Agent 工作流与工具调用

面试回答

这条工作流从理解用户目标开始，先补齐必要条件，再通过业务工具查询当前数据、通过知识工具取得专业资料，生成可检查的草案。后端先校验权限、资源和业务约束，把草案及依据展示给用户，人工确认后才进入实际执行。

比如用户要求安排下周作业并避开维修设备，Agent 先查询任务要求、设备、人员和已有安排，再准备调度方案。确认期间资源可能变化，所以执行前还会复核当前状态和冲突，通过业务 Service 写入，并记录结果与审计。模型负责理解和组织步骤，设备能否调度、用户是否有权操作由后端确定。

面试回答

我按需要取得的信息选择工具。作业调度查询任务、设备、人员和已有安排；维保建议结合设备档案、维修记录与手册检索；经营分析从业务记录中取得指标；知识问答则检索说明书、规范和资料页，保留引用。

动态状态通过业务工具查询，维修方法这类专业知识通过检索取得，不能把历史对话里的设备状态当成当前事实。金额、工时等指标由确定性的业务查询和计算产生，模型负责组织方案或解释结果，避免它根据零散记录自行估算。各场景最终返回草案、指标或带证据的答案，写操作再经过确认和业务校验。

面试回答

我把查询资产、查询任务、检查冲突、检索维修资料和准备调度草案等能力封装成工具，明确名称、说明、参数 Schema、读写属性、返回结构和幂等要求。执行器统一处理参数、权限、超时和预算，实际业务仍调用已有 Service。

这样可以复用普通接口的组织范围、状态流转和审计规则。比如创建维保工单，需要校验资产、用户权限和必填信息，不能让模型拼一条 SQL 就插入表。模型提出工具和参数，后端决定是否合法并执行；写操作还要关联用户确认和稳定执行标识，避免一次重试产生多条业务记录。

面试回答

后端根据草案中的设备、执行人和时间范围做确定性检查。先确认资源存在且在授权范围内，再看设备当前状态、维保占用、已有任务，以及人员和设备在相关时段是否冲突，同时核对作业要求和候选资源是否匹配。

失败时返回具体资源、冲突记录和原因，Agent 据此换设备、调时间或请求补齐条件。用户确认期间其他请求可能改变安排，所以真正写入前还要再次复核，并在业务写入环节控制并发，避免两个请求都查到空闲后同时占用。模型生成方案本身不能代表资源已经被预留。

面试回答

用户确认的是一份内容确定的草案，里面明确设备、操作、时间和关键参数。后端把真实确认动作关联到具体草案版本，执行也使用这个版本；设备、时间或其他关键参数改动后，要重新展示并确认，不能沿用旧确认执行新方案。

确认表示用户接受这份安排，权限和审批仍按业务规则检查。执行时会重新核对成员关系、资源状态和任务冲突，模型生成一句“用户已同意”不能替代确认记录。这样既知道用户同意了什么，也能保证实际执行内容与确认内容一致。

面试回答

每个业务动作都有稳定执行标识和执行记录。重复请求先查记录，已经成功的返回已有业务结果，避免再次创建。一个批量方案有部分成功、部分冲突时，逐项保存回执，只处理未完成或需要修正的项，不能整体重放。

写操作超时尤其要先核对执行记录和实际业务状态，因为可能已经写入，只是响应没回来。确认未执行后才考虑重试，重试时继续检查权限、草案版本和确认状态。只读查询可以在预算内有限重试；明确失败的写操作返回具体原因，必要时调整草案并重新确认。

面试回答

审计要能够还原谁提出了什么目标、确认了哪份草案、调用过哪些工具，以及最终影响了哪些业务记录。因此会记录发起人、组织、任务和草案版本，关键参数与用户确认，工具调用时间、状态、错误、证据和执行回执。

我会区分建议、待确认草案和已执行结果。比如草案生成成功，只说明模型已经提出方案，不能记成调度成功；最终还要关联创建或修改的业务记录 ID，说明哪些动作完成、哪些失败。界面和日志采用同样的状态区分，方便定位失败、处理重复请求和回溯实际变更。