晚上十点，一条新线索从活动表单进入系统。客户先问课程内容，过一会儿补充自己的工作背景，第二天又回来比较价格。销售需要记住前面的信息，判断对方处于了解需求、方案比较还是报价阶段，还要决定什么时候继续跟进。遇到敏感承诺、强烈负面情绪或复杂异议，回复权需要及时交回人工。

单轮回复只是这段工作的起点。真正消耗人力的是持续几天甚至几周的判断与执行：整理客户信息、维护销售阶段、核对商品事实、按时触达、控制风险，并把值得人工投入的客户交给销售。Sales Agent 围绕这条流程搭建，目标是让模型参与销售过程，同时让业务状态、后续任务和人工边界都落在可运行的系统里。

销售对话真正难在哪里

To C 销售常见于零售、电商、教育、订阅服务等场景。线索数量多，问题看起来重复，实际决策条件却分散在多轮交流中：预算可能在第一天提到，使用场景到第三轮才说清，真正的异议又出现在报价之后。

一线销售的压力首先落在日常执行上。

线索多，注意力有限。 同一名销售往往同时维护大量客户。聊天记录不断累积，预算、需求、顾虑和承诺散落在不同日期的消息里，重新翻找上下文既耗时，也容易遗漏关键信息。

跟进周期长，节点容易漏。 客户可能几小时后回复，也可能隔几天才重新出现。销售通常依靠个人习惯、便签或 CRM 提醒安排触达，忙碌时容易错过合适时机，也可能对同一客户重复跟进。

答疑质量依赖个人经验。 产品、价格、优惠和业务政策会变化，新员工需要反复查资料；熟练销售也可能因记忆偏差给出不一致的口径。优秀的异议处理和推进方式往往留在个人聊天记录里，难以复用。

需要人工投入的客户不容易及时识别。 高意向、复杂报价、负面情绪和敏感承诺混在大量普通咨询中。判断晚了会错失机会，判断过早又会把重复劳动重新推回人工。

从管理者视角看，还有一层更难处理的问题：销售过程分散在每名员工的会话里。管理者很难连续观察阶段分布、跟进执行、人工接管和回复质量，也难以总结哪些做法有效，再据此调整团队 SOP、人员安排和销售策略。

Sales Agent 针对这些问题做了五组设计。

跨回合维护客户状态。 客户画像、历史摘要和当前意向持续更新。系统读取的不只是最后一条消息，还能结合此前的目标、预算和顾虑判断本轮应该回答什么。

客户沉默后，跟进任务仍按规则执行。 不同销售阶段配置等待时间和后续动作：有的阶段继续触达，有的阶段暂停或结束。任务持久化保存，服务重启后也能继续调度。

事实、策略和表达分开管理。 商品价格、服务范围和业务政策来自知识库；SOP 决定当前推进动作；优秀销售案例提供表达参考。三类内容走独立检索路径，减少错价和过度承诺。

风险和复杂决策及时交给人工。 高意向客户、复杂报价、敏感问题、负面情绪和模型异常都可以触发接管。人工进入后，自动回复和定时任务立即停下；恢复自动模式时，系统补齐人工沟通期间的上下文。

把个人销售过程汇总成可观察的经营状态。 管理员端聚合客户阶段、意向分布、SOP 漏斗、跟进任务、人工接管、Agent 成功率与耗时。管理者可以从单个会话追溯到团队整体，定位流程卡点，并用同一套数据复盘销售策略和系统效果。

这些要求共同决定了产品形态：它需要对话能力，也需要客户状态、任务调度、知识治理、风控、实时通信和可观测性。

从客服机器人到销售 Agent

客服机器人：围绕问题解决和服务动作展开

今天的客服机器人已经具备知识检索、多轮理解、业务动作、人工交接和运营分析能力。它们与销售 Agent 的差别不在于能否保存上下文，更关键的是长期维护什么业务状态：客服系统通常关注问题是否解决、工单是否关闭；销售流程还要持续维护客户意向、销售阶段、下一次触达时间和人工跟进状态。

产品、项目或公司	来源与形态	功能特点	Sales Agent 与其区别
阿里云智能对话机器人（原云小蜜）	中国，商业产品	支持 FAQ、任务式多轮问答、表格与图谱问答，可视化配置对话流程，并提供 API、多渠道接入和运营分析	围绕一对一销售会话持续维护客户画像、意向、阶段和后续任务，销售推进状态更集中
Zendesk AI agents	国外，商业产品	基于可信知识源回答问题，支持生成式流程、脚本对话、授权动作、API 集成、多渠道和自动化效果分析	内置阶段化 SOP、超时触达和销售人工接管状态，可把一次答疑延伸为后续销售任务
Intercom Fin	国外，商业产品	将知识库、全渠道收件箱、工单、Copilot、人工交接和报表放在统一客服平台	对每轮销售判断保留 Agent 调用链，并把客户意向、推进阶段和下一步动作作为独立状态管理
Chatwoot	国外，开源、自部署	开源全渠道客服工作台，提供统一收件箱、帮助中心、自动分配、报表和 Captain AI 客服能力	项目范围更聚焦销售流程，开箱包含销售 SOP、定时跟进、销售案例 RAG、风控和三端业务界面

这些客服产品在渠道覆盖、工单体系和客服运营上积累更深。Sales Agent 的优势集中在另一个方向：将连续销售推进所需的状态、任务和人工边界放进一条可运行、可追踪的链路。

销售 Agent：从线索处理走向持续推进

面向销售流程的产品已经覆盖 CRM、渠道拓客、线索培育和实时对话等不同入口。成熟商业产品的优势在于企业数据、渠道与现有 CRM 生态，开源项目则更适合研究和二次开发。

产品、项目或公司	来源与形态	功能特点	Sales Agent 相比的优势
深信服销售智能体（Sales Agent）	中国，商业产品	支撑多 Agent、知识抽取、优秀销售经验模仿、逐步引导成单和反思迭代	更加拟人化的节点级 Agent 编排，模型调用链可视化从而减少黑盒操作，管理员综合查看数据从而优化管理
Salesforce Agentforce Lead Nurturing	国外，商业产品	在 Salesforce CRM 中完成线索培育、产品答疑、异议处理、会议预约和持续跟进	不依赖 Salesforce 数据体系，业务知识、模型供应商、SOP 和部署环境均可自行替换
HubSpot Prospecting Agent	国外，商业产品	基于 Smart CRM 做账户研究、购买信号识别、个性化邮件触达和人工审核	更贴近即时会话，能在客户连续发消息、分段回复、人工接管和定时触达之间保持一致状态
Microsoft Sales Qualification Agent	国外，商业产品	结合 Dynamics 365、Exchange 和 Dataverse 完成线索研究、资格判断、自动互动与销售交接	提供从 LangGraph 节点、知识检索到风控复审的完整可观察链路，适合展示和验证 Agent 工程实现
SalesGPT	国外，开源项目	根据销售阶段进行需求分析、方案介绍、异议处理和成交推进，支持产品知识、邮件、会议、支付链接及 human in the loop	提供客户与任务持久化、销售工作台、管理员看板、SOP 定时调度以及更细的风控状态管理

Sales Agent 选择的是一个相对明确的切口：把一对一聊天中的销售推进做成可自部署、可查看运行链路、可替换业务数据的完整实现。它可以独立作为销售工作台运行，也为后续接入企业现有 CRM 和消息渠道保留适配层。

销售智能体嵌入到业务中的流程

图 1：线索进入、Agent 推进、人工接管与后续成交。

线索可以来自表单、咨询入口或外部系统。销售把客户纳入跟进后，Sales Agent 承担高频且规则相对明确的工作：识别意图、匹配知识、判断销售阶段、生成回复和安排下一次触达。系统持续判断是否需要人工介入；进入人工模式后，销售完成复杂沟通、报价和成交跟进，后续仍可将会话交还给 Agent。

项目中的“自主推进”对应图中的绿色部分。系统依据客户阶段、SOP 和超时规则安排下一步动作，生成并审核回复，保存发送结果，再更新后续任务。风险场景和复杂决策由人工处理。这个边界让自动化承担重复工作，同时保留销售对关键承诺和成交环节的控制权。

Human in the loop 贯穿整条流程。人工接管可以由强制关键词、意图判断、知识不足、Safety Agent 审核结果、模型异常或销售手动操作触发。接管后系统会取消尚未完成的自动回复，暂停后续触达，也不会向客户发送无法保证时效的“已为您转接”话术。人工消息仍进入同一条会话；恢复自动模式时，Memory Agent 会把人工期间的关键信息补入摘要和客户画像。

一轮对话如何在 LangGraph 中流转

图 2：基于 LangGraph 的多 Agent 调度对话回合编排流程。

业务流程进入系统后，一轮客户消息会经历下面这条链路：

1. 客户消息先写入数据库，前端立即收到已接收确认。
2. 会话级后台 worker 负责生成回复。客户连续补充消息时，首条 AI 回复发送前可以取消当前回合，合并尚未回复的内容后重新运行。
3. Supervisor 先执行确定性规则，处理强制转人工、明显寒暄和异常状态，减少不必要的模型调用。
4. Intent Agent 识别意图、情绪和购买意愿，并决定本轮需要哪些上下文。
5. SOP Agent、Knowledge Agent 和 Sales Case RAG 按需并行运行，在 context_gate 汇聚。
6. Conversation Agent 根据客户记忆、事实、阶段和案例参考生成回复草稿。
7. Safety Agent 审核草稿。需要调整时先给出建议稿，再回到 Safety Agent 复审；达到重试上限或风险过高时转人工。
8. 审核通过的回复按标点和长度拆分，以更自然的节奏发送。首段已经发出后，本回合会完成剩余分段，新消息进入下一回合。
9. 发送成功后，系统同步落库本轮事实，并异步更新会话摘要和客户画像。SOP 服务再根据当前阶段安排后续触达。

每个回合都有独立 turn_id，客户输入、分段回复、Graph 节点、LLM 调用、Embedding、风控命中和记忆更新可以沿同一条链路追踪。主模型失败时，多供应商 fallback 会按配置继续尝试，失败原因和耗时保留在调用记录中。

四个机制让流程持续运行

1. 客户记忆与销售状态分开保存

原始消息、会话摘要和结构化客户画像承担不同职责。原始消息用于完整追溯；摘要保留后续交流仍需要的事实；画像保存职业、目标、预算、意向和主要顾虑等字段。销售阶段和主动推进状态单独保存，避免将所有判断都埋在一段自然语言摘要里。

Memory Agent 在客户可见回复发送后异步更新记忆。这样既缩短客户等待时间，也避免失败的回复进入长期记忆。

2. SOP 既是知识，也是任务状态

SOP 表定义阶段、目标、参考话术、最长等待时间和超时动作；会话状态记录当前阶段、最近回复和自动推进状态；跟进任务记录计划时间、执行状态、发送结果和失败原因。

超时动作支持继续下一阶段、发送后暂停或结束自动推进。客户回复、人工接管和重新排程会取消或调整待执行任务。项目还提供持久化定时发送功能，销售可按客户或阶段选择对象，任务到期后写入统一消息链。

3. 商品事实、销售策略和风控规则各走各的检索路径

Knowledge Agent 读取产品、SKU、FAQ 和业务政策；SOP Agent 决定当前阶段的动作；Sales Case RAG 从优秀销售片段中检索表达方式和推进思路；风控规则只供 Safety Agent 使用，不进入客户可见的知识上下文。

销售案例 RAG 当前使用一份脱敏开发样本验证数据处理链路。448 条原始消息经过文本筛选、噪声清理、连续消息合并和片段构造后，得到 44 个达到当前阈值的“客户问题—销售回复”片段。这里的 44 个片段属于开发测试规模，用来确认导入、检索、提示词注入和效果记录能够跑通。

进入正式业务场景后，销售案例、产品库、FAQ、SOP 和风控规则都需要根据行业、商品、渠道和合规要求重新整理。案例库还要经过授权、脱敏、质量标注和定期更新，不能直接沿用开发样本。项目已经把这些内容设计成独立的数据和导入流程，便于替换业务资产而不改动 Agent 主链路。

4. Human in the loop 与风控共用一套状态

Safety Agent 可以通过、改写、拦截或转人工。人工接管状态会同时影响实时回复、SOP 跟进和手动控制台，防止自动任务在人工沟通期间继续发送。销售端能看到触发原因、当前节点、客户画像和 Agent 调用链，再决定回复、继续人工跟进或恢复自动模式。

从对话界面到运营看板

项目提供三个前端入口，各自面向不同角色。

销售端：处理会话和接管 Agent

销售工作台集中展示联系人、聊天记录、销售阶段、客户意向、情绪、客户画像、主动推进状态和 Agent 调用链。销售可以手动接管会话、回复客户、恢复自动模式，也可以创建持久化定时发送任务。销售端使用邮箱密码登录，内部 REST 和 WebSocket 都需要短期 bearer token。

图 3：销售端工作台。中间是统一消息链，右侧显示阶段、画像、人工接管和 Agent 运行状态。

客户模拟端：验证真实聊天体验

客户模拟端用于开发和评测，保留客户连续发消息、分段接收回复、未读状态和人工接管后的交流体验。正式接入企业微信等渠道时，外部消息会先通过渠道适配层映射到内部客户、会话和出站任务。

图 4：客户模拟端。

管理员端：管理配置并观察效果

管理员端提供白名单配置、系统健康状态、消息趋势、SOP 转化漏斗、意向与阶段分布、Agent 成功率和耗时，以及销售案例 RAG 的命中、使用和后续回复指标。敏感 API Key 不会在前端展示或编辑，管理员接口有独立鉴权。

图 5 6 7：管理员效果大屏，可同时看到核心指标、消息趋势、SOP 漏斗、RAG 效果评估、系统配置。

可观测性决定系统能否持续改进

系统记录每个 Graph 节点和模型调用的结果、供应商、耗时、fallback 尝试与错误信息。销售案例 RAG 还会记录本轮是否启用、召回了哪些片段、最高分和平均分、是否注入生成，以及客户是否继续回复。运营人员可以据此区分“检索命中”和“生成实际使用”。

效果指标分为四层：系统层看服务健康、Redis 和模型调用；过程层看客户消息、AI 回复、人工接管和定时触达；销售层看意向、阶段和 SOP 漏斗；RAG 层看检索与使用效果。随着真实业务数据增加，这套事件可以继续支持提示词版本、模型、案例库和业务策略的对比。

一次和真人销售的盲评对比

项目使用 144 条脱敏对话轮次做了一次离线测试。每条记录包含客户消息、上文记忆和真人销售当时的回复。Sales Agent 销售智能体系统复用正式 SalesGraphService 独立运行每条记录，得到 124 条正常回复、20 条转人工、0 条失败。

智能体回复和真人回复被随机打乱成“候选甲/候选乙”，一名有 5 年 To C 销售经验的评审在不知道来源的情况下按五个维度打分 0 或 1：

• 信息准确 A：回复信息是否正确
• 不违规 C：是否守住业务和合规边界
• 解决问题 R：是否回应客户当轮问题
• 意向推进 P：是否推动下一步销售动作
• 用户反馈 F：评审阅读当前回复后的主观体感是否积极、自然

这里的“用户反馈”是评审对当前回复的主观判断，不代表客户后续真实发送的消息。R 和 P 各占 30 分，F 占 40 分；A 和 C 是门控项，任一为 0 时该轮计 0 分。转人工轮次没有系统回复，智能体侧综合分按 0 计。

总分计算方式为：

$$S=\frac{1}{N}\sum _{i=1}^N(30R_i+30P_i+40F_i)A_i{C}_i$$

评测结果各项得分率和总分统计：

维度	智能体	真人
信息准确 A	88.19%	94.44%
不违规 C	100%	90.97%
解决问题 R	75.00%	86.11%
意向推进 P	79.17%	48.61%
用户反馈 F	86.11%	87.50%
总分	80.00	64.44

总分只能说明整体差异，无法回答系统在哪类问题上表现好、又在哪类问题上容易失分。为此，我继续按照客户本轮的主要沟通目标做题型拆分。分类时同时查看客户消息和上文记忆，用上文消除“好的”这类短句的歧义；一条消息包含多个意图时，只保留最主要的沟通目标。规则完成初分后，再逐条复核短句和多意图消息。

144 条记录最终分为六类：关系建立与时机协调 21 条、需求与客户画像 26 条、产品与规则咨询 44 条、价格与方案咨询 19 条、异议与风险顾虑 20 条、报名与服务办理 14 条。

Sales Agent 按题型拆分后的五维得分率：

题目类型	样本数	信息准确 A	不违规 C	解决问题 R	意向推进 P	用户反馈 F
关系建立与时机协调	21	95.24%	100.00%	95.24%	76.19%	95.24%
需求与客户画像	26	92.31%	100.00%	88.46%	92.31%	92.31%
产品与规则咨询	44	95.45%	100.00%	77.27%	88.64%	95.45%
价格与方案咨询	19	78.95%	100.00%	57.89%	63.16%	73.68%
异议与风险顾虑	20	90.00%	100.00%	75.00%	85.00%	85.00%
报名与服务办理	14	57.14%	100.00%	35.71%	42.86%	50.00%

图 8：Sales Agent 按题目类型拆分的五维得分率。X 轴为题目类型，Y 轴为五个评估维度，曲面高度和颜色表示得分率。

真人销售按相同题型拆分后的五维得分率：

题目类型	样本数	信息准确 A	不违规 C	解决问题 R	意向推进 P	用户反馈 F
关系建立与时机协调	21	100.00%	90.48%	71.43%	52.38%	71.43%
需求与客户画像	26	92.31%	100.00%	96.15%	53.85%	96.15%
产品与规则咨询	44	95.45%	95.45%	93.18%	52.27%	90.91%
价格与方案咨询	19	89.47%	84.21%	73.68%	52.63%	84.21%
异议与风险顾虑	20	90.00%	70.00%	75.00%	45.00%	85.00%
报名与服务办理	14	100.00%	100.00%	100.00%	21.43%	92.86%

图 9：真人销售按题目类型拆分的五维得分率，坐标与图 8 一致。

为了直接比较双方表现，我将每个题型、每个维度的智能体得分率减去真人得分率。差值单位为百分点，正值表示 Sales Agent 更高，负值表示真人销售更高。

图 10：Sales Agent 得分率减去真人销售得分率。蓝色正值表示 Sales Agent 更高，红色负值表示真人销售更高。

差值图把当前做得好的地方和下一轮优化方向放在了同一张图上：

观察项	相对真人的差值表现	结论与后续动作
优势：异议与风险顾虑	不违规 C 高 30.00，意向推进 P 高 40.00；A、R、F 持平	风控与推进配合较好，继续保留“先处理顾虑、再推动下一步”的策略，并扩大优秀案例覆盖
优势：关系建立与时机协调	解决问题 R、意向推进 P、用户反馈 F 均高 23.81，不违规 C 高 9.52；信息准确 A 低 4.76	关系建立和跟进节奏有效，下一步只需收紧少量事实表达，不必改变整体对话策略
P0：报名与服务办理	信息准确 A 低 42.86，解决问题 R 低 64.29，用户反馈 F 低 42.86；意向推进 P 高 21.43	增加报名状态、支付结果、老师分配、班级与账号等业务工具；将可自动查询的标准流程和必须人工处理的例外情况分开
P1：价格与方案咨询	A 低 10.52、R 低 15.79、F 低 10.53；C 高 15.79、P 高 10.53	现有流程守住了风险边界，也能推动下一步，但直接答疑不足；需要把价格、套餐、赠品、退费条件和适用范围整理成版本化结构数据
P1：产品与规则咨询	A 持平，C 高 4.55、P 高 36.37、F 高 4.54，R 低 15.91	推进能力明显，但有些回复没有先解决当轮问题；调整 Knowledge Agent 返回结构和回复顺序，先回答，再补充依据与下一步建议
P2：需求与客户画像	P 高 38.46，R 低 7.69，F 低 3.84	需求挖掘较积极，但不能让连续追问压过当前问题；减少一次回复中的提问数量，并增加对客户原话的直接回应

在本次 144 条脱敏样本和单评审盲评口径下，系统总分高出 15.56 分，主要差异来自意向推进。差值图进一步说明，优势集中在异议处理、关系建立以及多数题型的下一步推进；明显短板集中在报名服务办理，其次是价格与产品答疑的直接性。报名与服务办理的 14 条记录中有 7 条转人工，后续还需要单独评估转人工是否必要、触发是否及时、交接上下文是否完整。离线盲评用于观察单轮回复体验，真实转化效果仍需结合正式场景中的客户行为和成交数据。

部署方式与公开 Demo

完整部署版使用 Docker Compose 管理 sales-agent、PostgreSQL 和 Redis。FastAPI、LangGraph、Web 前端与后台调度器运行在应用容器；PostgreSQL 保存业务事实、任务、知识和向量；Redis 用于跨进程 WebSocket 广播以及调度器分布式锁。Windows 开发环境通过 WSL Integration 使用同一套配置，迁移到 Linux 服务器时运行入口保持一致。

企业微信渠道层已经实现外部联系人同步、会话消息导入、消息去重和出站任务抽象。真实自动发送需要企业在官方后台开通相应能力并确认发送权限。

目前已开源 AI-Sales-Agent-Demo，面向快速体验，直接在 Windows Python 环境运行，使用独立 PostgreSQL 数据库，不依赖 Redis，也不包含完整的 Linux 容器编排和生产渠道配置。Demo 保留多 Agent 主链路、SOP、知识库、销售案例 RAG、风控、客户记忆、三端界面和离线评估流程。完整部署版则增加 Redis 运行时协调、Docker Compose、Linux/WSL 入口和渠道适配。

写在最后

Sales Agent 的开发重点始终围绕一件事：让每轮交流形成可继续执行的销售状态。模型负责理解和生成，知识库约束事实，SOP 管理阶段与时间，Safety Agent 和人工销售控制风险，数据库与调度器保证流程可以跨回合、跨重启继续运行。

当这些环节连起来，AI 才能从回答当前问题走向维护客户关系、安排下一步动作，并在合适的时机把沟通交给人。