摘要同样在终端里输入一句「帮我修这个 bug」Pi、Codex 和 Grok Build 表面上都会开始读文件、跑命令、改代码。可一旦把仓库打开事情就没那么像了。Pi 更像一套可以拆开重组的乐高底板它把多模型适配、Agent 循环、终端 UI、会话存储和编码助手拆成独立包默认功能很克制计划模式、子代理、权限门都留给扩展作者决定。Codex 更像一辆已经装好安全带、仪表盘和行车记录仪的量产车Rust 核心、线程会话、审批策略、执行策略、沙箱和 App Server 被组织成一条受治理的执行链。Grok Build 则有点像一个自带任务调度中心的工程车间以 ACP 会话为骨架把任务并发、Agent Profile、Skills、Plugins、Hooks、MCP、LSP、跨会话记忆和 OS 级沙箱一起带进了核心产品。这篇文章的结论并不神秘三者的分水岭不是「谁的模型更聪明」而是「谁拥有工作流的控制权、谁承担安全治理、谁为复杂度买单」。想把 AI 编码助手当作可编程基础设施Pi 的开放边界很有吸引力需要稳定、安全、低配置地完成日常工程任务Codex 的一体化治理更省心需要把并行 Agent、组织化规则和插件生态当成一等能力Grok Build 的能力面最宽同时也最需要认真治理。如果你只想要一个答案先记住这句话Pi 适合做自己的车Codex 适合开一辆可靠的车Grok Build 适合运营一支车队。下面把这句话拆开讲免得它听上去像一句写在会议室墙上的空话。从一个「修 bug」请求开始三种 Agent 到底在解决什么想象一个不怎么戏剧化、却很常见的周二下午。线上订单接口偶发 500日志指向一个并发分支。你不希望 AI 只说「建议检查空指针」更希望它能读仓库规则、搜索调用链、跑一个定向测试、改动最小的一处并把它为什么这么改讲清楚。这件事乍一看只有一个循环人给任务模型调用工具工具返回结果模型继续想最后给答案。所有编码 Agent 的心脏确实都是这个循环。真正拉开差距的是循环外面那一大圈并不浪漫的工程问题谁把模型 API 变成统一消息格式工具调用是否可并行命令该不该先审批项目目录里的扩展是否可信长会话爆掉后如何压缩上下文任务能否拆给子 Agent会话如何回放、分叉、导出IDE、桌面端和终端又如何共用同一套协议把这些问题放在一起看三者其实代表了三种产品哲学。Pi 的仓库首页把自己定义为Pi Agent Harness。这里的 Harness 不是一个故作高级的词它意味着 Pi 的重点并非替用户规定唯一工作流而是提供一副可接上不同模型、不同工具、不同 UI 和不同会话存储的「缰绳」。它的 coding-agent CLI 只是这副缰绳最完整的一种现成装配。Codex CLI 则明确是一款在本机运行的 OpenAI coding agent。它当然也开放源码也有 SDK、App Server 和插件等扩展面但从codex-rs的目录划分就能看出另一种重心core、protocol、app-server、execpolicy、linux-sandbox、shell-escalation、thread-store、process-hardening。它不只关心「模型能不能调用 shell」还关心「谁批准、在哪儿执行、允许什么网络、如何跨客户端保持线程」。Grok Build 的仓库则把自己定义为终端 AI coding assistant 和 agentic harness并同时提供 TUI、headless 模式与 ACP。它的 workspace 里有xai-grok-shell、xai-grok-agent、xai-grok-tools、xai-grok-workspace、xai-grok-mcp、xai-grok-memory、xai-grok-sandbox、xai-grok-plugin-marketplace、xai-prompt-queue等大量专门 crate。它的姿态很明确不只让一个 Agent 干活还要让一组可配置角色、工具和外部系统在长期任务里协作。所以先把一个常见误区放下。三个项目并不是「同一个 CLI 换了三个大模型」。它们在回答不同问题。Pi 问的是怎样让开发者快速拥有一个自己能改的 Agent 运行时Codex 问的是怎样把本地编码 Agent 变成可控、可审核、可被多个客户端消费的产品能力Grok Build 问的是怎样把复杂 Agent 工作流里的角色、任务、规则、集成和隔离做成可以组合的操作系统问题不同优劣就必须跟着换。用「功能数量」给它们排座次跟用瑞士军刀评价扳手一样都有点委屈工具。Pi 的项目背景与技术架构Pi 使用 TypeScript、Node.js 和 npm workspaces 构建。根目录的package.json显示它以多包仓库发布而不是把所有逻辑塞进一个巨型 CLI。当前核心包可以概括为下面五层。用户 / 自动化调用 | -- pi-coding-agent 交互式 CLI、print/JSON、RPC、SDK 入口 | | | -- pi-agent-core 通用 Agent 状态、循环、工具与会话抽象 | | | | | -- pi-ai 多供应商模型、流式传输、认证、模型目录 | | | -- pi-tui 差分渲染终端组件库 | -- pi-storage-sqlite-node 可选 SQLite 会话后端 -- pi-server 实验性的服务端/IPC 能力这张图有一个很关键的细节pi-coding-agent并不等于pi-agent-core。前者是面向人类开发者的产品壳负责命令行参数、交互模式、模型选择、项目可信任判断、扩展加载、内置读写工具以及会话界面后者则是一个更通用的 Agent runtime。换句话说想在内部平台里嵌入 Pi 的循环不一定要把那套终端界面也一起搬进去。第一层pi-ai把模型差异压到边界packages/ai的定位是统一 LLM API。其源码不仅有 OpenAI、Anthropic、Google 的实现还包含 Azure OpenAI、Amazon Bedrock、Mistral、xAI、OpenRouter、DeepSeek、Groq、GitHub Copilot、Cloudflare、Hugging Face 等 provider 模块以及 OAuth、credential store、模型生成脚本和 image model 注册表。这不是简单地把不同 SDK 包一层。真正的价值在于Agent 循环面对的是统一的Model、消息、流事件、工具参数校验和使用量语义不同供应商 API 的流式差异、认证方式、模型目录以及响应格式留在 provider 适配层处理。packages/ai/src/api/中专门存在 OpenAI Responses、Anthropic Messages、Google Generative AI、Bedrock Converse Stream 等适配文件就是这种边界设计的直接证据。对于使用者这带来一个非常实际的能力在 Pi 的/model或配置中切换模型往往不需要改动 Agent 本身的工具定义和会话逻辑。对于平台开发者这也意味着自建兼容 OpenAI、Anthropic 或 Google 协议的网关可以被接入如果 API 或 OAuth 不兼容则可以用扩展补齐。当然统一层不是魔法。各模型的工具调用可靠性、上下文窗口、推理预算、图片支持、缓存计费和策略限制仍然不同。Pi 做的是让这些差异有一个共同接口而不是承诺它们从此表现一样。把不同模型当成同一种螺丝刀最后通常会拧坏一颗螺丝。第二层pi-agent-core一个小而完整的 Agent 心脏packages/agent/src/agent.ts中的Agent类是理解 Pi 的入口。它持有系统提示词、模型、消息、工具、流状态、待执行工具调用和错误状态并通过订阅机制向 UI 或宿主发出生命周期事件。核心状态不是藏在 CLI 里而是可被宿主接管的对象。它提供了两个非常值得注意的队列。Steering queue当前助手回合完成工具调用后尽快插入用户新消息。Follow-up queueAgent 原本准备结束后再进入下一轮处理。终端里 Enter 与 AltEnter 的差别背后并不只是快捷键花样。它是对人机协作时序的建模。用户可以在 Agent 跑很久时纠偏又不必粗暴取消整个回合也可以先把下一件事放到队列里等当前任务收尾。这种机制在长时间修复、批量重构和探索性调试中很有用尤其适合那种「先别碰数据库先把测试跑出来」的临时指令。真正执行推理的agent-loop.ts保持得很干净。它使用streamFn向模型发起流式调用在 LLM 调用边界才把内部AgentMessage[]转成 provider 所需的消息格式收到助手消息后校验工具参数、执行工具、收集toolResult再决定是否继续。AgentOptions还给出beforeToolCall、afterToolCall、prepareNextTurn、transformContext、convertToLlm等钩子。把核心思路压缩成伪代码大致是这样。for (;;) { const context await transformContext(transcript); const reply await streamFn({ model, tools, context }); append(reply); const results await executeToolCalls(reply, { beforeToolCall, afterToolCall }); append(results); if (steeringQueue.hasItems()) append(steeringQueue.drain()); else if (reply.hasToolCalls()) continue; else if (followUpQueue.hasItems()) append(followUpQueue.drain()); else break; }代码实际比这多了错误处理、事件流、abort signal、重试、并行工具执行以及上下文准备但控制骨架就是这么直接。这里有一个很好的工程判断Pi 没有把「Agent」做成不可拆的黑箱而是把最容易因业务而变化的环节暴露为函数和事件。第三层coding-agent把默认体验做小而不是做弱packages/coding-agent是用户通常运行的pi。它默认只给模型四个工具read、write、edit和bash。相较于把搜索、规划、浏览器、子代理、记忆、工单系统全塞进第一屏的产品这个默认值近乎克制。但克制不等于简陋。CLI 具备交互模式、单次 print/JSON 输出、进程集成 RPC 模式和 SDK 使用方式交互层支持文件引用、路径补全、图像粘贴、外部编辑器、!与!!shell 命令、会话树、分叉、克隆、上下文压缩、HTML/JSONL 导入导出、模型登录和切换。它的一个重要设计是把「高级能力」降为可安装或可编写的扩展。Pi 的 TypeScript Extension API 可以注册工具、命令、快捷键、事件处理器和 UI 组件也可以改写 compaction、加入权限门、接 MCP、实现子代理或计划模式。README 甚至非常坦白地写着Pi 默认跳过 sub agents 和 plan mode用户可以安装第三方 Pi package或者让 Pi 自己帮你做一个。这句话既是 Pi 的魅力也是它的门槛。它不替团队决定流程所以团队必须真的愿意决定流程。第四层pi-tui终端 UI 不是日志打印机终端 Agent 的体验常常被低估成「颜色好看一点」。Pi 的pi-tui却把它单独做成包提供组件、输入、编辑器、Markdown、选择器、终端抽象与虚拟终端测试支持。它使用三种渲染策略首次完整输出终端宽度变化或视口上方变化时完整重绘普通更新时只移动到第一行变化处清除并重绘变化行。更新被 ANSI synchronized output 包围以减少撕裂和闪烁。对一个不断流式输出、工具结果又会折叠展开的 TUI 来说这不是炫技而是避免终端变成一锅刚煮开的面条。它还明确处理 East Asian width、ANSI 截断、输入法硬件光标定位与图片协议回退。中文开发者会知道能正确显示中文并不等于输入法候选框会出现在正确位置能运行的 TUI 与能长期使用的 TUI中间往往隔着这些看似琐碎的细节。第五层会话、压缩与信任边界Pi 默认把会话保存为~/.pi/agent/sessions/下按工作目录组织的 JSONL 文件。消息条目拥有id与parentId因此一个文件可以表示树状历史。/tree可以跳回任意历史点继续/fork创建新会话/clone复制当前分支。上下文压缩是有损的但原始完整历史仍留在 JSONL用户可以回到树中查看。这是一种很朴素、也很工程化的选择。JSONL 不像数据库那样显得「高级」但它便于导出、版本化检查、离线分析和故障恢复。Pi 同时提供pi-storage-sqlite-node说明持久化层也没有被永久锁死。对于希望把会话接到企业数据服务的团队这是好消息。Pi 还有 project trust如果项目目录带有.pi设置、扩展、资源或本地 skills交互启动时会询问是否信任。未信任前项目局部扩展和设置不会加载。这个机制防的是「进入一个仓库就自动执行仓库作者放进去的 TypeScript 扩展」这类供应链问题。不过必须把边界说清楚project trust 不是沙箱。Pi 的根 README 明确说明它不内置限制文件系统、进程、网络或凭据的权限系统默认继承启动进程的权限第三方 Pi package 也以完整系统权限运行。需要强边界时官方建议使用 Gondolin 扩展、Docker 或 OpenShell 等外部容器/沙箱方案。这一点非常重要。它不是 Pi 的「小缺陷」而是它为可编程性做出的设计选择。Pi 把安全执行环境当成可替换外壳而没有把它焊死在核心里。对个人高级用户这很自由对有密钥、生产库和合规要求的组织这意味着不能只安装完就说「上吧」。Pi 的核心实现为什么说它是 Agent Harness 而不只是 CLI如果只看pi命令很容易把它误判为又一个终端聊天程序。看完代码后我更愿意把它叫作「可脚本化的 Agent 装配线」。原因有四个。1. 把模型调用当成可替换 transport而不是程序中心在Agent构造选项中streamFn、getApiKey、onPayload、onResponse、transport和thinkingBudgets都是显式概念。streamFn让模型调用逻辑可以替换transport可以表达 SSE、WebSocket 或自动选择思考级别和 token budget 不是散落在 UI 代码里的魔法数。这使 Pi 能覆盖交互终端、无头脚本、RPC 和嵌入 SDK。真正复用的不是终端页面而是「输入如何变成上下文流如何变成事件工具结果如何再进入下一轮」这条链。2. 把工具生命周期当成政策插点很多 Agent 框架只把工具当函数表模型给 JSON程序调函数。Pi 的beforeToolCall和afterToolCall则给了一个更有价值的插点。你可以在工具前做路径白名单、命令审批、审计记录、工作树快照、成本预算在工具后做结果脱敏、失败重试、变更统计或自动测试触发。例如一个企业内部扩展完全可以用下面的思路阻止生产配置被改写。代码只是说明接口位置生产场景还应加入路径规范化、符号链接处理和审计。pi.on(tool_call, async (event, ctx) { if (event.toolName write event.input.path.startsWith(infra/prod/)) { return { block: true, reason: 生产基础设施目录必须走变更流程 }; } await ctx.audit.append(event); });这里的重点不是这几行代码而是 Pi 的内核确实把这类策略留在了扩展层。它给你的不是一个「也许可以二开」的承诺而是运行时已经存在的事件和工具包装边界。3. 把会话视为可分叉数据而不是一条不可回头的聊天记录会话树的价值在复杂工程任务里比「记住上次聊天」大得多。假设 Agent 提出了两条修复路径一条做空值保护一条重构并发队列。你可以在同一个会话树上回到分叉点各试一条而不是复制粘贴一整段历史重新提问。这种设计还天然适合调试 Agent 自身。某次上下文压缩后模型开始跑偏回到压缩前节点。某个扩展在第 15 轮引入了错误命令导出 JSONL对照工具事件。Agent 在这里不只是聊天对象也是可检查的执行记录。4. 把「默认少」变成生态插槽Pi 的扩展系统能加载本地或 package 化的 TypeScript 模块Skills 使用 Agent Skills 标准prompt template、theme、extensions 又可打包成 Pi package。它还会从AGENTS.md或CLAUDE.md读取项目规则。这让 Pi 很适合下面这类团队已经有成熟的工程规范、私有工具、模型路由、审批系统和内部知识库不希望为了使用编码 Agent 而迁移到另一个封闭工作流。它可以像适配器一样嵌入现有体系。代价也很诚实。默认没有现成子代理和计划模式意味着「开箱即用地并发研究、拆任务、聚合结果」不是 Pi 的默认强项。你要么安装可信扩展要么自己实现要么接受单 Agent 的简单流程。自由不是免付费午餐只是账单换成了工程设计时间。Pi 的使用方式与真正适合的应用场景从安装到第一次可靠任务Pi 的常规安装方式如下。官方推荐 npm 安装时带--ignore-scripts它不依赖生命周期脚本完成正常安装。npm install -g --ignore-scripts earendil-works/pi-coding-agent # 任选一个已配置的 provider或启动后用 /login export ANTHROPIC_API_KEY... pi进入交互模式后先用/login完成订阅或 API key 认证再用/model选择模型。可以引用项目文件/resume恢复会话/tree查看分支/compact手动压缩上下文。单次自动化任务可以走 print 或 JSON 模式进程集成可走 RPC这些模式共用的仍是同一个 Agent 核心。使用时最值得建立的不是一堆花哨 prompt而是三层规约。第一层是AGENTS.md放项目不可违反的事实代码风格、测试命令、不可编辑目录、部署禁令、提交规范。第二层是 skill把可复用但不需要每回合塞进上下文的流程写成按需加载的说明。第三层才是 extension用代码实现工具、权限拦截、模型路由和外部系统接入。这三个层次不要混。把安全策略写成一句「请不要删除文件」并不等于实现了安全策略让模型记住 API 规范也不等于把 API 文档接成工具。人类在凌晨两点会犯错模型在下午两点也会能由程序约束的事就别只交给语气词。Pi 最适合的四类场景第一类多模型和多账户的个人高级工作台。你可能白天使用团队的 Claude 或 ChatGPT 订阅晚上调用公司网关上的模型偶尔还要比较 DeepSeek、Gemini、xAI 或本地 llama.cpp。Pi 的 provider 层与模型选择天然适合这种环境。它让工作流和模型解绑模型换了工具与会话树不需要重写。第二类内部开发者平台的 Agent 底座。如果公司已有单点登录、代码扫描、变更审批、工单系统和审计平台最现实的需求通常不是再买一个「万能聊天窗」而是把 Agent 嵌入已有控制面。Pi 的pi-agent-core、扩展、RPC/SDK、可替换 storage 都很合适。你可以把公司流程装到它的钩子上而不是反过来让公司流程迁就产品固定形状。第三类重视会话可回放的探索和调试。排查跨模块 bug、尝试两种重构方案、训练团队如何与 Agent 协作时会话树和 JSONL 导出特别实用。它允许你保留历史和分支而不是把每次尝试都变成一次性聊天。第四类想构建垂直 Agent 的小团队。比如数据工程团队需要一个只会读数据字典、生成 dbt 变更、运行受限 SQL 检查的 AgentSRE 团队需要一个能读告警、查询 CMDB、生成变更计划但不能直接生产执行的 Agent。Pi 不会替你造完整成品却能让你在既有 Agent 循环上加出合适外壳。它不那么适合什么如果团队想要开箱即用的多 Agent 编排、内建 OS 权限隔离、统一企业管理和极低的二开成本Pi 不应被硬拗成答案。给一辆可改装赛车装上班车座椅当然也能开只是你会开始怀疑人生。Codex 的工程路线安全治理为何被放进核心Codex 的代码主体位于codex-rs主力实现语言是 Rust。根 README 的入口很直接安装后运行codex通过 ChatGPT 账户或 API key 登录。它还覆盖 IDE 集成、桌面应用和云端 Codex Web。从工程形态看Codex 最值得关注的不是「它有终端 UI」而是它把本地 Agent 作为一套多客户端共享的服务能力来组织。Rust 核心与 App ServerUI 不是唯一宿主codex-rs/core承担核心运行时codex-rs/protocol定义内部和外部通信类型codex-rs/app-server则把能力暴露给客户端。TUI 代码通过 App Server 会话工作而不是把所有 agent 决策埋在界面事件里。App Server README 中可以看到典型的thread/start请求指定cwd、模型、审批策略、sandbox、人格、动态工具或能力根目录得到threadId后再由客户端消费事件。这个结构带来两个直接好处。一是终端、IDE、桌面端、未来的远程控制端可以共享线程和协议语义不必每个客户端自己再实现一遍工具状态机。二是治理可以落在服务层审批、配置、MCP 状态、插件、线程持久化与权限 profile 不必由每个 UI 各自猜一套。这也是为什么 Codex 源码里有thread-manager、thread-store、rollout-trace、app-server-daemon等模块。它把一次 Agent 运行建模为可恢复的线程和 rollout而不是一串只在终端内存里流过的文本。审批、执行策略与沙箱把「能不能做」从 prompt 里拿出来安全是编码 Agent 最容易被说得漂亮、做得含糊的领域。Codex 的目录划分相当明确execpolicy用于命令执行策略linux-sandbox负责 Linux 沙箱相关能力另有shell-escalation、network-proxy、process-hardening等模块。TUI 侧还显式处理 Exec Approval、Apply Patch Approval、MCP elicitation 等交互请求。从 App Server 的线程启动参数也能看到approvalPolicy和sandbox是独立控制面。例如可指定approvalPolicy: never和sandbox: workspaceWrite还可选择更细的 permission profile。它表达的并不是「模型自己答应不乱来」而是程序在工具执行之前评估政策、必要时请求用户决定。这套结构在企业环境里非常有价值。一个 Agent 最危险的时刻通常不是它回答错了一句而是它真的执行了命令删错目录、上传密钥、改错基础设施、把网络请求打到不该去的地方。将审批和沙箱做进内核会降低不同扩展作者各自实现安全门而漏掉边角的风险。但也别把它神化为绝对安全。沙箱强度依赖平台、配置和运行环境权限策略再细用户主动批准高风险操作后风险仍然存在工具和 MCP 的供应链同样需要审计。安全不是一个开关而是一张由目录、进程、网络、身份、审核和日志组成的网。Codex 做得更像一套网而不是在屏幕上贴一张「请小心」的便签。线程、子 Agent 与产品化复杂度Codex 的core中存在 Agent control、ThreadManager、rollout budget、父子线程关系和 subagent 相关实现TUI 也有 agent navigation 与 side thread 状态。这说明它已经把并发协作当作核心运行时语义处理而非只靠 prompt 约定「你去开三个子任务」。好处是明确的线程拥有身份、来源、状态、预算和可恢复历史父子任务可被管理客户端有机会展示真实活动状态。缺点也同样明确概念更多升级和调试成本更高扩展时必须遵循既有协议与治理边界。产品越像一架民航客机驾驶舱按钮就越不可能只有两个。Codex 适合谁如果你的团队主要使用 OpenAI/Codex 生态希望从 CLI 延伸到 IDE、桌面或服务端并且最看重本地执行的审批、工作区隔离、统一线程与成熟产品体验Codex 是非常自然的选择。它尤其适合「多数开发者需要可预测默认行为少数平台团队再做受控扩展」的组织。它相对不占优的地方是把多模型路由当作核心生产需求的场景。Pi 在这一点上是从架构第一天就做 provider abstractionCodex 的默认用户旅程则围绕 ChatGPT 账户、OpenAI 模型与 Codex 产品面。即便配置和协议允许延展两者的重心也不同。前者鼓励你换发动机后者更擅长把同一套发动机周围的底盘、安全系统和仪表整合好。Grok Build 的工程路线ACP、任务与插件如何成为一等公民先说明命名。本文将本机grok-build仓库中的终端产品简称为 Grok Build其 npm 包名是xai-official/grok最终二进制以grok形式发布。它的主语言同样是 Rust根Cargo.toml是自动生成的 workspace 描述列出数十个 crate。如果 Pi 给人的感觉是「小内核加扩展槽」Codex 是「安全治理型产品平台」Grok Build 的气质则更偏「大规模工作流运行时」。它把 Agent、任务、会话、TUI、工具、工作区、MCP、内存、Hook、Plugin、Sandbox、LSP 和模型配置分别拆给专门模块。ACP让 Agent 与宿主之间有共同语言Grok Build 支持交互 TUI、headless 命令和grok agent stdio的 Agent Client Protocol 模式。这里的 ACP 可以理解为 Agent runtime 与 IDE/客户端之间的协议边界。TUI 不必假装自己是全部世界它是 ACP clientxai-grok-shell则承担 agent runtime、leader/stdio/headless 入口。xai-grok-pagerREADME 把 TUI 架构写得很清楚AppView管全局配置和会话AgentView管单会话的 prompt、scrollback、工具面板与弹窗PromptWidget管文件搜索、slash command 和历史输入会走 Action - dispatch - Effect - state update 的 Elm 风格单向流。这种架构的好处是状态更新的来源更可追踪。工具事件、终端输入、异步 ACP 响应不会随意互相改状态而是经过 action/effect 分发。对于一个既能跑后台任务、又能切换任务面板、还要显示并行子 Agent 的 TUI这种纪律很有必要。否则终端界面很快会发展成一锅「是谁把状态改掉了」的悬疑剧。Agent Profile把角色定义从 prompt 文本升级为可验证配置xai-grok-agent把 Agent 定义做成 Markdown 正文加 YAML frontmatter。一个 definition 可以声明名称、描述、工具 allowlist/denylist、permission mode、预加载 skills、是否注入 AGENTS.md、输出风格、bash 超时与输出限额、工具重命名以及更有意思的 completion requirement。completion requirement 的含义是某个 worker 不能仅靠输出一段「我完成了」就结束而应调用指定的complete_task工具如果没有调用运行时可按重试策略提醒或恢复。这个设计非常有代表性。它把多 Agent 协作里最脆弱的口头约定往前推成了运行时协议。一个简化的定义类似这样。--- name: code-reviewer description: 只读审查关注安全和回归 tools: [read_file, grep_search, list_dir] disallowedTools: [bash, search_replace] permissionMode: plan skills: [secure-review] --- 先建立证据链再按严重程度输出问题。没有证据时明确说明。这和 Pi 的 Skill/Extension 并不冲突但层次不同。Pi 更倾向于先给通用 runtime再由扩展决定能力Grok Build 直接把「一个 Agent 由工具、系统提示、提醒策略、压缩策略和模型配置组成」抽成一等对象并提供 discovery 与优先级覆盖规则。子 Agent、任务队列与工作流Grok Build 默认工具列表中包含task、kill_task、get_task_output启用子 Agent 后可启动子会话源码还有 prompt queue、goal planner、goal evaluator、workflow manager、worktree pool、background task、parallel dispatch 等模块。换句话说它不是把并行只当作 UI 里多开几个窗口而是让任务状态、完成条件、取消、输出获取、目标追踪和工作树都进入运行时。这套能力特别适合大仓库任务。主 Agent 可以负责拆解和汇总子 Agent 分别调查依赖调用链、检查测试失败、查文档或在独立 worktree 尝试修改。它的价值不在于「一次开五个 Agent 就一定快五倍」那是把协作当电饭煲的天真想象价值在于不同调查路径能并行且产物、状态和取消行为有结构可循。插件、Hook、MCP、LSP 与 Claude Code 兼容Grok Build 不只读取.grok/下的 skills、agents、plugins、hooks 和配置也会发现 Claude Code 的.claude/skills、.claude/agents、.claude/plugins、.mcp.json、CLAUDE.md、权限设置等兼容路径。grok inspect能列出当前工作目录实际加载的规则、技能、Agent、插件、MCP、LSP、hooks 和配置来源。这项 introspection 很重要。可扩展系统最容易出现的事故不是「没有能力」而是「不知道能力从哪儿来的」。一个插件加了 MCP一个父目录放了 AGENTS.md一个用户全局 Hook 覆盖了策略最终模型看到的环境可能与开发者以为的完全不同。inspect相当于在起飞前把驾驶舱里所有自动化开关亮出来。MCP 与 LSP 进一步扩展了 Agent 的触角。MCP 让外部系统以工具、资源和模板接入LSP 提供代码智能web search/web fetch 支持检索与抓取。能力面很强但能力面越强供应链和权限面也越大。一个能读仓库、执行 shell、访问网络、调用工单系统和数据库的 Agent不再是「聊天插件」它更像一个需要身份与审计管理的自动化账号。持久化、记忆与沙箱Grok Build 的会话落在~/.grok/sessions/以工作目录和 session ID 组织包含summary.json、updates.jsonl、chat_history.jsonl、plan.json、rewind points、signals、feedback、compaction checkpoints 以及子 Agent 目录。会话不仅可恢复还显式保存计划和回退点。它还支持实验性跨会话 memory。这很适合长期项目但也要警惕「记忆污染」过时结论、错误偏好或不该跨项目传播的敏感信息都可能变成下一次任务的隐性上下文。因此记忆应有可见、可删除、可审计的边界不能因为它看起来聪明就默认全开。安全侧Grok Build 文档给出 OS 层 filesystem/network isolationLinux 使用 LandlockmacOS 使用 Seatbelt并记录 sandbox events。文档同时坦承限制不支持或无法应用时会警告后继续网络限制主要针对子进程进程内的 web search 和 LLM API 并不受同一限制。这种把限制写出来的态度值得肯定。安全工程最怕的不是有限制而是把有限制写成无限。Grok Build 适合谁它适合需要内建并行任务、Agent profile、插件/Hook、MCP、LSP、会话恢复与企业化配置的团队尤其是愿意为统一工作流投入治理的人。大仓库、跨服务改造、研究和实现并行、需要兼容既有 Claude Code 项目资产的组织都能从这条路线获益。它的代价也最大workspace 很大概念很多功能 flag、权限、插件来源、memory、subagent 与 MCP 的组合需要被认真配置。对一个只想让 AI 改三行 CSS 的开发者这套系统可能像带着消防车去取快递当然能到但停车有点费劲。三项目逐层比较模型、循环、会话、扩展、安全与部署一张表先建立全局坐标维度PiCodexGrok Build主体实现TypeScript / Node.js npm monorepoRust 为核心含 CLI、TUI、App Server、协议 crateRust workspace数十个专职 crate核心定位可嵌入、可扩展的 Agent HarnessOpenAI 本地 coding agent 与多客户端产品平台终端 coding assistant 与 agentic workflow harness模型策略多 provider 一等公民统一 API 与模型目录默认围绕 ChatGPT/OpenAI/Codex 产品与模型xAI/Grok 为中心同时支持 BYOK、Ollama、OpenAI 与自定义端点默认工具观默认read/write/edit/bash其余通过扩展补齐产品内建工具、审批与策略层更深内建文件、搜索、shell、web、todo、task、MCP/LSP 等广能力集子 Agent / 计划不内建强调由扩展或第三方 package 实现线程和 subagent 为核心运行时能力的一部分task/subagent、goal/workflow、后台任务与并行调度为一等能力会话模型JSONL 树id/parentId可 tree/fork/clone/exportthread/rolloutApp Server 与线程管理JSON/JSONL 会话目录计划、回退点、子会话、压缩检查点安全默认项目资源信任无内建 OS 级工具权限沙箱approval policy、exec policy、sandbox、网络与进程治理模块permission profile、工具 allow/deny、OS sandbox、hooks/plugin 管理扩展方式TypeScript extensions、skills、prompts、themes、Pi packageApp Server、MCP、skills、plugins、产品配置Agent profile、skills、plugins、hooks、MCP、LSP、兼容 Claude assets适合的组织姿态愿意自定义、已有平台能力希望安全默认与产品一致性愿意治理复杂协作系统表格只能给地图真正影响选型的是下面几组矛盾。1. 模型中立性对抗产品深度Pi 的最大优势之一是模型中立。pi-ai把 provider 层做得足够厚CLI 则把模型切换和认证当作日常交互的一部分。对于需要性能、成本、区域可用性和公司合同之间来回权衡的团队这是实打实的生产能力。Codex 的优势则是深度整合。当组织的主要模型就是 CodexChatGPT 订阅、IDE、桌面端、Web、CLI 与 App Server 能形成连续体验。少一层模型抽象就少一层「某个 provider 的边角特性被抹平」的摩擦。Grok Build 位于中间偏广的一侧。它以 xAI 产品为中心但文档包含 Custom Models、BYOK、Ollama、OpenAI 和自定义 endpoint。它的模型可配置性高于典型单一产品但系统的整体心智模型仍更围绕 Grok Build 的工作流。选择原则很简单模型策略本身是业务变量就选把它当一等公民的 Pi模型策略已稳定真正痛点是执行安全和端到端体验就别为了「理论上的自由」牺牲 Codex 的产品深度如果模型并非唯一变量你还需要任务编排、插件和组织规则Grok Build 的整合度更有价值。2. 最小内核对抗电池全配Pi 默认只有四个编码工具默认不带 plan mode 和 subagents。乍看会觉得「少」但这是让能力可审计的办法。你知道默认 Agent 能做什么也知道多出来的能力来自哪一个 extension。它的复杂度是按需购买的。Grok Build 恰好相反它把 task、web、memory、MCP、LSP、plugins、hooks 放进统一产品面。对于复杂任务这种集成省去大量胶水代码但每增加一种能力配置和攻击面也会增加。Codex 则更偏向把高风险执行路径与用户审批、沙箱、线程治理绑定起来在能力和控制间追求产品级平衡。所以别问「哪个功能更多」。应该问团队有能力维护多少运行时概念一个人维护的仓库四个明确工具可能比二十个可选工具更有效平台团队维护的数百仓库环境缺少任务、策略和集成反而会让胶水代码到处生长。3. 事件钩子对抗策略内建Pi 的beforeToolCall、afterToolCall、extension event 等机制很适合把公司规则写成代码。它将能力交给开发者适合已有安全平台、审计服务和内部工具网关的团队。Codex 和 Grok Build 更强调内建 policy。Codex 将 approval 与 sandbox 纳入 thread start 和执行流程Grok Build 将 permission mode、工具 allowlist/denylist、sandbox profile 放进 Agent 或配置体系。这种方式对大多数用户更安全也更一致。这里没有道德高低只有责任归属。Pi 的责任更多落到扩展作者和部署者Codex/Grok Build 的责任更多由产品核心承接。前者能精准贴合业务后者能避免每个团队重新发明一个并不牢靠的审批弹窗。4. 会话是日志、线程还是工作现场Pi 的 JSONL 会话树最轻巧也最利于检查。它像一本可以翻页、插书签、在任意段落旁另开支线的实验记录。开发者喜欢它因为出问题时文件在那里不需要先学一套后台服务。Codex 的 thread/rollout 更适合多客户端和服务端语义。一次会话不只是历史文本更是带有线程 ID、审批、配置快照、事件和子线程关系的受管理对象。它的收益在统一和可运营。Grok Build 的会话目录再往前走一步计划、回退点、signals、compaction checkpoints、subagent 目录和 memory 共同组成工作现场。它最适合长任务与协作也最需要建立保留期限、敏感数据清理和审计策略。5. 扩展自由度对抗供应链治理Pi 的 TypeScript extension 极其灵活能直接加工具、UI、权限、MCP、沙箱桥接甚至小游戏。灵活的另一面是扩展就是代码Pi package 以完整系统权限运行。安装前审查源码、固定版本、记录来源不是「保守」而是基本操作。Grok Build 的 plugins/hooks/MCP/compat 生态更宽grok inspect能把来源列出来适合治理大规模配置。但生态越宽插件市场、Hook 脚本、MCP server、Claude 兼容目录的来源也越值得纳管。Codex 在其 App Server 和配置体系中同样覆盖插件、技能与 MCP但更强的产品边界通常也意味着自定义会受到更多约束。最实用的治理模型不是禁用一切而是分层只读 skills 可放宽可执行 hook、MCP 和 extension 必须有来源、版本、审批和最小权限生产环境禁止无审计的网络和写操作。让能力与风险对应别让一个「好用」把所有门都打开。选型不是投票按团队约束做决策下面是一套比「我喜欢哪个 UI」更可靠的决策顺序。情况 A你是个人高级开发者手里有多个模型和多套账号优先看 Pi。你真正需要的是同一份工程规则、同一棵会话树、同一套工具习惯可以在不同模型与供应商之间切换。Pi 的多 provider、订阅/API key 并存、可扩展工具与本地 JSONL 会话正好命中这个需求。先用默认四工具跑通确认自己常做的重复动作再写 skill 或 extension不要第一天就装二十个 package把终端做成一个赛博仓库。安全上给 Pi 外套Docker、微型 VM 或团队已有的 sandbox。不要把 project trust 当安全边界更不要把生产凭据和一个来历不明的 extension 放在同一权限域里。情况 B你是企业研发负责人最怕误执行和影子流程优先看 Codex或把 Codex 作为基线对照。这里最值钱的不是模型回答多华丽而是审批、沙箱、执行策略、线程和客户端协议已经是核心能力。团队可以把「哪些命令自动批准、哪些必须确认、工作区外能否写、网络如何处理」变成制度化配置而不是依赖每个开发者记住一份 prompt。但别因为用了 Codex 就停止做治理。仍然要规定 MCP server 来源、插件安装方式、日志保留、密钥注入方式和高风险命令策略。安全产品是安全系统的一个部件不是免思考卡。情况 C你在建设内部 AI 工程平台希望 Agent 可以编排复杂工作优先评估 Grok Build。当任务常常包含「调查、拆分、并行验证、独立工作树修改、汇总、回归检查」时子 Agent、任务状态、Agent Profile、completion requirement、MCP、LSP、Hooks 和 ACP 能少写很多基础设施。尤其已有 Claude Code 资产时它的兼容发现机制可以降低迁移成本。落地的第一步不是全开功能而是建立一个受控 baseline禁用不需要的 web/memory/subagent定义只读 reviewer、受限 implementer、审批式 release manager 三类 profile对插件和 MCP 做允许列表用grok inspect进入 CI 或启动检查确认实际注入环境。复杂系统需要的是秩序不是更多按钮。情况 D你正在做垂直 Agent 产品而不是给自己写代码优先看 Pi 的 agent-core也将 Codex/Grok Build 当作架构参考。Pi 的可嵌入 runtime 与 provider 抽象很适合做领域产品。你可以自定义工具和 UI把模型提供商选择留给客户或企业网关。Codex 的 App Server 值得借鉴协议、线程与审批的分层Grok Build 则值得借鉴 Agent definition、任务完成契约、配置检查与工作流管理。现实里最常见的正确方案不是把三者原封不动塞进产品而是选一个作底座向另外两个借思想。工程成熟的标志不是忠诚于工具而是知道该借哪一段结构。三个落地案例把对比从概念拉回工程现场案例一支付团队的跨仓库故障定位场景是支付回调偶发重复入账。代码跨 API、消息队列、账务服务三个仓库所有仓库都可以读但只有修复分支可写生产配置绝不能触碰。用 Pi 的做法是把三个仓库挂入受控容器写一个 extension 注册只读检索工具、受限写工具和工单查询 MCP再利用beforeToolCall对路径和命令做拦截。主 Agent 在一个会话树中完成调查发现两条候选根因后用/fork分叉验证。优点是模型可以按成本和特长切换团队可以把内部平台直接接入缺点是权限、隔离、审计都要自己补齐不能只写一句「不要改生产」。用 Codex 的做法是为工作线程设置 workspace write、按命令策略审批利用 thread/rollout 记录调查过程。优点是执行治理天然靠近 runtime适合组织标准化缺点是如果团队希望在不同模型网关间做精细路由会不如 Pi 自然。用 Grok Build 的做法是主 Agent 分出三个子任务一个只读调查幂等键实现一个检查消息重复投递一个分析回归测试覆盖。每个 Agent Profile 明确工具集合和完成工具主任务聚合结果后在受限工作树里修复。优点是并行调查结构清晰缺点是必须约束子 Agent 数量、上下文预算和工具权限不然「并行」很容易变成三个人同时把厨房翻一遍。案例二受监管团队的依赖升级金融或医疗团队升级一个存在高危漏洞的依赖。任务包含扫描影响范围、改 API、跑测试、生成变更说明但不允许 Agent 自动提交、发版、访问生产网络。Codex 是最顺手的起点。审批策略和 sandbox 可以让「读、搜索、在工作区写、执行已批准测试」成为可控默认把 git push、发布命令、网络外联放到明确确认后。线程记录也能成为变更证据的一部分。Grok Build 同样能胜任特别适合用 Agent Profile 固化「依赖升级专员」允许 read、grep、package manager 和测试禁止任意 shell 或发布工具再加一个只读 reviewer profile。它的 sandbox 与工具 allow/deny 能形成多道门但配置更复杂需要先做一次安全基线评审。Pi 不是不能做而是更适合已有成熟执行控制面的团队。例如所有命令本来就经过内部 runnerPi extension 只把 runner 暴露成工具。若没有这层基础设施直接让 Pi 默认bash处理受监管升级风险模型会比较难看。技术上能跑与治理上该跑是两句话。案例三开发者平台为全公司提供 AI 编程能力这时需求变成了产品各团队使用不同模型内部有私有文档、CI、代码搜索、工单与审计平台希望统一接入而不把所有人锁到单一 CLI。Pi 是很好的框架候选。pi-ai接公司模型网关pi-agent-core跑在服务或本地客户端中extension 接内部工具SQLite 或远端存储承接会话TUI/网页/IDE 只是不同宿主。平台团队付出的代价是必须把权限、租户隔离、观测、限流和升级策略做完整。Codex 更像一套可直接提供给开发者的成熟客户端体系。如果公司已经以 OpenAI 为主要供应商平台可以少造很多轮子把精力集中到企业配置、审批策略和工具接入。Grok Build 则适合平台希望把「可配置 Agent 团队」作为产品能力的情况比如代码审查 Agent、迁移 Agent、文档 Agent、事故调查 Agent 可以用 profile 和 workflow 编排。不过要先明确哪些 plugin/hook/memory 可在企业环境启用以及谁负责批准它们。平台最危险的成功是大家都用起来之后才发现每个仓库悄悄加载了不同的自动化规则。一套可执行的评估清单不论最后选谁建议用真实任务做两周 POC而不是让三个工具都写一个 Todo List 然后看谁的终端颜色更顺眼。至少测下面十件事。读取真实AGENTS.md后是否能遵守测试、提交和目录约束。在长任务中加入临时纠偏是否会正确停止、继续或排队。运行命令、写文件、访问网络、调用 MCP 时是否出现预期的审批与审计记录。上下文接近极限后压缩是否保留关键事实能否恢复原始历史。一次错误修改后回退、分叉或工作树隔离是否可靠。同一任务切换模型、账号或网络环境后行为差异是否可接受。插件、skills、hooks、父目录规则与项目规则的加载来源是否可见。子 Agent 并行时成本、竞争写入、取消和最终汇总如何处理。断网、鉴权过期、工具超时、模型服务失败时是否有可理解的恢复路径。最后一个最俗也最重要的问题新同事一小时内能否安全地完成第一次任务。第十条经常决定产品命运。一个架构再漂亮若只有设计者知道哪个开关不能碰它在组织里就不是生产力而是一座需要预约参观的博物馆。未来趋势编码 Agent 会从聊天工具走向可治理运行时看完这三个项目有几个趋势已经很清楚。趋势一模型会继续商品化运行时会成为差异中心模型能力仍会快速进步但团队很快会发现真正影响产出的不只是回答质量而是工具可靠性、上下文治理、会话恢复、审批、工作树、观测和集成。模型像发动机Agent runtime 更像整车工程。发动机强很重要可刹车、方向盘和仪表盘也不能靠祈祷。Pi 提前押注了模型抽象和 runtime 可嵌入Codex 押注了产品化治理和多客户端协议Grok Build 押注了可编排的协作运行时。这三条路都指向同一个未来编码 Agent 不再只是「把问题发给模型」而是一个有状态、有权限、有工具、有记录的软件系统。趋势二安全会从「确认弹窗」走向分层能力模型未来真正成熟的 Agent 安全不会只有「允许/拒绝」两个按钮。它需要项目可信任、工具能力最小化、路径与网络策略、隔离执行、秘密管理、审批升级、可回放审计和插件供应链治理。Codex 与 Grok Build 已把较多部分纳入核心Pi 则给出了把这些能力嫁接到运行时的空间。对团队而言最重要的不是选中一个安全名词而是明确每层由谁负责。模型提示词负责意图约束工具包装负责参数约束沙箱负责系统边界审批负责人的判断审计负责事后追溯。把它们混成一句「AI 要安全」大概和把数据库、缓存和备份统称为「数据要稳定」差不多有用。趋势三多 Agent 的关键会是协议而不是数量子 Agent 不会自动创造并行收益。没有任务边界、完成契约、上下文预算、共享状态和冲突处理五个 Agent 只会更快地产生五份不一致结论。Grok Build 的 Agent definition 与 completion requirement、Codex 的线程与 Agent control、Pi 可通过 extension 构建的队列和策略分别给出了不同答案。未来的竞争点会从「能否启动子 Agent」转为「子 Agent 的工作是否可观测、可取消、可验证、可复用」。趋势四配置资产会成为迁移壁垒也会成为治理对象AGENTS.md、skills、plugins、hooks、MCP、Agent profiles、会话记忆这些都不是边角料而是团队把经验编码进 Agent 的方式。Grok Build 对 Claude Code 资产的兼容和inspectPi 对 Agent Skills、Pi package 与上下文文件的支持Codex 对 app-server skills/plugins/MCP 的管理都说明配置资产正变成新的开发资产。它们也会变成新的攻击面和技术债。未来团队会像管理依赖包、CI 模板一样管理 Agent 配置有仓库、有代码评审、有版本、有测试、有弃用策略。谁还把 Hook 当作「某人电脑上的小脚本」谁迟早会被一个神秘自动化教育。结语别只比较谁更会写先比较谁替你承担了什么回到开头那句「帮我修这个 bug」。一个真正可靠的编码 Agent不应只会把补丁写出来还应该能说明它读了什么、为什么改这里、在哪个边界内执行、失败后如何回来、长任务如何不丢记忆以及谁有权让它做更危险的事。Pi、Codex 与 Grok Build 的价值恰好分布在这些不同问题上。Pi 把选择权交给你。它的多模型、可嵌入 runtime、事件钩子、会话树和 TypeScript 扩展非常适合想把 Agent 变成自己系统一部分的人。代价是安全和工作流不能偷懒得自己设计。Codex 把更多治理装进产品核心。它适合希望在 OpenAI/Codex 生态中获得一致体验并需要审批、策略、沙箱、线程和多客户端协议的团队。代价是更强产品边界也意味着较少把一切改成自己形状的冲动。Grok Build 把协作能力推到更前面。任务、子 Agent、Agent Profile、Plugins、Hooks、MCP、LSP、记忆与沙箱形成一套厚实工作流。它适合需要组织化 Agent 协作的工程团队代价是要像管理一个平台那样管理它。所以最值得带走的判断不是「Pi、Codex、Grok Build 谁赢了」。正确的问题是你的团队是缺一个会写代码的模型还是缺一套能把模型放进真实工程流程的运行时前一个问题几个月后可能又有新答案。后一个问题才决定你会不会在下一个周二下午看着 Agent 跑完一堆命令之后既拿到修复也还睡得着。