Context Filtering（上下文过滤）
多 Agent 系统中，将主对话历史按目标 Agent 的需求裁剪后再传递的机制。核心策略：只保留 user 消息和各 Agent 的最终输出（带 name 标签的 assistant 消息），丢弃工具调用细节。与"上下文隔离"不同——过滤是主动选择传什么，隔离是结构性不共享。
定义
Context Filtering（上下文过滤）是多 Agent 编排系统中的一项核心工程实践：在将消息历史传递给 Sub-Agent 之前，根据目标 Agent 的角色和任务需求，对消息进行筛选和裁剪。
它是更广义的"上下文管理"（Context Management）的子集——后者还包括记忆系统中的信息筛选（第8篇）。
与"上下文隔离"的区别
- 上下文过滤（Filtering）：Supervisor 模式中主动选择传递哪些消息给 Sub-Agent。Agent 共享同一进程，通过代码逻辑控制可见性。
- 上下文隔离（Isolation）：结构性不共享。如 CrewAI 的 Task.output 链——每个 Agent 只看到上一个 Task 的输出，而非完整对话历史。
本系列约定：描述 Supervisor 的 _filter_context 时用"过滤"，描述 CrewAI 式结构性隔离时用"隔离"，中性泛指时用"管理"。
过滤策略（第7篇实现）
第7篇 _filter_context 的策略：只保留两类消息，丢弃其余：
| 保留条件 | 示例 | 原因 |
|---|---|---|
role == "user" | 用户的原始任务描述 | 所有 Sub-Agent 都需要理解用户意图 |
role == "assistant" 且有 name 字段 | [coder]: 代码已写入... | 带 name 标签的消息是各 Agent 的最终输出，其他 Agent 需要看到 |
丢弃的内容包括：工具调用请求（tool_calls）、工具执行结果（tool role）、中间推理过程、system prompt。
target 参数为扩展预留——当 Agent 数量增加到 5-10 个时，可按 target 决定哪些 Agent 的输出对当前 Agent 可见。
工程价值
- 降低噪音：工具执行日志对审查 Agent 无益，过滤后减少干扰
- 节省 Token：一次编码任务可能产生数千 token 的工具调用日志，过滤后大幅降低成本
- 专注度保证：每个 Agent 只看与自己任务相关的信息，提升输出质量
引用本术语的文章