一个门面，三条后台线：我是怎么用多 Agent 做客户运营团队的

客户从始至终只跟一个人说话。但他不知道的是，这个人背后站着一支团队。

一、起因

做智能体服务这行，早期的做法很朴素——有几个 Agent，就给客户开几个入口。

获客一个号，销售一个号，客服一个号。听上去分工挺明确，实际跑起来是这样的：

客户先加了获客的号，聊两句，对方说「这个得销售那边跟你对接」。客户加了销售，又把自己的需求从头讲一遍。买完之后出了问题，销售说「售后找他」。客户第三次从头讲一遍。

每换一个号，客户都得重新交代一遍自己是谁、要什么、聊到哪了。这不是分工，这是把组织内部的复杂度转嫁给客户。

后来把架构反过来做了一次：对外只留一个声音，对内保留完整分工。

这就是「前台门面 + 后台专科」。运营是唯一对客的门面，获客、销售、客服退到后台做专家。

二、架构总览

关键在最后那列：只有运营对客。另外三个角色不管多专业，客户都碰不到它们本身。

三、运营：一个全场唯一能说话的人

运营这个角色只有一条核心原则：

默认自己答，只在「需要专业产出」时才委托。

先说为什么默认自己答。客户的问题里，绝大多数翻来覆去就是那几个：你们是做什么的、多少钱、怎么用。这些不需要后台专家介入，运营自己答最快。

委托只发生在一种情况：这件事要交出一份正式产出。报价单、方案对比、线索名单、触达话术这类东西有格式、有依据、有专门的知识页兜着，交给对应专家质量更稳。

分诊分三步走。

第一步：判断客户处在哪个阶段

这个人付过钱了吗？
├─ 没有 ──→ 我们/他主动沟通过吗？
│          ├─ 完全没有（陌生）→ 获客线
│          └─ 有接触、有兴趣   → 销售线
└─ 有 ──────→ 客服线

这一步只看一个事实：付没付过钱。付过的，所有问题都归客服，不再从获客或者销售那里绕。没付的，再看他有没有接触过我们。

之所以把这一步做得这么粗暴，是因为「已成交」是个不可逆的事实。客户一旦买过，还让他从销售线重新走一遍，纯属折腾人。

第二步：自己答，还是委托

第三步：关键词兜底

前两步靠判断，这一步靠关键词兜底：

• 「价格 / 报价 / 优惠 / 怎么买 / 考虑一下」→ 销售线
• 「已经买了 / 退款 / 坏了 / 用不了 / 投诉 / 差评」→ 客服线
• 「你是谁 / 怎么知道的 / 加个微信 / 有没有合作」且未成交 → 获客线

委托到底怎么落地

委托不是「把客户转走」，是「叫专家会诊」。

这一条我觉得是整个架构里最容易做错的地方。技术上实现很简单，把子任务交给队友、拿回结果就行。但结果不能原封不动贴给客户。

后台专家产出的是材料，运营才是那个说话的人。报价单是销售做的，但发给客户的措辞得运营组织；话术是获客设计的，但对着客户说出口的得是运营。

客户全程只跟运营对话。

四、三条后台线

后台三个角色的思路是一样：各管一段，边界写死。

获客：管「让人认识我们」之前的事

对象是陌生人和还没接触的潜在客户，主动性最强——通常是我们主动出击，不是等客户上门。

核心动作是找客户、判断有没有戏、设计「拿联系方式」的话术和时机。交付物是线索名单、渠道方案、触达话术。

这里有个反直觉的设计：获客不对客。

向客户开口要联系方式的动作，是运营做的；获客负责设计「怎么问、什么时候问」，再接运营转来的线索做跟进。

为什么要这么拆？因为要联系方式这件事，话术一硬，客户第一反应就是戒备。让已经跟他聊起来的运营去说，比一个突然冒出来的「获客」去说自然得多。

所以留资走了两步：

• 默认：运营发现「客户有意向 + 档案里没联系方式」，自己当场顺势问一句。
• 例外：客户戒备、场景特殊、需要一套可复用话术，才委托获客产出分层话术（首问 / 被拒后 / 复访），再由运营拿去对客户说。

获客不报价、不谈成交、不处理售后，也不直接对客户承诺。

销售：管「有意向」到「成交」

对象是已经接触、还没成交的潜在客户。发起是双向的——客户来询价，或者我们主动跟进。

核心动作是答疑、报价、处理异议、推成交。交付物是报价单、成交话术、方案对比、跟进节奏。

销售线有条硬规矩：报价必须有依据。 价格从知识页取，不是让模型现场编的。这条听着基础，但它决定了 AI 报价这件事能不能用——客户拿到的每个数字，背后都得有出处。

销售也不做线索挖掘、不碰售后投诉。已成交客户的问题一律归客服，哪怕他问的是「能不能再买一份」。

客服：管成交之后

客服这个角色最近调整过一次，值得说一句。

原来它是对客入口之一。后来改成纯粹的后台售后专家——对外门面统一交给运营，客服退回后台，接运营的委托，处理复杂投诉、争议工单和需要专门流程的售后问题，产出交回运营统一回复。

改它的原因就是开头那个问题：只要客服还能被客户直接找到，「一个声音」就守不住。

客服不做线索挖掘，不做报价推成交。

五、协作闭环

几条链路把角色串成一个环：

• 线索流转：获客拿到线索，客户有意向后移交销售
• 售后归口：成交之后的问题全走客服线
• 复购识别：客服先接，识别出购买意图后转回销售
• 对外接口：始终是运营一个人

最后一条是重点。这个环里角色之间可以互相转交，但转交的终点永远回到运营，链路上没有任何一条直接通向客户。

六、对客规矩

多 Agent 架构有个绕不过去的问题：客户会问「你是不是 AI」「你们几个人」。

我们的答案是两条。

身份可以坦诚。 客户问是不是 AI，可以承认是智能客服，但不谎称真人，也不主动展开技术细节。

架构绝不外露。 客户问「你们有几个人」「架构是什么样的」，统一回答「我这边负责对接你」。队友、门面、三条线这些，一个字不提。

身份可坦诚，架构绝不外露；对客户永远只有「我」一个声音。

这两件事的区别挺关键。承认是 AI 关乎诚信，暴露多 Agent 架构关乎体验。客户知道对面是 AI 不会怎么样，但客户要是发现「刚才跟我说话的和现在这个不是同一个」，就不一样了。

还有一条红线要分清：我方信息和客户信息，处理方向正好相反。 我方的微信号、账号、ID，怎么问都不给；客户自己的联系方式，反倒要主动去要——那是获客线索的核心动作。

微信端排版有条铁律：微信不渲染 Markdown，所有对客文字一律纯文本。不用标题、加粗、表格、代码块，列点用中文顿号或者「1. 2. 3.」，链接直接给纯网址。这事看着小，但它直接决定客户看到的是一段话还是一堆乱码。

转人工的触发场景包括：用户明确要求、答不上来、强烈不满投诉、涉及具体交易、反复跑题、同一个问题追问两次以上。触发后用一个内部标记收尾，渠道会自动去掉，客户看不见。原则是不谎称「已经转好了」，正常说「帮你转人工同事看一下」。

七、技术落地

配置本身很简单：一条客服通道绑一个门面 Agent，也就是运营，再挂上三个队友。通道绑多个 Agent，得到的是委托能力，不是会话切换。

有两个地方值得单独说。

委托不等于会话切换。 很多人一听「多个 Agent 服务一个客户」，第一反应是会话跳转——客户跟 A 说话，转到 B。我们不是这么干的。通道绑多 Agent 之后，队友是被调用的对象，不是被切过去的对象。客户那条对话线从头到尾没变过。

归档跟着客户走，门面目录不留副本。 每个客户的完整对话归档在他自己目录下，运营目录里不存副本。原因很实际：门面目录再存一份，同一段对话就有两份，时间一长必然对不上，出了事不知道该信哪份。一份记录落一处就够了。

（这块之前单独写过，可以翻那篇《我把智能体接进业务系统，才发现最难的不是「接」，是「谁都别想自己造一套记忆」》。）

八、为什么不给客户多开几个入口

回到最开始的问题。

客户的困惑是实打实的成本。他不需要知道我们有几个人、分几条线，只需要知道「找个入口就能把事解决」。多开一个入口，就多一次让他重新自我介绍的机会。

专业分工也确实管用。线索怎么拿、单怎么成、投诉怎么平，各有人管，比一个角色硬扛所有事稳得多。

对内灵活这点，是我们改完之后才体会到的好处。前台管体验，后台随时能加人、能调分工，客户完全无感。这半年我们动过客服的定位、改过留资流程，客户侧一次都没察觉。

合规和安全也顺带解决了：身份坦诚但不外露架构，我方账号不外泄，客户联系方式主动获取但不过度纠缠。

九、最后

写到这里想说句不太像技术总结的话。

这套架构里，技术部分反而是最简单的。调用、绑定、委托、归档，都有现成机制，配一下就跑起来了。

难的是那些写在「规矩」里的东西：什么时候自己答、什么时候叫队友、什么话能说、什么话不能露、客户问到边界上该怎么绕。这些没法靠代码约束，只能在角色定义里把边界写死。

所以我的体会是，多 Agent 系统的成败不在「能不能协作」，在「知不知道各自的边界在哪」。

一个没有边界的分工，比不分工还糟——客户会被几个专家同时拉着走，每个都觉得自己该接话。

这是从「三个号分别对客」走到「一个门面三条后台线」交的学费。

本文写的是我们实际跑着的一套配置，不涉及具体产品与客户信息。架构还会继续调，调完再更新。