开箱即用 vs 自研底座:OpenClaw 与 Pi

开箱即用 vs 自研底座：OpenClaw 与 Pi

01 演进路径：为什么很多公司先用 OpenClaw，后转 Pi

这两年一个反复出现的落地姿势是：团队先拿 OpenClaw 把 AI 助手跑起来，等业务真长出来、要嵌进自有系统时，再迁到 Pi 这类能“自己改”的底座上做二次开发。

这背后的逻辑并不复杂。Agent 项目早期最大的不确定性不是“模型够不够强”，而是“到底要解决谁的什么流程”。先用一个开箱即用的工具，能以最小代价验证需求、收集反馈；等需求清晰、且 Agent 要从“外部助手”变成“产品内部能力”时，开箱工具的可定制天花板就显出来了，这时候才值得投入研发，把 Agent 做成可随业务迭代的代码底座。

一句话概括两种产品哲学：

• 开箱即用派（OpenClaw）：把能力打包好，你接上聊天渠道就能用，产品/运营都能参与。
• 可改造底座派（Pi）：把最小内核交给你，扩展点全部开放，你自己按工作流搭积木。

1.1 为什么需要 Agent 框架

直接调 LLM API 只能做“问答”。一旦要让 AI 真正办事——读文件、发消息、调内部接口、多步推理——就需要工具调用、状态管理、渠道接入、权限边界这一整套运行时。这两类框架解决的是同一件事，但给出的“默认形态”完全不同：OpenClaw 默认你是个用户，Pi 默认你是个开发者。

1.2 工作原理对比

OpenClaw 的运转围绕“聊天渠道 → Gateway → Agent Runtime + Skills”展开：用户在 WhatsApp/Telegram/Discord/Slack 等渠道里 @ 它，Gateway 统一接收并路由，Runtime 加载 100+ 个 Skill 执行任务，底层接多 Provider 大模型。

Pi 则完全是另一条链路：你的业务系统通过 SDK 或 RPC 调用 Pi，下面依次是 pi-agent-core（工具执行与状态管理）、pi-coding-agent（交互式编码 Agent CLI）、pi-ai（统一多 Provider LLM API），再往下是 15+ 模型 Provider。Agent 不再“等人发消息”，而是“被代码调用”。

图 2 把两条链路并列，差异一目了然。

02 两个项目到底是什么

2.1 OpenClaw 定位与能力

OpenClaw 是 local-first 的开源个人/多 Agent 助手运行时，核心价值是“开源透明、数据自主、跨平台、可组合”。它强调本地运行、清晰的权限边界，以及工具 + 自动化 + Gateway 的可组合执行能力。社区提供 100+ 预置 AgentSkills，能对接 50+ 第三方服务，支持把对话能力挂到 WhatsApp、Telegram、Discord、Slack、iMessage、Teams 等渠道。

2.2 Pi 定位与能力

Pi（earendil-works/pi）官方自述是“AI agent toolkit: unified LLM API, agent loop, TUI, coding agent CLI”，更准确地说是一个 极简、终端核心、可自我扩展的 Coding Agent Harness。它是一个 TypeScript monorepo，由五个正交分层包组成：pi-ai（统一多 Provider LLM API）、pi-agent-core（Agent 运行时：工具调用与状态管理）、pi-coding-agent（交互式编码 Agent CLI）、pi-tui（差分渲染终端 UI）、pi-web-ui。设计哲学是“适应你的工作流，而非让你适应工具”——核心保持极轻，把扩展点开放出来。

2.3 核心差异一览

03 二次开发：扩展方式差异

光看定位还不够，落到“二次开发”上，两条路线的代码形态差别很大。

3.1 OpenClaw：Skill 与 Gateway 扩展

OpenClaw 的扩展以“配置 + 插件”为主。装好之后，靠 onboard 向导把认证、Gateway、渠道一次性接好，群聊里 @ 就触发，几乎不写代码：

bash
# 安装（需要 Node.js 22+）npm install -g openclaw# 配置向导：认证 → Gateway → 渠道（如 Telegram）openclaw onboard --install-daemon# 启动后在群里 @ 即可触发，无需写代码openclaw start
执行结果如下：
plaintext
[ok] daemon registered[ok] gateway listening on :8787[ok] channel telegram connectedready. type @claw <指令> in your chat.
进一步做业务动作，OpenClaw 的 Skill 以 Markdown + Frontmatter 描述行为，由运行时加载，非研发也能参与维护：
markdown
---name: jira-ticket-creatordescription: 根据对话内容在 Jira 创建工单triggers: ["建单", "提 bug"]---# 当命中 triggers 时，调用 Jira REST API 创建工单，# 并把返回的 ticket key 回写到群聊。
3.2 Pi：SDK/RPC 嵌入与 TypeScript 扩展
Pi 的扩展是“代码级”的。先装好 coding agent，之后关键的不是把它当终端工具，而是把它的能力编进你自己的系统。下面是一段将 Pi Agent 嵌入后端服务的示意（具体 API 以官方文档为准）：
typescript
// 将 Pi 的 Agent 能力嵌入业务系统（示意）import { createProvider } from "@earendil-works/pi-ai";import { runAgent } from "@earendil-works/pi-agent-core";const provider = createProvider({  type: "openai",  apiKey: process.env.OPENAI_KEY,});// 在你的后端服务里调用，而非独立终端const result = await runAgent({  provider,  tools: [myBusinessTool],        // 注入业务工具  prompt: "根据订单状态给用户发提醒",});
如果标准工具不够，用 TypeScript Extension 自定义业务工具，热重载即可生效：
typescript
// pi 扩展：自定义一个业务工具（示意）export default defineExtension({  name: "order-reminder",  tools: [{    name: "query_order",    description: "查询订单当前状态",    run: async ({ orderId }) => db.orders.find(orderId),  }],});
执行结果如下：
plaintext
[pi] loaded extension: order-reminder[pi] tool registered: query_orderagent ready via SDK, callable from your service.
3.3 扩展模式对比
图 3 用“业务系统”作中心，直观说明两种集成面的本质：OpenClaw 把 Agent 当“同事”加进群聊，人发指令它执行；Pi 把 Agent 当“函数”编进系统，业务事件自动调用。

═════════
04 场景化技术推荐
选型没有“更好”，只有“更合适”。下面按真实业务场景给出推荐。
4.1 场景矩阵



场景
推荐
原因




个人/小团队快速有个 AI 助手
OpenClaw
开箱即用、多渠道、零研发


飞书/企微/Telegram 群聊机器人
OpenClaw
渠道接入成熟，Skill 丰富


把 Agent 能力嵌入自家 SaaS 产品
Pi
SDK/RPC 嵌入，随产品迭代


需要深度定制 Agent 逻辑/工具
Pi
TypeScript 扩展，核心极简可控


编码助手 / 研发提效工具
Pi
本身就是 Coding Agent Harness


业务规则频繁变化、需快速试错
OpenClaw 起步，Pi 兜底
先验证，核心逻辑再用 Pi 重构


严格合规 / 数据不出域
两者均可本地化
均 MIT 自托管；Pi 需自行做沙箱



4.2 演进路线图
图 4 给出一条务实的四阶段路径。注意：不是所有公司都要走到阶段 4。阶段 1-2 足以覆盖绝大多数“助手/机器人”需求；只有当“Agent 要成为产品的一部分、要随业务持续迭代、要可控可观测”时，才值得投入 Pi 自研。

4.3 给技术决策者的结论

如果你要的是“尽快有个能用的 AI 助手/群聊机器人”，选 OpenClaw，把研发精力留给业务本身。
如果你要的是“把智能体变成自家产品的一项能力”，选 Pi，并接受它需要 TypeScript 工程投入。
最常见的正确姿势是混合演进：先用 OpenClaw 验证需求与流程，等需求清晰、且确实要嵌入系统时，再用 Pi 做底座重构核心逻辑。这两条路线不是二选一，而是同一件事的早期与后期。

═════════




本文对比基于 OpenClaw 与 earendil-works/pi 的公开定位与文档（2026-07 整理）。具体 API 与版本请以各项目官方仓库为准。




欢迎在评论区聊聊：你们团队现在处在哪个阶段？是 OpenClaw 起步，还是已经在用 Pi 做自研底座？