KEEL · 龙骨 · A CURRICULUM FOR THE AI ERA

01. 第二个 Agent 真的有必要吗？ — keel 龙骨

支付服务出现超时。你已经有一个 Agent，它能读取事件描述、指标快照和部署记录，并给出分析。现在有人提出：“再加三个 Agent，让它们分别扮演 SRE、开发和审查员，效果一定更好。”

支付服务出现超时。你已经有一个 Agent，它能读取事件描述、指标快照和部署记录，并给出分析。现在有人提出：“再加三个 Agent，让它们分别扮演 SRE、开发和审查员，效果一定更好。”

先不要写代码。多 Agent 首先是一项架构判断，而不是模型数量升级。

一个 Agent 和多个 Agent 的真正差别

下面三种写法看起来都有多个“角色”，但只有最后一种形成了独立协作单元。

一个 prompt 里的多个视角

请先以 SRE 视角分析，再以开发视角分析，最后自我审查。

这仍是一次模型调用：相同上下文、相同工具权限、相同失败边界。它可以产生多视角文本，却没有独立任务和运行状态。

一个 Agent 连续调用多个工具

Agent -> 查询指标 -> 查询部署 -> 生成结论

这仍是单 Agent。能力变多了，但目标、上下文和控制循环仍由同一个执行者管理。

多个可独立寻址的执行者

Coordinator
  -> Task M -> Metrics Agent -> Result M
  -> Task D -> Change Agent  -> Result D
  -> Gather -> Final Report

每个 Worker 接收独立任务，可以拥有不同上下文、工具、模型、超时和失败状态。Coordinator 通过协议收集结果。这才是本课讨论的多 Agent 协作。

Role、Agent 和 Agent instance 不要混淆

把 Role 当成 Agent，会遗漏最重要的问题：谁创建实例、谁发送任务、实例能读取什么、失败由谁处理。

第二个 Agent 可能带来的四种真实收益

上下文隔离

指标分析员只需要指标和告警；变更分析员只需要部署记录。让两者各自处理较小上下文，可能比把所有资料塞进一个 prompt 更稳定。

专业能力隔离

不同 Agent 可以拥有不同工具和规则。例如指标分析员只能读取监控数据，变更分析员只能查询发布记录。工具边界比“你是一位专家”更可靠。

并行处理

两个独立调查可以同时开始，降低端到端延迟。只有任务之间不存在未满足的依赖时，并行才成立。

独立验证

Reviewer 可以只看到候选结论、证据和验收标准，检查“每个结论是否有证据”，而不是继续沿用生成者的完整推理历史。

不适合多 Agent 的情况

• 单次模型调用已经稳定达到目标；
• 任务不能清楚拆分，所有步骤都依赖同一份不断变化的上下文；
• 多个 Agent 使用完全相同的模型、prompt、工具和输入，只是名字不同；
• 无法定义每个子任务的完成条件；
• 延迟、token 或基础设施预算不允许额外模型调用；
• 没有单 Agent 基线，无法证明增加复杂度带来收益。

一个直接的采用标准是：

协作收益 > 额外成本 + 额外延迟 + 新增失败风险

这里的每一项都需要通过实验测量，不能凭演示中的一次流畅回答判断。

先建立单 Agent 基线

为 20 个事件准备固定输入和人工验收标准，记录单 Agent 的：

• 结论正确率；
• 证据引用完整率；
• 平均和 P95 延迟；
• 模型调用次数与 token；
• 工具调用错误率；
• 需要人工纠正的比例。

多 Agent 版本必须使用同一批任务比较。若质量没有显著提升，或者只提高少量质量却成倍增加延迟，应保留简单方案。

本章实验

拿同一份事件资料，分别设计：

1. 一个 Agent 完成全部分析；
2. 两个 Agent 接收完全相同的资料和 prompt；
3. 两个 Agent 接收不同任务、不同上下文和明确输出标准。

在运行前预测哪种方案会真正降低单次调用的认知负担。第三种方案是否更好，仍要由后面的基线评估证明。

检查理解

• 两个不同 system prompt 是否必然构成两个 Agent？
• 一个 Agent 调用十个工具为什么仍可能是单 Agent？
• 上下文隔离和角色名称有什么区别？
• 在没有单 Agent 基线时，为什么不能声称协作有效？

下一步先不增加模型。先定义一个任务怎样被分派、接收、完成和拒绝。

下一章：协作为什么要从任务契约开始？

进入 keel 阅读