LangChain 给 Deep Agents 加了一个新能力：RubricMiddleware。它的核心功能很直白——你定义一份"做完的标准"（rubric），agent 每次跑完之后会由一个独立的 grader sub-agent 按 rubric 逐条打分，没全过就按 criterion 把反馈注回主对话，让 agent 重新跑。终止条件有四个：rubric 全部 satisfied、达到 max_iterations、整体 failed、grader 自身出错。
如果用过 Claude Code 的 /goal 指令或者 Codex，思路是类似的——区别在于这次的 grader 是一个独立的 sub-agent，能调用工具、能推理完整 transcript、能返回按 criterion 维度的反馈，比单纯一句"继续做到对"灵活得多。
真实问题：agent 永远做不到一次到位
Agent 接到任务后，输出经常是"方向对、没落地"。代码能跑但有一个测试挂了、报告每个章节都覆盖但少了一个表格、需求都实现了但缺了错误处理。问题是 context 越长，歧义指令、工具误用、随机性错误会叠加放大，最后质量塌方，开发者只能肉眼 review 完手动重跑。
这种"概率性失败"是 agent 输出最让人头疼的部分：同一个 prompt 上一次成功下一次就崩。RubricMiddleware 的目标就是把"捕获这种方差"的负担从开发者身上挪到系统里。
工作机制
中间件挂在 agent run 的结尾。在 run 真正结束前，独立的 grader sub-agent 会按 rubric 一条一条对照检查：
- 全过 → run 结束
- 没过 → grader 输出按 criterion 的反馈，反馈被注入到主对话，agent 再跑一次
- 循环直到 rubric 全部 satisfied，或者达到
max_iterations上限，或者整体 failed / grader 自身出错
关键点：grader 是一个 sub-agent，不是字符串模板。它能调工具（比如 run_test_suite 实际跑一遍测试），能推理完整 transcript，能给每个 criterion 出独立的 verdict。这意味着反馈是针对性的——不是"再试一次"，是"测试 test_unhashable 失败，函数遇到 unhashable 类型会 crash"。
接入方式
接入分成三步，对应 deep agents 的三段式结构：
第一步：定义 RubricMiddleware。 这里要配置 grader 用的 LLM（通常比主 agent 模型小、便宜）、grader 的 system_prompt（决定"好"的标准）、grader 能调的工具（可以给它 run_test_suite 之类的工具去拿硬证据），以及 max_iterations 上限。
第二步：把 middleware 挂到 deep agent 上。 主 agent 的 system_prompt 告诉它"怎么干活"（编码规范、约束），rubric 告诉 grader"怎么判"。两个职责完全分离。
第三步：invoke 时传 rubric。 这是最关键的——rubric 不是写死在 agent 定义里的，而是每次 invoke 时作为参数传入。如果某个 invoke 没传 rubric，中间件直接什么也不做。 这让 rubric 跟具体任务绑定，而不是 agent 的通用配置。
文章里给了一个真实例子：让 agent 写 find_duplicates(lst)。rubric 是两行 checklist——"所有测试通过"、"函数命名 find_duplicates、接受一个 list 参数"。第一次跑，函数看着对但 test_unhashable 测试挂了：输入里含 list 时函数 crash。grader 的反馈按 criterion 给出，agent 第二次修过。
为什么这是关键一步
文章的总结点得清楚：Agent 输出是概率性的，同一个 prompt 这轮过下轮崩。RubricMiddleware 把"抓住这种方差"的责任从开发者挪到系统里。
"开发者不用肉眼检查每个输出再手动重跑了——你定义一次'做完'是什么样，剩下的循环帮你跑完。每次重试都是有依据的，grader 明确指出哪里错、给出按 criterion 的针对性反馈。"
结果是：在一类正确性真的很重要的任务上，agent 变得可以信赖。
跟其他模式的关联
- Claude Code 的
/goal思路接近，但 grader 是模型自评（subjective），不能调工具 - Dynamic Workflow 里的 adversarial verification 模式（Thariq 那篇讲的）是让一个独立 agent 验证另一个 agent 的产出，但 rubric 通常内嵌在 prompt 里
- RLAIF / Constitutional AI 是训练时让模型按规则评估自己
- RubricMiddleware 是把"评估循环"作为运行时的可配置中间件交给开发者用
最实用的差别是：rubric 是 invoke 时的参数，不是 agent 的系统配置。这意味着同一个 agent 定义可以根据任务动态切换 rubric——做 code refactor 用一份 rubric，做 report 写作用另一份 rubric。这才是中间件该有的样子。
适用边界
文章自己点出了适用场景："most effective for tasks with clear, verifiable success criteria like passing tests, avoiding forbidden patterns, covering required sections."
本质上是：完成标准能被结构化成 checklist 的任务。代码改对了有测试、有 lint 规则、有 type check。报告写对了有 section checklist、有字数下限、有引用数要求。open-ended 的创意任务（写一首诗、想一个 slogan）反而不适合——rubric 一旦写死就压抑发散了。
当前状态
RubricMiddleware 还在 beta，API 可能变。完整 walkthrough（包括配置、可观测性、rubric 持久化）在 LangChain 文档里。
值得记住的一点：现在 agent 框架普遍在补齐"运行时的评测循环"这一块——LangGraph、Claude Code Dynamic Workflow、Deep Agents RubricMiddleware 殊途同归。说明 agent 系统的下一个质量瓶颈不在生成侧、而在校验侧：模型能力够写出"大致对"的答案，瓶颈是怎么稳定地验证它"真的对"。