---
{
  "series": "Harness工程研究：让AI Agent好用的工程实践",
  "article_index": 2,
  "topic": "Context是稀缺资源：每个token都有隐藏成本",
  "created": "2026-04-25",
  "deai_score": 92.0,
  "pipeline": "series"
}
---

随着模型厂商将 Context Window 推向 128K 甚至 1M，一种极其危险的开发习惯正在蔓延：将原始日志、长篇文档和冗余对话全部塞进 Prompt。这种操作背后隐含着一个虚假的前提：物理窗口只要放得下，模型的逻辑推理就能自动对标。

在上一篇《Harness比模型重要》中，我们讨论了运行环境的精细化治理为什么比换模型更重要。Context 管理是 Harness 中最容易被低估的一环。

在 Transformer 架构下，长上下文对模型注意力有稀释效应。输入的每一枚 Token 都在摊薄模型的注意力。一旦 Context 超过特定规模，模型对关键指令的遵循能力会发生衰减。如果研发团队内部连一份统一的项目规范都没有，讨论模型的逻辑上限是对时间的浪费。杂乱的上下文会增加推理延迟并引入干扰噪声。

## 注意力衰减的物理边界

Transformer 处理信息的效率与 Token 间的两两关系计算深度绑定。即便现在的线性注意力机制在学术上不断突破，实际生产中的注意力和性能曲线依旧显示出明显的非线性特征。Anthropic 的实验数据显示，模型在 75K token 以内的区域通常处于性能最佳区间。在这个区间，模型对细节的捕获最可靠。

越过这个阈值，幻觉随之增加，逻辑开始断裂。目前很多 AI 项目高度依赖运气。我们在做 Demo 时往往会为长上下文带来的某种随机性感到惊喜，但在生产环境中，这种随机性即是风险。给模型喂 10 万行冗余代码只为了改一个函数接口，会导致方案受到上下文中过时逻辑的干扰。

注意力稀释是物理事实。单纯在 Prompt 里增加"请务必关注"等强调词无法校准性能。这种做法实际上是用更多的冗余 Token 去对抗冗余，反而导致困惑度升高。如果无法在 75K 区间内解决问题，盲目扩张到 200K 通常不会带来质变。

当一个项目涉及跨模块逻辑重构时，开发者习惯于把整个代码库的索引抛给模型。结果往往是，模型在处理文档中间位置的类定义时，开始忽略开头的全局约束条件。模型的注意力被那些无关紧要的注释和模板代码摊平了。

对抗这种性能下降的关键在于通过外部手段维持上下文的高信息密度。高质量的上下文应当是经过提炼的原子化事实。如果我们允许冗余信息无限制地占据窗口，本质上是在逼迫模型在推理的同时进行高强度的信息降噪。

## Token 经济学

在生成式 AI 的商业逻辑里，Token 管理是极其敏感的经济杠杆。Agent 的输入与输出比例通常达到 100:1。由于预填充输入与推理输出的资源消耗并不对称，优化 KV-cache 的命中率是节约成本的关键。

KV-cache 命中率高度依赖 Prompt 的稳定性。在每轮对话中大幅重写 Prompt 前缀会直接导致缓存机制失效，意味着开发者在为每一轮重复计算支付全额费用。成熟的工程做法是采用追加模式，即只在末尾增加新信息，保持前缀高度一致。这种一致性不仅是技术实现的需要，更是为了维持推理逻辑的连续性。

Context 管理存在明显的杠杆效应。人类在规划阶段多投入一小时，能减少后续数十倍的 Token 浪费。早期的意图偏差如果没被定义清楚，在后续的 Agent 自循环中，每一轮产生的错误逻辑和纠错日志都会快速填充上下文。

逻辑失误产生的 Token 消耗，往往比正常执行任务高出 10 倍以上。在实际应用场景中，我们经常看到一个 Agent 因为一个初始的错误命令，反复生成上万个 Token 的废话来试图解释逻辑漏洞。

我们需要对 Token 的生命周期进行精细化核算。如果一个工程链路的单位产出需要消耗数十万个输入 Token，那么这个架构在商业化层面就是脆弱的。减少浪费的首要步骤是识别那些"死 Token"，也就是对当前决策没有正向增量的历史记录。

许多开发者误以为保留所有原始对话能增加模型的上下文意识。模型不需要历史的全部，它只需要能代表当前状态的最简路径。过多的历史细节反而会让模型迷失在过去的错误尝试中，产生路径依赖。

## 为系统引入背压机制

依靠模型自我管理上下文是危险的。即使是最先进的模型，在面对几万行混合了报错日志、历史对话和代码片段的混沌信息时，也很难自主决定哪些应当截断。这种决策责任必须回归到治理层（Harness），通过确定性的逻辑接管 Context 的生命周期。

背压（Backpressure）机制在网络协议中用于防止接收端被淹没。AI 工程同样需要这种拦截器。当检测到上下文触碰性能衰减边界时，应当强制触发压缩或截断逻辑。如果模型在一个固定步数内无法收敛出结果，应当通过重置状态机来终止，而不该通过增加 Context 来补救。

渐进式披露是应对上下文质量下降的有效手段。在大模型运行期间，应当让它维持在最小高信号 Token 集合中。例如在一些自动化编程工具实践里，每当阶段性任务完成，系统会立刻将关键成果写回持久化的项目文件，然后清空当前的 Context，重新开启一条干净的会话路径。

良好的治理层应当实现自动化的历史压缩：保留逻辑锚点，剔除无用的执行细节，将模型锁在推理性能最优的区间内。

在具体的实现层面，可以采用结构化萃取技术。当 Context Window 接近预警线，治理层应当暂停推理流程，调用一个较低成本的模型对已有历史进行提炼，只保留关键参数、已达成的进展和残留的问题。这种做法虽然增加了单次处理的复杂性，但在长程任务中，它能保证模型始终处于清醒状态。

引入外部存储来分担上下文压力也是必然选择。与其指望模型在 100K 的内容中寻找答案，不如将其转化为高精准度的检索增强生成（RAG），通过硬性的约束，强迫系统在进入模型层之前先进行一次质量过滤。

## 知识与噪声的界限

开发者常犯的错误是将 Context 当成数据库使用。这种做法混淆了长期记忆和短期工作区的职能。数据库擅长索引和存储海量原始数据，而模型的上下文应当是瞬时的、高频交换的推理草稿纸。

高性能的 Agent 框架对输入的 Token 极度吝啬。它们不会在每个请求中都带入完整的 system prompt，而是根据当前任务的类型动态挂接最相关的指令片段。这种动态挂接能有效降低模型的认知负荷。

目前许多人把"能读长文本"等同于"能理解复杂逻辑"。这是两回事。模型扫描一遍文档并回答问题，与模型在长达数万行的上下文背景下进行多步推理，两者的难度差异在实践中被严重低估了。

## 精确规划的杠杆

在自动化系统的设计中，确定性是稀缺资源。如果你给 Agent 的初始指令是模糊的，它就会生成大量探索式的对话。每一轮探索都在向上下文里添加没用的信息，后期真正需要高难度决策时，可用的高质量注意力资源已经所剩无几。

如果开发者能多花一个小时将任务分解成微小的、自包含的子任务，并在每个子任务完成后清零上下文，那么整个系统的鲁棒性将远高于一个试图在长上下文中"一站式解决"的方案。

我们需要建立一套度量标准，量化每一枚 Token 对于最终目标的贡献。如果发现某个环节的增益 Token 占比过低，那就是流程冗余的警示信号。在成熟的软件工程中，代码量从不代表生产力；在 AI 应用中，Prompt 的长度和上下文的厚度通常是架构设计失败的标志。

这里有一个尚未解决的技术问题：保留多少比例的失败决策轨迹能让模型学会有效反省，而不至于被噪声带偏？在必须追加历史以提高缓存命中率，与必须重写压缩以维持推理质量之间，是否存在一个数学上的平衡点？目前我们对这个问题的回答还处于经验积累阶段。

Context 管理解决了输入端的纯净度问题，然而，拥有高质量输入的模型依然可能在推理路径上跑偏。这就是为什么我们必须引入物理级的限制。下一篇《约束让Agent更好用》将探讨如何用确定性的机械约束收窄解空间。