昨天看到一篇文章 Context Mode：为你的AI开发工具节省98%的上下文token，里面有一些观点挺有意思。
在构建 Agent 的时候，“Context”几乎是绕不过去的一关。 随着对话增加，上下文不断变长，带来的问题也越来越明显：
- 响应速度变慢
- Token 消耗显著增加
- 有时候模型开始“答非所问”
过去大家的优化思路其实比较统一：
- 不把全文塞进去，而是用 RAG 检索相关片段
- 动态裁剪无关信息
- 滑动窗口只保留最近几轮
- 用小模型做摘要压缩
这些思路都没问题。
但我最近在想一个问题：
我们是不是默认“所有信息都应该进上下文”，然后再想办法压缩它？
会不会一开始方向就有点偏？
上下文变长，到底影响什么？
很多人只看到 Token 成本。
但其实问题不只是“贵”。
从模型结构来看，Transformer 的 attention 计算复杂度是 O(n²)。 上下文越长，计算量越大，推理延迟自然上升。
更关键的是：
模型并不会因为上下文变长而更聪明。
很多时候：
- 无关内容会干扰推理路径
- 冗余信息会分散注意力
- 太多历史对话会降低当前问题的权重
这其实是一个“信噪比”的问题，而不是简单的压缩问题。
回到写代码的场景
如果我们从工程实践来看，现在很多 AI CLI 工具，日常会用到三类能力：
- 搜索网页（贴链接或关键词）
- 引入文件（比如
@src/main.ts） - 执行命令（eslint、build、test 等）
这三种行为有个共同点：
都会产生大量原始数据，而且大部分是冗余的。
问题来了：
我们真的需要把这些原始数据，原封不动丢给主 Agent 吗？
1️⃣ 搜索网页：我们真的需要整页 HTML 吗？
当我们“让 AI 读网页”时，本质上是：
- 抓取 HTML
- 把页面内容交给模型
但 HTML 里面包含：
- 各种结构标签
- CSS / style
- 导航栏
- 页脚
- 重复内容
而用户真正关心的，可能只是：
这个文档里 xxx 的用法是什么？
那我们真正需要的，其实是：
- 和问题相关的段落
- 对应代码示例
- 可能的注意事项
而不是整页页面。
所以我的想法是：
针对“搜索网页”这个行为，应该内置一个子 Agent，专门负责：
- 抓取网页
- 清洗 DOM
- 结合用户问题筛选内容
- 再把精简后的结果传给主 Agent
而不是直接把 HTML 当作知识。
2️⃣ 日志文件：不要让模型读完 10MB 才发现报错
CLI 场景里，经常会出现：
@logs/output.log
如果文件只有 2KB，直接传入上下文问题不大。
但如果是 5MB、10MB 呢？
日志通常有几个特点：
- 大量重复信息
- 真正有用的是 error 和 stack trace
- 结构高度规则
更合理的做法可能是：
- 判断文件大小
- 大文件交给子 Agent 处理
- 提取 error block
- 聚合重复报错
- 结构化输出
主 Agent 只看到“处理后的结果”。
而不是把整个文件丢进去，再问一句：
哪里错了？
3️⃣ 命令执行：不要实时倾倒输出
比如：
npm run build
eslint .
输出往往非常长。
如果每一行都流入主上下文，很容易：
- Token 爆炸
- 模型注意力被淹没
更合理的方式是：
- 子 Agent 执行命令
- 过滤 warning / error
- 汇总关键信息
- 必要时并发执行多个命令
主 Agent 只接收“有意义的结果”。
把它抽象一下
如果稍微抽象一点，其实是一个信息流设计问题。
可以简单理解为：
User Intent（用户意图）
↓
Task Router（任务路由）
↓
Sub-Agent / Tool（子代理 / 工具）
↓
Preprocess（预处理）
↓
Context Injection（上下文注入）
↓
Main Agent（主代理）
关键不在于“压缩多少”。
关键在于：
- 什么信息应该进入主 Agent？
- 什么信息应该被过滤？
- 什么信息应该被结构化？
- 什么信息根本不该出现？
当我们开始这样思考时，“上下文优化”就不再只是摘要算法问题，而是系统设计问题。
一点个人感受
我越来越觉得，大模型应用正在从 Prompt Engineering，走向 Context Engineering。
不是把 prompt 写得多花哨。
而是把信息流设计清楚。
Context 不是压缩出来的，是设计出来的。
以上只是自己的一点思考，抛砖引玉。如果你有更好的做法或者踩过坑，也欢迎交流。
