控制日志和命令输出：不要把十万行结果塞进上下文

问题通常出在哪里

测试、构建、搜索和日志查询都可能输出远超当前决策需要的内容。代理真正需要的往往只是：

• 失败测试名
• 第一段错误堆栈
• 命中的文件与行号
• 汇总数量
• 失败命令和退出码

把完整输出直接塞进会话，不但扩大上下文，也会稀释关键信号。

优先做结构化缩小

搜索

rg -n "refreshToken|refresh_token" src tests

优先限定目录和关键词，不先打印整个仓库。

测试

先运行目标测试：

pnpm test auth-refresh --runInBand

失败后再扩大范围，不要每次小改动都跑全套并回传全部日志。

日志

完整日志写文件，聊天只提供摘要和路径：

some-command > /tmp/codex-task.log 2>&1
printf "exit=%s\n" "$?"
tail -n 120 /tmp/codex-task.log

大 JSON

用 jq 只取必要字段：

jq '{status, error, requestId, items: (.items | length)}' response.json

head -c 不是万能答案

简单截断可以防止灾难性大输出：

COMMAND 2>&1 | head -c 8000

但它也可能切掉最后的根因和汇总。更稳妥的顺序是：

1. 先选择正确命令和范围
2. 让工具输出摘要
3. 保存原始输出到文件
4. 需要时读取相关区段
5. 最后才做字节截断

RTK 与 Distill

这类工具会将常见 CLI 输出压缩成更适合代理阅读的结果。它们对测试、Git、构建等噪声较大的命令可能有价值，但项目方宣称的节省比例主要针对命令输出，不应直接写成总 Codex 配额节省比例。

使用前检查：

• 是否保留退出码
• 是否能回看原始输出
• 是否会漏掉 warning 或堆栈
• 是否支持你的命令
• 工具自身是否引入额外模型调用

建议的 AGENTS.md 规则

- Before running a potentially verbose command, narrow its scope.
- Save full logs to a file and return only the exit code, failing items, and relevant excerpts.
- Do not truncate away the only copy of an error; keep the raw file path for follow-up.
- Run targeted checks after small edits; run the full suite only at the final verification stage.

衡量方法

同一测试任务记录：

• 原始输出字符/token 估算
• 压缩后输出
• 是否一次定位成功
• 是否因信息缺失再次读取
• 总完成时间和配额变化

只有在不增加返工的情况下，输出缩小才是真正的节省。