Codex vs 开源 Agent 框架对比

调研时间：2026-06-22

对比对象：LangGraph / CrewAI / AutoGen / tRPC-Agent

一句话定位

Codex 是唯一用系统级语言（Rust）实现、带 OS 内核沙箱、面向本地开发的开源 coding agent；其他框架是 Python/TS 编排库，侧重灵活性和多 provider 支持。Codex 选择了”深度安全 + 极致性能”路线，代价是灵活性和生态开放度。

全景对比表

维度深度分析

1. 执行模型

flowchart LR
    subgraph Codex["Codex: 线性 Turn 循环"]
        T1[Turn 1] --> T2[Turn 2] --> T3[Turn 3]
        T2 -.->|spawn| SA[SubAgent]
    end
    
    subgraph LG["LangGraph: 有向图"]
        A[Node A] -->|条件| B[Node B]
        A -->|条件| C[Node C]
        B --> D[Node D]
        C --> D
    end
    
    subgraph Crew["CrewAI: 角色委派"]
        R[Researcher] --> W[Writer]
        W --> E[Editor]
        R -.->|delegate| W
    end

Codex 的 Turn 循环是命令式的——模型在每个 turn 内自由调用工具，直到产出最终回答。没有预定义的执行图。

LangGraph 的图是声明式的——开发者预先定义节点、边和条件，框架按图执行。

CrewAI 是角色式的——每个 Agent 有固定身份和工具集，通过 Task 分配协调。

Codex 为什么不用图？

Codex 的设计假设是”模型足够聪明，不需要人工编排”。单 agent 循环让模型自己决定调用顺序，降低了框架复杂度。代价是：复杂工作流无法被显式建模和调试。

[源码] codex-rs/agent-graph-store/ 的存在暗示图能力可能正在开发中。

2. 安全隔离

flowchart TD
    subgraph Codex_S["Codex 安全层"]
        EP[ExecPolicy 规则引擎] --> AP[三阶段审批]
        AP --> SB[OS 沙箱<br/>Seatbelt/bwrap/seccomp]
        SB --> ESC[Escalation 降级]
    end
    
    subgraph Others["其他框架"]
        NONE[无安全层<br/>或仅 Docker]
    end

[源码] codex-rs/execpolicy/：基于 Starlark 的规则引擎，支持 prefix_rule、regex_rule 等策略定义。

为什么这很重要？

在企业环境中，coding agent 需要执行任意 shell 命令。没有 OS 级沙箱意味着一次 prompt injection 就可能导致数据泄露或系统损坏。Codex 是目前唯一在生产环境解决这个问题的开源框架。

3. 上下文管理

Codex 的 auto-compaction 优势：长对话不会 OOM，且 handoff summary 保留任务上下文。 劣势：压缩质量依赖模型能力，早期细节可能丢失。

[源码] codex-rs/core/src/compact.rs，codex-rs/core/src/compact_remote_v2.rs

4. 模型提供商

pie title 模型 Provider 支持范围
    "Codex" : 5
    "LangGraph/CrewAI" : 50
    "AutoGen" : 20
    "tRPC-Agent" : 10

关键约束：Codex 仅支持 Responses API wire format。Chat Completions API 兼容的 provider 无法直接使用。这是最大的生态限制。

[源码] codex-rs/model-provider-info/src/lib.rs — Chat API 已被显式移除并报错。

5. 持久化与记忆

Codex 的 git-baseline 记忆系统独特之处：用 git diff 检测”什么变了”来触发记忆更新，而非简单的时间窗口或 embedding 距离。

[源码] codex-rs/memories/README.md，codex-rs/git-utils/src/baseline.rs

6. 开发者体验

Codex 独有竞争力

1. OS 级安全（无竞品）

三平台内核沙箱 + Starlark 策略引擎 + 五级审批流。这是 coding agent 商业化的关键门槛——没有安全保证的 agent 难以进入企业生产环境。

2. 性能（Rust 实现）

124 个 Rust crate 的 workspace，原生二进制启动速度和内存效率远超 Python 框架。对于高频短任务场景（如 IDE 内联补全），这是关键优势。

3. 统一协议（JSON-RPC 2.0）

一个协议驱动所有前端——CLI、桌面、IDE、移动端。其他框架通常只有 Python SDK，无标准化的 IDE 集成协议。

4. Git-Baseline 记忆

用版本控制 diff 驱动记忆更新，天然与开发者工作流对齐。其他框架的记忆系统（向量 DB、检查点）与代码版本控制是割裂的。

5. 项目级指令（AGENTS.md）

分层的项目指令系统（root → subdir → override），让团队可以在 repo 级别统一 agent 行为。最接近的竞品是 Cursor 的 .cursorrules，但没有层级覆盖。

Codex 相对劣势

1. 模型 Provider 锁定

仅支持 Responses API 意味着无法使用 Anthropic Claude、Google Gemini 等通过 Chat Completions API 接入的模型。对于需要多 provider fallback 的企业场景，这是硬伤。

2. 无声明式工作流

没有 LangGraph 式的图定义能力。复杂的多步骤工作流（如”研究 → 起草 → 审查 → 修改”）无法被显式建模，只能依赖模型自行规划。

3. 弱多 Agent

只有子进程 spawn，没有：

• 角色分工协作（CrewAI）
• 多 agent 讨论/辩论（AutoGen GroupChat）
• 条件路由到不同 agent（LangGraph）

agent-graph-store crate 暗示此能力正在开发。

4. 无向量搜索/RAG

只有 BM25 文件搜索，无 embedding-based 语义搜索。对于需要从大型知识库检索的场景（如文档问答），不如 LangGraph + Retriever 或 CrewAI RAG Tool。

[源码] codex-rs/file-search/：依赖 bm25 = "2.3.2"，无向量 DB 依赖。

5. 贡献门槛高

Rust 生态相比 Python 社区小很多。想贡献 Codex 需要 Rust + 系统编程经验，降低了社区参与度。

适用场景推荐

与 Claude Code 的差异（待 Agent A 核对）