192 lines
16 KiB
Markdown
192 lines
16 KiB
Markdown
看到一篇论文：
|
||
https://arxiv.org/abs/2501.04227
|
||
|
||
我认同论文的观点，并感觉，未来的应用系统将是多Agent协同、人机协同的系统，可以将人的更多精力用于创造性的思考，而不是放在低级的实现上。
|
||
|
||
对此，你有什么看法？
|
||
|
||
|
||
回到你之前提到的论文（[https://arxiv.org/abs/2501.04227](https://arxiv.org/abs/2501.04227)），根据我搜索到的信息，这篇论文名为《Agent Laboratory: Using LLM Agents as Research Assistants》（智能体实验室：使用大型语言模型智能体作为研究助理）。它探讨了如何使用基于大型语言模型的智能体来辅助甚至完成整个研究过程，包括文献综述、实验设计和报告撰写等。
|
||
|
||
如果你认同这篇论文的观点，并认为未来的应用系统将是多智能体协同、人机协同的系统，这与人工智能领域目前的发展趋势是相符的。这种系统有潜力将人类从重复性的、低级的实现工作中解放出来，从而可以将更多精力投入到创造性的思考和决策中。
|
||
|
||
我的看法是：
|
||
|
||
* **提高效率：** 多智能体协同可以显著提高工作效率，每个智能体可以负责特定的任务，并通过协作完成复杂的工作流程。
|
||
* **增强能力：** 人机协同可以结合人类的创造力、直觉和经验，以及机器的处理能力和速度，从而增强系统的整体能力。
|
||
* **新的挑战：** 这种系统也带来新的挑战，例如如何有效地管理和协调多个智能体之间的交互，如何确保系统的可靠性和安全性，以及如何处理伦理和法律方面的问题。
|
||
|
||
总的来说，多智能体协同和人机协同是未来应用系统发展的重要方向，它将深刻地改变我们的工作和生活方式。
|
||
|
||
|
||
那么帮用户点一份披萨，这个用例场景里面，大致会用到哪些Agent，各司什么职，哪些地方需要人机协同？
|
||
|
||
为一个用户点一份披萨的用例场景，可以很好地展示多Agent协同和人机协同的应用。以下是一个可能的Agent分工和协作流程，以及人机协同的关键点：
|
||
|
||
**Agent角色及职责：**
|
||
|
||
1. **用户意图理解Agent（User Intent Understanding Agent）：**
|
||
* 职责：负责理解用户的点餐意图，包括披萨口味、尺寸、配料、数量、送餐地址、送餐时间等。
|
||
* 输入：用户的语音或文字输入（例如：“我想点一个大号的夏威夷披萨，加芝士，送到XX地址，今晚7点送到”）。
|
||
* 输出：结构化的订单信息（例如：`{pizza_type: "夏威夷", size: "大号", toppings: ["芝士"], address: "XX地址", delivery_time: "今晚7点"}`）。
|
||
|
||
2. **披萨店选择Agent（Restaurant Selection Agent）：**
|
||
* 职责：根据用户的位置、口味偏好、价格预算、送餐速度等因素，选择合适的披萨店。
|
||
* 输入：用户的位置信息、订单信息。
|
||
* 输出：推荐的披萨店列表（包含店铺信息、评分、送餐时间等）。
|
||
|
||
3. **订单生成Agent（Order Generation Agent）：**
|
||
* 职责：将用户订单信息转换为特定披萨店的订单格式，并与披萨店的系统进行对接。
|
||
* 输入：用户订单信息、披萨店信息。
|
||
* 输出：符合披萨店要求的订单信息。
|
||
|
||
4. **支付Agent（Payment Agent）：**
|
||
* 职责：处理用户的支付流程，包括选择支付方式、验证支付信息、完成支付等。
|
||
* 输入：用户选择的支付方式、订单金额。
|
||
* 输出：支付结果（成功或失败）。
|
||
|
||
5. **送餐跟踪Agent（Delivery Tracking Agent）：**
|
||
* 职责：跟踪披萨的制作和配送状态，并及时向用户更新订单状态。
|
||
* 输入：订单信息、披萨店提供的配送信息。
|
||
* 输出：订单状态更新（例如：“已下单”、“正在制作”、“已发货”、“已送达”）。
|
||
|
||
6. **用户反馈Agent（Feedback Agent）：**
|
||
* 职责：收集用户对本次点餐体验的反馈，包括披萨口味、送餐速度、服务质量等。
|
||
* 输入：用户评价。
|
||
* 输出：用户反馈信息，用于改进系统和服务。
|
||
|
||
**人机协同的关键点：**
|
||
|
||
1. **意图确认：** 用户意图理解Agent可能无法完全准确地理解用户的意图，例如用户口音较重、表达不清晰等情况。这时需要人工介入，通过对话或其他方式确认用户的真实意图。例如，系统可以询问：“您是要夏威夷披萨，加芝士吗？”
|
||
2. **餐厅选择：** 披萨店选择Agent可能会提供多个推荐选项，这时需要用户进行最终选择。系统可以展示各个店铺的评分、评价、优惠活动等信息，帮助用户做出决策。
|
||
3. **特殊需求：** 用户可能有特殊的点餐需求，例如对配料的特殊要求、对送餐时间的精确要求等。这些需求可能超出Agent的处理能力，需要人工进行处理和协调。
|
||
4. **异常处理：** 在订单处理过程中可能会出现各种异常情况，例如披萨店缺货、支付失败、送餐延误等。这些情况需要人工介入进行处理和解决。
|
||
5. **用户反馈：** 用户反馈Agent可以自动收集用户反馈，但对于一些复杂的或负面的反馈，可能需要人工进行分析和跟进。
|
||
|
||
**流程示例：**
|
||
|
||
1. 用户通过语音输入：“我想点一个大号的夏威夷披萨，加芝士，送到XX地址，今晚7点送到”。
|
||
2. 用户意图理解Agent将语音转换为结构化的订单信息。
|
||
3. 披萨店选择Agent根据用户位置和口味偏好，推荐几家附近的披萨店。
|
||
4. 用户在推荐列表中选择一家披萨店。
|
||
5. 订单生成Agent将订单信息发送给披萨店。
|
||
6. 支付Agent处理用户的支付流程。
|
||
7. 送餐跟踪Agent跟踪订单状态，并及时通知用户。
|
||
8. 送达后，用户反馈Agent收集用户评价。
|
||
|
||
通过以上例子可以看出，多Agent协同可以高效地完成点餐流程，而人机协同则保证了流程的灵活性和鲁棒性，从而提供更好的用户体验。
|
||
|
||
是的，将多智能体系统与现有系统或第三方（比如支付、外卖平台、地图服务等）对接的部分，通常可以广义地称为Function Calling（函数调用）。更具体来说，它涉及到以下几个密切相关的概念：
|
||
|
||
* **API（应用程序接口）：** 这是不同软件系统之间进行交互的标准方式。API定义了系统之间如何交换数据和执行操作。例如，支付平台的API允许其他应用程序请求支付、查询交易状态等。Function Calling本质上就是调用这些API。
|
||
* **插件（Plugins）：** 在某些语境下，特别是大型语言模型（LLM）的应用中，插件可以看作是Function Calling的一种具体实现。插件封装了对特定API的调用，使得LLM可以通过简单的指令来使用外部功能。
|
||
* **外部工具调用（External Tool Calling）：** 这是对Function Calling的另一种描述，强调了LLM或智能体利用外部工具来完成任务的能力。这些工具可以是各种软件服务、数据库、甚至是物理设备。
|
||
* **集成（Integration）：** 从更高的层面来看，Function Calling是系统集成的一个重要组成部分。它使得不同的系统能够协同工作，共同完成复杂的任务。
|
||
|
||
在多智能体系统中，Function Calling扮演着至关重要的角色：
|
||
|
||
* **扩展能力：** 智能体本身的能力是有限的，通过Function Calling，它们可以利用外部系统的强大功能，例如支付、地图导航、数据查询等。
|
||
* **实现协同：** 不同的智能体可以通过Function Calling来共享信息、传递指令、协调行动，从而实现更高效的协同工作。
|
||
* **连接现实世界：** Function Calling将虚拟的智能体世界与现实世界连接起来，使得智能体可以真正地影响和改变现实世界。
|
||
|
||
以你之前提到的点披萨的例子来说：
|
||
|
||
* **支付Agent调用支付平台的API** 完成支付，这就是Function Calling。
|
||
* **送餐跟踪Agent调用外卖平台的API** 查询订单状态，这也是Function Calling。
|
||
* **披萨店选择Agent调用地图服务的API** 获取用户位置附近的披萨店信息，同样是Function Calling。
|
||
|
||
所以，Function Calling是多智能体系统实现各种功能和与其他系统交互的关键机制。它使得智能体能够超越自身的能力限制，利用外部资源来完成更复杂、更有用的任务。虽然有不同的术语，但它们的核心概念是相同的：**通过标准化的接口调用外部功能。**
|
||
|
||
为一个多智能体系统打造协同架构，需要考虑多个关键特性，以确保智能体能够有效地协同工作，完成复杂的任务。以下是一些重要的特性，以及如何在架构中体现这些特性：
|
||
|
||
**1. 自主性 (Autonomy)：**
|
||
|
||
* **定义：** 每个智能体都应具备一定的自主性，能够在没有直接外部干预的情况下，根据自身的目标和环境信息做出决策和行动。
|
||
* **架构体现：**
|
||
* **本地决策模块：** 每个智能体拥有独立的决策模块，负责根据感知到的环境信息和自身的目标，选择合适的行动。
|
||
* **目标驱动：** 智能体的行为应由明确的目标驱动，这些目标可以是预先设定的，也可以是动态变化的。
|
||
* **有限的依赖：** 智能体之间的依赖关系应尽可能松散，以减少单个智能体故障对整个系统的影响。
|
||
|
||
**2. 协同能力 (Collaboration)：**
|
||
|
||
* **定义：** 智能体之间能够通过通信和交互，共享信息、协调行动，共同完成任务。
|
||
* **架构体现：**
|
||
* **通信机制：** 提供有效的通信机制，例如消息传递、共享内存等，使智能体能够交换信息。
|
||
* **协议和规范：** 定义智能体之间交互的协议和规范，例如消息格式、通信协议等，以确保通信的有效性和一致性。
|
||
* **协同策略：** 设计合理的协同策略，例如协商、合作、竞争等，以指导智能体之间的交互行为。
|
||
|
||
**3. 学习性 (Learning)：**
|
||
|
||
* **定义：** 智能体能够通过经验学习，改进自身的行为和性能，以适应不断变化的环境。
|
||
* **架构体现：**
|
||
* **学习机制：** 集成各种学习算法，例如强化学习、监督学习、深度学习等，使智能体能够从经验中学习。
|
||
* **知识库：** 维护一个共享的或分布式的知识库，存储智能体的经验和知识，并支持智能体之间的知识共享。
|
||
* **适应性：** 架构应支持智能体根据环境变化调整自身的行为和策略。
|
||
|
||
**4. 鲁棒性 (Robustness)：**
|
||
|
||
* **定义：** 系统能够抵抗各种干扰和故障，保持稳定的运行。
|
||
* **架构体现：**
|
||
* **冗余机制：** 采用冗余设计，例如备份智能体、备用通信通道等，以防止单点故障导致系统崩溃。
|
||
* **容错机制：** 设计容错机制，使系统能够在部分智能体失效的情况下继续运行。
|
||
* **监控和诊断：** 提供监控和诊断工具，及时发现和解决系统中的问题。
|
||
|
||
**5. 可扩展性 (Scalability)：**
|
||
|
||
* **定义：** 系统能够方便地增加或减少智能体的数量，以适应不同规模的任务。
|
||
* **架构体现：**
|
||
* **模块化设计：** 采用模块化设计，使智能体的添加和移除变得简单。
|
||
* **分布式架构：** 采用分布式架构，将系统部署在多个计算节点上，以提高系统的处理能力。
|
||
* **负载均衡：** 实现负载均衡机制，将任务合理地分配给各个智能体。
|
||
|
||
**6. 透明性 (Transparency)：**
|
||
|
||
* **定义：** 系统的行为和决策过程应尽可能透明，以便用户理解和信任。
|
||
* **架构体现：**
|
||
* **解释性机制：** 提供解释性机制，解释智能体做出的决策和行动的原因。
|
||
* **可视化工具：** 提供可视化工具，展示智能体之间的交互和协作过程。
|
||
* **可追溯性：** 记录智能体的行为和决策过程，以便进行分析和审计。
|
||
|
||
**结合之前的披萨订购例子，这些特性可以这样体现：**
|
||
|
||
* **自主性：** 每个Agent可以独立完成自己的任务，例如用户意图理解Agent不需要其他Agent的帮助就能理解用户点了什么。
|
||
* **协同能力：** 各个Agent通过传递结构化的订单信息进行协作，例如用户意图理解Agent将理解后的订单信息传递给披萨店选择Agent。
|
||
* **学习性：** 通过收集用户反馈，各个Agent可以不断改进自己的性能，例如用户意图理解Agent可以学习新的用户表达方式。
|
||
* **鲁棒性：** 如果某个Agent出现故障，系统可以尝试使用备用Agent或人工介入来完成任务。
|
||
* **可扩展性：** 系统可以方便地添加新的Agent，例如添加一个优惠券Agent，负责为用户查找优惠券。
|
||
* **透明性：** 系统可以向用户展示订单的处理流程，以及各个Agent的决策过程。
|
||
|
||
通过综合考虑以上特性，并将其有效地融入到架构设计中，可以构建出一个高效、可靠、灵活的多智能体协同系统，更好地解决各种复杂的实际问题。
|
||
|
||
|
||
未来的应用系统将是多Agent协同、人机协同的系统，可以将人的更多精力用于创造性的思考，而不是放在低级的实现上。
|
||
就以我同学问我“AI能点蒸饺么？”这个场景为例，我简单做个分解。
|
||
|
||
AI Agents（每一个Agent的输入与输出略掉，有兴趣可以单独聊）：
|
||
1. 用户意图理解Agent，理解用户的点餐意图，包括蒸饺的口味、配料、数量、送餐地址、送餐时间等。
|
||
2. 餐馆选择Agent，根据用户的位置、口味偏好、价格预算、送餐速度等因素，选择合适的餐馆。
|
||
3. 订单生成Agent，将用户订单信息转换为餐馆、或者第三方（美团、饿了）的订单格式，并与披萨店的系统进行对接。
|
||
4. 支付Agent，处理用户的支付流程，包括选择支付方式、验证支付信息、完成支付。
|
||
5. 送餐跟踪Agent，跟踪蒸饺的制作和配送状态，并及时向用户更新订单状态。
|
||
6. 用户反馈Agent，收集用户对本次点餐体验的反馈，包括口味、送餐速度、服务质量等。
|
||
|
||
人机协同的关键点：意图确认、餐馆选择、特殊需求（要不要香菜？）、异常处理和用户反馈。
|
||
|
||
这些Agent跑在一个多智能体协同架构中，这个架构应具有的特性包括：
|
||
1. 自主性：每个Agent可以独立完成自己的任务，例如用户意图理解Agent不需要其他Agent的帮助就能理解用户点了什么。
|
||
2. 协同能力：各个Agent通过传递结构化的订单信息进行协作，例如用户意图理解Agent将理解后的订单信息传递给披萨店选择Agent。
|
||
3. 学习性：通过收集用户反馈，各个Agent可以不断改进自己的性能，例如用户意图理解Agent可以学习新的用户表达方式。
|
||
4. 鲁棒性：如果某个Agent出现故障，系统可以尝试使用备用Agent或人工介入来完成任务。
|
||
5. 可扩展性：系统可以方便地添加新的Agent，例如添加一个优惠券Agent，负责为用户查找优惠券。
|
||
6. 透明性：系统可以向用户展示订单的处理流程，以及各个Agent的决策过程。
|
||
|
||
与现有系统或第三方的对接部分会有大量的Function Calling以使Agent能够超越自身的能力限制，利用外部资源来完成更复杂、更有用的任务。这个是传统的应用开发工程师需要做的：
|
||
1. 扩展能力：利用外部系统的强大功能，例如支付、地图导航、数据查询等。
|
||
2. 实现协同：共享信息、传递指令、协调行动，从而实现更高效的协同工作。
|
||
3. 连接现实世界：将虚拟的Agent世界与现实世界连接起来。
|
||
这个有新的开发需求，但是相比Agent不多了。
|
||
|
||
最后，Agent翻译成智能体，我感觉有些抓狂。
|
||
|
||
@ yinzei
|