一个来自实践的 Context Engineering 思路：并行调度 + 层级压缩
做了一段时间的 Agent 开发，最头疼的不仅仅是怎么让 LLM 理解任务，还有怎么喂 context。
任务稍微复杂一点，context 要么太多撑爆窗口，要么裁剪过度让 subagent 变傻。今天分享一下我在实践中摸索出来的一套思路，本质上是把 Hierarchical Map-Reduce 的思维方式带进 Agent 设计。
整体思路
- Map：主 agent 把复杂任务拆成多个独立子任务，并行分发给 subagent，每个 subagent 只拿自己需要的 context
- Reduce：subagent 完成后，主 agent 聚合结果
听起来简单，但实践中有几个细节值得说清楚。
一、并行分发：不是所有任务都能并行
前提：任务之间必须真的独立
独立性的判断标准：
- 无共享写目标（不会同时写同一个文件 / DB 表）
- 无执行顺序依赖（A 的结果不是 B 的输入）
在我做的场景里，任务边界比较清晰，主 agent 能稳定识别独立性。但如果业务逻辑复杂，这里是最容易出错的地方——判断错了，并行会直接产生冲突结果。
Context 要裁剪，不要全量 dump
每个 subagent 只拿它需要的 context，而非把主 agent 的全部上下文塞进去。全量 dump 会让 subagent 注意力分散，也是对 token 的浪费。
结果聚合策略要显式定义
并行结束后，主 agent 怎么合并结果？两种情况：
- 输出互不重叠：直接拼接
- 输出有重叠/需要综合：让主 agent 或专门的聚合 agent 做一次摘要归并
二、Context 分发：Push 还是 Pull？
多个 subagent 都需要的通用信息，由主 agent 负责分发。但怎么分发，要看信息体积：
| 模式 | 描述 | 适用场景 |
|---|---|---|
| Push | 主 agent 直接写入每个 subagent 的 context | 共享信息体积小，主 agent 窗口够用 |
| Pull / Hybrid | 共享信息存入外部 store，subagent 按需取；或主 agent 只分发"索引"，subagent 自行拉取详情 | 共享信息体积大，或主 agent 窗口紧张 |
原则很简单：主 agent 窗口够就 Push；不够就把共享信息外置，让 subagent 自己去取。
三、层级压缩：当一个 subagent 装不下时
这是我觉得最有意思的部分。
场景：subagent-LV1 在执行前做了一次 discovery，发现需要读取的信息量远超自己的上下文窗口。
解法：不硬塞，向下再开一层——启动多个 subagent-LV2，并行获取信息、局部总结，再把压缩后的结果返回给 LV1：
主 agent
└── subagent-LV1（任务执行）
├── subagent-LV2（并行获取 + 总结 A）
├── subagent-LV2（并行获取 + 总结 B）
└── subagent-LV2（并行获取 + 总结 C）
↓ 压缩摘要返回 LV1
LV1 拿到的是压缩后的摘要，而不是原始全量信息，从而把任务装进窗口。
几个实践细节：
触发时机要有信号，不能靠感觉
在 discovery 阶段估算数据源的 token 规模，超过阈值（比如窗口的 80%）时触发。不要等真正溢出了才处理。
先算压缩比，再决定要不要用
LV2 总结必然有损。如果内容本身不可压缩（需要精确还原的代码、关键数值、特定标识符），总结前后token数几乎没有变化，这个机制就没有意义。
需要在 discovery 阶段同时估算压缩比：预期压缩后保留的有效信息低于某个阈值，就不用分层压缩，改为外置 store + Pull 方案。
最深 2 层
超过 LV1 → LV2 两层后，调度开销和错误传播都会变得难以控制。如果 2 层还不够，说明信息体量已超出 in-context 方案的适用范围，应该换用外部 store。
关注成本
每增加一层，token 消耗倍增。如果不是按次计费的模型（如Github Copilot、Coding Plan 等）需要预先算好"开多少层合算"。
什么时候不值得并行？
并行本身有开销：任务拆分、context 裁剪、结果聚合，都需要额外调用。几个判断参考：
- 子任务数 ≤ 2 且耗时差不多 → 串行更简单
- 子任务之间存在任何写目标重叠 → 重新设计，不要强行并行
- 任务本身很轻量（单次 API 调用级别）→ 调度开销可能超过并行收益
总结
用一句话概括这套思路：
主 agent 负责调度和聚合，subagent 负责执行；context 按需裁剪、按需分发；信息量超窗口时，用层级压缩代替硬溢出。
大任务 → 拆解 → 并行执行 → 压缩聚合，Map-Reduce 的思路在 Agent 里同样好用。
