写在最前面,这是我做了几个智能体项目后最想劝同行的一句话:凡是能用 if-else 写死的逻辑,千万别甩给大模型去判断。又慢、又贵、还不稳定。这篇不讲具体代码多,主要是个架构观点,讲规则引擎和 Agent 怎么各干各的、怎么配合。

一个反面教材

见过一个项目,把"订单金额大于 1000 走人工审核"这种纯阈值判断,也写进 prompt 让模型决策。结果呢:模型偶尔把 999 也判成"接近 1000 建议审核",偶尔把 1200 漏判,每次调用还要等一两秒、花一笔 token。一个 if amount > 1000 一行代码、零延迟、百分百准确的事,愣是搞成了概率事件。

这不是抬杠,是真实的资源错配。大模型擅长的是处理模糊、开放、语义类的问题;确定性的规则判断,是它的短板。

我的分工原则:确定性归规则,模糊性归模型

我现在搭智能体时,脑子里默认画一条线:

判断标准很朴素:这个逻辑你能不能用 if-else 穷举清楚?能,就别碰模型。

配合的姿势:规则在前,模型兜底

实际搭的时候,工具是个零代码搭智能体的平台,但我没把所有逻辑都堆进智能体里。我让规则引擎站在前面做一道"分流闸门",简单的、确定的直接规则出结果,落不进规则的疑难才丢给模型:

用户请求
  → 规则引擎匹配(命中已知规则?)
       命中 → 直接按规则返回(快、准、免费)
       未命中 → 转给智能体做语义理解和处理

举个客服的例子:用户问"营业时间""退货地址"这种,规则引擎用关键词直接命中标准答案,根本不惊动模型;问"我这种情况能不能退"这种带具体情境的,才交给智能体去理解。这么一分,大几成的请求被规则便宜地解决了,模型只处理真正需要它的那部分,成本和延迟都下来一大截。

为什么这么分,好处是实打实的

• 省钱省延迟:能被规则拦下的请求,不花 token、毫秒级返回。

• 确定性逻辑可单测:规则部分是普通代码,写测试用例就能覆盖,不像模型那样每次都可能飘。

• 改起来安全:阈值从 1000 调到 800,改一行代码、跑个测试就行,不用重调 prompt 再祈祷它听话。

两个容易忽略的坑

规则和模型的边界会漂。一开始划好的线,业务一变就模糊。我有段时间偷懒,把新增的判断都往模型里塞,跑了一阵发现成本悄悄涨、偶发错也多了。后来定期回看:哪些"模型判断"其实已经能固化成规则了,就把它沉淀下来。这个梳理是持续的。

规则太多也会变成另一坨屎山。if-else 堆到几百条,可读性和模型 prompt 一样烂。该上正经规则引擎(配置化、可视化)就别硬写代码,别从一个极端跳到另一个极端。

收尾

那些真交给模型的语义活,跑在讯飞 Agent 的 MaaS 上,按 API 取用——正因为模型能力是现成 MaaS,我才更舍得把确定性逻辑留在自己这边的规则引擎里,好钢用在刀刃上。

你们项目里有没有"杀鸡用牛刀"让模型干 if-else 活的?规则和 Agent 怎么划边界,评论区聊聊。