企业多智能体系统的验收，不能以“演示效果不错”或“最终答案像人工”为标准。验收对象不是某个模型，而是一条由任务拆解、资料检索、工具调用、结果审核和人工接管组成的完整业务链路。只有当这条链路可验证、可审计、可控制，系统才具备进入生产环境的条件。
先定义业务任务，再定义验收指标
验收应从真实业务任务出发，而不是从模型名称或单轮问答能力出发。例如，客服流程可能包含意图识别、订单查询、政策匹配和回复生成；合同初审则可能涉及文档解析、条款检索、风险识别、规则比对和人工复核。每个任务都应明确输入条件、允许调用的工具、预期输出、失败处理方式和必须由人工确认的环节。
指标至少要覆盖四类：
- 业务结果：输出是否符合业务规则，是否遗漏关键事项。
- 流程可靠性：任务分解、智能体协作、重试、超时和退出是否按预设规则执行。
- 安全与权限：是否遵循最小权限，能否阻止无关数据访问，并对写入、删除、付款、发布等高风险动作进行人工确认。
- 可观测性：是否保留请求追踪编号、各智能体输入输出、工具参数与返回结果、失败原因、模型版本和提示词版本记录。
把异常场景纳入验收
只测试成功路径，会掩盖多智能体最危险的问题。验收必须主动设置错误意图、检索不到资料、工具返回异常、重复调用、上下文不完整和权限不足等场景，观察系统是安全终止、请求人工接管，还是继续生成貌似合理的结果。
尤其要检查错误是否会在智能体之间扩散。若前序任务拆解错误，后续智能体即使执行准确，也可能输出错误结论。因此，任务层级、调用次数、超时机制和循环行为都应有明确限制，不能完全依赖模型自主判断。
设定“一票否决”条件
涉及财务、法务、人事、生产控制或敏感数据的流程，不能只看准确率。未提供完整审计日志、无法配置独立身份、不能撤销错误操作、数据使用和删除机制不明确，或供应商无法说明责任与退出机制时，都应暂停上线。
同时，企业应按完整任务测算成本，纳入多个智能体的重复调用、长上下文、工具调用、失败重试、人工审核和日志存储，而非只比较单次模型调用价格。验收标准的核心，不是证明系统“会做事”，而是证明它知道何时执行、何时停止、谁能追责，以及出错后能否恢复。