如何用一张验收清单，评估一个真实的Agent系统？（11/12）
架构师之路 · 软件开发
原创 58沈剑 2026-11-07 11:46 北京 《Agent原理，架构与实践》 第11讲：Agent验收评估 准备起一个新的系列 《Agent原理，架构与实践》 。目标不贪心： 1. 希望每篇文章有1-2个点能让大家有收获； 2. 希望不被骂； 本期第11讲，咱们开始。 前面10讲：机制、上下文、记忆、循环、工具、skill、编排、评估、安全、成本——一个Agent的各个部分基本都全了。那么问题来了： 用这套体系构建起来的完整Agent系统，如何验收它到底是否符合设计预期？ 【1】问题一：验收清单checklist，从哪里来？ 验收清单不用重新发明创造，前十讲每一讲都提到了相关的标准，把它们汇总到一起，就是一张六格清单： 第一格：机制共识（第1-2讲） 1. 对大模型无记忆，对token，对上下文窗口，对模型幻觉，是否有统一认知？ 2. 幻觉预防，是靠流程还是靠系统提示词提醒？ 3. 是否指望模型"记住"和"诚实"？ ... 具体参见： 《 大模型没有记忆，token就是钱，上下文窗口就是天花板（1/12） 》 《 大模型为什么会「幻觉」？这其实就是它的机制！（2/12） 》 第二格：上下文工程（第3-4讲） 1. 上下文是否有分层设计（常驻/按需）？是否有记忆结构？是否有压缩策略？ 2. 是否 所有知识常驻系统提示词？ 3. 是否把上下文窗口当仓库用？ ... 具体参见： 《 Agent的上下文里，究竟要放哪些东西？（3/12） 》 《 Agent的长期记忆要怎么做？（4/12） 》 第三格：Agent核心（第5-6讲） 1. 双循环四步骤是否完整？ 2. 工具是否按工作流设计？ 3. 权限是否有边界？ 4. 工具是否是 API逐个包装？ ... 具体参见： 《 做个Agent，首先得知道什么是Agent！（5/12） 》 《 为什么说工具是 Agent 的手？（6/12） 》 第四格：知识沉淀（第7讲） 1. know-how是否以skill的形式沉淀？ 2. description设计是否靠谱？ 3. skill.md是否保存指针？ 4. 细节是否在单独文件里？ ... 具体参见： 《 Agent架构，know-how怎么设计？（7/12） 》 第五格：编排决策（第8讲） 1. subagent拆分决策由什么驱动？ 2. 任务书怎么传递上下文？ ... 具体参见： 《 究竟什么时候该拆subagent？（8/12） 》 第六格：工程化落地（第9-10讲） 1. 是否有三层验收标准？是否有通过率数据？ 2. 是否有安全设计？ 3. 是否有成本评估？ ... 具体参见： 《 如果你做了一个垂直Agent，如何评估它的好坏？（9/12） 》 《 Agent架构，安全和成本，如何设计？（10/12） 》 这张清单就是Agent架构系列内容的"毕业考纲"。它同时是Agent的设计清单和验收清单：设计时按它设计， 验收 时按它检查。 【2】问题二：怎么分步骤迭代优化Agent系统？ 大的方向上，三个步骤： 第一步：先读设计文档，再看运行结果。 设计文档（咱们的十份作业）说明"系统计划怎么运行"；运行结果（调用轨迹、通过率、成本情况）说明"系统实际怎么运行"，两个都要看，还要进行比对。只读设计文档，容易被"设计意图"欺骗，只看运行结果，可能会看不懂"为什么这样设计"。 第二步：比对第一步的结果，可能有三种情况。 情况一，运行结果符合预期：有明确证据支撑，符合设计； 情况二， 运行结果 有待改进：部分证据支撑，基本符合设计； 情况三， 运行结果不符合预期：实现有问题 ，或者设计本身就是错的； 自己是裁判，又是运动员，评审验收不要手软。不用逼自己非黑即白，每一条都拿“运行结果”证据说话。 第三步：问题归因，排改进优先级。 不符合预期的地方，按第9讲的四类归因，到底是Agent的哪个大步骤出了问题：是规划错了？行动错了？观察错了？知识（技能）错了？ 修正的优先级是：安全>正确性>成本>体验。 安全是底线，必须高优修改，不符合预期的 错误 其次，然后是烧钱的地方，体验的细节可以最后打磨。 【3】问题三： 验收 完一次，就OK了吗？ 显然不是。 系统会变，模型会升级，规范会演进，业务会扩张。Agent评估与review需要变成定期动作：每个季度，或者每次大改版，把清单拿出来重新check一遍。执行结果与设计初衷，是否有新的不一致。 checklist本身也是动态的：每次review发现清单没覆盖的问题，就把它补进去——验收体系和测试集一样，发现了不符合预期的地方，发现bad case，就要补充进去。 画外音：和架构设计checklist，上线checklist一样，做出来的Agent的checklist每年都会增长。 【4】简单总结 今