从单 Agent 到多 Agent 的案例落地实践 原创

关于 Agent 的定义目前还没有形成共识，目前有3个代表性的定义：

流行最广的是前 OpenAI 研究与安全副总裁 Lilian Weng 对 Agent 的定义：Agent = LLM + Planning + Tools + Memory。

除此之外，LangChain 对 Agent 的定义为：使用 LLM 决定应用程序控制流的系统。

OpenAI 对 Agent 的定义是：Agent 是能够代表用户自主完成任务的系统。

尽管目前对 Agent 的定义还没形成共识，但是大家对 Agentic System（智能系统）基本的共识是：Agentic System 是一种有目标、基于环境的决策系统。与 LLM 最大的区别在于，Agentic System 可以与现实世界交互，从感知环境开始，做出决策并执行，影响环境，然后基于反馈调整，不断持续迭代循环。

1、Agentic System 架构设计剖析

一个完整的 Agentic System 架构包含四个核心组成部分：

• 感知：为大模型构建上下文信息。常见的方法包括检索增强生成（RAG），查询结构化数据（比如：数据库、网页内容）或者检索历史记录（比如：长短期记忆）。
• 决策：本质上是 Planning 规划过程。可以通过规则引擎（Workflow）实现，也可以由大语言模型（LLM）驱动（自主 Agent），或者借助外部规划器。在设计时需要权衡泛化能力和准确性--LLM 驱动的决策泛化能力强，但不确定性较高；而基于规则的工作流泛化能力较弱，但更可控。
• 执行：通过调用工具来改变环境。包括 API 调用（比如：REST、RPC、SQL、函数调用）或与图形软件的集成（比如：Anthropic 的 Computer use）。
• 反馈：用于评估和迭代的机制。反馈可以通过人工标注、规则或模型生成，更新可以是离线的或在线的。

这个闭环构成了 Agent 的基础单元（building block）。复杂的 Agent 可以由多个小 Agent 组成，复杂业务逻辑大决策通常由一系列小型决策构成。

2、多 Agentic System 架构设计原则

当多个 Agent 协同工作时，就构成了 Multi-Agent 系统。在设计 Multi-Agent 系统时，要避免过度拆分。每个 Agent 应该代表一个明确的业务决策点，并可以通过持续反馈进行优化。只有在单个 Agent 无法满足需求时，才考虑引入更多的 Agent。

第一、借鉴分布式系统的思路，可以把 Agent 比作一台计算机：

• LLM（大语言模型）是计算机的CPU，负责处理和运算。
• Context window（上下文窗口）是计算机的内存，用于临时存储信息。
• 向量数据库是计算机的硬盘，用于长期存储数据。
• 工具（Tools）是计算机上的程序，用于执行特定任务。

分布式系统主要解决以下三个问题：

1. 性能不足：单台计算机的计算或存储能力有限。
2. 容错性：单个系统容易出现故障，需要多个系统协同工作以提高可靠性。
3. 协作：不同团队负责不同的微服务，需要协同工作。

Multi-Agent 系统的设计原则与此类似：

• 解决单次 LLM 调用智力不足的问题：当单个 Agent 无法处理复杂的任务时，可以引入多个 Agent 协同工作。
• 提高容错性：多个 Agent 协同工作可以提高系统的可靠性和稳定性。
• 促进协作：不同 Agent 可以负责不同的任务或决策点，实现更复杂的业务逻辑。

第二、Agentic System 架构演进

Multi-Agent 系统的设计应从单个 Agent 开始，只有在单个 Agent 无法满足需求时，才逐步过渡到多 Agent 架构。这种逐步扩展的方式有助于保持系统的简洁性和可维护性。

3、从单 Agent 到多 Agent 智能助手案例架构演进

智能助手的演进遵循了从单 Agent 到 Multi-Agent 的路径：

• 初始阶段：仅有产品问答模块，使用简单的 RAG（检索增强生成）技术。
• 技能扩展：添加多种技能，但用户需要手动切换。
• 意图识别：开发意图识别 Agent，但仍为单 Agent 架构。
• 多 Agent 体系：随着场景复杂化和多团队协作需求的增加，逐步过渡到多 Agent 体系。

除架构演进外，我们还进行了多项技术优化：

• RAG 优化：增加查询改写功能，提高系统的鲁棒性。用户不一定会提出完美的问题，通过查询扩展和改写，系统能够更好地处理各种输入变化。
• 知识图谱：引入 GraphRAG 技术，将产品知识问答的准确度从 76% 提升到 93%。对于算法实力一般但工程能力强的团队，知识图谱是模型后训练的实用替代方案。
• 强化学习：在经营分析场景中，将评价体系（如 AARRR 模型）转化为强化学习的奖励函数，实现模型的持续优化。

当然，我们也在经营分析场景中基于 SFT（监督微调）和强化学习进行微调。我们之前基于经营分析 Agent 构建的数据集和评价体系，天然地过渡到了 RL（强化学习）领域的环境和奖励函数的构建。我们之前评价一个经营建议好坏的一个重要指标是思考过程是否符合 AARRR 模型，现在在 RL 中，这个指标也成为了奖励函数之一。

本文转载自​​玄姐聊AGI​​  作者：玄姐