Conditional Parallel Tool Execution

当AI Agent在单个推理步骤中决定调用多个工具时，若严格按顺序执行这些工具，会导致严重延迟——尤其是当多数工具为只读类型、本可并发运行时。反之，如果不加以考量就并行执行所有工具，那么当部分工具存在状态修改操作（例如写入文件、更改系统设置）时，可能会引发竞态条件、数据损坏或不可预知的行为。

基于工具操作属性实现批量工具的条件执行策略

1. 工具分类：Agent可调用的每个工具必须声明自身类型：

   • 只读型：仅用于检查数据或系统状态，不执行任何修改操作（例如FileRead、GrepTool、GlobTool）。
   • 状态修改型（写入类）：会修改文件、系统状态或产生其他副作用（例如FileEditTool、FileWriteTool、执行特定命令的BashTool）。

2. 执行编排：当Agent请求执行一批工具时：

   • 编排器检查当前批次中所有工具的分类类型。
   • 若批次内所有工具均为只读型：并发执行所有工具，以最大化执行速度。
   • 若批次内存在任意状态修改型工具：按照Agent请求的顺序串行执行所有工具，以确保操作的安全性和可预测性。

3. 结果聚合：执行完成后，收集所有工具的执行结果。若工具采用并行执行，需确保结果按一致顺序返回给Agent（或用于后续处理），通常与Agent原始请求的顺序保持一致。

该策略兼顾了性能需求（通过安全操作的并行执行提升效率）与安全正确性需求（通过状态修改操作的串行执行保障可靠性）。

flowchart TD
    A[Agent 同时请求多个工具] --> B{检查批次内的工具类型}
    B --> C{所有工具均为只读型？}
    C -- 是 --> D[并发执行所有工具]
    C -- 否 --> E["按请求顺序串行执行所有工具"]
    D --> F[收集并排序结果]
    E --> F
    F --> G[向Agent返回聚合后的结果]

• 确保Agent工具集中的每个工具都有一个明确定义的属性，用以标识它是isReadOnly（只读）还是状态修改型工具。
• 当处理涉及多个工具的tool_use请求时，Agent的核心执行循环应实现上述描述的条件逻辑。
• 应为并行执行设置默认并发限制，以避免耗尽系统资源。
• 当工具以并行方式执行时，需先收集它们各自的结果（可能会乱序返回），然后按照Agent最初请求的顺序重新排序，再将结果传回LLM或用于后续处理。这能为LLM保持结果的可预测性。

• 优点：
  • 显著提升只读工具调用序列的性能。
  • 通过序列化状态修改操作保障安全性，避免竞态条件的发生。
  • 相较于针对工具执行的完整依赖关系图分析，实现难度更低，同时仍能带来可观收益。
  • 模型行为适配：部分模型（如Claude Sonnet 4.5）天然具备并行工具执行的行为特性，使得该模式更自然、高效。
• 缺点/注意事项：
  • 若一批工具中以只读操作为主，但序列早期包含单个状态修改操作，整个批次仍可能需串行执行，从而限制了潜在的并行化空间。
  • 该模式的有效性依赖于对工具的只读/状态修改属性的准确分类。分类错误的工具可能引发安全问题，或错失优化机会。
  • 上下文消耗：并行执行时，多个结果会同时返回，导致上下文窗口被更快耗尽，这可能会让上下文感知模型产生上下文焦虑。