【Agent】模型一次返回多个工具调用，Harness 该如何执行？
英文标题：【Agent】模型一次返回多个工具调用，harness 该怎么执行？
在以大模型为核心的 Agent 架构中，LLM 单轮推理常会返回包含多个 Tool Use 的调用数组，Harness 执行层的编排调度直接决定了系统的响应效率与执行安全。目前业界主要存在全并行执行、严格串行执行以及基于读写属性与依赖关系的混合交叉调度三种方案。实践表明，对无副作用的只读检索进行并发执行可显著降低端到端延迟，而状态变更操作则须串行或加锁隔离以规避竞态冲突。对于开发者而言，构建具备元数据读写分离、局部容错及对齐 API 协议的 Harness 调度机制，是推动 Agent 从 Demo 走向高可用生产环境的关键基础设施。
中文
【Agent】模型一次返回多个工具调用，Harness 该如何执行？
在构建自主 Agent（智能体）系统的过程中，Agent Loop（智能体循环） 是整个架构的心脏。随着 OpenAI、Claude 等主流大模型对 Tool Calling（工具调用）能力的升级，模型在单次推理响应中返回多个工具调用请求（即 Tool Use 数组）已成为常态。
例如，OpenAI 的 parallel_tool_calls 特性或 Claude 的多 tool_use 内容块，允许模型同时发出多个检索请求或操作指令。面对模型输出的工具调用数组，负责驱动 Agent 运行的 Harness（运行底座 / 编排层） 究竟应该如何执行？是全部并行、全部串行，还是遵循特定规则交叉执行？
本文从执行机制、竞态安全、错误处理及架构实践四个维度，深入解析多工具调用的 Harness 执行策略。
一、模型返回多个 Tool Use 的本质
当用户提出一个复合任务（例如：“查询北京和上海今天的天气，并将结果汇总保存到 weather.txt”）时，LLM 通常会在单轮输出中生成如下所示的结构化调用：
[ {"id": "call_01", "name": "get_weather", "arguments": {"city": "Beijing"}}, {"id": "call_02", "name": "get_weather", "arguments": {"city": "Shanghai"}}, {"id": "call_03", "name": "write_file", "arguments": {"filename": "weather.txt", "content": "..."}} ]
对于 Harness 而言，处理这组调用的方式直接影响到 Agent 的执行耗时、上下文一致性以及系统安全性。
二、三种主流执行策略对比
1. 全并行执行（Parallel Execution）
- 机制：Harness 为数组中的每个工具调用创建独立的协程或线程（如 Python 中的
asyncio.gather），同时发起请求并等待全部完成。 - 适用场景：只读型工具（Read-Only），如并发网页检索、数据库查询、API 数据拉取。
- 优势：
- 显著降低延迟：总耗时取决于最慢单次调用的耗时（
max(t1, t2, ...)），而非时间总和。
- 显著降低延迟：总耗时取决于最慢单次调用的耗时（
- 风险与隐患：
- 竞态条件（Race Condition）：如果多个工具修改同一份全局状态或文件（如并发写同一文件），会导致数据污染。
- 隐式依赖破坏：模型若在
call_03中盲猜了call_01的输出，并发执行必然导致逻辑断层。
2. 全串行执行（Sequential Execution）
- 机制：按照模型返回数组的先后顺序，逐一同步执行每一个工具，前一个执行完成且拿到结果后再执行下一个。
- 适用场景：对状态一致性要求极高、存在潜在写入操作的敏感环境。
- 优势：
- 状态可控：每一步执行都建立在确定的系统状态上。
- 避免并发死锁与资源冲突。
- 局限：
- 端到端延迟过高，完全丧失了模型“一次性并发规划”带来的性能收益。
3. 基于读写规则与依赖图的混合调度（Hybrid / DAG Scheduling）
这是目前生产级 Agent 框架所采纳的最佳实践：
| 调度模式 | 串行执行 | 并行执行 | 混合依赖调度 (DAG) |
|---|---|---|---|
| 延迟表现 | 高（耗时累加） | 最优（取决于最慢任务） | 优（并发只读，隔离写入） |
| 安全性 / 一致性 | 极高 | 较低（易发状态竞争） | 高（规则化管控） |
| 实现复杂度 | 低 | 中等 | 较高 |
| 适用阶段 | 早期原型 / 单一写任务 | 纯检索型 RAG Agent | 生产级复杂任务 Agent |
三、生产级 Harness 的设计准则
1. 读写分离与元数据声明（Idempotency & Side-effects）
在注册工具时，Harness 应要求定义工具的副作用元数据：
python class Tool: name: str is_read_only: bool = True # 是否为无副作用的只读操作 concurrency_safe: bool = True # 是否支持并发
- 只读操作组：聚合并行执行。
- 写操作/副作用组：强制加排他锁或降级为串行执行。
2. 异常与局部失败处理（Partial Failure Handling）
当工具列表中某一个调用发生网络超时或参数错误时，Harness 不应直接抛出异常中断 Agent Loop，而应：
- 收集已成功的
tool_result。 - 将失败工具的错误信息格式化为包含具体
error_message的结果对象。 - 将所有工具调用的结果批量打包，回传给 LLM，由 LLM 自主决定是重试、换用工具还是向用户报错。
关键提示：OpenAI 与 Claude 的 API 均严格要求：一次返回的
tool_call_id必须在下一轮输入中提供对应的tool_result，漏传任何一个 ID 均会导致 API 报错。
四、总结与建议
在 Agent Harness 中处理模型返回的多个工具调用，既不能一味追求低延迟而“无脑并行”，也不能因噎废食而“全盘串行”。
建议开发者的演进路线：
- 第一阶段（快速起步）：默认对只读操作开启并发，一旦检测到包含副作用写工具，回退至串行。
- 第二阶段（企业级架构）：引入依赖图解析与沙箱隔离环境，支持细粒度超时控制与局部容错重试。
合理设计工具执行调度，不仅能大幅提升交互响应速度，更是构建生产级高鲁棒性 Agent 的核心基石。
English / 原文
Please wait...