二、RAG 与 Context 的关系#

RAG 本质上是 context 管理的一种工程手段。RAG 是其中专门用来解决”跨会话长期记忆”和”超出 context 容量的大知识库”的方案。它跟其他方案的关系不是替代，而是互补——长会话场景用 Compaction 压缩历史，跨会话场景用 RAG 检索相关内容，工具调用密集场景用 Subagent 隔离。

理解这一点之后，RAG 的所有设计都能从 context 视角解释。为什么要分块（chunking）：因为整篇文档塞不进 context；为什么要做语义检索：因为只能塞几个最相关的块，必须挑准；为什么要 rerank：因为粗筛回来的候选还有噪声，挑得不够准会浪费 context 预算；为什么要 contextual retrieval：因为分块切断了原文的语境，光看孤立块连相关性都判断不准。整套 RAG 就是围绕”如何用最少的 token 把最相关的知识塞进 context”展开的工程优化。

三、RAG 的工作流总览#

一套完整的 RAG 系统在工程上分为两个独立子流程：离线索引（Indexing） 与 在线查询（Retrieval + Generation）。两者在时间、成本、性能要求上完全不同——离线索引可能耗时数小时甚至数天，但只做一次；在线查询必须在数百毫秒内完成，且每次提问都触发。这是 RAG 系统设计的核心时间约束。

有一条硬性约束必须明确：离线与在线必须使用同一个 embedding 模型。不同模型生成的向量位于不同的几何空间，互相之间没有可比性。一旦切换 embedding 模型，所有历史索引必须重新生成。这是 RAG 工程中常被低估、但代价极高的一条铁律。

四、Embedding：把语义变成可计算的向量#

RAG 的整个工作机制建立在一个核心数学操作上——把文字变成可以比较的数字。这个操作叫 embedding。理解 embedding 是理解 RAG 的前提。

1
A: [0.21, -0.45, 0.88,  0.12, -0.33]
2
B: [0.23, -0.42, 0.85,  0.15, -0.30]   ← 跟 A 数值非常接近
3
C: [-0.61, 0.32, -0.17, 0.91,  0.44]   ← 跟 A 数值差很远

五、Indexing：把文档预处理好放进库里#

RAG 不是把整篇文档原封不动塞进数据库就完事了——文档必须经过一整套预处理流程才能被高效检索。这套流程叫 indexing（建索引）。

1
向量库（用于 embedding 检索）
2
  ┌─────────────────────────────────────────────────┐
3
  │ chunk_001  →  向量 [0.21, -0.45, ...]            │
4
  │             ↳  原文 "公司的收入比上一季度..."     │
5
  │ chunk_002  →  向量 [0.18, -0.42, ...]            │
6
  │             ↳  原文 "本季度推出了新产品..."       │
7
  │ ...                                              │
8
  └─────────────────────────────────────────────────┘
9

10
BM25 倒排索引（用于关键词检索）
11
  ┌─────────────────────────────────────────────────┐
12
  │ 词 "ACME"  →  出现在 [chunk_001, chunk_015, ...] │
13
  │ 词 "营收"  →  出现在 [chunk_001, chunk_008, ...] │
14
  │ 词 "Q2"    →  出现在 [chunk_001, chunk_022, ...] │
15
  │ ...                                              │
16
  └─────────────────────────────────────────────────┘

六、经典 RAG 的根本缺陷：上下文丢失#

到这里为止讲的是 2024 年之前所谓的”经典 RAG”。

这一方法在 2024 年遭遇了严重的挑战——Anthropic 在 9 月发布的博文 Introducing Contextual Retrieval 中明确指出了它的系统性缺陷：传统 RAG 在编码信息时移除了上下文，导致系统无法从知识库中检索到本应相关的信息。

Anthropic 给出的经典例子是这样的：某金融知识库中存在一个 chunk，原文是「公司的收入比上一季度增长了 3%」。当用户查询「ACME 公司在 2023 年第二季度的收入增长是多少？」时，这个 chunk 既不会被向量检索命中（embedding 里没有 ACME、2023、Q2 这些语义信号），也不会被 BM25 命中（关键词零重叠）。但从整篇文档角度看它显然就是答案——只是分块时切断了 chunk 与上下文的关联，让它失去了识别度。

这是经典 RAG 的系统性问题。任何长文档分块后都会出现大量”丢上下文”的 chunk——技术报告里写”该方法相比 baseline 提升了 5%“，但具体是哪个方法、哪个 baseline 在前文；财报里写”营业利润同比增长 12%“，但具体是哪家公司、哪个季度也在前文。分块切断了这些信息，孤立的 chunk 就失去了被检索到的能力。

七、三种应对方法：chunk 层、query 层、context 层#

针对这个问题，业界三家头部厂商给出了三种完全不同的应对方法。

Anthropic 的 chunk 层修复：Contextual Retrieval。在 embedding 之前，用 LLM 为每个 chunk 生成 50-100 tokens 的”上下文化前缀”，描述该 chunk 在全文中的位置与背景。原始 chunk「公司的收入比上一季度增长了 3%」会被改写为「本段来自 ACME 公司 2023 Q2 SEC 10-Q 文件的财务摘要部分；上一季度营收为 3.14 亿美元。公司的收入比上一季度增长了 3%」。上下文化后的 chunk 才进入 embedding 与 BM25 索引——这样 chunk 自带 ACME、2023、Q2 等关键词，向量也带上了这些语义信号。这一步要对每个 chunk 调一次 LLM 处理整篇文档加该 chunk，听起来昂贵，但通过 prompt caching（整篇文档只缓存一次，每个 chunk 只为变化部分付费），总成本可压到约 $1 / 百万文档 tokens。Anthropic 给出的实测数据是惊人的：Contextual Embeddings 单独使用让检索失败率降低 35%，叠加 Contextual BM25 降低 49%，再叠加 reranking 降低 67%。这是当前最具影响力的方案，已被业界广泛复现。注意：Claude 这里生成的”小型上下文”是一段普通文字，不是向量、不是 embedding，它只是给 chunk 补全了文字，后续才走标准的 embedding 流程。这是非常容易被混淆的一点。

Microsoft / Azure 的 query 层修复：Agentic Retrieval。不在 chunk 层做手脚，而是前置增强 query 的智能化——用 LLM 在查询前做 query rewriting、query decomposition、并行子查询。Azure AI Search 2025 年 5 月推出的 Agentic Retrieval 把这套做成了官方能力：LLM 分析复杂问题，分解为多个针对性子查询，跨知识源并行执行，再融合结果。复杂查询的相关性比经典 RAG 提升最高 40%。Copilot Studio 的 4 步流水线也是同样的哲学：用最近 10 轮对话上下文重写查询、从所有已配置知识源各取 Top 3、生成带引用的回答、内容审核。

Google 的 context 层跳过：超大窗口直接全文塞入。Gemini 2.5 Pro 支持 1M tokens 的原生 context，对于较小的知识库（百万 tokens 以内），Google 的建议是跳过 RAG，直接全文塞 context。这种做法完全无信息丢失、工程最简单，代价是受限于 context rot（前面讲过的”长 context 上模型悄悄变笨”）和容量上限。Anthropic 也认可这一方案：知识库小于 200K tokens 时可省略 RAG。

成熟的 RAG 系统往往三者并用。Azure AI Search 的 Agentic Retrieval 同时做 query decomposition 与 hybrid search；Claude Projects 在容量内时全文塞 context，超过时自动触发 RAG；企业级方案往往在 Anthropic 的 Contextual Retrieval 基础上叠加 query rewriting。

八、2026 年的标准 RAG 技术栈#

把前面讲的所有改进组合起来，2026 年企业级 RAG 的事实标准已经形成：Contextual Chunks + Hybrid Search（BM25 + Vector） + RRF 融合 + Cross-encoder Reranking + Agentic Query Decomposition。任何企业级 RAG 项目都应以此为起点而非从经典 RAG 起步。各环节单独失效率降幅可叠加：Contextual Retrieval 降 49%、Reranker 再降 18%、Agentic Retrieval 再降相关性 40%——综合下来比 2020 年的经典 RAG 强出数倍。

下表总结各方案的特征：

九、Agentic RAG：从一次性检索到工具化检索#

经典 RAG 是一次性的：“检索一次 → 拼装 prompt → 生成回答”。这在简单 Q&A 上有效，但在复杂任务上有明显局限：复杂问题需要多步检索（先查 A，根据 A 的结果再查 B）；检索结果可能自相矛盾需要澄清；单次检索的 chunk 可能缺失关键背景。

Agentic RAG 把检索本身视为 Agent 可调用的工具，由模型决定何时检索、检索什么、是否继续检索。代表实现是 Claude Code 的 Agentic Search——它不预先 embedding 代码库，而是让 Agent 用 grep / glob / read 等工具按需探索代码，每一步都是模型自主决策。GitHub Copilot Chat 走同样的思路：对 GitHub 仓库有远端 semantic code search index 兜底，但实际交互中大量依赖工具调用（grep、file search、find references、read），本质是 Agentic Search 而非经典 RAG。这是 2025-2026 年代码类 Agent 的核心转变。

OpenAI File Search、Anthropic Claude Projects、Microsoft 365 Copilot 也都在向 Agentic RAG 方向演进——检索从”一次性预处理步骤”转为”Agent 可重复调用的工具”。模型可以决定”我需要更多信息，再检索一次”，可以决定”这次检索结果不够用，换个角度再查”。

十、RAG 的真实成本结构#

把 RAG 的所有环节成本放到一起对比，得到一张非常重要的全景图。假设 100 万 tokens 的文档库，不同方案的成本对照：

三个核心观察。 第一，indexing 成本随方案不同差 50-500 倍，但绝对值都很小——花一次性的小钱换长期检索质量提升，工程上完全划算。 第二，运行时成本主要由 LLM 决定，跟用不用 contextual retrieval 关系不大。 第三，主 LLM 推理（约 $0.05/次）远高于 indexing 任何阶段。结论是优化 RAG 成本先看主 LLM 的输入 token 怎么省——Top-K 减小、chunk 缩短、用更便宜的生成模型——indexing 阶段那点钱不用纠结。

十一、终端产品中的 RAG 实现#

终端 LLM 产品在 RAG 上的策略差异非常大，分清楚有助于理解日常工具的真实行为。

Claude Projects 当 Project 的知识库逼近上下文窗口上限时自动切换到 RAG 模式，将容量扩展约 10 倍，无需用户配置。界面会显示 “Indexing” 提示告知当前模式。容量回落到 context 容量内时自动切回 in-context 模式。Anthropic API 层面则提供完整的 Contextual Retrieval 实现。

ChatGPT Projects 提供工作区语义的 RAG 体验——每个 Project 拥有独立的文件库、自定义指令、聊天历史。OpenAI File Search Tool 是其 API 层暴露：用户预先创建 vector store 并上传文件，OpenAI 自动完成解析、分块、embedding、索引，调用时模型决定是否检索、检索什么，返回结果包含 file citations 引用。OpenAI 的”上下文丢失”方案不做 chunk 层 contextual prefix，而是依赖语义化分块策略 + 混合检索 + 元数据 attribution。

Microsoft 365 Copilot 的 RAG 不依赖用户上传——它直接基于 Microsoft Graph + Semantic Index 检索企业现有数据（SharePoint、OneDrive、Outlook、Teams、日历、Planner、Loop、Viva、Graph Connectors 外部系统）。2026 年推出的 Work IQ 是组织智能层，超越了传统的文档式 RAG——它聚合带权限的工作信号而非原始文档（邮件模式、会议关系、文档协作模式、任务归属、非正式团队关系），构建持久化的工作记忆（个人沟通风格、重复工作流、常合作的同事、角色优先级）。Copilot Studio 在中间层提供四步 RAG 流水线（query rewriting、content retrieval、summarization、safety validation），底层是 Azure AI Search——它在 2025 年 5 月推出的 Agentic Retrieval 把”query 层修复”做成了产品能力。

Google Vertex AI 按抽象层级分三个产品：Vertex AI Search 完全托管，开箱即用语义+关键词混合搜索；Vertex AI RAG Engine 中等托管，提供 RAG 流水线编排；Vertex AI Vector Search 最底层向量数据库服务。Google 的 grounding 体系还包括 Grounding with Google Search——直接把 Gemini 回答 grounded 到实时搜索结果。

十二、PDF 上传与 Copilot 问代码库的真实行为#

把 RAG 知识应用到日常工具行为上，几个常见场景值得明确。

拖 PDF 进 chatbot 问问题的行为取决于文件大小。小 PDF（几十页内）会被全文塞 context，完全不走 RAG；大 PDF 自动触发 RAG，Claude.ai 切换时会显式显示 “Indexing”，ChatGPT 隐式切换不提示。判断当前模式的方法是问模型”统计全文 X 出现几次”——答得准说明全文塞入，答得近似说明走了 RAG。各家阈值不同：ChatGPT 大约 50-100 页内全文塞入，Claude 200 页内，Gemini 由于 1M context 几乎不需要触发 RAG。

VS Code 里 GitHub Copilot 问代码库用的是分层 fallback 机制。文件数 < 100 且 < 32K tokens 时全部塞 context；GitHub 仓库自动触发远端 semantic code search index（真正的经典 RAG，GitHub 服务端用专门的代码 embedding 模型预建索引，跨用户共享）；非 GitHub 本地仓库可选 local index 上限 2500 文件；Agent 模式组合 grep / file search / read 等工具按需检索，本质是 Agentic Search。

IntelliJ IDEA 里的 Copilot 是简化版——命令是 @project 而非 VS Code 的 @workspace，没有独立 embedding 索引，依赖 IDE 自身的 PSI 索引 + 文本搜索。对 md 文件的检索质量明显弱于 VS Code，实战中推荐用 #filename 或 #folder/ 显式指定上下文，绕过它薄弱的自动检索环节。这也是为什么主问答留在 VS Code、IntelliJ 只做 Java 开发是当前最务实的分工。

一、Knowledge 是什么#

提到 Agent 的 Knowledge，容易望文生义地以为它是某种被写进协议里的标准能力，像 OAuth 有规范文档、MCP 有 Anthropic 发布的协议规格。

事实并非如此——“Knowledge” 从来不是一个有正式规范的技术术语，它是各家产品和框架各自起的功能性名字：Claude 把它叫 project knowledge，OpenAI 把它叫 knowledge files / vector store，Gemini 把它叫 File Search，开源 Agent 框架（LangChain、LlamaIndex）则统一叫它 RAG（Retrieval-Augmented Generation）。没有任何组织出面定义”Knowledge 必须长什么样”，这也是它和 MCP 最大的不同——MCP 有协议文档规定”外部工具怎么被标准化调用”，Knowledge 没有对应的东西，各家实现可以完全不兼容，甚至同一家公司不同产品线的做法都不一样。

剥掉命名的外壳，Knowledge 的技术内核只有一句话：模型参数之外、运行时可检索的外部信息源。模型的”知识”在训练阶段就已经固化进权重，而 Knowledge 指的是训练之后、通过工程手段外挂进来的信息，本质就是 RAG 那一套。

Knowledge 与 Skill 是同一层面的两种东西：都是在运行时往上下文里注入内容，但注入的东西性质不同。Skill 注入的是”指令”——一份 SOP、一套操作步骤，教模型”怎么做”；Knowledge 注入的是”资料”——一段事实、一份文档，告诉模型”是什么”。

二、Knowledge 与上下文、与 Skill reference 的关系#

三、是否一开始加载 & upload 文件算什么#

四、聊天框 与 Project 中的 Knowledge#

普通聊天框（比如不开 Projects 的一次性对话）当然”有知识内容”——这次对话里拖进来的文件，模型完全读得到、答得出。但它没有”持久知识库”：这份文件只活在这一次的 context 里，会话一关、窗口一超，内容就彻底消失，不会被任何向量库记录，下次开新对话等于从未上传过。

只有 Project（Claude Projects、ChatGPT Projects、自定义 GPT 的 knowledge files、Gemini 的 Gems / File Search）才提供跨会话持久、可复用的 Knowledge Base——文件上传一次，之后每次在这个 Project 里开新对话，都可能被重新检索到。

所以准确的措辞不是”普通聊天框没有知识”，而是**“普通聊天框没有持久化、可挂载的知识库”**——它有的只是一次性的长 context，会话结束即焚。

五、Knowledge 如何与 LLM 关联 / LLM 怎么知道自己有知识#

呼应 Token 那篇的核心结论——自然语言在 LLM 内部不存在，模型只处理数字——这里同样成立：Knowledge 与 LLM 只有一条关联路径：知识内容变成 context 里的 token。不存在第二条路径能让 LLM 凭空”知道”自己有一个知识库，它不会读数据库的 schema，不会感知向量库里躺着多少份文件，它能看到的永远只是这一次 API 调用 messages 数组里已经拼好的文字。

这条唯一路径之上，衍生出两种截然不同的工作模式：

模式一：传统 RAG。检索这件事完全发生在 LLM 外部，由应用层的 orchestrator 代劳——先做检索，再把结果拼进 prompt，LLM 从头到尾是被动接收方，它不知道、也不需要知道这段文字是”从知识库查来的”还是”用户自己打的”，更谈不上任何声明。

模式二：Agentic RAG。知识库被包装成一个工具（比如 search_knowledge_base），连同其他工具一起，通过工具的 description 出现在这次调用的工具清单里。LLM 看到工具描述，自己判断”这个问题需不需要查知识库”，主动发起调用。这一模式下 LLM 是主动知道自己”有知识可查”的——它看到的是一份工具清单，跟看到 Skill 清单没有本质区别，这也是 Agentic RAG 与 Skill 高度趋同的原因。

六、外部检索器的例子#

一个具体例子：embedding 模型（OpenAI text-embedding、Voyage、Gemini embeddings 等）配合向量数据库（Azure AI Search、Pinecone、FAISS、Milvus 等）。

整个流程分离线、在线两段，离线阶段 LLM 完全不参与：

1. 切块：把文档切成几百 token 一段的小块（OpenAI 的 file_search 工具默认切成 800 token、重叠 400 token）。
2. 向量化：用 embedding 模型把每个块转成一个高维向量。
3. 入库建索引：向量连同原文写入向量数据库，建好可供近似搜索的索引。

运行阶段则是：

1. 用户提问，用同一个 embedding 模型把问题也转成向量；
2. 在向量数据库里计算相似度，取 top-k 个最相关的块（OpenAI file_search 默认取 20 个块，Anthropic 在 Contextual Retrieval 的实验里也发现取 20 个块效果最好——两家不约而同选中同一个数字）；
3. 把这几个块拼进 prompt；
4. 交给 LLM 生成最终回答。

核心结论是：检索器独立于 LLM 运行，只做”比较向量距离谁更近”的数学活，这一步是纯粹的线性代数与工程索引问题（常用 HNSW、IVF 等近似最近邻算法），跟”理解语言”没有任何关系，LLM 全程不参与这一步的计算。

七、检索结果在 prompt 里的具体呈现#

呼应 Context 那篇提到的四种标准 role（system / user / assistant / tool）——Knowledge 检索结果没有专属的 role，最终必须伪装成这四种里的一种才能进入 context。实践中常见三种做法：

做法 A：塞进 user 消息。最常见的传统 RAG 实现，把检索到的几段资料和用户原始问题拼在一起，包一层”以下是相关资料：……\n用户问题：……”，整个包装完的文本作为一条 user 消息发给模型。LLM 对此浑然不觉，它看到的只是一条比较长的 user 输入，无法分辨哪部分是用户写的、哪部分是检索器塞的。

做法 B：塞进 system 消息。把检索结果当成背景设定放进 system prompt，常见于企业客服类场景——把命中的产品手册片段写进 system，人设加资料一起定义这轮对话的背景。

做法 C：以 tool 返回，前面配一个 tool_calls。这是 Agentic RAG 的标准做法——模型主动发起一次 tool_use 调用（比如调用 search_knowledge_base），检索器执行后把结果包成 tool_result 传回去。这里可以直接借用 Context 那篇提到的一个细节：tool_result 的 role 其实是 user，因为 Anthropic 的设计逻辑是工具执行器站在用户侧，把结果”递给”模型。也就是说，即便是最像 Skill 的 Agentic RAG，检索结果最终进入 context 时，依然要套上四种标准 role 之一——通常又是套上了 user。

八、是否每轮都做向量比对#

默认是的，做法 A、B 这类无脑塞入的实现，每一轮提问都会重新触发一次完整的检索流程。但这不等于”每轮都要把整个知识库重新算一遍”，中间有几层工程上的修正：

知识库的向量早就预存好了，第六节的离线阶段只做一次，之后每一轮只需要重新计算”这句提问”的 embedding，知识库那一侧的向量是现成的，不会被重复计算。

检索靠索引近似搜索，不是逐一扫全库。向量数据库依赖 HNSW、IVF 这类近似最近邻算法，把毫秒级的响应时间和几乎线性的召回质量做了权衡，即便知识库有几十万条向量，一次查询通常也就是几毫秒到几十毫秒。

真正的成本大头不在向量比对本身，而在每轮注入 context 的那几段资料 token——这与 Context 那篇的结论一致：Agent 系统里 tool_result 才是消耗大户，检索命中的几个 chunk 一旦拼进 prompt，就是实打实的输入 token，要按次付费、占用窗口，向量数据库那边的计算开销相比之下可以忽略不计。

有两个常见的优化方向：一是加一道门控判断，先用一个轻量分类器判断这轮提问要不要检索，不需要就跳过，省下一次检索调用；二是改成 Agentic 检索，把检索包装成工具，让模型自己判断要不要调，用不上就不调。多轮对话场景下还有一个绕不开的问题：用户这一轮的原始提问经常是”那它呢""再详细说说”这类指代不明的短查询，直接拿去做向量检索效果很差（语义信息不完整），因此需要先做 query rewriting——用 LLM 把带着历史上下文的提问改写成一句独立、完整的检索查询，再送去做向量比对。

九、主流产品策略（ChatGPT / Claude / Gemini）#

三家的共同核心策略高度一致：知识库小就走 long-context 全量塞入，知识库大就切换到 RAG，分界线大致在20 万 token附近，正是第三节提到的 Anthropic 那条经验值，三家的产品设计大致都在这条线附近做取舍。

Claude：Projects 会在 project knowledge 接近 context window 上限时自动切换到 RAG 模式，官方说明这一步可将知识容量扩容至多 10 倍，且是双向可逆的——如果之后内容量又降回阈值以下，会自动切回 context 模式，全程不需要用户手动配置。在检索质量上，Anthropic 通过 Contextual Retrieval（Contextual Embeddings + Contextual BM25，再叠加 Cohere 重排序）把 top-20 chunk 检索失败率从 5.7% 降到 1.9%，相当于降低 67%。2026 年 3 月，Claude Opus 4.6 与 Sonnet 4.6 的 1M token 上下文窗口已按标准价格全量开放，进一步抬高了”直接塞 long context”这条路径能覆盖的场景。

OpenAI：策略更偏”按文件类型分流”——ChatGPT 对文本类文件（PDF、Word、PPT）走文本抽取 + 检索，对表格类文件（CSV、Excel）交给 Code Interpreter 用 Python 直接跑分析，对图片走 Vision 描述，三条路径互不相同；开发者侧的 file_search 工具默认按 800 token 切块、重叠 400 token、取 top-20 chunk 拼进 prompt。GPT-5.5 在 2026 年 4 月把 API 端上下文窗口做到了 100 万 token，是 OpenAI 第一个达到这一量级的模型。相比之下，普通 ChatGPT Projects 里”自动检索”这一层目前还不够成熟——开发者社区里能看到”把 Project 级检索能力搬到 ChatGPT 里”的功能请求帖，说明这块拼图眼下还在补齐中。

Gemini：押注的方向是超大窗口 + Context Caching——当前的 Gemini 3.1 Pro 输入上限为 1,048,576 token；Google 官方的 long-context 文档明确表达了这层立场：更小窗口的模型需要”滑动窗口丢弃旧消息、摘要压缩、RAG 检索”这类补救手段，而 Gemini 的超大窗口鼓励一种更直接的做法——把相关信息一次性全部放进去。与此同时，implicit context caching 在 Gemini 2.5 及之后的模型上默认自动生效（最低缓存门槛 2,048–4,096 token 不等），命中缓存部分的输入输出成本可降至标准价格的四分之一左右，完全不需要开发者写代码开启。File Search 这个托管 RAG 工具则更像一层面向开发者的 API 级基础设施——自动完成切块、向量化、建索引，2026 年新增了多模态检索能力，但定位始终不是面向普通用户、开箱即用的 Project 知识库产品。

三家共同的演化方向也很清楚：检索正在从”被动拼接”走向”模型主动调用的工具”——Claude 的 project knowledge search tool、OpenAI 的 file_search、Gemini 的 File Search tool，本质上都是把第五节的”模式二：Agentic RAG”做成了标准配置，这条路线也是三家都在收敛的共同答案。

十、由该机制衍生的常见现象#

2. Skill 的起源<谁提出的>,为了解决什么#

Agent Skills 这一概念由 Anthropic 在 2025 年 10 月正式提出,并很快演变成一个跨平台的开放格式——微软 Copilot Studio、GitHub Copilot、Cursor、Gemini CLI 等生态随后都采用或兼容了这套思路。

它要解决的,是纯 prompt 工程在规模化时的三个结构性痛点:

简单来说:Skill 是把 prompt 工程”产品化”了——加上了持久化、按需加载、自动路由,以及(关键的)可选的代码执行能力。

3. Skill 到底是什么<定义与形式>#

从底层来讲,一个 Skill 就是磁盘上的一个文件夹。文件夹里必须有一个 SKILL.md 文件,可选地附带脚本、参考文档、模板等资源。

一个完整 Skill 在磁盘上长这样:

1
pdf-skill/                    ← 整个 Skill 就是一个文件夹
2
├── SKILL.md                  ← 核心:元数据(标题)+ 正文(指令)
3
├── scripts/                  ← 可执行脚本
4
│   ├── fill_form.py
5
│   └── merge_pdf.py
6
├── references/               ← 参考文档
7
│   └── pdf_spec_notes.md
8
└── assets/                   ← 模板 / 静态素材
9
    └── letterhead_template.pdf

SKILL.md 本身内部又分两部分:

1
---
2
name: pdf-form-filler
3
description: 当用户需要填写或处理 PDF 表单时使用     ← 元数据(标题)
4
---
5
# 填写 PDF 表单                                      ← 正文(指令)1. 读取用户提供的字段数据
6
2. 调用 scripts/fill_form.py 完成填充
7
3. 细节规格见 references/pdf_spec_notes.md
8
...

它把”某一类任务该怎么做”的流程性知识固化下来,让一个通用模型在需要时表现得像某个领域的专家。

4. 三层结构<渐进式披露>(Progressive Disclosure)#

Skill 最核心的设计,是把内容分成三层,按需逐层加载。这套机制叫渐进式披露,目的只有一个:省上下文窗口。

用一个类比贯穿理解:

• L1 元数据 = 一本书的书名 / 目录里的一行标题——“第 7 章<如何填> PDF 表单”。
• L2 正文 = 第 7 章的完整内容。平时不翻,真要做这件事时才翻到那一页读进来。
• L3 资源 = 附录里的计算器和详细规格表。你用计算器算,但不需要把它的电路图背下来。

正因如此,有 50 个 Skill,平时只占 50 行简短描述的成本(几百 token),而不是 50 套完整指令。模型在有限窗口里能”认识”上百种能力,却不必时刻背着它们的全文。

1
flowchart TD
2
    A[会话启动] --> B[L1: 50 行 description 常驻 system]
3
    B --> C{用户提出需求}
4
    C -->|匹配到某 Skill| D[L2: 该 Skill 正文动态注入]
5
    D --> E{正文里引用了资源?}
6
    E -->|要执行脚本| F[L3 scripts: 窗口外运行, 只回填结果]
7
    E -->|要查参考| G[L3 references: 按需读取部分进窗口]
8
    E -->|不需要| H[直接完成任务]

5. 例子<生成规范> Excel#

用同一个任务对比”纯 prompt”和”Skill”,能立刻看清差别。任务是:把一批数据做成一张格式规范的 Excel 表。

方案 A — 纯 Prompt(每次手敲):

1
请帮我生成 Excel。要求:
2
- 表头加粗、底色深蓝、白字
3
- 冻结首行,数字列右对齐保留 2 位小数
4
- 金额列用千分位,列宽自适应
5
- 用 openpyxl 输出到 output.xlsx
6
数据如下:...

下次再做同类任务,这段又得从头贴一遍。

方案 B — Skill(建一次,长期复用):

1
xlsx-skill/
2
├── SKILL.md          # name + description + 上面那套格式规范
3
└── scripts/
4
    └── format_table.py   # 真正干活的代码

之后你只需说”把这批数据做成 Excel”,模型读到 L1 描述判断匹配,把 L2 正文拉进来,再调用 format_table.py 完成——那段格式规范再也不用手敲。

6. Skill vs Prompt<本质相同>,定位不同#

两者本质上都是”外部输入”<都不改变模型权重>,都以 token 进入上下文,由同一次推理处理。 从这个意义上说,它们和微调(fine-tuning)、RLHF 这种真正改动参数的手段有本质区别——后者才”触及根本”。

但在”外部提示”这个大类里,两者定位差别很清楚:

关键区别不在”是否触及模型”,而在”复用性 + 加载机制 + 谁来触发 + 能否外挂执行”。 Skill 可以粗略理解成”被规范化、模块化、按需加载的 prompt 仓库”,外加一层纯 prompt 做不到的可执行能力。

7. Skill 是不是 system prompt?#

既然skill是以prompt的形式出现在上下文，那么它的role是什么，是system prompt吗？

答案是:不完全等于,但有交集,而且必须精确措辞。

先厘清 “system prompt” 到底指什么。在一次推理里,送进上下文窗口的文本按**角色(role)**分层:

所谓 system prompt,就是 System 角色那一段,而它的定义里隐含了”静态常驻”。

Skill 的两层内容,落点不同:

• L1 元数据(那行描述) → 确实被塞进 System 区并常驻,让模型一直知道有哪些技能可选。这部分算 system prompt 的一部分。
• L2 正文 → 触发后动态注入。它以 System 级的权威进入,但它是”会进出的”,不是一开始就钉在那儿的固定 prompt。

所以严谨的表述是:

L2 正文是”动态注入的 system 级指令片段”,而不是”一段动态的 system prompt”。

而且要记住:Skill ≠ 只有正文。它还有 L3 那层——那是窗口外的可执行代码,根本不是 prompt。所以”本质上是一种 prompt”这句话只覆盖了 L1 + L2。

8. 动态注入 vs 静态注入<区别到底在哪>#

这是理解 Skill 机制的核心:

对模型的单次前向推理来说,“一开始注入”和”运行时注入”没有任何区别。 模型只看它这一刻窗口里有什么 token,token 不带时间戳,模型无从分辨哪段是开机就有、哪段是刚才才塞的。

那区别在哪?在整场多轮对话里,这段文本存在多久、占用多少、由谁决定。

一个推演最能说明问题。假设有 50 个 Skill、对话进行 10 轮:

• 若全部静态注入<每一轮窗口都背着> 50 套完整正文(比如 5 万 token),被重复喂 10 次,而大部分这次根本用不上——纯浪费,上下文窗口很快撑满。
• 若动态注入<任何一轮窗口里只有>”50 行索引 + 当前用得上的那 1 套正文”,省下 90%+ 的空间。

动态注入最大的价值是”可逆、可调度”:

系统能用有限窗口支撑海量能力——模型平时只背一份薄目录,真要用哪一章,编排器现场翻开塞给它,用完合上。

9. L3 资源<不进窗口>,怎么执行?#

这里要破除第二个误区:“进上下文”和”被执行”是两条完全独立的路径。 上下文窗口是给模型”读”的;执行是在模型之外的机器上”跑”的。

模型本身不运行任何代码。 LLM 是个文本预测器,只会输出 token。真正干活的是它旁边的运行环境(runtime / sandbox / 工具执行器)。流程是:

1
① 模型在 L2 正文里读到:"调用 scripts/format_table.py 处理数据"
2
② 模型据此输出一个动作指令 token:
3
   { "tool": "bash", "command": "python scripts/format_table.py data.csv" }
4
③ 外部执行器收到 → 在沙箱里真正运行那个 .py 文件
5
④ 脚本跑完,把【结果】(成功/报错/输出值)作为文本回填进上下文窗口
6
⑤ 模型读到结果,继续下一步

所以进出上下文的到底是什么,要分清:

10. role 的定义权与生效层级#

一个更底层的问题<注入进上下文的那段东西>,role 到底是谁定的、在哪一层生效?这要拆成两个不同的问题。

1
<|system|> 你要遵守...  <|end|>
2
<|user|>   帮我做...    <|end|>
3
<|assistant|> ...

11. L3 的 reference 如何参与上下文#

L3 内部还要再分”读”和”跑”两种命运——第 9 节讲的是”跑”(脚本),这里讲”读”(参考资料)。

核心区别 通常不是被系统被动”直接加载”,而是模型主动去”读”的。

具体流程——它走的是和 L3 脚本执行一模一样的工具调用管线,只不过脚本是”跑”、reference 是”读”:

1
① 模型读到 L2 正文:"详细规格见 references/spec.md"
2
② 模型判断:这次任务需要这个细节
3
③ 模型输出动作 → { "tool": "read_file", "path": "references/spec.md" }
4
④ 外部执行器读取该文件 → 把内容(或指定的某几段)作为【结果】回填
5
⑤ 这段文本进入上下文,role 通常是 tool,模型接着用

所以 reference 回填进上下文时,最典型的 role 是 tool(工具返回结果)——因为它复用了现成的文件读取管线,和 L3 脚本共用一套机制。同样,这也是实现相关的<少数实现会直接把内容拼进> system 上下文,role 就成了 system。

reference 常常不是全量加载。它的价值恰恰在于可以只读需要的片段——带 offset 的部分读取,或先读目录 / 摘要再决定深入哪段。这就是**“更深一层的渐进式披露”** → L2 渐进过一次,reference 内部还能再渐进一次,尽量少占窗口。

12. 核心结论#

1. Skill 从头到尾没有触及 LLM 本身。 它不改权重、不改推理,最终只是以 token 进入上下文窗口,和普通 prompt 走同一条路。它与微调 / RLHF 有本质区别。

2. Skill 由 Anthropic 于 2025 年 10 月提出,现已成为跨平台开放格式。 它把 prompt 工程”产品化”,解决了纯 prompt 的三大痛点<不可复用>、占满上下文、要人手动触发。

3. 一个 Skill 就是一个文件夹,核心是 SKILL.md,内容分三层 元数据(常驻的”书名”)、L2 正文(动态注入的”章节内容”)、L3 资源(窗口外的脚本 / 参考 / 素材)。

4. 渐进式披露是它的灵魂。 平时只暴露 L1 的简短描述,匹配到任务才注入 L2;省的是上下文窗口这一稀缺资源的调度效率,而非模型的理解力。

5. “动态注入”与”静态注入”对模型单次推理无区别(token 不带时间戳),区别在多轮对话中”存在多久、占多少、谁调度”——静态是纹身,动态是便利贴。

6. L1 + L2 本质是”动态加载的 system 级提示”;L3 不是提示,是窗口外的可执行资源。 L3 内部又分两种命运<脚本>”给机器跑”(bash 或 MCP,不进窗口,只回填结果),参考资料”给模型读”(按需读片段进窗口,role 通常是 tool)。

7. role 的词汇表由 API 定义,role 的权力由训练在模型端刻死。 Skill 正文以 system 级权威进入上下文永远成立,但其字面 role(system / tool / developer)取决于具体产品实现,唯一确定的是它绝不是 user。

Skill 不是一样神秘的新东西,而是一套围绕上下文窗口做加载调度的机制——用一个静态常驻的”书名”(L1)在 system 里挂号,用到时把”正文”(L2)以 system 级权威动态注入,必要时再指挥窗口外的脚本(L3)去干活。读的归读,跑的归跑,谁都不挤占本就稀缺的上下文窗口。

二、Token 的本质#

Token 是一种介于字母和单词之间的子词（subword）单位。一个具体 token 的形态，完全取决于该字符序列在训练语料中出现的频率。OpenAI 给出的经验值是英文场景下 1 token ≈ 4 个字符 ≈ ¾ 个英文单词，但该数值会因内容性质显著波动：纯英文常用词每个仅占 1 个 token，中文一个字往往占 1–2 个 token，乱码或罕见专有名词可能每个字符都要单独占用一个 token。

下表列出若干真实示例（可在 platform.openai.com/tokenizer 上验证）：

高频整词被合并成 1 个 token，中频词被拆为多个高频子词，罕见词或乱码退化为按单字节切分。这是 BPE 算法的核心特征。

三、BPE 训练过程#

BPE 全称为 Byte-Pair Encoding（字节对编码），OpenAI、Anthropic、Meta Llama、Google Gemini 系列底层均使用该算法或其变体。训练过程可通过一段迷你语料逐步演示。

设训练语料仅包含四个词：

1
low low low low low       (5 次)
2

3
lower lower               (2 次)
4

5
newest newest newest      (3 次)
6

7
widest widest widest      (3 次)

第一步，所有词拆为单字符，词尾添加特殊符号 </w> 标记词边界：

1
"l o w </w>"        × 5
2

3
"l o w e r </w>"    × 2
4

5
"n e w e s t </w>"  × 3
6

7
"w i d e s t </w>"  × 3

此时词表包含 11 个 token：{l, o, w, e, r, n, s, t, i, d, </w>}。

第二步，扫描整个语料，统计”相邻字符对”的出现次数。例如 l + o 在 “low” 与 “lower” 中累计 5 + 2 = 7 次；o + w 同样为 7 次；e + s 在 “newest” 与 “widest” 中累计 6 次。l + o 与 o + w 并列最高频，任选其一（如 l + o）合并为新 token lo 加入词表，并记录合并规则：l + o → lo。

第三步，重复扫描与合并。下一轮 lo + w 成为最高频对，合并为 low；再下一轮 e + s 最高频，合并为 es；再下一轮 es + t 合并为 est；继而 est + </w> 合并为 est</w>。整个过程持续进行，每轮合并当前最高频的字符对，直至词表达到预设大小。

OpenAI 训练 GPT-4o 时，合并至词表约 20 万 token 停止（对应的编码方案命名为 o200k_base）。训练完成后，产物仅有两个文件：

1. vocab.json：{token 文本 → token ID} 的映射表。

2. merges.txt：数万至数十万条”x + y → xy”形式的合并规则，严格按照训练时的合并顺序排列。

这两个文件合计通常仅几 MB，构成了 tiktoken 库的全部核心数据。训练完成后，两个文件永久固定，不再变更。

四、BPE 编码过程#

编码阶段以一个训练语料中未出现过的新词 "lowest" 为例：

1
Step 1: 拆为单字符          "l o w e s t </w>"
2

3
Step 2: 按 merges.txt 顺序遍历规则，能合并则合并
4

5
        规则 #1  l + o → lo            →  "lo w e s t </w>"
6

7
        规则 #2  lo + w → low          →  "low e s t </w>"
8

9
        规则 #3  e + s → es            →  "low es t </w>"
10

11
        规则 #4  es + t → est          →  "low est </w>"
12

13
        规则 #5  est + </w> → est</w>  →  "low est</w>"
14

15
Step 3: 无更多可用规则，终止
16

17
最终结果: ["low", "est</w>"]  →  token ID 例如 [10516, 478]

关键事实：训练语料中并未包含 “lowest” 一词，但分词器依靠已学到的 “low” 与 “est” 两个高频子词，仍能合理切分。这是 BPE 的核心价值——以有限的子词表覆盖近乎无限的词汇组合。

由此也可解释 Token ID 与频率的对应关系：BPE 训练按频率从高到低依次分配 ID，因此 ID 本身即反映频率高低：

Token ID 本质上是一张按频率排序的索引表：ID 越小代表 token 越高频、越常见；ID 越大代表越罕见、越”碎”。这也解释了为何 "the the the" 切出的 ID 都很小，而 "xqzpfk" 这类乱码切出的 ID 都在数万以上。

五、不同厂商的分词器差异#

虽然算法本质均为 BPE，但各厂商在实现细节、词表大小、预处理方式上存在差异。这直接决定了能否在本地精确计算 token 数，以及相同文本在不同模型间的成本差异。

OpenAI 的透明度最高，通过 pip install tiktoken 即可在本地精确计算任意字符串的 token 数与 token ID。Anthropic 透明度最低，分词器从未公开，社区曾通过监听 streaming 流量逆向 token 边界。Google 的 SentencePiece 存在一个独特设计：将空格视为普通字符，以 ▁（U+2581）替代，因此 "This is a test" 在 SentencePiece 中先转为 "▁This▁is▁a▁test" 再行切分。该设计的工程意义在于完全语言无关——中文、日文、泰文等无空格语言不再需要特殊处理，与英文采用统一流程。这也是 Gemini 在多语言场景表现优于早期 GPT 的原因之一。

六、LLM 实际处理的对象#

回到核心问题：LLM 处理的是文字还是数字？

全流程均为数字，更准确地说是高维空间中的向量。 LLM 本质是一个超大规模的数学函数，输入与输出均为数字。模型不识别 “hello”、“你好” 等字符串——这些字符序列对模型内部计算而言不具备任何含义。

完整的”文字 → 数字 → 文字”流程如下：

Part 1：输入 → 模型内部

Part 2：模型推理 → 输出

其中一个关键中间步骤是 Embedding（嵌入层）。仅有 token ID 不足以支撑模型计算——整数 13225 与 13224 之间不存在任何语义关系，无法直接参与运算。因此模型内部维护一张大规模的 Embedding 矩阵，将每个 token ID 映射为一个高维向量（GPT-3 为 12288 维，Llama 3 为 4096 维）。该矩阵通过训练得到——训练过程中模型自主学习”语义接近的 token，向量也应当接近”的特性。训练完成后，"king" 与 "queen" 的向量距离较小，"happy" 与 "joyful" 的向量距离较小，著名的等式 king − man + woman ≈ queen 在该向量空间中近似成立。

模型的全部”推理”过程发生在向量空间内。模型接收一串向量，经过多层矩阵乘法与非线性变换，最终输出一个长度等于词表大小的概率分布，表示”下一个 token 在词表中每一个候选位置的概率”。采样器从该分布中选出一个 token，追加至输入末尾，再次输入模型预测下一个 token——如此循环，直至模型输出表示终止的特殊 token <end_of_text>。该机制称为 autoregressive generation（自回归生成），是所有 GPT 类模型的统一生成原理。

七、由该机制衍生的常见现象#

理解”LLM 仅处理数字、不处理字符”这一前提后，许多常见现象可获得统一解释。

八、核心结论#

1. 自然语言在 LLM 内部不存在。 模型内部仅有 token ID，且 token ID 会被立即转换为向量。

2. Tokenizer 是人类世界与模型世界之间唯一的接口。 理解 Tokenizer 即理解 LLM 工程问题的一半。

3. token ID 本质上是按频率排序的索引表。 ID 越小越高频，ID 越大越罕见。

4. BPE 的核心思想：以有限子词表覆盖无限词汇组合。

5. LLM 不读字符，它执行数学运算。

二、Context 的内部构成#

Context 在工程上是一个结构化的 messages 数组，由四种 role 与多种 content block 组成。四种 role 分别承担不同职责：system 定义全局规则、人设、输出约束，user 是人类输入，assistant 是模型回复，tool 是工具调用的执行结果。API 强制约束第一条 message 必须是 user，user 与 assistant 必须严格交替，tool 消息必须紧跟一个发起调用的 assistant。Anthropic 官方明确说明 system 在训练时被赋予更高优先级——即使用户在对话中说”忽略前面的指令”，system 中写的约束通常依然被遵守，这是 system 这个 role 存在的根本意义。

一条 message 内部还可继续拆分为多种 content block：普通 text 块、image 块（仅 user 可用）、tool_use 块（assistant 决定调用工具）、tool_result 块（工具返回值）、thinking 块（reasoning 模型的内部推理）、document 块(PDF 等结构化文档)。一个反直觉的细节是：tool_result 的 role 是 user 而非 tool，因为 Anthropic 的设计逻辑是工具执行器站在用户侧，把执行结果”递给”模型，所以包装成 user 消息注入。

各部分的 token 占比直接决定 Agent 的成本结构与可用容量。下表列出实战中典型的 token 占用情况：

Agent 系统中，tool_result 才是 context 真正的消耗大头。一次代码库搜索可能返回 10KB 文本，一次数据库查询可能返回 50KB JSON，这些数据原样塞回 context，几轮工具调用下来 context 就满了。所有 context 压缩策略，第一刀都砍向 tool_result。

三、API 的无状态性#

Anthropic 官方文档原文：“The Messages API is stateless, which means that you always send the full conversational history to the API.”

无状态是计算机科学的术语，意思是服务端不保存任何会话信息，每次请求必须自带所有需要的内容。这对 Agent 工程产生了根本性影响：模型本身从不记忆任何东西，所谓的”会话连续性”完全是应用层把历史回传给 API 的工程结果。

多轮对话的实际机制是这样的：第一轮用户说”我叫 Michael”，应用发给 API；第二轮用户问”我叫什么名字”，应用必须把第一轮的内容一起回传，模型才能”记得”。若应用只发当前问题不回传历史，模型会真实地回答”我不知道”——它从未”记住”过任何东西。这一机制带来的工程后果是：所有看起来像”记忆”的能力（ChatGPT memory、Claude Projects、Copilot personalization）本质上都是应用层在每次请求时把相关信息拼接到 context 里。

四、Context 的累积机制#

由于 API 无状态，多轮对话的 context 必然单调递增。Anthropic 官方文档将此过程总结为三条规律：progressive token accumulation（渐进累积）——每轮的 user 与 assistant 消息被永久保留；linear growth pattern（线性增长）——context 占用随轮次线性上涨；capacity ceiling（容量天花板）——所有累积内容加上即将输出的内容，总和不得超过模型最大 context。

在 Agent 场景下，问题更严峻。普通 chatbot 每轮可能增加 1–2K tokens，Agent 每轮可能伴随多次工具调用——一次搜索返回 5KB JSON，一次文件读取返回 12KB 文本，一次 API 查询返回 8KB 数据——单轮 context 增量可达 20K 以上。Claude Code 官方文档明确指出：在用户输入第一条消息之前，context 中已被系统提示、CLAUDE.md、所有 MCP 工具定义、Skill 描述、路径作用域规则等内容占满，一个复杂任务可能开局就消耗几万 token。这是 Agent 比 chatbot 烧 context 烧得快得多的根本原因，也是 context 工程在 Agent 系统中被推到第一优先级的原因。

五、Context 是输入与输出共享的同一池子#

一个被大量误解的工程事实：context window 是输入与输出共享的同一额度，不是只算输入。若模型 context 上限为 200K，输入塞入 199K，留给输出的仅剩 1K。许多 API 调用中模型回答突然戛然而止、max_tokens 设大也写不完的根源就在这里。

主流模型当前的 context 容量参考：GPT-5.4 在 API 中标称 1.05M tokens（max output 128K），Claude Sonnet 4.6 支持原生 1M tokens，Gemini 2.5 Pro 同样支持 1M tokens 量级。需要注意 max output 通常远小于 context 上限——模型可以”看到”百万 token，但一次性”输出”不超过十几万 token。这是工程决策中容易踩坑的细节。

六、Context Rot：长上下文性能退化#

业内一度认为 context window 越大越好，但 2025 年 7 月 Chroma 团队发布的《Context Rot》技术报告系统性推翻了这一假设。该研究测试了 GPT-4.1、Claude 4、Gemini 2.5、Qwen3 等 18 个前沿模型，结论极为明确：模型并不会均匀地使用 context；随着输入长度增加，模型表现愈发不可靠。Anthropic 官方文档已正式采用 context rot 这一术语，并在 context windows 页面警告：“随着 token 数量增加，准确率与召回率会衰减——所以精心策划放什么进 context，和能放多少一样重要。”

Context rot 必须与 context 溢出严格区分。溢出是二元失败——超过 token 上限时请求被截断或拒绝，会报错；context rot 是连续退化——在远未达到上限时输出质量已经悄悄下降，不报错也不提示。一个 200K context 的模型，可能在 50K tokens 时就已出现明显性能下降。Chroma 研究的核心贡献是揭示：衡量上下文质量的正确指标不是容量，而是信噪比（signal-to-noise ratio）。

Context rot 的成因可从三个层面理解。架构层面：Transformer 的 self-attention 要求每个 token 与所有其他 token 建立 n² 关系，序列越长注意力越被稀释。训练分布层面：训练语料绝大多数是中短文本，长距离依赖在训练分布中被低估，模型对长上下文的推理能力本身就训练不足。应用层面：Agent 在搜索、探索、回溯过程中持续累积噪声 token，这些噪声直接降低后续每一步的输出质量。

七、大窗口模型是否一定更好#

由 context rot 引出的精确判断：窗口大小决定”能不能做”，模型代际决定”做得好不好”。

在两者都能装得下的区间（例如同为 50K 输入的小数据量场景），大窗口模型并不天然更好——其表现主要由模型本身的能力决定，不由窗口上限决定。许多场景下感受到的”大窗口模型表现更好”，真正起作用的是”大窗口模型通常是更新一代、训练更充分”，而非”窗口大”这个属性本身。但一旦数据量逼近或超过小窗口上限，大窗口模型就拥有绝对优势——因为小窗口模型已经直接出局。

此外，大窗口模型在工程上还有两个隐性价值。第一是 buffer 余量：Agent 的 context 用量不可预测，大窗口允许 compaction 触发更晚，对应更少的额外 LLM 调用与更少的信息损失。第二是新一代模型的 long-context 训练本身更充分：Gemini 2.5、Claude Sonnet 4.6 在 1M context 上的表现已显著优于上一代模型在 200K 上的表现，context rot 在变弱，只是变弱的速度跟不上容量增长的速度。

八、Context Engineering：新一代工程范式#

Anthropic 在 2025 年 9 月 29 日发布博文 Effective Context Engineering for AI Agents，正式将 context engineering 定义为 prompt engineering 的自然演进。两者的本质差异在于关注对象与时间维度：Prompt engineering 关注 system prompt 的写法——一次性的、离散的、静态的写作任务；Context engineering 关注每次推理时往 context 里放什么——持续的、动态的、跨轮次的策划过程。在多轮 Agent 场景中，每一个 inference loop 都会产生新数据，这些数据是否应进入下一轮 context、以何种形式压缩、何时丢弃，构成了 context engineering 的核心工程问题。

Anthropic 给出的核心原则可归纳为五条：第一，将 context 视作稀缺资源进行预算管理——由于 context rot 的存在，无脑塞入更多内容只会降低质量，每个进入 context 的 token 都应有明确价值；第二，system prompt 应在”明确”与”灵活”之间取得平衡——过度工程化的硬规则脆弱易碎，过于模糊的指导无法引导行为；第三，工具定义是 Agent 与环境的契约——工具集应小而精，每个工具的输入输出、副作用、错误模式应清晰可预测；第四，长会话必须有压缩机制；第五，subagent 模式隔离上下文污染。

九、Context 管理的六类工程手段#

实践中存在六类主流的 context 管理手段，分别对应不同层次的工程问题。各方案的信息损失、实现复杂度、适用场景差异显著：

截断是最朴素的方案，超过阈值丢掉最早几轮对话，实现成本零但早期重要信息直接丢失。摘要（Compaction） 是 Claude Code 的 /compact 命令的核心机制——让另一个 LLM 调用把早期对话总结成结构化摘要，保留任务目标、关键决策、文件状态，丢弃探索过程、被否决的方案、详细 tool_result。摘要由 LLM 生成本身消耗 tokens，且不可逆——一旦压缩被丢的细节就回不来了，但这是当前长会话 Agent 的主流方案。Tool Result Clearing 是专门针对 tool_result 吞噬者的优化——清除中间探路失败的 tool_result 内容但保留对应的 tool_use 调用记录（否则 API 会因不匹配而报错）。Subagent 隔离 是结构性方案：把大量文件读取、搜索操作放入独立 subagent 的 context 中执行，主对话只接收 subagent 返回的摘要，主 context 始终保持干净。RAG 处理跨会话长期记忆，将历史会话/文档存在向量库中，每次请求时只检索与当前问题相关的几段注入 context。

Code Execution with MCP 是 Anthropic 2025-11 提出的最新方案，应对”工具爆炸”问题——当 Agent 接入大量 MCP 工具时，工具定义本身就能塞满 context，解决方案是让 Agent 生成代码调用工具而非直接调用，代码在沙箱执行，仅最终结果回 context。

成熟的 Agent 系统通常组合使用多种方案。Claude Code 同时用了 system prompt 优化、subagent、tool result clearing、/compact 摘要四种机制。

十、Prompt Caching：成本优化的关键机制#

Anthropic 的 prompt caching 是 context 工程中无法跳过的成本优化手段。其机制是将稳定的前缀（system prompt、工具定义、长背景资料）缓存在服务端，5 分钟内的后续请求只为变化部分付费。命中缓存的 token 价格降至正常输入的 10%，首次写入价格为 125%。对于多轮会话或固定模板场景，节省比例可达 80–92%。

缓存遵循严格的前缀层级：tools → system → messages，任一层级变更会使该层及之后的所有缓存失效。具体规则：修改工具定义会使整张缓存失效；修改 system 会使 system + messages 缓存失效；修改 tool_choice 仅使 messages 缓存失效。模型对缓存有最小 token 门槛——Claude Sonnet/Haiku 系列要求 ≥1024 tokens，Opus 系列要求 ≥4096 tokens，低于门槛的内容不被缓存。这一机制在工程上的直接影响是：工具集应结构稳定、版本受控，频繁修改工具定义会导致 caching 优化完全失效。

十一、Context 与 Memory 的关系#

容易混淆的一对概念是 context 与 memory。Context 指单次推理请求中模型实际看到的全部 token 序列，是模型的工作记忆，调用结束随请求消失。Memory 指跨会话保留的信息，由应用层实现，通常落地在数据库、向量库、知识图谱中。模型本身没有 memory，所谓”模型记得用户偏好”本质上是应用层在每次请求时将相关 memory 提取并注入到 context 中。

二者的关系可类比为：Memory 是磁盘，Context 是 RAM。每次请求时，应用层从 memory 中取出与当前任务相关的片段，连同 system prompt、对话历史、工具定义一起组装成 context 交给模型；模型完成推理后，应用层决定是否将本轮的新信息回写到 memory。

十二、由该机制衍生的常见现象#

理解 context 是模型的”工作记忆”、API 无状态、context window 输入输出共享、context rot 存在等核心事实后，许多平时让人困惑的现象可获得统一解释。

一、什么是 Agent#

在开始之前，可以先看一下官方的定义。

二、为什么叫 Agent#

英文 “agent” 来源于词根 agency，意为”代理权、代为行动的能力”。在法律、商业语境里，agent 指被授权代他人办事的人（房产 agent、保险 agent）。把这个词用在 AI 系统上，强调的不是它”多聪明”，而是它拥有代理权——可以代用户去思考、查询、调用工具、产出结果。这一点是它和传统软件、传统 LLM 应用最根本的区别。

判定一个系统是不是 Agent，有一条非常实用的标准：下一步动作是写死在代码里的，就不是 Agent；下一步是 LLM 实时决定的，才是 Agent。

三、Agent 与几个相邻概念的边界#

四、Agent 的内部结构#

1
Thought: 用户想查自己的 manager，需要先知道用户身份
2

3
Action: lookup_current_user()
4

5
Observation: Michael Zhao, employee_id=12345
6

7

8

9
Thought: 有了 employee_id，可以查 manager
10

11
Action: get_manager(12345)
12

13
Observation: Akira Yamamoto
14

15

16

17
Thought: 信息够了，可以回答
18

19
Answer: 你的 manager 是 Akira Yamamoto。

五、要不要写代码#

这取决于站在哪一层。造 Agent 内核：要写代码，但其实非常薄。用低代码平台搭业务 Agent：可以几乎不写代码，例如 Microsoft Copilot Studio 通过拖拽配置就能搭出一个能跑的 Agent。给 Agent 提供工具能力（例如写一个 MCP Server 把企业 API 暴露出去）：必然要写代码，这是后端工程师的活。

一个 Agent 项目往往三层都涉及——前端 Agent 用低代码配置，工具层用代码实现 MCP Server，更底层的业务 API 用传统后端框架（Spring Boot、Express、FastAPI 等）实现。

六、微软 Agent 生态#

微软的 Agent 栈里有三个关键名字：Copilot Studio（低代码 Agent 平台，前身 Power Virtual Agents，面向业务用户）、Microsoft Agent Framework / MAF（2025 年 10 月发布预览版的代码优先 SDK，由 Semantic Kernel 和 AutoGen 合并而来，面向 AI 工程师，原生支持 MCP、A2A、OpenAPI）、Work IQ（2025 年 Ignite 命名的”工作智能层”，给上层 Agent 提供数据、上下文、工具能力）。这三者构成”底座 + 两种搭建方式”的结构，详细内容另开笔记。

1. 安装 Xray#

1
bash -c "$(curl -L https://github.com/XTLS/Xray-install/raw/main/install-release.sh)" @ install

2. 配置 Xray#

1
vim /usr/local/etc/xray/config.json

自行修改配置

1
{
2
  "log": {
3
    "loglevel": "warning"
4
  },
5
  "inbounds": [
6
    {
7
      "listen": "0.0.0.0",
8
      "port": 30000,
9
      "protocol": "shadowsocks",
10
      "settings": {
11
        "method": "none",
12
        "password": "password"
13
      },
14
      "tag": "ria-socks-in"
15
    },
16
    {
17
      "listen": "0.0.0.0",
18
      "port": 20000,
19
      "protocol": "shadowsocks",
20
      "settings": {
21
        "method": "none",
22
        "password": "password"
23
      },
24
      "tag": "tpc-socks-in"
25
    }
26
  ],
27
  "outbounds": [
28
    {
29
      "protocol": "freedom",
30
      "settings": {},
31
      "proxySettings": {
32
        "tag": "freedomout"
33
      }
34
    },
35
    {
36
       "protocol": "socks",
37
       "settings": {
38
         "servers": [
39
           {
40
             "address": "127.0.0.1",
41
             "port": 40000
42
           }
43
         ]
44
       },
45
       "tag": "warp-proxy"
46
    },
47
    {
48
      "protocol": "blackhole",
49
      "settings": {},
50
      "tag": "blocked"
51
    }
52
  ],
53
  "routing": {
54
    "rules": [
55
      {
56
        "type": "field",
57
        "inboundTag": ["tpc-socks-in"],
58
        "outboundTag": "warp-proxy"
59
      },
60
      {
61
        "type": "field",
62
        "inboundTag": ["ria-socks-in"],
63
        "outboundTag": "freedomout"
64
      }
65
    ],
66
     "strategy": "rules"
67
  }
68
}

设置完之后开放对应的端口，然后重启服务：

1
systemctl restart xray

2. Cloudflare WARP (ZeroTrust)#

1
curl -fsSL https://pkg.cloudflareclient.com/pubkey.gpg | sudo gpg --yes --dearmor --output /usr/share/keyrings/cloudflare-warp-archive-keyring.gpg

1
vim /etc/apt/sources.list.d/cloudflare-client.list

1
deb [arch=amd64 signed-by=/usr/share/keyrings/cloudflare-warp-archive-keyring.gpg] https://packages.cloudflare.com/cloudflared/ bookworm main

1
apt-get update

1
apt-get install cloudflare-warp

1
adduser username

1
usermod -aG sudo username

1
sudo -u username warp-cli registration new YOUR_TEAM_NAME

1
sudo -u username warp-cli registration token "your access token"

1
warp-cli connect

4-QAM#

1. 信号能量#

在一个4-QAM的星座图中，以A点举例。

SA=E+jES_A = \sqrt{E} + j\sqrt{E}SA​=E​+jE​Es=(E)2+(E)2=2EE_s = (\sqrt{E})^2 + (\sqrt{E})^2 = 2EEs​=(E​)2+(E​)2=2E

其中，E\sqrt{E}E​ 是 III 和 QQQ 两个维度的各自的幅度，EEE 是每个维度的能量，每个符号在两个幅度上的能量之和是 2E2E2E。

因为是4-QAM，每个符号携带的比特数为 log⁡2(M)=2\log_2(M) = 2log2​(M)=2，因此：

Eb=Eslog⁡2(M)=Es2=EE_b = \frac{E_s}{\log_2(M)} = \frac{E_s}{2} = EEb​=log2​(M)Es​​=2Es​​=E

16-QAM#