用一张清单解剖一个真实 Agent 系统——评审对象是我们自己的 sdd-site-agent
上一讲结尾咱们说：十讲了，机制、上下文、记忆、循环、工具、skill、编排、评估、安全、成本——零件全了。可这套体系拼起来的完整系统，到底过不过关？
验收一个系统不能靠感觉。感觉过得去的系统，上线第一个月就会教咱们做人。这一讲，咱们做一件硬核的事：把前十讲的标准收成一张评审清单，然后拿它解剖一个真实系统——咱们自己的 sdd-site-agent。
大伙过去十讲攒下的课后作业（分层表、记忆表、循环图、工具清单、三个 skill、拆分决策、三层评估标准、安全清单、成本预算），都做完了吗？今天全部拿出来吧——它们就是最好的评审材料。
问题一：评审清单，怎么来？
评审清单不用重新发明了，前十讲每一讲都贡献了自己的标准。把它们按模块汇总到一起，就是一张六格清单：
第一格：机制共识（第 1-2 讲）
过关标志：团队对无记忆/token/窗口/幻觉有统一认知，
幻觉防线靠流程而不是提醒
常见翻车：把模型当数据库用，指望它"记住"和"诚实"
第二格：上下文工程（第 3-4 讲）
过关标志：有分层设计（常驻/按需）、有记忆结构、
有压缩策略
常见翻车：所有知识常驻系统提示词，将上下文窗口当仓库用
第三格：Agent 核心（第 5-6 讲）
过关标志：循环四步完整，工具按工作流设计、
权限有边界
常见翻车：单次调用当 Agent，API 逐个包装当工具
第四格：知识沉淀（第 7 讲）
过关标志：know-how 以 skill 的形式沉淀，
description 是触发器
常见翻车：规范只存在老员工脑子里，Agent 各凭感觉
第五格：编排决策（第 8 讲）
过关标志：拆分决策由信号驱动，任务书显式传递上下文
常见翻车：为显得高级而拆，子 Agent 上下文靠猜
第六格：工程化落地（第 9-10 讲）
过关标志：有三层验收标准、有通过率数据、
有安全清单、有每成功任务成本
常见翻车：上线靠目测，成本只算单次调用这张清单就是这门课的”毕业考纲”——它同时是 agent 的设计清单和评审清单：设计时按它建，评审时按它查。它的便携版收在速查卡区：Agent 设计实战总速查卡——评审时打开那张卡，逐项过。
问题二：怎么解剖一个真实系统？
清单在手，评审我有。三个步骤：
第一步：先读设计文档，再看运行证据。设计文档（我们的十份作业）说明”系统打算怎么跑”；运行证据（调用轨迹、通过率、成本账）说明”系统实际怎么跑”。两个都要看——只读文档会被”设计意图”骗，只看数据会读不懂”为什么这样设计”。
第二步：逐格打三档，每条附证据。
过关 有明确证据支撑（文档或数据）
待改进 有设计但不完整，或证据不足
翻车 没有设计，或设计本身就是错的注意”附证据”这三个字——没有证据的”过关”只是自我感觉良好。这和 skill 课第 6 课是同一个纪律：评审不是找茬，是用标准解剖；而且官方也不能免检——当时咱们评审 Anthropic 官方示例都能找出问题，今天评审咱们自己的系统，标准一分也不能降。
自己评自己，是最容易手软的环节。所以三档里专门留了”待改进”——不用逼自己非黑即白，但每一条都要拿出证据说话。（沈剑评过别人的系统十几年，这次评自己设计的——手软是本能，但别手软。）
第三步：问题归因，排改进优先级。评出来的问题按第 9 讲的四类归因（规划/行动/观察/知识），然后排优先级：
安全 > 正确性 > 成本 > 体验
权限没收口的先收，评错的先修，
烧钱的后优化，体验的最后打磨问题三：评审是一次性的吗？
不是。系统会变——模型会升级，规范会演进，业务会扩张。评审得变成定期动作：每个季度，或者每次大改版，把清单拿出来重新过一遍。清单本身也是活的：每次评审发现清单没覆盖的新翻车，就把它补进去——评审体系和测试集一样，朝真实风险面生长。
沈剑的团队每个季度做架构评审，清单每年都在长——哪天清单不长了，多半说明没在真评。
落到 sdd-site-agent：咱们自己的评审
现在，把十份作业摆上桌，按六格清单过一遍。我猜一下大概率的结果哈：大部分格子是”过关”——因为课程就是按这个清单铺着设计的；但大概率也能评出真问题，比如：
可能的待改进项：
三个 skill 的资源层（模板/示例）还不够厚
测试集 case 数量还太少，覆盖面不足
成本预算基于的通过率样本只有 5 个任务
编码子 Agent 的拆分还没实测验证评出自己的系统”待改进”，不是打脸，是评审在正常工作——咱们自己设计的系统也不是免检的。这门课从头到尾都在说”靠流程不靠感觉”，评审自己，让我们最后一次身体力行。
实操演练（约 30 分钟）
必做部分 + 一步加餐。做完必做部分，本讲的核心手感就到手了。
检验一下
①sdd-site-agent 完整评审报告：六格三档 + 每条证据 + top 3 改进项——这是第 12 讲向团队推广时的”样板间”，团队会照着这份报告学怎么评自己的系统。
本讲是课程的收拢讲，来源就是前十讲自己——每一格清单后面都标注了对应的讲次，翻回去复习哪格都行。
评审方法论的源头：skill 课第 6 课《综合评审：用标准解剖一个真实 Skill》——同样的”清单+三档+证据”纪律，那次评的是 skill，这次评的是整个 Agent 系统。
但还有一个没解决的问题：系统评审过关了，它会成为我们团队的新同事。可一个团队要怎么真正用好它？从个人提效到组织改造，中间隔着什么？为什么有的团队 AI 化成了，有的团队买了一堆工具落不了地？——第 12 讲，我们讲团队 AI 化路线。
本讲评审清单的上游出处：Anthropic · Building effective agents——清单里的每一条，都能在这篇官方原则里找到源头。
评审完我们自己的系统，建议再拿官方示例练一遍手，清单就真正长在你身上了。
知其然，知其所以然。思路比结论更重要。