1.2 方案对比：规则客服、大模型 API 直连与智能体平台

目标定了，接下来是选型。CEO 丢给我一句话：你看网上人人都在搞 AI 客服，咱们也搞一个。真正到要落地的时候，摆在我面前的其实只有三条路：继续养规则客服系统、自己写代码直连大模型 API、或者上智能体平台做编排。我把三条路的代价和坑都自己趟了一遍，这里一笔一笔算清楚，免得你以为我是拍脑袋选的。

在动手对比之前，我先给自己立了个规矩：每条路都要真正跑起来测一下，不能只看宣传。所以每条路我都做了原型验证，有的写了两三天代码，有的只花了一下午配置。下面的小节里我会写清楚每条路给我的实际感受，而不只是表格里的空话。

三方案对比

先上结论表，后面再逐条展开。这张表是我们技术部内部评审时用的，评分维度是我跟客服组长一起定的，每一格的依据都写在下面三小节里。如果只看一栏，我会建议看维护成本——搭建成本是一次性的，维护成本才是每个月都要还的债。

规则客服：维护关键词库的痛苦

我两年前给公司搞过一个半手工的规则客服：用户消息里命中关键词，就吐对应的话术。上线第一周效果惊人，因为当时问题就那么几类，命中率直奔九成。第二个月就开始痛苦了——产品一迭代，关键词就失效，客服回头把新说法一条条加进库里。更难搞的是用户不会按你的词说话，问导出功能，有人说导出，有人说下载，有人说存成表格，一个人一个说法，关键词库越加越臃肿，同义词层层叠叠，命中率反而往下掉。

到最后，这个库只有客服组长维护得动，因为只有他知道客户最近在用哪些说法。热点一过，整套东西就成了摆设，工单该多少还是多少。

还有一组数字更能说明问题：当年我们关键词库里有 400 多条规则，客服每周要花两个小时维护，而命中率从巅峰时候的八成慢慢滑到四成——因为客户问法在变，产品的功能也在变。规则系统本质上是鼓励你少改产品，这在 SaaS 公司简直是反着来的。我后来跟同行交流，踩过这个坑的不止我们一家，关键词库最后都长成了没人敢动的祖传代码。我们现在的工单量是当年三倍，问题也分散得多，规则客服根本接不住。这条路的教训我记了很久：靠人工维护规则，规模一上去必定崩。

大模型 API 直连：没有知识库就会胡说

第二个月我自己写了段后端代码，直连大模型的 API，把官网常见问题一股脑丢进去测试。结果很分裂：它回答得特别流利，态度也好，但经常一本正经地编我们产品没有的功能。客户问能不能批量导入联系人，它不仅能，还能给你详细描述出一个并不存在的导入入口和参数说明，说得比真功能还真。同事看了都说：这要是放官网，用户照着操作失败了，投诉可比没人回答还狠。

原因很直白：模型只知道公开语料里的一般知识，不知道我们公司的产品细节，它的本能是把话说圆满。要不让它胡说，就得自己搭一套检索流程：把文档切片、向量化、检索 top-k 相关片段、拼进提示词，再加超纲兜底和来源引用。这些活每一件都得自己写、自己调、自己保障可用性，向量服务的稳定性也是自己的事。我不是不能写，但算算时间，至少两周起步，而且上线之后这套流水线还是得我一个人维护，出点奇怪的检索不命中，排查链路能折腾一整天。

更麻烦的是多轮对话和转人工这些闭环功能：用户上一句问了套餐 A 接着问能开发票不，系统得记得上下文；答不上来要平滑地收尾并交给人工，而不是突兀地报错或者无限兜圈。这些每一样都要单独设计和编码，代码量加起来比检索流水线本身还大。我做了两周原型，功能能跑，但离敢放给官网客户用的标准还差得远，心里已经清楚这条路对五人团队不现实。

我硬着头皮评估如果把原型补齐到能用要多久：检索流水线再磨一周，多轮记忆和兜底分支一周，权限和日志一周，还不算上线后每天盯着的精力。这还不包括模型本身的费用波动——我一个人调提示词的 token 费，两周烧了一杯星巴克的钱，虽然不贵，但量级上去之后会是持续支出，老板会盯。综合算下来，这条路单看功能是可行的，死在工程量和持续维护上。

选什么模型也很纠结，公开模型各有脾气，有的便宜但上下文短，有的聪明但贵。DeepSeek 工具链里讲模型怎么选、怎么测，我当时就是照着那个思路过了一遍候选模型，心里才有底。

顺带一提，裸调 API 这条路最适合的场景恰恰是做技术验证：我先写五十个高频问题，直连模型批量跑，把回答人工打分，得出基线数据，之后换任何方案都拿这五十题做对照。这个基线在后续几篇里会反复出现，是我衡量每一步改进有没有用的标尺，建议你也弄一套，迟早用得上。

智能体平台：编排省事，把精力留给业务

第三条路是上智能体平台。我最初是抵触的：平台听起来贵，而且总觉得被绑定不灵活。后来实际试了试，思路变了。平台把通用流程做成了编排画布上的节点：知识库节点负责检索上传的文档、大模型节点负责生成、工具节点对接业务接口、条件判断节点做分支、转人工节点负责兜底。我们要做的只是在画布上把这些节点按业务流程串起来，而不是从零写流水线代码。

真正要写的业务代码其实只有订单查询那几个接口——这些本来就要写，不论走哪条路。平台帮我省掉的是文档切片、向量索引、提示词拼装、多轮上下文管理这些重复建设，还能直接在调试预览里对话调通，再一键发布成 API。对五人小团队来说，不必自己造轮子才是正经事，省下来的精力够我把业务侧的订单接口写得稳一点。这个随改随测的体验也挺重要：自己写代码时，改完流水线得额外搭测试脚本验证，平台上是现成的。

也不用担心被平台绑死：查询订单、查价格这些业务能力本来就是我自己服务上的接口，平台只是调用方；知识库的原文我一直留着自己的备份在对象存储里。哪怕哪天换方案，数据和接口都还是我的，迁移成本可控。

第一次在编排画布上把问答链路跑通那天，我专门拉了老周来看。他不懂代码，但一眼就理解了界面上的流程走向：用户问题进来，知识库先查，查到就回答，查不到走兜底转人工。他说这是他第一次感觉看得懂的技术方案。这个细节很重要——客服组长能看懂流程，意味着后续的知识维护和答案审校他能参与进来，而不是完全依赖我。这种业务侧的参与度，是我后来整个项目推进最依赖的东西。

后来真正打动我的还有一个现实因素：选型那阵子ADP 智能体开发平台正好有新客活动，门槛比我想的低，我先开了个账号自己试了两周，确认客服场景跑得通、知识库和转人工的闭环都顺，才拿到团队内推。官网访客从哪来、官网服务器怎么选这些底子，我参考的是轻量建站实战。

结论：我们选了第三条路

三条路不是谁替代谁，而是适用阶段不同。规则客服适合问题极度固定、量级很小的场景，比如一个只有一个入口的静态页面；直连 API 适合快速验证想法，写个 demo 给老板看；但要做真正可用的企业客服，知识库管理和工具调用绕不开，这两件事恰恰是最吃维护成本的。

我们最终落在智能体平台上：用平台编排流程，业务逻辑和数据接口还是掌握在自己手里，出了问题自己能修，维护成本也在五人团队能承受的范围内。如果你们团队人更少、技术栈更单薄，这个结论只会更成立。反之如果团队里有专门的同学愿意造轮子、也养得起，自己搞也未尝不可，选型从来是算账而不是站队。

回过头看，选型真正难的从来不是技术对比，而是抵挡住自己动手显摆技术的冲动。自己写一套 RAG 流水线当然更酷，讲出来也更有料，但对客户和团队而言，更快且更稳地解决问题才是本职。这个心路历程，我后来跟好几个来问选型的同行都聊过，大家的结论出奇一致。

还有一点要提醒：平台上手快不代表不用懂原理。切片为什么要有重叠窗口、top-k 为什么太大会引入噪声、提示词为什么要兜底，这些原理性的东西后面每一篇都会讲，平台帮你省的是重复劳动，不是省脑子。一句话：选平台不是因为平台酷，是因为我们把人力想花在业务上。定了路子，下一步就是开账号、算预算。

延伸阅读

• 智能体开发过程中我用 AI 编程工具提了不少效，看Claude Code 指南。
• 底座服务器和云数据库那些事，看腾讯云五件套实战。