《Agent 原理，架构与实践》系列第 11 讲给出一套可直接落地的验收清单，核心思路是把前面十讲的架构标准收拢为六大模块，不再只看回答好不好看，而是对照设计文档、运行轨迹、指标数据双向核验，用来验收生产环境真实 Agent；整套清单同时是设计自检表、上线验收表，并且配套固定验收流程、问题优先级排序、持续复评机制，解决 Agent “看起来能跑，但上线之后幻觉泛滥、越权、循环调用、成本失控” 这类验收盲区。这套验收体系不依赖单一打分，核心原则是拿证据判定：设计预期和真实运行轨迹是否对齐；一旦出现偏差，按安全、正确性、成本、体验的顺序排修复优先级，并且验收不是一次性动作，版本迭代、模型升级、业务扩张之后都要反复复检。
一、六大模块验收清单总表
| 验收模块 | 对应系列章节 | 核心检查项 | 验收判定标准 |
|---|---|---|---|
| 机制共识 | 第 1、2 讲 | 团队对 Token、上下文窗口、模型原生无记忆、幻觉底层机制是否达成共识；幻觉管控是靠流程约束，还是仅靠提示词；是否错误指望模型天然记住事实、天然诚实 | 红线：不能把可靠性寄托在模型自觉；必须有独立流程拦截幻觉 |
| 上下文工程 | 第 3、4 讲 | 上下文分层常驻 / 按需加载；长期记忆结构、摘要压缩策略；是否无脑把全部知识塞进系统提示词、把上下文窗口当成存储仓库 | 门禁：有可控的记忆召回、摘要压缩机制，避免窗口溢出与信息污染 |
| Agent 核心循环 | 第 5、6 讲 | 双循环四步骤闭环完整；工具按业务流编排；最小权限边界；工具不是简单逐个 API 包装，有失败熔断 | 门禁：工具调用、规划、行动、观察闭环完整，禁止无边界自主调用 |
| 知识与 Skill 沉淀 | 第 7 讲 | 业务 Know‑How 封装为独立 Skill；Skill 描述、文档指针、细节文件分离；版本可追溯 | 观测：业务能力可沉淀、可单独更新，不用改动主 Agent 逻辑 |
| 编排与子智能体拆分 | 第 8 讲 | 子 Agent 拆分有明确驱动条件；任务书、上下文传递规范；子智能体之间通信边界清晰 | 观测：拆分不随意，避免子 Agent 互相循环、信息泛滥 |
| 工程落地指标 | 第 9、10 讲 | 三层评估标准、任务通过率；安全拦截、注入防护；单任务 Token 成本、超时、重试上限、人工升级率 | 红线：安全拦截必须生效；门禁：成本、成功率落在预设基线内 |
二、完整验收三步流程
- 对照基线材料
- 三分类判定
- 归因与排期
先审阅全套设计文档，明确这个 Agent 的任务目标、成功标准、权限范围、成本上限、失败兜底；再拉取线上真实 trace、测试集运行记录、失败样例，把 “计划怎么跑” 和 “实际怎么跑” 放到一起比对，不能只看输出文本，忽略中间轨迹。
符合预期：多条轨迹、多组测试稳定匹配设计目标，证据充分；待优化：大体可用，但存在固定 badcase、冗余调用、偶尔幻觉；不符合预期：核心流程跑偏、越权、高频失败，或是底层设计本身存在缺陷。
失败按四类定位：规划错误、行动 / 工具调用错误、观测解析错误、Skill / 知识库错误；修复优先级固定：安全 > 正确性 > 成本 > 用户体验。
三、核心能力拆解
- 区分 “表面答对” 和 “真正验收通过”
- 幻觉管控不依赖提示词魔法
- 上下文是重点风险区
- Skill 作为业务最小单元
- 持续验收机制
很多 Agent 单次回答正确，但多轮、异常输入、边界场景会翻车；这份清单强制检查闭环：规划、工具调用、结果解析、记忆召回、失败回滚，每一环都要留审计轨迹。
清单明确把幻觉管控放到机制层，不允许只靠一句 “你不能撒谎” 做约束；必须配套溯源校验、引用锚定、事实比对、可疑内容人工升级通道。
最常见反模式：所有文档、全部历史对话永久塞到提示词；合格方案是分层：常驻系统指令、按需召回的知识、摘要压缩的久远对话，控制每一轮输入体量，同时控制 Token 开销。
业务逻辑封装进独立 Skill，而不是散落在 prompt；好处是验收时可以单独验收单条 Skill，迭代时只更新对应模块，不会污染整个智能体。
Agent 是动态系统：底座模型升级、业务变更、用户分布漂移，都会让原本合格的系统慢慢失效；因此每次版本发布、每季度固定复评；发现新失败案例，同步补充进测试集和清单。
四、适合和不太适合场景
✅ 适合使用
- 准备上线、需要正式验收的业务 Agent（客服、工单、研发助手、企业内部智能体）；
- 团队缺少统一评审标准，大家对 “合格” 定义不一致；
- 有长期迭代计划，希望沉淀可复用的评审规范；
- B 端场景，对越权、数据泄露、错误操作有强约束。
❌ 不太适合
- 一次性轻量 Demo、纯玩具演示，不打算长期线上运行；
- 只需要开放式创意生成、没有固定业务目标、没有明确成功标准；
- 缺少 trace、日志、调用记录，拿不到运行证据，只能看最终输出。
五、上手实操步骤
- 把六格清单导出成勾选表，提前冻结验收基线：成功率阈值、单任务成本上限、安全红线；
- 准备测试集：正向标准任务、边界异常任务、对抗注入、权限越界测试用例；
- 批量跑任务，保存完整轨迹，逐条对照清单打标，区分红线、门禁、观测项；
- 汇总失败案例，定位到规划 / 工具 / 观测 / Skill；按优先级排优化工单；
- 本次验收完成后，把新发现的漏洞、遗漏检查点追加到清单；后续迭代重复执行。
六、常见误区
- 误区 1：输出看起来对，Agent 就算验收通过。事实：输出正确不代表链路可靠，大量 Agent 是 “偶然蒙对”，换参数、换模型就翻车，必须核查完整执行轨迹。
- 误区 2：验收做一次就永久生效。事实：模型、业务、数据分布会漂移，Agent 的合格状态会衰减，清单需要周期性复检。
- 误区 3：幻觉靠一句提示词就能管住。事实：清单明确提示词只是辅助，必须配套独立校验流程，否则属于机制不达标。
- 误区 4：子 Agent 拆得越多，系统越强。事实：拆分要有明确驱动，无节制拆分容易造成通信爆炸、上下文失控，验收时会判定编排不合格。
【常见问题】
问题 1：如何用一张验收清单评估真实 Agent 系统（11/12），清单由哪六大模块组成？
回答 1：这份验收清单来自《Agent 原理，架构与实践》第 11 讲，六大模块分别是机制共识、上下文工程、Agent 核心循环、知识与 Skill 沉淀、子 Agent 编排决策、工程落地指标，覆盖从底层认知、架构到安全成本的全链路验收。
问题 2：这套 Agent 验收清单判定问题之后，修复优先级是什么？
回答 2：固定优先级：安全最高，其次是任务正确性，再是 Token、调用次数这类成本问题，最后打磨用户体验；红线类安全问题一票否决，必须优先修复。
问题 3：这套 Agent 验收和普通功能测试差别在哪？
回答 3：普通功能测试只核对输出；这套验收同时核对设计文档与运行轨迹，重点看中间的规划、工具调用、记忆、权限、幻觉管控机制，识别 “单次答对、链路不可靠” 的假合格。
问题 4：完成一次 Agent 验收之后，后续还要怎么做？
回答 4：验收不是一次性工作，每次版本迭代、模型升级、业务扩张都要复检；新发现的失败案例补充进测试集，清单本身持续迭代扩充，形成长期评估闭环。
【参考资料】
[2026-11-07]（如何用一张验收清单，评估一个真实的 Agent 系统？（11/12））商业新知
[2026-11-07]（Agent 原理，架构与实践系列：第 1 讲 大模型没有记忆）商业新知
[2026-11-07]（Agent 原理，架构与实践系列：第 9 讲 垂直 Agent 评估）商业新知
[2026-11-07]（Agent 原理，架构与实践系列：第 10 讲 Agent 安全与成本设计）商业新知
[2026-04-15]（Anthropic：构建高效的 Agents）Anthropic 官方博客
【免责声明】
本文基于《Agent 原理，架构与实践》第 11 讲原文整理；该验收清单偏向企业自研 Agent 的架构评审，不同业务场景可以自行增删检查项；清单结果仅作为评审依据，不替代正式安全渗透、等保、合规审计；Agent 的实际稳定性随底座模型、知识库、业务数据持续变化；本文仅行业资讯梳理，不构成项目上线、采购、外包验收的法定标准。