11.6 多智能体协作的上下文管理

面向经管学生、研究者与从业者的 AI 智能体设计教材

作者

李学恒、林建浩、严翊歆

发布于

2026-05-11

本节讨论上下文工程原则在多智能体协作中的具体用法。

保护主代理的上下文

在多智能体系统中，主代理或 Lead 的上下文最为珍贵。它需要掌握整体任务目标、跟踪各子任务进度，并协调不同智能体的工作。因此，子代理和队友的完整工作结果不应直接返回给主代理。

反面做法

▶ Claude Code

请分析这份财报，然后把完整的分析报告返回给我。

子代理完成后返回 3000 字的分析报告，全部进入主代理的上下文。

推荐做法

▶ Claude Code

请分析这份财报。
将完整的分析报告保存到 output/analysis-report.md。
完成后，返回一句话摘要说明分析结论和保存位置。

子代理完成后只返回一行文字，主代理的上下文消耗极小。

输出压缩策略

不同类型的子任务需要不同的压缩策略：

任务类型	压缩方式	示例
数据分析	保存到文件，返回关键指标	“ROE 15.2%，同比+2.1%，报告已保存”
代码生成	直接写入文件，返回文件路径	“已生成 3 个模块，保存到 src/”
文档评审	保存详细评审意见到文件，返回评审结论	“发现 2 个高优先级问题，详见 review.md”
信息检索	保存检索结果到文件，返回摘要	“找到 5 篇相关研究，已整理到 refs.md”

一个基本做法是：完整内容进文件，摘要进上下文。

通过 CLAUDE.md 维护一致性

在多智能体协作中，所有智能体共享同一个项目目录，因此都会自动加载项目的 CLAUDE.md。这是一种成本较低的一致性机制。

适合放入 CLAUDE.md 的内容：

术语标准（如”Agent → 智能体”）
输出文件的命名规范和存储路径
代码风格和格式要求
团队协作的基本规则

不适合放入 CLAUDE.md 的内容：

具体任务的详细说明（应在创建时通过 prompt 传入）
频繁变化的配置项
某个特定智能体才需要的专业知识

CLAUDE.md 的内容会被每个智能体加载，因此它本身也会占用上下文空间。文件应尽量简洁，避免放入冗余信息。

文件系统作为共享存储

在子代理和 Agent Teams 中，文件系统都是共享信息的主要通道。它的优势在于信息先留在文件里，需要时再读取，不会长期占用上下文窗口。

使用文件共享的实践规则

明确文件归属：每个文件只由一个智能体写入，避免写入冲突
约定目录结构：在任务分配时明确每个智能体的输入/输出目录
使用标准格式：JSON 用于结构化数据，Markdown 用于报告类内容

▶ Claude Code

你负责的工作目录是 output/compliance/。
输入数据在 data/report-2024.csv。
请将审查结果保存到 output/compliance/review.md，
发现的问题清单保存到 output/compliance/issues.json。

Plan Approval 的上下文价值

Agent Teams 的 Plan Approval 机制既是质量控制手段，也是一种上下文管理策略。

当队友在计划模式下工作时，它只进行读取和分析操作，不会修改任何文件。如果 Lead 发现队友的方向不对，可以在计划阶段就纠正，避免浪费执行阶段的上下文和资源。

没有 Plan Approval：
队友执行 → 发现方向错误 → 回滚修改 → 重新执行
（上下文消耗：2 倍）

有 Plan Approval：
队友规划 → Lead 发现方向错误 → 反馈修改 → 队友调整计划 → 执行
（上下文消耗：1 倍 + 少量计划开销）

Plan Approval 特别适用于高风险操作，比如批量修改生产代码、处理敏感数据。在执行前增加一道审核，可以减少代价高昂的返工。

辩论式协作的上下文考量

辩论式协作是 Agent Teams 的一种典型用法。两个队友从不同角度分析同一个问题，互相质疑和补充，可以减少分析盲区，但每轮交流都会消耗双方的上下文空间。

不要让队友无限制地辩论。在任务描述中设定明确的边界：

▶ Claude Code

队友 A（分析师）和队友 B（批评者）：
请就这家公司的估值合理性展开讨论。
规则：
- 每人最多发言 3 轮
- 每轮发言不超过 200 字
- 第 3 轮必须给出各自的最终结论
- 将讨论记录保存到 output/valuation-debate.md

设定轮次和字数限制，可以避免辩论占用过多上下文空间，同时保留关键观点。

实战案例：金融研报多维度评审

一份金融研报需要从合规性、数据准确性和投资逻辑三个维度进行评审。使用 Agent Teams 可以让三个队友并行评审，并在发现交叉问题时直接沟通。

▶ Claude Code

请创建一个团队评审这份研报 data/research-report.pdf。

队友 A（合规审查员）：
- 检查信息披露是否符合规范
- 核实风险提示是否完整
- 审查利益冲突声明

队友 B（数据审查员）：
- 验证财务数据的准确性
- 检查计算过程是否有误
- 核实数据来源的时效性

队友 C（投资逻辑审查员）：
- 评估分析框架的合理性
- 检查论证是否有逻辑漏洞
- 评价投资建议是否被数据支持

每位队友将审查结果保存到 output/review/ 目录：
- compliance-review.md
- data-review.md
- logic-review.md

如果发现跨维度问题，直接与相关队友沟通确认。
最终由 Lead 综合三份审查报告生成评审总结。

上下文管理要点

每个队友只关注自己的审查维度，上下文不被其他维度的细节污染。发现交叉问题时通过私信沟通，而非广播。完整评审意见保存到文件，Lead 只需读取三份审查报告的关键结论。

--- title: "11.6 多智能体协作的上下文管理" --- ![11.6 配图](images/img_06_context_management.png) 本节讨论上下文工程原则在多智能体协作中的具体用法。 ### 保护主代理的上下文在多智能体系统中，主代理或 Lead 的上下文最为珍贵。它需要掌握整体任务目标、跟踪各子任务进度，并协调不同智能体的工作。因此，子代理和队友的完整工作结果不应直接返回给主代理。 **反面做法** ```opencode 请分析这份财报，然后把完整的分析报告返回给我。 ``` 子代理完成后返回 3000 字的分析报告，全部进入主代理的上下文。 **推荐做法** ```opencode 请分析这份财报。将完整的分析报告保存到 output/analysis-report.md。完成后，返回一句话摘要说明分析结论和保存位置。 ``` 子代理完成后只返回一行文字，主代理的上下文消耗极小。 ### 输出压缩策略不同类型的子任务需要不同的压缩策略： | 任务类型 | 压缩方式 | 示例 | |:---|:---|:---| | 数据分析 | 保存到文件，返回关键指标 | "ROE 15.2%，同比+2.1%，报告已保存" | | 代码生成 | 直接写入文件，返回文件路径 | "已生成 3 个模块，保存到 src/" | | 文档评审 | 保存详细评审意见到文件，返回评审结论 | "发现 2 个高优先级问题，详见 review.md" | | 信息检索 | 保存检索结果到文件，返回摘要 | "找到 5 篇相关研究，已整理到 refs.md" | 一个基本做法是：完整内容进文件，摘要进上下文。 ### 通过 CLAUDE.md 维护一致性在多智能体协作中，所有智能体共享同一个项目目录，因此都会自动加载项目的 `CLAUDE.md`。这是一种成本较低的一致性机制。 **适合放入 CLAUDE.md 的内容**： - 术语标准（如"Agent → 智能体"） - 输出文件的命名规范和存储路径 - 代码风格和格式要求 - 团队协作的基本规则 **不适合放入 CLAUDE.md 的内容**： - 具体任务的详细说明（应在创建时通过 prompt 传入） - 频繁变化的配置项 - 某个特定智能体才需要的专业知识 `CLAUDE.md` 的内容会被每个智能体加载，因此它本身也会占用上下文空间。文件应尽量简洁，避免放入冗余信息。 ### 文件系统作为共享存储在子代理和 Agent Teams 中，文件系统都是共享信息的主要通道。它的优势在于信息先留在文件里，需要时再读取，不会长期占用上下文窗口。 **使用文件共享的实践规则** - **明确文件归属**：每个文件只由一个智能体写入，避免写入冲突 - **约定目录结构**：在任务分配时明确每个智能体的输入/输出目录 - **使用标准格式**：JSON 用于结构化数据，Markdown 用于报告类内容 ```opencode 你负责的工作目录是 output/compliance/。输入数据在 data/report-2024.csv。请将审查结果保存到 output/compliance/review.md，发现的问题清单保存到 output/compliance/issues.json。 ``` ### Plan Approval 的上下文价值 Agent Teams 的 Plan Approval 机制既是质量控制手段，也是一种上下文管理策略。当队友在计划模式下工作时，它只进行读取和分析操作，不会修改任何文件。如果 Lead 发现队友的方向不对，可以在计划阶段就纠正，避免浪费执行阶段的上下文和资源。 ```txt 没有 Plan Approval：队友执行 → 发现方向错误 → 回滚修改 → 重新执行（上下文消耗：2 倍）有 Plan Approval：队友规划 → Lead 发现方向错误 → 反馈修改 → 队友调整计划 → 执行（上下文消耗：1 倍 + 少量计划开销） ``` Plan Approval 特别适用于高风险操作，比如批量修改生产代码、处理敏感数据。在执行前增加一道审核，可以减少代价高昂的返工。 ### 辩论式协作的上下文考量辩论式协作是 Agent Teams 的一种典型用法。两个队友从不同角度分析同一个问题，互相质疑和补充，可以减少分析盲区，但每轮交流都会消耗双方的上下文空间。不要让队友无限制地辩论。在任务描述中设定明确的边界： ```opencode 队友 A（分析师）和队友 B（批评者）：请就这家公司的估值合理性展开讨论。规则： - 每人最多发言 3 轮 - 每轮发言不超过 200 字 - 第 3 轮必须给出各自的最终结论 - 将讨论记录保存到 output/valuation-debate.md ``` 设定轮次和字数限制，可以避免辩论占用过多上下文空间，同时保留关键观点。 ### 实战案例：金融研报多维度评审一份金融研报需要从合规性、数据准确性和投资逻辑三个维度进行评审。使用 Agent Teams 可以让三个队友并行评审，并在发现交叉问题时直接沟通。 ```opencode 请创建一个团队评审这份研报 data/research-report.pdf。队友 A（合规审查员）： - 检查信息披露是否符合规范 - 核实风险提示是否完整 - 审查利益冲突声明队友 B（数据审查员）： - 验证财务数据的准确性 - 检查计算过程是否有误 - 核实数据来源的时效性队友 C（投资逻辑审查员）： - 评估分析框架的合理性 - 检查论证是否有逻辑漏洞 - 评价投资建议是否被数据支持每位队友将审查结果保存到 output/review/ 目录： - compliance-review.md - data-review.md - logic-review.md 如果发现跨维度问题，直接与相关队友沟通确认。最终由 Lead 综合三份审查报告生成评审总结。 ``` ::: {.callout-tip} ## 上下文管理要点每个队友只关注自己的审查维度，上下文不被其他维度的细节污染。发现交叉问题时通过私信沟通，而非广播。完整评审意见保存到文件，Lead 只需读取三份审查报告的关键结论。 :::