Agent 架构深度对比

6 大编码工具核心模块解析 -- 从 Agent Loop 到多 Agent 协作

Claude Code Codex CLI Gemini CLI OpenCode DeerFlow 2 OpenClaw

M0: 整体差异总览

在深入 6 个模块之前，先看全局：谁真正超越了 Claude Code，哪些领域各有千秋，哪些方面 CC 仍然领先。

真正超越 CC 的能力
能力超越者具体优势CC 的差距
运行性能Codex CLI (Rust)零依赖原生二进制，启动毫秒级，内存占用极低TypeScript/Node.js，启动需加载运行时，内存占用高
沙箱深度Codex CLIexecve(2) 系统调用拦截 + Apple Seatbelt + Full Auto 完全禁网容器化 Bash，无网络隔离，无系统调用级拦截
沙箱多样性Gemini CLI4 种沙箱（Seatbelt/Docker/gVisor/LXC），gVisor 用户态内核是最强隔离仅容器化方案
免费额度Gemini CLI60 req/min, 1000 req/day 完全免费（Google 账号）必须付费 API Key
上下文窗口Gemini CLI1M tokens（Gemini 3 模型）200K tokens（Claude 模型）
Google 搜索Gemini CLI内置 Google Search grounding（独家能力）仅 MCP 工具搜索
多 ProviderOpenCode / Codex10+ Provider 统一接口，一个工具用所有模型仅 Anthropic（Bedrock/Vertex 间接）
Copilot 免费OpenCodeGitHub Copilot 订阅用户零额外成本无 Copilot 集成
内容生成DeerFlow 2播客(TTS→MP3)/PPT(8风格)/咨询级报告/数据可视化无内容生成能力（纯编码 Agent）
中间件编排DeerFlow 2LangGraph 状态图 + 11 中间件链，最可扩展的编排架构简单 while loop，无中间件层
生产级沙箱DeerFlow 2Docker/K8s Pod 隔离执行，适合大规模部署无 K8s 支持
消息渠道OpenClaw23+ 渠道（WhatsApp/Telegram/Slack/飞书/iMessage…）终端唯一入口
语音交互OpenClawWake Word + Talk Mode + ElevenLabs TTS无语音能力
设备控制OpenClawCamera/GPS/SMS/联系人/日历（跨 macOS/iOS/Android）无设备访问
技能生态OpenClawClawHub 13,729+ 社区技能技能生态较小
AST 重构OmO (OpenCode插件)AST-Grep 语法树级搜索重写，25 语言，确定性 100%依赖模型理解，概率性 ~99%
交互终端OmOTmux 集成，支持 REPL 和断点调试Bash 非交互式，无 REPL
扩展画廊Gemini CLIExtensions Gallery 浏览/安装/开发模板无扩展商店
MCP 双向Codex CLI既是 MCP Client 又能作为 MCP Server仅 MCP Client
企业管控Codex CLIrequirements.toml 强制安全策略无企业策略机制
配置兼容OpenCode同时读 CLAUDE.md + .cursorrules + copilot-instructions只读 CLAUDE.md
各有千秋的领域
1. 记忆系统
产品方式优点缺点
CCCLAUDE.md + memory 文件（手动/半自动）用户完全可控，透明可编辑需要手动维护
DeerFlow 2LLM 驱动 memory.json（自动提取+置信度评分）最智能，自动提取事实LLM 提取可能出错，30s 防抖有延迟
OpenCodeSQLite 持久化结构化可查询不如 Markdown 直观
OpenClawMarkdown 本地文件 + 向量搜索可读可编辑+语义搜索向量搜索准确度不稳定
Gemini CLIGEMINI.md + save_memory 工具 + JIT 发现JIT 最灵活（访问目录自动扫描）记忆工具较简单
Codex CLI~/.codex/memories/ 目录持久化记忆，workspace-write 沙箱模式下可写沙箱感知（memories 目录在沙箱可写白名单内），与安全模型深度集成记忆机制文档较少，不如 CC 的 CLAUDE.md 直观
2. 多 Agent 编排
产品模式优点缺点
CCSub-Agent 委派 + Agent Team（/agent-team 创建命名团队，每个成员独立 git worktree，Lead Agent 协调合并）简单委派 + 团队编排兼备；worktree 隔离避免合并冲突；成员并行开发不同模块Team 功能较新，生态工具支持待完善
DeerFlow 2Lead + Sub-Agents（最多 3 并发）中间件可扩展，checkpoint 恢复架构复杂，启动开销大
OpenClawRouter + 隔离 Agent（Bindings 路由）最适合多人格多任务安全风险（Agent 间 prompt injection）
Gemini CLI4 个内置子代理专家化（browser/codebase/help）不可自定义，数量固定
Codex CLI实验性 multi_agent有潜力尚不成熟
3. 上下文管理
  • CC：自动压缩接近上下文限制（本地截断式压缩） — 简单有效
  • Codex CLI：云端压缩（上下文满时将完整对话发送至 OpenAI 云端 API 进行摘要压缩，保留关键决策和代码变更）— 理论上可维持更长有效对话，但有隐私与延迟代价
  • DeerFlow 2：SummarizationMiddleware (tokens/messages/fraction 三维触发) — 最精细
  • Gemini CLI：/compress + JIT 上下文发现 + Token Caching — 最节省 token
  • OpenCode：Auto Compact 95% 阈值 — 与 CC 类似

各有取舍：精细度 vs 简单性 vs 节约成本

4. 项目上下文文件
  • CC：CLAUDE.md 3 层 — 简洁直接
  • Gemini CLI：GEMINI.md 3 层 + JIT + @./path 模块化导入 + /init 自动生成 — 功能最丰富
  • Codex CLI：AGENTS.md 3 层 — 与 CC 类似
  • OpenCode：兼容所有格式 — 最实用但无创新
  • DeerFlow 2：SOUL.md (Bootstrap 对话引导生成) — 最有趣

各有特色，无绝对优劣

5. 安全 vs 易用
  • 安全性最高的产品（DeerFlow K8s / Gemini gVisor）需要最多配置
  • CC 的平衡点最好：默认安全够用 + 配置极简
  • OpenClaw 最易用但安全被批评最多
  • 永恒 tradeoff，没有最优解
CC 仍然领先的领域
能力CC 的优势竞品的差距
模型编码质量Claude Sonnet/Opus 编码能力顶级Gemini/GPT 编码仍有差距（尤其复杂重构）
编辑可靠性old_string→new_string 内容匹配，架构层面规避行号漂移OpenCode/OmO 需要哈希锚定补丁
零配置体验npm install 一条命令，开箱即用DeerFlow 需要 Python+Node+nginx+make，OpenClaw 需要 onboard
Hooks 系统PreToolUse/PostToolUse/Stop，成熟的事件驱动自定义Codex/OpenCode 无 Hook 系统
开发者 UX终端原生、响应快、输出简洁DeerFlow/OpenClaw 需要浏览器/消息应用
意图理解Claude 模型隐式理解用户意图，无需额外层OmO 需要显式 IntentGate 补偿弱模型
系统提示词经过大量优化的 system prompt，深度整合 Claude 能力OpenCode 直接搬用 CC 的 prompt
简洁架构简单 Agent Loop 足够强大，维护成本低DeerFlow 4 服务 + 11 中间件，架构复杂度高

两条路线之争：模型驱动 vs 工程驱动。CC 选择用更强的模型减少工程复杂度（简单架构 + 顶级模型）；其他产品选择用更好的工程弥补模型差距（复杂架构 + 多模型路由）。当模型能力趋同时，工程架构的差异将成为决胜因素。

M1: Agent Loop 核心循环

Agent Loop 是所有编码智能体的心脏。理解循环机制的差异，就理解了产品架构的根本分歧。

通用 Agent Loop 模型

无论哪个产品，核心循环都遵循同一模式：接收输入 -> 组装 Prompt -> 调用 LLM -> 解析响应 -> 执行工具 -> 回传结果 -> 继续循环。差异在于每个环节的工程实现。

User Input Terminal / VS Code / API System Prompt Assembly Instructions + Tools + Memory + Context LLM API Call Streaming SSE / WebSocket Response? [text] Output Return to User text tool_use Permission Check Hooks / Policy / Sandbox Tool Execute Read / Edit / Bash / MCP Tool Result Loop Back to LLM Context Window Full? -> Auto Compaction -> Summarize & Continue

6 产品 Agent Loop 实现对比

维度Claude CodeCodex CLIGemini CLIOpenCodeDeerFlow 2OpenClaw
Loop 实现 TypeScript async generator，while 循环逐 turn 推进 Rust core crate AgentLoop，rollout/apply 两阶段 TypeScript AgentLoop (packages/core)，while 循环 Go Agent Loop (internal/llm/agent/)，for 循环 LangGraph StateGraph + 11 中间件链，图编排 TypeScript Agent Runner (Layer 3)，event-driven
API 协议 Anthropic Messages API OpenAI Responses API Gemini API (@google/genai) 双适配: Anthropic SDK + OpenAI SDK LangChain ChatModel 抽象层 多 Provider 统一适配
流式处理 SSE streaming SSE streaming SSE streaming Provider-specific streaming LangGraph SSE streaming WebSocket (ws://127.0.0.1:18789)
上下文压缩 自动压缩（接近上下文限制时触发） model_auto_compact_token_limit 配置阈值 + 云端压缩（上下文满时发送完整对话至 OpenAI 云端 API 摘要，比本地截断更智能） /compress 命令 + 自动触发 Auto Compact (95% 阈值) SummarizationMiddleware (tokens/messages/fraction 三种策略) /compact 命令
错误恢复 自动重试 + 降级 自动重试 + backoff ModelAvailabilityService 健康监控 + 降级链 Provider-specific 错误处理 LangGraph checkpoint 恢复 模型降级链 (fallbacks)
并行工具 支持（parallel tool_use） 支持 支持 支持（goroutine） 支持（LangGraph 并行节点） 支持

架构模式的根本分歧

命令式循环 (Imperative Loop) -- 5/6 产品

Claude Code, Codex CLI, Gemini CLI, OpenCode, OpenClaw 都使用 while/for 循环驱动 Agent。

  • 简单直接，容易理解和调试
  • 控制流显式，异常处理直观
  • 适合单 Agent 场景
声明式图编排 (Declarative Graph) -- DeerFlow 2

DeerFlow 2 使用 LangGraph 的 StateGraph，节点是处理步骤，边是条件跳转。

  • 天然支持并行、分支、合并
  • Checkpoint 实现断点恢复
  • 复杂度高，调试需要理解图语义
  • 11 层中间件链（认证/限流/日志/缓存...）

独特设计亮点

OpenCode 双 System Prompt
检测到 Anthropic provider 自动切换 Claude 风格 prompt；检测到 OpenAI provider 切换 Codex 风格 prompt。同一个工具，两套人格。
OpenClaw WebSocket 通信
其他 5 个产品都用 stdio 或 HTTP/SSE 与 LLM 通信。OpenClaw 的 Gateway 架构用 WebSocket 双向通信，因为它本质上是一个服务而非 CLI。
Gemini CLI 健康监控
ModelAvailabilityService 持续追踪模型健康状态，自动在多个模型间降级切换，是唯一一个有完整健康监控链的产品。
DeerFlow 2 Checkpoint
LangGraph 的 checkpoint 机制可以在任意节点保存状态，崩溃后从上次断点恢复，不丢失已执行的工具结果。
Codex CLI rollout/apply
Rust 实现的 AgentLoop 分为 rollout（规划）和 apply（执行）两阶段，先生成完整计划再批量应用变更。
Claude Code async generator
使用 TypeScript 的 async generator (yield) 实现流式输出，每个 turn 是一个 yield 点，调用方可以暂停/恢复循环。

命令式 vs 声明式是最根本的架构分歧。5/6 产品选择命令式循环，说明对于编码 Agent 场景，简单直接的 while 循环已经足够。DeerFlow 2 选择 LangGraph 图编排，是因为它定位为通用研究型 Agent而非纯编码工具，需要复杂的多步骤工作流编排能力。

OpenCode 的双 Prompt 策略揭示了一个深层问题：不同模型对同样的指令理解不同，最佳的 System Prompt 是模型特定的。这也是为什么 Claude Code 只绑定 Anthropic API -- 可以深度优化 Prompt 与模型的匹配度。

Agent Loop 是产品的「引擎」。选择 while 循环还是状态图，本质上决定了产品的复杂度天花板和可扩展性。对于 PM，关键问题是：你的用户需要的是「快速完成编码任务」还是「编排复杂的多步骤工作流」？前者用命令式循环，后者用声明式图。

M2: Tool System 工具系统

工具是 Agent 的手和脚。工具的定义方式、执行流程和权限模型，直接决定了 Agent 的能力边界和安全性。

工具定义方式对比

产品定义方式Schema 格式示例
Claude Code TypeScript 函数 + JSON Schema 参数 Anthropic tool_use format { name, description, input_schema }
Codex CLI Rust trait 实现 OpenAI function_call schema impl Tool for ShellTool { ... }
Gemini CLI TypeScript class + DiscoveredMCPTool 包装 Gemini function declarations class ReadFileTool extends BaseTool
OpenCode Go struct 实现 Tool interface JSON Schema (OpenAI compatible) type Tool struct { Name, Desc, Params, Execute }
DeerFlow 2 LangChain @tool 装饰器 LangChain ToolMessage format @tool def web_search(query: str)
OpenClaw SKILL.md Markdown + YAML frontmatter Markdown-defined parameters 纯 Markdown 文件定义工具接口

工具执行流程

LLM Output tool_use block Parse name + args Permission? Deny -> Error to LLM deny allow Execute Tool Sandbox / Direct Capture Output Truncate if > limit Return to LLM tool_result in context Ask User -> Confirm? ask

权限模型对比

L6 DeerFlow 2 -- 沙箱隔离执行。工具在 Docker/K8s Pod 内运行，与主机完全隔离 Most Strict
L5 Gemini CLI -- Policy Engine (TOML 规则引擎)。支持 allow/deny/ask_user，正则匹配文件路径和命令 Flexible + Strict
L4 Codex CLI -- 3 级审批模式 (suggest / auto-edit / full-auto) + 沙箱策略联动 Mode-based
L3 Claude Code -- 工具级别权限 (Read 免审批，Edit/Bash 需审批) + 会话级「记住」 Tool-level
L2 OpenCode -- 3 级权限 (单次 / 会话级 / 自动) + 安全命令白名单 Whitelist
L1 OpenClaw -- 工具 Profile (messaging/automation/minimal) + Shell 三级审批 Profile-based

工具数量与分类

产品内建工具数文件操作命令执行搜索Agent/MCP其他
Claude Code ~12 Read, Write, Edit, MultiEdit Bash Glob, Grep Agent (sub-agent), MCP tools Notebook, WebFetch
Codex CLI ~5 read_file, write_file, patch_file shell (exec/apply) list_directory MCP Client + MCP Server --
Gemini CLI ~10 read_file, write_file, edit_file run_shell_command glob, grep, list_directory sub-agents (4 种), MCP tools save_memory, web_search
OpenCode ~8 read, write, edit bash glob, grep, ls task_agent, MCP tools fetch
DeerFlow 2 ~16 read_file, write_file, edit_file bash (sandbox) web_search, crawl_url MCP tools, sub-agents python_repl, create_document, dedup
OpenClaw ~15 Read, Write, Edit Shell (三级审批) Glob, Grep, WebSearch sessions_spawn, sessions_send, MCP Fetch, Skill, Memory tools

工具系统的设计哲学存在两极分化：Claude Code 和 Codex CLI 走「精简内建 + MCP 扩展」路线，核心工具仅 5-12 个；DeerFlow 2 和 OpenClaw 走「丰富内建 + 分类管理」路线，内建工具 15-16 个。

Gemini CLI 的 Policy Engine 最灵活，支持 TOML 规则文件、正则匹配，可以精细控制每个工具对每个文件路径的访问权限。DeerFlow 2 的沙箱化执行最安全，工具在 Docker 容器内运行，即使 LLM 被 prompt injection 诱导执行危险操作，也被容器边界限制。

OpenClaw 的 SKILL.md 是最创新的工具定义方式 -- 用 Markdown 而非代码定义工具接口，降低了社区贡献门槛，这也是 ClawHub 能积累 13,729+ 社区技能的关键原因。

工具系统的核心决策是「安全 vs 易用」的 tradeoff。Codex CLI 的 3 级模式让用户自己选择安全级别，这是最好的产品设计 -- 不替用户决定，而是提供清晰的选项。Gemini CLI 的 TOML 策略引擎则适合企业场景，管理员可以统一配置安全策略。

M3: Context & Memory 上下文与记忆

上下文是 Agent 的「工作记忆」，记忆是 Agent 的「长期知识」。两者的管理方式决定了 Agent 的连续性和个性化能力。

System Prompt 构建流程

Base Instructions System prompt core Project Files CLAUDE.md / GEMINI.md Environment OS / CWD / Git info Tool Definitions JSON Schema for each Memory Persisted facts User Custom Rules / Preferences System Prompt Assembly Priority-ordered concatenation Final System Prompt Sent to LLM as first message

项目上下文文件对比

产品文件名层级结构特殊功能
Claude Code CLAUDE.md 全局 (~/.claude/) -> 项目 (repo root) -> 子目录 (任意嵌套) CLAUDE.local.md 用于个人配置 (gitignore)
Codex CLI AGENTS.md 全局 -> 项目 -> 子目录 child_agents_md scope 优先级控制
Gemini CLI GEMINI.md 全局 -> 环境 -> JIT 发现 @./path 模块化导入；/init 交互式自动生成；工具访问目录时自动扫描
OpenCode contextPaths (多格式) 兼容所有竞品格式 同时读 CLAUDE.md + .cursorrules + copilot-instructions.md
DeerFlow 2 SOUL.md 对话引导生成 Bootstrap skill 交互式创建人格文件
OpenClaw AGENTS.md + SOUL.md + USER.md per-Agent 隔离 每个 Agent 有独立的 workspace 和上下文

记忆系统对比

产品存储方式持久性写入方式读取方式
Claude Code Markdown 文件 (~/.claude/memory) 跨会话 手动写入 (Read+Write 工具) 启动时自动加载 MEMORY.md
Codex CLI 文件系统 (~/.codex/memories/) 跨会话 自动 / 手动 启动时注入 System Prompt
Gemini CLI GEMINI.md + save_memory 工具 跨会话 工具驱动写入 (save_memory) 启动时读 GEMINI.md + JIT 发现
OpenCode SQLite 数据库 跨会话 自动（会话+消息持久化） 结构化查询
DeerFlow 2 memory.json (LLM 驱动) 跨会话 自动提取 + 置信度评分 + 防抖更新 Top 15 注入 System Prompt
OpenClaw Markdown 本地文件 跨会话 自动提取 + 向量搜索 相关性检索注入

上下文压缩策略

6 种压缩策略对比
1/6
Claude Code -- 自动压缩
当对话接近上下文窗口限制时，自动触发压缩。使用 LLM 对历史对话生成摘要，保留关键决策和工具结果，丢弃中间思考过程。用户也可手动 /compact 触发。

特点：完全自动，用户无需干预。压缩后 token 用量大幅降低，但可能丢失细节。
Codex CLI -- 可配置阈值 + 云端压缩
通过 model_auto_compact_token_limit 配置压缩触发阈值。当 token 数超过该值时自动压缩。支持在 codex.json 中为不同模型设置不同阈值。

独特机制：云端压缩：当上下文窗口填满时，Codex 会将完整对话发送至 OpenAI 云端 API 进行智能摘要压缩，保留关键决策和代码变更，压缩后的摘要替换完整历史以释放上下文空间。这与 CC 的本地截断式压缩有本质区别——云端压缩更智能，理论上能维持更长的有效对话。
代价：需要将完整上下文发送至云端（隐私顾虑），压缩过程有额外延迟。

特点：给用户控制权 + 云端智能压缩双重机制。本地阈值控制触发时机，云端 API 保证压缩质量，是目前最独特的上下文管理方案。
Gemini CLI -- 混合模式
提供 /compress 手动命令 + 自动触发两种方式。自动触发时使用 Gemini 模型生成对话摘要。独特之处在于 JIT 上下文发现：当工具访问新目录时，自动扫描该目录下的 GEMINI.md 并动态注入。

特点：上下文不是静态的，而是随工具执行动态扩展。
OpenCode -- 95% 阈值
当上下文使用量达到 95% 时自动触发 Auto Compact。使用较小的模型生成摘要以降低成本。支持 session 持久化到 SQLite，压缩前后都有完整记录。

特点：阈值较高（95%），尽量保留更多原始上下文。SQLite 存储使得历史可追溯。
DeerFlow 2 -- SummarizationMiddleware 三策略
提供 3 种压缩策略可选：
- tokens：按 token 数量阈值触发
- messages：按消息数量阈值触发
- fraction：按上下文窗口使用比例触发
作为 LangGraph 中间件，插入在消息传递链路中自动执行。

特点：最灵活的压缩策略，可根据场景选择。中间件设计使得压缩对业务逻辑透明。
OpenClaw -- 手动压缩
主要依赖 /compact 命令手动触发。Agent 级别隔离意味着每个 Agent 有独立的上下文窗口，不会互相干扰。Memory 系统通过向量搜索实现语义检索，减少了对长上下文的依赖。

特点：依赖向量记忆替代长上下文，是一种不同的思路。

DeerFlow 2 的记忆最智能：LLM 自动从对话中提取事实 -> 计算置信度评分 -> 防抖更新（避免频繁写入）-> 只注入 Top 15 条最相关记忆。这是「AI 驱动的记忆管理」。

OpenCode 的 SQLite 持久化最工程化：结构化存储使得记忆可查询、可统计、可导出，是唯一一个用数据库而非文件系统存储会话的产品。

Gemini CLI 的 JIT 上下文发现最灵活：不需要预先加载所有上下文，而是在工具访问目录时才动态发现和注入，天然适合大型 monorepo。

OpenCode 的 contextPaths 兼容性最强：一个工具能读所有竞品的配置文件 (CLAUDE.md, .cursorrules, copilot-instructions.md)，这是最聪明的「借力」策略。

记忆系统的核心问题是「信噪比」。DeerFlow 2 的置信度评分机制解决了「记太多无用信息」的问题；Gemini CLI 的 JIT 发现解决了「预加载太多不相关上下文」的问题。对于 PM，选择记忆方案时要考虑：你的用户是「高频短对话」（需要跨会话记忆）还是「低频长对话」（需要上下文压缩）？

M4: Sandbox & Security 沙箱与安全

Agent 拥有执行代码和操作文件的能力，安全机制决定了这种能力的边界。从最宽松到最严格，6 个产品构成了完整的安全谱系。

安全哲学谱系

6 个产品的安全设计哲学可以排列成从「信任用户」到「零信任」的谱系：

01 OpenClaw -- 信任操作者模型。沙箱为 opt-in（默认不启用），依赖工具 Profile 和 Shell 审批 Most Open
02 Claude Code -- 工具级权限 + 容器化 Bash。Read 免审批，Edit/Bash 需确认，可会话级记住 Tool-level
03 OpenCode -- 命令白名单/黑名单 + 输出截断。安全命令（ls, cat, git）免审批 Whitelist
04 Codex CLI -- Apple Seatbelt + Docker + 网络隔离 + execve(2) 拦截 Process-level
05 Gemini CLI -- 4 种沙箱 (Seatbelt/Docker/gVisor/LXC) + Policy Engine + 6 种网络 Profile Multi-layer
06 DeerFlow 2 -- Docker/K8s/Apple Container 完全隔离。工具在沙箱内执行，无外网访问 Most Strict

沙箱实现技术矩阵

技术使用产品隔离级别说明
Apple Seatbelt
sandbox-exec		 Codex Gemini 进程级 macOS 原生沙箱。通过 profile 文件定义允许的系统调用、文件路径、网络访问
Docker 容器 Codex Gemini DeerFlow OpenClaw 容器级 最常用的隔离方案。完整文件系统 + 网络隔离，跨平台
gVisor runsc Gemini 用户态内核 Google 开源的用户态 Linux 内核。拦截所有系统调用，提供最强的隔离能力
Bubblewrap bwrap Codex 进程级 Linux 轻量沙箱，用于 Flatpak。命名空间隔离，启动快
LXC/LXD Gemini 系统容器 完整 Linux 系统容器，比 Docker 更接近虚拟机
K8s Pod DeerFlow 集群级 生产环境大规模隔离，自动扩缩容
Apple Container DeerFlow 容器级 macOS 原生容器（自动检测环境后选用）
execve(2) 拦截 Codex 系统调用级 Shell Tool MCP 拦截每个 execve 调用，知道每个执行程序的完整路径。最底层的安全机制

网络隔离对比

产品Full Auto 模式默认模式可配置性
Codex CLI 完全禁网 (defense-in-depth) 允许网络 通过审批模式间接控制
Gemini CLI 取决于沙箱 profile 允许网络 6 种 profile (permissive/strict x open/proxied/blocked)
DeerFlow 2 沙箱内无外网 主进程有网络 Docker network 配置
Claude Code 允许网络 允许网络 无内置网络限制
OpenCode 允许网络 允许网络 无内置网络限制
OpenClaw 允许网络 允许网络 无默认网络限制

安全设计对比：两种极端

Defense-in-Depth: Codex CLI
  • Full Auto 模式完全禁网
  • Apple Seatbelt / Bubblewrap 进程级沙箱
  • execve(2) 拦截每个系统调用
  • Docker 容器备选
  • 哲学：即使 LLM 被攻击，也无法造成实质伤害
Trust-the-Operator: OpenClaw
  • 沙箱默认不启用 (opt-in)
  • 依赖 Shell 三级审批 + 工具 Profile
  • 无内置网络限制
  • 社区安全审计多次指出 prompt injection 风险
  • 哲学：用户（操作者）应该知道自己在做什么

Codex CLI 的 execve(2) 拦截是最底层的安全机制：它不依赖沙箱或容器，而是在系统调用级别知道每个被执行程序的完整路径。这意味着即使攻击者绕过了所有上层防护，execve 拦截仍然能阻止未授权的程序执行。

Gemini CLI 的 gVisor 是最强隔离：它运行一个用户态 Linux 内核，拦截所有系统调用并在用户空间实现。这比 Docker（共享宿主内核）安全得多，但性能开销也更大。

安全性和易用性永远是 tradeoff：Codex CLI Full Auto 的完全禁网使得无法在自动化模式下调用外部 API；OpenClaw 的开放模式使得初学者可以快速上手但面临安全风险。没有绝对正确的选择，取决于使用场景。

安全架构直接影响产品的目标用户群。Codex CLI 的多层沙箱面向企业和安全敏感场景；OpenClaw 的开放模式面向个人开发者和创客。PM 在设计安全策略时，核心问题是「你的用户出了安全事故后，谁来承担责任？」-- 如果是平台承担（SaaS），必须严格；如果是用户自担（开源 CLI），可以宽松。

M5: Multi-Agent 多 Agent 架构

单 Agent 能力有上限，多 Agent 协作是突破天花板的关键。但不同产品对「多 Agent」的理解截然不同。

4 种多 Agent 模式

模式 1: Sub-Agent 委派型

Main Agent Full context + all tools spawn Sub-Agent (read-only) Limited tools, own context Sub-Agent (task) Scoped task, returns result Sub-Agent (research) Search & analyze codebase result Merge Results Back to Main Agent Claude Code, OpenCode Codex CLI (experimental)

模式 2: Lead + Sub-Agents 编排型

Lead Agent Planner + Coordinator Auth RateLimit Cache ...11 middlewares General-purpose Agent Research, analysis Bash Sub-Agent Code execution (sandboxed) Browser Sub-Agent Web search, crawl Max 3 concurrent 15 min timeout DeerFlow 2

模式 3: Router + Isolated Agents 路由型

Gateway Router + Bindings route Agent A (独立 workspace) Own session + tools + AGENTS.md Agent B (独立 workspace) Own session + tools + SOUL.md Agent C (独立 workspace) Own session + tools + USER.md sessions_spawn / sessions_send Inter-agent messaging OpenClaw

模式 4: 内置专家子代理

Main Agent Orchestrator codebase_investigator cli_help generalist_agent browser_agent Each has independent context window + tools Gemini CLI

并发控制对比

产品多 Agent 模式最大并发超时隔离级别
Claude Code Sub-Agent (Agent tool) + Agent Team（/agent-team 命名团队，worktree 隔离并行） 无硬限制 无 Sub-Agent：独立上下文窗口，共享文件系统；Agent Team：每成员独立 git worktree（代码级隔离），Lead Agent 协调合并
Codex CLI Sub-Agent (experimental) 无硬限制 无 独立上下文
Gemini CLI 内置专家子代理 (4 种) 4 个内置 无 独立上下文窗口 + 独立工具集
OpenCode Task Agent 无硬限制 无 独立上下文
DeerFlow 2 Lead + Sub-Agents 3 个 sub-agents 15 分钟 独立上下文 + 独立线程
OpenClaw Router + Isolated Agents 无硬限制 可配置 完全隔离（独立 workspace + session + tools）

大多数编码 Agent 用简单的 Sub-Agent 模式（Claude Code, OpenCode, Codex CLI），因为编码场景的任务分解相对明确：一个主 Agent 负责全局决策，Sub-Agent 负责局部调查或执行。

DeerFlow 2 的 Lead Agent + 中间件链是最复杂但最可扩展的，11 层中间件（认证/限流/日志/缓存/去重...）使得每一层都可以独立替换和扩展。

OpenClaw 的 Router 模式最适合「多人格多任务」场景：每个 Agent 有完全独立的 workspace、session 和工具集，通过 sessions_spawn 和 sessions_send 进行跨 Agent 通信。这不是编码工具的「子任务委派」，而是多个独立 Agent 的协作网络。

Gemini CLI 的 4 个内置专家子代理是一种折中方案：不像 Sub-Agent 那样完全通用，而是预定义了 4 种专家角色（代码调查/CLI帮助/通用/浏览器），每个角色有针对性的工具集和上下文。

多 Agent 的核心产品决策是「隔离 vs 共享」的 tradeoff。隔离度越高（OpenClaw），Agent 间越安全但信息传递成本越大；共享度越高（Claude Code），信息流通越快但上下文污染风险越大。对于 PM，关键是理解用户的任务是「一个大任务分解为子任务」（用 Sub-Agent）还是「多个独立任务并行」（用 Router 模式）。

M6: Extension & Ecosystem 扩展与生态

可扩展性决定了产品的生命力。MCP 协议已成为事实标准，但各产品的扩展体系远不止 MCP。

MCP 支持对比

产品MCP 角色传输协议OAuth工具过滤独特能力
Claude Code Client stdio, SSE 无 无 --
Codex CLI Client + Server stdio, HTTP 有 白/黑名单 双向 MCP（可作为 Server 被其他工具调用）
Gemini CLI Client stdio, SSE, HTTP 有 include-tools DiscoveredMCPTool 包装层，统一工具接口
OpenCode Client stdio, SSE 无 无 --
DeerFlow 2 Client stdio, SSE, HTTP 有 (client_credentials) enabled 开关 嵌入式 Client（直接在 Python 中使用）
OpenClaw Client stdio 无 无 --

扩展体系全景对比

扩展层Claude CodeCodex CLIGemini CLIOpenCodeDeerFlow 2OpenClaw
Hooks / 生命周期 PreToolUse, PostToolUse, Notification, Stop (4 事件) -- 11 事件 (onStartup, onShutdown, onQuery, onResponse...) -- LangGraph callbacks --
Skills / 命令 Custom Slash Commands (/init-project 等) Feature Flags Skills + Custom Commands + Extensions Custom Commands (.md 文件) 16 内建 Skills 13,729+ ClawHub 社区技能
MCP Client Client + Server Client Client Client Client
插件系统 -- Shell Tool MCP (可扩展) Extensions Gallery -- Skills-as-Markdown Plugins (npm 包)
规则引擎 CLAUDE.md rules/ AGENTS.md Policy Engine (TOML) contextPaths SOUL.md AGENTS.md + SOUL.md
生态规模 中（社区 MCP） 中 大（Extensions Gallery） 小 中 最大（13,729+ ClawHub）

扩展层数对比

5 层 Gemini CLI -- Extensions + Skills + Hooks (11) + Custom Commands + MCP = 最全面的扩展体系 Most Comprehensive
4 层 OpenClaw -- Skills (ClawHub) + Plugins (npm) + MCP + AGENTS.md = 最大社区生态 Largest Ecosystem
3 层 Claude Code -- Hooks (4) + Slash Commands + MCP Focused
3 层 Codex CLI -- Feature Flags + MCP (双向) + Shell Tool MCP Unique: MCP Server
2 层 DeerFlow 2 -- Skills (16 内建) + MCP Built-in Focus
2 层 OpenCode -- Custom Commands (.md) + MCP Minimal

Hooks 事件对比

Gemini CLI: 11 Hook Events
  • onStartup / onShutdown -- 生命周期
  • onQuery / onResponse -- 消息拦截
  • onToolCall / onToolResult -- 工具前后
  • onError -- 错误处理
  • onFileChange -- 文件变更
  • onSessionStart / onSessionEnd -- 会话管理
  • onContextUpdate -- 上下文变更
Claude Code: 4 Hook Events
  • PreToolUse -- 工具调用前（可拦截/修改）
  • PostToolUse -- 工具调用后（可注入信息）
  • Notification -- 通知事件
  • Stop -- Agent 停止前
  • 数量少但足够（80/20 原则）
  • Shell 脚本实现，零依赖

Gemini CLI 的扩展体系最全面，5 层扩展（Extensions + Skills + Hooks + Commands + MCP）覆盖了从生命周期到工具到 UI 的所有扩展点。11 个 Hook 事件是所有产品中最多的，使得第三方可以深度定制行为。

OpenClaw 的 ClawHub 生态最大（13,729+ 社区技能），因为 SKILL.md 的 Markdown 定义方式极大降低了贡献门槛 -- 不需要会编程，只需要写 Markdown 就能定义新工具。

Codex CLI 的 MCP 双向能力是独家的：它不仅是 MCP Client（消费其他 MCP Server 的工具），还可以作为 MCP Server 被其他工具调用。这意味着你可以在 Claude Code 中通过 MCP 调用 Codex CLI 的能力。

Claude Code 的 4 个 Hook + MCP 虽然数量少，但遵循 80/20 原则：PreToolUse 和 PostToolUse 两个钩子就覆盖了 80% 的扩展需求（权限控制、日志记录、信息注入）。Shell 脚本实现意味着零依赖，任何语言都可以写 Hook。

扩展体系的核心产品决策是「平台化 vs 专精化」。Gemini CLI 和 OpenClaw 走平台路线，提供丰富的扩展点吸引第三方生态；Claude Code 走专精路线，用少量但关键的扩展点保持核心体验的一致性。PM 需要考虑：你的产品是「操作系统」（需要生态）还是「工具」（需要精简）？

Information Sources
Claude Code: Anthropic Docs + Source Analysis
Codex CLI: GitHub (Apache-2.0) + Source Analysis
Gemini CLI: GitHub (Apache-2.0) + Source Analysis
OpenCode: GitHub (MIT, Archived) + Source Analysis
DeerFlow 2: GitHub (MIT) + Source Analysis
OpenClaw: GitHub (MIT) + Source Analysis

Generated: 2026-03-07 | Design System: cc-agent-harness.html