2 Goal Manager：把 Agent 的主目标钉在系统外面

发布日期: 2026-06-08

分类: Harness Engineering

预计阅读: 3 分钟

Agent 最容易跑偏的地方，往往不是模型不会推理，而是目标没有被牢牢保存。用户一开始说“帮我调研一个工具并写成文章”，中间搜索到很多新资料，Agent 就可能变成“继续搜索更多资料”，最后忘了交付文章。

Goal Manager 要解决的就是这件事：把主目标从对话历史里拿出来，变成一个独立对象。模型可以忘，历史可以压缩，但 Goal 不能丢。每轮调用前，系统都把 Goal 重新放回输入里。

一个好 Goal 不是“帮我做一下”这种模糊句子，而是包含目标、交付物、约束、完成标准和风险边界的任务契约。它越清楚，Planner 和 Executor 后面越稳。

1. Goal 要独立于聊天历史

聊天历史是过程，不是目标。过程里有尝试、插曲、观察结果和临时判断，不能让模型每轮都从里面重新推断主线。Goal Manager 的第一条规则，就是目标单独存放。

例如：目标是“写一篇 3000 字公众号文章并输出配图建议”。这个目标不会因为中间搜到一个新模型、一篇新论文或一个新工具就自动改变。要改目标，应该有明确的用户确认或系统级重新规划。

第一是 Objective，也就是最终要完成什么。第二是 Deliverables，也就是要交付哪些产物。第三是 Constraints，也就是范围、风格、时间、权限和不能触碰的区域。第四是 Done Criteria，也就是满足什么条件才算完成。

如果是写文章，Done Criteria 不能只写“写好”。可以写成：标题已定、正文已完成、图片已插入、参考资料已列出、没有明显事实错误、能在网站页面正常打开。

Goal Manager 的常见调用方式是：Goal + CurrentState + CurrentTask + UserMessage。模型不需要猜“我们现在到底在干什么”，因为输入里已经明确给出。

这和把所有历史都塞进上下文不同。所有历史会越来越重，还会带入噪音；Goal 注入只保留稳定主线，State 注入只保留当前必要信息。

真实任务里，目标当然可能变化。比如调研时发现原本主题不存在，或者用户中途要求改成短视频脚本。关键不是目标不能变，而是目标变化必须显式发生。

一个稳的 Harness 会记录 Goal Revision：谁改的，为什么改，改了哪些字段，旧目标是否废弃。这样后面复盘时能知道 Agent 是合理转向，还是悄悄漂移。

拿你最近一个常用任务，写一份 Goal Contract。不要写长，控制在 8 行以内：目标、交付物、约束、完成标准、禁止事项。然后问自己：如果 Agent 执行 20 步之后，只看这份契约，还能不能找回主线？

下一节我们讲 State Engineering。Goal 负责主线不变，State 负责记录过程变化，这两者分开以后，Agent 才真正开始稳定。