9.6 上下文工程与多代理编排

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

当一个 Skill 开始编排多个子代理时，上下文管理就从”可选的优化”变成了”必须做的基本功”。每个子代理的上下文窗口是独立的、有限的，主代理的上下文窗口更是整个工作流的瓶颈。如果不主动管理信息的流入和流出，系统的产出质量会随着任务复杂度的上升而迅速下降。

上下文工程（Context Engineering）就是围绕这项稀缺资源展开的管理方法。它包含三个操作层面，分别解决不同的问题。

信息注入

信息注入（Context Loading）决定了智能体开始工作时掌握多少背景信息。注入过少，智能体缺乏判断依据，产出质量差。注入过多，关键信息被稀释，智能体反而更容易遗漏重点。

在 Skill 编排子代理的场景中，信息注入主要通过三个通道完成：

注入通道	内容	控制要点
CLAUDE.md	项目级规则，所有智能体自动加载	保持简洁，只放所有智能体都需要的共性规则
Skill 的分派提示词	任务目标、输入文件路径、输出要求	每个子代理只接收与自身任务相关的信息
子代理主动读取文件	需要分析的数据、参考模板	在提示词中指定文件路径，而非把内容复制进提示词

注入原则

指定路径，不搬内容。与其把一份 CSV 的内容复制到提示词里（消耗上下文空间），不如告诉子代理”请读取 data/report.csv“。文件内容只在子代理的上下文中出现，不占用主代理的空间。

信息隔离

信息隔离（Context Isolation）是多智能体架构的天然优势。每个子代理拥有独立的上下文窗口，彼此的工作内容不会互相干扰。

隔离体现在三个维度：

• 上下文隔离：子代理 A 分析业绩数据时产生的中间推理，不会进入子代理 B 分析持仓结构的上下文
• 工具权限隔离：通过 allowed-tools 限制每个子代理只使用完成自身任务所需的最小工具集
• 文件空间隔离：在分派时为每个子代理指定独立的输出目录，避免写入冲突

▶ Claude Code

子代理 1（业绩分析）：
- 只读取 data/nav_history.csv
- 输出保存到 temp/performance/

子代理 2（持仓分析）：
- 只读取 data/holdings.csv
- 输出保存到 temp/holdings/

子代理 3（风险评估）：
- 只读取 data/returns.csv
- 输出保存到 temp/risk/

隔离的直接好处是减少上下文污染——当不同任务的信息混在同一个上下文窗口中时，智能体对指令的遵从度会下降，输出质量也会变得不稳定。

信息压缩

在多代理编排中，主代理的上下文是最珍贵的资源。它需要掌握整体任务目标、跟踪各子任务进度，并负责最终的结果整合。如果每个子代理都把完整结果返回给主代理，上下文空间很快就会耗尽。

信息压缩（Context Compaction）的核心做法是一条规则：完整内容进文件，摘要进上下文。

做法	主代理上下文消耗	信息完整性
子代理返回完整报告	高（数千字）	完整但挤占空间
子代理保存文件 + 返回摘要	低（一两句话）	完整结果在文件中，按需读取

反面做法

▶ Claude Code

请分析这只基金的业绩表现，把完整分析结果告诉我。

推荐做法

▶ Claude Code

请分析这只基金的业绩表现。
将完整分析报告保存到 temp/performance_analysis.md。
完成后只返回一句话摘要，说明关键结论和文件保存位置。

文件化传递（File Handoff）

File Handoff 是上下文工程在实践中最核心的操作：子代理将完整结果保存到约定路径的文件中，只向主代理返回简短的状态摘要。这样做有三个好处：主代理的上下文保持干净、完整结果不会丢失、主代理可以在需要时选择性读取。

在 Skill 中编排多个子代理时，每个子代理的分派提示词都应包含明确的输出路径和”只返回摘要”的要求。

上下文工程清单

设计一个编排多子代理的 Skill 时，可以按这张清单逐项检查：

检查项	具体操作
每个子代理的输入是否明确？	在提示词中指定文件路径，不搬运内容
每个子代理的输出路径是否指定？	约定 temp/ 或 output/ 下的具体文件名
是否要求子代理只返回摘要？	提示词中明确”只返回一句话状态摘要”
不同子代理的文件空间是否隔离？	各自写入不同的子目录
CLAUDE.md 是否精简？	只保留所有智能体共需的规则
主代理是否避免处理大量文本？	结果整合阶段才读取子代理的输出文件

这些做法在子代理数量为 2-3 个时可能感觉多余，但当编排规模扩大到 5 个以上子代理时，不做上下文管理的系统几乎必然出现遗漏、重复或逻辑混乱。