做 Agent 时我是怎么处理 Context 的一个来自实践的 Context Engineering 思路并行调度 层级压缩这个是5月份写的文章忘了发在这里了。补发一下做了一段时间的 Agent 开发最头疼的不仅仅是怎么让 LLM 理解任务还有怎么喂 context。任务稍微复杂一点context 要么太多撑爆窗口要么裁剪过度让 subagent 变傻。今天分享一下我在实践中摸索出来的一套思路本质上是把Hierarchical Map-Reduce的思维方式带进 Agent 设计。整体思路Map主 agent 把复杂任务拆成多个独立子任务并行分发给 subagent每个 subagent 只拿自己需要的 contextReducesubagent 完成后主 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共享信息存入外部 storesubagent 按需取或主 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 ↓ 压缩摘要返回 LV1LV1 拿到的是压缩后的摘要而不是原始全量信息从而把任务装进窗口。几个实践细节触发时机要有信号不能靠感觉在 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 里同样好用。延伸阅读[[03 Knowledge/AI/Agent 架构/Agent构成要素-执行路径评估]]如何评估 agent 的执行是否符合预期流程 做 Agent 时，我是怎么处理 Context 的
做 Agent 时我是怎么处理 Context 的一个来自实践的 Context Engineering 思路并行调度 层级压缩这个是5月份写的文章忘了发在这里了。补发一下做了一段时间的 Agent 开发最头疼的不仅仅是怎么让 LLM 理解任务还有怎么喂 context。任务稍微复杂一点context 要么太多撑爆窗口要么裁剪过度让 subagent 变傻。今天分享一下我在实践中摸索出来的一套思路本质上是把Hierarchical Map-Reduce的思维方式带进 Agent 设计。整体思路Map主 agent 把复杂任务拆成多个独立子任务并行分发给 subagent每个 subagent 只拿自己需要的 contextReducesubagent 完成后主 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共享信息存入外部 storesubagent 按需取或主 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 ↓ 压缩摘要返回 LV1LV1 拿到的是压缩后的摘要而不是原始全量信息从而把任务装进窗口。几个实践细节触发时机要有信号不能靠感觉在 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 里同样好用。延伸阅读[[03 Knowledge/AI/Agent 架构/Agent构成要素-执行路径评估]]如何评估 agent 的执行是否符合预期流程