上下文里到底装了什么
上下文不是聊天记录，而是十来类来源共用同一份预算的分配结果；每一类都要声明来源、信任等级、保留时间和裁剪规则。
上下文不是聊天记录。它是十来类来源共用同一份预算的分配结果，每一类都得说清三件事：从哪来、信到什么程度、什么时候可以裁掉。做不到这一点，你优化的就只是"怎么把句子写得更像人话"，而不是"这次调用凭什么该看到这些"。
上下文不是聊天记录
把上下文当成聊天记录，会直接导出两个错误动作：一是把历史对话和工具结果无选择地持续追加，二是窗口不够了就去换更大的模型。前者制造噪音，后者掩盖问题——两者都会让你在真正的原因旁边反复经过。
从 Prompt 管理升级到 Context 管理，差别就在这里。Prompt 关心"这句话怎么说"，Context 关心"这次调用该看到哪些东西、谁有权覆盖谁、看不到的部分去哪了"。后者是工程问题，需要预算表、生命周期和裁剪日志，不是靠反复调措辞能解决的。
十二类来源，每一类都要有主人
现代 Agent 的上下文至少包括十二类：系统指令、工具定义、用户输入、会话历史、业务状态、检索数据、文件、记忆、中间结果、计划、预算、环境反馈。
对每一类都要声明来源、信任等级、保留时间和裁剪规则。这不是文档工作，而是复盘能力：线上答错一次，你要能回答"它当时看到了什么、哪些被裁掉了、裁剪是谁触发的"。声明不出来的那几类，就是出事时你只能靠猜的地方。
工具定义最容易被低估。一个工具的完整成本是 Schema 常驻 token 加选择推理、参数构造、执行、结果注入，再加上这段历史在后续每一步里被反复携带。接满 MCP Server 之后，光是 Schema 就能吃掉一大截窗口，而且每一步都要付一次。
结构与描述不是装饰
Tau-Bench 上的一组消融实验把这件事量化了。规则内容一个字不动，只打乱组织——去掉标题层次、把有序流程拆成无序的规则集合——任务成功率下降超过 30%，Agent 开始违反关键业务规则："先验证身份再处理退款"这条被拆散后，它就直接退款了。保留函数签名和参数定义、只删掉描述性文本，工具调用错误率上升 45%，表现为传入无效参数值和误解参数含义 ai-agent-book。同一批实验里，把语气换成极度自信的表演型口吻或加满表情符号，对完成率的影响反而有限。
三条一起读：模型扛得住你怎么说话，扛不住你怎么组织。工具描述不是给人看的文档，它是参数正确率的一部分。而省 token 时最先下刀的恰好是结构层次和描述文本——线上最先坏的，也正是这两处。
六层信任分级
信任从高到低是 SYSTEM、ORGANIZATION、APPLICATION、USER、RETRIEVED、EXTERNAL_UNTRUSTED。核心规则只有一句：用户输入不能改变系统权限。它决定了 prompt 组装的冲突消解方式不是"谁写在前面谁赢"，而是"谁的信任等级高谁赢"。
RETRIEVED 和 EXTERNAL_UNTRUSTED 经常被合并，但它们该分开：前者来自你自己管理的知识库，有版本、可追溯；后者来自网页、邮件和工具返回，内容本身就可能是攻击载荷，必须按不可信数据处理，并且带上来源与时间。组织策略只允许管理员发布，项目规则要版本化——否则你无法回答"这次行为变化是哪个规则版本引起的"。
预算要先扣掉输出和工具定义
每次调用前做一次预算预检：模型窗口 − 输出预留 − 工具定义 − 系统与组织规则 − 当前任务目标 = 可分配上下文预算。
最常见的错误是把整个窗口都当成"能塞的历史"。输出预留被吃掉，模型会在写到一半时被截断；工具定义被挤掉，模型就开始调用不存在的工具。收缩时按固定优先级来：调试预览 → 可重新获取的完整数据 → 低相关摘要 → 非直接依赖 → 会话历史 → 工作记忆；任务目标、安全规则、审批状态和当前步骤留到最后。降级后仍超限就返回 CONTEXT_BUDGET_EXCEEDED，不要假装没事。
还有一条硬要求：必须记录被裁剪的上下文类型和数量。没有裁剪日志，模型答错时你分不清是"它没看到"还是"它看到了没用"，只能继续猜。
系统指令不只是占预算，它还极其敏感。Anthropic 的一次线上事故里，system prompt 中加的一句"保持简洁"让两代模型的编码质量各下降 3%，内部测试却没测出来，因为 eval 集覆盖不到受影响的场景。anthropic-postmortem
长上下文不等于有效容量
这是最贵的误解。公开实测里有个常被引用数字：某个模型用满 256K 上下文时精度还能维持在 90% 左右，换到窗口扩到 1M 的新版本，超过 500K 之后精度掉到 36%，价格还更高 redis-semantic-routing。物理容量不等于有效容量。
阿里千问平台把这件事量化得更直接：到第 8 步时，上下文里 70% 是前几步工具调用的原始 JSON、20% 是历史对话、只有 10% 是当前步骤真正用得上的指令。同一个团队花两周评估更大参数的模型，指标没动；做一周上下文管理，指标提升 40%。qwen-harness
代价是实打实的工程投入：外置存储、裁剪逻辑、裁剪日志、按来源统计 token。短任务和单步任务不值得上这套。你的检查方法很简单——dump 一次第 8 步的 prompt，数一数其中当前步骤真正用得上的内容占多少；如果不到三成，先管上下文，再谈换模型。这份 70/20/10 的噪音如何随步骤自我恶化，上下文是怎么一步步变脏的 有完整分析。