不过，

：那次凌晨的退款事故

一个客户支持 Agent 在生产跑了三个月。eval 分数不错，trace 看起来干净。接下来某天一位使用者的退款被处理了三次。五次，

至于排查后发现，Agent 在调用 process_refund 时遇到网络超时框架层重试了一次Agent 自己也重试了一次。没有幂等键，每次重试都变成了真实退款。其实，

这不是模型幻觉。这是 LLM Tool Calling 的工程问题：当你把工具调用当成普通函数。而不是有副作用的分布式操作时分布式程序几十年踩过的坑，全都在你的 Agent 里重新踩一遍。

这篇文章聚焦于并发场景下的五个主要生产陷阱，还有对应的工程解法。老实说，每个陷阱都附可运行代码。

从陷阱①来看，你以为并发在跑。其实还是串行

问题

模型确实在一次响应里返回了多个 tool_use block，但你的执行层还是一个个顺序调用。

这是最常见的「并发调整」误区！ LLMCompiler 的 benchmark 显示，正确实现并发调用可以带来 .4x~.7x 的延迟降低。但如果执行层没跟上，这个收益完全消失！

根本原因

模型「请求」并发，框架决定是否真正并发执行！很多 LangChain 的早期版本默认串行处理 tool_calls

# ❌ 串行执行——latency = sum
for tool_call in message.tool_calls:
result = tool_executor.invoke
results.append

正确实现

import asyncio
from typing import Any
async def execute_tool_calls_parallel(
tool_calls: list,tool_registry: dict
) -> list:
"""
并发执行所有工具调用，latency = max
"""
async def run_single -> dict:
tool_fn = tool_registry]
至于try。result = await asyncio.to_thread
return {
"tool_use_id": tc,"content": str,"is_error": False
}
except Exception as e:
return {
"tool_use_id": tc,"content": str,"is_error": True
}
tasks =
return await asyncio.gar
# 调用方
tool_results = await execute_tool_calls_parallel(
message.tool_calls,tool_registry={"search_web": search_web,"query_db": query_db}
)

注意事项

部分海外大模型厂商的 API 提供 parallel_tool_calls=true,默认为 true,但某些推理系列模型会直接返回 错误 ,如果你显式设置这个参数！国内主流模型在多 tool_call 响应格式上一样存在差异。怎么说呢，路由多个模型时执行层必须能处理多 tool_call 响应。无论你有没有主动开启并发！老实说，

从陷阱②来看。并发暴露了你从不知道存在的顺序依赖

串行执行天然强制执行了工具之间的顺序.切换到并发后,原来隐藏的依赖立刻破坏程序!

再看顺序执行时，. create_order
→ order_id = "ord_789"
. update_inventory
→ OK
. send_confirmation
→ OK
并发执行时：
跑
→ update_inventory 和 send_confirmation 在 order_id 存在前就执行
→ 静默失败或者引用到过期数据!实际库存应该是,结果是 .超卖了件。

检测方法

def audit_tool_dependencies -> dict:
"""
检测工具调用之间是否存在数据依赖.
规则的观点是，如果tool B 的参数中引用了tool A 输出字段名,则B依赖A.
"""
output_fields: dict = {} # field_name -> tool_name
dependencies: dict] = {}
 #简化版通过schema注解声明输出字段
for tc in tool_calls:
schema = TOOL_SCHEMAS.get
#检查本工具输入是否依赖前一个工具输出
deps=
for param,value in tc.get.items:
if isinstance(value,str) and value.startswith:
source_tool=value.split
deps.append
dependencies]=deps
#注册本工具输出字段名称及来源tool名称
for out_field in schema.get:
output_fields=tc


return dependencies

def buildexecutionplan-

stages :list]=
completed:set=set
remaining=list

while remaining:
ready=

if not ready:
raise ValueError

stages.append
completed.update
remaining=

return stages


html

工程清单的观点是。上线前必过检查项

根据以上5大陷阱关键验收标准:



层级
主要检查项
潜在风险




基础能力
框架真正实现异步I/O非假装
性能红利被吃掉



工具Schema完善注解输入/输出约束
隐含耦合无人知晓


冗余防护
全链路幂等保证机制覆盖
副作用翻倍



写操作资源加锁防竞态
数据不一致


容错机制
Saga补偿或事务支持
中间态无人管理



消息队列异步通知+补偿计划
故障导致业务断裂


监控程序
全流程埋点记录
上下文追踪困难




性能vs稳定性权衡框架

ini
IF 工具均为读操作 =>
ELSE IF 写操作独立 =>
ELSE IF 有顺序约束 =>
ELSE IF 高价值交易 => ENDIF

参考资源 ### - - LLMCompiler性能白皮书 - 分布式理论《Designing Data Intensive》