我实测了编程代理上下文的真实内容：84%的命令输出是无人阅读的噪音

我花了一周时间查看我的编程代理实际上在其上下文中的内容，结果令人尴尬：大部分是没有人或模型需要的命令输出。以我自己的仓库为例。cargo test 向标准输出写入了188,298字节：2,553行，约47k token。其中，有用的部分是三个失败测试的文件:行号、断言、总计和退出状态：共669字节。其余部分是2,503个通过测试的名称、打印了两次的panic跟踪、回溯提示和构建杂谈。对于宽分支上的 git diff 和跨树的 grep，情况类似。我构建了什么来修复它，更重要的是我学到了什么：在执行时过滤，而非之后。一旦188KB进入记录，成本已经产生。决定必须在命令运行的地方进行。有限输出必须命名其丢弃的内容并保持精确恢复可用。静默截断的数据包比长数据包更糟，因为模型无法区分"完成"和"截断"。归因比压缩更重要。在典型技术栈中，命令包装器修剪输出，搜索工具建立自己的索引，记忆工具运行自己的进程，三者对保存内容的描述各不相同。除非一个组件拥有记录，否则节省数字只是感觉。代理会绕过障碍。如果原始命令比高效命令更容易获取，代理就会选择原始命令。因此，高效路径必须比绕行需要更少的判断，而绕行必须获得零分，而不是悄悄算作一次成功。永远不要伪造零。如果记录不可用，它应该显示未知。一个舒适的零会教你信任一个不存在的数字。在14个相同案例、5次重复和固定版本上测量：交付的原始命令输出为284,996 token，通过控制平面为44,400 token。减少了84%，记录的运行和校验和与代码一起保存。Token计数是基于字节的交付输出估算，而非提供商计费。乐意回答实现问题。链接在评论中，按照规则3。