AI Agent 核心策略：Gemini CLI 和 Claude Code 的上下文隔离策略和细节

前面两篇文章我们聊了 AI Agent上下文管理的策略，以及上下文压缩的策略和细节。

上下文的管理策略一般可以分为写入、选择、压缩和隔离。

聊完压缩，今天我们再聊一下上下文策略中的隔离。

当我们让 AI Agent 去完成一个复杂任务时，比如重构一个 React 项目，它可能需要同时处理文件编辑、代码执行、测试运行、文档查询等多个子任务。如果这些任务的上下文混在一起，就像在一个嘈杂的办公室里同时进行十个会议——每个人都听不清自己该听的内容。

今天还是以 Gemini CLI 和 Claude Code 为例来聊下上下文管理的隔离策略。

1. 为什么要有上下文隔离？

在有限上下文文窗口的前提下，如果没有上下文隔离，会引发出错误的 LLM 上下文管理，从而会产生四种比较严重的问题：

1. 上下文中毒——当错误信息进入上下文后，会像病毒一样持续影响后续的所有决策。这是由大模型的自回归特性所决定的。
2. 上下文干扰——当上下文太长时，模型会过度关注历史信息而忽略核心任务。就像我们在写代码时，IDE 里打开了 50 个文件标签，反而找不到真正需要编辑的那个。
3. 上下文混乱——信息过载导致模型性能急剧下降。即使提供了完整的工具描述，模型也可能因为信息太多而调用错误的工具。
4. 上下文冲突——新旧信息直接矛盾，让 Agent 的推理过程完全不知所云。

这些问题在 Agent 场景下被严重放大，因为 Agent 需要收集多源信息、进行顺序工具调用、多轮推理，极易导致上下文膨胀和失控。

2. Claude Code 的隔离策略

Claude Code 的隔离策略让我想起了潜艇的水密舱设计——即使一个舱室进水，也不会影响整艘潜艇。

2.1 主从分离的执行模式

Claude Code 最核心的设计是主 Agent (nO循环引擎) 和 SubAgent (I2A实例) 的分离。主 Agent 就像一个项目经理，负责统筹全局，而具体的开发任务会分配给不同的 SubAgent 去执行。

每个 SubAgent 都在自己独立的执行环境中工作，通过 Task 工具实现单向通信，避免上下文污染。当一个 SubAgent 在处理文件编辑任务时出了问题，不会影响另一个正在执行代码测试的 SubAgent。它们之间唯一的联系就是通过主 Agent 传递最终结果。

2.2 三层记忆架构

Claude Code 把对话历史分成三层来管理：

短期记忆层——当前会话的实时消息数组，O(1) 时间复杂度访问，自动进行 Token 统计。

中期记忆层——当短期记忆使用率达到 92% 时，系统会触发 AU2 算法进行 8 段式结构化压缩。这不是简单地删除旧消息，而是智能提炼成：背景上下文、关键决策、工具使用记录、用户意图演进、执行结果汇总、错误与解决、未解决问题、后续计划。

长期记忆层——CLAUDE.md 系统存储项目级别的信息，包括项目上下文、用户偏好、代码风格、开发环境、安全配置等，实现跨会话的持久化记忆。

2.3 工具执行的 6 阶段隔离

Claude Code 的 MH1 工具执行引擎实现了严格的6阶段流水线：

1. 工具发现与验证：工具名称解析、注册表查找、可用性检查
2. 输入验证：Zod Schema 验证、参数类型检查、必填参数验证
3. 权限检查：Allow/Deny/Ask 三种权限行为，Hook 机制支持
4. 取消检查：AbortController 信号、用户中断处理、超时控制
5. 工具执行：pW5 具体执行函数、异步生成器处理、流式结果输出
6. 结果格式化：结果标准化、状态清理、分析事件记录

2.4 并发控制的智能隔离

UH1 调度器把工具分成两类处理：

并发安全工具（可同时执行，最多10个）：

• Read、LS、Glob、Grep、WebFetch、TodoRead、Task

非并发安全工具（必须串行执行）：

• Write、Edit、MultiEdit、Bash、TodoWrite

这种分类确保了读操作可以高效并发，而写操作必须严格串行，避免了资源竞争和数据冲突。

2.5 会话轮次的独立隔离

每个对话轮次都有独立的状态管理：

currentTurnState = {
  compacted: true,
  turnId: generateTurnId(),  // 独立轮次ID
  turnCounter: 0             // 独立计数器
};

这确保了即使在处理第 20 轮对话时出现问题，也不会影响到前面已经完成的工作。系统可以随时回滚到之前的某个状态，就像 Git 的 commit 一样。

2.6 SubAgent 架构的完全隔离

SubAgent 提供了最强的隔离保证：

• 独立的 nO 循环实例
• 专用消息队列
• 隔离的工具权限
• 独立错误处理
• 单一消息返回机制（无状态通信）

2.7 文件内容注入的容量隔离

当需要查看项目文件时，系统有严格的限制：

• 一次最多打开 20 个文件
• 每个文件最大 8K Token
• 总共不超过 32K Token

这防止了恶意或错误的请求导致系统过载。

2.8 6 层安全防护体系

Claude Code 实现了企业级的 6 层安全防护：

1. 输入验证层：Zod Schema 严格验证，防止恶意输入污染
2. 权限控制层：Allow/Deny/Ask 三元组权限验证，Hook 机制绕过通道
3. 沙箱隔离层：Bash 命令在 sandbox=true 环境执行，文件系统写入限制，网络访问域名白名单
4. 执行监控层：AbortController 提供中断隔离，超时控制防止卡死，资源限制（内存/CPU）
5. 错误恢复层：异常捕获防止错误传播，错误分类与详细日志，自动重试与降级处理
6. 审计记录层：操作日志完整追踪，安全事件实时告警，定期合规审计

3. Gemini CLI 的隔离策略

相比 Claude Code 的「严格」，Gemini CLI 采用了更加实用主义的策略（或者说简单、简陋？）。

3.1 会话级别的物理隔离

Gemini CLI 的核心策略是通过文件系统实现物理隔离。每个对话会话都有独立的存储文件：

const timestamp = new Date().toISOString().slice(0, 16).replace(/:/g, '-');
const filename = `session-${timestamp}-${this.sessionId.slice(0, 8)}.json`;
this.conversationFile = path.join(chatsDir, filename);

这个命名策略包含时间戳和会话ID，既保证了唯一性，又方便查找和管理。

3.2 项目级别的组织

对话记录按项目哈希值组织，不同项目的对话存在完全不同的目录中：

this.projectHash = getProjectHash(config.getProjectRoot());
const chatsDir = path.join(this.config.storage.getProjectTempDir(), 'chats');

这种设计让项目之间的上下文天然隔离，你在项目 A 中的对话历史永远不会影响到项目 B。

3.3 优雅的会话管理

Gemini CLI 提供了灵活的会话管理机制：

会话重置——随时可以创建全新的对话上下文

async resetChat(): Promise<void> {
  this.chat = await this.startChat();
}

会话恢复——可以从之前的会话继续，同时保持隔离

if (resumedSessionData) {
  this.conversationFile = resumedSessionData.filePath;
  this.sessionId = resumedSessionData.conversation.sessionId;
}

3.4 模型切换的处理

Gemini CLI 在模型切换时采用了一个相对简单的策略——共享历史记录，但中断当前查询。这种设计是实用主义的体现：保留有价值的上下文信息，同时通过中断来防止潜在的不一致性。

这就像你换了一个新同事接手项目，你会把之前的讨论记录都给他看，但当前正在进行的讨论会重新开始。

4. 一些实践建议

基于这些分析，如果你要构建自己的 Agent 系统，有几个建议：

4.1 从简单开始，逐步演进

不要一开始就构建复杂的多层隔离系统。可以先从 Gemini CLI 这样的文件级隔离开始，随着需求增长再逐步增加隔离层次。

4.2 明确隔离边界

清楚地定义什么信息可以跨边界传递，什么不可以。Claude Code 的单向数据流原则值得借鉴——上下文只能从高层向低层传递。

4.3 监控隔离效果

建立指标来监控隔离的效果：

• 上下文大小的变化趋势
• 任务成功率
• 响应时间
• Token 消耗量

4.4 为失败做准备

即使有完善的隔离机制，也要为失败做准备。Claude Code 的六层安全防护体系就是一个很好的例子——每一层都为 Agent 的安全执行提供保障。

4.5 考虑成本

更强的隔离通常意味着更高的成本。Anthropic 的数据显示：

• 单聊天：1× Token 消耗
• 单 Agent：4× Token 消耗
• Multi-Agent：15× Token 消耗

要确保隔离带来的价值匹配增加的成本。

5. 写在最后

研究了这么些 Agent 系统的实现细节后，我觉得可能：上下文就是 Agent 的操作系统。就像操作系统通过进程隔离、内存管理、权限控制来保证计算机的稳定运行，优秀的 Agent 系统也需要通过精心设计的上下文隔离策略来确保任务的可靠执行。Claude Code 的严格隔离和 Gemini CLI 的实用主线，虽然实现方式不同，但都在解决同一个核心问题：如何让 AI 在复杂环境中保持清醒。

从技术演进的角度来看，上下文隔离正在从「锦上添花」变成「必备基础」。早期的 AI Agent 就像在一个嘈杂的开放办公室里工作，所有信息混在一起，难免会出现混乱。而现在，通过 SubAgent 架构、分层记忆、智能压缩等技术，我们正在给每个 Agent 构建独立的「工作空间」。这种演进让我想起了从单任务 DOS 到多任务 Windows 的跃迁——隔离不是为了分离，而是为了更好地协作。

未来的 Agent 系统会走向何方？我相信会出现更多创新：自适应的隔离策略、跨 Agent 的安全通信协议、甚至是 Agent 专属的「虚拟操作系统」。但无论技术如何演进，有一点是确定的：好的隔离策略不是技术炫技，而是让 Agent 能够心无旁骛地解决问题。这就像给一个优秀的程序员提供安静的办公环境——不是奢侈，而是必需。

以上。