面试题 · 评估
搜索「诊断」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
在构建基于大模型的Agent系统时，其工具（Tool）调用的设计是否应采用工作流（Workflow）的形式？请分析采用或不采用Workflow的优缺点及典型应用场景。
不是二选一，而是分层设计：简单/确定性任务用Workflow，复杂/开放性任务用动态Agent，生产环境常采用"Workflow兜底 + LLM动态规划"的混合架构。
| 维度 | 特点 |
|---|---|
| 可控性 | 节点、分支、异常处理完全可控，适合金融审批、医疗诊断等强合规场景 |
| 可观测性 | 执行路径透明，便于审计和调试 |
按学习路线查看教程、项目和面试题。
| 成本稳定 | Token消耗可预测，无LLM"胡思乱想"风险 |
典型场景：固定SOP的售后工单处理、多轮表单填写、需要人工审批节点的流程。
典型场景：开放域问答、创意写作辅助、探索性数据分析。
| 考量因素 | 建议倾向 |
|---|---|
| 失败成本极高（医疗/金融） | → Workflow为主 |
| 工具调用链长度>5步 | → Workflow避免LLM规划失效 |
| 需求变化周期<1周 | → 动态Agent降低迭代成本 |
| 需要人机协同审批 | → Workflow显式嵌入人工节点 |
建议系统学习该知识点
场景切入
假设你在做一个订单售后Agent，用户说‘我要退款’，系统需要先查订单、验证身份、再判断是否可退。你觉得这个流程是写成固定的工作流好，还是让LLM自己决定调哪个工具？
层层追问
你设计Agent时，工具调用这块一般怎么规划？……有没有考虑过用工作流来组织？……那什么情况下你更倾向用工作流，什么情况下让LLM自由发挥？
直球架构
直接说，构建Agent系统时，工具调用到底要不要设计成工作流形式？分析一下用和不用工作流各自的优缺点，以及适合的场景。
这道题其实问的是，在[[Agent]]系统里，工具调用到底该不该用工作流来管。我的看法是，这不是一个二选一的问题，而是一个分层设计的问题。简单说，确定性任务用Workflow，复杂开放性任务用动态Agent，生产环境往往是混合架构，Workflow兜底，LLM动态规划。
先说说Workflow适合什么场景。说白了，就是那些流程固定、失败成本高的任务。比如金融审批、医疗诊断，还有企业里的售后工单处理。举个例子，一个售后工单流程：用户提交、客服初判、技术分派、维修反馈、用户确认。每一步都很确定，分支也有限。用Workflow的好处是，每个节点都透明可控，异常处理能写死，Token消耗也稳定。而且审计起来很方便，每一步都有日志。反过来，要是让LLM自由发挥，它可能把工单派错部门，或者编个不存在的处理步骤，那风险就大了。
再说说动态Agent的优势。当任务边界模糊、用户意图可能漂移的时候，Workflow就僵了。比如用户问“帮我查下天气，然后推荐穿搭，再生成一张图”，这种工具链组合人类可能没预设过，但LLM能自己串起来。而且业务规则变化快的时候，改Prompt比改代码快得多。所以开放域问答、创意辅助、探索性数据分析这些场景，动态Agent更合适。
但这里有个坑。很多人一上来就想用Agent解决所有问题，结果发现工具调用链一长，LLM规划就崩了。我的经验是，如果工具调用链超过5步，或者失败成本极高，优先用Workflow兜底。比如医疗场景，诊断路径错了可能出人命，这时候Workflow为主，只在分支判断节点内嵌LLM决策。
那实际落地怎么平衡？我倾向渐进式引入。先用LLM跑一批数据，生成执行轨迹，把高频路径沉淀成Workflow模板。然后混合架构：Workflow管主干，比如售后工单的流程框架，但在“是否升级投诉”这种条件分支上，交给LLM判断。最后一定要有逃生舱设计，Workflow执行失败时，降级到动态Agent兜底。
还有一个点值得注意，就是Workflow和Agent的切换时机。我会在Workflow里设一个“不确定性阈值”，比如LLM对分支判断的置信度低于0.6，就自动跳出固定流程，交给Agent动态规划。这其实是个[[ReAct]]循环的变体。
所以我的结论是：别把Workflow和Agent对立起来，它们是一个谱系的两端。我更倾向以Workflow为骨架，在关键节点注入LLM的灵活性，同时保留逃生舱。这样既有可控性，又不会太死板。