工程实践2026-07-22

AI Agent 工程化落地实战：小程序三种架构取舍

去年一个零售客户的小程序智能体上线三天就被用户抛弃——单次对话14轮LLM调用、耗时9秒。本文基于Anthropic和LangGraph的工程实践，拆解小程序AI Agent三种架构模式的真实取舍，含四个生产事故复盘。

去年底我们帮一个零售客户做智能客服小程序，第一版用了某网红编排框架，上线第三天就因为一次对话触发 14 轮 LLM 调用、单次耗时 9 秒，小程序直接被用户拉黑。这个教训让我们重新审视了一个问题：小程序里跑大模型应用，和 Web 端完全是两回事。

小程序接入大模型，约束条件完全不同

微信小程序有几个硬约束：主包不超过 2MB、冷启动 2 秒内完成首屏渲染、WebSocket 并发上限 5 条。这些数字决定了你不能像 Web 应用那样随便塞一个运行时进去，也不能指望用户手机跑本地推理。所有推理必须在云端完成，小程序端只做渲染和通信。

更关键的是用户容忍度。Anthropic 在 2024 年底的《Building Effective Agents》中提出了一个重要洞察：大多数成功的智能体实现用的不是复杂框架，而是简单、可组合的模式——「用最简单的方案解决问题，只在必要时才加复杂度」。小程序场景下，用户切走三秒就判定"不好用"，这个原则比任何时候都重要。

Lilian Weng 在其经典文章中将智能体系统拆解为三个核心组件：规划（Planning）、记忆（Memory）、工具使用（Tool Use）。小程序场景下，规划必须考虑网络抖动导致的中断恢复，记忆要处理后台切换时的状态丢失，工具调用则面临小程序 API 沙箱的限制。关于多智能体编排和 MCP 协议层面的技术选型，我们在《AI Agent 平台搭建指南》中有更详细的拆解。

三种架构模式实测对比

基于 Anthropic 总结的五种生产环境模式，我们结合小程序特点，实际跑过以下三种。下面是数据对比：

架构模式	核心思路	小程序适配要点	首字延迟	适合场景
Prompt Chaining（链式调用）	任务拆成固定步骤，每步输出是下一步的输入，中间设程序化 gate 检查	每步通过 HTTPS 请求后端，小程序端只做展示 + 轻量状态管理；无需维护长连接	1.5–3 秒	FAQ 客服、表单引导、固定业务流程办理
Routing + Tool Use（路由 + 工具）	LLM 先做意图分类，再路由到不同工具链；工具调用走后端 API	意图分类在云端完成，小程序根据返回的 action 类型渲染对应 UI 组件；需要 WebSocket 推送中间状态	2–5 秒	多业务线客服、企业内部工具助手、带查询的对话
Orchestrator-Workers（调度-执行）	一个主 LLM 做任务拆解和分配，多个 worker 并行/串行执行子任务	小程序端需维护任务状态机，用 WebSocket 推送子任务进度；主包体积压力大，建议纯云端	5–15 秒	复杂诊断、多数据源聚合分析、多步推理场景

三种模式的本质差异在于控制权归属。Prompt Chaining 的每一步是确定的，LLM 只在单步内发挥；Routing 让模型有了选路径的自主权；Orchestrator 则把规划和执行都交给了模型。自主权越大，能力天花板越高——但失控风险也越大。

怎么选：一个三问决策框架

不要上来就套框架。问自己三个问题，答案自明：

任务确定性有多高？如果用户问题类型可以用一张表穷举（退货/查物流/改地址），直接用 Prompt Chaining + 规则路由，不需要上智能体编排。Anthropic 原话是——「优化单次 LLM 调用 + 检索增强，对很多应用已经足够」。不必要的复杂度就是在浪费 latency 和 token。
延迟预算有多少？小程序用户平均等待耐心约 3 秒。Orchestrator 模式首字延迟普遍在 3 秒以上，除非业务天然允许异步（提交诊断报告、后台跑完推送结果），否则别碰。
团队能承受多高的维护成本？Routing 模式需要持续维护意图分类的准确率，每增加一个业务线就多一个分类维度。LangGraph 这类框架提供了持久化执行和 human-in-the-loop 能力——模型决策不确定时暂停、等人工介入——这对小程序的灰度发布和风险控制非常实用。

如果你的业务同时覆盖 Web、小程序和桌面端，跨平台架构统一是另一个维度的难题——我们在《AI Agent 工程化跨平台实战》中做了系统梳理。

工程化的四个硬坑

过去一年我们在小程序项目里踩过的四个坑，每个都关联一次线上事故：

坑一：WebSocket 重连风暴。小程序切后台超过 5 秒，WebSocket 被系统强制断开。此时后端正在等 LLM 流式返回——用户切回来看到一个"正在思考中…"的僵尸页面。解法：切后台主动发送 heartbeat，onShow 时做状态快照恢复，不等重连。

坑二：Token 消耗失控。一个用户在客服小程序连续追问 23 轮，Prompt Chaining 把完整历史塞进每轮 context，最后一轮 prompt 膨胀到近 8000 token，单次调用成本是正常的 12 倍。后来用滑动窗口 + 摘要压缩，历史 token 控制在 2000 以内。

坑三：工具调用超时后 LLM 自己"编"答案。后端调库存查询 API 超时 5 秒，LLM 直接编了一个数字返回给用户。教训：每个工具调用的返回值必须过 schema 校验，不合规的直接 fallback 到"暂无法查询"，不给模型幻想空间。

坑四：小程序包体积膨胀。早期我们把一个轻量运行时（约 300KB）塞进小程序，加上 UI 组件库后主包逼近 1.8MB，离 2MB 上限只剩一口气。后来把所有推理逻辑移到云端，小程序端只保留渲染层和 WebSocket 客户端，主包降到 400KB。

移动端特有的坑远不止这四个，我们在《移动端从 Demo 到生产》中补充了更多案例，包括离线场景的降级策略和弱网环境下的超时配置。

常见问题

问：小程序做 AI 智能体，必须用微信云开发吗？
不一定。云开发提供了免鉴权的云函数和数据库，适合快速验证。但如果你已有自建后端（比如基于 LangGraph 搭建的服务），直接通过 HTTPS / WebSocket 对接——域名需在小程序后台配置白名单。

问：LangGraph 和 Claude Agent SDK 怎么选？
LangGraph 是底层编排框架，适合需要精细控制状态流转、持久化和中断恢复的团队。Claude 的 SDK 更轻量，适合快速原型。经验法则：任务链超过 10 步、需要断点续跑 → LangGraph；客服问答 + 简单查询 → SDK 够用。

问：流式输出在小程序端怎么实现？
LLM 的 SSE 流由后端中转，转成 WebSocket 消息推给小程序。关键：后端处理好流中断和重连；小程序端收到每个 chunk 做增量渲染，不等全部内容返回——用户感知延迟从 5 秒可降到 1 秒以内。

问：模型出错怎么兜底？
三层：① 工具调用层——每个 tool 返回超时或格式异常，统一 fallback 话术；② 对话层——连续 3 轮未产生有效工具调用，自动降级为 FAQ 匹配；③ 全局层——任何异常 3 秒无响应，展示"连接断开，请重试"。这些规则写死在代码里，不让 LLM 自己判断。

如果你正在做小程序端 AI 能力的选型和落地，欢迎查看蓝曜炬辉的工程实践案例，或直接联系我们讨论你的具体业务场景。