Agent / 工程
Snyk 如何将内部支持 Agent 打造成面向客户的产品功能
Snyk 是一家面向开发者的 AI 安全平台，其客户每天需要在文档、支持文章、账户数据等多个来源中寻找漏洞修复和产品使用的答案。为解决这一痛点，Snyk 基于 LangChain 和 LangGraph 构建了对话式 Agent——Snyk Assist，并以 LangSmith 管理可观测性。该 Agent 最初作为内部支持团队的工单分诊工具运行约一年，随后于 2026 年 4 月上线支持门户，同年 9 月正式集成进核心产品，面向所有付费客户开放。整个演进过程中，Agent 的运行时始终保持统一，变化的只是前端接入面。Snyk 将权限控制、状态管理、护栏机制和评估体系作为核心产品要求，通过 LangSmith 的评估流程确保每次变更在上线前都能通过质量门槛，从而在安全合规的前提下实现快速迭代与规模化交付。
Snyk 的客户群体以开发者为主，他们在日常工作中频繁提出关于漏洞、账户状态和产品行为的具体问题。在 Snyk Assist 出现之前，这些信息分散在产品文档、支持文章、发布说明和账户数据等多个系统中，用户往往需要阅读多个页面或提交工单等待人工响应。支持团队每隔几周就要处理数千个案例，每个案例都需要人工阅读、分类和路由，随着客户咨询量的增长，这一模式面临严峻的规模化挑战。
面对规模化压力，Snyk 选择构建一个对话式 Agent，但作为安全软件公司，他们对上线标准有着极高要求。团队需要证明三件事：Agent 能够正确回答问题、能够拒绝不该回答的内容，以及绝不返回用户无权访问的数据。为此，Snyk 没有直接面向客户发布，而是先在内部支持团队中运行约一年，将所有早期会话的追踪数据导入评估集，在支持门户上线前就建立起对 Agent 行为的深入理解。
Snyk Assist 的架构核心是一个统一的 LangGraph Agent 运行时，同时服务于 Slack 应用、Web 应用和直接 API 访问三个接入面。团队选择 LangChain 的原因在于其庞大的社区生态和行业标准地位，使用其中间件而非自建方案，为上下文管理、护栏机制和模型降级提供了清晰的集成点。这种设计让功能的添加或调整只需修改一行配置，而无需大规模重写代码，极大降低了小团队的维护成本。
在权限控制层面，Snyk Assist 采用了按用户动态注册工具的机制：每次请求时根据当前登录用户的实际权限挂载对应工具，确保 Agent 只能访问该用户本就有权查看的数据。大多数工具以独立微服务形式存在，可独立扩展，新增能力无需改动 Agent 主循环。会话状态则通过 PostgreSQL 持久化存储，以会话为键，支持多轮记忆、跨 Pod 扩展和会话恢复，无需额外的状态管理逻辑。
评估体系是 Snyk Assist 能够持续迭代的关键保障。团队通过 LangSmith 对每次变更运行评估，只有通过质量门槛的版本才能上线。AI 工程师 Bailey Millns 指出，构建 Agent 的难点不在于模型能做什么，而在于证明 Agent 确实按预期工作。正是这套严格的评估流程，让团队在保持快速交付节奏的同时，能够及时发现回归问题并持续改善响应质量，最终在 2026 年 9 月将 Snyk Assist 集成进核心产品，面向全量付费客户开放。
要点
- 从内部工具起步是降低 AI 功能上线风险的有效策略，内部测试阶段的追踪数据可直接转化为评估集，为正式上线提供质量基准
- 统一 Agent 运行时、多接入面复用的架构设计，让小团队能够在不分裂代码库的前提下快速扩展产品覆盖范围
- 在安全敏感场景中，按用户权限动态注册工具是实现数据隔离的关键机制，而非依赖事后过滤
- 将 LangSmith 评估流程嵌入发布门控，是在保持迭代速度的同时防止质量回归的核心工程实践
原始标题：How Snyk Turned an Internal Support Agent into a Customer Feature
本文由 DataHub 基于公开来源整理，用于信息发现与摘要阅读；具体事实、数据和后续更新以原始来源为准。