「Pi 少送 3 倍上下文」该怎么读?

读懂「少送 3 倍」

一个流传很广的数字,原文正文写的是「每轮」,配图量的却是「每任务累计」。用我们自己的运行现算一遍就知道这两个口径可以方向相反:分层压缩那条运行比不压缩的每轮少送约四分之一,每任务累计却多送四成多。再看这个数字的来源等级:第三方公司的内部基准,自报、不可复现。

❓

本课一问:讲 agent 上下文的文章里常见一句「Pi 比 Claude Code 少送 3 倍上下文」。这句话该怎么读?

这一课先不碰:Pi 为什么能送得少(它的设计,本章与 A2、A6 里分散讲过);哪个 harness 更好(A9)。这里只练一件事:读一个数字之前,先问它的口径与来源。

从已有出发 · 累计数据流点已学环节看它回答什么

每一轮循环都经过

第一问:原文到底说了什么

原始出处不是 Pi 的作者,而是 Databricks 的官方博客《Benchmarking Coding Agents on Databricks’ Multi-Million Line Codebase》(2026-07-08;本章开发时 2026-09-26 重新打开核对)。同一段里有两处说法:

正文:「Pi sent about 3x less context per turn」——每轮。
紧跟着的配图,图的替代文本是「Total context re-fed to the model per task」——每任务累计重送的上下文(中位数)。据调研档案对原图的转录:Opus 4.8 上 Claude Code 742k 对 Pi 236k;GPT-5.5 上 Codex 1,235k 对 Pi 665k。按这四个柱值现算,倍数是 3.14 与 1.86;档案与红线措辞写作 3.2x 与 1.9x(图上的标注;柱值是取整后的,本页无法独立核对原图)。

所以同一段文字里,「每轮」和「每任务累计」被当成了一回事;而且只有一个模型上接近 3 倍,另一个不到 2 倍。

第二问:每轮和每任务累计,会差多少?

用我们自己的运行现算一遍。每任务累计 = 把每一轮发出的上下文加起来;它同时取决于「每轮多大」和「跑了几轮」。下面四条都是修同一个 bug、最后都成功的运行(数据:agent-traces.json 的服务端 usage):

运行	轮数	每轮平均发出	单轮最多	每任务累计
pd-v2-unlimited-s2	6	1,430	1,866	8,577
pd-v2-unlimited-s3	7	1,568	2,133	10,975
pd-v2-cap20-s1	11	1,899	2,618	20,894
pd-v2-layered-s1	21	1,444	1,724	30,314

拿分层压缩那条(pd-v2-layered-s1)和不压缩的 pd-v2-cap20-s1 比:每轮平均发出 1,444 对 1,899,每轮少送 24%;每任务累计 30,314 对 20,894,每任务多送 45%——它为了把每一轮压小,压缩了 26 次,也多跑了 10 轮。四条里每任务累计最多的是 pd-v2-layered-s1。两个口径不但数值不同,方向都可以相反。原文自己也写了另一半原因:Pi「finishing the tasks in fewer runs」——轮数少,累计自然少。

⚠

常见误解一:「Pi 每轮少送 3 倍上下文。」

原文正文这么写,但配图的度量是每任务累计的中位数,而且只在 Opus 4.8 上接近 3 倍,GPT-5.5 上约 1.9 倍。可以引用的说法只有一种:「每任务累计重送上下文的中位数,Opus 4.8 上 Pi 比 Claude Code 少 3.2x,GPT-5.5 上 Pi 比 Codex 少 1.9x(Databricks 自报)」。

常见误解二:「这是 Pi 作者测出来的。」

不是。出处是 Databricks;Pi 作者本人没有发表过这组测量。

第三问:这个数字的可信度在哪一层?

谁测的:Databricks,在自己的私有代码库上跑内部基准。第三方公司的自报数据:不是 Pi 官方的广告,但也不是独立复现。
能不能复现:不能。任务与代码库不公开。
条件:同模型、同思考强度下只换 harness;图上没有置信区间;Codex 只配过 GPT 模型,所以「Opus 4.8 上比 Codex 省」在同模型意义上不存在。
作者自己的限定:紧接着那张图,原文写的是这一课不在于某个 harness 永远更省、也不在于原生 harness 更差,而在于模型只是拼图的一块。

问	本课的回答
① 这个数字在量什么?	每任务累计重送的上下文(中位数),不是每轮
② 为什么 Pi 可能送得少?	能在源码里看到的是设计:默认 system prompt 短(仓库深读实测约 2,527 字符,pin `system-prompt.ts:121-138`,本页未复算);工具输出按「2,000 行或 50KB」两道上限截断
③ 实验上呢?	Databricks 内部基准,单一来源

Pi 源码里能直接核对的那一条设计,是工具输出的双上限:

truncate.ts pi@31b513e3:packages/coding-agent/src/core/tools/truncate.ts:1-12需联网 MIT

1/**

2 * Shared truncation utilities for tool outputs.

3 *

4 * Truncation is based on two independent limits - whichever is hit first wins:

5 * - Line limit (default: 2000 lines)

6 * - Byte limit (default: 50KB)

7 *

8 * Never returns partial lines (except bash tail truncation edge case).

9 */

11export const DEFAULT_MAX_LINES = 2000;

12export const DEFAULT_MAX_BYTES = 50 * 1024; // 50KB

👆 带下划线的行可以点:点哪行,讲哪行。

演进地图

这一课是读证据的练习,不在演进链上;它回扣第 3 课的「触发」与第 1 课的「每轮重发」——「每任务累计」正是把第 1 课那张逐轮柱状图加起来。

上下文管理的演进:每一代都被上一代的某个真数字逼出来

起点不管它:每轮把整段历史原样重发

A1 的循环(所有 harness 的底层事实:模型 API 不记得上一轮)

解决了实现最简单,模型每轮都看得到全部经过。

卡在pd-v2-cap20-s1 从第 1 轮的 947 token 涨到第 11 轮的 2,618;第 1 轮里工具定义就占 72%,到最后一轮工具结果占 44%。只增不减,总有撞墙的一轮。
朴素超了就截掉最早的

本课项目 miniagent 的 truncate(整轮丢,保留 system 与任务)、learn-claude-code s08 的 snip_compact(中段存档)

解决了零成本,还能保证 tool 调用与结果不被拆散(按整轮丢)。

卡在pd-v2-truncate-s1 截断 2 次共丢 3 轮,读文件那一轮也在其中;第 7 轮模型凭记忆改,那一行变成 + 1 + 1,验收测试退出码 1。
先便宜先裁工具输出,不花一次推理

CoreCoder Layer 1、learn-claude-code micro_compact、OpenCode prune(默认关)、Anthropic tool result clearing

解决了工具结果是最占地方、也最可再生的一块;裁它不用调模型。

卡在按位置裁,不懂内容:分层运行里被裁过的 0 份测试输出,0 份丢了唯一关键的 AssertionError 行。另一头,本任务最长的工具输出 1,302 字符,CoreCoder 的 1,500 字符门槛一次都没碰到。
何时什么时候触发:百分比、余量,还是以 usage 为准你在这里

CoreCoder 50 / 70 / 90%、Pi 窗口 − 16,384、OpenCode 窗口 − min(20,000, 最大输出)、Codex 90%

解决了阈值定在撞墙之前,给压缩本身和下一次回复留出余地。

卡在本地估算在中文上偏低:一段真实中文 118 token(录制模型的 tokenizer),CoreCoder v0.4.0 估成 60,按「字符数 ÷ 4」估成 45。只靠本地估算触发,就会晚。
再花钱让模型把旧轮次写成摘要

CoreCoder Layer 2、本课项目 miniagent L2

解决了比截断保留更多:旧轮次不是消失,而是被压成一段话。

卡在pd-v2-layered-s1 的 17 份摘要里,写下确切报错的 0 份,编出不存在的「timezone」的 16 份;第 10 轮模型把改对的一处改了回去。21 轮、73,168 token(摘要另花 11,832)才完成,是同组不压缩成功运行最少的 4.3 倍。
现代压缩 = 给接手者写交接文档

Codex(交接摘要 + 保留用户原话)、Pi(结构化模板 + 文件清单)、OpenCode(五节模板)

解决了把「必须留下什么」写进模板:目标、约束、进度、确切报错、下一步、相关文件;完整历史留在磁盘上。

卡在仍然有损。Codex 每次压缩后提醒用户:「Heads up: Long threads and multiple compactions can cause the model to be less accurate. Start a new thread when possible to keep threads small and targeted.」→ 下一章:会话存在哪、明天还记得吗。

旁支 context reset:清空上下文,换一个新 agent 接手作者已弃用

Anthropic《Harness design for long-running application development》(2026-03-24)

为治「context anxiety」(模型以为快满了就草草收尾)而设;同一篇文章写明:换到 Opus 4.5 后这种行为基本消失,作者把 reset 整个拿掉了。

数字口径:本课项目 miniagent 用 Qwen/Qwen3-8B-MLX-4bit 本机录制的真实运行(2026-09-26),每轮发出的消息由重放得到并与录制的压缩事件、服务端 usage 逐轮核对一致;估算器的输出由 CoreCoder、Pi 的原实现在 pin 源码上跑出(a05-context.json,2026-09-26)。耗时不作比较(本机有其他任务同时占用)。

一句话

📌

先问数字的口径:每轮还是每任务、谁测的、能不能复现。

回到主线

压缩了之后,丢了什么? → 第 4 课

你可能会问

「那 Pi 到底省不省?」 这次测量说:在 Databricks 的任务上、同模型同思考强度下,把原生 harness 换成 Pi,单任务成本降低 1.2–2.1 倍,通过率变化 −7 到 +3 个点(自报、不可复现)。「省」有条件,也不是在每个模型、每个强度上都成立。
「我们自己该用哪个口径?」 两个都记:每轮的上下文决定会不会撞墙(本章),每任务累计决定花多少钱(A8)。本课项目的 trace 里两者都能直接算。