问题
搭 Agent 的团队几乎都经历过这个循环：改了一版，手动试三五个 case，感觉好多了，上线。过两天用户又报了一个新 badcase，再补丁式修改。
这个循环的问题不在于改得慢，在于没有坐标系：不知道这次修改让系统整体变好还是变坏，也不知道问题出在链路的哪一段。归结起来就是一个问题：Agent 怎么知道自己做对了？
正路：把循环倒过来
先定义“好”是什么（评测集 + 判分标准），再让每次修改对着评测集回归。修改的最小单位不再是“改了个功能”，而是“评测分从 61 → 68，退化 0 例”。
从 benchmark 身上拿三样东西
- 读榜选型：用公开榜单比较模型与方案
- 抄判分方法：借鉴公开 benchmark 的判分标准，建自己的评测集
- 切片诊断：出问题时，把单次执行拆成节点逐段定位
一次执行的 7 个节点
任何一个 Agent 系统，不管什么框架、什么模型，单次请求都可以拆成 7 个节点：输入理解与澄清、检索/工具调用、上下文组装、推理规划、执行、结果验证、输出。每个节点都有典型的坏法——该问不问、拿着歧义需求猛跑；检索结果不相关；验证缺失导致幻觉输出。
实践体会
- 评测集不是一次建完的：每发现一个 badcase，就把它沉淀进评测集
- 判分标准要可执行：能说清“什么算对”，才能让修改有方向
- 没有坐标系的迭代，只是看起来在进步