# 工具结果回流税：截断即丢证三栈实测 ## 核心发现 2026年，AI Agent的工具使用瓶颈已经悄悄换位。**"选对函数"这道题被BFCL宣布基本做完了——单轮函数调用对前沿模型接近饱和；真正的死亡现场，是函数把结果吐回来那一刻。** 一行`get_log_events`返回180KB JSON，三步之内上下文预算爆表，Agent开始编造日志里根本不存在的错误码；三个常用MCP服务器（GitHub/Slack/Sentry）加载完就吃掉200K窗口的71.5%，用户还没开口预算已近枯竭。我们把这一层称为"工具结果回流层"（tool result boundary），实测三种处理策略——**截断、投影、摘要**——各自吞掉一种税：截断丢证、投影丢语境、摘要丢细节。而多轮串链（turn-3的结果要喂给turn-8）则把单轮70%+的保真度压成MCPMark的52.6% pass@1。本文以Harbor DevOps事故、Perplexity出走MCP、BFCL V4人格分裂三个案例为骨架，拆解结果回流层的暗账。 ## 工具使用能力五维拆解 在进入结果回流层之前，先厘清"工具使用"从来不是单一能力。它至少分解为五个正交子能力，不同的benchmark只测其中一片： | 子能力 | 定义 | 主测benchmark | 2026状态 | |--------|------|--------------|---------| | 函数选择 | 在工具清单里选对函数 | BFCL / ToolBench | 单轮近饱和 | | 参数填充 | 从请求抽取正确参数 | BFCL / T-Eval | strict模式后大幅改善 | | 调用排序 | A的结果决定B的调用 | BFCL multi-turn / MCPMark | 断崖区 | | 对话管理 | 多轮围绕工具澄清/总结 | Tau-Bench | 中等 | | 策略合规 | 越权/鉴权/范围限制 | Tau-Bench / BFCL abstention | 公开短板 | 独立的benchmarkingagents评测直言：**"诚实的工具使用声明，至少要引两个benchmark"**——BFCL高分的模型在Tau-Bench上仍可能崩，因为Tau-Bench额外要求策略合规与多轮对话。只贴一个分数，就是障眼法。 ## 结果回流三式策略对比表 当工具返回的payload大到不能原样塞进下一轮，工程上有三条快慢车道。下表是三式策略的横向实测账本： | 策略 | 证据保真度 | 上下文成本 | 端到端延迟 | 实现复杂度 | 最佳适用 | |------|-----------|-----------|-----------|-----------|---------| | 头尾截断(head/tail) | 低-中：中间行全丢 | 极低 | 最低(ms级) | 低 | 时间序列日志 | | JSON投影投影+行帽 | 中：丢字段不丢行 | 低 | 低 | 中 | 列表/搜索API | | 抽取+小模型摘要 | 中-高：保语义丢原文 | 中 | 高(多一跳) | 高 | 长事件线程/多文件diff | | 全量原样回灌 | 理论最高 | 爆窗 | 高 | 最低 | 仅极小payload | 三式没有赢家，只有**取舍**。下面逐一拆解每种策略吞掉的"税"。 ## 一、证据死亡现场：丢证三态 Harbor DevOps的事故Agent是一个教科书级的回流失败案例。它能查CloudWatch、拉部署事件、起草事故摘要——staging阶段一切正常。上线后，一次`get_log_events`返回**180KB JSON blob**：上千行日志、堆栈、健康检查噪声、重复重试。Agent把整包塞进下一轮，三个工具步之内，运行超过上下文预算，**先前推理被驱逐，Agent开始编造日志里从未出现过的错误码**。oncall工程师事后反馈：在日志量大的Sev-2告警里，这个Agent有**41%的情况"自信且错误"**。 这不是偶发，而是结果回流层的三个确定失败态： - **上下文驱逐（context eviction）**：一个50K-token的JSON数组落地历史，系统提示、工具定义、先前推理全被挤出窗口。 - **针丢失（needle loss）**：信号在第4812行，模型只关注头尾，中间错过，然后靠猜。 - **虚假确信（false confidence）**：模型把截断后的垃圾叙述成规律，仿佛读完了全文件。 关键洞察：**摘要不是可选的润色，而是工具契约的一部分**——就像你不会把一个无界`SELECT *`直接暴露给Web表单一样。 ## 二、截断快车道：头尾保留与行帽的代价 最便宜的第一道防线是**观测预算（observation budget）**——每个工具调用设一个token上限。生产环境典型带位：结构化状态工具（健康检查、单记录查询）500–2000 token；列表与搜索工具2000–8000 token加硬行帽；文档与日志工具4000–12000 token（投影后），**永不无界**。 预算要与会话级天花板组合：如果三个并行工具各返回8K，合并步必须仍塞得下窗口。截断本身有四种子技术： 1. **头尾保留**：时间日志保留前N后M行（错误常在边界），插入显式省略标记`[... 11,240 lines omitted ...]`，绝不静默从JSON中间切。 2. **JSON路径投影**：每工具定义白名单`$.items[*].{id, status, updated_at}`，丢掉base64、HTML正文、嵌套审计尾，**投影在工具适配器服务端跑，不在模型prompt里跑**。 3. **行帽与稳定排序**：按severity desc再timestamp desc取前50行，并告诉模型排序键，让它知道缺了什么。 4. **二进制blob拒绝**：用`{sha256, size_bytes, mime, preview:null}`占位，提供`extract_text_page(range)`后续工具，而非内联。 截断的税很明确：**它在概率上杀死了中间的针**。当正确答案恰好落在被截断的区间，模型只能编。 ## 三、摘要慢车道：抽取+小模型+结构化Schema 当投影后的行仍超预算（长事件线程、多文件diff、聚合指标），就在观测进入历史前插一个摘要跳： - **抽取跳（extractive）**：正则/解析器拽出错误码、HTTP状态行、异常类型、top堆栈帧。便宜且忠实。 - **内联LLM摘要**：小快模型把投影后payload压成带行号/记录ID引用的bullet简报，**输出上限800 token**。 - **结构化摘要Schema**：强制JSON（症状/可疑服务/时间线/悬而未决项），让主Agent对着字段规划，而非对着散文漂移。 完整原始payload落到对象存储，以`observation_id`为键供审计重放（deterministic replay），**只把摘要+指针传进会话**。这本质是把上下文压缩从会话中段挪到了工具边界。摘要的税是**一跳延迟和细节损耗**——但相比爆窗，这是生产里唯一可承受的权衡。 ```python SUMMARY_SCHEMA = { "symptoms": [str], # 异常码 / 5xx 计数 "likely_services": [str], "timeline": [{"ts": str, "event": str}], "open_questions": [str], # 待主Agent决策的悬而未决项 } # 小模型压缩 → 800 token上限；原始payload落对象存储，仅summary+指针进会话 ``` ## 四、烧窗危机：MCP的71.5%原罪 如果说单工具的结果回流是慢性病，那MCP的多服务器schema膨胀就是急性危机。agentmarketcap 2026年4月的实测指出：加载三个常用MCP服务器（GitHub、Slack、Sentry）**约消耗200K窗口里的143,000 token——71.5%在Agent处理第一条用户消息前就已蒸发**。 Perplexity CTO Denis Yarats在2026年3月公开宣布公司内部放弃MCP，理由正是**72%的上下文窗口在用户查询处理前就被工具schema吃掉**，Perplexity已回退到传统API和CLI工具。Scalekit一份跑了75组头对头的benchmark发现：**相同操作，MCP比CLI多烧4倍到32倍的token**。在日调用1000万+的规模下，这个成本差成了预算黑洞。 2026年MCP路线图公开承认了这一点，把上下文效率列为优先项，但提议的解法（**lazy tool loading、tool summarization、schema compression**）全部还停留在pre-RFC——也就是"问题陈述"阶段，没有一项是已发布的修复。这与本系列早前实测的"懒加载发现税：省85%却漏工具"形成闭环：省预算和漏工具是一枚硬币的两面。 ## 五、单轮满分多轮崩：BFCL V4人格分裂 Berkeley的BFCL V4（2025发布、ICML宣讲）是函数调用的事实标准，覆盖22个任务类别、2000+问答对，用AST方法验证调用是否结构语义都正确。V4的进化谱系很清晰：V1单轮AST、V2企业库、V3多轮+并行、V4 holistic agentic（联网搜索、持久记忆、abstention弃权）。 榜单本身就有 surprises。据agentmarketcap抓取的BFCL V4快照： | 排名 | 模型 | BFCL V4 总分 | |------|------|-------------| | 1 | GLM-4.5（开源） | 70.9% | | 2 | Claude Opus 4.1 | 70.4% | | 3 | Claude Sonnet 4 | 70.3% | | 7 | GPT-5 | 59.2% | 两个发现刺眼：开源GLM-4.5登顶，证明函数调用领域开源权重已与闭源API持平甚至反超；GPT-5以59.2%排第七，与其在通用推理/SWE-bench的强势形成反差。**这不是模型质量问题，而是测量缺口**——为代码和推理优化的模型，未必在精确工具调用格式与编排上拿到等量训练信号。工具调用准确率和编码能力相关但可分离。 但V4最致命的发现是**"人格分裂"（split-personality）**：前沿模型在孤立的一次性函数调用上近乎满分，一旦要跨对话管理上下文、记住先前工具输出并推理，分数骤降。三个开放挑战： - **记忆管理**：turn-3的工具输出要在turn-8构造正确调用时，多数模型要么丢上下文要么**虚构先前结果**。 - **动态决策**：实时决定是调用、等待、还是声明上下文不足。V4的abstention任务显示，高分模型也频繁在"本该用自然语言回答或反问"时错误地调用了工具。 - **长程推理**：串链超过4-5个顺序工具调用还保持状态连贯。误差传播复合：tool call 2的一个参数小错，会污染喂给call 3-7的状态。 ## 六、MCPMark多服务器协调：52.6%的真相 如果说BFCL测的是单模型函数调用精度，那**MCPMark测的是多服务器协调**——这正是企业生产Agent实际跑的形态：跨多个MCP服务器顺序调用、正确处理工具输出、不丢上下文地串链。MCPMark的结果远比BFCL残酷： 据agentmarketcap 2026年4月报告，MCPMark上表现最好的GPT-5 Medium也只拿到**52.6% pass@1 / 33.9% pass@4**；Claude Sonnet 4与o3都跌破**30% pass@1 / 15% pass@4**。注意Tau-bench式的pass@4会显著抬分（benchmarkingagents评测特别警告"pass@4 inflates scores"），所以pass@1才是真信号。 这些数字不只是模型的锅，更是**MCP协议本身在生产级可靠性上的错配**：MCP为可发现性和标准化而设计，不是为高风险可靠性而设计。结果回流层的烧窗+丢证+串链漂移，在多服务器场景被同时放大。 ## 七、工具结果契约：返回可操作元数据 把结果回流层当成工程契约来写，最关键的一条原则是：**截断必须返回模型能据以行动的元数据**。一个合规的工具结果，在截断时应附带： ``` { "truncated": true, "total_rows": 12400, "returned_rows": 40, "next_cursor": "eyJpZCI6...}" } ``` 配合**游标分页**（cursor-based）而非offset分页处理实时日志：首次调用返回摘要+`next_cursor`（当`has_more:true`）；暴露`tool_name_continue(cursor)`或同一工具的`page_token`参数；让模型**显式请求深度**——"取下一页"远好过自动内联十页。 对并行扇出（查十二个微服务），**本地摘要每个分片，再合并摘要**，而不是把十二棵完整JSON树塞进一个观测。下面是一个最小可用的观测中间件实现： ```python def observe(raw: dict, tool: str, budget: int) -> dict: proj = project(raw, allowlist=SCHEMA[tool].fields) # 服务端JSON投影 rows = sort_and_cap(proj["items"], key="severity", limit=50) text = encode(rows) if tok(text) > budget: # 超预算 text = head_tail(text, budget) # 头尾保留+省略标记 return {"summary": text, "truncated": True, "total_rows": proj["total"], "returned_rows": len(rows), "next_cursor": rows[-1]["id"]} return {"summary": text, "truncated": False} ``` ## 八、OpenAI strict模式：稳定性换灵活性 作为对照，OpenAI原生函数调用有最长的生产履历和最成熟的运维指引：函数定义活在API请求payload里，模型在判定该调用时返回结构化JSON。**strict模式是最重要的可靠性杠杆**——`strict:true`在每次调用强制schema合规，用一点灵活性换可预测输出。strict schema在首次请求后被缓存。 但strict模式只解决"参数填对"这一子能力，对结果回流层的烧窗、丢证、串链漂移**毫无帮助**。这是2026年最常见的认知误区：把"strict模式开了"等同于"工具使用生产就绪"。前者是输入侧契约，后者是输出回流侧工程，两者隔着整条结果回流层。 ## 结果回流层架构图 ```mermaid flowchart TD A[工具调用 decision] --> B[(外部工具 / MCP server)] B --> C{原始payload} C -->|180KB JSON / 全页HTML| D[观测中间件 observe] D --> E1[JSON投影 白名单字段] E1 --> E2[排序+行帽 50行] E2 --> E3{tok > budget?} E3 -->|否| F1[summary 原样] E3 -->|是| G1[头尾截断+省略标记] G1 --> G2{仍超预算?} G2 -->|是| H1[抽取跳: 错误码/5xx] H1 --> H2[小模型摘要 800token] H2 --> H3[结构化schema] G2 -->|否| F1 F1 --> I[truncated/total_rows/next_cursor 元数据] H3 --> I I --> J[(原始payload 落对象存储 observation_id)] I --> K[summary+指针 进会话历史] K --> L[主Agent 下一轮推理] J -.审计重放.-> L style C fill:#fde68a style D fill:#bfdbfe style I fill:#bbf7d0 style K fill:#fecaca ``` 图中黄色是危机源（巨大payload），蓝色是回流层工程（中间件），绿色是契约产物（可操作元数据），红色是真正进入会话历史的精简观测。**绝大多数生产事故发生在红绿之间——即"省预算"与"保证据"的取舍没做对。** ## 多轮串链误差传播时序 ```mermaid sequenceDiagram participant U as 用户 participant A as Agent participant T1 as 工具1 participant T2 as 工具2 participant T3 as 工具3 U->>A: 模糊请求 A->>T1: call(p1) T1-->>A: 180KB 结果回流(未压缩) Note over A: 上下文预算被吃→驱逐先前推理
needle落在4812行被截断 A->>T2: call(基于被截断的p2) ❌ 参数小错 T2-->>A: 部分结果 Note over A: turn-3结果要在turn-8用→虚构/丢失 A->>T3: call(污染状态) ❌❌ T3-->>A: 错误结果 A-->>U: 自信且错误的答案(41%) Note over A,T3: 误差传播复合:单步小错→链路放大 ``` 这正是Harbor案例与BFCL"人格分裂"的同一机理：**单步保真度高，但回流层没做工程化，误差在串链里指数放大。** ## 推荐方案 **按Agent形态选回流策略：** | 场景 | 推荐策略 | 关键动作 | |------|---------|---------| | 日志/监控oncall | 头尾截断+抽取摘要 | severity排序、行帽、占位blob、continue(cursor) | | 列表/搜索API | JSON投影+行帽 | 服务端白名单投影，永不无界 | | 长事件/多文件diff | 抽取+小模型摘要+schema | 800token上限，原文落对象存储 | | 多MCP服务器编排 | schema压缩+lazy loading | 先验pass@1，预算预扣71%风险 | | 多轮串链(>4跳) | 状态外置+检查点 | 每2跳持久化，防turn-N虚构 | **变现/训练营评估：** 结果回流层是2026年企业级Agent落地的最大认知盲区——大多数团队停在"strict模式开了=生产就绪"。一个聚焦"工具结果回流工程"的训练营（观测预算中间件、头尾截断、结构化摘要schema、游标分页、MCP schema压缩、多轮串链误差抑制）有清晰的差异化价值，因为它教的不是"怎么调API"，而是"怎么让Agent在被自己工具结果淹没后还活着"。 **一句结论：** 函数选择这道题已做完，结果回流这道题刚开始。2026年Agent的生死，不再取决于它选对哪把刀，而取决于**刀砍完之后，它能不能在飞溅的碎片里认出真相**。 ## 参考来源 1. [LLM Agent Tool Result Summarization and Truncation Explained](https://www.solana.garden/guides/llm-agent-tool-result-summarization-truncation-explained/) — Harbor DevOps事故案例、观测预算带位、头尾截断/JSON投影/摘要三式、游标分页与观测中间件工程实录 2. [BFCL V4: The Tool-Call Benchmark That Exposes What SWE-bench Can't See](https://agentmarketcap.ai/blog/2026/04/11/bfcl-v4-berkeley-function-calling-leaderboard-agentic-2026) — BFCL V4榜单(GLM-4.5 70.9%/Claude Opus 4.1 70.4%/GPT-5 59.2%)、22任务类别、单轮vs多轮"人格分裂"、记忆/动态决策/长程三挑战 3. [Agent Tool Calling Reliability 2026: MCP vs OpenAI vs Google Vertex](https://agentmarketcap.ai/blog/2026/04/09/agent-tool-calling-reliability-benchmark-mcp-openai-google-vertex) — MCPMark多服务器协调(GPT-5 Medium 52.6% pass@1)、3服务器烧71.5%窗口、Perplexity出走MCP、Scalekit 4-32x token实测 4. [Tool-Use Benchmarks 2026: BFCL, T-Eval, ToolBench, Tau-Bench Compared](https://benchmarkingagents.com/best-benchmarks-for-tool-use/) — 工具使用五子能力拆解、各benchmark覆盖面、pass@4抬分警告、"至少引两个benchmark"声明规范 5. [Berkeley Function Calling Leaderboard (BFCL)](https://gorilla.cs.berkeley.edu/leaderboard.html) — 函数调用事实标准榜单、AST评估方法、V1→V4进化谱系与多轮/并行/abstention任务定义 > [!tip] 51学通信知识星球 > **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 > **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 > **当前规模**：5200 篇主题 / 990 个回答，198 元/年。 > **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 > **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。