AI编程Agent的＂引擎＂对决:Codex、Grok、Hermes、Pi的Harness深度拆解

如果你关注过AI编程Agent这个领域，大概率已经看过无数"谁更强"的对比——SWE-bench分数、代码生成速度、支持的模型数量。

但我今天想聊的不是这些。

我想聊一个更底层、更决定性的、但几乎没人系统拆解过的东西——Harness。

什么是Harness？简单说，就是Agent的"引擎"——它怎么执行代码，怎么管理文件，怎么跟操作系统打交道，怎么保证安全，怎么扩展能力。如果说模型是Agent的大脑，那Harness就是它的躯干和四肢。

我花了相当一段时间，把目前市面上最值得研究的四个开源Agent项目——OpenAI Codex CLI、xAI Grok Build、Nous Research Hermes Agent、Earendil Works Pi——的源码翻了一遍，重点看的就是它们的Harness设计。

这四个项目，恰好代表了四种截然不同的Harness哲学。看完你会发现，Agent和Agent之间的差距，远不止模型调用那点事。

先说一个判断：Harness是Agent的"隐藏护城河"

在正式开始之前，我想先抛一个判断。

过去两年，AI编程Agent领域有一个很有意思的现象：很多看起来"模型能力很强"的产品，实际体验却很一般。反过来，有些用的模型不是最强的，但体验却出奇的好。

原因在哪？就在Harness。

一个好的Harness，能让模型的能力被充分释放。一个糟糕的Harness，会让最强的模型也像戴着镣铐跳舞。代码执行的安全性、文件读写的效率、工具调用的可靠性、扩展能力的灵活性——这些才是决定Agent"好不好用"的关键因素，而不是模型跑分。

所以这篇文章，我试图从四个维度来拆解这四个项目的Harness：

安全模型：Agent怎么防止自己（或被恶意利用）搞破坏？执行引擎：代码和命令到底怎么跑的？工具系统：Agent的能力怎么定义和扩展？状态管理：会话、记忆、上下文怎么管理？

四个项目，四个方向，各有各的精彩。

Codex CLI：OpenAI的工业级沙箱

我们先看Codex CLI。

Codex CLI是OpenAI在2025年推出的开源编程Agent，用Rust写核心，TypeScript写CLI层。如果你只用过Codex的ChatGPT网页版，那你不算真正见过Codex——它的CLI版本才是真正的"完全体"。

在Harness设计上，Codex CLI有一个非常鲜明的特征：安全至上。

这其实很好理解——OpenAI是大厂，Codex CLI要面向海量用户，用户可能在任何环境里运行它。如果Agent执行命令时把用户系统搞崩了，或者被恶意prompt注入搞出了安全问题，那是OpenAI不能接受的。

所以Codex CLI在安全上做了极其"重"的投入。

平台原生沙箱

Codex CLI最让我震撼的，是它针对三个主流操作系统都实现了原生的沙箱方案。

在Linux上，它用了Bubblewrap + Landlock LSM + seccomp三层防护。Bubblewrap是一个不需要root权限的沙箱工具，做的是用户命名空间级别的隔离。Landlock是Linux内核的一个LSM（Linux Security Module），可以做细粒度的文件系统访问控制。seccomp则是系统调用过滤——Agent进程能调哪些系统调用，不能调哪些，都在这里被限制住了。

在macOS上，它用的是Apple的Seatbelt沙箱。这是macOS原生的沙箱框架，通过sandbox profiles（.sbpl文件）来定义策略。Codex CLI在代码里自带了一套seatbelt base policy，定义了Agent进程可以访问哪些路径、可以建立哪些网络连接。

在Windows上，这个就更复杂了——Rust写的windows-sandbox-rs crate，实现了一套完整的Windows沙箱方案：Restricted Token（限制令牌，降低进程权限）、Job Objects（作业对象，限制进程资源）、WFP（Windows Filtering Platform）（网络流量过滤）、Desktop isolation（桌面隔离，防止窗口消息注入），甚至还有DPAPI（数据保护）相关处理。

ExecPolicy：执行策略即代码

除了沙箱，Codex CLI还有一个非常有意思的设计——ExecPolicy（执行策略系统）。

这个系统本质上是一个策略引擎，它在命令执行之前，会先对命令进行解析和策略匹配。比如，某些命令只能在特定目录下运行，某些命令必须经过用户确认，某些命令被完全禁止。

你可以在Codex CLI的execpolicy crate里看到完整的策略定义：rule.rs定义了匹配规则，policy.rs定义了策略决策，decision.rs定义了决策结果（允许/拒绝/需要确认）。

这个设计最妙的地方在于，它把"安全策略"从代码中抽离成了可配置的规则。不同的权限profile（PermissionProfile）可以对应不同的策略集——比如"只读模式"下写操作被拒绝，"网络隔离模式"下网络请求被拦截。

网络代理与MITM

还有一个细节值得单独拿出来说——Codex CLI的网络代理系统。

它在Agent和外部网络之间插入了一个受控的网络代理层。这个代理不仅能做请求转发，还能做MITM（中间人）的HTTPS解密——这意味着它可以对Agent发出的网络请求进行内容审计。

配合ManagedNetworkSandboxContext，这个代理系统可以做到：允许Agent访问指定的API端点，但阻止它访问内网资源；或者在Agent执行需要联网的任务时自动注入代理配置。

这套网络代理系统是Codex CLI安全架构中最被低估的部分。它其实是在解决一个很核心的矛盾：Agent需要联网才能完成任务，但联网就意味着风险。通过代理层做精细化控制，既给了Agent能力，又给了用户安全感。

我的评价

Codex CLI的Harness设计，是典型的"大厂重投入"路线。它的安全体系是全方位的、平台原生的、策略驱动的。如果你是一个企业用户，或者你的Agent要处理敏感数据，Codex CLI方案的安全成熟度目前是四个项目里最高的。

但代价也很明显——代码量巨大。光是Windows沙箱那一个crate，就包含了50+个源文件，覆盖了ACL、令牌、进程、WFP、桌面隔离等各个方面。这个体量，小团队基本不可能复现。

图片

Grok Build：xAI的企业级工作空间引擎

接下来看Grok Build。

Grok Build是xAI（Elon Musk的SpaceXAI）推出的终端AI编程Agent，也是一个Rust写的项目，而且它和Codex CLI有一个很有意思的渊源——Grok Build的代码里明确标注了部分工具实现是从OpenAI Codex移植过来的（THIRD_PARTY_NOTICES里写得很清楚）。

但在Harness设计上，Grok Build走了和Codex CLI完全不同的路。

Codex CLI的焦点是"安全"，而Grok Build的焦点是**"工作空间"**。

工作空间（Workspace）中心架构

Grok Build最核心的设计理念，是把整个Agent的运行环境抽象为一个"工作空间"（Workspace）。

这个工作空间不是简单的当前目录，而是一个包含了文件系统、会话管理、检查点、版本控制、权限控制、工具配置的完整抽象层。

来看它的crate结构：xai-grok-workspace这个crate有30+个源文件，覆盖了：

• 文件系统抽象层（file_system/）：它不是一个简单的文件读写，而是一个五层的文件系统架构——local_fs（本地文件系统）、client_fs（客户端文件系统）、ext_fs（扩展文件系统）、acp_fs（Agent Client Protocol文件系统）、mock_fs（测试用模拟文件系统）。通过adapter模式，Grok可以在不同文件系统间透明切换。
• 会话管理（session/）：checkpoint（检查点）、checkpoint_store、file_state（文件状态追踪）、git和jj（Jujutsu版本控制）集成。每个Agent会话都可以创建检查点、回滚、分支。
• 工作树（worktree/）：代码库的快速索引和浏览。
• 权限系统（permission/）：细粒度的权限控制，包括folder_trust（文件夹信任机制）。

这个设计意味着什么？意味着Grok Build的Agent可以在一个高度结构化的环境中工作——它知道哪些文件是项目的一部分，可以追踪文件的变化历史，可以在不同会话之间切换，可以回滚到任意历史状态。

沙箱：Profile驱动的策略系统

Grok Build也有沙箱——xai-grok-sandbox crate。但它的沙箱设计和Codex CLI完全不同。

Codex CLI是"平台原生沙箱"，直接调用操作系统的沙箱机制。Grok Build的沙箱是profile驱动的策略系统。

在xai-grok-sandbox的源码里，你可以看到几个核心文件：

• profiles.rs：沙箱profile定义，不同的profile对应不同的安全级别
• network_policy.rs：网络策略，控制Agent的网络访问
• paths.rs：路径策略，控制文件系统访问
• hook_write_deny.rs：写操作拒绝钩子——这是一个很巧妙的设计，它通过hook机制拦截写操作，在写入前检查策略
• child_net.rs：子进程网络管理
• **deny/**：各种拒绝规则的实现

这个设计的好处是灵活性。通过切换profile，Agent可以在"严格隔离"和"完全开放"之间灵活切换，而不需要像Codex CLI那样在代码层面做大量平台适配。

PTY Harness：终端模拟的"硬核"部分

Grok Build还有一个值得单独拎出来的组件——xai-grok-pager-pty-harness。

PTY（伪终端）是CLI Agent最难做好的部分之一。Agent需要在终端里执行命令、捕获输出、处理交互式程序（比如vim、less、数据库客户端），还要处理ANSI转义序列、终端尺寸变化、信号处理。

Grok Build的PTY harness实现了完整的终端模拟功能，包括ANSI解析、终端尺寸管理、输入输出缓冲等。这个组件的质量直接决定了Agent在终端里执行命令的可靠性和用户体验。

工具系统：MCP + 内置工具 + 插件市场

Grok Build的工具系统是三层架构：

1. 内置工具（xai-grok-tools）：终端执行、文件编辑、搜索等核心工具，部分移植自Codex CLI和OpenCode
2. MCP支持（xai-grok-mcp）：通过Model Context Protocol接入外部工具
3. 插件市场（xai-grok-plugin-marketplace）：可安装的第三方插件

这个三层架构的设计很务实——核心工具保证基础能力，MCP提供标准化扩展，插件市场满足长尾需求。

我的评价

Grok Build的Harness设计，核心关键词是**"结构化"**。它把Agent的工作环境抽象成了一个高度结构化的Workspace，在其中做文件系统、会话、权限、工具的精细管理。

如果你是一个需要管理大型代码库的团队，或者你的Agent工作流涉及复杂的文件操作和版本管理，Grok Build的Workspace架构会非常有吸引力。

相比Codex CLI的"安全优先"，Grok Build是"协作优先"——它更像是一个Agent OS，而不仅仅是一个Agent CLI。

Hermes Agent：Nous Research的自进化工具生态

第三个项目，Hermes Agent。

Hermes是Nous Research（著名的开源AI研究团队）开发的Agent，也是四个项目里唯一用Python写的。它的核心定位非常独特——**"Self-improving AI Agent"**，也就是能自我改进的Agent。

这个定位直接决定了它的Harness设计方向。

工具注册中心：一个活的工具生态

Hermes的Harness核心，是它的工具注册中心（Tool Registry）。

在Codex CLI和Grok Build里，工具是"编译进来的"——你在Rust代码里定义工具函数，编译成二进制。但在Hermes里，工具是"注册进来的"——每个工具文件在tools/目录下通过registry.register()方法注册自己的schema、handler和metadata。

这个差异看似技术细节，实际上决定了整个Agent的扩展哲学。

因为工具是运行时注册的，Hermes可以做到：

1. 动态加载和卸载：不需要重新编译，就能添加新工具
2. 条件启用：通过check_fn机制，工具只有在满足条件时才出现在模型可用的工具列表中。比如，某个工具需要特定的API key，没配置就不显示
3. 工具集（Toolset）管理：工具按功能分组为toolset，不同的场景启用不同的toolset

这套设计最妙的地方是toolset distribution系统（在toolset_distributions.py里）。它定义了不同平台（CLI、桌面版、消息网关）应该加载哪些工具集。CLI版本有终端执行工具，消息网关版本有消息发送工具，桌面版有GUI交互工具——每个平台只加载自己需要的工具，减少模型在工具选择上的开销。

技能系统：从经验中学习

Hermes还有一个其他三个项目都没有的东西——技能系统（Skills System）。

当Agent完成一个任务后，它可以"学习"这个过程，生成一个可复用的技能（Skill）。这个技能本质上是一组指令和模板，以后遇到类似的任务，Agent可以直接调用这个技能，而不需要从头推理。

技能系统在代码里对应的是skills/目录下的skill_preprocessing.py、skill_utils.py、skill_bundles.py等文件。它的核心逻辑是：从对话轨迹中提取关键步骤，生成结构化的技能描述，然后索引存储供后续检索。

这个能力让Hermes的Harness区别于其他三个——它不是一个静态的执行环境，而是一个会进化的执行环境。

子代理生命周期

Hermes还有一个很完善的设计——子代理（Subagent）生命周期管理。

在agent/subagent_lifecycle.py里，你可以看到完整的子代理管理：SubagentHandle（子代理句柄）、SubagentStatus（状态追踪）、SubagentLifecycleService（生命周期服务）。

这个系统的价值在于，它让Agent可以动态创建子代理来处理并行任务，然后统一管理这些子代理的生命周期。这在处理复杂任务时非常有用——比如，同时让三个子代理调研三个不同的技术方案，然后汇总结果。

网关架构：多平台适配

Hermes的gateway/目录是另一个值得关注的组件。它实现了一个抽象网关层，可以对接Telegram、Discord、Slack等20+个消息平台，以及TUI（终端界面）和Desktop（桌面应用）。

这个网关架构的核心价值在于，它把Agent的Harness从"单机工具"变成了"服务平台"。同样的Agent core，可以在CLI里运行，也可以在Telegram机器人里运行，还可以在桌面应用里运行——不需要修改核心代码。

我的评价

Hermes Agent的Harness设计，核心关键词是**"进化"和"生态"**。

它的工具注册中心让工具生态可以有机生长，技能系统让Agent可以自我进化，子代理系统让它可以处理复杂任务，网关架构让它无处不在。

代价是Python的性能开销——相比Rust或者TypeScript，Python在工具执行和并发处理上的性能确实有差距。但考虑到Hermes的定位是"自进化通用Agent"，这个取舍可以理解。

如果你想要一个能不断学习、不断扩展能力的Agent，Hermes是目前最独特的选择。

Pi Agent：极简主义的TypeScript轻骑

最后一个项目，Pi。

Pi是Earendil Works（一个独立开发者团队）开发的Agent，用TypeScript写成，代码量是四个项目中最少的。但它的影响力和社区关注度非常高——在GitHub上有相当可观的star数。

Pi的Harness哲学可以用一句话概括：**"最小可行工具集，最大可扩展性"**。

四工具原则

Pi默认只给Agent提供四个核心工具：read（读文件）、write（写文件）、edit（编辑文件）、bash（执行命令）。

你没看错，就四个。

在Codex CLI动辄几十个工具的情况下，Pi的四个工具显得"寒酸"。但这不是设计缺陷，这是刻意为之。

Pi的设计者认为，工具越多，模型的选择成本越高，出错的概率也越大。四个核心工具覆盖了编程Agent最核心的需求——读、写、改、跑。其他所有能力，都通过扩展（Extensions）、技能（Skills）、提示模板（Prompt Templates）来添加。

这个"少即是多"的哲学，在Pi的代码里体现得非常彻底。它的Agent核心包（@earendil-works/pi-agent-core）只有十几个源文件，核心的agent-loop.ts才几百行代码。

Agent Loop：简洁而优雅的事件驱动

Pi的Agent Loop设计得非常干净。它的核心循环在agent-loop.ts里，实现了一个完整的事件驱动机制：

prompt → agent_start → turn_start → message_start/end → 
  streamAssistantResponse → toolCalls → toolExecution → 
  turn_end → agent_end

这个循环支持：

• 并行工具执行：多个工具可以同时执行
• 顺序工具执行：需要顺序依赖的工具按序执行
• 消息队列：支持在Agent运行时注入新的用户消息
• 中止和恢复：支持AbortSignal和对话恢复

它的Agent Harness（agent-harness.ts）则是一个更高层次的抽象，管理了Lane（运行通道）、Run（运行实例）、Session（会话）、Compaction（压缩）等概念。

无内置沙箱的设计决策

Pi在安全模型上做了一个非常有意思的选择——不内置沙箱。

在README里，它明确写道："Pi does not include a built-in permission system for restricting filesystem, process, network, or credential access. By default, it runs with the permissions of the user and process that launched it."

但它提供了三种容器化方案作为替代：

1. Gondolin扩展：把工具执行路由到Linux微VM中
2. Plain Docker：把整个Pi进程跑在Docker容器里
3. OpenShell：把Pi跑在策略控制的沙箱中

这个"不做内置，但提供方案"的路线，和Codex CLI的"重安全"路线形成了鲜明对比。

Pi的取舍逻辑是：安全和便利之间存在根本矛盾。内置沙箱会增加复杂度、降低性能、限制Agent的能力。与其提供一个半吊子的内置沙箱，不如让用户自己选择合适的外部沙箱方案。

统一的多Provider LLM层

Pi的AI层（@earendil-works/pi-ai）是四个项目中最完善的LLM抽象层之一。它支持30+个Provider，包括OpenAI、Anthropic、Google、DeepSeek、xAI、Mistral、Groq、OpenRouter等。

这个层的关键设计是：

• 统一的流式接口：不管是哪个Provider，都用同样的stream/complete接口
• 自动认证解析：自动从环境变量/凭据存储中读取API key
• 工具调用标准：统一的工具定义和参数验证（基于TypeBox）
• 跨Provider切换：同一个会话中可以切换不同的Provider

这个设计意味着，Pi用户可以在Anthropic Claude和OpenAI GPT之间自由切换，甚至可以在同一个对话中切换——这在其他项目里是不常见的。

我的评价

Pi的Harness设计，核心关键词是**"极简"和"可扩展"**。

它的代码量最小，概念最简洁，但通过Extensions和Skills系统保持了极强的扩展能力。它不做内置沙箱，但给出了清晰的替代方案。它只给四个工具，但通过统一的LLM层支持了最多的Provider。

如果你是一个喜欢精简工具链的开发者，或者你的场景需要频繁切换不同的LLM Provider，Pi会是一个非常顺手的工具。

它的"少即是多"哲学，在AI Agent越来越臃肿的今天，显得格外清爽。

横向对比：四个维度，四种哲学

好了，四个项目都拆完了。我们来做一个横向对比。

安全模型

Codex CLI在安全上的投入是其他三个项目的总和都不及的。但另外三个项目也有各自的合理性——它们的目标用户和技术栈不同，对安全的需求也不同。

执行引擎

执行引擎的性能上，Rust写的Codex CLI和Grok Build明显占优。但Hermes的Python在灵活性上有优势，Pi的TypeScript在生态和开发者体验上有优势。

工具系统

Hermes的注册机制是最灵活的，Pi的"四工具原则"是最极简的，Codex CLI和Grok Build的MCP支持是最标准的。

状态管理

Grok Build的Workspace状态管理是最完整的，Hermes的技能系统是最独特的，Pi的会话分支是最简洁的。

升维：从Harness看Agent基础设施的未来

写了这么多，我想做一个更高层次的判断。

这四个项目，其实代表了Agent基础设施的四个阶段：

Codex CLI代表了"安全基础设施"阶段。它的核心问题是"Agent怎么安全地跑"。在一个Agent可能被prompt注入、可能被恶意利用的世界里，安全是0和1的问题——没有安全，其他都是0。

Grok Build代表了"环境基础设施"阶段。它的核心问题是"Agent怎么高效地工作"。当Agent需要在大型代码库中操作、需要管理复杂的文件状态、需要和版本控制系统交互时，一个结构化的Workspace是必须的。

Hermes Agent代表了"能力基础设施"阶段。它的核心问题是"Agent怎么变强"。当Agent需要不断学习新技能、需要和不同平台交互、需要处理复杂的多代理协作时，一个活的工具生态和技能系统是核心。

Pi Agent代表了"体验基础设施"阶段。它的核心问题是"Agent怎么好用"。当Agent的基本能力已经足够，用户的关注点会转向开发者体验、扩展的便利性、Provider的灵活性——Pi的极简设计和TypeScript生态就是为这个阶段准备的。

这四个阶段不是互斥的，而是递进的。一个成熟的Agent平台，最终需要同时解决安全、环境、能力、体验四个层面的问题。

但不同的项目有不同的起点和侧重点，这正好给了我们一个观察这个领域的好窗口。

最后

这篇文章我写了很长时间，不是因为资料少，而是因为资料太多了——每个项目的代码量都是万行级别的，而且每个项目的设计都有其独特的思考在里面。

我尽量从"设计哲学"的层面去理解它们，而不是简单地罗列功能。因为我始终觉得，对于一个开发者来说，理解一个项目"为什么这么设计"，比知道它"有什么功能"要重要得多。

这四个项目，我自己的使用频率从高到低是：Pi > Hermes > Grok Build > Codex CLI。但这不代表排名——每个项目都有自己的目标用户和适用场景。我建议你把这四个项目都拉下来跑一跑，看看哪种Harness哲学更符合你的需求。

毕竟，工具没有最好的，只有最适合的。

以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～谢谢你看我的文章，我们，下次再见。