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、多个 sessionAI 面临的不再是“记不记得”的问题而是跨主体协调的问题——这恰恰是人类组织数十年来最头疼的问题。所以 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 今天已经可以用了。关键在于你是否准备好重新定义自己团队的协作坐标