Goals 和 Rubrics 是 LangChain Deep Agents 中用来定义“任务完成标准”并驱动代理自我检查与迭代修正的两套机制。它们解决的核心问题是：代理经常“方向正确，但第一次没完全做对”，导致输出不达标。

---

1. 概念对比

维度	Goal（目标）	Rubric（评分标准）
何时用	你只有高层目标，希望代理先帮你把“完成标准”具体化	你已经明确知道验收条件
工作方式	代理先起草验收标准 → 你审查确认（可改、可拒）→ 再开始干活	直接把标准交给代理，作为硬性质量门禁
生命周期	跨多轮对话持续有效，直到完成/阻塞/清除；支持暂停、恢复、修订	可设为“仅下一轮”或“持续生效”；也可跨调用持久化
交互性	依赖人审查标准（交互式场景）	适合非交互式（CLI 一次跑完）
典型命令	/goal add OAuth refresh handling	/rubric set tests pass; no unrelated files changed 或 --rubric "..."

两者底层都依赖 LLM-as-a-judge（用大模型当裁判）：工作模型完成后，一个独立的 grader（评分子代理） 对照标准检查，不通过就注入反馈让主代理继续改，直到全部满足或达到最大迭代次数。

---

2. 作用与能解决的实际问题

主要作用：

• 把模糊的“做好就行”变成可检查的验收清单。
• 让代理在真正结束前自动自我评估 + 迭代修正，而不是一次输出就完事。
• 把“质量把关”从主代理的提示词中剥离出来，交给专门的 grader，更稳定、可观察。

能解决的实际痛点：

1. 一次做不对：代码写了但测试没过、报告缺了必写章节、诗歌音节不对、重构改了不该改的文件等。
2. 长任务容易跑偏：多轮工作中目标逐渐模糊，代理“感觉做完了”其实还差关键标准。
3. 非交互场景无法人工把关：CLI / CI / 批处理里没法中途暂停让人审查标准。
4. 提示词 alone 不够可靠：只靠 system prompt 说“必须通过测试、不要改无关文件”，模型经常会忽略或自欺欺人；独立 grader + 迭代循环更强制。
5. 需要可验证的“完成”定义：尤其适合有明确成功标准的任务（测试通过、格式合规、覆盖指定要点等）。

工作循环（简化）：

1. 代理执行任务。
2. Grader 对照 Goal/Rubric 检查。
3. 不满足 → 给出每条标准的具体反馈 → 代理再改。
4. 重复直到 satisfied 或达到 max_iterations。

Grader 还可以配备工具（比如跑测试套件、读文件、数音节），让评判更客观。

---

3. 适合运用到哪些项目 / 场景

Goals / Rubrics 特别适合**有清晰“完成定义”**的中长期、多步骤任务。典型项目类型：

编程与工程类

• 实现功能（如 OAuth refresh handling）并要求测试通过、不改无关文件、更新帮助文档。
• 重构：只改指定模块、保持 API 兼容、测试全部绿。
• 代码生成：函数签名正确、边界情况处理、通过给定测试套件。
• 自动化 PR / 代码审查代理：按团队规范检查。

内容与文档类

• 写报告 / 研究综述：必须覆盖指定章节、引用数量、字数范围、无幻觉声明。
• 博客 / 营销文案：符合品牌调性、包含 CTA、SEO 关键词、指定结构。
• 诗歌 / 创意写作：严格音节（如 5-7-5 俳句）、主题约束。

研究与分析类

• Deep Research 代理：必须回答所有子问题、列出来源、对比多方观点。
• 数据分析：生成脚本 + 图表 + 结论，且脚本可执行、结果可复现。
• 合规 / 审计报告：覆盖法规条款、证据链完整。

产品与业务工作流

• GTM / 销售策略代理：产出必须包含竞品分析、定价建议、下一步行动清单。
• 客服 / 工单处理：回复满足 SLA 模板、包含正确信息、语气合规。
• 内容生成管道（多平台适配）：同一内容同时满足 Twitter / LinkedIn / 博客的不同约束。

非交互 / 自动化场景

• CI/CD 中的代码修改任务。
• 批处理报告生成。
• 后台异步代理（如 Open SWE 一类的内部编码代理）。

不太适合的场景：

• 完全开放式、没有可判断对错标准的探索（“随便聊聊想法”）。
• 极短、单步、确定性任务（直接调用工具即可）。
• 需要强人类主观审美且难以用文字描述的任务（grader 也会受限于标准的可操作性）。

---

4. 使用建议（实践层面）

• 有明确标准时优先用 Rubric（尤其是脚本化、非交互场景）。
• 目标较模糊、希望代理帮你细化时用 Goal，并在交互模式下审查它起草的标准。
• 给 grader 配上可执行工具（跑测试、检查文件 diff、验证格式）比纯文本推理更可靠。
• 设置合理的 max_iterations（常见 3–5），避免无限循环。
• 标准尽量写成可观察、可验证的条目（“tests pass”“no unrelated files changed”“包含 3 个引用”），而不是“写得好”“专业”。

---

总结：
Goals 让代理先帮你把“什么叫完成”说清楚并经过确认；Rubrics 则直接把已有验收清单变成运行时质量门禁。两者都通过独立评分 + 自动迭代，显著提高代理在复杂、有明确成功标准的任务上“一次做到位”的概率，特别适合编程、报告生成、研究、内容生产等需要可靠交付的项目。