2025-09-11 Anthropic 做 Multi Agent 系统的工程经验（下）

发布于 2025年09月11日  •  1 分钟  • 116 字

这一篇写Anthropic的智能体评估、生产可靠性和工程挑战。

智能体评估

如何做智能体评估呢？传统的做法是“给定输入 X，必须走步骤 Y，才能得到正确输出 Z”。但是多智能体不能这样做，因为它没有固定唯一的、可预先写死的解题路径。

评估什么

不要去检查是否走了预设的路径，而要判断是否有合理的过程和正确的结果。

• 结果导向：最终答案是否正确、是否满足用户需求。
• 过程合理性：虽然允许路径变化，但要确保路径在逻辑、效率、成本、可靠性上“说得通”。

从小样本集上就开始做评估

不要等数据量大时才开始做评估，在小样本的时候就开始做评估

LLM AS JUDGE

• 研究输出的评估难题：研究输出通常是自由形式的文本，很难通过程序化的方法进行评估，因为它们很少有唯一正确的答案。
• LLM作为评判工具的适用性：LLM 由于其强大的语言理解和生成能力，非常适合用于评估这种复杂的研究输出。

打分规则

Anthropic 制定了一些打分规则：

• 事实准确性（说法是否与来源一致？）
• 引用准确性（引用来源是否真的支撑该说法？）
• 完整性（是否涵盖了所有要求的内容？）
• 来源质量（是否优先使用了高质量的一手资料，而不是低质量的二手资料？）
• 工具效率（是否用了恰当的工具、调用次数是否合理？） 评分方式：LLM评判工具会根据上述标准对每个输出进行评分，评分范围为0.0到1.0，并给出通过或不通过的等级。

实验与优化

• 多评委实验：最初尝试使用多个LLM评判工具来评估每个标准，但发现这种方法不够一致，与人类评判结果的对齐度也不够高。
• 单评委优化：最终发现，使用单个LLM评判工具，通过一个单一的提示（prompt）来输出评分和通过/不通过的等级，是最一致且与人类评判结果最接近的方法。

人工评估的重要性

1. 自动化评估的局限性： 自动化评估工具（如LLM评判工具）虽然高效，但可能会遗漏一些边缘情况（edge cases）。这些情况包括：
2. 人工评估的优势：
3. 多智能体系统的复杂性

生产可靠性和工程挑战

在传统软件里，一个小 bug 可能仅仅让功能崩溃、性能下降或触发一次故障。

而在agentic 系统里，微小的改动会像滚雪球一样放大，引发巨大的行为漂移——这使得为那些需要在长时间运行中保持状态的复杂智能体编写可靠代码变得异常困难。

1. 增加故障点原地恢复的功能

智能体可能长时间运行，在多次工具调用之间持续保持状态。这意味者必须保证代码的持久执行，并在每一步都能妥善处理错误。

出错时，不能简单地“重启”：重启太昂贵了。所以Anthropic 构建了一套可从故障点原地恢复的系统，并加上了重试逻辑和定期快照来保证断点恢复的功能。

2. 开发全链路追踪

在传统软件里，同样的输入基本会得到同样的输出，可 AI 智能体是“动态、非确定性”的——同一套提示词跑两次，内部决策路径都可能不同，于是调试难度成倍上升。 举个例子：用户投诉“智能体连显而易见的资料都找不到”。光凭日志根本看不出问题出在哪——是它生成了糟糕的搜索关键词？还是选到了垃圾网页？还是工具本身调用失败？

Anthropic 引入了一套“全链路追踪（full production tracing）”，记录每一次调用、每一个决策节点（关键词→结果→评分→下一步动作），但不记录对话正文，保证用户隐私。

好处：

• 能一眼看出“哦，原来失败都是因为它把 PDF 当网页解析导致失败”之类的根本原因；
• 能发现“两个子智能体反复互相踢皮球”这种事先没想到的异常协作；
• 把常见失败归纳成模式后，就可以系统性地修 bug、改提示、补工具，而不是靠猜。

3. 部署的时候要考虑用户正在使用

考虑到无论什么时候发布更新都有可能有用户在使用智能体，Anthropic 采用“彩虹部署（rainbow deployments）”：旧版本和新版本同时在线，逐步将流量从旧实例切到新实例，从而避免打断正在运行的智能体。

4. 同步执行与异步执行

同步执行优点

• 流程简洁：主智能体按固定顺序等待全部子智能体返回即可，调度与调试成本较低。
• 状态一致：所有子任务一次性完成，输出天然对齐，无需额外的合并步骤。

同步执行挑战

• 吞吐受限：任一子智能体延迟即拖慢全局，系统整体并行度受限。
• 缺乏弹性：主智能体无法在运行过程中动态修正子智能体的目标；子智能体之间亦无法实时共享信息或协同。
• 资源闲置：当大部分子智能体已结束而少数仍在执行时，算力与带宽均被阻塞，利用率下降。

异步执行优点

• 并行度显著提升，各子智能体可独立推进并按需衍生新任务；
• 主智能体可实时接收中间结果，及时重定向或终止子任务，实现精细化控制；
• 子智能体之间可通过消息机制即时协作，提高整体效率。

异步执行挑战

• 结果汇总：需额外机制对无序到达的结果进行排序、去重与聚合；
• 状态一致：分布式快照或事务协议保障全局视图同步，增加系统复杂度；

5. 上下文管理

当 AI 代理需要与用户进行几百轮对话时，如何让它“记住”前面发生的事，又不会因为上下文窗口塞不下而失效呢？

1. 解决思路：
2. 具体做法：

总结

把 AI 原型变成真正可依赖的生产系统，比大多数人想象的要难得多。

1. 在 AI Agent项目上，跑通demo 只占 40% 的工作量，剩下 80% 都要花在“最后一公里”——让它在生产环境中长期、可靠、可扩展地运行。
2. 在开发者电脑上能跑 ≠ 能在生产环境跑。要把demo变成 7×24 可用的服务，需要额外的工程：持久化、重试、并发、监控、灰度发布、回滚、成本控制……这些在传统软件里已经很复杂，在“会思考”的 AI 代理里更加复杂。
3. 传统软件里，一个小 bug 通常只影响一个功能；AI 代理里，一个小错误会被“推理链”放大，导致后续所有步骤跑偏。例如搜索返回一条错误信息，代理可能据此做出完全错误的商业决策。
4. 很多团队低估了这个差距，导致项目延期或失败。因此要提前规划工程投入，而不是“先做出来再说”。