我为什么愿意在 Pi 上折腾：一个极简 Agent Harness 的真实价值

前段时间，我把Pi、DeepSeekHarness、OpenHands、Goose等五条AgentHarness路线放在一起做了比较，最后选择从Pi开始。

我更关心一个实际问题：如果要做自己的个人Agent，我能不能理解它、修改它，并把积累下来的Skill、工具和工作流继续带走？

Pi 给出的答案比较直接。它先提供一个足够小的Agent运行内核，模型、工具、上下文和交互方式都可以继续往上搭。默认能力很克制，很多事情需要自己动手补齐。

这正是我愿意在它上面折腾的原因。

第一次看到 Pi Agent，容易把它理解成ClaudeCode、Codex一类完整的AI编程产品。更准确地说，Pi是一个开源AgentHarness：它负责把大模型、工具调用、会话状态和终端交互连接起来。

模型想清楚下一步做什么，Harness负责把这个判断变成真实动作：读文件、执行命令、改代码，再把工具结果送回模型，进入下一轮判断。

Pi 官方仓库目前把主要能力拆成三个部分：

这套拆分把两条路都留了出来：一条是直接用现成的CLI，另一条是把底层运行时嵌进自己的程序，逐渐做成面向写作、研究、自动化或者垂直业务的Agent。

下图主要用来确认 Pi 的产品边界：它是一套可以继续组装的Agent基础设施。GitHubStar会变化，架构分层才是我们后面实践的依据。

Pi 经常被描述成“极简Agent”。这个词如果只停留在界面简单，就没有多少分析价值。实际影响使用成本的，是每次模型调用前需要携带多少固定上下文。

一个 Coding Agent每走一步，通常都要重新携带系统提示词、工具定义、会话历史和工具返回结果。固定内容越长，多轮任务里的重复成本越高。

Pi 默认只提供四个核心工具：

从当前源码看，只有实际传给模型的工具才会出现在系统提示词的工具列表里。默认提示词也没有塞进一套庞大的项目管理流程，怎么组织工作、用什么节奏，都由你自己定。

工具定义本身也要占 Token，而且会在多轮任务中重复出现。默认工具面比较小，意味着Pi从第一轮开始就少背一部分固定包袱。

Pi对Skill的处理也遵循同一思路。启动时，它只把Skill的名称和简介放进上下文；当任务确实需要某项能力时，再读取完整的SKILL.md。

Skill 的完整说明不常驻上下文，用到了才加载。

这对我很重要。以后无论是代码分析、公众号写作、资料研究还是图片生成，我都可能积累越来越多Skill。如果几十份完整说明每轮一起发送，能力越多，成本反而越重。Pi的做法允许我保留一个小内核，再按任务装入需要的能力。

围绕 Pi 的 Token 效率，社区里已经出现过“少40%”、“少一半”、“省90%”甚至“便宜30倍”等说法。

这些数字不一定是假的，但它们测量的通常不是同一件事。有的统计单轮固定前缀，有的统计完整任务，有的把缓存Token算进去，有的只看最终账单，还有的没有把失败和重试计入。

现阶段，我更看重两组相对可靠的外部材料。

1、Databricks：每轮上下文约少3倍

Databricks 使用自家百万行、多语言代码库里的真实PR构建内部Benchmark。任务来自近期人工代码修改，并使用隐藏测试判断Agent有没有完成。为了避免Agent从Git历史里找到原答案，他们还在运行期间切断了工作副本与原仓库历史的连接。

在相同模型、相同思考强度下切换不同Harness，Databricks观察到：

这组结果对我有参考价值，因为任务来自真实代码库，也使用确定性测试验收。不过公开文章没有给出完整样本量和全部逐任务原始记录，因此我不会把“约少3倍上下文”改写成“Pi普遍节省67%Token”。它只证明，在Databricks的任务和配置里，Harness本身足以显著改变成本。

2、预注册研究：固定前缀相差约12—15倍

2026 年 8 月，PointFive的两位作者发布了一项预注册研究。核心实验包含24个确定性代码任务、6个开放权重推理模型以及ClaudeSonnet5，共记录4,644次有效运行。

研究在其特定配置中测得：

固定前缀包括系统提示词和工具Schema。研究最终报告，在匹配的模型、任务和提示词组合里，两套Harness的“每次成功成本”差距达到5—30倍。

“5—30 倍”很有传播性，也最容易被误用。这项研究里的任务最多涉及4个文件，整体成功率较高，部分开放模型还经过协议转换网关。它是2026年8月发布的预印本，复现材料公开，但还不能代表所有长周期生产项目。

我愿意引用它，是因为它把固定前缀、轮次、缓存、成功率和最终成本分开测量；我不会把实验里的最大数字直接写成Pi的产品承诺。

如果只放支持 Pi 的数据，这篇文章会变成一篇软文。

Composio 使用同一个DeepSeekV4Pro、同一组30个工具任务、相同工具和验收规则测试多种Harness，结果很有意思：

Pi 的通过率最高，总花费低于OpenCode；但它使用了最多的原始Token，平均轮次更多，中位完成时间也是最慢的。

这组反例帮助我把 Pi 的优势说得更准确：它降低了每轮调用的固定成本，最后总账仍然取决于模型走多少轮、读取多少文件、调用多少工具，以及失败后是否返工。

轻量 Harness 也会被用重。装入大量常驻工具和扩展、把多个无关目标塞进一个长会话，或者反复要求模型“深度思考、比较所有方案、确认绝对正确”，都可能把节省下来的固定Token再花出去。

Pi 作者 Mario Zechner在X上公布过一项传输优化：通过OpenAIWebSocket使用增量更新后，只发送最新增加的上下文，在对应链路上获得了66%的吞吐提升。

吞吐提升、Token减少和完整任务提速是三个指标。增量传输可以减少重复数据的传送和处理，却不意味着模型少看了66%的逻辑上下文，也不能推导出其他Provider同样提速。

以后评估Pi，我会同时记录新输入Token、缓存读取、输出、推理、轮次、工具调用、任务成功率和墙钟时间。只拿其中一个数字，很容易得到一个好看但不完整的结论。

我选择 Pi 时，也接受了它没有把所有功能做好的现状。Pi没有内置完整的权限系统，也没有为文件、进程、网络和凭据提供默认沙箱。官方文档明确说明：它默认继承启动用户和进程的权限；需要更强边界时，应使用容器、微型虚拟机或策略沙箱。

这意味着它不适合毫无准备地交给普通用户，更不能未经隔离就用于多租户或敏感环境。扩展直接运行在同一个进程里，也要求我认真审查来源和权限。

对我的目标来说，这些边界可以管理。我想逐步形成自己的Agent工作环境：

Pi 的默认状态不完整，却足够透明。对希望开箱即用的人，这会增加学习和维护工作；对愿意理解Agent如何运行、希望自己控制能力边界的人，这种克制反而留下了空间。

这一篇先解决“Pi是什么、为什么值得选”的问题。后面的实践不会一开始就堆扩展，我准备按下面的顺序推进：

我不会因为几张Benchmark图表就认定Pi一定比其他Harness更好。现在能确认的是，Pi把系统提示词、工具集合、Skill加载和上下文管理都做得足够轻，大部分决定权也留给了我。

这套取舍适合我。

接下来，我愿意把时间花在 Pi 上：读源码、做实验、搭Skill、记录失败，再看看一个极简Harness最终能被我折腾成什么样。