每个产品路线图中都有一个名为“AI Agent”的要点。这个词听起来像是进步。它向领导层传递了一个信号：你的团队正在构建未来，而不仅仅是在维护现状。但这里有一个大多数演示视频都不会告诉你的残酷事实：Agent 是完成一项工作中最昂贵且最不可预测的方式。对于大多数业务任务来说，它完全是错误的工具。最优秀的工程师不是那些急于构建 Agent 的人，而是那些知道何时该停下来的人。
分类陷阱
观察一个团队规划他们的第一个 Agent，你通常会看到这样的场景：一封支持邮件到达。大语言模型读取主题和正文，决定它是账单问题还是技术漏洞，然后将其放入相应的队列。团队称之为 Agent。其实不然。
他们构建的是一个包含单个模型调用的确定性流程。步骤是固定的：接收邮件、调用模型、路由到队列。没有循环，没有工具使用，没有系统因为第一次尝试失败而停下来重新考虑计划的时刻。它不会在运行中途浏览知识库、编写代码或检查订单状态。它做出一次判断，然后继续。将这个单一调用封装在微服务中并不会使其成为 Agent。
将流程误认为 Agent 的真实代价不仅仅是额外的基础设施。而是你为了毫无收益而引入的非确定性。同一封邮件在周二早上和周三下午可能会被路由到不同的地方，因为 temperature 不为零，或者 prompt 发生了偏移。你为延迟、Token 成本和评估开销支付了 Agent 级别的价格，而一个带有单一分类步骤的流程却能更快、更便宜地解决问题。
按阶梯式工作
大多数问题都有更简单的“近亲”可以同样好地解决它们。把它想象成一个梯子，从底部开始。
修复流程。 有时工作之所以存在，仅仅是因为两个系统之间存在分歧。你 CRM 中的客户记录与工单平台不同步，因此每天早上都需要人工来弥补这一差距。不要用 Agent 来自动化这个桥梁，而是要消除它。如果数据管道是健康的，这项工作就会消失。
使用查询。 如果答案是一个简单的查找或聚合，就把它当作查询来处理。“上周二我们处理了多少退款？”不需要推理。它需要 SQL。一个将自然语言转换为 SQL 的 Agent 听起来很优雅，直到你意识到维护负担超过了编写三个由团队从仪表板运行的文档化查询。
构建确定性流程。 当规则是固定的且结果是可重复的时，请使用显式逻辑。如果订单金额超过阈值，则升级给财务部门。如果用户三十天未活跃，则发送重新参与邮件。代码处理这些任务时具有零偏差和完全的可观测性。你可以对其进行单元测试。你无法对“感觉”进行单元测试。
使用带有单个模型调用的流程。 这是分类、情感标签或数据提取所在的地方。模型在严格的脚本中做出单一判断。你摄取一份文档，提取发票号码，并将其写入数据库。周围的步骤是硬编码的。模型不会选择下一步做什么；它只是标记它所看到的内容。这是一个强大的模式，但它仍然是一个流程。
最后再构建 Agent。 将这一步留给那些下一步行动确实取决于模型在运行中发现的内容的任务。如果系统必须阅读一封邮件，意识到它需要通过物流 API 查询货运情况，发现货运延迟，然后根据这些最新数据起草一份定制回复，那么你就进入了 Agent 的领域。路径无法预先绘制，因为模型会在获取每个新事实后决定下一步做什么。
白板测试
在会议中有一个快速解决争论的方法。让你的团队在白板上画出决策分支。
如果你可以在模型运行之前映射出每一条路径，那就构建一个流程。画出菱形框，写下 if 语句，然后大功告成。可预测性是一项特性，而不是一种限制。
如果模型本身必须决定下一步是什么，如果它选择工具、设置参数并循环回来重新思考，那么你就需要一个 Agent。这种动态路由就是分界线。不要因为想使用一个新的 API 而不小心跨过了这条线。
隐藏税
演示让 Agent 看起来毫无摩擦。生产环境则揭示了会迅速累积的四种“税”：
非确定性。 同一