工具契约要能独立看懂
每个工具的用途、入参出参、错误码、调用限制与幂等要求，应整理成一份可脱离代码阅读的文档。契约不清时，后续新增工具或更换供应商都要重新逆向接口，维护成本会随时间快速累积，最终没人敢动这套系统，只能用补丁勉强维持。
权限矩阵是验收重点
把动作、权限档位、审批人、可回滚方式列成一张表，逐行确认。验收时随机抽取若干动作，核对实际配置与矩阵是否一致；不一致的项必须整改，否则权限设计与真实运行就是两套东西，出事时也找不到可依据的说明。
编排配置要可导出
提示词、工具路由、失败重试与终止条件应可导出为配置文件，而不是散落在界面里。配置可导出才能做版本对比与迁移，也能在出问题时快速定位是提示词改动还是工具异常导致，缩短排障时间，减少相互推诿。
红队报告不能省略
红队用例需覆盖越权、注入、诱导承诺与跨权限查询，并记录每条用例的实际表现与修复情况。没有红队报告的验收只能证明正常路径可用，无法说明边界是否守得住，也无法向合规与风控交代，后续审计会非常被动。
审计日志与接管流程
日志要记录谁在何时发起了什么动作、结果如何、是否经过审批；接管流程要写清触发条件、接管人与回访方式。这两项决定事故发生时能否追溯与止损，属于必须交付的内容，不能等到出事之后再补，那时已经来不及。
适用与不适用
适合谁
- 正在编写智能体采购需求与验收条款的企业，需要对外解释口径
- 需要向安全与合规说明权限边界的项目
- 准备把智能体接入生产系统的团队
不适合谁
- 只做内部演示、不接入真实系统的小规模试验
- 不接受任何审计日志留存，也无法配合抽检与演练的场景
典型场景
某银行的智能体项目验收时，验收组从权限矩阵中随机抽取六个动作，逐一在测试环境触发，核对是否需要审批、是否留痕、能否回滚。其中两个动作的实际配置与矩阵不符，被列为整改项。整改完成后，红队用例复测通过，系统才进入灰度，验收纪要与整改记录一并归档以备后续审计。
可执行步骤
- 按六类交付物列清单，逐项标出必交项、可选项与验收责任人，作为验收的第一道关口
- 逐条核对工具契约能否脱离代码独立阅读，并让新同事试读一遍，验证文档是否真的够用
- 随机抽取动作核对权限矩阵与实际配置是否一致，记录差异，作为整改依据
- 检查编排配置能否导出，并做一次版本对比与回滚演练，确认可迁移可回退
常见坑
- 只验收对话效果，不验收权限矩阵，上线后没人说得清哪些动作会自动执行，风险完全不可控；后续改动无人敢碰。
- 编排配置锁在供应商界面里，更换服务商时无法迁移，只能推倒重做，前期投入几乎全部沉没；团队信心同时受损。
- 红队用例由交付方自拟且不公开，验收通过但边界实际守不住，问题往往在首次真实攻击时才暴露出来。
- 审计日志缺失，出问题后无法还原操作序列，责任无法界定，内部追责也失去依据；只能各自承担，责任也难以追溯。
自检与验收清单
- 工具契约是否可独立阅读并能指导接入，新同事能否读懂
- 权限矩阵是否与实际配置逐行一致，差异是否已整改
- 编排配置是否可导出并支持版本对比，回滚是否验证过
- 审计日志与接管流程是否可用并演练过，接管人是否明确
常见问题
红队测试要谁来做？
建议由未参与开发的第三方或客户方安全团队执行，用例与结果双方留档。交付方自测可以作为预检，但不能替代独立测试，否则容易只覆盖自己熟悉的路径，恰好漏掉最危险的那几条，而这几条往往就是事故入口。
权限矩阵要细到什么程度？
细到每个可改变系统状态的动作一行，写明档位、审批人与回滚方式。查询类动作可以合并描述，但涉及写入、删除、发送、支付的动作必须逐条列出，并在验收时逐条核对配置是否一致，不能只看文档。
验收要跑多久？
通常一到两周，含配置核对、抽检触发、红队复测与接管演练。时间不宜压缩到几天，因为权限与日志类问题往往要在真实操作序列中才会暴露，仓促验收等于把风险整体推迟到上线之后。