夜雨聆风Pi 框架设计哲学与三个核心问题的讨论
第一部分：原文核心内容总结
1. 什么是 Pi 框架
Pi 是当下最火的开源个人 AI 助手 OpenClaw 背后的核心框架。它是一个极简的 Coding Agent 框架，由奥地利开发者 Mario Zechner 创建。
核心特点：
• 系统提示词 + 工具定义 不到 1000 tokens（Claude Code 超过 10000 tokens） • 核心工具只有 4 个： read、write、edit、bash• 没有内置 plan mode、没有 to-do 系统、没有 MCP 支持、没有权限弹窗 • 不绑定任何特定模型
2. Mario 的设计哲学
核心理念："做减法"
"好的 coding agent 不应该预设你需要什么，而是应该让你自己决定需要什么。"
关键洞察：
• 经过大量 RL（强化学习）训练的大模型，天然就知道 coding harness 是什么 • 不需要在上面堆加太多东西 • 追求确定性：确定性的工具、确定性的系统提示词、确定性的行为
明确"不做"的功能
| MCP | ||
| Plan Mode | ||
| To-Do 系统 | ||
| 后台 Bash | ||
| 内置 SubAgent |
3. 核心观点：确定性 > 功能丰富
关于"AI 变笨了"
Mario 开发了 cchistory 工具追踪 Claude Code 的系统提示词变更，发现大量**"静默调整"**：
• 项目目录树注入被删除（污染上下文） • 清理测试文件的指令被移除（过于激进） • Bash 命令解释要求被去掉（降低服务器负载） • Grep 工具重大重构
"虽然每条变更都合情合理，但用户对此完全不知情，而每一条都可能改变模型在你 session 中的行为。"
关于安全性
"看看其他编程 agent 的安全措施，大部分都是安全剧场（security theater）。只要你的 agent 能写代码和执行代码，就已经 game over 了。"
Pi 的策略：默认全开（YOLO 模式），把决定权交给用户。
4. 用户反馈
三位深度用户（Sentry 工程总监 Daniel、Pi 核心贡献者 Armen、Modem 创始人 Ben）分享了不同的使用工作流：
• Daniel：用自定义 skill 做规划（激进/务实/豪华三方案）→ scoutSubAgent 探索 → worker agents 实施 → Codex reviewerSubAgent 审查 • Armen：替换内置 edit tool 为 patch-based 多文件编辑；用 answer 扩展替代 plan mode 的提问工具；让 agent 验证时自动截图 • Mario：只有两个特定项目的扩展，追求极简体验
第二部分：讨论的三个问题
问题一：没有 plan mode 怎么保证比 Claude Code 的工作流稳定？
核心区别：显式 > 隐式
Pi 的替代方案
1. 显式规划文件（PLAN.md）
• 直接告诉 agent："我们先一起想清楚这个问题，不要改文件也不要执行命令" • 把计划写到 PLAN.md，agent 可以读、改、引用 • 文件随代码版本化，下次直接加载
2. 可观测性 vs 黑箱
• Claude Code：背后生成子 agent，用户完全看不到对话过程 • Pi：所有探索过程都在用户面前，可以看到 agent 读了什么、遗漏了什么 • 用 /tree命令让 agent 探索代码库，做摘要后继续
3. 状态持久化（断点续传）
• 状态序列化到磁盘上的 JSON 和 Markdown 文件 • 可以从任意断点重启，用全新上下文继续 • 从根本上绕过上下文衰减问题
一句话总结
Claude Code 的 plan mode 是**"我帮你规划，你放心"（黑箱，易变）
Pi 的替代方案是"我们一起规划，你掌控"**（显式，稳定）
问题二：OpenClaw 有 SubAgent 机制，与原文反对的 SubAgent 用法如何理解？
原文反对的是什么
Mario 反对的是 "在 session 中途用 SubAgent 做上下文收集"：
❌ 错误做法：
Session A 跑了一半
→ 突然 spawn 一个 SubAgent 去探索代码库
→ 把探索结果塞回 Session A
→ 用户看不到 SubAgent 做了什么问题：
• 破坏了 Session A 的连续性 • SubAgent 变成黑箱，不可观测 • 说明"没有提前规划好"
原文推荐的做法
✅ 正确做法：
独立的 Session B：专门做上下文收集
→ 产出 artifact（文件/摘要）
→ 全新的 Session C：加载 artifact，干净上下文开始优势：
• 每个 session 目标单一、清晰 • 完全可观测、可操控 • artifact 可复用
OpenClaw 的 SubAgent 是哪种
OpenClaw 的 sessions_spawn 实际上是 Mario 推荐的模式，不是他反对的模式：
一句话总结
• Mario 反对：session 中途偷偷 spawn SubAgent 收集上下文，破坏连续性 • OpenClaw 做法：显式启动独立 SubAgent，产出 artifact，主 session 决定加载 — 这正是 Mario 推荐的模式
问题三：只有 4 个工具是不是太少了？连浏览器操作都没有吗？
为什么只有 4 个工具
核心理念：让 AI 自己决定需要什么
Mario 的观察：
"模型经过大量 RL（强化学习）训练后，天然就知道 coding harness 是什么，不需要在上面堆加太多东西。"
read | ||
write | ||
edit | ||
bash | 万能工具 |
对比：少即是多
浏览器操作怎么办？
答案：用 bash 调用 CLI 工具
Mario 的实际做法（文章中提到）：
不用 Playwright MCP（21个工具，13700 tokens）
而是用：CLI 工具 + README 文件具体方案：
1. 写一个简单的浏览器自动化 CLI 工具 2. 配上 README 说明使用方法 3. agent 需要时： • 读 README（按需付出 token 成本） • 用 bash调用 CLI 工具
效果对比：
| 225 tokens |
OpenClaw 与 Pi 的关系
我日常使用的 OpenClaw 实际上比 Pi 更丰富：
| 内置 browser 工具 | ||
sessions_spawn |
所以我的担心是多余的 — OpenClaw 已经内置了浏览器操作能力（就像我刚才用来打开这篇公众号文章一样）。
总结：三个问题的核心答案
问题一：没有 plan mode 怎么保证稳定？
显式 > 隐式：用 PLAN.md 文件显式规划，而不是黑箱 plan mode。
问题二：OpenClaw 的 SubAgent 怎么理解？
Mario 反对：session 中途偷偷 spawn SubAgent 收集上下文，破坏连续性
OpenClaw 做法：显式启动独立 SubAgent，产出 artifact，主 session 决定加载 — 这正是 Mario 推荐的模式
问题三：4 个工具是不是太少？
够用原则：bash 是万能工具，可以调用任何 CLI。
OpenClaw 实际：比 Pi 更丰富，已内置浏览器工具。
核心洞察：Mario 的 Pi 是在探索"极简的下限"，而 OpenClaw 是在 Pi 的基础上，根据实际需求做了合理的扩展 — 既保留了 Pi 的确定性哲学，又提供了更丰富的开箱体验。