# 云端服务器整理与优化卡（零停机 · 含一次事故复盘）

> 服务器 `43.167.209.150` 上同时跑着**实盘交易系统**与 Agent OS。
> 第一原则：**不许中断交易链路**；第二原则：**改动前先确认进程依赖关系**。
> 出卡人：验收方（DeepSeek Harness）　依据：2026-10-17 真机审计 + 一次真实事故

---

### P1-06B 云端服务器整理与优化

```text
【任务 P1-06B】整理并优化云端服务器（零停机 · 先稳定后容量）

━━━━━━━━━━ 零、必读：验收方刚刚踩过的坑（不要再踩）━━━━━━━━━━
1. 【两个 uvicorn 是父子耦合，不是重复实例】
   实测：venv 的 python（父，如 PID 104）会拉起系统 Python 的 python（子，如 PID 3628），
   真正占 :8000 的是子进程。**杀掉任意一个，整个服务就挂**。
   验收方按"清理重复实例"杀了 5096，结果服务 DOWN 约 2~4 分钟，
   最后由 uvicorn_watchdog 自动重启恢复（12:01）。
   ⇒ 本卡**不做**"清理重复 uvicorn"这件事。除非你能给出进程关系图并证明可安全移除。

2. 【系统 Python 的依赖已经漂移，用它会崩】
   系统 Python 3.11:  fastapi 0.115.0 | uvicorn 0.51.0 | starlette 1.0.1
   venv:            fastapi 0.115.0 | uvicorn 0.30.6 | starlette 0.38.6
   用系统 Python 启动直接报：
     TypeError: Router.__init__() got an unexpected keyword argument 'on_startup'
   （FastAPI 0.115 要求 starlette <0.42，而系统里是 1.0.1）
   ⇒ 一切启动**必须**用 C:\agent-os\backend\venv\Scripts\python.exe

3. 【logs 目录原本不存在】
   C:\agent-os\backend\logs 之前**不存在**，任何带 `>> logs\x.out` 重定向的启动都会
   让 cmd 秒退、看起来像"启动失败"。验收方已创建该目录。

4. 【已有自愈机制，别重复造】
   C:\Users\Administrator\AppData\Local\hermes\scripts\uvicorn_watchdog.py
   每 2 分钟探测 http://127.0.0.1:8000/api/v1/health，挂了就用 **venv python** 重启。
   注意它注释里记录的坑：网关环境有 HTTP_PROXY/ALL_PROXY=http://127.0.0.1:8765，
   本地探测必须 trust_env=False 绕过代理，否则会误判并假重启（历史上 50/50 全误报）。
   ⇒ 我们要做的是"让 watchdog 之外还有一层系统级保障"，不是再写一个 watchdog。

━━━━━━━━━━ 一、绝对禁止（违反会造成真实资金损失）━━━━━━━━━━
  1. 禁止停止/重启：hermes.exe gateway run、silicon_proxy.py、relay_server.py、
     以及任何 Hermes* / ydguard / cua-driver-serve / CreatorHub 计划任务
  2. 禁止改动 C:\Users\Administrator\AppData\Local\hermes\ 下任何脚本与 cron
  3. 禁止卸载/重装宝塔(C:\BtSoft) 与 nginx
  4. 禁止改 3389/22 的防火墙放行（可能把自己锁在门外）
  5. 禁止改 .env 里除 DEBUG 外的任何值
  6. 禁止杀 uvicorn 进程（见上面第 1 条）

━━━━━━━━━━ 二、分级任务 ━━━━━━━━━━

P0-1【依赖锁定，消除"用错 Python 就崩"的地雷】风险：低
  动作：
    a) 用 venv 导出锁文件：venv\Scripts\python.exe -m pip freeze > C:\agent-os\backend\requirements.lock
    b) 给系统 Python 装回兼容的 starlette（`pip install "starlette<0.42"`），
       让"误用系统 Python"也不会崩 —— 这是**消除地雷**，不是绕开它
    c) 在 backend 根写一个 start_agentos.bat，唯一正确启动方式写死在里面（venv + logs 重定向）
  验证：`& "C:\Program Files\Python311\python.exe" -c "import starlette;print(starlette.__version__)"`
        应 <0.42；用系统 Python 试启一次（另开端口 8010）应能正常起、然后关掉。

P0-2【relay 的安全处置】**必须让用户拍板，做前先问**
  事实：relay_server.py 监听 **0.0.0.0:8001**，同目录有 ssh_tunnel.zip / connect.bat /
        worker.zip / config.json，与历史上那次安全事件里的"中继"高度相似。
  请：① 查明它的用途、谁在用、是否仍需常驻，写进 done.json 的 notes；
      ② 给出三个选项给用户选：保留但限制来源 IP / 改监听 127.0.0.1 / 停用并移除自启；
      ③ 用户未明确选择前：**不停止、不删除、不修改**。

P0-3【防火墙收敛（只加严）】风险：中
  目标：8000 不对公网直开，只允许本机/nginx 访问。
  动作：加一条入站规则只允许 127.0.0.1 访问 8000；若存在 8000→Any 的放行则禁用。
  验证：本机 `curl http://127.0.0.1:8000/api/v1/health` 仍 200；外部访问 8000 失败。
  回滚：重新启用原规则。**不要碰 3389/22。**

P1-1【Agent OS 系统级服务化（重启后自动恢复）】风险：中（有 watchdog 兜底）
  现状：只有用户级 watchdog（每 2 分钟），**没有 Windows 服务/开机任务**，
       机器重启后依赖某个启动脚本才起来。
  动作：建一个 Windows 服务（NSSM）或 ONSTART 计划任务，唯一命令：
        C:\agent-os\backend\venv\Scripts\python.exe -m uvicorn app.main:app --host 127.0.0.1 --port 8000 --workers 1 --log-level info
        工作目录 C:\agent-os\backend
        失败自动重启（服务恢复策略 3 次 / 每 60 秒）
  注意：**不要与 watchdog 抢**。若两者都重启可能起两个实例。
        建议：服务化完成后，把 watchdog 改为"只告警不重启"，或让它检查服务状态而非进程。
  验证：`Get-Service` Running；停一次服务确认能自动回来；health 200。

P1-2【DEBUG 关掉】风险：极低
  .env 里 DEBUG=true → false（只改这一项），重启服务后 health 200，日志量下降。

P1-3【收进 nginx 反代】风险：中
  现有 nginx 已在跑（80/443，站点 ldeh.asia）。把 /api/ 反代到 127.0.0.1:8000，
  获得 TLS/限流/访问日志。**先备份 nginx conf**，只加最小 location，不要动现有站点。
  验证：经 nginx 访问 /api/v1/health 返回 200。

P2-1【磁盘回收（目标 ≥1.5 GB）】风险：低，逐项做
  现状：49.9GB / free 5.7GB (11.4%)。可回收项（实测体积）：
    C:\BtSoft 1732MB、winevt\Logs 149MB(345文件)、Windows\Installer 196MB(只报告不删)、
    SoftwareDistribution\Download 46MB、回收站 36MB、Windows\Temp 10MB(769文件)
  顺序：回收站 → Windows\Temp(删>2天) → 事件日志压上限20MB → WU缓存(先停wuauserv) →
        BtSoft 只清安装包/zip，**不动面板本体与网站**
  每步报告回收量；**Windows\Installer 只报告不删**（删了无法卸载/修复）。

P2-2【日志与备份轮转】
  - Hermes memories 目录有 12 个 .bak/.conv_/.sink/.nxai_backup → 只保留最近 5 个
  - Agent OS 日志按 10MB×5 轮转（logs 目录刚建，正好一开始就配好）
  - 事件日志上限统一 20MB

P2-3【计划任务梳理（只报告）】
  现有非 Microsoft 任务：CreatorHub、CreatorHub_Logon、cua-driver-serve、EnableOpenSSHOnce、
    hermes-reload、HermesGateway、HermesGatewayBoot、HermesGatewayWatchdog、HermesGwReloadOnce、
    HermesReloadTest、ydguard
  产出表：任务名 / 触发 / 实际命令 / 是否仍需要 / 建议。**只报告，不执行禁用。**

━━━━━━━━━━ 三、每步都要验证并写进 done.json ━━━━━━━━━━
  格式例：
  "P0-1: 系统 starlette 1.0.1→0.38.6，系统Python试启 8010 成功；
   P1-2: DEBUG true→false，重启后 health=200；
   P2-1: free 5.7GB→X.GB（回收 X MB）；
   交易进程未动：hermes pid=____ / silicon_proxy pid=____（启动时间与动手前一致）"

━━━━━━━━━━ 四、验收标准 ━━━━━━━━━━
  □ health 始终 200（每次改动后都验过，并记录时间点）
  □ 用系统 Python 启动也不再崩（starlette 已修回兼容版本）
  □ 有 requirements.lock + start_agentos.bat，启动方式唯一且正确
  □ Agent OS 有系统级服务/开机任务，重启能自动恢复，且与 watchdog 不打架
  □ free space 至少回收 1.5 GB，附前后对比
  □ 交易相关进程/任务一个都没被动过（列出 PID + 启动时间自证）
  □ relay 已给出三选项交用户决策（有记录）
  □ 计划任务梳理表已产出
  □ 每个改动都有回滚说明
```

---

## 附：为什么不能暂停整台服务器

用户提出过可以暂停服务器再优化，**但不要这么做**：

1. `hermes.exe gateway run` 是交易大脑，另有播报自愈(10min)/盯盘(30min)/link_check(30min) 等 cron；
   记忆里明确写着 `margin_gate`、`止损·反手照常`、`watch_only.flag` —— 停摆期间**止损不会执行**。
2. 本次所有任务都不需要停机：清理是文件操作；服务化可"先建后切"；DEBUG 与监听地址只影响
   Agent OS 这个 PWA 后端，与交易进程无耦合。
3. 唯一会短暂中断的是 Agent OS 自身（秒级），而且有 watchdog 2 分钟内兜底。
4. **事故复盘**：验收方曾误判"重复进程"并杀掉一个，导致服务 DOWN 约 2~4 分钟（无交易影响，
   watchdog 自愈）。这正说明"看起来无害的清理"也可能造成中断 —— 所以本卡要求：
   **改任何进程前，先画出父子关系，再动手。**