核心要点
- 我们从一个真实的客户痛点出发。 Snyk Assist 的构建目的是让客户更轻松地获得快速、准确的答案，而无需在文档、支持内容和账户系统之间进行搜索。
- 我们将信任和访问控制视为核心产品要求。 由于 Snyk 是一个安全平台，该智能体的设计确保其在用户的权限范围内运行，并在更广泛推出之前证明其安全、可靠和正确。
- 我们将其打造为有用、可衡量且可扩展的产品。 一个 LangGraph 运行时为多个界面提供支持，同时 LangSmith 评估帮助团队发现回归问题、改进响应，并充满信心地持续发布。
Snyk 是一个 AI 安全平台。其平台可发现并修复代码、开源依赖项、容器和云配置中的漏洞，并且它嵌入在开发人员已经工作的地方：IDE、拉取请求和流水线中。
我们为开发人员构建安全产品，这意味着我们的客户会提出困难而具体的问题。他们想要关于漏洞、账户上下文、支持问题和产品行为的答案，而且往往是在实际工作中提出。在 Snyk Assist 出现之前，这些信息分散在产品文档、支持文章、发布说明、学习内容和账户数据中。找到正确信息通常意味着要阅读多个页面，或者提交工单并等待。
Snyk Assist 是一个基于 LangChain 和 LangGraph 构建的对话式智能体，其可观测性由 LangSmith 管理。它帮助客户用自然语言找到答案，并可以代表他们采取行动。它可以查找未解决的问题、检查某个软件包是否存在已知漏洞、从对话中开立支持工单，或者在我们尚不支持客户所需的工作流程时记录功能请求。
它最初是我们自己支持团队的内部工具。2026 年 9 月，我们将其迁移到 Snyk 核心产品中，每位付费客户都可以访问它。
在本文中，我们将分享我们如何构建 Snyk Assist，从最初的内部支持用例到面向客户的产品体验。我们还会介绍其背后的架构，包括我们在扩展过程中如何处理权限、状态、防护栏和评估。
挑战：无法扩展的支持体系，以及对发布 AI 的高标准
我们的支持团队每几周要处理数千个工单。每个工单都必须经过阅读、按产品、严重程度和负责人分类，并路由到正确的位置。随着客户咨询的增长，这带来了扩展方面的挑战。智能体是显而易见的解决方案，但因为我们构建的是安全软件，任何呈现给客户的东西都必须达到我们对产品其他部分所期望的同样标准。我们需要证明三件事：智能体能够正确回答、拒绝应该拒绝的内容，并且绝不会返回用户本无权查看的任何信息。
“构建智能体的难点不在于模型能做什么，而在于证明智能体确实有效。我们通过 LangSmith 中的评估来检验每一次变更，如果达不到标准，就不会发布。”
——Bailey Millns，Snyk AI 工程师
我们没有直接在产品中发布，而是先在自己团队内部进行测试。这种方式确保任何初始错误都留在 Snyk 内部，而不会影响付费客户。这也使我们能够在更广泛推出之前安全地测试风险较高的功能并观察智能体的行为。
这一内部阶段使我们能够在引入面向客户的功能之前，利用 LangSmith 建立起我们的运营模型。这些早期会话的每一条追踪记录都直接输入到我们的评估集中，使我们能在支持门户中发布该智能体时，对其表现有充分的了解。
第 1 阶段：内部工具
大约一年时间里，Snyk Assist 作为客户支持团队的内部工具运行，既充当工单分类工具，也充当虚拟智能体，Snyk 员工是唯一的用户。在内部测试该智能体使我们能够发现离线测试中未出现的边缘情况，而且反馈周期是以小时而非发布周期来衡量的。
第 2 阶段： 支持门户
2026 年 4 月，我们在支持门户中向客户发布了 Snyk Assist。在那个阶段，它可以按姓名问候用户、理解账户上下文、在登录时运行健康检查，并且可以在一天中的任何时间开立工单，而无需等待人工介入。
第 3 阶段：核心产品
2026 年 9 月 1 日，Snyk Assist 迁入 Snyk 核心产品，与我们全新的导航并列，作为每个页面顶部栏中的面板，面向所有付费客户开放。
我们在每个阶段都保留了相同的智能体运行时。唯一变化的是它面前的界面。
一个运行时，多个入口
Snyk Assist 是位于多个界面背后的单一 LangGraph 智能体：一个 Slack 应用、一个 Web 应用以及直接的 API 访问，全部通过同一个经过安全加固的框架进行路由。
我们选择 LangChain 是因为它拥有庞大的社区、健全的生态系统，以及作为构建智能体的行业标准地位。
“LangChain 拥有迄今为止最大的社区和生态系统，并且正在迅速成为构建智能体的事实标准。”
—Jada Ross，Snyk AI 工程师
作为一个小团队运营，我们希望使用单一的运行时环境，这样就可以从一个地方修复 bug、发布功能并处理事故响应。这种简洁性使我们能够快速扩展，而不会使架构碎片化。
此外，使用 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