第 9 篇｜如何解决系统上下文爆炸问题：从 Prompt 管理到 Context Orchestrator

在前几篇里，我们已经逐步搭建起了 Harness 的核心框架：

用 Code Graph 让 AI 理解代码
用 Flow Graph 让 AI 理解系统
用 Constraint Engine 避免错误
用 Risk Engine 提前识别风险

但当很多团队真正把 AI 用进复杂项目后，很快会遇到一个新的瓶颈：

上下文爆炸（Context Explosion）

它不是偶发问题，而是 AI Coding 走向企业落地时，迟早会碰到的一堵墙。

这一篇，我们专门讲清楚：

系统上下文为什么会爆？以及企业里该怎么真正解决。

一、为什么上下文一定会爆？

很多团队第一次遇到这个问题时，直觉是：

“是不是模型上下文不够大？”

比如：

128k
200k
甚至更大的窗口

看起来已经很大。

但问题是：

上下文爆炸，本质不是窗口不够，而是“记忆管理方式错误”。

一个真实的工程场景

当 AI 参与一个真实需求时，上下文会自然增长：

需求说明
↓
读取代码
↓
分析调用链
↓
讨论方案
↓
修改代码
↓
补充约束
↓
回滚重试
↓
再次修改

最后你会发现：

每一轮对话都在把新信息继续往上下文里堆。

结果就是：

Token 越来越多
注意力越来越分散
推理越来越不稳定

二、真正的问题：把“系统认知”塞进了“聊天窗口”

很多团队默认认为：

上下文 = 记忆

于是会把：

项目说明
架构文档
业务规则
会话历史
代码片段

全部塞进 prompt。

但实际上：

上下文不是仓库，而是工作记忆。

就像人脑一样：

你不会在解决一个问题时，把整个职业生涯都同时想一遍。

三、正确思路：记忆分层

解决这个问题的第一步，是把上下文拆成不同层次。

1️⃣ Working Memory（工作记忆）

只保留当前任务最小信息：

当前需求
当前代码
当前决策

👉 这是本轮推理真正需要的东西

2️⃣ Structural Memory（结构记忆）

由系统保存：

Code Graph
Flow Graph
Registry

👉 不常驻，只在需要时检索

3️⃣ Semantic Memory（语义记忆）

长期知识：

constraints
incidents
隐性约定

👉 只按需加载

4️⃣ Episodic Memory（会话记忆）

保存：

关键决策
被否决方案
本轮状态

👉 不是保留整段聊天

四、方案一：按需加载，替代“全量记忆”

这是最基础，也最有效的方法。

核心原则

不要把信息放进上下文，除非它当前真的需要。

实现方式

在 CLAUDE.md 中明确：

涉及 API → 读取 api-registry
涉及数据库 → 读取 db-schema
涉及核心业务 → 读取 constraints

再通过：

code-map
flow-graph
skill 调度

动态检索。

实战经验

在一个：

5万行代码
200k context window

的项目里：

memory-file 仅占 5%

这完全正常。

因为：

好的系统不是用满上下文，而是精准使用上下文。

五、方案二：把一个需求拆成多个上下文

很多上下文爆炸，来自一个误区：

想让 AI 一次完成整个需求

但复杂需求应该拆成多个阶段：

需求分析
↓
影响范围分析
↓
方案设计
↓
代码修改
↓
测试验证

每个阶段：

独立上下文
独立输入
独立输出

好处

AI 每次只处理一件事：

推理质量会明显提升

六、方案三：用多 Agent 隔离上下文

当项目继续变大时，仅靠拆步骤还不够。

需要进一步：

按职责拆分上下文

示例

主 Agent（Planner）

负责：

理解需求
拆任务
汇总结果

开发 Agent

只看：

代码
约束

测试 Agent

只看：

flow
测试场景

Review Agent

只看：

diff
risk
incidents

本质

不是让一个模型记住一切，而是：

让不同 Agent 各自只记住自己该记住的事。

七、方案四：按领域拆分知识

当系统进一步复杂后，还会遇到新的问题：

即使检索，也会召回太多信息

于是需要：

领域级上下文隔离

做法

增加一个：

👉 Domain Agent

它先判断：

这个需求属于：
- 订单
- 库存
- 支付

然后只加载对应领域知识。

这样做的意义

避免：

订单需求加载营销系统上下文支付需求加载会员系统规则

八、最容易踩的三个坑

❌ 坑一：把大上下文当优势

很多团队误以为：

“200k 就应该用满”

实际上：

上下文越多，模型越容易失焦。

❌ 坑二：把聊天记录直接继承

结果：

信息重复
噪音累积
推理变差

❌ 坑三：只做摘要，不做状态管理

很多人会让 AI：

“帮我总结一下刚才对话”

但真正需要的是：

{
  "goal": "",
  "decisions": [],
  "constraints": []
}

👉 不是摘要，而是状态。

九、真正的解决方案：Context Orchestrator

走到最后，你会发现：

真正需要的不是：

更大的上下文

而是：

👉 Context Orchestrator（上下文编排器）

它负责：

判断当前任务类型
选择需要的知识
控制 token 预算
动态构建 prompt

让上下文从：

“不断累积”

变成：

“每轮重新构建”

十、一句话总结

这篇文章最重要的一句话是：

上下文爆炸的根本原因，是把“系统认知”错误地塞进“单轮对话”；真正的解决方案，是把认知外部化，让上下文只承载当前推理。

结尾

很多团队在 AI Coding 上卡住，不是因为模型不够强，而是因为：

还在用 Chat 模式，做系统工程。

而企业级 Harness 的本质，是让 AI 从：

“记住很多”

升级到：

“只在正确的时候知道正确的信息”

下一篇，我们继续深入：

👉 如何设计 Context Orchestrator，让上下文真正变成系统能力，而不是 Prompt 技巧。

一、为什么上下文一定会爆？

一个真实的工程场景​

二、真正的问题：把“系统认知”塞进了“聊天窗口”

三、正确思路：记忆分层

1️⃣ Working Memory（工作记忆）​

2️⃣ Structural Memory（结构记忆）​

3️⃣ Semantic Memory（语义记忆）​

4️⃣ Episodic Memory（会话记忆）​

四、方案一：按需加载，替代“全量记忆”

核心原则​

实现方式​

实战经验​