tighten volume-1 article 04 execution boundary explanation

Author: T0UGH

docs/guidebookv2/volume-1/04-how-intent-becomes-execution.md

@@ -17,13 +17,11 @@ tags:
 - **上一篇**：[上一篇：一次请求是怎么跑成一次 Agent Turn 的](./03-how-a-request-becomes-an-agent-turn.md)
 - **下一篇**：[下一篇：Claude Code 怎么维持上下文、状态与持续工作](./05-how-claude-code-maintains-context-state-and-continuity.md)
 
-上一篇把 Claude Code 的动态主线立住了：一次请求不会天然停在首条回复，而是沿着“判断 → 执行 → 结果回流 → 再判断”的闭环继续推进。
+上一篇已经把一件事讲清了：Claude Code 的基本单位不是一句回复，而是一轮会继续推进的 agent turn。
 
-但第三篇还留下了一个关键问题：
+第四篇不再重复讲这条闭环，只往前补一个关键问题：
 
-> **当模型已经判断“下一步该做什么”时，Claude Code 怎么把这个判断真正落成现实动作？**
-
-这篇补的，就是这层桥。
+> **当模型已经判断“下一步该做什么”时，这个判断是怎么被 runtime 接住，并落成现实动作的？**
 
 先把核心判断摆在前面：
 
@@ -33,15 +31,17 @@ tags:
 
 ## 执行能力层在系统里的位置
 
-把前几篇连起来看，Claude Code 至少已经有这样一条主线：
+这里最容易产生的误解，是把这条链直接想成“模型调用了一个函数”。
+
+但更准确的理解其实是三层分工：
+
+- **模型**只负责形成当前判断，并把“下一步想做什么”表达成 `tool_use`
+- **runtime**负责接住这份意图，决定怎样纳入当前 turn，并推动执行发生
+- **tool / external capability**负责真正落到读文件、跑命令、改内容这类现实动作上
 
-1. 用户把请求送进 runtime
-2. runtime 组织一轮 agent turn
-3. 模型形成当前判断
-4. 系统把这个判断落成现实动作
-5. 结果回流，当前 turn 再继续或收口
+所以第四篇真正要解释的，不是“模型怎么直接做事”，而是：
 
-第四篇讲的，就是第 3 步和第 4 步之间的那层执行能力结构。
+> **模型的意图，怎样经过 runtime，变成正式执行。**
 
 可以先看这张总图：
 
@@ -63,6 +63,35 @@ flowchart TB
 
 也正因为这条链存在，Claude Code 才不是“会说的模型”，而是“能把意图推进成进展的 runtime”。
 
+如果想把“谁负责哪一段”看得更清楚，可以再看下面这张职责边界图：
+
+```mermaid
+flowchart LR
+    subgraph ML[模型层]
+        M1[形成当前判断]
+        M2[输出 tool_use]
+    end
+
+    subgraph RT[runtime 层]
+        R1[接住结构化意图]
+        R2[orchestration\n纳入当前 turn]
+        R3[execution\n推动动作发生]
+        R4[收集 tool_result]
+        R5[组织 continuation]
+    end
+
+    subgraph TL[tool / external capability 层]
+        T1[读文件 / 跑命令 / 改内容 / 调外部能力]
+    end
+
+    M1 --> M2
+    M2 --> R1 --> R2 --> R3 --> T1 --> R4 --> R5
+```
+
+这张图想强调的只有一句：
+
+> **模型负责表达意图，runtime 负责编排与接管，tool 负责把动作真正落到现实边界上。**
+
 ---
 
 ## 先把整条链讲清：`tool_use -> orchestration -> execution -> tool.call -> tool_result`
@@ -95,7 +124,7 @@ flowchart TB
 
 所以可以把它压成一句话：
 
-> **orchestration 负责把这次工具意图纳入当前运行时。**
+> **orchestration 负责决定：这次工具意图怎样被纳入当前 turn。**
 
 它关心的是运行时编排，不是底层动作本身。
 
@@ -138,19 +167,14 @@ execution 最后还要落到具体对象上。最典型的，就是 `tool.call`
 
 > **`tool_result` 回流到 runtime，不等于某个工具一完成，系统就立刻单独再打一轮模型请求。**
 
-Claude Code 更接近这样一条链：
+更接近的过程其实是：
 
 1. assistant 先在当前输出流里产出 `tool_use`
-2. runtime 可以边流边执行工具，也可以边拿到已完成的 `tool_result`
-3. 这些结果会先被收进当前 turn 的本地消息状态
+2. runtime 逐步执行工具，并接住已经完成的 `tool_result`
+3. 这些结果会先收进当前 turn 的本地消息状态
 4. 然后再按下一轮 continuation 的组织方式，一起送回模型继续当前工作
 
-所以这里真正成立的，不是“每个 result 立刻递归打一次模型”，而是：
-
-- **对执行层来说**，工具可以流式启动、并发完成、逐步收结果
-- **对模型回喂层来说**，结果不是 `result-by-result` 地即时递归打模型，而是回到下一轮 continuation 的统一组织里
-
-更短地说：
+所以这里真正成立的不是“每个 result 都即时递归打模型”，而是：
 
 > **工具执行可以边流边跑，但模型 continuation 仍然按 turn 收口。**