LangChain 用 Deep Agents 打造销售智能体，转化率提升 250%

在 LangChain，过去的每一条外联线索都始于同样的场景：销售代表在多个标签页间切换。查看 Salesforce 的账户记录、Gong 的通话历史、LinkedIn 的联系人信息、公司官网的背景资料。动笔写邮件前，光是研究就要花 15 分钟，而且很难知道同事昨天是否已经联系过对方。跟进内联线索则意味着手动为每个新联系人在 Apollo 里重复输入同样的信息。

我们构建了一个 GTM 智能体（GTM Agent），它能端到端地运行这个流程。当 Salesforce 出现新线索时，它会自动触发，判断是否应该联系，收集背景信息（包括会议历史），然后在 Slack 中生成一份待审核的邮件草稿（附上推理过程和来源）。我们选择在 Deep Agents 上构建它，因为这是一个需要可靠编排多个工具和大量数据的长周期、多步骤流程。

关键成果

从 2025 年 12 月到 2026 年 3 月，潜在客户到合格商机的转化率提升了 250%，同期产生的管道金额增加了 3 倍。
自 12 月以来，销售代表对低意向线索的跟进率提高了 97%，对高意向线索的跟进率提高了 18%。
每位销售代表每月节省了 40 小时，整个团队总计节省了 1320 小时。
销售团队成员每日活跃使用率为 50%，每周活跃使用率为 86%。

团队反馈

这个 GTM 智能体最初是一个销售开发代表（SDR）智能体，后来被更广泛的市场团队采用。

约束条件与成功标准

在写任何代码之前，我们先明确了智能体到底需要做什么。

我们有两个目标：减少销售代表花在每个线索上的研究和草拟时间，以及提高市场生成的内联线索的转化率。外联研究和草拟工作足够系统化，可以实现自动化，但前提是系统必须安全、可审计，并且能随着使用而改进。

不可妥协的原则

人机协同（Human-in-the-loop）： 任何内容未经销售代表明确审核和批准，都不会发送。一封不合时宜的邮件可能会毁掉数月建立的关系。
联系历史知识： 智能体需要检查销售代表或同事是否已经联系过对方，然后才能起草任何内容。

核心能力

关系感知的个性化： 草稿应反映账户的当前状态（现有客户 vs. 热线索 vs. 冷线索），而不是对所有线索一视同仁。
可解释性： 销售代表应该能看到关键输入，并理解智能体为何选择某个特定角度，以便他们能进行优化并提供反馈。
学习循环： 智能体应能从销售代表的编辑中学习，这样草稿质量会随时间提升，而无需手动更新提示词。

度量

每个销售代表的操作（发送、编辑、取消）都会记录到 LangSmith，并附加到底层的追踪记录中，这样我们就可以评估质量、发现性能回退，并量化哪些部分是有效的。

范围扩展：账户情报

除了生成一次性草稿，我们还希望智能体能主动发现账户层面的信号，比如交易风险、扩展机会和竞争对手动态，这样销售代表就知道每周该把重点放在哪里。

我们构建了什么

这个 GTM 智能体做两件事：(1) 研究线索并撰写个性化邮件草稿，(2) 聚合来自网络活动、开发者生态、产品使用情况和市场触点的账户级信号，向销售代表展示工作重点。通过将这些意向数据与销售代表的账户关联起来，它能发现有意义的动态，标记交易风险和竞争对手动向，并明确下一步应该联系谁。

我们将智能体连接到以下数据源：

内联线索处理

当 Salesforce 中出现新线索时，智能体会立即接管。它做的第一件事就是寻找“不发送”的理由。如果有人刚提交了支持工单，或者同事本周早些时候已经联系过，那么发送一封自动邮件就是个错误。智能体被设定为谨慎行事。

一旦通过了这些检查，它就会执行销售代表过去手动完成的研究：拉取完整的 Salesforce 记录、阅读 Gong 的文字记录、查看潜在客户的 LinkedIn 个人资料。如果内部历史记录不多，它会通过 Exa 访问网络，了解该公司目前在 AI 领域的动态。

撰写邮件草稿的方式取决于关系的状态。智能体遵循一个定义好的外联技能（Skill），这是在起草前加载的一个“剧本”。该技能设计用于覆盖热线索和冷线索两种情况。现有客户收到的内容与热线索不同，热线索收到的内容又与冷线索不同。对于冷外联，智能体会保持简洁并以研究为支撑，遵循我们在技能中定义的剧本。

销售代表会在 Slack 私信中看到完成的草稿，并附有发送、编辑或取消的按钮。他们还能看到智能体的推理过程，从而清楚它为何采取某个特定角度。如果他们发送了邮件，智能体会排队准备一组后续邮件，供选择性地让潜在客户加入。

随着我们优化智能体，我们为银级线索增加了 48 小时的服务水平协议（SLA）：如果销售代表在该时间窗口内没有批准或拒绝草稿，它会自动发送。这显著提高了我们对那些原本可能因无人回复而遗漏的线索的跟进率。

账户情报

随着团队规模扩大，每位销售代表开始负责 50 到超过 100 个账户。在这种体量下，很容易出现动态沉寂或错失扩展机会的情况。

每周一早上，智能体会从 Salesforce 和 BigQuery 拉取数据。然后，它会检查外部世界，寻找融资轮次、产品发布和新的 AI 计划。我们为两个受众定制了报告：我们的销售团队和我们已部署的工程团队，因为他们关心的数据点不同。

对于销售团队，智能体聚合来自产品使用、开发者生态、网络活动、招聘趋势和公司新闻的信号，以发现扩展机会。它会标记高管变动、软件包安装量的激增，以及公司是否正在积极招聘 AI 工程师或构建智能体系统——这是他们准备扩展的强烈信号。当我们发布新功能时，它还会识别出潜在的良好匹配账户，即近期活动与新功能高度契合的账户。并且，仅仅知道账户活跃是不够的，它还会发现哪些个人参与度最高，并建议下一步联系谁。

对于已部署的工程师，重点转向账户健康状况。智能体从 BigQuery 拉取产品使用数据，突出显示近期客户通话的要点、即将到来的续约日期，以及客户即将用完积分的情况。它还会发现近期通话中悬而未决的问题和未解决的线索。目标是标记出真正需要人工介入的情况，这样团队就不必在周日晚上埋头研究仪表板了。

我们如何构建它

智能体需要从多个来源拉取数据，进行跨源推理，并生成个性化输出。这超出了简单 LLM 调用能可靠处理的范围。

我们选择 Deep Agents 进行多步骤编排，因为输入本质上是不均衡的：会议数据、CRM 历史和网络研究在大小和结构上差异很大。使用 Deep Agents，大型工具结果会自动卸载到虚拟文件系统中，因此我们无需构建自己的截断和检索层。我们还利用该执行框架（Harness）的原生规划工具来强制执行一致的检查清单（不发送检查 → 研究 → 草拟 → 推理 → 后续跟进），这使得运行过程更易于调试，并减少了智能体的“漫游”。

我们将智能体连接到 LangSmith，以便了解销售代表实际如何使用它，并衡量智能体是否随时间改进。这意味着从一开始就设置评估，而不是事后补救，事实证明，当我们在提示词或模型版本上进行迭代时，这对于发现性能回退至关重要。

智能体模式

将我们的 GTM 智能体投入生产，暴露了两个必须解决的问题：如何让智能体向使用它的人学习，以及如何在大规模运行时保持效率。

记忆

当销售代表在 Slack 中编辑草稿时，系统会比较原始版本和修订版本。如果更改具有实质性内容，一个 LLM 会分析差异并提取结构化的风格观察：什么改变了，这暗示了销售代表的哪些偏好，以及一个可选的引用示例。这些观察结果存储在 PostgreSQL 中，按销售代表进行键控，每次未来的运行在起草前都会读取它们。

每位销售代表在语气和简洁度方面都有风格偏好。反馈循环是自动的。每次编辑都在教导智能体，下一次的草稿就会反映这一点。一个每周运行的定时任务会压缩这些记忆，防止它们随时间变得臃肿。

子智能体委托

账户情报通过编译的子智能体（Subagent）运行：这些是轻量级智能体，具有受限的工具集和结构化的输出模式，它们充当与主智能体的契约。销售研究子智能体可以访问 Apollo、Exa 和 BigQuery，并返回结构化的潜在客户和市场背景。已部署工程师子智能体使用 Salesforce、Gong 和支持工具，返回使用趋势、未解决的工单和扩展信号。

父智能体为每个账户生成一个子智能体，保持工具隔离和输出可预测。由于子智能体独立运行，我们可以并行执行它们。LangSmith Deployment 处理水平扩展和持久化执行，因此随着体量增长，系统仍能保持可靠。

评估与反馈

在为新工作流编写任何生产代码之前，我们会在 LangSmith 中定义成功标准。我们从一小批代表实际销售代表面临场景的案例库开始，用它们构建初始智能体或功能，确保基础工作正常后再扩展。

功能就绪后，我们在 LangSmith 中扩展评估集，覆盖更复杂的场景：比如深入研究智能体 AI 或 NLP 的研究人员、试图重新激活的现有客户、有 Gong 转录记录的账户、医疗等专业术语密集的垂直行业。所有测试都通过一个模拟外部 API 的执行框架（Harness）运行，这样我们就能在接触真实数据前，在受控环境中观察行为。

评估分两个层面。首先，基于规则的断言检查基础项：工具使用正确、顺序合理、没有重复草稿。其次，一个 LLM 法官对语气、字数、格式进行评分。两者都作为完整评估套件的一部分在 CI 中运行，任何智能体行为的未解释偏差都会被当作需要调查的 bug。

但评估只反映部分情况。真正重要的是销售代表日常如何使用草稿。我们追踪每个 Slack 操作（发送、编辑、取消），并直接关联到 LangSmith 中的轨迹。久而久之，这让我们能将写作模式与实际结果关联起来：哪种风格能提高打开率，哪些主题行能获得回复。当某种模式在足够多代表中持续出现时，我们就将其固化到智能体的默认行为中。

LangSmith 评估套件和销售代表反馈循环相互强化：一个捕捉回归问题，另一个驱动改进。

超越销售团队的采用

GTM 智能体最初是作为环境智能体（Ambient Agent）运行的，作为一个后台进程。线索出现在 Salesforce 中，智能体运行，草稿就会出现在销售代表的 Slack 里。无需触发，无需手动操作。

后来我们作为附带实验构建了一个对话式 Slack 界面，主要是为了让 SDR 能直接与智能体交互。没想到的是，它迅速在公司其他部门传播开来。因为智能体已经连接了 Salesforce、Gong、BigQuery 和 Gmail，人们找到了我们未曾设计的用途：工程师无需编写 SQL 就能查看产品使用情况；客户成功团队在续约通话前拉取支持历史；客户经理在会议前总结 Gong 转录内容。

这些工作流都不是我们有意构建的。智能体拥有访问权限，人们找到了阻力最小的路径：和机器人对话比打开六个不同标签页更容易。

其他团队如何使用 GTM 智能体，我们会在后续文章中详细介绍。

经验总结

如果有人从零开始，我们会分享几点心得：

从定义成功开始，而不是代码。 在为新工作流编写任何生产代码前，我们先定义“好”是什么样子，并围绕它构建一个小型场景库。随着智能体成熟，这个集合会扩展。到功能上线时，我们已经有了一个能捕捉回归、标记偏差、在 CI 中自动运行的评估测试套件。
人机协同（Human-in-the-Loop）不止关乎安全。 它实际上成了一个数据收集机制。每个销售代表的操作（发送、编辑、取消）都成了我们可以学习的信号。记忆系统和反馈循环之所以有效，是因为销售代表就在流程中。
从一开始就将智能体连接到你的记录系统。 智能体能在公司内自然传播，正是因为它已经具备了人们所需数据的访问权限。我们没计划让工程师或客户成功团队使用它，但使用范围之所以扩大，就是因为访问权限已经存在。
长周期工作流需要合适的基础设施。 这个智能体需要的远不止一个简单的 LLM 调用加一两个工具。它需要从多个来源拉取数据、跨数据推理、并行运行子智能体、并在多轮对话中保持状态。选择专为此类编排设计的智能体执行框架（Harness）——Deep Agents，让我们免于从头重建基础设施。
我们仍处于早期阶段。 GTM 智能体现在能处理真实工作流，但我们构建的反馈循环——包括记忆、评估、以及与轨迹关联的销售代表操作——才是未来六个月让它显著提升的关键。