一个用户请求命中两个函数时，系统如何安排调用？

核心回答

先判断这两个函数是都需要、互为替代，还是存在先后依赖，再安排调用。一次请求匹配到两个候选，不意味着两个都要执行；模型可以提出调用，真正的调度、参数校验和执行由宿主完成。

以LocalLife这类本地生活项目为背景，下面用假设的查询与预订能力说明调用安排。

三种主要情况

两个独立子需求可以并行。 用户要比较两家门店营业时间，两次只读查询对象明确、互不依赖时，可以并发执行，分别设置超时，再聚合结果。并行是否可用还取决于模型接口、工具实现和资源限制，不能只因一轮返回多个调用就认定都已同时完成。

后一个依赖前一个结果就串行。 用户要“查附近有空位的店并预订”，先查询候选与可用条件，取得真实门店ID和时段，再形成后续调用。前一步结果未知时不能为并行而臆造参数。是否能预订及必要信息仍由业务条件决定。

两个工具都是候选则先消歧。 同名门店搜索和精确ID查询可能都与问题相关，但不应为提高命中率把它们全部执行。根据对象、参数与适用范围选择；确实缺少关键条件时再询问，或先做必要的低成本查询。

宿主调度具体做什么

解析本轮完整的工具调用，为每个调用分配或保留调用ID，校验参数、身份和资源范围，建立依赖与执行状态。两个动作写同一对象时，要按业务一致性串行或加并发控制；各工具没有数据依赖，也可能存在副作用冲突。

执行结束后按调用ID把结果对应回消息，不能把A工具的数据放到B调用结果里。模型根据这些观察决定是否继续、修正参数或形成答案；多轮调用时它负责组织下一步，不负责直接执行后端函数。

失败和部分成功如何处理

两个查询一个失败，可以保留成功结果并明确不完整，必要时有限重试。若是“创建任务后发送通知”，创建成功但通知失败，状态应是任务存在、通知待处理，不能整体盲目重放造成重复任务。

具有副作用的调用要保留业务幂等标识与实际结果；工具返回超时不等于操作没发生。后续动作是否继续取决于依赖条件，而不是所有工具必须同成同败。

如何验证

用独立查询、输出依赖、相似候选、同资源写冲突、一个失败、连接超时和重复请求做测试，检查工具选择、顺序、结果配对与最终回答。技术亮点是把“选了哪些工具”与“按什么依赖安全执行”分开，让并行收益和一致性都有明确依据。

对应教程

参考资料