ARTICLE · 1089307
OpenClaw 背后的 Pi:一个“小框架”,为什么让开发者上头?
OpenClaw 背后，有个叫 Pi 的 Agent。有人拿它写代码，有人给它加交互式终端，作者甚至把 Doom 塞了进去。
看起来像开发者整活。但顺着这些例子往下看，会碰到一个很实际的问题：当 AI 已经会写代码，我们能不能让它顺手改造自己使用的工具？
Pi 吸引人的地方，正是这条路径。你先得到一个能工作的助手，再通过扩展，把它改成适合自己的样子。OpenClaw 则展示了另一种可能：把它的运行能力拿出来，装进一个不同的产品。
这篇从 Pi 的来历和社区讨论讲起，再把它与 Claude Code、LangChain 放到同一张地图上。先看各自能做什么，再看开发者能控制什么，最后讨论项目真正上线时还缺什么。
Pi 是什么，又是怎么受到关注的？
这里的 Pi，指 Mario Zechner 创建的编码 Agent，与同名聊天产品无关。
2025 年 11 月，Mario 已经公开介绍这套工具。他的出发点很具体：希望更清楚地掌握模型收到哪些上下文，也希望工具的变化不要不断打乱自己的工作方式。
Pi 有两种用法。
一种是直接在终端里使用：让它读项目、改文件、运行命令，完成编码任务。另一种是把它作为组件放进程序，让自己的应用获得模型调用、工具执行和会话管理能力。Pi 核心采用 MIT 许可证，支持多家模型服务。
所以，Pi 同时是一件成品工具，也是一套可以拿来继续开发的底座。
早期终端界面：从一个工作目录开始。
它早期最有辨识度的设计，是读文件、写文件、修改文件、执行命令这几类基础工具。很多复杂任务都能从这些操作组合出来，不必为每一个动作预先设计专门按钮。
不过，工具少不代表权限小。一个能执行 shell 命令的入口，背后可能调用大量程序。这里的“小”，主要指核心机制和默认选择比较克制。
至于它怎么火的，比较明确的传播链路是：OpenClaw 的采用，让更多人开始追问它底下用的是什么；开发者文章与扩展示例，又把这种关注转化成了上手兴趣。
Armin Ronacher 曾发表《Pi: The Minimal Agent Within OpenClaw》，介绍两者关系和自己的定制方式。Mario 后来在个人回顾中也明确提到，OpenClaw 与 Armin 的文章给 Pi 带来了关注。
这能支持“Pi 借 OpenClaw 获得了更多曝光”，却不能直接推出“Pi 已经替代 Claude Code”。没有连续的用户与使用数据，也不适合编一个一夜暴涨的故事。
为什么有人看完介绍，还愿意真的动手折腾？
X 上的讨论：让 Agent 给自己加功能
在几条可以核对到原文的 X 帖子里，最具体的话题是扩展。关注点并不只是“回答得好不好”，而是这个助手还能被改造成什么。
Mario 展示过在 Pi 里运行 Doom 的扩展。这当然不是生产力测评，但它把一个抽象能力变得直观：Pi 的终端界面可以被扩展到远超普通聊天窗口的程度。
真正贴近开发工作的例子来自 Nico Bailon。他介绍的交互式终端扩展，按帖子描述，可以让 Agent 操作交互式 CLI，包括其他 Agent 工具；用户能旁观，也能随时接管。
这个例子有意思的地方是，开发者没有等 Pi 官方新增一个产品功能，而是自己把所需的交互补了上去。它展示的是一种开发方式；帖子中的效率描述仍是作者陈述，不能直接当作横向测试结论。
Armin 在介绍 Pi 的帖子中，把吸引力概括为：软件可以编写自己的软件，编码 Agent 可以扩展自己。
这条帖子把关注点放在 Agent 扩展自身的能力上。
这里的“扩展自己”需要解释清楚：模型生成扩展代码，运行环境加载它，再通过执行结果继续修改。它没有凭空学会一种新能力，也没有自动保证生成的扩展安全、正确。代码仍然需要检查。
这几条帖子也有各自的立场。Mario 是作者；Armin 是使用者、Mario 的长期朋友，后来又成为同事；Nico 分享的是自己的扩展。它们说明了社区里具体有人在做什么，不代表所有开发者已经达成共识。
我的理解是，Pi 抓住了一种需求：用户不仅希望 AI 帮忙写业务代码，也希望 AI 帮忙调整自己的工作环境。 当修改工具的成本降低，可扩展性就从少数人的高级功能，变成了日常使用的一部分。
接下来要弄清楚的是，Agent 框架在这件事里究竟负责哪一层。
Agent 框架是什么？用一次修 Bug 看懂
假设你把一份报错交给模型。普通聊天模式下，它会根据你提供的内容解释原因、建议修改方案。要真正修好项目，还需要有人把建议变成文件修改，并验证结果。
Agent 会把这个过程接起来：读取代码，找到可疑位置，修改文件，运行测试，再根据错误继续调整。
可以把流程写成一行：
目标 → 模型判断下一步 → 执行工具 → 返回结果 → 再判断，直到结束。
模型负责生成决策，工具负责执行动作。框架则把两者组织起来：怎么声明工具、怎么处理调用结果、历史消息怎么保存、内容太长时怎么整理、发生错误如何继续。
模型根据工具返回的结果，继续决定下一步。
这里经常出现三个词：模型、框架、harness。
模型是提供推理与生成能力的服务。换模型，可能改变任务表现、成本和支持的能力。
框架提供可复用的开发接口，帮助你把模型、工具、状态和业务逻辑连接起来。
Harness更强调包围模型的那套运行环境：系统指令、工具集合、上下文管理、执行循环和交互方式。中文不必硬译成一个新名词，把它理解为“让模型实际工作的一整套配置与运行机制”就够了。
这些概念有重叠，行业也没有绝对统一的边界。Pi 常被称为 coding agent 或 harness，开发者也会把它当框架使用。LangChain 更明确从开发框架出发；Claude Code 首先是一件可直接使用的产品。
框架不会凭空提升模型智力，但会改变模型能看到什么、能做什么，以及做错以后能否纠正。同一个模型，配上不同工具、上下文和反馈，任务表现完全可能不同。
因此，比较这三者，不能只问“谁更聪明”。更有用的顺序是：我要直接用，还是拿来开发？需要改哪一层？出了问题由谁恢复？
第一层比较：你要一个助手，还是要造一个应用？
如果今天的任务是修一个项目，Pi 和 Claude Code 都可以从终端开始使用。它们都能围绕文件和命令工作，完成多步任务。
Claude Code 提供相对成套的编程工作方式，以及项目规则、Skills、MCP、Hooks、子 Agent、插件等扩展能力。很多团队需求可以沿着这些入口完成，不必重建一套助手。
Pi 同样提供可用的终端助手，但更突出多模型与组件改造。你既可以先用默认形态，也可以逐步替换工具、调整上下文、增加界面，或者把会话运行能力嵌进自己的产品。
LangChain 的起点通常不同：你正在写一个应用，需要接模型、业务工具、数据源和运行逻辑。当前的 create_agent 可以组织模型与工具，并通过 middleware 干预运行过程。它也支持多种模型，不能把“多模型”算成 Pi 独有的优势。
这张表只是帮助定位，边界并不封闭。
例如，Claude 还有 Claude Agent SDK，可以通过 Python 或 TypeScript 把 Claude Code 的 Agent 能力嵌入应用。到了这一层，合理的对照对象就是 Pi SDK，而不只是 Claude Code 的终端界面。
LangChain 生态也有 Deep Agents，提供文件系统抽象、上下文压缩和子 Agent 等配套能力。想比较“现成助手底座”的完整程度，不能只拿 LangChain 的一个基础入口来对照。
这几个名字放回各自的位置后，选型就少了一半混乱：产品对产品、SDK 对 SDK、流程运行能力对流程运行能力。
先明确任务，再比较需要哪一层能力。
第二层比较：定制需求来了，代码写在哪里？
用一个具体需求看差异：给 Agent 接入公司的知识库，规定回答必须引用内部资料，并在执行写操作前检查权限。
它其实包含三件不同的事。
回答规范，是指令层。 例如“先检索再回答”“结果必须带资料编号”，可以用项目规则、模板或技能表达。它们帮助模型遵循工作方式，但不能代替实际鉴权。
查询知识库，是工具层。 你需要一个真实可执行的接口，接收查询、访问数据、返回结果。Pi 可以通过 pi.registerTool() 注册；Claude Code 常通过 MCP 连接外部工具，Agent SDK 也有工具接入能力；LangChain 则把业务函数包装成 Agent 可调用的工具。
检查权限，是执行层。 用户与租户身份应来自可信的应用上下文，由工具或后端验证。让模型自己填写 tenant_id，然后完全相信它，三种方案都会出问题。
再往下看，差别出现在具体能控制哪些环节。
Pi 的扩展是 TypeScript 模块。tool_call 可以在执行前处理输入或阻止调用，tool_result 可以处理返回结果，context 可以调整送给模型的对话材料。开发者可以把这些接口组合成自己的运行规则。
比如，知识库一次返回了大量无关内容。你可以让工具只返回相关片段与资料编号，把完整结果留在外部存储；也可以在模型调用前整理历史内容，避免同一批资料反复占据上下文。
Claude Code 也能通过 Hooks、权限配置和扩展接口改变行为。若团队需求正好落在这些能力覆盖范围内，沿现成产品扩展可能更省维护。Pi 的价值要落到你确实需要控制的接口上，不能简单概括为“Pi 开放，Claude Code 不可改”。
LangChain 的 middleware 同样可以介入模型与工具调用，适合把应用规则放进运行逻辑中。对于已经围绕 LangChain 组织工具、数据与监控的团队，迁移到另一套环境需要有明确收益。
我的选择方法是先列出必须控制的行为，再逐项找接口。
只需要换一套提示词，就别因为“更灵活”重搭系统。确实需要持续切换模型、改写上下文和定制交互，再认真评估 Pi 能减少哪些工作。灵活性只有用到时才产生收益，没用到的部分也可能变成维护负担。
第三层比较：会话能保存，业务就能恢复吗？
到这里，三者都能接工具、改行为，看上去区别不大。把任务放到线上，差异会更明显。
假设需求是：读取客户问题，查询订单，生成回复，等主管批准后发送。中间可能隔几个小时，进程也可能重启。
这时需要保存两类东西。
一类是对话：模型看过什么、调用过哪些工具、接下来还能用什么信息。另一类是业务状态：草稿哪个版本被批准、谁批准的、消息有没有发出去。
Pi 的会话可以持久化和分支，帮助重建模型上下文。它适合继续一段工作，也便于探索不同路线。但一份对话记录，不会自动变成订单系统里的审批和发送账本。
LangGraph 更直接处理流程状态、检查点、中断和恢复。LangChain 的 Agent 就建立在 LangGraph 之上；当工作从一次对话发展成长时间业务流程时，这层能力值得单独评估。
例如，审批可以成为明确的中断点。人工给出结果后，用相同线程的状态继续执行，而不必靠模型从一段聊天里猜“刚才批没批准”。
但这也不是自动获得可靠性。LangGraph 的中断节点恢复时会从头执行，节点中的某些操作可能重跑；使用内存检查点，也无法跨进程重启保存状态。持久化后端、业务幂等和异常处理仍需设计。
所谓幂等，可以用一个问题说明：同一条已批准的回复被重试两次，客户会收到一条还是两条？
如果下游已发送成功，应用却在记录结果前崩溃，单靠“保存了图状态”无法排除重复发送。业务系统需要稳定的操作标识、下游幂等支持或对账机制。审批还应绑定草稿版本，不能批准旧内容后让 Agent 随意改完直接发送。
允许加载项目资源，不等于隔离工具的运行范围。
落到选型上，我会这样划分：
个人或团队的交互式助手： 先比较 Pi 与 Claude Code 的实际工作体验、工具接入和扩展成本。
嵌进自家产品的 Agent： 比较 Pi SDK、Claude Agent SDK，以及 LangChain / Deep Agents 提供的运行能力。
有长时间等待、多人审批和失败恢复的业务： 把 LangGraph 或已有业务编排系统纳入方案，明确状态、重试和副作用的责任。
它们甚至可以组合。Pi 负责某个需要模型判断的步骤，外部流程系统负责审批和恢复。组合时要避免内外两层各自重试，最终把一次失败变成多次写入。
权限隔离同样需要单独设计。Pi 扩展与运行进程拥有相同的操作系统权限；项目信任机制不等于沙箱。能控制上下文、能拦截工具调用，都不能直接替代文件、网络和凭据的执行隔离。
我的看法：Pi 的价值，在于让改造工具变得日常
回看开头那些例子，Doom 是一个吸引眼球的演示，交互式终端扩展则更接近实际需求。两者指向同一个变化：开发者开始把 Agent 本身也当成可以持续修改的软件。
过去，我们更多是在现成工具里调整设置；现在，模型可以参与编写扩展，开发者负责提出需求、检查结果和决定边界。Pi 给这套工作方式提供了比较明确的接口。
我认为，这比“又一个 Claude Code 替代品”更能解释它的吸引力。替代品通常比谁现成功能更多，而 Pi 让一部分用户愿意先保留一个较小的核心，把特定功能交给自己来做。
不过，核心小不意味着项目简单。工具接多了、用户变多了，版本兼容、权限、恢复和监控一样会出现。今天让 Agent 帮你写好的扩展，明天也需要有人判断它还能不能正确工作。
所以我不会只因为 Pi 轻量就推荐团队迁移，也不会因为 LangChain 提供的组件多就说它臃肿。判断依据应当是：你要直接完成工作，还是要塑造自己的助手，还是要运行一套可恢复的业务流程？
这三种需求，对应三笔不同的工程账。
如果要试 Pi，我建议先挑一个现有工具让你不满意的具体步骤，做成扩展，然后用同一批任务比较成功率、人工修正量、费用与维护工作。能清楚说出它替你解决了什么，再决定要不要把更多东西搬过去。
至于 Pi 后续能走多远，我更想观察的是：这些个人扩展能否沉淀成可靠、可复用的能力。演示让人愿意点开，持续可维护才会让人留下。
▪️感谢你的阅读，如果觉得有帮助，随手点个关注,赞👍🏻和推荐♡吧~
▪️这里是Cyber.阿雷克西，欢迎评论区留言分享你觉得好用的 AI 产品 / 工具~
▪️或许会在不经意间帮助到更多朋友~ 我们下期见~