Snyk 是一个 AI 安全平台。其平台能够发现并修复代码、开源依赖项、容器和云配置中的漏洞，并且它们就位于开发者已经工作的地方：IDE、拉取请求和流水线中。
我们为开发者构建安全产品，这意味着我们的客户会提出棘手而具体的问题。他们想要关于漏洞、账户上下文、支持问题和产品行为的答案，而且往往是在实际工作中提出的。在 Snyk Assist 之前，这些信息分散在产品文档、支持文章、发布说明、学习内容和账户数据中。找到正确的那一个通常意味着要阅读好几页内容，或者提交工单然后等待。
Snyk Assist 是一个对话式智能体，基于 LangChain 和 LangGraph 构建，可观测性在 LangSmith 中管理。它帮助客户用通俗语言找到答案，并可以代表他们采取行动。它可以查询未解决的问题、检查某个包是否存在已知漏洞、在对话中创建支持案例，或者在我们尚不支持他们所需的工作流时记录功能请求。
它最初是作为我们内部支持团队的工具。2026 年 9 月，我们将其移入 Snyk 核心产品，在那里每一位付费客户都可以使用它。
在这篇文章中，我们分享我们如何构建 Snyk Assist，从最初的内部支持用例到面向客户的产品体验。我们还会介绍其背后的架构，包括我们在扩展过程中如何处理权限、状态、护栏和评估。
挑战：无法扩展的支持，以及发布 AI 的高标准
我们的支持团队每两周要处理数千个案例。每一个都必须被阅读，按产品、严重程度和负责人分类，并路由到正确的地方。随着客户咨询的增长，这带来了扩展挑战。智能体是显而易见的解决方案，但由于我们构建的是安全软件，我们放在客户面前的任何东西都需要达到我们对产品其余部分所期望的同样标准。我们需要证明三件事：智能体回答正确、拒绝它应该拒绝的内容，并且绝不返回用户本来就不被允许看到的内容。
“构建智能体的难点不在于模型能做什么，而在于证明智能体确实能正常工作。我们把每一次改动都通过 LangSmith 中的评估来运行，如果达不到标准，就不发布。”
——Bailey Millns，Snyk 的 AI 工程师
我们没有直接在产品内部上线，而是先用自己的团队进行内部测试。这种做法确保任何初期错误都留在 Snyk 内部，而不会影响到付费客户。它还让我们能够安全地测试风险更高的功能，并在更广泛推广之前观察智能体的行为。
这个内部阶段让我们能够在引入面向客户的功能之前，先用 LangSmith 建立我们的运营模式。这些早期会话中的每一条 trace 都直接进入我们的评估集，让我们在支持门户上线时，已经对智能体的表现有了充分的了解。
阶段 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