LangChain 的 GTM Agent 正在颠覆传统销售模式，这款市场推广AI助手将潜在客户转化率提升250%，同时为团队节省1320小时。通过深度集成Salesforce、Gong等核心系统，它能自动完成客户研究、邮件草拟等重复工作，而销售代表只需专注决策环节。本文详解这款AI agent如何重构人机协作边界，以及它对AI在企业应用中价值的启示。

你有没有想过，销售这件事可能会被彻底重新定义？

不是那种换个 CRM 系统或者学几个销售话术的小改进，而是从根本上改变销售人员的日常工作方式。

想象一下，销售代表不再需要在 Salesforce、Gong、LinkedIn、公司网站之间疯狂切换标签页，不再需要花 15 分钟做背景调查才能写出第一个字，也不用担心同事昨天刚联系过的客户今天又被重复骚扰。

这不是未来的幻想，而是 LangChain 团队已经实现的现实。

他们构建了一个 GTM Agent（Go-to-Market Agent，市场推广 AI agent），从 2025 年 12 月到 2026 年 3 月，仅仅三个月时间，就把潜在客户到合格商机的转化率提升了 250%，pipeline 规模增长了 3 倍，同时为整个销售团队节省了 1320 个小时。

当我读到 LangChain 分享的这个案例时，我意识到这不只是一个销售自动化工具的成功故事。这代表了一种全新的工作范式：AI agent 不再是简单地回答问题或生成内容，而是真正能够端到端地执行复杂业务流程，并且在执行过程中不断学习和优化。

更重要的是，LangChain 作为一家 AI 基础设施公司，他们自己就是这项技术的第一个用户，这让他们的经验格外具有说服力。我想深入剖析他们是如何做到的，以及这对我们理解 AI agent 在企业应用中的真实价值有什么启发。

销售流程的真实痛点

LangChain 在文章开头就直接描述了他们销售团队之前的工作状态：每一次外呼都是从同样的方式开始的，销售代表在多个标签页之间切换。打开 Salesforce 查看客户记录，切到 Gong 听通话历史，再跳到 LinkedIn 看联系人信息，然后去公司网站了解背景。光是做这些背景研究就要花掉 15 分钟，而且完全无法确定团队里的其他人是不是昨天刚联系过这个客户。对于入站线索的跟进，则意味着要手动在 Apollo 里给每个新联系人发送同样的消息。

这个场景我太熟悉了。我之前和很多销售团队合作过，发现这种低效不是个例，而是行业普遍现象。问题的核心在于，销售是一个高度依赖上下文信息的工作。你必须了解客户是谁、他们的公司在做什么、之前有过什么互动、现在处于什么阶段，才能写出一封真正有针对性的邮件。但这些信息散落在至少五六个不同的系统里，没有任何一个系统能给你完整的画面。

更糟糕的是，销售团队规模扩大后，协调成本会呈指数级增长。你不仅要担心自己有没有遗漏什么信息，还要担心同事有没有已经联系过这个人。我见过太多次这样的尴尬场景：同一家公司的两个销售代表在同一周内给同一个潜在客户发了几乎一模一样的邮件，结果客户直接拉黑了这家公司。这种失误不仅浪费了销售机会，还会严重损害品牌形象。

所以当 LangChain 决定构建一个能够端到端处理这个流程的 AI agent 时，他们瞄准的是一个真实存在、影响巨大的痛点。这不是为了 AI 而 AI 的技术炫技，而是为了解决销售团队每天都在面对的实际问题。

GTM Agent 到底做了什么

LangChain 构建的 GTM Agent 主要做两件事情。

第一，它能够研究潜在客户并撰写个性化的邮件草稿。

第二，它会聚合账户层面的各种信号，包括网站活动、开发者生态系统数据、产品使用情况和营销接触点，帮助销售代表清楚地知道应该把精力集中在哪里。通过将这些意图数据与销售代表负责的账户关联起来，它能够浮现出有意义的活动，标记出交易风险和竞争对手的动向，并明确下一步应该联系谁。

我觉得这个设计非常巧妙的一点是，它不是试图完全取代销售人员，而是把销售人员从重复性的研究和起草工作中解放出来，让他们能够专注于真正需要人类判断和创造力的部分。

整个流程是这样的：当一个新的潜在客户出现在 Salesforce 系统里时，AI agent 会立即接管。它做的第一件事不是马上写邮件，而是寻找”不应该发送任何内容”的理由。如果这个人刚刚提交了一个技术支持工单，或者团队成员在本周早些时候已经联系过，那么发送自动化邮件就是一个错误。这个 agent 被设计成非常谨慎的。

一旦通过了这些检查，它会做销售代表过去手动做的所有研究工作：拉取完整的 Salesforce 记录，阅读 Gong 的通话记录，查看潜在客户的 LinkedIn 个人资料。如果内部历史记录不多，它会使用 Exa 这个工具去网上搜索，了解这家公司目前在 AI 方面正在做什么。

如何撰写邮件草稿取决于关系的状态。这个 agent 遵循一个定义好的 outbound skill（外呼技能），这是一个它在起草之前会加载的行动手册。这个技能被设计成能够覆盖温暖和冷淡两种情况。现有客户会收到与温暖潜在客户不同的内容，而温暖潜在客户又会收到与冷接触不同的内容。对于冷外呼，agent 会保持简洁并以研究为基础，遵循他们在技能中定义的行动手册。

销售代表会在 Slack 私信中看到完成的草稿，带有发送、编辑或取消的按钮。他们还可以看到 agent 的推理过程，这样就能清楚地知道它为什么采取了特定的角度。如果他们发送了邮件，agent 会排好一组后续跟进邮件，让销售代表可以选择是否将这个潜在客户加入后续培育流程。

我认为这里有一个非常关键的设计决策：human-in-the-loop（人在回路中）。LangChain 明确表示，没有经过销售代表的明确审查和批准，任何内容都不会被发送出去。一封时机不当的邮件可能会毁掉数月的关系建设。这不仅是一个安全措施，也是一个数据收集机制。每次销售代表的操作（发送、编辑、取消）都成为系统可以学习的信号。

账户智能：从被动响应到主动洞察

随着团队规模的扩大，销售代表开始负责 50 到 100 多个账户。在这种规模下，很容易让一些账户变得沉默，或者让扩展机会悄悄溜走。LangChain 的解决方案是让 GTM Agent 每周一早上自动从 Salesforce 和 BigQuery 拉取数据，然后检查外部世界的融资轮次、产品发布和新的 AI 计划。

他们为两个受众定制了报告：销售团队和部署工程团队，因为他们关心不同的数据点。对于销售团队，agent 会聚合产品使用、开发者生态系统、网站活动、招聘趋势和公司新闻等信号，以浮现扩展机会。它会标记高管变动、软件包安装量的激增，以及公司是否正在积极招聘 AI 工程师或构建 agentic 系统——这是他们准备扩展的强烈信号。当他们推出新功能时，它还会识别潜在的良好匹配对象，将最近活动与新功能良好契合的账户匹配起来。而且因为仅仅知道一个账户是活跃的还不够，它会浮现哪些个人最活跃，并建议下一步应该联系谁。

对于部署工程师，重点转向账户健康状况。agent 从 BigQuery 拉取产品使用数据，提取最近客户电话的要点，即将到来的续约日期，以及客户接近用完额度的情况。它还会浮现最近通话中的开放问题和未解决的线索。目标是标记真正需要人工介入的内容，这样团队就不用在周日晚上翻看仪表板了。

我觉得这个账户智能功能特别有价值的地方在于，它不只是被动地回答销售代表的问题，而是主动地发现和浮现重要的信号。传统的商业智能工具通常需要你知道要问什么问题，然后去查询数据。但现实中，销售代表往往不知道应该关注什么，或者他们根本没有时间去主动挖掘数据。AI agent 通过持续监控多个数据源并识别有意义的模式，实际上是在充当一个永不疲倦的分析师，帮助销售团队发现那些可能会错过的机会。

更重要的是，这种主动洞察是基于多源数据的综合分析。一个公司在招聘 AI 工程师可能意味着他们在扩大 AI 团队。如果同时他们的软件包下载量在激增，高管层有了新的 CTO，那么这三个信号结合起来就构成了一个非常强烈的扩展机会指示。单独看每个信号可能不够有说服力，但当 AI agent 能够跨多个数据源进行综合分析时，它就能发现这些隐藏的模式。

技术架构：为什么选择 Deep Agents

LangChain 在构建这个系统时面临的核心挑战是：这个 agent 需要从多个来源拉取数据，跨这些数据进行推理，并产生个性化的输出。这远远超出了简单的 LLM 调用能够可靠处理的范围。

他们选择了 Deep Agents 来处理多步骤编排，原因是输入本质上是尖峰化的：会议数据、CRM 历史记录和网络研究在大小和结构上变化很大。使用 Deep Agents，大型工具结果会自动卸载到虚拟文件系统中，所以他们不必构建自己的截断和检索层。他们还使用了 harness 的原生规划工具来强制执行一致的检查清单（不发送检查 → 研究 → 草稿 → 理由 → 后续跟进），这使得运行更容易调试并减少了 agent 的漫游。

我认为这个技术选择非常关键。很多人在构建 AI agent 时低估了处理可变输入和多步骤编排的复杂性。当你只是做一个简单的问答系统时，输入和输出都相对可预测。但当你要处理真实的业务流程时，数据的复杂性会爆炸式增长。有些客户可能有十几次 Gong 通话记录，每次通话可能持续一小时；有些客户可能完全是新的，只有一个 LinkedIn 个人资料和一个公司网站。如果你没有一个能够优雅处理这种可变性的架构，系统很快就会变得不可靠。

Deep Agents 提供的虚拟文件系统功能解决了一个很实际的问题：当工具返回的数据太大而无法直接放入 LLM 的上下文窗口时，应该怎么办？传统方法是截断数据或者构建复杂的检索系统。但 Deep Agents 通过自动将大型结果卸载到虚拟文件系统，让 agent 可以在需要时再去访问相关部分，既保持了效率又不会丢失信息。

另一个重要的技术选择是将 agent 连接到 LangSmith，这样他们可以理解销售代表实际上是如何使用它的，并衡量 agent 是否随着时间的推移而改进。这意味着从一开始就设置评估，而不是后来再改装，这对于在迭代提示或切换模型版本时捕获回归至关重要。

Memory 系统：让 AI Agent 从每次编辑中学习

LangChain 在文章中描述的 Memory（记忆）系统是我觉得整个设计中最巧妙的部分之一。当销售代表在 Slack 中编辑草稿时，系统会将原始版本与修订版本进行比较。如果更改是实质性的，一个 LLM 会分析差异并提取结构化的风格观察：发生了什么变化，这对销售代表的偏好意味着什么，以及一个可选的引用示例。这些观察被存储在 PostgreSQL 中，按销售代表分组，每次未来运行都会在起草之前读取它们。

每个销售代表在语气和简洁性方面都有风格偏好。反馈循环是自动的。每次编辑都会教会 agent，下一次草稿就会反映出来。一个每周的定时任务会压缩这些记忆，防止它们随着时间的推移变得臃肿。

我认为这个设计天才的地方在于，它把人在回路中的需求转化成了一个持续学习的机制。很多人把 human-in-the-loop 仅仅看作是一个安全措施——确保 AI 不会犯错误。但 LangChain 意识到，每次人类编辑实际上都是一个训练信号。销售代表删掉了一句话？那可能意味着草稿太啰嗦了。他们改变了开头的语气？那可能意味着对于这种类型的客户，应该用更正式或更随意的方式。

更重要的是，这个记忆系统是个性化的。不同的销售代表有不同的风格，面对不同的市场和客户群。一个专注于企业客户的销售代表可能需要更正式的语言，而一个专注于初创公司的销售代表可能更喜欢简洁直接的风格。通过为每个销售代表维护独立的记忆，系统能够适应这些个人差异，而不是强迫每个人使用同一种模板。

这种学习循环的强大之处在于它的隐性和持续性。销售代表不需要填写反馈表单或者给 AI 打分，他们只需要像平常一样编辑草稿。系统会自动从这些日常操作中学习和改进。随着时间的推移，草稿会越来越符合每个销售代表的风格，需要的编辑会越来越少。这就是我理解的真正的 AI 助手：不是一个需要你适应它的工具,而是一个能够适应你的伙伴。

Subagent Delegation：如何处理复杂的并行任务

在处理账户智能功能时，LangChain 采用了一个叫做 subagent delegation（子 agent 委托）的模式。账户智能通过编译的 subagents 运行：这些是具有受限工具集和结构化输出模式的轻量级 agents，它们作为与主 agent 的契约。销售研究 subagent 可以访问 Apollo、Exa 和 BigQuery，并返回结构化的潜在客户和市场上下文。部署工程师 subagent 使用 Salesforce、Gong 和支持工具来返回使用趋势、开放工单和扩展信号。

父 agent 为每个账户生成一个 subagent，保持工具隔离和输出可预测。因为 subagents 独立运行，他们可以并行执行它们。LangSmith Deployment 处理水平扩展和持久执行，所以系统随着量的增长保持可靠。

我觉得这个架构设计解决了一个很现实的问题：当你需要处理几十个甚至上百个账户时，如果串行处理，整个流程可能需要几个小时才能完成。但如果你能够并行处理，就可以在可接受的时间内完成所有分析。

更深层的洞察是关于责任边界的清晰划分。每个 subagent 都有明确定义的工具集和输出格式。销售研究 subagent 不会去看支持工单，部署工程师 subagent 不会去做市场研究。这种清晰的边界不仅使系统更容易理解和调试，也减少了 agent 出错或产生不相关输出的可能性。

我在构建复杂系统时经常看到的一个问题是，当一个组件试图做太多事情时，它往往什么都做不好。通过将复杂任务分解成多个专门的 subagents，每个都专注于特定的数据源和输出格式，LangChain 创建了一个更模块化、更可维护的系统。如果他们需要改进销售研究的质量，他们可以只修改那个 subagent，而不用担心影响部署工程师的功能。

Evals 和反馈：如何确保质量不会退化

LangChain 强调，在为新工作流编写任何生产代码之前，他们会在 LangSmith 中定义成功的样子。他们从一个小型的代表性场景库开始，这些场景都基于销售代表实际面对的情况，使用这些来构建初始 agent 或功能，并确保基础功能在扩展之前是有效的。

一旦功能正常运行，他们会在 LangSmith 中扩大评估集，以涵盖更难的情况：深入研究 agentic AI 或 NLP 的研究人员，他们试图重新吸引的现有客户，有先前 Gong 记录的账户，像医疗保健这样有大量行话的垂直行业。一切都通过一个测试工具运行，该工具模拟他们的外部 API，这样他们可以在接触真实数据之前在受控环境中观察行为。

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

但我认为 LangChain 在这里真正聪明的地方是，他们意识到评估只能讲述部分故事。真正重要的是销售代表日常如何使用草稿。他们跟踪每个 Slack 操作（发送、编辑、取消）并将其直接附加到 LangSmith 中的 trace。随着时间的推移，这让他们能够将写作模式与真实结果相关联：哪些风格带来了打开率，哪些主题行得到了回复。当某些模式在足够多的销售代表中成立时，他们就会将其编码到 agent 的默认行为中。

我觉得这种双轨制的评估体系非常值得学习。自动化评估能够快速发现明显的错误和回归，但它无法告诉你 AI 生成的内容在真实世界中是否有效。只有通过跟踪真实用户的行为和结果，你才能知道什么真正起作用。

这也解决了 AI 系统的一个核心挑战：如何持续改进。很多 AI 系统在部署后就停止进化了，因为没有有效的反馈机制。但 LangChain 通过将用户操作与 traces 关联起来，创建了一个持续的学习循环。每次销售代表发送、编辑或取消一个草稿，系统都会学到一些东西。这些学习可以用来调整提示、改进模型，或者更新默认行为。

意外的跨团队采用

LangChain 在文章最后分享了一个有趣的发现：GTM Agent 最初是作为一个 ambient agent（环境 agent）开始的，作为后台进程运行。潜在客户出现在 Salesforce 中，agent 运行，草稿发送到销售代表的 Slack。没有触发器，没有手动工作。

后来他们构建了一个对话式 Slack 界面作为副项目，主要是为了给 SDR 一种直接与 agent 交互的方式。他们没有预料到的是它传播到公司其他部门的速度有多快。因为 agent 已经连接到 Salesforce、Gong、BigQuery 和 Gmail，人们发现了他们没有设计的用途。工程师在不编写 SQL 的情况下检查产品使用情况。客户成功团队在续约电话之前拉取支持历史。客户经理在会议前总结 Gong 记录。

他们没有有意构建任何这些工作流。agent 有访问权限，人们找到了阻力最小的路径。与机器人交谈比打开六个不同的标签页更容易。

我认为这个意外的跨团队采用揭示了一个深刻的洞察：当你构建一个真正有用的 AI agent 并给它访问核心数据系统的权限时，它的价值会自然地扩散到你最初设想之外的用例。这不是因为你做了什么特别的营销或推广，而是因为人们会自然地寻找更高效的工作方式。

这也说明了为什么将 AI agent 与现有的系统记录（systems of record）集成如此重要。如果 LangChain 构建的是一个独立的工具，需要手动输入数据或者只能访问有限的信息源，它可能永远不会获得这种有机的跨团队采用。但因为它已经连接到 Salesforce、Gong、BigQuery 等核心系统，它自然而然地成为了一个任何需要访问这些数据的人都可以使用的界面。

我也注意到一个有趣的演进：从环境 agent 到对话式界面。环境 agent 非常适合标准化、可预测的工作流，但当人们需要更灵活、更探索性的使用方式时，对话式界面就变得非常有价值。能够直接问”这个客户的产品使用趋势如何”或者”最近一次与这个客户的通话提到了什么问题”，比导航一个复杂的 UI 或者编写 SQL 查询要直观得多。

我的思考：AI Agent 的真正价值在哪里

读完 LangChain 的这个案例，我最大的感受是：AI agent 的真正价值不在于完全自动化某个任务，而在于重新定义人机协作的边界。

很多人在谈论 AI agent 时，关注的是它能否完全取代人类完成某项工作。但我认为这个视角太狭隘了。LangChain 的 GTM Agent 之所以成功，恰恰是因为它没有试图取代销售代表，而是识别出销售流程中哪些部分是重复性的、可自动化的，哪些部分需要人类的判断和创造力。研究客户背景、拉取历史记录、起草初版邮件——这些都是费时但相对机械的工作，AI 可以做得很好。但决定是否发送、如何调整语气、什么时候跟进——这些仍然需要人类的专业判断。

我也看到了一个重要的模式：最成功的 AI agent 往往是那些能够融入现有工作流程的。LangChain 没有要求销售代表学习一个新的界面或者改变他们的工作习惯。草稿出现在 Slack 中，他们已经每天都在用的工具。数据来自 Salesforce 和 Gong，他们已经在使用的系统。这种无缝集成大大降低了采用的摩擦力。

另一个深刻的洞察是关于学习循环的重要性。一个静态的 AI 系统，无论最初设计得多么好，都会随着时间的推移变得过时。但如果你能构建一个从每次交互中学习的系统，它就会持续改进。LangChain 的 Memory 系统和反馈追踪机制创建了这样一个学习循环，使得系统能够适应不同销售代表的风格偏好，并从真实的结果数据中学习什么真正有效。

我还特别欣赏 LangChain 对可解释性的重视。AI agent 不只是给出一个结果，它还解释为什么选择了某个角度，使用了哪些数据源。这种透明度不仅建立了信任，也让销售代表能够更好地理解和改进系统的输出。在企业环境中，这种可解释性往往比纯粹的性能更重要。

最后，我认为 LangChain 这个案例证明了一点：构建 AI 基础设施的公司应该成为自己产品的第一个用户。他们在构建 GTM Agent 的过程中积累的经验和遇到的挑战，直接帮助他们改进了 LangChain 和 LangSmith 这些产品。这种”吃自己的狗粮”（dogfooding）不仅能发现产品的真实问题，也能让他们更深刻地理解客户的需求。

从更宏观的角度看，我相信 LangChain 的 GTM Agent 代表了企业 AI 应用的一个重要方向：不是构建独立的 AI 工具，而是将 AI 能力深度集成到现有的业务流程中，创建一个人机协作的智能系统。这种系统能够处理大量的重复性工作，同时保持人类在关键决策点的控制权，并且能够从每次交互中持续学习和改进。这才是 AI agent 在企业环境中应该有的样子。