7.上下文工程

上下文工程: 模型每次推理时，它眼前的全部内容(系统提示词 + 工具说明 + 记忆 + 检索结果 + 历史 + 当前问题) 如何组合最优 -- 这是信息架构。

一个真实智能体每轮要塞的东西:

┌── 上下文窗口(比如 32K Token)───────┐
│ 系统提示词(人设+规则)      ~800 tok │ ← 固定开销
│ 工具说明书(20个工具)      ~3000 tok │ ← 固定开销
│ 记忆检索结果               ~1000 tok │ ← 动态
│ RAG 检索的文档块           ~4000 tok │ ← 动态
│ 历史对话(已聊50轮)       ~20000 tok │ ← 疯狂膨胀!
│ 当前用户问题                ~200 tok │
└──────────────────────────────────┘

随着上下文里塞的内容越来越多,模型准确回忆其中信息的能力会持续下降。这个现象叫上下文腐蚀(context rot)。厂商标称的"支持 200K 上下文"说的是技术上不报错,不是"塞满 200K 时效果和塞 2K 一样好"。

为什么会这样,三个原因:

• 注意力被拉薄。Transformer 的注意力机制要计算每个 token 和其他所有 token 的两两关系,token 数量翻倍,关系对数量涨到四倍( )。但模型的"注意力总量"是有限的——内容越多,分给每一条的注意力就越少。就像一个人同时听 100 个人说话,不是听不见,是听不清。
• 训练数据的长度分布是偏的。互联网上的文本绝大多数是短的,几十万字的超长样本极少。所以模型在长上下文上的训练远不如短上下文充分——它在长文里的表现是"外推",不是"内插"。
• 位置编码要做插值。模型原本在比如 4K 长度上训练位置编码,扩展到 128K 时要把位置刻度"拉长"(插值)。副作用是位置精度被牺牲:模型知道某句话大概在前半段,但"到底是第 300 句还是第 320 句"变模糊了。

最关键的一点,请务必记住:上下文腐蚀表现为平滑的性能梯度,不是悬崖式崩溃。

三条黄金原则

• 预算制:给每类内容分配 Token 配额(如系统 5%、工具 10%、检索 20%、历史 50%、留白 15%),超配额就压缩,谁也不许挤占别人;
• 新鲜与重要优先:历史太长时,保最近几轮原文 + 更早的压缩成摘要;检索结果按相关度截断;
• 少而准胜过多而全:因为有上下文腐蚀,塞进去的每一条都要为自己的位置付费。判断标准不是"这条有没有用",而是"这条的价值是否超过它挤薄其他内容的代价"。

GSSC四阶段上下文流水线

GSSC是上下文组装的四个阶段:

1. Gather(汇集): 把所有可能有用的信息包成统一格式的候选
2. Select(选择): 给每个候选打分，在预算内贪心装包
3. Structure(结构化)： 按固定分区拼装成最终文本
4. Compress(压缩)： 万一还是超过了，按分区截断兜底

长程任务三件套

真实的智能体任务经常跑几十上百轮 -- 上下文必然会满。

这时候需要三种技术，他们不是三选一， 而是配合使用

Compaction: 不是删，是提炼

当上下文快满时，让模型总结一份高保真的交接文档，然后开一个新的窗口，只带这份摘要继续干。

结构化笔记

模型在任务过程中主动把进度、结论、卡点写到磁盘，需要时再读回来。

它和Compaction的关键区别:

• Compaction是被动的(窗口满了才做)，笔记是主动的(随时记)。

Sub-agent架构: 用干净窗口换隔离

主智能体负责规划和汇总，把具体的子任务派给子智能体，每个子智能体有自己干净的上下文窗口。

为什么有效 -- 两个理由，第二个更重要:

• 总容量变大了: 三个子智能体 = 三个窗口，能处理的信息是单窗口的三倍。
• 污染被隔离了: 子智能体探索时产生的一大堆中间垃圾(例如读了30个文件、试了5个错误方向)留在它 自己的窗口里，不会留进主窗口。主智能体只收到结论。

智能体通信协议

• MCP: 统一了智能体怎么用工具(相当于给工具固定了USB接口)
• A2A： 统一了智能体怎么和别的智能体对话
• ANP: 想让全网的智能体能互相发现和组网

MCP

MCP(Model Context Protocol，模型上下文协议)由Anthropic 2024年底发布，核心角色:

• MCP服务器: 工具的提供方。把查天气、读数据库包装成标准格式对外提供，并能回答你有哪些工具？每个工具要什么参数？
• MCP客户端: 工具的使用方(智能体/IDE/聊天应用)。连上服务器 -> 拿到工具清单 -> 需要时按标准格式调用。

MCP vs Function Calling的区别

• Function Calling： 是模型的能力(模型输出结构化的调用意图)
• MCP: 是工具的分发标准(工具怎么被发现、描述、调用)

两者是上下游关系，不是竞争关系: 智能体用Function Calling决定我要调工具，通过MCP找到并执行工具。

A2A

A2A(Agent-to-Agent),Google 2025 年发布。解决的问题:你的智能体怎么调用别人家的智能体(而不是工具)?核心机制:

Agent Card(名片):每个 A2A 智能体挂出一份标准 JSON 名片——我叫什么、我会什么技能、在哪个地址找我; 任务(Task)机制:调用方发任务 → 接收方异步执行 → 中途可以汇报进度、可以追问澄清 → 最终交付。对话式、长任务友好,这是它和"调工具"最大的不同:工具调用是"一问一答",智能体协作是"来回商量"。

ANP(Agent Network Protocol):更宏大的愿景——让全网智能体像网站一样可以被发现(类似 DNS/搜索引擎)、互相认证(去中心化身份 DID)、自由组网。目前处于早期,了解理念即可:如果说 MCP/A2A 在修"点对点的路",ANP 想修"整个路网"。

三句话记住分工:MCP 管"用工具",A2A 管"雇同行",ANP 管"找到彼此"。 真实系统三者叠着用:你的智能体通过 ANP 发现一个擅长财报分析的智能体 → 通过 A2A 委托它任务 → 它内部通过 MCP 调用数据库工具完成分析。