我为什么开始厌倦逐轮接棒

我在使用 Claude Code 的过程中逐渐意识到：随着它能够独立推进越来越长的工作，REPL 开始不够用了。我需要 Goal。

Claude Code 在终端里读代码、提出方案、修改文件、运行测试，然后结束这一轮，等我接下一轮。很多时候，它并不是真的需要我做决定。下一步该做什么，它已经有建议；它建议的下一步是否合理，我通常只是看一眼，然后同意。

我必须一直在场，却没有持续提供与这份注意力相称的判断。

表面上，我在监督 Agent；实际上，我只是它的时钟。它完成一轮，我按一下继续，这个任务才会进入下一轮。我的注意力就这样被切成许多碎片：每一次打断都很短，每一次决定都不难，但我始终不能真正离开，也很难把注意力完整地放到另一件事上。

这是一种很隐蔽的低效。衡量它，不能只看我点一次“继续”花了几秒。真正昂贵的是，为了随时接住下一轮，我必须让这个任务一直占据一部分注意力。

更关键的是，那些真正需要我判断的事情，大多不在每一轮结束时，而在任务开始之前：

  • 我要的结果是什么；
  • 哪些事情可以做，哪些不能做；
  • 什么证据可以证明任务已经完成；
  • 遇到什么情况，Agent 必须停下来找我。

只要这些问题已经讲清楚，后面的实现路径、工具调用和轮次衔接，本来就应该由 Harness 自己完成。

这就是我为什么开始需要 Goal。

Goal 改变的不是运行时长，而是协作单位

Goal 很容易被理解成“让 Agent 自动多跑几轮”。但在我看来，它真正改变的不是一次运行有多长，而是人与 Agent 以什么为单位协作。

我说的 Goal，是让 Harness 围绕一个目标和完成条件，自行接续中间的多个 turn。这里的异步也不只是把进程放到后台，而是人不必与 Agent 保持同一个节奏在线。

我把这种每轮结束都把控制权交还给人的交互称为同步 REPL。在这里，需要人介入的单位是 turn：Agent 做完一轮，人读完输出，再决定下一轮要不要开始。无论这个决定是否真的需要人的判断，任务能否继续都依赖人再次接棒。

Goal 把需要人介入和负责验收的单位，从 turn 改成了 task。人不再逐轮描述下一步，而是在开始时定义一份完成契约：目标是什么，边界在哪里，什么证据算完成。Harness 负责接住中间的 turn，持续推进，直到满足完成条件，或者遇到一个无法根据既有契约处理的新决定。

两种模式的区别不是“手动”与“自动”这么简单：

同步 REPL：人持续在线，以 turn 为单位决定是否继续

Goal：      人可以离开，以 task 为单位定义和验收工作

从 turn 到 task，人的工作也随之上移：从批准一个个行动，变成定义目标、行动边界与完成条件。

这才是异步协作真正开始的地方。我把任务交给 Harness，然后可以离开。它不再需要我为每一轮上发条；我也不再需要反复交出注意力，只为完成一连串几乎没有判断价值的“继续”。

当人终于可以离开，注意力成了新的瓶颈

但当 Goal 真的让我离开终端，另一个问题马上出现了。

既然一个任务可以自己向前走，我就可以同时交代更多任务。过去，我的工作容量受限于一次能为几个 Agent 逐轮接棒；现在，Agent 可以各自运行，限制不再来自它们能否继续，而来自我回来后能否有效地管理它们。

我需要知道：

  • 哪些任务正在进行；
  • 哪个任务遇到了真正需要我的问题；
  • 哪个任务已经完成；
  • 我回来时应该先读什么；
  • 每个任务改变了什么；
  • 凭什么判断它真的完成了。

这时，Goal 与 task management 的区别变得很清楚：

Goal 解决“一个任务能不能在我离开后继续”；task management 解决“当多个任务都能独立工作时，我的注意力应该去哪”。

这里的 task management 不是排期，也不是给任务列一张待办清单。它管理的是已经委托出去、正在执行、等待人介入或者等待验收的工作。表面上管理的是 task，实际管理的是人的注意力何时离开、又因为什么回来。

Goal 让单个任务可以异步推进；task management 则决定人的注意力如何在多个任务之间分配。这是第二次上移：第一次从逐轮接棒到定义 Goal，第二次从定义单个 Goal 到管理多个 task。

逐轮接棒
   ↓
定义 Goal
   ↓
管理多个 task

到这里，我才重新看懂 Claude Code 与 Codex 的差别：它们的区别不只是一个在 CLI、一个在 app，而是各自围绕先后出现的两个瓶颈组织交互。

Claude Code 解决了 Agent 的行动瓶颈

我的不适不是因为 Claude Code 没有解决问题，而是因为它成功解决的是执行层的问题：如何让 Agent 直接、高效地使用 shell、代码库、Git、测试和各种真实开发工具。

当模型刚刚能够从“给出代码建议”走向“自己完成工程行动”时，最重要的是减少它与真实工作环境之间的阻隔。终端足够薄，离工具足够近，也天然可组合。模型可以搜索、编辑、运行、检查，程序员也可以随时看见和介入。

Claude Code 优先展开的是 Agent 的行动过程。它的中心是一段持续向前的 session：Agent 读到了什么、调用了什么工具、产生了什么结果、下一步准备做什么。在 Agent 还需要密切协作时，行动过程就是最重要的信息，人在旁边也能及时修正方向。

但当 Agent 已经可以独立完成越来越长的工作，这个优点会逐渐变成新的摩擦。Agent 的执行流仍然需要 command 和 turn，人却不再需要观看每一个 command、接住每一个 turn。终端仍然很适合 Agent 行动，却不一定适合人管理许多正在异步推进的任务。

所以这不是 CLI 和 GUI 的胜负。CLI 是很好的 Agent execution surface，却未必是最好的 human supervision surface。当执行层已经足够强，人开始需要一层为监督而设计的交互。

Codex 围绕人的注意力重新组织交互

从 Claude Code 转到 Codex app 时，我的第一反应是：这才是我现在需要的工具。我也开始理解，为什么一部分 Claude Code 重度用户会在这个阶段需要 Codex 式的工具。

差别不只是 GUI 更漂亮。Claude Code 优先展开 Agent 的行动过程；Codex 则把 task 放在交互中心，优先组织人的监督过程。正因为前者已经释放了 Agent 的行动能力，人的逐轮陪伴才会暴露为新的瓶颈；Codex 接住的正是这个需求。

Agent 的行动单位仍然可以是 command 和 turn，但人的管理单位已经变成了 task。人不必持续跟随执行流，而可以围绕任务进行调度、理解和验收。

Codex 的几个区域，对应的其实是几种不同的注意力：

  • 任务列表负责调度：现在有哪些工作在进行，哪个任务需要我；
  • 任务流负责理解：这个任务的目标是什么，过程中发生了什么；
  • diff 负责验收：这次任务具体改变了什么；
  • 状态与通知负责召回：什么时候真的需要我回来。

这些能力单独看都不神秘，放在一起却改变了人与 Agent 的关系。它不要求我持续观看 Agent 工作，而是让我的注意力只在任务边界上出现：开始时定义，必要时决策，结束时验收。

任务列表也不只是多个 chat 的目录。Chat 保存的是一段对话，task 还应该具有目标、状态、改动、证据和完成条件。对话只是任务的过程记录，不再是组织工作的最上层单位。

这就是 Codex 在我当前工作方式下做对的地方。它没有取代 Agent 的执行层，而是在执行层之上，为人建立了一层 task management。它也让我看见，自己的 Harness 在 Goal 之后仍然缺什么。

Goal 之后，我的 Harness 还需要任务管理

我的 Harness 也停留在 REPL。实现 Goal 之后，它已经能够替人接住中间的 turn，让一个任务持续推进。但现在我知道，Goal 只是完成了从同步执行到异步执行的第一步。

落到我的 Harness 上，这个差别很具体：Goal 让任务不再依赖人的逐轮接棒；task management 才让人的注意力不再被执行过程占住。

如果 Harness 可以同时承载更多异步任务，它接下来需要的就不只是一个输入框和一段更长的执行记录，而是一套围绕人组织的任务界面：持久的任务状态、明确的等待原因、只在必要时发生的召回、task-scoped 的改动与证据，以及可以被快速完成的最终验收。

Agent 仍然需要 shell、文件系统、Git 和测试。它的 execution surface 不必离开终端式的行动环境。但人的 control surface 应该围绕 task 建立，因为人已经不再以 command 和 turn 为单位工作。

这就是我现在知道的、更好的 Harness 用户体验：不是在 REPL 里容纳更多 session，而是让每个 task 都可以独立推进，只在真正需要判断时把人的注意力召回。

我既经历了交互瓶颈，也实现过试图解除这个瓶颈的机制。因此，我看到的不只是两个产品的界面差异，而是人与 Agent 的协作单位正在发生变化。

对我来说，亲自构建 Harness 不只是实现一套功能，也是理解技术趋势的方法：先在使用中感到摩擦，再把摩擦拆成机制，用代码和 Dogfood 验证，最后回到产品形态判断它是不是结构性变化。

这条从体验、实现再回到产品的路径，也改变了我判断 coding 工具的尺度。

效率工具最终管理的是人的注意力

这个尺度很具体：我不再只看一个 coding 工具让 Agent 做得有多快，也会看它要求人以什么节奏参与：

  • 它是在每一个 turn 结束时把人叫回来，还是只在真的需要判断时召回人？
  • 它展示的是完整的行动流水，还是为人组织过的任务状态与完成证据？
  • 它让人同时盯住更多 session，还是让人可以放心地忘记正在执行的任务？
  • 它优化的是 Agent 的吞吐，还是人与多个 Agent 协作时的注意力质量？

效率工具很容易优化可见的操作：少一次点击、少敲一条命令、快几秒得到回答。但人的注意力并不是由许多可以随意切割的秒组成的。一次只需点击“继续”的打断，也可能破坏一段完整的思考。

真正好的异步 Agent 工具，不是让人更快地回应每一次打断，而是让那些不需要人的时刻，不再打断人。

Agent 不会行动时，工具应该帮助它行动；Agent 已经可以连续行动时，工具就应该帮助人分配注意力。瓶颈在哪，交互重心就在哪。