跳到主内容LLM、Workflow 和 Agent 怎么选？什么任务根本不该做成 Agent · AlgoMooc面试题 · Agent 项目面试题
LLM、Workflow 和 Agent 怎么选？什么任务根本不该做成 Agent
固定 Workflow：程序负责控制步骤和顺序
Workflow 的核心是控制流可以提前定义。每一步做什么、下一步去哪里、异常如何处理，主要由代码、规则、状态机或流程引擎决定。
以教学退款流程为例：先验证用户身份，再检查订单状态，再判断是否满足规则，之后进入人工或系统审批，最后才执行退款。哪些步骤必须经过、谁有权限、退款能否重复执行，这些都属于业务制度，不应该让模型临场发挥。模型可以解释规则、整理用户描述、生成回复建议，但它不应该有权跳过身份验证，也不应该自己发明一条退款路径。
Workflow 并不意味着系统“没有智能”。固定流程中的某个节点完全可以使用 LLM，例如把自然语言问题分类、从文本中提取字段、生成一段面向用户的解释。区别只在于：模型完成局部能力，程序仍掌握流程主干。
受控 Agent：模型在边界内决定下一步
Agent 多了一层动态控制。用户给的是目标，不一定给出完整路径。系统需要观察当前状态，选择一个行动，调用工具，读取结果，再决定下一步，直到满足完成条件或触发停止条件。
教学场景中，用户要求“比较两个候选市场的进入门槛，并列出仍需确认的信息”。系统可能先搜索政策，再读取两份资料；发现其中一个地区缺少最新准入信息后，调整查询；如果来源冲突，再请求补充检索或明确提示不确定。这里的下一步会随中间结果改变，固定写死每条路径的维护成本很高，Agent 才可能带来实际价值。
注意“受控”两个字。生产系统不是把所有 API 交给模型，然后相信它会做对。真正的 Agent 仍需要工具白名单、参数 Schema、权限、超时、最大步数、预算、审计和人工介入。模型拥有的是有限决策权，不是系统最高权限。
一个任务复杂，不代表它就需要 Agent
一份流程有二十个步骤，看起来很复杂，但如果二十步的顺序固定、条件明确，它仍然更适合 Workflow。一份任务只有三步，看起来不复杂，但第二步必须根据第一步的外部结果选择完全不同的工具，它反而可能适合 Agent。
复杂度可以来自很多地方：数据量大、业务规则多、步骤多、参与系统多、输入模糊。Agent 主要解决的是“路径无法完全提前写死，并且需要根据反馈继续决策”这一种复杂度。它不自动解决高并发、数据库一致性、权限、数据质量或业务规则本身的问题。
1. 任务的完成条件能不能写清楚
如果连什么算完成都无法定义，Agent 也不知道什么时候停。模型可能输出一句“任务已完成”，但这只是自然语言声明，不是业务证据。
例如“帮我做一个最好的市场方案”没有明确验收标准。至少要补充输出结构、信息范围、时效要求、必须引用的证据和哪些结论允许保留不确定性。完成条件越模糊，越不应该一开始就赋予系统更多自主行动权。
2. 下一步是否真的依赖外部反馈
如果每次都按 A、B、C 执行，写成 Workflow 更直接。只有当 B 的结果会决定下一步选择 C、D、E 中哪一个，模型的动态规划才有价值。
这里的“反馈”必须是真实可读取的环境状态，例如数据库结果、工具返回、测试结果或用户补充信息。让模型读一遍自己刚生成的文字，再声称它在根据环境反馈决策，意义有限。
3. 可选行动能否被清楚约束
Agent 至少要知道有哪些工具、工具分别解决什么问题、参数边界是什么、哪些用户有权调用。如果工具描述含糊、返回格式不稳定，模型得到的就不是可靠行动空间。
没有稳定工具，Agent 会退化成“连续猜测”。它可能看起来进行了很多步，但每一步都没有可验证的新信息。
4. 错误是否可逆
搜索一次错误关键词和误删生产数据，不是同一个风险等级。前者通常可以换关键词重试；后者即使事后发现也可能无法恢复。
只读、可回放、低成本的动作可以允许更高自治。写库、发消息、下单、转账、修改权限等动作，要由代码做权限检查、幂等控制和二次确认。风险越高，流程越应固定，人工介入越应靠前。
5. 动态决策带来的收益是否值得
Agent 的每轮决策都可能增加模型调用、工具等待、上下文和排障难度。若固定流程已经覆盖绝大多数情况，剩余少量异常可以转人工，就未必值得让模型自由探索所有路径。
“能做成 Agent”与“值得做成 Agent”是两个问题。架构选型还要看维护成本、响应要求和团队能否建立评估与观测。
6. 出错后能不能知道错在哪
一次模型调用错了，通常只需要检查输入、提示词和输出。Agent 错了，可能是目标理解错、规划错、工具选错、参数错、工具本身失败、状态过期，也可能是模型没有忠实使用工具结果。
如果系统没有逐步 Trace，只保存最终答案，那么引入 Agent 会让问题从“答案错了”升级为“答案错了但无法定位”。在选型阶段就应该把可观测性算进成本。
选型不是先问用哪个框架，而是先找到最小、可验证、可约束的自治范围。
真实系统更常见的是混合架构
把 LLM、Workflow 和 Agent 画成三个互斥选项，会误导设计。更实用的方式是把一个任务拆成不同责任层。
最外层：代码定义不可越过的边界
包括身份认证、租户隔离、数据权限、可用工具、总耗时、最大步数、Token 预算、危险操作确认和审计。这些规则不应该只写在 Prompt 里。Prompt 可以提醒模型遵守，但后端必须再次执行确定性检查。
中间层：Workflow 固定关键业务主干
例如任务创建、资料收集、检查缺失项、人工审批、最终提交，这些阶段可以固定。每个阶段内部是否允许 Agent 自主搜索或选择工具，可以单独决定。
局部：模型处理不确定判断
模型可以判断用户意图、从几个只读工具中选一个、根据空结果调整查询、对多个候选进行解释，或发现信息不足后向用户追问。它的输出进入下一步前，仍由 Schema、规则或人工验收。
这种结构有个重要好处：出了问题可以先定位是哪一层。业务状态跳错，检查 Workflow；工具参数非法，检查 Schema 和执行层；模型选错方向，检查任务描述、候选工具和上下文。系统不会因为“Agent 是一个黑盒”而只能整体重试。
高风险步骤不因模型能力变强就自动适合自治；可控性和可审计性始终是业务边界。
哪些任务通常不该直接做成 Agent
固定、强合规、不可跳步的流程
实名认证、权限审批、账务状态变更等教学类型的业务，核心步骤由规则决定。模型可以帮助读材料和解释，但不应决定是否绕过检查点。
一次生成已经足够的任务
摘要、改写、格式转换、分类等任务，如果一次调用就能完成且结果容易审阅，引入循环只会增加成本和不确定性。
没有可靠反馈的开放任务
模型执行一步后，如果系统无法从工具、测试、数据库或用户那里获得可验证结果，它就没有依据纠正下一步。多循环几次不等于更接近正确答案。
高风险且无法撤销的动作
当错误操作不可恢复，应该使用固定流程、最小权限和人工确认。Agent 可以提出行动建议，但执行权要隔离。
无法建立评测集的“万能助手”
如果项目目标是“什么都能做”，就很难准备覆盖边界的任务集，也难以解释一次改动到底改善了什么。先把范围缩到一类可验证任务，通常比堆很多工具更像工程项目。
面试里怎样证明你的选型不是拍脑袋
只说“这个问题很复杂，所以用了 Agent”不够。更有说服力的证据按以下顺序准备。
先拿出任务定义
写明用户目标、输入、允许调用的数据和工具、输出结构、完成条件、超时后如何处理，以及哪些失败不可接受。
任务定义还要说明个人负责范围。工具 API、模型调用、工作流编排、权限和业务接口可能由不同人负责，不能把整个系统都说成自己独立完成。
再拿出控制流拆解
画出哪些节点固定，哪些节点由模型决定。对每个模型决策点，写清候选行动、输入状态、输出 Schema 和失败出口。若模型永远只有一个可选动作，这个节点大概率不需要 Agent 决策。
准备三种方案的同题对照
使用同一批教学任务，至少比较：一次 LLM 调用、固定 Workflow、受控 Agent。这里不预设哪种一定胜出，而是记录各自是否完成任务、用了几次模型和工具、是否需要人工、失败发生在哪一步。
对照的价值不是产生一个漂亮总分，而是找到适用边界。固定流程可能在常见任务上更稳；Agent 可能只在路径变化明显的任务上有优势；一次 LLM 调用可能在简单任务上最省。这样的结果比“全部换成 Agent”更可信。
最后拿出失败样本和 Trace
挑一条 Agent 没完成的任务，按“输入状态、模型决策、工具请求、工具结果、状态更新、停止判断”回放。说明失败是因为工具不可用、计划错误、权限不足、预算耗尽，还是完成条件定义不清。
能讲清一个失败样本，通常比演示十次顺利运行更能证明你理解系统。
怎样设计一套不自欺的验证方法
第一步：按任务类型分层
至少区分单步生成、固定多步、动态多步、高风险操作和信息不足需要澄清的任务。不要把它们混成一个平均分，否则会掩盖某种架构只在少数类型上有效。
第二步：定义分层指标
最终任务是否完成只是第一层。还要记录工具是否选对、参数是否合法、业务接口是否成功、是否触发重复副作用、循环是否正常停止、人工是否接管，以及每个任务消耗的模型与工具调用次数。
这些指标都应从真实执行记录计算。没有运行日志时，可以先定义字段和判断规则，但不能填写“预计提升”。
第三步：做故障注入
在教学验证中，可以人为让一个只读工具返回空结果、超时或格式变化，观察系统是盲目重试、换工具、向用户澄清，还是安全停止。对于写操作，只做模拟或 Dry-run，不执行真实副作用。
故障注入不是为了证明 Agent “聪明”，而是确认控制系统能否在模型犯错、工具失败时把损失限制住。
第四步：验证退路
Agent 不是唯一入口。系统应明确哪些情况回到固定流程、返回部分结果、让用户补充信息或转人工。如果自动化失败后只剩无限重试，这个架构没有真正的失败恢复。
项目的专业感来自边界、证据和失败处理，不来自“用了 Agent”这句话。
把选型结论写成一份可以复查的决策记录
架构选型不应只存在于汇报幻灯片里。可以为每个拟引入 Agent 的任务保存一份简短决策记录，至少包含：当前基线是什么；固定流程为何不足；哪些局部路径确实无法提前枚举；允许模型调用哪些工具；哪些动作只能建议不能执行；业务完成条件；失败和人工出口；准备怎样验证。
决策记录还要写明反证条件。例如，若动态任务只占很小比例，且人工处理更便宜，就暂不扩大自治；若工具反馈无法稳定区分成功和失败，就先修工具契约；若高风险动作没有幂等与审批，就只开放 Dry-run。把这些停止条件写清，团队才不会因为已经投入开发，就不断为错误选型寻找理由。
上线后的真实数据也要回写决策记录。哪些任务频繁触发人工、哪些循环没有带来新信息、哪些工具始终按固定顺序调用，都可能说明 Agent 范围应该缩小。反过来，若大量长尾任务确实需要根据 Observation 改变路径，才有证据继续完善规划和工具系统。
面试官会怎样连续追问
追问一：为什么不用固定 Workflow
先指出哪些步骤的下一步依赖外部结果，无法合理穷举全部路径；再说明固定 Workflow 仍然保留在哪些关键阶段。不要回答“Agent 更灵活”，而要指出灵活发生在具体哪个决策点。
追问二：为什么不用一次 LLM 调用
说明任务需要获得模型参数之外的实时或业务信息，并且要根据工具反馈继续行动。一次生成无法完成真实查询、验证或操作。
追问三：哪些步骤绝不能让模型决定
列出鉴权、数据权限、不可逆写操作、金额或资源上限、审计和最终提交。强调这些边界由后端强制执行，而不只依赖提示词。
追问四：Agent 怎么知道任务完成了
回答应该包含业务完成条件、工具结果、状态字段和系统出口。模型的自然语言声明只能是一个信号，不能成为唯一证据。
追问五：如果模型一直调用工具怎么办
说明最大步数、最大耗时、预算、重复动作检测、连续失败阈值和人工接管。具体阈值要由真实任务和服务目标确定，不能背固定数字。
追问六：怎样证明 Agent 方案更好
用同一批任务做基线对照，分任务类型比较完成、失败、人工介入、调用次数和成本，并保存逐步 Trace。若结果显示固定流程更合适，也应接受结论，而不是为了维护原选型而挑指标。
Agent 还是 Workflow：给出可验证的选型答案
我不会因为任务看起来复杂就直接上 Agent，而是先判断控制流是否真的需要动态决策。输入明确、一次理解或生成就能完成的任务，用一次 LLM 调用；步骤和规则固定、不能跳过的任务，用 Workflow；只有目标明确，但下一步必须根据工具返回动态变化的多步任务，才考虑 Agent。真实系统通常是混合架构：身份、权限、状态、危险操作、预算和停止条件由代码控制，关键业务阶段由 Workflow 固定，模型只在低风险、无法提前枚举的局部做规划和工具选择。选型后我会用同一任务集比较一次调用、固定流程和受控 Agent，分层记录任务完成、工具选择、失败恢复、人工介入和调用成本，并保留 Trace。高风险不可逆、没有可靠反馈、无法定义完成条件的任务，不会直接交给自主 Agent。对我来说，Agent 的重点不是自由，而是可验证边界内的自治。
选 Agent 之前，把这些项目证据摆出来
面试官若要求你证明选型依据，下面这些材料比一份背熟的定义更有说服力：
- 一句不夸大的任务定义，以及什么算完成。
- 一张标出固定节点和模型决策节点的流程图。
- 一份工具、权限、预算和停止条件清单。
- 一组相同任务上的基线对照，而不是只展示最好的一次。
- 一条失败 Trace，能解释错误发生在哪一层。
- 个人真实负责的模块，以及尚未实现或尚未验证的部分。
如果这些证据还没有，就诚实地把回答说成设计方案或教学实验。面试官会据此判断你是否知道什么时候不该用 Agent，以及采用 Agent 后能否把自治范围限制在可控的工程边界；术语包装无法替代这份判断力。
