工具返回几十万 Token 的日志，怎么处理？

先这样答

绝不能把几十万 Token 的日志直接塞进上下文。处理超长日志必须采用分层截断与按需读取策略。最理想的做法是把过滤逻辑前置。我们在设计日志类工具时，直接增加过滤参数。调用时必须传入时间范围或日志级别。这样从数据源头就能减少返回体积。

工具返回数据后，我们要对内容分层处理。第一层是即时层。我们只截取关键信息放入上下文。这包括运行错误码，以及通过正则匹配提取的日志首尾关键行。第二层是摘要层。我们引入小模型或写死一套提取规则。小模型阅读长日志并提取结构化结论。Agent 阅读结论即可做决策。

第三层是原始层。几十万 Token 的全文必须外置。我们把完整日志存入对象存储系统。存好后，我们在 Agent 的上下文里只保留一个引用句柄。Agent 如果发现即时层和摘要层信息不够用，可以再次调用读取工具。Agent 传入引用句柄和指定行号范围，按需回放特定片段的日志。

面试官会怎么追问

• 「如果 Agent 频繁调用按需回放工具，导致整体耗时太长怎么办？」 我们可以在摘要层把提取工作做细。小模型生成结论时，要求它一并返回关键报错的具体行号。Agent 拿到行号后，直接调用工具精准请求目标片段。这能减少 Agent 盲目翻页的试错次数。

• 「即时层的首尾关键行具体怎么截取？」 这取决于具体日志类型。如果是堆栈报错日志，我们保留前五十行看异常类型。我们再保留最后五十行看具体业务代码报错点。中间冗长的框架内部调用栈直接丢弃。

• 「为什么不用大模型直接做长文本摘要，而要用小模型或规则？」 每次都调用大模型处理几十万 Token 成本太高。日志格式通常比较固定，规则匹配已经能提取大部分关键指标。小模型专门微调后处理特定格式日志的速度更快。

回答的坑

盲目迷信长上下文模型，回答直接把几十万 Token 扔给大模型，忽视了高昂的推理成本与延迟。

忘记提及工具端的过滤参数设计，只在 Agent 接收端做后置处理，显得缺乏工程经验。