前言

在上篇文章 Learn-Claude-Code | 笔记 | Collaboration | s10 Team Protocols 中，我们介绍了开源项目 learn-claude-code 第十个章节 s10 Team Protocols 的内容，这篇文章我们继续跟着教程文档来学习协作后续内容，记录下个人学习笔记，和大家一起分享交流😄

Note：本篇文章主要学习记录教程第五部分 Collaboration 中 s11: Autonomous Agents 章节的内容。

github：https://github.com/shareAI-lab/learn-claude-code

reference：https://chatgpt.com/

1. s11: Autonomous Agents

如果说 s10 的 Team Protocols 解决的是 “多个 teammate 在团队中不能只靠自由文本交流，而必须在某些关键动作上遵守统一协议”，那么到了 s11，这一节继续沿着 Collaboration 这条主线往前推进，但它要回答的问题已经又比 s10 更进一步了：

即便团队里已经有了持久存在的成员、有了收件箱、有了 shutdown 和 plan approval 这样的协议，如果这些队友仍然只有在 lead 明确下指令时才会行动，那这样的团队到底算不算真正自治？

前面 s09 我们已经看到了 “命名 teammate + 文件邮箱” 这套团队结构，s10 又进一步告诉我们：团队里有些动作必须走协议，不能只靠自然语言凑合。但仔细想想，这两节里整个系统依然保持着一个非常强的中心化特征：队友要么等 lead spawn 出来，要么等 lead 发消息，要么等 lead 发起 shutdown / review。

也就是说，虽然系统里已经有了多个 agent，但这些 agent 的行动起点，依然主要来自外部指派，而不是来自它们自己。文档里对这个问题说得非常直接：在 s09-s10 中，teammate 只会在被明确指派时才动；如果任务看板上挂着 10 个未认领任务，lead 还得一个一个去写 prompt 分配，这显然是扩展不了的。

这其实就是 s11 的出发点。一个真正有自治性的团队，不应该永远靠 lead 来逐个派活，而应该具备某种更接近现实组织的能力：队友自己会看任务板，自己会发现有活没人做，自己会去认领，做完之后再继续找下一件事。

也就是说，到了这一节，问题已经从：

• 队友能不能长期存在
• 队友能不能互相通信
• 队友某些动作能不能走协议

进一步变成了：

如果没有人明确来分配工作，Agent 能不能自己去找工作？

这也是为什么这一节叫 Autonomous Agents。它不是再给团队加一个新协议，也不是对 mailbox 机制做小修小补，而是第一次真正要把 teammate 从 “被动执行者” 推进成 “主动寻找工作的人”。

2. 问题

我们先来看一个很朴素的问题：为什么到了 s11，单靠 lead 指派任务已经不够用了？🤔

从前几节的视角来看，让 lead 来统一分配工作其实很自然。毕竟系统总得有一个中心去统筹全局，于是最简单的方式就是：

• lead 先看当前需要做什么
• 然后决定该让哪个 teammate 去做
• 再通过 prompt、inbox、protocol 去把任务发下去

这个模式当然能工作，而且前面 s09-s10 也已经证明它可以跑通。但它有一个很明显的问题：扩展性很差。

假设现在任务板上有下面这些任务：

Fix auth bug
Add rate limiter
Write tests
Update API docs
...

如果每一个任务都必须等 lead 亲自去看、去决定分给谁、再一条一条发出去，那么随着任务数量和 teammate 数量增加，lead 很快就会变成整个系统的瓶颈。也就是说，虽然表面上你有多个 teammate，但真实的调度能力仍然被锁死在唯一的中心节点里。

文档里把这个问题概括得非常到位：真正的自治，不应该是 “队友等着被告知该做什么”，而应该是 “队友自己扫描任务板，认领没人做的任务，做完再找下一个”。

更关键的是，这里还有一个前面几节已经埋下伏笔的问题：上下文压缩之后，智能体可能会忘记自己是谁。

s06 我们已经看到，长会话一定会发生 compact，原始上下文会被压缩掉。那如果一个 autonomous teammate 在空闲很久之后，重新因为自动认领任务而恢复工作，此时它的 messages 很可能已经只剩很短的尾巴。那它还能不能稳定记住：

• 自己叫什么名字
• 自己扮演什么角色
• 自己属于哪个 team
• 自己此刻应该继续干什么

如果没有额外机制，答案其实并不乐观。也就是说，自治并不只是“自己找活”这么简单，还必须解决一个更细节但非常关键的问题：

如果 Agent 是长期自主运行的，那在上下文被压缩之后，它必须还能重新确认自己的身份。

所以 s11 这一节真正想解决的问题，可以概括成两句话：

第一，teammate 不能只会等指派，而要能自己扫描任务板并认领工作。

第二，这种长期自治必须能跨越上下文压缩继续成立。

3. 解决方案

明确问题之后，s11 给出的解法非常漂亮，而且依然完全符合这个项目一贯的风格：不靠一个更强的中心调度器，不引入复杂的外部 orchestrator，而是让每个 teammate 在自己的循环中自然长出 “空闲—轮询—认领—工作” 的自治节奏。

文档里给出的整体生命周期非常清楚：

+-------+
| spawn |
+---+---+
    |
    v
+-------+   tool_use     +-------+
| WORK  | <------------- |  LLM  |
+---+---+                +-------+
    |
    | stop_reason != tool_use (or idle tool called)
    v
+--------+
|  IDLE  |  poll every 5s for up to 60s
+---+----+
    |
    +---> check inbox --> message? ----------> WORK
    |
    +---> scan .tasks/ --> unclaimed? -------> claim -> WORK
    |
    +---> 60s timeout ----------------------> SHUTDOWN

也就是说，从 s11 开始，teammate 的行为不再只是 “spawn 后执行一轮 loop，然后 idle 等待外部消息”，而是被明确拆成了两个阶段：

1. WORK phase

这部分和前面几节熟悉的 agent loop 很像。队友照常：

• 读 inbox
• 调模型
• 执行工具
• 把 tool_result 塞回上下文
• 持续工作

直到出现两种情况之一：

• 模型不再调用工具
• 或者模型主动调用了新的 idle 工具，明确表示 “我现在没活了，进入空闲阶段吧”

也就是说，WORK phase 仍然是一个标准 agent loop，只不过现在它多了一个显式的 “进入 idle” 出口。

2. IDLE phase

这才是 s11 真正的新东西。队友一旦进入 idle，并不会像前面那样 “静静挂着”，而是开始进入一个轮询周期：

• 每隔 5 秒醒一次
• 先看 inbox 里有没有新消息
• 如果有消息，立刻恢复到 WORK phase
• 如果没消息，就去扫描 .tasks/ 看板
• 如果发现有没人认领、未被阻塞的任务，就自动 claim
• 然后带着这条任务重新进入 WORK phase
• 如果持续 60 秒既没有消息也没有任务，就自动 shutdown

文档里把这一步概括得很直白：idle cycle with task board polling, auto-claiming unclaimed tasks。

这一步变化的意义其实非常大。因为从这里开始，teammate 的存在不再只是 “被动等工作”，而是：

• 有活时会干
• 没活时会自己去找
• 实在太久没活，才会退出

也就是说，系统里第一次真正出现了一种接近现实 worker 的自组织节奏。

除此之外，s11 还有一个非常细节但又非常关键的补丁：身份重注入（identity re-injection）。

文档里专门给出了这一段：

Identity re-injection after compression:
messages = [identity_block, ...remaining...]
"You are 'coder', role: backend, team: my-team"

它的作用非常明确：如果一个自治 agent 在 idle 了很久之后重新恢复工作，而这时候上下文已经被压缩得很短，那么系统会主动在 messages 开头插入一段 <identity>...</identity>，重新告诉模型：

• 你是谁
• 你的 role 是什么
• 你属于哪个 team
• 现在请继续你的工作

也就是说，自治能力和长期记忆的稳定性，是通过 identity re-injection 这一步被重新焊接起来的。

所以从解法角度看，s11 真正做的事情可以概括成三点：

1. 给 teammate 引入显式的 idle -> poll -> claim -> work 周期；

2. 让任务板第一次真正成为队友自己会去读取和认领的公共空间；

3. 用 identity re-injection 保证自治行为能跨越上下文压缩继续成立。

这意味着，到了 s11，这个项目已经不再只是一个 “lead 能管理多个 teammate” 的协作系统，而第一次真正长出了一种更接近自组织团队的能力：

队友不必等人安排，它们自己会在空闲时抬头看板，有活就主动认领。

4. Autonomous Agent Cycle 流程图分析

这一节教程配了 8 张 Autonomous Agent Cycle 的图。如果说 s10 的 FSM Team Protocols 图是在说明 “某些关键团队动作如何被建模成 request-response 状态机”，那么 s11 的这一组图，重点就在于说明：当没有人明确分配任务时，teammate 如何通过 idle-poll-claim-work 这个循环，自发地组织起团队工作。

先看第一张图。左边是一个 spatial view，有三个 agent：

• A
• B
• C

中间有一个 Task Board，上面显示：

• 4 unclaimed
• 0 complete

与此同时，左下角是任务表（Task Table）的详细信息，列出了每一个任务的状态与归属，例如：

• Fix auth bug
• Add rate limiter
• Write tests
• Update API docs

并且当前这些任务全部处于 unclaimed 状态，还没有被任何 agent 领取。

底部说明写的是：

Self-Governing Agents
Autonomous agents need no coordinator. They govern themselves with an idle-poll-claim-work cycle.

这张图对应的其实就是 s11 整节课最根本的出发点：自治的前提不是 “没有结构”，而是每个 agent 内部都有一套相同的行为循环。

这里最重要的不是某个任务已经被做掉，而是先把整个世界观建立起来了：任务板在中央，多个 agent 围绕它独立存在；而每个 agent 的内部行为，不靠外部统一驱动，而靠同一个 FSM cycle 自己反复转动。也就是说，s11 想强调的第一件事不是 “谁更聪明”，而是 “每个人都遵守同一套局部规则”。当局部规则一致时，后面才有可能从多个局部动作中涌现出全局秩序。

第二张图里，A 节点被橙色高亮，右侧 FSM 图里从 idle 指向 poll 的箭头也被点亮。底部说明写的是：

Idle Timer
Each idle agent counts rounds. A timeout triggers self-directed task polling.

这一张图把 “空闲” 从一种静止状态，变成了一种带时间感的状态。也就是说，idle 并不是 “什么都不做地挂着”，而是会计时，会在一定轮数 / 时间后主动触发 poll。换句话说，自治不是持续瞎忙，而是带节奏地醒来查看有没有新事要做。

这一步也说明了 s11 的一个核心设计哲学：系统不需要一个全局 coordinator 定时唤醒所有 agent，而是每个 agent 自己维护自己的 idle timer。谁先醒，谁先看；谁先看到可做的任务，谁就先认领。这里没有中央钟表，只有每个 agent 自己的本地节奏。

第三张图里，A 到 Task Board 之间出现了一条橙色虚线，右侧 FSM 中 poll 状态被高亮。底部说明写的是：

Poll Task Board
Timeout! The agent reads the task board looking for unclaimed work.

这一张图说明了 idle 之后的第一个自治动作：看板轮询。

注意，这里 agent 并不是去问 lead “我现在该做什么”，也不是先等 inbox 里有人给它发任务，而是直接自己去读任务板。这意味着从 s11 开始，.tasks/ 不再只是供 lead 或外部系统查看的状态目录，而第一次真正变成了 autonomous teammates 自己会去扫描和消费的公共任务空间。

也就是说，任务板开始从 “被管理的对象” 变成 “agent 自己的感知来源”。这一点非常重要，因为它标志着系统里第一次出现了 “工作不是被推送，而是被主动发现” 的能力。

第四张图里，A 节点被蓝色高亮，Task Board 上的第一条任务 Fix auth bug 已经变成：

• status = active
• owner = A

右侧 FSM 图中 claim 状态被高亮。底部说明写的是：

Claim Task
The agent writes its name to the task record. Atomic, no conflicts.

这一张图几乎把 s11 的核心升级讲透了。因为它说明 poll 到任务之后，并不是 “想做就做”，而是必须先 claim。而 claim 的含义，不是脑子里默默决定一下，而是把自己的名字正式写进任务记录，把：

• owner 设成自己
• status 改成 in_progress

这里那句 Atomic, no conflicts 也很重要，因为它明确在强调：认领不是一个松散意向，而是一次真正的、带并发安全保护的状态修改。也就是说，自治不是大家抢着做同一件事，而是靠 atomic claim 先占坑。

从系统视角看，这一步相当于把 “我准备做这个任务” 变成了 “任务记录上已经出现了我的名字”。从这一刻起，这件事不再只是某个 agent 脑子里的打算，而是任务板上的一个公开事实。

第五张图里，A 节点被绿色高亮，任务 Fix auth bug 仍然归 A 所有，右侧 FSM 中 work 状态被高亮。底部说明写的是：

Work
The agent works on the claimed task using its own agent loop.

这一张图说明 claim 之后并不会产生某种特殊新机制，agent 仍然回到自己熟悉的工作模式：自己的 loop、自己的工具、自己的上下文，只不过这次上下文里多了一条 “我刚刚自动认领了 Task #1” 的任务提示。

这其实非常漂亮，因为它说明 s11 的自治系统并不是造了一套完全新的工作流，而只是给原有 teammate loop 在前面加了一层：

• 先自己找活
• 再自己认领
• 最后仍然用原来的 agent loop 去干活

也就是说，自治调度和具体干活逻辑是解耦的。

系统并没有因为引入自治，就改变 agent 实际做任务时的基本模式；变化只发生在 “任务从哪来” 这个问题上。

第六张图里，A 继续在工作，B 也被蓝色高亮并朝任务板连出一条线。Task Board 现在显示：

• Fix auth bug → active / owner=A
• Add rate limiter → active / owner=B

底部说明写的是：

Independent Polling
Multiple agents poll and claim independently. No central coordinator needed.

这一张图特别重要，因为它第一次真正把 “自治” 从单个 agent 的行为提升成了一种群体级行为。

也就是说，A 并不需要先向 lead 汇报 “我做了第一个任务”，B 也不需要等 lead 再次调度。B 只是按自己那套 idle-poll-claim-work cycle，独立醒来，看板上发现还有其他未认领任务，于是自己认领了第二个任务。

这说明 s11 的真正价值，并不只是 “某个 agent 会自己去找活”，而是：

多个 agent 会在没有 central coordinator 的情况下，通过同一套本地规则，自然地把不同任务分散认领掉。

这就是 self-organization 开始出现的时刻。系统没有显式地说 “A 做第一个，B 做第二个”，但这种分工却自然发生了。

第七张图里，A 恢复成灰色 idle，B 仍然在绿色 work 状态。Task Board 上：

• Fix auth bug → complete / owner=A
• Add rate limiter → active / owner=B

底部说明写的是：

Complete & Reset
Task done. Agent returns to idle. The cycle repeats.

这一张图说明自治 agent 并不是一旦工作就持续忙下去，而是会在完成当前任务后重新回到 idle。也就是说，自治循环不是单向走一遍，而是一个真正不断重复的 cycle：

idle -> poll -> claim -> work -> idle -> ...

这一点很关键，因为它说明 agent 的自治性不是 “一次性自动认领”，而是长期存在的、自重复的行为模式。A 完成任务后并不会退出系统，而是准备在下一轮空闲计时结束后继续找下一个活。

最后第八张图里，C 也加入了认领，Task Board 现在变成：

• Fix auth bug → complete / owner=A
• Add rate limiter → active / owner=B
• Write tests → active / owner=C

底部说明写的是：

Self-Organization
Three agents, zero coordination overhead. Polling + timeout = emergent organization.

这张图其实就是对 s11 整节课的总结。它最重要的一点在于强调：这里没有出现一个新的 central planner，也没有出现某种隐藏调度器。所谓自组织，不是来自外部统一安排，而是来自每个 agent 本地都遵循同一个简单规则：

• 空闲时计时
• 时间到就去 poll
• 看见没人认领的任务就 claim
• 然后去 work
• 做完再回来 idle

多个 agent 同时遵守这个局部规则，最终就自然形成了全局上的任务分工。也就是说，自组织并不是额外加出来的一层，而是简单局部规则叠加之后涌现出来的全局秩序。

完整动画演示如下图所示：

5. 工作原理（代码分析）

看完流程图之后，接下来我们正式进入 agents/s11_autonomous_agents.py。和前面几节一样，文件顶部先给出了这一节的设计意图说明：

#!/usr/bin/env python3
# Harness: autonomy -- models that find work without being told.
"""
s11_autonomous_agents.py - Autonomous Agents

Idle cycle with task board polling, auto-claiming unclaimed tasks, and
identity re-injection after context compression. Builds on s10's protocols.
...
Key insight: "The agent finds work itself."
"""

这段注释其实已经把 s11 的主题说得非常清楚了。这里最重要的几个关键词是：

• Idle cycle
• task board polling
• auto-claiming unclaimed tasks
• identity re-injection after context compression

也就是说，s11 真正新增的，不只是 “teammate 会自己扫任务板”，而是一整套围绕自治运行设计出来的机制：有空闲阶段，有轮询节奏，有自动认领，也有为了长期运行而必须存在的身份重注入。 文件头部也明确写了，这一节是在 s10 protocol 基础上继续往前走，核心洞察是 The agent finds work itself.

初始化部分和 s10 非常像，依然有 .env、Anthropic client、WORKDIR、TEAM_DIR、INBOX_DIR，但这一节新增了两个非常关键的常量：

TASKS_DIR = WORKDIR / ".tasks"

POLL_INTERVAL = 5
IDLE_TIMEOUT = 60

这里几乎一眼就能看出 s11 的重心已经从纯通信进一步扩展到了 “任务板 + 轮询周期”。

TASKS_DIR 说明 autonomous teammates 会真正去读 .tasks/；POLL_INTERVAL 和 IDLE_TIMEOUT 则说明 idle 已经不再是一个抽象状态，而是一个明确带时间参数的阶段。

这一节首先新增的是任务板扫描与认领逻辑。

先看 scan_unclaimed_tasks()：

def scan_unclaimed_tasks() -> list:
    TASKS_DIR.mkdir(exist_ok=True)
    unclaimed = []
    for f in sorted(TASKS_DIR.glob("task_*.json")):
        task = json.loads(f.read_text())
        if (task.get("status") == "pending"
                and not task.get("owner")
                and not task.get("blockedBy")):
            unclaimed.append(task)
    return unclaimed

这一段代码特别关键，因为它正式把 .tasks/ 从 s07 的 “持久化任务图目录” 提升成了 s11 中 autonomous teammates 自己会主动消费的任务源。

这里最值得注意的是筛选条件。它并不是把所有任务都扫出来，而是只选满足下面三个条件的任务：

1. status == "pending"

2. 没有 owner

3. 没有 blockedBy

也就是说，只有那些还没开始、没人认领、不被前置依赖阻塞的任务，才会进入候选列表。

这一点把 s07 任务图里的 “依赖关系语义” 直接继承到了 s11 的自治认领系统中。换句话说，自治不是无脑抓任务，而是只会抓当前真正可执行的未认领任务。

再看 claim_task()：

def claim_task(task_id: int, owner: str) -> str:
    with _claim_lock:
        path = TASKS_DIR / f"task_{task_id}.json"
        if not path.exists():
            return f"Error: Task {task_id} not found"
        task = json.loads(path.read_text())
        task["owner"] = owner
        task["status"] = "in_progress"
        path.write_text(json.dumps(task, indent=2))
    return f"Claimed task #{task_id} for {owner}"

这一段正好对应前面流程图第四张图里的 Atomic, no conflicts。这里最关键的就是：

with _claim_lock:

也就是说，claim 并不是简单地读一下 JSON 再改一下字段，而是在锁保护下完成：

• 读取任务文件
• 写入 owner
• 写入 status = in_progress
• 原子性地保存回去

这意味着即便多个 autonomous agents 几乎同时看到同一个 unclaimed task，真正写入 owner 的那一刻仍然是串行保护的。也就是说，自组织并不意味着混乱抢活，而是靠一个很小但关键的 claim lock 维持最基本的并发安全。

接下来就是另一个很关键的新组件：身份重注入。

def make_identity_block(name: str, role: str, team_name: str) -> dict:
    return {
        "role": "user",
        "content": f"<identity>You are '{name}', role: {role}, team: {team_name}. Continue your work.</identity>",
    }

这一段虽然很短，但它其实是 s11 里非常有 “长期运行味道” 的一个设计。因为只有当 agent 会长期 idle、长期 resume、并且还会经历上下文压缩时，你才会真正需要去考虑：

它下次恢复工作时，会不会已经忘了自己是谁？

这里用 <identity>...</identity> 包一层，其实就是在给模型一个明确的、结构化的身份提醒。也就是说，身份不再只是 system prompt 开头的一次性描述，而在必要时会被重新插回上下文里，防止自治 agent 在长时间运行后出现 “角色漂移”。

教程文档里也把这一点说得很直接：上下文压缩之后智能体可能忘了自己是谁，身份重注入就是为了解决这个问题。

然后我们进入这一节最核心的代码：TeammateManager._loop()。

def _loop(self, name: str, role: str, prompt: str):
    team_name = self.config["team_name"]
    sys_prompt = (
        f"You are '{name}', role: {role}, team: {team_name}, at {WORKDIR}. "
        f"Use idle tool when you have no more work. You will auto-claim new tasks."
    )
    messages = [{"role": "user", "content": prompt}]
    tools = self._teammate_tools()

    while True:
        # -- WORK PHASE: standard agent loop --
        ...
        # -- IDLE PHASE: poll for inbox messages and unclaimed tasks --
        ...

这一段几乎就是 s11 整节课的灵魂。因为它第一次把 teammate loop 清清楚楚地拆成了：

• WORK PHASE
• IDLE PHASE

1. WORK phase

先看前半段：

for _ in range(50):
    inbox = BUS.read_inbox(name)
    for msg in inbox:
        if msg.get("type") == "shutdown_request":
            self._set_status(name, "shutdown")
            return
        messages.append({"role": "user", "content": json.dumps(msg)})
    try:
        response = client.messages.create(...)
    except Exception:
        self._set_status(name, "idle")
        return
    messages.append({"role": "assistant", "content": response.content})
    if response.stop_reason != "tool_use":
        break
    results = []
    idle_requested = False
    for block in response.content:
        if block.type == "tool_use":
            if block.name == "idle":
                idle_requested = True
                output = "Entering idle phase. Will poll for new tasks."
            else:
                output = self._exec(name, block.name, block.input)
            ...
    messages.append({"role": "user", "content": results})
    if idle_requested:
        break

你会发现，WORK phase 的主体其实仍然是我们从 s01 开始就已经非常熟悉的 agent loop：

• 读 inbox
• 调模型
• 检查 stop_reason
• 执行工具
• 回填 tool_result

也就是说，s11 并没有推翻前面所有 teammate loop 的工作方式。真正的变化主要有两点：

第一点，是 idle 工具。

从这一节开始，模型在 “我现在没事做了” 这个时刻，不再只能通过 stop_reason != "tool_use" 被动结束，而是可以主动调用一个显式工具：

{"name": "idle", ...}

这个工具的语义非常清楚：我现在不再继续当前工作了，请把我送进 idle polling phase。

这一步很重要，因为它把 “空闲” 从隐式终止状态，变成了一个显式的 agent 行为。

第二点，是 shutdown_request 的即时处理。

在 WORK phase 开头读 inbox 时，如果看到消息类型是：

"shutdown_request"

系统会直接：

self._set_status(name, "shutdown")
return

也就是说，s10 里的协议能力在 s11 并没有消失，而是继续沿用到了自治 teammate 身上。自治 agent 不是无法被管理，它只是平时自己找活；但一旦收到协议化的 shutdown_request，仍然会优先遵守组织规则。

2. IDLE phase

然后看后半段：

self._set_status(name, "idle")
resume = False
polls = IDLE_TIMEOUT // max(POLL_INTERVAL, 1)
for _ in range(polls):
    time.sleep(POLL_INTERVAL)
    inbox = BUS.read_inbox(name)
    if inbox:
        ...
        resume = True
        break
    unclaimed = scan_unclaimed_tasks()
    if unclaimed:
        task = unclaimed[0]
        claim_task(task["id"], name)
        task_prompt = (
            f"<auto-claimed>Task #{task['id']}: {task['subject']}\n"
            f"{task.get('description', '')}</auto-claimed>"
        )
        if len(messages) <= 3:
            messages.insert(0, make_identity_block(name, role, team_name))
            messages.insert(1, {"role": "assistant", "content": f"I am {name}. Continuing."})
        messages.append({"role": "user", "content": task_prompt})
        messages.append({"role": "assistant", "content": f"Claimed task #{task['id']}. Working on it."})
        resume = True
        break

if not resume:
    self._set_status(name, "shutdown")
    return
self._set_status(name, "working")

这一段可以说是 s11 的真正自治核心。

先看第一句：

self._set_status(name, "idle")

也就是说，teammate 一旦离开 WORK phase，系统就会正式把它在 team config 里的状态改成 idle。这不仅是运行时行为，也是外部可见状态。也就是说，队友此时是真正进入了团队意义上的空闲阶段。

接着：

polls = IDLE_TIMEOUT // max(POLL_INTERVAL, 1)

用默认值就是 60 // 5 = 12，也就是说，idle phase 最多会轮询 12 次，每次间隔 5 秒，总共等待 60 秒。

然后，idle phase 每轮先看 inbox：

inbox = BUS.read_inbox(name)
if inbox:
    ...
    resume = True
    break

这一点特别重要，因为它说明自治 teammate 虽然会自己找活，但它并没有脱离团队通信体系。也就是说，外部消息优先级仍然高于自动认领任务。只要 inbox 里来了新消息，它就会立刻恢复到 WORK phase，优先处理组织层面的输入。

如果 inbox 没消息，才会继续：

unclaimed = scan_unclaimed_tasks()
if unclaimed:
    task = unclaimed[0]
    claim_task(task["id"], name)
    ...
    resume = True
    break

这一步正对应前面流程图里的：

• poll
• claim
• work

也就是说，自治 agent 并不是无条件地一直 busy loop 扫任务板，而是在每次轮询周期里：

1. 先看看有没有团队消息

2. 没消息再看看任务板有没有可认领任务

3. 找到之后立刻 claim

4. 然后构造一条 <auto-claimed>...</auto-claimed> 的任务提示

5. 再把自己送回 WORK phase

这里那条 task prompt 也很有意思：

<auto-claimed>Task #id: subject ...</auto-claimed>

也就是说，自动认领之后，任务不会只是文件状态变了，还会被显式包装成一条新 user message 注入上下文，让模型知道：

• 我认领了哪个任务
• 任务主题是什么
• 任务描述是什么

这一步非常重要，因为它说明 claim 并不是系统偷偷替模型做掉的动作，而是会变成 agent 后续推理的一部分。

3. 身份重注入的真正接入点

然后再回头看这一段：

if len(messages) <= 3:
    messages.insert(0, make_identity_block(name, role, team_name))
    messages.insert(1, {"role": "assistant", "content": f"I am {name}. Continuing."})

这一段正是前面 make_identity_block() 真正用上的地方。

它的触发条件其实很巧妙，不是 “每次恢复工作都强制插入身份块”，而是只在：

len(messages) <= 3

也就是上下文已经非常短的时候才插。

这意味着系统是在用一个非常简单但实用的启发式来判断：如果 messages 已经短得不太像一段正常延续工作上下文了，那大概率发生了压缩或裁剪，此时应该把身份再补回来。

这种设计特别符合这个项目一贯的风格：不是搞很重的记忆系统，而是用一个小而有效的机制，在关键点上把系统稳定性补上。

4. 最终的自动关机

最后看 idle phase 的收束：

if not resume:
    self._set_status(name, "shutdown")
    return

这说明 autonomous teammate 也不是无期限永远活着。它的自治不是 “永远待命”，而是：

• 有活就继续干
• 有消息就恢复工作
• 一段时间里既没消息又没任务，就自动 shutdown

这一点其实非常合理，因为真正的自治系统也需要资源边界。如果一个 teammate 已经连续 60 秒什么都等不到，那它继续挂着的意义就很小了。也就是说，s11 给出的并不是 “无限后台常驻 agent”，而是一个更克制、更工程化的模型：自治，但不无限空转。

除了 _loop() 之外，这一节的 _exec() 也有一个很关键的新分支：

if tool_name == "claim_task":
    return claim_task(args["task_id"], sender)

这说明 claim_task 也被正式提升成了工具层的一等公民。

从这一刻起，“认领任务” 不再只是 harness 里的内部动作，而是可以被 agent 显式调用和理解的工具。教程文档里也明确说了，这一节相对 s10 最大的工具变化之一，就是新增了：

• idle
• claim_task

再看 _teammate_tools()，就更清楚了：

{"name": "idle", "description": "Signal that you have no more work. Enters idle polling phase.", ...}
{"name": "claim_task", "description": "Claim a task from the task board by ID.", ...}

这说明从 s11 开始，自治不再只是 loop 外围的隐藏逻辑，而是部分进入了模型自己的工具空间：

• 模型可以主动说 “我现在进入 idle”
• 模型也可以显式地说 “我要 claim 这个 task”

也就是说，自治从系统策略慢慢开始变成 agent 可操作的行为原语。

最后再看最外层 lead 的工具 dispatch。现在 lead 已经有 14 个工具：

TOOL_HANDLERS = {
    ...
    "shutdown_request": ...
    "shutdown_response": ...
    "plan_approval": ...
    "idle":              lambda **kw: "Lead does not idle.",
    "claim_task":        lambda **kw: claim_task(kw["task_id"], "lead"),
}

也就是说，s11 并没有因为强调 teammate 自治，就把 lead 完全排除掉。lead 仍然可以：

• 查看团队
• 发协议消息
• 甚至自己 claim task

但新的重点已经不再是 “lead 去逐一分配工作”，而是：

• lead 可以存在
• 但即使 lead 不去逐一派活，teammates 自己也能通过 idle-poll-claim-work 周期把任务板跑起来

这正是 s11 真正的升级点：团队开始具备去中心化地寻找工作的能力。

所以从代码角度看，s11 真正的价值并不只是 “多了两个工具”，也不只是 “teammate 会扫 .tasks/ 目录了”，而是第一次让这个项目在协作层面长出了非常重要的一种工程能力：

队友不仅会被分配工作，还会在空闲时自己发现工作、自己认领工作，并在长期运行中通过身份重注入保持自我连续性。

到了这一节，这个项目已经不再只是一个 lead + teammates + protocols 的协作系统了，它开始真正拥有一种更接近自治组织的协调观：局部规则足够简单，但多个 agent 同时遵守这些规则时，会自然涌现出任务分工。

博主在给定下面的提示词情况下：

Create 3 tasks on the board, then spawn alice and bob. Watch them auto-claim.

想通过调试看看整个过程发生了什么，我们来具体分析下：

Note：由于整个调试过程较长，因此下面我们只展示其中的关键部分。

Key 1: Lead 创建 3 个任务

Lead 第一次循环模型响应结果

Lead 第十一次循环模型响应结果

Lead 第十一次循环工具执行

Lead 第十二次循环模型响应结果

虽然我们的目标是 “创建任务并观察 autonomous teammates 自动认领”，但从 lead 的真实执行过程来看，它并不会一上来就立刻创建任务，而是仍然先沿着自己惯常的 agent loop 去理解环境、确认目录结构，然后才逐步推进到真正的任务创建动作。

先看 Lead 第一次循环模型响应结果。从图里可以看到，这一轮 response.content 仍然是典型的 “文本 block + 工具 block” 结构：前面的 TextBlock 里，lead 表示自己要先帮助创建任务并 spawn teammates，但第一步会先探索当前目录；后面的 ToolUseBlock 调用的是 bash，命令大意是：

pwd && ls -la

这一步其实非常符合前面几节一贯的风格：哪怕系统现在已经具备了自治能力，lead 仍然首先是一个正常的 coding/coordination agent，它会先确认环境，而不是盲目假设当前目录状态。也就是说，s11 引入的 “自治” 并没有让主线程失去谨慎性，lead 依然是在一个真实工程环境里按步骤做事。

然后看 Lead 第十一次循环模型响应结果。到了这一轮，lead 终于明确进入 “创建任务” 这个动作本身。图里可以看到，response.content[0] 是一个文本 block，大意是：

Now I need to create tasks. Let me use the task_create tool to create 3 tasks:

值得注意的是这里的工具 block 实际调用的是 bash，因为我们并没有把 s07 那套 task_create / task_update / task_list 工具暴露给 lead。

再看 Lead 第十一次循环工具执行 这张图。这里最值得注意的是：lead 在 bash 中直接运行了一段较长的 Python 代码，核心逻辑大致是：

• 初始化 .tasks/ 目录
• 构造 3 条任务记录
• 为每条任务分配 id
• 写出 task_1.json、task_2.json、task_3.json

而工具结果中也明确返回了三条创建信息，例如：

• Created task: Fix login bug
• Created task: Add user profile page
• Created task: Improve API documentation

从这一刻开始，自治团队后面要消费的公共任务空间已经被真正建立起来了。

接着看 Lead 第十一次循环工具执行结果。图中已经能直接看到 .tasks/ 目录下新增了三个文件：

• task_1.json
• task_2.json
• task_3.json

并且它们的内容都已经初始化为：

• status = "pending"
• blockedBy = []
• blocks = []
• owner = ""

这正好对应了后面 scan_unclaimed_tasks() 的筛选条件。也就是说，lead 创建出来的不只是三段文本描述，而是三条完全符合自治系统扫描规则的任务记录。换句话说，任务板此时已经处于一种 “等待被 autonomous teammate 发现” 的状态了。

最后再看 Lead 第十二次循环模型响应结果，此时模型已经创建了三个任务，想要验证下刚创建的三个任务是否存在。

Key 2: Lead spawn 2 个 teammate

Lead 第十三次循环模型响应结果

Lead 第十四次循环模型响应结果

Lead 第十五次循环模型响应结果

Lead 新建的 teammate 信息

接下来这一部分，对应的是 s11 从 “任务板已经存在” 过渡到 “自治成员正式上线”。

先看 Lead 第十三次循环模型响应结果。这一轮文本 block 里，lead 明确表示自己接下来要 spawn autonomous teammates Alice 和 Bob；但是在 spawn 之前，先调用了 list_teammates。这一点很有意思，因为它说明主线程在把系统推进到 “多 teammate 自治团队” 之前，仍然会做一次中间确认：先看当前 team roster 是什么状态。换句话说，lead 并不是无脑连续 spawn，而是会在中间插入检查动作。

再看 Lead 第十四次循环模型响应结果。lead 开始 spawn Alice 和 Bob；而工具 block 调用的是：

spawn_teammate(
    name="alice",
    role="Senior Backend Developer",
    prompt="You are Alice ... autonomously find and claim tasks ..."
)

这里最重要的不是 spawn_teammate 这个名字本身，而是传给 Alice 的 prompt 内容已经明显和 s09、s10 时期不同了。此时 Alice 不再只是一个 “等着被指定任务的 coder”，而是在 prompt 中被明确要求：

• 自主查找 task board
• 自主认领与后端相关的任务
• 做完一个任务后再继续找下一个
• 必要时通过 send_message 与队友沟通

也就是说，从 spawn 开始，自治逻辑其实就已经被写进 teammate 的初始行为设定里了。

然后到了 Lead 第十五次循环模型响应结果，Lead 才继续把第二个 teammate — Bob 拉起来。

最后看 Lead 新建的 teammate 信息。图里 .team/config.json 已经清楚显示出了两条成员记录：

{
  "name": "alice",
  "role": "Senior Backend Developer",
  "status": "working"
},
{
  "name": "bob",
  "role": "Frontend Developer",
  "status": "working"
}

lead 到这里为止，已经完成了两件自治系统启动前的必要准备：

1. 建立好公共任务板；

2. 建立好会自己去轮询任务板的自治队友。

从这一刻开始，后面的 “自动认领” 就不再依赖 lead 继续逐一指派了。

Key 3: Alice、Bob 准备开始认领工作，Lead 确认一切正常

Alice 第一次循环模型响应结果

Bob 第一次循环模型响应结果

Lead 第十六次循环模型响应结果

Lead 第十七次循环模型响应结果

这一部分其实特别能体现 s11 和前面章节的根本区别：从这里开始，lead 已经不再是唯一在主动推进系统的人，Alice 和 Bob 也开始在自己的线程里独立运转了。

先看 Alice 第一次循环模型响应结果。图里可以看到，Alice 的 messages 里最初只有 spawn 时塞进去的那条用户提示；随后她第一次调用模型，返回的 response.content 同样是 “文本 block + 工具 block”。文本 block 中，Alice 说的是：

I'll start by checking available tasks. Let me first look at the task board to see what tasks are available.

后面的工具 block 则调用了 bash，命令是 ls -la。

也就是说，Alice 虽然被赋予了 “自治找活” 的能力，但她并不是一启动就直接 claim 某个任务，而是先沿着自己的 agent 风格去检查环境和任务相关信息。这一点其实和前面 s08~s10 的各种 teammate 行为非常一致：自治并没有让 agent 失去探索步骤，它只是把 “接下来该做什么” 的决策权从 lead 手里交还给了 teammate 自己。

再看 Bob 第一次循环模型响应结果。Bob 的行为模式和 Alice 很像：他同样在自己的第一轮里先表达 “我要先检查可用任务”，随后调用 bash 去查看目录结构。也就是说，两个 autonomous teammate 一启动，并不是立刻被 lead 指定不同任务，而是都先以自己的上下文去感知当前环境和任务板。

然后看 Lead 第十六次循环模型响应结果。这时 lead 自己并没有继续去给 Alice 或 Bob 指派任务，而是开始做确认动作。图里显示，这一轮 lead 选择调用：

list_teammates()

这一步很有意思，因为它说明在 autonomous system 里，lead 的角色开始悄悄发生变化：它不再是 “继续派活的人”，而更像是 “观察当前系统状态的人”。也就是说，自治团队启动后，lead 更多是在做检查、监控，而不是继续亲自把工作往下发。

最后再看 Lead 第十七次循环模型响应结果。这一轮 lead 又继续调用了：

read_inbox()

并且文本 block 的大意是：

Now let me check if there's any activity in the inboxes to see if they're communicating or claiming tasks.

这一点特别有代表性，因为它说明到了 s11，lead 对团队的观察重点已经变成了两类东西：

• 当前 teammate 状态是否正常
• inbox / task board 上有没有出现新的自治活动痕迹

换句话说，主线程此时更多是在 “看自治系统是不是已经自己跑起来了”，而不是亲自推动它继续往前走。

Key 4: Bob 认领 Task2 任务开始正式工作

Bob 第六次循环模型响应结果（认领 task2）

Bob 第六次循环 claim_task 工具执行

Bob 第六次循环工具执行结果

Bob 第七次循环模型响应结果（正式开始去完成 task2）

先看 Bob 第六次循环模型响应结果。图里可以非常清楚地看到，这一轮 Bob 的 response.content 仍然是 “文本 block + 工具 block” 的组合，但文本 block 的语义已经发生了质变。Bob 明确说：

As a frontend developer, I should claim task 2: "Add user profile page" ...
Let me claim this task.

后面的工具 block 直接调用的是：

claim_task(task_id=2)

这一点特别重要，因为它说明 Bob 这时不是被 lead 告知 “你去做 task2”，而是 他自己在当前上下文里判断：task2 更符合自己的前端角色，因此主动决定去认领它。

这正是 s11 自治性的核心：任务分工不是外部安排出来的，而是由 agent 在本地依据角色、任务内容和当前看板状态自己做出的。

再看 Bob 第六次循环 claim_task 工具执行。调试图里停在了：

def claim_task(task_id: int, owner: str):
    with _claim_lock:
        ...
        task["owner"] = owner
        task["status"] = "in_progress"
        path.write_text(...)
    return f"Claimed task #{task_id} for {owner}"

下方打开的 task_2.json 已经清楚显示出变化后的任务内容：

{
  "id": 2,
  "subject": "Add user profile page",
  "description": "...",
  "status": "in_progress",
  "owner": "bob"
}

从这一刻开始，task2 已经不再是 unclaimed 的公共任务，而是一个被 Bob 占有、正在执行中的任务。也就是说，claim 把 “我的意图” 变成了 “系统事实”。

再看 Bob 第六次循环工具执行结果。这里的 tool_result 很直接：

Claimed task #2 for bob

最后看 Bob 第七次循环模型响应结果。到了这一轮，Bob 已经不再围绕 “我要不要认领任务” 打转，而是明确进入了 “开始工作” 的阶段，大意是：

Great! Now I've claimed task 2.
Let me first explore the project structure to understand what we're working with.

这一步其实正好对应前面流程图里的：

poll -> claim -> work

Bob 并不是被额外切换到一个特殊执行器里，而是：

1. 先在自己的上下文里发现适合自己的任务

2. 用 claim_task 正式占有它

3. 然后继续沿用自己熟悉的 agent loop 去真正完成它

这说明 s11 的自治并不是 “系统替 agent 分配任务”，而是 agent 自己在本地观察任务板、基于角色做判断、通过 claim_task 把选择写成系统事实，然后再回到标准 work loop 中继续干活。

Key 5: Lead 确认 Alice、Bob 有认领任务并工作

Lead 第十八次循环模型响应结果

Lead 第十九次循环模型响应结果

这一部分其实非常能体现 s11 中 lead 角色的变化：当 autonomous teammates 真正开始工作之后，lead 的主要职责已经不再是继续派活，而是转向 “观察、验证、监控” 整个自治系统是否按预期运转。

Key 6: Alice 认领 Task1 任务开始正式工作

Alice 第六次循环模型响应结果（认领 task1）

Alice 第六次循环 claim_task 工具执行

Alice 第六次循环工具执行结果

Alice 第七次循环模型响应结果（正式开始去完成 task2）

这一部分和前面 Bob 认领 Task2 的过程正好形成了非常漂亮的对照，因为它进一步说明：多个 autonomous teammates 并不是随机乱抢任务，而是在自己的局部上下文里，根据角色偏好和当前任务板状态，自然地做出了不同的分工选择。

整个任务认领流程和 Bob 认领 Task2 非常像，因此这里我们就跳过分析了。

Key 7: Lead 时刻监控 Alice 和 Bob 状态

Lead 第二十三次循环模型响应结果

Lead 第二十四次循环模型响应结果

Lead 第二十五次循环模型响应结果

这一部分调试进一步强化了我们前面已经看到的一个趋势：到了 s11，lead 更像是在围绕 “状态可见性” 工作，而不是围绕 “任务分配权” 工作。

Key 8: Bob 完成 Task2 后认领 Task3，并在完成后发送消息给 Lead

Bob 新认领 Task3

Bob 认领 Task3 工具执行

Bob 认领完 Task3 工具执行结果

Bob 完成 Task3 后发送消息给 Lead

这一部分可以说是整个调试里最能体现 s11 “自治循环会持续重复” 的地方，因为它不只是展示了一次 auto-claim，而是展示了 同一个 teammate 完成一个任务之后，又继续发现并认领下一个任务 的完整过程。

先看 Bob 新认领 Task3。图里的文本 block 其实已经把这件事讲得非常清楚了：Bob 此时并不是刚启动的新 teammate，而是在完成了 Task2 之后，重新回到了 “看看还有没有新活可做” 的自治判断状态，然后直接调用：

claim_task(task_id=3)

这一点特别漂亮，因为它说明 Bob 的自治并不是 “一次性找到一个适合自己的任务就结束”，而是真的具备了循环工作的能力：

完成 Task2 -> 再看板 -> 再判断 -> 再认领 Task3

再看 Bob 认领 Task3 工具执行。调试图里停在 claim_task() 内部，这一次打开的是 task_3.json，其内容已经清楚变成：

{
  "id": 3,
  "subject": "Update README documentation",
  "status": "in_progress",
  "owner": "bob"
}

与此同时，下方还可以看到 task_2.json 已经被改成了：

"status": "completed",
"owner": "bob"

这一组状态对照非常有价值，因为它把 s11 的自治循环完整地展示出来了：

• Task2：Bob 已经做完，状态是 completed
• Task3：Bob 刚刚接手，状态是 in_progress

也就是说，同一个 agent 已经在任务板上完成了一次 “完成旧任务 → 再认领新任务” 的状态接力。

再看 Bob 认领完 Task3 工具执行结果。这里返回的是：

Claimed task #3 for bob

这说明 claim 已经正式成功，而 Bob 的上下文也会基于这条结果继续往下推理下一步怎么做。

最后看 Bob 完成 Task3 后发送消息给 Lead。这张图特别重要，因为它说明 s11 的自治系统并不是 “只会自己埋头干活”，而是仍然保留了团队沟通能力。图里可以看到，Bob 在完成文档任务之后，文本 block 先说：

Now let me send a message about completing the documentation task

接着调用了：

send_message(to="lead", content="I've completed task #3 ...")

而消息内容并不是一句简单的 “做完了”，而是带有相当详细的工作总结，这说明 s11 的 autonomous teammate 并不是与团队断开连接的 “独狼”，而是：

• 平时可以自己找活
• 自己做完
• 但做完之后仍然会通过 inbox 把结果汇报回团队

也就是说，s11 的自治不是去掉团队，而是让团队成员在保持通信能力的前提下，减少对中心显式分配的依赖。

由于篇幅内容的限制，后续的调试内容博主这里就不一一展示了，大家可以自己多尝试尝试，看看整个过程发送了什么，是否和自己想象的存在偏差。

不过，从上面这些部分的调试分析，其实已经足够把 s11 最核心的几件事情看得非常清楚了：

首先，lead 并不是完全消失了，而是把自己的角色从 “持续派活的人” 逐步让渡成了 “观察、确认、监控系统状态的人”；

其次，Alice 和 Bob 也不是随机乱抢任务，而是会结合自己的角色定位、当前任务板状态以及其他 teammate 已经占有的任务，逐渐形成一种互补分工；

再次，这种分工并不是一次性静态完成的，而会随着任务完成不断重复，形成真正的 idle -> poll -> claim -> work -> idle 自治循环；

最后，自治并不等于沉默，teammate 在完成关键任务后依然会通过 send_message 向 lead 反馈工作结果，从而把 “自组织执行” 和 “团队可见性” 连接起来。

也就是说，s11 这一节最值得我们记住的一点其实是：

自治系统不是把 lead 去掉，也不是把通信去掉，而是把 “任务如何被发现与分配” 这件事情，从中央调度中解放出来，交给多个 teammate 在共享任务板上自己完成。

这正是为什么 s11 会成为整个 Collaboration 部分里一个非常重要的转折点。到了这里，团队终于开始不只是 “有人、有邮箱、有协议”，而是开始像一个真正会自己找活、自己分工、自己推进的组织。

OK，以上就是 Autonomous Agents 工作原理的完整分析了。

大家也可以试试文档里给出的这些 prompt，感受一下自治能力引入之后，这个 Agent 团队在协作方式上会有什么变化：

1. Create 3 tasks on the board, then spawn alice and bob. Watch them auto-claim.

2. Spawn a coder teammate and let it find work from the task board itself

3. Create tasks with dependencies. Watch teammates respect the blocked order.

4. 输入 /tasks 查看带 owner 的任务看板

5. 输入 /team 监控谁在工作、谁在空闲。

6. 相对 s10 的变更

组件	之前 (s10)	之后 (s11)
Tools	12	14 (+idle, +claim_task)
自治性	领导指派	自组织
空闲阶段	无	轮询收件箱 + 任务看板
任务认领	仅手动	自动认领未分配任务
身份	系统提示	+ 压缩后重注入
超时	无	60 秒空闲 -> 自动关机

7. 小结

如果说 s10 最大的贡献，是让多 Agent 团队第一次从 “会发消息” 升级成 “在关键动作上必须走 request-response 协议” 的协作系统；那么 s11 的贡献就是让我们进一步意识到：真正可扩展的团队，不应该永远依赖 lead 逐一分配任务，而应该允许 teammate 自己在空闲时去发现并认领工作。

前面 s09-s10 里，teammate 虽然已经是持久存在的成员，也已经有 inbox 和 protocol，但从行动起点上看，仍然很依赖外部指派；到了 s11，系统第一次正式引入了 idle、claim_task、任务板扫描、claim lock、idle timeout 和 identity re-injection 这一整套自治运行机制。

所以，s11 真正的价值并不只是 “让 agent 自己扫一下任务目录”，也不只是 “多了个 idle 状态”，而是第一次把这个项目从一个 需要中心持续驱动的协作团队，推进成了一个开始具备 自组织能力的协作团队。从这一节开始，任务分工不再完全依赖外部安排，而开始能够从多个 autonomous teammates 各自遵循的简单局部规则中自然涌现出来。也就是说，团队开始不只是 “被组织”，而是开始 “自组织”。

这一步其实非常关键，因为它为后面的 worktree task isolation 等机制继续往上搭建，提供了一个真正自治的执行底座：如果队友自己不会找活，那再好的隔离环境也只是更高级的被动执行器；而一旦队友自己会找活，整个系统才真正开始像一个会自己运转的团队。

OK，以上就是本期想要分享的全部内容了。

结语

本篇文章我们围绕 s11 Autonomous Agents 这一节，从问题出发，结合流程图与代码实现，完整梳理了 Agent 团队是如何从 “被动执行” 演进为 “主动寻找工作的自治系统” 的。

相比前面的章节，这一节最本质的变化不再是能力增强或结构补全，而是第一次真正引入了 “自治”：teammate 不再依赖 lead 持续分配任务，而是在空闲阶段通过 idle-poll-claim-work 这一循环，自主扫描任务板、认领工作并持续推进。这使得系统的运行不再完全依赖中心节点，而开始具备去中心化的执行能力。

从工程视角来看，这一步的关键在于：任务的 “发现与分配” 从外部调度，转移到了 agent 自身的局部决策之中。每个 teammate 只需遵循简单的本地规则 — 空闲计时、轮询任务、原子认领、完成后返回空闲 — 多个 agent 同时运行时，就会自然形成全局上的任务分工。这种分工并不是显式设计出来的，而是从局部规则中 “涌现” 出来的。

进一步来看，s11 实际上完成了一次非常重要的范式跃迁：前面的章节一直在解决 “如何让系统更可控、更可组织”，而到了这里，系统开始回答一个更深层的问题 — 在没有持续外部控制的情况下，系统能否自己稳定运行。通过任务板、claim 机制与 identity re-injection 的结合，Agent 不仅能够自己找活，还能够在上下文压缩后保持身份连续性，从而支持长期自治运行。

也正因为如此，Autonomous Agents 的意义并不只是 “让队友自己干活”，而是让整个系统第一次具备了接近真实组织的运行形态：成员可以长期存在、在空闲时主动寻找工作、在完成任务后继续参与分工，并在无需中心调度的情况下维持整体运转。

下篇文章我们将来学习最后一个章节 s12 Worktree + Task Isolation 的内容，敬请期待🤗

参考

• https://github.com/shareAI-lab/learn-claude-code