LLM API 对请求的 前缀（prefix） 做自动缓存。两次请求的 prompt 开头部分完全相同时，相同部分的 token 不再重新计算，只付缓存价（通常低 100 倍以上）。

2 详细回答

2.1 命中条件

1. 必须是前缀：缓存只认从 prompt 第 1 个 token 开始的连续相同段
2. 完全匹配：字符级一模一样才命中，多一个空格就失效
3. 至少 N 个 token：大部分模型要求缓存段 ≥ 1024 token
4. TTL 内：缓存有效期通常 5-10 分钟，超时重新计算

2.2 什么最容易命中

• System prompt / 系统指令：每轮对话都一样 → 必中
• 多轮对话（重点）：同一对话框里持续聊天，每轮请求都会把"全部历史"重发给 API。历史部分和上一轮请求完全相同 → 前缀越来越大，缓存命中越来越多
• 反复引用的长文档/代码：同一个文件的 content 放前面
• AGENTS.md：每次都是 system prompt 开头 → 必中

2.2.1 多轮对话为什么自动命中

关键认知：每次发消息，API 收到的是"全部聊天记录 + 你的新消息"，不是只发新的一句。

所以同一个框连聊 20 轮，从第 2 轮起前面绝大部分都是缓存价，真正按输入价算的只有最新一句。

2.3 为什么便宜百倍

Transformer 推理最贵的步骤是 self-attention 的 KV 矩阵计算。如果 prefix 相同，上一轮算好的 KV cache 直接复用，跳过计算，只剩后面新增 token 的增量计算。服务商 GPU 成本大头被消除，所以定价极低。

2.4 实际影响

• 第一次请求：按输入价全额计费
• 后续请求（前缀相同）：前缀部分按缓存价，新增部分按输入价
• AGENTS.md / 项目 context 只有第一次会话贵，之后近乎免费

3 知识扩展

不同模型的缓存定价差异很大：

• DeepSeek V4 Pro：缓存 ¥0.02 → 是输入价的 1/147
• Qwen3.7 Plus：缓存 ¥0.27 → 是输入价的 1/10
• 缓存折扣越大，说明该模型在长对话/大 context 场景越划算

之前对 AI 的底层原理理解很模糊，一堆术语堆在一起分不清。今天从对话里一步步拆明白了。

主要卡点：

1. 模型的"权重"到底是静态的还是动态的 → 两种都有
2. Decoder-only 为什么不需要 Encoder → Decoder 自己就能看自己
3. Attention 里的 Q、K、V 到底是什么 → 每个 token 乘三个矩阵算出来的

2 最终理解

2.1 两种权重别搞混

2.2 Attention 三步（用"今天天气很好"生成"好"为例）

每个 token 变成向量后，乘三个矩阵（W_q、W_k、W_v），得到三样东西：

• Q（查询）：我要找什么信息
• K（键值）：我身上有什么标签
• V（价值）：我身上有什么信息

然后：当前位置的 Q × 每个位置的 K → 得出得分 → softmax 归一化 → 用归一化后的分数加权取 V → 最终输出。

关键是自己在注意力计算时能看自己，不是只看前面的词。

2.3 Transformer = 注意力 + 前馈，叠 N 层

1
2
3
4

输入文字
   → Token Embedding + 位置编码
   → [Self-Attention（看全局）→ 前馈网络（消化信息）] × N 层
   → 线性层 → 预测下一个字

2.4 为什么现在的大模型都是 Decoder-only

原始 Transformer 有 Encoder + Decoder，但聊天场景下输入和输出天然在一条序列里，Decoder 的 self-attention 自己就能回看所有 token，不需要 Encoder 额外"翻译"。

3 联系之前的问题

• 缓存为什么便宜：每个 token 的 K、V 上轮已经算好了，直接复用不用重算
• 多模态为什么多一个编码器：图像被打包成视觉 token 送进同一个 Transformer

文本模型只认识 token（词元）。多模态模型在语言模型外面加了一个视觉编码器（Vision Encoder），把图像切块（patch）变成"视觉 token"，再投影到和文字 token 相同的向量空间，喂进同一个 Transformer。所以图像对它来说也是一串"符号"，只是这个符号来自像素而不是文字。

2 详细回答

2.1 文本模型怎么读文字（基线）

1

"你好" → 分词器 → [token1, token2] → 嵌入表查表 → 向量 → Transformer

文字本来就有天然的分词方法（中文按字/词，英文按子词），每个 token 对应嵌入表里的一行向量。

2.2 多模态模型怎么读图像

1
2

1024x1024 图片 → 视觉编码器(ViT/CLIP) → 切成 16x16 的 patch → 每个 patch 一个"视觉 token"
→ 线性投影层（Projection Layer）→ 和文字 token 同一向量空间 → 同一个 Transformer

关键点：

1. 图像不是"直接看懂"，而是被转换成视觉 token 序列。一张 1024x1024 的图 ≈ 256~576 个视觉 token
2. 视觉编码器和 LLM 是两个网络，中间靠一层投影矩阵对齐
3. Transformer 对 token 一视同仁——不管是文字 token 还是视觉 token，都走 attention

2.3 和训练方式的区别（多模态要分阶段训）

所以多模态不是"文本模型加了读图功能"，而是从一开始就用图文数据训练，训练数据和计算量都大得多。

2.4 视频怎么读

视频 = 连续帧。处理方式：

1. 抽帧（通常 1~2 fps，即每秒抽 1-2 帧）
2. 每帧走视觉编码器变成视觉 token
3. 按时间顺序拼成超长 token 序列喂给模型
4. 部分模型（如 Gemini、Qwen2.5-VL）还有音频编码器，把声音轨也变成 token 一起处理

这就是为什么视频贵：1 分钟视频 = 60 帧 × 每帧 2561100 token ≈ 1.5万6.6万 token。

2.5 PDF 怎么读

PDF 本身不算独立模态：

• 有文字层的 PDF → 直接抽文字（像文本一样）
• 扫描件/图文混排 → 每页渲染成图像，走视觉编码器读
• 大多数模型实际是"按页转图再读"

3 知识扩展

• 判断一个模型是否多模态，看它有没有视觉编码器，而不是看名字
• 同一模型的多模态版本（如 GPT-4o vs 纯文本 GPT-4）架构差别主要在编码器部分，LLM 主干基本共享
• DeepSeek V4 Flash 是文本模型，所以视频/图片对它 = 不可读；要用多模态功能得换支持视觉的模型

所有插件机制本质相同：宿主留扩展点（接口），插件注册回调函数，宿主在关键时刻调用回调。配置文件覆盖、Obsidian 插件、游戏 Mod 全是这个套路。

2 详细回答

2.1 1. 配置覆盖原理

以 opencode 模型名显示为例：opencode 启动时读取配置并与模型数据合并（数据在 ~/.cache/opencode/models.json），选择器渲染时取合并后的 model.name。所以在 opencode.jsonc 里写：

1

{ "provider": { "opencode-go": { "models": { "deepseek-v4-flash": { "name": "...价格..." } } } } }

就能覆盖显示名。改配置 → 改数据 → UI 自动变，没碰任何程序代码。

2.2 2. 插件机制的通用四步

1. 扩展点：宿主在关键流程留接口（消息发送前、工具执行后、模型显示时…）
2. 注册：插件把函数注册到挂钩点（宿主保存回调列表，不写死行为）
3. 调用：宿主在合适时机遍历回调列表依次调用
4. 公开 API：插件只能通过宿主开放的 API 交互，拿不到内部实现

2.3 3. C++ 类比

• 接口 + 虚函数：class IPlugin { virtual void onLoad() = 0; }，插件实现接口
• Windows：DLL 动态加载（LoadLibrary）
• 设计模式：观察者模式 / 回调函数指针

2.4 4. 插件的写法

1
2
3
4
5
6
7
8

export default (async ({ client, project, $ }) => {
  return {
    config: (cfg) => { /* 配置加载时 */ },
    "tool.execute.before": async (input, output) => { /* 工具执行前 */ },
    "chat.message": (input) => { /* 每来一条消息 */ },
    event: (input) => { /* 所有事件 */ },
  }
})

加载：plugin: ["npm包名", "./本地.ts"]，或放 .opencode/plugin/ 自动发现。宿主启动时调用导出函数拿到 hooks，之后事件发生时调用对应 hook。

2.5 5. 对照：Obsidian 插件

manifest.json 声明 → Obsidian 扫描插件目录 → 实例化 class extends Plugin 并调用 onLoad() → 在 onLoad 里注册 ribbon 图标、状态栏、命令。和 export default function 是同一件事的两种写法：宿主调用插件注册的回调。

3 知识扩展

• 事件总线：宿主发布事件，插件订阅（event hook 就是这个）
• 生命周期：发现插件 → 加载模块 → 拿 hooks → 绑定事件 → 卸载时清理
• 宿主不直接引用插件类型，通过约定的接口/函数签名解耦——插件和插件之间互不感知

• Codex 能接 DeepSeek，三行配置的事
• Cloud Code（Google）基本不能接，绑定自家生态
• 效果差别：外壳（工具本身）一样，上限由模型决定；GPT-5-Codex 为 coding agent 特调，DeepSeek 是通用模型，复杂任务差距明显、简单任务够用且便宜

2 我的想法 / 卡点

之前一直以为这些工具只能用自己的模型，聊完才知道：

• Codex 2026 年 6 月官方宣布支持第三方模型，从"OpenAI 专用客户端"变成"模型中立的编码代理平台"
• 我的困惑点是"DeepSync 是什么"——其实是语音识别把 DeepSeek 听错了
• “Cloud Code 源码泄露导致 React/Reason 流行"这个说法也记错了：泄露的是 Claude Code（Anthropic），不是 Google 的 Cloud Code

3 详细回答

3.1 Codex 接入 DeepSeek（可行）

~/.codex/config.toml 加 provider 定义：

1
2
3
4

[model_providers.deepseek]
name = "DeepSeek"
base_url = "https://api.deepseek.com/v1"
env_key = "DEEPSEEK_API_KEY"

命令行走 codex --provider deepseek --model deepseek-coder 切换。Kimi、GLM、Qwen、Ollama 同理。

坑：

• Codex 2026 年 2 月起默认走 Responses API，第三方接口大多只有 Chat Completions，需设 wire_api = "chat"，否则报流式/格式错误
• 桌面端接 DeepSeek 需要两层本地代理（模型名映射 + Responses→Chat 转换），社区有现成方案
• provider ID 区分大小写，模型名前缀写错会被静默忽略走 fallback

3.2 Cloud Code 接入 DeepSeek（基本不可行）

• Cloud Code（IDE 插件）绑定 Google 生态，不开放自定义模型
• Gemini CLI（已开源）原生只认 Gemini；需"魔改版"或 LiteLLM 代理才能接 DeepSeek
• 且 Gemini CLI 免费版 2026-06-18 已停用，个人用户迁移到 Antigravity CLI

3.3 效果差别：外壳一样，上限由模型决定

结论：日常小活用 DeepSeek 省钱，大活切回专用模型。Codex 支持多 provider 随时切，opencode 本身 75+ 模型随便换。

3.4 彩蛋：源码泄露事件的真相

• 2026-03-31，Anthropic 的 Claude Code 因 npm 包遗留 59MB source map（cli.js.map），51.2 万行 TypeScript 全曝光（第二次同原因泄露）
• 大家因此看到：终端 UI 用 React+Ink、Bun 运行时、40+ 工具模块、权限分层
• React（2013 年）/ ReAct（2022 年论文）不是泄露"导致"的，泄露只是让大家看到了顶级 Agent 的工程实现，引发讨论和借鉴

4 知识扩展

• DeepSeek API 完全兼容 OpenAI 协议，官方文档有 coding agents 接入指南
• Codex config.toml 三级配置：用户级（~/.codex/config.toml）→ 项目级（.codex/config.toml）→ 命令行参数，优先级递增
• 环境变量方式（OPENAI_BASE_URL）只能配一个 provider，config.toml 支持多 provider 并存切换

读完这篇文章，你就能明白：AI 是怎么从"只会聊天"变成"能帮你做事"的！

1 🧠 一、先认识 LLM（大语言模型）

LLM 就像一个读了超级多书的学霸。

你问它什么，它都能回答。比如你问：“恐龙是怎么灭绝的？“它能给你讲得头头是道。

但它有一个大问题：只会说，不会做。

• 你让它"帮我订个外卖”，它只能告诉你"你可以打开外卖 App 来订…"——它没法真的帮你下单。
• 你让它"帮我把作业发到老师邮箱”，它也只能告诉你怎么做——它没法真的帮你发。

就像一个有嘴没手的人，讲得头头是道，但你让它动手做事，它就没办法了。

2 🦸 二、Agent 是什么？——给 LLM 装上"手和脚"

Agent（智能体）就是解决了这个问题！

Agent = LLM（大脑）+ 工具（手和脚）+ 记忆 + 规划能力

2.1 用一个小故事来理解

• LLM：像一个只会给你提建议的顾问。你问"怎么收拾房间？“他说"先把书放好，再把玩具收起来…"——但他绝不会动手帮你。
• Agent：像一个能帮你干活的小管家。你说"帮我收拾房间”，他会自己去拿扫把、整理书架、把玩具放进箱子，直到房间干干净净！

2.2 Agent 能做什么？

3 🏭 三、Workflow 和 Agent 的区别

• Workflow：就像工厂流水线——每一步做什么都是提前规定好的，按顺序来。
• Agent：就像一个聪明的小帮手——你只告诉它目标，它自己决定怎么做。

举个例子：处理退换货

• Workflow 的做法：每一步都写死在程序里（先查订单→再判断能不能退→然后退款→最后发邮件）
• Agent 的做法：收到退货申请后，自己去查订单、看退货政策、判断要不要退款、发邮件——每一步都是它自己决定的！

💡 简单记：Workflow 是"我告诉你每一步怎么做"，Agent 是"我告诉你目标，你自己想办法"

4 🎮 四、Agent 的四种工作模式

就像小朋友写作业有不同的方式，Agent 也有不同的"干活方式"：

4.1 1. 🏃 ReAct（边想边做）

学到哪做到哪。先想一步→做一步→看看结果→再想下一步。像玩迷宫游戏，走一步看一步。

4.2 2. 📝 Plan-and-Execute（先列计划再做）

先把整个计划写下来，然后一步一步执行。像写作文前先列提纲，再按提纲来写。

4.3 3. 🔍 Reflection（做完再检查）

做完之后自己再检查一遍，发现问题就改。像考试做完卷子再检查一遍。

4.4 4. 👥 Multi-Agent（团队合作）

让好几个 Agent 分工合作，各做各擅长的。就像一个小组作业，有人查资料、有人写报告、有人做 PPT。

5 🔧 五、Function Call——Agent 的"超能力"

Function Call 就是让 AI 能"打电话"的能力。

• 以前：你问 AI “今天天气怎么样？“它只能猜。
• 现在：AI 会"打电话"给天气 App，查到真实数据后再告诉你！

就像你问妈妈一个问题，妈妈不知道，但她会打电话问别人，然后再告诉你答案。

6 🔌 六、MCP——AI 世界的"USB-C 接口”

MCP 是一个统一标准，让 AI 能用同一种方式连接各种工具。

想象一下：

• 以前：每个设备充电都要用自己的充电线（iPhone 用 Lightning、安卓用 Micro-USB…）——太乱了！
• 现在：大家都用 USB-C，一根线搞定所有设备。

MCP 就是 AI 世界的 USB-C——一种通用的连接方式，让 AI 能轻松接入任何工具（搜索、邮件、数据库…）。

7 📖 七、Skills——AI 的"菜谱”

Skills 是教 AI “怎么做事"的说明书。

打个比方：

• MCP = 厨房里有锅、有刀、有烤箱（工具）
• Skills = 菜谱，告诉你怎么做红烧肉（方法）

光有工具不够，还得知道怎么用！Skills 就是在教 Agent：“遇到这种情况，你应该这样做…”

8 🗣️ 八、A2A——Agent 之间的"电话”

A2A 是让不同的 Agent 之间能互相聊天、协作的协议。

比如：一个公司里，有 HR Agent（管人事）、IT Agent（管电脑）、财务 Agent（管工资）。新员工入职时，这三个 Agent 需要一起配合。

A2A 就是让它们能互相"打电话"、分配任务的标准方式！

9 🎯 总结：一张图搞定所有概念

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

┌──────────────────────────────────────────────┐
│                  Agent（智能体）               │
│  ┌─────────┐  ┌──────────┐  ┌────────────┐  │
│  │ 🧠 大脑  │  │ 📝 规划  │  │ 💾 记忆    │  │
│  │  (LLM)  │  │          │  │            │  │
│  └─────────┘  └──────────┘  └────────────┘  │
│                   ┌──────────────┐           │
│                   │ 🔧 工具模块   │           │
│                   │ Function Call │           │
│                   │ MCP 协议      │           │
│                   │ Skills 技能   │           │
│                   └──────────────┘           │
└──────────────────────────────────────────────┘

Function Call → 让 AI 能"打电话"（最基础的能力）
MCP          → 统一的连接标准（AI 的 USB-C）
Skills       → 教 AI 怎么做事（AI 的菜谱）
A2A          → Agent 之间的沟通协议（Agent 的电话）

10 🌟 记住这三句话就够了

1. LLM 是大脑：会想会说，但不会做
2. Agent 是完整的人：有大脑（LLM）+ 手和脚（工具）+ 记忆 + 计划
3. Function Call / MCP / Skills / A2A：都是让 Agent 变得更强的方法