我的天，Pi 在最新的开发日志里居然把其他公司的 Agent 都怼了个底朝天🤣
@pidotdev
官方声明，对于 DSH、Claude Code、OpenCode 等解决方案，重点不再是谁的工具更多，或者谁的演示更炫酷，而是一个更棘手的问题：
如果一个 Agent 连续运行 50 个小时，它还能记住自己到底在做什么吗？
他们首先点名批评了 DeepSeek Harness。
Pi 直击 DSH 的上下文管理。
DSH 有一个工具结果修剪器，当工具输出过长时，它会保留开头和结尾部分，直接剪掉中间部分。
Pi 的观点则毫不留情：永久丢失数据。
因为一旦你删除了那些东西，它们就永远消失了。
例如，假设一个代理运行测试并输出一个 30,000 个字符的日志——真正的错误就在第 12,000 个字符处，压缩后，这部分数据就消失了。无论模型后续多么智能，都无法凭空将其恢复。
因此，Pi 的版本是修剪 + 溢出。
它仍然只在上下文中保留一小段数据，但同时将完整的工具结果转储到磁盘，上下文中保存文件路径和偏移量。当模型需要时，它会使用 grep、sed 命令自行读取。
他们在 19 个真实会话上运行了 GLM-5.3 和 DeepSeek V4 Flash，将上下文使用量减少了 26%–35%，未缓存的预填充减少了 72%–88%，并且信息仍然可以完全恢复。
公关稿甚至直接说“绝对比 dsh 的永久损失剪枝器好得多”😂。
然后他们又测试了 Claude Code。
Pi 指出了一个相当有趣的发现：
新一代 Claude 在第三方 Harness 上运行时，有时更容易搞砸工具调用。
典型的例子：Pi 给模型提供了一个非常清晰的编辑工具模式，但它生成的参数却像 requireUnique、matchCase、oldText2 一样——而 Pi 本身根本没有这些参数。
一个合理的猜测是，Claude 的训练后处理会针对它自身的 Claude Code Harness 和工具模式进行超调。
模型已经精确地学习了 Claude Code 中的工具应该是什么样子。
然后你把它放到 Pi 里，它仍然保留着这些固有的思维模式。
所以现在，模型越强大，它与 Harness 的绑定可能就越深。
展望未来，孤立地评判编码模型可能越来越没有意义。
Claude + Claude Code、DeepSeek + DSH、GPT + Codex——它们可能都在融合演变成统一的整体。
Pi提到，他们最近重写了Harness，开始将单个Agent运行视为类似于数据库事务的设计。
在工具调用执行之前，写入意图。
执行结束后，写入结果。
如果进程崩溃，系统需要知道该工具是否实际运行过。
会话树、运行状态、通道、操作日志——所有这些都单独存储。
一个Agent可以并行运行多个通道，每个通道都知道其当前位置、队列和待处理的操作。
上下文可以压缩，但原始执行历史记录保持不变。
他们甚至针对进程在工具执行过程中崩溃等棘手情况设计了专门的恢复机制。
回顾一下如今的许多代理框架，你会发现当时的开发者们真是胆大包天：
一个 while 循环，塞进一个模型，塞进几个工具，在上下文即将崩溃时进行汇总，然后祈祷它不会崩溃。
十分钟内或许没问题。
但一旦代理开始运行数小时甚至数天，各种问题就会接踵而至。
这些问题越来越像是操作系统和数据库的问题。
更令人惊讶的是，Pi 甚至改变了他们对扩展的态度。
如今，人人都信奉“万物皆插件”——DSH 的 Cordis 在这方面走得更远。
但 Pi 最近却在加强对边界的划分：
什么是对话，什么是运行时状态，什么是用户界面，什么是扩展——哪些可以持久化，哪些只能观察。
因为如果插件的功能无限扩展，而代理又长时间运行，那么状态的管理就会变得极其复杂。
OpenCode、Claude Code、DSH、Pi——它们表面上看起来都像是编码代理，但实际上，它们的核心发展路径已经各不相同。
Harness 越来越像人工智能时代的操作系统了🤔