最近在看 learn-claude-code 的前四章，最大的感受是：一个 Agent 不是突然“变聪明”的，而是被一层一层搭出来的。

这四章刚好对应四个非常基础、但非常关键的能力：

• s01：让模型形成执行闭环
• s02：让工具能力可扩展、可约束
• s03：让多步任务有显式计划
• s04：让复杂子任务在独立上下文里完成

如果只记一句话，我会记这句：

Agent 的成长，不是单纯靠更强模型，而是靠更清晰的系统结构。

s01：最小 Agent 的起点是 Loop

s01 讲的是最小 Agent Loop。

模型本身只会生成内容，它并不能天然读文件、跑命令、看测试结果。真正让它开始“做事”的，是这样一个循环：

1. 用户提任务
2. 模型决定是否调用工具
3. 系统执行工具
4. 把结果喂回模型
5. 重复，直到模型停止调用工具

Agent 不是一个提示词，而是一个“行动 – 反馈 – 再行动”的闭环。

没有这个 loop，模型再聪明也只是会说，不算真正能做。

s02：工具的意义不只是更多能力，而是更清楚的边界

s02 在 s01 的基础上加入了更正规的工具体系，比如 read_file、write_file、edit_file。

最重要的变化不是“工具变多了”，而是：

• 主循环不用改
• 工具通过 dispatch map 分发
• 每个工具都有清晰职责
• 安全约束写在工具层，而不是只靠提示词提醒

比如路径沙箱这种设计，本质上是在系统层面规定“你只能操作工作区里的文件”。

所以，工具不仅是能力接口，也是约束边界。

好的 Agent，不只是会调用工具，而是知道每种能力应该从哪个入口进入，并且入口本身是可控的。

s03：多步任务要稳定，必须把计划写出来

s03 解决的是一个特别真实的问题：任务一长，模型就容易忘步骤、跳步骤、重复步骤。

它的解决方法不是在prompt上做优化，而是直接加一个 todo 工具，把计划写成结构化状态。

于是任务不再只是脑子里想的几步，而是明确写成：

• pending
• in_progress
• completed

这里有一个比较巧妙的设计，是“同一时间只允许一个 in_progress”。这个约束非常小，但非常有效，它会强制 Agent 一次只专注一件事。我的理解是，这条规则表面上是在管 todo 状态，实际上是在管“写入秩序”：只要 Agent 同时推进多个任务，尤其这些任务还落在同一个模块上，就很容易出现前一个改动还没验证、后一个改动又叠上去的情况，最后代码越改越乱。把进行中的任务强制收敛到一个，本质上就是在用串行执行换稳定性。

再加上“几轮不更新 todo 就提醒一次”，整个系统就开始具备一种持续推进任务的能力。

s04：Subagent 的价值，首先是上下文隔离

s04 引入了 subagent。

很多人看到这里会先想到“多智能体协作”，但我觉得这章更重要的关键词其实是：上下文隔离。

父 Agent 工作久了之后，messages 会越来越长。读文件、跑命令、分析结果，这些信息都会不断堆积，最后主上下文会越来越乱，重新开一个对话窗口的代价也很高。

s04 的做法是：

• 父 Agent 用 task 工具分派一个子任务
• 子 Agent 用全新的上下文独立完成任务
• 子 Agent 做完后，只返回一个摘要给父 Agent

这意味着父 Agent 不需要背着子任务的全部过程，只需要拿到最终结果。

Subagent 不只是为了分工，更是为了把噪音挡在主上下文之外。

复杂过程留在局部，主线只保留高价值信息，这才是它最实用的地方。

最后怎么把这 4 章连起来看

如果把这四章串起来，其实就是一个 Agent 从“能动”到“能稳”的成长过程：

• s01 解决“能不能做”
• s02 解决“怎么安全、清晰地做”
• s03 解决“怎么按步骤持续做”
• s04 解决“任务复杂时怎么保持上下文清醒”

Agent不是靠”神奇的提示词”堆出来的，而是靠一层又一层的工程机制叠起来，每一层都必不可少，后续如果要继续往Agent上加功能，一定也是在这个骨架的基础上去添加机制。一个可靠的Agent，一定最清楚自己该怎么行动，怎么约束，怎么记状态，怎么管理上下文。

所以我最后给自己的总结是：

Loop 解决执行问题，Tool 解决边界问题，Todo 解决进度问题，Subagent 解决复杂度上升时的上下文问题。