Runable Grow 刚宣布完成 2100 万美元融资核心方向是“全链路 GTM 智能体”。GTM 是 Go-To-Market 的缩写范围很宽从产品准备推向市场到线索进来、被清洗、被触达、被跟进、被转化再到数据反哺后续策略这条链路都算。过去这件事靠 CRM、营销自动化、销售手动跟进拼起来链路长、数据断点多。现在把线索清洗、意向判断、触达执行、销售交接、效果回收交给智能体串联这才是“全链路”三个字真正值得关注的地方。如果你在做销售运营、市场投放、企业 AI 落地或者正打算在公司内部搭建销售智能体这篇文章值得看完。接下来我会把 GTM 智能体拆成几个可以当项目来做的问题先想清楚它解决什么再设计工作流然后定验收标准最后知道卡住时去哪里排查。整个思路不仅适用于 Runable Grow也适用于任何想用智能体改造销售流程的团队。1. 先搞清楚 GTM 智能体到底解决什么问题很多团队第一次看到“GTM 智能体”时容易把它理解成一个更聪明的销售助手能写邮件、能总结会议、能生成跟进话术。这些确实是能力的一部分但“全链路 GTM 智能体”的核心不在单个能力而在于把一到多个智能体编排成一套可运行的销售流程。1.1 传统 GTM 的最大断层线索和跟进之间做 To B 销售的人都有体感市场部花大量预算投广告、做内容、办活动线索进入 CRM 后销售要花时间手动查公司背景、找联系人邮箱、写第一封触达邮件。等销售做完这些动作线索可能已经被同赛道竞对抢先联系了。传统 GTM 流程里最常出现的几个问题线索跟进速度慢从线索创建到第一次触达往往隔了一天以上。触达内容过于模板化销售没有足够时间做个性化调研只能改改称呼就发出。销售交接信息丢失市场线索转给销售时只有基础联系方式缺少行为记录和意向信号。数据回填靠人跟进结果、客户反馈、下次跟进时间都要销售手动录入 CRM漏记很常见。归因不清晰一个客户最后成交到底是哪封邮件、哪个电话、哪次活动起了作用很难准确判断。这些问题不是单一工具能解决的。CRM 能记录结果但不能主动执行触达营销自动化能发邮件但很难根据实时回复动态调整下一步大模型能生成内容但不了解你的客户分群和销售策略。GTM 智能体的设计逻辑是把“数据获取、内容生成、触达执行、意图判断、销售交接”全部串在同一个流程里。1.2 智能体如何把链路串起来“全链路”并不意味着只有一个超级智能体包办所有事情。更合理的架构是多个小型智能体协作每个智能体负责一个专业环节再通过一个编排层统一调度。这种思路和现在大家常说的“多智能体”是一回事只是把场景聚焦到了 GTM。一个典型的 GTM 智能体流程可以拆成这样线索接入智能体接收来自表单、广告、会议活动、官网访客的线索完成去重和基础清洗。画像补全智能体根据公司名称、官网、公开信息补齐行业、规模、区域、关键联系人。意向评分智能体根据行业匹配度、职位角色、访问行为、是否打开邮件等信号打分。触达内容智能体基于客户画像生成个性化邮件或社交私信准备多版备选。触达执行智能体按设定的时间节奏发送自动处理退信、自动提醒销售。回复识别智能体识别客户回复中的意向等级判断“有兴趣、暂时不感兴趣、需要转给销售”。销售交接智能体把完整的时间线、沟通摘要、建议动作打包推送给对应销售。效果回收智能体把打开、回复、退订、转化结果写回数据表反哺评分和内容模型。这八个环节并不是每次都要全上。具体要拆多细取决于公司的客户量级和销售模式。线索量少、客单价高的项目可以先做画像补全和销售交接线索量大的行业再优先做清洗、评分和自动触达。1.3 判断一个系统是不是真“全链路”判断标准不应该是“有没有接大模型”而是看四件事有没有形成闭环有没有触发新线索进来是否会自动进入流程。有没有执行每个节点是否真的产生了动作而不只是生成建议。有没有反馈回复、退订、拒绝这些结果是否被捕获。有没有优化效果数据能否影响下一次评分和触达策略。如果没有反馈和优化那本质上还是“AI 辅助生成 手动执行”不能叫智能体。这也解释了为什么 Runable Grow 这种全链路方向会出现它想解决的不只是“写一段更好的销售文案”而是“如何让整条销售流程自己转起来”。GTM 环节传统工具/人工智能体增强线索清洗销售手动查重、补全自动去重合并多来源记录客户画像手动搜索公司信息自动补全行业、规模、决策链内容触达模板邮件群发按客户特征生成个性化首触内容意向判断凭经验判断回复基于行为数据和回复内容打分销售交接口头/邮件转交输出完整沟通时间线和摘要效果回收销售手动录入 CRM自动回填打开、回复、转化数据如果你正在评估一个智能体平台建议直接对着这张表看它到底覆盖了哪几个环节环节之间是独立运行还是真的能互相传递上下文。这比看产品 Demo 里单封邮件写得多好更有价值。2. 2100 万美元融资背后资本看好的是“串联能力”而非单点工具Runable Grow 这轮融资规模是 2100 万美元。对于一个 GTM 类产品来说这个金额不算小。它释放的信号不只是“AI 销售赛道热”更关键的是资本开始认可“把销售流程做成智能体工作流”这个方向。2.1 为什么资本会押注 GTM 自动化过去十几年企业服务里最成熟的自动化发生在研发和客服领域。研发有 CI/CD客服有机器人分流但销售和市场的自动化程度明显落后。核心原因是 GTM 流程太依赖人的判断客户什么时候有意向用什么话术切入不同行业之间的决策链差异很大规则引擎很难覆盖。现在大模型把这个限制打开了一部分。智能体可以根据上下文动态调整触达方式客户回复“最近预算紧”和回复“这周可以聊聊”是两种完全不同的路径。传统营销自动化很难处理这种差异但智能体可以做意图判断和分支流转。从商业角度看资本喜欢 GTM 方向还有一个很实在的原因离钱近。销售工具的效果可以直接体现在线索量、回复率、成交率这些指标上企业愿意为可量化的收益付费。相比之下很多 AI 辅助工具的效果很难归因而 GTM 工具天然有 CRM 里的数据做证明。2.2 融资事件能说明什么不能说明什么对于普通团队看到“融资 2100 万美元”时最好保持两种清醒第一融资只说明投资方认可产品方向不说明产品已经成熟。很多早期 AI 产品在公开 Demo 里表现很好接入真实客户数据后才发现数据结构混乱、权限复杂、销售流程特殊。判断产品能不能用还是要回到自己的场景里做验证。第二全链路是产品目标不代表所有客户都能一步到位。Runable Grow 如果要做全链路就必须面对不同企业完全不同的 CRM、数据源、销售 SOP。这种产品通常需要大量配置和集成工作不是开箱即用。实际落地时企业往往还是先从某一个环节开始跑通了再逐步扩展。2.3 赛道逻辑从单点 AI 工具走向流程编排平台这轮融资背后还有一个更值得关注的趋势GTM 工具正在从“单点增强”走向“流程编排”。前两年流行的做法是给销售配一个 AI 写信助手或者给市场配一个内容生成器。这类工具很容易被大模型能力覆盖壁垒不高。真正的壁垒在于编排层能不能稳定地把多个模型、多个数据源、多个业务系统连接在一起并且让一个节点失败时不影响整条链路。这就涉及工作流引擎、任务队列、权限管理、日志追踪、人工兜底等一系列工程问题不是单纯调大模型 API 能解决的。所以如果你所在团队也在考虑做 GTM 智能化不要只关注“用哪个大模型”更多精力要放在流程编排和系统集成上。模型能力会持续升级但客户数据、销售 SOP、部门协作方式需要你一点一点梳理清楚。3. 落地上手把全链路拆成可搭建的智能体工作流智能体听起来很玄落地时其实就是一套工作流。区别在于传统工作流每个节点是固定规则而智能体工作流里某些节点具备动态决策能力。下面按一套通用方法拆解不管最后用 Runable Grow、其他智能体平台还是自研框架思路都适用。3.1 第一步先画主流程不要急着选模型我见过不少团队上来就问“该接哪个大模型”这是顺序错了。先画主流程画完之后你会发现真正难的不是模型选择而是流程里那些“需要人去判断”的节点怎么定义。先拿一张白纸列出从线索进来到成交的必经节点。下面是一个常见的最小流程线索进入。判断是否重复是否有效。补全公司、联系人、行业、规模信息。根据规则或模型判断意向等级。生成第一轮触达内容。发送邮件/私信。等待回复设置超时时间。回复后判断意向有兴趣、不感兴趣、需要人工跟进。转给对应销售交接上下文。销售成交或暂缓回写结果。这十个节点不一定都要自动化。比如第 8 步完全可以用模型识别也可以先由销售人工确认。初期我更建议把“低风险、重复度高”的节点自动化把“需要判断、容易出错”的节点留给人。3.2 第二步定义每个节点的输入、输出和成功条件每个节点都要回答四个问题输入是什么从哪个系统、哪个字段拿数据。输出是什么处理后写入哪个字段。成功条件是什么判断这个节点有没有正常完成。失败分支是什么是重试、跳过还是转人工。举例来说“画像补全节点”的输入是线索里的公司名称输出是补全后的行业、规模、官网地址。成功条件可以定义成“关键字段完整度大于 80%”。如果某个公司信息过少补全失败这不算致命错误可以把它标成“低完整度线索”降低触达优先级而不是直接卡死流程。下面是一个示例配置不是 Runable Grow 的具体配置而是一种通用流程设计参考{ workflow: lead_to_followup, trigger: { type: crm_event, event: lead.created }, nodes: [ { id: deduplicate, type: rule, input: [lead.email, lead.company], output: lead.status, success: lead.status ! duplicate, failover: end }, { id: enrich, type: llm_call, input: [lead.company], output: [lead.industry, lead.size, lead.website], success: profile.completeness 0.8, failover: manual_review }, { id: score, type: rule_llm_mix, input: [lead.industry, lead.size, lead.behavior_score], output: lead.score, success: lead.score ! null, failover: default_score }, { id: generate_message, type: llm_call, input: [lead.industry, lead.size, lead.pain_point], output: message.draft, success: message.draft ! , failover: template_message }, { id: send_email, type: integration, input: [message.draft, lead.contact_email], output: message.sent_at, success: message.sent_at ! null, failover: retry_then_manual } ], global: { max_concurrency: 5, timeout_seconds: 30, retry: 2, retry_interval_seconds: 60, manual_review_channel: sales_queue } }这段配置表达的核心思想是每个节点都有限定的输入输出都定义“什么不算成功”都有失败后的兜底路径。没有兜底路径的智能体流程上线之后一定会让团队天天救火。3.3 第三步选择搭建方式搭建方式大致分为三类方式适合场景缺点低代码智能体平台团队没有专门工程资源想快速验证流程自定义逻辑受限复杂权限较难处理自研框架对数据安全、流程控制要求高开发周期长需要维护任务队列和模型调用混合模式平台跑主流程自建部分特殊节点需要定义好平台和自研接口之间的数据协议到底选哪种取决于团队规模和已有系统。如果公司已经有自己的 CRM、数据仓库而且销售 SOP 很特殊自研或混合模式更稳。如果只是想先验证一下智能体能带来多大增量低代码平台是最快路径。这里要提醒一个点低代码平台不等于不用写流程。你还是要自己理解 GTM 业务逻辑否则只会把一个混乱的流程搬到平台上跑得再顺也是错的。3.4 核心参数和判断标准智能体工作流里有几个参数会影响稳定性和效率建议一开始就明确并发数同时处理多少条线索。不是越大越好太大会触发邮件服务商的限流也会让模型接口延迟增加。超时时间单个节点最长等待多久。模型调用、外部接口都可能卡住不设超时会导致整条队列积压。重试次数外部接口失败后重试几次。重试太多会放大故障一般 1 到 3 次比较合适。人工阈值哪些情况必须转人工。比如客户回复明确提到“别再联系我”这时候系统应该立即停止自动触达而不是继续生成新文案。限频规则同一天对同一联系人最多触达几次。这个参数在销售场景里非常关键直接影响客户体验和合规风险。配合这些参数还要定好日志规范。每个节点执行完至少记录当前状态、耗时、输入摘要、输出摘要、失败原因。这样后面排查问题的时候不会两眼一抹黑。4. 从单场景试跑到生产部署资源、流程和验收很多团队拿到全链路产品后恨不得把所有线索都交给智能体。这种心情能理解但实操上风险很大。我更建议分两个阶段走先做单场景验证再进入生产部署。4.1 单场景验证先跑通一条“窄链路”选一个范围很小的客户群比如“最近一个月注册但未转化的 SaaS 小企业”大概 100 到 200 条线索。只跑一个渠道比如邮件首触。目标不是拿到多少回复而是验证三件事线索能不能稳定进入流程。每个节点是否能正常执行。结果数据能否回写到 CRM 或数据表。这个阶段不追求复杂只求跑通。看到一条线索从进入系统、生成邮件、成功发送、记录日志全链路没有断才算第一步完成。我一般会在验证阶段做一次“输入破坏测试”故意造几条异常线索比如邮箱格式不对、公司名为空、重复线索看看流程会怎么处理。好的流程设计应该把这些异常都识别出来并放进人工队列而不是让整个任务卡住。4.2 生产部署不再只看“能不能跑”还要看“稳不稳定”单场景验证通过后再扩大范围。生产部署阶段要重点处理下面几件事数据权限不同销售只看自己的客户不能因为智能体统一调度就把客户隐私暴露给所有人。失败重试并发上来后接口报错、限流、超时都会更频繁必须有重试和死信队列。人工兜底标明“AI 自动处理”和“人工处理”并存。比如系统自动生成触达内容后可以先由销售点击确认再发送也可以直接全自动发送取决于团队对风险的承受度。效果回收把打开、回复、退订、拒绝等结果及时回写否则后续评分和内容优化没有依据。输出命名和记录批量任务最容易乱的是“同一客户被重复触达”或“多个销售争抢同一条线索”。生产部署前要把客户归属、任务编号、流程状态定义清楚。4.3 验收标准不要只看转化率智能体项目的验收指标要分成“效率指标”和“质量指标”两组。效率指标常见的有首触耗时线索创建后多久完成第一次有效触达。处理量单日能稳定处理多少条线索。人工介入率多少比例的节点需要人工处理。质量指标常见的有回复率和人工邮件组对比是否有明显差异。退订率是否高于行业正常水平。无效触达率因为邮箱错误、地址无效导致的发送失败比例。人工处理满意度销售是否认可智能体交接过来的上下文。维度单场景验证阶段生产部署阶段数据量100-200 条全量/目标客户池并发1-5按渠道限流和资源动态调整目标观察链路是否跑通观察稳定性、质量、效果人工权限可全程人工审核明确自动和人工边界关键指标节点成功率、日志完整性回复率、转化率、人工介入率异常处理简单重试死信队列、人工兜底、告警通知如果验证阶段连 200 条线索都跑不利索就不要急着扩大。问题扩大后排查成本会成倍增加。4.4 低配置环境下的尝试方向有些团队没有专门的 AI 工程资源也没有高配 GPU。GTM 智能体多数情况下走的是大模型 API 调用对本地算力要求不高但对外部服务的稳定性和权限管理要求更高。如果你所在团队环境比较受限建议从“半自动”开始系统生成客户摘要和触达建议销售确认后发送。这样既能看到智能体的效率提升又能保留人的判断力。真正决定能不能跑起来的通常不是模型性能而是数据是否干净、CRM 字段是否齐全、销售和市场是否愿意配合。5. 销售智能体最常见的卡点和排错顺序智能体上线后问题不会少。下面几个现象是销售智能体项目里最高频的我按“先看什么、再看什么”的排错顺序整理出来。5.1 常见现象一流程不触发线索已经进入 CRM但智能体没有动作。很多人第一反应是“模型出问题了”实际排查时应该先看事件有没有到达工作流引擎。可能是 CRM 的 Webhook 没配好也可能是 API 密钥失效或者事件类型不匹配。排错顺序查看是否有新任务产生。查看 CRM 事件日志确认线索创建事件是否成功推送。查看工作流触发条件是否和数据结构一致。查看是否有权限或者 IP 白名单拦截。5.2 常见现象二邮件发出去了但内容雷同很多智能体邮件一多就显得模板化原因不是大模型不会写而是输入给模型的画像字段太少。客户画像里只有公司名和职位生成结果自然同质化。排错顺序检查画布字段完整度是否覆盖行业、规模、近期动态、关键联系人。检查提示词里是否使用了足够的差异化变量。检查触达内容里是否有限制比如“必须使用模板禁用词”。如果画像不足先关掉个性化生成改回人工写一封优质邮件不要硬让模型在无信息条件下硬编。5.3 常见现象三同一客户被重复触达重复触达通常不是模型问题是流程设计问题。常见原因是“线索更新事件”和“新建线索事件”同时触发或者去重节点没有在流程最前面生效。排错顺序看 CRM 里是否产生了多条相同客户的记录。看去重规则匹配字段用的是邮箱、域名还是统一社会信用代码。看事件触发是否包含更新操作避免每次字段变更都触发一次全流程。在触达节点加“24 小时内不可重复发送”的幂等控制。5.4 常见现象四回复识别不准客户回复“不需要”被识别成“有兴趣”或者回复“邮件收到了我看看”却被判定为“无意向”。这种问题本质上是意图分类的边界不够细。排错顺序检查意图分类标签是否太少只有“有兴趣/没兴趣”两类时模糊表达容易误判。检查是否需要加入“不确定转人工”这个分类不要强迫模型在模糊输入下硬选。检查历史人工标记结果用真实纠偏数据优化提示词或模型。对高价值线索宁可多转人工也不要误判为“无兴趣”直接放弃。5.5 排错通用原则不管遇到什么现象建议都按这个顺序排查先确认数据有没有进来。再确认权限和配置是否正确。然后看模型调用是否正常。最后才怀疑流程设计和参数问题。最浪费时间的是跳过前两步直接看模型。很多“智能体出错”的案例最后发现是 CRM 字段映射错位或者某个人不小心关掉了调度开关。注意排错时要保留每个节点的输入输出日志。没有日志排查复杂问题基本靠猜效率会非常低。6. 团队现在要做的准备不是先买工具而是先把流程和数据理清Runable Grow 融资这件事说明 GTM 智能体赛道的产品会越来越多。但对大多数企业来说关键问题不是“选哪个智能体工具”而是“自己有没有准备好被智能化”。这个准备分为四个层面。6.1 数据质量决定智能体上限智能体所有判断都依赖数据。字段缺失、重复记录、归属混乱都会让智能体产生错误动作。建议在上线前做一次数据盘点CRM 里有多少条线索缺失联系人邮箱。同一家公司是否存在多条重复记录。客户行业、规模字段是自动填充还是常年空缺。销售归属是否清晰是否会出现同一个客户被多个销售跟进的情况。这些看起来是体力活但如果不做智能体上线后的错误率会高到让团队失去信心。我见过某些团队试跑智能体结果一周内给同一个客户发了五封邮件原因就是 CRM 里重复记录没清理去重节点再强也拦不住脏数据。6.2 销售和市场的 SOP 必须先书面化智能体工作流本质上是在执行一份 SOP。如果公司目前的销售流程靠老师傅口头传智能体无法复制。上线前市场部、销售部、技术负责人应该一起写清楚线索到什么状态算“有效”。首触用什么渠道、什么节奏。什么情况下转给销售什么情况继续自动培育。客户明确拒绝后如何处理。销售反馈的字段和更新时间要求。这一步没有技术含量但直接决定智能体能覆盖多少环节。流程越模糊智能体的自动化比例越低最后可能只变成一个“AI 内容生成器”和预想相差很远。6.3 建立反馈闭环不做一次性项目GTM 智能体不是配置完就结束的。客户的回复、销售的判断、成交与否都要不断回写到系统里。只有回写评分模型、内容生成策略才能迭代。我建议每周花一天做一次“样本复盘”拉出 20 条智能体生成的触达记录标注哪些有效、哪些无效把有效的原因沉淀为提示词规则。这个复盘动作会比换个更强的模型更有效。6.4 先自动化辅助再自动化执行不是所有环节都要一步到位。按风险从低到高推荐这样推进自动补全客户画像销售看得更快。自动生成首触邮件草稿销售确认后发送。自动发送低风险触达如会议邀请、资料跟进。自动处理“客户明确拒绝”的退订流程。最后才是全自动跟进系统直接在合适时间替换人工动作。每个阶段跑两周看数据、看反馈再决定是否进入下一个阶段。这样能避免销售团队因为一次事故彻底否定智能体项目。6.5 组织层面用一人或一小组专门负责流程优化GTM 智能体项目最怕“上线即解散”。市场部认为技术负责销售认为市场负责最后没人跟进效果。最好指定一个人作为“GTM 流程负责人”既懂销售业务又能理解工作流配置。这个人不需要写复杂代码但必须能把销售语言翻译成流程语言。如果团队没有这样的人初期可以从一名资深销售运营里选人培养。这比外招更稳因为他对客户、数据和部门衔接的理解需要时间积累。结尾全链路智能体的真正门槛在流程而不在模型回到 Runable Grow 这轮融资。2100 万美元押注的不是一个能写邮件的 AI而是“把 GTM 链条变成一套可编排、可反馈、可优化的智能体系统”这件事。这个方向对行业有价值值得持续观察。但落地时还是要守住一条底线先跑通单环节再谈全链路。真正让销售智能体发挥作用的前提是数据和流程都足够清楚。模型能力会越来越强智能体框架会越来越成熟但客户数据、销售 SOP、部门和部门之间的协作方式仍然需要团队一点一点打磨。购买工具只是开始把流程理清、把数据治理好、把反馈闭环建起来才是决定项目成败的关键。