01

60 秒回答模板

Agent 多工具调度的冲突检测，我会先把工具抽象成带元数据的能力：输入输出、读写资源、是否有副作用、幂等性、依赖关系、互斥组和优先级。冲突主要有四类：资源冲突，比如两个工具同时写同一对象；状态冲突，比如一个工具依赖另一个工具的结果却并行执行；语义冲突，比如两个工具目标相反；副作用冲突，比如重复下单、重复发消息。解决上分三层：执行前用依赖图和资源锁做静态预检查，把可并行和必须串行的工具拆开；执行中用超时、取消、优先级和仲裁器处理动态冲突；执行后用幂等键、补偿动作和审计日志保证可恢复。最终目标不是简单阻止并发，而是在正确性、效率和用户可解释之间做平衡。

考点 Agent plan 到 scheduler
难度 真实面经题
回答目标 设计工具冲突检测与仲裁
02

深入解析

01

先定义工具元数据

冲突检测不能只靠工具名称判断，必须给每个工具定义可调度元数据，包括读集合、写集合、权限等级、是否有外部副作用、是否幂等、是否可重试、依赖哪些前置结果。没有这些元数据，调度器只能让模型猜顺序，稳定性很差。

02

冲突类型要分清

常见冲突包括资源冲突、依赖冲突、语义冲突和副作用冲突。资源冲突是多个工具读写同一对象；依赖冲突是 B 需要 A 的输出却提前执行；语义冲突是一个工具创建、另一个工具删除；副作用冲突是重复触发外部不可逆动作。不同冲突的处理方式不同。

03

执行前做计划校验

Agent 生成工具计划后，调度器应构建依赖图，检查是否存在环、缺失输入、互斥工具并发、权限不足和写资源冲突。能并行的只读工具可以并发；有写冲突或依赖关系的工具要串行；高风险工具要等待确认或进入沙箱。

04

执行中做动态仲裁

真实执行时还会出现动态冲突，比如工具返回的数据改变了后续计划，某个工具超时，或用户中途改变目标。调度器需要支持取消、重排、优先级、超时预算和部分结果继续执行。对同一资源的写操作可以使用锁、版本号或乐观并发控制。

05

执行后要有幂等和补偿

对于有副作用的工具，调度器要用幂等键避免重复执行，用事务或补偿动作处理半成功状态。比如一个步骤成功、后续失败时，不能简单让模型重新跑全流程，而要识别哪些动作已经生效，哪些可以重试，哪些必须人工确认。

06

用审计和评测持续改进

冲突检测不是一次性规则。应记录工具计划、冲突判定、仲裁决策、执行结果和用户反馈，沉淀成回归用例。面试回答中如果能补上可观测性和 badcase 复盘，会比只说加锁更完整。

03

易错点

  • 只回答“加锁”或“排队”，没有区分不同冲突类型。
  • 让 LLM 自己决定所有执行顺序，忽略调度器的确定性校验。
  • 没有考虑工具副作用，重复执行可能造成真实业务影响。
  • 只讲执行前检测，不讲执行中目标变化、超时和取消。
  • 没有幂等和补偿设计，半成功状态无法恢复。
  • 把旧的测试用例设计问题套过来，没回答 Agent 多工具调度本身。
04

面试官追问

所有工具都串行执行能不能避免冲突？

可以减少冲突，但会牺牲效率，而且不能解决语义冲突和副作用重复。更好的方式是基于读写资源和依赖关系决定哪些并行、哪些串行。

如何处理模型生成了冲突工具计划？

调度器应拒绝或改写计划，并把冲突原因反馈给模型重新规划；高风险场景可以要求用户确认，而不是直接执行。

资源冲突用锁就够了吗？

锁只能处理一部分并发写问题，还需要幂等、版本校验、补偿和审计。语义冲突和依赖冲突也不能只靠锁解决。

怎么判断一个工具可不可以并行？

看它是否只读、是否依赖其他工具输出、是否访问同一写资源、是否有不可逆副作用，以及失败后是否能独立重试。

冲突检测规则从哪里来？

一部分来自工具注册时的元数据，一部分来自业务资源模型和权限模型，后续再用线上 badcase 和人工 review 更新规则。