最近连续看了一个 Pi Agent 视频，也查了 PilotDeck 的官方文档。视频里把 Pi 和 Claude Code、Codex、OpenCode 放在一起比较，PilotDeck 则是另一种思路：它不只关心一次对话能不能完成任务，而是试图管理多个项目、记忆、模型和后台任务。

如果只问“谁更强”，很容易得到没有意义的答案。更准确的问法是：它们分别解决 Agent 系统中的哪一层问题？

先建立三个层次

模型：负责思考

GPT、Claude、Kimi、DeepSeek 等是模型。模型可以理解问题、生成文本、选择工具，但模型本身不会自动读取文件或执行命令。

Agent Harness：负责行动

Pi 和 Codex 都可以放在这一层理解。它们负责维护上下文、调用工具、执行命令、保存会话，并把工具结果交回模型。

Agent 平台：负责长期运行

PilotDeck 更接近这一层。它在 Agent 之上增加项目隔离、长期记忆、模型路由、任务调度、消息渠道和后台运行能力。

可以用一句话概括：

Pi 是“我来造一个属于自己的 Agent”；Codex 是“给我一个能直接交付工作的 Agent”；PilotDeck 是“让我管理一组长期工作的 Agent 和项目”。

Pi：极简、可改造、低锁定

Pi 官方把自己定位为极简的终端 coding harness。它的核心工具很少，常见的基础能力可以概括为读取文件、写文件、编辑文件和运行命令。

这并不代表 Pi 能力弱，而是它把很多能力放到了扩展层：

  • Skill：可复用的操作手册；
  • Extension：可以用 TypeScript 增加工具、命令和 UI；
  • Prompt Template：保存常用任务模板；
  • Custom Provider：连接不同的模型服务；
  • SDK、RPC 和 JSONL：嵌入其他程序或工作流。

Pi 的优点

  1. 可改造性强：可以直接修改工具调用、事件处理和界面行为。
  2. 模型自由度高：不容易被某一家模型服务绑定。
  3. 默认上下文较轻：简单任务不需要加载大量编程专用说明。
  4. 适合本地工作流：文件、脚本和产物都可以掌握在自己的机器上。
  5. 容易形成个人 Agent：研究、办公、内容创作和开发可以装不同的 Skill。

Pi 的代价

  1. 需要自己配置模型、API、Skill 和依赖。
  2. Skill 的质量和安全性需要自己判断。
  3. 默认运行权限可能比较宽，需要自行做容器化或沙箱隔离。
  4. 当 Skill 越装越多，系统也会重新变复杂。

所以 Pi 更适合“愿意搭建工具的人”，不一定是完全不想配置的初学者。

Codex：开箱即用的综合工作环境

Codex 的默认重心确实偏软件开发：读代码、改文件、执行命令、跑测试、做审查。但在当前 Codex 环境里，它还可以通过 Skill 和工具完成研究、浏览器操作、PDF、Word、表格、幻灯片、图片和本地文件交付。

Codex 的优点

  1. 上手成本低：不必先搭建模型服务和工具链。
  2. 综合能力完整：编码、浏览器、文档和媒体工作流可以放在一起。
  3. 交付导向明显：不仅回答问题，还能生成文件、运行验证和检查结果。
  4. 默认流程更成熟：项目规则、测试、审查和安全边界通常已经被考虑。
  5. 适合跨领域任务：同一个任务可以从搜索资料一直做到最终报告。

Codex 的限制

  1. 你能使用的能力受当前环境、工具和权限控制。
  2. Skill 主要是工作流和操作规范，不等于可以任意改写底层运行时。
  3. 更完整的系统提示词和工具定义可能带来额外上下文成本。
  4. 模型、服务和产品策略可能会改变，控制权不如自建 Agent 完全。

因此，Codex 和 Pi 的差别不主要是“谁更聪明”，而是：Pi 把控制权交给用户，Codex 把更多成熟流程提前交给用户。

PilotDeck：面向长期工作的 Agent 平台

PilotDeck 的核心概念是 WorkSpace。每个项目有自己的文件、记忆和 Skill，项目之间尽量隔离。它还在 Agent Runtime 之外提供了更多管理能力：

  • WorkSpace：每个项目有独立的文件范围、会话和 Skill；
  • White-box Memory：项目记忆和反馈记忆可追踪、可修改；
  • Router：根据任务复杂度选择模型，并支持多供应商 fallback；
  • Always On：在工作区空闲时做 Discovery，或通过 Cron 执行计划任务；
  • Gateway：通过 Web、CLI、桌面端和聊天渠道接收任务；
  • MCP 和 Extension：接入外部工具和自定义能力。

PilotDeck 的优点

  1. 多项目隔离：不同项目的文件、上下文和记忆不容易混在一起。
  2. 长期记忆：不是每次都从空白聊天开始。
  3. 后台执行：适合监控、定时研究、周期性报告等任务。
  4. 成本路由：简单请求可以交给轻量模型，复杂请求再使用强模型。
  5. 多入口管理：不必始终打开同一个终端或聊天页面。

PilotDeck 的代价

  1. 系统更重，安装、配置和运维成本高于 Pi。
  2. 记忆、路由和后台任务增加后，排查问题也更复杂。
  3. 它不是简单的 Pi 网页版，也不能默认认为能无缝接管任意第三方 Agent。
  4. PilotDeck 使用 AGPL-3.0，二次开发和商业部署时要单独评估许可影响。

PilotDeck 更像“Agent 操作系统”或“控制平面”，不只是另一个聊天窗口。

Skill 在三个系统里的含义不同

“Skill”这个词看起来一样，实际所处的位置并不相同。

系统 Skill 更像什么
Pi 给极简底座增加一项能力的操作手册，必要时再用 Extension 改运行时
Codex 让 Agent 按指定规范使用现有工具的一套工作流
PilotDeck 安装在某个 WorkSpace 中，并可与项目记忆和长期任务结合的能力模块

所以，给 Codex 一个合适的 Skill，确实可以复现很多 Pi + Skill 的效果，例如：搜索资料、读取 PDF、生成文案、调用 TTS、生成图片和制作 HTML 演示。

但 Skill 不能凭空创造不存在的权限或服务：没有浏览器工具，就不能自动点击网页；没有 TTS 服务，就不能直接生成音频；没有后台运行环境，就不能在会话关闭后继续工作。

为什么视频里 Pi 会显得特别适合普通人

视频展示的不是“Pi 内置了所有能力”，而是一个很清晰的学习过程：

最小 Agent
  → 搜索 Skill
  → PDF/Office Skill
  → TTS Skill
  → 图片生成 Skill
  → HTML/视频 Skill
  → 可交付的完整项目

这种过程让人看见了 Agent 能力是怎样长出来的。它比直接面对一套庞大的工具清单更容易形成理解。

但“Pi 的 Token 一定只有 Codex 的几分之一”不能作为固定结论。视频中的数字属于特定模型、版本和任务下的体验；而 Codex 的额外上下文里，可能包含工具定义、安全规则、项目约束和验证流程。上下文越短不一定总是越好，关键是这些上下文是否真正帮助任务完成。

按任务选择

只想把事情做完

优先选择 Codex + Skill。尤其是研究、代码、文档、表格和网页产物混合在一起的任务，开箱即用的工具链会省很多时间。

想拥有自己的 Agent

选择 Pi。它适合研究模型、尝试不同 Provider、设计个人工作流，以及把 Agent 嵌入自己的脚本或应用。

想让 Agent 长期工作

选择 PilotDeck。它适合多项目、长期记忆、定时任务、后台发现和成本路由。

想组合使用

可以采用下面的思路：

Codex：快速验证任务流程和产物格式
Pi：把稳定流程改造成自己的本地 Agent
PilotDeck：管理多个项目、记忆和后台任务

这不是开箱即用的“直接互换”，具体还要看适配器、MCP、CLI 或 API 是否接通。

最后：不要只比聊天效果

如果要认真比较三个系统，建议让它们使用同一个模型、同一份资料和同一项任务，然后观察：

  • 完成时间；
  • 总 Token 和外部 API 成本；
  • 工具调用次数；
  • 产物是否可复用；
  • 错误能否定位和恢复；
  • 是否能在没有人工盯着的情况下继续运行；
  • 权限和敏感数据是否可控。

这样得到的才是工作流层面的比较，而不是一次对话的印象分。

总结

Pi、Codex 和 PilotDeck 的长处并不重合：

  • Pi：最容易被改造成“你的 Agent”；
  • Codex：最适合直接完成跨领域任务并交付结果；
  • PilotDeck：最适合管理长期、多项目、可持续运行的 Agent 工作。

它们不是简单的替代关系，而是可以对应不同阶段：先用 Codex 找到自己的工作流，再用 Pi 深度定制；当项目、记忆和后台任务不断增加时，再考虑用 PilotDeck 做统一管理。

参考资料：

本文根据 Pi Agent 相关视频字幕、Pi 官方文档和 PilotDeck 官方文档整理。模型能力、Token 用量、服务价格和产品功能会随版本变化。