试点上线与验收
本页用于验收独立 Evolver 的首次部署或升级。验收对象是一个确定版本、身份和目录的运行实例。
先把一个节点作为试点，完成安装、身份、策略、服务和恢复验证，再扩大到团队或长期运行环境。
安装前准备 Node.js
^22.13.0 || >=23.4.0与 Git，并通过evolver --help查看命令。
试点前
- 指定负责人、环境、Hub、身份目录和数据目录。
- 固定 Node.js、Evolver 与相关应用版本来源。
- 建立节点身份、GEP 资产、配置和事件的备份。
- 默认关闭不需要的 Worker、Validator、自动发布和付费行为。
- 设置任务级文件上限、行数上限、禁止路径与验证命令。
设计一个能够说明问题的试点
试点任务需要有明确输入、预期产物和验证方式。选择可以在测试环境重做、结果能够独立检查的工作，并记录初始文件状态。只验证程序能够启动，无法说明任务边界、停止控制与恢复流程有效。
验收至少覆盖三种情形：允许的任务正常完成；超出已配置边界的请求被拒绝；人为中断后能够确认已有结果并按流程恢复。拒绝测试应针对当前版本已经落实的控制，在隔离测试目录中进行，不使用生产凭证或真实付费请求来试探限制。
例如，试点仅允许处理一个测试仓库：正常案例检查目标产物和验证结果；边界案例检查任务没有越过已配置的工作根目录；恢复案例在受控停止后核对已有产物，再恢复未完成部分。三种结果分别保留，不能用一次正常完成代替其余验收。
从试点扩大到持续运行
扩展前先列出与试点不同的因素：服务用户、启动方式、目录、平台、网络条件和任务规模。差异项决定需要重新验证的内容。把终端启动改为系统服务后，尤其要重新确认进程读到的环境配置与目录，而不是直接沿用终端检查记录。
升级时将软件版本变更与策略放宽分开进行。先按原边界验证新版本，再评估新增能力；失败后才能明确恢复到哪个软件版本和哪份配置。上线记录同时保存版本与配置，单独记录其中一项不足以重现试点结果。
启动与检查
evolver doctor
evolver status
evolver lifecycle status
evolver lifecycle check
如果需要长期运行，再选择适合平台的 Windows 服务、systemd 或 launchd 安装方式。启动后验证进程身份、最近心跳、数据目录和停止命令，而不只检查进程是否存在。
旧计划任务
升级前后都应检查旧计划任务或重复启动项。先执行预览：
evolver lifecycle cleanup-legacy-tasks --dry-run
只有确认目标与备份的 preimage 后才执行清理。发生误删时使用保存的 preimage 恢复，不要手工猜测原任务参数。
验收标准
- 一个边界明确的任务能够完成并产生可复核证据。
- 停止、重启和系统重启后状态符合策略，没有重复进程。
- 备份能够在隔离目录恢复，事件和资产可读取。
- 网络角色、发布和预算行为与清单一致。
- 负责人能够在不读取秘密明文的情况下定位一次失败请求。
任何一项失败都应保持在试点范围内，恢复旧配置或停止服务后再排查。
形成可交接的验收记录
首次部署先保存初始配置；升级则保留旧版本、目录清单和已领取任务的状态。服务方式只能选择已核对的入口，避免手动进程和系统服务同时启动同一实例。工具安装见Evolver CLI；服务安装与启动参数以当前版本的 evolver lifecycle --help 为准。
每项验收记录目标、实际结果、证据位置、时间和负责人，分别标记通过、失败或未执行。恢复演练或停止验证未执行时，不能判定已具备长期运行条件。扩容时按同一清单逐个核对新实例；已有节点通过不替代新节点验收。
相关页面
EvoX 文档 · 开发者 · 独立 Evolver 维护