别再盲目上 Agent 了！大厂面试官最爱问的工程陷阱

引言

前两天跟一位在大厂做技术管理的哥们吃饭，他跟我吐槽了一个面试经历。

他们团队最近在做一个内部效率工具，需要接入 AI 能力。面试来了个挺资深的候选人，简历上写着“精通 Agent 架构，有多款落地产品”。

哥们问他：“如果让你来设计这个工具的 AI 部分，你会用 Workflow 还是 Agent？”

候选人眼睛一亮，仿佛终于等到了送分题，滔滔不绝地讲了二十分钟。核心思想就一个：“这都什么年代了，当然要上 Agent！Agent 能自主规划、能调用工具、能自我反思，Workflow 那种死板的链路早就过时了。”

哥们听完，只回了一句：“如果我们的用户要求响应时间在 1 秒以内，而且并发量很大，你的 Agent 方案怎么保证稳定性？”

候选人愣住了。

这道题，其实不是在考技术栈的熟练度，而是在考工程判断力。

在 AI 落地的浪潮里，我见过太多团队为了“先进”，把本来一个简单的 if-else 或者几行代码就能搞定的 Workflow，硬生生包装成了复杂的 Agent。结果呢？成本翻倍，延迟爆炸，调试起来痛不欲生。

今天，我们就来把这层窗户纸捅破：到底什么时候 Workflow 就够了，什么时候才真正需要上 Agent？

01

误区：步骤多不等于需要 Agent

很多人对 Agent 有一种迷之自信，觉得只要任务稍微复杂一点，涉及多个步骤，就必须上 Agent。

“你看，这个任务要先分类，再查数据库，最后生成回复，这步骤多复杂啊，肯定要让模型自己决定怎么走。”

大错特错。

步骤多，不代表路径未知。

举个最通俗的例子。你在组装宜家（IKEA）的家具。 说明书上写着：第一步，拧螺丝 A；第二步，装板子 B；第三步，拧紧螺丝 A。 这虽然步骤多，但每一步都是预定义的。你不需要在拧完螺丝后，停下来思考宇宙的尽头，然后决定下一步去煮咖啡。这就是 Workflow。

而 Agent 是什么呢？ Agent 就像你雇了一个非常有经验但偶尔会犯迷糊的老师傅。你告诉他：“帮我把这个柜子装好。” 他可能先去喝了口水，然后发现少了个螺丝，自己跑去楼下五金店买了一个，回来接着装，中间还顺便帮你把地拖了。

这就是本质区别：

• Workflow：路径是写死的，代码里已经决定了下一步做什么。
• Agent：路径是模型在运行时动态决定的，下一步做什么取决于上一步的结果和模型的“思考”。

如果你能在一个白板上，把整个业务的流程图画得清清楚楚，没有分叉，或者分叉是确定的，那么请相信我：用 Workflow，别用 Agent。

硬上 Agent 的后果，就是让模型去“重新发明”你已经知道的逻辑。这不仅是算力的浪费，更是引入了巨大的不确定性。

02

Anthropic 的五种武器

在判断是否上 Agent 之前，我们得先看看 Workflow 到底有多强。很多时候，你以为 Workflow 做不到的，其实只是你没用对模式。

Anthropic 出过一篇经典的文章《Building Effective Agents》，里面提到了五种 Workflow 模式。这五种模式能覆盖 80% 以上的业务场景。

我们结合一个“企业智能报销系统”的案例来拆解一下。

1. Prompt Chaining（链式处理）

这是最基础的。一步做完，校验通过，再做下一步。

★场景：员工上传了一张发票图片。流程：

1. OCR 识别图片，提取文本。
2. LLM 从文本中提取金额、日期、商家。
3. 代码校验日期是否在报销周期内。
4. 生成报销单草稿。

这里每一步都是固定的，不需要模型思考，这就是典型的 Prompt Chaining。

2. Routing（路由分流）

根据输入的特征，分发给不同的处理链。

★场景：员工提交报销申请。流程：

1. LLM 判断报销类型：是“差旅交通”、“团建费用”还是“办公用品”？
2. 如果是差旅，走 A 链路（自动审批）。
3. 如果是团建，走 B 链路（需要部门经理审批）。

很多人以为这种“判断”需要 Agent，其实一个简单的 Routing 就够了。

3. Parallelization（并行处理）

同时跑多个任务，互不干扰。

★场景：处理一张包含机票、酒店、餐饮的混合报销单。流程：

1. 同时让三个 LLM 去识别机票、酒店、餐饮的发票。
2. 汇总结果，计算总金额。

这种能显著降低延迟，Agent 串行处理可没这么快。

4. Orchestrator-Workers（编排者-工作者模式）

一个中心大脑负责拆解任务，分发给小弟去干，最后汇总。

★场景：月度报销汇总。流程：

1. Manager LLM 接收一个月的所有消费记录。
2. 拆解成：交通类、住宿类、餐饮类。
3. 分发给三个 Worker LLM 分别生成统计报表。
4. Manager 汇总成一份月度分析报告。

注意：这依然是 Workflow！因为拆解的逻辑是预定义的（按类别拆），而不是模型自己突发奇想拆成了“周一花的钱”和“周二花的钱”。

5. Evaluator-Optimizer（评估优化模式）

生成 -> 评审 -> 修改 -> 再评审，直到达标。

★场景：生成给老板的报销说明邮件。流程：

1. LLM 生成初稿。
2. Evaluator LLM 检查语气是否太卑微，或者格式是否太乱。
3. 如果不通过，反馈给 LLM 重写。

这适合对质量要求极高的内容生成环节。

看完这五种，你会发现，绝大多数企业内部系统，其实用这几种组合起来就完全够用了。

03

四个维度，判断是否该上 Agent

既然 Workflow 这么强，那 Agent 是不是就该失业了？当然不是。

Agent 有它的不可替代性，但它的入场门槛非常高。我们可以用四个维度来做一个严格的“体检”。

维度一：路径是否已知？

这是最核心的判断标准。

• 已知路径：你能画出流程图。比如报销流程，一定是提交->审核->打款。-> 选 Workflow。
• 未知路径：你不知道下一步会发生什么。比如一个“私人购物助理”，用户说“帮我买个礼物送给女朋友”。模型可能先去查女朋友的微博，看她最近喜欢什么，然后去电商平台搜索，再比价，最后下单。中间每一步都是动态的。-> 选 Agent。

维度二：错误成本有多高？

• 高成本：金融转账、删除数据库、发送全员邮件。Agent 的决策带有随机性，哪怕只有 1% 的概率发错邮件，在金融领域也是灾难。-> 选 Workflow。
• 低成本：推荐一个菜谱、写个周报草稿。错了也就错了，大不了重来。-> 可以考虑 Agent。

维度三：是否需要运行时动态判断？

• 不需要：逻辑是写死的。-> 选 Workflow。
• 需要：比如“智能客服”遇到一个极其刁钻的问题，模型可能决定先去翻历史工单，发现没有，再决定去知识库搜，还是没有，最后决定转人工。这个“翻什么、搜什么”是取决于用户具体的问题内容的。-> 选 Agent。

维度四：对时延和稳定性的要求？

• 高要求（< 2秒）：用户点了按钮就要看到结果。Agent 每次决策都要调用一次 LLM，还要加上 Tool Execution 的时间，延迟是叠加的，很难做到 2 秒内稳定响应。-> 选 Workflow。
• 低要求（异步任务）：比如后台生成一份复杂的行业研报，跑个 30 秒也没关系。-> 可以考虑 Agent。

04

实战拆解：报销系统的双轨制

为了让大家更直观地理解，我们还是回到刚才的“企业智能报销系统”。

假设你是这个系统的架构师，你会怎么设计？

最务实的方案是：混合双打。

1. 常规路线（Workflow）：覆盖 90% 的场景

大部分员工的报销是非常规范的：上传发票 -> 系统识别 -> 填写金额 -> 提交。 这部分完全用 Routing + Chaining。

• 输入：发票图片。
• 处理：OCR -> 提取字段 -> 校验金额 > 0 -> 写入数据库。
• 结果：延迟 500ms，成本 0.01 元，成功率 99.9%。

2. 特殊路线（Agent）：覆盖 10% 的异常场景

总有那么一些“难搞”的报销。比如员工贴了一张手写的便签，上面写着：“打车去客户公司，因司机绕路多付了 20 元，申请额外补贴。”

这种非结构化的描述，Workflow 根本处理不了。这时候，Agent 出场了。

• 输入：手写便签 + 用户历史行为。
• Agent 思考：
  1. 这是一个打车报销，但涉及纠纷。
  2. 我需要查一下当天的天气（如果是暴雨天，绕路可能合理）。
  3. 我需要查一下该客户的地址（确认距离）。
  4. 综合判断，是否应该批准这笔补贴。
• 结果：延迟 8 秒，成本 0.2 元，可能需要人工复核。

对比结论：

• 对于那 90% 的简单工单，如果你硬上 Agent，不仅浪费钱，用户还得傻等 8 秒，这是典型的“拿着大炮打蚊子”。
• 对于那 10% 的复杂工单，如果你不上 Agent，用户就得填一堆复杂的表单，体验极差。

这就是高级工程师的价值：在合适的场景，用合适的工具。

05

面试官的追问链

如果你在面试中回答到了这一步，面试官通常会继续追问，考察你的实战踩坑经验。

追问 1：“你有没有做过一开始用了 Agent，后来又改回 Workflow 的项目？”

满分回答思路： 一定要诚实地说“有”。 “我之前做过一个内部文档问答系统。一开始觉得 Agent 很酷，让它自己去检索、判断、总结。结果上线后发现，对于‘怎么报销’这种固定问题，Agent 有时候会瞎编，有时候检索不到。 后来我们把 Top 20 的高频问题提取出来，做成了固定的 Workflow（直接返回预设答案）。不仅准确率到了 100%，延迟从 3 秒降到了 0.1 秒。这让我明白，能确定的逻辑，绝对不要交给模型。”

追问 2：“Orchestrator-Workers 和 Agent 有什么区别？”

满分回答思路： 这题考的是概念的本质。 “Orchestrator-Workers 本质上还是 Workflow。虽然它有拆解和分配的过程，但拆解的规则是代码写死的（比如按章节拆）。 而 Agent 的拆解是动态的。比如你让它写一本书，它可能先写大纲，再写第一章，发现不满意又重写，这个路径是不可预知的。只要决策逻辑可以用 if-else 穷举，那就是 Workflow；只有当逻辑依赖模型对内容的‘理解’时，才是 Agent。”

追问 3：“如果对成本极其敏感，你会怎么选？”

满分回答思路： “毫无疑问，优先 Workflow。Agent 的最大成本不仅仅是 Token，还有调试和维护的时间成本。Workflow 的调试是看日志，Agent 的调试是像破案一样去猜模型在想什么。在商业落地中，稳定性和可维护性往往比‘智能’更重要。”

06

上线后的三个大坑

最后，给大家提个醒，如果你真的决定上 Agent，这三个坑千万别踩。

坑 1：没有 Fallback（降级方案）Agent 是不可控的。如果它突然“发疯”或者 API 挂了，你的系统是不是就崩了？ 必须要设计好：如果 Agent 超时或报错，自动降级成一个简单的 Workflow，或者直接转人工。永远不要把系统的命脉交给模型。

坑 2：把规则逻辑写进 Prompt比如：“如果金额大于 5000，需要审批。” 千万别让模型去判断“5000”这个数字。这是代码的事！ 你应该在代码里判断 if amount > 5000，然后把 need_approval=true 传给模型。 让模型做它擅长的事（语义理解），让代码做代码擅长的事（逻辑判断）。

坑 3：为了炫技而过度拆解不要一上来就搞 Multi-Agent。什么 Planner、Executor、Critic、Evaluator 一大堆。 先搞一个单点的 Agent，跑通了，发现瓶颈了，再考虑拆分。过早优化是万恶之源，这在架构设计里同样适用。

07

总结

AI 落地不是比谁的技术栈更新，而是比谁更务实。

• 默认选择 Workflow：它是可控的、廉价的、快速的。
• 仅在必要时选择 Agent：当任务路径高度动态、且对错误容忍度较高时。

记住一句话：好的工程师，不是用最复杂的技术解决简单的问题，而是用最简单的技术解决复杂的问题。

希望这篇文章能帮你在下一次面试或者技术评审中，给出那个最“性感”又最靠谱的答案。

📢 互动时间

你在实际工作中遇到过强行上 Agent 导致的“翻车”现场吗？ 或者你对 Workflow 和 Agent 的边界有什么不同的看法？ 欢迎在评论区聊聊你的经历或想法。