Ayush Bhardwaj：智能体的绕行做法就是命令行工具的反馈

我构建了一个命令行工具，让编程智能体检索以前会话的上下文。观察它们使用工具让我认识到：绕行做法本身就是反馈；智能体可能默默地在工具外面写程序，而不是提交错误报告。

我从自己的会话记录中提取约两万次调用，涉及 14 个命令行工具。约四分之一将输出通过 head、tail、grep 或 Python 等工具过滤；读取密集型命令的比例更高。这些是我个人会话中的观察结果。

管道也可能掩盖失败。没有启用 pipefail 时，shell 管道通常返回最后一个命令的退出状态，因此成功的 head 或 tail 可能掩盖失败的测试。截断输出还可能删掉实际错误；我建议在末尾提供简短失败摘要和完整日志路径。

我的 chat-history 命令行工具可以搜索多个编程工具的历史会话。在一项规模较小的个人使用审计中，智能体经常打开会话后立刻再次过滤。重复截取表明接口应该提供更好的选择功能，而不是每次都让智能体自行重建。

一个完整会话约有 120 万字符，而匹配位置附近的消息约有 3000 字符。通用大小上限只能限制数量，不能确定相关部分，因此我增加了范围、匹配消息和最近消息等选项。

反复用 Python 处理 JSON 暗示需要字段更少的紧凑搜索格式；反复循环检查多个会话则暗示需要批量检查命令。智能体围绕我的命令编写的命令，成了产品路线图。

帮助文本和技能文件也是接口的一部分。我让一个参数不再产生作用，却把它留在技能指令里；观察到的 95 次搜索仍全部使用它。两个会话加载修订指令后，都不再使用旧参数，并尝试了新选项。

会话记录可以提供重放测试：在新旧版本中运行相同命令，再检查智能体后来使用的结果是否仍然可用。智能体接下来的动作只是其意图的粗略线索，因此应留出部分案例用于评估。

如果重新开始，我会先添加有用的范围和数量限制，教智能体使用这些选项，并让默认输出简洁，同时说明如何获取更多内容。智能体知道何时使用参数，参数才有帮助。

面向智能体的模式可以提供简洁输出和清楚的错误。但一个例子虽然减少了工具输出 token，却没有明显改善总体成本或运行时间。因此除了返回字符数，还要衡量正确答案和交互轮次。

我不指望智能体一次就设计出最好的智能体接口。人应该决定工具需要完成什么，再利用真实会话和测试帮助智能体发现并修复摩擦。

备份会话记录，搜索工具名后跟管道或反复重试的情况，再检查接下来发生了什么。对于面向智能体的工具，这些绕行做法就是产品使用数据。