解读下这个：https://x.com/josharosen/status/2097324183428444499

这篇讲的是：别等 Agent 干完活才给它打分，而是把“验收”放进执行过程，让验收结果决定下一步做什么。 拿修 bug 举个例子，这是对文中思路的具体化： 普通流程：Agent 看代码、修改、跑测试，最后告诉你“修好了”。 文章提倡的流程：动手前检查方案是否覆盖问题；修改后用程序检查测试是否通过，再让模型检查有没有绕开需求、漏掉边界条件。通过才进入交付，不通过就返工；缺证据就补信息，反复失败就交给人。 区别不在于“多了一个负责打分的模型”，而在于：验收结果真的能改变流程，而不是生成一段没人看的评价。 文章里的几个重点 第一，把“好不好”拆成具体问题。 别问“这份研究报告能打几分”，而是分别问：有没有回答用户的问题？关键结论有没有来源支持？有没有遗漏必要工作？ 这几件事不能混成一个总分。文笔再好，也不能抵消证据不足。拆开后，系统才知道究竟该重写表达，还是重新搜资料。 第二，不只验最终答案，也验关键步骤。 研究 Agent 如果一开始就选错资料，最后文章写得再漂亮也没用。与其全文完成后返工，不如在资料筛选完、开始综合之前先检查一次。 重点不是每一步都插个裁判，而是在“这里错了，后面做再多也是白做”的位置设检查点。 第三，裁判不一定要比干活的模型更强。 写出一份优秀报告很难，但检查“这些结论是否有给定材料支撑”，是范围更窄的任务，有可能交给便宜模型。 注意，是有可能，不是“小模型天然适合当裁判”。要拿实际样本验证它能不能判对，不能因为它说得像验收意见，就默认它可靠。 第四，多个裁判的分歧，比简单多数票更有用。 两个模型对是否通过意见相反，不一定要再找一个凑出二比一。分歧本身可能说明证据不够、标准不清，或者任务超出了当前模型能力。 此时更合理的动作可能是补证据、换强模型或找人。作者也明确说，多裁判这套模式目前没有太多生产采用的证据，并不是在介绍一个已经成熟普及的方案。 第五，能用代码判断的，别让模型猜。 测试过没过、字段全不全、数据库里有没有这条记录，都应该直接检查。 “证据是否充分”“有没有真正满足需求”这类语义判断，再交给模型。最终能否继续，由外围程序结合这些结果决定，而不是让裁判随口说一句“可以”就放行。 我觉得最值得拿走的是什么 这篇表面上在讲评估，实际上在讲 Agent 的流程控制：把一部分原来由人承担的验收判断，变成系统里的继续、返工、补证据和升级处理机制。 它和你刚才讲的“快速反馈、快速迭代”正好接得上： 你讲的是，人能快速看出哪里不对，然后纠偏。 这篇讲的是，其中哪些纠偏可以交给系统自己完成。 但这不等于加一个 judge 就能自动迭代到高分。裁判判错，Agent 就可能不断修改本来正确的东西，或者把错误结果一路放行。反馈快的前提仍然是反馈有效。 所以我的评价是：它是一份很清楚的架构模式梳理，不是一套已经证明能通吃的生产方案。最有价值的提醒是“让验收参与流程”；最需要警惕的是，把“模型说通过了”误当成“事情真的做对了”。