我们把给不同产品单独写的 AI 客服，做成了一个通用产品

最近把这段时间做的东西整理了一下，想发出来跟大家聊聊。

简单说就是，我们早期一直在给不同产品单独写 AI 客服，后来发现这条路越走越重，于是干脆把这件事做成了一个通用产品，叫微林智能。

一开始遇到的问题

最开始的做法很直接：一个产品写一套 AI 客服逻辑，按各自的页面结构、业务流程和数据规则去适配。

前期能跑，但系统一多，问题就很明显了：相同能力反复实现，公共逻辑很难复用，一个功能改动往往要在多个项目里重复修，代码量和维护成本都越来越高。

后来我们慢慢发现，问题不在于要不要继续做下一套 AI 客服，而在于一直没有一套更省事的通用做法。

现在怎么做

我们现在的思路很简单：把通用问题和业务问题分开处理。

• 智能体负责角色、人设和回答边界
• 知识库负责承接产品说明、FAQ 、操作文档这类静态内容
• 外部工具负责接业务接口和实时数据

这样做的好处是，常见问题可以直接靠知识库回答，跟具体业务状态相关的问题再通过工具去处理，不用每个系统都从头再写一遍。

这 5 个多月做到什么程度了

去年 12 月立项到今年 1 月发布了第一个内部测试版本，到现在已经更新了 5 个大版本。

这几个月我们基本就在反复做一件事：根据真实反馈一直改，把“能演示”慢慢做成“真能用”。如果粗略量化一下，最开始它大概只能解决 20% 左右的问题，现在已经提升到了 95% 左右，基本能把大部分问题处理掉。

数据安全和模型

这个问题大家一般都会问，所以也直接说。

目前我们所有的 AI 端点都采用自部署硬件，数据都在我们自己手里，不依赖第三方托管推理服务。简单说，核心请求不会跑到外部公共服务上去。

模型这边现在主要是两条：主要请求由 qwen3.6-35b-a3b 处理，一部分请求由 gemma-26b-a4b 处理。我们平时也会持续比较不同模型在不同问题上的表现，再决定后面怎么调。

为什么现在拿出来分享

因为做到这个阶段，我们觉得它已经不只是一个概念产品了，而是一个已经在真实场景里反复改过、也基本能解决问题的东西。

如果你们也在做类似的事情，也在想怎么把 AI 更稳地接进现有系统里，那微林智能也许正好能帮你们省掉一部分重复工作。

有兴趣的话可以直接看下：https://www.vxai.link

也欢迎直接提问题。