Coding Agents 软件分析

这次作业我选择分析开源的 Coding Agents 软件，研究对象是 openai/codex，竞品则选了 badlogic/pi-mono。从编译优化开始接触 Codex，到现在使用 Pi，我接触这类软件已经有三个多月了。借着这次作业的机会，我想把之前零散的使用感受，连同这次专门查阅的文档、源码和相关文章，重新整理成一篇相对完整的分析。

“这类”软件到现在也还没有一个稳定的术语定义。人们常常把 Agent、Harness、Engineering、Coding、CLI 等词混在一起排列组合，或者干脆用 Claude Code 这样的代表性产品来指代整类工具。Simon Willison 在 What is agentic engineering? 里把 Agentic Engineering 描述为“借助 Coding Agents 来开发软件的实践”，并把 Coding Agents 定义为“既能编写代码又能执行代码的代理”。本文里我基本沿用这个说法，把本文讨论的对象统一称作 Coding Agents 软件。⊕LLM、Coding Agents、Agentic Engineering 这些术语总是被混用。如果有人专门写一篇文章把这些词的边界讲清楚，应该会很有帮助。

Codex 是 OpenAI 推出的 Coding Agents 软件。Pi 则是当前爆火的 OpenClaw（小龙虾）背后运行的 Coding Agents 软件。⊕其实该怎么定义 OpenClaw，我自己也觉得有点模糊。

很多人在使用这类软件时，要么根本不关心背后的机制，要么只关心它调用了什么模型。但我在看 OpenAI 自己发布的文章时，一个非常明确的感受是：真正决定产品体验的，并不只是模型本身，还有模型外面的那层系统是怎么设计的。工具怎么给，权限怎么管，输出怎么展示，失败之后怎么恢复，长对话怎么压缩，这些都会直接影响用户体验。换句话说，Coding Agents 之间的差别，不只是模型能力的差别，也是框架实现方式的差别。⊕从这个角度看，我其实很喜欢 Harness Engineering 这个词。Harness 在这里像是把模型比作野马，强调的是模型之外这层“挽具”的设计价值。

这次作业里，我以 Codex 作为主要分析对象，用 Pi 作为竞品进行对比。Codex 算是我真正上手使用的第一个 Coding Agent CLI。在此之前我也装过 Claude Code、Gemini CLI 等工具，但都没有认真用下去。从上个月开始使用 Pi 进行一些实际开发，我意识到：相比 Codex，我更喜欢 Pi 这种“做减法”的设计。但 Pi 这个名字实在太过于普通，我在网上检索它的相关资料就感到很困难。

整体印象

要理解 Codex 和 Pi 这类软件，首先得把它们和普通的 AI 聊天工具区分开。普通聊天一般是一问一答，每一轮模型只做一次相对封闭的推理与输出。⊕如果接了 Web Search 之类的工具，通常也只是先搜索，再把结果塞回上下文里生成一次性回答。

Coding Agents 的核心则是一个 Agent Loop，也就是一个迭代执行周期：系统先组装任务与上下文，调用模型做当前判断，模型选择发起工具调用；系统执行动作并将结果反馈给模型，让模型循环做判断，直到模型决定输出响应。用户看到的一次任务推进是多轮状态更新不断叠加出来的结果。

OpenAI 在 深入解析 Codex 智能体循环 中给出的 Agent Loop 示意图。

所以，要把一个 Coding Agent 做好，关键不只是模型本身，也在于这个循环是否稳定、顺畅、可持续。⊕关于 Agent Loop 的更多信息，可以参考 Oracle 的文章 What Is the AI Agent Loop? The Core Architecture Behind Autonomous AI Systems。

在这个前提下再看 Codex 和 Pi，两者都是把模型放进这个循环里，让它直接参与本地开发流程。但 Codex 更在意把循环外面的配套也一起做完整，比如登录、配置、审批、沙箱，以及和 IDE、桌面入口等不同形态的连接。它是一整套已经整理好的使用环境。Pi 则把注意力集中在循环最核心的那一层。它默认只给模型几个最基础的工具，把不少常见的能力先拿掉了，比如 plan mode、sub-agents、MCP 和权限弹窗；同时它又把扩展机制设计得很好，把选择权留给用户，让用户自己决定要不要把这些能力再加回来。

所以，总体上说，Codex 更像一种“大厂特调”：面向真实工程环境，强调完整体验；Pi 则是明显更克制的路线，它主动对功能做减法，把更多控制权还给用户。

核心体验与对比

为了避免讨论停留在抽象印象上，我专门拿了一个很小的任务做对比测试：给一个最小的 Express 服务接入 morgan，要求安装依赖、修改 index.js、启动服务、发送请求验证日志，并把测试过程写进 README。使用的提示词如下：

请帮我引入 morgan 库来记录 HTTP 请求日志。你需要先安装依赖，然后在 index.js 中配置它使用 'dev' 模式。完成后，请帮我启动这个服务并发送一个测试请求到 http://localhost:3000，确认日志能正常打印，最后把运行结果告诉我，并把测试过程补充到 README 中。

从结果来看，两者都完成了任务：Codex 和 Pi 都成功引入了 morgan('dev')，也都验证了类似 GET / 200 这样的访问日志。这说明在这种很小的任务里，二者的代码修改与命令执行能力都已经足够，真正拉开体验差异的不是结果，而是过程。

Codex 的执行路径很标准。它会先确认目录和文件，再检查仓库状态，读完 package.json、index.js 和 README.md 之后才开始动手。但一旦进入执行阶段，它那层外围系统就变得非常有存在感。安装 morgan 时，它先在沙箱里尝试，之后又因为权限问题重新提权；本地验证时，服务明明已经打印出 listening on port 3000，它却还要继续和沙箱、进程状态以及端口访问打交道，最后才真正拿到 curl 200 OK 和服务端日志。这里的问题不是 Codex 不谨慎，恰恰是它太谨慎了，以至于一个本来很轻的任务，用户也要不断理解框架本身正在做什么。

几天后才截的图，已经展示不出更详细的执行过程了，但从它的输出也可以看到它纠结于各种提权的问题。

这也是我觉得 Codex 有些“过度设计”的地方。它把很多原本是为真实工程场景准备的边界处理，提前暴露成了普通任务里的交互成本。尤其是在执行长命令时，Codex 会使用 background terminal，把命令异步挂到后台。这个思路本身没有问题，但它进一步放大了 Codex 的上下文不透明：用户往往只能看到“它执行了什么命令”，却看不到命令执行到了哪里、卡在了哪里、有没有中间输出。于是，服务启动和验证这种本来最直观的步骤，反而变成了最难判断状态的部分。⊕命令的中间执行过程，Agent 自己读懂、处理掉不就行了吗？为什么还要让人操心这些细节？但恰恰只有当过程对人可见时，人才能主动分析哪里可以优化、哪里正在出错；否则，我们就很难真正提高 Agentic Engineering 的成功率与效率。在我看来，Agentic Engineering 的主导者始终还是人。

Pi 在同一个任务上的路径就短得多。它读完 index.js、package.json 和 README.md 之后，直接安装依赖，精确修改文件，再用一条命令完成“启动服务、发送请求、读取日志、结束进程”这一整套验证。整个过程几乎没有把注意力从任务本身移开。UI 上也是一样，Pi 会把它执行的命令和过程直接摊开给用户看。这种透明度不一定让它显得更强，但会让人更容易判断它到底在做什么。

绿色框中就是它执行的 Bash 命令，非常简洁地完成了测试。

所以，我的结论不是“Pi 全面优于 Codex”，而是更具体一些：在轻量、局部、低风险的开发任务里，Codex 那套完整框架并没有明显转化成更好的体验，反而因为沙箱、提权和上下文隐藏拉长了交互路径；Pi 的极简设计则更贴近我想要的工作流。至于在复杂仓库、严格权限边界或者多人协作环境里，Codex 这些设计会不会重新体现价值，还需要更大规模的任务来验证。

下面这个表格不是在给模型能力打分，而是在给这次实际使用体验打分，因此它只对应这个测试场景。

维度	Codex	Pi	说明
安装与启动流程流畅度	7/10	9/10	Codex 完成了任务，但中间被沙箱和提权打断；Pi 的路径更短。
执行状态可理解性	6/10	9/10	Codex 会解释自己在做什么，但 background terminal 的实际执行过程不透明；Pi 暴露出的动作更直接。
工程环境治理能力	9/10	6/10	Codex 对权限、沙箱、提权和环境边界的处理明显更完整。
简单任务的执行效率	6/10	9/10	同样是接入一个中间件，Pi 更像一次线性执行，Codex 则更曲折。
用户主观舒适度	6/10	9/10	我更喜欢 Pi 让我把注意力留在代码和命令上，而不是框架机制上。
结果正确性	9/10	9/10	两者都正确完成了代码修改、启动验证和 README 补充。

总体上，我会把 Codex 评价为“工程上很强，但在简单任务里偏重”，把 Pi 评价为“能力更克制，但交互更顺手”。如果问我更愿意长期把哪个工具放在命令行里，我目前还是会选 Pi。

其他开发者的反馈

只靠我一个人的体验，其实很容易陷入一种偏见：熟悉命令行的人，天然就更偏好透明的工具。所以按照作业要求，这一部分我准备结合一次简短访谈来补足视角。问题并不复杂，核心是想确认一件事：别的开发者在接触 Coding Agent 时，最在意的究竟是能力边界、结果正确性，还是执行过程是否可理解。

我采访的 B 同学平时很少使用 Codex 这类命令行 Coding Agent，更多还是用 Gemini 网页版来辅助写代码。B 提到，自己更习惯“向 AI 提问题，再由 AI 给出修改建议”的使用方式，而不是让 AI 直接上手改本地代码，因为后者会让人有些不放心。因此，在工具偏好上，B 也明显更倾向于过程透明的产品：一旦 AI 开始执行命令、修改文件，用户至少应该知道它具体做了什么。与此同时，B 并不因此反对权限控制和沙箱机制，反而认为这些限制是有必要的。如果系统没有额外的权限约束或隔离环境，那么自然语言里的模糊性就会直接变成真实环境里的风险。

采访 B 同学的聊天记录

这段反馈让我觉得，用户对 Coding Agent 的期待并不是单向度的。他们既希望过程足够透明，也希望高风险操作受到约束。换句话说，透明度和沙箱并不是互相替代的：前者解决的是“我知不知道它在做什么”，后者解决的是“即使我说得不够精确，它也不至于直接把事情做坏”。