前段时间一个做电商的朋友问我一个问题。他说他们准备做一个智能客服希望 Agent 能够直接处理退款、修改地址、查询物流这些事情。按照他们最开始的设想其实非常简单。用户输入一句话Agent 理解意图然后调用几个 Tool事情就结束了。整个流程画在白板上不过几条箭头。User ↓ Agent ↓ Tool ↓ Done那天讨论结束的时候所有人都觉得这件事情不会太复杂。毕竟现在大模型越来越强Function Calling、MCP、Tool Use 都已经非常成熟剩下的不过是把业务接口接进去而已。后来事情的发展和我们想象的完全不一样。真正困难的地方从来都不是 Agent。项目进行到第二周的时候第一个问题就出现了。Agent 已经能够识别用户的意图也能够正确调用退款接口。但是运营提出了一个问题。“如果订单已经发货还允许退款吗”大家开始翻业务代码。退款服务里面有判断。订单服务里面也有判断。售后服务还有另外一套判断。最后谁说了算没有人敢确定。后来产品又补了一句。“不同店铺规则还不一样。”于是这个 Tool 不得不继续扩展。再后来。VIP 用户。跨境订单。预售订单。组合商品。虚拟商品。活动订单。每增加一种业务就意味着 Agent 调用退款的时候需要知道更多上下文。慢慢地我们发现所谓的 Tool其实已经不像一个简单的方法而更像一个完整的业务系统。很多人第一次接触 Agent都容易形成一种错觉。大模型负责思考。工具负责执行。整个系统就完成了。这种理解在 Demo 里面完全成立。可一旦进入企业项目事情马上开始变味。因为企业真正重要的从来不是怎么完成一件事情而是有没有资格完成这件事情。举个最简单的例子。用户说帮我取消订单。对于 Agent 来说这只是一个 Intent。但是对于后台系统来说它至少意味着十几个业务判断。订单是否支付。库存是否已经扣减。优惠券是否已经核销。物流是否已经出库。售后是否正在处理中。是否超过取消时限。是否存在人工审核。有没有命中风控规则。这些规则没有任何一个来自 Prompt。它们全部来自业务。后来我越来越觉得大模型只是把人的语言理解得越来越好。真正复杂的地方从来没有发生变化。项目做到一个多月的时候我们开始重新设计 Tool。最开始每一个 Tool 都对应一个接口。refundOrder() cancelOrder() updateAddress() queryLogistics()后来这些 Tool 越来越复杂。每一个 Tool 前面都开始出现各种校验。权限。风控。幂等。日志。审计。限流。超时。异常恢复。慢慢地我们发现一个很有意思的现象。Tool 的代码越来越少。Service 的代码越来越多。最后 Tool 几乎变成了一层转发。真正完成业务的还是原来的 Java 服务。那天晚上我们几个开发一起看代码的时候有人突然笑了一句。“搞了半天Agent 最后还是在调用我们的 Backend。”大家都笑了。但这句话后来一直留在我的脑子里。以前做后台我们习惯讨论接口。REST API。RPC。MQ。这些东西本质上都在解决一个问题。不同系统之间如何调用能力。Agent 出现以后调用方变了。以前调用接口的是前端。现在调用接口的是 AI。能力本身却没有发生变化。退款还是退款。支付还是支付。库存还是库存。以前 Controller 收 HTTP 请求。现在 Tool 收 Agent 请求。本质上它们都只是入口。真正重要的那部分业务规则并没有因为 AI 的出现而减少一行。反而因为调用方越来越聪明后台系统承担的责任越来越重。后来我们又遇到另外一个问题。Agent 经常喜欢连续思考。比如用户说我想把昨天买的耳机退掉如果不能退就帮我申请售后如果售后也不行就联系客服。以前这是客服自己处理。现在 Agent 会自动规划。于是调用链开始变成这样。QueryOrder ↓ Refund ↓ AfterSale ↓ CreateTicket看起来很合理。真正上线以后却出现了很多意想不到的问题。退款失败以后售后成功了。售后成功以后客服工单又创建失败。第二天 Agent 又重新执行了一遍。于是重复申请售后。重复创建工单。重复发送短信。后来排查日志的时候我们发现这已经不是 AI 能不能理解的问题。而是整个后台系统从来没有假设过会有一个调用方一次性连续执行这么多业务动作。以前一个页面只会点一次按钮。现在 Agent 一分钟可能尝试几十种方案。后台系统第一次开始真正面对一个永远不会嫌麻烦的调用者。也是从那个时候开始我越来越少讨论 Prompt。很多团队讨论 AI最后都会回到 Prompt Engineering。怎么写提示词。怎么让 Agent 少犯错。怎么减少幻觉。这些当然重要。但是如果站在后台开发的角度它们反而没有那么重要。因为 Prompt 再优秀也无法替代业务规则。模型可以理解退款是什么意思。却不知道公司规定发货七天以后必须人工审核。模型可以知道取消订单这个动作。却不知道某个品牌要求订单拆单以后不能整单取消。这些东西不属于语言能力。它们属于业务。而业务一直都活在后台系统里面。后来我重新看了一遍我们所有 Tool 的设计。发现一个现象特别明显。那些最稳定、最容易维护的 Tool都有一个共同特点。它们几乎不会直接操作数据库。也不会直接修改状态。它们更像一句完整的业务语言。比如createOrder() lockInventory() submitRefund() confirmReceipt()而不是updateOrderStatus() updateInventory() updateRefundFlag()这两个看起来只是命名不同。实际上代表着完全不同的设计思想。前者描述的是业务能力。后者描述的是数据修改。对于 Agent 来说它需要的是能力。不是 SQL。后来有人问我如果重新做一次你最大的变化是什么。我想了很久。答案其实很简单。以前设计后台接口的时候我关心的是前端怎么调用。现在设计后台接口的时候我关心的是 Agent 能不能安全调用。这两个问题看起来只有几个字的区别。真正做起来却意味着整个设计思路都变了。因为人会犯懒。Agent 不会。人会放弃。Agent 会不断尝试。人知道什么时候应该停下来。Agent 只会按照目标一直执行。后台系统第一次需要面对一个几乎无限耐心、无限执行力的调用方。这也是为什么我越来越觉得以后的 Backend 不再只是业务系统。它更像是 Agent 的操作系统。Agent 负责理解世界。Backend 负责约束世界。前者决定想做什么。后者决定什么可以做。这两年关于 AI 的讨论越来越多。有人说大模型会重构软件。有人说Agent 会取代大量业务系统。我没有那么悲观也没有那么乐观。真正做过项目以后我反而越来越相信另一件事情。Agent 的出现并没有让后台系统变简单。恰恰相反它把后台系统过去很多被隐藏的问题全部暴露了出来。权限是不是清晰。能力是不是稳定。接口是不是幂等。业务边界是不是明确。这些以前可以依赖前端兜底的问题如今都会直接摆在 Agent 面前。Agent 足够聪明它会把系统所有设计上的模糊地带一个一个试出来。所以AI 真正考验的从来不是模型。而是软件工程。这也是我现在越来越不相信一个 Agent 就能解决所有业务的原因。真正决定一个 AI 应用能不能走到生产环境的从来不是 Agent 有多聪明而是它背后的后台系统到底是不是一个足够可靠的基础设施。而下一次当我们开始讨论 MCP、Tool、Workflow甚至 Multi-Agent 的时候我发现自己已经很少先看模型了。我更关心另一个问题。我们的后台系统真的准备好迎接一个永远不会疲倦、永远不会按套路出牌的新调用方了吗