Snyk 如何将内部支持 Agent 变成面向客户的产品功能

LangChain：Blog·2026-10-09 08:43· 16 分钟前AI 评分49

Snyk 如何将内部支持 Agent 转变为面向客户的功能

AI 导读

Snyk 将内部支持 Agent 演进为面向所有付费客户的 Snyk Assist，该 Agent 基于 LangChain 和 LangGraph 构建，并在 LangSmith 中管理可观测性。

正文

Snyk 是一个 AI 安全平台。其平台可发现并修复代码、开源依赖项、容器和云配置中的漏洞，并且它们就位于开发者已经工作的地方：IDE、拉取请求和流水线。

我们为开发者构建安全产品，这意味着我们的客户会提出棘手而具体的问题。他们想要关于漏洞、账户上下文、支持问题和产品行为的答案，而且往往是在实际工作中途。在 Snyk Assist 之前，这些信息分散在产品文档、支持文章、发布说明、学习内容和账户数据中。找到正确的那一个通常意味着要阅读好几个页面，或者提交工单然后等待。

Snyk Assist 是一个基于 LangChain 和 LangGraph 构建的对话式 Agent，并在 LangSmith 中管理可观测性。它帮助客户用自然语言找到答案，并能代表他们采取行动。它可以查询未解决的问题、检查某个包是否存在已知漏洞、在对话中创建支持案例，或者在我们尚不支持他们所需的工作流时记录功能请求。

它最初是我们自己支持团队的内部工具。2026 年 9 月，我们将其移入 Snyk 核心产品，所有付费客户都可以访问它。

在这篇文章中，我们分享我们如何构建 Snyk Assist，从最初的内部支持用例到面向客户的产品体验。我们还会介绍其背后的架构，包括我们在扩展过程中如何处理权限、状态、护栏和评估。

挑战：无法扩展的支持，以及发布 AI 的高标准

我们的支持团队每两周处理数千个案例。每个案例都必须被阅读，按产品、严重程度和负责人分类，并路由到正确的地方。随着客户咨询的增长，这带来了扩展挑战。Agent 是显而易见的解决方案，但由于我们构建的是安全软件，我们放在客户面前的任何东西都需要达到我们对产品其他部分所期望的同样标准。我们需要证明三件事：Agent 回答正确、拒绝它应该拒绝的内容，并且绝不返回用户本来无权查看的任何内容。

“构建 Agent 的难点不在于模型能做什么，而在于证明 Agent 确实有效。我们通过 LangSmith 中的评估来运行每一项变更，如果它没有达到标准，就不会发布。”

—Bailey Millns，Snyk AI 工程师

我们没有直接在产品内部发布，而是先与我们自己的团队进行内部测试。这种方法确保任何初始错误都留在 Snyk 内部，而不会影响付费客户。它还让我们能够安全地测试风险更高的功能，并在更广泛推广之前观察 Agent 的行为。

这个内部阶段使我们能够在引入面向客户的功能之前，使用 LangSmith 建立我们的运营模式。这些早期会话中的每一条追踪都直接进入我们的评估集，使我们在支持门户中发布它时，已经对 Agent 的表现有了充分了解。

阶段 1：内部工具

在大约一年的时间里，Snyk Assist 作为客户支持团队的内部工具运行，既用于案例分诊，也作为虚拟代理，Snyk 员工是唯一的用户。在内部测试该代理使我们能够发现离线测试中未出现的边缘情况，而且反馈循环以小时而非发布周期来衡量。

第二阶段： 支持门户

2026 年 4 月，我们在支持门户中向客户推出了 Snyk Assist。在那个阶段，它可以按名字问候用户、理解账户上下文、在登录时运行健康检查，并且可以在一天中的任何时间提交工单，而无需等待人工介入。

第三阶段：核心产品

2026 年 9 月 1 日，Snyk Assist 进入了 Snyk 核心产品，与我们的新导航一起，作为每个页面顶部栏中的一个面板，面向每一位付费客户。

我们在每个阶段都保持了相同的代理运行时。唯一改变的是它前面的界面。

一个运行时，多个入口

Snyk Assist 是一个单一的 LangGraph 代理，位于多个界面之后：一个 Slack 应用、一个 Web 应用和直接 API 访问，全部通过同一个安全框架路由。

我们选择 LangChain 是因为其庞大的社区、强大的生态系统，以及作为构建代理的行业标准的地位。

“LangChain 拥有迄今为止最大的社区和生态系统，并且正迅速成为构建代理的事实标准。”

——Jada Ross，Snyk AI 工程师

作为一个小团队运作，我们希望有一个单一的运行时，这样我们就可以从一个地方修复错误、发布功能和处理事件响应。这种简单性使我们能够快速扩展，而不会分散我们的架构。

此外，使用 LangChain 的中间件而不是构建自定义解决方案，为上下文、护栏和模型回退提供了明确的集成点。这种设置使我们能够通过简单的一行编辑来更新或重新排序功能，而不是进行大量的代码重写。

以下是使该系统在生产中切实可行的四个设计决策：

工具作为类型化函数，按用户注册。我们在请求时根据已登录用户实际拥有的权限附加工具。这意味着代理只能访问用户已经可以看到的数据。大多数工具是独立的微服务，这使我们能够独立扩展它们，并在不改变代理循环的情况下添加能力。
用中间件代替管道。上下文管理、护栏和模型回退接入代理生命周期中的定义点，而不是手动贯穿整个循环。添加或重新排序行为只需要对列表进行一行更改，而不是完全重写。
状态由检查点器处理。对话历史持久化在 PostgreSQL 中，并按会话键控，因此多轮记忆、跨 Pod 扩展和恢复对话都可以正常工作，无需额外接线。
将循环作为内部平台。因为代理只是一个模型、工具、提示、中间件和一个检查点器，一个共享工厂返回编译后的图，每个团队提供自己的配置。大多数新工作流是配置更改，而不是新架构。

“从开发的角度来看，LangChain 为我们提供了一个开箱即用的代理抽象，因此我们可以专注于代理的影响和能力，而不是重新发明编排、工具调用、流式传输和状态。”

——Matt Jarvis，Snyk AI 工程总监

我们如何评估每一次变更

从开发的第一天起，每一次模型调用、工具调用和决策点都在 LangSmith 中被追踪。这些追踪记录成为我们发布方式的基础。

我们使用两层评估。

离线评估在 LangSmith 中运行测试问题集。第一组是带有已知优质答案的真实问题，由第二个模型进行标记，这样我们就能快速判断提示词或模型的变更是否降低了答案质量。第二组是自动化红队演练，由人们尝试诱骗智能体忽略指令或泄露机密。

CI 作为关卡意味着每个拉取请求都会让真实智能体针对这些测试套件运行，并以提交到仓库中的约定阈值为准进行拦截。

在线评估通过定时任务对每一次生产运行进行评分。我们检查两件事：这是否与 Snyk 相关，以及回答是否解决了该问题？这些评分让我们得到的是经过测量的分流率，而非估算值。我们还会按产品领域、主题、语言生态和错误类型对每个问题进行分类，为产品经理提供客户在哪些方面遇到困难的实时地图。

闭环通过 LangSmith MCP 服务器在我们的编码智能体内部完成。当我们发现一条糟糕的追踪记录时，可以在不离开 IDE 的情况下调查它并将其转化为数据集。

由于每一步都在 LangSmith 中被追踪，我们可以用真实问题测试变更，在发布前捕获回归，并快速将糟糕的追踪记录转化为新数据集。这为我们提供了更快的反馈循环，也让带着信心发布变得容易得多。

影响：更少的工单，更快的答案

自 Snyk Assist 于 2026 年 4 月面向客户上线以来：

处理了 60,000+ 次查询
500+ 个客户账户
85%+ 的会话无需支持工单即得到解决，为支持团队节省了数百小时
250+ 个案例由智能体自动检测并直接升级至正确的团队

每一次对话都会被评分和分类，因此我们可以看出产品的哪些部分造成的困惑最多。这有助于我们改进文档。

关键要点与下一步

Snyk Assist 最初是 Snyk 自己支持团队的工具。如今，它已处理了超过 60,000 次客户查询，并在超过 85% 的会话中无需创建支持工单即得到解决。自 9 月以来，Snyk Assist 已成为产品本身的一部分，出现在每个页面上，与客户正在进行的工作相伴。我们希望它成为每位客户 Snyk 体验中有用的一部分。

链接：https://docs.snyk.io/navigate-the-snyk-web-ui#snyk-assist

‍

来源：LangChain：Blog · langchain.com