Claude Code 一次请求全链路拆解：Agent循环、数据库与省钱策略

你输入一行字：「订单页为什么这么慢？修一下。」这行字到最终答案之间，究竟发生了什么？据 YouTube 技术频道的深度拆解，Claude Code 的每一次交互都跑在同一个 Agent 循环上，而理解这个循环，既是从新手到进阶的分水岭，也是系统设计面试的高频考点。

本文沿着「一次请求的完整生命周期」逐层展开：从终端输入到模型响应，从数据库查询到多 Agent 编排，最后落到成本优化——每一步都附上可复用的判断规则。

第一层：请求进入 Agent 循环

你在终端、编辑器或通过 SDK 输入一行指令，窗口会变，但底层循环是一致的。在文字到达模型之前，Claude Code 会先补充上下文：CLAUDE.md 文件与上层目录的记忆文件在启动时加载，而项目源码文件不会——Agent 只有通过工具调用才会按需读取。

所以第一次模型调用携带的内容包括：你的指令、系统提示词、工具列表、记忆文件与技能描述。模型的回复还不是答案，而是第一步动作。

循环本身分为三个阶段：收集上下文、执行动作、验证结果。以「订单页慢」为例，模型会先请求读取相关文件，再决定下一步；循环在某个回复不再包含工具调用时终止，也可以提前用轮次上限或预算上限叫停。

第二层：权限检查发生在模型之外

大多数流程图在这里画错了一件事：模型自己从不执行任何操作，它只是「请求」。工具调用在获得批准之前就已经存在，但真正把关的是 Claude Code 本身——文档明确写道，权限规则由 Claude Code 强制执行，而非模型。

规则按顺序检查：先拒绝（deny），再询问（ask），最后允许（allow）。钩子（hooks）可以更早介入，pre-tool-use 钩子能看到每一次调用并拦截它。如果你的规则把数据库命令标记为「询问」，Agent 想跑查询计划时就会弹出一个确认提示。

面试时可以这样表述：规则存在于模型之外，共有三类，且拒绝优先检查。

批准之后，工具才真正运行。本地会话中它跑在你自己的机器上；Claude Code 也能在云端运行或被远程驱动。沙箱是可用的，但文档说明它默认关闭，且只覆盖 shell 命令——文件工具、MCP 服务器和钩子都运行在沙箱之外。只读工具可以并发执行，会改变状态的工具则串行执行。每次文件编辑前，Claude Code 会为文件做快照，以便随时回滚。

钩子（hooks）机制是 Claude Code 在工具调用生命周期中预留的拦截点。pre-tool-use 钩子在权限规则检查之前运行，能看到即将执行的工具名与参数，并有机会直接否决或修改这次调用；此外还有 post-tool-use、会话开始等钩子。钩子通常配置在项目或用户级设置文件中，指向一个可执行的 shell 命令，因此它可以做规则引擎做不到的事——比如按路径白名单校验、调用外部审计服务、或对危险命令做二次确认。理解钩子的价值在于：权限规则是声明式的静态配置，钩子则是可以编程的运行时闸门，二者叠加构成纵深防御。

沙箱（sandbox）的边界值得单独说明。Claude Code 的沙箱通常基于操作系统级隔离机制（如 macOS 的 Seatbelt、Linux 的 bubblewrap/命名空间）对 shell 命令施加文件系统与网络的限制。关键在于它默认关闭，且只覆盖通过 Bash 工具执行的 shell 命令；文件读写工具、MCP 服务器进程和钩子本身都在沙箱之外运行。这意味着沙箱不是一道覆盖全部副作用的安全墙，开启它时要清楚哪些执行路径并不受保护。

第三层：数据库内部发生了什么

工具把一条 SQL 发给数据库，数据库自己也有一条流水线。以 PostgreSQL 官方文档为参照，链路是这样的：

解析、转换与重写

客户端建立连接并发送查询，解析器检查语法并构建语法树。一个常被忽略的细节是：解析器不做任何查找。单独的转换步骤才确定你指的是哪些表、函数和操作符。所以拼错的关键字在解析阶段就失败，而不存在的列要到下一步才报错。

接下来是重写系统，它套用已存储的规则——最常见的情况是视图被替换为底层的表，文档称之为宏展开的一种形式。

规划器与执行器

规划器列出所有执行方式：全表扫描、走索引、不同的连接顺序，并为每种方式估算成本，选出最便宜的一条。连接很多时，可尝试的顺序数量爆炸，Postgres 会切换到遗传搜索，接受一个「合理」而非最优的计划——这正是 Agent 先请求查询计划的原因。

执行器运行计划时，很多图把它画成直线，其实不是。行从底部的扫描节点向上流动，但控制流是向下的，文档称之为按需拉取的流水线：顶层节点向子节点要「下一行」，子节点再向自己的子节点要。过滤条件内嵌在这些节点里，并不是独立步骤。每次扫描先读缓冲区缓存，未命中才向操作系统（它也有自己的缓存）请求。

面试提示：用 EXPLAIN ANALYZE，在版本 18 中会显示缓冲区命中情况；注意它会真正执行查询。默认缓存通常是 128MB，专用服务器上文档建议设为内存的四分之一。

执行器边产出边返回行，工具把结果交回循环。如果计划显示订单表走了全表扫描，这就构成了模型下一步动作的依据：加索引。同时，每条消息、工具调用和结果都会写入你机器上的一个文件，这就是之后能恢复会话的原因。

**缓冲区缓存（shared buffers）**是 PostgreSQL 在共享内存中维护的页缓存，默认 shared_buffers 为 128MB，数据文件的一次逻辑读先在缓存中查找，命中则无需陷入操作系统。EXPLAIN (ANALYZE, BUFFERS) 会输出每个节点的 shared hit（命中缓存）与 read（需从磁盘或 OS 页缓存读取）计数，这也是判断「慢」究竟慢在磁盘 I/O 还是慢在计划本身的关键。需要注意的是，ANALYZE 会真实执行语句，对写操作应包在事务中回滚。

**遗传搜索（genetic query optimizer）**是 Postgres 规划器在连接表数量超过阈值（默认 geqo_threshold = 12）时的兜底策略。穷举所有连接顺序的组合数随表数量阶乘增长，规划时间可能反超执行时间，因此规划器改用启发式搜索，接受一个「足够好」而非全局最优的计划。这解释了为什么表很多时执行计划可能看起来并不理想，也提醒 Agent 在解读计划时不要默认它就是最优解。

第四层：多 Agent 编排的六种框架

当一个 Agent 不够用时，所有编排框架都在回答同一个问题：谁决定下一步跑什么？

答案是「你的代码」

LangGraph 中，节点做工作，边决定接下来跑什么，检查点机制保存状态，还支持人工暂停。微软的 Agent Framework 思路相同，用执行器和边组织流程，它接替了 Semantic Kernel 与 AutoGen，可在每个超级步之后做检查点，内置顺序、并发、移交、群聊等模式。图的好处是可预测，代价是每条路径都得自己画。

答案是「一个管理者」

CrewAI 给每个 Agent 一个角色、目标和背景故事。Crew 以两种流程之一运行任务：顺序执行，或层级模式——后者增加一个管理者来分配任务、审核产出、决定何时完工。Crew 之外由 Flow 承载步骤、状态和分支。默认情况下 Agent 之间不能互相移交工作，委托是关闭的，所以它读起来像一张团队架构图。代价是管理者本身也是模型，会额外产生调用。

答案是「模型自己」

OpenAI 的 Agents SDK 给出两条路：让模型决定，或用代码决定。把 Agent 当作工具时，管理者保持控制权，像调用函数一样调用专家；用移交（handoff）时，分诊 Agent 把对话交给专家，专家成为活跃 Agent。底层上，一次 handoff 不过是一个名为「转交给退款 Agent」之类的工具。文档指出，用代码编排在速度、成本和性能上更可预测——移交换来灵活性，代码换来确定性。

**移交（handoff）**与「Agent 作为工具」是两种常被混淆的委托方式，区别在于控制权归属。Agent-as-tool 时，管理者 Agent 始终持有对话主循环，专家 Agent 只是一次有界调用，返回结果后控制权立即回到管理者；而 handoff 时，对话本身被转移，被移交的专家成为新的活跃 Agent，后续轮次由它继续处理，原 Agent 不再介入。实现层面，handoff 表现为一个特殊的工具调用，模型「调用」它即完成转移，因此对模型而言两者都是工具，只是语义与被调用的运行时行为不同。

上下文隔离是多 Agent 编排的隐形收益。每个子 Agent 拥有独立的上下文窗口，只接收被显式传入的信息，这既避免了主对话被大量中间结果污染，也让子任务可以并行。代价是信息需要显式传递，跨 Agent 的状态共享要由编排层负责，否则子 Agent 会在信息缺失的前提下做出判断。

两种混合形态

Google 的 ADK 兼而有之：工作流 Agent 可以按顺序、并行或循环运行子 Agent，无需模型决策；协调 Agent 则通过为每个子 Agent 生成的工具进行委托。版本 2 增加了图，在 Python 和 Go 中取代了这些模板。

最后是 Claude Agent SDK——运行 Claude Code 的同一个循环。默认由循环自己编排，孵化各自带上下文的子 Agent；在 TypeScript SDK 中，工作流工具可以一次性编排数十个 Agent。

面试提示：说清楚「谁决定下一步」——代码、管理者还是模型——并选择能完成任务的最小自由度。

第五层：账单是怎么被削减的

每一轮都会重新发送整个对话，所以先看什么在重复。据该频道分析，在 Claude Opus 5.5 上，输出成本是输入的五倍，而缓存从不影响输出定价。

缓存：稳定前缀优先

提示缓存依赖一个保持完全一致的前缀：系统提示词、工具、记忆文件。缓存读取价格远低于未缓存输入，默认存活 5 分钟，且只有完全相同的前缀才计入。所以把稳定部分放前面，变化部分放后面。语义缓存更进一步，用相似问题的存量答案复用，但在某项基准上，正确命中与错误命中的平均相似度几乎相同（0.84 与 0.85）——这意味着它并不总能分辨对错。

路由、批处理与裁剪

不是每一轮都值得送给最大的模型。路由器把简单请求分给小模型，困难请求分给强模型；在 RouteLLM 论文中，某些测试下路由把成本降低了两倍以上且不损质量，另一项基准上它用的 GPT-4 调用比随机路由少数倍，同时保持约 95% 的 GPT-4 质量——不过那是 2024 年的模型，需要在你的场景上实测。

能等的任务走批处理 API：Anthropic 与 OpenAI 都对批处理收取半价，OpenAI 承诺 24 小时内返回结果；在 Anthropic 的 API 上，批处理与缓存折扣可以叠加。夜间评测和批量打标属于这里，而不是实时循环。

历史记录同样要裁剪：Anthropic 的压缩机制用摘要替换较早的轮次，上下文编辑则清理旧的工具结果。注意，清理会改变前缀，下一次调用就要为新缓存写入付费。

最后是模型本身：在够用的地方换更小的模型，或做蒸馏与量化。一个 80 亿参数模型在 16 位下权重约需 16GB，4 位下约 4 到 5GB。

提示缓存的前缀匹配要求从第一个 token 起完全一致，任何位置的改动都会使该位置之后的缓存全部失效。因此系统提示词、工具定义、记忆文件这类稳定内容必须排在前面，用户输入与工具结果这类变化内容排在后面。缓存写入通常比普通输入更贵，读取则便宜得多，所以缓存的价值取决于同一前缀被复用的次数——一次性请求反而可能因写入而变贵。

批处理与缓存的叠加需要留意语义：批处理 API 以异步、非实时换取折扣，而提示缓存要求在时间窗口内重复命中同一前缀。批处理任务往往批量提交相似请求，理论上利于缓存复用，但由于任务未按顺序执行、时间窗口不确定，实际命中率并不保证。在估算成本时应把两者视为可叠加但非必然同时生效的优化手段。

四条规则速查

1. 模型只负责请求，规则在它之外做决定。
2. 行是沿计划树向上拉取的，加索引前先读计划。
3. 明确谁决定下一步，并给出能完成任务的最小自由度。
4. 缓存前缀、路由简单轮次，并记住输出最贵。

整条链路串起来就是：你输入一行，Claude Code 补充记忆文件并调用模型；模型请求工具；钩子先行，然后按拒绝、询问、允许的顺序检查，全部在模型之外；工具运行并发出 SQL；Postgres 解析、重写、规划，从缓冲区缓存拉取计划树上的行；结果返回、轮次落盘，循环再次运行，直到没有工具调用；当一个 Agent 不够时，由某人决定下一步——你的图、一个管理者，或模型本身。这就是「回车」到「答案」之间发生的全部。