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更稳定、可观察。能解决的实际痛点一次做不对代码写了但测试没过、报告缺了必写章节、诗歌音节不对、重构改了不该改的文件等。长任务容易跑偏多轮工作中目标逐渐模糊代理“感觉做完了”其实还差关键标准。非交互场景无法人工把关CLI / CI / 批处理里没法中途暂停让人审查标准。提示词 alone 不够可靠只靠 system prompt 说“必须通过测试、不要改无关文件”模型经常会忽略或自欺欺人独立 grader 迭代循环更强制。需要可验证的“完成”定义尤其适合有明确成功标准的任务测试通过、格式合规、覆盖指定要点等。工作循环简化代理执行任务。Grader 对照 Goal/Rubric 检查。不满足 → 给出每条标准的具体反馈 → 代理再改。重复直到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 则直接把已有验收清单变成运行时质量门禁。两者都通过独立评分 自动迭代显著提高代理在复杂、有明确成功标准的任务上“一次做到位”的概率特别适合编程、报告生成、研究、内容生产等需要可靠交付的项目。