问题背景：为什么需要多智能体

单智能体架构在简单场景表现良好，但面临四个核心瓶颈：

• 认知负荷过载：任务复杂时上下文被信息填满，关键细节被淹没
• 专业化困境：单一 Agent 难以在多领域同时达到专业水准
• 串行效率限制：可并行的子任务只能依次执行，耗时累加
• 错误累积效应：缺乏交叉校验，前期错误在后续环节放大

多智能体框架通过四条路径解决这些问题：

• 任务分解与并行化：拆分复杂任务为可并行子任务，缩短整体时间
• 专业化配置：每个 Agent 针对特定职责优化模型、工具、提示词
• 相互校验机制：多 Agent 交叉审查，降低错误率
• 人机协作优化：Agent 处理繁琐工作，人类专注关键决策

顺便一提，Harness Engineering（研发效能工程）关注通过工程化手段提升软件研发效率和质量。多智能体框架是 Harness Engineering 的重要组成部分，为研发流程智能化提供基础设施：

• 智能代码审查：安全 Agent、性能 Agent、规范 Agent 并行检查代码
• 自动化测试：测试策略 Agent 分析变更，测试生成 Agent 补充用例
• 需求分析：需求分析 Agent 提取关键点，任务分解 Agent 拆分开发任务

核心概念：多智能体框架的本质

什么是多智能体框架

多智能体框架是一类用于协调多个 AI 智能体协作完成任务的软件基础设施。它提供 Agent 定义、通信机制、任务分配、状态管理、编排逻辑等核心能力，使开发者能够构建由多个专业化 Agent 组成的协作系统。

框架的核心组成

Agent 抽象

Agent 是框架的基本执行单元。一个 Agent 通常包含：

• 身份定义：名称、角色描述、职责范围
• 认知能力：接入的 LLM 模型、系统提示词
• 行动能力：可调用的工具集、代码执行权限
• 记忆能力：短期上下文、长期记忆存储

通信机制

Agent 之间需要交换信息，主流框架提供两种通信模式：

• 消息传递：Agent 通过显式消息进行点对点通信，状态隔离，松耦合
• 共享状态：所有 Agent 访问统一的状态对象，数据一致性容易保障，但需要处理并发访问

编排逻辑

决定 Agent 何时执行、如何流转的控制逻辑。常见模式包括：

• 顺序执行：Agent A 完成后触发 Agent B
• 条件分支：根据中间结果决定下一步执行哪个 Agent
• 并行执行：多个无依赖的 Agent 同时执行
• 循环迭代：重复执行直到满足终止条件

状态管理

维护跨 Agent 的上下文和中间结果。关键能力包括：

• 持久化：支持检查点和恢复，应对长时任务
• 版本控制：追踪状态变更历史，支持回溯
• 访问控制：定义哪些 Agent 可以读写哪些状态

多智能体 vs 单智能体的边界

并非所有任务都适合多智能体架构。决策时需要考虑：

维度	适合单智能体	适合多智能体
任务复杂度	单一领域、步骤少	跨领域、步骤多、依赖复杂
执行时间	短于 1 分钟	超过 5 分钟或需要并行
质量要求	一般质量即可	需要多轮校验
领域跨度	单一专业领域	需要多个专业领域协作
可分解性	难以分解为独立子任务	可清晰分解为独立子任务

设计哲学：框架的分类与对比

显式编排 vs 自主编排

多智能体框架最根本的设计分歧在于控制权的分配：由开发者精确定义流转规则，还是由 Agent 自主决定行动。

维度	显式编排	自主编排
核心思想	开发者定义流转规则，框架严格执行	给定目标后，Agent 自主决策下一步
可控性	执行路径透明，便于调试优化	执行逻辑分散，难以追溯
可预测性	相同输入产生确定性路径	相同输入可能产生不同路径
开发成本	需要仔细设计每个流转节点	无需设计详细流程
灵活性	难以应对边界情况	能够应对未预见的场景
资源效率	按需调用，无浪费	可能产生无效探索，Token 消耗高
适用场景	生产环境、企业级应用	实验探索、创造性任务

实际趋势：混合模式

当前主流框架（如 LangGraph、OpenAI Agents SDK）采用混合模式：

• 主体流程显式编排，保证可控性和可预测性
• 关键节点保留自主决策空间，应对边界情况
• 支持人工介入机制，在必要时人工接管

生产环境以显式编排为主，自主编排作为补充；研究和实验场景可尝试更高程度的自主编排。

控制逻辑：中心化 vs 去中心化

控制逻辑决定 Agent 之间的协调方式。

维度	中心化	去中心化
决策方式	管理 Agent 统一协调	Agent 之间直接协商
职责定位	中心节点负责调度，工作节点负责执行	每个 Agent 自主决策
优势	流程清晰、易于调试、适合明确流程	灵活性强、适合开放式协作
劣势	中心节点可能成为瓶颈	协作逻辑复杂、难以追溯
适用场景	软件流水线、数据处理流程	头脑风暴、协商讨论

通信机制：状态共享 vs 消息传递

通信机制决定 Agent 之间如何交换信息。

维度	状态共享	消息传递
数据访问	所有 Agent 访问统一状态对象	Agent 各自维护私有状态
一致性	数据一致性容易保障	需要显式同步
耦合度	紧耦合，Agent 依赖共享状态	松耦合，Agent 可独立部署
调试难度	状态流转清晰可追溯	消息流可能复杂难追溯
适用场景	需要强一致性的工作流	分布式部署、微服务架构

架构选择的组合

控制逻辑和通信机制是正交的两个维度，可以组合出四种典型架构：

组合	特点	示例场景
中心化 + 状态共享	管理 Agent 统一调度，状态集中管理	传统软件流水线
中心化 + 消息传递	管理 Agent 调度，Agent 通过消息交互	微服务编排
去中心化 + 状态共享	无中心节点，但共享状态	协作编辑、白板
去中心化 + 消息传递	完全分布式，Agent 自治	P2P 网络、开放协商

实践中，生产环境多采用"中心化 + 状态共享"或"中心化 + 消息传递"，平衡可控性和灵活性。

工程实践：如何构建自己的多智能体架构？

Agent 划分策略

设计原则

任务分解粒度

• 过细：Agent 切换开销增加，上下文频繁重置
• 过粗：失去多 Agent 优势，回到单智能体问题
• 建议：每个子任务执行时间在 30 秒到 5 分钟之间

Agent 单一职责

• 可描述：能用一句话清晰说明职责
• 可评估：有明确标准判断输出质量
• 可隔离：与其他职责耦合度低

交付物标准化

• 使用结构化格式（JSON、YAML）传递关键信息
• 定义清晰的输入输出 Schema
• 建立统一的错误处理规范

分工边界决策规则

单 Agent vs 多 Agent 的决策框架

考虑因素	保持单 Agent	拆分为多 Agent
任务特性	原子性、强依赖、延迟敏感	多领域、可并行、需校验
收益	避免切换开销	专业化、并行化、容错性
成本	认知负荷、错误累积	上下文切换、协调复杂度

粒度判断标准

• 执行时间：30 秒 - 5 分钟为宜
• 职责清晰度：一句话可描述、可独立评估
• 高内聚低耦合：内部逻辑紧密，外部依赖最小

分工策略模式

按职能分工

需求分析 → 架构设计 → 开发 → 测试 → 文档

按流程阶段分工

数据获取 → 清洗 → 特征工程 → 建模 → 评估

按专业领域分工

         ┌→ 经济学 Agent
用户查询 → 社会学 Agent → 综合 Agent → 报告
         └→ 技术 Agent

按质量层级分工

生成 → 自检 → 同行评审 → 修改

Agent 与工具的设计模式

核心定位

• Agent：决策和协调
• 工具：执行具体动作

专属工具 vs 公用工具

维度	专属工具	公用工具
耦合度	与 Agent 职责深度耦合	通用，与业务无关
权限	需要特殊权限	无特殊要求
范围	单个 Agent 专用	多个 Agent 共享
示例	代码静态分析	文件读写、HTTP 请求

公用工具的管理策略

• 工具注册中心：统一注册、版本管理
• 访问控制：基于 Agent 身份的权限控制
• 并发管理：连接池、配额、超时

工具调用模式

模式	适用场景	特点
同步	执行快（< 5 秒）	阻塞执行
异步	执行慢或不可控	非阻塞，回调
批量	多个相似调用	合并执行

Token 成本优化策略

模型分层策略

任务类型	推荐模型	成本比例
简单分类、提取	轻量级	1x
常规文本生成	中等能力	3-5x
复杂推理、代码	顶级模型	10-20x

上下文压缩技术

• 摘要传递：传递摘要而非完整内容
• 关键信息提取：只保留决策必需信息
• 增量更新：只传递差异部分

运行时监督优化

根据 2025 年研究（SupervisorAgent）：

• 自适应过滤器：识别高风险交互点
• 主动纠错：避免错误传播
• 观察净化：压缩过长返回结果

效果：降低 Token 消耗 29.68%，保持成功率

成本追踪与监控

多智能体框架本身普遍缺乏原生成本追踪能力，需要引入外部工具实现：

可观测性平台

• LangSmith：支持 Token 用量和成本追踪（LangGraph 首选）
• Langfuse：开源 LLM 可观测性平台，支持多框架成本归因
• Helicone：提供 per-request Token 追踪和成本分析
• OpenLIT：CrewAI 官方集成，支持成本监控和性能分析

缓存与复用

• 结果缓存：确定性任务结果缓存
• Agent 复用：连接池管理
• 嵌入向量缓存：RAG 场景长期缓存

并行度控制

• 合理控制并行数量，避免资源争抢
• 按优先级动态调度

框架选型建议

框架对比

对比维度	LangGraph	OpenAI Agents SDK	CrewAI	AutoGen	Mastra	Google ADK
核心能力
状态持久化	完整状态图持久化	会话级状态	内存状态	会话状态	持久化存储	云端状态
可视化调试	LangSmith 企业级	基础日志	基础日志	基础	Mastra Studio	Google Cloud Trace
条件分支	原生支持	有限支持	有限支持	有限支持	.branch() 支持	原生支持
循环迭代	原生支持	不支持	不支持	有限支持	.loop() 支持	LoopAgent 支持
并行执行	原生支持	有限支持	Process 支持	有限支持	.parallel() 支持	ParallelAgent 支持
可观测性	LangSmith 企业级	基础日志	基础日志	基础日志	Mastra Studio	Cloud Trace
Eval/测试支持	需集成第三方	需集成第三方	需集成第三方	需集成第三方	原生支持	需集成第三方
选型相关
编程语言	Python	Python	Python	Python	TypeScript	Python/TypeScript/Go/Java
学习曲线	中等	低	低	中等	中等	中等
生产就绪度	高（400+企业）	高	中	低（维护模式）	中	中
维护活跃度	高	高	中	低（维护模式）	中	中
部署方式	自托管/云服务	自托管	自托管/CrewAI 平台	自托管	Vercel/Cloudflare/Node	GCP 原生

场景化推荐

场景特征	推荐框架	关键考量
企业级复杂工作流（5+ Agent、需要故障恢复）	LangGraph	唯一完整状态持久化和企业级可观测性
快速原型验证（2 周内上线）	OpenAI Agents SDK	API 极简，开发效率最高
业务人员主导、角色驱动场景	CrewAI	角色抽象直观，学习成本低
TypeScript 全栈团队	Mastra	类型安全、原生 Eval 支持、与 Node/React 无缝集成
已深度使用 GCP	Google ADK	云原生集成，一键部署

现存问题与挑战

多智能体框架在实际应用中仍面临以下核心问题：

• 可观测性不足：大多数框架仅提供基础日志，缺乏 Agent 间协作的实时可视化、执行链路追踪、性能瓶颈定位能力。生产环境故障诊断困难。
• 调试成本高昂：多 Agent 系统的错误可能来自编排逻辑、单个 Agent 输出、工具调用、状态传递等多个环节，定位问题需要大量人工分析。
• Token 成本不可控：长链路的 Agent 协作容易产生大量上下文传递，缺乏有效的预算控制和成本预警机制。
• 状态管理复杂：跨 Agent 的状态一致性、故障恢复、幂等性处理需要开发者自行实现，框架支持有限。
• 标准化缺失：Agent 间通信协议、工具接口规范尚未统一，框架间迁移成本高，供应商锁定风险大。
• 测试困难：多 Agent 系统的非确定性输出使得自动化测试覆盖率低，回归测试成本高昂。

因此，多智能体框架需要进一步研究和优化。