北京
Sierra 宣布在其平台中直接内置 Release governance（发布治理）功能，为大规模智能体（agent）部署提供系统化的安全护栏。这一功能的推出，意味着智能体从构建到上线将不再依赖非正式的检查或人工记忆，而是通过平台内置的检查、审批和发布策略，确保每一次变更都能安全地进入真实客户对话。
在 Sierra 平台上，一些全球最大的公司正在构建智能体：数百人协作开发同一个智能体，覆盖数百个用户旅程，服务数百万客户。一个微小的改动，就可能瞬间改变智能体与每一位客户的交互方式。在这样的规模下，安全发布智能体显然不能靠非正式检查或某个人记得去复核变更来实现。
平台内置三道防线
Release governance 将软件工程领域成熟的纪律——自动化测试、代码审查、分阶段发布——应用到智能体开发生命周期中。具体落地为三个核心机制：Agent Checks（智能体检查）、Simulations（模拟测试）和merge approval workflows（合并审批流程），以及split traffic releases（流量拆分发布）。
Agent Checks 相当于智能体的 linter（代码检查工具），在构建过程中基于用户旅程及其生成的对话，实时给出警告。它能捕捉那些容易被忽略但上线代价高昂的问题，例如：提示词引用了工具但从未实际提供、给智能体的指令相互冲突、查询工具被当作操作工具使用、在屏幕上显示正常但在电话中失效的回复，以及敏感数据查询缺乏足够的身份验证。检查结果按严重程度分级，帮助团队区分哪些问题可能影响客户、哪些只是低优先级的质量改进项，且大多数问题都会附带 Ghostwriter 提供的可一键应用的修复建议。
如果说 Agent Checks 解决的是智能体"如何构建"的问题，那么有些问题只会在对话中暴露。因此，团队还可以要求在进入生产环境前必须通过 Simulations（模拟测试）。两者结合，构成了平台内置的自动化质量门禁，大幅降低变更在未经验证的情况下溜进生产环境的风险。
人工审批：自动化无法替代的判断
自动化门禁能拦截"坏的"变更，但无法判断一个变更"是否应该上线"。这正是合并审批流程存在的意义。组织现在可以要求在变更发布前必须经过同行评审，就像软件团队在合并 pull request 前需要批准一样。专门的 Reviewer（评审者）角色让组织可以精确决定需要谁的签字：客户体验负责人、合规利益相关方、工程经理，或其他领域专家。
评审者可以逐行检查差异（diff）、留下上下文相关的评论，并在合并批准前要求修改。构建者可以借助 Ghostwriter 处理反馈，甚至在人工签字前再次请求评审。
渐进式发布，而非一次性全量
变更获得批准后，下一步是发布策略。Sierra 支持流量拆分发布，让变更逐步灰度上线，而非一次性推送给所有客户。这种渐进式发布方式，与软件工程中的分阶段发布一脉相承，为大规模智能体部署提供了可回退、可观测的安全路径。
Release governance 的推出，将软件工程领域数十年来积累的发布纪律系统性地引入智能体开发生命周期。对于正在将智能体推向生产环境、服务真实客户的企业团队而言，这意味着从"构建"到"上线"的每一个环节都有了明确的检查点、责任人以及可执行的发布策略。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
