Snyk 如何将内部支持智能体打造为面向客户的功能

核心要点Key Takeaways

Snyk 是一个 AI 安全平台。它能够发现并修复代码、开源依赖项、容器和云配置中的漏洞，并融入开发者日常工作的环境：IDE、拉取请求和流水线。Snyk is an AI Security Platform. Its platform finds and fixes vulnerabilities in code, open source dependencies, containers and cloud configuration, and they sit inside the places developers already work: the IDE, the pull request, and the pipeline.

我们为开发者打造安全产品，因此客户会提出一些棘手且具体的问题。他们想了解漏洞、账户背景信息、支持问题和产品行为，往往是在实际工作过程中提出的。在 Snyk Assist 推出之前，这些信息分散在产品文档、支持文章、发布说明、学习内容和账户数据中。要找到合适的信息，通常意味着得阅读好几页内容，或者提交工单后等待回复。We build security products for developers, which means our customers ask hard, specific questions. They want answers about vulnerabilities, account context, support issues and product behavior, often in the middle of real work. Before Snyk Assist, this information was spread across product documentation, support articles, release notes, learning content and account data. Finding the right one usually meant reading several pages or filing a ticket and waiting.

Snyk Assist 是一个基于 LangChain 和 LangGraph 构建的对话式智能体，其可观测性由 LangSmith 管理。它能帮助客户用通俗语言查找答案，也能代表客户采取行动。它可以查询未解决的问题、检查软件包是否存在已知漏洞、根据对话创建支持工单，或者在我们尚不支持客户所需的工作流时记录功能请求。Snyk Assist is a conversational agent built on LangChain and LangGraph with observability managed in LangSmith. It helps customers find answers in plain language and can take action on their behalf. It can look up open issues, check a package for known vulnerabilities, open a support case from the conversation, or log a feature request when we don’t yet support the requested workflow they need.

它最初是为我们自己的支持团队开发的内部工具。2026 年 9 月，我们将它整合进 Snyk 核心产品，所有付费客户都可以使用。It began as an internal tool for our own support team. In September 2026, we moved it into the core Snyk product, where every paying customer can access it.

在这篇文章中，我们将分享 Snyk Assist 的构建历程，从最初的内部支持用例，到面向客户的产品体验。我们还将介绍其背后的架构，包括在扩展过程中如何处理权限、状态、护栏和评估。In this post, we share how we built Snyk Assist, from the original internal support use case to the customer-facing product experience. We also cover the architecture behind it, including how we handled permissions, state, guardrails, and evaluation as we scaled it.

挑战：难以规模化的支持，以及推出 AI 的高门槛The challenge: support that didn’t scale, and a high bar for shipping AI

我们的支持团队每隔几周就要处理数千个案例。每个案例都必须经过阅读，并按产品、严重程度和负责人分类，然后转交到正确的地方。随着客户咨询不断增加，这给我们的扩展能力带来了挑战。部署智能体显然是解决办法，但由于我们开发的是安全软件，任何面向客户的产品都必须达到与我们其他产品相同的标准。我们需要证明三件事：智能体能够正确作答、会拒绝它应该拒绝的请求，并且绝不会返回用户原本无权查看的任何内容。Our support team handles thousands of cases every couple of weeks. Each one had to be read, classified by product, severity and owner, and routed to the right place. This presented a scaling challenge as customer inquiries grew. An agent was the obvious fix, but because we build security software, anything we put in front of customers needs to meet the same standards we expect from the rest of our product. We needed to prove three things: that the agent answered correctly, refused what it should refuse, and never returned anything the user wasn’t already allowed to see.

构建智能体的难点不在于模型能做什么，而在于证明智能体确实有效。我们会在 LangSmith 中对每项改动进行评估；如果达不到标准，就不会发布。“The hard part of building agents isn't what the model can do, it's proving the agent actually works. We run every change through evals in LangSmith, and if it doesn't clear the bar, it doesn't ship."

——贝利·米尔恩斯，Snyk AI 工程师—Bailey Millns, AI Engineer, Snyk

我们没有直接在产品中上线，而是先在内部团队中进行测试。这种做法确保了最初出现的任何错误都留在 Snyk 内部，不会影响付费客户。此外，我们还能安全地测试风险较高的功能，并在更大范围推广之前观察智能体的行为。Rather than launch directly inside the product, we started by testing internally with our own team. This approach ensured that any initial errors remained within Snyk rather than impacting paying customers. It also allowed us to safely test riskier features and observe the agent's behavior before a broader rollout.

这一内部阶段使我们能够在推出面向客户的功能之前，先借助 LangSmith 建立运营模式。这些早期会话中的每条追踪记录都直接纳入了我们的评估集，让我们在将智能体部署到支持门户时，对其表现有了充分的了解。This internal phase enabled us to establish our operating model using LangSmith before introducing customer-facing features. Every trace from these early sessions fed directly into our evaluation sets, giving us a strong understanding of how the agent would perform by the time we launched it in the support portal.

阶段 1：内部工具开发Phase 1: internal tooling

大约一年来，Snyk Assist 一直作为内部工具供客户支持团队使用，既用于工单分诊，也充当虚拟客服，且用户仅限 Snyk 员工。在内部测试该代理，帮助我们发现了离线测试中未能显现的边缘情况；反馈周期以小时计，而非以发布周期计。For roughly a year, Snyk Assist ran as an internal tool for the customer support team as both a case triage and a virtual agent, with Snyk staff as the only users. Internally testing the agent enabled us to surface edge cases that didn’t show up in offline testing and the feedback loop was measured in hours rather than release cycles.

阶段 2：支持门户Phase 2: the support portal

2026年4月，我们在支持门户中向客户推出了 Snyk Assist。当时，它可以称呼用户的名字、了解账户背景信息、在用户登录时运行健康检查，并随时提交工单，无需等待人工介入。In April 2026 we launched Snyk Assist to customers in our support portal. At that stage, it could greet users by name, understand account context, run a health check on login, and raise a ticket any time of day without waiting for a human to step in.

阶段 3：核心产品Phase 3: the core product

2026年9月1日，Snyk Assist 并入 Snyk 核心产品，与全新导航一同以面板形式显示在每个页面的顶部栏中，面向所有付费客户开放。On 1 September 2026, Snyk Assist moved into the core Snyk product, alongside our new navigation, as a panel at the top bar of every page, for every paying customer.

在每个阶段，我们都使用了相同的代理运行时。唯一变化的是它面向用户的界面。We kept the same agent runtime through each phase. The only thing that changed was the surface in front of it.

一个运行时，多种入口One runtime, many front doors

Snyk Assist 是一个单一的 LangGraph 智能体，支持多个入口：Slack 应用、Web 应用和直接 API 访问，所有请求都通过同一套安全框架进行路由。Snyk Assist is a single LangGraph agent behind several surfaces: a Slack app, a web app and direct API access, all routed through the same secured framework.

我们选择 LangChain，是因为它拥有庞大的社区、完善的生态系统，并且是构建智能体的行业标准。We chose LangChain because of its extensive community, robust ecosystem, and status as the industry standard for building agents.

LangChain 的社区和生态系统规模遥遥领先，并迅速成为构建智能体的事实标准。“LangChain had the largest community and ecosystem by far, and was quickly becoming the de facto standard for building agents. “

—Jada Ross，Snyk 人工智能工程师—Jada Ross, AI Engineer, Snyk

作为一支小团队，我们希望使用统一的运行时，以便在同一个地方修复漏洞、交付功能并处理事故响应。这种简洁性使我们能够快速扩展，同时避免架构碎片化。Operating as a small team, we wanted a single runtime so we could fix bugs, ship features, and handle incident responses from one place. This simplicity enabled us to scale quickly without fragmenting our architecture.

此外，使用 LangChain 的中间件而非自行构建解决方案，为上下文、防护机制和模型回退提供了明确的集成点。这样一来，我们只需进行简单的单行修改，就能更新或重新排列各项功能，无需大幅重写代码。Additionally, using LangChain’s middleware instead of building a custom solution provided defined integration points for context, guardrails, and model fallbacks. This setup allows us to update or reorder functionality with simple, one-line edits rather than extensive code rewrites.

以下是使该系统能够在生产环境中实际运行的四项设计决策：Here are the four design decisions that made the system practical to run in production:

1. 工具以类型化函数的形式按用户注册。我们会根据已登录用户实际拥有的权限，在请求时附加工具。这意味着代理只能访问用户本来就能看到的数据。大多数工具都是独立的微服务，因此我们可以分别扩展它们，并在不更改代理循环的情况下增加功能。
   Tools as typed functions, registered per user. We attach tools at request time based on the permissions the signed-in user actually has. That means the agent can only access data the user could already see. Most tools are separate microservices, which lets us scale them independently and add capability without changing the agent loop.
2. 采用中间件，而不是手工搭建管线。上下文管理、护栏和模型回退会接入智能体生命周期中预先定义的节点，而不是手动贯穿整个循环。添加或调整行为顺序只需修改列表中的一行，无需全面重写。
   Middleware instead of plumbing. Context management, guardrails and model fallbacks hook into defined points in the agent lifecycle instead of being threaded through the loop by hand. Adding or reordering behaviour only requires a one-line change to a list, not a full rewrite.
3. 状态由检查点机制管理。对话历史会持久化到 PostgreSQL 中，并按会话进行索引，因此无需额外配置即可实现多轮记忆、跨 Pod 扩展以及对话恢复。
   State handled by the checkpointer. Conversation history is persisted in PostgreSQL and keyed by session, so multi-turn memory, scaling across pods, and resuming a conversation all work without extra wiring.
4. 将循环视为内部平台。由于智能体只是由模型、工具、提示词、中间件和检查点器组成，共享工厂会返回编译后的图，每个团队则提供自己的配置。大多数新工作流只需修改配置，而不必采用新的架构。
   The loop as an internal platform. Because an agent is just a model, tools, a prompt, middleware and a checkpointer, a shared factory returns the compiled graph and each team supplies its own configuration. Most new workflows are a config change rather than a new architecture.

从开发角度来看，LangChain 为我们提供了开箱即用的智能体抽象，让我们能够专注于智能体的影响力和能力，而不必从头构建编排、工具调用、流式处理和状态管理。“From a development POV, LangChain gave us a batteries-included agent abstraction so we could focus on the impact and capability of our agent, instead of reinventing orchestration, tool-calling, streaming, and state.”

——Matt Jarvis，Snyk 人工智能工程总监—Matt Jarvis, Director of AI Engineering, Snyk

我们如何评估每一项更改How we evaluate every change

从开发的第一天起，我们就在 LangSmith 中追踪每一次模型调用、工具调用和决策点。这些追踪记录成为了我们交付产品的基础。Every model call, tool call and decision point has been traced in LangSmith from the first day of development. That trace became the basis for how we ship.

我们采用两层评估。We use two layers of evaluation.

离线评估会在 LangSmith 中运行一组测试问题。第一组是真实问题，并附有已知的正确答案，由第二个模型进行评分，这样我们就能快速判断提示词或模型的改动是否降低了回答质量。第二组是自动化红队演练，参与者会尝试诱骗智能体无视指令或泄露秘密。Offline evaluation runs sets of test questions in LangSmith. The first is real questions with known good answers, marked by a second model, so we can tell quickly if a prompt or model change made the answer quality worse. The second is an automated red-teaming exercise where people try to trick the agent into ignoring instructions or handing over secrets.

将 CI 作为门禁，意味着每个拉取请求都会针对这些测试套件运行真实的智能体，并依据提交到仓库中的约定阈值决定是否阻止合并。CI as a gate means every pull request runs the real agent against those suites and blocks on agreed thresholds committed to the repo.

在线评估通过定时任务对每次生产环境运行进行评分。我们会检查两点：问题是否与 Snyk 有关，以及回复是否回答了问题？这些评分让我们能够获得实际测得的自助解决率，而非估算值。我们还会按产品领域、主题、语言生态和错误类型对每个问题进行分类，为产品经理实时呈现客户遇到困难的领域。Online evaluation grades every production run with a scheduled job. We check two things: was this about Snyk and did the response answer it? Those grades give us a measured deflection rate rather than an estimate. We also categorise each question by product area, topic, language ecosystem and error type, giving product managers a live map of where customers are struggling.

通过 LangSmith MCP 服务器，我们的编码智能体可以在 IDE 内完成整个闭环。发现有问题的追踪记录后，我们可以进行调查，并将其转化为数据集，无需离开 IDE。Closing the loop happens inside our coding agents through the LangSmith MCP server. When we find a bad trace, we can investigate it and turn it into a dataset without leaving the IDE.

由于 LangSmith 会追踪每一步，我们可以针对真实问题测试变更，在发布前发现回归问题，并快速将不佳的追踪记录转化为新数据集。这样一来，我们就能更快地获得反馈，也更有信心地发布。Because every step is traced in LangSmith, we can test changes against real questions, catch regressions before they ship, and turn bad traces into new datasets quickly. That gives us a faster feedback loop and makes it much easier to ship with confidence.

影响：工单更少，答复更快The impact: fewer tickets, faster answers

自 Snyk Assist 于 2026 年 4 月正式向客户上线以来：Since Snyk Assist went live to customers in April 2026:

• 已处理超过 60,000 次查询
  60,000+ queries handled
• 500 多个客户账户
  500+ customer accounts
• 85% 以上的会话无需提交支持工单即可解决，为支持团队节省了数百小时的工作时间。
  85%+ of sessions resolved without a support ticket, saving the support team hundreds of hours
• 代理自动检测并将 250 多个案例直接升级至相应团队
  250+ cases auto-detected by the agent and escalated straight to the right team

每段对话都会经过评分和分类，这样我们就能了解产品的哪些部分最容易让人困惑，从而改进文档。Every conversation gets graded and categorized, so we can see which parts of the product create the most confusion. That helps us improve documentation.

要点总结及后续计划Key takeaways and what’s next

Snyk Assist 最初是为 Snyk 自己的支持团队打造的工具。如今，它已处理超过 60,000 个客户咨询，并且在超过 85% 的会话中无需创建支持工单即可解决问题。自 9 月起，Snyk Assist 已成为产品本身的一部分，出现在每个页面上，与客户正在进行的工作相伴。我们希望它能成为每位客户使用 Snyk 体验中实用的一部分。Snyk Assist began as a tool for Snyk’s own support team. Today, it has handled more than 60,000 customer queries and resolves over 85% of sessions without creating a support ticket.Since September, Snyk Assist has been part of the product itself, available on every page alongside the work customers are already doing. We want it to be a useful part of the Snyk experience for every customer.

Link: https://docs.snyk.io/navigate-the-snyk-web-ui#snyk-assist

‍‍