tighten volume-5 boundaries and navigation

Author: T0UGH

docs/guidebookv2/volume-5/03-how-skills-mcp-agents-subagents-hooks-and-plugins-enter-claude-code.md

@@ -103,7 +103,7 @@ flowchart TD
 ## 再画一张更具体的接入位置图
 
 ```mermaid
-flowchart LR
+flowchart TD
     A[用户方法] --> S[skills]
     B[外部 server / resources] --> M[MCP]
     C[任务委派需求] --> AG[agents / subagents]

docs/guidebookv2/volume-5/09-why-mcp-is-not-just-more-remote-tools.md

@@ -97,18 +97,16 @@ MCP 组的第一个任务，不是立刻把接入链讲完，而是先拆掉一
 ## 先把主图立住：远程工具模型 vs 能力源接入模型
 
 ```mermaid
-flowchart LR
-    subgraph A[把 MCP 看成远程工具]
-        A1[外部函数] --> A2[暴露成工具]
-        A2 --> A3[模型调用]
-    end
-
-    subgraph B[把 MCP 看成能力源接入]
-        B1[外部 server / 资源系统] --> B2[连接 / 认证 / 状态]
-        B2 --> B3[tools / prompts / resources]
-        B3 --> B4[翻译成内部对象]
-        B4 --> B5[权限 / 重试 / 结果治理]
-    end
+flowchart TD
+    A0[把 MCP 看成远程工具] --> A1[只看见外部函数]
+    A1 --> A2[暴露成工具名]
+    A2 --> A3[模型调用]
+
+    B0[把 MCP 看成能力源接入] --> B1[外部 server / 资源系统]
+    B1 --> B2[连接 / 认证 / 状态]
+    B2 --> B3[tools / prompts / resources]
+    B3 --> B4[翻译成内部对象]
+    B4 --> B5[权限 / 重试 / 结果治理]
 ```
 
 这张图的作用就是先打掉一个偷懒理解：

docs/guidebookv2/volume-5/11-how-mcp-relates-to-skills-hooks-and-plugins.md

@@ -26,7 +26,7 @@ status: draft
 - **所属卷**：卷五：扩展层与平台对象
 - **卷内位置**：11 / 24
 - **上一篇**：[卷五 10｜Claude Code 是怎样通过 MCP 接入外部能力源和资源系统的](./10-how-claude-code-uses-mcp-to-connect-external-capabilities-and-resource-systems.md)
-- **下一篇**：待后续回合衔接 Agent 主轴
+- **下一篇**：[卷五 12｜Claude Code 里的 agent，跟 tool 不是一回事](./12-why-agent-is-not-just-another-tool.md)
 
 到第 11 篇，MCP 组已经把两件事讲清了：
 

docs/guidebookv2/volume-5/13-how-claude-code-grows-more-executors.md

@@ -46,7 +46,7 @@ source_files:
 先看总图：
 
 ```mermaid
-flowchart LR
+flowchart TD
     A[主线程单执行者] --> B[AgentTool 成为任务委派入口]
     B --> C[系统开始有 agent definitions]
     C --> D[built-in / user / project / plugin agents 并存]

docs/guidebookv2/volume-5/14-why-runagent-feels-like-an-agent-runtime-assembly-line.md

@@ -11,6 +11,21 @@ source_files:
 
 # 卷五 14｜这组 agent 是怎么被拉进当前任务的
 
+## 导读
+
+- **所属卷**：卷五：外部扩展与多代理能力
+- **卷内位置**：14 / 24
+- **上一篇**：[卷五 13｜Claude Code 一开始就准备了一组 agent](./13-how-claude-code-grows-more-executors.md)
+- **下一篇**：[卷五 15｜为什么主 agent 还要继续把活拆出去](./15-why-the-main-agent-needs-to-spawn-subagents.md)
+
+第 13 篇先把“系统里已经有一组可被识别、可被加载、可被选择的执行者”立住了。
+
+第 14 篇往前推进的，不是“agent 存不存在”，而是：
+
+> **这组已经存在的 agent，到底是怎么被拉进一次当前任务里的？**
+
+也就是说，这篇只负责把 `runAgent` 写成一条正式装配主干：它怎样把 agent 定义、上下文、能力面和生命周期编成一个可运行执行体；至于为什么主 agent 还要继续拆活，那是第 15 篇的问题。
+
 ## 这篇要回答的问题
 
 第 13 篇已经先立住了“系统里有一组 agent”这件事，但那还只是静态层。

docs/guidebookv2/volume-5/15-why-the-main-agent-needs-to-spawn-subagents.md

@@ -10,6 +10,21 @@ source_files:
 
 # 卷五 15｜为什么主 agent 还要继续把活拆出去
 
+## 导读
+
+- **所属卷**：卷五：外部扩展与多代理能力
+- **卷内位置**：15 / 24
+- **上一篇**：[卷五 14｜这组 agent 是怎么被拉进当前任务的](./14-why-runagent-feels-like-an-agent-runtime-assembly-line.md)
+- **下一篇**：[卷五 16｜subagent 不是另起一个指挥部](./16-why-forksubagent-is-not-just-starting-another-agent.md)
+
+第 14 篇已经把统一 agent runtime 装配主干立住了。
+
+第 15 篇要继续回答的，不是“agent 怎么启动”，而是：
+
+> **为什么主 agent 在真正执行时，还不能把所有局部都自己吞下，而要继续把活拆给 subagent / worker？**
+
+这篇只负责把“为什么要继续分工”讲透；subagent 到底继承什么、不继承什么，要留给第 16 篇。
+
 ## 这篇要回答的问题
 
 第 14 篇已经回答了：系统里准备好的一组 agent，是怎么被真正拉进当前任务的。
@@ -142,17 +157,9 @@ subagent 的出现，就是为了让主 agent 保住：
 - 一组叫 agents
 - 另一组叫 subagents
 
-## 这篇给下一篇留下什么坡度
-
-第 15 篇先回答“为什么主 agent 还得继续拆活”。
-
-但它还没回答最关键的对象问题：
-
-- 这个被拆出去的 subagent 到底算什么？
-- 它是不是又起了一个平级主脑？
-- 它继承什么，又没继承什么？
+## 这篇收住什么
 
-这正是第 16 篇要接的地方。
+第 15 篇只把“为什么主线必须继续分工”讲透：复杂任务会把问题从单执行者能力，推进到受控协作结构。至于 subagent 到底继承什么、不继承什么，要留给第 16 篇单独切开。
 
 ## 一句话收口
 

docs/guidebookv2/volume-5/16-why-forksubagent-is-not-just-starting-another-agent.md

@@ -10,6 +10,21 @@ source_files:
 
 # 卷五 16｜subagent 不是另起一个指挥部
 
+## 导读
+
+- **所属卷**：卷五：外部扩展与多代理能力
+- **卷内位置**：16 / 24
+- **上一篇**：[卷五 15｜为什么主 agent 还要继续把活拆出去](./15-why-the-main-agent-needs-to-spawn-subagents.md)
+- **下一篇**：[卷五 17｜拆出去的活，最后怎么回到主线](./17-boundaries-and-information-flow-between-main-agent-and-worker-agent.md)
+
+第 15 篇已经说明：复杂任务会把主线继续推进到分工问题。
+
+第 16 篇要解决的是更容易被误解的一刀：
+
+> **被拆出去的 subagent，到底为什么不是又起了一个平级总控？**
+
+所以这篇的任务，是把 `forkSubagent` 写成沿父执行线切出的受控 worker 分叉，而不是另起一个横向指挥部。
+
 ## 这篇要回答的问题
 
 第 15 篇已经说明：主 agent 为什么还得继续把活拆出去。现在还要再往前走一步：
@@ -33,10 +48,12 @@ source_files:
 ## 主图：forkSubagent 的继承与分叉
 
 ```mermaid
-flowchart LR
+flowchart TD
     A[主 agent 当前执行线] --> B[保留父 assistant message 全量内容]
-    B --> C[buildForkedMessages 构造 fork prefix]
-    C --> D[FORK_AGENT 继承 model=inherit tools=* permission=bubble]
+    B --> C[buildForkedMessages
+构造 fork prefix]
+    C --> D[FORK_AGENT
+继承 model/tools/permission]
     D --> E[worker 只处理当前 directive]
     E --> F[结果回到父线]
 ```

docs/guidebookv2/volume-5/17-boundaries-and-information-flow-between-main-agent-and-worker-agent.md

@@ -11,6 +11,21 @@ source_files:
 
 # 卷五 17｜拆出去的活，最后怎么回到主线
 
+## 导读
+
+- **所属卷**：卷五：外部扩展与多代理能力
+- **卷内位置**：17 / 24
+- **上一篇**：[卷五 16｜subagent 不是另起一个指挥部](./16-why-forksubagent-is-not-just-starting-another-agent.md)
+- **下一篇**：[卷五 18｜Claude Code 的 hooks，为什么不是挂几个脚本这么简单](./18-why-hooks-are-more-than-just-some-scripts.md)
+
+第 15、16 篇已经把后半段主线的两个核心问题切开了：为什么要继续分工，以及 fork 为什么只是受控 worker 分叉。
+
+第 17 篇现在要收住的是：
+
+> **活都拆出去了，最后谁来收口，结果又是怎么重新回到主线里的？**
+
+也就是说，这篇不再扩写“还能分多少 worker”，而是把主 agent / worker 的边界和信息回流机制收成后半段闭环。
+
 ## 这篇要回答的问题
 
 后半段主线走到这里，真正要收的已经不是“还能分叉多少 worker”，而是：

docs/guidebookv2/volume-5/21-why-plugins-are-still-needed-after-skills-mcp-and-hooks.md

@@ -6,6 +6,21 @@ tags: [Claude Code, plugins, skills, MCP, hooks, agents]
 
 # 卷五 21｜为什么前面这些扩展点加起来，还是不够
 
+## 导读
+
+- **所属卷**：卷五：外部扩展与多代理能力
+- **卷内位置**：21 / 24
+- **上一篇**：[卷五 20｜一轮会话怎么起、怎么进、怎么收，hooks 其实都能插手](./20-what-different-hooks-intercept-connect-and-modify-in-claude-code.md)
+- **下一篇**：[卷五 22｜plugin 到底是什么，它不是哪一种扩展点的壳](./22-what-layer-plugins-occupy-relative-to-other-extension-objects.md)
+
+卷五前面已经把 methods、capabilities、executors、runtime seams 几条线分别立住了。
+
+第 21 篇现在要先回答一个过渡问题：
+
+> **既然已经有这么多扩展对象并存，Claude Code 为什么还会继续长出 plugins？**
+
+这篇不主讲 plugin 的完整形态，只先证明一件事：前面这些对象分别解决了入口问题，但还没有把一整组扩展内容收成统一封装单位。
+
 ## 这篇要回答的问题
 
 卷五前面已经把几条扩展主线分别立住了：
@@ -43,20 +58,19 @@ tags: [Claude Code, plugins, skills, MCP, hooks, agents]
 ## 主图：分散扩展点并存，为什么还会逼出 plugin
 
 ```mermaid
-flowchart LR
-    A[skills\n方法组织入口] --> E[很多扩展点并存]
-    B[MCP\n外部能力源入口] --> E
-    C[hooks\nruntime 接缝入口] --> E
-    D[agent\n执行者结构入口] --> E
+flowchart TD
+    A[skills
+方法组织入口] --> E[很多扩展点并存]
+    B[MCP
+外部能力源入口] --> E
+    C[hooks
+runtime 接缝入口] --> E
+    D[agent
+执行者结构入口] --> E
 
     E --> F{有没有统一封装单位}
-
-    F -->|没有| G[来源分散]
-    F -->|没有| H[启停分散]
-    F -->|没有| I[治理分散]
-    F -->|没有| J[分发分散]
-
-    F -->|有 plugin| K[一组能力作为正式单元进入系统]
+    F -->|没有| G[来源 / 启停 / 治理 / 分发都分散]
+    F -->|有 plugin| H[一组能力作为正式单元进入系统]
 ```
 
 这张图的重点不是说 plugin 比前面“更强”，而是说：

docs/guidebookv2/volume-5/22-what-layer-plugins-occupy-relative-to-other-extension-objects.md

@@ -6,6 +6,21 @@ tags: [Claude Code, plugins, LoadedPlugin, hooks, skills, MCP]
 
 # 卷五 22｜plugin 到底是什么，它不是哪一种扩展点的壳
 
+## 导读
+
+- **所属卷**：卷五：外部扩展与多代理能力
+- **卷内位置**：22 / 24
+- **上一篇**：[卷五 21｜为什么前面这些扩展点加起来，还是不够](./21-why-plugins-are-still-needed-after-skills-mcp-and-hooks.md)
+- **下一篇**：[卷五 23｜为什么 plugins 最后会长成一层平台边界](./23-why-plugins-represent-a-more-complete-form-of-packaging-distribution-and-reuse.md)
+
+第 21 篇已经先证明：很多扩展入口并存，不等于插件层已经成立。
+
+第 22 篇要继续切开的，是 plugin 的对象身份：
+
+> **plugin 到底是什么？为什么它既不是 hooks 的壳，不是 marketplace 安装包，也不是某一种扩展点的同义词？**
+
+所以这篇只做一件事：把 plugin 写成统一运行时对象，而不是再来一种大号扩展点。
+
 ## 这篇要回答的问题
 
 第 21 篇已经先回答了“为什么前面已经有 skills / MCP / hooks，系统还需要 plugin”。