不用 Agent，只用规则、检索、模板 SQL 能做到几成效果？为什么还要上 Agent？

先这样答

结论是，高频标准场景只用规则、检索和模板 SQL，就能覆盖七成以上的效果。这七成没有必要使用 Agent。Agent 会让处理变慢，成本更高，结果也更不稳定。面试时不能为了体现技术先进，就默认所有问题都交给 Agent。

上 Agent 的理由，只在剩下的部分。长尾问题通常不能直接套用固定规则，需要把多个信息组合起来推理。存在多步依赖时，系统需要根据当前结果决定下一步，不能提前写死流程。这类问题适合让 Agent 做动态规划。用户意图模糊时，系统也需要先澄清，再继续处理。这个场景同样不适合只靠固定模板覆盖。

所以，正确架构应该分层。第一层用规则处理高频标准场景。第二层用检索承接规则没有直接覆盖的问题。最后只把最难的头部问题交给 Agent。这样做的判断标准不是 Agent 能不能处理，而是问题是否真的需要组合推理、动态规划或意图澄清。若回答 Agent 全面优于规则，就忽略了成本、速度和稳定性，也没有说明为什么要分层。

面试官会怎么追问

• 「如果规则和检索已经覆盖七成以上，为什么不继续把剩下的问题也写成规则？」 剩下的问题包含长尾场景，不能都用固定规则直接覆盖。多步依赖需要根据中间结果决定下一步，意图模糊时还需要先澄清。继续堆规则并不能替代这些动态处理。

• 「什么样的问题才值得交给 Agent？」 我会看问题是否需要组合推理、动态规划或意图澄清。长尾问题需要组合多个信息，多步依赖需要动态决定处理顺序，意图模糊的问题需要先确认用户真正要什么。满足这些特征时，才把它交给 Agent。

• 「你会怎么设计规则、检索和 Agent 的分工？」 先用规则处理高频标准场景，再用检索承接规则没有覆盖的问题。只有最难的头部问题才进入 Agent。这样可以让七成以上的常见问题保持更快、更便宜、更稳定的处理方式。

回答的坑

• 不要把 Agent 说成全面优于规则，否则既忽略了七成以上的覆盖，也没有回答成本、速度和稳定性的问题。
• 不要只说 Agent 能做复杂任务，还要明确指出长尾、组合推理、多步依赖和意图澄清这几个使用理由。