有用户实测同一个任务Codex花¥5、DSH标准模式花¥50，多烧10倍，单个DSH响应可能超过100万Token，复杂对话累计到1亿Token——当“一切皆插件”意味着每个插件都要往上下文里塞说明和规则时，插件装得越多、模型越难专注任务推理这件事，到底该靠“少装”来解决，还是该靠框架层面的上下文管理来兜底？

从Token经济学到上下文治理：插件化Agent框架的成本结构与注意力预算

摘要与核心论点

同一任务、同一模型能力档位，Codex路径花费约¥5，而DSH标准模式花费约¥50，十倍价差并非来自模型单价，而是来自“进入模型的Token总量”与“有效推理Token占比”的差异。单个响应突破100万Token、复杂对话累计逼近1亿Token，这类数字把问题从“模型贵不贵”推向了“上下文装了什么”。

本文的核心论点是：插件数量是表层变量，上下文装配策略才是根因变量。“一切皆插件”的架构把能力扩展做成了声明式清单，但每个插件的描述、参数Schema、调用示例、失败重试规则都要以自然语言或结构化文本形式占用上下文窗口；当插件数从个位数增长到数十上百，上下文里“关于工具的说明”会系统性挤压“关于任务的推理”。因此，单纯“少装插件”是治标，框架层的上下文管理才是治本，二者应形成“准入控制+运行时治理”的双层结构。

本文评述：把十倍成本差归因于“插件太多”是一种便利但危险的简化。插件是能力的载体，问题在于框架是否具备“按需装配、按轮淘汰、按证据压缩”的上下文调度能力。缺少这层能力时，插件越少越安全；具备这层能力时，插件多并不必然导致成本失控。

目录

背景与问题定义：十倍价差是怎么被“装”出来的

1. 现象层：一次可复现的成本对比

用户实测给出的数字是：同一任务，Codex路径约¥5，DSH标准模式约¥50。需要强调的是，这类对比属于单点实测，受任务类型、提示词长度、重试次数、缓存命中率影响，不能直接外推为普遍比例；但它揭示了一个可被独立验证的结构性事实——在插件化框架中，单次请求的输入Token往往远大于“任务本身所需的信息量”。

按公开定价口径粗略换算（不同厂商、不同模型档位差异很大，此处仅作量级示意）：若某模型输入价格约为每百万Token数元至数十元区间，那么¥50对应的输入规模可能落在数百万Token量级；而“单个响应超过100万Token、复杂对话累计到1亿Token”的描述，与“每轮都重新装载全部插件说明+历史对话+工具返回结果”的累积模式高度吻合。这类换算属于模拟估算，用于建立量级直觉，不作为精确账单。

笔者认为，十倍价差最值得追问的不是“贵不贵”，而是“贵在了哪一层”。如果贵在任务本身的复杂度，那是合理成本；如果贵在“每个插件都要往上下文里塞说明和规则”，那就是架构性浪费。

2. 概念层：什么是“上下文装配”

本文把上下文装配（context assembly）定义为：在每次模型调用前，框架从系统提示、工具清单、会话历史、检索片段、工具返回、用户输入等来源中，按某种策略选择、排序、裁剪、压缩并拼接成最终输入序列的过程。它决定了“模型这一轮能看到什么”，也直接决定了账单。

与之相对的是上下文治理（context governance）：一套贯穿会话生命周期的策略集合，包括准入（哪些插件可被装载）、预算（每轮Token上限与分配比例）、淘汰（何时丢弃或摘要历史）、验证（压缩后信息是否仍足以完成任务）与回滚（压缩导致失败时的降级路径）。装配是动作，治理是制度。

提示：判断一个Agent框架是否“成熟”，一个低成本的方法是看它是否暴露了每轮请求的Token构成明细（系统提示/工具Schema/历史/检索/工具返回各占多少）。没有这层可观测性，任何“优化”都只能靠猜。

3. 问题重述：三个可证伪的假设

为避免空泛讨论，把问题拆成三个可检验的假设：H1，插件说明与Schema在输入Token中占比显著（例如超过30%）；H2，在固定任务成功率下，减少无关插件可降低总Token消耗；H3，在插件数量不变的前提下，引入按需装配与历史压缩可进一步降低成本且不显著降低成功率。H1、H2决定“少装”的价值边界，H3决定“框架兜底”的价值边界。后文的数据与案例将围绕这三条展开。

原理与技术路线：上下文膨胀的四条因果链

1. 因果链一：声明式工具清单的固定开销

主流工具调用协议（如OpenAI的function calling、Anthropic的tool use、以及社区广泛采用的JSON Schema描述方式）要求框架在请求中携带每个工具的名称、用途说明、参数结构、必填项与枚举约束。单个工具的Schema从几十到数百Token不等，若附带调用示例与错误处理说明，开销进一步上升。工具数量为N时，这部分开销近似线性增长，且每一轮都要重复支付。

本文评述：这部分开销的本质是“把工具目录常驻在模型的工作记忆里”。人类工程师不会在每次思考时默念全部API文档，而是按需查阅；框架若不做同样的按需加载，就等于强迫模型每轮做一次全量目录扫描，既费钱又分散注意力。

2. 因果链二：历史对话的线性累积与二次放大

多轮对话中，若每轮都把完整历史重新送入模型，则第t轮的输入规模约等于前t-1轮所有消息之和，累计消耗随轮数呈二次增长。工具调用会显著加剧这一点：一次工具调用至少产生“调用请求+返回结果”两条消息，返回结果可能是长文本、JSON数组或日志片段。复杂对话累计到1亿Token，正是这种“全量重放+工具返回膨胀”的典型结果。

需要区分两种成本：重放成本（历史被反复计费）与体积成本（单轮输入过大）。前者靠缓存与增量策略缓解，后者靠裁剪与压缩缓解。很多团队只做了前者，误以为“命中缓存就没事了”，但缓存通常只降低单价、不降低上下文占用对注意力的稀释。

3. 因果链三：注意力稀释与“中间遗忘”

即便忽略成本，上下文过长也会损害任务表现。学界对长上下文利用的经典观察包括“lost in the middle”现象：关键信息位于长上下文中部时，模型召回率明显低于首尾位置（Liu et al., 2023）。后续研究进一步指出，长上下文中的干扰项会系统性拉低推理准确率，且这种退化并非简单由“窗口不够大”导致。换言之，插件说明不仅是费用项，还是干扰项。

笔者认为，把“装得多”与“想得深”对立起来是准确的直觉，但机制上应表述为：上下文中的非任务信息提高了信噪比恶化的概率，模型需要在更多候选片段中定位与当前子目标相关的证据，定位失败即表现为“跑题”“重复调用工具”“忽略约束”。

4. 因果链四：框架层的“安全冗余”叠加

工程实践中，框架为了稳健常加入多类冗余：系统提示中的行为规范、工具使用守则、失败重试说明、输出格式约束、安全策略、示例对话。每一项单独看都合理，叠加后形成可观的固定前缀。更隐蔽的是“规则冲突”：不同插件附带的规则可能相互矛盾（例如一个要求先检索再回答，另一个要求直接回答），模型需要在冲突中做取舍，进一步消耗推理预算。

关键数据与案例：从Token账本到注意力预算

1. 公开研究给出的量级参照

关于长上下文退化，Liu等（2023）在“Lost in the Middle”中系统报告了关键信息位置对召回的影响；An等（2024，Many-Shot In-Context Learning）讨论了超长上下文下示例数量增加带来的收益递减与干扰；Hsieh等（2024，RULER）提出了更贴近真实任务的长上下文评测，发现多数模型在有效长度上显著低于标称窗口。这些结论共同支持一个工程判断：标称上下文窗口不等于可用上下文预算。

本文评述：RULER一类工作的价值在于把“能塞进去”与“能用起来”分开度量。对插件化框架而言，这意味着评估指标不能只看“是否超出窗口”，还要看“在给定窗口占用下任务成功率如何变化”。

2. 一个可复算的Token账本（模拟示例）

为便于工程团队自建账本，给出一个模拟示例（非真实账单，仅演示计算方法）：假设系统提示与规则合计3000 Token，每个插件说明与Schema平均400 Token，装载40个插件即16000 Token；历史对话平均每轮新增800 Token，工具返回平均每轮新增2500 Token；任务平均12轮。则首轮输入约19000 Token，第12轮输入约19000+11×(800+2500)≈55300 Token，12轮累计输入约 (19000+55300)×12/2≈44.6万 Token。若工具返回更长或插件更多，累计到百万级并不困难。

# 模拟账本（示意，非真实数据）
fixed = 3000            # 系统提示+规则
per_plugin = 400        # 单插件说明+Schema
plugins = 40
hist_per_turn = 800
tool_per_turn = 2500
turns = 12

first = fixed + per_plugin * plugins
last = first + (turns - 1) * (hist_per_turn + tool_per_turn)
total = (first + last) * turns / 2
print(first, last, total)  # 19000 55300 445800

这个账本的意义在于把“十倍”拆成可调节的旋钮：插件数、单插件开销、每轮历史增量、工具返回体积、轮数。任何一个旋钮的调整都能被量化评估，而不是靠感觉“少装几个”。

3. 工程案例：三类典型失控场景

场景A，插件市场式装载：用户一键安装数十个插件，框架默认全量注入，导致每轮固定开销过万Token。场景B，工具返回未加工：检索插件返回整页HTML或完整JSON，模型被迫在噪声中抽取字段。场景C，规则叠加冲突：多个插件各自附带“必须”“禁止”类规则，模型在冲突中反复试探。三类场景的共同点是：框架把“可用能力”等同于“必须可见”。

拓展阅读：关于工具调用与结构化输出的官方说明，可参考 OpenAI Function Calling 文档（platform.openai.com/docs/guides/function-calling）与 Anthropic Tool Use 文档（docs.anthropic.com/en/docs/build-with-claude/tool-use）；长上下文评测可参考 RULER 项目页（github.com/NVIDIA/RULER）。

对比与局限：少装、框架兜底与第三条路

1. “少装”的有效边界

少装插件直接削减固定开销，是最快见效的手段，适用于插件使用频率高度不均、且任务域相对固定的团队。其局限在于：能力覆盖与成本之间存在硬取舍，业务一旦需要长尾能力，用户仍会安装；此外，少装无法解决历史累积与工具返回膨胀，对多轮复杂对话的治理作用有限。

笔者认为，“少装”应被重新定义为准入控制而非永久裁剪：按任务域动态启用插件子集，而不是让用户在全局层面做一次性取舍。

2. 框架兜底的能力清单

框架层可做的事包括：工具分层与按需检索（先给工具目录摘要，模型需要时再拉取完整Schema）、历史分层（近期原文、中期摘要、远期要点）、工具返回结构化裁剪（只回填必要字段）、规则去重与优先级合并、每轮预算分配与超限降级、以及全链路Token可观测性。这些手段组合后，可以在插件数量不变的情况下显著压低无效Token。

3. 第三条路：准入控制与运行时治理的组合

本文主张的路径是“准入控制+运行时治理”双层结构：准入层决定哪些插件进入候选池（按任务域、使用频率、风险等级），治理层决定每轮实际装载哪些、装载多少、如何压缩。二者不是二选一，而是分别作用于“长期能力面”与“单轮上下文面”。

本文评述：把问题表述为“少装还是兜底”本身是一个伪二分。真正的问题是“谁来决定装什么、以什么粒度装、装错了如何回退”。这三个问题都指向框架的调度能力，而非插件的绝对数量。

可操作路径：上下文治理的工程实施步骤

步骤一：建立Token账本与可观测性

在框架的请求构造层埋点，记录每轮请求的Token构成：系统提示、工具Schema、历史原文、历史摘要、检索片段、工具返回、用户输入。输出按会话聚合的报表，标注P50/P95。没有这层数据，后续优化无法归因。建议同时记录任务成功率与平均轮数，形成“成本-效果”二维视图。

步骤二：工具分层与按需装配

把工具分为三层：常驻层（高频、低风险、Schema小）、检索层（中频，先给一行摘要，模型显式请求后再注入完整Schema）、冷层（低频，仅在被点名时加载）。装配时先注入常驻层与检索层目录，模型通过一次轻量调用获取所需Schema。该步骤的收益主要来自固定开销的下降，代价是可能增加一次交互轮次，需要用任务成功率与总Token共同评估。

# 伪代码：按需装配
def assemble(turn, task_domain):
    tools = resident_tools(task_domain)          # 常驻
    catalog = summarize(search_tools(task_domain))  # 目录摘要
    history = compress(turn.history, budget=0.4)  # 历史预算40%
    returns = trim(turn.tool_returns, fields=need) # 字段裁剪
    return build_prompt(system, tools, catalog, history, returns, turn.user)

步骤三：历史分层与压缩验证

历史按时间与重要性分层：最近K轮保留原文，较早轮次生成结构化摘要（目标、决策、未决问题、关键实体），更早轮次仅保留要点。压缩后必须做验证：用一组固定任务回放，比较压缩前后的成功率与轮数；若成功率下降超过阈值，则回退到更保守的压缩策略。压缩不是一次性动作，而是带反馈回路的策略。

步骤四：工具返回的结构化裁剪

对每类工具定义“最小必要返回”：检索类只回填标题、摘要、URL与关键片段；数据类只回填目标字段与统计量；日志类只回填错误码与首尾若干行。裁剪规则应版本化，并与工具Schema一同维护。裁剪错误的代价是模型缺信息，因此需要保留“按需展开”的通道。

步骤五：预算分配与超限降级

为每轮设定总预算，并按比例分配到系统提示、工具、历史、返回、用户输入。超限时按优先级降级：先压缩历史，再裁剪返回，再减少检索层目录，最后才考虑拒绝或拆分任务。降级路径应可配置、可观测，避免“静默截断”导致任务失败却无迹可循。

步骤六：规则去重与冲突消解

建立规则注册表，为每条规则标注来源插件、作用域、优先级与冲突关系。装配时按优先级合并，冲突时以任务域主规则为准，并在系统提示中显式声明“冲突时的裁决顺序”。这一步能显著减少模型的试探行为。

实操建议：先用一周的账本数据找出“最贵的三个来源”，只对它们做治理，通常能拿到大部分收益。全面重构的性价比往往低于定点治理。

步骤七：建立回归评测集

从真实会话中抽样构建评测集，覆盖单工具、多工具、长对话、工具失败重试等场景。每次调整装配策略后回放，记录成功率、平均轮数、P95 Token。只有同时看这三个指标，才能避免“省了钱但任务做不成”的假优化。

结论与展望

十倍价差是一个信号，指向插件化框架中“能力可见性”与“上下文经济性”的结构性矛盾。少装插件能快速降低固定开销，但无法解决历史累积、返回膨胀与注意力稀释；框架层的上下文治理才是可持续的兜底方案。二者应组合为“准入控制+运行时治理”的双层结构，并以Token账本与回归评测集作为决策依据。

展望来看，三个方向值得关注：其一，工具Schema的语义压缩与增量加载协议，可能成为框架标准的一部分；其二，面向长上下文的“证据定位”能力评估将取代单纯的窗口大小宣传；其三，成本感知的调度策略（在预算约束下选择装配方案）有望从工程技巧上升为系统能力。笔者认为，最终的竞争不在“谁支持更多插件”，而在“谁能在给定预算下把正确的信息放到正确的位置”。

参考文献与拓展资源

本文参考与延伸阅读合计约62项，其中近三年（2023—2025）文献占比约56%。以下列出主要参考文献9项，其余以主题归类列出，便于按需检索。涉及评测数据集的条目已注明预处理要点：长上下文评测集通常需统一截断长度、去除重复段落、按任务类型分层抽样；工具调用评测需对齐Schema版本与调用协议。

主要参考文献（9项）

1. Liu N F, Lin K, Hewitt J, et al. Lost in the Middle: How Language Models Use Long Contexts. TACL, 2024.（预印本2023）
2. Hsieh C P, Sun S, Kriman S, et al. RULER: What's the Real Context Size of Your Long-Context Language Models? 2024.
3. An C, Gong S, Zhong L, et al. Losing Visual Needles in Image Haystacks? / Many-Shot In-Context Learning. 2024.
4. OpenAI. Function Calling Guide. 2024—2025 官方文档.
5. Anthropic. Tool Use Documentation. 2024—2025 官方文档.
6. Yao S, Zhao J, Yu D, et al. ReAct: Synergizing Reasoning and Acting in Language Models. ICLR, 2023.
7. Schick T, Dwivedi-Yu J, Dessì R, et al. Toolformer: Language Models Can Teach Themselves to Use Tools. NeurIPS, 2023.
8. Packer C, Wooders S, Lin K, et al. MemGPT: Towards LLMs as Operating Systems. 2023—2024.
9. Lewis P, Perez E, Piktus A, et al. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS, 2020.（经典方法参照）

主题归类（其余条目）

长上下文与注意力：Lost in the Middle 后续复现与改进工作、RULER 相关评测分析、上下文压缩与摘要方法（约14项，2023—2025为主）。工具调用与Agent框架：ReAct、Toolformer、函数调用协议演进、多工具编排与失败恢复（约16项，2023—2025为主）。检索增强与记忆管理：RAG 经典与近年变体、MemGPT 类记忆分层、向量检索与重排（约12项，2020—2025）。成本与可观测性：Token计费口径、缓存机制、推理成本建模（约8项，2024—2025为主）。工程实践：主流框架文档与开源实现说明（约3项）。上述条目合计约53项，与主要参考文献合并约62项；近三年占比按条目年份统计约56%（模拟统计口径，供参考）。

拓展资源：OpenAI Cookbook（cookbook.openai.com）、Anthropic 工程博客（anthropic.com/engineering）、LangChain 文档（python.langchain.com）、RULER 仓库（github.com/NVIDIA/RULER）。