pi 过去以 badlogic/pi-mono 为人熟知，如今官方仓库已经迁到 earendil-works/pi。更重要的不是换了地址，而是边界变得更明确：Slack 自动化移到独立 pi-chat，主仓库只保留四块核心积木。
极简项目最容易被误解成“代码少”。pi 展示的另一种极简，是每一层都敢于说这不是我的责任。
四个包，四种变化速度
pi-ai 统一 OpenAI、Anthropic、Google 等 provider 的 model 与 streaming 接口。它处理各家协议差异，向上输出一致的 assistant message event。
pi-agent-core 接管最小循环：把 AgentMessage[] 先交给可选的 transformContext 做裁剪或注入，再由 convertToLlm 过滤 UI-only 自定义消息，调用模型，验证 tool arguments，执行 tool batch，把结果写回 context，并发出严格顺序的 lifecycle events。
这里有个很讲究的并发细节：工具默认可以 parallel 执行，完成事件按真实结束顺序发出，但写入 transcript 的 tool result 仍按模型原始调用顺序排列。运行可以快，历史必须确定。任何工具声明 sequential，整批就顺序执行，避免带副作用的动作互相踩踏。
pi-coding-agent 再向上加入 session tree、compaction、project context、skills、extensions 和编码工具；pi-tui 只负责终端的差量渲染与交互。provider 变动不需要重写 UI，终端主题也不该污染 agent loop。
harness 为什么比 loop 厚
低层 loop 只承诺事件顺序，不等待外部异步 listener 成为执行 barrier。上层 Agent / harness 才负责状态归约、steering、follow-up、abort、save point 和 session 持久化。例如 assistant 的 message_end 在工具 preflight 前成为 barrier，beforeToolCall 因而能看到已经落入状态的请求消息。
这个差异很小，却决定了扩展能不能安全地做审计或阻断。pi 没把所有需求塞进 loop，而是用层级明确“观察事件”和“参与控制”不是一回事。
它故意没有什么
pi 明确不内置 filesystem、process、network 或 credential 权限系统，默认继承启动进程的权限。需要隔离时，官方建议 Gondolin、Docker 或 OpenShell。它也不把 MCP、subagent、plan mode、todo、background bash 作为核心内建，而是留给 extension 或外部 package。
这给高级用户极大自由，也把责任原样交还部署者。minimal 不等于 safe by default；边界画得清楚，不代表边界已经替你建好。
我的思考
pi 最能打动框架作者、CLI 爱好者和想组装自己 coding agent 的高级开发者。他们宁愿拿到清楚的 event、session 与 extension 接口，也不想被一个全家桶规定工作流。
市场上，模型 API 和基础 loop 会越来越商品化，真正长寿的是边界稳定的组件。围绕 pi 这类 kernel，可能出现两类生意：一类卖 workflow extension，另一类卖 hardened distribution，把权限、容器、企业策略和审计预装好。
我额外认同它把“未实现”写进设计。很多框架用内置功能数量证明完整，pi 反过来用责任归属证明可组合。但这也给使用者一道考试：当工具以你的系统权限运行时，自由不是默认安全的同义词。未来最好的极简内核，应该同时拥有最清楚的外部安全契约。