「群机器人用什么方案」这个问题，八成的讨论停在「哪个上线更快」。但群机器人是那种一周就能上线、之后要活三年的东西 —— 决定总成本的不是第一周写多少代码，是接下来三年谁在维护登录态、谁在跟进平台侧的变化、谁在出事那天被叫醒。这篇把自建、开源、平台三条路按维护面摊开比，末尾给一段能照着走的决策顺序；讲到平台那一档的具体形态时，以 wecomapi 这类网关式接入作为参照。
先排除一种：只发不收，不用做这道题
如果需求只是把告警、审批结果、日报推进群里，群里说了什么完全不需要被系统听见，这道选型题根本不用做 —— 群内的 Webhook 型机器人就是为这个设计的：一个地址，POST 一段内容，结束。别为了架构完整性给它套一整套接入方案。
有一种介于中间的需求容易被误判：群里的消息需要被读，但不需要被回 —— 把客户群里的关键问题同步到工单系统、统计群活跃度都属于这类。它同样得走能收消息的方案，只是业务层不发消息而已，选型上和「能收能发」是同一档。
分界线只有一句话：需不需要收消息。一旦出现「群里回复关键词要触发流程」「入群要打标签」「群成员变化要同步到 CRM」，只发不收就到头了，才轮到下面三条路。
多数公司同时存在两类群，而它们通常正好落在这条分界线两侧：内部通知群绝大多数只需要往里推消息，客户服务群才需要收。所以第一个动作不是整体二选一，是按群的性质分开 —— 内部群走 Webhook 型，客户群走下面三条路，两边共用一份话术模板和一份告警规则就够，接入层没有必要统一。只有当内部群也需要对话式交互（在群里问一句就查到订单状态），合并才划算。
先量一把尺子：它挂了，多久会有人知道
在比较三条路之前，先回答一个问题：这个机器人停止工作，多久会被发现，那段时间的损失有多大。内部通知群里的机器人挂了，半小时内一定有人在群里问一句；客户群里的应答机器人挂了，可能一周都没人说，因为客户不会追着一个没回应的群喊人，他们只是不再问了。
这个数直接决定该往哪一档投。发现时间以分钟计、损失可忽略的，三条路随便挑最省事的那条；发现时间以天计、期间在持续掉客户的，那么「谁负责让它一直活着」就是整道选型题的主轴，其余都是次要指标。多数团队在这一步就已经能把选项砍掉一半。
顺带一提，无论最后选哪条路，都要有一个独立于这套系统之外的存活探针 —— 定时往一个内部测试群发一句，确认能收到回声。这条探针的开发成本大概是一小时，它兜住的恰好是最贵的那种故障：悄无声息地停了。
三条路的差别在维护面，不在开发量
自建、开源、平台，三条路的业务代码量其实差不多。差别在四块长期成本各自落在谁头上：接入层的稳定性、登录态与掉线自愈、能力边界随平台演进、以及合规的解释权。
- 自建：四块全在你身上，换来的是完全可控和没有第三方依赖。
- 开源：接入层的代码你拿到了，维护责任也一并拿到了 —— 上游停更或者改方向时，你手上的是一份需要自己养的分叉。
- 平台：前两块交出去，第三块变成对方的文档更新，第四块变成一份可以拿去过评审的服务条款；代价是链路上多了一段你不掌控的依赖。
拿这四块去问供应商、去评估开源项目，比问「支持哪些功能」有用得多 —— 功能列表都长得差不多，区别在出事那天谁负责。走自建的时候，被问的那个人就是你自己；答不上来说明这块成本还没被估进去，而不是它不存在。
四项之外还有一块隐性成本：出事时的沟通路径。自建时你自己翻日志就行；用平台，定位一次问题要跨一次组织边界。这段时间差写在合同里叫响应时限，实际体验取决于对方的支持质量 —— 问一句「上一次线上问题多久给的结论」，比看那个数字有用。
自建：三个信号，以及那个中间选项
值得自建的信号很清楚：业务逻辑重到没有现成产品能表达；机器人要和内部系统深度耦合，权限、审批、数据都在内网；团队里有人能长期负责这块，而不是做完就换项目。三条同时成立，自建是对的。
「有人长期负责」这条有个很直接的检验方式：这个人休假两周，机器人半夜掉线了谁处理。答不上来就是没有，别拿「大家一起看着」搪塞过去。
不值得的信号同样清楚：需求是标准的客服应答或者通知推送；没有专职维护的人；上线时间以周计。这三种情况下自建的典型结局是第一版跑通、第二个月没人管、第三个月悄悄挂掉还没人发现 —— 正好是上一节那把尺子量出来最贵的那种故障。
最常被忽略的是中间那个选项：业务层自建，接入层外包。机器人的价值几乎全在路由和业务逻辑里，成本却几乎全在登录态维持、掉线自愈、消息投递这些底座上。用 wecomapi 这类网关承接底座、自己写业务层，是不少团队兜一圈之后落到的形态 —— 编排逻辑没有交出去，也不用自己养一套接入设施。
开源：三个隐藏成本
- 1能力边界不由你决定。你需要的那个能力，上游要么已经有、要么永远不会有，中间没有可谈的空间。真要加就得自己往里改，并承担每次上游更新后的合并成本。
- 2活跃度就是你的安全响应速度。看提交频率、看 issue 有没有人答、看上一个安全问题多久修好的。半年没有提交的项目，应当当成一份要你自己接管的代码，而不是一个可以依赖的依赖。
- 3合规审查提前做，别等法务来问。选型时先确认项目走的是官方或者合规的接入方式，任何涉及绕过平台机制的项目一律排除 —— 这不是风格偏好，是能不能上生产的问题。
结论：开源适合原型、内部工具和技术验证，这几种场景下性价比无可替代。对客生产环境里，除非你已经打算把它当自己的代码来养，否则风险和收益不成比例。
真要用，就当代码而不是当产品：锁版本、在自己仓库里留分叉、把改动写成可重放的补丁而不是直接改文件，并且指定一个人跟上游。这几件事做了，开源的成本才是可预期的；不做，它的引信长度取决于上游哪天改了什么。
平台：省的是运维，锁的是编排
平台这一档省掉的正好是最难长期做好的那部分：账号在线、掉线自愈、投递重试、可观测。以 wecomapi 的接入形态为例，登录态维持与异常自愈收在网关侧，你这边只面对一套 REST 接口和事件回调。这些东西写一遍都不难，难在三年里持续保持。
它也有明确不适合的场景：机器人要读的内网数据不允许出网、业务对端到端时延有硬要求、或者你们本来就养着一支在维护同类基础设施的团队。这三种情况下，多一段外部依赖带来的麻烦会盖过它省掉的运维。
减轻锁定的办法不是不用，是把边界划清楚：业务规则、话术、路由表、客户数据留在自己这边，只把「收消息」和「发消息」这两个动作交出去。这两个动作的语义足够窄，窄到可以用一个几十行的适配层包住。
// 示意接口，字段与返回结构以线上文档为准
interface GroupChannel {
onMessage(handler: (evt: NormalizedEvent) => Promise<void>): void;
sendText(group: string, text: string): Promise<void>;
}
// 平台实现：POST https://manager.wecomapi.com/message/sendText
// 自建实现：换成自己的接入服务，业务层一行不改有了这一层，换方案的成本从「重写机器人」降到「重写适配层」。它顺带也提示了评估价格的正确方式：算的是替换成本和维护人力，不是每月调用量 —— 按账号订阅、订阅内不限调用次数的计费模式下，调用量本来就不是变量，账号数才是。
决策顺序，以及两种常见错配
- 1只需要往群里推消息吗？是 → Webhook 型，到此结束。
- 2它挂了多久会被发现？以分钟计就挑最省事的；以天计，先回答「谁让它一直活着」。
- 3有没有人能长期维护接入层？没有 → 直接排除自建和「开源自养」。
- 4对客生产还是内部工具？内部工具可以接受开源；对客生产按能力边界和合规两条硬指标先筛一遍。
- 5业务逻辑有多重？重到要和内网系统打通，就业务层自建、接入层选平台。
- 6无论选哪条，先把适配层划出来。这个决定几乎没有成本，却让上面五条在半年后都还能推翻重来。
常见的错配有两种：拿开源方案直接顶到对客生产，以及用平台跑完原型之后为了「省钱」全面自建。前者的账记在合规和安全响应上，后者的账记在人力上 —— 自建省下的订阅费，通常不够付维护它那个人半年的工资。两种错配的共同点，是把一次性的开发成本和持续的维护成本放在同一个天平上比，而这两样的量纲根本不同。
以上都是路线层面的判断。具体的能力覆盖、计费方式与接入约束以 wecomapi 线上文档与服务条款为准，选型阶段建议在预发环境实测一遍再拍板。
常见问题
- 开源的群机器人方案能直接上生产吗？
- 内部工具和原型可以，对客生产要先过两关：项目走的是不是合规的接入方式（涉及绕过平台机制的直接排除），以及上游是否还在活跃维护。两关都过，也要按自己的代码来养，包括安全更新。
- 自建是不是一定比买现成的贵？
- 开发阶段未必，长期一定要算维护人力。真正的账在登录态维持、掉线处理和跟平台演进的适配上，这部分工作量不随业务增长而下降。把这三样折成人力去比，再决定要不要用 wecomapi 这类现成的接入层承接底座。
- 以后想换方案，成本主要在哪？
- 在你有没有留适配层。业务规则和数据留在自己这边、只把收发两个动作抽象出去，换方案就是替换一层实现；如果业务逻辑直接写在某个框架的回调里，那就是重写。wecomapi 这类网关式接入的 REST 语义比较容易被包在适配层后面。
准备好动手了？
精确字段、鉴权与端点以线上文档为准；可在控制台创建密钥后联调。