[效率] Pi Agent：一个把子代理和计划模式都删掉的编程工具，凭什么说它更适合普通人

💡 前阵子我连着写了两篇 Claude Code 的入门稿，把安装路线、模型接入和权限模式摊开讲了一遍。写完没多久就刷到另一条视频，标题起得很冲——《Pi Agent：比 Claude Code 和 Codex 更适合普通人的 AI 工具》，up 主是「第四种黑猩猩CHIMP」，二十一分钟的口播，播放十七万多，收藏八千七。

我第一反应是这标题在碰瓷。Claude Code 和 Codex 是两家公司官方下场的产品，一个是 Anthropic 的，一个是 OpenAI 的，GitHub 上分别挂着十四万九和十二万八的 star；Pi 是一个开源组织做的命令行工具，凭什么"更适合普通人"？

但把它装上跑了一遍、把仓库文档从头读到尾之后，我的判断变成了另一件事：这句话里的"普通人"三个字，其实指向一组非常具体的需求——装得上、连得通、花得起、而且不必只写代码。Pi 在这四件事上确实做了和那两位不同的取舍，只不过它同时也拿走了一样东西，而那样东西恰恰是很多教程不会提醒你去想的。

这篇就把三个工具放在同一张桌子上：先给一份当天的实测数据快照，再顺着"普通人四问"拆开看，然后讲 Pi 的核心设计（一个被刻意做小的内核 + 四类扩展挂载点），中段专门说清它故意没给什么、以及那位的安装命令为什么会让人装错，最后回到风险——这节是全文我最想写清楚的。

1. 先给一份快照：2026-10-09 这三个工具各自是什么样

写对比最怕拿记忆里的旧数据说事，所以这一节的数字全部是我在 2026 年 10 月 9 日当天从 GitHub API 和 npm registry 拉的原始字段。

三个数字值得停一下。

第一，Claude Code 的 star 最多，但它的 GitHub 仓库在协议这一栏是空的——那个仓库主要是文档、issue 跟踪和插件示例，npm 包里的 license 字段写的是 SEE LICENSE IN README.md。Codex 是 Apache-2.0，Pi 是 MIT。所以如果"开源"这件事对你重要，那这三者里只有两个真的把许可证挂出来了。

第二，三者都还很年轻。仓库创建时间全落在 2025 年，Codex 的 Rust 主体和 Pi 的 monorepo 到现在都还在日更（推送时间分别是 10-09 和 10-08）。这意味着任何"某某工具已经成熟到可以无脑用"的说法，保质期都不会超过一个季度。

第三，Pi 的贡献者结构比较特别：badlogic（Mario Zechner）3,854 次提交，第二名 mitsuhiko（也就是 Flask 的作者 Armin Ronacher）863 次，再往下是 303、215、199。它不是大厂的产品线，而是几个很有名的个人工程师攒出来的工程品——这个区别会贯穿后面所有的设计取舍。

Q1：那 Pi 到底是什么？官方自己是怎么定义的？

README 第一句就是定义：Pi is a minimal, extensible agent harness that you can make your own.（一个最小可扩的 agent 骨架，你可以把它变成自己的东西。）

官网 pi.dev 上有一句更像口号：There are many agent harnesses but this one is yours.

“骨架”（harness）这个词是它自我定位的关键。它不宣称自己是"AI 编程产品"，它宣称自己是装载模型、工具、上下文和会话的那层壳。这层壳做小了，剩下的空间留给你自己填。

Q2：它凭什么说能覆盖编程之外的事？

官方文档首页有一句我认为整篇对比里最要紧的话：

Use Pi for software development, research notes, writing projects, data files, or hobby work.

写研究笔记、写东西、处理数据文件、玩票性质的活儿——这五项是官方文档主动列出来的用途，不是我替它引申的。而 Claude Code 和 Codex 的官方自述里，主语境内都只有代码仓库。

"普通人"这个说法如果成立，第一个支点就在这儿：它从一开始就没假设使用者是开发者。

2. 把"更适合普通人"拆成四个能验证的问题

标题里那句断言，只有拆成具体动作才知道真假。我按一个非开发者真实会走的顺序拆成四问。

Q1：装得上吗？

Pi 官方给了四条安装路径，覆盖的机器类型比另外两个都宽：

macOS / Linux curl -fsSL https://pi.dev/install.sh | sh
Windows powershell -c "irm https://pi.dev/install.ps1 | iex"
npm（可选） npm install -g –ignore-scripts @earendil-works/pi-coding-agent
Nix nix profile add github:earendil-works/pi/stable

三条细节值得抄进笔记本：

• 官方文档写明 Pi 需要 Node.js 22.19 或更新，macOS / Linux / Windows 的安装脚本会代劳装 Node。对不用命令行管运行时的人，这是真的省事。
• 安装脚本会把依赖钉死（“The installer pins all dependencies”），而直接走 npm 装则不锁传递依赖。同一个工具，两条路的安全边界不一样。
• 官方在多处强调 normal npm 安装不需要依赖的 lifecycle 脚本，所以命令里带着 –ignore-scripts。这不是客套，是防供应链攻击（第 7 节展开）。

除此之外还有一条我觉得最"普通人"的路径：Android 上的 Termux 有官方文档（termux.md），明确支持文本输入、文件工具和 shell 命令，装了 Termux:API 还能读写安卓剪贴板，只有剪贴板图片不支持。一台旧安卓机当终端跑 agent，这条路线在 Claude Code 和 Codex 的官方文档里我没找到对等物。

对照着看，Claude Code 的 README 现在把 npm 安装明确标成 deprecated，推荐 curl -fsSL https://claude.ai/install.sh | bash、Homebrew cask、Windows 的 irm 脚本或 WinGet；Codex 同样有 curl -fsSL https://chatgpt.com/codex/install.sh | sh、brew install –cask codex、npm 和各平台的 release 二进制。三者在"装"这件事上其实都已经做得不错了，Pi 的加分项是 Node 版本自动补齐和 Termux。

Q2：连得通吗？（也就是手上那个模型能不能接进来）

这才是普通人真正卡住的地方。装完只是拿到一个命令行，接不上模型它就是一坨终端界面。

Pi 的官方 providers.md 里，只统计"单个主要 API Key 变量"那张表就列了 33 个入口：Anthropic、Ant Ling、OpenAI、DeepSeek、NVIDIA NIM、Google Gemini、GitHub Copilot、Mistral、Groq、Cerebras、xAI、OpenRouter、Vercel AI Gateway、ZAI Coding Plan（Global / China 两档）、OpenCode Zen and Go、Radius、TypeSafe、Hugging Face、Fireworks、Together AI、Baseten、Kimi For Coding、Meta、MiniMax（含 China）、Moonshot AI、Qwen Token Plan（含 China）、Xiaomi MiMo（含 China / Amsterdam / Singapore 三档）。表格外还有 Amazon Bedrock 和 Google Vertex AI 可以直接吃云上环境凭据。

我把这些名字念一遍你会发现规律：除了 Anthropic 和 OpenAI，剩下的几乎全是"订阅计划"或者"国产 coding plan"。

这就是它和另两位最硬的分野。Claude Code 的官方语境里，模型来源是 Anthropic 的订阅 / API Key，以及 Bedrock、Vertex 这些云上转售的 Claude 模型；Codex CLI 的名字直接绑在 OpenAI 和 ChatGPT 订阅上（curl 脚本都挂在 chatgpt.com 域名下）。而 Pi 把自己放在"壳"的位置，模型是谁的不重要，重要的是它有统一的 LLM API 层（monorepo 里那个 @earendil-works/pi-ai，官方描述就是 “Unified multi-provider LLM API (OpenAI, Anthropic, Google, etc.)”）。

对国内使用者，这条差异是实打实的钱和可用性：Kimi For Coding、Qwen Token Plan、MiniMax、Moonshot、Z（智谱）的 coding plan、DeepSeek，都在这张表里。

凭据取用优先级官方也写清了（这条很实用，很多人配了环境变量不生效就是栽在这儿）：

运行时 –api-key > auth.json 里存的凭据 > models.json 里的 apiKey > 提供商环境变量 / 云端环境凭据

连本地模型也有路：models.md 给的选择表里，"本地 GGUF 模型"对应的是把 Pi 接到 llama.cpp router；OpenAI / Anthropic / Google 三种协议兼容的自建端点写进 models.json 就行。

Q3：花得起吗？

pi.dev 上有句原话，我认为这是 Pi 全部卖点里最可验证的一句：

Pi supports skills, AGENTS.md files and is very token efficient due to its minimal system prompt.

系统提示词短，每次请求带过去的固定开销就小。对天天烧 token 的人是效率问题，对"一个月想省几十块"的普通人是价格问题——这两件事在成本上同源。

配套的可见性也做了：交互界面底部的 footer 显示当前目录、会话、模型、上下文占用，以及累计用量和费用（usage.md 原话：“The footer updates as the model uses context and reports usage.”）。/session 能看到下一次缓存决策。而模型目录本身带价格数据，Pi 出厂带一份内嵌目录，还能从 pi.dev 叠加更新的目录数据，pi update –models 手动刷新，缓存的目录可离线用。

省不省得到钱，取决于你选的模型；但至少"这一轮花了多少"这件事，它摆在了明面上。

Q4：只有编程能干吗？

这一问的答案在第 4、5 节：它的四类扩展机制加上"按需加载指令"的 skills 设计，让它能干写作、笔记、数据这类活儿。反过来说，这也正是它把子代理和计划模式删掉之后仍然完整的理由。

上面这张是静态版，下面这张是把同一个论证做成会跑的面板：四问从左往右逐条点亮，每个问题右边的三个答案格同时亮起来，底部一行给出该问的结论。屏上滚动的计数和状态条是面板自造的示意数字，不是实测数据。

3. 它到底装了什么：monorepo 里的七个包

很多人以为 Pi 就是一个 CLI，其实仓库是一个 monorepo，CLI 只是最外面那个壳。把这层结构看清楚，后面所有扩展能力都不难理解。

npm 上 @earendil-works/pi-coding-agent 的包描述更直白：“Coding agent CLI with read, bash, edit, write tools and session management”——内置工具就是读、跑命令、改、写四件，加上会话管理。这个工具面小到这种程度地写进包描述，本身就是一种设计宣言。

how-pi-works.md 把运行机制讲了四段，我摘成一张流程：

提交消息 → 追加到 session 树的 active branch
→ 组装请求（system prompt + active branch + 可用工具 + 模型设置）
→ 经选定的 provider 流式发出
→ 收到文本 + 工具调用，记录、执行、记录结果 = 一轮
→ 还需要下一轮就继续，否则 run 结束

三个我觉得设计得干净的地方：

• 会话是 JSONL 文件里的树，每条 entry 有 ID 并指向父节点，当前 entry 决定 active branch。回到之前某条消息再继续，就是在同一文件里开新分支；fork 和 clone 会把选定的历史复制成另一个会话文件。官方演示里专门展示了"rewind 到任意一条消息、从那儿分叉、把整个会话分享给别人"。
• 压缩（compaction）不是删历史。它插入一条摘要 entry，在后续模型请求里替换掉旧消息，原始 entry 依然留在树里。
• 四种使用形态共用同一套 agent 与 session 机制：交互 TUI、print 模式（跑一条命令拿最终结果）、JSON 事件流（输出 JSONL 事件）、RPC（stdin/stdout 控制一个独立 Pi 进程），以及 TypeScript SDK 在应用内起会话。你在终端里用的一切，脚本里都能一样用——这是很多工具做不到的对称性。

4. 四类扩展挂载点：这才是"最小内核"的另一半

"内核做小"只讲了它删了什么，剩下的空间靠什么填，是这一节。官方 README 的顺序是 extensions、skills、prompt templates、themes，然后打包分发。

4.1 Extensions：直接是进程内的 TypeScript 模块

适用判断官方写得很克制：当工作流需要工具、命令、事件处理器、模型 provider、会话状态或终端界面，而不只是"多一段指令"时，才用 extension。

一个最小例子，官方文档给的就是这十行（放 ~/.pi/agent/extensions/hello.ts）：

import type { ExtensionAPI } from "@earendil-works/pi-coding-agent";

export default function (pi: ExtensionAPI) {
pi.registerCommand("hello", {
description: "Show a greeting",
handler: async (name, ctx) => {
ctx.ui.notify(`Hello, ${name || "world"}!`, "info");
},
});
}

启动 Pi 后敲 /hello。开发阶段可以直接 pi –extension ./hello.ts 单挂一个文件试。它用 jiti 加载，本地 TS 扩展不需要先编译——这一点比 Claude Code 那类"你得先把插件目录结构搭对"的体验省事得多。

官方给的能力清单（"Choose an integration point"那张表）我原样列一遍，因为这几乎是它的 API 地图：

事件侧也做得细：before_agent_start 能同时拿到当前 prompt 和结构化的 systemPromptOptions；message_end 可以替换已定稿的消息；tool_call 可以改入参甚至直接拦掉；tool_result 的多个 handler 按顺序叠加，每个都能看到前面的改动。换句话说，权限确认这件事在 Pi 里不是没有，而是它把拦截点留给了扩展。

4.2 Skills：只在需要时把全文读进上下文

Pi 实现的是 Agent Skills 规范（SKILL.md + frontmatter 的 name / description）。它的加载模型是整段设计里我认为最值得抄走的一条：

启动：扫描 skills 目录 → 只把 name + description + path 写进 system prompt
运行时：任务命中 → 模型自己去读 SKILL.md 全文
强制：/skill:name 手动触发（后面还能带参数）

也就是说，Detailed 指令在没被用到之前不占上下文。官方还提醒了一句很实在的话：模型有可能没能加载相关的 skill，需要时请用 /skill:name 强制。frontmatter 里可以设 disable-model-invocation: true，让这个 skill 只能通过显式命令使用。

这条机制解决的是所有 agent 用户都会遇到的那件事：装了十个 skills 之后，system prompt 胖成球，每一轮都在为用不到的指令付 token。

4.3 Prompt Templates：Markdown 文件直接变成 / 命令

适用判断同样克制：想复用同一段 prompt，但不需要可执行行为、也不需要一整套附加指令时，用 prompt template。

—
description: Review staged git changes
argument-hint: "[focus]"
—
Review the staged changes. Focus on ${1:-correctness, security, and error handling}.

文件名即命令名，${1:-默认值} 是参数位。个人目录 ~/.pi/agent/prompts/、项目 .pi/ 都能放，项目配置只在 project trust 通过后才加载。

4.4 Themes 与 Packages：把上面三样打成一个包发出去

主题管终端配色。真正让"最小内核"能变成"什么都能凑出来"的是 packages：

pi install npm:@scope/package
pi install git:github.com/example/pi-tools@v1
pi install ./local-package
pi list
pi update –extensions # 更新所有已装包
pi update <source> # 只更新一个

个人安装写进 ~/.pi/agent/settings.json，加 –local / -l 写进项目的 .pi/settings.json（要先给 project trust）。想临时试一个包又不想动配置：pi -e npm:@example/pi-tool。

官方在这里的安全提醒，我把原文留着：package 会执行扩展代码，也可能带 skill 去指挥模型跑程序；装第三方包之前先读它的源码。

这张会跑的面板演示的是同一套机制在时间轴上的样子：一轮 run 从"组装上下文"走到"模型返回"再回到组装，右栏的四个资源位在被取用的那一刻亮起来；底下的条是上下文占用，接近阈值时插一条摘要 entry，历史记录本身不删。屏上的轮数和 token 数是面板自己累计的示意数字，不是实测。

5. 它故意没给什么，以及已经内置了什么

这一节是标题里那句话真正的战场。

Q1：README 里那句"skips features"具体指什么？

原文：

Pi ships with powerful defaults but skips features like sub-agents and plan mode. Ask Pi to build what you want, or install a package that does it your way.

它点名少掉的是子代理和计划模式。这两样恰好是 Claude Code 官方文档里的两大卖点（plan mode、subagents，外加 hooks、MCP、skills 一整套）。

官方给的补法有两条：让 Pi 自己现造，或者装一个按你的方式实现的包。这句话的潜台词其实挺硬：它认为"子代理"和"计划模式"不该由工具替你定义形状。

这一点我持保留意见。对熟练的人是自由，对普通人恰恰相反——他不知道"计划模式"应该长什么样，你删掉一个他本来能直接按的按钮，他得到的不是自由而是空白。

Q2：那 MCP 呢？（网上不少旧文章说 Pi 不支持，现在要更正）

截至 v1.1.0，Pi 的 MCP 支持是内置的，不需要第三方适配包。 官方 mcp.md 给的入门就是三条命令：

pi mcp add filesystem — npx -y @modelcontextprotocol/server-filesystem .
pi mcp add docs –url https://example.com/mcp –bearer-token-env-var DOCS_TOKEN
pi mcp list

配置读写位置是 ~/.pi/agent/mcp.json（用户级）和 .pi/mcp.json（项目级，project trust 之后才读），同名时项目覆盖用户。stdio 走 command / args / env / cwd，远程走 url / headers / oauth，还能设 exposure / toolExposure 控制工具怎么暴露给模型。会话里 /mcp 能看连接状态、登录、重连、启停。扩展也能 pi.registerMcpServer() 动态注册。

我特意查了 npm 上的生态位，发现 Pi 的扩展生态是"补内核没做的事"，而不是"内核做不了事"：

版本号本身就是信号：一个社区扩展能迭代到 40.x，说明这条"内核最小 + 扩展补位"的路线真的有人在用、在维护。

Q3：那个 npx @agegr/pi-web@latest 到底是什么？（这条最容易装错）

视频简介给的整句安装命令是 npx @agegr/pi-web@latest。我把它的 npm 元数据拉下来核对过：

包名 @agegr/pi-web
版本 0.11.0（截至 2026-10-09，累计 102 个版本，创建 2026-03-24）
描述 Web UI for the pi coding agent
可执行 pi-web
许可证 MIT
仓库 github.com/agegr/pi-web
Node >=22.19.0

它是给 Pi 套的第三方图形界面，不是 Pi 本体的官方安装命令。 官方 CLI 的入口是 curl -fsSL https://pi.dev/install.sh | sh（或 npm 全装的 @earendil-works/pi-coding-agent）。顺带一提，pi 命令自己的子命令只有 install、update、list、mcp 这几类，没有 pi web。

而且这一族已经长出一片 fork：@rainmanhhh/pi-web 0.27.0（描述直接写着 “fork of @agegr/pi-web”，版本号已经跑到 0.27）、@silgrid/pi-web、@pricening/pi-web、@baique/pi-web-sky、@xup3ng/pi-web、@calmabacus/pi-web、@cyia/pi-web、@praveenc/pi-web，还有给 oh-my-pi 用的 omp-web。

这对普通人的实际影响很直白：同一条 npx 命令换个 scope 就是另一批代码，还都在活跃更新。 装之前先确认包名和作者，别照抄标题里的命令。我的建议是——先用官方 CLI 跑通一次（少一层依赖），再按需选一个 Web UI。

6. 上下文与成本：为什么"省 token"对普通人是真需求

把这一节单独拎出来，是因为它常被当成工程师的自嗨，实际上它是普通人和重度用户之间最硬的那道墙。

Claude Code 和 Codex 都是"产品"：功能、默认提示词、内置子代理定义都由厂商替你定好，代价是每次请求的固定开销你也拿不掉。Pi 是"骨架"：它把 system prompt 做小（pi.dev 明说 token efficient 的原因就是 minimal system prompt），然后把"要不要多带一点指令"的选择权交给 skills 的按需加载。

固定开销 = 基础 system prompt + 已加载上下文文件 + 工具定义 + skill 的 name/description
可变部分 = 任务消息 + 工具结果 + 历史（或被 compaction 摘要替换）

对照着看，Pi 在这条线上做的每一件事都指向同一个目的：

• skill 全文按需读入（不在上下文里常驻）；
• 压缩插入摘要 entry，后续请求用摘要替代旧消息，原文仍在树里；
• 工具能不能被模型看见由 exposure / toolExposure 控制，MCP 挂十个 server 也不必把全部工具描述都塞进 prompt；
• prompt cache 有专门机制，且只有当模型声明了缓存生命周期、并且估算能省下至少 $0.05 的缓存未命中成本时才做预热（settings.md 原口径）；
• thinkingBudgets 让 minimal / low / medium / high 四档思考各自有 token 预算；
• 会话可分支，同一段前缀复用；/model 与 Ctrl+L 可以随时把贵的模型换成便宜的。

对普通人的意义：你不必为了让它"更懂你"而写一份巨大的常驻提示词。要它懂你的写作规范，做成 skill；要它每次按固定格式回复，做成 prompt template。这两种做法都不抬高每一轮的固定开销。

反过来，如果一个人从来不看用量，那这些机制他一时半会儿也用不上——省成本这件事，永远建立在"知道自己花了多少"上面。

7. 风险这一节不能跳过：它不问你要权限，也不拦你

如果我在这里顺着标题一路夸下去，这篇稿子就没必要写了。

Q1：Pi 的默认权限是什么？

README 里有一节标题就是 “Permissions & Containerization”，第一句写得毫不含糊：

Pi does not include a built-in permission system for restricting filesystem, process, network, or credential access. By default, it runs with the permissions of the user and process that launched it.

usage.md 补了交互层的同一件事：Pi does not ask before every tool call.（它不会在每次工具调用前问你。）security.md 更直白：扩展、包安装器、语言服务器和其他子进程都以启动者的权限运行；只要 trust 判定过了，之后就是"模型说，工具做"。

这跟 Claude Code、Codex 的路数是相反的。Claude Code 在 CLI 里给出 allow / ask / deny 的权限规则和若干权限模式（含 plan、acceptEdits 这类），Codex 的官方仓库 docs/ 里 sandbox.md 直接指向"Sandbox & approvals"文档、execpolicy.md 指向执行策略文档。那两家把"审批"做进了产品，Pi 把"边界"交还给操作系统和容器。

对普通人的直接影响是：少了那些弹窗，确实少了摩擦；但同样意味着，当模型被一句网页里的恶意内容带跑（prompt injection，官方专门列了这条：文件、注释、指令、命令输出、模型回复都可能引导模型），没有任何内置关卡会替你挡下那条 rm。

官方的处置方式也很诚实。security.md 明确写了：盯着 transcript、用 project trust、人工 review 改动，这些都不构成安全边界（“do not create a security boundary”）。真正的边界只有三种：

containerization.md 给了三种具体做法：Gondolin 扩展（pi 与 provider 认证留在宿主，把内置工具和 ! 命令路由进本地 Linux 微虚机）、直接用一个普通 Docker 容器跑整个 pi 进程、用 OpenShell 跑在策略控制的沙箱里。

我的口径是这样：只在你自己完全掌控的目录里、做不需要联网也不需要碰凭据的活儿，可以直接跑；只要任务涉及"去网上拿东西"或者读敏感文件，先套容器。

Q2：那它有没有认真做工程安全？有，而且做得比很多产品狠

这里必须给 Pi 补一句公道话。README 的 “Supply-chain hardening” 一节列的条目密度，远超我对个人项目的预期：

直接依赖全部钉到精确版本；.npmrc 设 save-exact=true 且 min-release-age=2
package-lock.json 是依赖的唯一真相；pre-commit 拦截误提交 lockfile
（除非显式设置 PI_ALLOW_LOCKFILE_CHANGE=1）
pi.dev 安装脚本从 install-lock/ 装，锁传递依赖；npm 包本身不锁
本地发布冒烟、npm 发布、CI 安装统一带 –ignore-scripts
CI 用 npm ci –ignore-scripts；另有定时工作流跑 npm audit –omit=dev
和 npm audit signatures –omit=dev
安装锁生成对依赖 lifecycle 脚本设显式 allowlist，新增带脚本的依赖不过检查

min-release-age=2 这条我特别喜欢：当天发布的依赖版本一律不采用，给恶意发版留出两天被发现的窗口。这是拿工程手段回答"普通人不可能逐条审计依赖"这个问题。

另外它的贡献流程也做了闸门：README 顶部写着新贡献者的 issue 和 PR 会被自动关闭，维护者每天审一遍。粗暴，但对一个 star 过十万、维护者是个位数的开源项目来说，这可能是唯一能坚持下去的办法。

8. 回到标题：这三个工具分别该给谁

我把自己的判断摆成一张决策表，按"你手上有什么"来分，不按"谁更强"来分。

再补一句我对标题本身的态度："更适合普通人"这句判断，方向对，但措辞反了。 Pi 更适合的其实是"知道自己要什么的普通人"——它把自由度换成了配置量，把审批弹窗换成了你自己划的边界。一个从来没想过"我要什么工作流"的人，打开 Pi 看到的是一个干净但空荡的终端；而一个早就想把自己的笔记规范、代码习惯、常用命令固化下来的人，会在它身上找到另外两个工具给不了的东西：这东西是我的。

最后总结

• Pi 的官方定位不是"编程产品"而是"agent harness"：README 原话 minimal、extensible、you can make your own；monorepo 七个包，CLI 只是最外面那层，内置工具按 npm 包描述就是 read / bash / edit / write 加会话管理。
• "普通人"三个支点它确实踩住了：Node 版本安装脚本代劳（含 Windows 与 Android Termux 官方文档）；33+ 个 provider 入口，国产 coding plan 成排出现在官方表里；minimal system prompt 带来可核查的 token 优势，footer 直接把用量和费用摆在状态栏。
• 四类挂载点是它的真正竞争力：extensions（进程内 TS，11 类 API）、skills（实现 Agent Skills 规范，全文按需加载）、prompt templates（Markdown 变 / 命令）、themes，四样能打成一个包用 pi install npm: / git: 分发。
• 两个需要更正的旧印象：一是 MCP 到 v1.1.0 已是内置（pi mcp add / /mcp / mcp.json），不再需要适配包；二是视频简介里的 npx @agegr/pi-web@latest 装的是社区 Web UI（0.11.0，MIT），不是 Pi 本体，而且这一族已有近十个 fork。
• 它删掉子代理和计划模式，换来的是你得自己定义形状；社区用 40.x 的 @gotgenes/pi-permission-system 把权限强制补了回来——这既说明生态真的能用，也说明被删掉的那部分不是伪需求。
• 风险必须摆在最后一条：Pi 没有内置权限系统，且不会每次工具调用都问；官方自己写明 project trust 和人工 review 都不是安全边界，真边界只有容器 / 微虚机 / 沙箱。与它的供应链硬化（精确钉版、min-release-age=2、统一 –ignore-scripts、定时 npm audit + audit signatures）合起来看：它认真防的是"依赖害你"，而把"模型害你"这件事留给你自己。
• 一句话结论：Pi 不是更强的 Claude Code，它是另一种契约——工具少管你一点，你多想一步。愿意多想的人，它确实更合手；不愿意的人，那两个"话多、弹窗多"的产品才是给他准备的。

参考资料 & 致谢

[1] earendil-works/pi — GitHub 仓库与 README（含 Packages / Permissions & Containerization / Supply-chain hardening 各节） [2] Pi 官网 pi.dev（定位语、安装方式、模型目录与 token 效率说明） [3] Pi Quickstart [4] Pi — Use Pi in the terminal（footer 用量与费用、不逐次询问工具调用） [5] Pi — Choose a Model（33 行 provider 表、凭据优先级、本地 GGUF 路径） [6] Pi — Providers [7] Pi — Extensions（能力清单表、事件与 hook 点、registerMcpServer） [8] Pi — Skills（Agent Skills 规范与按需加载） [9] Pi — MCP Servers [10] Pi — Pi Packages [11] Pi — How Pi Works（agent 循环、session 树、compaction、四种界面） [12] Pi — Run Pi safely（三种运行方式对照、project trust 的边界） [13] Pi — Run Pi on Android with Termux [14] Agent Skills specification [15] anthropics/claude-code — GitHub 仓库 README（安装方式、npm 已弃用、插件目录） [16] openai/codex — GitHub 仓库 README 与 docs/ 目录（安装、sandbox & approvals、exec policy、AGENTS.md） [17] Pi Agent：比 Claude Code 和 Codex 更适合普通人的 AI 工具 — 哔哩哔哩（本文选题来源）

致谢：谢谢 up 主「第四种黑猩猩CHIMP」把 Pi 放进普通人的视野里；文中所有数字均为 2026-10-09 当天取自 GitHub API、npm registry 与官方仓库文档，与上面各链接一一对应。