2023 年 6 月，Windows 代码签名的合规要求确实改过一次，但改的不是「必须买 EV」。真正的变化来自 CA/Browser Forum：OV 证书的私钥必须存放在硬件安全模块或硬件令牌里，证书不能再直接下载到构建机。微软官方文档写明 OV 证书依然可以签名，在系统的信誉筛选上，效果与微软自家云签名服务等价；EV 证书则在 2024 年失去了「首次下载即跳过筛选」的待遇，官方也不再推荐为绕过提示而多付 EV 溢价。
这条政策对智能体桌面应用的影响，远大于对普通工具软件的影响。它同时决定了三件基础设施级能力能不能用：自动更新、本地凭据加密、开机自启。
站内已经讨论过桌面应用从需求到上线的五道门槛，也拆过客户端与智能体集成的成本结构。本文不重复这些内容，只谈一件更靠后、也更容易在现场翻车的事：把程序发到几百上千台机器上，并在出事时收得回来。
桌面端智能体的发布链路，本质是一条远端代码执行通道
网页端升级是换一份静态资源，出问题重发一次容器镜像。桌面端不是这个模型：自动更新会下载一个可执行文件，并以程序自身的权限，在所有装过它的机器上运行。
反过来看，这就是攻击面。更新证书或更新源一旦失守，攻击者不需要欺骗任何单个用户打开恶意文件，就能在整个装机基座上取得代码执行能力。Tibicle 在 2026 年 9 月的一篇工程分析把这条链路直接称为远程代码执行设计，并引用 Verizon《2026 数据泄露调查报告》：第三方参与的数据泄露已占 48%，同比上升 60%。
所以发布链路的第一条设计原则不是「快」，而是「可验证」。下面三道坎按实际踩坑顺序排列。
第一道坎：签名是采购与流程周期，不是构建参数
多数团队把签名当成流水线里的一段配置，写完就以为结束了。真实约束在配置之外，而且分散在三个不同责任方手里。
| 环节 | 硬约束 | 最常见的卡点 |
|---|---|---|
| Windows 安装包 | OV 或 EV 证书都可以签；完全未签名会被系统强拦截，新文件无论用哪种证书都要先累积信誉 | 证书采购与企业主体核验的周期以周计，不在研发排期内 |
| 签名密钥保管 | 2023 年 6 月起，OV 证书私钥必须存放在硬件安全模块或硬件令牌里；EV 证书同样要求硬件模块保管 | 证书不能下载到构建机，流水线拿不到密钥就签不了 |
| 流水线集成 | 云签名服务可远程调用签名硬件，微软的云签名服务（Azure Artifact Signing）无需硬件令牌即可接入现有构建流程，但同样不提供即时的信誉 | 该服务仅对部分国家或地区的开发者开放：机构限美国、加拿大、欧盟、英国，个人开发者限美国、加拿大 |
| 苹果系统分发 | 签名与公证是两步，前置需要开发者计划账号、Xcode、一台苹果构建机 | 团队没有苹果构建机，公证这一步无处可跑 |
| 苹果系统自动更新 | Squirrel.Mac 要求应用已签名，自动更新才能工作 | 本地临时签名测通了，发到现场整条更新链全废 |
表格里最容易被低估的是第二行。证书必须落在硬件模块里，意味着它不能像普通密钥那样写进流水线的环境变量。
可行的替代是云签名：签名硬件留在证书服务商机房，构建流程用短期令牌远程调用。这条路径同时解决了密钥托管和审计留痕两个问题，代价是要接受签名动作依赖外部服务可用性。但签名只是起点：系统信誉是按签名主体累积的，中途换证书主体或换签名方式，用户端的提示会重新来一遍。
苹果侧则要先确认构建基础设施。签名需要证书，公证需要把产物上传给苹果自动审核，两步都发生在苹果系统上。团队如果没有常备的苹果构建机，这条流水线在立项阶段就是缺的，而不是上线前补一下就能好。
第二道坎：签名一致性决定本地状态接不接得上
更隐蔽的问题不在安装时，而在更新之后。苹果系统靠签名判断两个版本是不是「同一个应用」。签名不一致，钥匙串就把它当成陌生程序，每次更新后重新向用户索要权限。
- 加密存储接口 safeStorage 保存的配置与凭据：更新后重复弹窗，用户开始习惯性点「拒绝」，智能体拿不到凭据直接停摆。
- 登录项设置接口：应用未正确打包、签名、公证时，开机自启会静默失败。智能体不再随系统启动，而日志里什么都没有。
- cookie 加密开关：与加密存储接口同源，同样受签名约束，出问题的表现也同样是「忽然要重新登录」。
这三条的共同点是不报错。它们以用户抱怨的形式出现，工程侧拿到的日志却干净得很。等到有人开始统计「为什么大家都不用」的时候，问题已经被记录成了采纳问题，而不是发布问题。
站内另一篇关于企业内部助手只剩四个用户的复盘讲的正是这条线：入口没打通、状态没接上，功能再多也留不住人。
结论很朴素：签名密钥、证书主体、应用唯一标识必须在立项时就定死。中途换证书主体，在系统看来等于换了一个应用，本地状态全部作废。
第三道坎：更新失败时，故障停在哪一层
签名校验失败之后的默认动作，是一条分水岭。记一条警告然后继续安装，等于把零信任降级成「看得见的冒险」；正确做法是失败即拒装——无法验证的更新直接拒绝并上报，不进入下一环节。
回滚同理。很多团队的回滚方案是「再推一个修好的新版本」，这个方案依赖三个前提同时成立：现场机器还能连上更新服务器、还能通过校验、用户还愿意再等一次下载。任意一条不成立，回滚就变成上门服务。
真正能兜底的方案是保留上一版完整安装包，并配一个不依赖用户点击的降级开关。灰度阶段把新版本比例压在可承受区间，异常指标一出现先冻结比例，而不是全量之后再去补救。
代价也要说清楚：保留旧安装包意味着产物体积和更新服务端存储都要按双份准备，灰度机制则要求发布平台支持按比例或按组织分组投放。这两项在小团队里通常最先被砍掉，而被砍掉的当天不会有人察觉，直到第一次需要回滚。
一套可以照搬的发布流程
- 立项定签名主体：确定证书主体、应用唯一标识、签名密钥托管方式，写入技术方案，后期不再变更。
- 打通构建与签名：Windows 走云签名，苹果走签名加公证，两条链路在流水线里各跑一次冒烟构建。
- 加更新包本地校验：更新器在程序内验证签名，失败即拒绝，并把失败事件上报到监控。
- 先做内部灰度：用一小组真实办公机器跑满一个完整更新周期，重点看钥匙串、登录项、常驻进程三项。
- 按比例放量并设熔断线：明确崩溃率、更新失败率、凭据弹窗率三个阈值，越过即冻结投放。
- 演练一次真回滚：在灰度阶段实际执行一次降级，验证旧安装包可回退、配置可兼容。
这套流程的价值不在于步骤本身，而在于把「发布」从一个人的动作变成一条有准入门槛的路径。谁都能推包，和谁能推包，是两种组织的差别。
上线前自查清单
- Windows 安装包使用 OV 或 EV 可信证书签名，签名时间戳可验证，并已准备好向用户解释首次发布可能出现的信誉提示。
- 签名密钥不在流水线的明文环境变量里，也不在任何研发的本地磁盘上。
- 苹果产物完成了签名与公证两步，而不是只有临时签名。
- 更新器校验失败时的行为是拒绝并上报，不是警告后继续。
- 上一版完整安装包在更新服务端仍可取回，降级路径演练过。
- 钥匙串与凭据相关状态在跨版本更新后仍然有效。
- 崩溃率、更新失败率、凭据弹窗率三项指标已接入告警。
- 证书到期时间已进入日历提醒，且续期流程有人负责。
关于本文的证据边界
本文不引用任何客户成效数据，也不引用站内案例的条数、按端占比或签核状态统计——这类数字必须逐条核到案例页与签核记录，本文没有做这项统计。
仍然值得强调的一点是：桌面端智能体的公开可核验样本偏少。看到「某行业落地后效率提升若干倍」这类说法时，先要求看原始材料，再讨论是否适用。站内桌面端转型复盘这类内容，其价值同样在过程记录，而不在结论数字。
如果你正在评估桌面端智能体的分发方案，可以先看已公开的案例页了解交付范围与边界，或直接联系我们讨论签名资质、灰度策略与回滚预案的具体做法。
常见问题
纯内网、离线部署的智能体还需要做代码签名吗
需要。签名解决的是系统信任，不是联网校验。未签名的程序在 Windows 和苹果系统上依然会被安全策略拦截或反复警告，内网分发只改变了更新源，没有改变操作系统的判定规则。
把网页端套一个桌面壳，能不能绕开签名问题
绕不开，只是把问题推迟到分发环节。Electron、Tauri 或原生容器最终都产出一个需要安装的可执行文件，签名要求由操作系统给出，与前端技术栈无关。
更新服务器放在自己机房，是否还要校验更新包签名
要。更新源不可信是一条基础假设：机房账号、流水线凭据、内容分发网络配置任一环节失守，都能让攻击者投递任意程序。校验发生在用户机器本地，才不依赖对服务端的信任。
团队没有苹果构建机，苹果版本怎么办
两条路：配置一台常驻的苹果构建机接入流水线，或使用支持苹果系统构建的托管服务。签名证书和公证都需要发生在苹果系统环境中，这一步无法用其他系统替代。
参考
- Microsoft Learn：Windows 应用代码签名选项（OV 与 EV 在系统信誉筛选上的实际表现、2023 年 6 月起 OV 私钥必须存放硬件安全模块或硬件令牌、2024 年起 EV 不再即时绕过、微软云签名服务免硬件令牌与地区限制）
- Electron 官方代码签名文档（Squirrel.Mac 签名前置、加密存储与登录项的签名依赖；该页关于 Windows 侧必须使用 EV 证书的表述与微软现行文档不一致，本文以微软文档为准）
- Tibicle：Setting Up a Zero-Trust Electron App Auto Update Pipeline（2026-09，更新通道的远程代码执行属性、失败即拒装原则、灰度与回滚策略）