Learn_Claude_Code_完整课程笔记
Learn Claude Code - 完整课程笔记
来源:https://learn.shareai.run/zh/timeline/
一套从零开始学习 Claude Code 智能体构建的进阶课程,共12个章节,从最基础的 Agent 循环逐步构建出完整的自主多智能体协作系统。
目录
- 第一章:Agent 循环(s01)
- 第二章:工具(s02)
- 第三章:TodoWrite(s03)
- 第四章:子 Agent(s04)
- 第五章:技能(s05)
- 第六章:上下文压缩(s06)
- 第七章:任务系统(s07)
- 第八章:后台任务(s08)
- 第九章:Agent 团队(s09)
- 第十章:团队协议(s10)
- 第十一章:自主 Agent(s11)
- 第十二章:Worktree + 任务隔离(s12)
第一章:Agent 循环(s01)
分类: 工具与执行 | 副标题: Bash is All You Need
代码量: 84 行 | 工具数: 1
“One loop & Bash is all you need” – 一个工具 + 一个循环 = 一个智能体。
The While Loop
Every agent is a while loop that keeps calling the model until it says ‘stop’.
学习路径: s01 → s02 → s03 → s04 → s05 → s06 | s07 → s08 → s09 → s10 → s11 → s12
问题
语言模型能推理代码,但碰不到真实世界 – 不能读文件、跑测试、看报错。没有循环,每次工具调用你都得手动把结果粘回去。你自己就是那个循环。
解决方案
1 | +--------+ +-------+ +---------+ |
一个退出条件控制整个流程。循环持续运行,直到模型不再调用工具。
工作原理
1. 用户 prompt 作为第一条消息。
1 | messages.append({"role": "user", "content": query}) |
2. 将消息和工具定义一起发给 LLM。
1 | response = client.messages.create( |
3. 追加助手响应。检查 stop_reason – 如果模型没有调用工具,结束。
1 | messages.append({"role": "assistant", "content": response.content}) |
4. 执行每个工具调用,收集结果,作为 user 消息追加。回到第 2 步。
1 | results = [] |
组装为一个完整函数:
1 | def agent_loop(query): |
不到 30 行,这就是整个智能体。后面 11 个章节都在这个循环上叠加机制 – 循环本身始终不变。
变更内容
| 组件 | 之前 | 之后 |
|---|---|---|
| Agent loop | (无) | while True + stop_reason |
| Tools | (无) | bash (单一工具) |
| Messages | (无) | 累积式消息列表 |
| Control flow | (无) | stop_reason != "tool_use" |
试一试
1 | cd learn-claude-code |
试试这些 prompt(英文 prompt 对 LLM 效果更好,也可以用中文):
Create a file called hello.py that prints "Hello, World!"List all Python files in this directoryWhat is the current git branch?Create a directory called test_output and write 3 files in it
第二章:工具(s02)
分类: 工具与执行 | 副标题: 工具分发映射
代码量: 120 行 | 工具数: 4
“加一个工具,只加一个 handler” – 循环不用动,新工具注册进 dispatch map 就行。
The Dispatch Map
A dictionary maps tool names to handler functions. The loop code never changes.
工具列表:
bash- Execute shell commandsread_file- Read file contentswrite_file- Create or overwrite a fileedit_file- Apply targeted edits
问题
只有 bash 时,所有操作都走 shell。cat 截断不可预测,sed 遇到特殊字符就崩,每次 bash 调用都是不受约束的安全面。专用工具(read_file、write_file)可以在工具层面做路径沙箱。
关键洞察: 加工具不需要改循环。
解决方案
1 | +--------+ +-------+ +------------------+ |
The dispatch map is a dict: {tool_name: handler_function}。One lookup replaces any if/elif chain.
工作原理
1. 每个工具有一个处理函数。路径沙箱防止逃逸工作区。
1 | def safe_path(p: str) -> Path: |
1 | def run_read(path: str, limit: int = None) -> str: |
2. dispatch map 将工具名映射到处理函数。
1 | TOOL_HANDLERS = { |
3. 循环中按名称查找处理函数。循环体本身与 s01 完全一致。
1 | for block in response.content: |
原则: 加工具 = 加 handler + 加 schema。循环永远不变。
变更内容
| 组件 | 之前 (s01) | 之后 (s02) |
|---|---|---|
| Tools | 1(仅 bash) | 4(bash, read, write, edit) |
| Dispatch | 硬编码 bash 调用 | TOOL_HANDLERS 字典 |
| 路径安全 | 无 | safe_path() 沙箱 |
| Agent loop | 不变 | 不变 |
试一试
1 | cd learn-claude-code |
Read the file requirements.txtCreate a file called greet.py with a greet(name) functionEdit greet.py to add a docstring to the functionRead greet.py to verify the edit worked
第三章:TodoWrite(s03)
分类: 规划与协调 | 副标题: TodoWrite 提醒系统
代码量: 176 行 | 工具数: 5
“没有计划的 agent 走哪算哪” – 先列步骤再动手,完成率翻倍。
问题
多步任务中,模型会丢失进度 – 重复做过的事、跳步、跑偏。对话越长越严重:工具结果不断填满上下文,系统提示的影响力逐渐被稀释。一个 10 步重构可能做完 1-3 步就开始即兴发挥,因为 4-10 步已经被挤出注意力了。
解决方案
1 | +--------+ +-------+ +---------+ |
工作原理
1. TodoManager 存储带状态的项目。同一时间只允许一个 in_progress。
1 | class TodoManager: |
2. todo 工具和其他工具一样加入 dispatch map。
1 | TOOL_HANDLERS = { |
3. nag reminder:模型连续 3 轮以上不调用 todo 时注入提醒。
1 | if rounds_since_todo >= 3 and messages: |
“同时只能有一个 in_progress” 强制顺序聚焦。nag reminder 制造问责压力 – 你不更新计划,系统就追着你问。
变更内容
| 组件 | 之前 (s02) | 之后 (s03) |
|---|---|---|
| Tools | 4 | 5(+todo) |
| 规划 | 无 | 带状态的 TodoManager |
| Nag 注入 | 无 | 3 轮后注入 <reminder> |
| Agent loop | 简单分发 | + rounds_since_todo 计数器 |
试一试
1 | cd learn-claude-code |
Refactor the file hello.py: add type hints, docstrings, and a main guardCreate a Python package with __init__.py, utils.py, and tests/test_utils.pyReview all Python files and fix any style issues
第四章:子 Agent(s04)
分类: 规划与协调 | 副标题: 子 Agent 上下文隔离
代码量: 151 行 | 工具数: 5
“大任务拆小,每个小任务干净的上下文” – 子智能体用独立 messages[],不污染主对话。
问题
智能体工作越久,messages 数组越胖。每次读文件、跑命令的输出都永久留在上下文里。”这个项目用什么测试框架?” 可能要读 5 个文件,但父智能体只需要一个词:”pytest。”
解决方案
1 | Parent agent Subagent |
工作原理
1. 父智能体有一个 task 工具。子智能体拥有除 task 外的所有基础工具(禁止递归生成)。
1 | PARENT_TOOLS = CHILD_TOOLS + [ |
2. 子智能体以 messages=[] 启动,运行自己的循环。只有最终文本返回给父智能体。
1 | def run_subagent(prompt: str) -> str: |
子智能体可能跑了 30+ 次工具调用,但整个消息历史直接丢弃。父智能体收到的只是一段摘要文本,作为普通 tool_result 返回。
变更内容
| 组件 | 之前 (s03) | 之后 (s04) |
|---|---|---|
| Tools | 5 | 5(基础)+ task(仅父端) |
| 上下文 | 单一共享 | 父 + 子隔离 |
| Subagent | 无 | run_subagent() 函数 |
| 返回值 | 不适用 | 仅摘要文本 |
试一试
1 | cd learn-claude-code |
Use a subtask to find what testing framework this project usesDelegate: read all .py files and summarize what each one doesUse a task to create a new module, then verify it from here
第五章:技能(s05)
分类: 规划与协调 | 副标题: 按需技能加载
代码量: 187 行 | 工具数: 5
“用到什么知识,临时加载什么知识” – 通过 tool_result 注入,不塞 system prompt。
问题
你希望智能体遵循特定领域的工作流:git 约定、测试模式、代码审查清单。全塞进系统提示太浪费 – 10 个技能,每个 2000 token,就是 20,000 token,大部分跟当前任务毫无关系。
解决方案
1 | System prompt (Layer 1 -- always present): |
第一层:系统提示中放技能名称(低成本)。第二层:tool_result 中按需放完整内容。
工作原理
1. 每个技能是一个目录,包含 SKILL.md 文件和 YAML frontmatter。
1 | skills/ |
2. SkillLoader 递归扫描 SKILL.md 文件,用目录名作为技能标识。
1 | class SkillLoader: |
3. 第一层写入系统提示。第二层不过是 dispatch map 中的又一个工具。
1 | SYSTEM = f"""You are a coding agent at {WORKDIR}. |
模型知道有哪些技能(便宜),需要时再加载完整内容(贵)。
变更内容
| 组件 | 之前 (s04) | 之后 (s05) |
|---|---|---|
| Tools | 5(基础 + task) | 5(基础 + load_skill) |
| 系统提示 | 静态字符串 | + 技能描述列表 |
| 知识库 | 无 | skills/*/SKILL.md 文件 |
| 注入方式 | 无 | 两层(系统提示 + result) |
试一试
1 | cd learn-claude-code |
What skills are available?Load the agent-builder skill and follow its instructionsI need to do a code review -- load the relevant skill firstBuild an MCP server using the mcp-builder skill
第六章:上下文压缩(s06)
分类: 内存管理 | 副标题: 三层上下文压缩
代码量: 205 行 | 工具数: 5
“上下文总会满,要有办法腾地方” – 三层压缩策略,换来无限会话。
问题
上下文窗口是有限的。读一个 1000 行的文件就吃掉 ~4000 token;读 30 个文件、跑 20 条命令,轻松突破 100k token。不压缩,智能体根本没法在大项目里干活。
解决方案
三层压缩,激进程度递增:
1 | Every turn: |
工作原理
1. 第一层 – micro_compact: 每次 LLM 调用前,将旧的 tool result 替换为占位符。
1 | def micro_compact(messages: list) -> list: |
2. 第二层 – auto_compact: token 超过阈值时,保存完整对话到磁盘,让 LLM 做摘要。
1 | def auto_compact(messages: list) -> list: |
3. 第三层 – manual compact: compact 工具按需触发同样的摘要机制。
4. 循环整合三层:
1 | def agent_loop(messages: list): |
完整历史通过 transcript 保存在磁盘上。信息没有真正丢失,只是移出了活跃上下文。
变更内容
| 组件 | 之前 (s05) | 之后 (s06) |
|---|---|---|
| Tools | 5 | 5(基础 + compact) |
| 上下文管理 | 无 | 三层压缩 |
| Micro-compact | 无 | 旧结果 → 占位符 |
| Auto-compact | 无 | token 阈值触发 |
| Transcripts | 无 | 保存到 .transcripts/ |
试一试
1 | cd learn-claude-code |
Read every Python file in the agents/ directory one by one(观察 micro-compact 替换旧结果)Keep reading files until compression triggers automaticallyUse the compact tool to manually compress the conversation
第七章:任务系统(s07)
分类: 规划与协调 | 副标题: 任务依赖图
代码量: 207 行 | 工具数: 8
“大目标要拆成小任务,排好序,记在磁盘上” – 文件持久化的任务图,为多 agent 协作打基础。
问题
s03 的 TodoManager 只是内存中的扁平清单:没有顺序、没有依赖、状态只有做完没做完。真实目标是有结构的 – 任务 B 依赖任务 A,任务 C 和 D 可以并行,任务 E 要等 C 和 D 都完成。
没有显式的关系,智能体分不清什么能做、什么被卡住、什么能同时跑。而且清单只活在内存里,上下文压缩(s06)一跑就没了。
解决方案
把扁平清单升级为持久化到磁盘的任务图。每个任务是一个 JSON 文件,有状态、前置依赖(blockedBy)和后置依赖(blocks)。任务图随时回答三个问题:
- 什么可以做? – 状态为
pending且blockedBy为空的任务。 - 什么被卡住? – 等待前置任务完成的任务。
- 什么做完了? – 状态为
completed的任务,完成时自动解锁后续任务。
1 | .tasks/ |
这个任务图是 s07 之后所有机制的协调骨架:后台执行(s08)、多 agent 团队(s09+)、worktree 隔离(s12)都读写这同一个结构。
工作原理
1. TaskManager: 每个任务一个 JSON 文件,CRUD + 依赖图。
1 | class TaskManager: |
2. 依赖解除: 完成任务时,自动将其 ID 从其他任务的 blockedBy 中移除,解锁后续任务。
1 | def _clear_dependency(self, completed_id): |
3. 状态变更 + 依赖关联: update 处理状态转换和依赖边。
1 | def update(self, task_id, status=None, |
4. 四个任务工具加入 dispatch map。
1 | TOOL_HANDLERS = { |
从 s07 起,任务图是多步工作的默认选择。s03 的 Todo 仍可用于单次会话内的快速清单。
变更内容
| 组件 | 之前 (s06) | 之后 (s07) |
|---|---|---|
| Tools | 5 | 8(task_create/update/list/get) |
| 规划模型 | 扁平清单(仅内存) | 带依赖关系的任务图(磁盘) |
| 关系 | 无 | blockedBy + blocks 边 |
| 状态追踪 | 做完没做完 | pending → in_progress → completed |
| 持久化 | 压缩后丢失 | 压缩和重启后存活 |
试一试
1 | cd learn-claude-code |
Create 3 tasks: "Setup project", "Write code", "Write tests". Make them depend on each other in order.List all tasks and show the dependency graphComplete task 1 and then list tasks to see task 2 unblockedCreate a task board for refactoring: parse -> transform -> emit -> test, where transform and emit can run in parallel after parse
第八章:后台任务(s08)
分类: 并发 | 副标题: 后台任务通道
代码量: 198 行 | 工具数: 6
“慢操作丢后台,agent 继续想下一步” – 后台线程跑命令,完成后注入通知。
问题
有些命令要跑好几分钟:npm install、pytest、docker build。阻塞式循环下模型只能干等。用户说 “装依赖,顺便建个配置文件”,智能体却只能一个一个来。
解决方案
1 | Main thread Background thread |
工作原理
1. BackgroundManager 用线程安全的通知队列追踪任务。
1 | class BackgroundManager: |
2. run() 启动守护线程,立即返回。
1 | def run(self, command: str) -> str: |
3. 子进程完成后,结果进入通知队列。
1 | def _execute(self, task_id, command): |
4. 每次 LLM 调用前排空通知队列。
1 | def agent_loop(messages: list): |
循环保持单线程。只有子进程 I/O 被并行化。
变更内容
| 组件 | 之前 (s07) | 之后 (s08) |
|---|---|---|
| Tools | 8 | 6(基础 + background_run + check) |
| 执行方式 | 仅阻塞 | 阻塞 + 后台线程 |
| 通知机制 | 无 | 每轮排空的队列 |
| 并发 | 无 | 守护线程 |
试一试
1 | cd learn-claude-code |
Run "sleep 5 && echo done" in the background, then create a file while it runsStart 3 background tasks: "sleep 2", "sleep 4", "sleep 6". Check their status.Run pytest in the background and keep working on other things
第九章:Agent 团队(s09)
分类: 并发 | 副标题: Agent 团队邮箱
代码量: 348 行 | 工具数: 9
“任务太大一个人干不完,要能分给队友” – 持久化队友 + JSONL 邮箱。
问题
子智能体(s04)是一次性的:生成、干活、返回摘要、消亡。没有身份,没有跨调用的记忆。后台任务(s08)能跑 shell 命令,但做不了 LLM 引导的决策。
真正的团队协作需要三样东西:(1) 能跨多轮对话存活的持久智能体,(2) 身份和生命周期管理,(3) 智能体之间的通信通道。
解决方案
1 | Teammate lifecycle: |
工作原理
1. TeammateManager 通过 config.json 维护团队名册。
1 | class TeammateManager: |
2. spawn() 创建队友并在线程中启动 agent loop。
1 | def spawn(self, name: str, role: str, prompt: str) -> str: |
3. MessageBus:append-only 的 JSONL 收件箱。send() 追加一行;read_inbox() 读取全部并清空。
1 | class MessageBus: |
4. 每个队友在每次 LLM 调用前检查收件箱,将消息注入上下文。
1 | def _teammate_loop(self, name, role, prompt): |
变更内容
| 组件 | 之前 (s08) | 之后 (s09) |
|---|---|---|
| Tools | 6 | 9(+spawn/send/read_inbox) |
| 智能体数量 | 单一 | 领导 + N 个队友 |
| 持久化 | 无 | config.json + JSONL 收件箱 |
| 线程 | 后台命令 | 每线程完整 agent loop |
| 生命周期 | 一次性 | idle → working → idle |
| 通信 | 无 | message + broadcast |
试一试
1 | cd learn-claude-code |
Spawn alice (coder) and bob (tester). Have alice send bob a message.Broadcast "status update: phase 1 complete" to all teammatesCheck the lead inbox for any messages- 输入
/team查看团队名册和状态 - 输入
/inbox手动检查领导的收件箱
第十章:团队协议(s10)
分类: 并发 | 副标题: FSM 团队协议
代码量: 419 行 | 工具数: 12
“队友之间要有统一的沟通规矩” – 一个 request-response 模式驱动所有协商。
问题
s09 中队友能干活能通信,但缺少结构化协调:
关机: 直接杀线程会留下写了一半的文件和过期的 config.json。需要握手 – 领导请求,队友批准(收尾退出)或拒绝(继续干)。
计划审批: 领导说 “重构认证模块”,队友立刻开干。高风险变更应该先过审。
两者结构一样:一方发带唯一 ID 的请求,另一方引用同一 ID 响应。
解决方案
1 | Shutdown Protocol Plan Approval Protocol |
工作原理
1. 领导生成 request_id,通过收件箱发起关机请求。
1 | shutdown_requests = {} |
2. 队友收到请求后,用 approve/reject 响应。
1 | if tool_name == "shutdown_response": |
3. 计划审批遵循完全相同的模式。队友提交计划(生成 request_id),领导审查(引用同一个 request_id)。
1 | plan_requests = {} |
一个 FSM,两种用途。同样的 pending → approved | rejected 状态机可以套用到任何请求-响应协议上。
变更内容
| 组件 | 之前 (s09) | 之后 (s10) |
|---|---|---|
| Tools | 9 | 12(+shutdown_req/resp +plan) |
| 关机 | 仅自然退出 | 请求-响应握手 |
| 计划门控 | 无 | 提交/审查与审批 |
| 关联 | 无 | 每个请求一个 request_id |
| FSM | 无 | pending → approved/rejected |
试一试
1 | cd learn-claude-code |
Spawn alice as a coder. Then request her shutdown.List teammates to see alice's status after shutdown approvalSpawn bob with a risky refactoring task. Review and reject his plan.Spawn charlie, have him submit a plan, then approve it.- 输入
/team监控状态
第十一章:自主 Agent(s11)
分类: 并发 | 副标题: 自主 Agent 循环
代码量: 499 行 | 工具数: 14
“队友自己看看板,有活就认领” – 不需要领导逐个分配,自组织。
问题
s09-s10 中,队友只在被明确指派时才动。领导得给每个队友写 prompt,任务看板上 10 个未认领的任务得手动分配。这扩展不了。
真正的自治:队友自己扫描任务看板,认领没人做的任务,做完再找下一个。
一个细节:上下文压缩(s06)后智能体可能忘了自己是谁。身份重注入解决这个问题。
解决方案
1 | Teammate lifecycle with idle cycle: |
工作原理
1. 队友循环分两个阶段:WORK 和 IDLE。LLM 停止调用工具(或调用了 idle)时,进入 IDLE。
1 | def _loop(self, name, role, prompt): |
2. 空闲阶段循环轮询收件箱和任务看板。
1 | def _idle_poll(self, name, messages): |
3. 任务看板扫描:找 pending 状态、无 owner、未被阻塞的任务。
1 | def scan_unclaimed_tasks() -> list: |
4. 身份重注入:上下文过短(说明发生了压缩)时,在开头插入身份块。
1 | if len(messages) <= 3: |
变更内容
| 组件 | 之前 (s10) | 之后 (s11) |
|---|---|---|
| Tools | 12 | 14(+idle, +claim_task) |
| 自治性 | 领导指派 | 自组织 |
| 空闲阶段 | 无 | 轮询收件箱 + 任务看板 |
| 任务认领 | 仅手动 | 自动认领未分配任务 |
| 身份 | 系统提示 | + 压缩后重注入 |
| 超时 | 无 | 60 秒空闲 → 自动关机 |
试一试
1 | cd learn-claude-code |
Create 3 tasks on the board, then spawn alice and bob. Watch them auto-claim.Spawn a coder teammate and let it find work from the task board itselfCreate tasks with dependencies. Watch teammates respect the blocked order.- 输入
/tasks查看带 owner 的任务看板 - 输入
/team监控谁在工作、谁在空闲
第十二章:Worktree + 任务隔离(s12)
分类: 并发 | 副标题: Worktree + Task Isolation
代码量: 694 行 | 工具数: 16
“Each works in its own directory; tasks manage goals, worktrees manage directories, bound by ID”
“各干各的目录,互不干扰” – 任务管目标,worktree 管目录,按 ID 绑定。
问题
到 s11,智能体已经能自主认领和完成任务。但所有任务共享一个目录。两个智能体同时重构不同模块 – A 改 config.py,B 也改 config.py,未提交的改动互相污染,谁也没法干净回滚。
任务板管 “做什么” 但不管 “在哪做”。解法:给每个任务一个独立的 git worktree 目录,用任务 ID 把两边关联起来。
解决方案
1 | Control plane (.tasks/) Execution plane (.worktrees/) |
工作原理
1. 创建任务。 先把目标持久化。
1 | TASKS.create("Implement auth refactor") |
2. 创建 worktree 并绑定任务。 传入 task_id 自动将任务推进到 in_progress。
1 | WORKTREES.create("auth-refactor", task_id=1) |
绑定同时写入两侧状态:
1 | def bind_worktree(self, task_id, worktree): |
3. 在 worktree 中执行命令。 cwd 指向隔离目录。
1 | subprocess.run(command, shell=True, cwd=worktree_path, |
4. 收尾。 两种选择:
worktree_keep(name)– 保留目录供后续使用。worktree_remove(name, complete_task=True)– 删除目录,完成绑定任务,发出事件。一个调用搞定拆除 + 完成。
1 | def remove(self, name, force=False, complete_task=False): |
5. 事件流。 每个生命周期步骤写入 .worktrees/events.jsonl:
1 | { |
事件类型:worktree.create.before/after/failed、worktree.remove.before/after/failed、worktree.keep、task.completed。
崩溃后从 .tasks/ + .worktrees/index.json 重建现场。会话记忆是易失的;磁盘状态是持久的。
变更内容
| 组件 | 之前 (s11) | 之后 (s12) |
|---|---|---|
| 协调 | 任务板(owner/status) | 任务板 + worktree 显式绑定 |
| 执行范围 | 共享目录 | 每个任务独立目录 |
| 可恢复性 | 仅任务状态 | 任务状态 + worktree 索引 |
| 收尾 | 任务完成 | 任务完成 + 显式 keep/remove |
| 生命周期可见性 | 隐式日志 | .worktrees/events.jsonl 显式事件流 |
试一试
1 | cd learn-claude-code |
Create tasks for backend auth and frontend login page, then list tasks.Create worktree "auth-refactor" for task 1, then bind task 2 to a new worktree "ui-login".Run "git status --short" in worktree "auth-refactor".Keep worktree "ui-login", then list worktrees and inspect events.Remove worktree "auth-refactor" with complete_task=true, then list tasks/worktrees/events.
附录:课程代码量增长
| 章节 | 代码行数(LOC) |
|---|---|
| s01 Agent 循环 | 84 |
| s02 工具 | 120 |
| s03 TodoWrite | 176 |
| s04 子 Agent | 151 |
| s05 技能 | 187 |
| s06 上下文压缩 | 205 |
| s07 任务系统 | 207 |
| s08 后台任务 | 198 |
| s09 Agent 团队 | 348 |
| s10 团队协议 | 419 |
| s11 自主 Agent | 499 |
| s12 Worktree + 任务隔离 | 694 |
核心学习路径
1 | s01 → s02 → s03 → s04 → s05 → s06 | s07 → s08 → s09 → s10 → s11 → s12 |
左侧(s01-s06):单智能体能力增强
- s01:最基础的 while 循环 + bash 工具
- s02:多工具分发映射(dispatch map)
- s03:TodoWrite 计划与提醒
- s04:子 Agent 上下文隔离
- s05:按需技能加载
- s06:三层上下文压缩
右侧(s07-s12):多智能体协作
- s07:带依赖关系的文件持久化任务图
- s08:后台任务并行执行
- s09:Agent 团队 + JSONL 邮箱通信
- s10:FSM 团队协议(关机握手、计划审批)
- s11:自主 Agent(自组织认领任务)
- s12:Worktree 任务隔离(独立目录执行)
本文档整理自 https://learn.shareai.run/zh/timeline/ 的全部 12 个章节内容。
附录:完整源代码
以下源代码来自 shareAI-lab/learn-claude-code 仓库。
第一章:Agent 循环(s01) - 源代码
文件: s01_agent_loop.py
1 | #!/usr/bin/env python3 |
第二章:工具(s02) - 源代码
文件: s02_tool_use.py
1 | #!/usr/bin/env python3 |
第三章:TodoWrite(s03) - 源代码
文件: s03_todo_write.py
1 | #!/usr/bin/env python3 |
第四章:子 Agent(s04) - 源代码
文件: s04_subagent.py
1 | #!/usr/bin/env python3 |
第五章:技能(s05) - 源代码
文件: s05_skill_loading.py
1 | #!/usr/bin/env python3 |
第六章:上下文压缩(s06) - 源代码
文件: s06_context_compact.py
1 | #!/usr/bin/env python3 |
第七章:任务系统(s07) - 源代码
文件: s07_task_system.py
1 | #!/usr/bin/env python3 |
第八章:后台任务(s08) - 源代码
文件: s08_background_tasks.py
1 | #!/usr/bin/env python3 |
第九章:Agent 团队(s09) - 源代码
文件: s09_agent_teams.py
1 | #!/usr/bin/env python3 |
第十章:团队协议(s10) - 源代码
文件: s10_team_protocols.py
1 | #!/usr/bin/env python3 |
第十一章:自主 Agent(s11) - 源代码
文件: s11_autonomous_agents.py
1 | #!/usr/bin/env python3 |
第十二章:Worktree + 任务隔离(s12) - 源代码
文件: s12_worktree_task_isolation.py
1 | #!/usr/bin/env python3 |