卷一 04｜Claude Code 怎么把模型意图落成执行能力¶

导读¶

所属卷：卷一：Claude Code 系统全景导论
卷内位置：04 / 06
上一篇：上一篇：一次请求是怎么跑成一次 Agent Turn 的
下一篇：下一篇：Claude Code 怎么维持上下文、状态与持续工作

上一篇已经把一件事讲清了：Claude Code 的基本单位不是一句回复，而是一轮会继续推进的 agent turn。

第四篇不再重复讲这条闭环，只往前补一个关键问题：

当模型已经判断“下一步该做什么”时，这个判断是怎么被 runtime 接住，并落成现实动作的？

先把核心判断摆在前面：

Claude Code 不是让模型直接“调函数”，而是让模型先产出 tool_use 这样的结构化意图，再由 runtime 把它编排、执行，并把结果重新送回当前 turn。tool 是这层里最标准的执行接口。

执行能力层在系统里的位置¶

这里最容易产生的误解，是把这条链直接想成“模型调用了一个函数”。

但更准确的理解其实是三层分工：

模型只负责形成当前判断，并把“下一步想做什么”表达成 tool_use
runtime负责接住这份意图，决定怎样纳入当前 turn，并推动执行发生
tool / external capability负责真正落到读文件、跑命令、改内容这类现实动作上

所以第四篇真正要解释的，不是“模型怎么直接做事”，而是：

模型的意图，怎样经过 runtime，变成正式执行。

可以先看这张总图：

flowchart TB
    M[模型形成<br/>结构化意图] --> TU[tool_use]
    TU --> O[runtime 编排<br/>orchestration]
    O --> E[开始执行<br/>execution]
    E --> C[触发具体工具<br/>tool.call]
    C --> R[得到结果<br/>tool_result]
    R --> A[结果先收进<br/>当前 turn 本地状态]
    A --> RT[组织下一轮<br/>continuation]
    RT --> M2[模型继续当前 turn]

这张图最重要的不是术语，而是它说明了一件事：

执行不是模型自己往系统里伸手做事，而是一条由 runtime 接管的正式链路。

也正因为这条链存在，Claude Code 才不是“会说的模型”，而是“能把意图推进成进展的 runtime”。

如果想把“谁负责哪一段”看得更清楚，可以再看下面这张职责边界图：

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`¶

1. `tool_use`：模型先表达意图¶

模型先给出的，不是底层系统动作本身，而是一个结构化意图：

读某个文件
执行某个命令
修改某段内容
调用某个外部能力

所以 tool_use 的意义不是“已经执行”，而是：

把“下一步想做什么”表达成 runtime 可以接住的请求。

它相当于把模型的判断，从自然语言推进到可编排的结构。

2. `orchestration`：runtime 决定这次意图如何进入当前 turn¶

tool_use 产生之后，系统还不会立刻执行。中间先经过 orchestration。

这一层解决的不是“底层动作怎么发生”，而是：

这是不是一个可接受的执行请求
它应该路由给哪个执行对象
它在当前 turn 里处在什么位置
执行前后怎样接回主循环

所以可以把它压成一句话：

orchestration 负责决定：这次工具意图怎样被纳入当前 turn。

它关心的是运行时编排，不是底层动作本身。

3. `execution`：系统开始推动现实动作发生¶

一旦这次请求被 runtime 接住，execution 才开始真正把结构化意图往现实动作压：

读文件
改文件
跑命令
调用别的能力边界

所以 execution 的重点也可以压成一句话：

execution 负责让已经被接住的请求真正发生。

如果说 orchestration 解决的是“怎么纳入当前 turn”，那 execution 解决的就是“现实动作怎么开始发生”。

4. `tool.call`：具体执行对象被触发¶

execution 最后还要落到具体对象上。最典型的，就是 tool.call。

这时 tool 的位置就很清楚了：

tool 不是附带功能菜单，而是 runtime 把模型意图落成现实动作时所调用的标准执行接口。

这也是为什么卷一此处不急着深挖 BashTool、FileReadTool、FileEditTool 的实现。对这一篇更重要的是先看清：这些具体工具，都是同一层执行系统里的不同样本。

5. `tool_result`：执行的终点不是做完，而是结果回流¶

从 Claude Code 的角度看，执行成功还不算结束。真正关键的是：

执行结果必须重新回到当前 turn，变成下一步判断可以消费的输入。

所以 tool_result 不是单纯的底层返回值，而是当前工作回合继续推进的一部分。

这也正好接回第三篇的判断：agent turn 之所以是闭环，不是因为做过一个动作，而是因为动作结果会重新回到 runtime 里。

这里还有一个很容易误读的点，最好顺手压清：

tool_result 回流到 runtime，不等于某个工具一完成，系统就立刻单独再打一轮模型请求。

更接近的过程其实是：

assistant 先在当前输出流里产出 tool_use
runtime 逐步执行工具，并接住已经完成的 tool_result
这些结果会先收进当前 turn 的本地消息状态
然后再按下一轮 continuation 的组织方式，一起送回模型继续当前工作

所以这里真正成立的不是“每个 result 都即时递归打模型”，而是：

工具执行可以边流边跑，但模型 continuation 仍然按 turn 收口。

为什么不能把它简单理解成“模型直接调函数”¶

“tool 就是 function calling”这个说法有一点像，但不够解释 Claude Code 为什么需要一整层执行能力结构。

至少差在三点。

第一，模型表达的是意图，不是直接拥有现实动作权限¶

模型最先产出的是“我接下来要做什么”的结构化判断，而不是直接操作文件、命令行或外部系统的能力。

所以 Claude Code 要解决的第一个问题，不是“模型会不会说”，而是：

模型的意图怎样被系统接住，并转成真实动作。

第二，Claude Code 需要的是运行时编排，不是孤立调用¶

普通函数调用关心的，往往只是参数和返回值。

但 Claude Code 关心的是：

这次动作是否属于当前 turn
应该在什么时候触发
结果回来后是否继续
结果如何重新进入主循环

所以这里真正重要的，不是“是否存在调用”，而是：

执行被怎样编排进当前工作回合。

第三，结果必须重新织回主循环¶

如果一个动作只在底层发生，却没有把结果重新送回当前 turn，那它就只是一次孤立执行。

而 Claude Code 需要的不是孤立执行，而是：

模型形成意图
runtime 组织执行
结果回流
当前回合继续判断

所以这里真正成立的不是“模型调了一个函数”，而是：

runtime 把模型意图稳定地落成执行，并把结果重新织回主循环。

tool 在 Claude Code 里到底是什么¶

如果把这一篇只压成一句最该记住的话，那就是：

tool 是 Claude Code 执行能力层里的标准接口：模型先通过 tool_use 表达意图，runtime 再通过 tool 把这份意图落成现实动作，并把结果送回当前 turn。

这句话有三个重点：

tool 不等于 Claude Code 的全部，但它是执行层最标准的对象
tool 的价值不只是“能做事”，而是动作边界清楚、能被 runtime 编排
tool 不是和主循环分开的附属层，而是主循环推进现实进展时最关键的接口之一

所以这篇真正想建立的，不是“Claude Code 会调用很多工具”这个印象，而是：

Claude Code 的执行能力，本质上是一层由 runtime 组织起来的接口系统。

这一篇在卷一里的作用¶

把卷一前四篇连起来看，逻辑已经比较完整：

第一篇回答：Claude Code 是什么系统
第二篇回答：这套系统有哪些核心对象
第三篇回答：一次请求怎么跑成一轮 agent turn
第四篇回答：这一轮里的模型意图，怎么被落成执行能力

所以第四篇的作用，不是抢先细讲某一个工具，而是替后面的工具系统卷先立一张执行层总图。

等这张图立住之后，后面再看 BashTool、FileReadTool、FileEditTool，就不会像在看几个零散功能，而是在看 Claude Code 执行能力层的不同切面。

一句话收口¶

Claude Code 不是让模型直接“调函数”，而是让模型先产出 tool_use，再由 runtime 经历 orchestration -> execution -> tool.call -> tool_result 这条链，把意图落成现实动作，并把结果重新送回当前 turn。tool 的真正位置，不是功能菜单，而是模型意图通往现实动作的标准执行接口。