正在加载，请稍候
把大模型智能体塞进微信小程序，卡住团队的一般不是模型智力，而是主包体积、冷启动首响和会话态归属这三件事。下面给出一套小程序客服 Agent 的参考实施方案，用于拆分工作与安排验收。
口径说明：本文是工程方案，不是某个客户项目的交付复盘。案例库聚合统计只用于说明样本分布，不证明某个客服项目已在三周内交付；实际排期取决于需求范围、接口联调及验收条件。
因为小程序是受限运行时，主包体积、跨包引用规则和 tabBar 归属会直接决定智能体的代码放在哪一层。微信官方分包文档写得很死：tabBar 页面必须在主包内，packageA 无法 require packageB 的 JS 文件，只能引用主包与自身分包。
客服场景的 prompt 模板、工具定义与状态机往往几百 KB 起步，一旦被打进主包，启动路径立刻被拖长。一种可行的做法是把对话交互页整体切成独立分包，主包只留 tabBar、登录与一个「空壳」入口页。
还有一个 2026 年值得注意的信号：微信开放文档的 AI 能力分类下，已列有「AI 推理能力（Beta）」「AI Skills」等条目。这说明端侧推理是官方认可的路径之一，但从工程约束看，它同样受包体积与机型差异限制，不该被默认当成默认解。
客服场景可优先评估「服务端编排 + 端侧只做 UI」，具体选哪种取决于延迟、可维护性与数据出域三者的优先级：端侧推理只在有离线或数据不出域硬约束时才值得付出包体积代价。
| 落位方式 | 端上需要什么 | 主要优势 | 主要风险 | 适用场景 |
|---|---|---|---|---|
| 端侧推理 | 模型文件（包内或下载） | 无网络往返、数据不出端 | 包体积、机型差异、模型更新成本 | 离线可用、轻量意图识别 |
| 服务端编排 + 端侧只做 UI | 一个会话页加事件上报 | 模型可随时换、逻辑可灰度 | 首响依赖网络、并发成本 | 客服、导购、售后主流程 |
| 托管式智能体平台 | 一个入口页与鉴权 | 验证快、无需自建编排 | 供应商绑定、合规评审周期 | 内部工具、概念验证 |
第二行适合需要频繁更新知识与工具的客服场景：客服话术、知识库和工具几乎每周都在变，把变更放在服务端，端上就不用重新提审发版。这三种落位的更细拆解，见我们此前写的《AI Agent 工程化落地实战：小程序三种架构取舍》。
对于范围已收敛的纯文本、单知识库场景，可参考三周排期：第 1 周打通链路，第 2 周做工程化收敛，第 3 周灰度与验收。该排期是方案建议，并非从案例统计推导出的交付保证。案例库的独立背景数据是：截至今日，我们已发布的 7 个交付案例中，5 个登记了项目周期，最短 2 周、最长 6 周，其中一条样本正是「产品规划 2 周 + UI 设计 1 周 + 全栈开发 3 周」；登记了团队规模的案例集中在 3–4 人。
从 POC 验证到生产放量的完整路径与选型顺序，见企业 AI Agent 落地完全指南。
移动端智能体的成本核算不该按「请求数」算，而该按「任务」算：一次客服会话可能触发检索、工具调用、改写等多个步骤，按请求计费会让预算失真。这部分我们单独写过一篇拆解，见《AI Agent 工程化到移动端：成本按任务算，不按请求》；更细的会话级账本口径见《小程序 AI Agent 的会话级账本》。
如果你在评估小程序侧 AI Agent 的落地路径，可以先看我们的服务范围与已交付案例，或直接联系团队沟通；蓝曜炬辉（lanyaoai）是广州的 AI 转型与软件定制开发团队，主要服务广州及粤港澳大湾区客户，也支持全国远程交付。
问：小程序里跑 AI Agent 一定要用端侧模型吗？
答：多数 B 端客服与导购场景不需要端侧模型就能满足需求，因为端侧推理受包体积与机型差异约束，而服务端编排在模型替换、灰度发布和知识库更新上都更可控；只有离线可用或数据不出域这类硬约束才值得考虑端侧。
问：对话相关代码放不进主包怎么办？
答：把对话页整体声明为独立分包、主包只保留 tabBar 与登录入口即可，因为微信官方规则是 subPackages 配置路径之外的目录才会打进主包，而 tabBar 页面必须留在主包内。
问：端上不存上下文，多轮会话会不会丢记忆？
答：不会，只要会话态放服务端即可，端上仅传 sessionId，由服务端维护滚动摘要与最近若干轮原文，这样既避免端上上下文被篡改，也便于跨设备、跨端延续同一会话。
问：三周真的够上线一个客服 Agent 吗？
答：按我们已发布案例的口径（7 个案例中 5 个有周期记录，区间 2–6 周），这些跨项目统计不能保证客服项目三周上线。三周只能作为范围受控时的参考排期，涉及多端同步、多工具编排或复杂权限时，应单独评估并预留联调与验收时间。
问：要不要一开始就抽象出编排框架？
答：不建议，先用 LLM API 直接实现更稳，因为 Anthropic 的工程经验是「最成功的实现用的是简单可组合的模式，而不是复杂框架」，等模式稳定后再抽象不容易返工。