都说 2025 年是智能体落地元年但真正把智能体用进业务的人可能体会更深的一点是能“跑通 Demo”的智能体很多能“接进销售、市场和客户成功流程里产生 ROI”的智能体很少。最近 Runable Grow 完成新一轮 2100 万美元融资并推出全链路 GTM 智能体的消息让不少做 To B 增长的同学开始重新审视 GTMGo-to-Market市场进入流程中那些重复、低效、依赖人的环节。这篇文章不打算只做融资新闻解读而是想借这个话题完整拆解 GTM 智能体背后的技术形态、落地架构和实操思路它和普通聊天的“AI 助手”到底有什么区别如果要自己在业务里搭建一个销售线索筛选、客户画像和首封触达的智能体应该怎么设计用低代码平台怎么落地用代码自研又该从哪里切入适合下面两类读者一类是看过不少 Agent 概念、但还没动手搭建过的开发者另一类是正在为公司选型 GTM 智能体平台想搞清楚内部实现逻辑的技术负责人。文章中会给出可运行的最小示例、平台选型思路、常见报错与排查清单。1. GTM 智能体为什么突然值钱1.1 先理解 GTM 是什么GTM 的全称是 Go-to-Market直译是“进入市场”。在 SaaS、企业服务、甚至传统制造业里GTM 通常指从产品准备好之后到客户真正付费之前的所有市场动作包括目标客户定位与线索挖掘市场活动策划与内容投放销售线索的触达、培育、跟进售前方案设计与演示合同谈判与关闭成交后的客户成功交接。这中间牵扯市场部Marketing、销售部Sales、售前Sales Engineer、客户成功Customer Success多个角色而且每个角色都在大量使用 CRM、邮件营销、广告后台、企微、Excel 等工具。传统做法是市场部把线索导进 CRM销售手动查公司信息写邮件打电话做完以后再把结果往回填。你会发现整个流程的技术含量全在“人的经验”上而 AI 真正能替代的是那些“一看就会、但极其耗时”的动作。1.2 为什么需要“智能体”而不是“自动化流程”过去大家也会用 RPA机器人流程自动化或者工作流工具去解决这类重复操作比如定时抓取线索、自动发邮件。这类工具适合“路径完全固定”的场景一旦判断条件一变流程就要重写。而 GTM 业务的特点正好相反客户不相同行业不相同响应不相同甚至同样是“高意向客户”不同行业的高意向判断标准也不同。这就要求系统具备很强的动态推理能力。智能体Agent与普通工作流最大的区别正是把“决策”交给了大模型。它可以根据当前客户特征自己决定先查什么、再判断什么、最后生成什么内容。Runable Grow 这类全链路 GTM 智能体产品本质就是把这种 Agent 能力渗透到从线索到成交的每个环节里。2. GTM 智能体的核心能力拆解一个标准的 GTM 智能体至少应该具备四个能力模块2.1 线索识别与统一画像智能体需要把散落在不同系统里的客户信息拉回来合并成统一的客户画像。比如官网表单里的客户名称CRM 里的历史跟进记录外部数据库里的公司规模、行业、融资状态邮件打开率、点击行为。这一步最关键的是“字段清洗”和“实体识别”常见做法是让 Agent 调用查询工具再通过大模型做信息抽取与合并。2.2 线索评分与优先级判断不是所有线索都应该第一时间跟进。智能体要能按规则或模型给线索打分比如行业匹配度、公司规模、行为热度、渠道来源等。评分结果可以由规则计算也可以由模型综合判断但规则计算更稳定、更易解释。2.3 个性化内容生成这一步最容易理解也最容易出效果。智能体要根据客户画像、行业特征、近期动态生成针对性的首封邮件、企微话术、跟进纪要甚至销售演示大纲。相比市场上通用的营销模板Agent 生成的内容往往更能提到客户关心的具体场景。2.4 多通道触达与结果回写智能体最终要执行动作所以它需要接入邮件系统、企微、钉钉、CRM甚至外呼系统。执行完成后还要把数据回写到原来的系统里形成闭环。2.5 销售辅助复盘成交之后Agent 还可以帮销售做赢单/输单复盘把关键因素沉淀下来反过来优化前端的线索评分策略。3. 智能体的技术架构从单 Agent 到多 Agent3.1 单 Agent 架构当一个智能体负责处理“查询客户信息 - 评分 - 生成邮件 - 发送”这样一条线性任务时我们可以把它设计成一个单 Agent。它内部通常包含组件作用大模型LLM理解用户意图、做决策、生成内容工具集Tools查询 CRM、发邮件、查企业信息等外部能力短期记忆记录当前任务上下文比如客户 ID、步骤状态规划循环Agent Loop反复执行“思考 - 调用工具 - 观察结果 - 再思考”3.2 多 Agent 架构随着业务复杂度提升单 Agent 会把所有职责混在一起导致提示词很长、上下文容易混乱、权限也不好隔离。这时候可以把不同职责拆成多个智能体例如市场智能体负责线索挖掘、内容投放、活动管理销售智能体负责线索跟进、邮件回复、会议预约客户成功智能体负责续约提醒、使用问题解答。多个 Agent 之间再通过一个“编排层”Orchestrator进行任务分配。编排层不一定需要额外写代码使用 Dify、Coze 这类平台时工作流本身就承担了编排职责。3.3 与传统 RPA 的对比对比维度传统 RPA / 工作流GTM 智能体流程定义固定步骤条件写死动态规划由模型判断下一步异常处理依赖人工配置分支可根据中间结果调整策略内容生成不支持或只支持模板替换可生成个性化内容适用场景跨系统数据搬运、固定审批销售线索筛选、客户沟通、策略推荐解释性好依赖提示词设计和日志追踪4. 环境准备与平台选型4.1 自研与平台选型对比在动手前先确认团队是“从零写 Agent 内核”还是“在平台上搭”。下面是几种常见选择方案适合团队优点缺点使用 Dify / Coze 低代码平台业务团队、初创团队上手快可视化编排复杂逻辑受平台限制使用 LangChain / LlamaIndex 等开源框架有算法和开发能力灵活、可深度定制学习成本高抽象层多基于大模型 API 自研 Agent 内核对 Agent 原理熟悉可控性最强需要处理记忆、工具、评测等工程细节使用 Runable Grow 等商业化 GTM 产品想直接付费买效果全链路集成好需要结合公司私有化与数据安全要求4.2 环境说明如果选择自研示例本文的示例环境如下操作系统Windows / macOS / Linux 均可Python3.9 及以上大模型 API需要一个可调用的模型服务本地或云端均可依赖requests、json 等标准库即可运行教学示例如果使用 Dify 社区版可用 Docker 部署具体版本以官方仓库最新 release 为准。版本相关提醒大模型 SDK 和平台版本迭代非常快文章中的伪代码重点是表达架构思路实际运行时要按你当前的 SDK 和模型接口做替换。5. 实战从零写一个最小 GTM 智能体这个实战会聚焦一个非常具体的业务闭环输入一个客户公司 ID → 查询客户画像 → 给线索打分 → 如果分数达标则生成首封触达邮件。为了让你能直接跑通我先把大模型部分降级为规则逻辑这样不申请 API Key 也能复现再单独给出基于大模型的 Agent 循环架构。5.1 项目结构gtm-agent/ ├── main.py # 入口文件 ├── tools.py # 工具函数画像查询、打分、邮件生成 └── readme.md # 使用说明5.2 编写工具层先创建tools.py把工具能力单独拆出来。这一步非常关键因为在后面的 Agent 架构里工具就是大模型可以操作的外部接口。# 文件路径gtm-agent/tools.py import json def query_customer(company_id: str) - dict: 模拟从 CRM/企业信息库查询客户画像 fake_db { C001: { name: 某云科技, industry: 企业服务, size: 200, revenue: 5000万, source: 官网表单, }, C002: { name: 某连锁零售集团, industry: 零售, size: 1500, revenue: 8亿, source: 行业活动, }, C003: { name: 某精密制造股份, industry: 制造, size: 800, revenue: 3亿, source: 广告投放, }, } return fake_db.get(company_id, {name: 未知客户, industry: 未知, size: 0}) def score_lead(profile: dict) - int: 基于简单规则计算线索分方便解释和调试 score 0 if profile.get(industry) 企业服务: score 10 if isinstance(profile.get(size), int) and profile.get(size, 0) 500: score 5 if profile.get(source) 官网表单: score 3 if profile.get(source) 行业活动: score 2 return score def build_email(profile: dict, score: int) - str: 根据客户画像生成首封触达邮件 return ( f主题为{profile[name]}提供销售增长方案\n\n f{profile[name]} 的负责人您好\n f我们看到贵司属于{profile[industry]}行业团队规模约{profile[size]}人。\n f根据初步分析贵司的线索得分为 {score} 分我们希望在销售流程优化方面做一些交流。\n f方便约 15 分钟电话聊一下吗\n\n f此致\n销售团队 )这个工具层做了几件事query_customer模拟了外部数据查询真实项目中可以替换成 CRM API 或企业信息接口score_lead是纯规则打分好处是结果可解释方便业务人员调整build_email生成个性化邮件真实项目里这里可以接入大模型生成更复杂的内容。5.3 编写主流程再创建main.py实现一个最简单的 Agent 决策查画像 - 打分 - 按分数分支处理。# 文件路径gtm-agent/main.py from tools import query_customer, score_lead, build_email def run_simple_agent(company_id: str): # 第一步查询客户画像 profile query_customer(company_id) # 第二步线索评分 score score_lead(profile) # 第三步根据分数决策 if score 10: email build_email(profile, score) print( 智能体决策高潜线索生成首封触达邮件 ) print(email) else: print( 智能体决策线索得分不足先转入培育序列 ) print(f当前分数{score}) if __name__ __main__: run_simple_agent(C001)运行命令cd gtm-agent python main.py预期输出类似 智能体决策高潜线索生成首封触达邮件 主题为某云科技提供销售增长方案 某云科技 的负责人您好 我们看到贵司属于企业服务行业团队规模约200人。 根据初步分析贵司的线索得分为 13 分我们希望在销售流程优化方面做一些交流。 方便约 15 分钟电话聊一下吗 此致 销售团队这个版本虽然简单但它已经具备“查数据 - 评分 - 决策 - 生成内容”的闭环。实际业务中你要做的大部分 Agent 底层都是这个模式只是把其中的“打分规则”和“内容生成”换成了更复杂的模型能力。5.4 升级为真正的大模型 Agent 循环上面的版本只能处理固定分支。真正的大模型 Agent应该能把“工具选择”也交给模型。下面是一个标准的 Agent Loop 伪代码展示的是当前主流工具调用function calling流程# 伪代码基于大模型工具调用的 Agent 循环 # 需要接入真实的大模型 SDK并注册工具 schema import json SYSTEM_PROMPT 你是 GTM 销售助手。 你可以使用以下工具 - query_customer(company_id): 查询客户画像 - score_lead(profile): 给线索打分 - build_email(profile, score): 生成首封邮件 请根据用户需求自主决定调用哪个工具最后给出可执行结果。 def run_llm_agent(user_query: str, max_steps: int 5): messages [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: user_query}, ] for step in range(max_steps): # 1. 调用大模型返回回复或工具调用请求 response call_llm(messages) # 需替换成真实 SDK # 2. 如果模型直接给出最终答案结束循环 if not response.tool_calls: return response.content # 3. 将模型返回追加进上下文 messages.append({ role: assistant, content: response.content, tool_calls: response.tool_calls, }) # 4. 逐个执行工具调用 for tool_call in response.tool_calls: tool_name tool_call.function.name arguments json.loads(tool_call.function.arguments) # 在本地找到对应工具函数 result execute_tool(tool_name, arguments) # 5. 把工具结果返回给模型 messages.append({ role: tool, tool_call_id: tool_call.id, content: json.dumps(result, ensure_asciiFalse), }) return 达到最大执行步数已停止请人工介入这段代码不能直接运行因为call_llm和execute_tool是占位函数。但如果你用 OpenAI、通义、DeepSeek 等支持 function calling 的模型会发现官方示例的框架和这个结构非常接近。理解这个循环再看任何 Agent 框架都会容易很多。6. 用 Dify 低代码快速搭一个 GTM Agent如果你的团队没有太多算法背景直接使用 Dify 这类平台会更高效。Dify 社区版支持 Docker 一键部署也支持直接连接多种大模型 API。6.1 推荐的工作流节点搭建一个“客户信息问答 线索评分”的 Agent可以使用以下节点节点作用开始节点接收用户输入例如 company_idLLM 节点根据用户问题判断调用哪个工具工具节点接入 HTTP 接口或内部工具查询客户画像代码节点用 Python 代码计算线索分LLM 节点把工具结果整理成自然语言输出给用户结束节点返回最终结果可同时回写 CRM6.2 落地建议不要把“写大段 Prompt”当成全部。Dify 同样重视工具和数据的稳定输出。建议把企业信息查询、邮件发送封装成可复用的工具 API而不是让模型直接拼数据库。第一次上线时可以先用“人工审核 自动生成”的方式跑一周积累真实的输入输出样本再逐步放开自动执行。6.3 其他平台Coze扣子也比较适合快速搭建面向 C 端或业务团队的智能体它的优点是插件生态丰富、发布渠道多适合验证想法。但如果企业数据要私有化还是优先考虑 Dify 私有部署或基于开源框架自研。7. 常见问题与排查思路7.1 高频问题对照表问题现象常见原因解决思路Agent 回答与业务事实不符模型幻觉或缺少工具校验关键结果必须调用工具查询不让模型瞎猜上下文超过模型长度限制会话过长、工具返回太多做历史消息裁剪或把长文本存入外部向量库工具调用格式解析失败模型返回了不规范 JSON在 Prompt 中给出严格示例并增加异常重试逻辑邮件/消息内容太模板化画像数据不足或 Prompt 约束太强补充行业和客户动态信息降低固定句式智能体连续调用工具停不下来缺少最大步数限制设置 max_steps 上限超限转人工数据权限泄露工具没有按用户鉴权每个工具调用都必须做权限校验默认拒绝跑批任务时接口超时同步调用外部服务改为异步任务 回调通知或增加超时重试“Runable 是同步的吗”把 Agent 当成普通接口调用Agent 执行可能耗时较长建议异步化查询时返回任务状态7.2 排查建议遇到 Agent 效果不稳定不要急着改 Prompt。建议按下面顺序排查确认工具返回的数据是否正确确认工具结果是否完整进入模型上下文确认模型是否真的看到了工具结果而不是只读了历史消息确认 Prompt 中的工具描述是否与代码中的参数名一致加上完整日志记录每次模型输入、工具调用和输出方便复盘。8. 最佳实践与工程建议8.1 保持可控性GTM 智能体在较长一段时间内更适合做“辅助人”而不是“替代人”。具体做法是邮件发送、合同报价、外呼等高风险动作默认需要人工审批重要判断给出理由和参考数据来源每次 Agent 决策都留痕便于追溯。8.2 控制成本与性能工具调用时尽量返回精简字段避免把整张表塞进上下文对高频查询做缓存只在小概率场景使用大模型例如把规则打分放在前端模型只做内容润色跑批任务放到低峰期执行避免影响在线响应。8.3 数据安全与最小权限GTM 智能体必然要接触客户信息这是最需要注意的地方。建议对每个工具按角色鉴权防止销售看到非授权数据敏感字段脱敏后再进入模型上下文大模型 API 尽量走私有化或专线避免客户数据直接暴露给第三方上线前做一轮数据流向审计。8.4 建立评测集Agent 很容易出现“换一个客户表现不错、换下一个客户就乱掉”的情况。建议从上线第一天就建立评测集准备 50 到 100 条真实脱敏样本包含不同行业、不同脚本每次修改 Prompt 或模型版本后跑一遍回归。8.5 从单场景切入不做大而全如果你准备在真实业务里落地 GTM 智能体我的建议是先选一个最痛、最重复、最不容易出错的场景切入比如“销售线索自动筛选 初版邮件生成”。这个场景数据容易获取、效果可量化、风险可控跑通之后再扩展多 Agent 协作。9. 下一步怎么学GTM 智能体看起来是个新概念拆开之后其实还是 Agent 那一套基本功先跑通一个最小的 Agent Loop理解工具调用和上下文管理再尝试接入真实 CRM 或企微 API打通数据闭环然后用 Dify / Coze 这类平台做快速验证最后才是多 Agent 编排、记忆优化和复杂评测。Runable Grow 拿到融资这件事说明资本已经认可 GTM 智能体这个方向。但对普通开发团队来说更重要的是理解它背后的工程化思路数据怎么接入、决策怎么约束、结果怎么兜底。建议你直接打开编辑器先把本文的最小示例跑起来再往里面加一个真实的客户查询接口。动手一次比看十篇介绍文章都有用。如果你正在做同类的智能体项目遇到最多的问题是什么欢迎在评论区把你踩过的坑一起聊一聊。