超过85%的会话没有创建支持工单，这个数字背后最值得复制的，可能是上线闸门而不是模型。Snyk在10月8日公开支持Agent生产复盘：从内部工具走向客户产品，团队坚持按用户权限注册工具、保存会话状态，并让每次改动先通过评测。累计超过6万次查询的结果仍是团队自报，但权限和产品功能可在客户文档中交叉核验。

内部一年，不是上线的唯一验收标准

Snyk Assist先服务内部支持团队约一年，2026年4月进入客户支持门户，随后被放进主产品的工作界面。阶段推进让团队把边缘问题留在可控制的用户群中处理，并把真实交互轨迹转成测试样本，再扩大服务范围。

复盘称同一个运行时覆盖Slack、Web和API，团队没有为每个入口重写Agent循环。对小团队而言，统一架构让修复、功能更新和事故响应集中在一处；但多入口也意味着认证、会话归属和当前业务范围必须保持一致，不能只统一界面体验。

这里存在需要读者注意的可用范围差异：复盘把产品面向付费客户描述为广泛可用，当前用户文档却标注Early Access、Enterprise计划，并要求新导航。实际接入应以账户与现行文档为准，不能把案例中的推广范围写成所有付费用户已经开通。

按用户注册工具，限制放在调用之前

系统把工具定义为类型化函数，在请求时按已登录用户的实际权限注册。Agent可以调用的数据因此首先受业务身份约束，而不是让提示词承担全部保密责任。多数工具作为独立微服务，能力扩展与吞吐可以分别处理，不必改变整个Agent循环。

Snyk产品文档进一步限定，Assist只访问当前Organization和Group，不能跨Tenant比较多个组织；它看不到用户屏幕，也不能代替用户修改设置、运行扫描或修改项目。查知识、查账号信息、创建支持工单与改变安全配置，需要在工具层明确区分。

上下文、护栏和模型回退通过中间件接入固定生命周期点；会话历史由checkpointer保存到PostgreSQL，并按session区分。持久会话有助于多Pod扩容和继续对话，但会话ID、身份变化和组织切换仍应共同检查，不能把“恢复了历史”自动理解成权限仍然有效。

每次改动先跑评测，线上失败再变成样本

Snyk从开发开始就记录模型调用、工具调用与决策点。离线评测包含真实问题与已知良好答案，并由另一个模型评分；另有红队测试，观察是否会被诱导忽略指令或透露秘密。模型评分能加速比较，但本身也需要抽样人工复核。

每个拉取请求运行真实Agent与测试套件，达到仓库中约定的阈值才可发布。这样的闸门把质量要求放到开发流程里，不必依靠某个人记得手工验收；阈值、测试集和数据版本需要一起保留，才能解释一次变更为什么被放行。

线上定时任务给生产运行打分，检查问题是否与Snyk有关、回答是否回应了问题，并按产品领域、语言生态和错误类型分类。失败轨迹通过LangSmith的MCP入口进入调查与数据集，形成下一次测试材料。观察结果如果不能进入回归测试，日志就只会越积越多。

小编判断：不建工单，仍需证明问题已解决

复盘报告自4月面向客户后处理超过6万次查询、覆盖500多个客户账号，超过85%的会话没有创建支持工单，另有250多个案例被自动识别并升级。它们是客户团队披露的结果，公开产品文档支持功能存在，但没有给出这些业务数字的独立审计。

85%不建工单是特定会话口径，不等于85%的所有客户问题被彻底解决，也不等于人员工作量或成本下降85%。读者还需要知道分母、会话如何划分、评分误差、用户放弃率和后续重复求助。材料没有提供完整基线与长期跟踪，因此不把“节约数百小时”转换为普遍ROI。

真正可复用的是交付方法：先在内部积累真实失败，工具按用户权限提供，状态按会话隔离，发布用评测阻断，线上问题回流为测试。企业试点也应统计人工介入、错误升级、越权尝试与重复求助，并让用户始终能找到人工支持。

数据治理还需按具体服务检查。Snyk公开资料区分问题审核和答案生成的模型供应商，保留策略也不同，不能统称零保留。把权限、状态、评测和数据处理条款一起验收，才有机会让一个内部有用的Agent稳定成为客户产品。