跑起来是第一天的事，跑下去是后面几个月的事。把 iPolloWork 放进阿里云长期使用，真正决定成败的不是安装命令，而是几条关于「什么不该做」的判断——尤其是别把桌面端的东西当成服务端组件，也别把本地敲出来的包当成正式版本。
该留的：把状态隔离当默认
iPolloWork 在这点上做得克制，值得当成默认习惯：
开发模式使用隔离的 iPolloWork/OpenCode 状态，不会覆盖用户正常的 OpenCode 配置。
dev:cloud 会创建隔离的开发配置文件，把身份验证与 Cloud API 指向给定 URL，并要求 Cloud 登录；不会更改正常的本地 iPolloWork 配置文件。
这在云上尤其值钱：长期运行的机器上折腾升级、切换 Cloud 地址、试新插件，只要隔离还在，改坏了也不污染另一套配置；一旦为省事把它们合并，回滚成本就从「删掉一个目录」变成「重建整个环境」。另外，Cloud 连接是可选的——长期方案不需要云端控制面，就别把它接进来。
云上长期运行要固定的三件事
实例与云盘
长期运行按运行水位选规格，不必按构建峰值常驻；构建是间歇性的，需要时临时升配更划算。但依赖缓存与构建产物会持续膨胀，建议放数据盘并定期做快照，实例被回收或重建时状态还在。
安全组
长期运行最怕「临时放开忘了收」。原则是默认拒绝入方向：SSH 只放行你自己的来源 IP，不要留 0.0.0.0/0；dsh web 端口优先用 SSH 端口转发，确需直连时把来源限制到具体 IP。为排查问题开的宽放行，都该记成待办而不是顺手操作。
出网
出网需求是脉冲式的：构建期要下载依赖与 sidecar，日常运行不需要大出口。长期策略应是「平时收紧、构建时按需放行」，而不是长期全开。
别做：把 Electron 桌面壳当服务器组件
桌面形态是 apps/desktop——「Electron 桌面外壳与打包」；真正负责无头运行的是 apps/orchestrator（无头运行时编排）与 apps/server（服务器 API）。
把桌面壳常驻在 ECS 上，等于为了拿一个 web 界面额外背上整套 Electron 运行环境（Linux 上还得有 C/C++ 工具链、Python 3、pkg-config 与桌面库）。云上该走「服务 + 浏览器访问」，桌面壳留给本地。
同理，./ipollowork dev 会打开 Electron 桌面客户端，笔记本上是好事，无图形界面的服务器上是多余的等待——服务器上优先用只启浏览器 UI 的 ./ipollowork dev:ui。
别做：把本地打包产物当正式版本分发
最容易踩、后果也最麻烦的一条。README 写明：除非提供相应的 Apple 或 Windows 签名凭据，否则本地包未签名；它们适合开发测试，但不应作为官方版本呈现。
两件事要一起记住：
本地打包针对当前机器的操作系统和 CPU 架构——x64 上打出来的包天然不是 ARM64 的；完整签名/公证矩阵（macOS ARM64/x64、Windows ARM64/x64、Linux ARM64/x64）由 GitHub 发布工作流生成，本地替代不了。
Windows 侧还有一层：本地构建的未签名安装程序可能会触发 Microsoft Defender SmartScreen。这是未签名包的常态，但它出现在你交付给别人的「正式安装包」上时，对方看到的是一次来源不明的警告。
判断标准很简单：产物给自己或测试用，本地打包没问题；要对外呈现为某个版本，就必须走发布工作流。
版本号怎么跟着发布流走
命令 结果
build 编译生产 UI、服务器、Electron shell 和 sidecar；不会创建安装程序
package:dir 创建最快的未打包桌面应用，用于本地验证；不会更改发布版本
package 运行检查、推进客户端版本，再为当前系统和 CPU 创建原生安装程序与便携/更新产物，但不会发布它们
关键在 package：它是本地发布命令，让 App、Desktop、Orchestrator 与 Server 的版本保持同步并推进客户端版本，但本地打包从不提交、打标签、推送或发布版本。也就是说版本号被推进了，发布动作一次也没发生；在多台机器上跑 package，版本号会各自往前走，这是长期运行里最容易被忽略的漂移来源。
配套两条规则：版本序列是从 0.1.0 到 0.99.0，然后是 1.0.0，源码检出从未发布的基线 0.0.0 开始；./ipollowork package --dry-run 可查看下一个版本，--skip-check 只在检查已通过时才用。
一条容易漏的收尾：本地开发构建与 Cloud 登录
如果在 Windows 上做开发构建、又要连云上或本地的 Cloud 控制面测试登录，README 提示了一件容易忘的事：Windows 开发构建不会自动注册生产环境的 ipollowork:// 处理器。用外部浏览器测试 Cloud 登录时，需要用仓库中的协议切换器，并在完成后恢复生产处理器。测完不收，本机协议处理就停在非生产状态，之后所有走 ipollowork:// 的操作都会受影响。
总结
阿里云上长期跑 iPolloWork 的取舍可以压成一句：把该隔离的隔离住（开发模式的隔离状态、dev:cloud 的隔离配置），把该收的收紧（安全组最小放行、出网按需开、实例按运行水位），把不该混的分清楚（桌面壳不当服务端组件、本地打包产物不当正式版本、package 推进版本但不发布）；守住这几条，长期维护成本会明显低一截，想先摸清可选插件的范围，可以对照这份 DeepSeek Harness Hub 插件清单。
适合与不适合
适合：已经把 iPolloWork 放进长期环境、开始考虑升级与版本一致性的团队；在云上跑服务、同时在本机做开发构建的开发者；需要把产出与状态留在服务器侧的人；想用 Cloud 控制面但不想让它污染本地配置的用户。
不适合：只做一次性试用、不打算维护到第二个月的人；必须把本地构建的未签名产物直接交付给外部客户的团队；希望把 Electron 桌面客户端当常驻服务运行在无图形环境的用户。
标签：iPolloWork、DeepSeek Harness、阿里云长期运维、版本与发布
本文由 DeepSeek Harness Hub 自动整理，数据来源于插件详情页。
