一、背景

组内推荐活动有统一的框架和配套平台，活动上线前后除了功能开发之外，存在不少需要人工介入的重复性辅助工作。比如咨询协议、中间组件配置、上传白名单、活动逻辑细节确认、发送测试请求、查询服务部署、排查日志错误原因等等。

我之前维护过一个基于企微群机器人的辅助工具，沉淀了一些能力，并接入大模型来承担个人部分重复性工作。

企微智能机器人和 CodeBuddy CLI 等基础设施的升级，为机器人能力的系统性扩展提供了支撑。

在以上三个背景下，我收集了推荐活动上线前后的重复工作列表，将需要人工沟通、多个平台上的操作沉淀成工具，搭建 AI Agent 服务，将活动、工具、会话上下文进行整合，最终以智能机器人的形式，对开发、测试、产品同学提供活动上线前后的智能辅助。

二、推荐活动助手能干什么

这是一个面向推荐活动开发与运营支持的企业微信群机器人，不仅能进行简单的功能操作，还能编排功能工具完成复杂的任务。

考虑到企微会话通常围绕某个活动展开，所以使用功能之前，要先将会话跟活动绑定。绑定之后，会获取项目开发平台(lingqu)、部署平台(koala)、运营平台(KP)、实验平台(iegab)、工蜂仓库地址等信息。同时，会触发最新代码扫描，产生服务协议、基础逻辑、中间组件查询方式并记录，初次扫描通常会在3～5分钟内完成。

绑定之后就可以放开进行操作了，这里简单列一下我们的常用场景。

• 获取协议、配置、关联平台信息
• 逻辑细节问答，基于最新代码、配置，利用 CodeBuddy 进行逻辑问答
• 不暴露中间件密钥，查询中间件内容，比如 Redis 中某个 key
• 获取请求返回白名单模板文件，设置和查询白名单
• 实验白名单分组查询与设置
• 线上部署规模和环境变量、服务状态、QPS、成功率拉取，上线前持续值班监控
• 捞取指定条件的日志，并分析错误原因
• 发送测试请求、简易 mock、生成测试要点

功能截图太多我拼装到一个图片中，可放大观看。更详细的用法，可以看使用文档。

机器人能够根据上述工具，自己进行 Plan，这里就能衍生出更智能的用法。比如你要求他发送一个测试请求，如果返回错误，他可以自己捞取错误日志、结合代码分析失败原因：

三、整体架构

这个服务的整体架构大概是下边这样，后边我来详细解释。

3.1 接入方式

这里选择接入智能机器人，使用的是我找 AI 简单封装的长连接框架。接入过程中还了解了「企微群机器人、智能机器人回调、智能机器人长连接的区别」，欢迎点击查看。

另外为了方便，这里还提供了 MCP 的接入方式，可以直接通过 CodeBuddy、Codex 等进行对话，不需要非得通过企业微信。

3.2 IDC 上部署服务

上面文章中有介绍过，使用企业微信智能机器人，其实可以部署在任何环境的，包括 DEV、IDC，甚至是个人的办公网络，因为网络层上服务通过 WebSocket 向企业微信服务器建立连接，在协议层上「监听」企业微信发来的用户@消息。

但这里为什么我们要放在 IDC 环境呢？因为我们需要请求测试环境服务、访问周边平台、访问中间件，这些都依赖公司内网。另外 IDC 环境部署会更稳定一些，权限边界也更清晰。

服务内部主要是一个 ReAct Agent 模块。将当前活动的所有 cmd_* 方法注册为 OpenAI function tools，注入业务规则约束 LLM 行为，然后 LLM 以 ReAct 方式循环：理解意图 → 调用工具 → 观察结果 → 循环（最大 7 轮）。同时会将多轮对话历史存储在 Redis，按 chat_id 隔离。

3.3 Dev Bridge：IDC 与 Dev 机的通信通道

我们的机器人需要扫描分析代码，如果只使用 IDC 环境，是无法拉取工蜂仓库代码的。

最开始的时候，我是通过 IDC 触发蓝盾 CI 流水线来实现一次性的代码扫描，但是之后的问答就会显得很死板。

为了更好的效果，后来改成了自己申请一个 DevCloud 的机器，部署一个 Agent，并在 IDC 服务上开启监听。Agent 同样通过 WebSocket 的方式与 IDC 服务建立通道，可以接收来自机器人服务转发的指令。

Agent 接收到指令后，可以执行 Dev 环境特定的操作，比如拉取代码仓库、提工蜂 ISSUE。在此基础上，再触发 CodeBuddy CLI，实现逻辑问答和异常日志排查等功能。

3.4 Tool 和第三方渠道

在 Agent 开发中，一个常见问题是：哪些能力应该沉淀为 Skill，哪些能力应该封装为 Tool？

我的理解是，Skill 不是单纯写一个 md 文档就结束，通常还需要元数据、资源声明、脚本/工具、权限配置和运行时配合。

我这里把调用中间平台、组件的能力封装成 Tool，而不是只描述访问方式让大模型自己生成访问脚本，是因为这本质上是在把外部系统的操作抽象成受控函数，再由 Agent Runtime 根据上下文选择调用。

要让这个机器人智能，前提是安全性和权限边界要先定义清楚，否则 Agent 能调用工具以后，风险会比传统脚本更大。

同时，我这里还配置了可以根据 LLM 将消息路由到第三方渠道的能力，配套的支持第三方渠道拿着我们分发的凭证回调接口，发送消息到群里或者给具体的用户。

四、架构之外

4.1 权限与安全控制

这里给所有人都能使用的机器人，权限控制一定要处理好。在此简单列举一下，我这里设置的安全措施：

• 工具中做硬性限定，比如发送请求，只能往测试环境进行发送，这些可以通过网关命名检测进行判断
• 敏感指令权限授予：一些设置白名单的敏感操作，需要得到项目开发的主动授权才能执行
• 高危命令拦截：删除所有白名单等危险命令需二次确认，才会执行
• 渠道转发签名验证：前面提到的消息转发到外部渠道时，使用 HMAC-SHA256 对 {chat_id}:{ts} 进行无状态签名，凭证有效期 1 小时，防止伪造回调

4.2 审计与统计页面

机器人对外服务后，需要了解谁在用、用了什么、用得怎么样，因此设计了配套的审计与统计能力。

使用统计采用「埋点 + 按需计算 + 缓存」三层模型：

• 埋点层：每次命令执行后，将 (date, user_id, service_name, cmd) 写入 Redis List，TTL 30 天；
• 计算层：按用户 / 活动 / 指令维度聚合，支持查看各群、各活动、各命令的使用频次；
• 缓存层：今日数据 5 分钟缓存复用，历史数据最终化后永不重算，避免重复聚合。

统计结果通过独立 HTTP 接口暴露，不走机器人对话路径，可被外部系统集成，也提供了一个可视化统计页面供管理员查看。

你可能会注意到，这里还有一个节省时长（估算）的标签。这里对每个命令预先标注了"单次节省时长"的经验估算值（比如生成测试要点 20 分钟、更新一次白名单 3 分钟、代码逻辑确认需要 10 分钟等），然后将所有命令的调用次数乘以对应时长累加，换算成小时数展示出来。这个数字当然是估算，不是精确计量，但它能直观反映机器人替团队省掉了多少重复性人工操作。

4.3 引导使用

我这里开发并发布机器人之后，首先产生了一个 Help文档，发送给了开发、测试和产品同学。

文档里引导大家通过搜索跟机器人对话，但是过了几天也没有看到新增用户。后来有同学反馈说，搜不到机器人——可能是企业微信为了避免机器人太多影响真正的搜索，只有跟他聊过天，才能搜索。

这就陷入了一个循环，新用户没用过，就一直没有机会使用。于是，我就单独通过分享名片的方式给大家发了消息。

还参考了混元3等一些用户体验反馈群的方式，创建了一个体验群，并在 Help 文档上加了一个飞鸽传书链接，点击后可以直接进群。

五、下一步优化

根据同学们的反馈，机器人的自主性还可以进一步提高一下。

比如下边这个例子，测试同学想问某几个值的内容，机器人后台调用逻辑问答能力，查到了来源，并且知道这些值来自「Koala部署的环境变量」，于是询问是否需要帮忙查询。其实这种情况，可以给机器人更大的弹性空间，让它在确认风险可控后继续完成后续动作。

后续希望把机器人从“能调用工具的助手”进一步升级为“能围绕活动目标完成闭环的 Agent”：在权限可控、过程可审计的前提下，主动串联代码理解、环境查询、测试请求、日志分析等能力，减少开发、测试、产品同学在重复沟通和跨平台操作上的时间消耗。