OpenManus是一个基于大语言模型(LLM)的智能体框架,它的设计目标是创建一个灵活、可扩展且功能强大的系统,使AI能够通过各种工具与外部世界交互,从而解决复杂的任务。
与传统的聊天机器人不同,OpenManus不仅能够理解和生成文本,还能够执行具体的操作,如搜索信息、浏览网页、执行代码和保存文件等。这种能力使其成为一个真正的”智能助手”,而不仅仅是一个对话系统。
OpenManus的核心理念是”思考-行动”循环,即智能体先分析当前状态和任务需求(思考),然后选择并执行适当的工具(行动),接着基于执行结果进行下一轮思考。这种循环使智能体能够逐步解决复杂问题,同时保持对任务的连贯理解。
OpenManus的项目结构清晰而模块化,主要包括以下几个部分:
这种结构使得各个组件之间的职责划分清晰,便于维护和扩展。
1) 智能体系统
智能体系统是OpenManus的核心,它采用了层次化的设计:
- BaseAgent:提供基本的状态管理和执行循环
- ReActAgent:实现思考-行动循环模式
- ToolCallAgent:实现工具调用机制
- Manus:集成多种工具的具体智能体实现
这种层次化设计使得代码更加模块化和可扩展,每个层次只需关注自己的职责。
2) 工具系统
工具系统为智能体提供了与外部世界交互的能力:
- BaseTool:所有工具的抽象基类
- ToolCollection:工具的集合和管理器
- 具体工具:如PythonExecute、GoogleSearch、BrowserUseTool等
每个工具都有明确的名称、描述和参数规范,使LLM能够正确选择和使用它们。
3) 记忆系统
记忆系统使智能体能够在多个步骤中保持上下文连贯性:
- Memory:存储交互历史的容器
- Message:表示不同类型消息的结构
记忆系统记录了用户输入、LLM响应和工具执行结果,使智能体能够基于历史信息做出决策。
4) LLM接口
LLM接口负责与大语言模型(如OpenAI的GPT模型)通信:
- LLM:封装了与LLM API的交互
- ToolResponse:表示LLM响应的结构
LLM接口将智能体的记忆和工具信息传递给LLM,并解析LLM的响应。
5) 流程控制
流程控制组件管理不同类型的执行流程:
- BaseFlow:所有流程的抽象基类
- PlanningFlow:实现规划和执行的流程
- FlowFactory:创建不同类型流程的工厂
流程控制使OpenManus能够支持不同的执行模式,如规划式执行。
OpenManus具有几个显著的技术特点:
- 异步编程:广泛使用进行异步操作,提高I/O效率
- 模块化设计:清晰的组件划分和接口定义,便于维护和扩展
- 错误处理:多层次的错误捕获和恢复机制,提高系统稳定性
- 工具抽象:统一的工具接口,便于添加新工具
- 记忆管理:完善的记忆系统,支持上下文连贯的多步骤任务
这些特点使OpenManus成为一个强大而灵活的智能体框架,能够应对各种复杂任务。
通过这个项目,可以看到AI智能体如何从简单的对话系统演变为能够执行具体操作的助手,这代表了AI应用的一个重要发展方向。在接下来的章节中,下文将深入探讨OpenManus的各个组件和机制,揭示其内部工作原理。
BaseAgent是所有智能体的基类,位于中。它提供了智能体的基本功能:
核心属性
- :智能体的名称
- :智能体的描述
- :系统级指令提示
- :决定下一步行动的提示
- :语言模型实例
- :智能体的记忆存储
- :当前智能体状态(IDLE、RUNNING、FINISHED、ERROR)
主要方法
- :执行智能体的主循环
- :执行单个步骤(抽象方法,需要子类实现)
- :更新智能体的记忆
- :检测智能体是否陷入循环
- :处理卡住状态
BaseAgent的方法是智能体执行的核心,它实现了一个循环,在循环中不断调用方法,直到任务完成或达到最大步骤数:
ReActAgent继承自BaseAgent,位于中。它实现了思考-行动循环模式,这是一种强大的智能体决策框架。
核心方法
- :处理当前状态并决定下一步行动(抽象方法)
- :执行决定的行动(抽象方法)
- :执行单个步骤(实现了BaseAgent的抽象方法)
ReActAgent的方法实现了思考-行动循环:
这种思考-行动模式非常适合智能体的决策过程,它模拟了人类的思考方式:先分析情况,再采取行动。
ToolCallAgent继承自ReActAgent,位于中。它实现了工具调用机制,使智能体能够使用各种工具来完成任务。
核心属性
- :可用工具集合
- :工具选择模式(”none”、”auto”、”required”)
- :特殊工具名称列表
- :工具调用列表
主要方法
- :实现了ReActAgent的抽象方法,使用LLM决定使用哪些工具
- :实现了ReActAgent的抽象方法,执行工具调用
- :执行单个工具调用
- :处理特殊工具执行和状态变化
ToolCallAgent的方法使用LLM来决定使用哪些工具:
ToolCallAgent的方法执行工具调用并处理结果:
Manus继承自ToolCallAgent,位于中。它是用户直接交互的主要智能体,集成了多种工具。
核心属性
- :”Manus”
- :”一个可以使用多种工具解决各种任务的多功能智能体”
- :来自的系统提示
- :来自的下一步提示
- :包含PythonExecute、GoogleSearch、BrowserUseTool、FileSaver和Terminate的工具集合
- :20(最大步骤数)
层次结构的优势
- 代码重用:每个层次只需实现自己特有的功能,其他功能可以从父类继承。
- 关注点分离:
- BaseAgent处理基本的状态管理和执行循环
- ReActAgent实现思考-行动模式
- ToolCallAgent处理工具调用
- Manus集成特定工具和提示
- 灵活性和可扩展性:可以通过继承现有智能体类来创建新的智能体类型,而不需要修改现有代码。
- 维护性:每个层次的代码都相对简单和专注,使得代码更容易理解和维护。
- 测试性:可以独立测试每个层次的功能,简化测试过程。
智能体执行流程
当用户输入一个请求时,执行流程如下:
- 请求被传递给Manus智能体的方法(继承自BaseAgent)
- 方法进入一个循环,重复调用方法(继承自ReActAgent)
- 方法首先调用方法(ToolCallAgent实现)来决定使用哪些工具
- 然后调用方法(ToolCallAgent实现)来执行工具调用
- 工具执行结果被添加到记忆中,用于后续决策
- 重复这个过程,直到任务完成或达到最大步骤数
这种层次化设计使得OpenManus项目能够以一种模块化、可维护的方式实现复杂的智能体行为。
OpenManus中的工具是经过精心设计的软件组件,它们主要是规范了输入输出的功能模块,而不是完全智能化的应用。下文来详细解析这些工具的实现机制。
所有工具都继承自抽象基类,这个基类定义了工具的基本结构:
这个架构确保了所有工具都有统一的接口,方便智能体调用和管理。
PythonExecute:代码执行工具
工具允许执行Python代码:
这个工具主要是一个代码执行器,它创建了一个受限的执行环境,并使用Python的函数来执行代码。它不是智能化的应用,而是一个规范了输入输出的功能模块。
GoogleSearch:搜索工具
工具允许执行网络搜索:
这个工具是一个搜索接口封装,它调用来执行实际的搜索操作。可能是一个API客户端,用于调用Google搜索API或其他搜索服务。
BrowserUseTool:浏览器控制工具
工具允许控制浏览器:
这个工具是一个浏览器自动化接口,它使用类(可能基于Playwright或Selenium)来控制浏览器。它提供了一组标准化的操作(如导航、点击、输入文本等),但本身并不包含智能化的逻辑。
FileSaver:文件保存工具
工具允许保存内容到文件:
这个工具是一个简单的文件操作接口,它使用库(异步文件I/O)来保存内容到文件。它是一个非常基础的功能模块,没有智能化的逻辑。
Terminate:终止工具
工具用于结束智能体的执行:
这个工具非常简单,它只是返回一个状态消息。实际的终止逻辑是在的方法中实现的,它会将智能体的状态设置为。
在OpenManus框架中,工具与智能体之间形成了一种独特而高效的协作模式,这种模式可以概括为”智能体决策,工具执行”。这种协作充分发挥了大语言模型的推理能力和专用工具的执行能力,形成了一个强大的组合。
决策与执行的分离
OpenManus中最核心的协作理念是将决策与执行明确分离:
- 智能体负责决策:利用LLM的强大理解和推理能力,分析任务需求,选择合适的工具,确定工具参数,解释工具执行结果。
- 工具负责执行:接收智能体提供的参数,执行特定功能,返回执行结果,不参与决策过程。
这种分离使系统既有LLM的灵活性和创造性,又有专用工具的可靠性和确定性。
协作流程
工具与智能体的协作流程可以分为以下几个步骤:
- 任务分析:智能体分析用户请求,理解任务需求。
- 工具选择:智能体从可用工具列表中选择合适的工具。
- 参数准备:智能体确定工具所需的参数。
- 工具调用:智能体通过工具调用机制执行工具。
- 结果处理:智能体接收工具执行结果,进行分析和解释。
- 下一步决策:智能体根据结果决定下一步行动。
接口标准化
为了使协作顺畅,OpenManus对工具接口进行了标准化:
- 统一的工具描述:每个工具都有名称、描述和参数规范,使LLM能够理解工具的功能和用法。
- 统一的调用方式:所有工具都通过方法调用,参数通过关键字参数传递。
- 统一的结果格式:工具执行结果统一为字符串或特定的结果对象,便于智能体处理。
这种标准化使得添加新工具变得简单,只需实现标准接口即可。
错误处理与恢复
协作模式中的一个重要方面是错误处理与恢复:
- 工具执行错误:工具捕获执行过程中的异常,返回错误信息而不是抛出异常。
- 智能体处理错误:智能体接收错误信息,分析原因,尝试其他方法或工具。
- 多次尝试:如果一种方法失败,智能体可以尝试其他方法,直到任务完成或达到最大尝试次数。
这种错误处理机制使得系统在面对各种异常情况时仍能保持稳定运行。
在OpenManus中,工具选择主要在类的方法中实现。
工具选择的核心代码
的方法是工具选择的核心:
工具选择的关键步骤
- 1) 准备工具列表
首先,智能体需要准备可用工具的列表。这在类中通过属性设置:
每个工具都有一个方法,将工具转换为LLM可以理解的函数调用格式:
- 2) 调用LLM进行工具选择
关键步骤是调用方法,这个方法会将所有可用工具的信息传递给LLM,让LLM决定使用哪些工具:
- 3) LLM如何选择工具
在类的方法中,会构建一个请求发送给OpenAI API:
LLM会根据当前任务和上下文,选择最合适的工具来完成任务。这个选择过程是由LLM的模型能力决定的,它会分析任务需求并选择合适的工具。
工具选择的具体例子
假设用户输入:”帮我搜索关于Python异步编程的信息”
- 这个请求被传递给Manus智能体
- Manus调用方法,将请求和可用工具信息传递给LLM
- LLM分析请求,发现需要搜索信息,因此选择工具
- LLM返回一个包含工具调用信息的响应:
- 方法将这个工具调用信息保存在中,并返回表示需要执行行动
一旦工具被选择,下一步就是使用工具。这主要在类的方法中实现。
工具使用的核心代码
工具使用的关键步骤
- 1) 执行工具调用
方法负责执行单个工具调用:
- 2) 工具集合的执行
类的方法负责找到并执行指定的工具:
- 3) 具体工具的执行
每个工具都有一个方法,实现具体的功能。以工具为例:
工具使用的具体例子
继续上面的例子,用户要求搜索Python异步编程的信息:
- 方法已经选择了工具,并保存了工具调用信息
- 接下来,方法被调用,它会遍历中的每个工具调用
- 对于工具调用,方法被调用:
- 方法找到工具并执行:
- 方法找到工具实例并调用它的方法:
- 方法执行实际的搜索操作,并返回格式化的搜索结果:
- 这个结果被添加到智能体的记忆中,并返回给用户
特殊工具的处理
OpenManus还有一些特殊工具,如工具,它们需要特殊处理:
当工具被调用时,智能体的状态会被设置为,这会导致方法中的循环终止,从而结束智能体的执行。
在OpenManus中,信息在智能体的多次迭代中通过精心设计的记忆系统进行保存、传递和使用。这个系统确保了智能体能够在多个步骤中保持上下文连贯性,并基于历史信息做出决策。下文将详细解析这个过程。
记忆系统的实现
OpenManus使用类来保存信息。这个类在中定义:
类非常简单,它主要是一个消息列表的包装器,提供了添加、获取和清空消息的方法。
消息的结构
每个消息都是类的实例,这个类定义了消息的结构:
每个消息都有一个角色(系统、用户、助手或工具)和内容。助手消息可能还包含工具调用信息,工具消息包含工具调用ID和工具名称。
信息保存的时机
信息在多个地方被保存到记忆中:
- 用户输入保存
当用户提供输入时,它会被保存到记忆中:
- LLM响应保存
当LLM生成响应时,它会被保存到记忆中:
- 工具执行结果保存
当工具执行完成时,结果会被保存到记忆中:
消息传递给LLM
在每次调用LLM时,记忆中的消息会被传递给LLM,使其能够了解历史上下文:
这里的就是记忆中的消息列表。
消息格式转换
在传递给LLM之前,消息需要转换为LLM能够理解的格式:
这个方法将对象转换为包含适当字段的字典,这些字典符合OpenAI API的消息格式要求。
LLM使用历史信息
LLM会使用传递给它的所有历史消息来生成响应。这使得它能够:
- 理解当前任务的上下文
- 记住之前的交互
- 基于之前的工具执行结果做出决策
- 避免重复之前的错误
例如,如果用户要求搜索信息,智能体使用工具获取结果,然后用户要求总结这些结果,LLM会使用记忆中的搜索结果来生成总结,而不需要重新搜索。
记忆长度管理
由于LLM的上下文窗口有限,记忆中的消息数量可能需要限制。OpenManus可能使用以下策略来管理记忆长度:
- 保留最新的N条消息
- 保留重要的消息(如系统提示、用户请求)
- 压缩或摘要化旧消息
虽然代码中没有明确实现这些策略,但这是处理长期交互的常见做法。
记忆持久化
当前的实现中,记忆只存在于内存中,当智能体实例被销毁时记忆也会丢失。为了支持长期记忆,可能需要将记忆持久化到数据库或文件中。
具体例子:多步骤任务执行
下文将通过一个具体例子来说明信息如何在多次迭代中流动:
假设用户要求:”帮我找到关于Python异步编程的信息,然后创建一个简单的异步程序”
步骤1:理解请求
- 用户请求被添加到记忆中:
- LLM接收这个消息,并决定首先需要搜索信息
- LLM的响应被添加到记忆中:
步骤2:执行搜索
- 工具被执行,搜索”Python异步编程”
- 搜索结果被添加到记忆中:
- LLM接收所有历史消息,包括搜索结果
- LLM分析搜索结果,决定创建一个异步程序
- LLM的响应被添加到记忆中:
步骤3:创建程序
- 工具被执行,创建并运行一个异步程序
- 执行结果被添加到记忆中:
- LLM接收所有历史消息,包括程序执行结果
- LLM生成最终响应,解释程序并总结任务完成情况
- LLM的响应被添加到记忆中:
在这个过程中,信息不断被添加到记忆中,并在每次LLM调用时传递给LLM,使其能够基于完整的历史上下文做出决策。
OpenManus中的信息通过记忆系统在多次迭代中流动。用户输入、LLM响应和工具执行结果都被保存到记忆中,并在每次LLM调用时传递给LLM。这使得智能体能够保持上下文连贯性,累积知识,分解任务,并从错误中恢复。
这种信息保存、传递和使用机制有几个重要优势:
- 上下文连贯性 :智能体能够保持对话的连贯性,理解之前的交互并基于它们做出决策。
- 累积知识:智能体可以累积知识,将之前步骤获取的信息用于后续步骤。
- 任务分解:复杂任务可以分解为多个步骤,每个步骤都基于之前步骤的结果。
- 错误恢复:如果某个步骤失败,智能体可以看到错误信息并尝试不同的方法。
这种设计使得OpenManus能够处理复杂的多步骤任务,每个步骤都能利用之前步骤获取的信息,创造出超越单个步骤能力的解决方案。
在OpenManus中,确保LLM给出正确响应以及处理错误响应是一个重要的环节
系统提示和指令
OpenManus通过精心设计的系统提示来引导LLM生成正确的响应。在类中,系统提示定义如下:
这个包含了详细的指导,告诉LLM如何分析任务、选择工具和格式化响应。例如:
工具参数验证
每个工具都定义了明确的参数规范,这些规范会在调用LLM时传递给它:
这些参数规范告诉LLM每个工具需要哪些参数,哪些是必需的,以及它们的类型和描述。
工具选择模式
类提供了不同的工具选择模式:
- :不要求LLM使用工具
- :LLM可以自行决定是否使用工具
- :要求LLM必须使用工具
这个设置会影响发送给OpenAI API的参数:
尽管有上述机制,LLM仍可能给出不正确的响应。OpenManus通过多层错误处理来应对这种情况:
响应解析和验证
在类的方法中,会解析和验证LLM的响应:
这个方法会尝试解析LLM返回的工具调用参数,如果解析失败(例如,参数不是有效的JSON),会记录错误但不会中断执行。
工具执行错误处理
在的方法中,会捕获工具执行过程中的任何异常:
如果工具执行失败,会返回一个错误消息,而不是中断整个执行流程。
工具参数验证
在的方法中,会检查工具是否存在:
如果指定的工具不存在,或者执行过程中抛出异常,会返回一个对象,而不是中断执行。
具体工具的参数验证
每个工具都可以实现自己的参数验证逻辑。例如,工具会检查查询参数是否有效:
卡住状态检测
类实现了卡住状态检测机制,用于处理LLM陷入循环的情况:
如果检测到智能体陷入循环(最近几条消息内容相同),会添加一条干预消息,提示LLM尝试不同的方法。
例子1:工具参数不正确
假设LLM选择了工具,但提供了错误的参数格式:
处理流程:
- 方法尝试解析参数,但会失败
- 错误会被记录,但不会中断执行
- 方法会收到一个空的参数字典
- 方法会检测到无效参数并返回错误消息
- 错误消息会被添加到智能体的记忆中
- 在下一个步骤中,LLM会看到这个错误消息,并可能尝试修正参数格式
例子2:工具不存在
假设LLM选择了一个不存在的工具:
处理流程:
- 方法会调用方法
- 方法会检查工具是否存在
- 由于工具不存在,会返回一个错误消息:”Tool nonexistent_tool is invalid”
- 这个错误消息会被添加到智能体的记忆中
- 在下一个步骤中,LLM会看到这个错误消息,并可能选择一个存在的工具
例子3:工具执行失败
假设LLM选择了工具,参数正确,但搜索API暂时不可用:
处理流程:
- 方法会调用方法
- 方法会尝试调用搜索API
- 由于API不可用,会抛出异常
- 异常会被捕获,并返回一个错误消息:”Error performing Google search: API not available”
- 这个错误消息会被添加到智能体的记忆中
- 在下一个步骤中,LLM会看到这个错误消息,并可能尝试其他方法或工具
OpenManus通过多层错误处理机制来确保即使LLM给出不正确的响应,系统也能继续运行:
- 预防措施:
- 精心设计的系统提示
- 明确的工具参数规范
- 灵活的工具选择模式
- 错误处理:
- 响应解析和验证
- 工具执行错误捕获
- 工具参数验证
- 卡住状态检测和干预
这种设计使得OpenManus能够在各种情况下保持稳定运行,即使LLM偶尔给出不正确的响应。
OpenManus作为一个功能强大的智能体框架,可以应用于多种场景:
自动化助手
OpenManus可以作为个人或团队的自动化助手,执行各种任务:
- 信息收集与整理:自动搜索、浏览网页并整理信息
- 代码生成与测试:根据需求生成代码,并自动执行测试
- 文档处理:自动生成、修改和整理文档
- 数据分析:执行数据处理脚本,生成分析报告
研究辅助工具
研究人员可以使用OpenManus来加速研究过程:
- 文献调研:自动搜索和总结相关文献
- 数据处理:执行数据清洗和转换脚本
- 实验自动化:设计、执行和记录实验
- 结果可视化:生成图表和可视化展示
教育与学习工具
OpenManus可以作为教育和学习的辅助工具:
- 交互式教程:创建能够执行代码示例的教程
- 问题解答:回答学习问题并提供实际示例
- 编程练习:生成编程练习并评估解答
- 知识探索:帮助学习者探索新领域
开发辅助系统
软件开发人员可以使用OpenManus来提高开发效率:
- 代码生成:根据需求生成代码框架或完整实现
- 调试辅助:分析错误信息并提供修复建议
- 文档生成:自动生成代码文档和API说明
- 测试自动化:生成测试用例并执行测试
OpenManus的模块化设计使得添加新工具变得简单直接。以下是添加新工具的步骤:
1) 创建工具类
首先,创建一个继承自的新类:
2) 实现工具功能
在方法中实现工具的具体功能。确保:
- 处理所有可能的异常
- 返回清晰的结果或错误信息
- 使用异步编程()处理I/O操作
3) 添加工具到智能体
将新工具添加到智能体的可用工具列表中:
或者修改现有的Manus智能体:
4) 更新系统提示(可选)
如果新工具需要特殊的使用说明,可以更新系统提示:
OpenManus的层次化设计使得定制智能体变得灵活多样:
1) 继承现有智能体
最简单的方法是继承现有的智能体类:
2) 自定义工具集
为特定任务定制工具集:
3) 自定义提示模板
为智能体定制专门的提示模板:
4) 自定义执行流程
通过重写、或方法来自定义执行流程:
OpenManus的设计使其易于集成到各种系统中:
1) Web应用集成
将OpenManus集成到Web应用中:
2) Agent 智能体 桌面应用集成
将OpenManus集成到桌面应用中:
3) API服务集成
将OpenManus作为API服务提供:
4) 自动化工作流集成
将OpenManus集成到自动化工作流中:
OpenManus作为一个开源项目,有多个潜在的发展方向:
多智能体协作
实现多个智能体之间的协作,每个智能体专注于特定领域:
- 专家智能体:不同领域的专家智能体
- 协调智能体:负责分配任务和整合结果
- 评估智能体:评估其他智能体的输出质量
- 对抗智能体:提供批判性思考和挑战
增强学习能力
为智能体添加更强的学习能力:
- 长期记忆:持久化存储重要信息
- 知识库集成:连接到专门的知识库
- 示例学习:从用户示例中学习新技能
- 反馈学习:根据用户反馈调整行为
自主性增强
增强智能体的自主性:
- 自主规划:智能体自主规划解决问题的步骤
- 自主探索:主动探索未知领域
- 自主学习:识别知识缺口并主动学习
- 自主决策:在不确定情况下做出决策
工具生态扩展
扩展工具生态系统:
- 多模态工具:处理图像、音频、视频的工具
- 专业领域工具:针对特定领域的专业工具
- 工具市场:允许社区贡献和分享工具
- 工具组合:自动组合多个工具创建复杂功能
安全与隐私增强
加强安全性和隐私保护:
- 沙箱执行:更安全的代码执行环境
- 权限控制:细粒度的工具访问权限
- 隐私保护:敏感信息的处理机制
- 审计日志:详细记录智能体的所有操作
用户体验优化
改善用户与智能体的交互体验:
- 自然对话:更自然的对话界面
- 多模态交互:支持语音、图像等交互方式
- 进度反馈:实时显示任务进度
- 可解释性:解释决策过程和推理逻辑
OpenManus作为一个灵活且强大的智能体框架,有着广阔的应用前景和发展空间。随着技术的进步和社区的贡献,它有潜力成为构建下一代AI应用的重要基础设施。
关于大模型的可靠性
大模型的输出仍然需要大量后期校验来修正,这一过程既可以依赖人工编写的规则,也可以借助大模型自身进行自纠自查。或许,随着技术的发展,模型自我优化的能力会进一步增强,使得人工干预的成本逐步降低。
关于 Agent 开发
当前,大模型的主流交互方式仍然较为低效,Agent 的引入可以在一定程度上提升交互效率。然而,这种形态仍让我联想到清朝末年“马拉火车”的景象——新旧技术的混搭或许只是过渡阶段,最终更高效、更自然的交互方式将会取代它。
关于 Prompt 工程
Prompt 工程从最初的火热讨论,到如今的相对沉寂,反映了技术的演进趋势:交互方式正变得越来越自然,复杂性逐渐被底层封装,最终回归到最朴素的形态。然而,在 Agent 开发中,Prompt 设计仍然是重要环节,或许未来这一过程也会被进一步抽象化,让开发者无需直接接触底层逻辑,而是通过更直观的方式操控大模型。
关于大模型之间的交互
曾经看到一个视频,内容是两个大模型通过语音聊天,在确认对方也是 AI 后,切换为一种奇特的电子音交互模式。这是否真实尚未求证,但这一思路令人遐想——或许未来的大模型之间需要一种全新的交互协议,使得它们能够高效、准确地沟通,而非模拟人类语言的方式。
关于软件开发
从单机到联网,从物理机到云,每一次基础设施的变革都推动了软件开发范式的演进。如今,大模型正在成为新一代的基础设施,这意味着未来的软件开发可能需要与大模型深度适配,甚至直接基于大模型构建。也许,Agent 只是过渡形态,更激进的方式是——模型即软件。
关于端侧智能
大模型的横空出世,使得在联网环境下,边缘计算和端侧智能的意义似乎变得模糊。当计算能力可以按需获取,设备本地的智能化或许不再是核心问题,而是如何高效地利用模型资源,真正实现智能无处不在。
发布者:全栈程序员-站长,转载请注明出处:https://javaforall.net/236158.html原文链接:https://javaforall.net
