观察窗口：2026-08-17 至 2026-08-23。只纳入已经正式发布、能找到原始证据，并且公告之外还有具体材料的 Pi / Extension 更新。
这一周 Pi 生态没有出现一个轰动式的大版本，但三个 Extension 把 agent runtime 的三个麻烦问题往前推进了一步：上下文如何留下来、缓存如何变成成本指标、多个 Agent 如何在边界内协作。
它们共同指向一个变化：Pi 的价值不只在于“能调用模型”，而在于模型周围的运行时越来越可组合。
本周三个正式发布
Cortext：每轮召回，压缩时不再调用总结模型
Cortext for Pi v0.1.1 于 8 月 18 日发布。它不是在 compaction 时生成一篇固定摘要，而是把消息写进本地记忆存储，在每轮上下文组装时根据当前请求召回相关内容。
它有两个普通用户能感受到的变化：
- Pi 调用搜索、代码检查等工具后，Cortext 会把工具刚刚得到的重要信息记下来。模型下一步继续工作时，还能看到这些信息，而不是只记得最开始的问题。
- 对话太长、Pi 需要压缩上下文时，Cortext 不会再额外调用一个模型来写长摘要。它会把旧对话存到本地，只在当前对话里保留最近的一段，并在之后需要时把相关内容找回来。
仓库 README 声明包含 83 项单元和类型测试，以及运行真实 Pi 0.84.2 RPC session 的集成测试。测试会检查三件事：压缩过程没有额外的 LLM 总结调用、被压缩的内容能在下一轮召回、另一个 session 不能读取当前 session 的记忆。
这不是“装上就不会忘记”的魔法。召回内容仍然是不可信输入，历史 prompt injection 可能被重新带入上下文；细粒度检索也仍在改进。如果本地引擎加载失败，记忆 scope 会退化为没有 recall 的透传模式。
适合谁：经常跑长任务、频繁触发 compaction，或者需要跨多轮排查同一问题的人。它真正节省的是总结调用和重新寻找上下文的成本，而不是保证模型每次都正确使用记忆。
证据：v0.1.1 Release · 架构、测试与限制 · npm
Pi Cache Optimizer：缓存命中率变成可观察的成本指标
Pi Cache Optimizer v2.8.6 于 8 月 23 日发布。它处理的不是“让模型少看一点”，而是尽量让应该稳定的 prompt 前缀保持稳定，并帮助请求持续路由到能够复用缓存的 provider 节点。
它提供的能力包括：
- 将稳定的 system prompt 内容放到动态上下文之前。
- 为兼容的 OpenAI-style channel 提供保守的
prompt_cache_keyfallback。 - 诊断第三方代理的 session affinity / sticky routing。
- 检查 DeepSeek reasoning、Anthropic cache TTL 和 provider compatibility。
- 在 footer 显示 session、process 或 provider/model 维度的缓存统计。
/cache-optimizer fix修改models.json前必须确认预览，并自动生成时间戳备份。
更值得记录的是同一周出现的一条独立实测。EvanDeKim 报告：使用 Pi harness 运行 DeepSeek V4 Flash，近 10 亿 token 的缓存命中率达到 99.93%，实际花费 $2.65；无缓存成本估算为 $132。
这里必须把归属说清楚：这条帖子是 Pi harness + DeepSeek 的独立使用结果，不是 Pi Cache Optimizer 自身的 A/B benchmark。Extension 提供的是稳定 prompt、路由诊断和统计观测；独立实测则说明这些机制在某些模型和 provider 上可能直接影响成本。
怎么复现：在同一个 Pi session 中发送数轮具有相似稳定前缀的请求，观察 footer 或运行 /cache-optimizer stats。如果使用第三方代理，再运行 /cache-optimizer doctor 检查 session affinity 和 provider compatibility。
边界：99.93% 不是所有用户的保证值。provider、模型、代理路由、prompt 变化和计费规则中的任意一项变化，都可能显著改变结果。
证据：npm v2.8.6 · 功能与复现步骤 · 独立缓存实测
pi-subagents：并行不等于失控
pi-subagents 在 8 月 23 日发布 v0.56.0。它让父 Pi session 把任务交给独立的 child Pi session，用于侦察、实现、审查、第二意见、并行审计和后台工作。
README 给出的角色分工很具体：scout 先理解代码，researcher 核验外部事实，worker 执行实现，reviewer 检查正确性与测试，oracle 在行动前挑战假设。推荐流程是：
clarify -> scout -> worker -> fresh reviewers -> workerv0.56.0 的更新重点包括：白名单内的 OpenAI Codex 子代理可以选择 priority service tier；有限的 Extension metadata 可以传给原生 child launch，但不会泄露给外部 runner；workflow 更容易返回和检查 child result；大文件脏状态、中断任务和 provider-qualified model ID 的 completion guard 更稳健。
它的边界比功能列表更重要：安装不会自动启动后台 reviewer；父 session 仍然掌握角色、任务和最终结果；后台任务受并发、模型、工具权限和累计 spawn 数量限制。maxSubagentSpawnsPerRun 默认值为 64，这是一道防止工作流无边界扩张的护栏，不是建议一次创建 64 个 Agent。
一位 Pi 实践者把 pi-subagents 列为最常用的 Extension 之一，具体用于代码审查、探索、实现、并行审计、保存工作流和后台任务。这是使用反馈，不是量化 benchmark，但说明它已经进入真实工作流，而不只是一个 API demo。
适合谁：需要第二视角、并行审查或长时间后台任务的人。它解决的不是“让模型变聪明”，而是让委派有角色、边界和完成检查。
证据：v0.56.0 Release · 角色、工作流与限制 · npm · 实践者反馈
这周真正的信号
这三个项目看似分散，实际都在做同一件事：把模型之外的运行时行为变成可控制、可观察、可替换的组件。
| 问题 | Extension 方向 | 对用户的直接影响 |
|---|---|---|
| 长会话容易丢上下文 | Cortext 的每轮召回与零 LLM compaction | 少一次总结调用，压缩后更容易找回相关信息 |
| 长任务的缓存成本不可见 | Cache Optimizer 的稳定 prompt、路由诊断和 footer 统计 | 能看到命中率，定位代理和 provider 配置问题 |
| 多 Agent 容易互相覆盖或无限扩张 | pi-subagents 的角色、父子边界和 completion guard | 并行审查更容易复用，也更容易停止和验收 |
这也是 Pi 和传统“功能越多越好”的 Agent 产品之间的差异：Pi 把基础能力保持得很小，再让用户通过 Extension 组合出自己的运行时。代价是安装、兼容性和安全边界需要自己负责；好处是每个能力都可以替换、拆开验证，而不是被一个封闭工作台一次性决定。
本周的结论不应该是“哪个 Extension 最强”，而是：Pi 生态正在把 Agent 的竞争从模型选择，推进到运行时设计。