别凭感觉：给Claude多Agent做一套"可量化"的稳定性评测
我最近跑Claude多Agent系统比较多，踩了一个反复出现的坑：每次觉得"这套配置挺好用"，换个任务就拉胯。问别人的经验，得到的回答清一色是"我感觉还行"、"跑了几次都成功了"。
感觉不是指标。跑了几次不是统计。
01 现状：大家怎么评价多Agent系统
坦白说，目前绝大多数人评估多Agent系统的方式是试用几次，看看结果满不满意。满意就说"好用"，不满意就换个prompt再试。
这个方法有一个致命问题：LLM的输出本身是非确定性的。同样的任务同样的输入，跑十次可能八次成功两次失败。你恰好试的那两三次如果都在成功的那八次里，就会产生"稳定好用"的错觉。
推理能力、规划能力、执行能力，这些是大家评估Agent时最关注的。但有一个能力被严重忽视了：记忆和信息检索。一个Agent能不能在长对话中准确找回之前的信息？能不能在新旧信息矛盾时做出正确判断？这些问题很少有人系统测过。
02 MemoryAgentBench：一个学术界的尝试
arxiv上有一篇论文叫MemoryAgentBench，提出了评估Agent四个核心能力的框架：
准确检索——给Agent存入100条信息，之后问它其中某条具体内容，看能不能精确找到。测试时学习——Agent在会话过程中获得新知识后，能不能立刻用上。长程理解——跨越很长的上下文窗口，Agent还能不能把前后信息串起来。冲突消解——旧信息说A，新信息说B，Agent选哪个。
结论让人不太乐观。论文测了从简单RAG到带外部记忆的高级Agent，没有任何一个实现在四项上全部达标。尤其是冲突消解，几乎所有实现的得分都很低。Agent更倾向于相信先看到的信息，即使后来的信息明确否定了前者。
这个结论跟我的实际体验吻合。我在用多Agent处理代码重构任务时，Lead Agent把旧版本的文件结构告诉了Sub Agent，后来项目结构改了，Sub Agent拿到新的目录信息后仍然按旧结构去操作，导致整个任务失败。
03 Anthropic自己的评估工具
Anthropic提供了官方的评估工具和指南。他们的eval tool支持定义测试用例、设置评分标准、批量运行并收集结果。
工具本身设计得不错，但它主要面向单次对话质量的评估——给一个输入，看输出是否符合预期。对于多Agent协作场景，官方工具覆盖不到的地方很多：Agent之间的信息传递是否准确、任务分发是否合理、失败后的恢复路径是否有效。
这些都得自己补。
04 我建议的多Agent评测维度
跑了两个月多Agent之后，我觉得至少要测四个维度。
任务完成率。同一个任务跑10次，成功几次。这是最基本的。我实测一个中等复杂度的代码生成任务，单Agent成功率大概7/10，三Agent协作的成功率反而只有5/10。多Agent并不自动意味着更好。
一致性。同样的输入多次运行，输出是否稳定。不要求完全一致，但核心逻辑不应该变。我遇到过一个case：同样的数据处理任务跑五次，三次用了pandas，一次用了纯Python循环，一次直接调了shell脚本。五种做法都能得到正确结果，但对下游流程来说这种不一致是灾难。
协调效率。多Agent跑完一个任务用了多少时间、消耗了多少token，跟单Agent比差多少。如果三个Agent协作花的时间是单Agent的两倍，token是三倍，那这个"协作"不划算。
错误恢复。故意注入一些错误条件：给Agent一个不存在的文件路径、一个格式错误的输入、一个中途超时的API调用。看Agent能不能检测到错误、自动修复、继续完成任务。
05 怎么做一个最简单的评测
不需要搭建复杂的测试框架。选5到10个代表性任务，每个跑5次，用一个表格记录下来就够了。
| 任务 | 运行次数 | 成功次数 | 平均耗时 | 平均token | 错误类型 | |------|---------|---------|---------|----------|---------| | 代码生成-REST API | 5 | 4 | 3m12s | 28k | 1次路径错误 | | 文件重构-移动模块 | 5 | 3 | 5m45s | 41k | 2次遗漏导入 | | Bug修复-类型错误 | 5 | 5 | 2m03s | 15k | 无 | | 多文件编辑-添加日志 | 5 | 2 | 7m30s | 52k | 3次Agent间信息丢失 |
这张表能告诉你的东西比"感觉还行"多太多了。哪类任务多Agent协作不稳定，一目了然。
跑完之后你可能会发现，有些任务根本不适合多Agent。比如上面那个"Bug修复-类型错误"，单Agent就能稳定搞定，没必要上多Agent增加协调成本。
06 评测的陷阱
最大的陷阱是只测Happy Path。任务描述写得清清楚楚、输入格式完全正确、API全部正常响应——这种理想条件下的测试意义有限。
要测边界情况。输入里有中文和英文混合怎么样？文件路径带空格呢？网络中途断一下呢？一个Agent返回了格式不对的结果，下游Agent能不能处理？
要测错误恢复。前面提到的错误恢复维度不是可选的。生产环境里出错是常态，不是例外。一个多Agent系统如果只能在一切顺利的前提下工作，那它就不能上生产。
还有一个容易忽略的：测试环境和生产环境的差异。我见过在本地跑得很好的多Agent配置，部署到服务器上因为网络延迟增加，Agent之间的信息传递开始出现时序问题。Sub Agent还没收到上一步的结果，就开始执行下一步了。
07 写在最后
量化评测不是为了追求完美的数字。它的价值在于让你知道系统的边界在哪里。哪些任务能放心交给多Agent，哪些任务还是老老实实用单Agent跑，哪些地方需要加人工兜底。
有了数据，就不用凭感觉做决定了。
参考链接：
- MemoryAgentBench论文：https://arxiv.org/html/2507.05257v1
- Anthropic测试和评估指南：https://docs.anthropic.com/en/docs/build-with-claude/develop-tests
- Claude评估工具：https://docs.claude.com/en/docs/test-and-evaluate/eval-tool
- Anthropic多Agent系统构建指南：https://claude.com/blog/building-multi-agent-systems-when-and-how-to-use-them