多智能体怎么互相调用：QA 场景里不要群聊，要工单、契约和仲裁

很多多智能体方案看起来很热闹：一个负责需求，一个负责接口，一个负责 UI，一个负责日志，一个负责总结。

但如果没有调用规则，它很快会变成一堆模型互相转述。

高级 QA 真正关心的不是“有几个智能体”，而是：

• 谁能发起任务
• 谁能调用工具
• 谁能改测试资产
• 谁只能读证据
• 谁负责最终复核

先说一个真实场景

假设一个订单确认页改版，涉及：

• 优惠试算接口
• 订单确认页 UI
• 支付入口
• 埋点字段
• 服务端优惠计算日志

QA 要做的不是“让一个智能体测一下”。

更合理的拆法是：

• 变更分诊者：读需求和 PR，拆影响面
• 接口执行者：生成请求草稿和断言建议
• UI 执行者：生成冒烟步骤和失败截图说明
• 日志证据员：按 traceId 整理服务端时间线
• 复核者：检查输出是否缺证据、是否越权、是否遗漏高风险场景

注意，这里每个角色都不是“全能测试专家”。

它们只负责一个窄动作。

第一条规则：任务必须像工单一样流转

不要让智能体之间自由聊天。

每次调用都应该像内部工单：

任务编号： 发起方： 接收方： 输入材料： 期望输出： 允许工具： 截止条件： 人工确认项：

这套格式看起来很笨，但非常适合 QA。

因为测试最怕的是输出不可复现。

如果接口建议从哪里来的、日志查了哪个时间窗口、UI 失败截图是哪一步生成的都说不清，后面就无法追责和复核。

第二条规则：调用必须分层

我建议最多分 4 层。

第一层：入口分诊。

只做三件事：

• 判断任务类型
• 拆影响面
• 决定调用哪些执行者

它不能直接写测试库，也不能直接下通过结论。

第二层：专业执行。

接口、UI、日志、历史缺陷，各自只做自己的事。

接口执行者不能判断页面体验。

UI 执行者不能判断数据库副作用。

日志证据员不能直接说“可以上线”。

第三层：证据复核。

复核者只看结构化输出：

结论： 证据： 调用工具： 不确定项： 需要人工确认：

它的任务是找漏洞，不是美化总结。

第四层：人工审批。

所有高风险结论必须回到 QA。

特别是支付、发券、权限、通知、数据删除、灰度配置这类动作，不能让智能体自动拍板。

第三条规则：不同测试类型用不同调用方式

功能测试更适合“分诊 -> 用例建议 -> 人工复核”。

它的输入通常是需求、PR、历史缺陷。

它的风险是需求理解错了，所以必须保留不确定项。

接口测试更适合“接口文档 -> 请求草稿 -> 断言建议 -> 数据准备确认”。

它的输入通常是 OpenAPI、请求样例、错误码、鉴权说明。

它的风险是测试数据和环境状态不可靠，所以不能让模型自动造高风险数据。

UI 测试更适合“页面路径 -> 操作步骤 -> 失败归因”。

它的输入通常是页面截图、DOM、accessibility snapshot、自动化错误。

它的风险是把真实缺陷误判成 selector 更新。

APP/小程序测试更适合“发版说明 -> 端侧冒烟清单 -> 真机确认项”。

它的输入通常是版本说明、页面路径、权限、系统版本、弱网条件。

它的风险是端侧环境太复杂，不能只靠文本判断。

服务端测试更适合“接口失败 -> trace/log 摘要 -> 可能原因”。

它的输入通常是 requestId、traceId、服务名、日志窗口、消息队列状态。

它的风险是把相关日志误当成根因。

第四条规则：工具调用要有白名单

多智能体最容易失控的地方，是工具权限。

我会把工具分成三类。

只读工具：

• 读需求
• 读 PR
• 读接口文档
• 读日志
• 读历史缺陷

低风险执行工具：

• 生成请求草稿
• 生成测试点
• 生成 UI 步骤
• 生成日志摘要
• 生成回归建议

高风险工具：

• 写测试库
• 改配置
• 清数据
• 触发支付
• 发通知
• 修改灰度

前两类可以自动调用。

第三类必须人工确认。

这不是保守，而是测试工作的基本责任边界。

第五条规则：必须设置终止条件

多智能体如果没有终止条件，很容易循环。

比如接口执行者说“需要日志”，日志证据员说“需要更多请求信息”，入口分诊者又把任务丢回接口执行者。

这类循环必须提前限制。

我建议设置 5 个终止条件：

• 最大调用轮次
• 最大工具调用次数
• 最大等待时间
• 连续两次缺少新证据就停止
• 出现高风险动作就转人工

输出也要明确：

已完成： 未完成： 停止原因： 缺失证据： 建议人工动作：

这样 QA 才知道它是“完成了”，还是“因为缺证据停了”。

第六条规则：复核者不能改结果

很多人会让一个总结智能体把前面所有输出整理得更好看。

这在 QA 场景里有风险。

复核者不应该美化结论，而应该做反向检查：

• 是否有证据缺口
• 是否存在越权工具调用
• 是否把推测写成事实
• 是否漏掉历史缺陷
• 是否缺少人工确认
• 是否存在互相矛盾的结论

它的输出最好长这样：

可采纳项： 不可采纳项： 证据不足项： 需要人工确认： 建议补充调用：

如果复核者直接重写结论，原始证据链就会被稀释。

10-30 分钟最小验证

选一个小需求就够了。

比如登录页新增一个入口，后端新增一个配置接口，前端多一个跳转。

不要接 CI，不要接测试平台，不要写复杂编排。

先用 4 个文本文件模拟：

• change.md：需求和 PR 摘要
• api.md：接口说明
• ui.md：页面路径
• bugs.md：历史缺陷

然后让入口分诊者输出任务工单。

再分别让接口执行者、UI 执行者、历史缺陷执行者处理。

最后让复核者只读这些输出。

判断标准不是“它是否全自动完成测试”，而是：

• 是否减少了 QA 第一轮拆解动作
• 是否能留下可复核证据
• 是否能明确说出缺什么
• 是否没有越权执行高风险动作

我建议的最小输出模板

每个角色都用同一套模板。

角色： 输入： 处理动作： 输出结论： 证据： 不确定项： 调用工具： 禁止动作： 需要人工确认：

模板统一后，多智能体才容易管理。

否则每个角色都输出一段长文，QA 反而要花更多时间读总结。

总结

多智能体不是让多个模型一起讨论测试。

在 QA 场景里，它更像一个受控的任务流转系统：

• 入口负责分诊
• 专业角色负责窄动作
• 工具调用必须白名单
• 证据必须结构化
• 复核者只做审查
• 高风险动作回到人

如果做不到这些，多智能体不是提效，而是在制造新的不可控流程。

参考资料

• MCP Tools 规范：https://modelcontextprotocol.io/specification/2025-11-25/server/tools
• Playwright Codegen：https://playwright.dev/docs/codegen