Plan 和 Task 的消亡

最近 Codex 和 Claude Code 都在做一件有意思的事：给 Agent 做减法。

2026 年 8 月 31 日，Codex 合并了一个标题很直接的 PR：Make the update_plan tool opt-in。update_plan 默认关闭，用户可以主动开启。这个改动不只是隐藏一个工具，还清理了模型指令、协作模式、上下文压缩和 Goal 续跑提示中，要求模型使用它的配套指导。[1]

这件事可以说得比“Codex 不搞 TODO 了”更准确一点。Codex 在当前源码里直接把 update_plan 定义为 TODO/checklist/progress 工具，主分支也有一项名为 code_mode_does_not_expose_update_plan_by_default 的测试：默认 Code Mode 中，它既不能调用，也不会出现在可用工具列表里。需要时，仍可以通过 tools.update_plan.enabled = true 显式启用。[13]

所以，Codex 默认路径确实不再要求模型维护一张自用的待办清单；但这不是把待办能力从产品里彻底删除。更像是把它从默认工作法降为一个可选的辅助工具。

同样，Codex 并没有因此放弃规划。官方当前仍建议：复杂或含糊的任务可以进入 Plan mode，由模型先查上下文、追问和组织方案；更长的工作可以使用 PLANS.md 一类持久计划文档。[14] 现在更清楚的结构是：Plan mode 用来把人的意图和取舍说清，update_plan 是可选的模型侧清单，Goal 则保存跨 turn 的完成条件与续跑状态。

Claude Code 也调整了任务跟踪工具的默认可用性。在较新的模型上，TodoWrite 和 TaskCreate、TaskGet、TaskUpdate、TaskList 不再默认提供。官方文档给出的解释相当明确：这些模型可以在没有书面清单的情况下跟踪多步工作，而工具定义和提醒本身会占用上下文。[2]

与此同时，Claude Code 团队成员 Thariq 开始公开讨论 Plan mode 是否还有必要，甚至考虑把 Shift+Tab 留给 effort 调节。收到反馈后，他又提出将 Plan mode 做成可定制的内置 mod，让用户自行选择和扩展工作模式。这里仍然是产品方向的讨论，不是已经完成的移除；截至 9 月 29 日，官方文档依然保留 Plan mode。X 的相关表态可以从公开原文存档中看到。[3]

所以，严格来说，不能把这些变化概括成“两个产品都取消了规划模式”。工具、模式和规划能力是不同的东西。

但我觉得，更值得关注的恰恰不是某个按钮还在不在。

一种曾经被我们视为 Agent 标准配置的东西，正在失去默认存在的理由。

以前我们问：怎么给模型配一个更好的 Planner、更完整的任务系统？

现在的问题开始变成：模型已经能自己组织工作了，我们为什么还在要求它维护这些东西？

我们曾经给模型制定了一套工作纪律

先说清楚这里的 harness：它是模型周围那层程序，负责提供工具、组织上下文、推进执行、保存状态和控制权限。

当模型不能稳定完成复杂任务时，在 harness 里增加一些做事方法是很自然的选择。

不会拆任务，就要求先写 Plan；执行时容易漏项，就提供 TODO；多个 Agent 不知道怎么配合，就增加 Task 和依赖关系；中途停下来，就反复提醒它继续。

这些设计并不愚蠢。它们是在当时的能力条件下，给模型补上一部分缺失的工作习惯。

Anthropic 的复盘就描述过这段历史：早期 Claude Code 提供 TodoWrite，让模型写下待办事项并逐项勾选，但模型仍然会忘记工作，于是他们每隔五个 turn 插入一次提醒。后来，随着模型变强，提醒反而产生了副作用：模型觉得自己应该坚持清单，即使已经发现需要改变方向。团队随后把重点从单 Agent 的 TODO，转向支持共享状态和依赖关系的 Task。[4]

但 Task 也没有因此获得永久席位。现在，更强模型上的这套任务跟踪工具，也开始默认退出。

这件事让我重新审视了一个问题：我们到底是在设计一个长期成立的 Agent 架构，还是在把某一代模型的缺点写成产品功能？

看 Codex 的 update_plan，这种感觉尤其明显。模型提交步骤与状态，handler 解析参数，发出 PlanUpdate 事件，再返回成功。它没有执行清单里的工作，也没有检查被标记为完成的事项是否真的完成。

它当然有价值。清单可以压缩信息、提醒遗漏，也可以让人知道大致进展。但如果模型已经能从用户要求、执行记录和当前环境中判断下一步，那么维护清单就成了额外的一份工作。

模型要一边做事，一边维护一份“我正在做什么”的描述。

如果这份描述还能改善执行，值得保留；如果它只是让界面显得井然有序，就需要重新算账。

模型学会的，不只是执行计划

我觉得，真正重要的能力变化，不是模型更会照着计划执行了，而是它开始更会判断：什么时候需要计划，应该计划到什么程度，以及什么时候应该推翻计划。

这几件事，远比生成一张清单难。

假设一个模型接到修复问题的任务，最初认为需要重构三个模块，于是列出了完整步骤。读完代码后，它发现问题只来自一个边界条件。

这时，好的执行应该是放弃原来的重构方案，而不是为了完成已经写下的计划，把三个模块都改一遍。

如果我们在外部反复强调“按计划执行”“完成一步更新一步”“不要遗漏任何任务”，就可能把原本应该服从事实的计划，变成模型需要服从的另一套指令。

计划应该是当前最好的猜测，不应该变成任务本身。

这里并不是说模型从此拥有了无限记忆。Codex 的 agent loop 仍把上下文管理视为 harness 的职责，并在上下文接近限额时自动压缩对话；关闭 TODO 不代表这些信息不再存在，只是不再默认要求模型通过专用工具反复维护一张清单。[11]

不过，如果只把这次变化理解成“换一种方式记忆”，还是低估了它。

更深一层的变化是：组织工作的能力，正在从 harness 的显式流程，转移到模型执行时的判断。

面对同等难度的任务，模型越强，外部流程提供的边际收益就越可能下降。到某个时候，模型不但不需要别人替它拆步骤，还可能比我们预先写好的步骤更适应现场情况。

当然，任务难度不会永远不变。模型能轻松处理一个功能后，我们很可能立刻让它迁移整个系统。接近能力边界时，计划和外部记录仍然可能有价值。OpenAI 自己的 harness 工程实践中，就同时保留了轻量临时计划和用于复杂工作的持久执行计划。[5]

所以，我说的“消亡”，不是所有计划文档从此都该删除。

它更像是默认地位的消失：不再假定每项工作都必须先进入规划模式，也不再假定每个 Agent 都必须维护一套任务账本。

删掉规划工具，不等于删掉人的决策入口

讨论 Plan mode 时，有一个问题很容易被混过去。

模型可能不需要 Plan mode，但人可能需要一个“先别动手，和我讨论”的入口。

我想先确定数据模型，再决定是否实施；我不确定两个方案的取舍，希望先看一个原型；我只授权调查，不授权修改。这些需求，都不能因为模型更聪明而被自动取消。

这里有一个很有价值的区分：帮助模型获得足够精确的执行指令，和帮助人理解自己正在构建什么，是两种不同的需求。前一种会随着模型进步而减弱，后一种仍然重要；但一份越来越长的计划文档，未必是好的解决办法。

我认同这个区分。

我们不一定需要让用户阅读模型接下来准备改哪些文件、按什么顺序调用工具。更值得让用户看到的，可能是三个真正影响结果的选择：是否改变原有交互，是否引入新的依赖，是否接受某种性能与复杂度之间的交换。

这些内容可以通过原型、差异对比、关键决策说明来表达，不必全部装进一篇名为 Plan 的长文。

还有一个经常被低估的入口：人怎样审阅模型已经做出来的东西。

模型生成一张网页、一份文档或一段可运行的功能后，用户不该只剩下“接受”或“重做”两个按钮。更自然的状态是能在具体位置留下评论、圈出不满意的部分、说清“这里想要更像另一个例子”，或者把一个尚未决定的问题标出来，交回给模型继续处理。

这类反馈最有价值的地方，不是让人替模型逐步写指令，而是把人的判断重新绑定到真实产物上。比起在对话框里补一句“第二屏不够清楚”，对着第二屏留下批注、连同上下文和修改意图一起交回去，模型更不容易猜错。对代码也是一样：差异、运行结果、测试失败和一句有位置的评论，往往比一段泛泛的返工要求更有用。

人提出的要求里，还有不少东西一开始就是没想清楚的。好的 harness 不该假装一份 Plan 可以替人把问题想明白；它应该帮人把模糊处摊开：给出几个可比较的原型，指出不同选择会影响什么，记录已经作出的决定，也保留还没决定的地方。对话在这里不是进度播报，而是把“我大概想要这样”慢慢变成可判断、可验收的东西。

Task 也是一样。模型内部的任务清单，与组织里的工作项，并不是同一层东西。一个客户请求归谁处理、交付了什么、谁验收，仍然需要共享记录；但这不意味着执行它的模型必须把每一个思考步骤，也同步到这份记录里。

减少认知上的辅助，不应该顺手把协作和授权机制也删掉。

对正在做 Agent 产品的人，我觉得最实际的做法，不是看见趋势就立即把所有 Plan、Task 关闭，而是重新审查它们各自在解决什么问题。

用于补偿模型能力不足的部分，应该随模型升级重新测试；用于表达真实业务约束、共享承诺和权限边界的部分，则需要留下可靠的实现。

否则，我们只是从“所有任务都要规划”的教条，换成了“所有任务都不准规划”的教条。

现代模型的 Prompt，正在从操作手册变成任务说明

这件事也在改变 Prompt 的写法。

Anthropic 在 7 月的一篇文章里披露，针对更先进的模型，他们移除了 Claude Code 超过 80% 的 system prompt，在其编码评测上没有观察到可测量的性能损失。他们发现，system prompt、Skills 和项目指令里存在大量重复、冲突或过度约束。这个结果有明确的模型与评测范围，不能直接推广到所有 Agent，但已经足以说明：旧提示词并不会因为积累得久，就自动更有价值。[6]

我现在更倾向于把 Prompt 的工作理解成：补充模型不知道的信息，定义我们在意的结果，而不是尽可能详细地规定它怎么思考。

把要求写在结果上，不要写满执行姿势

例如，下面这种指令看起来很严谨：

1
2
3

先完整分析问题，再写出详细计划。
将计划拆成 Task，每完成一项更新状态。
严格按照计划实施，最后进行检查。

但它几乎没有告诉模型，这个任务究竟哪里重要。

相比之下，我更愿意给出这样的任务说明：

1
2
3
4
5
6
7
8
9
10
11
12
13

修复移动端编辑器在软键盘展开时遮挡发送按钮的问题。

复现材料和相关组件已附上。

验收要求：
键盘展开与收起时都能正常发送；已有草稿不能丢失；
桌面端交互不能退化。

约束：
不修改服务端接口，不引入新的 UI 框架。

交付修改和验证结果。缺少设备条件时，明确列出未验证项。
实现路径自行决定；涉及交互语义变化时，先说明取舍。

后者甚至可能更长，但多出来的内容是任务信息，而不是管理模型的口令。

OpenAI 的推理模型提示指南也明确建议使用直接、清晰的要求，不必默认附加“逐步思考”式提示；同时，目标、约束与成功标准仍然应该具体。[7]

这里需要区分：不强迫模型展示某种思考过程，不等于不要求它提供可检查的解释、计算、测试或证据。后者是交付内容，前者是对内部做事方式的规定。

告诉它这里有什么特殊之处

项目指令最值得保存的，往往不是“代码要简洁”“注意边界条件”，而是模型无法从常识里知道的事情。

某个接口看起来奇怪，是因为外部客户依赖它；某张表的数据不完整，不能用于统计口径；一个模块有两种实现，但只有其中一种仍在使用。这些信息能真正改变判断。

Anthropic 对项目指令的建议也在向这个方向移动：保持入口轻量，把篇幅留给代码库特有的注意事项，并让详细知识按需加载，而不是把所有实践一次性塞进上下文。[8]

我的理解是，少教它常识，多告诉它现场。

这不意味着知识越少越好，而是应该让知识有来源、有适用范围，也有被重新发现的路径。一个可以查阅的事实库，通常比一篇混合了规则、历史、习惯和情绪的巨型提示词更容易维护。

用参考物缩小误解，而不是靠形容词增加信心

“做得专业一点”“像一个成熟产品”“不要太复杂”，都能表达倾向，却不能充分定义结果。

参考实现、可交互原型、真实输入输出、失败样例和验收测试，往往能暴露文字没有说清的部分。Anthropic 的现代模型使用指南也强调，通过参考物、原型和有针对性的追问，在实施前后逐步发现未知条件，而不是假定一次规划就能消除全部歧义。[8]

不过，参考物也要说明参考什么。

给一份旧代码作为行为参考，不等于让模型复制里面的全部架构；给一个页面作为视觉参考，不等于接受它的交互。否则，我们只是把模糊性从文字搬到了附件里。

Few-shot 也没有失效。需要精确格式、特殊分类口径或团队独有判断时，例子仍然有用。只是可以先尝试直接说明要求，再针对实际失败补例子，而不是默认堆满示范。[8]

调整投入，而不是不断提高命令的音量

“务必深入”“必须全面”“再仔细十遍”，很容易写，也很难知道到底有没有产生预期作用。

在提供 effort 控制的模型里，可以更直接地试验不同计算投入。Thariq 最近的公开实验就区分了两类场景：快速迭代原型时，较低 effort 有助于尽早获得反馈；边界条件多、验证要求高时，更高 effort 往往更有价值。他也观察到，更高投入不一定修复错误的理解方向。[9]

这意味着，“认真做”不是一个足够完整的配置。

有时缺的是计算，有时缺的是事实，有时缺的是用户尚未作出的决定。让模型再想一会儿，不能替代把这三种情况分开。

归根结底，现代 Prompt 的技巧可能正在变得不那么像技巧：明确目的，提供现场信息，给出高质量参考，说明边界，然后通过结果修正理解。

真正困难的部分，开始从“怎样说才能让模型听话”，转向“我到底有没有说清自己要什么”。

能写成检查的，就别只写在提示词里

这里还有一个工程上的分界。对于“不要改这个接口”“不能泄露这个字段”“页面必须通过无障碍检查”这类约束，反复在自然语言里提醒模型，通常不是最可靠的办法。

如果一条要求可以落到 lint、类型检查、测试、schema、权限策略或发布门禁里，就应该尽量放进去。模型可以参与写这些检查，也可以根据失败结果修复实现；但检查本身不该只存在于一段容易被上下文淹没的提示词里。语言适合说明目标、背景和取舍，硬约束更适合变成可执行的证据。

那下一个消亡的，会不会是 Goal？

顺着这个逻辑继续往下想，Goal 也不应该被豁免。

现在，从 Plan 转向 Goal，看起来非常合理。既然模型可以决定怎么做，harness 就只负责告诉它要达到什么结果。

从当前开源代码看，Codex 的 Goal 扩展比 TODO 多了一层实际执行语义：它会读取持久化目标，检查状态与续跑条件，再在空闲时请求启动下一轮。它不是单纯展示一段文字，而是在管理跨 turn 的继续执行。官方对 Goal 的描述也把它定义为线程范围内的完成契约：目标、生命周期、预算、续跑条件与基于证据的完成判断，都被保存在同一个线程里。[10][15]

Goal 的续跑模板也说得很直白：不要把目标缩小成更容易完成的部分，不能把状态重述当进展，完成前应检查当前事实与证据。这些内容在试图修复长期执行中的目标漂移和过早停止。[10]

但问题来了。

如果下一代模型已经能稳定保持目标、判断进展、处理阻塞、决定何时结束，那么这些反复提醒它“不要停”“不要忘记目标”的指令，会不会和今天的 TODO 提醒一样，逐渐变得多余？

我觉得，很有可能。

如果 Goal 的价值只是督促模型继续工作，它同样是一种能力补偿。

更进一步，显式的 Goal 工具也未必需要始终暴露给模型。用户已经提出了要求，系统也已经保存了要求，为什么模型还必须再调用一次工具，把这段话登记成 Goal？这种登记是否产生了新的系统语义，还是仅仅换了个地方重复一遍？

当然，Goal 里面还有另一类东西：预算、暂停、恢复、目标变更、完成状态，以及谁有权接受结果。

这些不是模型多聪明就能凭空解决的。模型知道应该停止花钱，不等于系统已经限制了支出；模型理解用户撤销授权，不等于一个正在运行的外部任务已经被取消。

所以，我更倾向于预测：**Goal 作为提醒机制可能消退，作为执行契约的部分可能下沉到运行时。**这是对未来架构的推测，不是现有产品已经宣布的路线。

用户未必需要维护一个 Goal 表单，模型也未必需要频繁调用 update_goal，但系统仍然需要知道：它接受了什么工作，边界是什么，现在发生了什么。

还有一个不能跳过的问题：谁来宣布完成？

不过，Goal 的完成状态本身仍是一种声明，不是独立验收的替身。当前实现对状态与使用量有自己的处理，但“目标是否真的完成”仍要靠任务证据、验证，以及系统外的判断来支撑。[10]

我们不能因为从 TODO 换成了 Goal，就假定完成问题已经解决。

否则，只是从“所有任务都打勾了”，换成“目标状态变绿了”。

下一代 harness，应该把力气花在哪里？

我不觉得答案是把所有东西删掉，只留一个模型和 Bash。

真正值得讨论的是：哪些东西应该继续由模型决定，哪些东西必须由系统承担。

先让模型更容易接触真实工作。与其不断提醒它“正确”，不如让它读到相关代码、数据、需求和历史决定，能运行环境，能看见产物，也能拿到明确的执行结果。OpenAI 的 harness 工程文章提出过一个很具体的原则：关键不变量由系统机械地执行，而不是靠提示词微观规定实现方式。[5]

执行可靠性也要留在模型之外。一次动作到底有没有执行，失败后能不能重试，会不会重复发送，预算是否耗尽，权限是否仍然有效，都需要有可追踪的状态。模型可以自由选择路径，但系统不能因为它说“应该没问题”，就把一个没有回执的操作当成成功。

对人来说，重点不是审阅每次搜索，也不是盯着一张不断变化的 TODO。真正值得把人拉进来的，是目标理解开始分岔、关键取舍尚未决定、操作要跨过授权边界，或者结果无法通过现有标准验收。届时，原型、差异对比、可评论的网页和文档、带来源的结果，比几十轮进度汇报更有帮助。

我还期待 harness 有一点“自我总结”的能力。它可以观察哪些默认工具、提示词规则或固定阶段反复被跳过，哪些检查真正拦住了问题，再把这些观察整理成下一轮实验。模型升级后，系统可以尝试删掉一条规则、一个默认工具或一个固定阶段，然后看真实任务是否变差。

这件事听起来确实有点玄。它不能变成“Agent 自己改自己的规则，然后自己宣布变好了”的闭环。更可靠的做法是把改变放在受控实验里，用代表性任务、独立评分和保留测试集判断效果；Anthropic 关于自动评测的文章也强调了这些基础工作。[12] 只有在结果没有变差，或者确实更好时，机制才值得留下。否则，harness 只是越来越会适应自己造出来的样例。

这也意味着，验收器不会成为新的万能答案。验收标准可能写错，测试可能覆盖不足，另一个模型也可能共享同样的误解。模型可以参与构建评测，但不应该在没有约束的情况下，同时决定目标、修改判定标准，再宣布自己已经成功。

方法可以自适应，承诺和判断依据不能悄悄跟着变。

Plan 和 Task 的退场，让我意识到，Agent 工程里有一种很容易被忽视的技术债：我们为旧模型设计的工作方法。

这些方法曾经有效，所以很容易被保留下来；后来又进入模板、Skills、项目规范和产品交互，逐渐变得像不可缺少的基础设施。

但模型升级以后，它们未必还是基础设施，也可能已经成为负担。

Goal 也可能经历同样的过程。今天我们用它解决过早停止和目标漂移，明天其中一部分可能被模型能力吸收，另一部分则变成用户根本不需要看见的运行时机制。

我更愿意把下一代 harness 的方向理解成：更少替模型规定做事方法，更可靠地连接人的意图、模型的行动与可审阅的结果。

至于最终还会留下几个工具、几种模式、多少显式对象，我觉得现在下结论还太早。

但有一个问题已经值得反复问了：

我们正在维护的这些流程，究竟是在解决真实工作的需要，还是只是在延续上一代模型留下的习惯？

参考资料

1. OpenAI Codex GitHub，Make the update_plan tool opt-in (#41744)，2026-08-31。
2. Anthropic，Track todos，Claude Agent SDK 文档。
3. Thariq Shihipar，关于 Plan mode、effort 与内置 mod 的讨论，2026-09-24。
4. Anthropic，Effective harnesses for long-running agents，2025-11-26。
5. OpenAI，Harness engineering: leveraging Codex in an agent-first world，2026-02-11。
6. Thariq Shihipar，The new rules of context engineering for Claude 5 models，2026-07-29。
7. OpenAI，GPT-5 prompting guide，开发者指南。
8. Anthropic，Effective context engineering for AI agents，2025-09-29。
9. Anthropic，Effort，Claude Platform 文档。
10. OpenAI Codex，Goal extension source，开源实现，访问于 2026-09-29。
11. OpenAI，Unrolling the Codex agent loop，2026-01-23。
12. Anthropic，Demystifying evals for AI agents，2026-01-09。
13. OpenAI Codex，code_mode_does_not_expose_update_plan_by_default，当前主分支源码快照，访问于 2026-09-29。
14. OpenAI，Codex best practices，Plan mode 与长任务规划说明，访问于 2026-09-29。
15. OpenAI，Using Goals in Codex，Goal 的线程状态、续跑与证据完成条件，访问于 2026-09-29。