企业官网建设流程全解析

「漫说测试」风向观察 · 第 5 期

第 1 期讲了单个 Agent 怎么评测，第 4 期讲了它调的"工具"（MCP）怎么测。 这一期，架构又往上走了一层：AI 从"一个人干活"，变成了"一队人协作"——多个 Agent 分工、交接、互相调用。 而海外测试圈最近在反复强调一个反直觉的事实：你把每个 Agent 单独测到满分，整个系统照样会崩。

【贴图1】

一、先看一件事：单测全绿，系统照崩

先理清一条逻辑链。

前面几期我们聊的，都是**“单 Agent 视角”**：一个 Agent 能不能理解任务、会不会调对工具、抗不抗得住攻击。这些当然要测。

但现在越来越多的系统是多 Agent 架构：一个"调度 Agent"拆任务，一个"检索 Agent"找资料，一个"写作 Agent"出内容，一个"审核 Agent"把关——它们通过"交接（handoff）"串成一条链^1。

于是问题来了：我们习惯的"逐个测 Agent"的方法，在这里失效了。

因为你测的是"每个零件合格"，可系统崩不崩，取决于"零件之间怎么配合"。这就像四个人各自技术顶尖，凑成一个球队却踢得一塌糊涂——问题不在个人，在协作。

这就是本期要讲的核心：多 Agent 系统的 bug，主要不在 Agent 内部，而在 Agent 之间。

二、风向一：bug 藏在"协作层"，而且会级联放大

海外的数据很直接。有分析指出：多 Agent 系统在生产环境中的失败率高达 41%–86.7%，并从中归纳出14 类典型的失败模式^2。

这些失败模式，几乎没有一个是"单个 Agent 自己坏了"，而是集中在协作层^3：

• 交接失败（handoff failure）

  ：A 把任务交给 B，意图丢了、上下文丢了、格式对不上——链条在接口处断掉^4；

• 协调死锁（deadlock）

  ：两个 Agent 互相等对方，或者绕圈重复劳动，任务永远推进不下去^3；

• 涌现行为（emergent behavior）

  ：单个 Agent 都"正常"，但凑在一起产生了谁都没设计过的行为——可能是低效，也可能是危险^3。

更狠的是级联失败（cascading failure）：一个 Agent 产生了一个错误（哪怕是幻觉），这个错误变成了下游 Agent 的"输入"——下游信了，再往下传，错误被一层层放大，最后变成一个系统级事故^5。

一句话：单个 Agent 幻觉，是个"小毛病"；一个幻觉喂给五个下游 Agent，就是一场"雪崩"。而这，恰好是"逐个测 Agent"的方法永远发现不了的东西。

三、风向二：方法上，要测"三层"，而不是"一层"

那多 Agent 系统该怎么测？海外给出的一致答案是：分层测，而且必须覆盖"协作"这一层^1。

第一层：单个 Agent。每个 Agent 自己的行为、工具调用、输出质量——对应我们前几期讲的那套（评测、红队、MCP 测试）。

第二层：每一次交接（handoff）。这是多 Agent 特有的、也是最重要的一层：A 交给 B 的时候，意图、上下文、格式、约束，有没有完整、准确地传过去？交接处失真，后面全废^4。

第三层：整体编排 + 压力。把整条链跑起来，加并发、加异常、加超时——看它会不会死锁、会不会级联崩、会不会涌现出没设计过的行为^1。

关键洞察：大部分团队只测了第一层，就以为"系统测过了"。而多 Agent 真正的风险，全压在第二、三层——这正是测试人最该补上的地方。

四、风向三：失败往往起于"规格不清"，而不是"技术不强"

还有一个被海外反复强调的点：多 Agent 系统失败，多半不是"基础设施不行"，而是"规格模糊 + 协调断层"^6。

翻译一下：不是因为模型不够聪明，而是因为"没人把’每个 Agent 该干什么、交接什么、边界在哪’说清楚"。

这就有意思了——因为它把问题从"AI 难题"拉回到了"测试难题"：定义清晰的标准、明确每个环节的输入输出、把隐含假设显式化——这不正是测试人天天在做的事吗？（第 2 期讲 Vibe Coding 时，我们说过要"先定意图和契约"，这里是同一个道理。）

所以海外给出的对策，也很"测试味"：确定性的任务分配、清晰的层级目标拆解、以及贯穿全程的可观测性^7。

尤其是可观测性（observability）——因为多 Agent 的失败是"跨 Agent 的时间线"，你必须能看到每一次交接、每一个决策、每一段上下文，才定位得到问题^8。这就像我们做分布式系统的链路追踪：看不见链路，就查不出故障。

五、一个结论：单 Agent 评测会"漏"，因为协作问题不在单个 Agent 身上

把上面的逻辑收成一句：

用"逐个测 Agent"的方法，去测一个"多 Agent 系统"，天然会漏掉最大的一类风险——协作层的失败。^2

这不是"测得更努力"就能解决的，而是测试的"对象"和"层级"变了：你的被测单元，从"一个 Agent"，变成了"Agent 与 Agent 之间的那条链路"。

对测试人来说，这其实是个熟悉又陌生的局面：

• 熟悉

  的是——交接、契约、链路、级联、链路追踪，这些在微服务/分布式测试里我们早就玩过；

• 陌生

  的是——这次的"服务"，是会自己"理解、决策、幻觉"的 AI。

结论很清楚：多 Agent 测试，是"分布式系统测试"的功底，加上"AI 不确定性"的新变量。会做分布式测试的人，天然有一半优势。

六、给国内测试人的 3 条落点

【贴图9】

**1. 把"交接"当被测点，单独写用例。**别再只测单个 Agent。针对每一次 handoff，专门设计用例：意图有没有丢？上下文全不全？格式对不对？边界说清没有？交接处，就是最容易断的地方^4。

2. 主动构造"级联"用例，别等它自己崩。**故意注入一个错误（一个幻觉、一个超时、一个脏数据），看它会不会沿链路放大**——这叫"混沌测试"的思路，用在多 Agent 上照样成立^5。

**3. 先把"可观测性"搭起来，再谈定位。**多 Agent 的问题横跨时间线，没有 trace（谁在什么时候把什么交给了谁），你连复现都做不到。把链路追踪和决策日志建起来，才能从"系统崩了"走到"交接在这断了"^8。

一句话：单 Agent 时代，你测的是"人"；多 Agent 时代，你测的是"配合"。而"测配合"，本来就是测试人的主场。

【贴图10】

🎁 彩蛋我把这一整套「多 Agent 系统测试」资料整理成了资源包：三层测试法落地指南 + 14 类协作失败模式清单 + 级联失败检测方法 + 可观测性/trace 实践（全部附直达链接）。

参考来源（海外）

• [^1] ContextQA《How to Test Multi-Agent Systems: A Practical Guide》https://contextqa.com/blog/how-to-test-multi-agent-systems/

• [^2] Prefactor《Multi-agent coordination failures: why per-agent evals miss the real risks》https://prefactor.tech/blog/multi-agent-coordination-creates-new-reliability-and-evaluation-requir

• [^3] Galileo《Why Multi-Agent AI Systems Fail and How to Fix Them》https://galileo.ai/blog/multi-agent-ai-failures-prevention

• [^4] QAwerk《Testing Multi-Agent AI Systems: Catch Handoff Failures Early》https://qawerk.com/blog/testing-multi-agent-ai-systems/

• [^5] Adversa《Cascading failures in agentic AI: the OWASP ASI08 guide》https://adversa.ai/blog/cascading-failures-in-agentic-ai-complete-owasp-asi08-security-guide-2026/

• [^6] Augment Code《Why Multi-Agent LLM Systems Fail and How to Fix Them》https://www.augmentcode.com/guides/why-multi-agent-llm-systems-fail-and-how-to-fix-them

• [^7] Splunk《Multi-Agent Coordination: 10 Strategies to Prevent System Failures》https://www.splunk.com/en_us/blog/artificial-intelligence/multi-agent-coordination-strategies.html

• [^8] Zyrix《Multi-Agent AI Testing Guide 2026》https://zyrix.ai/blogs/multi-agent-ai-testing-guide-2026/