Context 不是压缩出来的，而是设计出来的

昨天看到一篇文章 Context Mode：为你的AI开发工具节省98%的上下文token，里面有一些观点挺有意思。

在构建 Agent 的时候，“Context”几乎是绕不过去的一关。 随着对话增加，上下文不断变长，带来的问题也越来越明显：

• 响应速度变慢
• Token 消耗显著增加
• 有时候模型开始“答非所问”

过去大家的优化思路其实比较统一：

1. 不把全文塞进去，而是用 RAG 检索相关片段
2. 动态裁剪无关信息
3. 滑动窗口只保留最近几轮
4. 用小模型做摘要压缩

这些思路都没问题。

但我最近在想一个问题：

会不会一开始方向就有点偏？

上下文变长，到底影响什么？

很多人只看到 Token 成本。

但其实问题不只是“贵”。

从模型结构来看，Transformer 的 attention 计算复杂度是 O(n²)。 上下文越长，计算量越大，推理延迟自然上升。

更关键的是：

模型并不会因为上下文变长而更聪明。

很多时候：

• 无关内容会干扰推理路径
• 冗余信息会分散注意力
• 太多历史对话会降低当前问题的权重

这其实是一个“信噪比”的问题，而不是简单的压缩问题。

回到写代码的场景

如果我们从工程实践来看，现在很多 AI CLI 工具，日常会用到三类能力：

1. 搜索网页（贴链接或关键词）
2. 引入文件（比如 @src/main.ts）
3. 执行命令（eslint、build、test 等）

这三种行为有个共同点：

问题来了：

我们真的需要把这些原始数据，原封不动丢给主 Agent 吗？

1️⃣ 搜索网页：我们真的需要整页 HTML 吗？

当我们“让 AI 读网页”时，本质上是：

• 抓取 HTML
• 把页面内容交给模型

但 HTML 里面包含：

• 各种结构标签
• CSS / style
• 导航栏
• 页脚
• 重复内容

而用户真正关心的，可能只是：

那我们真正需要的，其实是：

• 和问题相关的段落
• 对应代码示例
• 可能的注意事项

而不是整页页面。

所以我的想法是：

针对“搜索网页”这个行为，应该内置一个子 Agent，专门负责：

1. 抓取网页
2. 清洗 DOM
3. 结合用户问题筛选内容
4. 再把精简后的结果传给主 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 不是压缩出来的，是设计出来的。

以上只是自己的一点思考，抛砖引玉。如果你有更好的做法或者踩过坑，也欢迎交流。