单 Agent 与多 Agent
比较一个 Agent 统一处理与多个专业 Agent 分工的收益、成本和控制方式。
学习目标
- 能说明单 Agent 与多 Agent解决什么问题，以及何时适用。
- 能解释为什么“为展示复杂度而多 Agent”是误区。
学习前需要掌握
背景与问题
当一个 Agent 的指令越来越长、工具越来越多时，拆成多个专家看起来很自然。但拆分也会增加上下文传递、等待、成本和结果合并；复杂度增加并不保证效果提升。
先确认问题是单个任务范围过大、专业职责冲突，还是工具描述和状态设计本身有缺陷。后两者通常需要先修清晰接口，再决定是否引入多个 Agent。
概念定义
单 Agent 由一个活动决策主体完成流程；多 Agent 把任务分给多个具有不同指令或工具的 Agent。
直观理解
单人完成沟通少；团队分工专业，但需要负责人、交接标准与共享记录。
核心原理
单 Agent 可以在一个控制流中使用多个工具，适合职责一致、步骤互相依赖或上下文紧密耦合的任务。单 Agent 不代表只有一次模型调用，也不等于不能使用确定性子程序。
多 Agent 为不同职责设置独立指令、工具与上下文。只有当这些边界有意义时，隔离才可能减少干扰；若每个专家都接收全部历史并使用同一组工具，只是增加角色名称，收益并不明确。
独立的分析分支可以并行，依赖链则应顺序执行。并行缩短的通常是等待路径，并不必然降低总计算量；还要考虑限流、失败重试与聚合等待最慢分支的影响。
比较方案应使用相同任务和验收标准，观察端到端质量、延迟、成本与错误定位。多个专家共享相同模型或资料时，错误可能相关，不能把意见一致当作独立验证，也不能用多数投票替代证据。
案例：设计文档的事实检查与风险审阅
一份已冻结的设计文档可以同时交给证据审阅者和风险审阅者：前者检查主张是否有来源，后者检查权限与故障场景，两者输入相同版本但输出契约不同。这种分工比让多个角色重复回答“设计好不好”更明确。
若风险审阅依赖先修正后的接口，就必须等待修改完成，不能与修改过程并行读取同一路径。汇总者应保留不同意见并回到原文核对，而不是自动取两位专家结论的平均值。下方 SDK 代码仅展示并行调用与收集结果的结构，不提供真实设计材料或实际质量评测。
理解与实践步骤
- 评估任务是否可分解
- 定义每个角色的输入输出
- 选择 Manager、Handoff 或并行
- 聚合并验证结果
- 记录跨 Agent 轨迹
代码实现
示例 1
Manager 并行调用两个专业 Agent
example_01.py用途：展示独立子任务并行和 Manager 聚合的边界；代码遵循 Agents SDK 当前 Agent/run 基本结构。
import { Agent, run } from '@openai/agents';
const evidenceAgent = new Agent({
name: 'Evidence reviewer',
instructions: 'Return claims with supporting evidence only.',
});
const riskAgent = new Agent({
name: 'Risk reviewer',
instructions: 'List security and reliability risks.',
});
const task = 'Review this local design summary.';
const [evidence, risks] = await Promise.all([
run(evidenceAgent, task),
run(riskAgent, task),
]);
const managerInput = JSON.stringify({
evidence: evidence.finalOutput,
risks: risks.finalOutput,
});
console.log(managerInput);代码解析
解析始终位于完整代码下方，并按实际代码段逐项对应。
输入数据与任务
展示独立子任务并行和 Manager 聚合的边界；代码遵循 Agents SDK 当前 Agent/run 基本结构。
Step 1 · 1–1 行
导入当前步骤需要的数值计算、预处理、模型或评价工具。依赖集中写在代码开头，便于复现。
import { Agent, run } from '@openai/agents';Step 2 · 3–10 行
每个 run 有自己的 Agent 指令和结果。
const evidenceAgent = new Agent({
name: 'Evidence reviewer',
instructions: 'Return claims with supporting evidence only.',
});
const riskAgent = new Agent({
name: 'Risk reviewer',
instructions: 'List security and reliability risks.',
});Step 3 · 12–16 行
聚合数据先结构化；真实 Manager 还应验证证据、处理失败与限制敏感信息。
const task = 'Review this local design summary.';
const [evidence, risks] = await Promise.all([
run(evidenceAgent, task),
run(riskAgent, task),
]);Step 4 · 18–22 行
执行当前代码段，并把得到的状态传给下一步。
const managerInput = JSON.stringify({
evidence: evidence.finalOutput,
risks: risks.finalOutput,
});
console.log(managerInput);预期输出或运行结果
包含 evidence 与 risks 两个字段的 JSON 字符串；内容取决于所配置模型。
常见错误 · 3 条
- 为展示协作效果而增加角色，没有明确的职责隔离和可验收输出。
- 把具有前后依赖的工作强行并行，或让多个 Agent 同时写同一目标。
- 把多次相似模型回答当成独立证据，忽略共同数据、共同偏差和协调成本。
实际应用
- 研究分工
- 多领域客服
常见错误
- 为展示协作效果而增加角色，没有明确的职责隔离和可验收输出。
- 把具有前后依赖的工作强行并行，或让多个 Agent 同时写同一目标。
- 把多次相似模型回答当成独立证据，忽略共同数据、共同偏差和协调成本。
安全风险与信任边界
多个 Agent 共享相似模型与资料时，意见一致不等于独立证据。拆分还会增加信息传递和错误传播路径，应核对结果来源与写入归属，避免多个角色反复引用同一错误后制造虚假的共识。
性能与失败模式
独立子任务可能并行缩短关键路径，强依赖任务则会被等待、通信和合并拖慢。用同一总预算比较成功率、返工和完整任务耗时，计入每个角色的 token 与工具费用；角色数量不是能力或速度指标。
推荐学习资料
参考库不会生成虚假资源或无效外部链接。