“工具刚跑完一段构建日志，上下文立刻爆了，后面的推理全乱，像被人塞了一本说明书。”
图：MikeRun / Wikimedia Commons / CC BY-SA 4.0
这是上周我们办公室给本地 Agent 接构建工具之后发生的事。同事小陈让 Agent 读一次失败日志再总结原因，工具原样把几千行输出塞回对话。模型还没开始分析，上下文预算已经被日志占满，后面连问题本身都记不清。
我问他：“日志里真正有用的大概多少行？”
他把屏幕往下翻：“错误就那么十几行，前面全是下载进度和无关警告。”
一、先别急着怪模型记性差
小陈一开始以为是模型窗口太小。我们换了一个上下文更大的本地档，问题还在：工具返回太长，再大的窗口也会被一次调用吃掉大半。说明根因是工具输出没有截断和摘要，不是单纯换更大模型能解决的。人眼扫日志会跳过进度条，模型却把每一行都当成同等重要。
图：Colin / Wikimedia Commons / CC BY-SA 4.0
二、我们怎么改
第一步，摘要截断。工具返回超过约定长度就先截断，只保留尾部失败相关段落和开头的命令摘要；完整日志落到本地文件，对话里只留路径和摘要。Agent 需要细节时再按需读取片段，而不是一次灌进上下文。
第二步，关键行抽取。对构建、测试这类日志，优先抽取含错误、失败、超时、退出码的行，以及紧邻前后各若干行。进度条、重复警告默认丢弃。抽取规则写死在工具包装层，不依赖模型自己记得删掉废话。
第三步，上下文预算。每次工具调用前估算将占用的字数，超过本轮预算就强制走摘要路径；多工具串联时给每个工具留配额，禁止某一个工具独占。预算打满就提示人先看摘要，再决定要不要展开某一段。
三、验收数字
我们准备了十份真实失败日志，长短不一。改之前，Agent 直接吃全文，十次里有七次后半段推理跑偏或答非所问；改成摘要截断加关键行抽取以后，十次都能指出真正失败点，且上下文占用稳定在预算内。我们还故意塞了一份超长成功日志，确认不会因为看起来很重要就整份灌进去。
图：Abigor / Wikimedia Commons / CC BY-SA 3.0
另外我又加了三道题：只要摘要、只要错误行、需要展开某一段。三道都按预期走，没有偷偷把全文塞回对话。换人值班按同一套规则跑，结果也一致。
四、几点体会
工具返回不是越全越好，上下文是稀缺资源。截断、关键行、预算三件套，比换更大窗口更可控。完整日志留给文件，对话里只留能支撑下一步的信息。验收要用真日志，空口说差不多短一点不够。包装层把规则写死，比每次口头叮嘱模型更靠谱。
你们给本地 Agent 接工具时，有没有被超长日志塞爆上下文？欢迎评论区交流做法。
我把这次摘要截断和预算验收的记录整理在 evafang.com ，需要时可参考。
