# 在线客服系统可行性 / 优化报告

> 日期：2026-04-24  
> 核验口径：本地方案文档 + 原型 + 任务计划 + 线上服务器只读核验 + Cloudflare 资源只读清点  
> 范围：`customer-service-plan.html`、`prototype.html`、`customer-service-tasks.md`、`项目文档.md`、`analytics-grafana.md`、`logpush-setup.md`、线上 OpenClaw 服务器、Cloudflare 账号资源  
> 安全说明：本报告不展示服务器密码、Cloudflare API Token、OpenClaw Gateway Token、业务 API Token 等明文密钥。凡已出现在本地文档或线上配置中的真实密钥，均按已暴露处理。

## 1. 执行摘要

在线客服系统 v3.0 的技术方向是可行的：以 **per-biz OpenClaw workspace** 承担客服 Agent、RAG、审批、工作流和渠道能力，以 **Cloudflare** 承担前端托管、边缘鉴权、WebSocket 转发、管理台 CRUD、对象存储、监控和日志。这一架构比 v2.0 的 Cloudflare 重业务后端更适合客服业务的频繁运营迭代，也更容易做到不同业务语料隔离。

但结合线上服务器和 Cloudflare 实际状态后，结论必须调整为：**方案可行，但当前不具备直接生产灰度条件；必须先完成 P0 安全与资源补齐。**

核心判断：

| 维度 | 评分 | 结论 |
|---|---:|---|
| 架构可行性 | 8/10 | per-biz workspace + 薄 Cloudflare edge 边界清晰，适合多业务客服 |
| 原型完整度 | 7.5/10 | 覆盖 Widget、坐席台、管理后台、训练闭环；缺移动端、异常态、权限态和空状态 |
| 线上服务器承载力 | 8/10 | 32 vCPU、31 GiB 内存、174 GB 可用磁盘，足够支撑 MVP 与首批灰度 |
| 线上架构匹配度 | 4.5/10 | 当前 OpenClaw 已运行，但目录、端口、暴露方式与 v3.0 设计不一致 |
| Cloudflare 资源就绪度 | 3/10 | 未发现客服专用 D1/R2/Workers/Pages/Tunnel/Access/Turnstile 资源 |
| 安全合规成熟度 | 4/10 | 文档有明文凭据，OpenClaw Control UI 设备认证被禁用，尚未接 Access/Tunnel |
| 交付可控性 | 6.5/10 | W1-W5 计划合理，但 P0 阻塞不解决会直接影响端到端验收 |

建议结论：**条件通过，可以进入 P0 整改；暂不建议直接生产灰度。**

## 2. 关键线上核验结论

### 2.1 服务器资源

线上 OpenClaw 服务器核验结果：

| 项 | 实际值 |
|---|---|
| 主机 | `69.30.251.10` / `s288851.wholesaleinternet.net` |
| 系统 | Ubuntu 24.04.1 LTS / Linux 6.8.0-41-generic |
| CPU | 32 vCPU，Intel Xeon E5-2670 0 @ 2.60GHz |
| 内存 | 31 GiB，总体可用约 27 GiB |
| Swap | 8 GiB，当前未使用 |
| 磁盘 | 根分区 219 GB，已用 35 GB，可用约 174 GB，使用率 17% |
| 负载 | 约 0.44 / 0.62 / 0.80，资源余量充足 |
| Uptime | 约 17 天 |

判断：服务器硬件容量足够支撑首个客服业务、少量坐席、Web Widget 灰度和 OpenClaw Gateway 运行。短期瓶颈不会是 CPU / 内存 / 磁盘，而是 **OpenClaw Gateway 稳定性、LLM provider、WebSocket 并发、工作区治理和安全暴露面**。

### 2.2 OpenClaw 实际部署

当前线上存在两个 OpenClaw Gateway：

| 服务 | 状态 | 用户 | 端口 | 说明 |
|---|---|---|---|---|
| `yitongkan-openclaw-gateway.service` | active running | `yitongkan` | `19189` / `19191` | 一同看 OpenClaw，OpenClaw `2026.4.22` |
| `zhuavision-openclaw-gateway.service` | active running | `customer` | `18789` / `18791` | 另一套 zhuavision OpenClaw |

重要偏差：

- 方案文档默认 OpenClaw Gateway 为 `127.0.0.1:18789`，但线上 **一同看实际是 `19189`**；`18789` 当前被 zhuavision 使用。
- 方案文档目标目录是 `/opt/openclaw/workspaces/{biz}/`，但线上该目录 **不存在**。
- 线上一同看 OpenClaw 主目录是 `/opt/yitongkan-company/`，systemd 工作目录是 `/opt/yitongkan-company/workspace`。
- 当前一同看 Agent 实际位于 `/home/yitongkan/.openclaw/company-agents/*`，不是 v3.0 设计中的 per-biz `/opt/openclaw/workspaces/{biz}/`。
- `customer` 用户下 `/usr/bin/openclaw` 是 `2026.4.12`，且提示配置由更新版本写入；`yitongkan` 用户下 OpenClaw 是 `2026.4.22`。存在 CLI 版本和用户环境漂移。

判断：线上已有可用 OpenClaw 基础，但还不是 v3.0 方案需要的标准 workspace 编排形态。实施前必须统一 **用户、版本、目录、端口、workspace 生命周期**。

### 2.3 当前 OpenClaw 健康与安全

`openclaw --profile yitongkan status` 显示：

- Gateway reachable，`ws://127.0.0.1:19189`，auth token 模式。
- OpenClaw `2026.4.22`，更新状态为 up to date。
- 已配置 13 个 agents，包括 `customer-service`、`finance-reconciliation`、`risk-control` 等。
- `customer-service` 有活跃 session，模型为 `gpt-5.4`。
- Security audit 报告：**1 critical、1 warn、1 info**。
- Critical 项：`gateway.controlUi.dangerouslyDisableDeviceAuth=true`。
- Channels 列表为空，尚未看到 Telegram / WhatsApp / Discord 等客服 channel 接入。

日志侧还看到：

- `customer-service` 当前处于 **human-assist safe mode**，输出 YAML 草稿给人工审核，不直接发送。
- 退款 / 写操作请求会被标为 `risk_level: high`、`need_human_review: true`，这是正确的安全基线。
- 曾出现 `Proxy headers detected from untrusted address`，需要复核 `trustedProxies` 与 Nginx / Tunnel 转发头。
- 曾出现 `sqlite-vec unavailable` 导致部分 memory 文件未写入向量索引；当前 status 显示 memory vector ready，但建议做一次 reindex 与检索验收。
- 2026-04-24 04:54-05:43 UTC 期间 `yitongkan-openclaw-gateway.service` 有多次 restart / stop / start 记录，其中一次 `status=1/FAILURE` 后重启成功。

判断：OpenClaw 已能跑客服安全草稿，但还未达到“生产客服系统”的完整状态：缺 channel、缺 per-biz workspace 标准化、缺 Access/Tunnel 隔离、存在设备认证关闭和近期重启波动。

### 2.4 Nginx / 暴露方式

当前线上没有 `cloudflared` 命令，也没有 `/etc/cloudflared/config.yml`。Cloudflare API 清点也显示 Tunnel 数量为 0。

当前暴露方式是 Nginx：

- `openclaw.1.gay` 代理到 `127.0.0.1:19189`。
- `openclaw-yitongkan.yitongcs.com` 当前跳转到 `https://openclaw.1.gay`。
- 历史备份配置中曾直接把 `openclaw-yitongkan.yitongcs.com` 代理到 `127.0.0.1:19189`。

判断：这与 v3.0 设计的 `{biz}-cs.int.yitongcs.com` per-biz Tunnel + Service Token 不一致。当前 Control UI 暴露在公网域名上，且设备认证被禁用，必须优先收口。

### 2.5 Cloudflare 资源清点

Cloudflare 账号只读清点结果：

| 资源类型 | 实际情况 | 与客服方案差距 |
|---|---|---|
| D1 | 38 个数据库，含 `ytk`、`ytk-favorites`、`ytk-history-*`、`tong-*` 等 | 未发现 `ytk-cs-db` |
| R2 | 12 个 bucket，含 `ytk-logs`、`ytk-archive`、`ytk-user-assets` | 未发现 `cs-assets` |
| Workers | 49 个脚本，含 `ytk-api`、`tong-*`、`ai-guard` | 未发现 `cs-api`、`cs-widget` 相关 Worker |
| Pages | 10 个项目，含 `ytk` | 未发现 `cs-widget`、`cs-console` |
| Cloudflare Tunnel | 0 | 未创建 per-biz OpenClaw Tunnel |
| Access Apps | 0 | 坐席台 / 管理台尚无 Access 保护 |
| Turnstile Widgets | 0 | Widget 防刷资源未创建 |
| Queues | 25 | 现有主站资源丰富，但 v3.0 客服方案原则上不依赖 Queues |

补充异常：`/user/tokens/verify` 返回 `Invalid API Token`，但多个账号资源 endpoint 可正常读取。无论原因是 token 类型、权限范围还是 Cloudflare API 行为差异，均建议创建新的最小权限运维 Token，并轮换当前文档中的 Token。

判断：Cloudflare 生产经验和账号能力存在，但客服系统专用资源尚未落地。W1 前必须先建资源并写入 IaC / `wrangler.toml` / runbook。

## 3. 方案研判

### 3.1 架构选择

v3.0 把业务决策、RAG、升级判断、审批和多渠道处理下沉到 OpenClaw，Cloudflare 只做薄边缘壳。这个方向合理，原因如下：

- 客服话术、退款规则、投诉升级、FAQ 命中经常变化，文本化规则 + workflow 比 Worker 硬编码更便于运营迭代。
- 多业务之间语料差异大，per-biz workspace 能降低 Memory 污染和 few-shot 混用风险。
- OpenClaw 原生提供 Agents、Memory、Sessions、Approvals、Channels，能减少自研状态机和审批流。
- Cloudflare 侧已有一同看生产经验，D1/R2/DO/Pages/Workers/AE/Logpush 能复用。
- 后续某个业务量变大时，可以单独迁移该业务 workspace 或 Gateway，理论上不影响其他业务。

主要代价：

- OpenClaw 成为关键控制面，必须有 systemd、备份、恢复演练、健康检查、版本回滚。
- 工作区从“代码部署”变成“规则/文档/工具集部署”，CI 必须覆盖 `SOUL.md`、skills、workflow、integration。
- 多 workspace 会引入版本治理、权限治理、训练数据治理和成本配额管理。
- 当前线上 OpenClaw 的实际形态是 company-agents，不是 v3.0 的 `/opt/openclaw/workspaces/{biz}`，需要迁移设计或修订方案。

### 3.2 组件合理性

| 组件 | 方案评价 | 线上/实现注意 |
|---|---|---|
| `cs-widget` | Web Component + Shadow DOM 合理，适合嵌入主站、H5 和 BizN | 首版需限制 gzip 包体，补断线重连、上传进度、移动端键盘适配 |
| `cs-api` Worker | 做鉴权、biz 路由、短 token、上传签名、管理接口，边界合理 | 当前未创建；不应承载业务判断；所有写操作写审计 |
| `BridgeDO` | 薄 WS 转发适合 Durable Object | 需验证 WS hibernation、断线续接、OpenClaw 超时降级 |
| `AgentPresenceDO` | 坐席在线、抢单、并发上限需要 per-biz 原子一致性 | 需 100 并发 claim 压测，断线 90 秒下线 |
| D1 `ytk-cs-db` | 管理台 CRUD、训练标注、审计、workspace 元数据适合 D1 | 当前未创建；建议把 `cs_workflow_runs` 纳入正式表设计 |
| R2 `cs-assets` | 附件、训练导出、备份、日志归档适合 R2 | 当前未创建；需 lifecycle、MIME 白名单、内容扫描预留 |
| OpenClaw workspace | 方案核心 | 当前线上不是目标目录模型；必须模板化、git 化、测试化 |
| Cloudflare Access | 坐席和管理台必须接入 | 当前 Access Apps 为 0，属于上线阻塞 |
| Cloudflare Tunnel | OpenClaw 不应直接公网暴露 | 当前 Tunnel 为 0，公网 Nginx 暴露需整改 |

### 3.3 数据模型修订建议

方案文档写 D1 “5 张表”：`cs_workspaces`、`cs_knowledge`、`cs_agents`、`cs_training_samples`、`cs_audit_log`。

任务计划又要求 `cs_workflow_runs` 记录 workflow 完成状态、ticket_id、api_calls、漏斗统计。建议正式口径改成 **6 张核心表**：

1. `cs_workspaces`：biz 元数据、stage、tunnel_host、workspace_path、provider、health。
2. `cs_knowledge`：FAQ 草稿、发布态、同步态。
3. `cs_agents`：坐席、角色、biz_scope、并发上限。
4. `cs_training_samples`：采用/改写/重写、差评、人工复核结果。
5. `cs_workflow_runs`：flow_id、status、step timings、ticket_id、api_calls、failure_reason。
6. `cs_audit_log`：管理台和敏感操作审计。

同时建议 `cs_workspaces` 增加：

- `health_status`
- `last_health_at`
- `degraded_reason`
- `gateway_port`
- `workspace_git_remote`
- `backup_last_at`
- `token_expires_at`

这样管理后台的系统健康页才能展示真实运维状态，而不是静态配置。

## 4. 原型评审

### 4.1 已覆盖能力

`prototype.html` 覆盖面较完整，适合作为需求确认和阶段验收基准：

- 用户 Widget：`ytk` / `bizdemo` 两个 workspace 浮窗，AI 对话，Skill 调用痕迹，升级 Approvals，人工接入，退款 workflow，Telegram channel。
- 坐席台：三栏布局、approvals 队列、跨 biz tab、会话上下文、AI 草稿、采用 / 改写 / 重写、Memory 搜索。
- 管理后台：Workspace 列表与详情、SOUL 编辑、Workflows、Integrations、Channels、Memory、指标、阶段切换、知识库、训练语料、对话审计、坐席管理、系统健康、审计日志。
- 运维视图：Tunnel 状态、OpenClaw 延迟、D1 写量、审计日志、workspace 同步。

### 4.2 原型缺口

| 缺口 | 影响 | 建议 |
|---|---|---|
| 移动端不足 | Widget 大概率大量来自 H5 / Android WebView | 补 360 / 390 / 430 px 三档，验证键盘、附件、长文本和安全区 |
| 异常态不足 | 真实客服高频遇到超时、断线、无坐席、审批失败 | 增加 OpenClaw 超时、Tunnel 断开、Access 过期、上传失败、工单失败 |
| 空状态不足 | 新 biz 初期 FAQ、训练样本、坐席队列都可能为空 | 增加空知识库、空队列、首次配置、无权限视图 |
| 权限态不足 | Trainer、坐席、主管、admin 可见菜单不同 | 原型需展示不同角色菜单、禁用按钮、Step-Up 弹窗 |
| SLA / 排队策略不细 | 只展示等待时间，不足以指导实现 | 增加 VIP、投诉、超时升级、坐席并发上限、队列优先级 |
| 状态可解释性不足 | 坐席需要知道 AI 为什么这么答 | 在 AI 草稿旁展示命中 FAQ、调用工具、风险规则、置信度、是否脱敏 |
| 视觉实现风险 | 原型大量 emoji，正式 UI 跨系统显示不稳定 | 正式产品用图标库替代，减少 emoji 作为关键状态标识 |

### 4.3 原型到工程的落地建议

- Widget 首版只做三件事：建会话、发消息、接收 AI/人工消息；附件和评价作为 W4 后交付。
- 坐席台首版围绕 Approvals 队列，不先做大而全 CRM。
- 管理台首版先做 Workspace 健康、FAQ CRUD、SOUL 只读/编辑、审计；workflow DAG 可后置到 W4。
- 系统健康页必须读取真实 Cloudflare / OpenClaw / systemd / R2 备份状态，不做静态演示数据。

## 5. 主要风险

### 5.1 P0 阻塞风险

| 风险 | 等级 | 证据 | 影响 | 处理建议 |
|---|---|---|---|---|
| 明文凭据出现在本地资料 | P0 | `配置.md` 含服务器密码和 Cloudflare Token，`analytics-grafana.md` 含 Cloudflare Bearer Token | 凭据可被误传、日志化、提交 | 立即轮换；文档改模板；真实值迁入密码管理器 |
| Control UI 设备认证关闭 | P0 | OpenClaw audit 报 `dangerouslyDisableDeviceAuth=true` critical | 公网域名暴露时风险极高 | 关闭该开关；用 Access/Tunnel/Service Token 收口 |
| Cloudflare Access / Tunnel 未创建 | P0 | API 清点 Access Apps=0、Tunnels=0 | 坐席台无法安全上线，OpenClaw 无内网保护 | W1 前创建 Access app 和 per-biz Tunnel |
| 客服专用 CF 资源缺失 | P0 | 未发现 `ytk-cs-db`、`cs-assets`、`cs-api`、`cs-widget`、`cs-console` | 方案无法端到端落地 | 建资源并用 IaC 固化 |
| Gateway 端口口径冲突 | P0 | 文档写 `18789`，线上 ytk 为 `19189`，`18789` 是 zhuavision | Worker / Tunnel 可能打错业务 | 明确 ytk 端口或迁移端口，禁止沿用错误默认 |
| workspace 目录模型不一致 | P0 | `/opt/openclaw/workspaces` 不存在 | per-biz 隔离无法按文档实施 | 决定迁移到目标目录，或修订方案以 company-agents 为基准 |

### 5.2 P1 工程风险

| 风险 | 等级 | 说明 | 建议 |
|---|---|---|---|
| OpenClaw 重启波动 | P1 | 2026-04-24 有多次 restart 和一次 failure 后恢复 | 加健康探针、异常日志采集、restart 告警 |
| `customer` / `yitongkan` 版本漂移 | P1 | `customer` 为 2026.4.12，`yitongkan` 为 2026.4.22 | 统一运维账号和 PATH，避免误用旧 CLI |
| `workspaces` 命令不可用 | P1 | 旧 CLI 报 `plugins.allow excludes "workspaces"`，新 CLI 使用 `agents` 命令体系 | 任务计划命令需更新为实际 OpenClaw CLI |
| Memory 向量索引曾降级 | P1 | 日志出现 `sqlite-vec unavailable` | 做 `memory reindex`，补检索验收 |
| 业务 API 工具在 Agent 侧 | P1 | 当前已有 `query_ai_robot_api.py` 等工具 | 必须保证只读、脱敏、白名单 endpoint、超时和审计 |
| Nginx 代理头信任不一致 | P1 | 日志出现 untrusted proxy header | 复核 `trustedProxies`、`X-Forwarded-*`、Access/Tunnel 后的真实源 |

### 5.3 P2 产品风险

| 风险 | 等级 | 说明 | 建议 |
|---|---|---|---|
| 用户等待时流失 | P2 | 人工排队期间若无反馈，容易关闭 Widget | 允许用户继续补充信息，展示排队状态和预计等待 |
| 训练闭环无质量门 | P2 | SOUL/FAQ 变更若无测试会引入隐蔽错误 | `tests/soul.test.yaml` + golden conversations + 回滚 |
| 成本不可见 | P2 | LLM 成本是最大变量 | per-biz token、provider、单会话成本统计 |
| 多业务权限串线 | P2 | 坐席跨 biz tab 容易上下文污染 | Worker、DO、OpenClaw 三层都校验 biz_scope |

## 6. 优化建议

### 6.1 线上架构整改

1. 建立客服系统目标目录：
   - `/opt/openclaw/workspaces/_template`
   - `/opt/openclaw/workspaces/ytk`
   - `/opt/openclaw/workspaces/bizdemo`

2. 明确端口策略：
   - 保留现状：ytk 使用 `19189`，zhuavision 使用 `18789`，所有文档和 Worker 配置同步修正。
   - 或迁移策略：将 ytk 迁到 `18789` 前，必须先迁走 zhuavision，避免误连。

3. 把当前 `customer-service` safe mode 沉淀为 `ytk` workspace 初始规则：
   - 退款、写操作、封禁/解封、补偿承诺必须 `need_human_review=true`。
   - 工具调用必须只读、脱敏、超时、记录来源。
   - 回复草稿必须包含风险等级和 handoff note。

4. 关闭 `dangerouslyDisableDeviceAuth`：
   - 只允许短期 break-glass。
   - 生产 Control UI 必须经 Cloudflare Access。
   - OpenClaw Gateway 对外只通过 Tunnel 或内网反代暴露。

5. 建立恢复演练：
   - OpenClaw workspace 每日快照。
   - D1 每日 export。
   - R2 lifecycle 30 天。
   - 每周抽样恢复一次 `_template` 或 `ytk` workspace。

### 6.2 Cloudflare 资源补齐

P0 需要创建并纳入 `wrangler` / runbook：

| 资源 | 建议名称 | 目的 |
|---|---|---|
| Worker | `cs-api` | 鉴权、路由、短 token、上传签名、管理 API |
| Pages | `cs-widget` | 嵌入式客服 Widget |
| Pages | `cs-console` | 坐席台 + 管理后台 |
| D1 | `ytk-cs-db` | workspace、FAQ、坐席、训练、workflow、审计 |
| R2 | `cs-assets` | 附件、训练导出、备份、日志 |
| KV | `cs-runtime` | 短期 token、坐席快照、轻量临时态 |
| Durable Objects | `BridgeDO`、`AgentPresenceDO` | WS 转发、坐席在线与抢单 |
| Access App | `cs-console` | 坐席 / 管理员 SSO + TOTP + Step-Up |
| Tunnel | `openclaw-cs` 或 per-biz ingress | `{biz}-cs.int.yitongcs.com` 到 OpenClaw |
| Turnstile | `cs-widget` | 首次建会话防刷 |
| AE dataset | `cs_metrics` | per-biz 指标 |
| Logpush | Workers logs → `cs-assets/logs/` | 排障和合规留存 |

### 6.3 安全治理

- 立即轮换本地文档中的服务器密码、Cloudflare Token、OpenClaw Gateway Token、业务 API Token。
- `配置.md` 改成脱敏模板，只保留变量名、用途、权限范围、轮换位置。
- Cloudflare Token 拆分为最小权限：
  - `cf-read-inventory`
  - `cf-deploy-workers`
  - `cf-d1-r2-admin`
  - `cf-access-tunnel-admin`
- SOUL 修改、密钥变更、阶段切换、导出训练集、删会话必须 Access Step-Up + 双签。
- Integration endpoint 做白名单，禁止 Agent 任意 URL 调用。
- 工具返回给 LLM 前先脱敏，训练样本进入 D1 前二次脱敏。
- 附件上传加 MIME 白名单、10 MB 上限、扩展名规范、病毒/内容扫描预留。

### 6.4 可观测性

建议从 W1 起采集：

| 指标 | 标签 | 告警 |
|---|---|---|
| `cs_openclaw_latency_p95` | biz / workspace | > 5s 持续 3 分钟 |
| `cs_openclaw_error_rate` | biz / provider | > 5% 持续 5 分钟 |
| `cs_ws_disconnect_rate` | biz | 异常升高 |
| `cs_approval_queue_depth` | biz / priority | 超过坐席容量 |
| `cs_bad_rating_rate_1h` | biz | > 10% |
| `cs_llm_cost_daily` | biz / provider | > 预算 80% |
| `cs_tunnel_status` | biz | disconnected |
| `cs_backup_last_success_at` | d1 / workspace | 超过 24h |
| `cs_memory_reindex_status` | biz | failed / stale |

系统健康页必须展示真实状态：

- OpenClaw Gateway `/health`。
- systemd active / restart count。
- Tunnel connected。
- Access app enabled。
- D1 schema version。
- R2 backup last object。
- 当前 provider 与 fallback 状态。

### 6.5 工程实现

- `OpenClawClient` 统一封装：timeout、retry、circuit breaker、request id、PII redact、错误分类。
- `BridgeDO` 不存业务状态，只记录连接诊断事件到 AE。
- 所有 D1 查询强制 `biz=?`，测试中加入故意串 biz 用例。
- workflow runtime 先做轻量 runner，不做复杂 DAG 平台。
- `SOUL.md` / workflow / integration 改动必须经过：
  1. diff
  2. 行为测试
  3. git commit
  4. 审计
  5. 可回滚

## 7. 交付计划修订

### P0：上线前阻塞整改

建议 P0 不计入 5 周开发工期。

| 任务 | 验收 |
|---|---|
| 凭据轮换与文档脱敏 | 本地文档不再出现明文密码/Token；旧 Token 全部失效 |
| 关闭 Control UI 危险开关 | `openclaw security audit` 无 critical |
| 统一用户/目录/端口口径 | runbook 写清 `yitongkan`、`19189` 或迁移后的目标端口 |
| 创建 Cloudflare 客服资源 | `ytk-cs-db`、`cs-assets`、`cs-api`、`cs-widget`、`cs-console`、Access、Tunnel、Turnstile 均存在 |
| 建 `_template` 和 `ytk` workspace | 能从模板 fork；有 git；有 SOUL/skills/tests |
| provider / safe mode 验证 | `customer-service` 最小 prompt 成功；退款类请求只出人工草稿 |
| 备份链路 | OpenClaw workspace 和 D1 均能手动备份与恢复 |

### W1-W5：建议顺序

| 周期 | 产出 | 验收 |
|---|---|---|
| W1 | Cloudflare 资源、D1 schema、OpenClaw workspace 模板、Tunnel ingress、Worker 骨架 | Worker 能通过 Tunnel 调 ytk OpenClaw `/health`；D1 6 表就绪 |
| W2 | Widget MVP、BridgeDO、OpenClawClient、Turnstile | Web Widget 真实完成一条 AI 安全草稿对话；断线可恢复 |
| W3 | 坐席台 Approvals、AgentPresenceDO、Access SSO | 坐席采用/改写/重写能写 training_samples；100 并发 claim 仅 1 人成功 |
| W4 | 管理后台、FAQ、SOUL 编辑、workflow/integration 只读与测试 | 修改 FAQ 同步到 workspace；SOUL 改动需测试、审计、回滚 |
| W5 | 监控、告警、备份、熔断、多 biz E2E、安全演练 | 故障注入能告警和降级；故意串 biz 返回 403 |

## 8. Go / No-Go 结论

当前结论：**Go for P0 remediation，No-Go for direct production rollout。**

可以继续推进的理由：

- 服务器资源充足。
- OpenClaw 已部署并可运行一同看客服 safe mode。
- 现有一同看 Cloudflare 生产体系成熟，主站已有 D1/R2/Workers/Pages/AE/Logpush 经验。
- 方案文档与原型覆盖了核心业务闭环。

不能直接上线的理由：

- Cloudflare 客服专用资源未创建。
- Access、Tunnel、Turnstile 均未就绪。
- OpenClaw Control UI 设备认证关闭，且当前通过公网 Nginx 暴露。
- 目标 workspace 目录模型未落地。
- 文档含明文凭据，必须轮换。
- 端口和服务口径与文档冲突。

满足以下 Go 条件后，可进入 10% 灰度：

1. `openclaw --profile yitongkan security audit` 无 critical。
2. `ytk-cs-db` D1 6 表已部署，schema version 可查。
3. `cs-assets` R2 lifecycle 已配置。
4. `cs-console` 通过 Cloudflare Access + TOTP 访问。
5. `{biz}-cs.int.yitongcs.com` Tunnel + Service Token 可用。
6. Widget → Worker → BridgeDO → OpenClaw → Approvals → 坐席台端到端跑通。
7. 退款 / 账号 / 支付 / 解封等高风险请求只产生人工审核草稿。
8. D1 和 workspace 备份连续 3 天成功，至少一次恢复演练通过。
9. 多 biz 串线测试返回 403。

## 9. 证据来源

本地资料：

- `docs/customer-service-plan.html`：v3.0 架构、数据模型、工作流、安全、监控、风险。
- `docs/prototype.html`：用户 Widget、坐席台、管理后台原型。
- `docs/customer-service-tasks.md`：P0/W1-W5 任务与验收。
- `docs/项目文档.md`：现有一同看 Cloudflare 架构、D1/R2/DO/Queues/AE/Logpush 经验。
- `docs/analytics-grafana.md`、`docs/logpush-setup.md`：现有监控和日志归档方案。
- `配置.md`：线上服务器和 Cloudflare 账号信息，报告已脱敏引用。

线上只读核验：

- SSH 只读查看：OS、CPU、内存、磁盘、负载、端口、systemd、Nginx、Docker、OpenClaw CLI/status/logs。
- Cloudflare API 只读清点：D1、R2、Workers、Pages、Tunnel、Access、Turnstile、Queues。

本次未执行：

- 未修改线上服务器文件。
- 未重启线上服务。
- 未创建或删除 Cloudflare 资源。
- 未执行生产数据库写入。
- 未在报告中展示任何明文密钥。