业务规则和AI代理都是实现决策自动化的方式。比如批准退款或标记交易，但它们采用的方法不同。我的问题是：AI代理是否已经取代了业务规则？还是说两者各有其用武之地？它们之间究竟有何区别？让我们从业务规则开始。
业务规则在业务规则引擎中运行，其逻辑由人明确编写，比如像我这样的人。例如一条业务规则：如果订单创建不到30天，且商品未标记为“最终销售”，那么批准退款。这就是业务规则，它包含条件和动作。
AI代理的工作方式则不同，它不一定基于写好的规则运行。你给它一个目标、情境背景以及允许调用的工具，代理自行决定步骤。与其提供退款规则，不如说：“这是客户、订单政策和历史记录，请解决吧。”
那么谁更适合做决策？规则引擎能提供一致且可预测的答案。它根据事实和条件进行检查，例如订单12天未售、非最终销售，两者均为真时规则判定批准退款。这是确定性逻辑，输出是输入的固定函数，没有猜测成分。
AI代理则不然，它们基于大语言模型构建，预测下一个词元。给定订单、政策和目标后，模型根据训练中的模式生成响应，并不一定锁定唯一答案。它从可能响应的概率分布中进行选择，因此具有概率性而非确定性。
对于上述情况，“批准”仍是最高可能结果，但“拒绝”也有一定概率。这使得AI代理具有不确定性，而规则引擎评估的是固定条件。这就是为什么同一请求运行两次可能得到不同结果：规则是确定性的，代理则是概率性的。
何时使用哪一种？业务规则适用于决策定义明确、逻辑可预先界定的场景，如退款政策、贷款资格检查或保险定价层级。只要输入结构化且已知答案预期，业务规则便非常适用。
在受监管领域还有另一个原因：处理过的规则本身就是解释，引擎能指出触发决策的具体条件，这对审计非常有利。此外，确定性有助于测试：每个分支都可进行单元测试，并在生产中表现一致。
业务规则无需模型调用即可运行，因此没有AI推理成本，优势众多。而AI代理适用于逻辑无法预先编写、结果取决于理解情境的场景。输入可能杂乱无章或非结构化，或者出现了无人预见的案例。
例如，如果我因哑铃太重而退货（这恰是哑铃的用途），这种判断理由优劣的情况正是AI代理的用武之地。这类情况难以用确定性的预定义规则来捕捉，因此需要智能判断而非机械执行。
这就是两者的权衡：规则引擎仅处理预期内的情况，面对无规则的输入时会力不从心；而代理能通过模式泛化处理未预见的问题。回到最初的问题：AI代理是否取代了业务规则？
在许多实际系统中，答案是将两者结合使用。这是一种混合方法，同时利用两者的优势。让我们通过一个混合解决方案来填充流程，看看它可能是什么样子的：请求进入后，首先导航至规则引擎。
为何先使用规则而非代理？因为规则成本相对较低且运行速度快。规则引擎根据策略检查请求并确定行动，例如订单12天、非最终销售意味着在自动批准限额内。此时可直接做出“批准”的最终决定，简单明了。
如果请求明显超出政策范围，则会直接拒绝。大多数退款和决策都是如此清晰明确。只有当规则无法做出决定时，请求才会进入另一条路径，即升级给AI代理处理。
通常有几种原因导致这种升级：首先是需要对数据进行额外处理。规则需要干净的结构化事实（如订单年龄或最终销售标志），但许多退款请求包含不整洁的数据，如有自由文本段落或图片。
规则引擎通常最适合结构化数据，而代理还可以利用工具。例如调用视觉模型查看缺陷搅拌机的照片，或查询订单系统获取客户购买历史。代理会根据情境决定使用哪些工具以及调用顺序。
并且它能在没有预先编写脚本的情况下做到这一点。因此，在那一点上，代理可以自行推荐决策，但它可能没有最终决定权，因为它的建议随后会进入一组确定性的护栏进行评估。因此，一个护栏可能会规定：代理绿灯放行且超过特定阈值的所有内容都应实际路由到其他地方。
首先，它应该进入这里的人机交互环节（human in the loop），在最终决策达成之前。如果低于特定阈值，它可以直接进入决策环节。因此，我们在利益攸关最高的情况下，有机会用真人来检验代理的判断力。
所以不，代理并没有取代硬编码的业务规则，但它们与这些规则配合起来效果相当不错。特别是在数据混乱、我们需要判断力或工具调用可以扩展上下文的情况下尤其如此。最终，两者结合可以帮助做出更好的决策。