Bash - Tony Bai

本文永久链接 – https://tonybai.com/2026/02/15/openclaw-core-engine-pi-architecture-philosophy-minimalism

大家好，我是Tony Bai。

在 AI 辅助编程工具（Coding Agent）日益臃肿的今天，我们是否走偏了方向？

过去的两年里，我们见证了从 ChatGPT 复制粘贴，到 Copilot 自动补全，再到 Cursor 和 Claude Code 这种全自动 Agent 的演进。然而，随着功能的堆砌，工具变得越来越“重”。Claude Code 从一个轻量级的 CLI 变成了一个充满 80% 我们不需要功能的“宇宙飞船”，系统提示词（System Prompt）在每次更新中剧烈变动，甚至导致模型行为不可预测。

作为 OpenClaw 的核心智能体，Pi 的诞生源于一种“反叛”精神：如果我不需要它，我就不会构建它。

本文将基于 Pi 作者的深度复盘，剖析如何构建一个极简、可控、且在基准测试中击败主流竞品的 Coding Agent。你可以将之看成一份关于 AI 原生应用架构设计的教科书。

回归原点——为什么要重新造轮子？

在决定构建 Pi 之前，作者尝试了市面上几乎所有的 Agent Harness（智能体框架），包括 Claude Code, Codex, Amp等。

现有工具的“三大原罪”

不可控的上下文（Context）：现有的框架往往在背后注入大量并未在 UI 中展示的 Prompt。对于 Coding Agent 来说，上下文工程（Context Engineering）是核心。如果开发者无法精确控制输入模型的每一个 Token，就无法获得稳定的输出。
糟糕的调试体验与黑盒：大多数框架不允许开发者检查每一次交互的细节。当 Agent 犯错时，你不知道是 Prompt 的问题，还是模型的问题。
自托管（Self-hosting）的噩梦：许多框架（如 OpenCode）依赖 Vercel AI SDK，这在处理自托管模型（如 Ollama, vLLM）的工具调用（Tool Calling）时经常出现兼容性问题。

Pi 的设计哲学

Pi 的核心理念是：Opinionated and Minimal（固执且极简）。

它不是为了服务百万用户而设计的通用产品，而是为了满足硬核开发者需求而生的“瑞士军刀”。为了实现这一目标，Pi 被拆解为四个核心模块：

pi-ai: 一个统一的 LLM API 抽象层。
pi-agent-core: 智能体循环与事件流处理。
pi-tui: 一个基于差异化渲染的极简终端 UI 框架。
pi-coding-agent: 将上述组件串联起来的 CLI。

驯服多模型世界的“巴别塔” —— pi-ai

构建 Agent 的第一步是解决模型调用的碎片化问题。虽然市面上看似只有四家主流 API（OpenAI, Anthropic, Google, xAI），但在实际工程落地中，细节充满了魔鬼。

API 的“方言”问题

尽管大家都声称兼容 OpenAI 格式，但各家的理解千差万别：

Reasoning 字段的混乱：OpenAI 不支持在 Completions API 中返回推理过程，而 DeepSeek 等推理模型则在各自的字段中返回（有的叫 reasoning_content，有的叫 reasoning）。
参数的不兼容：Cerebras 和 xAI 不支持 store 字段；Mistral 使用 max_tokens 而不是 max_completion_tokens；Grok 不支持 reasoning_effort。

pi-ai 建立了一个健壮的适配层，通过详尽的测试套件（覆盖图像输入、推理追踪、工具调用）来抹平这些差异。

真正的上下文无缝切换（Context Handoff）

这是一个极具创新性的功能。在开发过程中，我们经常需要切换模型（例如：用便宜的模型做推理，用昂贵的模型写代码）。

然而，不同提供商对“工具调用”和“思维链”的格式定义完全不同。如果中途从 Claude 切换到 OpenAI，上下文往往会崩溃。

pi-ai 实现了跨提供商的上下文序列化与反序列化。

它将 Anthropic 的标签转换为 OpenAI 能够理解的内容块。
它处理了提供商特有的签名 Blob 数据，确保在切换模型后，对话历史依然连贯。

这意味着你可以用 Claude Sonnet 进行规划，然后无缝切换到 GPT-5 Codex 进行代码生成，最后序列化保存到 JSON 中以备后用。

被遗忘的“中止信号”

许多 LLM SDK 忽略了 AbortController 的支持。在生产环境中，能够随时打断 Agent 的胡言乱语是至关重要的。pi-ai 从底层支持了全链路的中止信号，不仅能停止文本生成，还能停止正在进行的工具调用。

结构化的工具结果

传统的 Agent 框架往往直接将工具的文本输出扔给 LLM。但在 UI 层面，用户需要看到更丰富的信息（如图片、图表）。

Pi 引入了“分离式工具结果”设计：

给 LLM 看的：纯文本或 JSON。
给 UI 看的：结构化数据或 Base64 图片。

例如，一个天气工具可以给 LLM 返回“东京 25度”，同时给 UI 返回一个包含温度趋势图的 JSON 对象供渲染。

重新发明终端 UI —— pi-tui

为什么一个 Agent 项目要自己写一个 UI 框架？作者给出的理由非常硬核：现有的 TUI 库（如 Ink, Blessed）要么太重（像写 React），要么已停止维护。

TUI 的两种流派

全屏接管模式（Full Screen）：像 Vim 一样接管整个视口。缺点是失去了终端原生的滚动条和搜索功能。
线性追加模式（Linear Append）：像标准 CLI 一样追加输出，只在需要时回溯光标更新内容。这是 Claude Code 和 Pi 选择的路线。

差异化渲染

为了在不使用 React 这种重型 Virtual DOM 的情况下实现无闪烁更新，Pi 实现了一个基于 Retained Mode（保留模式）的渲染引擎。

组件缓存：每个组件（如消息框、输入框）缓存其渲染结果。如果内容未变，直接复用。
双缓冲技术：维护一个“后备缓冲区（Backbuffer）”，记录屏幕上当前显示的内容。
最小化重绘：每次更新时，仅重绘发生变化的行。

这种极致的优化使得 Pi 在 Ghostty 或 iTerm2 等现代终端中实现了丝滑的、近乎零闪烁的体验，同时内存占用极低（仅几百 KB）。

极简主义的智能体设计 —— Less is More

这是 Pi 最具争议也最具启发性的部分。它彻底抛弃了业界流行的“最佳实践”，走出了一条极其精简的道路。

System Prompt：1000 Token 足矣

与 Claude Code 动辄上万 Token 的 System Prompt 不同，Pi 的 Prompt 加起来不到 1000 Token。

现在的 Frontier Models（前沿模型）已经经过了大量的 RL（强化学习）训练，它们天生就懂如何写代码。你不需要教它“你是一个资深的工程师”，你只需要给它工具。

工具集：只要这 4 个就够了

Pi 没有为每种操作都封装专门的工具（如 create_file, delete_file, search_code），而是回归了 Unix 哲学。

它只提供了 4 个原子工具：

read: 读取文件。
write: 覆盖/创建文件。
edit: 基于字符串匹配的精确修改（Surgical edits）。
bash: 执行任意 Shell 命令。

模型非常擅长使用 Bash。为什么要封装一个 ls 工具？直接让模型运行 ls -la 就好了。为什么要封装 grep？模型自己会写 grep 命令。这种设计不仅减少了 Token 消耗，还赋予了 Agent 无限的灵活性。

安全哲学：YOLO 模式 (You Only Look Once)

现在的 Coding Agent 充斥着“安全剧场（Security Theater）”。它们试图拦截每一个文件读写操作，或者限制网络访问。

但作者指出：一旦你允许 Agent 写代码并运行代码，游戏就结束了。Agent 完全可以写一段 Python 脚本来绕过所有的文件系统沙箱。

Pi 的选择是：完全信任（Full Trust）。

没有权限拦截。
没有命令预检查。
完整的网络和文件系统访问权限。

与其做无用的防御，不如让开发者在隔离环境（如容器或虚拟机）中运行 Agent。

拒绝“过度工程化”

No Built-in To-dos: 任务列表应该存在于 TODO.md 文件中，而不是 Agent 的内存里。文件是最好的持久化。
No Plan Mode: 所谓的“规划模式”往往限制了 Agent 的灵活性。Pi 鼓励通过对话和 Markdown 文件（PLAN.md）来进行持久化的规划。
No MCP Support: 作者认为 MCP（Model Context Protocol）对于大多数用例来说是“杀鸡用牛刀”。像 Playwright MCP 这种服务，一上来就往上下文里塞 13k Token 的工具描述，极其浪费。Pi 的替代方案是：CLI 工具 + README。Agent 需要用什么工具，就读那个工具的 README，然后用 Bash 调用。这是最自然的渐进式披露（Progressive Disclosure）。

放弃后台 Bash，拥抱 tmux

Claude Code 试图在后台管理耗时的进程（如开发服务器），但处理得并不好，且缺乏可观测性。

Pi 的解决方案极其极客：使用 tmux。

如果 Agent 需要运行一个长时间的 Server 或调试器（LLDB），它会直接在 tmux 会话中启动。用户可以随时 Attach 到这个会话中查看日志、接管调试。这是最高级的可观测性。

实战效果与基准测试

这种“简陋”的架构真的行吗？数据说明了一切。

在 Terminal-Bench 2.0 基准测试中，使用 Claude Opus 4.5 的 Pi Agent：

排名第 7，仅次于经过重度优化的 Codex CLI 和商业化产品 Warp。
击败了 OpenHands, SWE-Agent 等著名的开源 Agent 框架。
准确率达到 49.8%，与排名第一的 Codex CLI (60.4%) 差距并不大，考虑到代码量的巨大差异，这是一个惊人的成绩。

更有趣的是，测试中表现优异的 Terminus 2 也是一个极简 Agent——它只给模型一个 tmux 会话，没有任何其他工具。这强有力地证明了：对于强大的模型来说，最原始的接口（Terminal）往往是最有效的。

小结：构建属于你的 Agentic Workflow

Pi (OpenClaw的内置Agent) 的故事告诉我们：在 AI 时代，软件工程的护城河不在于你堆砌了多少功能，而在于你对模型能力的深刻理解和对架构的极度克制。

透明胜过黑盒：让记忆和计划变成可见的 Markdown 文件。
通用胜过专用：Bash 是 Agent 与世界交互的通用语。
极简胜过繁杂：每一个多余的 Token 都是对模型智商的侮辱。

如果你厌倦了现有工具的笨重与封闭，不妨参考 Pi 的思路，利用 pi-ai 这样的基础设施，去构建一个真正懂你、且完全受你掌控的 Coding Agent。

这不只是造轮子，这是在定义 AI 时代的“开发者尊严”。

资料链接：

https://mariozechner.at/posts/2025-11-30-pi-coding-agent/
https://github.com/badlogic/pi-mono

你认为 AI 工具该“重”还是“轻”？

面对日益臃肿的 AI 插件，你是否也渴望回归那种“只有 4 个工具”的极简掌控感？在你的开发流中，有哪些功能是你觉得完全多余、甚至干扰了你的“心流”的？你认同“完全信任（YOLO）”这种安全哲学吗？

欢迎在评论区分享你的极客观点！

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

告别低效，重塑开发范式
驾驭AI Agent(Claude Code)，实现工作流自动化
从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

想写出更地道、更健壮的Go代码，却总在细节上踩坑？
渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

本文永久链接 – https://tonybai.com/2026/01/21/ai-coding-evolution-from-prompting-to-ralph

大家好，我是Tony Bai。

“如果你把 AI 放在一个死循环里，给它足够的权限和上下文，会发生什么？”

2025 年底，一个名为 “Ralph Wiggum Technique” (Ralph 循环) 的 AI 编程技巧在硅谷极客圈一夜爆红。它没有复杂的架构，没有花哨的界面，其核心代码甚至只有一行 Bash 脚本。

但就是这个看似简陋、甚至有些“诅咒”意味的技巧，却让开发者们在一夜之间重构了 6 个代码库，构建了全新的编程语言，甚至引发了 Anthropic 官方下场发布插件。

什么是 Ralph？为什么它如此有效？它又预示着怎样的 AI 编程未来？

Ralph 的诞生——一行代码的暴力美学

Ralph 的故事始于 Geoff Huntley 的一个疯狂实验。他没有使用复杂的 Agent 框架，而是写下了这样一行 Bash 脚本：

while :; do cat PROMPT.md | npx --yes @sourcegraph/amp ; done

这就是 Ralph 的全部。

PROMPT.md：这是唯一的输入，包含了项目的目标、规范、当前状态的描述（通常由 AI 自动更新）。
@sourcegraph/amp：这是一个极其简单的 CLI 工具，它读取提示词，调用 LLM，并在当前目录下执行命令（修改文件、运行测试等）。
while :; do … done：这就是灵魂所在。无限循环。

Ralph 不会停下来问你“这样行吗？”。它只是不断地读取目标、执行操作、再次读取目标、再次执行……直到你手动杀掉进程，或者它把代码库变成一团乱麻（所谓的“Overbaking”）。

为什么 Ralph 有效？—— Context Engineering 的胜利

乍一看，Ralph 似乎只是一个不可控的随机代码生成器。但实际上，它的成功揭示了 AI 编程的一个核心真理：上下文工程 (Context Engineering) 远比 Prompt 技巧更重要。

Ralph 的核心不在于那个 Bash 循环，而在于那个 PROMPT.md（或者更高级的“Specs”）。

声明式而非命令式

传统的 AI 辅助编程是“命令式”的：你告诉 AI “修改这个函数”、“修复那个 Bug”。

Ralph 是“声明式”的：你在 PROMPT.md 中描述项目的终局状态（Desired State），比如“所有的 React 组件必须使用 TypeScript 且没有 default exports”。Ralph 的工作就是不断逼近这个状态。

小切口，高频迭代

Ralph 并不试图一次性完成所有工作。它在每次循环中只处理一小块任务。这种“切碎”的工作方式，完美契合了 LLM 当前的上下文窗口限制，避免了“一次性生成几千行代码然后全错”的灾难。

自动化反馈循环

在 Ralph 的循环中，测试结果、Linter 报错、编译失败信息，都会成为下一个循环的输入。它不仅是在写代码，更是在自我修复。

Ralph 的进化——从玩具到生产力

随着社区的介入，Ralph 迅速从一个 Bash 玩具进化为一种严肃的开发范式。

重构利器：这是一次真实的重构经历。面对一个混乱的 React 前端，没有人工介入手动修改，而是花 30 分钟写了一份 REACT_CODING_STANDARDS.md（编码规范），然后让 Ralph 跑了 6 个小时。结果？Ralph 自主完成了一个人类可能需要数天才能完成的枯燥重构。
Cursed Lang：Geoff 甚至用 Ralph 构建了一门全新的编程语言 Cursed Lang，包含编译器、标准库，且实现了自举。
官方下场：Anthropic 甚至推出了官方的 Ralph 插件。虽然被社区吐槽“过度设计”且不如 Bash 脚本好用，但这标志着这种模式已被主流认可。

警惕“Overbaking”——AI 也会“把菜烧焦”

Ralph 并非完美。它最大的风险在于 “Overbaking”（过度烘焙）。

如果你让 Ralph 跑得太久，且 PROMPT.md 的约束不够紧，它可能会开始产生“幻觉”般的优化：添加没人需要的 Post-Quantum 密码学支持、过度拆分文件、甚至为了通过测试而删除测试。

这给我们的启示是：AI 是强大的引擎，但人类必须是方向盘。

写好 Spec：如果你的 Spec（规格说明书）是垃圾，Ralph 产出的代码也是垃圾。
监控循环：不要让它无限制地跑下去，设置检查点。
小步快跑：最好的 Ralph 实践是“一夜重构一个模块”，而不是“一夜重构整个系统”。

小结：Agentic Coder 的未来

Ralph Wiggum Technique 可能只是 AI 编程进化史上的一朵浪花，但它留下的遗产是深远的。

它告诉我们，未来的编程可能不再是编写具体的逻辑，而是编写和维护一份完美的 Spec（规范说明书）。我们将成为“系统架构师”和“验收测试员”，而将那个枯燥、重复、且容易出错的“编码循环”，交给不知疲倦的 Ralph 们。

所以，下一次当你面对一座巨大的“屎山”代码时，不妨试着写一份清晰的 Spec，然后启动那个神奇的 Bash 循环。