先看一组我们自己算出来时都愣了一下的数字5个人的销售团队靠一套内部代号叫 Rasp 的 AI 智能体每个月省下约600小时的等效工时。当时这个数字报上去运营负责人第一反应是“你们是不是把等待时间也算进去了”。我说对等待时间本来就是要算的——客户回复的等待、系统流转的等待、人工来回确认的等待这些在过去都是一个萝卜一个坑地占着人的时间。Rasp 做的事情简单说就是把销售团队里那些重复、低认知、纯执行的工作接过来让真人只做需要判断和经验的事。这套东西能跑通底层依赖是 OpenRouter。它把我们接入多个大模型的成本压到了很低一个 API Key 就能按任务切换模型不用再分别对接不同厂商的接口。我把整个过程拆成几块讲清楚从时间账怎么算到 Rasp 的架构设计、关键配置、踩坑实录再到最后几句大实话。不管你是做销售的、带销售团队的还是正在给业务方做 AI 自动化的开发者这篇应该都能给你一份可以直接抄作业的参考答案。1. 先算一笔账600小时是怎么从5个人手里挤出来的1.1 五个时间黑洞把销售的一天撕成碎片我们团队做的是某 B2B SaaS 产品的销售客单价不算低销售周期两到三个月所以每个人手里同时有几十个在跑的线索。这种模式下真正影响成单的是有效沟通时长但现实是每个人的白天几乎都被五类事占满。第一类是线索清洗。CRM 里填进来的线索质量参差不齐有从表单里来的有展会扫码来的有客户转介绍来的经常缺联系人、缺行业标签、缺公司规模。正式联系之前销售得先去补齐这些信息一条线索平均花两分钟一天一百多条就是三四个小时。第二类是邮件跟进。一个销售一天收发几十封邮件真正需要深度回复的可能只有几封但每封邮件都要读完、判断意图、组织措辞再发出去三五分钟是跑不掉的。第三类是会议纪要。每周周会、复盘会、客户需求会加起来十几场开完会还要整理纪要、提取待办、同步到项目平台一场四十分钟算少的。第四类是报价单和合同初稿。价格表、服务项、折扣、付款条件都要填进模板改格式就要折腾半天。第五类是竞品动态和周报。销售新人要培训老人要盯竞品每周定期整理行业新闻、竞品更新、话术库一弄就是几个小时。这些事有一个共同点它们不是销售的“本事”而是销售的“成本”。我花了一周时间盯团队的时间消耗拉了一个保守的估算表场景原每月人工工时5人合计Rasp介入后的人工工时每月节省等效工时线索清洗与数据补全220小时50小时抽查与纠错170小时邮件语义识别与跟进起草200小时50小时一键确认或改写150小时会议纪要与任务提取120小时30小时人工复核分配90小时报价单与合同初稿生成120小时20小时人工审核价格100小时竞品情报整理与周报100小时10小时校准数据来源90小时合计760小时160小时600小时这个表就是整个项目的起点。刚才说了600小时不是把五个人每天压缩出多少“纯空闲时间”而是这些流程如果继续用手工做本该被吞掉的等效工时。对我们来说省下来的时间意味着同样的人力可以覆盖多三到四成的客户量或者把每个客户的触达频次提上去。1.2 为什么OpenRouter是这套方案的底座确定要做自动化之后技术选型是第一道坎。我们把需求列了一遍邮件语义判断要有强分类能力线索清洗要能处理非结构化文本会议纪要要能长文归纳报价单生成还得稳定输出结构化字段。没有哪个单一模型在这些任务上全都能打而且不同任务的频率和成本敏感度差别很大——线索清洗是高频、低单价的活会议纪要是中频、重上下文的活邮件起草是低频但需要谨慎的活。最初考虑直接接入多家大模型厂商的 API结果发现维护成本很高。每个厂商的接口格式、鉴权方式、限流策略都不一样今天这个模型效果好明天另一个模型降价了每切换一次都要改代码。后来团队里一个开发者提出来用 OpenRouter 做模型网关理由很直接它已经把几十家模型厂商的 API 统一成了一个标准接口我们用一套代码就能完成模型切换剩下的事情全部交给路由策略。OpenRouter 在我们项目里承担的角色可以理解成一个“模型调度中心”。Rasp 每个任务进来先看任务类型和复杂度再决定路由到哪个模型。比如批量文本分类这种对推理深度要求不高的活可以路由到便宜的轻量模型成本只有旗舰模型的零头而涉及客户邮件语义这种容易踩雷的任务就强制走强推理模型。这个设计用了一年最大的感受是“不被任何单一模型绑架”。某家模型服务临时不可用的时候其他家的接口照样顶着业务侧完全无感知。后面我会把具体的配置方式展开讲。2. Rasp怎么设计让AI干脏活把决定权留给人2.1 四条设计原则Rasp 上线之前我们定了四条不能破的原则这几条原则在后续推进中几乎决定了项目能不能被团队接受。原则一是“能自动的全部自动但对外动作必须留人工确认”。所谓对外动作包括发出去的邮件、报出去的报价单、对外承诺的交期等等。AI 可以起草可以推荐但最后一下点击发送或者确认必须由真人完成。这不是不信任模型而是把责任边界划清楚——模型出错时最终责任在操作的人。原则二是“Agent 只做初稿不做拍板”。Rasp 可以根据客户历史记录和当前对话生成回复初稿但遇到折扣、个性化承诺、风险话术它只会给出建议选项不会自作主张。团队里没有一个人会觉得被机器架空了反而觉得这是个干活很利索的助手。原则三是“每个动作都要可追溯”。Rasp 执行的每一次任务从触发条件、调用模型、输入输出到人工是否确认、确认耗时多久全部落日志。后面排查问题、计算真实节省工时、说服管理层继续投入靠的全是这些日志。原则四是“从低风险场景开跑别一上来就碰钱”。我们第一批自动化只做了会议纪要和内部知识库整理让团队用顺手了建立信任再逐步开放邮件、线索清洗最后才上报价单。这个节奏很重要销售团队对 AI 的接受度是养出来的不是逼出来的。2.2 一次任务在Rasp内部的完整流转Rasp 的整体结构不复杂本质上是一个带调度和记忆的 Agent 壳子核心可以拆成四层。第一层是触发层。它得知道什么时候该干活。我们接了三个触发器CRM 新建线索事件、邮箱收到新邮件事件、日历会议结束事件。也可以定时触发比如每天早上八点生成当日跟进建议每周五下午生成周报初稿。第二层是路由层。这是 OpenRouter 发挥核心作用的地方。Rasp 根据任务类型、文本长度、语义复杂度三个维度给任务打标然后决定走哪个模型。分类标签决定模型档位文本长度决定上下文处理方式语义复杂度决定是否追加“谨慎输出”的指令。路由规则写在一个配置文件里调整模型档位的时候只改配置不改业务代码。第三层是执行层。Rasp 要真正操作外部系统得靠工具。我们给 Rasp 配了 CRM 读写工具、邮件读取与草稿工具、日历查询工具、知识库检索工具、PDF 生成工具。每个工具都是一个封装好的函数Agent 通过函数调用方式使用。第四层是人工复核层。Rasp 输出的结果不是直接落地而是先进入一个审批队列。审批队列展示在团队内部的工作台页面上销售可以一键通过、一键退回修改、或者直接编辑后发送。这一层是整个系统信任感的来源。一个典型流程长这样客户给销售邮箱发来一封询价邮件 → 触发层把邮件文本送入路由层 → 路由层判断属于“高语义复杂度的商务沟通”路由到强推理模型 → Agent 调用 CRM 工具读取该客户的历史订单和沟通记录 → 结合知识库里的报价规则生成邮件回复草稿到审批队列 → 销售看到草稿微调了价格表述点击发送 → 任务完成日志记录全过程统计本次节省约4分钟。2.3 五条自动化工作流的具体实现线索清洗这条线Rasp 每天凌晨批量跑一次。逻辑是从 CRM 里抽出状态为“待清洗”的线索对每一条做公司信息补全、联系人多渠道匹配、行业自动打标输出结构化的补全建议。对于置信度在95%以上的字段直接自动写入置信度在70%-95%的字段写入“待确认”状态置信度低于70%的字段明确标出来交给人工补。这套分级让系统不至于瞎填同时把人工工作量压到最低。实测下来原来120条线索要手工处理四个小时现在销售只需要看那十来条低置信度的记录二十分钟左右就能收工。邮件处理这条线是使用频率最高的。Rasp 在邮件系统上做了收件箱监听对新到邮件做意图分类询问产品、询问价格、催促交付、投诉抱怨、已读不回的跟进、垃圾广告。分类结果直接决定动作。催交付的邮件会提示销售“该客户已经等了一周建议优先处理”询问价格的邮件会自动带上最近的报价模板草稿。我一开始担心分类不准确后来设置了连续一周的对照测试AI 分类 vs 人工分类一致率在九成以上剩下的基本都是边界模糊案件人的判断本来也会分歧。会议纪要这条线属于“用了就回不去”的典型。Rasp 接到会议结束信号后拉取会议语音转写文本做三段式处理先提炼议程和关键结论再按发言人提取待办事项最后把待办同步到项目管理系统并标记负责人。销售不需要打开会议工具再去逐条听录音直接点开 Rasp 生成的纪要确认任务分配无误即可。报价单这条线最谨慎。Rasp 从审批通过的邮件中识别报价需求提取产品型号、数量、客户行业、历史折扣再从价格表工具里拉标准价生成一式两份的报价 PDF 和配套说明文字。折扣字段只要出现就强制要求销售在审批台手动确认Rasp 不会自己往下填。这个设计在这个项目上线三个月后救了一次有个案子因为客户采购量很大Rasp 按惯例生成了批量折扣但那个折扣级别早就不适用于新款产品了幸好人工确认环节拦住了。竞品情报和周报这条线是定时任务。Rasp 每天扫描一批行业关键词和技术社区抓取内容做摘要去重后存入团队知识库每周五下午自动把一周的摘要拼成周报初稿。销售只需要删掉不相关内容、补充自己的客户反馈十分钟搞定。3. 落地实操接入OpenRouter与配置智能体的关键步骤3.1 模型接入与分级路由配置先把接入这步讲透。OpenRouter 的使用方式本质上就是一个标准的 Chat Completions API只是 backend 是它。第一步在 OpenRouter 创建账号、创建 API Key然后把 Key 配到环境变量里。我们用 Python 调用核心代码长这样import os import requests API_KEY os.getenv(OPENROUTER_API_KEY) url https://openrouter.ai/api/v1/chat/completions def ask_model(messages, modelopenrouter/auto, temperature0.3): response requests.post( url, headers{Authorization: fBearer {API_KEY}}, json{ model: model, messages: messages, temperature: temperature, max_tokens: 2000, }, timeout30, ) response.raise_for_status() return response.json()[choices][0][message][content]注意这里 model 参数填了openrouter/auto这个值表示让 OpenRouter 根据题目自动选一个合适的模型。在项目初期我们确实用它跑了一阵省去手动测试不同模型的功夫。等跑了两周积累了实际数据之后发现很多任务用自动路由不是最优的——有些场景想固定走便宜模型有些场景想固定走最强推理模型。于是我们改成了手动路由配置。我们的路由配置核心是一个映射表用 YAML 写成route_rules: - task_type: email_intent_classification model: openrouter/auto temperature: 0 human_review: false - task_type: email_drafting model: a-premium-reasoning-model temperature: 0.7 human_review: true - task_type: lead_enrichment model: a-cheap-fast-model temperature: 0.1 human_review: false - task_type: meeting_minutes model: a-premium-context-model temperature: 0.2 human_review: true分级的意义一是效果二是成本。我们把当月 API 账单拉出来对比过采用分级路由后单月成本比全程用旗舰模型方案降了差不多一半同时高难度任务的输出质量没有明显下降。温度这个参数也别忽视分类、清洗这类任务把 temperature 降到0附近输出更稳定起草邮件这种创意性任务调到0.6到0.8语气更自然。3.2 工具链打通CRM、邮件、日历、知识库Rasp 真正从“聊天机器人”变成“智能体”靠的是工具调用。我们把 Rasp 的所有工具统一成一套 JSON Schema 接口Agent 根据任务需要自行决定调用哪个工具。这里有一个实操建议工具定义要尽量窄一个工具只做一件事。比如“读取客户历史订单”和“写入线索状态”要拆成两个工具不要合成“操作客户数据”否则模型容易在参数上犯迷糊。CRM 工具我们对接了开放 APIRasp 可以读取线索、联系人、订单、跟进记录也能写入状态变更。邮件工具只开放了“创建草稿”权限没有开放“直接发送”权限严格遵守前面说的对外动作人工确认原则。日历工具用于读取会议时间、创建会议邀请。知识库用的是向量检索文档先切片再存入向量库Rasp 在回答时先检索相关片段作为上下文再生成回复。这一步对于报价规则、产品参数这类事实类问题特别重要能显著降低瞎编概率。还有个容易被忽略的工具是“模板引擎”。报价单生成不是让模型自由发挥排版而是让模型输出结构化字段值模板引擎去套用现成的 PDF 模板。比如模型输出product_code,quantity,discount0.15模板引擎负责排版。生成速度和格式稳定性都远超直接让模型生成 HTML 再转 PDF 的方案。3.3 人工复核机制防止AI失控人工复核不能设计成“每件事都要审批”否则销售会疯的。我们的准则是“按风险分级”。风险等级是自动计算的涉及对外发送的动作全要审涉及金额变更、折扣、合同条款的动作全要审只写内部笔记、整理标签、补全公开信息、生成内部摘要的动作直接自动执行但保留日志。这样销售每天打开审批台需要处理的条目通常只有十几条每条看一眼点掉整体不超过二十分钟。审批台本身要做得轻。我们用内部工作台做了一个简单的列表页每一条任务显示触发来源、AI 生成的草稿内容、关联的客户和订单、模型分辨率、置信度评分。销售可以直接在页面上编辑编辑后保存会触发版本记录。设置置信度评分是为了让销售对 AI 输出有提前心理预期。置信度来自三个信号模型返回时的采样概率、规则引擎的校验结果、知识库检索的相关度。三者加权生成一个0到100的分数。分数高于90的条目审批台默认折叠详情一键通过分数低于60的条目醒目提示“建议详细核对后再操作”。3.4 成本核算和效果追踪这套系统到底值不值账要算清楚。我们在每月最后一天拉一次报表统计维度包括各任务类型执行次数、调用 token 总量、按路由模型拆分的费用、人工审批通过率和退回率、以及“单任务节省工时”的汇总。节省工时的核算口径得提前定好否则各部门会扯皮。我们的口径是每个自动化任务以一个“手工完成该任务所需的标准时间”为基准再由人工实际处理时间折算。比如一封邮件人工标准处理时间是4分钟Rasp 起草后销售只需30秒确认那这单就节省3.5分钟。一个月下来所有任务的节省时间相加得到总节省工时。这样算出来才能支撑“每月节省约600小时”这句话。成本那边OpenRouter 的 API 是按 token 计费的。我们的月度用量大约在千万级 token费用在几百到两千之间浮动具体取决于当月高峰期。语音转写是另一个成本大头好在会议数量稳定费用可控。对比一下如果这600小时全部折算成招聘兼职或者外包处理的成本哪怕按当地最低时薪水平算也是 API 费用的几十倍。ROI 在这个项目里是断档级别的划算。4. 踩过的坑和排查实录4.1 模型选型不是所有任务都该用旗舰模型项目一开始我们犯过一个挺典型的错所有任务都用同一个强模型跑觉得“贵有贵的道理”。跑了一周发现邮件意图分类这种简单任务用旗舰模型完全是浪费而且因为强模型思考链路长响应时间反而更慢批处理队列经常堆积。后来把分类、标签、情感判断这类任务全部切到轻量模型成本降下来速度提上去准确率基本没变化。反过来也有教训。会议纪要在初期用轻量模型跑结果长对话摘要丢失关键决策待办事项提取得支离破碎甚至出现过把客户说的客套话当成需求的乌龙。这个场景换回强模型之后质量立刻上来。所以我的建议是每类任务上线前拿一周真实数据做 A/B 对照用轻量模型和强模型各跑一遍比对输出质量和成本再决定路由规则。4.2 API超时与限流OpenRouter 的 API 偶尔也会碰到限流和超时。最典型的场景是跟某几个大模型厂商的波动有关但因为我们走了聚合网关受影响面比直连小很多。即便这样代码里面也要做重试和退避。我们踩过的坑是没有重试机制时凌晨批量跑线索清洗只要有一个请求超时整个批处理就中断第二天早上销售看到的是“清洗失败”的报错。后来给请求做了三层保护轻量模型请求失败先退避重试重试次数上限两次重试仍失败就排队等下一轮批量任务统一补跑所有失败请求都会记录到错误队列运维只需扫一眼错误队列就能判断是模型问题还是网络问题。4.3 幻觉与数据安全幻觉是所有 LLM 应用的必修课。在我们场景里最怕的幻觉是编造客户名称、编造报价、编造历史沟通。处理思路就一句话让模型在事实性问题上不依赖记忆而是去检索。报价数字从价格表工具里实时读取客户信息从 CRM 工具里实时读取模型只做理解、归纳和生成不做记忆。凡是涉及具体数字、客户名称、日期、订单状态生成之后还有一道规则校验比如金额格式、折扣范围、日期逻辑。规则校验能拦掉一大半明显错误。数据安全方面我们规定客户个人敏感信息在传给模型前做脱敏处理模型拿到的字段里姓名和手机号替换成占位符生成完毕后再映射回来。Prompt 里也做了约束模型收到的指令是规则化、模板化的客户原始邮件中的内容被视为“待处理数据”而不是“指令”防止邮件正文里夹带恶意指令影响模型行为。这套防护虽然不是银弹但至少挡住了常规的注入尝试。4.4 团队信任问题这个坑最容易被技术团队忽略。Rasp 上线初期销售同事嘴上说“挺方便”实际行为却是不太敢用审批台里面堆了一堆未处理的草稿大家宁可自己重写邮件。后来我们发现根因是“不知道 AI 为什么这么写”。加了置信度分数和生成依据摘要之后销售能看懂每条建议背后的逻辑使用率才慢慢上来。还有个小细节审批台的一键通过按钮要设计得显眼编辑功能要顺手。如果工具本身用起来别扭AI 再智能大家也不愿意碰。我们的做法是让销售同事参加审批台的原型评审他们提了“不要让我在弹出的多个窗口之间切换”“草稿邮件要能一键复制到邮件正文而不是下载文件”这些实际操作建议。采纳之后团队接受度立刻不一样。5. 关于600小时几句大实话5.1 等效工时的口径前面表格里的600小时我必须再把口径说清楚免得有人照着抄作业的时候对不上。这个数字是“等效工时节省”不是“员工每天多出了这么多时间闲着”。它的意义在于如果没有 Rasp这些工作量必须有人去做那意味着要么团队加班要么增聘人手。所以你也可以理解为这套系统相当于在团队没有扩编的情况下凭空多出了大约三个半全职人力。这种算法在公司内部汇报时很站得住脚因为你拿出的是“人工原耗时 - 人工现在耗时”的差值每一步都有日志支撑。但如果有人拿这个数字说“我们团队现在每天只用干两小时活”那是不对的。销售们省下的时间大多从低价值执行转移到了高价值客户沟通上这是自动化项目该有的样子。5.2 哪些团队最适合做这套改造复盘一下这个模式不是所有销售团队都能照搬。适合的前提有三个一是流程标准化程度高销售每步动作都有明确规则AI 才有章可循二是线索和沟通量足够大至少每天两位数以上的批量任务自动化的规模效应才出得来三是管理层愿意花一到两周做流程梳理把原先“凭经验干活”变成“有规则可执行”。反过来如果你的团队做的是客单价极高的战略型销售每一封邮件都要仔细斟酌个性表达那自动起草邮件这步就不适合最多只做会议纪要和情报整理。工具是死的边界是活的。我们现在的思路也是分阶段扩大范围先帮团队省出时间再让省出的时间花在真正不可替代的事情上。5.3 给准备复刻的同学的最终建议如果你准备在团队里做类似的事我的核心建议有三条。第一条先花一周记录时间开销用数据说话。没有前面那张表后面所有技术方案都会变成自嗨。第二条不要一开始追求“全自动”先把“辅助生成 人工确认”的闭环跑稳。销售团队对 AI 的信任是靠一次次不出错的草稿攒出来的。第三条把所有技术细节留给日志别让销售去理解技术他们只需要看到一个好用的工具和一个清晰的数字。最后提一个我们自己还在优化的方向Rasp 目前还是“任务触发式”下一步准备做“主动建议式”比如根据客户长期不活跃、竞品动态等信号主动触发销售去触达某个客户。这会把节省工时进一步转化为商机收入。自动化这件事思路一旦打开可做的空间比想象中大得多。