面试官问：“你的 Agent 平均每轮调几个工具？“

面试官问“你的 Agent 平均每轮调几个工具”简历“3 年后端开发主导公司 AI Agent 平台建设负责多工具编排与端到端延迟优化。”看到简历上延迟优化这几个字我问了个当场就能验证的问题你的 Agent 平均每轮调用几个工具候选人想了几秒说没专门统计过一般是一个复杂任务可能两三个。前半句是实话后半句是猜的。这个数字就躺在他的调用日志里五行代码能算出来。绝大多数自研 Agent 算出来的结果是 1.0不多不少的 1.0意味着这套系统从上线到现在从来没有在一轮里同时调起过两个工具。而它用的模型出厂设置本来就会并行。Agent 为什么慢多数团队的答案是模型推理慢、工具接口慢。今天这场面试聊的是第三种可能慢的是自己写的那段拼装消息的代码。Round 1这个数你算过吗面试官“你的 Agent 平均每轮调用几个工具给个数。”候选人“这个……应该是一个吧大部分任务一个工具就够了复杂的会多调几次。”正解这个指标在 Anthropic 官方文档里有正式名字average tools per message判断标准只有一条大于 1.0 说明并行生效等于 1.0 说明一次都没并行过。算法很直白。遍历收到的所有 assistant message数出其中含 tool_use block 的消息条数作分母数出 tool_use block 的总数作分子相除。日志里已经存着的响应对象直接就能跑不用改任何线上代码tool_call_messages [msg for msg in messages if any(block.type “tool_use” for block in msg.content)]total_tool_calls sum(len([block for block in msg.content if block.type “tool_use”])for msg in tool_call_messages)avg total_tool_calls / len(tool_call_messages) if tool_call_messages else 0.0print(fAverage tools per message: {avg})大于 1.0 才说明并行在工作来源Anthropic 官方文档 Parallel tool use 页2026-08 访问跑之前先猜一个数跑完再看差多少。关键在于 1.0 这个值本身就不正常。Claude 4 及以后的模型在请求受益于多个工具时默认就会并行调用OpenAI 侧的并行 function calling 在 GPT-5 及以后同样支持。什么都不配置模型出厂自带这个能力。日志里出现一个精确的 1.0说明这条链路上有东西在把它压回去而且压得非常彻底几千次调用里一次例外都没有。这跟我的任务本来就只需要一个工具是两回事。用户说帮我看看这三个配置文件、端口是不是撞了这是三个彼此独立、参数在提问那一刻就已经确定的读操作模型完全有能力一次吐出三个 tool_use block。真实的 Agent 日志里这类请求占比通常不低。如果它们也是 1.0问题就不在任务复杂度上。先把这个数算出来。后面几轮讲的所有事情都是围绕怎么让它从 1.0 涨上去。要点速记指标名 average tools per messagetool_use block 总数 ÷ 含 tool_use 的 assistant message 条数大于 1.0 并行生效等于 1.0 说明一次都没并行过Claude 4 及以后默认并行GPT-5 及以后支持并行 function calling都不需要额外开关五行代码在现有日志上就能算不用改线上代码Round 2那三个工具是谁在并发跑面试官“假设模型一次返回了 3 个 tool_use block这 3 个工具是谁在并发执行”候选人“SDK 吧API 既然一次返回多个调用应该是框架帮我并发跑掉再把结果一起送回去。”正解没有人帮你跑。Anthropic 文档在这点上写得毫不含糊How you run those calls is your decisionThe API doesnt prescribe an execution order。模型给你的只是一份清单谁先谁后、并发还是串行全在你自己的 runtime 里。并行工具调用这个词其实盖着两件独立的事任何一件掉链子端到端都是串行。生成侧的并行模型在一次前向生成里连续产出多个 tool_use block装在同一个stop_reason: tool_use的响应里。这一步由模型决定你能影响但替它做不了主。执行侧的并行拿到这 3 个 block 之后是 for 循环挨个 await还是asyncio.gather一把梭。这一步纯粹是你的代码。大量团队卡在后面这层。模型老老实实吐了 3 个 block业务代码一个 for 循环挨个跑三个各花 800ms 的接口硬生生跑成 2.4 秒。日志上看 average tools per message 是 3.0体感却和串行没差别。两层都通了再看并行到底省下什么。墙钟时间是最直观的那部分3 个 800ms 的独立接口串行 2.4 秒并行 800ms。但这只是表层。真正的大头是往返次数。串行调 3 个工具意味着 3 次独立的 LLM 请求第一次让模型决定调 A拿到结果后第二次让它决定调 B第三次调 C最后还要一次生成最终回答整整 4 次往返。而每一次往返都要把 system prompt、全部工具定义、到目前为止的完整对话历史重新发一遍。并行的话一次请求吐出 3 个调用一次请求消化 3 个结果2 次往返收工。把这笔账按 token 算一遍。设固定前缀system 工具定义 已有历史20K token每个 tool_use block 约 50 token每个工具返回约 800 tokenLLM 请求次数累计 input token串行 3 个工具485,100并行 3 个工具242,550按上述假设推算非实测数据input token 砍掉一半。按 claude-opus-5 输入 $5/M 计Anthropic 定价该型号 2026-07-24 发布单次任务从 $0.43 降到 $0.21。工具数量越多两条曲线岔得越开因为串行的往返次数随工具数线性增长而每次往返都在重发那个越来越长的前缀。要点速记API 不规定执行顺序并发与否由你的 runtime 决定SDK 不会替你 gather并行分两层模型愿不愿意一次吐多个 block你的代码敢不敢同时跑3 个工具串行需要 4 次 LLM 往返并行只要 2 次20K 前缀下 input token 从 85K 降到 42Kopus-5 单价 $5/M 时单次省约 $0.21Round 3avg 就是卡在 1.0你怎么排查面试官“你回去跑了脚本avg 精确等于 1.0。现在让你排查第一步做什么”候选人“那我在 system prompt 里加一句要求它尽量并行调用工具加完再看效果。”正解第一步该看的不是 prompt是上一轮把 tool_result 送回去时的消息结构。这是整件事里最反直觉的地方你的历史消息本身正在充当少样本示例一轮一轮教模型不要并行。Anthropic 把这条列为并行失效的头号原因文档里用的动词是 teach说错误的 tool_result 格式会teach Claude to avoid parallel calls。机制不复杂。模型生成下一个 tool_use block 时看到的是完整对话历史。假如你把两个工具结果拆成两条独立的 user message 发回去[ {role: assistant, content: [tool_use_1, tool_use_2]}, {role: user, content: [tool_result_1]}, {role: user, content: [tool_result_2]} ]历史里就留下了一个结构清晰的范例一次调用配一个结果一轮只办一件事。模型下一轮生成时会照着历史里已有的样式来于是只吐一个 block。你的代码看到只有一个 block自然又只回一条 user message历史里再添一条串行样本。这是个自我强化的负反馈环。Agent 跑得越久历史里串行的示范越密模型越不并行avg 在 1.0 上钉得越死。此时加 prompt 去扭转等于用一句指令对抗几十条现成的反面示例效果时有时无而且随着会话变长越来越弱。想快速确认是不是这个问题在消息数组上数一下相邻的 user message 就行# 相邻两条都是 user说明一批 tool_result 被拆开发了 splits sum( 1 for a, b in zip(messages, messages[1:]) if a[role] user and b[role] user ) print(f被拆开的 tool_result 批次: {splits})结果大于 0问题基本就在这里。有些框架还会在每条 tool_result 后面自动补一条提示性的 user message这种同样算拆开而且更隐蔽。正确写法是所有结果合并进同一条 user message靠tool_use_id做配对[ {role: assistant, content: [tool_use_1, tool_use_2]}, {role: user, content: [tool_result_1, tool_result_2]} ]还有一条顺序规则容易踩。这条 user message 里所有 tool_result block 必须排在任何 text block 前面。想在结果后面追一句接下来该做什么是允许的追在前面直接 400。官方给的报错特征是tool_use ids were found without tool_result blocks immediately after日志里搜到这句就去查 content 数组的元素顺序。排查顺序很明确先确认消息结构再动 prompt。结构不修prompt 加得再重也是在跟历史打架。要点速记并行失效的头号原因是 tool_result 回传格式prompt 强度排在后面N 个结果拆成 N 条 user message等于给模型做了 N 次串行示范正确做法所有 tool_result 合并进同一条 user message用 tool_use_id 配对同一条消息里 tool_result 必须排在 text 之前反了报 400修复顺序先结构后 prompt结构不修 prompt 白加Round 4格式改完了还差什么面试官“消息格式改对了接下来还要做什么这套东西你线上跑过吗”候选人“改完格式再加个提示词执行那边用 asyncio.gather 包一下应该就可以了。”正解方向没错但这三步改完直接上线大概率要在生产环境出事。打开的部分确实是三件事。消息结构是前提Round 3 已经说过。第二件是 system prompt官方给了两个版本弱版一句话For maximum efficiency, whenever you need to perform multiple independent operations, invoke all relevant tools simultaneously rather than sequentially.默认效果不够时换强版包在一对名为use_parallel_tool_calls的 XML 标签里额外给了具体例子读 3 个文件就发 3 个并行调用跑多个只读命令一律并行。第三件是执行层的asyncio.gather或Promise.all。出事的地方在第三件。并行安全的前提是这批调用彼此独立而模型判断独立性的能力并不可靠。官方文档专门开了一节讲批次里的调用看起来互相依赖该怎么办给的缓解 prompt 是Only batch tool calls that are independent of each other。需要为它单独写一节说明这情况够常见。真正会出事故的是有副作用的工具。三个只读接口并发跑错了顶多重试一次三个写操作乱序执行就是数据事故。可行的做法是给每个工具打标只读的进并发池带写、带事务、带外部状态的一律退回串行执行。这个判断放在你的代码里别交给模型。失败处理是第二个坑而且是硬性 API 约束。你串行跑这批调用第二个失败了第三个决定不跑那么第三个也必须回一个 tool_result带上is_error: true和一句说明{ type: tool_result, tool_use_id: toolu_02, is_error: true, content: Not executed: the preceding write_file call failed. }少回一个整个请求 400。规则是每个 tool_use block 都要有对应的 tool_result一个都不能缺。第三件要提前想清楚的是上下文膨胀速度。并行把 N 个工具的返回值一次性灌进上下文而串行至少还留有在中间做裁剪的机会。Anthropic 在工程博客里提到Claude Code 默认把单个工具响应限制在 25,000 token同一篇里举的例子某个 Slack 接口的详细返回占 206 token精简版只要 72 token差了将近三倍。并发度乘上这个差值就是上下文被烧掉的速度。工具返回值的分页、字段过滤、截断该在开并行之前做完。最后把成本这笔账修正一下。Round 2 算出的省一半 input token前提是没开 prompt cache。开了缓存之后串行多出来的那几次往返里重发的前缀绝大部分会命中而缓存读取按基础 input 价的 0.1 倍计费Anthropic 定价文档5 分钟缓存写入 1.25 倍1 小时写入 2 倍读取 0.1 倍。同样那笔账按缓存价重算2 倍的差距会收窄到几成之内。具体收窄到多少取决于缓存断点打在哪、首轮前缀是否已经命中按不同假设算下来大致落在 15% 到 60% 这个区间。并行能稳定兑现的收益是墙钟时间和往返次数这两项跟缓存开不开没有关系。省钱那部分会被缓存吃掉一大截拿能省一半 token 成本去立项上线后大概率对不上账。顺带一个高频踩坑想关掉并行时disable_parallel_tool_use藏在tool_choice对象里面不在请求顶层。tool_choice{type: auto, disable_parallel_tool_use: True}写在顶层不会报错也不会生效。这个字段的语义还随tool_choice类型变化auto下是至多调一个工具也可以一个都不调any或tool下是恰好调一个。OpenAI 侧对应参数叫parallel_tool_calls置为 false 时保证一轮里零个或一个工具调用。要点速记三步修消息结构 → 加 system prompt → 执行层 gather缺第一步后两步无效只读工具进并发池带写/带事务的强制串行独立性判断别交给模型没执行的调用也要回 tool_result is_error: true少一个整个请求 400Claude Code 默认限制单个工具响应 25,000 token并发度会成倍加快上下文消耗缓存读取是基础 input 价的 0.1 倍开 cache 后并行的成本优势从 2 倍收窄到 15%-60%随缓存断点而变disable_parallel_tool_use 在 tool_choice 对象内写在顶层静默失效Round 5什么时候你会主动把并行关掉面试官“你讲了一堆怎么打开。反过来什么情况下你会主动关掉”候选人“有副作用的工具吧写操作不能并发。其他的……应该是越并行越好”正解副作用只是最表层那条。真正决定能不能并行的是参数在这一刻是否已知。模型一次吐出 3 个 tool_use block 时这 3 组参数是在同一次生成里连续写完的。第 2 个调用的参数是在完全看不到第 1 个调用返回值的情况下填出来的。读这三个文件能并行三个路径在用户提问时就写死了。而先列出目录再读里面最大的那个文件没法并行第二步的文件名要等第一步返回才知道。模型如果被 prompt 逼着并行它会做的事情是猜一个文件名填进去然后你在 tool_result 里收到一个 file not found白烧一轮。这条边界比工具有没有副作用更常被忽略。两个纯只读的接口一样可能因为参数依赖而不该并行。第二种该关的是逐步收敛的探索型任务。Agent 做故障排查、代码定位这类工作时每一步的观察结果都会改变下一步该看哪里。并行等于强迫它在信息最少的时刻一次性把后面几步全押出去押错就是成倍的无效 token。这类任务串行反而更省也更准。第三种是模型侧的已知缺陷。OpenAI 文档点名过某个旧版快照在开启并行时会重复调用同一个工具建议对该版本直接关闭微调模型还有个额外约束一轮里调多个函数时 strict 模式对这些调用会失效schema 校验的保证就没了。上生产前值得对实际在用的型号跑一遍验证。最后一条跟缓存有关。改动tool_choice参数本身会让 messages 层的缓存失效tools 和 system 层保留Anthropic 缓存失效规则文档。别设计成按请求动态开关并行每切换一次就要付一遍 message 缓存重建的钱。要么全局固定要么按会话固定。把这几条判据摊平成一张表落到代码里就是给工具打标时的依据场景并行判据读 3 个已知路径的文件✅参数在提问那一刻已确定并发查 3 个只读 API✅参数独立失败可直接重试先 list 目录再读最大的文件❌第二步参数依赖第一步的返回批量写库 / 转账 / 发通知❌有副作用乱序即事故故障排查、代码定位❌每步观察都会改变下一步方向微调模型一轮调多个函数先验证strict 模式对这批调用失效要点速记能否并行的判据是参数此刻是否已知工具有无副作用只是其中一条只读工具也可能因参数依赖而不该并行比如先 list 后 read探索型任务故障排查、代码定位串行更省并行是在信息最少时下注微调模型一轮调多个函数时 strict 模式失效schema 保证随之消失动态改 tool_choice 会失效 messages 层缓存并行开关按会话固定面试官点评这位候选人对 Agent 的理解停在模型加工具加循环这个层面缺的是对循环里每一条消息如何反过来影响下一次生成的感知。他把 Agent 慢归因到模型和接口唯独没想过自己那段拼装 message 的代码也是变量。三条建议今晚就把 average tools per message 加进监控跟 P99 延迟放在一张图上看。这个数从 1.0 涨到 2.0收益通常比换个更快的模型更直接。把 tool_result 的拼装逻辑翻出来看一眼确认 N 个结果合并在同一条 user message 里且排在所有 text block 之前。这是一个函数级的改动。给工具加只读标记只读的才进并发池。这件事的顺序是开并行之前做完。写 Agent 的人大多在优化模型选型、prompt 措辞、工具设计很少有人回头看自己送进去的那份消息历史长什么样。而模型每一轮都在读它并且照着它的样子作答。调了半年 Agent 延迟最后发现拖慢它的是自己写的那个 for 循环。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】