前段时间，一个做电商的朋友问我一个问题。

他说，他们准备做一个智能客服，希望 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 的时候，我发现自己已经很少先看模型了。

我更关心另一个问题。

我们的后台系统，真的准备好迎接一个永远不会疲倦、永远不会按套路出牌的新调用方了吗？