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