摘要本文围绕智能创作助手在信息检索与内容生成中的应用展开重点探讨如何基于用户意图和搜索词通过网络检索整合有效信息生成结构清晰、逻辑严谨且具备实用价值的文本。内容涵盖从关键词提取到多源信息融合的全流程处理机制强调答案的可操作性与专业性。针对不同场景需求提供多种方法论支持包括分步式信息整合、关键要素提炼以及格式化输出规范。特别关注技术实现中的细节要求如避免使用第一人称、禁用步骤词汇、确保标题层级符合三级标准###等。同时对代码与数学公式的呈现方式提出严格规范确保内容在视觉呈现与语义表达上均达到高标准。最终目标是构建一个高效、准确、易于理解的信息生成系统适用于学术研究、技术文档撰写及日常知识管理等多种应用场景。目录信息检索与内容生成流程概述关键词解析与用户意图识别多源信息整合策略结构化输出规范与格式要求标题层级与文档组织原则代码与公式呈现标准实用性与可操作性设计要点应用场景与案例分析如果你用 Claude Desktop 接了几个 MCP Server或者在 Cursor 里启用了十几个 MCP 工具大概率会遇到一种诡异的体验你只是想让 AI 帮你查一个文件里的某个函数结果还没开始干活Token 计数就已经飙到了一万多。模型反应变慢了选工具开始出错甚至有时候明明有合适的工具它却绕来绕去不肯调用。这不是你的错觉。这也不是什么玄学问题。这是一个有着清晰数学结构和工程根源的系统性问题——连接器Connector / MCP Tool的数量增长会以非线性的方式侵蚀上下文窗口的有效容量。这篇文章想把这件事从底层说清楚为什么工具多了窗口就挤不是一个实现细节上的小问题而是当前大模型应用架构中一个本质性的矛盾。一、先厘清问题上下文窗口不是内存是工作台在讨论挤占之前我们需要对上下文窗口建立一个准确的心智模型。很多人把它类比为计算机的内存——你往里面塞东西塞多了就满了。这个类比有一定道理但它掩盖了一个更关键的事实上下文窗口不是一个被动存储数据的容器而是模型在单次前向传播中能够对其执行注意力计算的全部 token 的序列长度上限。模型对窗口内每个 token 的理解质量不是均匀分布的注意力资源是有限且竞争性的。让我用一个更贴切的类比。想象一个外科医生正在做手术手术台上下文窗口的面积是固定的。主刀医生注意力机制在每一个时刻只能专注于手术台上有限的区域。你可以在手术台上铺更多的器械工具定义但每铺一件器械就意味着真正做手术的空间变小了医生在找器械时被无关工具干扰的概率也上升了。这就是挤占的双重含义空间挤占工具定义本身消耗 token 数量直接减少了留给用户问题、对话历史和推理结果的空间。注意力挤占即使 token 总量没有超出窗口上限过多的工具定义也会稀释注意力权重降低模型对关键信息的感知质量。前者是显而易见的占地方后者是更隐蔽但更致命的分心神。大部分人只看到了第一层而真正导致系统性能下降的往往是第二层。1.1 从 Token 计数说起一个工具到底占多少要理解空间挤占我们需要做一个精确的计算。一个标准的工具Function/Tool定义由三部分构成工具名称name通常 2~10 个 token比如read_file、execute_command、search_github_repos功能描述description通常 30~150 个 token用自然语言告诉模型这个工具做什么、什么时候该用参数模式inputSchema / parameters这是大头。每个参数包含名称、类型、描述、是否必填、枚举值等复杂工具的参数 schema 可以轻松达到 200~800 token我们来做一个保守估算。考虑一个结构中等的工具{ name: query_database, description: Execute a SQL query against the connected database and return results. Use this when you need to look up records, filter data by conditions, or perform aggregations. Do NOT use for schema modification., parameters: { type: object, properties: { sql: {type: string, description: The SQL query string to execute. Must be valid SELECT statement.}, timeout_ms: {type: integer, description: Query timeout in milliseconds., default: 30000}, max_rows: {type: integer, description: Maximum number of rows to return., default: 100} }, required: [sql] } }这个工具定义经过 JSON 序列化后大约是 450~550 个 token。注意这还算是一个相对简单的工具。当你接入一个完整的 GitHub MCP Server包含创建 issue、列出 PR、读取文件、管理分支、搜索代码、查看评论等功能工具数量可能达到 30~60 个一个综合性的企业服务 MCP如 Salesforce、Jira 加上文档检索工具总数可能超过 200 个如果是一个加密货币交易所的 API 封装工具数量甚至能超过 400 个。工具定义总 Token ≈ 单个工具平均 Token × 连接器数量 300~500 token × N代入不同的 N 值连接器数量工具定义总 Token占 128K 窗口比例占 32K 窗口比例10 个~4,0003.1%12.5%30 个~12,0009.4%37.5%60 个~25,00019.5%78.1%100 个~45,00035.2%窗口溢出200 个~90,00070.3%严重溢出看到问题了吗在 128K 窗口下接 60 个连接器光工具定义就吃掉了接近五分之一的窗口。在 32K 窗口下很多模型的默认配置60 个工具直接占掉四分之三的空间。你还没开始问问题、没开始多轮对话、没开始接收工具返回值窗口已经用掉了一大块。关键观察工具定义的 token 开销是每轮固定开销。由于大模型是无状态的每次 API 请求都必须重新携带完整的工具列表。你不是只付一次钱而是每一轮对话都在为那些本轮根本用不到的工具定义付费。1.2 真正的账本上下文窗口的预算分配让我们把一个典型 Agent 场景的 token 预算做一个更完整的拆解。在一次持续多轮的 Agent 任务中上下文窗口被以下几个部分瓜分组成部分典型 Token 大小增长模式系统提示词角色设定规则1,000~8,000固定每轮重复发送工具定义所有连接器 schema3,000~60,000固定每轮重复发送用户原始问题50~2,000一次性当前轮历史对话记录持续累积线性增长可压缩工具调用请求50~500/次每轮增加工具返回结果500~50,000/次每轮大量增加模型思维链/推理过程200~3,000/轮每轮增加模型输出最终回答200~2,000计入输出 token注意固定那两行。系统提示词和工具定义构成了每次请求的前缀开销——它们在每一轮对话中都会被完整发送。如果你有 60 个工具这意味着无论用户问的是多简单的问题你每轮都要花 25,000 个 token 来告诉模型你有哪些工具可以用。而工具返回结果那一行是最容易被低估的。你调用一个读文件的工具它可能返回 3000 行代码你调用一个搜索工具它可能返回 20 条搜索结果每条几百字你调用一个数据库查询它可能返回一张有 50 列、200 行的表。这些返回值全部要作为上下文的一部分回传给模型且很多实现是全文返回——你问第 52 行的函数定义工具把整个 3000 行文件都塞回来。所以挤占不是一次性事件而是一个动态过程固定的工具定义先占掉一块地基然后每一轮工具调用又在这栋楼里添砖加瓦直到整个窗口被塞满。二、注意力稀释看不见的认知税负如果说 token 数量的空间挤占还算一个直观的容量问题那么注意力稀释Attention Dilution就是一个更隐蔽、更深刻的质量问题。很多开发者的第一反应是那我换更大窗口的模型不就行了——这恰恰误解了问题的本质。2.1 自注意力的数学本质所有 Token 在竞争注意力Transformer 的核心是自注意力机制Self-Attention。我不想在这里推导完整公式但我们需要理解一个关键性质在每一层注意力头中每个 token 都会对序列中的所有其他 token计算一个注意力权重然后根据这些权重对所有 token 的 value 向量做加权求和。用简化的语言说模型在处理每个位置时会看一眼上下文中的所有内容然后决定把多少注意力分配给每个词。Attention(Q, K, V) softmax(Q · KT / √dk) · V其中 Q·KT 是一个 n×n 的注意力分数矩阵n 是序列长度。softmax 操作将每一行的分数归一化为概率分布——这意味着每个 token 对其他所有 token 的注意力权重之和恒等于 1。这就是注意力稀释的数学根源注意力权重是一个归一化的概率分布它的总预算是固定的等于 1。当序列中增加新的 token 时除非这些新 token 被判定为完全无关注意力权重为 0但实际中极少发生否则它们必然会从已有 token 那里抢走一部分注意力权重。把这个概念具体化。假设在没有任何工具定义的情况下模型处理用户问题查一下订单 12345 的物流状态时对订单物流12345这几个关键词分配的注意力权重合计为 0.3。当你注入了 60 个工具定义后这些工具名称、参数描述、使用说明都会参与注意力计算。即使模型最终正确选择了query_order工具其他 59 个无关工具的描述仍然会从总概率质量中分走一部分权重——因为 softmax 不会把它们的权重精确归零只会让它们变得相对较小。注意力稀释的定量直觉如果 n 个 token 大致均匀地分散注意力最坏情况每个 token 分到的平均注意力权重约为 1/n。当上下文从 4000 token 增长到 40000 token增加 10 倍工具定义理论上每个 token 的平均注意力权重下降到原来的 1/10。当然实际中注意力是稀疏且非均匀分布的关键 token 会获得比平均值更高的权重。但无关 token 越多关键 token 拿到的权重就越低这个趋势在数学上是不可避免的。2.2 迷失在中间效应如何被工具放大2023 年以来被广泛研究的Lost in the Middle现象揭示了一个与直觉相悖的事实大模型对长上下文的开头和结尾信息保持较高的召回率但对序列中段信息的召回率显著下降呈现出明显的 U 形注意力曲线。这个效应在 Agent 场景中被工具定义严重放大了。原因在于上下文的排列顺序开头系统提示词高注意力区紧接着工具定义列表——这是一个巨大的块通常占据数千到数万个 token中间历史对话记录、之前的工具调用结果低注意力区尾部当前用户问题或最新的工具返回结果高注意力区问题在于工具定义这个大块本身虽然被放在开头区域获得了一定的注意力但它同时做了两件坏事第一它把对话历史推到了更深的中间地带。假设系统提示词是 2000 token工具定义是 25000 token。那么第 1 轮对话的起始位置就在第 27000 个 token 处。如果你的总窗口是 128K这意味着前 20% 的窗口被工具定义占满真正有语义内容的对话历史全部落在中段——注意力衰减最严重的区域。用户在第 2 轮说过的重要信息比如我们用的是 PostgreSQL 14不是 MySQL在第 8 轮时恰好滑到了注意力谷底。第二工具定义本身内部也存在中间迷失。一个 25000 token 的工具列表第一个工具和最后一个工具获得的注意力权重可能高于中间的工具。这意味着模型在选择工具时存在位置偏差——排在列表开头和结尾的工具更容易被选中中间的工具即使功能更匹配也可能被忽略。这不是猜测而是有实验数据支撑的行为当工具数量超过 40 个时开发者普遍观察到模型开始出现选错工具的现象且选错的往往不是最不相关的工具而是位置更靠近首尾的工具。2.3 指令遵循率的非线性下降注意力稀释不只是找错工具这么简单它还会导致系统指令的执行力下降。系统提示词通常位于上下文的最开头包含了对模型行为的各种约束输出格式、拒答规则、安全边界、工具调用协议等。当上下文被大量工具定义和历史数据填满时系统提示词中的关键约束被埋在了数万 token 之前。虽然位置编码理论上让模型能够看到这些 token但实际注意力权重的衰减使得这些约束的信号强度大幅降低。这就解释了一个常见现象当工具很少时模型严格遵守输出格式要求当工具增加到几十个后模型偶尔会忘记输出 JSON 格式、漏填必填参数或者在应该调用工具的时候直接生成自然语言回答。这种下降不是线性的。从 10 个工具增加到 30 个工具你可能感觉不到明显变化但从 40 个工具增加到 80 个工具指令遵循率会出现一个明显的拐点——错误率从个位数跃升到两位数。这个拐点存在的原因在于当无关信号的总量超过某个阈值后softmax 注意力分配会发生一种相变关键 token 的权重从显著高于噪声变成与噪声难以区分。这类似于信噪比低于某个阈值后无线电信号突然被噪声淹没。三、多轮循环的复利灾难Token 是如何滚雪球的静态分析只看到了单轮请求的情况。真正恐怖的是多轮交互中的复利效应——工具定义的固定开销在每一轮中都被重复支付而工具返回结果的累积又在不断压缩可用空间。两者叠加形成了一个加速恶化的正反馈循环。3.1 固定开销的重复支付理解这一点至关重要大语言模型是无状态的。它不像数据库那样记住你之前传过的工具列表。每一次你调用 API你都必须把所有信息——系统提示词、全部工具定义、完整对话历史、当前问题——一股脑全部发送过去。这意味着什么假设你有 60 个连接器工具定义总共约 25000 token。如果一个复杂任务需要 Agent 进行 20 轮交互这在 Coding 场景中非常常见读文件→搜索→读更多文件→写代码→执行测试→修改bug→再测试...那么仅工具定义这一项的总 token 消耗就是25,000 token × 20 轮 500,000 token这 50 万 token 中绝大部分是重复的。工具列表在 20 轮中没有任何变化但你为它付了 20 次费用。相比之下如果用户的问题和对话历史总共才 10000 token你会发现整个任务中超过 90% 的输入 token 花在了与本轮决策无关的固定开销上。这是当前 Agent 架构中一个极其低效的设计——Prefix Caching前缀缓存虽然在部分 API 提供商处已经实现可以大幅降低缓存命中 token 的成本约为正常价格的 10%~25%但这只是降低了费用并没有解决窗口容量和注意力稀释的问题。缓存的 token 仍然占据上下文窗口的物理空间仍然参与注意力计算。3.2 工具返回值的二次污染如果说工具定义是固定税那么工具返回值就是累进税——而且是税率越来越高的那种。每次调用工具后执行结果需要作为一条新消息追加到上下文中让模型基于结果继续推理。问题在于大部分 MCP 工具的默认返回策略是全文返回read_file工具返回文件全部内容不管你需要的是哪几行list_directory工具返回目录下所有文件的完整列表web_search工具返回搜索结果的完整摘要文本database_query工具返回查询到的全部行和列execute_command工具返回完整的 stdout/stderr 输出一个中等复杂度的编码任务中工具返回值的数据量非常可观。实测数据显示在 Claude Code 或 Cursor 中处理一个包含 380 个文件、12 万行代码的中型 Node.js 项目时查找某个函数的定义和用法平均消耗 ~38,000 token其中工具返回占 80% 以上理解一个模块的整体逻辑平均消耗 ~52,000 token修改一个跨 3 个文件的功能平均消耗 ~67,000 token这些工具返回值一旦进入上下文就占据了窗口空间且在后续每一轮中都被重复发送和重复计算注意力。更糟糕的是很多工具返回的内容是高度冗余的——你为了找到一个函数定义grep 搜索返回了 50 个匹配行但其中 47 个都是无关的 import 语句或注释。于是形成了一个恶性循环上下文膨胀的正反馈循环第一步连接器越多工具定义占用的固定空间越大 →第二步留给工具返回值和对话历史的有效空间变小 →第三步空间变小后模型不得不更频繁地调用工具来获取信息因为上下文里放不下足够的信息→第四步更多的工具调用带来更多的返回值进一步挤占窗口 →第五步窗口逼近上限后框架开始截断最早的对话历史 →第六步截断导致模型丢失之前的决策上下文做出错误判断需要更多轮工具调用来纠正 →回到第二步循环加速。3.3 截断的残酷性不是遗忘是删除当上下文窗口真的被撑满时几乎所有 Agent 框架都会采取同一种策略截断Truncation——丢弃最早的消息给新内容腾位置。这通常不是一个优雅降级的过程而是一个硬切。截断带来了一个严重问题它可能直接切断了任务逻辑链。想象一下用户在第 1 轮告诉 Agent 请把所有 API 响应改为 camelCase 格式在第 12 轮时由于工具定义和中间返回值占据了太多空间最早这条指令被截断掉了。第 13 轮 Agent 开始生成 snake_case 的代码——它不是忘记了它根本看不到那条指令了。这也是为什么很多人感觉 Agent 说着说着就跑偏了。在工具多的场景中系统提示词工具定义本身就占了很大前缀留给对话历史的空间被严重压缩。一个 128K 的窗口去掉 30K 的系统工具开销剩 98K。每轮工具返回平均 8K token那么大约 12 轮之后最早的对话就面临被截断的风险。如果工具更多比如 100 个连接器吃了 45K那么可用空间进一步缩减到 83K约 10 轮就开始截断。四、Prefill 阶段的计算税延迟和成本的双重打击到这里我们讨论了窗口容量和注意力质量但还有一个维度经常被忽视推理延迟和计算成本。上下文越长模型处理一次请求的时间就越长费用也越高——而这不是线性关系。4.1 O(n²) 的注意力计算标准 Transformer 的自注意力计算复杂度与序列长度的平方成正比即 O(n²)。这是因为 Q·KT 矩阵乘法中Query 矩阵是 n×dKey 矩阵是 d×n相乘得到 n×n 的注意力分数矩阵。n 翻倍这一步的计算量变成四倍。当然现代推理引擎做了大量优化——FlashAttention、PagedAttention、Grouped-Query Attention 等技术显著改善了显存访问效率但这些优化主要改善的是常数因子和 IO 效率并不能把 O(n²) 变成 O(n)。序列长度仍然是 Prefill 阶段处理输入 token 的阶段计算量的主导因素。Prefill 阶段的耗时直接决定了用户感受到的首字延迟Time to First Token, TTFT。当输入从 4000 token 增加到 40000 token 时首字延迟可能从 300ms 增加到 2~3 秒。对于实时对话产品来说2~3 秒的等待已经是明显的体验降级。4.2 Token 账单的真实面目从成本角度看API 定价按输入 token 和输出 token 分别计费且输入 token 的价格虽然低于输出 token但在 Agent 场景中输入 token 的数量远远超过输出 token。以 2026 年主流模型定价水平估算场景平均输入 Token/轮平均输出 Token/轮输入占总费用比普通聊天无工具500~2,000300~1,000~40%RAG 问答5个工具3,000~10,000500~1,500~70%Coding Agent30个工具15,000~50,000800~3,000~90%多 MCP 编排60工具40,000~120,000500~2,000~95%当你接入 60 个以上连接器时输入 token 中的相当一部分是工具定义的重复开销。以 20 轮任务、每轮 25000 工具 token 计算仅工具定义的输入费用就达到了 50 万 token。按主流商业模型输入价格约 15~70 元/百万 token这部分费用约为 7.5~35 元——这是一个任务的费用。如果你的产品每天服务 1000 个用户工具定义带来的无效开支就是每天 7500~35000 元。这就是为什么行业里有人把这种现象称为Token 税——你每接一个连接器就等于在每轮对话中交一笔固定税连接器越多税率越高对话轮次越多税收总额越大。五、更深层的矛盾协议设计哲学与架构现实的冲突到这里我们讨论的都是症状和机制。但如果退一步看这个问题的根源其实是一种架构层面的矛盾MCPModel Context Protocol以及类似的工具调用协议在设计哲学上假设模型应该知道所有可用的工具但 Transformer 的架构现实决定了模型无法在不付出注意力代价的情况下知道更多工具。5.1 全量注册模式的设计假设MCP 协议的tools/list接口采用全量返回模式客户端与服务器建立连接后一次性获取该服务器开放的所有工具定义然后将这些工具全部注入到发给模型的 tools 数组中。这个设计的优点是简单——模型在每次决策时都能看到完整的工具菜单可以自由选择最合适的工具。但这个设计隐含了一个没有被明说的假设上下文窗口是免费的或者至少是足够大的。在工具数量很少时5~10 个内置工具这个假设近似成立。但当 MCP 生态爆发用户开始同时接入 GitHub、Slack、数据库、文件系统、浏览器自动化、邮件、日历、云服务等十几个 MCP Server 时工具数量轻易超过 100 甚至 200这个假设就彻底破产了。这不是 MCP 独有的问题。OpenAI 的 Function Calling、Anthropic 的 Tool Use、Google Gemini 的 Function Declaration——所有主流工具调用机制都采用同样的全量注入模式。MCP 只是因为让外部工具接入变得零成本从而把这个矛盾以前所未有的烈度暴露出来。5.2 类比从命令行参数到操作系统的架构错位我想到一个很有意思的类比。早期的命令行工具通过命令行参数传入配置参数少的时候没问题但当功能膨胀后命令行参数列表变得又长又难用于是发明了配置文件、环境变量、交互式菜单等机制来避免每次都传递全部配置。当前的工具调用架构相当于停留在命令行参数阶段——每次调用都把所有可用工具作为参数传入。而我们需要的是某种操作系统级的能力管理模型不需要知道系统里安装了所有工具只需要在需要的时候能找到合适的工具。人的工作方式也是如此。一个优秀的程序员不需要在脑子里记住所有可用的 CLI 命令、所有库函数的签名、所有 API 的参数格式。他只需要知道有这方面的工具然后在需要时通过man页面、--help、文档搜索或 IDE 自动补全去查找具体用法。人类的工作记忆是有限的但我们通过外部记忆文档、搜索、索引来弥补。连接器过多挤占上下文窗口的本质就是试图把整个软件仓库的目录塞进人的工作记忆里而不是提供一个按需检索的索引系统。5.3 为什么更大的窗口不是答案最常见的回应是模型窗口会越来越大从 128K 到 1M到时候这个问题自然就解决了。这个说法我不敢苟同原因有三第一注意力跨度不等于窗口大小。如前文所述即使窗口支持 1M token模型对中间部分信息的有效注意力仍然显著下降。大量研究表明当上下文超过一定长度不同模型这个阈值不同大约在 64K~256K 之间信息检索质量出现断崖式下跌。把更多工具塞进一个 1M 窗口可能只是让更多工具定义被看见但被忽略。第二成本不会因为窗口变大而消失。1M 窗口的模型推理成本和延迟远高于小窗口模型。即使技术上能塞下每轮对话为 200 个工具定义付费仍然是巨大的浪费。而且当窗口变大后开发者的倾向是塞更多东西进去更多历史、更多 RAG 检索结果、更多工具成本继续膨胀。第三工具数量也在增长。窗口从 8K 扩到 128K16倍的同时可用的连接器数量从几个增长到几百个接近 100 倍。连接器的增长速度超过了窗口扩容的速度这个缺口不会因为技术进步自动弥合。MCP 生态正在爆发式增长可以预见未来会出现上万个公开 MCP Server你不可能把它们全部注入上下文。六、工程出路如何在不牺牲能力的前提下缓解挤占分析问题是为了解决问题。理解了挤占的机制之后我们来讨论当前业界已经在实践和探索的解决路径。这些方案不是互斥的它们在不同层面上缓解问题。6.1 工具按需加载Tool Search / Tool Retrieval最直接的思路是不要把所有工具都注入上下文只注入当前任务可能用到的工具。这相当于给工具做了一层检索——先根据用户意图从全量工具库中筛选出 Top-K 个最相关的工具再把这些工具发给模型。实现方式通常有两种基于 embedding 的语义检索将每个工具的描述文本编码为向量用户问题到来时用问题向量在工具向量库中做相似度搜索取最相似的 K 个工具注入。这种方法简单高效对工具数量的扩展性好几百到几千个工具都能处理但可能漏掉语义上不完全匹配但实际需要的工具。基于轻量模型的工具路由训练一个小模型或用规则LLM做工具分类判断当前任务需要哪些领域的工具然后加载对应领域的工具组。很多 MCP Server 已经开始将工具分组如 SOCIAL_MEDIA、FINANCE、BROWSER 等允许用户在配置中指定只加载某些组。核心挑战在于检索召回率。如果筛选阶段漏掉了真正需要的工具模型就无法完成任务——这比多注入一些无关工具更致命。因此实际工程中通常采用两阶段策略先检索缩小范围如从 200 个筛到 20 个再让模型在这 20 个工具中做选择。这样既大幅降低了 token 开销又保留了足够的选择余地。6.2 工具定义的精简化这是最容易落地的优化把每个工具的定义写得更短、更密。很多开发者在写工具描述时有一种倾向觉得写得越详细模型用得越准。实际上冗余的描述不仅浪费 token还可能干扰模型判断。好的工具描述应该做到一句话说清功能不要用长篇大论解释工具的实现细节或使用场景参数描述精确而简洁每个参数的描述控制在一句话以内避免重复参数名所隐含的信息省略不言自明的内容比如path参数的类型是 string不需要额外写这是一个字符串类型的路径参数用结构化缩写枚举值如果很多不必全部列出只列最重要的几个加等工具返回值的精简同样重要。将全文返回改为摘要优先、按需展开模式工具先返回结构化的摘要信息如文件的函数列表、搜索结果的标题列表模型需要细节时再调用工具获取特定部分。实测表明AST 摘要化可以将代码文件读取的 token 消耗降低 80%~85%。6.3 上下文管理的分层策略更系统的做法是对上下文内容进行分层管理不再无差别地堆叠所有信息。一种有效的分层模型是核心层Core Context系统提示词精华版、当前用户问题、当前活跃工具定义——始终保留在上下文中不参与淘汰工作层Working Context最近 N 轮对话、最近的工具返回结果——在窗口中滚动保留归档层Archived Context较早的对话历史、已完成步骤的工具返回——压缩为摘要后保留或移出上下文存入向量数据库需要时通过检索重新载入这本质上是在模拟人类的记忆系统工作记忆容量小但速度快长期记忆容量大但需要检索。不是所有信息都应该始终占据工作记忆的位置。6.4 架构层面的长期方向从更长远的角度看真正解决这个问题需要架构层面的创新原生工具检索能力未来的模型可能在微调阶段就具备先搜索可用工具、再使用工具的能力而不是依赖应用层做工具筛选。这相当于把 Tool Search 内化到模型的推理流程中。分层注意力/条件注意力在注意力机制层面可以对工具定义使用特殊的掩码或条件计算——只有当模型决定要选工具时才去深度处理工具定义部分而不是在每一步推理中都对全部工具进行完整注意力计算。协议演进MCP 和类似协议需要从全量注册模式进化到支持按需发现模式。MCP Server 应该支持工具检索接口不仅仅是 tools/list允许客户端先查询我有某个需求你这里有什么相关工具再获取特定工具的完整定义。七、结语在能力与容量之间找到平衡连接器太多会挤占上下文窗口这不是一个 bug也不是某个实现的失误——它是当前 Transformer 架构与全量工具注入模式之间根本性张力的体现。自注意力机制的 O(n²) 复杂度、注意力权重的归一化特性、模型的无状态性、多轮对话的累积效应这些因素共同作用使得工具越多越好的直觉在某个拐点之后变成了工具越多越差的现实。理解这个问题的意义不仅仅在于省 token。它关系到我们如何设计下一代 AI 应用架构是继续沿着把一切都塞进上下文的暴力美学前进还是发明更聪明的信息组织方式让模型在有限的注意力资源下做出更好的决策我倾向于后者。人类的智慧从来不是因为我们能同时在脑子里 hold 住成千上万的工具和信息而是因为我们擅长在需要的时候找到需要的东西。给模型构建类似的索引能力和检索习惯比简单地扩大上下文窗口更接近智能的本质。在工程实践中我的建议是把工具数量当成一个需要严肃管理的指标而不是越多越好。定期审查哪些连接器是真正必要的哪些是装了但从没用过的。对工具描述做精益写作用最少的 token 把功能说清楚把参数说明白。尽快实现工具的按需加载机制哪怕是最简单的规则过滤或 embedding 检索都能带来显著改善。对工具返回值做摘要化和截断处理默认返回摘要而非全文需要时再展开细节。建立上下文分层管理机制区分核心信息和历史信息适时归档和压缩。连接器是 Agent 感知世界、改变世界的手。手太多了大脑处理不过来反而手忙脚乱。给大脑一张清晰的可用手清单比把所有手都摆在它面前更能让它做好事情。