Pi为什么突然火了：它可能比Claude Code更接近Agent的最终形态

2025年到2026年，Coding Agent这个赛道最明显的趋势是什么？

功能越堆越多。

打开Claude Code今天的能力清单，你会看到：文件读写、Shell执行、Web搜索、MCP协议对接、Skills系统、Hooks钩子、Memory记忆、Plan Mode计划模式、Subagents子智能体、Agent Teams团队协作、Plugins插件、Permission权限系统……甚至Anthropic已经把Claude Code背后那套agent loop、上下文管理、工具调用的底层能力，直接封装成了Agent SDK，让开发者可以照着这个思路自己搭Agent。

按正常的产品逻辑，功能越全，应该越有优势。Agent这种东西本来就要和真实世界打交道，多一个工具、多一层记忆，似乎都能让它更像一个能干活的人。

但就在这个方向越来越热的时候，一个反方向的项目突然火了。

它叫Pi。打开它的官网，第一句话不是“最强大的编程Agent”，而是一句朴素得有点意外的话：

Pi是一个极简的agent harness。

更反常识的是，Pi官方文档和社区资料里反复强调一件事：它故意保持小。默认核心工具只有read、write、edit、bash这4个；Subagent、Plan Mode这类能力不直接焊进核心，而是靠扩展、Skills、外部Package去补。

这篇文章不打算下“Pi比Claude Code强”这种简单判断，那样比较没有意义。更准确的说法是：Claude Code代表今天最好用的一类Agent产品；Pi更像是在探索Agent未来应该怎样被组织。 标题里“更接近最终形态”，说的是架构思想，不是当前产品的胜负。

真正的问题是：我们是不是把Agent做复杂了？

先把Agent拆开看：中间还有一层，很多讨论里被忽略了

平时讨论Agent，很容易混在一起讲。有人说模型强，有人说工具多，有人说上下文长，有人说MCP生态好。但一个Agent真正跑起来，至少分三层：

1
2
3

应用层负责产品入口，比如Claude Code、Pi、Codex；模型层负责生成下一步，比如Claude、GPT、Gemini、Qwen、DeepSeek；中间的Agent Harness负责把上下文、工具、循环、Skills、Memory和状态组织起来。

真正决定模型怎么工作的，主要是中间这一层。

过去两年，大家讨论AI编程，注意力几乎全部集中在最底层——Claude强还是GPT强，谁的代码能力更好。但进入Agent阶段之后，一个越来越明显的事实浮出水面：模型不是直接工作的。

真正决定模型“怎么工作”的，是中间这一层，业内把它叫作harness。它负责把上下文、工具、循环、Skills、记忆、权限、压缩、模型调用这些东西组织起来——模型负责生成下一步，harness决定模型什么时候看见什么、能调用什么、工具结果怎么回到上下文、会话满了怎么压缩、失败了怎么继续。同一个模型，换一个harness，表现可能完全不同。

这篇文章真正的主角，其实不是Pi，而是harness这个概念本身。Pi只是目前最适合用来讲清楚它的案例，因为Pi自己就是按这个思路拆的——它不是一个单体产品，而是一组包：pi-ai负责统一多模型接口，pi-agent-core负责工具调用和状态管理，pi-coding-agent是面向用户的交互式CLI，pi-tui负责终端界面渲染。官方仓库现在把整个项目描述为一个AI agent toolkit，而不是单纯的聊天工具。

理解Pi之前，先接受一个变化：到了Agent时代，模型只是发动机，harness才开始决定这辆车怎么开。

Pi做的第一件事：把Agent重新做小

Pi的作者Mario Zechner，网名badlogic，更早被很多人认识是因为libGDX——一个被广泛使用的Java游戏开发框架。2025年8月，他把Pi发布出来，动机很工程师式：受够了现有Coding Agent越来越臃肿、越来越黑盒，自己写一个。

多数Agent产品的默认路径是，用户要什么就加什么：要联网，加Web工具；要协作，加Subagent；要流程，加Plan Mode；要企业化，加权限系统；要长期任务，加Memory；要接外部系统，加MCP。每一个功能单独看都合理，但堆到最后，Agent越来越像一个小型操作系统。

Pi反过来做：

1
2
3

Pi的结构可以理解成一个很小的Core加一圈外围能力。

Core里只放read、write、edit、bash这类最基础动作；Skills、Extensions、Packages这些能力放在外围，需要时再组合进来。

核心压到很小，只保留最基本的本地开发动作——读文件，写文件，编辑文件，跑命令。其他能力放到外围，用Skills、Extensions、Packages按需加载。Pi官方文档明确说明，之所以跳过Sub-Agent、Plan Mode这类功能，是因为用户完全可以通过扩展或Package自己实现，没必要焊死在核心里。

这里有一个值得记住的判断：Pi的“少”，不是做不出来，而是它认为这些能力不应该被全部固化进Agent核心。

这一点很关键。因为一旦能力进了核心，它就会变成每次对话都要考虑的东西——文档、工具描述、权限规则、提示词、历史状态，都可能占用上下文，都可能分散模型的注意力。用户感受到的是功能变多了，模型感受到的可能是工作台上堆满了东西。

真正值得看的不是插件数量，是Skills怎么进入上下文

这一部分是全文技术含量最高的地方，也是最值得你多花两分钟看的部分。

设想一个功能齐全的Agent，同时挂着30个工具、20个Skills、10个MCP连接、项目级规则、用户级规则、长期Memory、完整对话历史，还有当前正在处理的代码和文档。问题不在于这些功能不好，而在于一个更根本的问题：模型到底什么时候需要看见这些东西？

如果全部提前一次性塞进Context Window，很容易演变成系统提示词、AGENTS.md、工具schema、MCP schema、Skills说明、Memory、聊天历史、代码全都挤在一起，而真正与当前任务相关的那一小块内容，占比反而越来越低。这其实是你在上下文窗口系列文章里反复讨论过的“标称长度”和“有效长度”之间的老问题，只是换了个场景重新出现。上下文窗口不是仓库，更像工作台——工作台越大，当然能放更多东西，但把所有扳手、螺丝、旧图纸都堆满桌面，不等于干活更快。

Pi给出的方案在官方文档里有非常具体的描述。Skills被定义为“self-contained capability packages”——独立的能力包，包含工作流程说明、脚本、参考资料，Agent按需加载。启动时，Pi只会把每个Skill的名称和一句简短描述放进系统提示词；只有当前任务真的匹配到某个Skill时，Agent才会用read工具去读取完整的SKILL.md。官方文档把这个机制直接命名为progressive disclosure（渐进披露）：只有描述常驻上下文，完整指令按需加载。

这不是一个小优化，它背后的问题是，Agent到底应该在什么时候把能力放进上下文。Claude Code也有Skills和Subagents，也在解决类似问题，区别在于Claude Code把很多能力做成了更完整的默认产品体验，而Pi把这件事拆得更裸，让你直接看见harness本身是怎么组织的。

由此可以得出一个判断：Agent的下一场竞争，可能不是谁能接入更多工具，而是谁能更晚、更准地把正确的工具放进Context。

Pi的压缩机制，暴露了一个更底层的问题

长任务跑久了，上下文一定会满，这是所有Agent都绕不开的问题。

Pi官方文档给出的默认参数是可查证的一手数据：系统在当前Context Token数 > 模型上下文窗口 - reserveTokens时触发自动压缩；reserveTokens默认预留16384个token，用来给模型的输出留出空间；keepRecentTokens默认保留20000个token的近期原文历史，作为工作记忆。两个参数都可以在配置文件里手动调整。当对话逼近上限，Pi会把更早的内容摘要压缩，而不是一直往里堆。

这组数字不神秘，但它们把问题讲清楚了：Agent不是简单地把对话越存越长，它必须决定哪些内容保留原文，哪些内容压成摘要，哪些内容该从上下文里彻底消失。压缩太早，细节会丢；压缩太晚，模型没有足够输出空间；保留近期太少，刚发生的工具结果可能断线索；保留太多，又压不出空间。

一个常见的直觉误区是：既然模型现在能支持百万级Context，那把所有东西都塞进去不就行了吗？Pi自己的压缩机制其实就是在否定这个直觉——Context的容量和Context的有效利用率，从来不是一回事。

顺着这条线可以看到一个大致的演进轨迹：第一阶段是拼命扩大Context Window，大家比谁的窗口更长；第二阶段进入Context Engineering，开始有意识地组织进入上下文的内容，怎么切、怎么排、怎么引用、怎么压缩；第三阶段是Dynamic Context——不是把准备好的东西一次性塞进去，而是让Agent根据任务动态加载模型、工具、Skills、文件、历史和验证器。Pi不是唯一在做这件事的项目，但它把这个方向表达得很直接。

所以长上下文时代的下一个问题，不是怎么装得更多，而是怎么少装一点。

Pi为什么不绑定某一个模型

Pi还有一个特征：它不把自己绑死在某一个模型上。

pi-ai模块是统一的多Provider接口，官方文档把支持的接入方式分成三类：直连API（Anthropic、OpenAI、Google、xAI、Groq、Cerebras、OpenRouter、Mistral等）、订阅类接入（Claude Pro/Max、ChatGPT Plus/Pro、GitHub Copilot等）、以及企业级接入（Azure OpenAI、Amazon Bedrock、Google Vertex AI等），此外也支持通过Ollama或llama.cpp接入本地模型。

这件事表面看是多模型适配，深一层看，是把模型变成了可更换的零件。过去的路径是“Claude Code绑定Claude”；Pi的思路是“任务先交给harness，再由harness决定用哪个模型执行”——简单搜索用便宜模型，代码修改用擅长编程的模型，复杂规划用推理模型，未来甚至可能按任务类型自动路由。

由此可以得出一个更长期的判断：如果模型本身还会持续快速迭代，那么真正长期留存的资产，可能不是某一个具体模型，而是你围绕任务搭建起来的harness、Skills和工作流。

这一点还有一个可以直接验证的旁证：Pi的Skills并不锁死在Pi里。官方文档里，你可以在配置文件中把Claude Code或OpenAI Codex的Skills目录直接接进来（比如在settings里加上~/.claude/skills、~/.codex/skills这样的路径），Pi会照常发现并加载这些Skills；反过来，Mario Zechner维护的pi-skills项目也明确说明这批Skills兼容Claude Code、Codex CLI、Amp和Droid。也就是说，你在一个Agent里攒下的能力，理论上可以直接搬到另一个Agent里继续用——用户真正积累的是“能力”本身，而不是被锁定在某一个平台的配置。

为什么是现在火，而不是一年前

Pi不是今年才出现的项目，2025年8月就发布了。它真正开始被大规模讨论，是最近几个月的事，这背后有几层原因叠加。

原因一：大家开始意识到harness本身的重要性。 同一个模型，换一个harness跑，表现可能完全不同。模型决定能力上限，harness开始越来越明显地决定这部分能力究竟能发挥出多少。

原因二：Agent功能膨胀开始产生副作用。 随着MCP、Skills、Memory、Hooks、Subagents、Agent Teams、Rules这些东西越叠越多，开发者开始面对一个新问题——到底哪些东西应该一直存在于Context里？Pi给出了一个偏极端的答案：尽量不要。

原因三：一条可以交叉验证的真实时间线，可能是加速器中最被低估的一环。

• 2025年8月，Zechner独立发布Pi，仓库挂在他自己名下；
• 2026年1月31日，Flask和Sentry的作者Armin Ronacher（网名mitsuhiko）在个人博客发表《Pi: The Minimal Agent Within OpenClaw》，公开背书Pi是“OpenClaw内部的极简agent”，也是他“几乎唯一在用”的Coding Agent；
• 2026年4月8日，Ronacher联合创立的公司Earendil宣布收购Pi，Zechner以核心成员身份加入。Earendil是一家风投背景的公益公司，早期投资方包括Accel、Balderton Capital，以及n8n、OpenClaw、Revolut、Sentry、Slack这几家公司的创始人；
• 2026年5月7日，官方发文《Pi Has a New Home at Earendil》，宣布代码仓库正式从Zechner个人名下迁移到earendil-works/pi，npm包作用域也从@mariozechner迁移到@earendil-works，版本号0.74.0是新作用域下的第一个正式发布版本，旧包并未下架，只是标记为废弃。

这条时间线说明，这次“火”不只是产品力本身的自然增长，也叠加了一条“独立项目→行业大佬公开背书→被组织化接手、拿到资本背书”的加速链条。

更值得关注的是生态信号。Pi的官方Package目录里，已经能看到不少第三方维护的能力包：比如pi-sub-agent，是一个专门给Pi补上Subagent能力的扩展，支持单任务、并行、链式三种委派模式；@baryonlabs/pi-agent-harness则更进一步，把Pi的极简核心包装成一套“团队架构工厂”，可以用一句话描述生成一整套多智能体协作方案，官方原本是Claude Code的插件，现在被移植成了Pi专用版本。也就是说，Pi官方没有把Subagent做进核心，但社区在外围把它补了回来——这正好回到Pi的哲学：核心保持小，能力在外面长。

Claude Code和Pi不是同一类答案

如果硬要对比，最容易写成一个假冲突：Claude Code封闭，Pi开放；Claude Code复杂，Pi先进。这个说法并不准确。

Claude Code本身也有开放生态——Skills、MCP、Hooks、Subagents、Plugins、Agent SDK它都有，也有相对完整的权限体系，不是一个不能扩展的黑盒。对大多数开发者来说，它现在就是更成熟、更省心的选择。

真正的区别在于，两者对同一个问题给出的默认答案不同：

Claude Code的逻辑是：由Anthropic先定义好一个优秀Agent应该长什么样，再把扩展空间留给用户。Pi的逻辑是：先给你一个足够小的Core，剩下的由你自己决定它最终变成什么样。

一句话总结：Claude Code是一个Agent；Pi更像是制造Agent的一套积木。

泼一盆冷水：极简不等于更安全

如果文章写到这里就收尾，很容易变成一篇Pi的软文，得把另一面也摆出来。

最重要的反例是权限。Pi官方安全文档写得很直接：它没有内置沙箱，内置的四个工具会用启动Pi进程本身的账户权限去读文件、写文件、编辑文件、执行Shell命令；扩展本质上是TypeScript模块，跑的时候用的也是同样的权限。官方给出的建议是，如果需要真正的隔离边界，要靠操作系统、虚拟化或容器去补。

这不是纸面上的风险。最近科技社区Linux.do上就出现过一份使用者报告：有开发者在使用Pi时遭遇终端失控输出，模型陷入无休止循环，短时间内耗尽系统资源，尝试Ctrl+C中断无效后，设备出现黑屏、异常蜂鸣，随后多次重启都出现死机，一段时间内无法正常使用。需要说明的是，这是一份用户自述的个案，并非官方确认的普遍性问题，但它足以说明极简架构在默认状态下，确实存在真实的稳定性和安全边界问题——一个能跑Shell、能改文件、能装包的Agent，如果没有权限边界，出错时影响范围可能不小。

相比之下，Claude Code在这方面明显更产品化：默认有权限提示，有分级的Permission Mode，Plan Mode下可以先只读探索，文件修改和Shell执行也有不同的确认策略。企业里真正要把Agent推给一群开发者用，这些默认边界很值钱。

所以不要把Pi讲成一个更高级的Claude Code替代品。对很多人来说，Claude Code反而是更正确的选择，因为它已经替用户提前解决了安全、权限、交互、规划这一整套问题。Pi把决定权交回给用户的同时，也把责任交回给了用户——这两者，来自同一个地方。

Agent可能会走向Composable Harness

不急着回答“Pi是不是最终形态”这个问题。更准确的说法是：Pi本身未必是最终会留下来的那个产品，但它所代表的架构思路，很可能会留下来。

顺着这个思路，可以粗略画出一条Agent的演进轨迹：

Agent 1.0：Prompt。 用户提问，模型给答案，核心问题是怎么问得更好。

Agent 2.0：Tools。 模型开始能调用搜索、文件、Shell、API，核心问题变成怎么让AI真的能行动。

Agent 3.0：Workflow。 Plan、Tools、Memory、Subagents、MCP拼在一起，核心问题是怎么让复杂任务持续跑完——这基本是今天大多数主流Agent产品所在的阶段。

Agent 4.0：Composable Harness。 任务驱动一个极小的核心，核心再动态调用模型、Skill、工具，配合Context管理和结果校验完成任务。核心问题变成：当前任务到底需要什么能力？什么时候该加载，什么时候该丢弃？该用哪个模型执行？

这个问题会越来越难回答，因为模型会变，工具会变，MCP会变，Skills会变，任务类型也会变。今天写死在核心里的能力，半年后可能已经不是最佳实践——一个更小、更可组合的harness，反而更容易跟上变化。

Pi真正值得关注的，可能不是它现在具备哪些功能，而是它在持续追问一个越来越关键的问题：一个Agent，到底应该内置多少东西？

写在最后

不需要得出“Pi将取代Claude Code”这种结论，至少今天看，这大概率是错的。

更准确的收束是：Claude Code给出的答案是，把最好的能力尽可能集成起来，做成一个越来越完整的Agent；Pi给出的答案是，把Agent核心尽可能缩小，让能力在真正需要的时候被临时组装出来。

今天看，前一种路线显然更成熟、更容易上手，这也是为什么大多数开发者的默认选择仍然是Claude Code。但如果把时间线拉长——模型还在不断变化，工具还在不断变化，Skills还在不断增加，任务只会越来越复杂——那么一个能长期存在的Agent，最重要的能力可能不是“它自己会多少东西”，而是它能不能在正确的时候，找到正确的能力、正确的模型、正确的上下文，把任务完成。

未来最强的Agent，也许不是那个什么都会的Agent，而是那个知道自己此刻只需要会什么的Agent。

如果这篇文章帮你理清了Pi和Claude Code之间的关系，欢迎点个在看；如果你也在关注Agent架构这条线，欢迎星标本号，以后类似内容不会错过；如果你已经在用Pi或者正在观望，欢迎在评论区聊聊你更喜欢完整产品，还是更喜欢自己掌控harness。

资料边界说明

本文数据分为几个层级：

一手官方信源：Pi官方仓库Compaction文档（reserveTokens默认16384、keepRecentTokens默认20000，pi.dev/docs/latest/compaction）；Pi官方仓库Skills文档（progressive disclosure机制、跨Agent目录加载配置，pi.dev/docs/latest/skills）；Pi官方新闻《Pi Has a New Home at Earendil》（pi.dev/news/2026/5/7/pi-has-a-new-home，仓库与npm作用域迁移的一手记录）；Armin Ronacher个人博客文章《Pi: The Minimal Agent Within OpenClaw》（lucumr.pocoo.org/2026/1/31/pi，1月31日背书文的一手原文）；Pi官方Package页面pi-sub-agent与@baryonlabs/pi-agent-harness，用于确认社区生态案例真实存在。

二手技术评测交叉确认：Pi的多Provider分层接入方式（直连/订阅/企业三类）与“无内置沙箱、继承启动进程权限”的安全表述，来自多篇独立技术评测对官方文档的转述，未直接引用官方安全文档原文链接，但内容彼此一致。

用户报告个案，非官方确认：Linux.do社区关于Pi终端失控、系统崩溃的故障报告，属于个别用户自述，不代表普遍性问题，也未见Pi官方或Earendil官方回应。

趋势性描述，不用单点数字：GitHub star增长轨迹本文只写“从几百量级到数万量级，不到一年”，不锁定某一天的精确数字，因为不同公开索引的抓取口径本身存在差异。

时效性提醒：Pi生态目前迭代速度很快，npm包命名空间已从@mariozechner迁移至@earendil-works，安装命令、当前star数、Package生态数量等信息时效性较强。

1
2

# 安装前请以官方文档 pi.dev 为准确认最新包名
npm install -g @earendil-works/pi-coding-agent