# Kestra NAS KB 接管加固状态

时间：2026-06-03T01:06:54+0800

## 已完成

1. Bridge v1 已从 Hermes background process 迁到 macOS LaunchAgent 常驻。
   - LaunchAgent label: `local.kestra.nas-kb-bridge-v1`
   - plist: `/Users/bot1/Library/LaunchAgents/local.kestra.nas-kb-bridge-v1.plist`
   - 本地 ops 目录：`/Users/bot1/.hermes/ops/kestra-nas-kb-bridge/`
   - 当前 listener PID：`50112`
   - 端口：`127.0.0.1:19092`

2. 解决了 launchd 访问 AI工作区/NAS 路径脚本与日志的权限问题。
   - Bridge 脚本本地镜像：`/Users/bot1/.hermes/ops/kestra-nas-kb-bridge/kestra_nas_kb_bridge_v1.py`
   - Bridge 项目源脚本也已更新为把 runtime state/logs 写入本地 ops：
     `/Users/bot1/Volumes/root_for_ai/AI工作区/通用_多Agent编排_Kestra评估POC_20260602_2208/runtime/scripts/kestra_nas_kb_bridge_v1.py`
   - runtime state/logs：`/Users/bot1/.hermes/ops/kestra-nas-kb-bridge/state` 和 `logs`
   - briefs 仍从项目目录读取，作为稳定配置资料。

3. 验证结果。
   - LaunchAgent state: `running`
   - Bridge `/health`: ok
   - Bridge direct preflight: ok
   - Kestra 手动触发 `preflight_status` 成功：execution id `7FgxHYzPQIgslaYE3LYeyD`
   - 该 execution task `preflight` 状态：SUCCESS

## Kestra Secret 状态

已按官方文档优先确认：Kestra Open Source 使用 `SECRET_<NAME>` 形式的 base64 环境变量作为 `{{ secret('<NAME>') }}` 的来源；Cloud/Enterprise 版可通过 UI/后端管理更多 secret backend。

现场检查结果：

- 当前本地 API 是通过 `ssh` 监听/转发到 `127.0.0.1:18080`。
- 本 profile 当前没有可直接操作的 Docker CLI。
- Kestra secrets API 返回 `readOnly: true`、`total: 0`。
- 因此当前不能在本轮通过 API 写入 `KESTRA_AGENT_BRIDGE_TOKEN` secret。
- 本地 Flow 源文件仍保留 `{{ secret('KESTRA_AGENT_BRIDGE_TOKEN') }}` 写法，作为后续迁回 Secret 的模板。
- 线上已部署 revision 2 为了保持接管可用，仍使用当前 Bridge token 值直接调用；具体 token 未写入本文档。

后续 Secret 迁移步骤：

1. 在 Kestra server/container 环境中设置 base64 后的 `SECRET_KESTRA_AGENT_BRIDGE_TOKEN`。
2. 重启 Kestra server/container，使 `{{ secret('KESTRA_AGENT_BRIDGE_TOKEN') }}` 可解析。
3. 将 `runtime/flows/nas_kb_*.yml` 这 4 个本地模板重新 PUT 到 Kestra，形成新的 revision。
4. 手动触发 `preflight_status`，确认 SUCCESS。
5. 再扫描线上 Flow 定义，确认不再包含实际 Bridge token 值。

## 当前接管边界

- Kestra 已接管调度与可视化状态机。
- 原 Hermes cron 三段已暂停。
- NAS 共享知识库写入仍由原审批门禁保护；Kestra 不绕过审批。
- Bridge 不是通用命令执行器，只允许固定 task_key。

## 回滚

如需回滚：

1. `launchctl bootout gui/$(id -u) /Users/bot1/Library/LaunchAgents/local.kestra.nas-kb-bridge-v1.plist`
2. 暂停/停用 namespace `studio.nas_kb_memory_governance` 下 4 个 Kestra Flow 的 schedule。
3. 恢复原 Hermes cron：
   - `f859bdb12387`
   - `a3d332a1d4b8`
   - `388e37df5449`
4. 运行一次 `nas_kb_approval_queue_status.py` 检查队列状态。