上一篇《手写一个 Claude Code1从 Agent Loop 到工具、权限、Hooks 与任务规划》我们把一个编码 Agent 的基本闭环搭了起来模型提出工具调用程序执行工具再把结果交还给模型。但“能调用工具”离“能把复杂项目做完”还有一段距离。任务长了会漏步骤读的文件多了会挤占上下文多个工作有先后关系测试和构建又可能让主循环停下来。再进一步几个 Agent 同时工作时谁负责哪个任务、什么时候可以开始、结果怎样回到负责人都需要明确的机制。这篇把 learn-claude-code 中与任务管理和执行直接相关的五章串起来s05 TodoWrite、s06 Subagent、s10 Task System、s11 Background Tasks、s13 Agent Teams。重点是理解它们分别解决什么问题以及从“一个人的执行清单”走到“一个团队的协作运行时”中间究竟多了哪些东西。目录一、先把五种机制放到正确的位置二、s05 TodoWrite把计划变成可检查的状态2.1 TODO 是当前工作的执行清单2.2 Reminder 让执行清单重新进入上下文2.3 它解决规划不负责验收三、s06 Subagent把一个子问题交给独立上下文3.1 task 是委派工具不是任务板上的 Task3.2 三个边界特别容易混淆四、s10 Task System从清单升级为持久化任务图4.1 Task 记录的是可协调的工作单元4.2 建图必须先创建节点再建立依赖4.3 ready 到底是不是任务状态4.4 Claim 与 Complete 管状态实际工作靠工具五、s11 Background Tasks让慢命令离开主循环的等待路径5.1 后台执行的是命令不是另一个会推理的 Agent5.2 一次调用分成启动回执和后续通知5.3 后台完成不会主动唤醒这个章节的 Agent5.4 bg_id 有自己的生命周期六、s13 Agent Teams把任务板交给多个持久执行者6.1 团队运行时多了什么6.2 第一步确认分工再建立任务图6.3 第二步按任务绑定目录在线程启动前认领6.4 第三步计划获批后才允许修改6.5 第四步队友执行自己的 Agent Loop6.6 第五步完成记录、结果通知、空闲通知分开处理6.7 第六步运行时投递消息自动唤醒 Lead6.8 第七步空闲队友自动找工作但认领必须原子化6.9 第八步关闭队友单独处理工作目录七、用一个后端重构把任务管理和执行串起来八、如何动手验证而不是只看模型说完成九、最容易混淆的几个问题参考资料一、先把五种机制放到正确的位置“Task”这个词在不同章节里指的并不是同一种对象。章节解决的问题核心对象执行方式与边界s05 TodoWrite接下来还有哪些步骤别漏掉内存中的 TODO 清单更新计划不新增文件或命令执行能力s06 Subagent一个子问题会产生太多中间上下文一次task工具调用同步嵌套 Agent Loop父循环等待s10 Task System谁负责、先做什么、怎样恢复进度持久化 Task 与依赖图记录与约束任务状态本章按顺序更新s11 Background Tasks慢命令不应挡住无关工作bg_id对应的命令执行记录后台线程运行 Shell后续轮次收集结果s13 Agent Teams多个 Agent 怎样长期分工协作持久队友、共享任务板、消息与协议独立线程和上下文WORK/IDLE 循环可以用五个问题记住它们TodoWrite 我接下来做哪一步 Subagent 这个子问题能否交给一段独立上下文 Task System 哪项工作已经可做由谁认领 Background Tasks 这条命令等待期间还能做什么 Agent Teams 多个执行者怎样共享任务并协调行动这是一条概念上的学习路线不是五个功能自动叠加成一个程序。这些章节是独立的教学实现。例如s06 并没有直接带上 s05 的 TodoWrites11 的工具集以基础工具和后台 bash 为主s13 复用任务系统但没有带入 s11 的后台任务或 s12 的定时任务。阅读时应看每章实际的TOOLS和 handler 注册而不是仅凭章节编号推断能力。二、s05 TodoWrite把计划变成可检查的状态2.1 TODO 是当前工作的执行清单假设用户要求“重构认证模块、补充测试、验证接口兼容性。”模型可能先修一个测试失败随后忘记还有兼容性检查。TodoWrite 把计划从自然语言约定变成显式列表[{content:梳理现有认证接口,status:completed},{content:重构认证实现,status:in_progress},{content:补充测试并验证兼容性,status:pending}]TodoManager.update()先完整校验再用新列表替换旧列表。主要约束包括最多 20 项、内容非空、状态合法以及最多一个in_progress。允许没有正在进行的条目例如刚创建时全部 pending或者结束时全部 completed。“整体替换”意味着模型更新一个条目时也应带上希望保留的其他条目。它不是“只传一条就自动局部更新”的接口。2.2 Reminder 让执行清单重新进入上下文只有工具声明还不够模型可能一直执行却不更新清单。s05 用计数器记录连续多少个工具调用轮次没有使用todo_writerounds_since_todo0ifused_todoelserounds_since_todo1ifrounds_since_todo3:results.append({type:text,text:reminderUpdate your todos./reminder,})rounds_since_todo0这里的“一轮”是一轮模型响应中的工具处理过程不是一个工具调用。模型一次返回三个文件读取请求并不等于计数器加三。典型过程是列清单 → 标记当前步骤 → 用文件或 Shell 工具执行 → 检查成果 → 更新状态 → 进入下一步。2.3 它解决规划不负责验收TodoWrite 没有任务 ID、owner、依赖图和持久化。清单写成 completed也不会自动证明文件已经修改正确、测试已经通过。另外该版本以是否执行到todo_write分支来重置提醒计数没有进一步区分这次更新是否成功。Reminder 是普通上下文提示不是强制调度器。适合把 TodoWrite 理解为帮助单个 Agent 跟踪当前工作的步骤而不是一套共享任务管理系统。三、s06 Subagent把一个子问题交给独立上下文3.1task是委派工具不是任务板上的 Task排查一个问题时模型可能读取十几个文件。父 Agent 最后只需要知道“根因在哪、建议怎么改”未必需要保留每一次读取的完整内容。s06 为此增加task工具。它收到 prompt 后创建全新的messages同步运行一个嵌套 Agent Loop结束时只把最终文本作为工具结果交还父 Agent。父 Agent 调用 task(prompt) ↓ run_subagent 创建新的 messages ↓ 子 Agent 调模型 → 调工具 → 收结果 → 继续 ↓ 子 Agent 返回最终文本 ↓ 父 Agent 收到这次 task 的 tool_result恢复执行代码的关键不是创建了多复杂的 Agent 类型而是这一句messages[{role:user,content:prompt}]父对话不会自动复制进去因此委派指令需要说明目标、范围、相关文件和希望返回的证据。例如阅读认证模块找出 token 校验入口与异常处理路径。只读分析不修改文件。返回关键文件、调用关系和可能受重构影响的测试。3.2 三个边界特别容易混淆第一独立上下文不等于并行执行。run_subagent()是普通同步调用父循环要等待子循环返回。本章主要解决上下文隔离并不直接加速并行工作。第二消息隔离不等于文件系统隔离。父子 Agent 使用相同的进程和WORKDIR。子 Agent 如果修改文件父 Agent 能看到这些修改它并不天然只读也没有自动获得沙箱。第三委派不是无限递归。子 Agent 只有五个基础工具没有task因此本章只提供一层委派。循环还有 30 次模型调用的上限达到上限会返回停止说明不能把它当作正常完成。父子工具调用复用权限检查和 Hooks。最终总结帮助减少父上下文负担但父 Agent 仍需要检查关键证据尤其是子 Agent 声称“修改完成”或“测试通过”时。四、s10 Task System从清单升级为持久化任务图4.1 Task 记录的是可协调的工作单元Todo 清单可以写“先做数据库再写接口”但程序无法稳定地从一句话判断依赖。Task System 把这些关系变成字段dataclassclassTask:id:strsubject:strdescription:strstatus:strowner:str|NoneblockedBy:list[str]任务保存在.tasks/{id}.jsonID 由运行时生成。工具包括create_task、update_task、list_tasks、get_task、claim_task和complete_task。和 TodoWrite 相比变化不只是“把列表写到磁盘”任务有独立身份、负责人、前置依赖以及受约束的状态转换。重启后可以读取记录恢复工作进度但不会因此自动恢复之前的模型上下文、线程和外部命令。4.2 建图必须先创建节点再建立依赖假设需要先建数据库结构再开发 API最后写测试文档则可以在数据库结构确定后开始schema ──→ endpoints ──→ tests └─────→ docs建图过程如下。这是调用源码函数的示意省略了环境初始化和真正的开发工作# 第一阶段先取得运行时生成的 IDschemacreate_task(建立数据库结构)endpointscreate_task(开发 API)testscreate_task(补充接口测试)docscreate_task(编写说明文档)# 第二阶段使用真实 ID 添加依赖update_task(endpoints.id,addBlockedBy[schema.id])update_task(tests.id,addBlockedBy[endpoints.id])update_task(docs.id,addBlockedBy[schema.id])为什么不能让模型在同一轮工具调用中直接引用“刚生成的 ID”因为同一响应里的工具参数在任何结果返回之前已经确定。模型必须先看到create_task的结果下一轮才能使用真实 ID 建立依赖不能编造task_1这样的标识。update_task会校验任务存在、目标仍为 pending 且无人认领并拒绝自依赖和依赖环。重复添加已有依赖不会形成重复边。4.3ready到底是不是任务状态不是。Task 的status仍只有三个值pending ──claim_task──→ in_progress ──complete_task──→ completedready表示“目前具备被认领的条件”它是根据任务记录计算的结果。在团队任务扫描中可理解为pending、没有 owner、前置依赖全部完成并且工作目录绑定有效。例如 B 依赖 A时刻B.statusB 是否 readyA 尚未完成pending否A 已完成B 尚未认领pending是B 已被认领in_progress否已经在执行前置任务完成时不需要把 B 的 status 改成 ready。下次检查依赖自然就能判断它可开始。blocked也不是这份 Task 数据结构里的第四个状态而是 pending 任务的依赖尚未满足。特别注意can_start()主要回答“依赖是否满足”不等同于完整认领检查。认领还要检查状态和所有权前置任务文件缺失也不能视为依赖已完成。4.4 Claim 与 Complete 管状态实际工作靠工具claim_task把任务从 pending 推进为 in_progress并写入 owner。complete_task要求任务正在进行、调用者拥有该任务然后标记 completed报告本次新解锁的下游任务。顺序应是读取完整任务 → 检查依赖 → 认领 → 修改代码 → 执行验证 → 保存成果 → 标记完成 → 查看下游任务不能省略中间的实际执行与验证。把任务标成 completed本身不会运行测试、提交 Git也不会检查业务验收标准。s10 是顺序执行的教学实现不能因为它有 owner 字段就直接认定它已经能安全处理多个 Agent 的并发抢占。共享认领的并发控制在 s13 中进一步补齐。五、s11 Background Tasks让慢命令离开主循环的等待路径5.1 后台执行的是命令不是另一个会推理的 Agent同步 bash 执行完整测试时当前工具不返回Agent Loop 就无法继续处理其他工作。如果后续只是读文档、检查配置等独立操作等待可以被利用起来。s11 扩展了 bash 的参数{command:python -m pytest tests/,run_in_background:true}是否后台执行由显式布尔值决定不根据命令里有没有test、build或install猜测defshould_run_background(tool_name:str,tool_input:dict)-bool:return(tool_namebashandtool_input.get(run_in_background)isTrue)字符串true也不等同于这里要求的布尔值true。5.2 一次调用分成启动回执和后续通知完整过程是主线程先执行PreToolUse完成权限判断。BackgroundManager.start()登记命令分配bg_0001这样的 ID。后台线程运行 Shell原始工具调用立即返回启动回执。Agent 继续执行与这条命令无依赖关系的工作。命令结束后worker 保存结果进入 completed 或 failed并加入完成队列。后续模型调用之前inject_background_results()收集完成结果注入上下文。消息关系可以画成tool_use(idcall_x, bash) └── tool_result(tool_use_idcall_x, bg_0001 started) ……后台命令继续运行…… 下一次进入模型调用前 └── 普通文本事件 task_notification携带 bg_0001 的状态与结果摘要原始tool_use已经有一个启动回执完成时不能再用同一个 ID 回第二个tool_result。完成通知是独立事件与 Task System 的.tasks/{id}.json也没有自动关联。5.3 后台完成不会主动唤醒这个章节的 Agent这是 s11 与 s13 很重要的区别s11 在下一次进入 Agent Loop、准备调用模型时收集通知。假如主循环已经结束并等待用户输入后台命令结束并不会自行启动新一轮模型调用。用户再次输入后通知才会在后续轮次被收集。因此不能把“后台启动成功”写成“测试已经通过”也不能假定命令一结束模型就已经知道结果。5.4bg_id有自己的生命周期后台命令记录使用另一套状态running → completed # 退出码为 0 → failed # 非零退出、超时或执行异常等这和任务板的pending/in_progress/completed不是同一个状态机。一次业务任务可能启动多个命令一个命令失败也不会自动给持久化 Task 增加 failed 状态。当前后台管理器主要维护内存状态结果被收集后会从相应队列和映射中移除通知里只保留有限长度的摘要。需要完整测试日志时应明确把日志保存到文件并在验证时读取。后台只适合独立工作。安装依赖还没完成就运行依赖这些包的测试或者测试执行中同时改它读取的代码都可能引入时序问题。命令进程组的超时和退出清理也只是生命周期管理不是安全沙箱或持久化任务队列。六、s13 Agent Teams把任务板交给多个持久执行者6.1 团队运行时多了什么s13 引入一个与用户沟通的 Lead以及多个持久队友。每个队友有自己的 system prompt、messages、工具集合和线程。队友完成一项工作后进入 IDLE收到消息或认领新任务后再回到 WORK。Lead沟通目标、建立任务图、协调和审批、检查结果 ├── alice独立上下文 Agent Loop 当前任务目录 └── bob独立上下文 Agent Loop 当前任务目录 共同使用.tasks/ 任务记录 消息通道.mailboxes/name.jsonl 可选目录.worktrees/name“持久”是指队友在同一运行进程中可以跨任务继续工作。任务文件可以保留不代表线程、完整 messages 和待审批状态都能在进程重启后自动恢复。6.2 第一步确认分工再建立任务图Lead 的系统提示词要求并行有价值时先提出小团队方案用户确认后再spawn_teammate。例如 config 负责配置auth 负责认证最后统一整合测试。这是模型行为层面的约束它与后面由工具分发代码执行的计划闸门不同不能把提示词本身当作不可绕过的安全边界。接着仍然遵循两阶段建图先create_task获取 ID再update_task(addBlockedBy...)建立依赖最后分派 ready task。只有 Lead 拥有修改依赖的工具队友不能随意改任务图。6.3 第二步按任务绑定目录在线程启动前认领如果认证重构需要独立工作目录Lead 在任务尚未认领时创建绑定# 工具调用形式示意auth_id 必须来自 create_task 的返回值create_worktree(nameauth-refactor,task_idauth_id)spawn_teammate(namebob,role认证重构,prompt保持现有接口报告修改内容与验证结果,task_idauth_id,require_planTrue,)启动流程是校验身份 → 设置计划要求 → 认领初始任务 → 建立 runtime → 启动线程。初始任务认领失败就不启动队友。lead和agent是保留身份不能作为普通队友名称。认领成功后运行时记录task_id与解析后的cwd。队友的 bash、read、write、edit 和 glob 都从 assignment 读取目录没有任务时不能直接使用这些工作区工具。没有 worktree 绑定的任务使用WORKDIR。绑定无效则直接失败不会静默退回主仓库。Worktree 分开 Git 工作目录与分支但并不限制 Shell 可访问的其他资源。6.4 第三步计划获批后才允许修改如果require_planTrue队友先读文件、了解情况再通过submit_plan提交计划。Lead 用review_plan审批。计划闸门状态含义bash / write_file / edit_filenot_required没有审批要求进入正常权限检查required等待提交计划阻止pending计划已提交等待审批阻止rejected需要修改计划阻止approved计划获批进入正常权限检查这里连只读 Shell 命令也会被挡住但仍可使用读取文件、glob 等工具收集信息。后台队友不会自行在终端向用户提问遇到需要用户确认的操作时返回权限错误由 Lead 协调。每个审批绑定request_id、task_id和work_version。旧任务的批准不能自动授权新任务普通消息也不能替代有效审批。完成任务并释放 assignment 后当前代码会重置闸门如果下一项任务也要求先看计划Lead 需要再次明确设置要求不能假定启动时的选项永久覆盖所有后续任务。6.5 第四步队友执行自己的 Agent Loop队友 WORK 阶段仍然是“调用模型 → 处理工具 → 回传结果”的循环。每次模型请求之前先处理队友收件箱工具分发层负责计划闸门、权限、Hooks 和异常转成结果。多个队友的模型请求可以并发同一个队友一轮中的多个工具调用则按顺序处理。收到关机或审批消息也不是强行打断正在执行的任意命令而是在运行时的消息检查点处理。中间协作使用send_message最后结果由运行时投递。队友不需要为了汇报最终结果再手动发送一遍相同消息。6.6 第五步完成记录、结果通知、空闲通知分开处理正常完成路径如下完成实际工作和验证 → complete_task写入 completed → 模型结束当前工作轮次并输出总结 → result把成果说明送给 Lead → 释放已完成任务的目录 assignment → idle_notification告知队友已空闲complete_task会检查任务状态、owner 和计划闸门。调用失败时保留当前目录方便修正后重试成功后也不会立即切换目录同一工作轮次后续工具仍使用原目录直到进入 IDLE 再释放。result回答“产出了什么”idle_notification回答“是否进入等待阶段”。不过代码不会仅因模型输出总结就替它把任务标为完成Lead 不能只凭“我做完了”或 idle 通知判断交付成功仍要核对任务板与实际成果。6.7 第六步运行时投递消息自动唤醒 LeadLead 和队友不共享 messages而是通过.mailboxes/name.jsonl传递事件。消息先写入收件箱再由运行时消费整理成[Team events]加入 Lead 的 history。队友 result / idle_notification → Lead 文件收件箱 → consume_lead_inbox → 更新协议状态、注入团队事件 → CLI 发起下一轮 Lead 调用read_inbox是消费式读取读完会删除收件箱文件所以 Lead 保留一个消费者。模型没有check_inbox工具不需要反复查询“队友结束了吗”。与 s11 不同这里 CLI 同时等待用户输入和团队消息团队事件能够触发新一轮 Lead 调用。但它仍是运行时事件循环不是能随时中断正在执行工作的抢占式调度器。6.8 第七步空闲队友自动找工作但认领必须原子化队友进入 IDLE 后先看消息再扫描任务板。代码使用约 2 秒的等待间隔没有消息时寻找 ready task成功认领后把任务描述加入自己的 messages回到同一个 WORK 循环。IDLE → 优先处理关机、审批和直接消息 → 没有消息则扫描 ready task → claim_task 成功 → 将任务 ID、描述、工作目录加入 messages → WORK扫描结果只是快照。alice 和 bob 可以同时发现同一个候选真正修改 owner 和 status 时必须在task_store_lock()中重新检查。它同时使用进程内锁与文件锁保存任务时先写临时文件再原子替换。alice 发现任务 C ──┐ ├── 进入认领临界区 → 只有一个执行者成功 bob 也发现任务 C ─┘运行时还会阻止队友在已有进行中任务、或当前工作轮次尚未释放 assignment 时继续认领其他任务。当前claim_next_task并不按角色做硬性技能匹配队友名称叫 auth不意味着它永远只能认领认证任务。若必须限定执行者不能仅依赖角色提示词需要额外的路由或资格校验。6.9 第八步关闭队友单独处理工作目录关机使用结构化握手Lead 创建请求 →shutdown_request(request_id)→ 队友在检查点响应 →shutdown_response(request_id)→ 原请求状态更新队友退出。协议校验请求 ID、消息类型、发送与接收身份及当前状态避免过期、重复或错配响应修改状态。正常执行到线程退出清理时尚未完成的任务会被退回 pending 并清空 owner便于重新认领。因此三个状态仍然成立只是异常或退出路径上还存在in_progress → pending的恢复转换。这不代表强杀进程后也能保证执行清理接手前仍应检查残留修改。任务完成、代码合并和 worktree 清理是三件事。清理只提供宿主函数模型不能直接移除 worktreepending/in_progress 绑定或尚在使用的目录租约会阻止移除。有改动时需要决定保留还是明确丢弃目录移除后仍保留wt/name分支。七、用一个后端重构把任务管理和执行串起来假设要“清理配置、重构认证、保持接口兼容、最后测试通过”可以设计下面的任务图A配置重构 ──┐ ├──→ C整合变更 ──→ D完整回归验证 B认证重构 ──┘为了看清五章的关系可以按下面的职责分层。这是组合设计说明不是声称 s13 原样就同时具备另外四章的全部工具。环节可以使用的机制应产出的证据明确目标和依赖Task SystemA/B/C/D 的真实 ID、依赖与验收描述某个任务内部安排步骤TodoWrite阅读、修改、验证的执行清单调查认证调用链Subagent关键文件与结论父 Agent 复核A/B 并行执行Agent Teamsowner、目录绑定、独立执行结果等待耗时测试时处理独立工作Background Tasks启动 ID、最终状态、测试日志最终验收Lead 与实际验证工具整合后的代码、测试结果、未解决项执行时Lead 先创建四个任务再连边只派发当前可开始的 A、B。如果 B 使用 worktree它完成后C 还需要把变更整合到最终验证所用的代码目录然后 D 才能开始。这里有个常见陷阱依赖完成只能证明任务板允许下游开始不能证明下游目录已经包含上游代码。如果认证修改还留在独立 worktree主目录测试通过也可能只是旧代码通过。把“整合变更”显式建成任务比在最后一句总结里顺带提到更可靠。若将 s11 后台机制集成进团队也要保留任务目录绑定、权限闸门、通知投递和进程生命周期管理。把 bash 简单扔进线程并不等于已经获得一套可靠的多 Agent 执行器。八、如何动手验证而不是只看模型说完成建议使用 Python 3.10在独立练习仓库或隔离环境中运行。基础依赖和.env配置可参考前篇s13 使用fcntl文件锁等机制按本章代码直接运行时以 macOS/Linux 或 WSL 环境为宜。worktree 示例还要求当前工作目录是有效的 Git 仓库并有可检出的提交。进入准备好的课程副本后以下命令每次只运行一个输入q退出后再启动下一章。脚本以启动时的当前目录作为工作区不要把有未保存重要修改的主项目当作试验场。python s05_todo_write/code.py python s06_subagent/code.py python s10_task_system/code.py python s11_background_tasks/code.py python s13_agent_teams/code.py章节可以输入的要求应观察什么s05先列计划再创建一个小模块、添加测试并运行TODO 是否更新完成状态是否有实际结果s06用子任务调查本项目测试框架只读分析并返回关键文件父循环等待子过程有独立日志父对话得到最终总结s10创建 schema、API、tests 三项任务API 依赖 schematests 依赖 API先返回真实 ID 再建边受阻任务不能提前 claims11将sleep 3明确放后台同时列出当前目录 Markdown 文件先收到 bg_id后续轮次收到完成通知若已回到输入提示符再输入“收集后台结果”s13拆分配置和认证重构认证使用 worktree先提交计划最后整合验证确认后启动初始认领、审批、结果与 IDLE 事件、任务目录均可对应再补四个反向检查往往比一次成功运行更能说明边界s10 中尝试给任务添加自依赖或环修改应被拒绝。s13 中两个队友竞争一个 ready task最终只能有一个 owner。s13 计划未批准时尝试 bash 或文件修改应返回阻止原因。模型声称完成后核对文件差异、任务 JSON 和测试日志而不是只读最后一句总结。这些是可重复的观察建议不同模型的具体工具调用顺序可能不同不能把示例日志当成固定输出。九、最容易混淆的几个问题TodoWrite 和 Task System 是替代关系吗概念上可以同时存在任务板管可认领工作TODO 管当前工作的内部步骤。但课程各章是否同时提供它们需要查看真实工具注册。Subagent 一定比主 Agent 更快吗不一定。s06 是同步委派主要减少父上下文中的中间细节还会增加子循环的模型调用成本。后台任务等于多 Agent 吗不等于。后台 worker 运行固定 Shell 命令不拥有一个持续决定下一步的模型循环。ready、running、idle能放进一个 status 字段吗不宜混用。ready 是任务可认领条件running 是后台命令状态idle 是队友运行状态。它们描述不同对象。completed 就表示交付成功吗Task completed 是执行者写入的业务进度后台 completed 是命令退出码为 0真正交付还需要验证需求、整合代码和检查成果。任务文件在就能无缝恢复整个团队吗不能。文件记录提供恢复依据但进程内的模型对话、后台命令、审批状态和线程生命周期仍需分别处理。沿着这五章看下来复杂任务执行的关键逐渐清楚了计划要可见工作要有身份和依赖耗时操作要有结果回收路径多执行者要有所有权和通信协议最后还要有可核查的验收证据。Agent Loop 负责持续行动围绕它的这些机制让长任务更有机会被正确地完成。参考资料前篇手写一个 Claude Code1learn-claude-code 仓库与许可证s05 TodoWrite 中文文档s06 Subagent 中文文档s10 Task System 中文文档s11 Background Tasks 中文文档s13 Agent Teams 中文文档各章实现位于对应目录的code.py。本文按“规划、委派、持久化、异步执行、团队协作”的主题重新组织并补充代码边界与验证建议源码及节选遵循原仓库 MIT 许可证。