AI 不再只是执行你的指令，它开始管理自己的项目了。
这是 Anthropic Claude Code 团队成员 Thariq Shihipar 在 2026 年悄悄发出的一条技术更新公告里，藏着的一个巨大信号。大多数人划过去了，没有停下来。
Claude Code 宣布：将 Todos 升级为 Tasks。
表面看，这是一次工具迭代。但如果你真正理解这次升级背后发生了什么，你会意识到：AI Agent 的能力边界，正在向一个方向悄悄蔓延——那个方向，过去叫做“项目管理”，是人类管理者的核心地盘。
这个事实，正在重写每一位 CEO 的商业假设，和每一位 CTO 的产研逻辑。
一、为什么 Todos 不够用了？
要理解这次升级的重量，先要理解 Todos 的时代背景。
过去，AI 编程工具里的 Todo 机制，本质上是一种“提醒便条”——帮助 AI 在有限的上下文窗口里记住自己还有哪些事没做完。它的存在，是因为模型需要被提醒。
Thariq 在公告里说了一句话，我觉得是整篇文章最值得反复咀嚼的一句：
“Compared to previous models， Opus 4.5 is able to run autonomously for longer and keep track of its state better. We found that the TodoWrite Tool was no longer necessary because Claude already knew what it needed to do for smaller tasks.”
翻译过来是：Todo 工具对于小任务已经不再必要，因为 Claude 已经自己知道该做什么了。
这句话的震撼之处不在于技术，而在于它描述了一种认知能力的质变。一个系统从“需要被提醒”到“自己记得”，这不是效率提升，这是自主性跃迁。
但随之而来的挑战也出现了：当任务变得更复杂，当项目跨越多个 context window、多个 subagent、多个 session，AI 面临的不再是“记不记得”的问题，而是跨主体协调的问题——这恰恰是人类组织数十年来最头疼的问题。
所以 Todos 不是被淘汰了，而是进化了。它进化成了 Tasks。
二、Tasks 的三个技术突破，每一个都在对标人类组织
Tasks 不是 Todos 的加强版，它是一次底层架构的重构。理解它的三个核心设计，你会看到一幅熟悉的图景——它在用技术语言，重新描述人类组织的协作机制。
1. 依赖管理：任务之间有了因果关系
Todos 是一个平铺的清单，Tasks 之间可以声明依赖关系（dependencies）。Task B 需要等 Task A 完成才能启动，Task C 如果遇到 blocker 可以显式标记。
这听起来像什么？像甘特图。像 JIRA 里的 epic 和 story 的层级关系。像任何一个成熟研发团队用来管理项目的协作工具。
AI 在给自己建了一套项目管理系统。
这只是开始。
2. 持久化存储：跨会话的记忆
更大的变化，在记忆里。
Tasks 存储在文件系统中（~/.claude/tasks），而不是存在内存里。这意味着任务状态在会话结束后不会消失，下一次启动的 Claude 可以接着上次的进度继续。
过去，每次开新会话，AI 是“失忆”的——你需要重新交代背景，重新建立上下文。现在，任务状态作为持久化的事实存在，AI 可以真正做到“上次讲到哪了，这次继续”。
这是 AI 从“工具”向“同事”转变的关键一步。同事之所以比工具更有价值，正是因为他们有记忆、有历史、有延续性。
但即便如此，单个 Agent 的记忆只是起点。真正的挑战，是多个 Agent 同时工作时，谁来协调？
3. 多 Agent 广播协作：分布式团队的协调机制
这是最让我震撼的设计。当多个 subagent 或 session 同时工作在同一个 Task List 时，其中任何一个 agent 更新了 Task 状态，这个变更会广播给所有正在工作的 session。
Thariq 写道：
“When one session updates a Task， that is broadcasted to all sessions currently working on the same Task List.”
这是什么？这是异步通知机制。这是分布式系统里的事件驱动架构。这是人类项目协作里的“状态同步”——当一个团队成员完成了某项工作，整个团队都应该知道，然后才能推进下一步。
AI 不是在模拟项目管理，它是在原生实现项目管理的底层逻辑。
三、unhobble：一个词，照见了所有组织的困境
你有没有想过，AI 的能力瓶颈，从来不是模型本身？
Thariq 在公告里用了一个词：unhobble——解除束缚。Anthropic 的判断是：Opus 4.5 已经有了更强的自主运行能力，但这种能力被旧的工具框架锁住了。TodoWrite 的设计预设了“模型需要被提醒”，而现在的模型已经不需要了。工具没有跟上模型，模型的潜力就被白白浪费。
这是 Anthropic 工程师的自我反省，也是一个深刻的隐喻。
一个系统的能力上限，不是由最强的组件决定，而是由最落后的约束决定。
Tasks 的诞生，是 Anthropic 主动打破自己旧有约束的结果。他们没有等 Todos 用到彻底失效，而是在模型能力扩张的临界点，提前重新设计了工具层的底层逻辑。这种“主动 unhobble 自己”的意识，比 Tasks 本身更值得被记住。
现在，把这个问题反打给你——
你的组织里，有没有在用旧的流程框架，束缚着新的人才潜力？
那套沿用多年的需求评审流程、那个以代码行数衡量产出的绩效体系、那个假设“沟通靠会议”的协作模式——它们当初的存在是有道理的，就像 TodoWrite 在旧模型时代的存在是有道理的。但如果你的团队能力已经进化，而框架还停在原地，你正在做的事就叫 hobble——把自己最好的人，套上了最旧的辕具。
这才是 Tasks 升级真正想让我们看见的东西。
它不只是一次工具迭代。它是一面镜子。
四、致 CEO：当 AI 开始管项目，你的商业逻辑要重写哪里？
我知道很多 CEO 看到这里会说：这是工程师的事，我不需要懂技术细节。
但我想说：Tasks 升级这件事，触动的不是技术细节，而是你公司的商业底层假设。
假设一：人力成本是项目推进速度的主要约束
过去，一个项目要快，答案几乎只有一个：加人。更多工程师，更快交付。整个融资逻辑、团队扩张逻辑、期权激励逻辑，都建立在这个假设上。
但当 AI 可以跨会话、跨 subagent 自主协调完成复杂项目时，这个假设开始松动。速度的约束，从“有多少人”转变为“有多清晰的任务定义和多高质量的决策输入”。
这不是小事。
这意味着：你的核心竞争力，不再是人才密度，而是问题定义能力。 能把一个复杂业务问题拆解成结构化、有依赖关系的任务树的人，将成为组织里最稀缺的资源。
假设二：项目管理是一个需要大量中间层的人力密集型职能
需求评审、排期协调、进度跟踪、跨团队同步——这些消耗着大量项目经理、产品经理和工程 lead 的精力。
当 AI Tasks 能够原生支持依赖管理和状态广播，这些工作中的大量机械性协调工作将被替代。留下来的，是那些需要真实人类判断的部分：需求是否正确、优先级是否合理、用户价值是否真实。
CEO 需要思考的不是“我的 PM 会不会失业”，而是“我的组织结构是否还适配这个新的人机协作模式”。
假设三：AI 只是辅助工具，最终决策还是人来做
这个假设还成立——但它的边界正在快速收缩。当 AI 可以自主完成跨 session 的复杂项目，你会发现：很多你以为是“决策”的事情，其实只是“执行中的信息整合”，而这恰恰是 AI 越来越擅长的事。
真正属于人类的决策，只剩下那些需要价值判断、商业直觉和责任承担的部分。 如果你今天还在亲自盯着执行细节，你正在用最贵的资源，做最不该自己做的事。
给 CEO 的一条核心建议： 下次开战略会，试着把讨论的目标用“任务树”的方式写出来——哪些任务有依赖关系，哪些可以并行推进，哪些是当下的真正 blocker。
如果你写不出来，说明这个目标还没想清楚。如果你写出来了，你就已经在用 AI 能理解的语言思考了。这个能力，将成为你公司驾驭 AI 项目管理能力的核心杠杆。
五、致 CTO：产研组织的底层假设，正在被颠覆
如果说 CEO 面对的是商业模型的重构，那 CTO 面对的，是更直接的冲击：你精心设计的产研流程，建立在哪些关于人的假设上？这些假设还成立吗？
假设一：上下文传递是研发效率损耗的主要来源
每个 CTO 都深有体会：需求从产品传给研发，信息衰减 30%；研发内部交接，再衰减 20%；跨团队对齐，损耗更大。于是我们设计了各种流程来对抗信息衰减：写 PRD、做 design doc、开对齐会。
但 Tasks 的持久化存储和状态广播机制，提供了一种不同的可能：让任务状态成为单一可信来源，让信息传递从“人传人”变成“状态同步”。
这不是说要用 AI 替换 PRD。这是一个更根本的问题。你的研发流程里，有多少沟通成本是在做本质上是“状态同步”的事？这部分，AI Tasks 有能力承担，而且承担得比人更准确、更及时。
假设二：Subagent 的协调需要人工介入
过去，多个 AI Agent 并行工作是个噩梦——你不知道谁做了什么，状态如何，有没有冲突。所以我们习惯性地在 AI 和 AI 之间，插入人工协调的节点。
Tasks 的广播协调机制，首次在原语层面解决了这个问题。多个 subagent 共享一个 Task List，状态变更实时广播，任务依赖自动感知。
这意味着：你的 AI 工程架构设计，需要认真考虑“多 Agent 协调层”的设计，而不是假设 Agent 永远是单线程运行的。 那些在 AI 工程架构上投入的 CTO，将在这一波竞争中获得巨大先发优势。
假设三：工程师的价值在于“生产代码”
我在之前的文章里讨论过这个问题。Tasks 的出现，进一步强化了这个判断：工程师的价值，正在从“代码生产者”转向“复杂系统的设计者和质量把控者”。
一个能把复杂业务需求拆解成结构化 Task 树、能验证 AI 执行结果的正确性、能在 AI 遇到 blocker 时做出正确判断的工程师，比一个能快速手写 CRUD 的工程师，价值高出一个数量级。
给 CTO 的三条核心建议：
重新设计你的 AI 工程架构：不要把 Agent 当成单线程工具用，开始设计支持多 Agent 协调的工程基础设施。Tasks 的文件系统存储和广播机制，是一个很好的起点，但你需要在此之上建立适合自己业务的协调层。
重新定义工程师的考核标准：把“代码产出量”从 KPI 里降权，把“任务定义质量”和“AI 结果验证能力”加权。一个具体的可观测指标是：一个工程师给 AI 写的 Task 描述，能不能让 AI 第一次就跑对方向？这个“一次命中率”，比他一天写了多少行代码，更能反映他在 AI 时代的真实价值。这不是在讨好工程师，而是在为下一个阶段的竞争做人才储备。
现在就开始实验 Multi-Agent 工作流：不要等到技术完全成熟再动。Task 列表共享、subagent 协调、跨 session 继续——这些能力今天就可以在 Claude Code 里实验。最先跑通 Multi-Agent 工作流的团队，将率先建立起难以追赶的效率优势。
六、结语：不是工具在升级，是协作的本质在重新定义
Steve Yegge 的 Beads 项目给了 Anthropic 灵感，Thariq 把它做成了Tasks。但无论叫什么名字，这件事背后的逻辑只有一个：
当 AI 的能力边界扩张到可以管理复杂项目，人类在协作中的角色就必须重新定义。
不是被替代。而是升维。
Todo 时代，AI 是你的提醒便条。Tasks 时代，AI 是你的协作团队成员——有记忆、有感知、有依赖管理、有状态广播。
那么，作为 CEO，你是在用旧的组织假设管理一支新型团队吗？
作为 CTO，你是在用旧的工程架构，束缚一匹越跑越快的马吗？
变化不等人。Tasks 今天已经可以用了。
关键在于，你是否准备好重新定义自己团队的协作坐标？
时光匆匆，感谢停留。
原创不易，如果觉得文章有价值，请点赞、推荐、分享到朋友圈。
关注我，往后岁月，一路同行，一起成长。
