Claude非专业入门实战笔记（4）：Claude运行方式简单解析——从RAG到代理循环

本节将简单说明我对于claude的运行方式的理解。在搭建了本地的RAG服务器后，我理解了RAG的处理流程：简而言之，就是把本地数据库抽象为向量，在用户问了相关问题后，计算问的问题和数据库里面的一个个向量的相关性，选择相关性最高的一个或几个块，与用户提的问题组合到一起并提供给LLM，获得LLM的答案后提供给用户。本地搭建RAGFlow与Ollama集成：从驱动配置到私域知识库部署。通过GPU加速嵌入模型与检索优化，实现可控、可溯源的AI问答系统，解决OCR与检索瓶颈，提升LLM生成准确性。_sed -i '1i device=gpu' .env-CSDN博客文章浏览阅读1.5k次，点赞17次，收藏30次。作者在RTX5080工作站完整搭建RAGFlow私域问答系统：先装nvidia-driver-580-open与Docker GPU支持，再用Ollama部署12b量化Gemma-3；解析-分块-embedding-向量库全流程CPU轻量，问答阶段GPU加速。针对deepdocOCR未用GPU、召回chunk不准两大痛点，给出Docker内升级PyTorch cu121、固化镜像、换bge-m3长文本嵌入、调Top-K至80、手动白名单、并启用bge-reranker-large精排等可落地方案，实现40 _sed -i '1i device=gpu' .envhttps://blog.csdn.net/Mr_liu_666/article/details/154238671

后面用起来，一方面由于分块大小微调效果不好、一方面由于向量化的结果效果也不好、重排序效果也不好，导致问答的效果很差，甚至不如自己查找关键词，编辑相关段落、组合问题并提供给网页对话式大模型，所以RAG后面弃置不用，开始用claude。

系列包括以下几个内容：

1. 环境搭建：Claude非专业入门实战笔记（1）：Ubuntu环境下的VSCode安装与API配置-CSDN博客
2. 配置、使得claude能做一点事情：Claude非专业入门实战笔记（2）：CLAUDE.md规则与目录权限设计，让Claude自动整理文献-CSDN博客
3. claude的同步：Claude非专业入门实战笔记（3）：多台Ubuntu通过软链接与工作区统一实现Claude记忆同步-CSDN博客
4. calude运行方式简单解析：Claude非专业入门实战笔记（4）：Claude运行方式简单解析------从RAG到代理循环-CSDN博客
5. claude的交互抓包：Claude非专业入门实战笔记（5）：mitmproxy抓包解析Claude请求与流式响应，看清它到底做了什么-CSDN博客

claude运行方式简单解析

经过抓包读取claude与LLM的交互信息我们可以看到Claude 并不是直接把我的话发给大模型，而是自己"加了很多料"。简单来说，Claude Code 本质上是一个模型代理平台，它提供了：

• 工具系统：

  • 文件操作：读写、编辑、搜索项目文件

  • 终端命令：可执行任意命令（需要用户批准）

  • MCP 工具：通过配置接入任意外部工具（浏览器、数据库、API 等）

  • 内置知识：一些常见的命令手册、编程规范（硬编码的默认提示词）

• Agent 循环 ：

  接收用户指令 → 模型决策下一步行动（调用工具或回答） → 执行工具并反馈结果 → 继续循环，直到任务完成。

• 对话管理 ：

  自动拼接系统提示、用户指令、工具执行记录、文件内容，组装成 API 请求发送给后端模型。

• 安全与沙盒 ：

  命令执行前可预览、批准；文件修改有 diff 显示；支持异步后台运行。

Claude Code 并不是"传话筒"

很多人以为，Claude Code 就是一个聊天窗口，你输入一句话，它转给大模型，再把答案显示出来。实际上它做的事情远不止这些。

抓包时我们看到，当你在终端输入"你是谁？守则是什么？"这样简单的问题时，Claude Code 实际发给大模型的请求体（request）里包含了三大块内容：

1. 你输入的用户消息（"你是谁？守则是什么？"）

2. 系统注入的上下文（当前日期、提醒信息等）

3. 一长串关于可用 Agent 类型、Skills 技能的说明

此外，请求体中还会有一个 tools 字段（虽然截图中没完全显示），里面用 JSON Schema 定义了各种工具的参数格式，比如 Bash、Read、Write、Edit 等。

这说明 Claude Code 的角色是一个**"调度器"或"代理外壳"**：它把用户指令、当前环境信息、可用的工具清单打包好，发给大模型；大模型不是直接回答文本，而是先"思考"下一步该做什么------是直接回答，还是调用某个工具。

从响应侧看：它不是在"写作文"，而是在"下指令"

抓包返回的 response 非常有意思。它不是一次返回一大段话，而是通过 Server-Sent Events（SSE）流式返回，像打字机一样一个 token 一个 token 地蹦出来："我是"" Claude"" Code""，""An""throp""ic""官""方的"......

这背后其实是两种可能的响应类型：

• 纯文本回答：模型认为可以直接回答用户，就流式输出文本。

• 工具调用 ：模型认为需要执行某个操作，就会返回一个结构化的 tool_use 块，里面指明要调用哪个工具、传什么参数。

非专业用户通常只看到第一种，因为 Claude Code 在收到 tool_use 后会默默执行工具，再把执行结果追加到下一轮的请求里，整个过程对用户透明。但如果你仔细观察终端输出，有时会看到"正在读取文件""正在运行命令"等提示，这些就是模型在指挥 Claude Code 干活。

完整运行循环：一个自动化的"问---做---反馈"过程

综合请求和响应，我们可以把 Claude 的运行方式总结成下面这个循环：

1. 接收用户指令

   你在终端输入一句话，比如"帮我把 Reference 文件夹里所有 CSV 文件里的论文标题提取出来，整理成表格"。

2. 组装请求

   Claude Code 把你这句话、当前的 CLUADE.md 规则、目录结构说明、可用工具定义、当前日期等全部打包成一个 HTTP 请求，发送给后端大模型。

3. 模型决策

   大模型根据收到的信息，判断下一步该做什么。它可能直接回答"好的，我计划这样做......"，也可能返回一个工具调用，比如"先执行 ls Reference 看看有哪些 CSV 文件"。

4. 执行工具

   Claude Code 收到工具调用后，在本机执行对应的命令（例如运行 ls），拿到输出结果。

   注意：这一步是在你电脑上真实执行的，所以需要权限控制。这也是为什么我们之前在 CLAUDE.md 里规定"新建文件直接写，修改文件要申请权限"------因为模型可能会让 Claude Code 执行修改操作。

5. 反馈结果

   Claude Code 把工具执行结果作为新的消息追加到请求里，再次发送给大模型。

6. 继续循环

   大模型看到工具结果后，可能再决定调用下一个工具（比如打开某个 CSV 文件读取内容），如此循环，直到它认为任务完成，最后流式输出一段总结文本给你。

这个循环就是 Claude 官方文档里提到的 agentic loop（代理循环）。说白了，就是"模型当大脑，Claude Code 当手脚，大脑下命令，手脚去执行，执行结果再告诉大脑，直到大脑说'好了，我把结论给你'"。

为什么它要这样设计？

理解了循环之后，很多非专业用户的疑惑就能解开了：

• 为什么有时候回答很快，有时候很慢？

  因为如果只是简单问答（比如"你是谁"），模型直接返回文本，一轮就结束，自然快。如果模型需要连续调用十几个工具（比如遍历目录、读取多个文件、分析、修改），就要走多轮循环，当然慢。

• 为什么我让它做事情，它有时会"自己做决定"？

  因为模型是在"决策"而不是"回答"。它看到你的指令，会自己规划步骤，所以你需要通过 CLAUDE.md 告诉它边界，比如"只能访问当前目录""修改文件要申请权限""禁止使用 Python"。这些规则在每次请求时都会被 Claude Code 放进系统提示里，模型就会遵守。

• 为什么我写了 CLAUDE.md 它就能记住？

  因为你写的规则被 Claude Code 加载后，会作为系统上下文的一部分发送给大模型。大模型每次"思考"时都会看到这些规则，所以它会遵守。这跟传统的"记忆"不同，更像是每次开会前把规章制度念一遍。

非专业用户如何利用这个运行机制

明白了 Claude 是一个"带工具的代理循环"之后，我们就能更聪明地使用它：

1. 把规则写清楚 ：CLAUDE.md 越明确，模型越不容易跑偏。比如指定文件结构、允许的命令、修改权限，等于提前给"大脑"画好地图。

2. 控制工具范围：你可以在设置里限制模型能调用哪些工具。比如我禁止了 Python，只保留 shell、grep、sed 等，既安全又能减少"乱试"造成的 token 浪费。

3. 善用流式输出：虽然流式只是显示方式，但它能让你更快看到模型思路，遇到不对的地方可以及时打断。

4. 理解权限提示：每次出现"是否允许执行某某命令"时，其实是 Claude Code 在执行模型给的工具调用前征求你的同意。你可以根据对模型的信任程度设置自动允许，但涉及修改类操作建议保留申请。

总结

通过抓包我们看清了：Claude 的运行方式，本质上就是把用户的问题、上下文、工具清单打包给大模型，由大模型决定"下一步做什么"，然后 Claude Code 负责执行，把结果反馈回去，如此循环直到任务完成。它不是简单的聊天机器人，而是一个能操作电脑的"代理"。

这个机制解释了为什么 Claude Code 能帮你整理文件、修改论文、批量处理文献------因为它有一个能指挥工具的"大脑"。同时，它也提醒我们：给它的规则越清楚、权限边界越明确，它就越能按照你的想法自动干活。

关于claude的宏观认识

Claude Code需要embeding和rerank吗？

视文献规模与检索方式而定：

• 不需要的情况

  如果你每次只打算搜索几篇到十几篇论文，把它们的摘要交给 Claude 对比分析，Claude 200K 的长上下文完全够用，直接用提示词就可以做信息提取、比较和总结，完全无需外部向量检索。

• 需要的情况

  如果你有一个本地论文库，里面存了几百上千篇 PDF/摘要，想用"这句话和哪篇最像"来做语义检索，再精排，那就需要：

  • 一个 embedding 模型（把文本转向量）

  • 一个向量库 + 检索工具

  • 可选的 reranker 来提升精度

Claude Code本身自带 embedding 或 rerank 服务？

既然可以读取文件并判断哪些需要发给LLM，那么是不是内部做了embedding 或 rerank？

事实上上下文窗口够大了，不需要这么复杂的过程，LLM可以通过 完整的注意力机制和长上下文窗口（200K tokens或1M） 直接阅读、理解和比较你交给它的文本。

对于你的场景------搜回来的几篇到几十篇论文摘要，Claude 可以一次性"装"进上下文里，直接分析异同、提取要点，不需要任何向量转换或重排序。

问题和本地文件都是直接给LLM的，Claude Code有啥用？

Claude Code 本质上是一个模型代理平台，它提供了：

• 工具系统：

  • 文件操作：读写、编辑、搜索项目文件

  • 终端命令：可执行任意命令（需要用户批准）

  • MCP 工具：通过配置接入任意外部工具（浏览器、数据库、API 等）

  • 内置知识：一些常见的命令手册、编程规范（硬编码的默认提示词）

• Agent 循环 ：

  接收用户指令 → 模型决策下一步行动（调用工具或回答） → 执行工具并反馈结果 → 继续循环，直到任务完成。

• 对话管理 ：

  自动拼接系统提示、用户指令、工具执行记录、文件内容，组装成 API 请求发送给后端模型。

• 安全与沙盒 ：

  命令执行前可预览、批准；文件修改有 diff 显示；支持异步后台运行。

它不包含任何模型权重、embedding 或 reranker，所有推理都交给配置的后端模型。

那么deepseek网页免费版本的问答、是不是某种意义上和claude是一样的？

是的，底层的"文本生成"原理一模一样，都基于"给定上下文，逐 token 预测下一个词"的自回归生成，排序（即 token 选择策略：temperature、top-p、top-k）也完全相同。

区别在于工作流的控制粒度：

维度	普通网页对话	Claude Code（作为 Agent）
输入构造	用户输入文本 + 历史对话	用户指令 + 工具描述 JSON + 文件内容 + 终端输出 + 对话历史，由框架自动拼接
输出解析	直接展示文本给用户	输出可能是"工具调用" JSON，框架拦截并执行，然后把执行结果喂回模型继续生成
交互模式	一问一答，人始终在循环中	模型自主决策何时调用工具、何时终止，形成 Observation → Action → Feedback 循环
上下文管理	固定窗口，满了自动截断	主动裁剪、摘要、压缩，尽量保留关键信息，还可以将中间结果写入外部文件
工具调用	无（或极其有限的插件）	可调用文件系统、终端命令、浏览器、数据库等，由 MCP 协议标准化

所以，更准确地说：

Claude Code 并没有改变模型的"排序/生成"机制，它只是在提示词中塞入了工具定义和调用协议 ，并把模型的某些输出解释为操作指令而非最终回答。底层模型依然是个"下一个 token 预测器"，但 Claude Code 给它加了一层"执行器壳"，把它变成了能感知环境、反馈迭代的自主代理。

LLM到底是咋能回答我们的问题的？

底层架构：都基于大规模 Transformer 的自回归语言模型，使用海量互联网文本训练，通过 SFT+RLHF 进行对齐，具备上下文学习、推理、多轮对话能力。

1. Transformer 模型

Transformer 是一种彻底抛弃了循环（RNN）和卷积（CNN）的序列建模架构 ，完全基于自注意力机制（Self-Attention） 来捕捉序列中任意位置之间的依赖。

关键组件：

• 自注意力：每个位置的表示通过计算它与其他所有位置的"相似度分数"（Query·Key^T / √d），加权聚合 Value 向量。这使得梯度路径极短，能直接捕获长距离依赖，且支持大规模并行计算。

• 多头注意力：多组 Q/K/V 投影，让模型在不同子空间里关注不同模式（如句法、语义、位置等）。

• 位置编码：由于没有循环/卷积，需要显式注入位置信息（原始论文用正弦编码，现在常用可学习的或 RoPE）。

• 残差连接 + LayerNorm：原论文用 Post-LN，现在主流用 Pre-LN 改善训练稳定性。

• 前馈网络（FFN）：每个位置独立地通过两层 MLP + 激活函数（通常是 GeLU 或 SwiGLU 变体），增加非线性。

大语言模型中的 Transformer 变体 ：

现在几乎所有 LLM（包括 DeepSeek、Claude）都是 解码器专用 Transformer（Decoder-only） ，即只保留原始 Transformer 的解码器部分，使用因果自注意力掩码（每个 token 只能看到它之前的 token）。这样模型自然成为"给定前缀预测下一个 token"的自回归语言模型。

为什么它这么强？

• 可扩展性：Transformer 在训练时每个 token 的注意力计算是 O(n²)，但它对 GPU/TPU 极其友好，可以堆到几百层、上万亿参数。

• 上下文窗口可以很长（现在百万 token 级别），因为注意力能直接关联任意距离的位置。

---

2. SFT + RLHF

这是现代 LLM 对齐训练的两个阶段，有 RL 基础的话更容易理解。

背景：基础语言模型（base model）通过海量文本的 next-token prediction 训练，得到了强大的"世界知识"和"语法能力"，但它只会续写文本，不会"遵循指令"或"对齐人类偏好"。

步骤一：SFT（Supervised Fine-Tuning，监督微调）

• 收集大量高质量指令-回答对（人工标注或由强模型生成），让模型以标准的监督学习方式微调。

• 目标：最小化模型输出与标准回答之间的交叉熵损失（和预训练一模一样，只是数据变了）。

• 作用：教会模型格式 （比如"问→答"的对话格式）和基本对齐，让它能听指令、拒绝不安全请求、输出结构化内容。

步骤二：RLHF（Reinforcement Learning from Human Feedback）

• 为什么需要 RLHF？

  SFT 只能模仿示例，但很多任务没有唯一正确答案（比如"写一首诗"），好坏是主观的。而且 SFT 分布漂移后可能出现不期望的行为。RLHF 直接用人类偏好信号优化模型。

• 标准流程（InstructGPT / PPO 方法）：

  1. 训练奖励模型（Reward Model，RM）：拿同一个 prompt 下模型生成的多个回答，让人工标注偏好排序（A > B > C）。用该排序数据训练一个 scalar 模型，输入 prompt+response，输出"人类偏好分数"（通常用 Bradley-Terry 模型，损失为 pairwise ranking loss）。

  2. 用 PPO 优化策略（即 LLM 本身） ：以 reward model 的分数为奖励信号，最大化 E[ R(prompt, response) ]，同时加一个 KL 惩罚项，防止策略偏离 SFT 模型太远（避免"奖励黑客"行为，比如生成一些高奖励但无意义的文本）。

     目标函数类似于：max E[ RM(prompt, answer) - β KL(π_θ || π_SFT) ]。

• 现代演进 ：现在很多模型直接用 DPO（Direct Preference Optimization） 替代 PPO+RM 的两阶段。DPO 把偏好数据直接转化为分类损失，在离线数据上一步训练同时完成"奖励建模"和"策略优化"，无需显式训练 RM 和在线采样，数学上等价于 Bradley-Terry 模型下的 RLHF 最优解。

总结这个流程：

预训练 → 获得会说话但不懂规矩的"野人"

SFT → 教会它听懂指令、举止得体（模仿好行为）

RLHF/DPO → 用人类偏好进一步雕琢，让它更有用、诚实、无害，输出更符合期望

每个 token 只能看到它之前的 token，所以事实上LLM是一个一个词往外生成的

是的，语言模型（如 GPT、Claude、DeepSeek）本质是学习一个条件概率分布：

给定上文 x1,x2,...,xt−1x1​,x2​,...,xt−1​，预测下一个 token xtxt​ 的概率 P(xt∣x<t)P(xt​∣x<t​)。

• 训练时 ：模型一次看到整个句子，但计算每个位置的输出概率时，只能用到它之前的 token（因果掩码）。对于每个位置，模型给出一个向量，经 softmax 变成词表大小的概率分布，与真实的 next token（one-hot 向量）计算交叉熵损失，反向传播更新参数。"命中"可以理解为训练时预测最可能 token 与真实 token 一致，但模型优化的是最小化分布差异，不是简单追求命中率。

• 推理时（生成文本） ：模型是一步一步 生成的。它先根据初始 prompt 预测第一个生成 token 的概率分布，然后从该分布中采样（或贪婪选择最高概率的 token），得到 token t1t1​。接着，将 t1t1​ 拼回输入，再预测 t2t2​，如此反复，直到生成终止符或达到长度限制。

• 模型不会"提前准备好整个回复"，而是每次只生成一个 token，再把该 token 当作已知上下文继续预测下一个。

模型计费的命中与未命中是啥？

大模型在计算时，输入的 prompt 会先通过 Transformer 层转换为 KV 缓存（Key-Value Cache）。

• 如果系统检测到你发的 prompt 和之前某次请求的前缀完全一致 （或系统自动缓存了常见系统提示），它可以直接复用已算好的 KV 缓存，跳过大部分输入计算，直接进入生成阶段，极大地节省了 GPU 算力。

• 于是，云厂商就用低价（0.02 元/百万 tokens）鼓励复用缓存，高价（1 元）覆盖完整输入计算的成本。

为什么输出通常比输入贵？

"输出越多，模型每一步都要把之前的输出当输入，越往后越费劲"，更精确的解释是：

• 输入阶段：全部 prompt 一次性并行计算，GPU 利用率高，1 个 token 输入的计算成本较低。

• 输出阶段 ：必须逐个 token 串行生成，每生成一个新 token，都要把整个序列（prompt + 已生成的 tokens）重新计算一遍注意力（长度平方增长的复杂度）。生成 1000 token 的输出，要跑 1000 次前向传播，而每次的序列长度越来越长。因此输出 token 的算力消耗远高于输入 token。

所以输出 token 定价通常是输入的 2~5 倍。

深度思考模型（如 DeepSeek-R1、o1）训练与 token 消耗是否与没有深度思考的LLM不同

训练过程的确不同

普通模型：预训练 + SFT + RLHF（偏好对齐），追求直接生成最终答案，推理时不暴露内部推理过程。

深度思考模型：额外引入了长思维链训练。通常做法有：

在强化学习阶段使用过程奖励模型，不仅奖励最终答案正确，还奖励中间推理步骤的合理性和准确性。

使用 MCTS（蒙特卡洛树搜索）或自我反思迭代生成高质量推理路径，然后蒸馏进模型。

或者直接在冷启动数据中包含人类或 AI 编写的详细思维链，做大量 SFT。

因此深度思考模型学会了在输出最终答案前，先生成大量内部独白（即思考过程），这些思考 token 对用户可见（或半透明），并且显著增加了总输出长度。

是否输出 token 更多？是的，且正是其特点。
例如你问一个数学题：

普通模型可能直接输出答案，消耗 ~50 token。

深度思考模型会先输出 500 token 的推理过程："我们可以先设立方程... 考虑到... 因此..." 最后才给出答案。

所以实际计费时，深度思考模型的输出 token 消耗会成倍增加（甚至可达数倍到数十倍）。因此同类模型中，深度思考版的输出单价往往更高，或者虽然单价相同但实际花费因生成长度而暴涨。