并行工具调用什么时候用？工具结果太长塞爆上下文怎么办？
谁在问：工程向二面；做过延迟或成本优化的面试官爱问，用来看你有没有算过上下文的账
口语化问法
- 并行工具调用你们用了吗？什么场景开、什么场景不敢开？
- 一个检索工具返回三万字，你怎么处理？
- 跑到第七八轮上下文就满了，你会先砍哪块？
考察意图
这题几乎不可能背出来，因为它要求你算过上下文这本账。面试官在看三件事：
- 知不知道并行省的是什么、不省的是什么。 以为并行=省钱的人，没算过 token；知道它省的是往返轮次、代价是全都得付费的人，是自己压过测的。
- 有没有把工具结果当"上下文的永久居民"。 结果一旦进历史，后面每一轮都在为它重复付费，还挤占模型的注意力。意识不到这点的人，做不了成本治理。
- 砍上下文时知不知道什么必须保真。 会砍是本事，知道砍错会丢什么才是经验。
参考答案
60 分答案（及格线）
并行：模型一轮里可以返回多个 tool_call，我并发执行完，把每个结果按 id 对应回灌，再请求一次。适合彼此独立、只读、结果不大的调用，比如同时查天气、日历、订单状态。不敢开的场景是：有写副作用的（模型可能一口气发三个创建请求）、后一个的参数依赖前一个的结果、以及结果特别大的。
结果太长：四层手段——工具侧只返回必要字段（别把数据库行原样吐出来）；分页只给 top-k 加上总数提示；太长就先摘要；再长就返回一个引用句柄，模型需要细节再来取。另外历史里的老结果也要清理，不然跑到第七八轮时上下文全是几轮前没用的检索片段。
90 分答案（有生产经验的回答）
补三层，重点在账和取舍。
1. 并行的账要分开算。 并行不减少工具结果的 token，它减少的是轮次——三个工具串行要三次模型请求，每次都重发一遍完整历史；并行只要一次。所以判断规则是：
- 历史已经很长、工具结果都不大 → 并行省钱又省时间（少了两次全量重发）；
- 工具结果很大、或者串行时第一个成功就能早停 → 串行更省（并行必然把三份大结果全塞进上下文，且不能跳过）。
时延上并行一定占优（墙上时间取最慢那个而不是求和），但要配并发上限，否则模型一轮发八个调用能把下游打爆。
2. 三段式看并行工具调用。 解决的是多轮往返带来的时延和重发开销；代价是多份结果同时涌入上下文、部分失败的处理复杂化、下游并发压力、失去早停机会；不该用在有写副作用（重复执行风险）、存在参数依赖、返回体大、或工具间成功率差异大需要按序决策的场景。
3. 上下文预算要显式管理，不能等它满。 我的做法是给工具结果单列预算（比如不超过模型窗口的四分之一），超了按优先级处理：
| 手段 | 解决什么 | 代价 | 什么时候不该用 |
|---|---|---|---|
| 字段裁剪 / 分页 | 从源头减量，最便宜 | 需要按场景定制工具返回 | 几乎总该做 |
| 小模型摘要 | 大幅压缩自然语言长文 | 多一次调用与延迟；可能丢细节 | 精确数值、条款原文、代码——摘要会改写关键字符 |
| 句柄（handle） | 把大结果留在上下文之外，按需取片段 | 多一跳；模型可能不去取 | 结果本来就短，或只用一次 |
| 历史折叠 | 治理累积，越到后期越关键 | 折叠丢了关键约束会让 Agent 忘记已确认的事 | 结论性信息（见追问 4） |
句柄这套，正好对上 MCP 2026-07-28 规范转无状态后的业务状态新范式：状态不放在协议会话里，由工具返回显式 handle，后续调用凭 handle 取。截至 2026-08 这已经是长结果处理的推荐写法。
4. 一个数字直觉（面试很加分）。 一份 3 万 token 的检索结果，如果后面还要跑 10 轮，它会被重发 10 次——30 万 token 的复利开销，还没算它挤占注意力导致的决策质量下降（长上下文里的 context rot，见 Q1-12）。所以"这次先塞进去，反正窗口够大"是最贵的一句话。
追问链
并行工具调用能省钱吗？
期望要拆开看。省的是轮次：串行 N 个工具就要 N 次请求、每次重发完整历史，越长越贵；不省的是结果 token，反可能更多：串行能看第一个结果决定还查不查（早停），并行三份全进上下文。结论条件式：历史长 + 结果小 → 并行省；结果大 + 有早停机会 → 串行省。时延上并行几乎总赢信号给出条件式结论并解释「早停机会被牺牲」→ 算过账；答「并行当然更省」或「只省时间不省钱」这种一刀切 → 没实测过模型一轮发了八个工具调用，把下游打爆了，怎么办？
期望多层限流：客户端并发上限（最多 3 个，其余排队）→ 按工具分组（慢工具或脆弱下游设更低并发）→ 整轮超时预算（不是单工具超时，总时间到就把未完成的以「超时，未获取」回灌）→ 下游熔断后回可操作说明让模型换路径。源头：八连发多半是粒度太细，八次查询本该是一个批量工具。重试要幂等信号提到「整轮超时预算」和「粒度太细才导致八连发」→ 处理过线上；只答「加个并发限制」→ 通用工程直觉，没针对 Agent 想过结果 3 万 token，你会摘要还是句柄？各自代价是什么？
期望按下一步用途选：整体判断/归纳 → 摘要（要带任务上下文，让小模型知道留什么）；精确引用几条 → 句柄 + 索引（返条目和 id，点名取）。摘要代价：多一次调用 + 信息损失，数值、条款、代码、日志上危险，只能裁剪。句柄代价：多一跳延迟，模型可能不去取。摘要后仍占上下文，非免罪符信号按「下一步用途」而不是按长度选、点出摘要在精确信息上的危险 → 做过取舍；答「都行，看情况」说不出情况 → 没落地跑到第十轮，历史里堆了七八条老工具结果，怎么清？清错会怎样？
期望折叠而非删除：结果要与tool_call配对，直接删破坏结构，换成一行摘要（「已查 3 月订单，命中 12 条」）。先折老的、被覆盖的、过程性的。保真四类：目标与约束（预算、截止）、已确认参数（3 月不是 4 月）、已执行写操作（防重复下单）、待办。清错即 Agent「失忆」信号说出「折叠而非删除，否则 id 配对被破坏」这种实现级细节并列出必须保真的类别 → 手写过上下文管理；只答「做个摘要压缩」→ 停在概念P95时延从 8 秒涨到 25 秒，要求压回 10 秒以内且准确率不能降，你怎么做？期望拆构成：时延 = 轮次 ×（排队 +prefill+ 生成）+ 工具 →trace拉轮次、单轮、工具三条耗时分布，隐藏项上下文变长拖慢 prefill → 按代价：①串行改并行 ②裁结果折叠历史 ③吃前缀缓存 ④多步固化成工具 ⑤慢工具异步 ⑥意图路由；①~④ 不损准确率，⑤⑥ 会 → 压不到分档：80% 进 6 秒，20% 给流式进度，复测P95信号先拆构成、想到「上下文变长拖慢 prefill」、按是否损伤准确率分组 → 做过真优化；上来「换更快模型」或「减 max_steps」→ 没分析能力
评分要点
- 说清并行的适用条件：独立、只读、结果不大
- 说清不该并行的场景：写副作用、参数依赖、结果过大、需要早停
- 知道并行省的是轮次（重发历史）而非结果 token
- 意识到工具结果是上下文的长期居民，成本是复利的
- 给出结果治理的分层手段：字段裁剪 → 分页 → 摘要 → 句柄
- 知道摘要在精确数值/条款/代码上不安全
- 提到历史折叠及「折叠而非删除」的实现约束
- 加分：知道 MCP 2026-07 无状态改版后用工具返回 handle 承载业务状态
- 加分：能把上下文膨胀与决策质量下降（context rot）联系起来