为什么所有 Agent Harness 的原子单元都是 Task，而 Todo 永远成不了第一公民？ #411
Replies: 3 comments
|
续：把视界拉长——为什么长任务更是 Task 的天下，Todo 连牌桌都上不了 上一帖论证了原子单元为什么是 Task。这一帖专门讨论长任务（long-horizon）：那种要跨上下文压缩、跨会话重启、甚至跨「人类睡觉」的马拉松。结论先行：短任务里 Todo 输给 Task 是方法论问题；长任务里 Todo 输给 Task 是物理问题。 有四个长视界特有的压力，每一个都在把 Todo 往牌桌外推： 1. 上下文必死，Task 不朽。 长任务注定穿越上下文的死亡：压缩、截断、会话结束、进程重启、甚至模型换版本。住在上下文里的 todo 是脑状态，跟着上下文一起死；Task 是世界状态（worktree、账本、diff），死了可以复活——问一句「这个分支改了什么、测试过不过」，工作就能继续。真正的判据是可复活性（resurrectability）：todo 死了就是死了，task 死了还能被世界唤醒。有人会说 Manus 的 2. Todo 是开环控制，长视界必然发散。 控制论的老结论：开环控制器的误差随视界复利增长。清单写好一次之后就是盲走——而长视界里所有漂移源都在场：lost-in-the-middle、压缩摘要的失真、模型自身的分布漂移。Task 是闭环：每个单元的结束是一次测量（artifact、测试、报告），重新锚定一次状态估计。验证间隙随视界增长，所以 harness 必须把长视界切成短视界，给间隙设上界。openpi 的 workflow 甚至内置了 watchdog：每个子代理回合 45 秒内必须显示进展，否则中止——而 watchdog 只能挂在「有运行时身份的对象」上。 3. Todo 没有崩溃一致性。 长任务必然遭遇崩溃。todo 没有幂等键，崩溃后重跑要么重复执行、要么整段遗忘。Task 系统是数据库式的：openpi 的账本给每次调用记录「意图、准入、执行状态」，崩溃后未终结的调用恢复为 4. 只有 Task 可并行、可调度。 长任务才值得并行化。清单本质是一个长度为一的队列，只能顺序消费；Task 才能组成 DAG——openpi 的 产品层的证据也一致：所有做长工作/自主运行的产品，产品名词全是 Task 系——ChatGPT 的功能叫 Tasks，Codex 的云端运行叫 tasks，Devin 的一次工作叫 session/plan。没有一家把长工作的产品名词叫 Todo。 那么长任务的 Todo 到底该住哪？ 我的猜测：Todo 不应该有自己的存储——它应该是 Task 账本的只读投影。 单一事实来源在账本（意图/准入/执行状态），todo 只是人类可读的 留给社区的三个问题：
|
|
你這個問題我覺得關鍵在「能不能被排程」，Todo 其實可以靠驗收 hook 原地晉升成 task，但 truth-maker 只解決 done 能不能被檢查。要讓一條記錄變成 harness 的原子單元，它還得把 blockedBy / blocks 這種依賴邊寫成資料，claim 時檢查 blocker 完成沒、owner 有沒有被拿走。少了依賴圖跟認領規則，順序還是留在模型的上下文裡，跨 turn、重開、多人 worker 時就沒有可恢復的排程語義。 這些我用 Python 整理成一套教學，GitHub 上 800+ 星：https://github.com/hardness1020/awesome-agent-architecture |
|
2026-09-09 只读对照（未
OpenPI 继续： |
Uh oh!
There was an error while loading. Please reload this page.
openpi README 里有一句话把分工说得非常清楚：「Tasks 是咨询性记录，Goal 是持续目标，Subagent 与 Workflow 才执行工作」——以及「文件、Git、测试、Artifacts 和用户确认始终是事实来源」。
我想顺着这句话往下挖，因为同样的分工出现在每一个 SOTA harness 里，而且我不认为这是巧合。标题里的问题是认真的：为什么整个生态都收敛到以 Task 作为原子单元——而 Todo 无处不在却又处处被降级，永远只是个咨询性的草稿区？是否存在某种结构性原因，使得 harness 根本无法让 Todo 成为第一公民？
1. 调研
2026 年每一个严肃的 harness 都把同一种形态用了两遍，戴着两顶帽子。
Task 作为执行单元 — 拥有自己上下文、生命周期和产物的委派工作：
Task工具派生 subagent，每个都有隔离的上下文窗口，可并行运行，返回报告。Task（submitted → working → completed/failed，携带 artifacts）。连协议层选的都是 Task，而不是 Todo。explorer/implementer/reviewer/advisor）与 workflow（phase()/agent()/pipeline()/parallel()，账本会把崩溃的调用标记为uncertain而不是猜成功）。Task 作为记账单元 — 一张只「谈论」工作的清单：
TodoWrite— 明确定位为进度追踪器，不是调度器。update_plan— 步骤列表，同一时刻只能有一个in_progress，本质是「渲染给用户看」。todo.md，在上下文尾部不断重写。Manus 团队自己的说法："That's not just cute behavior — it's a deliberate mechanism to manipulate attention… By constantly rewriting the todo list, Manus is reciting its objectives into the end of the context."（这不只是可爱的行为——这是刻意操纵注意力的机制……通过不断重写 todo list，Manus 在把自己的目标背诵进上下文的末尾。）tasks_add/tasks_update— 「不推断完成、不执行工作」。Tasksubagent（独立上下文，可并行）TodoWrite清单update_plan步骤todo.mdTask（status + artifacts）tasks_*（咨询性），goal（证据审计）而唯一一个让 todo list 当引擎的系统——BabyAGI 的
while True循环（执行 agent → 创建任务 agent → 优先级排序 agent）——如今成了全领域设计时共同的反面教材。2. 第一性原理：四种压力，指向同一个方向
注意力是局域且稀缺的。 Todo 是一台和工作本身住在同一份工作记忆里的状态机。Manus 的 recitation（背诵）技巧就是一份自白：清单没有因果力——它必须被不停重写进近因窗口，因为任何没被背诵的东西在功能上等于被遗忘。Task 则是花钱买出路：每个单元一份全新上下文，状态活在世界里（worktree、账本、进程），而不是活在脑子里。随着任务视界变长，空间维度的序列化（每个单元新开一份记忆）胜过时间维度的序列化（在一份记忆里反复重申）。Append-only、KV-cache 友好的设计也把同一方向推了一把：用硬性的 task 边界，而不是对一张活清单做原地修改。
真值必须能被说话者以外的人检验。 Todo 的「done」是由从宣布完成中获益的那个系统自己宣布的——模型给自己批作业。Task 的「done」则绑定在说话者之外的 truth-maker 上：一个 diff、一个通过的测试、一份返回的报告、一个 artifact。把波普的可证伪性用到控制流上：harness 只能用可证伪的语句来搭建机器。openpi 自己的规则——文件、git、测试、artifacts 是事实来源，tasks 只是咨询——不是这个仓库的局限，而是 Todo 在任何地方都只能建议、不能驱动的最深层原因。
失败必须可隔离。 Task 有爆炸半径和恢复语义：重试、重生、上报——openpi 的账本甚至拒绝猜测，把被打断的调用标记为
uncertain。而失败的 todo 是静默失败的，无形中污染整个计划。BabyAGI 的任务增殖死亡螺旋，就是「清单即引擎」时静默失败的样子。训练分布是 Task 形状的。 RL 后训练按 task episode 结算奖励；benchmark 定义的就是 task；策略被优化的目标，就是完成带可验证终点的单元。当 harness 的控制单元与策略被优化的单元一致时，表现最好。没有任何梯度会为「维护一张清单」付钱——todo 维护至多是一种涌现的习惯。有用（Manus 证明了），但没有任何 harness 应该依赖它。
3. 哲学视角
延展心智，但被官僚化了。 Clark & Chalmers 的延展心智（extended mind）论说笔记本可以成为心智的一部分——harness 正是那个外置皮层。但注意外化采取的形式：是制度，而不是日记。Task 是韦伯意义上的官僚制对象：它建立记录、角色、审计轨迹。Todo 是一个私人意图。官僚制是让不可靠组件可靠地复合的方式；日记是个人记忆的方式。harness 不信任个体心智——所以拒绝把意图存放在里面。
Todo 没有受话人。 用言语行为理论（Austin / Searle）的话说，Task 是两方之间的承诺式（commissive）：它创造一项义务和一个受话人可以被问责的完成条件。Todo 是写给自己的指令——没有第二方，就没有问责，也就没有可供检验的对象。问责需要受话人；第一公民原语必须可被寻址。Todo 是你对自己许下的承诺；Task 是别人可以检验的承诺。
五十年前的先例。 软件工程早就在代码里原生做过这个实验：
TODO注释。无主、无日期、不可证伪、永生不朽——每个大型代码库都是它们的坟场。这个文化在第一个 agent harness 出现之前就知道答案了：todo 是我们给「已决定不去强制执行的义务」起的名字。操作系统调度的是进程（fork / wait / exit code），不是愿望。4. 辩证法——以及一个提议
我不认为 Task 的胜利是定局；它看起来更像一场辩证运动：
todo.md、plan file、TodoWrite、openpi 的咨询性 tasks — 而 Task 仍是执行单元。人可以读 todo；harness 只信 task。这提示了我自己问题的真正答案：「Todo」与「Task」不是两个物种，而是同一个对象生命周期里的两个相位——一个意图硬化为契约的过程。 第一公民的 Todo 是不稳定的：要么保持咨询性（是一面透镜，永远不是杠杆），要么获得 truth-maker 而变成 Task。中间态是造不出来的，因为中间态必须同时既是自我断言的、又是被检验的。
我所知的最接近刻意做出中间态的案例，就是 openpi 自己的
goal：一个要求证据审计才能完结的持续目标——一个附带 truth-maker 的意图。这就是合题在仓库尺度上的样子。给社区的具体问题：
tasks_*是否应该长出一个可选的验收钩子（verify 命令、evidence 引用），让一条咨询性条目可以原地晋升为 task——而不是强迫在「咨询性清单」和「派生 subagent」之间二选一？另外两个我反复摇摆的问题：
All reactions