本文来自微信公众号： Founder Park ，作者：Founder Park，原文标题：《OpenClaw 背后核心框架 Pi：好的 Coding Agent 应该让用户来决定需要什么》
OpenClaw，是当下最火的开源个人AI助手。很多人不知道的是，OpenClaw背后，核心是一个极简框架Pi-coding-agent。
在OpenClaw的系统架构中，Pi agent是Gateway控制层的核心子系统，控制了所有agent的推理和工具调用。
和Claude Code、Cursor、Codex不同的是，Pi最大的特点是「做减法」：系统提示词和工具定义加起来不到1000 tokens，核心只有read、write、edit、bash四个工具，没有内置plan mode，没有to-do系统，没有MCP支持，没有权限弹窗，甚至没有绑定任何特定模型。
但就是这样一个「什么都没有」的框架，在Terminal Bench 2.0上与Codex、Cursor、Windsurf一同排进了前五。在GitHub上，Pi积累了超过24000 stars和148位贡献者。
Pi的作者是奥地利的开发者Mario Zechner，有着二十多年的开源经验。Mario此前曾开发了Java跨平台游戏开发框架libGDX，在GitHub上拥有2万标星。
Mario认为，好的coding agent不应该预设你需要什么，而是应该让你自己决定需要什么。
在最近的一场AMA的直播活动上，Mario和Pi框架的三位深度用户，Sentry工程高级总监Daniel、Pi核心贡献者Armen、以及Modem创始人Ben，聊了聊他对于Pi的极简设计思路，以及对当下Coding Agent的一些思考。
以下为活动中的部分精华内容。
⬆️关注Founder Park，最及时最干货的创业分享
超22000人的「AI产品市集」社群！不错过每一款有价值的AI应用。
邀请从业者、开发人员和创业者，飞书扫码加群：
进群后，你有机会得到：
最新、最值得关注的AI新品资讯；
不定期赠送热门新品的邀请码、会员码；
最精准的AI产品曝光渠道
01
在经过大量的RL后，
大模型天然就知道coding harness是什么
主持人：市面上已经有像Claude Code这样成熟的产品了，最初是怎么想到要自己写一个Pi的？
Mario：说实话，因为我受够了Claude Code（笑）。我很喜欢Claude Code，它是定义了Coding的产品，团队也很棒。但输出的东西老是坏，我说的不是bug，而是我自己的工作流被破坏了，因为harness变了，模型的行为就跟着变了。
作为工程师，我需要更可靠的工具。当然，在2026年说这话有点讽刺，因为LLM本身就不可靠，但至少我个人能让它确定性的部分，我希望它是确定性的，包括工具、系统提示词、以及背后被注入的所有东西。
如果你去看Claude Code或者OpenAI的Codex，它们会在你的上下文里偷偷塞进很多东西，而且不会在UI上展示给你。这些东西会以最微妙的方式破坏你的工作流。它们的发布节奏是每天一次甚至一天多次，你可以9点开始工作、工作流跑得好好的，10点就坏了，下午3点又变成完全不同的行为，模型没变，变的是harness。在这样的情况下，我没法工作。
主持人：Pi的极简设计，最初是受到了什么启发？
Mario：来自一个观察。在写Pi之前，我去看了Terminal Bench的排行榜，上面有一个叫Terminus的harness，非常神奇，它只给LLM一个工具，跟tmux session交互。LLM必须发送单独的按键，读取tmux返回的ANSI序列来完成任务。就这么一个工具，它几乎永远排在前三，而且经常是第一名。
这给了我一个划痕关键的直觉：模型现在经过了大量的强化学习训练，它们天然就知道coding harness是什么，不需要在上面堆加太多东西。Pi就是这个理念的实现：一个极简但可扩展的harness。
Mario在开发博客中写道：
过去几个月里，Claude Code变成了一艘宇宙飞船，其中80%的功能我完全用不上。系统提示词和工具定义在每次发布时都会变，这破坏了我的工作流、改变了模型行为。我恨透了这一点。另外，它还会闪屏。
02
系统提示词不到1000 tokens，
Pi坚持「极简」设计
Pi最大的特点是，整套系统提示词加工具定义加起来不到1000 tokens。作为对比，Claude Code的系统提示词超过10000 tokens，OpenCode的模型专用提示词也是类似这种的量级。
这么短的提示词，Pi是怎么做的？
Mario在一篇博客文章中，分享了他的设计理念。
Mario提到，应该把LLM当作「用自然语言编程的通用计算机」，prompt不是对话，而是代码，有输入、状态、输出和控制流。状态应该序列化到磁盘上的JSON和Markdown文件里，这样你可以从任意一个断点重启、用全新的上下文继续，从根本上绕过上下文衰减问题。Mario用这套方法把一个原本需要2-3周的游戏引擎跨语言移植任务压缩到了2-3天。
同样，Mario在Pi的设计中，也明确了几个主动选择「不做」的功能：
不支持MCP。主流MCP server会把大量工具定义一次性灌入上下文。Playwright MCP有21个工具、消耗13700 tokens；Chrome DevTools MCP有26个工具、消耗18000 tokens，还没开始干活，上下文窗口就少了7%-9%，而且这些工具在当次session中大多数你根本用不到。
Mario给出的替代方案是，写CLI工具配README文件。agent需要某个工具时才读对应的README，按需付出token成本，然后用bash调用。他用这种方式搭建了一套浏览器自动化工具集，总共只消耗225 tokens，是Playwright MCP的1/60。
不内置plan mode。直接告诉agent "我们先一起想清楚这个问题，不要改文件也不要执行命令"就够了。如果需要跨session的规划，写到PLAN.md里，agent可以读、可以改、可以引用，而且这个文件可以随代码一起版本化。
Mario特别强调了可观测性：在Claude Code的plan mode里，它会在背后生成子agent，你完全看不到这个子agent做了什么，不知道它读了哪些文件、漏掉了哪些。在Pi里，所有的探索过程都在你面前，你可以看到agent读了什么、遗漏了什么。
不内置to-do系统。Mario的经验是，to-do列表通常让模型更困惑而不是更高效，增加了模型需要追踪和更新的状态，会引入更多出错的机会。
不做后台bash。后台进程管理会引入大量复杂性，进程追踪、输出缓冲、退出清理、向运行中的进程发送输入。Claude Code有后台bash功能，但它的可观测性很差，而且在早期版本中，上下文压缩后agent会忘掉所有后台进程并且没有工具去查询它们。
不内置SubAgent。在这一点上，Mario的态度最坚决。Claude Code执行复杂任务时经常在背后生成SubAgent，完全看不到子agent的对话过程，属于「黑箱里的黑箱」。
如果需要Pi生成自己，直接用bash启动一个新的Pi实例就行了，甚至可以放在tmux里跑，获得完全的可观测性。
Mario在博客中写道：
在session中途用SubAgent做上下文收集，说明你没有提前规划好。如果你需要收集上下文，在一个独立的session里先做完，产出一个artifact，然后在新session里用这个artifact给agent提供干净的上下文。
03
在Pi框架下，
大家的使用工作流都不一样
主持人：Daniel，你作为大厂的工程总监，个人使用AI编程工具的演进路径是什么样的？
Daniel：我经历了很长一段时间的变化。2024年夏天，ChatGPT已经好到可以一次就能帮你搞定一个脚本了。以前写脚本要花几小时查文档和API，现在几分钟就完事，但体验很原始，打开网页、复制粘贴、本地创建文件，太笨重了。
真正的magic moment是2025年6月，Cursor实现了agentic loop。我第一次对agent编程上瘾了，一个周末、两个晚上，从零搭了一个包含前后端和用户登录的完整Web应用，放在以前至少要一到两周。
然后就是2025年底，Opus 4.5出来了，我彻底迷上了Claude Code。之前agent大概50%的时候能用，Opus 4.5让它变成了80%能用。
主持人：最后为什么你还是弃用Claude Code了？
Daniel：大概2026年1月，我发现了问题。Claude Code像一辆超级舒适的车，你坐进去，它就能把你送到目的地。而且它非常乐观，会告诉你"我们能搞定的"。但有时候它会骗你说，「已经production ready了」，结果你一打开就崩溃了。
每次开一个新的session时，我都要重复同样的指令，但同样的错误又来了，hooks机制刚推出就有bug。Claude Code本身不稳定，有时候直接崩溃把你踢出去，所以要从断点恢复几乎是不可能的。
我被弹回了两次，前两次装完Pi，感觉回到了「石器时代」，什么都没有。但第三次我换了策略：不用Pi去做一个功能，而是用Pi来构建我自己的agent。这是真正的Aha moment。
主持人：面对Pi这么极简的框架，你们三位的使用方式差异很大。分别讲讲各自日常的工作流。
Daniel：我的工作流是这样的：首先用我调整过的brainstorming skill做规划，它要求模型给出三种方案：一个激进的、一个务实的、一个豪华的，然后我跟模型讨论，最终确定方案。这个过程产出一个markdown计划文件和一系列to-dos。
然后进入实施阶段。如果是已有代码库，先启动一个scoutSubAgent去探索需要改动的文件，把结果传给worker agents。Worker agents只用Sonnet 4.6，因为任务已经足够明确，不需要Opus。更快也更便宜。实施完成后，用Codex reviewerSubAgent做代码审查。
最有意思的部分是迭代修复。大功能实施完之后，我通常还剩40%到60%的上下文窗口，而且是完美的热上下文。我不需要重新解释我们在做什么、用了什么技术、为什么做了某些取舍。直接使用应用、找到问题、让agent修复、然后rewind回实施完成的节点、修下一个问题，如此循环直到打磨完成。
Armen：我更关注怎么让agent更高效。比如我完全替换了Pi的内置edit tool，换成支持patch-based多文件编辑的版本，灵感来自Codex的apply patch。
另一个我重度使用的是answer扩展。Claude Code的plan mode会给上下文注入一个"提问"工具，即使你不在plan mode里它也一直存在，有时候会在不需要的时候蹦出来。我写了一个answer扩展替代它，提取模型提出的所有问题，重新渲染成UI，逐个回答后提交，完全不消耗上下文。
我还让agent在验证改动时自动截图。Pi是少数能把截图读进LLM并且漂亮显示的编程agent。即使几天后加载旧session，我仍然能看到agent当时截的每一张图。
Mario：我个人只有两个扩展，而且是特定项目的。我只要我的极简体验：打个招呼、开始干活、别出错。我给你们造了一台meta slop machine（元slop机器），这样你们可以尽情发挥。而我自己住在我非常斯巴达式的世界里。
04
让多个SubAgent并行开发的模式，
行不通
Mario此前在博客中，提到：
让多个子agent并行开发不同功能，在我看来是一种反模式，不会有好结果，除非你不在乎代码库变成一堆垃圾。
在session中途用子agent做上下文收集，说明你没有提前规划好。如果你需要收集上下文，在一个独立的session里先做完，产出一个artifact，然后在新session里用这个artifact给agent提供干净的上下文。这个artifact对下一个功能可能也有用，而且你能获得完全的可观测性和可操控性，这在上下文收集阶段至关重要。
去看看Pi的issue tracker和pull requests吧。很多都被关闭或者要求修改了，因为那些agent无法完全理解项目需要什么。这不是贡献者的错，即使是不完整的PR也能帮我更快地推进。但这说明我们对agent的信任还是太多了。
主持人：在SubAgent上，大家的分歧似乎很大。
Mario：我从来没发现SubAgent、编排、swarm这些东西对我有效。但这可能也因为我仍然会阅读agent产出的大部分代码。我不想要10个agent同时干活，然后一天结束时review 2万行代码，这对人类大脑来说不可扩展，而且那2万行代码大概率质量不行。
我不追求每天创建更多功能，我追求的是每天能做更多决策，关于产品需要什么、不需要什么。
我的替代方案是用/tree命令。让agent自由探索代码库，然后做一个摘要，回到起点只带上摘要继续工作。这是我的穷人版SubAgent。
Armen：我的看法是，你必须先把串行流程跑通了，才能考虑并行化。我到现在还没有找到一种方法可以自动化「探索」这一步。如果我自己还得在loop里，并行化对我帮助不大。
Mario：有一个不错的反例。Shopify的Tobi做了一个Pi扩展，给你一个本地指标，agent们在解空间里并行探索不同的优化方案。对这种「把东西往墙上扔、看哪个粘住了」的探索型任务，SubAgent确实很强大。但对于真正的功能构建，我还是要在loop里，我还是要做最后拍板的人。
Armen：我昨晚刚用auto-research跑了一下我自己的模板引擎。即便是这种场景，也只能串行跑，并行的话会同时引入太多修改，你得退回大部分，结果就是一堆merge conflicts。不过效果确实不错，引擎快了大约20%。
05
大部分Coding Agent的权限系统，
都是「安全剧场」
主持人：在安全问题上，Pi的设置是，完全没有权限系统。为什么这么设计？
Mario：这被Simon Willison称为「trifecta」：如果你给agent执行命令的能力、读取网络内容的能力、以及读取本地文件的能力，你就完蛋了。目前，其实没有好的解决方案。
至于那些权限弹窗？可爱，但不解决问题。它导致的是permission fatigue，用户被agent不断打断，最后就会一路yes yes yes，然后干脆"跳过所有权限"。
Mario在此前的博客中写道：
看看其他编程agent的安全措施，大部分都是安全剧场（security theater）。只要你的agent能写代码和执行代码，就已经game over了。唯一能防止数据泄露的方法是切断执行环境的所有网络连接，但这会让agent基本没法用。域名白名单也能通过其他手段绕过。
Simon Willison写了大量关于这个问题的文章。他提出的"dual LLM"模式试图解决confused deputy attack和数据窃取，但他自己也承认"这个方案相当糟糕"，而且引入了巨大的实现复杂度。核心问题不变：如果一个LLM能读取私有数据又能发起网络请求，你就是在玩打地鼠游戏。
既然我们解决不了这个"三体难题"（读数据+执行代码+网络访问），Pi就直接投降了。反正所有人最终都会切换到YOLO模式来提高生产效率，那为什么不把它作为默认的、唯一的选项？
Armen：权限系统还有另一个问题。即使你拒绝了大部分权限，只给agent跑一个脚本的权限，它会通过这一个脚本做所有事情。你可以自己试：给Claude Code或Codex，只允许它运行checkout里的一个脚本文件，它会开始编辑这个文件来实现各种改动。非常聪明，但也说明了权限系统形同虚设。
Mario：我个人的做法是：在宿主机上有需要保护的东西，就把Pi放进Docker容器，只挂载它需要的数据。其他时候就全开。
06
Coding Agent不需要额外的长期记忆
主持人：你们觉得Coding Agent需要额外维护一套记忆系统吗？你们怎么看agent的长期记忆？
Mario：我认为目前不需要，至少对编程任务来说不需要。代码库就是source of truth，我不需要在代码库之上维护一层额外的信息。
我认为Claude Code最伟大的发明之一是搜索，不是去索引、向量化、BM25检索你的代码库，而是让agent每次从零开始，探索代码库的当前状态，然后再动手。这以前做得不好，现在做得非常好，尤其是Codex，它在收集上下文方面真的很强。
传统的做法是什么？写文档，然后文档一周就过时了，没人读。代码才是真相。让agent探索代码库的当前状态，是编程任务目前最好的做法。对于其他场景，比如OpenClaw那种需要记住你家庭成员信息的个人助手，当然可以用记忆系统。但写代码不需要。
Daniel：我试过一种方法：session快超出上下文窗口了就做一个摘要，在新session里从摘要继续。但我发现没什么用，只是往上下文里塞了更多东西。最后我就用本地的agents.md，想让agent下次记住什么，写进去就行，够用了。
Armen：我们做了一些实验，把最近的Git变更推进上下文，帮agent从上次断点继续。结果好坏参半。目前没被说服。
07
你的AI「变笨了」，
并不是错觉
主持人：很多人提到，经常觉得自己的工具「变笨了」，AI工具在悄悄「gaslight」开发者，你们怎么看？
Mario：如果你经常觉得你的工具「变笨了」，这并不是错觉。
2025年8月，我开发了一个叫cchistory的工具，专门用来追踪Claude Code每个版本的系统提示词和工具定义变更。
在cchistory的记录下，发现了大量的「静默调整」：
早期版本会把完整的项目目录树注入系统提示词，后来被删掉了，因为它严重污染上下文；
一条要求Claude清理测试/调试文件的指令被移除，因为Claude过于激进地删除了合法文件；
Bash命令解释的要求也被去掉了，可能是为了降低服务器负载；
安全相关的措辞从笼统的"拒绝创建恶意代码"演变为更细致的分类；
Grep工具经历了重大重构，强制要求使用内置Grep而非bash grep；
虽然每一条变更都合情合理，但问题是：用户对此完全不知情，而每一条都可能改变模型在你session中的行为。
Armen：我们现在做的这个vibe-based engineering非常疯狂。以前我们行业有一个很重要的原则：不随便改API、保持向后兼容。现在因为所有接口都是自然语言，MCP server没有稳定接口，系统提示词没有稳定接口，各种agent harness上面还有随机的A/B测试。你日常使用的工具，每一层都在不断被gaslight。
我甚至觉得，虽然可能完全是我的错觉，当美国那边醒了之后，我的agent表现就会变差。但我也不知道是不是真的，因为我对正在发生的事情几乎没有任何能见度。
Mario：这也是我造Pi的动机之一。我不想要一个别人可以随时在背后改变的工具。我想要确定性的工具、确定性的系统提示词、确定性的行为。如果行为不对，我自己来改，至少我知道改了什么。
Claude Code或Codex在后台推了多少东西到你的上下文里，你是看不到的。而所有这些，都在以最微妙的方式影响着你的工作。
主持人：现在满世界都是能自动写代码、提PR的AI，这给你的开源社区维护带来了什么挑战？
Mario：大量完全由AI生成、没有人工监督的issue和PR涌入我的仓库。一个标题看起来合理的PR，点进去一看，天哪，PR描述是一本书的长度，改了30到100个文件。有时候是好的，有时候是垃圾，但你必须读完所有这些东西才能判断。
有人提到，为什么不让AI去审AI？但AI在判断一个issue或PR是否跟项目相关、质量是否达标、是否符合项目哲学方面非常糟糕。你可以在agents.md里编码这些标准，但就是不行。这些判断仍然需要经过人类的大脑。
所以我搭了一套系统：不是所有人都能直接提PR。你必须先用人类的声音开一个issue，我读了之后回复确认，你的账号名才会被写进白名单。之后你提PR，GitHub workflow会检查你是否在名单上。不在的话，PR自动关闭，附一条消息：「请先用人类的声音开一个issue。」
这个方案很有效，因为AI不会回去读那条关闭PR时机器人发的评论。但对issue不适用，issue的提交门槛更低，没法要求每个人都先经过手动审批。PR这边基本解决了，issue还是个难题。