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

昨天看到一篇文章 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 场景里，经常会出现：

sh 复制代码

@logs/output.log

如果文件只有 2KB，直接传入上下文问题不大。

但如果是 5MB、10MB 呢？

日志通常有几个特点：

大量重复信息
真正有用的是 error 和 stack trace
结构高度规则

更合理的做法可能是：

判断文件大小
大文件交给子 Agent 处理
提取 error block
聚合重复报错
结构化输出

主 Agent 只看到"处理后的结果"。

而不是把整个文件丢进去，再问一句：

哪里错了？

3️⃣ 命令执行：不要实时倾倒输出

比如：

sh 复制代码

npm run build
eslint .

输出往往非常长。

如果每一行都流入主上下文，很容易：

Token 爆炸
模型注意力被淹没

更合理的方式是：

子 Agent 执行命令
过滤 warning / error
汇总关键信息
必要时并发执行多个命令

主 Agent 只接收"有意义的结果"。

把它抽象一下

如果稍微抽象一点，其实是一个信息流设计问题。

可以简单理解为：

txt 复制代码

User Intent（用户意图）
      ↓
Task Router（任务路由）
      ↓
Sub-Agent / Tool（子代理 / 工具）
      ↓
Preprocess（预处理）
      ↓
Context Injection（上下文注入）
      ↓
Main Agent（主代理）

关键不在于"压缩多少"。

关键在于：

什么信息应该进入主 Agent？
什么信息应该被过滤？
什么信息应该被结构化？
什么信息根本不该出现？

当我们开始这样思考时，"上下文优化"就不再只是摘要算法问题，而是系统设计问题。

一点个人感受

我越来越觉得，大模型应用正在从 Prompt Engineering，走向 Context Engineering。

不是把 prompt 写得多花哨。

而是把信息流设计清楚。

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

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