我做了五年企业服务方向的AI应用去年带团队把“犀牛卫”这个企业级AI拓客系统从零搭到了稳定运行。中间踩过的坑、推翻过的方案、最后沉淀下来的架构思路一直想找机会完整写一遍。今天这篇就把智能体架构设计和工程实践拆开揉碎了讲从业务分析到模块实现从选型逻辑到线上稳定性不藏着掖着。这个系统解决的痛点很明确B2B销售团队找客户太依赖人力信息分散、线索质量差、触达效率低。犀牛卫的核心是一套多智能体协同的拓客引擎能自动完成线索发现、客户画像构建、触达策略生成、跟进提醒这些原本要多个销售和运营配合才能做完的活。如果你正在做销售自动化、智能获客或企业级Agent平台这篇文章能给你一套可落地的架构参考也会告诉你哪些坑千万别踩。1. 项目背景获客这件事为什么需要智能体1.1 传统拓客流程的典型痛点先说说我对企业获客的理解。过去B2B公司拓客基本是三板斧买名单打电话、参加展会换名片、让销售自己从公开渠道找线索。这三条路都有很严重的效率问题。买来的名单看着量大实际能用的很少很多号码打过去是空号企业名称和工商信息对不上筛选成本高得离谱。展会名片的问题在于线索没有任何上下文——你只知道这个人对你产品感兴趣但他什么预算、什么决策链路、当前用的是什么方案全都要销售自己去聊、去猜。至于让销售自己找线索更是不稳定优秀销售靠人脉普通销售靠勤奋但人脉和勤奋都复制不了团队一扩规模这套打法就崩。更麻烦的是整个流程全是断的。线索拿到手以后靠Excel流转谁跟过、聊到什么程度、下次什么时候跟进全在人的脑子里。销售离职带走一批客户换人接手后连客户的基本偏好都不知道其他部门想帮忙也无从下手因为数据根本没有沉淀下来。1.2 智能体切入的突破口在哪我复盘下来获客链条里至少有四个环节是可以用智能体替代人工的第一批公开数据源的信息收集和清洗第二客户背景和业务信息的自动整理第三基于客户动态的触达策略建议第四每个跟进节点的提醒和内容辅助生成。这四个环节有一个共同特点——大量重复、规则明确、但细节多变。这正好是智能体擅长的事。它能自己规划任务、调用工具获取外部信息、根据结果调整策略而不是像传统脚本那样死板地执行固定的正则表达式和爬虫规则。所以犀牛卫的定位从一开始就不是做一个简单的搜索工具而是做一套能替销售完成“动脑”工作的Agent系统。它要理解销售提的需求自己设计信息获取方案把结果整理成可用的客户画像最后生成针对性的沟通策略。这个目标定下来智能体架构就成了整个系统的核心。2. 架构设计与核心选型先把骨架立住2.1 六层架构从入口到执行怎么分层系统做了一年多架构改了四版最终稳定下来的结构是六层架构。整个设计思路是入口尽量薄编排尽量稳执行尽量厚。接收入层这是系统的输入端统一接收两类来源一是销售人员在Web端主动提交的拓客需求比如“帮我在华东地区找30家年营收5000万以上的智能制造企业”二是系统自动检测的被动触达事件比如企业发布了融资公告、高管发生变动这些动态信号。入口层的职责是统一鉴权和参数校验不做任何业务处理确保请求进来的时候是干净的。意图识别层接收入层处理完的请求后会先经过一轮意图拆解。这里用大模型结合少量规则把一条自然语言需求拆成结构化任务清单。比如“找30家智能制造企业”会被拆成行业筛选、地域限定、营收门槛、数据源选择、筛选优先级顺序这样五个子任务。任务编排层这是整个智能体的核心大脑负责决定任务以什么顺序执行、哪些可以并行、哪些必须串行。举例来说先跑数据采集再跑数据清洗这两步不能并行但工商信息、招投标记录、新闻舆情这几个数据源的采集可以并行。这一层我们用LangGraph实现了一个有状态的工作流引擎每个节点都是独立的Agent。工具执行层每个Agent在上层编排好任务后在这一层落地去调用真实的外部工具。包括企查查的工商数据API、公开招投标信息采集、企业新闻和社交动态抓取以及内部的CRM数据写入接口。每个工具被封装成一个函数对Agent暴露统一的输入输出结构Agent通过Function Calling来决定调用什么工具以及传什么参数。数据层所有采集到的原始数据、清洗后的结构化数据、生成的画像标签、以及每次Agent调用的日志统一进数据仓库。向量数据库单独拎出来放客户记忆和模板知识库为Agent提供长期记忆和参考。反馈闭环层系统产出结果后并不算完销售人员在实际跟进中的反馈、线索最终是否成交都要回传。这个反馈会成为后续模型微调和策略优化的重要依据也是整个系统能越用越准的关键。2.2 框架选型为什么最终选了自研调度加LangGraph做Agent项目框架选型是第一个大坑。我们先后评估了Coze、Dify和LangGraph这三条路也有一部分模块用到了Dify做运营后台但核心编排最终落在了LangGraph加上自研调度上。Coze上手快拖拽就能搭Agent做原型验证很方便。但深入用下来发现两个问题一是插件生态虽然丰富可企业级场景要调用的私有数据源根本接不进去数据安全就过不了关二是它的编排能力对我们这种需要精细控制状态的场景来说偏弱复杂多轮任务容易失控。Dify的优势在于知识库和RAG做得很顺手做运营后台和简单问答机器人效率极高。我们后面把某个内部的营销素材问答机器人放在了Dify上团队运营自己就能维护不用天天找研发改。但如果要做多智能体之间的复杂协作它同样存在定制空间有限的问题。LangGraph是我们最后选择的方案。它最大的价值是把Agent的工作流描述成一张有向无环图每个节点执行一个步骤节点之间通过State传递数据。这解决了我们最头疼的问题——长链路任务的状态管理。以前用纯LangChain写Agent一旦任务超过四五个步骤上下文就乱工具调用的中间结果没法持久化。LangGraph的节点化设计让每个步骤的输入输出都清晰可见出了问题可以精确定位是哪一个节点挂了。但LangGraph只是解决了编排层的框架问题外围的调度、重试、队列、权限控制还是得自己写。所以最终架构是自研调度中心负责任务的发起、重试、并发控制和人工干预入口LangGraph负责单条任务内部的工作流编排两者通过消息队列解耦。2.3 模型选型混合策略而不是押注一家大模型选型直接决定了成本和控制力。我们最终采用的是混合模型策略没有把宝押在任何一家上。复杂推理和最终报告生成用更强的主模型负责销售策略建议这类需要综合多源判断的任务。大量例行信息抽取和标签分类用轻量模型比如从一段公司简介里提取主营业务这种任务用轻量模型一天跑几千次成本只有主模型的十分之一。还有一个任务会对模型做单独微调就是用历史成交客户的特征来训练一个线索打分模型这个模型我们内部管它叫“成单概率预测器”。选择混合策略的另一个原因是容灾。单一模型供应商一旦出现限流或服务不稳定整个系统就瘫了这在企业服务里是不能接受的。我们现在做了模型层的抽象接口任何一个模型不可用可以在两分钟内切换到备用模型虽然回答风格会有细微差异但核心功能不受影响。3. 核心模块拆解智能体到底在做什么事3.1 线索识别与意图解析先讲系统怎么理解销售的需求。如果把智能体的任务比作一个实习生帮你干活那第一步一定是让实习生明白你到底要什么。这步在NLP里叫意图识别但真正落地远不止分类意图那么简单。我拿一个真实需求来举例“帮我找深圳那边的跨境电商公司主要做东南亚市场的团队规模50人以上最近有融资最好。”这条需求里至少有五个实体需要提取地域是深圳行业是跨境电商目标市场是东南亚规模是50人以上附加条件是最近有融资。我们的方案是用大模型加结构化输出约束来解决在Prompt里定义好输出JSON的Schema让模型按固定结构返回。这样后面所有模块都能用统一的数据结构来处理而不是面对一团自然语言。提取完实体后还有一个很容易被忽略的步骤叫“隐含需求推理”。用户可能没说但一个做东南亚市场的跨境电商公司大概率需要海外支付、跨境物流、多语言客服这些服务。系统会把这类隐含标签也加到筛选条件里在后面生成触达策略的时候作为个性化内容素材。这步我们踩过最大的坑是模型输出的稳定性问题。大模型返回JSON格式偶尔会多一个字段或缺少逗号比例不算高大概在2%到3%的样子但在一大批任务里就会被放大。所以我们在意图识别层加了一重额外的格式校验不合格的输出会触发一次模型重新生成再不行就转人工。后面团队对这块的升级方向是引入小型的嵌入分类模型先做粗分类再用大模型做细抽取这样速度和稳定性都能提上来。3.2 客户画像构建从多源数据到可读标签画像构建是犀牛卫最花功夫的模块。说白了系统要回答一个问题这家公司值不值得跟应该怎么跟。数据获取方面我们接入了四类来源。工商数据通过API接入拿到的是企业基本信息、股东结构、注册资本这些相对静态的数据。动态数据靠定时采集包括招投标公告、融资信息披露、官网动态发布这些事件型信息。舆情数据是另一个重要来源包括企业新闻和社交动态用来感知客户当前的话题和状态。另外还接了内部CRM系统销售人员已经记录过的沟通历史会回传这部分数据质量最高但也是过去最容易被忽略的。原始数据拿到手后不能直接用。举例来说一家公司可能在工商系统里是名字A在招投标网站上显示成缩写B在新闻稿里又用了品牌名C。系统里专门有一条“企业实体归一化”的链路利用别名库加语义匹配把同一个实体的多来源信息合并到一个档案下面。归一化之后是标签化。系统会把原始数据映射成业务标签分成行业、规模、发展阶段、技术方向、采购信号五个维度。每个标签都带一个置信度分数比如“最近有采购信号”这个标签如果依据是公司发布了供应商招标公告置信度就高如果仅仅是有一个招聘岗位看起来像在扩团队置信度就低。这个置信度在后面触达策略里非常关键我们只对高置信度信号触发强触达动作低置信度的只进入观察名单。画像的最终产物是一份结构化的客户概览包括一段由大模型生成的综合摘要把最核心的结论用100字以内讲清楚以及一组结构化标签数据用于后续评分和策略匹配。我见过不少竞品在这块偷懒直接扔给销售一大段原始信息说实话那跟让销售自己去搜一遍没区别只是换了个搜索引擎而已。3.3 线索评分用历史成交数据“教会”系统判断优先级画像标签是系统了解客户的“眼睛”但那还不够还得有“判断力”。这就要说到线索评分模块了。我决定用机器学习做线索评分是在一次复盘会上被刺激到的。当时我们发现销售人员倾向于先跟那些联系攻略写得好的客户而不是真正成交概率高的客户因为他们根本分不清。团队里一个老人用感觉判断一个新人用勤奋弥补最终结果差异巨大。这让我意识到系统必须给出一个相对客观的“值得跟进程度”分数。具体做法是这样的。首先从历史成交客户数据里提取正样本从长期跟进但最终丢单的客户里提取负样本大概清洗出几千条合格数据。每条样本的特征就是从画像模块里得到的那五个维度的标签值加上一些原始统计特征比如成立年限、员工数变化趋势、近期公开动态频次。模型选择上我们用的还是梯度提升树没有一上来就上深度学习。原因很简单样本量就那么大数据集也就几千条深度学习在这种规模下优势不明显反而更严重的问题是过拟合。梯度提升树可解释性好能给销售出一个明确的理由清单为什么这个客户打分88分核心是因为他们近30天有两起招标、预算区间匹配度高、且决策链角色齐全。评分跑完以后系统会做一个规则层的融合。比如有一条硬性规则客户处于“已接触竞品”状态时系统会在机器学习分数基础上加权这属于人为经验补充。这个模块上线后有效线索转化率比纯人工判断大概提升了至少三成而且省掉了很多新人盲目打电话的时间。3.4 触达策略编排与话术生成找到值得跟进的客户之后智能体还要负责告诉销售“怎么跟”。触达策略模块解决了这个问题。系统会把触达分成两条线来设计。第一条是时间线什么时候该联系这个客户信号触发型策略会监测到特定事件后自动建议触达比如客户发布融资新闻后的24小时内是一个绝佳的沟通窗口因为对方可能正处于花钱扩张的阶段。还有一种固定的节奏型策略按客户所处的漏斗阶段来设定跟进频率比如新线索三天内必须完成首触超过两周没回应的进入温和培育池每两周发一次行业内容。第二条是内容线跟客户说什么。话术生成不是凭空写而是基于客户画像里的标签组合来匹配内容模板。比如对刚融资的跨境电商企业系统生成的开场白会围绕“祝贺融资成功加是否有海外收款优化需求”这个角度对有明确招标信号的客户生成的话术会更直接围绕“你方正在采购的方向我们可以提供什么支持”来展开。写话术时还有一个细节很关键智能体生成的内容要提供多个版本。建议提供不同风格一种是“单刀直入型”适合快节奏的老板直接了当沟通另一种是“专业分析型”适合喜欢研究方案的技术负责人给出行业数据和第三方报告。因为不同决策角色在乎的事情完全不同给老板看ROI给技术负责人看架构和安全性一句通吃的话术在B2B场景里基本等于没写。部门内容生成我们做了关键词预设库把公司产品常用术语、竞品禁止说法、合规红线这些做成规则库模型生成时强制规避风险词同时每次生成的最终版话术都要经过一次自动合规校验才能推送给销售。4. 多智能体协同与记忆管理从“单打独斗”到“团队作战”4.1 为什么单Agent搞不定长链路任务项目早期我们犯过一个典型错误试图用一个超大Agent一次完成从线索发现到触达建议的所有工作。结果很惨Prompt写了几千字模型经常忽略掉中段的任务条件或者在前一步还没完成时就跳到下一步。后来我复盘原因长链路任务里信息在单Agent内部传递会逐渐衰减。好比让你一个人同时做调研、分析、写作、排版四件事精力被分散每一步的质量都不如专人专做。而且一旦中间某个环节出错要重跑就得整条链路重来时间和成本都扛不住。所以犀牛卫的智能体设计改成了多智能体协同架构每个Agent负责一个相对独立的专业环节环节之间通过明确的输入输出结构对接。整个链路包含这样几个角色规划Agent负责语义理解把用户需求拆解成结构化任务清单采集Agent负责调度各数据源拿到原始信息分析Agent负责实体归一和标签抽取策略Agent负责客户评分和触达策略生成质检Agent负责审核其他Agent的输出结果是否合格人行Agent负责调用CRM、企微等内部系统执行写入和触达这个结构还有个额外的好处可以做独立的模型配比。体力活的采集Agent用便宜的小模型脑力活的策略Agent上强模型成本一下子降下来了。4.2 状态管理与会话隔离多任务并发不串号多智能体协同最大的技术挑战是状态管理。系统同时跑着几百个拓客任务每个任务又包含多个Agent节点在执行状态一旦串掉就是灾难级的故障。设计上我们做了两层隔离。第一层是流程级隔离每个任务实例有全局唯一定位这个ID贯穿整个工作流的每一次调用、每一个工具请求、每一条日志。第二层是会话级隔离如果同一家客户被两个不同销售发起拓客任务系统要确保两个人的上下文互不可见每个业务记录的归属必须严格下单到销售维度只有权限可达的人能看到。数据字段也做了权限标记做不到的不给系统防止越权。实际执行层面我们用的是LangGraph的State机制加Redis持久化。LangGraph维护每个节点的输入输出State里存的是当次执行的过程数据。但工作流本身可能持续很长时间中间进程重启会丢内存数据所以每个节点结束时会快照一次State到Redis一旦节点挂了系统可以从最近的快照恢复而不是从零开始。超时控制也在这块做了线下功夫。每个Agent节点设了30秒响应上限超过就触发一次重试重试两次仍失败就进入人工队列。因为一次拓客任务往往要跑几分钟如果某个单一环节卡住整条链路都会被拖住所有外部调用必须有超时上限。4.3 记忆与向量库让系统越用越懂你的客户AI系统如果没有记忆每次交互都是从零开始那是不可用的。犀牛卫的记忆体系分了三层来设计。短期记忆在会话内生效比如同一次拓客任务里前面分析Agent抽取出的标签后面策略Agent生成方案时可以直接引用。这一层通过State传递实现不做持久化。长期记忆存在向量数据库里。客户的历史画像、历史沟通记录、销售曾经的反馈、相似客户的成功案例都通过嵌入模型转成向量存进去。策略Agent在生成触达方案前会先从向量库里检索出该客户最近的沟通销售关键信息以及其他相似客户的成功策略作为参考上下文喂给大模型。这套检索增强生成的组合拳是从根源上解决大模型“瞎编”的关键因为每次生成都是有依据的。行业经验沉淀存在知识模板库里。比如“跨境电商行业淡旺季规律”“制造业采购决策链角色清单”这类结构化知识和方法论也是向量化的形式存在所有策略Agent共享。运营团队可以定期更新这个库相当于把公司最好的销售经验固化到系统里新销售接手也能享受到老销售的行事逻辑。5. 工程实践与避坑实录上线以后才是真正开始5.1 延迟控制智能体一慢销售就不愿意用了智能体跑一趟完整任务我们上线初期的P95耗时大概是120秒。销售在旁边等着本来就急超过90秒就开始怀疑系统坏了。后来我们做了三件事把P95压到了40秒左右。第一件事是数据源并行采集。最开始采集Agent是按顺序请求工商API、招标接口、舆情接口单次任务光采集就耗掉大半时间。改成并行调用只等最慢的那一个后就快多了主要是统一了数据返回的格式不用再等前一个结果整理好才开始下一个。第二件事是引进了流式输出。系统分析Agent在生成客户画像时让模型以流式方式输出前端先显示已经生成好的结构化标签和原始数据概览这段在数据采集完就能立刻展示大模型生成的那段综合摘要最后慢慢“打字”出来。用户体感上效率提升非常明显虽然总耗时没缩短多少但等待焦虑几乎消失了。第三件事是加了预计算机制。对一些高频筛选条件比如“高新区企业”“注册资本2000万以上”这种组合系统在空闲时段把结果集预先算好缓存下来需求进来直接命中缓存就行零计算成本。预计算命中率大概在25%左右对于重复性需求这个比例很值得了。5.2 幻觉控制给AI的每个结论都加上证据链大模型生成内容的幻觉控制在企业级系统里是生死线尤其在拓客系统里一个编造出来的“客户融资消息”可能让销售在错误的方向上浪费一周时间。这个教训我们是真切地疼过也确实付出了代价。我们的方案是全链路加证据链。分析Agent在抽取每个标签时必须同时输出依据来源和原文摘要片段比如“近期有采购信号”这个标签证据是“某月某日发布了配电柜采购招标公告”。没有证据支撑的标签置信度直接降为零。这个设计从机制上限制了模型的编造空间。在生成客户摘要和策略建议时则用了一个更严的模式只允许模型基于限定结构的上下文来生成限定结构里的信息全部来自数据库或外部API大模型没有自由发挥的余地。它要做的只是在给定的结构化信息基础上组织语言而不是发明新的“事实”。质检Agent是最后一关。它会把生成结果中的关键事实点逐一与原始数据源做交叉校验比如提取“客户规模”“融资轮次”这些关键实体去数据库里核对是否一致。校验不过的结果会被打回重做或标记为低置信度绝对不会直接推到销售面前。这个质检环节让系统的信息准确率提升到了可用的水平这个流程也是我们项目里最值得复制的一个设计。5.3 上下文管理防止“记忆混乱”和“越聊越笨”大模型对话的上下文越长模型越容易抓不住重点幻觉率反而会上升。这是做Agent工程绕不开的问题。我们在长链路任务里做了一套上下文裁剪机制。每个Agent的输出只把与下游真正相关的字段透传下去而不是把整段回答原样传递。比如采集Agent输出的原始数据通常有大几千字真正传到分析Agent的只有格式化的标签数据和置信度原文只做存档备查不进上下文。还有一种情况是多个数据源里事实冲突比如工商信息显示“员工规模100人”舆情里说“员工规模超过300人”系统如果不处理模型就会自相矛盾。我们在分析Agent里专门做了冲突检测检测到冲突后按数据权威性排序工商数据高于舆情数据并保留高分优先同时把冲突信息本身提交到人工复核队列。对于那些确实需要让模型看更多背景的复杂场景我们则用“摘要梯度”的方式处理先把原始材料做成一层详细摘要如果还是超长度再压缩成100字以内的要点版模型只拿到当前需要用的那一层摘要。这个做法的效果是上下文可控费用可控而且模型表现比硬塞大量原文明显稳定得多。5.4 效果评估怎么衡量一个智能体系统是真的好用没有评估体系的AI系统上线就是摆烂。但智能体系统的评估跟传统软件完全不是一回事不能只看接口返回多少条数据得按照它的能力域拆开评估。我们建立了一套成本加质量加业务的三层评估体系。第一层看成本单次拓客任务的API调用费用、总耗时、失败重试率这些决定系统能不能持续跑下去。成本失控的智能体再聪明也落不了地。第二层看质量重点评估三件标签抽取的准确率有没有达到一个可靠的水平对大模型抽取结果人工会抽样复核生成的触达话术有多少条被销售直接采用或少量修改后采用这个比例我们叫“采纳率”低于30%就说明生成质量不行质检Agent发现多少次需要打回重做的样例这是模型输出稳定性的直观体现。第三层才看业务指标比较硬的是有效线索转化和成交率提升幅度。但这里要提醒一点业务指标受外部环境影响很大拿它来做单一的评估标准容易失真。我们每周固定抽一批新线索做人工盲测让有经验的销售在不知情的情况下给系统推荐质检跟系统的评分对比差异超过一定范围的情况必须回头排查原因这是长期保证系统不过时的方法。6. 常见问题快查表给正在做同类系统的你我把项目里高频遇到而且有明确定论的问题整理成了一张表包括现象、原因和解决办法供参考。现象根因解决方式多步任务跑到一半突然丢失上下文单Agent内Prompt过长导致模型忽略部分条件拆分多个专业Agent节点间只传递结构化数据字段JSON解析频繁报错大模型生成格式不稳定加Schema校验失败自动重生成一次仍失败转人工数据采集太慢多个数据源串行请求改并行调用只等最慢的那个返回系统生成明显编造的客户信息模型幻觉强制证据链抽取标签必须附依据无证据置信度置零多个销售反馈“推荐不相关客户”画像标签与目标需求不匹配检查意图识别实体提取环节补充隐含需求推理推广后API费用大幅上涨每个子任务都用大参数模型按任务复杂度分级使用模型简单抽取用小模型达到并发上限时任务堆积编排层无削峰能力自研调度中心引入消息队列做削峰填谷控制最大并发数销售最终还是不用系统推荐系统体验慢叠加话术不合适流式输出先展示已有结果话术生成提供多风格多版本这个表是我自己写文档时整理出来的同时也是给新成员入职时做培训的教材。看起来每条都很简单但每一条背后都有真实案例兜底当系统出问题时对照这个表去排查能节约大量定位时间。最后再说一个更虚但很实际的感受做企业级AI系统技术能力只占一半另一半是冷静克制地识别什么该智能化、什么不该智能化。系统里凡是要求绝对可靠的环节比如数据校验、权限控制、计费逻辑通通写死逻辑不走大模型凡是需要理解和创造的环节比如需求理解、话术生成、策略建议才是智能体发挥的地方。这个边界分清楚AI系统才能真正给业务带来增量不然技术上再炫业务的信任也会在一次错误之后崩塌。目前犀牛卫这套架构跑得还算稳后续我们还在迭代的方向是让触达策略更加贴近具体行业的决策链路逻辑那是另外一个值得展开的故事。