夜雨聆风
最近我一直在看几类东西：Claude Code 的 /goal，Codex 的 Goal Mode，Claude Managed Agents 里的 define_outcome，还有 Hermes 里的 Persistent Goals。
看着看着，我有一个挺强的感觉：Agent 这件事，正在从“会聊天”往“会接任务”走。
这句话听起来有点像行业黑话。过去两年我们已经听了太多“Agent 要来了”“Agent 会改变工作流”“Agent 是下一代软件形态”之类的说法。很多时候，讲到最后还是落回那几个熟悉的问题：模型是不是更聪明了，工具是不是更多了，能不能联网，能不能读文件，能不能操作浏览器。
这些当然都重要。没有模型能力和工具调用，Agent 连上桌的资格都没有。
只是我最近越来越觉得，值得盯住的变化，可能不是“Agent 又多会了一个工具”，而是它开始改变自己和用户之间的关系。
以前大多数 AI 产品，本质上还是你问一句，它答一句。就算它能调用工具，能查资料，能跑命令，节奏也仍然是用户握着的。你说“继续”，它才继续。你说“下一步”，它才下一步。你不说话，它就停在原地，像一个聪明但很谨慎的助手。
Goal-driven Agent 往前迈的一步，就在这里。
它不再只问：“你现在想让我回答什么？”
它开始问：“你最终想让我完成什么？”
这两个问题听起来只差几个字，产品形态却会完全不一样。
我们以前其实一直在带着 AI 干活
你可以回想一下自己平时怎么用 AI，尤其是用 Claude Code、Codex、Cursor 这类工具的时候。
假设你手上有一个旧项目，测试挂了一片。你打开 Agent，说：“帮我看看为什么 tests/auth 失败。”
Agent 很快开始工作。它读了一下测试文件，看了一眼报错，再看了一眼相关实现，然后告诉你：“问题可能出在 token refresh 逻辑里，我准备检查一下 auth service。”
你觉得挺好，说：“继续。”
它继续看。过一会儿，它说：“我发现这里有一个 mock 没有覆盖新字段，我可以尝试修复。”
你说：“修一下。”
它改了文件，跑了测试，又报另一个错。它解释了一遍，说：“现在还剩一个失败，可能和 session expiry 有关。”
你说：“继续修。”
它又修。再跑。再解释。再等你下一句话。
这个过程乍一看像 AI 在干活，其实更像你在带着它干活。你是项目经理、tech lead、测试负责人、验收员、流程推进器，全都由你一个人兼着。Agent 很聪明，但它每做完一步都抬头看你一眼：然后呢？
我这几天整理 Hermes 和 Claude Code 的学习笔记时，也有类似的感觉。很多资料不难找，难的是持续推进：先看一份架构文档，再对照源码入口，再整理成 PM 能讲清楚的逻辑，再把 Hermes、Claude Code、Codex、OpenClaw 放在一起比较。中间每一步都不复杂，但步骤很多。一旦 Agent 每完成一小段就停下来等我说“继续”，我就又被拉回了遥控器的位置。
现在很多 AI 产品已经从“只能回答问题”进化到了“能做事”。只是做事的方式，仍然很像一个高级命令行。你敲一次，它动一下。你停下来，它也停下来。
有些场景这样很好。比如你只是想问一个概念，或者让它帮你改一小段文案，或者让它解释一段代码。短任务天然适合对话式交互，用户在场也没什么成本。
可一旦任务变长，这种模式就开始别扭。
很多任务并不需要用户每一步都参与。它们的难点不是“下一步该做什么”，而是“要连续做很多步，并且做到一个能交付的状态”。
比如，修完一个模块下所有 failing tests。
比如，把一批用户反馈按问题类型归因，整理出优先级和产品建议。
比如，根据一份 PRD 做出一个可演示的原型。
比如，追踪一个竞品的定价、功能、定位变化，最后产出一份能拿去评审的材料。
这些任务都有一个共同特点：目标不算模糊，但中间会有很多小步骤。你不想每五分钟说一次“继续”，你只是想交代一句：“做到能交付再回来找我。”
goal mode 吸引我的地方也在这里。它解决的不是一个很炫的问题，而是一个很日常的问题：用户不想一直当 Agent 的遥控器。
/goal 表面是命令，背后是控制权的移动
第一次看到 Claude Code /goal 的时候，我其实没有特别兴奋。
AI 产品里多一个 slash command，很容易让人觉得只是又加了一个入口。就像 /help、/resume、/model 一样，看上去是功能菜单里的一个新按钮。
后来把 Claude Code、Codex、Managed Agents、Hermes 放在一起看，我才意识到它不只是入口变化。
这些产品都在尝试把一类责任从用户手里拿出来，交给系统维护。
这类责任可以叫“持续推进”。
以前，持续推进靠用户。Agent 做完一步以后，用户判断下一步是什么，用户决定要不要继续，用户看结果是否满意。
Goal-driven 之后，用户的工作开始前移。用户不再只是给当前这一轮输入，而是要把目标、边界、完成标准讲清楚。
比如同样是修测试，普通说法可能只是“帮我修一下 auth 相关测试”。这句话能启动 Agent，但它没有告诉系统什么时候该停。它可能修一个测试就回来汇报，也可能改一堆东西，最后说“我认为已经好了”。
更像 goal 的说法会具体很多：
修复 tests/auth 下所有 failing tests。验收标准是 pytest tests/auth 退出码为 0。不要修改 public API。如果需要改数据库 schema，先停下来问我。这句话里有目标，有验收方式，有边界，也有升级条件。它更像一个小型任务单。
你把任务单交给一个人时，不会每五分钟站起来说一次“继续”。你会说明最终要什么，哪些地方不能碰，什么时候需要你拍板。对方会自己推进，卡住了再回来找你。
Goal-driven Agent 想搬进 AI 产品里的，正是这种工作方式。
系统不再只处理单轮消息，而要维护一个跨轮次的目标状态。普通聊天关心这一轮怎么回答，goal mode 关心这件事怎么走到完成。
不过 /goal 也不是凭空冒出来的。它更像是 Agent 产品一路演进到某个阶段之后，自然长出来的东西。
从 plan 到 task，再到 goal
把这条线拉长一点看，Agent 产品其实一直在往前走。
最早大家关心的是 plan。
你给 AI 一个复杂问题，它先别急着动手，先拆一下：
第一步看需求。第二步读代码。第三步找相关测试。第四步修改实现。第五步跑测试。Plan 的出现很重要。它让 Agent 不再像无头苍蝇一样直接开干，至少先把路径想一遍。
但 plan 有一个问题：它更像“想法”，不是“工作”。
计划写得再漂亮，也不代表事情真的推进了。人类公司里也一样，PPT 里排了十个阶段，不等于项目已经走到第三阶段。Plan 解决的是“看起来怎么做”，还没有解决“谁来做、做到哪里、怎么验收”。
于是下一步，产品开始更强调 task。
Task 比 plan 更具体。它不只是“我要怎么做”，而是“现在有一件事要被执行”。比如：
修复 auth 测试。整理用户反馈。生成竞品分析。实现 PRD 里的登录页原型。Task 的好处是，它开始像工作单元了。你可以派发，可以排队，可以放进 session，可以记录状态，也可以交给不同的 agent 或 subagent。
但 task 也有自己的缺口。
很多 task 会变成“一次性执行”。Agent 做一轮，给你一个结果，然后停下来。它可能完成了，也可能只完成了一半。它可能说自己完成了，但你还得自己判断有没有真的达到标准。
这也是为什么 task 往后会自然长出 goal。
Goal 不是简单地把 task 换个名字。
Task 更像：
去做这件事。Goal 更像：
持续做这件事，直到满足这个完成条件。这中间多出来的东西，就是完成条件、持续状态和验收循环。
比如“整理用户反馈”是一个 task。
但下面这句话更像 goal：
整理最近 200 条用户反馈，按问题类型归因。最终输出一份产品评审用的 Markdown 文档。每个问题类型至少包含 2 条原始反馈证据和一个可落地建议。如果反馈信息不足，就标记为“证据不足”，不要强行下结论。你会发现，goal 里不仅有要做什么，还有最终产物是什么、证据够不够、什么时候不能继续硬编。
所以我现在更愿意把这三层连在一起看。
Plan 解决的是拆解。Task 让事情变成一个可以被执行、被记录、被派发的工作单元。到了 goal 这一层，系统才开始关心另一件事：这件事要持续推进到什么状态，才算真的可以停。
这不是三个互相替代的东西。
一个成熟的 Agent 产品，很可能三层都需要。Plan 帮它想清楚路径，task 帮它组织工作单元，goal 帮它维持方向和停止条件。
过去很多 Agent 产品停在 plan 或 task，就会出现一种熟悉的尴尬：它很会分析，也能做一点事，但你仍然要在旁边盯着，判断下一步、判断有没有完成、判断要不要继续。
Goal-driven Agent 往前补的，正是这块空白。
说到这里，问题就会落到一个很具体的地方：目标怎么写，才真的能被完成？
难点其实在“什么叫完成”
讲 goal mode 的时候，人很容易把注意力放在 “goal” 这个词上。
我现在更在意另一个词：完成。
人类在工作里经常会说一些很含糊的目标。比如“优化一下产品”“做个竞品分析”“帮我整理一下资料”“把这个页面改好一点”。
这些话在日常沟通里可以用，因为人会自动补上下文。你知道老板最近在焦虑转化率，你知道这个竞品分析是给下周评审用的，你知道“改好一点”其实是指首屏信息太散、按钮不明显、用户看不懂下一步。
Agent 不知道。
或者说，它可能猜得到一些，但它不应该靠猜来完成长任务。
如果你对 Agent 说：“帮我优化 onboarding。”这句话听起来像一个目标，其实更像一个愿望。它没有说明优化哪一段，没有说明目标用户是谁，没有说明最终产物是什么，也没有说明怎么判断好坏。
换一种说法，任务就立刻变得不一样：
分析当前 onboarding 流程，找出 3 个最可能影响激活率的断点。每个断点需要包含：用户行为证据、可能原因、一个可落地改进方案。最后输出一份适合产品评审使用的 Markdown 文档。不要直接改代码，先只做分析和方案。这个目标依然不完美，但它能工作。
Agent 知道自己要找几个问题，知道每个问题要包含什么，知道最终输出是什么格式，也知道这次不要直接动代码。
completion condition 的价值就在这里。它把“我想要更好”变成“做到这些点，就算这一轮可以交付”。
我觉得未来好的 Agent 产品，可能会越来越像一个会追问的任务助理。用户说“帮我优化一下”，它不会立刻开干，而是先问几句：
“你希望最后拿到什么？文档、PR、表格，还是一组改动建议？”
“这次成功的标准是什么？测试通过、指标提升、评审可用，还是只是先形成方案？”
“哪些地方不能碰？哪些动作需要你确认？”
这些问题看着不酷，甚至有点烦。但它们很重要。很多 Agent 任务失败，并不是模型不会做，而是任务从一开始就没有被定义成一个能完成的任务。它还停留在“愿望”的状态。
evaluator 像一个小小的验收员
Goal-driven Agent 里面还有一个很关键的角色：evaluator。
如果翻译得朴素一点，它就是验收员。
为什么需要验收员？因为一旦你希望 Agent 自己往前推进，就不能再默认用户一直坐在旁边盯着。以前在 Chat 模式里，用户天然就是 evaluator。Agent 做完一步，用户看一眼，说“可以”“不对”“继续”“重来”。
可 goal mode 不能一直依赖人来做这件事。
系统需要自己问一句：这个目标真的完成了吗？
evaluator 负责接住这件事。
你可以把一个 goal-driven 系统想成一个很小的团队。主 Agent 像做事的人，负责读文件、查资料、写代码、整理文档、调用工具。Evaluator 像看结果的人，负责检查这件事离目标还有多远。Rubric 像验收标准，告诉 evaluator 应该看哪些点。
比如让 Agent 做一个 DCF 模型。如果没有 evaluator，主 Agent 可能生成一个 Excel，然后告诉你“我完成了”。但完成了吗？不好说。
一个稍微靠谱的验收标准，至少会检查这些东西：
- 有没有 5 年收入预测- 有没有毛利率和运营利润假设- 有没有 WACC- 有没有 terminal value- 有没有 sensitivity analysis- Excel 文件是否能打开- 关键假设是否写清楚Evaluator 不一定比主 Agent 更聪明。它的价值在于站在另一个位置上。
写方案的人很容易觉得“差不多了”。看方案的人会发现“这里还缺证据”“这个表打不开”“这个结论没有对应假设”“你说做完了，但验收标准里第三条没满足”。
goal mode 不能只是“让 Agent 多循环几次”。
如果没有 evaluator，多循环几次只是让它更忙。它可能忙着忙着就偏了，也可能把同一个问题解释三遍，还自以为在推进。
有效的循环更像这样：
主 Agent 做一轮。
Evaluator 对照目标检查一轮。
如果没完成，系统把“还差什么”反馈给主 Agent。
主 Agent 再补一轮。
这个过程听起来简单，其实已经不像聊天机器人了。它开始有点像一个最小化的组织：有人执行，有人验收，有标准，有反馈，有下一轮。
我觉得 goal-driven 有意思的地方不在“模型突然变神”，而在系统里开始分出角色。
不要把自主理解成放飞自我
这里最容易被讲得太兴奋：用户设置一个目标，AI 自己跑，自己修，自己交付，听起来像未来已经到了。
真做产品的话，风险也藏在这里。
Goal-driven Agent 不是让 AI 想跑多久跑多久。一个成熟的 goal mode，一定要有边界。
它要知道最多跑多少轮，最多花多少钱，哪些工具调用必须审批，哪些文件不能碰，哪些环境不能进，多久没有进展就算卡住，失败以后能不能恢复现场，暂停以后能不能继续。
这些东西不酷，也不好写进宣传页，却决定了用户敢不敢真的把任务交出去。
想象一下，你让 Agent “整理一下我这周的会议纪要，生成一份项目状态报告”。它可以访问本地文件、邮件、日历、Slack。如果没有权限边界，它可能读到不该读的内容。如果没有成本边界，它可能为了一个报告跑半小时。如果没有审计日志，你不知道它引用了哪些信息。如果没有完成判断，它可能输出一份漂亮但缺关键风险的报告。
这时候，重点不是“AI 有没有自主性”，而是这份自主性有没有被装进一个可靠的框里。
所以我现在看 goal mode，会特别关注它背后的 Runtime 能力。
有没有 session，能不能记住这次任务的上下文。
有没有 checkpoint，跑坏了能不能回到某个阶段。
有没有 permission，高风险动作能不能停下来问人。
有没有 event log，出了问题能不能知道它做过什么。
有没有 pause / resume，用户中途打断后能不能接着干。
有没有 evaluator 的理由，系统说“完成了”时能不能解释为什么。
这些听起来像工程细节，落到产品里就是信任感。没有 Runtime 的 goal mode，很容易变成一个漂亮但危险的按钮。
也正因为这样，goal mode 在不同产品里的形态会很不一样。代码仓库里的 goal，和消息平台、定时任务里的 goal，不会长成同一种东西。
离开代码仓库以后，goal 还成立吗？
先看最容易理解的场景：代码仓库。
如果只看 Claude Code 和 Codex，goal mode 很容易被理解成一个编程工具功能。
这也合理。工程任务确实很适合 goal。测试过没过，构建成没成功，lint 有没有报错，类型检查有没有通过，PR diff 是否合理，这些都是比较天然的验收信号。
你可以对 Claude Code 或 Codex 说：
修复 auth 模块所有 failing tests。验收标准是 pytest tests/auth 全部通过。不要改 public API。如果需要改 schema，先问我。这个 goal 很舒服。它清楚，可验证，也有边界。Agent 做得怎么样，用户不用完全凭感觉判断，测试结果会给一个很硬的反馈。
问题也在这里：如果 goal mode 只在代码仓库里成立，那它就只是 coding agent 的一个高级功能。
我最近看 Hermes 时，被提醒到的是另一件事：很多非编程场景，其实也有同样的“别让我一直说继续”的需求，只是验收信号没有测试那么硬。
Hermes 不是 Claude Code 那样的纯 coding agent。它更像一个通用 Agent Runtime：有 CLI/TUI，有 Gateway，有 Telegram、Slack、Discord、Webhook 这类消息入口，也有 Cron、Plugin、Memory、Skills、Subagent、多模型 provider。
这时候问题就变了。
它不再只是：
Agent 能不能把一个代码任务做完？而是：
Agent 出现在不同入口、不同平台、不同触发方式里时，还能不能持续记住自己要完成什么？这句话稍微抽象，换几个场景就好理解了。
你在 Telegram 里丢给 Agent 一个研究任务：“这周帮我持续跟进某个开源项目的关键更新，周五给我一份摘要。”
你让它通过 Cron 每天醒来检查一个信息源，发现重大变化就补充到同一份文档里。
你让它在 Slack 里处理一批用户反馈，按问题类型归因，最后生成一份产品评审材料。
你让它通过 Webhook 接收外部事件，然后持续更新某个项目状态。
这些都不是典型 coding 任务，但它们都有同一个麻烦：用户不可能一直坐在那里看着它。你不会在 Telegram 里每半小时说一次“继续跟进”，也不会每天早上手动提醒它“再看一下那个信息源”。
你真正想要的是，把目标挂在那里。
它记得目标，知道下一步，知道什么时候继续，也知道什么时候该停下来找你。
Hermes 这条线的意义就在这里。它不是要证明自己比 Claude Code 更会写代码，而是把 goal mode 从“代码仓库里的长任务”推到了“多入口 runtime 里的持续目标状态”。
Claude Code / Codex 让 goal mode 在工程任务里变得可信。
Hermes 让人看到，goal mode 也许可以变成通用 Agent Runtime 的一层能力。
这层能力像一根线，把用户意图、工具调用、记忆、会话、定时任务和最终交付串起来。没有这根线，通用 Agent 很容易变成“哪里都能聊两句，但哪里都做不深”。有了这根线，它才有机会从多入口聊天机器人，变成多场景任务执行体。
放到 OpenClaw 和 Desk 这种产品上，问题会更具体。
OpenClaw 更像 personal AI / local-first assistant，强调本地控制、自动化、heartbeat、queue、follow-up。这些能力很有用，解决的是“什么时候醒来”“什么时候继续看一眼”“什么时候提醒用户”。
但“定时回来”不等于“知道什么时候完成”。
一个 Agent 可以每天都醒来，每天都报告一段进展，但始终没有真正收敛到交付。它有 automation，却不一定有 goal。
所以如果 OpenClaw 要往更强的 goal-driven 走，关键不是再多一个提醒入口，而是补上 completion condition、evaluator、自推进循环，以及更清楚的停止逻辑。
Desk 类产品也会遇到类似选择。
如果 Desk 只是聊天入口，它最后可能变成一个更漂亮的 ChatGPT。
如果它只做 coding agent，它会很强，但场景会被工程任务限制。
如果它只强调通用 runtime，又可能太灵活，普通用户不知道怎么用。
我现在更倾向的方向是：Desk 应该是 workflow-first 的目标执行产品。
表面上，它不用一直强调“我是 runtime”。用户也不关心 runtime 这个词。用户关心的是：我把一件事交给你，你能不能接住，能不能推进，能不能在该停的时候停下来，能不能告诉我结果为什么可信。
底层当然要有 runtime。它不一定只服务编程，但应该学会 coding agent 那套可验证、可恢复、可审计、可暂停、可继续的执行能力。
到这个时候，用户打开 Desk，不只是问：
你能帮我做什么？更像是在说：
这是我的目标。这是验收标准。你去推进。卡住再叫我。到这一步，Desk 才不只是聊天窗口，而开始像一个任务系统。
最后，下一阶段的关键是 goal
绕了一圈，其实还是回到开头那个很小的体验：我们不想一直对 Agent 说“继续”。
这不是懒。
这是因为我们交给 AI 的东西，正在从一句话、一个问题、一个临时动作，变成一段需要持续推进的工作。
如果只是问答，chat 就够了；如果只是调用外部能力，tool use 就够了；如果只是先想清楚路径，plan 也够用。
可一旦你交给它的不是一句问题，而是“请你做到一个结果”，核心问题就变成了 goal：
它能不能拿住一个目标，持续往前推，并且知道什么时候真的完成？goal mode 真正要回答的，就是这个问题。
这问题看着简单，真要做进产品里，就会牵出一堆基础设施：目标定义、完成条件、evaluator、iteration loop、session、checkpoint、权限、审计、pause / resume，还有关键时刻把控制权还给人。
所以我不太想把 goal mode 看成一个新按钮。它更像 Agent 产品的一次重心迁移。
从这个角度看，plan、task、goal 不是三个时髦词，而是一层层把 Agent 往“能交付”推。Plan 让它别乱撞，task 让事情有了工作单元，goal 则让系统开始围绕结果持续推进，并且在推进中不断问：还差什么，能不能停，是否需要人接管。
再往后，Runtime 决定它能不能安全地、可恢复地、可解释地推进。Hermes 这类通用 runtime 的意义也在这里：当 Agent 不只待在代码仓库，而是进入消息平台、定时任务、插件系统和更多工作流时，它更需要一根能把目标挂住的线。
下一阶段真正拉开差距的，不是 Agent 会不会聊天，也不只是会不会用工具，而是它能不能管理一个目标的生命周期。一个 goal 从被写下来开始，就要经历定义、拆解、推进、验收。中间遇到权限、成本、信息不足、风险变高这些情况时，系统还得知道什么时候停下来，而不是一路硬跑。
所以我会把“能不能拿住目标”看得很重。只会回答问题的产品，当然也有价值，但它还停在助手阶段；能持续推进、能验收、能在该停的时候停下来，才开始接近执行体。
也许未来某一天，我们打开一个 Agent 产品，第一句话会更接近：
这是我要的结果。你先去做。做不到的时候，再回来找我。这才是我觉得 Goal-driven Agent 最有意思的地方。
它不是让 AI 看起来更忙，也不是让 AI 无限自主。
它是在重新分配人和系统之间的责任：人定义目标、边界和验收标准，系统负责推进、检查、续航，并在该停的时候停下来。
AI 不再只是等你说“继续”。
它开始学着问：
目标是什么？什么算完成？我做到哪里，才算真的交付？
