# Kestra 本地 POC 验证报告

验证时间：2026-06-02 23:03–23:05 CST
执行 profile：it

## 结论

本地 Kestra POC 已跑通。

Kestra 可以作为 Bot1 / Bot2 / OpenClaw 的外部流程状态机和进度可视化层使用。三个最小验证 flow 均成功：

| Flow | Execution ID | 状态 | 耗时 | 结果 |
|---|---|---:|---:|---|
| `openclaw_ping` | `73FpsnnmYNl2cLlIzvkQau` | SUCCESS | PT2.198669S | OpenClaw gateway/health 可被 Kestra 间接调用 |
| `bot1_profile_ping` | `rlp6a4Ait41t69PxVe1Pi` | SUCCESS | PT7.354695S | Bot1 Hermes `it` profile 返回 `BOT1_OK` |
| `bot2_profile_ping` | `2tvEDCSSyBb5YB6d1MB68c` | SUCCESS | PT16.515282S | Bot2 Hermes `it2` profile 返回 `BOT2_OK` |

## 当前运行组件

- Kestra UI/API：`http://127.0.0.1:18080/ui/`
- Kestra service/management：`127.0.0.1:18081`
- 临时 host bridge：`http://127.0.0.1:19091`
- Docker network：`kestra-poc-net`
- Docker containers：
  - `kestra-poc`
  - `kestra-poc-postgres`
- Docker volumes：
  - `kestra-poc-data`
  - `kestra-poc-postgres-data`

## 实施方式

因为 Kestra Docker 容器不应直接拿到 Hermes/OpenClaw 的本机凭据和 profile 环境，本 POC 使用了一个本机 loopback-only bridge：

```text
Kestra container
  -> http://host.docker.internal:19091/ping/<target>
  -> 本机 bridge 执行受控命令
  -> 返回脱敏 JSON
```

Bridge 文件：

```text
runtime/scripts/kestra_poc_bridge.py
```

Flow 文件：

```text
runtime/flows/01_bot1_profile_ping.yml
runtime/flows/02_openclaw_ping.yml
runtime/flows/03_bot2_profile_ping.yml
```

## 验证结果摘要

### OpenClaw

- Kestra flow：`openclaw_ping`
- Bridge command：OpenClaw health/status 只读检查
- 结果：成功
- 摘要：Feishu configured，gateway event loop ok，Agents 包含 `main` 和 `video-executor`

### Bot1 Hermes

- Kestra flow：`bot1_profile_ping`
- Bridge command：调用 Bot1 `hermes -p it chat -q 'Reply exactly BOT1_OK.'`
- 结果：成功
- 输出：`BOT1_OK`

### Bot2 Hermes

- Kestra flow：`bot2_profile_ping`
- Bridge command：SSH 到 Bot2，调用 `hermes -p it2 chat -q 'Reply exactly BOT2_OK.'`
- 结果：成功
- 输出：`BOT2_OK`

## 遇到的问题与处理

1. Docker Hub 直连拉取 `postgres:16` 超时。
   - 处理：使用 `public.ecr.aws/docker/library/postgres:16`。

2. Kestra 官方镜像 Docker Hub 拉取超时。
   - 处理：使用镜像源 `docker.m.daocloud.io/kestra/kestra:latest`，镜像 digest 已由 Docker 拉取过程确认。
   - 风险：这是非官方域名镜像源，正式部署应优先用官方镜像或可信私有镜像仓库。

3. Kestra 1.3.20 开源版 Basic Auth 已强制启用，`enabled: false` 会被忽略。
   - 处理：为 POC 配置了本地临时 basic-auth 用户。
   - 正式部署应使用强密码、只内网/认证反代，并避免在文档中记录明文口令。

4. 初次 Postgres volume 使用了错误口令，导致 Kestra DB auth failed。
   - 处理：清理 POC Postgres volume，使用匹配配置重建。

5. API 部署 Flow 的 Content-Type 必须使用 `application/x-yaml`。
   - `text/yaml` / `application/yaml` 会被 Kestra 1.3.20 识别失败。

6. Hermes CLI `-t none` 会提示 Unknown toolsets: none，但不影响返回。
   - 正式 wrapper 应去掉该参数或改为明确可用 toolset。

## 停止/清理命令

仅停止 POC 容器和 bridge：

```bash
docker rm -f kestra-poc kestra-poc-postgres
# bridge 是当前 Hermes 后台进程 proc_c55472c031d7，可用 process kill 或 pkill 精确脚本停止
```

彻底清理 POC 数据：

```bash
docker volume rm kestra-poc-data kestra-poc-postgres-data
docker network rm kestra-poc-net
```

## 下一步建议

1. 如果只做验证，可以停止临时 POC，保留报告和 flow 文件。
2. 如果要继续试 UI，可临时保留 `127.0.0.1:18080`。
3. 如果要上 NAS 常驻，不建议直接迁移这个临时配置；应新建正式部署方案，重点确认：
   - 镜像来源；
   - NAS Docker 管理方式；
   - PostgreSQL 数据卷位置；
   - UI 访问控制；
   - bridge/API 安全认证；
   - 日志脱敏和保留周期；
   - Bot1/Bot2/OpenClaw 调用凭据边界。