03. 为什么你的项目用了 Agent，而不是纯 Workflow？

简单回答

这道题和上一道类似，考的是技术选型的判断力。回答要围绕你的项目场景说明：哪些任务的步骤是不确定的、需要根据中间结果动态决策（所以需要 Agent），哪些部分用的是固定流程（没有全用 Agent）。好的回答不是 “Agent 比 Workflow 先进所以选了 Agent”，而是 “我们的场景中有些环节必须动态决策、Workflow 覆盖不了，所以在这些环节引入了 Agent 能力”。

详细解释

这道题的考察点

面试官问这道题通常有两层意思。表面上是问你为什么选 Agent，深层是在试探：你是不是真的理解 Agent 和 Workflow 的区别，你是不是为了用新技术而用（“简历驱动开发”），还是有真实的业务需求推动。

如果你的项目实际上用 Workflow 就能搞定，但你硬要包装成 Agent，面试官一追问细节就会露馅——“你的 Agent 做了哪些动态决策？”“如果把 Agent 换成 if-else 分支能不能实现？”这些问题会很难回答。

所以回答这道题的前提是你确实有需要 Agent 的场景。如果你的项目实际上更接近 Workflow + 少量 LLM 调用，诚实地说 “我们主要是 Workflow，在某些环节用了 LLM 做判断” 也完全没问题——面试官欣赏诚实和清醒的技术判断，不欣赏过度包装。

怎么讲“为什么需要 Agent”

核心是说清楚哪些环节的 “下一步该做什么” 是不确定的，需要 LLM 来动态决策。

工具选择不确定。 “用户的提问类型非常多样——有的问制度规定（需要查文档库），有的问数据指标（需要查数据库），有的问操作流程（需要查系统接口文档），有的是复合问题（需要同时查多个来源再综合）。我们没办法用固定规则穷举所有情况的路由逻辑，需要 LLM 根据用户问题的语义来判断该调用哪些工具。”

步骤数量和顺序不确定。 “有些问题一次检索就能回答，有些需要多轮检索——先查到 A 信息后发现还需要 B 信息才能完整回答。检索几次、每次搜什么关键词，不是预先能确定的，需要 Agent 根据中间结果动态决定。”

需要条件判断是否继续。 “Agent 在拿到检索结果后需要判断 ‘信息够不够完整’。如果够了就直接回答，不够就继续检索或者换个角度检索。这个 ‘够不够’ 的判断不是简单的规则能覆盖的（不是看检索结果条数就行），需要 LLM 理解内容后做语义级的判断。”

同时说清楚哪些部分没用 Agent

好的回答还要展示你不是 “Agent 万能论”——你清楚哪些部分用 Workflow 更合适。

“我们的系统不是纯 Agent 架构。主流程还是 Workflow 驱动的——用户请求进来，先走意图分类（规则 + 分类模型），分流到不同的处理分支。每个分支里有些是固定流程（比如简单 FAQ 直接走知识库检索 + 生成），有些复杂场景才引入 Agent 做动态决策。大概 70% 的请求走固定 Workflow 就处理完了，只有 30% 的复杂请求需要 Agent 介入。”

这种表述比 “我们的系统是 Agent 架构” 有深度得多——它说明你理解两者的边界，知道在哪里用什么，而不是一刀切。

遇到了什么 Agent 相关的挑战

这是展示深度的好机会。

“Agent 上线后遇到的最大问题是稳定性。LLM 的决策是概率性的，同一个问题两次可能走不同路径，有时候 Agent 会陷入循环——反复用同样的关键词搜索得到同样的结果。我们后来加了几个工程措施：最大步骤数限制（10 步）、重复工具调用检测（连续两次相同调用自动跳出）、以及 fallback 机制——Agent 超时或异常时降级到简单的 RAG 模式保证有输出。”

“另一个挑战是延迟不可控。Workflow 的延迟是确定的，Agent 的延迟取决于它走了几步，可能 2 秒也可能 20 秒。我们做了预期时间提示——如果 Agent 判断需要多步检索，先给用户返回一个 ‘正在深度查询中’ 的提示，而不是让用户干等。”

如果面试官追问“能不能用 Workflow 替代你的 Agent”

这是一个好问题。诚实的回答可能是：“大部分场景确实可以用 Workflow + 条件分支覆盖。Agent 真正不可替代的是那些工具选择和步骤顺序完全不确定的场景——我们有约 10% 的复杂查询涉及跨多个知识源的动态检索。如果只是简化掉这 10% 的场景（告诉用户 ‘这个问题太复杂请分开问’），确实可以不用 Agent。但产品上我们需要覆盖这些场景。”

这种 “承认 Agent 不是必须的，但在特定场景下确实需要” 的回答比 “我们的场景就是需要 Agent 没法用 Workflow” 更真实也更有说服力。

一个反面教材

“我们用了 Agent 是因为 Agent 是当前大模型应用的趋势，而且 LangChain 的 Agent 模块用起来很方便，加几行代码就能把我们的工具接进去。”

这种回答暴露了几个问题：选 Agent 的理由是 “趋势” 而不是业务需求；对 Agent 的理解停留在 “框架提供了 Agent 功能所以用了”；没有讲清楚 Agent 在你的场景里解决了什么 Workflow 解决不了的问题。面试官听完一定会追问，而你很可能答不上来。

面试时可以这样答

我们不是全用 Agent，主体还是 Workflow。用户请求先走意图分类分流到不同分支，大概 70% 的简单问题直接走固定的 RAG 流程——检索、Rerank、生成，不需要 Agent 做决策。

引入 Agent 是因为剩下 30% 的复杂场景。比如用户的问题涉及多个知识源——可能同时需要查制度文档和数据库才能回答，Agent 要动态判断先查什么、查到的信息够不够、需不需要补充检索。这些 “下一步做什么” 的决策不是简单的 if-else 能覆盖的，需要 LLM 理解中间结果后做语义判断。

Agent 上线后遇到的主要挑战是稳定性和延迟。稳定性方面，我们加了最大步骤数限制和重复调用检测，还有降级到简单 RAG 模式的 fallback。延迟方面，Agent 走几步不确定，我们做了预期时间提示，避免用户干等。

回过头来看，如果只是为了简化技术方案，把那 30% 的复杂场景去掉——让用户把复杂问题拆开问——确实可以不用 Agent。但产品上我们选择覆盖这些场景，所以 Agent 是必要的。

常见追问

1. 你的 Agent 具体调用了哪些工具？工具定义是怎么写的？
2. Agent 的决策路径你们是怎么做 tracing 和调试的？
3. 如果 Agent 做了错误的决策导致答错了，你怎么发现和修复？