Agent 目标设歪，token 账单会先给反馈

Agent 的目标设计正在变成工程问题。LangChain 的 Harrison Chase 与 Actively AI 的 mgarimella、Anshul Gupta 合写了一篇《Goal Engineering: How to Design Goals》，原文在 X 上。文章讨论一个很具体的点：给 agent 定目标时，先想清楚人类怎么给反馈。

补一句背景。Agent 从文本生成走到工具调用、决策、执行任务，接下来会接开放式目标。目标范围设错，token 消耗只是最先出现的账单。文章提到，Hone 的 agent 设置里就有一项是给 agent 定义优化指标。

文章的核心判断是：设计 agent 范围时，要让 agent 在范围内工作时，人类尽可能容易给出高质量反馈。原因不复杂。Agent 出错常常缺正确上下文。文档、API 这类上下文好补。最难的是没写下来的知识，只能靠人类专家在反馈里交出来。Agent 开始做主观工作后，这点更明显。比如优化营销指标，品牌能多挑衅、审美偏好、表达边界，都很难写进文档。Agent 不能快速从反馈里学到这些，长任务里很快会变得没用。因此，审查 agent 工作的 UX 值得投入。瓶颈常在学习反馈，反馈采集的便利度和质量要优化。

案例来自 Actively AI。第一版是按账户建 agent，目标是推进账户，产出动作供销售审批。看起来合理，账户上下文似乎最重要。运行后发现另一类上下文同样关键：怎么高效做工作。具体到 outbound、回复、deal 策略、激进程度、怎么在大组织里 navigate。这些知识散在多个 agent 上。一个账户学到的 outbound 经验，经常要迁移到其他账户。按账户建 agent 让销售频繁切换上下文，跨 agent 分享学习也别扭。

第二版叫 motions，基于 Deep Agents。Motion 是一个具体 job to be done，比如 outbound 或 early-stage deal progression。一个 motion 包含一堆相似任务，销售可以一起审查，反馈从一个任务迁移到另一个任务。账户上下文仍重要，只是常已写下来、更客观，由后台 context-gathering agents 组装，motions 跨账户推进漏斗时按需拉取。

未来判断也直接：人类审查 agent 工作很花时间，但价值高，这是把领域知识教给 agent 的方式。目标是让 agent 的目标对齐人类最容易审查的粒度。文章末尾，Harrison Chase 写得很绝对：prompt engineering 和 context engineering 会消失，goal engineering 会留下。这个判断可以讨论，但它指出了一个现实：目标范围设计会直接影响反馈质量、学习速度和 agent 能否长期自主。

原文文章：https://x.com/i/article/2121382906820243456

原始推文：https://x.com/Hacubu/status/2121665217809801615