LangChain 如何构建 GTM Agent

作者：Vishnu Suresh 和 Jess Ou

在 LangChain，过去每一次外呼都始于同样的方式：销售代表在多个标签页之间来回切换。用 Salesforce 查看客户记录，用 Gong 查看通话历史，用 LinkedIn 查看联系人，用公司网站了解背景信息。在写下第一个字之前，先花十五分钟做调研，而且无法轻易得知队友昨天是否已经联系过对方。过去，入站跟进意味着要为每一个新联系人手动把同样的消息粘贴到 Apollo 里。

我们构建了一个 GTM 智能体，端到端地运行整个流程。它由新的 Salesforce 线索触发，判断我们是否应该联系对方，收集背景信息（包括会议历史），并发送一份 Slack 草稿（附带推理过程和来源）供销售代表审批。我们基于 Deep Agents 构建它，因为这是一个长时间运行、多步骤的流程，必须可靠地编排多个工具和大量数据。

关键成果

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

团队喜爱

GTM 智能体最初是一个 SDR 智能体，后来被更广泛的 GTM 团队所使用。

约束条件与成功标准

在编写任何代码之前，我们先定义了智能体实际需要做什么。

我们有两个目标：减少销售代表为每条线索花费的调研和起草时间，并提升营销带来的入站线索的转化率。外呼调研和起草足够系统化，可以自动化，但前提是系统必须安全、可审计，并且能随着使用不断改进。

不可妥协的要求

人在回路中：未经销售代表明确审核和批准，任何内容都不会发送。一封时机不当的邮件就可能毁掉数月建立起来的关系。
联系人历史知识：智能体在起草任何内容之前，必须检查销售代表或队友是否已经联系过对方。

核心能力

关系感知的个性化：草稿应反映客户的当前状态（客户、温线索还是冷线索），而不是对所有线索一视同仁。
可解释性：销售代表应能看到关键输入，并理解智能体为何选择某个切入角度，以便他们进行优化并提供反馈。
学习循环：智能体应随着时间从销售代表的修改中学习，使草稿不断改进，而无需任何人手动更新提示词。

衡量

销售代表的每一个操作（发送、编辑、取消）都会记录到 LangSmith，并附加到对应的追踪记录上，以便我们评估质量、发现回归问题并量化哪些做法有效。

范围扩展：客户情报

除了一次性草稿之外，我们还希望智能体能主动呈现客户层面的信号，例如交易风险、扩展机会和竞争动向，让销售代表知道每周该把重点放在哪里。

我们构建了什么

GTM 智能体做两件事：(1) 调研线索并撰写个性化邮件草稿；(2) 汇总跨网络活动、开发者生态、产品使用和营销触点的客户层面信号，向销售代表展示应重点关注哪里。通过将这些意向数据与销售代表负责的客户关联起来，它能呈现有意义的动态、标记交易风险和竞争动向，并明确接下来最适合联系谁。

我们将该 agent 连接到了以下数据源：

入站线索处理

当 Salesforce 中出现新线索时，agent 会立即接手。它做的第一件事就是寻找不发送任何内容的理由。如果某人刚刚提交了支持工单，或者团队中的某位同事本周早些时候已经联系过，那么发送自动邮件就是个错误。该 agent 被设定为谨慎行事。

一旦通过这些检查，它就会做销售代表过去手动做的同样的调研：拉取完整的 Salesforce 记录、通读 Gong 通话记录、查看潜在客户的 LinkedIn 个人资料。如果内部历史记录不多，它就会用 Exa 上网了解该公司目前在 AI 方面在做什么。

它如何撰写邮件草稿取决于关系的状态。该 agent 遵循一套已定义的外呼 skill，这是它在起草前加载的 playbook。该 skill 旨在同时覆盖 warm 和 cold 两种情况。现有客户收到的内容与 warm 潜在客户不同，而 warm 潜在客户收到的内容又与 cold 联系人不同。对于 cold outreach，agent 会保持简短且有调研支撑，遵循我们在该 skill 中定义的 playbook。

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

随着我们不断完善该 agent，我们为 silver 线索增加了 48 小时 SLA：如果销售代表在该时间窗口内未批准或拒绝草稿，它就会自动发送。这显著提高了那些原本可能被遗漏、得不到回复的线索的跟进率。

客户情报

随着团队规模扩大，销售代表开始各自负责 50 到 100 多个客户。在这样的规模下，事情很容易沉寂下来，扩张机会也很容易溜走。

每周一早上，agent 会从 Salesforce 和 BigQuery 拉取数据。然后它会检查外部世界中的融资轮次、产品发布和新的 AI 举措。我们为两类受众定制了报告：我们的销售团队和我们的驻场工程团队，因为他们关注不同的数据点。

对于销售，agent 会汇总产品使用、开发者生态、网络活动、招聘趋势和公司新闻等方面的信号，以发现扩张机会。它会标记高管变动、软件包安装量激增，以及某家公司是否正在积极招聘 AI 工程师或构建 agentic 系统——这是一个强烈的信号，表明他们已准备好扩张。它还会在我们发布新功能时识别潜在的良好匹配对象，将近期活动与新功能高度契合的客户匹配出来。而且，仅仅知道某个客户活跃还不够，它还会指出哪些个人参与度最高，并建议接下来联系谁。

对于驻场工程师，重点转向客户健康度。agent 会从 BigQuery 拉取产品使用情况、近期客户通话中的要点、即将到来的续约日期，以及客户即将用完额度的情况。它还会呈现近期通话中未解决的问题和未完结的讨论串。目标是标记出真正需要人介入的事项，这样团队就不必在周日晚上翻查仪表盘。

我们如何构建它

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

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

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

智能体模式

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

记忆

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

每位代表在语气和简洁性方面都有风格偏好。反馈循环是自动的。每一次编辑都在教导智能体，下一份草稿会反映出来。每周的定时任务会压缩这些记忆，以防止它们随时间膨胀。

子智能体委派

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

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

评估与反馈

在为新的工作流编写任何生产代码之前，我们会在 LangSmith 中定义成功的样子。我们从一小部分基于销售代表实际面临情况的代表性场景开始，用这些场景构建初始智能体或功能，并确保基础功能正常后再扩展。

一旦功能可用，我们就在 LangSmith 中扩大评估集，以覆盖更困难的情况：深入研究智能体 AI 或 NLP 的研究人员、我们试图重新激活的现有客户、有先前 Gong 转录记录的账户、像医疗保健这样术语密集的垂直领域。所有内容都通过一个测试框架运行，该框架模拟我们的外部 API，以便我们在接触真实数据之前在受控环境中观察行为。

我们从两个层面进行评估。首先，基于规则的断言检查基础项：工具是否正确、顺序是否正确、是否有重复草稿。其次，由 LLM 评审对语气、字数与格式进行评分。两者都作为完整评估套件的一部分在 CI 中运行，我们将 agent 行为中任何无法解释的漂移都视为值得调查的 bug。

但评估只能说明部分情况。真正重要的是销售代表日常如何使用这些草稿。我们追踪每一次 Slack 操作（发送、编辑、取消），并将其直接关联到 LangSmith 中的 trace。随着时间推移，这让我们能够将写作模式与真实结果关联起来：哪些风格能带来打开率，哪些主题行能获得回复。当某种模式在足够多的销售代表身上成立时，我们就将其固化为 agent 的默认行为。

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

销售团队之外的采用

GTM agent 最初是一个环境式 agent，作为后台进程运行。Salesforce 中出现一条线索，agent 运行，草稿落到销售代表的 Slack 中。无需触发，无需手动操作。

后来我们作为副项目构建了一个对话式 Slack 界面，主要是为了让 SDR 能够直接与 agent 交互。我们没料到的是，它竟如此迅速地扩散到公司其他部门。因为该 agent 已经连接了 Salesforce、Gong、BigQuery 和 Gmail，人们发现了我们未曾设计过的用途。工程师无需编写 SQL 就能查看产品使用情况。客户成功团队在续约电话前调取支持历史。客户主管在会议前总结 Gong 转录内容。

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

我们将在后续文章中介绍其他团队如何使用 GTM agent。

经验教训

如果有人要从零开始，我们会告诉他们几件事：

从成功定义开始，而不是代码。在为新工作流编写任何生产代码之前，我们先定义什么算好，并围绕它构建一个小型场景库。随着 agent 成熟，这个集合会扩展。到某个东西发布时，我们已经有了一个评估测试套件，可以捕捉回归、标记漂移，并在 CI 中自动运行。
人在回路不止关乎安全。它最终成了一种数据收集机制。销售代表的每一次操作（发送、编辑、取消）都成为我们可以学习的信号。记忆系统和反馈循环之所以有效，是因为销售代表身处流程之中。
从一开始就将 agent 连接到你的记录系统。公司内部的自发采用之所以发生，是因为 agent 已经能够访问人们所需的数据。我们没有计划让工程师或客户成功团队使用它，但这种使用之所以扩散，是因为访问权限已经存在。
长时间运行的工作流需要合适的基础设施。这个 agent 所需的远不止一次简单的 LLM 调用加一两个工具。它需要从多个来源拉取数据、跨来源推理、并行运行子 agent，并在多轮对话中保持状态。选择一个为此类编排而构建的 agent 框架 Deep Agents，让我们免于从零重建基础设施。
我们仍处于早期阶段。GTM agent 如今处理着一个真实的工作流，但我们构建的反馈循环——包括记忆、评估以及与 trace 关联的销售代表操作——才是让它在未来六个月中显著变得更好的关键。