如果你关注过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 CLIOpenAI的工业级沙箱我们先看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内核的一个LSMLinux 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作业对象限制进程资源、WFPWindows Filtering Platform网络流量过滤、Desktop isolation桌面隔离防止窗口消息注入甚至还有DPAPI数据保护相关处理。ExecPolicy执行策略即代码除了沙箱Codex CLI还有一个非常有意思的设计——ExecPolicy执行策略系统。这个系统本质上是一个策略引擎它在命令执行之前会先对命令进行解析和策略匹配。比如某些命令只能在特定目录下运行某些命令必须经过用户确认某些命令被完全禁止。你可以在Codex CLI的execpolicy crate里看到完整的策略定义rule.rs定义了匹配规则policy.rs定义了策略决策decision.rs定义了决策结果允许/拒绝/需要确认。这个设计最妙的地方在于它把安全策略从代码中抽离成了可配置的规则。不同的权限profilePermissionProfile可以对应不同的策略集——比如只读模式下写操作被拒绝网络隔离模式下网络请求被拦截。网络代理与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 BuildxAI的企业级工作空间引擎接下来看Grok Build。Grok Build是xAIElon 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_fsAgent Client Protocol文件系统、mock_fs测试用模拟文件系统。通过adapter模式Grok可以在不同文件系统间透明切换。会话管理session/checkpoint检查点、checkpoint_store、file_state文件状态追踪、git和jjJujutsu版本控制集成。每个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/**各种拒绝规则的实现这个设计的好处是灵活性。通过切换profileAgent可以在严格隔离和完全开放之间灵活切换而不需要像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的工具系统是三层架构内置工具xai-grok-tools终端执行、文件编辑、搜索等核心工具部分移植自Codex CLI和OpenCodeMCP支持xai-grok-mcp通过Model Context Protocol接入外部工具插件市场xai-grok-plugin-marketplace可安装的第三方插件这个三层架构的设计很务实——核心工具保证基础能力MCP提供标准化扩展插件市场满足长尾需求。我的评价Grok Build的Harness设计核心关键词是**结构化**。它把Agent的工作环境抽象成了一个高度结构化的Workspace在其中做文件系统、会话、权限、工具的精细管理。如果你是一个需要管理大型代码库的团队或者你的Agent工作流涉及复杂的文件操作和版本管理Grok Build的Workspace架构会非常有吸引力。相比Codex CLI的安全优先Grok Build是协作优先——它更像是一个Agent OS而不仅仅是一个Agent CLI。Hermes AgentNous 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可以做到动态加载和卸载不需要重新编译就能添加新工具条件启用通过check_fn机制工具只有在满足条件时才出现在模型可用的工具列表中。比如某个工具需要特定的API key没配置就不显示工具集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或者TypeScriptPython在工具执行和并发处理上的性能确实有差距。但考虑到Hermes的定位是自进化通用Agent这个取舍可以理解。如果你想要一个能不断学习、不断扩展能力的AgentHermes是目前最独特的选择。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 Harnessagent-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.但它提供了三种容器化方案作为替代Gondolin扩展把工具执行路由到Linux微VM中Plain Docker把整个Pi进程跑在Docker容器里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 ProviderPi会是一个非常顺手的工具。它的少即是多哲学在AI Agent越来越臃肿的今天显得格外清爽。横向对比四个维度四种哲学好了四个项目都拆完了。我们来做一个横向对比。安全模型项目安全方案理念Codex CLI平台原生沙箱Bubblewrap/Landlock/Seatbelt/Restricted Token ExecPolicy 网络代理安全是默认的智能是可扩展的Grok BuildProfile驱动的沙箱策略 网络策略 写拒绝钩子灵活的安全层可切换的隔离级别Hermes Agent无内置沙箱依赖容器化部署Docker安全在部署层解决不在应用层Pi Agent无内置沙箱提供三种容器化方案文档做安全不如做灵活让用户自己选Codex CLI在安全上的投入是其他三个项目的总和都不及的。但另外三个项目也有各自的合理性——它们的目标用户和技术栈不同对安全的需求也不同。执行引擎项目语言执行方式特点Codex CLIRustexec-server沙箱内执行高性能沙箱封装Grok BuildRustWorkspace内执行PTY harness带终端模拟结构化环境Hermes AgentPython工具函数直接调用灵活但性能开销大Pi AgentTypeScript子进程执行bash tool轻量依赖Node.js进程管理执行引擎的性能上Rust写的Codex CLI和Grok Build明显占优。但Hermes的Python在灵活性上有优势Pi的TypeScript在生态和开发者体验上有优势。工具系统项目工具数量扩展方式设计哲学Codex CLI多20内置工具MCP 插件丰富内置 标准扩展Grok Build多分层工具集MCP 插件市场内置 市场双轮驱动Hermes Agent丰富工具集分组注册机制 技能 MCP活的工具生态可进化Pi Agent极少4个核心工具Extensions Skills最小核心最大扩展Hermes的注册机制是最灵活的Pi的四工具原则是最极简的Codex CLI和Grok Build的MCP支持是最标准的。状态管理项目会话管理记忆/技能状态持久化Codex CLI会话历史 ThreadStore记忆系统本地持久化Grok Build检查点 文件状态 Git集成无专用记忆系统完整Workspace状态Hermes Agent对话管理 压缩技能系统从经验学习本地持久化 云端Pi Agent会话分支 压缩无内置记忆SQLite后端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哲学更符合你的需求。毕竟工具没有最好的只有最适合的。以上既然看到这里了如果觉得不错随手点个赞、在看、转发三连吧如果想第一时间收到推送也可以给我个星标⭐谢谢你看我的文章我们下次再见。