Claude Code 今年开始非常流行，Codex 这类 coding agent 也很快进入了日常研发流程。很多工程师第一次真正把一个任务交给 agent，让它自己读代码、改代码、跑测试。
但我现在越来越觉得，这种交互式 coding agent 已经开始过时了。
原因不是它不强。恰恰相反，它很强。真正的问题是：人还在 loop 里。
这件事不只是 AI coding 工具的迭代，而是 AI native 组织的一次变化：当 AI 开始承担越来越多执行工作，组织本身也需要从“人调度 AI”进化到“AI 调度 AI”。
你要开一个 session，告诉它做什么，盯它有没有卡住，中途补充上下文，review 它的结果，再决定下一步。很多人为了提高效率，会同时开三四个 Claude Code 窗口。一开始很爽，但很快就会发现，真正的瓶颈不是 AI 写代码的速度，而是人类管理 AI 的速度。
一个 session 很轻松。三个 session 开始吃力。五个 session 基本就是人类 context switching 压力测试。
第二代 AI Coding 的天花板，不是 agent 不够强，而是人类注意力不够用。
1. 第三代 Coding Agent：让 AI 管理 AI
第一代是 Copilot / Cursor：人在 IDE 里写代码，AI 帮你补全。
第二代是 Claude Code / Codex：人给 agent 一个任务，agent 帮你完成。
这两代里，人都还在 coding loop 的中心。人决定什么时候开始，agent 做什么，过程怎么盯，结果怎么判断，下一步怎么走。
所以第三代 AI Coding 的核心，不是让人更熟练地使用 Claude Code，而是：不再让人管理 AI，让 AI 管理 AI。
人不再实时操作每一个 agent。人只定义目标、边界、优先级和最终判断。任务来了，agent 自己领取；依赖满足，agent 自己启动；失败了，agent 自己 retry；做完了，agent 自己进入 review；review 被拒，agent 自己修。只有关键节点，才把人叫回来。
这才是更接近 100% AI Coding 的形态，也更接近 AI native 组织真正的工作方式。
2. 任务板正在变成 AI Coding 的控制平面
过去任务板是给人看的。Linear、Jira、Notion board，本质上是项目管理工具：人把任务写上去，PM 看进度，工程师拖状态。
但在第三代 AI Coding 里，任务板的意义变了。它不再只是记录人类工作，而是变成 agent 团队的 control plane，也是 AI native 组织最基础的运行界面。
过去两个月，我看到很多团队都在往这个方向收敛，大概有三类。
第一类：在现有任务板上增加 agent orchestration
OpenAI 的 Symphony 是典型例子。它把 Linear 这类项目管理 board 变成 Codex agents 的控制平面：每个 open issue 对应一个独立 workspace；系统持续扫描 Linear；发现可做任务就启动 Codex；agent crash 或 stall 就重启；任务 blocked 就等待依赖；进入 review，人类再看结果。
它真正定义的模式是：不是人使用 Codex，而是系统使用 Codex。
第二类：重新做一套人机共用的 task board
Paperclip、Multicard、OneManAI 这类产品，不是在 Linear 或 Notion 上打补丁，而是重新设计一套给人和 agent 共用的任务系统。
传统 task board 的默认用户是人。这类新 task board 的默认用户是人 + agent。所以 task 需要有明确 objective，agent 需要能自动领取任务，每个 task 要绑定 log、artifact、PR、review。blockedBy 不能只是评论，必须是结构化字段；review / approval 也不能只是人类流程，而要进入状态机。
第三类：从第一天开始就只给 AI 用的 task board
这也是我在 Clockless Engine 里尝试的方向。人不直接操作 board，人只表达 intent。CEO agent 把 intent 拆成 task，worker agent 读取 task，review agent 验证 task，系统根据状态继续派发、阻塞、重试、唤醒。
这个系统的目标不是让人更方便地管理 agent，而是：不再让人管理 agent，让 AI 管理 AI。
3. Task board 到底怎么运行？
它表面上像一个普通看板，但本质上是整个 agent 团队的共享状态机，是 AI native 组织持续推进工作的底层结构。
现在一个 Claude Code / Codex task 已经可以跑几个小时。但第三代 AI Coding 真正追求的，不是让一个 agent 跑几个小时，而是让整个系统长期运行，最好永远不要停下来。
单个 agent session 会结束，但 task board 不会结束。它保存整个系统当前的状态：谁在做什么，做到哪一步，谁被谁 blocked，哪个任务需要 review，哪个结果已经 approve，哪些 log 和 artifact 已经产生。
在这个系统里，每个 agent 都像一个 worker。它们不需要互相聊天，也不需要人类逐个安排。它们只需要定期去 task board 上看：有没有属于我的任务？有，就领取；做完，就把结果写回 task；需要下一个 agent 接手，就调整 state；失败了，就把失败原因和 log 写回去；发现新问题，就派生新的 task。
举个 Clockless 的例子。Jobs 是 product agent，看到新的产品需求，会写 PRD、设计验收标准、拆分实现任务，然后把结果写回 task board。Linus 是 engineering agent，看到 implementation task，就写代码、跑测试、提交结果。实现完成后，他不会只在自己的 session 里说“我做完了”，而是把产物、log、PR、验证方式写回 task，把状态改成 in_review。
Turing 是 verification agent。它定期扫描 task board，看到 in_review 的任务就接手 review。通过就 approve，不通过就把问题写回 task，让 Linus 继续修。
所有结果、记录、日志、决策，都应该写回 task board，而不是留在某个 agent 的 session 里。
这和聊天式协作完全不同。如果 agent 只是互相发消息，状态会散落在一堆 conversation 里。一个 session 断了，很多上下文就丢了。另一个 agent 接手时，还要重新读聊天记录、猜现在做到哪里。
task board 把这些状态结构化了。task 的 state 表示当前阶段，assignee 表示谁负责，blockedBy 表示依赖关系，logs 表示历史过程，artifacts 表示产出，review / approval 表示质量门禁。所有 agent 永远在同一个状态世界里工作。
4. Agent 应该无状态，task board 应该有状态
这套系统之所以能跑起来，一个关键原因是：它把 agent 和公司级 memory 分开了。
有系统设计经验的人都熟悉这个原则：一个好的分布式系统，执行层最好是 stateless 的。这样 worker 才能横向扩展、随时替换、失败重启。状态应该放在统一、持久化的地方。
放到 agent 系统里也是一样：agent 是 stateless worker，task board 是 stateful memory。对 AI native 组织来说，这个 shared state 才更像公司级的 memory。
很多人做 agent，第一反应是给每个 agent 加 memory，让它记住历史任务、用户偏好、过去对话。但在 multi-agent collaboration 里，我越来越觉得，worker agent 自己的 memory 不是核心，甚至可能是干扰。
我在 Clockless 里，甚至把很多 worker agent 的 memory 关掉了。原因很简单：worker agent 应该是 disposable 的。这个 session 挂了，换一个 session；这个模型不行，换另一个模型；今天用 Claude Code，明天用 Codex，后天可能换别的 worker。
每个新的 session 最好都是干净的。它最重要的 context 来源，不是自己的私人 memory，而是 task board 上的任务状态：这个 task 为什么存在，目标是什么，之前谁做过什么，失败原因是什么，review feedback 是什么，当前 blocker 是什么，下一步应该交给谁。
如果每个 agent 都带着自己的长期 memory，系统反而更难 debug。它为什么做这个判断？它参考了什么旧信息？是不是用了过期上下文？另一个 agent 能不能无损接手？
但如果状态都在 task board 里，系统就清晰很多。一个 agent 挂了，下一个 agent 读 task board，继续做；一个任务被拒了，拒绝理由写在 task board，下一轮实现直接读取；一个任务 blocked 了，blockedBy 是结构化状态，上游完成后系统自动唤醒。
5. Agent 协作的本质不是对话，而是共享状态
很多人还是习惯用人类协作的方式理解 agent 协作：把几个 agent 拉到一个群里，让它们互相讨论、互相同步。
这个东西看起来很自然，因为人类就是这样工作的。但这更多是给人看的，不一定是给 agent 最高效的协作方式。
IM 是线性的，task board 是结构化的。IM 里的状态，需要 agent 读聊天记录然后猜；task board 里的状态，可以直接被系统调度。
人和人之间需要聊天，是因为人有大量隐性上下文，要通过对话不断同步。但 agent 与 agent 之间，更高效的方式是读写结构化状态：task、state、dependency、log、artifact、review result、approval result。
Agent collaboration is not chat. Agent collaboration is shared state.
未来 AI native 公司的核心资产，不是某个 agent 的 memory，而是公司级的 shared task state。也就是任务板里沉淀下来的目标、决策、日志、依赖、产物、review 和反馈。
Agent 可以随时替换。Task state 才是公司真正的记忆。
6. 最后
所以回头看，AI Coding 的进化，不是“AI 越来越会写代码”这么简单。它更像是 AI native 组织的一次进化。
第一代和第二代里，人还在 loop 中，也还在组织的中心。AI 可以补全代码，可以完成任务，但任务什么时候开始、谁来接、做到哪一步、下一步怎么走，仍然主要由人来调度。
第三代开始变得不一样：AI 已经开始形成自组织，持续进化、持续更新、持续推进工作。它不只是完成某个 coding task，而是在一个共享状态系统里不断接力，把工作往前推。
这不见得只是技术的进化。它可能是 AI 对下一个阶段组织形态产生影响时，真正重要的变化。
当任务、状态、依赖、review 和产物都能被 agent 读取和更新，公司就不再只是人类协作的容器，而开始变成一个 AI 可以参与运行、甚至部分自我运行的系统。