写于 2026-10-10，2026-10-12 定稿
今年 6 月到 10 月，我做了一个客服 AI 助理项目，这个 Agent 搭在钉钉的 DEAP 平台上，核心功能是帮售前和售后客服查规则、准备对客回复。10 月初它以公测版开放给客服使用，获得了比较好的效果：在没有大力推广的情况下，外包客服的用量一周涨到近三倍，近八成账号会隔天再回来用。
现在项目到了要结项的时候，我开始回忆过程中的一些经验教训，并记录下来。这个项目里的经验教训，大概可以归到四个方面：定义问题、方案设计、交付与维护、团队协作。想到哪里就写到哪里，核心体会还是欲速则不达，不要雕花。
Agent 是非常好用的 meta tool，但无法取代产品 taste，没有产品品味，用 Agent 也只是“屎上雕花”——这里的雕花和精益求精有本质区别，指的是问题没定义清楚，就围着某些约束做局部适配，这些适配短期有效，但可扩展性不强。当然我也不例外，我们总是有太多的想法要实现，但大部分想法本身确实是伪需求。现在我逐渐意识到 less is more——简单、可扩展非常重要。
一、定义问题
做一个 Agent 项目，实际上是想满足某些用户的需求。这里的用户可能有好几类，需求各不相同，要先搞清楚每一类要什么，再权衡怎么满足。
客服 Agent 这个项目至少有三类用户。高管看的是整个项目的意义，核心需求是要有样板项目，需要在整个部门打样；业务负责人需要真实落地，关注的是人效、成本等指标；执行层的一线客服，关注的是 Agent 本身好不好用。
这个知识库 Agent 最初的目标是提高客服们的接线效率，当时想的是可以为一线客服解决同时接线很多用户的麻烦。这个想法非常自然，因为在前期我已经系统了解了业务资料，整理了组织架构和工作流，和业务负责人进行了反复核对，这个需求本身也是来自于负责人——他希望解决客服们接线效率低、回答容易错的问题。
所以我没有专门花时间验证需求真实性——访谈一线客服，主要是基于两个原因，一是觉得访谈一线客服能获得的信息有限，二是项目时间压力比较重，我希望尽快把东西做出来。
现在看，这是不对的，找需求不能着急。我直接根据负责人的描述和一些文本信息就开始做了，没有去了解一线客服的想法，后面走了很多弯路，如果前期了解更多信息，其实这些弯路本可以不用走。举个例子，在 Agent 的设计上，前期做得太工程化。我们在开发时追求完整、安全、可追溯，客服在接线时就要多读、多复制、多核对。但真正用起来之后，客服在意的事情是：能不能快点拿到对客草稿，为什么反复追问，来源能不能直接定位，售后排障有没有漏步骤。在开发时做的很多权衡取舍，回头看来都做错了，对真正的用户来说，很多都是不必要的，过度设计增加了很多成本。
公测数据显示，总部的老客服们对这个 Agent 没有很强的需求，真正在大量用 Agent 的是外包客服。在没有大力推广和培训的情况下，总部客服用钉钉端，每周大约 200 条，几乎没有变化；外包客服用网页端，一周从 219 条涨到 649 条，用得更频繁了。从问题分类看，外包客服问得最多的是型号、功能、翻译、配对、对比等产品相关的知识。
我认为原因是新老客服有熟练度差异。调研下来，老客服已经比较有经验，有自己的话术库和快捷键，对现有的工作方式比较习惯；而我们的 Agent 回复相比快捷键还是慢了些（一次对话的回复时间大约是 6 s），目前在线客服一个人同时接线 5~10 个客户，很多老客服经验充足，不用 Agent 也能忙得过来。但新客服有极强的提效需求，同时接待 5~10 人对新客服挑战很大，而这个 Agent 能够帮助他们快速渡过新手期，快速上手，达到及格标准，所以他们会高强度使用。
在公司层面，我们系统性提高了客户服务部的下限——客服这个行业人员流动非常快速，我们总是有大量的新客服需要快速培训上岗。
但解决了真实用户的需求不等于解决了负责人的需求——负责人要的是人效，从工具产生到人效提升，中间有很大的 gap。业务负责人的痛点是客服的人效不够、培养成本高、客服回复不规范等问题。我们预想的情况是做出来 Agent 之后，我们可以用同样的人数承接更多的业务，比如一个客服可以借助 Agent 的帮助承接 15 人以上的接待量。
但接待量在短期内并未显著提高，外包新人主动用起来，是因为他们同时接线的人数太多，处理不过来，用 AI 可以省下时间，节省精力，好处是落在自己身上的。但省下的时间要变成公司的人效，就是另一回事了。在 AI 提效的过程中，很多人都会遇到一个问题——用 AI 省下来的时间是自己的吗？
大部分企业仍然在按“计时工资”的方式实行雇佣制度，省下来的时间并不归自己所有，反而会让自己的工作量变大。所以一线的提效和管理层想要的提效是不一样的：一线是为了让自己省时间、省精力，管理层要的是同样的人承接更多业务。回到客服这个案例上看，从一个提效工具最终变成客服的人效，需要靠排班、编制、业务量这些管理动作来解决，这些流程上的问题短时间内是不容易改变的。
管理层要的是链条末端的结果，而做工具的人手里只有链条的第一环，经验又无法准确传递，所以落地的效果与工具的“好用程度”往往没有太大联系。要解决这些问题，可能需要一个有权力、有愿景、懂技术的人，用系统设计的思路整体去看待问题，多方面优化才能形成全面改善。而大部分 AI 提效工作，往往很难做到整体的规划设计，能动的通常只有工具这一块，这可能也是 FDE 们面临的困局，我们只能认为工具本身提供了“选择权”——有了工具后，我们具备了提效的必要条件。
二、方案设计
方案上，我犯了和定义问题类似的错误：太着急在一个平台上跑起来，结果被平台反向拟合了。
其实这是一个选择问题：我们到底是只做一次，还是以后可以更多地复用这些基础设施？
技术上，我觉得我们是过拟合的。当时是为了适配平台的 RAG（黑盒子）算法，我们设计了一个转卡 Skill，把业务文档转成适配平台的知识卡片，结果现在要维护两层知识库，非常麻烦。
如上图，整条链路实际上是被最右边的 RAG 卡住了，前面每一层都在往回拟合它。
转卡 Skill 在初期确实帮了忙，从少量样本搭出了可以问答、可以测试的助理，后来也让同事能够批量处理文档。但业务原文之外，从此多了一套知识卡，原文更新后，卡要不要改、对应哪几张、改完怎样同步，都成了新的工作。后来我们用通用 Agent（WorkBuddy）加本机定时任务，定期巡检群里的更新通知、比对已有内容、再增删知识卡——为了维护知识卡，我们又增加了一条流程，而且这个流程还非常依赖于本地环境，且质量无法得到有效保障，没有人复核。
Prompt 也是一样。内测时，有同事用型号简称问耳机的防护等级，助理坚持要求确认型号，直到写出完整型号才肯回答。这个限制原本是我为了防止型号判断错误加的，实际用起来却增加了麻烦。后来我们不断修补提示词，一类问题改善了，另一类又受影响：型号确认太严格会反复追问，回答压得太简洁又可能漏掉售后排障步骤。Prompt 还是要追求通用，不需要缝缝补补，给很多 corner case 特意放对应的 Prompt。
回头看，这些雕花很大程度上是黑盒逼出来的。平台的 RAG 改不了，就只能改喂进去的东西；看不到它检索到了什么，就只能对着输出补 Prompt。核心动不了，就只能在边上雕。公测时有 14 条翻译相关的问题被统一拒答，日志里看不出问题出在知识、检索、Prompt、模型还是平台。一个问题坏了，连坏在哪一层都不知道。速度也是一样，钉钉上一个问题要好几秒钟，这在平台上是无解的，只能接受。
这样做，在特定的任务上确实能表现得很好，现在这个 Agent 也够用了。但换到其他的领域，就没法用这套方式复用到其他的任务上去。比如做 AI 质检，就用不了我们转换之后的知识库，因为它是适配于 DEAP 平台黑盒 RAG 算法的。从原知识库到我们的 AI 知识库，也是为了拟合这个任务，过拟合了，就没办法很好地回到其他的项目当中去。
既然问题出在去适配一个黑盒，出路就是反过来，把力气花在源头上。
原知识库不够规范，新旧规则冲突、适用条件不清、流程有缺失，我们投入了不少精力让转卡工具和 Agent 去适配它。实际上我们应该整理和维护一个好的源知识库，而不是让 Agent 和算法去适配一个坏的知识库。
这其实还是定义问题时犯的错误，因为急于做这个事情，没有先看清楚知识本身的状况。就像之前供应链管不起来，根本原因是没有数据，客服这块也是类似的，很多企业的 AI 化，第一步应该先做数字化。
规则是否现行、适用于谁、主流程怎样走、例外怎样处理，尽量在源文档里讲清楚，让人和 AI 共用一份。型号别名、政策条件、售后分支这些业务细节，也应该回到知识库里，而不是写进 Prompt。我们的知识集并不大，几百个 md 文档而已。我做过一些测试，直接把原始信息塞给 AI，它也能做到不错的检索效果。用不用 RAG 其实无所谓，我甚至觉得，一个好的知识库，无论用什么技术手段，达到的效果都足够使用。
只改源知识库，不做雕花，可能在特定任务上的表现没有那么好（毕竟没有做特殊的优化），但我们可以很方便地泛化到不同的任务上去，不需要考虑是在 DEAP、WorkBuddy 还是扣子上做，在不同的平台上都有比较好的效果。就像打地基，地基打得好，就能修各种各样的房子，而不是搞专属地基、修专属房子。雕花是线性的，一个事搞一个产品，没法指数化，而一个好的地基，能造 100 个东西。在这个项目上，客服部门的产品知识本身也可以被其他部门使用，整个项目的经验也可以扩散到其他部门。
我们能做的是尽量压缩复杂度，尽可能抽象，为那些我们没有预料的“目标”去搭建工具。雕花是围着一个已知的约束做适配，可扩展是为没有预料到的目标留出余地。一个好的知识库本身就是选择权，这是一个比较底层的设计，可以扩展且不断叠加。
人能够使用的工具是有限的，如果每次都为了解决一个新需求，新开发一个特定工具，连接到不同的平台或者网页，对人来说负担太大，这不是一个美妙的产品设计思路。我们尽可能保证通用性，实际上也是为了更好的用户体验。所以我认为大部分单独造出来的 Agent 没有存在意义，我们应该尽量用通用 Agent 满足需求，提高可复用性，同时一定程度上也把产品复杂度外包给了专业人士。
回头来看，也许一开始就应该在公司提供的 WorkBuddy 等通用 Agent 里面做一些改造：通用能力交给已有的 Agent，我们把业务方法写成 Skill，必要的操作做成 tools，确实需要接系统时再加 MCP，用 plugin 打包交付。客服一旦学会在 Agent 上使用 Skill，我们之后开发其他小工具也很方便。
但有时候也要考虑真实用户的约束条件，用得最多的外包客服，没有 WorkBuddy 账号，也不会用 Agent，他们需要的是一个打开就能用的网页。这时候我们只能做取舍，把能复用的和必须按人来的分开：源知识库、型号别名、评测集、调用记录这些放在后端，换什么入口都能复用；入口和交互则要按用户的条件来设计，总部和维护者可以用 WorkBuddy + Skill，外包新人就给一个网页，网页上最要紧的是能快点拿到对客草稿、来源能直接定位。我理想中的形态其实也很简单：发布一个网页作为前端，后端是知识集 + LLM，再加一层薄薄的 harness，这样的问答助手不需要建设太多东西就能做，本质上，它就是大部分公司官网侧边栏的 AI 问答。
三、交付与维护
项目之初，我没有仔细思考过后续运营的问题，想法停留在“客服这边可以出人”。但“业务方可以出人”需要有激励，能够落实到具体的人，有的问题脱离了纯技术的层面，落地复杂——比如这个人能力如何？能投入多少时间？能做业务审核还是也能改工具？遇到知识冲突谁来确认？原来的人离开后怎样接续？
自下而上地做，是可以过拟合的，因为不需要可扩展。比如我造一个小工具，就给自己用，适合我自己的特定任务，再比如有同事做了一个数据看板，就自己看。用的人就是维护的人，这样是合理的。
但自上而下的项目不能这么做，因为没有人专门去持续维护这个系统。内部工具不是可以直接赚钱的产品，很难直接产生价值，所以组织内部往往不会有人愿意专门优化和改善内部工具。每多一层复杂度，接手的门槛就高一层。所以不要雕花不只是技术上的审美，也考虑了维护成本。
首先，“自己知道怎么做”和“别人能接手”之间差得很远，举个转卡 Skill 的例子，我给同事一个打包好的 Skill，他们不知道怎样安装，需要再给一段提示词；装好之后，不知道怎样调用。能转出卡之后，还要判断内容有没有遗漏、政策有没有过期；要修改 Skill，又需要理解设计和规则。评测集更难，原本希望同事修订 AI 生成的问题和参考答案，但判断标准、能力和时间都跟不上，最后只能降低要求。
其次，用 Agent 得到好处的人和需要维护它的人，往往不是同一批人。比如这个项目，受益的是外包新人，他们流动性大、没有话语权，也不可能来维护知识库；能维护的是总部懂业务的人，但他们自己基本用不着这个工具。再加上没有特别严肃的考核指标，自然不愿意投入进来。
在内部提效过程中，我们解决的往往是权力来源（领导）的需求，而不是真实用户的需求——真实用户往往是执行层，没有权力。一个解法是尽量端到端，人只停留在必须判断的地方，比如规则冲突的拍板，尽可能减少人的参与，毕竟 human in the loop 是复杂的。
四、团队协作
项目相关方会越来越多，这是组织通病，大家都喜欢拉人进入项目，但其实实际干活的人并没有那么多，少数人就可以做完了，这时候敏捷迭代是最好的。
也许 Agent 的提效工作，首先应该在前沿小团队内部使用。一旦走常规流程，就非常困难，会很难落地，很慢。AI 让做东西变快了，但人和人之间同步上下文的难度，远超我最初的预期。
这样的场景很多，我就不再仔细举例了。无论是关于技术路线的选择，还是这个项目本身的目标和愿景，以及我们设计的原则，想让大家理解我们为什么会有这些想法、为什么会这么选择，实在是太难（AI 可以读文档，但很多人连文档都不读）。能同步的是“做什么”，同步不了的是“为什么”。有的判断必须要一轮轮踩坑才能试错出来，就像做出来一个 Agent，后续维护上的困难，没有亲身经历的人很难理解（我自己最初也没有预见会如此艰难）。我也向上讲过维护和承接上的困难，但没经历过的人，很难觉得这是个问题。
AI 还会把这个差距拉大，因为大家对 AI 这个工具的使用和理解差别太大了。一个人拿着 AI，几个月可以迭代几十轮，攒下的判断越来越多，但解释的速度并没有变快。所以拉进来的人越多，理解的差距越大，推进越慢。AI 项目天然适合少数一起动手的人。
Karpathy 最近也提到，人们对 LLM 能力的理解差距正在变宽，像一个越来越尖的漏斗：大部分人几乎没接触过，很多人只把它当成更好用的搜索，只有极少数人亲身体验过 agent 做完大型项目。他还提到，高管和很多职能大部分时间在跟人打交道，对 AI 的理解是二手的、抽象的。
我深感认同。可被传递的经验往往是抽象的，抽象的好处是可以快速学习。人的大脑更容易接受叙事和概念，把经验压缩成概念，容易迅速传递信息，这种抽象在某种程度上够用，但一旦涉及到复杂问题，真到了要执行的时候，容易“失之毫厘，差之千里”。
既然判断靠讲是传不过去的，会也就没必要开那么多。
我发现每次开会，其实核心内容是非常少的，大部分人是不发言，或者发言是没有意义的。虽然这个项目总共也就两三次全体会议，实践证明，开会本身没啥大意义，直接在群里用文字同步信息也很方便。重要的是与“相关方”进行交流，而不是广义的相关方们，大部分人是不需要参会的。
我们都是统一分任务，在钉钉群里就分配了，回传结果也是回传到对应的位置，群里通知即可。大部分上下文只对某一小部分人有意义，大部分人只关注结果。
信息靠异步就能同步，判断靠开会也传不过去，只能一起动手。
写在最后
总体判断下来，现在这个 Agent 暂时够用，但可扩展性不够，后续很多维护工作就是纯雕花，下个阶段的目标应该往源知识库去治理。所以结项后，我会把注意力放回知识库本身，换一条技术路线，把投入集中到业务知识的正本上。换路线之后会有很多好处，比如知识库可以形成一套规范，让 AI 来协助我们管理，不能谁都去知识库里随便更改，谁负责维护这个知识库，手里也有很好的工具可以使用。
至于我自己，企业内部 AI 提效涉及流程变动时会比较难，提高个体效率，或者去做外部产品，可能是更适合我推进的方向。个人工具的用户就是我自己，用得爽不爽，马上就知道；外部产品直接面向客户，愿不愿意付钱也很直接。相当于把自己扔进了一个 reward 非常真实的环境里面，很适合我们做强化学习。
再聊点眼下的具体问题，最近真正开始做治理后，我发现源知识库有很多文档不好处理——是转写成某种既定的格式，还是删掉、合并？似乎都要挨个过，是个苦力活，尽管我们可以写 Skill 让 Agent 帮忙转写，但我们需要先定下来一些实际的原则。所以这似乎是一个知识管理体系的问题？
“先定一个格式，再把几百篇全量转过去”，是转卡的老路，肯定是不能这么走的。我现在的想法是，知识库治理也和定义问题一样，从真实的问题倒推，而不是从文档出发。下面这些是初步拟定的一些原则：
- 按热度治理，先理清高频型号和高频主题的正本，长尾的有人问到了再说
- 同一条规则只写在一个地方，会互相冲突的必须合并或废止，不冲突的放着也没关系
- 不统一正文格式，只统一最少字段：适用于哪个领域、现在是否有效、更新时间等等
- 过期的规则不删，标成废止，写清被什么替代
- Agent 做盘点，人只看冲突和存疑的部分
- 验收看问答，拿真实问题去问，答对了就够，够用就停
时刻提醒自己：知识治理项目本身也可能变成新雕花的起源，一定要尽量减少复杂度。