第 8 章：Context Isolation

本章导读

核心问题：如何避免不同 Agent、任务和权限之间的上下文污染。

关键词：Private Context、Shared Workspace、Scratchpad、Context Boundary、Subagent

学习产出：设计 Multi-Agent CI 分析中的私有上下文和共享 finding 协议。

1. 本章要解决什么问题

前几章讨论了上下文的组成、选择和压缩。

但还有一个经常被忽略的问题：

不是所有上下文都应该被所有 Agent、所有任务、所有阶段看到。

这就是 Context Isolation。

很多 Agent 系统失败，不是因为上下文太少，而是因为上下文混在一起：

一个子 Agent 的错误假设污染主 Agent；
一个任务的临时信息进入另一个任务；
一个用户的偏好影响另一个用户；
一个项目的代码泄露到另一个项目；
高权限工具结果被低权限 Agent 看见；
多个并行探索路径互相干扰。

Context Isolation 要解决的就是这些问题。

本章核心观点是：

上下文不仅要被选择和压缩，还要被隔离、分层和授权。

本章回答：

为什么上下文隔离是 Agent 可靠性问题；
为什么上下文隔离也是安全和权限问题；
单 Agent、长任务、多 Agent 分别需要什么隔离机制；
Private Context、Shared Context、Scratchpad、Workspace 如何设计；
如何用 Java / Spring Boot 实现 ContextBoundaryPolicy。

2. 对应 Anthropic 文章

本章主要对应两类文章：

Effective Context Engineering for AI Agents
How we built our multi-agent research system

Anthropic 在 context engineering 中提到 sub-agent architectures：每个 subagent 使用干净的上下文窗口进行探索，然后只返回压缩后的结论。

在 multi-agent research system 中，多个 Agent 并行探索不同方向，再由主 Agent 汇总。

这背后的关键思想就是：

详细探索上下文保留在局部，主上下文只接收高质量压缩结果。

这就是 Context Isolation 的价值。

3. 为什么需要 Context Isolation

3.1 防止上下文污染

Agent 在探索任务时，会产生很多临时假设。

例如：

可能是数据库连接池问题。
可能是最近提交导致。
可能是缓存未命中。

这些假设在未验证前不应该进入全局上下文。

如果所有假设都共享，模型可能把未经验证的内容当成事实。

正确做法是：

假设留在私有 Scratchpad
验证后的事实进入 Shared Context

3.2 降低认知噪声

多个 Agent 并行工作时，每个 Agent 都会产生大量细节。

如果主 Agent 看到所有细节，很快会被淹没。

因此 subagent 应返回：

结论
证据
置信度
未解决问题
引用

而不是完整对话轨迹。

3.3 支持权限隔离

企业环境中，上下文隔离首先是安全问题。

例如：

用户 A 不能看到用户 B 的任务上下文；
项目 X 的代码不能进入项目 Y；
生产日志不能给无权限 Agent；
密钥和凭证不应该进入模型；
高权限工具结果不能被低权限任务复用。

因此上下文隔离必须由程序强制执行。

3.4 支持并行探索

多 Agent 系统的优势之一是并行。

但并行探索要求上下文隔离。

否则多个 Agent 会互相影响，失去独立探索价值。

例如研究任务中：

Agent A 研究技术可行性
Agent B 研究成本
Agent C 研究安全风险

它们应该有独立上下文，最后只共享结论。

4. Context Isolation 的基本概念

4.1 Private Context

Private Context 只对当前 Agent 可见。

适合保存：

临时假设；
中间推理；
局部搜索结果；
未验证线索；
Agent 自己的 Scratchpad。

Private Context 不应自动写入共享区或长期记忆。

4.2 Shared Context

Shared Context 对多个 Agent 或多个阶段可见。

适合保存：

用户目标；
任务计划；
已验证事实；
阶段性结论；
共享证据；
最终产物。

Shared Context 应保持简洁和结构化。

4.3 Workspace

Workspace 是任务运行时的工作空间。

它可以包含：

shared/
  task.md
  plan.md
  evidence.md
  decisions.md
agents/
  planner/scratchpad.md
  researcher-a/scratchpad.md
  reviewer/scratchpad.md
artifacts/
  reports/
  patches/
  logs/

Workspace 可以映射为文件系统、数据库记录或对象存储。

4.4 Scratchpad

Scratchpad 是 Agent 的临时草稿本。

它适合保存：

待验证想法；
搜索路径；
中间计算；
局部计划。

Scratchpad 的关键原则是：

默认私有
默认短期
默认不进入 Memory

4.5 Context Boundary

Context Boundary 定义上下文能否跨边界流动。

边界可以是：

用户边界；
项目边界；
租户边界；
Agent 边界；
阶段边界；
权限边界；
敏感度边界。

Context Isolation 的核心就是管理这些边界。

5. 单 Agent 场景中的隔离

即使只有一个 Agent，也需要隔离。

一个长任务中至少有三类上下文：

Global Context：系统规则、项目规范
Task Context：当前任务目标、状态、证据
Temporary Context：临时搜索、假设、草稿

例如 Coding Agent：

Global：AGENTS.md、代码规范；
Task：本次 Issue、当前计划、修改文件；
Temporary：刚刚搜索到但未验证的可能原因。

Temporary Context 不应长期保留。

6. 多 Agent 场景中的隔离

多 Agent 系统中，隔离更重要。

推荐模式：

Coordinator 拥有全局计划和共享摘要
Subagent 拥有私有上下文和局部工具
Subagent 只向 Coordinator 返回压缩产物
Reviewer 只读取产物和证据，不读取全部私有轨迹

这样可以避免：

信息爆炸；
错误假设传播；
Agent 互相模仿；
权限扩散。

7. 架构图 / 流程图

图 8-1 Context Isolation 模式 这张图展示 Multi-Agent 场景中 Private Context、Scratchpad 与 Shared Workspace 的边界。 Mermaid 源文件

7.1 私有与共享上下文

图 8-2 私有与共享上下文 Mermaid 源文件

7.2 上下文边界过滤

图 8-3 上下文边界过滤 Mermaid 源文件

7.3 Subagent 隔离模式

图 8-4 Subagent 隔离模式 Mermaid 源文件

8. Java / Spring Boot 落地方案

8.1 ContextScope

public enum ContextScope {
    GLOBAL,
    TENANT,
    PROJECT,
    SESSION,
    TASK,
    AGENT_PRIVATE,
    STEP
}

8.2 AgentWorkspace

public record AgentWorkspace(
    String workspaceId,
    String taskId,
    String projectId,
    Map<String, PrivateWorkspace> privateWorkspaces,
    SharedWorkspace sharedWorkspace
) {}

8.3 SharedWorkspace

public record SharedWorkspace(
    String taskGoal,
    List<ContextChunk> verifiedFacts,
    List<Artifact> artifacts,
    List<DecisionRecord> decisions
) {}

8.4 PrivateScratchpad

public record PrivateScratchpad(
    String agentId,
    List<ContextChunk> notes,
    List<String> hypotheses,
    Instant updatedAt
) {}

8.5 ContextBoundaryPolicy

public interface ContextBoundaryPolicy {
    boolean canRead(AgentIdentity agent, ContextChunk chunk);
    boolean canShare(AgentIdentity agent, ContextChunk chunk, ContextScope targetScope);
    ContextChunk sanitizeForSharing(ContextChunk chunk, ContextScope targetScope);
}

一个基础策略：

public class DefaultContextBoundaryPolicy implements ContextBoundaryPolicy {

    @Override
    public boolean canRead(AgentIdentity agent, ContextChunk chunk) {
        return chunk.metadata().permissions().contains(agent.role())
            && chunk.metadata().sensitivity() != Sensitivity.SECRET;
    }

    @Override
    public boolean canShare(AgentIdentity agent, ContextChunk chunk, ContextScope targetScope) {
        if (chunk.type() == ContextType.SCRATCHPAD) {
            return false;
        }
        if (chunk.metadata().sensitivity() == Sensitivity.CONFIDENTIAL
            && targetScope == ContextScope.GLOBAL) {
            return false;
        }
        return true;
    }

    @Override
    public ContextChunk sanitizeForSharing(ContextChunk chunk, ContextScope targetScope) {
        // 脱敏、摘要、去除私有字段
        return chunk;
    }
}

8.6 ContextPromotion

私有上下文可以被提升为共享上下文，但必须经过验证。

public interface ContextPromotionService {
    PromotionResult promote(
        AgentIdentity agent,
        ContextChunk privateChunk,
        ContextScope targetScope
    );
}

例如：

私有假设：可能是 OrderStateMachine 漏配。
验证工具：读取代码 + 运行测试。
共享事实：OrderStatus 新增 PENDING_REVIEW，但 allowedTransitions 未更新。

只有后者应该进入 Shared Context。

9. 企业案例：多 Agent 代码评审

假设一个 PR 需要多 Agent 评审：

PlannerAgent：拆分评审维度
SecurityAgent：检查安全风险
PerformanceAgent：检查性能风险
TestAgent：检查测试覆盖
ReviewAgent：汇总意见

上下文设计：

Agent	可见上下文	私有上下文	输出到共享区
Planner	PR 描述、Diff	拆分思路	评审计划
Security	Diff、安全规则	安全假设	安全发现
Performance	Diff、性能规则	性能分析	性能风险
Test	Diff、测试文件	覆盖判断	测试建议
Review	所有共享发现	汇总草稿	最终报告

每个子 Agent 不需要看到其他 Agent 的完整推理，只需要看到共享计划和自己的任务输入。

10. 常见误区

10.1 所有 Agent 共享一个上下文

这会导致上下文爆炸和互相污染。

10.2 Scratchpad 自动进入长期记忆

Scratchpad 中有大量未验证假设，不应自动持久化。

10.3 只做 token 隔离，不做权限隔离

上下文隔离不仅是性能优化，也是安全边界。

10.4 主 Agent 读取所有子 Agent 详细日志

主 Agent 应读取压缩结论和证据，而不是所有轨迹。

10.5 没有共享标准

Subagent 输出应有统一格式：

finding
evidence
confidence
open_questions
references

否则共享区会变成杂乱文本。

11. 贯穿案例：CI 失败分析 Agent

如果 CI 失败分析扩展为 Multi-Agent，就必须进行 Context Isolation。

例如可以设计三个 Subagent：

LogAnalysisAgent：分析 CI 日志
CodeAnalysisAgent：分析 Git Diff 和相关代码
TestAnalysisAgent：分析失败测试和测试规则

每个 Subagent 应有自己的 Private Context。

LogAnalysisAgent 不需要看到完整代码库；CodeAnalysisAgent 不需要读取完整 CI 日志；TestAnalysisAgent 不需要访问无关业务模块。

共享到 Shared Workspace 的不应是完整探索过程，而应是结构化 finding：

{
  "finding": "OrderStateMachine rejects PENDING_REVIEW -> APPROVED",
  "evidence": ["CI log L912", "OrderStateMachine.java:88"],
  "confidence": 0.9
}

未验证假设，例如“可能是数据库问题”，应留在私有 Scratchpad，不能直接进入共享结论。

12. 本章小结

本章讨论了 Context Isolation。

核心结论：

上下文隔离可以减少噪声、错误传播和权限风险。
Private Context 适合保存临时假设和局部探索。
Shared Context 只应保存验证后的事实、产物和阶段性结论。
多 Agent 系统应让子 Agent 独立探索，只返回压缩结果。
企业 Agent 必须通过 ContextBoundaryPolicy 强制执行隔离。

一句话总结：

好的 Agent 系统不是让所有信息自由流动，而是让正确的信息在正确的边界内流动。

13. 实践任务

任务 1：设计上下文边界

为 PlannerAgent、CodeAgent、ReviewAgent 设计：

哪些上下文共享；
哪些上下文私有；
哪些上下文不能跨 Agent；
哪些上下文可以进入长期 Memory。

任务 2：实现 ContextBoundaryPolicy

实现：

canRead()
canShare()
sanitizeForSharing()

至少支持项目权限和敏感度检查。

任务 3：设计 SharedWorkspace

为“CI 失败分析 Agent”设计一个共享工作区，包含：

task goal；
verified facts；
hypotheses；
evidence；
final report。

其中 hypotheses 默认不进入 final report，除非被验证。

任务 4：设计 Subagent 输出格式

定义一个 JSON Schema：

{
  "finding": "...",
  "evidence": ["..."],
  "confidence": 0.8,
  "openQuestions": ["..."],
  "references": ["..."]
}