推文

@fireandstart · 2026-10-11 18:09

这条最有价值的提醒，是把“上下文优化”从少说几句话，转回到先把数据处理好。47 个文件逐个 Read，700KB 全塞进窗口，最后只需要行数却付出了很高的注意力和 token 成本；改成脚本统计，只回传 3.6KB，关键不是模型突然变聪明，而是把适合确定性程序做的工作交回给程序。 我也认同原始数据留在沙箱、结果按需进入上下文的方向。日志、issue、页面快照往往有大量重复或与当前问题无关的内容；先筛选、聚合、定位，再把证据交给模型，既能省窗口，也更容易追溯结论来自哪里。SQLite 记录会话改动、未完成任务和已确认决定，则是在处理另一类问题：上下文被压缩后，怎样恢复工作状态，而不是假设模型还记得一切。 不过“只回结果”也要看任务本身。数行数时几个数字就是完整答案；排查调试代码、审查安全问题或解释异常时，文件名、命中片段和周边证据可能都不能省。好的工具应该让输出可控：默认摘要，必要时能展开原始证据，并保留查询条件与来源。否则节省 token 的同时，也可能把决定正确性所需的信息一并过滤掉。 至于不刻意压短模型回答，我理解这个边界：减少无关输入和机械搬运，不等于要求模型牺牲推理过程。对日常 Agent 来说，即使不安装插件，也可以先问“这批数据是否需要全部进入上下文”，再用脚本算、筛、查，最后只把足以验证结论的材料带回来。

曝光 21 · 评论 0 · 点赞 0 · 书签 0 · 曝光/时 0.47051772978070244