考察点
这道题出自腾讯后台开发岗一面，场景非常具体：Oncall 排障 Agent 调日志查询工具，一次返回几万行日志，直接塞进上下文窗口就爆了。面试官想看的是你处理「工具输出远大于上下文容量」这个工程问题的思路——这是 Agent 落地的真实痛点，答案的关键不是某个 trick，而是「不让原始大数据进模型上下文」这个原则以及围绕它的一组手段。
参考答案
先立原则：原始日志永远不该整段进上下文
上下文窗口是稀缺资源， Oncall 排障里一次日志查询返回几千到几万行很正常，哪怕窗口装得下，全塞进去也是三个问题：token 成本爆炸、无关日志稀释模型注意力（lost in the middle）、把多轮诊断的后续轮次空间挤光。所以原则是：工具侧先把数据处理到「结论级」再返回，上下文里只放证据摘要，原始数据留在工具侧随时可查。
手段一：工具输出在服务端做摘要和截断
最直接的一层：工具网关对返回结果做统一后处理——
- 截断 + 元信息：返回前 N 条 + 明确告知「共 83,421 条，仅展示前 200 条」。模型知道总量和截断事实后，可以自己决定要不要缩小时间窗或加过滤条件重查，而不是对着不完整数据下结论。
- 服务端聚合摘要：日志工具不只返回原始行，同时返回聚合视图——按错误码/服务名/时间段分组的计数统计、top N 高频报错模式。排障时「哪个服务在 14:03 开始报 connection timeout、每分钟多少条」往往比原始日志行更有用。
手段二：让模型先过滤、再取详情（渐进式披露）
把一次大查询拆成两步走：
- 模型先发起粗查：限定时间窗和服务，工具只返回统计分布和采样示例（比如每种错误各 3 条样例）。
- 模型根据分布判断可疑方向，再发起细查：加 grep 条件（error 关键字、特定 traceId、特定实例），只取命中的小结果集。
这本质上是把日志平台的过滤能力（grep、聚合、采样）暴露给模型，让它像人一样「先扫一眼再钻进去」，而不是一次性把整个文件拖进来。工具设计上，查询接口要支持丰富的过滤参数和 limit，模型的工具描述里写清楚「结果集大时请先缩小范围」。
手段三：分段分析 + 中间结论外置（map-reduce 式）
当日志量确实需要全量过一遍（比如统计某异常的所有出现模式），用分段处理：
- 日志按时间或大小切成段，每段分别交给模型（或更便宜的小模型）分析，产出该段的结构化结论：错误类型、时间分布、关联 traceId、代表性日志行。
- 各段结论汇总后再做一次 reduce 分析，得出整体判断。
- 关键设计：中间结论写到外部存储（scratchpad / 状态机），上下文里只带结论的引用，需要回溯某段细节时按 traceId 或时间段重新查。这就是「记忆外置」——上下文只当工作区，不当仓库。
map-reduce 的成本不低，所以只用于确需全量分析的场景；大部分排障靠手段二的两步查询就能收敛。
手段四：上下文管理兜底
即使做了上面三层，多轮诊断累积下来上下文还是会涨，再加兜底：
- 工具结果生命周期管理：中间轮次的大段工具返回，在被模型消化（模型已基于它得出结论）之后，从上下文里移除或替换成摘要，只保留结论。Anthropic 的 context editing 思路就是这个。
- 历史轮次压缩：较早的诊断轮次做摘要，保留关键决策和已排除的方向。
- 关键证据白名单：排障里某些日志行是「铁证」（首次报错、panic 栈），标记为不可压缩，压缩时保留原文。
落地优先级
如果面试时被问「先做哪个」，我的排序是：服务端截断 + 聚合摘要（一天能上，解决 80% 问题）→ 两步式渐进查询（改工具接口和描述）→ 上下文压缩（框架能力）→ map-reduce 全量分析（最后做，成本最高）。同时埋点看每个工具的返回 token 分布，哪个工具是消耗大户一目了然，优先治理。
可能的追问
- 摘要会不会把关键错误信息滤掉？ 答：所以摘要只做「视图」不做「删除」——原始日志在工具侧可查，摘要里带定位信息（traceId、时间段），模型判断可疑后能取回原文；过滤规则本身也要在排障 badcase 上回归测试。
- 用小模型做日志初筛靠谱吗？ 答：错误分类、模式聚类这类任务小模型够用且便宜；但涉及根因推理的环节还是用主模型。用前在标注好的排障案例上验证小模型的漏报率。
- 怎么评 Oncall Agent 的排障效果？ 答：用历史故障工单建回放集（有完整日志和人工结论），看 Agent 的根因定位准确率、平均诊断轮次、token 消耗；上线后看 MTTR 变化和人工采纳率。