销售团队如何用OpenRouter+AI Agent一个月节省600小时：架构、流程与踩坑实录

五个人一个月从销售流程里省出600小时。这个数字第一眼看上去像在吹牛但项目跑完以后我更想说的是真正的难点从来不是让AI干活而是把账算清楚。这个项目内部代号叫Rasp。我们搭了一个以OpenRouter为底层路由的AI智能体把它接进5人销售团队的日常流程里。团队构成很简单2个人负责新线索开发2个人跟进中大客户1个人是负责人兼销售运营。上线一个月后盘点直接自动化加上流程返工减少合计节省了约600小时。平均到每个人头上每人每月约120小时相当于多出来三周可用时间——当然这些时间并没有真的变成躺着休息而是被投回了更难的订单、更重要的客户关系维护上。这篇复盘我想把600小时拆开讲清楚多少是自动化直接省下的、多少是流程规范带来的间接收益、哪些坑让我们的账单一度暴涨、哪些环节绝对不能去掉人工确认。不讲大道理全是实操记录和踩过的坑。如果你正打算在销售团队里推AI Agent或者你是销售运营、团队负责人这篇应该能帮你少走不少弯路。1. OpenRouter、Rasp、销售团队三者各管什么1.1 一个简单的三层结构很多人一听到AI智能体就觉得是个黑盒其实我们这套架构简单到可以画在一张A4纸上OpenRouter在最底层只做一件事接收Rasp发来的模型请求按配置路由到不同的模型统一计费、统一返回结果。它解决的核心问题是每次调用该用哪个模型同时换模型不用重写代码。Rasp是中间调度层负责理解销售场景。它知道来了一条新线索需要先分级再决定谁跟进也知道这封邮件语气太硬要重写。它把业务问题翻译成提示词发给OpenRouter拿回结果后自己再做一轮校验最后决定是写入系统还是交给人工确认。销售团队是最上层也是最不允许出错的一层。Rasp的所有输出尤其是对外邮件和CRM字段必须经过人确认后才能生效。一句话概括OpenRouter是水管和阀门Rasp是自动灌溉系统销售同事是最后那个园丁。分层分清楚了后面所有维护和排障都轻松很多谁出了问题就找谁。1.2 为什么选OpenRouter而不是直接接一家模型API当时摆在我们面前有三条路直接对接某一家模型厂商的API、用OpenRouter做路由、直接采购现成的AI销售工具。我们列了一张表对比方案优点缺点结论直接对接单一模型API接入简单文档多换模型要改代码遇到限流整条流程卡住定价波动不好控不选用OpenRouter做路由一套代码接所有模型按任务选模型失败自动切换日志统一多一层依赖但稳定性足够好选定采购现成的AI SDR工具见效最快不用开发流程固死接不进我们现有的线索池和CRM按席位收费关键数据要出场景试用后放弃选择OpenRouter还有一个很实际的原因5人团队没有专职AI工程师没人愿意维护一堆厂商SDK和密钥。OpenRouter的请求格式和主流API兼容我们用Python写一个统一入口之后加模型、换模型都只是改配置的事。整个项目的开发主力就是我加一个后端同学前后花了两周把骨架搭完。1.3 5人团队最忌讳的过度工程有件事得提前说我们一开始也想过做一个多Agent协作系统让几个Agent互相传递任务、自动编排。后来发现完全是给自己加戏。5个人的销售团队就算线索量再大一天处理几百条已经是极限根本不需要多Agent协同。真正有价值的是把单条工作流的端到端自动率从70%提到90%而不是再多三个花哨的Agent互相聊天。所以我们的原则就两条先跑通单条流程再谈串联所有AI输出先进影子模式观察再放开权限。这个后面会详细讲。2. 600小时的账是怎么算出来的2.1 统计口径日志、抽样、交叉核对600小时不是拍脑袋估的。项目上线前团队就定了一个铁律一切节省必须能落到过去人要做、现在人只需确认这个口径上。这是整个项目后来能持续改进的基础。具体统计用了三层方法上线前两周人工计时。我们用最简单的工时表覆盖所有销售动作5个人每天下班前填一次记录每类事务的实际耗时得到手工基线。两周数据虽然样本不大但对估算来说足够了。上线后埋点日志。Rasp里所有核心动作都埋了事件日志生成了多少封邮件草稿、分类了多少条线索、提取了多少次纪要和周报、写入了多少个CRM字段。这些数据是客观的不靠人回忆。每周抽样交叉核对。一周随机抽三天由销售运营把Rasp日志和实际工时表放在一起比对剔除模型生成了但人根本没用的无效产出。这个方式最大的好处是每个环节的节省都能被追溯到后续做月度复盘也有据可依。2.2 明细表600小时从哪里来下面这张表是项目第四周的实际数据汇总。为了不让表格太拥挤我按季度平均后的口径列出来工作流月处理量原人工耗时现在人工耗时月节省线索初筛与分级约1200条约150小时约35小时约115小时外联邮件起草与改写约500封约140小时约50小时约90小时会议纪要与CRM同步约90场约108小时约45小时约63小时方案/报价材料初稿约40份约80小时约20小时约60小时周报、数据汇总与跨系统搬运每周例行约90小时约30小时约60小时资料检索与竞品信息整理每日多次约90小时约30小时约60小时商机阶段梳理与跟进提醒每日例行约72小时约25小时约47小时因信息错漏导致的返工与内部同步全程约85小时约25小时约60小时合计下来直接自动化省出来的时间大约450小时流程稳定后减少的返工和内部同步损耗约150小时加在一起就是标题里的600小时。2.3 什么账我们没有算有几点必须诚实说明不然这个数字就变成吹牛了团队搭建Rasp的投入不算。前两周我们投入了大约40小时开发时间这部分是一次性成本后面基本只有维护成本。我们坚持只统计流程实际省出的时间否则就是拿研发时间顶替业务时间没有意义。人工确认的时间也还是算进了现在人工耗时里。所有对外邮件和CRM阶段字段我们仍然保留了人审环节这个时间没被当作节省。间接节省口径很克制。减少返工这部分我们是用确认次数来大致衡量的上线前一封邮件平均来回修改2.3次上线后降到1.2次开会后要反复追问上次说的那个事的次数明显减少。这些确实省了时间但我们把它单列为一档不和直接自动化混在一起。提示如果你也要做类似的提效项目强烈建议按直接自动化和间接流程收益两本账分开记。混在一起算既容易被质疑也看不清下一步该优化哪里。3. Rasp的几条核心工作流是怎么搭的3.1 先讲一个通用的构建四步每一条工作流我们都按同一个套路来落地这个套路就是四个步骤定义输入输出。想清楚什么东西进来一条线索、一封往来邮件、一段会议录音转写、什么东西出去分级标签、邮件草稿、行动项列表、结果写到哪个系统。人工跑50条样本。拿真实数据人工标注一遍作为提示词设计的参照。没有这个参照提示词写得再花哨也是盲调。用样本调提示词。一条条试目标是10条结果里至少8条能直接用。达不到就继续改提示词或补示例。影子模式跑两周。Rasp只给建议、不自动写入任何系统销售同事看到结果后手动落库。等误判率降到可接受范围再放开自动执行权限。这个影子模式是整个项目的生命线。3.2 线索初筛与分级数据量大才值得自动化我们团队最耗时的环节就是线索初筛。外部渠道每天进几十条新线索以前销售要挨个看官网、看需求描述、判断有没有预算和决策链一条平均要花5到15分钟。1200条线索光这个环节一个月就要烧掉150小时。Rasp的第一条工作流做的是定期从不渠道导入新线索整理成统一的JSON结构调OpenRouter的模型做意图识别输出行业、规模、需求信号、决策链完整度的判断按规则打上A/B/C三档A档是高意向且预算充足B档是值得跟进C档是近期大概率没有需求写回CRM的待跟进列表同时给销售推一条优先处理建议。提示词大概长这样你是一名有10年经验的B2B销售线索分级专员。 请基于以下线索信息输出JSON - lead_id - company_name - industry - company_size - intent_signals - decision_maker_info 分级要求 1. 分三档A-高意向高预算B-值得跟进C-近期无需求 2. 必须给出一句话分级理由 3. 必须给出优先触达渠道建议邮件/电话/社媒 4. 如果信息不足confidence字段输出low这里有个关键设计置信度控制。如果模型对一条线索判断得很重要但信息又不够完整那就不能直接自动写入。我们在代码里加了一道校验def validate_lead_output(data): required [level, reason, confidence] missing set(required) - set(data.keys()) if missing: raise ValueError(fmissing fields: {missing}) # 低置信度的A档线索必须人工确认 if data[confidence] low and data[level] A: return human_review if data[level] not in (A, B, C): return human_review return auto_write这条规则防止了最严重的后果模型把一条大单线索误判成C档、销售也不看结果白白丢掉商机。低置信度A档强制转人工宁可多花一分钟不可放过一个潜力客户。3.3 外联邮件起草让模型先猜痛点再写正文销售外联邮件特别容易写成两种极端要么是千篇一律的模板腔要么是大白话到没有重点。Rasp的邮件起草工作流是这样设计的输入的字段包括联系人姓名、公司一句话简介、客户最近公开动作官网新闻、招聘动态等这类信息我们会先抓取再压缩、历史往来记录、以及团队里公认写得最好的5封历史邮件作为风格样本。关键的一步是让模型先输出对客户痛点的猜测再写正文。这样邮件正文不会空洞无物也不会一上来就是我们很高兴向您介绍这种废话。生成完后Rasp会把邮件投递到销售个人的草稿箱人看一眼改一改再发。我们还给邮件模板加了几条硬约束最多使用两个形容词、禁用期待积极沟通如有兴趣请回复这类低频转化话术、正文不超过120个单词。这些细节是处理过一个客户回信说你们这是群发模板吧的惨案之后总结出来的后面踩坑部分会细聊。3.4 会议纪要与CRM同步把最烦的活干干净销售每天至少两场客户会议一场短则半小时长则一小时。以前开会要有人记录会后还要整理纪要、把下一步行动项同步给CRM、给参与者发待办邮件的提醒。这套动作做完一场会将近一小时就搭进去了。Rasp的会议流处理方式是销售把会议系统的转写文本丢给Rasp我们不允许直接把音频传出去只处理文本转写结果Rasp提取三样东西结论清单、分歧点清单、行动项清单行动项必须输出责任人动作截止时间三条要素结果先展示在页面里销售确认后才同步进CRM的相关字段。提示词里特意加了一句区分明确承诺和口头客套。这是处理了很多历史会议记录后发现的规律——模型容易把所有我们之后可以……都当成行动项实际上有一半是礼貌性回应。加了这条之后纪要的可用度立刻上了一个台阶。CRM同步我们做了字段级风控联系人变动、商机阶段变动、金额变动、预计成交时间这四个字段必须人工确认后才入库其他常规字段允许自动更新。这样既省时间又不会出现CRM里躺着一条错误的大字段月底一看数据全歪的事故。3.5 周报与数据问答把销售从Excel里解放出来销售团队每周都要交周报以前大家要到周五下午花一两个小时整理CRM导出数据做透视表再拼上几句总结。我们做了一个周报草稿器Rasp每周五中午自动从CRM只读数据里跑一遍汇总生成一份包含本周新增线索、跟进次数、阶段变化、商机预计金额的周报草稿销售只需要补充项目故事和个人思考。另外还做了一个自然语言的数据问答入口销售可以直接问这个月A类线索集中在哪些行业上周发了多少封邮件、回复率多少。Rasp从CRM提取对应字段算完以后用表格形式返回。这个功能看起来不起眼但实际使用率非常高因为大家是真的不想开Excel。注意数据问答入口我们只给了只读权限限定字段范围不允许Rasp改写任何CRM记录。安全边界一开始就要划清楚后续才不会出乱子。4. OpenRouter路由策略成本、质量、延迟怎么平衡4.1 任务分级不要让最强的模型去干最简单的事5人团队一个月跑下来OpenRouter路由带来的好处会直接体现在账单上。我们把Rasp里的任务分成三档档位任务类型模型选择温度说明T0线索分级、字段抽取、格式校验轻量型模型0.1便宜、快、输出稳定T1会议纪要、邮件改写、周报生成中等能力模型0.3~0.7质量和速度的平衡点T2客户痛点诊断、竞品对比、复杂方案初稿强推理模型0.7~0.9只在真正需要推理的场景用最开始我们图省事所有任务都用同一个强推理模型结果是线索分级这种简单任务也在烧大模型的token成本高速度还慢销售点一下要等五六秒。后来按任务分级路由月度API成本降了一半整体响应速度明显提升。这里要提一句OpenRouter的价值以上这些切换在我们内部只是配置层面的变化。Rasp的代码里写的是一个统一请求函数模型名从配置中心读不同任务配上不同模型名而已不需要为每个模型单独写一段调用逻辑。4.2 上下文管理别把整家公司官网塞进提示词踩得最狠的坑就在上下文上。第一次做客户资料整理时我们试图把客户官网全部页面抓下来丢给模型让它做客户画像。结果token消耗暴涨模型输出反而更差因为无关信息太多还容易产生幻觉。后来规则改成先抓取、再摘要、最后进上下文。用轻量模型先对客户官网的前几个关键页面做结构化摘要把摘要压缩到几百个字以内再交给主流程使用。上下文一短成本和准确性同时改善。另外Rasp会把高频的系统提示词团队历史邮件风格样本放进缓存里避免每次调用都重复计费。这部分优化不复杂但积少成多月末账单上能看得很清楚。4.3 重试与降级不能让流程卡在模型报错上模型API偶尔会超时、限流、返回空结果这是逃不掉的。Rasp的统一入口里做了三层兜底同一个模型重试最多两次间隔几秒重试失败后自动切换OpenRouter上的备选模型再跑一次连续两次都失败任务进入人工队列绝不静默丢弃。这套策略保证了一个很关键的结果销售同事看到的工作流几乎是稳定的偶尔慢一点但不至于中断。对我们这种没有专人值机的团队来说稳定性比单次结果质量更重要。4.4 成本实测第一次账单飞涨4倍之后项目上线第一周OpenRouter的账单直接飞了比预期高了4倍。查日志发现问题出在邮件优化这个工作流我们写了一个循环模型每次输出后还会被拿去再优化一遍优化到销售满意为止。结果一条邮件动不动就要调用模型五六次token自然扛不住。修复方案是给每类任务加最大步数限制简单任务只允许调用1次复杂任务最多调用3次超限就把当前最优结果交给人审不再让模型自己一遍遍卷。加了限制后月度API账单降到原来预计的2/3绝对成本大概相当于5人团队中一个人一两天的时薪完全可以接受。提示Agent类项目最容易失控的永远是无边界地让模型自己迭代。任何循环都要设步数上限任何让它再优化一下的需求都要问一句优化到什么标准算停没有终止条件账单会教你做人。5. 踩过的坑与完整排查链路5.1 坑一Agent自循环账单失控先说账单飞涨那次。这个坑属于配置不当而非模型本身的问题。现象是某天OpenRouter请求日志里的单条线索调用次数突然变成正常值的6到7倍而且集中在一个工作流上。排查链路是这样的先看OpenRouter后台的请求明细定位到某个工作流token消耗异常再查Rasp的日志发现该工作流里的邮件优化步骤被反复执行每次输出稍微不满意就再优化一次最后翻代码定位到一个for循环它把优化定义为独立的处理步骤没有设置终止条件导致模型一直被要求重写。修复方法很直接删除这个自动优化循环改成生成一次不行就在原始版本上人工改。同时给所有工作流加了全局的最大模型调用次数限制。我学到一个非常实在的教训答案不是更长更好的提示词而是流程控制。5.2 坑二结构化输出字段漂移CRM差点被污染第二个坑更隐蔽。某天运营同学发现CRM里有几条线索的grade字段是空的再往下查还有联系人字段被写成了John待确认这种格式。我们在Rasp的思路是要求模型输出固定JSON但某些场景下模型仍然会自由发挥把字段名改成grade_score或者把等级写成中文标签导致下游解析失败。排查链路先从Rasp日志里找到写入失败的记录比对模型原始输出发现模型确实返回了JSON但字段名和文档不一致用代码校验后发现解析逻辑太严格json.loads失败就丢给人工没有做容错。修复方案是三层先用宽松解析把JSON块从文本里捞出来再按schema逐字段做兼容映射映射失败就重试一次两次都失败才转人工。最后还加了一份字段别名表把模型常见的别名映射到标准字段名。经过这样一套处理CRM自动写入的准确率到了99%以上剩下1%转人工。5.3 坑三AI味太重客户回信说你们这是模板吧这是最让团队脸红的一个坑。某客户回复一封外联邮件开头就写我猜你们这封邮件是模板群发的内容很工整但不像是针对我们公司写的。当时Rasp生成的邮件确实太像AI了每段都是总分结构形容词密度高结尾永远是标准的行动呼吁。客户的敏感度远比我们想象的高。这个坑的修复不是换模型而是从三个层面下手让Rasp学习团队里最优秀销售的5封历史邮件模仿真实语气而不是写得专业提示词里加硬约束最多两个形容词不用期待积极沟通也很感兴趣这类词正文控制在120词以内流程上强制要求凡是Rasp生成的邮件销售发送前必须人工修改至少3处哪怕只是改个开场白。从那以后邮件回复率反而比上线前略高了一点。这也让我想明白一件事人在回路不是效率的敌人是质量的下限。完全指望模型输出直接发出去迟早出事。5.4 坑四模型响应太慢销售直接用回Excel第四个坑比较反直觉模型准确率已经不错了但销售同事还是不太愿意用。原因是延迟。有一次我站在同事身后看操作点了一下生成邮件草稿页面转圈转了6秒多。他叹了口气说还是自己写快。当时我们只优化了模型选择忽略了交互方式。大模型推理再快简单任务也要一两秒复杂任务走上十秒都不奇怪。在销售那个场景里等待就是一种厌恶。修复思路不是压缩延迟而是改变交互模式把同步等待改成异步预生成。批量任务如线索分级在后台跑队列跑完以后推送通知销售点开就能看到结果邮件草稿也是先一次性生成10封备选人再打开逐封审改。这等于把人等着模型变成人去看结果。这个改动之后使用率直线上升再也没人提回Excel的事。6. 这套方案能复制到什么程度6.1 先看看你们团队满足这三个前提吗写到最后必须泼一盆冷水不是所有销售团队都能复现这个600小时的故事。我们觉得至少要有这三个前提流程已经SOP化。如果连销售流程都还没固定下来每天做的事情都不一样AI没有稳定的输入输出可以对接硬上Agent只会变成负担。输入输出和系统接口是清晰的。线索在某个表里、CRM有固定字段、邮件模板有迹可循Rasp才有下手点。团队里有人愿意做提示词运维。AI不是配置完就一劳永逸的。我们的经验是每两周就得把这几周出现的bad case收集起来喂回提示词和样本库持续迭代。这个人可以是运营可以是业务负责人但必须存在。如果不满足你的路径可能不是复制我们的方案而是先在团队里把流程梳理清楚再来谈自动化。6.2 合规和安全这部分没有商量余地销售场景牵扯到的数据很敏感客户姓名、企业联系人、预算金额、商机阶段这些我们不能直接丢给第三方模型API。这块我们的做法是数据最小化能传摘要就不传全文能传脱敏值就不传原始值合同全文、底价表这种内容一开始就被排除在Rasp的处理范围之外合规确认前置项目启动前就先过合规审查明确哪些字段可以进模型、哪些只准留在本地权限分级普通销售只能操作自己客户的数据运营可以看汇总视图字段变更需要审批的另走流程。这些约束看着麻烦其实是必要的安全网。任何提效项目效率翻倍的前提都应该是风险可控。6.3 从5人到20人的演进路线如果团队从5人涨到20人Rasp大概率要变成另一个形态第一阶段5人单机脚本加一个简单页面开发投入低够用就行第二阶段10人左右加权限控制每个销售组有独立空间公共提示词库用版本管理不让每个人私藏自己的prompt第三阶段20人以上加审批流、数据看板、任务队列让整个系统更像个内部平台。但我的建议是不要急着多智能体化。很多人看几个Agent互相协作觉得很酷但实际业务里把一条线索工作流的端到端自动率从70%提到90%比再挂三个花哨的Agent有用得多。效率项目的衡量标准是业务指标不是技术复杂度。写在最后一个小技巧最后分享一个我们一直在用的笨办法每个月月底把Rasp的日志导出和销售同事自己填的月度工时自评放在一起交叉比对。重点不是核对谁偷懒而是找出那些日志显示已经自动处理了但大家仍然手工做了一遍的环节。每次都能发现一两处。原因通常是Rasp在这个环节有过几个bad case大家对它不信任宁可靠自己。找到以后把case喂回提示词再约同事一起实测一轮把不信任区一点一点消灭掉。没有一次落地是光靠提示词完成的一定是流程、观测、信任循环三件事一起转起来才行。希望这篇复盘对你们有帮助。