上个月把“训练师 Agent”小程序交到微信审核时我心里其实没底一个主打“零代码训练专属 Agent”的小程序到底有没有人愿意用上线第一周的数据比我预期好一些但也暴露出一堆只有真实用户场景才能扇出来的问题。这篇文章把从立项、技术选型、训练链路设计到上线踩坑的过程详细写一遍给正在做 Agent 小程序、或者准备把 AI Agent 能力装进小程序的朋友当个参考。这表面上是一个“训练师 Agent”小程序的上线记录实则背后是完整的 Agent 开发链路前端用 uni-app 兼容微信小程序后端是一套支持流式输出的 Agent 引擎中间还要处理知识库、记忆、行为约束、任务编排这些普通小程序完全不会碰的问题。我会按产品定位、技术选型、核心训练闭环、稳定性打磨、后续扩展这几条线来展开每一步都说清楚我为什么这么做以及哪些地方是回头复盘时觉得可以做得更好的。1. “训练师 Agent”不是又一个聊天机器人而是“给 Agent 当教练”1.1 为什么叫“训练师”产品定位从聊天转向调教最早做这个产品时我自己一直在和各种 Agent 框架打交道。市面上的 Agent 类产品很多但绝大多数是“给用户一个对话窗口背后挂一个大模型”用户问什么模型答什么。这种方案当然能用可一旦放到真实业务里问题就出来了模型不知道你是谁不知道你的领域知识也不知道哪些话能说、哪些动作能做。我想要的不是聊天机器人而是一个“可以被用户训练”的数字助手。所以产品取名叫“训练师 Agent”核心交互不是“我问你答”而是“我来定义你该成为什么样”。用户进来以后可以通过自然语言或表单给 Agent 设定身份、性格、擅长领域、回答风格、行为边界甚至上传一批自己的资料让它变成一个真正贴合自己需求的专属 Agent。这一点和搜索热词里常见的“ai agent”“agent框架与编排”方向一致但又有明显差异我们不是让开发者去编排复杂工作流而是让普通人用“对话 配置”的方式完成训练。整个训练过程的表达必须足够简单后端再笨重都行前端不能让用户感觉到门槛。1.2 谁需要这个工具三个典型用户画像产品做了三个类型的事前调研这几个画像后来也决定了功能优先级。第一类是小微商家和自媒体人。他们需要一个“懂自己业务”的客服或内容助手。普通用户很难写出一段高质量 prompt更不会做 RAG但他们手里有大量的产品说明、历史问答、介绍文案。把这些资料上传给 Agent再告诉 Agent“你是我的客服语气要热情遇到价格问题就按文档回答”就能得到一个相当可用的行业助手。第二类是想体验 Agent 开发的入门者。他们搜索过“agent开发学习路线”“agent框架”之类的内容有一定技术背景但不想从零部署一套 Agent 系统。小程序的低门槛让他们可以在手机上完成一个 Agent 的原型搭建随后再把同样的思路迁移到真项目里。第三类是企业里做运营和培训的人。他们想把公司的制度、流程、话术封装成一个问答 Agent给新员工用或为活动做智能导览。这一类用户更看重“行为约束”和“知识库更新”而不是泛泛的闲聊能力。这三个画像有一个共同点他们不需要“更聪明的模型”而是需要一个“能听懂规则、记得住上下文、可以持续修正”的训练工具。这也让我确定了一件事训练链路比模型本身更重要。2. 为什么选择微信小程序Agent 产品最缺的是触达不是算力2.1 小程序给 Agent 带来的三个便利AI Agent 类产品最常见的载体是网页端也有不少做 App。我最后选了微信小程序理由其实特别直接。第一触达成本低。用户看到“小程序”三个字点开就能用不需要注册账号、不需要下载安装。这对 Agent 类产品太重要了。大家嘴上聊 Agent 聊得热闹但真要打开一个网址去体验转化率会折掉一大截。小程序天然长在微信里分享到微信群、朋友圈打开率明显高。第二微信生态天然适合“分发 Agent”。Agent 一旦被训练好最大的价值是能被人使用。用户可以把 Agent 分享成一个专属会话卡片别人点进来就能和这个 Agent 对话。这种“训练一次、多人使用”的模式在小程序里实现成本最低。第三小程序提供了一套完整的用户体系和支付能力。wx.login 免去自建账号体系虚拟支付能力对后续售卖 Agent 模板、付费训练课程都是现成的基础。这个对小型团队省了很大一块开发量。2.2 uni-app 选型与 HBuilderX 开发流程技术选型阶段我在原生微信小程序和 uni-app 之间犹豫了一阵。我们团队之前有 Vue 的底子目标端主要盯微信小程序但也不想放弃未来发布到抖音小程序、支付宝小程序的可能性。最后选了 uni-app用一套 Vue 语法同时维护多个端工程量能省下来不少。开发工具用的 HBuilderX。说实话HBuilderX 的界面体验和微信开发者工具不是一个路子刚上手会有点不习惯但它在 uni-app 项目创建、真机运行、代码上传这些环节集成得很好尤其适合从零开始的新项目。跑通“HBuilderX 开发微信小程序”这条路以后后面每次发版都是三件事在 HBuilderX 里运行到微信开发者工具确认页面表现再点“上传”走微信审核。这里有一个容易被忽略的细节uni-app 编译到微信小程序后其实底层会生成一套原生小程序代码所以微信小程序的很多原生能力依然能用。比如动态设置导航栏标题我用的是 uni.setNavigationBarTitle它内部映射的就是微信的 wx.setNavigationBarTitle。如果你在小程序里根据不同的 Agent 名称动态替换标题记住要在页面 onShow 或进入会话时重新设置一次否则切换页面后标题会残留。2.3 端上界面和云端 Agent 引擎的分工另一个关键设计是“端上界面”和“云端 Agent 引擎”的边界。刚开始我有一版方案把对话记录和状态管理全放到小程序端后来发现完全走不通Agent 引擎要做意图解析、知识库检索、工具调用这些放到移动端会热到爆炸而且包体积根本不允许。最终划分方式很明确小程序端只做三件事渲染对话流、收集用户输入、展示 Agent 的状态思考中、调用工具中、生成中。云端 Agent 引擎负责所有推理和编排意图识别、插件调用、知识库召回、记忆读取、生成候选回复。两端通过 WebSocket 长连接传输流式结果小程序端按事件类型增量渲染。这种划分让小程序包体积保持得比较小也把计算压力全部收敛到云端。用户感知到的就是“输入一句话Agent 一个字一个字地回复”体验和 ChatGPT 非常接近但背后多了一层 Agent 训练和工具编排的逻辑。3. 训练一个 Agent 的三大核心模块角色、知识、规则3.1 自然语言定义角色后端怎么做意图解析“训练 Agent”的第一步是让用户给 Agent 定义人设。这里我们做了一个比较大胆的设计用户可以直接用大白话写比如“你是我的健身教练说话要直接一点不建议我吃夜宵每次回答尽量给一个具体动作示范”。系统需要从这段话里提取出角色名、技能领域、语气风格、禁止事项。实现上不是靠简单的关键词匹配而是先让大模型做一次“人设 JSON 化”把自然语言转成固定的结构化指令再把这个 JSON 作为系统提示词的一部分拼进后续的每次对话。这样做的好处是用户不需要学习 prompt 语法缺点是多一次模型调用响应会慢几百毫秒。为了让用户感知不到我把它放在训练保存阶段而不是每次对话都解析。这里还要处理一个很现实的问题用户写得乱七八糟怎么办比如有人只写“你是我的宠物”没写任何技能。我们的策略是允许落地但会给一个默认系统提示词并在保存前提示用户“你的 Agent 还没有指定擅长领域建议补充”。这比直接报错友好得多。3.2 知识库切分与召回文档切片、向量化和关键词兜底知识库是“训练师 Agent”的一个独立模块。用户可以在后台粘贴文本、上传 Markdown 或 TXT 文件让 Agent 回答问题时参考这些材料。这个功能看着简单实际上在设计上踩了不少坑。第一坑是切片长度。最开始固定按 512 字切切出来的片段经常把一句话拦腰截断导致召回内容残缺。后来改成按段落和语义边界切超过上限的段落再二次切开短文档不切。这样召回质量明显提升但入库耗时变长。最终我们让用户在“上传速度”和“回答精度”之间自己选择默认走精度优先。第二坑是召回策略。纯向量检索在中文场景下经常出玄学结果尤其是一些专业名词被向量化成奇怪的坐标。我最后用的是“向量检索 关键词匹配”双路召回两者合并后再按分数排序。当用户的输入包含文档里的标题、编号等强信号词时关键词召回会直接命中效果比纯向量稳定很多。第三坑是更新问题。用户改了文档旧的切片必须同时失效。我在存储层给每个知识块加了一个 source_id用户更新文档时先把旧的 source_id 标记为不可用再写入新切片。查询时强制过滤掉已失效块避免出现“已经删了还回答得头头是道”的情况。3.3 行为规则工具调用与敏感话题约束训练 Agent 不只靠“人设提示词”还要靠规则约束。我给 Agent 的指令里加了一个 action 列表也就是它被允许执行的动作。比如健身教练 Agent 可以调用“动作库检索”“饮食建议生成”这两个工具但默认不能调用“下单购买”这类工具。用户想新增动作只能从平台提供的动作列表里勾选不能自定义一段代码注入。这种限制看着不自由其实非常必要。如果允许用户在小程序里随便定义工具执行逻辑一来安全风险不可控二来后端根本无法统一编排。平台要做的不是“万能 Agent”而是“安全可控的 Agent 工具组合”。敏感话题约束也走规则层。用户可以在训练界面指定“哪些话题不要回答”比如不谈医疗诊断、不讨论政治、不做投资建议。这些约束会转成一行明确的否定式指令同时进入审核记录确保 Agent 的输出在红线范围内。上线前我最担心的就是这块后面会单独讲审核时遇到的严格检查。4. 训练闭环是产品灵魂从用户反馈到 Agent 进化的回路4.1 训练动作不只是聊天还包括打分、追问、纠错所谓“训练师”最核心的交互在于训练动作。用户和 Agent 对话时每条 Agent 回复下面都有三个操作赞同、不赞同、重新生成。用户点了“不赞同”会弹出一个小面板可以选择“回答错误”“答非所问”“语气不对”也可以直接输入一句期望的正确回答。这套反馈闭环非常关键。它与普通聊天机器人最大的区别就在这里用户不只是消费回答而是在持续修正 Agent。每次纠正动作都会被记录成一条训练样本保存到云端后后续对话会参考历史修正结果来生成新的答案。这里要说明一下产品刚上线时的模型链路还不是真正的强化学习我们做的是一种“动态示例选择”的近似方法。系统会把用户历史上纠正过的问答对作为 few-shot 示例拼到提示词里让模型看到“上次类似问题用户不满意期待的正确回答是这样”。虽然和大厂的重磅强化训练不是一个量级但对个体用户而言它的体感就是“Agent 越来越懂我了”这就达到了训练的目的。4.2 短期记忆与长期记忆该记什么、不该记什么“agent记忆”是这个产品的一个大工程。刚开始我把所有上下文都扔给大模型很快发现两个问题一是 Token 消耗扛不住二是模型会记住一些不该记住的无关信息。我后来把记忆拆成两层。短期记忆只保留当前会话窗口最近 20 轮对话并做压缩摘要每超过 10 轮就把前面 10 轮总结成一段摘要替换掉原始对话。这样会话级记忆不会无限膨胀也能保持连续性。长期记忆则是跨会话的。用户如果明确说过“我每周三晚上健身”Agent 需要把这条偏好写入长期记忆库。写入动作不是自动的而是 Agent 检测到这类信息后会向用户确认“我记住你每周三晚上健身下次帮你安排训练计划可以吗”用户同意才落库。这样既保留了长期记忆能力又避免 Agent 自作主张记录隐私信息。另一个容易踩的坑是记忆覆盖。用户有一天说“改成每周四”系统要判断这是更新而不是新增。我在长期记忆里对同一 key 做了版本替换而不是简单追加一条。如果没有这层处理Agent 会既记得周三又记得周四回答经常自相矛盾。4.3 反馈数据的利用思路用户产生的大量反馈数据除了实时影响对话还能沉淀成平台级的资产。当某个 Agent 的“不赞同率”连续多日上涨系统会标记这个 Agent 进入“待优化状态”。运营人员可以查看用户具体的纠错记录统计共性问题再针对性地更新 Agent 的人设和知识库。这个模块上线后我发现一个有趣的规律用户通常不会直接说“我教了你什么”而是不断用“不是这样”“不对”这种简短反馈来纠错。如果产品没有把反馈动作做得足够轻用户不会愿意表达。现在我把“双指下滑快速反对”这种手势也加上了操作成本低了反馈量明显上来。训练闭环的产品设计本质上是把“用户的纠正冲动”转化成一个可重复的低成本动作。5. 上线前我集中处理的三个稳定性问题5.1 流式输出在小程序端不流畅改协议后效果好很多Agent 和小程序结合的一个技术痛点是流式输出。我们后端用的是 SSE 协议在 Web 端表现很好但小程序端的原生 WebSocket 方案对 SSE 的支持需要自己做封装而且小程序网络库对长连接有超时限制连接一断整段回答就卡住不动了。最后我做的改造是后端输出结果统一包装成 WebSocket 消息类型分 token增量文本、status状态变更、error异常前端收到 token 事件后逐字渲染。连接断了以后自动重连并向后端请求最近一个“已确认序号”之后的增量数据保证回答不丢、不重。这套断点续传逻辑加完后弱网环境下的完成率提升了非常多。这里提醒一句小程序前后端联调时一定不要只在开发者工具里测真机测试在弱网下的问题暴露得非常明显尤其是流式输出这种对网络敏感的功能。5.2 高并发下重复请求和排队丢消息上线当天来了一个小高峰后台发现同一个用户发送一次提问却产生了三次 Agent 请求。查了半天问题出在前端用户在输入法确认后点击发送键盘收起事件和按钮点击事件同时触发导致 send 被重复调用。这算是一个很典型的小程序低级 bug解决方案是给发送函数加一个 pending 锁发送中直接忽略后续调用同时在服务端按 requestId 做幂等去重。另一个高并发问题是“排队丢消息”。WebSocket 连接建立后如果后端 Agent 引擎还在处理上一个请求新的请求就会进入队列。之前队列的长度没有上限高峰时直接挤爆用户看到的就是“发出去没回应”。后来做了一个明显的状态提示当队列积压超过 10 条时前端直接显示“前面还有任务排队中”禁止继续发送并在队列清空后恢复输入。这个改动很简单但用户体验比假装“已收到”好得多。5.3 微信审核与合规称加包体积、称号规避、类目资质微信审核是每个小程序团队绕不开的坎。这次因为涉及 AI 对话审核明显比普通工具类严格。第一次提交被驳回的原因是“服务内容涉及智能对话需要补充相关类目资质”。我们准备了 ICP 备案、服务协议和内容安全说明第二次提交才过。包体积控制是另一个硬指标。小程序主包限制 2MB分包限制 20MB我们的对话页面、训练页面、知识库页面全部拆成了分包。图片资源全部走 CDN 压缩不在包里放任何大图。HBuilderX 编译出来的 uni-app 项目有个特点引用的第三方库即使只用一个函数也可能整包打进去。所以我自己写了个脚本在编译前做一次依赖清理把没用到的大库移除掉。还有一点值得注意用户训练的 Agent 在生成内容时存在不可控的内容风险。这不仅是审核层面的风险更是产品运营层面的风险。我们在发布 Agent 给他人使用之前增加了一道“内容安全扫描”模拟对话几个预设问题检查输出是否存在违规倾向。虽然不能 100% 拦截但至少可以在审核和用户举报之间多一道缓冲。6. 这版上线只是开始Agent 的更多宿主与模板生态6.1 同一套 Agent 引擎可以接微信公众号和企业微信“训练师 Agent”上线以后我最想做的下一步不是增加更多训练玩法而是把同一个 Agent 引擎移植到更多宿主上。小程序的流量和推送能力有限微信公众号的客服消息就是另一个天然出口。如果用户把训练好的 Agent 绑定到公众号用户在对话框里发消息就能触发 Agent这对商家来说价值极大。企业微信的场景更偏向内部知识助手和客户运营。很多用户问过我能不能把训练好的 Agent 接入企业微信让客服同事共用同一个知识库。从技术上看Agent 引擎已经是标准的 HTTP WebSocket 服务新的宿主只需要把收消息、发消息的协议适配一下。真正的难点在于各宿主平台的内容合规要求不同所以“一次训练、多端发布”是后续版本的核心功能但我不会为了赶进度把规范适配做糙。6.2 模板广场把“训练过程”变成可复用的产品用户训练 Agent 的过程其实可以被模板化。我在后台看到很多用户会创建类似的角色比如“雅思口语陪练”“健身饮食顾问”“产品卖点问答”。如果把这些高赞的人设配置、知识库结构和规则组合做成模板用户可以直接一键复制并深度定制训练门槛会进一步降低。这也会带来新的商业模式。未来可以支持模板付费、训练成果分享、团队协作训练等能力。小程序里现有的虚拟支付能力会在这里发挥作用。不过在商业模式跑起来之前我更想把“训练闭环”的底层体验做好让用户真切地感受到 Agent 在持续变聪明而不是只是换了一身漂亮的对话外壳。最后说一个我反复验证后的体会Agent 类小程序能不能留住用户核心不在模型参数也不在界面多炫而在“用户每一次不满意的反馈是否真的让 Agent 变得更好了一点”。这句话听着简单但每一个环节——从反馈采集、记忆更新、知识库维护到内容安全过滤——都需要砸大量工程。小程序只是宿主真正的产品其实是背后那条不断进化的训练链路。训练师 Agent 上线的第一周让我确认了一件事普通人完全有能力训练出自己专属的 Agent只要产品愿意把复杂留给自己、把简单留给用户。