如果你刚开始搭建 Agent 系统，一个相当自然的想法是：让 Agent 先把任务做完，然后再让它自己检查一遍。听上去挺合理，相当于多了一道保险，结果应该更稳才对。但现实往往很打脸。模型往往会稳定地给自己打出高分，哪怕结果只是勉强能用，甚至带着明显的硬伤。
这种现象在主观任务里尤其突出，比如 UI 设计、交互体验或者创意内容。表面上看，产出似乎没什么大问题；但一旦真的上手去用，按钮没有响应、逻辑断裂、状态不一致这些硬伤就会全部暴露出来。换句话说，问题通常不是"看起来不对"，而是"用起来不对"。
问题的关键不全在模型本身的能力，更在于任务结构本身：
- 当生成和评估由同一个 Agent 完成时，本质上是在让同一套偏好体系做两件事
- 模型天然倾向于合理化自己产出的结果，而不是主动推翻它
- 对于主观问题来说，一旦缺乏外部标准，自洽就会被误认为正确
这意味着，自评并不是真正意义上的第二次判断，更像是第一次判断的延续。它会继承前一次生成时的偏好、假设和盲点，而不是独立地重新审视问题。所以，一个更可靠的原则是：生成与评估必须分离。与其要求生成者自我批判，不如让一个独立的角色来校准结果，这通常要可靠得多。
这不是一个工程实现的细节问题，而是系统设计层面的分水岭。只要这一步没有分开，后面叠加再多的检查环节，也很容易沦为同一种判断方式的重复放大。
多 Agent 如何拆解复杂问题
一旦接受了自评不可靠这个现实，下一步自然就是引入独立的评估者。但实践很快会发现，仅仅增加一个 Evaluator 还不够，因为输入本身往往还是模糊的。如果任务定义不清，评估再独立，也只能对一个模糊目标做判断。
这就引出了一个更完整的结构演进：
- Planner：把一句话需求转成结构化的规格
- Generator：基于规格完成实现
- Evaluator：独立验证结果是否达标
这个三段式结构的核心价值，不在于多了两个 Agent，而在于任务被重新分解了。原本混在一起的需求理解、任务执行和结果判断，被拆成了三类性质完全不同的工作。
原本一个模糊的大问题，比如"做一个游戏编辑器"，被拆成了三个不同性质的子问题：
- 什么是完成——定义问题
- 如何实现——构造问题
- 是否正确——验证问题
每个子问题都可以被单独优化、约束和调校。这样做的好处是，系统不再把所有不确定性都压在一个 Agent 身上，而是把复杂度分摊到多个可管理的环节里。
这对应一个关键方法论：拆解任务，用专职 Agent 攻克子问题。在这种结构下，质量提升通常很明显，系统会开始从"能跑"走向"可用"。与此同时，代价也很直接：耗时更长、成本更高、流程更复杂，链路里的每个角色都需要被单独约束和维护。
这一步的意义，在于证明了一件事：结构可以放大能力，但也会同步放大成本。系统设计从来不只是追求上限，还要判断这个上限，是否值得当前的复杂度。
让主观问题可验证
当系统演进到多 Agent 之后，真正的瓶颈会迅速转移：不再是生成不出来，而是评估不准。很多时候，系统失败不是因为没有产出，而是因为错误产出没有被及时识别出来。
一个典型问题是，Evaluator 虽然能发现 bug，但结论仍然偏宽松，比如明明存在问题，最后却只落到"整体不错"。这本质上还是另一种形式的偏差：它识别到了缺陷，却没有把缺陷真正转化为否决信号。
要解决这个问题，通常需要三层改造。
第一层，是从观察结果转向操作验证。评估不再停留在截图、代码片段或文字描述上，而是通过真实交互来完成，比如自动点击按钮、调用 API、检查数据库状态。只有进入行为层，很多隐藏问题才会真正暴露出来。否则，我们评估的往往只是"看起来像正确"，而不是"实际上可以工作"。
第二层，是从主观判断转向验收标准。模糊目标必须被拆成具体检查项。比如"界面好看"本身没有可操作性，但"对比度是否达标"、"拖拽是否覆盖完整区域"，这些都可以被明确验证。标准一旦落到检查项，主观任务就开始具备工程化的可评估性。
第三层，是从训练模型转向训练 prompt。评估偏差并不一定要通过微调模型来解决。很多时候，更高性价比的做法，是分析评估日志，识别它的判断模式，再用 prompt 做约束和纠偏。换句话说，先把错误模式找出来，再把判断框架校准清楚。
这一整套方法指向一个核心原则：用具体标准让主观判断可打分。同时，它也会带来一个更深层的认知：真正困难的不是生成结果，而是定义什么算好。评估系统本身也是需要持续调校的对象，而不是一个搭好以后就能长期不动的模块。它和生成系统一样，需要随着任务形态、模型能力和数据反馈不断迭代。
模型进步如何重塑系统设计
当上述体系逐步建立后，很容易产生一个误判：把它当成某种最优架构。但模型能力一旦继续演进，这种稳定性很快就会被打破。
比如，早期模型在长上下文里容易退化，所以系统不得不依赖复杂的流程拆分和状态管理；但新一代模型具备更强的上下文压缩和连续推理能力后，这些机制反而会变成额外负担。原来用来补短板的结构，后来可能会变成新的摩擦源。
结果是，系统开始反向演化：
- 删除多轮结构，改为单轮评估
- 去掉复杂的协商机制，比如冲刺合约
- 简化 Agent 之间的交互方式
在某些任务里，简化后的系统反而能在成本和效果之间取得更优平衡。这里的关键不在于"复杂系统一定更强"，而在于"结构是否仍然对当前模型有效"。这也引出两个关键方法论：持续实验，因为你今天对模型的假设，过一段时间就可能过期；新模型发布时重新审视 Harness，主动删掉那些已经不再承重的复杂性。
系统设计不再只是不断增加能力，而是不断移除不必要的结构。很多时候，真正的优化不是继续堆模块，而是识别哪些模块已经不再提供净收益。最终可以得到一个更高层的结论：模型变强不会让系统设计消失，而是会改变优化的方向。复杂性不会消失，只会转移到更高层级。
