面经策

AI Agent 如何处理工具调用返回超大结果的问题？有哪些实用的解决方案？ ​

  • 标签：AI、大模型、Agent

🏛 业务架构师 ​

工具返回超大结果的问题与解法，我按"危害—防线—设计规范"组织：

三大危害：挤爆上下文窗口（后续步骤无空间）、成本失控（大结果每次循环重复计费）、效果劣化（大海捞针，模型反而找不到重点）。

四道防线：

  1. 工具侧"摘要+钻取"（治本）：工具默认返回结构化摘要（总数、Top-N 预览、字段概览），配 get_detail(id) / next_page() 按需取明细。业务例子：代码搜索工具返回"命中 200 处，前 10 处预览"，而非 50KB 全文；
  2. 框架侧限幅截断：返回超过阈值（如 8K token）自动截断，并附元信息"已截断，共 X 条，可分页"——让模型知道信息不全，引导分页取用而不是凭残片硬编；
  3. 压缩侧摘要：超长文本用小模型做"面向当前任务的问题摘要"后入上下文，原文外置存储按 ID 引用；
  4. 协议侧约定：MCP 工具设计规范里明确"输出预算"，超大结果走 Resource 分页或文件引用（返回路径而非内容）。

设计哲学：工具输出要像"邮件摘要"而非"原始附件轰炸"。落地抓手：把"单次返回 token 上限"写进工具接入评审的强制项，超限工具必须改造后上架——事前一行规范，省掉事后无数次上下文救火。这个细节做得好不好，直接体现在 Agent 的单任务成本曲线上。

🏗 系统架构师 ​

超大工具结果的处理我按**"防线前置 + 分级处理 + 外置引用"**三段讲：

危害定量：50KB ≈ 12K token——单次吃掉 10% 的 128K 窗口预算；且 Agent 循环中该上下文每步重复计费（30 步任务 × 12K = 36 万 token 冗余成本，无缓存时）；同时稀释 attention，关键信息被淹没导致决策劣化。

实用方案：

  • 源头契约（最优先）：工具接口设计就限返回规模——分页/条数上限/字段白名单/超时；API 工具默认"摘要 + 明细分页"两种模式；
  • 分级处理管道：结果超阈值触发处理链——截断（保头保尾）→ 结构化提取（只留任务相关字段）→ LLM 摘要（信息密度提升 5~10 倍）；处理后的"高密度版"回填上下文；
  • 落盘外置（大结果正解）：全量结果写工作区文件，上下文只留"文件路径 + 内容概要 + 读取指令"——模型需要细节时用读取工具按需分段加载（带 offset/limit），等价于操作系统的不按需不换页；
  • 检索化：代码库搜索、长文档类结果建临时索引（或写入向量库临时 collection），按 query 取片段；
  • 流式消费：生成类工具结果边生成边处理，不缓冲全量。

架构原则：上下文放"目录"，数据放"外部存储"，按需分页加载——这是 Agent 系统的存储层次结构设计，和虚拟内存思想同源。工具结果尺寸策略应该做进 Context Engine 成为默认行为，而不是每个 Agent 自己处理。

💻 全栈开发专家 ​

超大工具结果的问题是：上下文被吃爆（50KB≈1.5万 token）、成本激增、有效信息被稀释（模型「抓不住重点」）、可能触发截断挤掉 system prompt。

我的四层解决方案：

1. 工具端设计（治本）：工具默认返回「摘要+样本+续读句柄」：

python
def search_logs(query, limit=200):
    hits = es.search(query, limit=limit)
    return {"total": len(hits),
            "summary": f"命中{len(hits)}条，错误类型TOP3: ...",
            "preview": [{"ts": h.ts, "msg": h.msg[:120]} for h in hits[:5]],
            "next": f"调用 get_more(offset=5) 查看后续"}

分页参数（limit/offset）、字段裁剪（只返回模型需要的列）、按需细化（先给摘要，模型觉得必要再调详情工具）。

2. 运行时防护：结果超过阈值（如 8k token）自动截断+摘要+提示「已截断」；文件类产物落沙盘只回传路径；流式聚合的中间结果定期 flush 到文件。

3. 结构化提炼：让结果先过一层「提取」——用规则/小模型从原始结果抽取目标相关字段（比如日志只需时间、级别、错误码），JSON 压缩比能到 10:1。

4. 子 Agent 消化（重型方案）：大结果交给子 Agent 在独立上下文里读全量、产出百字结论回传——父上下文只承担结论成本。代码库分析、日志排障这类必然大结果的场景，这是唯一优雅解。

原则：工具返回的默认形态应该是「摘要 + 获取更多信息的手段」，把「读全量」变成模型主动的、按需的动作。