# Pi

InfoQ 编译整理了一场围绕 Pi、Agent Harness 和 AI 编程的访谈。文章介绍了 Pi 1.0 的几项重要变化：Code Mode 与原生 MCP 进入稳定版，同时推出面向长时间运行 Agent 的 Pi Durable。Pi 团队此前曾公开批评 MCP，如今却在协议和生态成熟、模型训练更充分之后把它纳入核心能力，这反映出团队对 Agent 工具链的判断发生了变化。

文章的主线不是“再做一个 Coding Agent”，而是讨论如何把 Agent 从一次性、容易崩溃的程序，变成可以长期运行、跨设备恢复、被其他开发者复用的基础设施。Pi 团队认为，模型本身已经足够强大，但如果外层 Harness 不可靠，Agent 仍然无法真正承担长时间任务；与此同时，Agent 在架构设计、代码库治理和安全边界上仍然需要人类介入。

Pi Durable：让 Agent 崩溃后从断点继续

Pi Durable 解决的是长时间运行 Agent 的持久执行问题。典型场景是：Agent 启动后调用工具，进程在调用前、调用中或调用后突然崩溃；进程重新启动时，系统应该能够判断任务执行到了哪一步，并从正确的位置继续，而不是让用户再次输入“继续”。工具结果、流式输出、用户消息和应用状态也不能因为进程退出而丢失。

Mario Zechner 用一个简单流程概括 Pi Durable：Agent 启动，调用工具，进程挂掉，重新启动，然后从中断位置精确恢复。它不只保存对话文本，还保存模型回复、工具执行结果、任务状态和应用数据，因此可以支持 Slack Bot、个人助理以及其他运行数小时、数天甚至更久的 Agent。

Pi Durable 没有采用传统的事件溯源方案，而是使用“意图—执行效果—存储结果”的持久化结构：

1. 意图：执行一个操作前，先把参数、输入和待执行状态写入存储。
2. 执行效果：真正调用模型、工具或外部服务。
3. 存储结果：操作完成后保存结果，使系统能够判断任务是否已经完成。

这种设计需要结合幂等性处理崩溃。比如调用 GitHub Actions 时，系统应先获得并保存一次运行的 ID；即使进程在调用过程中退出，重启后也能通过这个 ID 查询原任务是已经运行、正在运行还是尚未启动，从而避免重复执行。对于删除文件、发送消息、刷信用卡等可能产生不可逆副作用的操作，则必须额外设计恢复和去重机制。

Pi Durable 还包含版本化文档存储，用 JSON 对象保存待办清单、画布、协作状态等应用数据。文档会随着对话和工具操作不断生成新版本，并可与转录记录中的任意位置关联。用户回到过去的对话节点时，可以选择读取当时的旧状态，也可以继续使用最新状态。Pi 团队为此设计了面向 Agent 场景的结构化更新机制，底层思路类似 JSON Patch，但更适合记录和重放 Agent 对应用状态的修改。

Code Mode：把工具调用变成可编排程序

与 MCP 一起进入稳定版的 Code Mode，允许 Agent 在 QuickJS 沙箱中编写并运行 JavaScript。它的作用不是简单替代 Bash，而是让模型能够在 Harness 内部对工具进行搜索、组合、并行调用、过滤、去重和计算，最后只把整理后的结果交给主模型。

例如，Pi 通过 MCP 获取 200 条 GitHub 评论后，Code Mode 可以先在沙箱中逐条处理这些评论，判断情绪、紧急程度和问题类别，再把汇总结果发送给 GPT 或 Claude。这样，大量中间数据不会挤占主模型上下文，也能降低 Token 消耗和运行成本。

Code Mode 还可以在 JavaScript 循环内部调用更快的 System 1 模型，例如 Jev。此时 MCP 负责获取数据，Code Mode 负责编排和处理，Jev 承担大量简单分类任务，前沿模型则集中进行高层推理。文章认为，这种“不同模型分层协作”的方式，可能比让一个大模型包办所有步骤更高效。

Pi 为什么改变对 MCP 的态度

Pi 创始人 Mario Zechner 和 Flask 创始人 Armin Ronacher 曾长期公开批评 MCP，认为它臃肿、浪费上下文，并主张 Agent 更多使用 Bash、CLI 和代码。Pi 官网甚至一度以“不支持 MCP”为特点。

这次变化并不是因为团队想追逐行业热点，而是因为几个条件发生了改变：模型已经接受了更多 MCP 相关训练，协议和 MCP Server 的质量有所提升，工具搜索与渐进式披露也缓解了工具定义占满上下文的问题。Pi 不会把所有 MCP 工具名称、参数和描述一次性放入上下文，而是根据任务需要动态加载。

Armin 表示，MCP 最终进入 Pi，最初其实是因为他需要一种方式为 Jev 编写代码模式。从 Jev 的分类需求出发，再把工具调用接入 MCP，只用了很短时间。但团队在正式支持 MCP 前进行了长时间权衡，直到它足够成熟、足够有用，才愿意把它作为内置功能发布。

这也引发了 Pi 用户的不满。一些用户认为，Pi 正在逐渐堆积自己过去反对的功能，可能从极简 Harness 变成臃肿系统。Pi 团队的回应是：默认上下文并没有显著增加，Code Mode 不是绕一圈调用 Bash，而是让 Agent 能在 Harness 内部对工具进行程序化编排；接入 MCP 的同时，Pi 仍在控制工具信息对上下文的占用。

Agent 擅长局部修复，却不擅长架构设计

访谈中最反复出现的判断是：Agent 可以非常高效地完成有明确验证标准的任务，但不擅长理解和维护大型代码库的整体架构。

Mario 认为，Pi 中有大量代码是“只要测试通过、渲染正确，就不必人工阅读”的产物。比如 TUI 库中的 Markdown、文本和编辑器组件，Agent 可以根据既定 API 直接生成，开发者只需要关心接口和行为是否正确。但当性能出现问题时，Agent 往往只会针对某个边缘场景做局部修补，很难发现真正造成性能下降的整体设计问题。

Armin 也指出，Agent 几乎总会通过增加代码来解决眼前问题，而一个成熟的软件修复缺陷后，代码量有时应该减少而不是持续膨胀。如果完全自动化地让 Agent 维护代码库，系统很可能在每次修 Bug 后都增加新的补丁、抽象和分支，最终形成难以理解的代码堆积。

他们把适合 Agent 的任务概括为具有清晰 Oracle 的任务：系统能明确告诉模型结果对不对。例如测试套件、模糊测试、格式解析、模拟器和部分安全任务，都有较强的自动验证信号。Bun 的 Rust 重写、序列化库实现和大量 fuzz 测试之所以适合交给 Agent，正是因为可以让测试不断给出明确反馈。

相反，“构建一个全新的系统”本身缺乏可直接学习的标准答案。Mario 认为，架构和设计过程通常没有被编码成完整文本训练数据，模型可以讨论某个架构方案，却不一定能在实际开发轨迹中持续坚持正确的整体方向。模型往往知道“什么架构听起来合理”，但在具体执行时又沿着局部、最可能的路径不断堆叠代码。

因此，文章并不是简单断言 Agent 不会架构，而是强调任务类型和验证信号的重要性：有明确反馈、可自动判断对错的任务，Agent 的效果会非常强；缺少反馈、需要长期保持整体判断的任务，仍然需要人类设计和监督。

什么时候可以接受 AI 垃圾代码

访谈嘉宾区分了不同层级的软件。对于只服务特定硬件组合、一次性完成明确目标的脚本，代码是否优雅并不一定重要，只要它能运行、能测试、能完成任务即可。这样的项目可以容忍一定程度的“AI 糊代码”。

但 Pi、Bun 或其他被大量用户长期使用的基础软件不同。它们需要稳定的接口、可维护的架构和持续演进能力，不能只看单个任务是否完成。Mario 的做法是先由人建立稳健、极简的 API 和整体设计，再让 Agent 批量实现具体组件；人类把精力放在边界和架构上，Agent 负责大量可验证的局部实现。

这实际上是一种“人决定在哪一层介入”的方法：并不是完全拒绝 AI 生成代码，也不是把所有设计都交给模型，而是把不可验证、影响全局的决策留给人，把可测试、可重复的实现工作交给 Agent。

Pi Durable 的基础设施定位

Pi 团队认为，现有许多 Agent Harness 都能让 Agent 工作，但很难直接拿来构建新的产品。不同项目往往要重复实现对话记录、上下文压缩、任务调度、进程恢复、跨设备迁移和应用状态保存。

Pi Durable 的目标是提供一组足够小、足够通用的基础原语。它大约有 1.2 万行代码，重点不是覆盖所有产品功能，而是让开发者能够在其上构建个人助理、Slack Bot、工作流 Agent、内部协作系统或其他长时间运行的应用。Armin 将这种可靠性比作基础环境：模型本身已经不可预测，至少任务编排、状态保存和故障恢复应该可理解、可追踪。

团队计划把 Earendil 的业务分成两条线：一条是面向普通用户的非 Coding Agent 产品，另一条是让开发者和其他团队能够构建自己 Agent 的基础设施。Pi 不再只想成为一个终端编程工具，而是希望成为“可自我修改的 Agentic 软件”的起点。

Pi Mobile、跨设备 Agent 与安全问题

Mario 正在探索 Pi Mobile（PIM），希望让“大脑”运行在手机上，而执行环境可以分布在其他机器，例如远程服务器或个人电脑。用户可以从手机连接不同设备，让多个 Agent 在不同机器上运行，并根据需要在 Agent 与人类之间切换。

但跨设备、多人共享会话和 Web 插件系统会带来严重的安全问题。访谈中提到，一个 Agent 曾因共享文件而把整个文件系统暴露到公网；在多人共享环境中，还要处理不同用户之间的信任等级、会话权限和数据隔离。服务器端使用 Docker 沙箱相对容易，真正困难的是 Web 界面：Agent 生成的链接和 UI 可能带来 XSS、Cookie 窃取、iframe 隔离和用户体验问题。

因此，Pi 团队认为个人 Agent 不能只追求“拥有更多权限”。当 Agent 能够访问邮箱、文件、服务器和个人财务信息时，权限边界、可审计性、幂等执行和默认安全设置必须成为 Harness 的核心设计，而不是事后补丁。

让非开发者真正用上 Agent

访谈最后把问题从 Coding Agent 扩展到普通用户。嘉宾认为，现在大多数产品只是给用户一个聊天框和侧边栏，然后让用户自己理解如何使用；“不知道自己能问什么”是普通人从不会用到会用之间最大的障碍。

真正有效的产品需要主动引导用户经历第一次成功体验，让他们看到 Agent 能够处理哪些具体事情，再逐渐建立信任。团队希望让家庭成员也能使用 Agent，把语言学研究、家庭后勤、创作和其他日常任务交给它处理，而不是只面向熟悉命令行和模型参数的工程师。

文章最终呈现出的 Pi 路线是：模型负责推理，Harness 负责可靠执行，工具协议负责连接外部世界，Code Mode 负责编排和数据处理，人类负责设定目标、架构和信任边界。Pi 接入 MCP 并不是放弃极简主义，而是在新信息和新需求出现后重新评估取舍；Pi Durable 则试图补上 Agent 从“能运行”走向“可长期依赖”所缺失的基础设施。