工具结果回流税：截断即丢证三栈实测

核心发现

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只测其中一片：

独立的benchmarkingagents评测直言："诚实的工具使用声明，至少要引两个benchmark"——BFCL高分的模型在Tau-Bench上仍可能崩，因为Tau-Bench额外要求策略合规与多轮对话。只贴一个分数，就是障眼法。

结果回流三式策略对比表

当工具返回的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），只把摘要+指针传进会话。这本质是把上下文压缩从会话中段挪到了工具边界。摘要的税是一跳延迟和细节损耗——但相比爆窗，这是生产里唯一可承受的权衡。

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快照：

两个发现刺眼：开源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树塞进一个观测。下面是一个最小可用的观测中间件实现：

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模式开了"等同于"工具使用生产就绪"。前者是输入侧契约，后者是输出回流侧工程，两者隔着整条结果回流层。

结果回流层架构图

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），蓝色是回流层工程（中间件），绿色是契约产物（可操作元数据），红色是真正进入会话历史的精简观测。绝大多数生产事故发生在红绿之间——即"省预算"与"保证据"的取舍没做对。

多轮串链误差传播时序

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: 上下文预算被吃→驱逐先前推理<br/>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形态选回流策略：

变现/训练营评估： 结果回流层是2026年企业级Agent落地的最大认知盲区——大多数团队停在"strict模式开了=生产就绪"。一个聚焦"工具结果回流工程"的训练营（观测预算中间件、头尾截断、结构化摘要schema、游标分页、MCP schema压缩、多轮串链误差抑制）有清晰的差异化价值，因为它教的不是"怎么调API"，而是"怎么让Agent在被自己工具结果淹没后还活着"。

一句结论： 函数选择这道题已做完，结果回流这道题刚开始。2026年Agent的生死，不再取决于它选对哪把刀，而取决于刀砍完之后，它能不能在飞溅的碎片里认出真相。

参考来源

1. LLM Agent Tool Result Summarization and Truncation Explained — Harbor DevOps事故案例、观测预算带位、头尾截断/JSON投影/摘要三式、游标分页与观测中间件工程实录
2. BFCL V4: The Tool-Call Benchmark That Exposes What SWE-bench Can't See — 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 — 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 — 工具使用五子能力拆解、各benchmark覆盖面、pass@4抬分警告、"至少引两个benchmark"声明规范
5. Berkeley Function Calling Leaderboard (BFCL) — 函数调用事实标准榜单、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 等场景全覆盖。