从 PHP 后端转向 AI Agent 开发：折腾 OpenClaw 半年，我踩过的那些坑

以前做后端开发时，觉得只要接口设计合理、数据库稳定、业务逻辑没问题，一个系统基本就能稳定运行。

但真正开始接触 AI Agent 后，我发现以前积累的后端开发经验虽然仍然非常有用，却远远不够。

因为传统系统和 AI Agent 有一个很大的区别：

传统程序主要依靠确定性的代码执行，而 AI Agent 的决策过程具有不确定性。

这意味着，以前只需要考虑接口、数据库和服务器的问题，现在还得考虑模型幻觉、上下文、Token 消耗、工具调用、模型限流，以及各种难以复现的异常。

最近这段时间，我的工作重心逐渐从 PHP 后端转向 OpenClaw、企业微信 Agent 及相关基础设施。

期间遇到了不少有意思的问题，整理出来，分享一些实际经验。

一、最开始，我以为 Agent 就是一个会调用工具的聊天机器人

刚接触 OpenClaw 时，我对 Agent 的理解其实很简单：

给大模型配置好提示词，再安装一些 Skills，让它能够调用工具，一个智能体就算搭建完成了。

但真正接入业务场景后，我才发现事情没有那么简单。

比如，给企业微信接入一个商家 AI 助手，看似只需要完成下面几步：

1. 接收企业微信消息
2. 转发消息给 Agent
3. Agent 调用模型
4. 返回回答给用户

这是最基础的链路。

但实际运行时，还需要考虑：

• 多个商户同时发送消息怎么办？
• 多个用户会不会相互污染上下文？
• 上游模型突然超时怎么办？
• 一个用户持续提问会不会消耗大量额度？
• Agent 调用工具失败，应该重试还是终止？
• 服务重启以后，原来的会话还能不能继续？

这些问题，才是真正决定 Agent 能否稳定运行的关键。

能跑起来和能长期稳定运行，是两回事。

二、模型不是永远可用的，限流和超时才是常态

传统后端开发也会遇到第三方接口不稳定的问题。

但接入大模型后，这个问题变得更加明显。

在 OpenClaw 运维过程中，我遇到过上游请求超时、模型服务不稳定、额度限制等情况。

有时候服务器资源一切正常，Gateway 进程也没有异常，但用户就是收不到回答。

一开始很容易把问题归咎于 OpenClaw。

后来慢慢意识到，整个请求链路实际上很长：

企业微信用户
    │
    ▼
消息接入层
    │
    ▼
OpenClaw Gateway
    │
    ▼
Agent / Session
    │
    ▼
模型提供商
    │
    ▼
模型推理
    │
    ▼
工具调用（可选）
    │
    ▼
结果返回用户

这其中任何一个环节出现异常，最终都会表现为用户觉得机器人坏了。

因此，不能只检查 OpenClaw 是否存活。

还需要区分：

• 请求有没有到达 Gateway？
• Agent 有没有收到消息？
• 模型 API 有没有正常响应？
• 工具调用是否超时？
• 消息有没有成功返回企业微信？

对于线上服务，我认为最重要的不是保证永远不出错，而是出错以后能够快速知道问题发生在哪个环节。

如果连请求失败的原因都定位不了，所谓的 Agent 运维就只能靠猜。

三、为什么我开始重视多 Agent 路由？

做单个 Agent 的时候，很多事情其实都很简单。

一个 Gateway、一个 Agent、一个模型，基本就能完成测试。

但到了商家 SaaS 场景，