# sgRobot 核心能力融合计划 ## 定位 本计划不是单纯的“前端页面嵌入计划”。 真正目标是： ```text 以 qimingclaw 为客户端底座， 以数字员工页面为主要产品载体， 逐步吸收 sgRobot 的核心任务操作系统能力。 ``` 数字员工页面不是一个展示壳，而是后续承载以下能力的主入口： - 今日工作台 - 任务中心 - 技能库 - 执行记录 - 审批与人工介入 - 运行时间线 - 产物与日报 - 计划模板与业务流程 当前 qimingclaw 已经完成一个过渡版本：在“概览”菜单内嵌 sgRobot 数字员工静态页面，不启动 sgRobot 后端也能展示页面。但这只是第一步，后续要把 sgRobot 的核心模型和执行治理能力融合进 qimingclaw。 ## 总体原则 ### 1. qimingclaw 是底座 保留 qimingclaw 当前已有优势： - Electron 客户端 - 登录与注册链路 - lanproxy 远程接入 - `/computer/chat` 本地执行入口 - ACP 引擎 - MCP 工具接入 - 本地 SQLite 配置与状态存储 不把 sgRobot Rust daemon 原样搬进来，不让 qimingclaw 启动依赖 sgRobot 进程。 ### 2. 数字员工页面是产品载体 sgRobot 的能力不是以后台模块裸露给用户，而是通过数字员工页面呈现： - 用户看到的是数字员工的任务、状态、汇报和介入点。 - 后台融合的是 Plan / Task / Run / Skill / Event / Artifact / Approval。 - 页面最终从 demo fallback 过渡到 qimingclaw 真实数据。 ### 3. 源码融合，运行隔离 数字员工前端采用源码级融合，而不是长期维护 `dist` 快照。 但第一阶段仍保持独立构建，不直接混入 qimingclaw 主 renderer bundle，避免： - React 18 / React 19 冲突 - Tailwind / Ant Design 样式污染 - 路由体系互相影响 推荐方式： ```text 源码融合 -> 独立构建 -> 输出静态资源 -> qimingclaw webview 加载 -> 后续通过 qimingclaw API 接真实数据 ``` ## 目标架构 最终目标链路： ```text 用户目标 / 后端远程任务 / 定时任务 -> Plan 或 Direct Task -> Task -> Run -> qimingclaw ACP / MCP 执行 -> Event / Artifact / Approval -> Projection -> 数字员工页面展示与人工介入 ``` 核心对象： ```text Plan PlanStep Task Run Skill Event Artifact Approval MemoryEntry ManagedService ``` 第一轮不要求一次性实现全部对象，但数据库和 API 设计要为这些对象预留边界。 ## 当前状态 已完成的过渡实现： ```text crates/agent-electron-client/public/sgrobot-digital/ crates/agent-electron-client/src/renderer/components/pages/OverviewPage.tsx ``` 早期链路： ```text qimingclaw 左侧菜单“概览” -> OverviewPage -> Electron webview -> sgrobot-digital/index.html#/digital -> sgRobot 数字员工静态页面 -> demo fallback 数据 ``` 早期问题： - 数字员工前端还是构建产物快照。 - 页面数据主要来自 sgRobot demo fallback。 - qimingclaw 没有 Plan / Task / Run / Event / Artifact 的正式状态模型。 - qimingclaw 的 ACP 执行链路尚未映射到数字员工任务中心。 - Skill、Approval、日报、执行时间线还不是 qimingclaw 真实能力。 ## 分阶段融合计划 ## Phase 1：数字员工前端源码融合（已开始） 目标：把现在的静态快照变成可维护源码集成。 ### 做法 在 qimingclaw 中新增独立 embedded 前端源码目录： ```text crates/agent-electron-client/ embedded/ sgrobot-digital/ package.json vite.config.ts tsconfig.json src/ pages/digital/ components/digital/ contexts/ lib/ types/ index.css main.tsx public/ digital-assets/ logo.png patches/ README.md public/ sgrobot-digital/ ``` 新增脚本： ```text scripts/sync-sgrobot-digital.js scripts/build-sgrobot-digital.js ``` 当前 qimingclaw 已新增： ```text crates/agent-electron-client/embedded/sgrobot-digital/ crates/agent-electron-client/scripts/sync-sgrobot-digital.js crates/agent-electron-client/scripts/build-sgrobot-digital.js ``` 常用命令： ```bash cd crates/agent-electron-client npm run sync:sgrobot-digital npm --prefix embedded/sgrobot-digital install npm run build:sgrobot-digital npm run build:renderer ``` 其中： - `sync:sgrobot-digital` 从 sgRobot 的 web 源码同步数字员工相关源码和资源。 - `build:sgrobot-digital` 从 qimingclaw 内的 embedded 源码构建到 `public/sgrobot-digital`。 - `build:renderer` 验证 qimingclaw 主客户端构建。 同步范围优先包含： ```text sgRobot/crates/sgclaw-core/web/src/pages/digital/ sgRobot/crates/sgclaw-core/web/src/components/digital/ sgRobot/crates/sgclaw-core/web/src/contexts/RoleContext.tsx sgRobot/crates/sgclaw-core/web/src/lib/api.ts sgRobot/crates/sgclaw-core/web/src/lib/basePath.ts sgRobot/crates/sgclaw-core/web/src/lib/i18n.ts sgRobot/crates/sgclaw-core/web/src/lib/tauri.ts sgRobot/crates/sgclaw-core/web/src/types/api.ts sgRobot/crates/sgclaw-core/web/src/index.css sgRobot/crates/sgclaw-core/web/public/digital-assets/ ``` qimingclaw 专用 patch： - 直达 `#/digital` - 禁用 sgRobot 配对页 - 静态资源使用相对 base path，兼容 Vite dev server 和 Electron `file://` 打包态 - API 早期允许 fallback 到 demo 数据；当前任务中心和技能库已切换为真实空态 / 错误态 - 关闭 sgRobot 独立窗口行为，交给 qimingclaw 容器处理 当前边界： - 前端已从“纯构建产物快照”推进为“源码同步 + 独立构建 + 静态嵌入”。 - 数字员工页面已接入 qimingclaw bridge/API adapter，不再让 demo mission/skill 冒充真实记录。 - qimingclaw 已落地 Plan / Task / Run / Event / Artifact / Approval 本地模型和 outbox。 - 下一阶段应开始建设 qimingclaw 本地数字员工 API 适配层。 ## Phase 2：qimingclaw 数字员工 API Adapter（已开始） 目标：让数字员工页面开始消费 qimingclaw 语义的数据，而不是完全依赖 sgRobot demo fallback。 当前 qimingclaw 已新增： ```text crates/agent-electron-client/embedded/sgrobot-digital/src/lib/qimingclawAdapter.ts ``` 当前覆盖的页面接口： ```text GET /api/digital-employee/workday POST /api/digital-employee/workday/actions GET /api/scheduler/jobs GET /api/debug/plans GET /api/debug/tasks GET /api/debug/plan/:planId/flow POST /api/debug/plan/:planId/dispatch GET /api/plan/:planId/messages GET /api/skill POST /api/skill/:skillId/enabled ``` 当前数据来源： - qimingclaw adapter 内置的客户端任务职责。 - 主进程 SQLite settings 保存的今日任务选择、角色偏好、运营偏好和日报生成状态；webview `localStorage` 仅保留为非 Electron 环境兜底和旧 key 迁移来源。 - qimingclaw 语义的 ACP / MCP / computer server / artifact-report 技能定义。 当前页面表现： - `source` 返回 `live`，数字员工首页会使用真实 adapter 数据通道。 - 今日任务从“白领一天 demo”切换为 qimingclaw 客户端职责。 - 任务中心、技能库、运行明细、日报预览开始使用 qimingclaw adapter 数据。 下一步： - 将 adapter 的静态职责替换为 qimingclaw 主进程 IPC 数据源。 - 新增本地数字员工状态服务，持久化 Plan / Task / Run / Event / Artifact / Approval。 - 把 `/computer/chat`、ACP session、MCP tool status 写入 Run/Event。 ## Phase 3：webview 只读状态桥（已开始） 目标：让 embedded 数字员工页能读取 qimingclaw 客户端真实状态，同时保持 webview 权限收敛。 当前 qimingclaw 已扩展： ```text crates/agent-electron-client/src/preload/webviewPerfBridge.ts crates/agent-electron-client/src/main/main.ts ``` 桥接对象： ```text window.QimingClawBridge.digital.getSnapshot() ``` 当前 snapshot 内容： - Agent service status - MCP proxy status - Computer Server status - Lanproxy status - File Server status - GUI Server status - ACP detailed sessions summary 安全边界： - 只读。 - 不暴露 start / stop / restart。 - 不暴露 prompt / shell / computer chat。 - webview 页面只能拿到状态快照，再由 adapter 映射到数字员工页面。 当前页面表现： - “客户端运行状态巡检”会显示 Agent、MCP、活跃会话数。 - “远程任务接入准备”会显示 Computer Server、Lanproxy、File Server 状态。 - 在非 Electron webview 环境下，adapter 自动降级为“未连接 bridge”的 fallback 文案。 下一步： - 新增 qimingclaw digital employee state service。 - 将 bridge snapshot 写入 Run/Event，而不是只作为页面即时 projection。 - 让 `/computer/chat` 请求生成真实 Task / Run / Event。 ## Phase 4：qimingclaw 本地状态服务雏形（已开始） 目标：让数字员工能力不只是页面 projection，而是开始拥有 qimingclaw 自己的本地状态沉淀。 当前 qimingclaw 已新增： ```text crates/agent-electron-client/src/main/services/digitalEmployee/stateService.ts crates/agent-electron-client/src/main/ipc/digitalEmployeeHandlers.ts ``` 新增 IPC： ```text digitalEmployee:getSnapshot digitalEmployee:getState ``` 当前职责： - 主进程统一采集 Agent / MCP / Computer Server / Lanproxy / File Server / GUI Server / Sessions。 - 每次 snapshot 写入 `digital_employee_state_v1`。 - 状态服务生成轻量事件 `service_snapshot`。 - webview bridge 改为调用 `digitalEmployee:getSnapshot`，不再自行聚合多个 IPC。 当前边界： - 状态服务仍保留 settings JSON 作为兼容快照。 - Plan / Task / Run / Event 已开始写入独立 SQLite 表。 - 当前事件主要记录服务状态变化，还没有接入 `/computer/chat` 和 ACP token/event stream。 下一步： - 新建正式 SQLite 表：`digital_plans`、`digital_tasks`、`digital_runs`、`digital_events`、`digital_artifacts`、`digital_approvals`。 - 在 computer server 的 `/computer/chat` 入口创建 Task / Run。 - 在 ACP event forwarder 中写入 Run/Event。 ## Phase 5：管理端任务入口落地（已开始） 目标：管理端或后端通过 `/computer/chat` 下发任务时，qimingclaw 本地数字员工状态可以生成真实任务记录。 当前 qimingclaw 已接入： ```text crates/agent-electron-client/src/main/services/computerServer.ts crates/agent-electron-client/src/main/ipc/computerHandlers.ts crates/agent-electron-client/src/main/services/digitalEmployee/stateService.ts ``` 记录时点： - 收到 chat 请求：创建/更新 Plan、Task、Run，写入 `computer_chat_received`。 - chat 成功返回：Run 标记 completed，写入 `computer_chat_completed`。 - chat 失败返回：Run 标记 failed，写入 `computer_chat_failed`。 当前联动意义： - 管理端任务进入客户端后，本地 SQLite 会立即有可追溯记录。 - 对应 Plan / Task / Run / Event 均进入 `digital_sync_outbox`。 - 后续管理端 sync API 确定后，可将 outbox 推送到管理端并回填 `remote_id`。 下一步： - 接 ACP event forwarder，把 token、tool、step、artifact 写入 Run/Event/Artifact。 - 增加 sync worker，根据 `step1_config.serverHost` 和登录 token 推送 outbox。 ## Phase 6：ACP / computer 运行事件落库（已开始） 目标：让数字员工不只知道“管理端下发了任务”，也能看到 qimingclaw 执行过程中的真实运行事件。 当前 qimingclaw 已接入： ```text crates/agent-electron-client/src/main/ipc/eventForwarders.ts crates/agent-electron-client/src/main/services/digitalEmployee/stateService.ts ``` 记录来源： - ACP session SSE 事件：`message.updated`、`session.updated`、`session.status`、`session.idle`、`session.error` 等。 - computer 执行进度：`computer:progress`。 - prompt 生命周期：`computer:promptStart`、`computer:promptEnd`。 - Agent 生命周期：`ready`、`destroyed`、`error`。 当前落库方式： - 运行中的事件会创建/更新对应 Plan、Task、Run。 - 完成和失败事件会结束 Run。 - 每条 Event 都写入 `digital_events`。 - Plan / Task / Run / Event 均进入 `digital_sync_outbox`，等待后续同步到管理端。 与管理端联动的边界： - SQLite 作为本地事实缓存和离线队列，不作为最终中心库。 - 管理端 API 未确定前，qimingclaw 先沉淀统一的本地实体和 outbox。 - 后续 sync worker 只消费 `digital_sync_outbox`，避免业务写入链路直接依赖网络。 下一步： - 确认 qiming-backend 的数字员工同步 API 路径和鉴权方式。 - 将 Artifact / Approval 从普通 Event 中拆成正式实体。 - 数字员工页面展示同步状态：待同步、同步失败、最近同步时间。 ## Phase 7：管理端 outbox 同步 worker（已开始） 目标：SQLite 继续作为本地事实缓存和离线队列，同时把 Plan / Task / Run / Event 推送到管理端，避免数字员工数据停留在单机。 当前 qimingclaw 已新增： ```text crates/agent-electron-client/src/main/services/digitalEmployee/syncService.ts crates/agent-electron-client/src/main/bootstrap/startup.ts crates/agent-electron-client/src/main/ipc/digitalEmployeeHandlers.ts crates/agent-electron-client/src/preload/webviewPerfBridge.ts ``` 当前机制： - 启动后后台启动 sync worker，默认每 30 秒扫描 `digital_sync_outbox`。 - 默认同步地址由 `step1_config.serverHost` 拼接： ```text /api/digital-employee/sync/outbox ``` - 可通过 settings `digital_employee_sync_config.endpoint` 覆盖同步地址。 - 使用 `auth.saved_key` 或域名级 saved key 作为客户端标识。 - 使用管理端登录态 token 作为 `Authorization: Bearer `，同时携带 `X-Qiming-Client-Key`。 - 同步成功后回填 outbox 状态，并根据后端 ack 回填实体 `remote_id` / `last_synced_at`。 - 同步失败时标记 failed 和错误信息；定时 worker 按指数退避补偿，手动 `flushSync` 可强制立即重试，不影响 `/computer/chat` 和 ACP 执行链路。 - 数字员工任务设置工具栏已增加“同步管理端”按钮，可通过 bridge 立即触发 `flushSync` 并刷新页面投影。 - 数字员工首页已增加管理端同步状态条，展示待同步数量、失败数量、可重试/退避分布、失败实体类型分布、最近同步时间和最近失败原因摘要。 - 数字员工嵌入页会通过 `window.QimingClawBridge.digital.getRuntimeRecords()` 读取本地 SQLite 的 `digital_plans`、`digital_plan_steps`、`digital_schedules`、`digital_schedule_runs`、`digital_tasks`、`digital_runs`、`digital_events`、`digital_artifacts`、`digital_approvals`，优先用真实本地记录生成 workday、任务中心、任务详情、调度列表和流程投影；本地记录为空时才回落到 qimingclaw 固定适配任务。 - 数字员工页面的任务确认、资料设置、角色选择、运营偏好、日报状态通过 `getUiState` / `saveUiState` 保存在主进程 SQLite settings；保存时会记录 `digital_workday_*` 本地事件并进入 outbox，避免这些页面操作只留在 webview localStorage。 - 数字员工技能库通过 `getSkillCapabilities` 读取 qimingclaw 当前 MCP 配置、server 状态、已发现工具与 allow/deny 限制，并把 MCP server/tool 投射为 `/api/skill` 技能项；技能策略已拆分为本地偏好 `local_skills` 与管理端治理 `remote_skills`，可通过 `POST /api/skill/policies/pull` 拉取管理端 `GET /api/digital-employee/policies/skills` 下发策略，远端禁用优先生效且拉取失败会保留现有策略并记录 `last_pull_error`。 - 数字员工调试存储、dashboard、flow 和产物列表通过 qimingclaw adapter 的 `/api/debug/store`、`/api/dashboard`、`/api/debug/plan/:id/flow`、`/api/debug/task/:id/flow`、`/api/artifact` 投射本地 Plan / Task / Run / Event / Artifact / Approval；Run/Event payload 中的 `artifacts`、`outputs`、`files`、`outputPath`、`uri` 等字段会作为正式 artifact 记录为空时的兼容产物入口展示。 - qimingclaw 主进程记录 `/computer/chat` 结果和 runtime event 时，会从 payload 的 `artifacts`、`outputs`、`files`、`attachments`、`outputPath`、`uri` 以及 `approvals`、`approval_requests`、`needApproval` 等字段轻量提取正式 `digital_artifacts` / `digital_approvals` 记录，并进入 outbox 同步。 - `digital_approvals` 会投射为数字员工 workday 的 `decisions`；首页待解决事项按钮会调用本地 `decide_approval` action，把处理结果写入 SQLite UI state，回写正式 approval 状态并进入 approval outbox，同时生成 `approval_decision` / `digital_workday_decide_approval` runtime event。approval payload 已支持 `workflow`、`steps`、`current_step_id`、`participants` 和 `decision_history`，旧单步审批会自动规范化为单步 workflow；多步审批未完成时保持 `pending`，全部通过才进入 `approved`，任一步拒绝进入 `rejected`。同步失败 review 只保留在 dashboard/同步诊断中，不作为可审批 workday decision。 - 审批跨端更新与回写已开始闭环：客户端可通过 `POST /api/approval/updates/pull` 拉取管理端 `GET /api/digital-employee/approvals/updates` 审批更新，也会在本地处理审批后通过 `POST /api/digital-employee/approvals/decisions` 尝试回写管理端；远端异常会写入 `digital_workday_approval_*` 事件，不阻断本地审批状态推进；若管理端终态、本地较新状态或多步 current step 与本地事实冲突，客户端会保留本地审批状态，把远端快照写入 approval payload `conflict`，生成 `approval_conflict_detected` event，并在首页审批卡展示“跨端冲突/冲突保护”。 - 通知跨端未读同步已开始闭环：客户端可通过 Bell 弹层的同步按钮或 embedded `POST /api/notifications/updates/pull` 拉取管理端 `GET /api/digital-employee/notifications/updates`，把 read/dismiss/reply overlay 合并进本地 `notificationStateById`；本地 read/dismiss/reply 后会尽力回写 `POST /api/digital-employee/notifications/actions`，回写失败只记录 `digital_workday_notification_*` 事件，不回滚本地 Inbox 状态；未读且重要的 Inbox 通知可通过受控 Electron `Notification` 弹出系统级桌面提醒，并用本地去重 key 避免重复打扰；系统权限引导 UI 已开始吸收，embedded 可通过 `GET /api/notifications/desktop/status` 查询桌面通知可用性，通过 `POST /api/notifications/desktop/settings/open` 打开系统通知设置，并在 Bell 设置面板提供测试桌面通知、失败原因和修复入口。 - 高风险动作审批策略已沉淀到 UI state 的 `riskApprovalPolicy`，可通过 `POST /api/risk-approval/policy/pull` 拉取管理端 `GET /api/digital-employee/policies/risk-approval` 下发策略；受控的服务重启、产物访问/保留、审批动作、治理命令和 ready PlanStep 派发前会先评估风险策略，命中审批会写入 `risk_approval_required` approval/event，命中拒绝会写入 `risk_policy_rejected` event，管理端同步业务视图会提炼 action、risk level、decision、approval ID 和策略来源。 - 入口路由治理策略已沉淀到 UI state 的 `routeDecisionPolicy`，可通过 `POST /api/route-decision/policy/pull` 拉取管理端 `GET /api/digital-employee/policies/route-decision` 下发策略；`/api/ingress/route` 在生成 route decision 后、映射 governance command 前会先评估策略，命中阻断会写入 `route_decision_blocked` event 并停止执行，命中审批会创建 `route_decision_approval_required` approval/event 并等待人工处理，放行时才继续按 `auto_create_governance_commands` 映射命令；route decision 与管理端 business view 会携带 `policy_result`、`policy_source`、`blocked_reason`、`approval_id` 和 `matched_intent`；embedded 已新增 `/api/route-decisions/interventions` 与 `/api/route-decisions/:routeDecisionId/intervention`，审批通过后会按 `approval_id + route_decision_id` 幂等恢复对应 governance command，处理结果写入 `route_decision_intervention_resolved`。 - 任务中心的 `/api/governance/command` 已接入 qimingclaw 兼容层：`create_plan`、`submit_plan`、`approve_plan`、`activate_plan`、`create_schedule`、`run_schedule_now` 等命令返回本地可解释结果，其中激活/立即运行会映射到 adapter 的 dispatch/workday 状态。 - 日报下载不再打开 sgRobot 风格 PDF 后端直链；生成日报后会基于当前 qimingclaw workday 投影在浏览器内导出本地文本日报。 - 任务中心和委托详情不再使用 sgRobot demo mission fallback；没有 qimingclaw Plan / Task / Run / Event 时展示真实空态或错误态，避免示例任务冒充本地任务记录。 - 技能库不再使用 sgRobot demo skill fallback；Skill Catalog 为空或读取失败时展示真实空态 / 错误态，避免示例技能冒充本机能力。 - 嵌入页 localStorage/sessionStorage 的运行态 key 已切换到 `qimingclaw:*` / `qimingclaw_digital_*` 命名；旧 sgRobot/zeroclaw key 仅作为迁移读取或清理，不再作为新状态写入目标。 - 数字员工本地表不另建 sgRobot SQLite；统一建在 qimingclaw 主进程数据库 `~/.qimingclaw/qimingclaw.db` 内，作为 qimingclaw 客户端本地事实缓存与 outbox；表结构在主进程启动时创建，数字员工 runtime/sync 服务读写前也会按需自修复执行 `CREATE TABLE IF NOT EXISTS`。 - 同步状态通过 bridge 返回最近失败 outbox 明细，首页可直接看到实体类型、outbox ID、操作类型、重试次数、失败时间和下次自动重试时间。 - 本地 SQLite 额外记录 `digital_sync_attempts`，每次 outbox 推送成功、失败或部分 ack 缺失都会留下一次尝试历史，默认保留最近 30 天。 - 点击失败 outbox 可打开详情弹窗，查看完整错误、实体 ID、退避状态、最近重试历史，并可复制或导出诊断 JSON；也可触发手动 `flushSync` 立即重试。若已配置管理端同步地址，详情弹窗可直接打开对应的管理端同步记录深链。 - qimingclaw 自动生成的管理端深链只携带 `device_id`、`entity_type`、`entity_id`、`outbox_id`，避免在 URL 中暴露客户端 Key，同时仍能区分同租户下的不同客户端；管理端列表仍保留客户端 Key 手动筛选能力。 新增 IPC / Bridge： ```text digitalEmployee:getSyncStatus digitalEmployee:flushSync digitalEmployee:getRuntimeRecords digitalEmployee:getUiState digitalEmployee:saveUiState digitalEmployee:getSkillCapabilities digitalEmployee:pullSkillPolicies digitalEmployee:pullRiskApprovalPolicy digitalEmployee:evaluateRiskPolicy window.QimingClawBridge.digital.getSyncStatus() window.QimingClawBridge.digital.flushSync() window.QimingClawBridge.digital.getRuntimeRecords() window.QimingClawBridge.digital.getUiState() window.QimingClawBridge.digital.saveUiState(update) window.QimingClawBridge.digital.getSkillCapabilities() window.QimingClawBridge.digital.pullSkillPolicies() window.QimingClawBridge.digital.pullRiskApprovalPolicy() window.QimingClawBridge.digital.evaluateRiskPolicy(input) ``` 当前边界： - qiming-backend 已补最小接收端，先以通用同步记录表承接客户端 outbox。 - worker 只消费 outbox，不直接侵入 Plan / Task / Run / Event 写入链路。 - 管理端返回格式包含 `acked[]`，每项带 `outbox_id`、`entity_type`、`entity_id`、`remote_id`。 - 若管理端只 ack 批次中的部分 item，已 ack 的 item 会标记 synced，未 ack 的 item 会保留 failed 状态并进入下一轮补偿。 - 当前接口沿用管理端登录态鉴权，客户端必须能读取到客户端 Key 和登录 ticket/token 才会推送；缺少凭据时保持本地 outbox 等待，并在数字员工同步状态条显示缺少项。 - 管理端接收 outbox 时会校验 `X-Qiming-Client-Key`，请求体缺少 `client_key` 时以 header 为准，二者不一致时拒绝写入。 后端最小落点： ```text qiming-backend/sql/update-20260605.sql qiming-backend/app-platform-modules/app-platform-agent/app-platform-agent-core-ui/.../DigitalEmployeeSyncController.java qiming-backend/app-platform-modules/app-platform-agent/app-platform-agent-core-application/.../DigitalEmployeeSyncApplicationServiceImpl.java qiming-backend/app-platform-modules/app-platform-agent/app-platform-agent-core-adapter/.../DigitalEmployeeSyncRecord.java ``` 后端观察接口： ```text GET /api/digital-employee/sync/records ``` - 支持 `client_key`、`device_id`、`entity_type`、`entity_id`、`outbox_id`、`page_no`、`page_size` 查询参数。 - 按当前登录上下文租户隔离，默认每页 20 条，最大每页 100 条。 - 当前返回通用同步记录和原始 payload，用于管理端页面或联调工具先查看同步结果；后续再拆分为更丰富的 Plan / Task / Run / Event 查询模型。 - 管理端已增加“数字员工同步记录”菜单、权限资源和列表页，可按客户端 Key、设备 ID、实体类型、实体 ID、Outbox ID 查询并查看 payload；URL 查询参数会预填筛选条件，并在命中 Outbox ID 时自动打开 payload 抽屉。 - 管理端同步记录页会从通用 payload 中提炼标题、状态、Plan/Task/Run 关联、发生时间等业务摘要，列表和详情抽屉不再只能依赖原始 JSON 排障。 - 管理端列表和抽屉内的客户端 Key 仅脱敏展示，筛选框仍支持输入完整客户端 Key 精准查询。 下一步： - 后续再拆分管理端 Plan / Task / Run / Event 查询模型，让同步记录从通用 payload 观察面升级为业务视图。 - 数字员工页面继续补充管理端业务视图入口和失败分组统计。 管理端业务视图建议： ```text GET /api/digital-employee/plans GET /api/digital-employee/plans/{plan_id} GET /api/digital-employee/tasks GET /api/digital-employee/runs GET /api/digital-employee/events GET /api/digital-employee/artifacts GET /api/digital-employee/approvals ``` - 查询参数沿用同步记录维度：`client_key`、`device_id`、`entity_id`、`remote_id`、`status`、`sync_status`、`updated_from`、`updated_to`、`page_no`、`page_size`。 - 业务视图先从通用 sync record 的 `entity_type/entity_id/payload/status/created_at/updated_at` 聚合，不要求立即拆物理表；后续再按容量和查询压力拆正式业务表。 - Plan 视图输出 `plan_id`、`title`、`objective`、`status`、`client_key_masked`、`device_id`、`task_count`、`run_count`、`latest_event_at`、`sync_status`。 - Task / Run 视图保留 `plan_id`、`task_id`、`run_id` 关联，Run 额外输出 `started_at`、`finished_at`、`duration_ms`、`last_event_message`。 - Event / Artifact / Approval 视图保留原始 payload 抽屉，但列表层必须提炼 `kind/title/message/status/occurred_at`，避免管理端只能看 JSON 排障。 - qimingclaw 客户端的失败详情深链仍指向 sync record；管理端命中后可跳转到对应业务视图详情，形成“同步诊断 -> 业务事实”的双入口。 ## 尚未完全吸收的核心能力清单 以下清单按当前 qimingclaw 已落地状态盘点，不重复列出已完成的前端嵌入、本地 Plan / Task / Run / Event / Artifact / Approval / MemoryEntry、outbox 同步、技能投影和同步诊断。 1. **PlanStep 与依赖图（依赖图调度已开始）** - 已吸收：Plan / Task / Run 记录、计划模板、`create_plan` 中的 steps/tasks 可物化为任务；PlanStep 已开始作为正式本地实体落入 `digital_plan_steps`。 - 当前能力：PlanStep 会进入 `digital_sync_outbox`，entity type 为 `plan_step`；任务中心 flow 和 debug store 优先读取真实 PlanStep 生成步骤图；Task Agent 的 retry / skip / cancel / pause / resume / input / run 控制已可更新真实 Task、PlanStep、Run、Event 和 outbox；前置步骤跳过、取消或重试后会重新评估后继步骤，推进为 ready / blocked / pending 并写入依赖图事件；scheduler sweep 会识别可派发的 ready PlanStep，派发前先通过管理端 `POST /api/digital-employee/leases/plan-step-dispatch/acquire` 做跨设备强租约仲裁，管理端拒绝会以 `remote_lease_rejected` 跳过，管理端异常会降级为 5 分钟本地软租约 `payload.dispatchLease.source = local_fallback` 并记录 `remote_error`；调用本地 `/computer/chat` 后会写入 `plan_step_dispatch_*` 与 `governance_start_run` 事件，派发完成或失败会先尝试 `release` 管理端租约再释放本地 lease 并写入 `plan_step_lease_*` 事件；已有未过期租约的步骤仍会以 `lease_active` 跳过；auto sweep 会按节流从管理端 `GET /api/digital-employee/policies/plan-step-dispatch` 拉取远端派发策略，拉取失败时保留本地策略并记录 `last_pull_error`；embedded 已提供 `/api/digital-employee/plan-steps`、`/api/digital-employee/plan-step-graph`、`/api/digital-employee/plans/:planId/dispatch-ready-steps`、`/api/plan-step/dispatch-policy` 和 `/api/plan-step/dispatch-policy/pull`，ready PlanStep 安全派发、计划级跨任务推进、管理端依赖图视图、本地/远端派发策略、可观察租约状态和首页阻塞依赖处理入口已开始闭环。派发策略管理 UI 已开始吸收，embedded 新增“策略中心”集中展示和编辑 `enabled/max_per_sweep/auto_dispatch_ready_steps`。 - 后续缺口：正式外部管理端路由 UI、跨设备审批策略 UI 和跨设备策略冲突合并仍待吸收。 - 建议：下一轮围绕管理端正式路由 UI 或跨端审批策略 UI，把本地可治理调度继续推进到跨端治理策略。 2. **调度 / 定时 / 周期任务** - 已吸收：`digital_schedules`、`digital_schedule_runs` 已进入 qimingclaw 本地 SQLite 与 outbox，entity type 为 `schedule` / `schedule_run`；旧 `/api/cron`、`/api/scheduler/jobs` 和治理命令会优先读取真实本地调度记录。 - 当前能力：主进程 `DigitalEmployeeScheduler` 可按本机 5 字段 cron 到点触发本地 `/computer/chat`，支持启动 catch-up、立即运行、暂停/恢复/删除、失败重试、运行历史和同步诊断。多调度并发策略 UI 已开始吸收，embedded 新增“调度运营”入口，可查看 scheduler jobs、最近运行、`catch_up_on_startup`、`max_run_history`，并触发一次立即检查调度。 - 后续缺口：更细的秒级 cron、复杂日历排除规则、正式外部管理端调度策略下发和跨设备调度冲突合并仍待吸收。 - 建议：下一轮围绕入口路由/任务分流，把 schedule 触发的计划与具体 Skill Policy、Task Agent 状态机更精确地绑定。 3. **MemoryEntry / 长期记忆（已开始）** - 已吸收：qimingclaw `memoryService` 已投射为数字员工本地 `digital_memories`，支持从主客户端记忆列表同步、桥接新增和软删除；本地兜底记忆仍可在 memory 服务未初始化时工作。 - 当前能力：embedded `/api/memory` 已由 qimingclaw adapter 接管，GET / POST / DELETE 会通过 preload bridge 读写 `digital_memories`；记忆新增、更新和删除会进入 `digital_sync_outbox`，entity type 为 `memory`，同步业务视图会提炼 key、category、source、status 和 content preview。记忆归档/恢复 UI、管理端长期记忆业务视图和记忆治理审计链已开始吸收，embedded 新增“记忆治理”入口，可从 runtime memories 派生 key/category/source/status/content preview、重复候选和同步状态，并通过本地 overlay/audit 批量归档、恢复或标记复核。 - 后续缺口：真实合并执行、远端记忆策略下发和外部管理端长期记忆工作台仍待吸收。 - 建议：下一轮围绕管理端视图和记忆治理，把长期记忆从本地事实继续扩展到人工可审计、可归档、可合并的运营闭环。 4. **治理命令完整生命周期** - 已吸收：`create_plan`、`submit_plan`、`approve_plan`、`activate_plan` 等基础命令可记录本地运行事实；任务级 `retry_task`、`skip_task`、`pause_task`、`resume_task`、`provide_task_input`、`cancel_task`、`start_run`、`cancel_run` 已具备本地事实闭环；embedded plan / task action endpoint 已开始映射为正式 governance command；治理审计链和低风险 action policy 已开始吸收，route decision 自动映射 governance command 前会先经过低风险/受保护高风险 action guard，未命中的动作写入 `route_action_policy_blocked`，所有 `governance_*` event 的同步 `business_view` 会提炼 command、route、实体目标、风险等级和结果字段，`provide_task_input` 只同步 `input_length`。 - 当前能力：`/api/plan/:id/submit`、`/api/debug/plan/:id/:action`、`/api/task/:id/:action` 会进入 qimingclaw 本地治理记录；plan revision v1 可从 `governance_*` 事件投影只读时间线；数字员工首页会展示“治理审计/治理拦截”摘要，管理端通用 sync record 可通过 `business_view.category = governance` 消费治理命令审计字段。 - 缺口：`escalate`、正式计划 revision 表、正式管理端治理工作台和对真实 ACP 执行流的硬中断仍不完整。 - 建议：下一轮围绕正式管理端治理工作台和 ACP 硬中断，把本地治理审计推进到完整跨端裁决与执行控制。 5. **ManagedService 控制面** - 已吸收：Agent、MCP、Computer Server、Lanproxy、File Server、GUI Server 状态已进入 snapshot / projection；File Server 与 GUI Server 已开放白名单式 restart bridge，并会写入 `managed_service_restart` / `managed_service_restart_rejected` 事件，安全服务 restart bridge 已开始闭环。完整人机介入入口已开始吸收，embedded 新增“处置台”聚合服务异常、诊断风险、审计风险和策略拉取错误，支持批量标记已看、忽略、策略重拉和白名单服务安全重启。正式外部管理端服务运营台预览已开始吸收，qiming-backend 新增 `service_operations` 运营台视图聚合 managed service 快照、服务诊断和重启审计，qiming“数字员工运营台”新增“服务运营” tab，并只开放复核/忽略等低风险动作意图，不开放 start/stop。 - 缺口：仍缺少 start / stop、lease 持久化、重启历史、自动恢复策略和完整外部管理端服务运营台；Agent、MCP、Computer Server、Lanproxy 等高风险服务不暴露数字员工重启动作。 - 建议：先沉淀安全重启审计和人工确认体验，再评估更细粒度的服务恢复策略。 6. **技能生命周期与策略** - 已吸收：ACP / MCP / GUI / file server 能力已投射到 Skill Catalog，技能库不再使用 demo fallback；Skill Library 启用/禁用已写入 qimingclaw 本地 `digital_employee_skill_policies_v1.local_skills`，管理端下发策略写入 `remote_skills`，远端禁用优先生效且不会被本地按钮覆盖；入口路由候选技能会按有效策略过滤；MCP 注入 Agent 前会应用有效技能策略，ACP permission / tool update 会写入 `skill_call_allowed` / `skill_call_rejected` / `skill_call_observed` 审计事件，`policy_snapshot` 会包含本地/远端策略命中字段；embedded 已提供 `/api/digital-employee/skill-call-audits` 只读投影、`POST /api/skill/policies/pull` 手动拉取入口，技能调用策略与审计已开始闭环。管理端调用审计视图已开始吸收，embedded 新增“技能审计”入口，将 skill call audit、tool_call_audit、sandbox_audit 和 token_cost 统一成可筛选列表，技能库可按 skill id 跳转聚焦。 - 缺口：仍缺少技能安装、版本管理、细粒度权限范围和正式外部管理端调用审计工作台。 - 建议：下一轮围绕管理端审计消费、技能安装和权限范围，把本地调用审计推进到更完整的跨端治理闭环。 7. **产物交付闭环** - 已吸收：运行 payload 中的 artifacts / outputs / files / uri 可提取为正式 `digital_artifacts` 并同步；File Server workspace / upload / download / export / file update 生命周期状态已开始写入 Artifact payload 的 `delivery` 对象，embedded `/api/artifact` 和日报产物来源可读取交付阶段、状态、文件与 workspace 信息；Artifact 预览/下载权限已开始闭环，嵌入页通过受控 bridge 访问本地产物，并写入 `artifact_access_allowed` / `artifact_access_rejected` 审计事件；Artifact 版本/保留策略已开始闭环，业务产物视图可读取 version / retention 摘要，保留标记会写入 `artifact_retention_marked` / `artifact_retention_rejected` / `artifact_version_observed` 事件。真实文件清理执行已开始吸收，过期本地普通文件可通过独立 `cleanup` bridge 删除，清理结果会写入 `artifact_cleanup_executed` / `artifact_cleanup_rejected` / `artifact_cleanup_failed`，artifact payload 与业务视图会投影 `cleanup_status`、`deleted_at` 和原因字段。保留策略批量治理和跨设备聚合视图已开始吸收，embedded 业务视图新增 `artifact-groups` 产物聚合入口，可按版本/来源聚合产物、统计设备/版本/保留/清理状态，并通过受控批量接口写入保留、到期或复核标记；日报产物来源也提供批量标记到期入口。 - 缺口：正式管理端产物生命周期预览已开始吸收，qiming“数字员工运营台”的“产物治理”tab 可只读聚合产物 lifecycle / access / retention / cleanup / version 业务视图，并通过低风险 admin action 记录 `mark_keep` / `mark_expire` / `mark_reviewed` 意图，等待客户端拉取执行；仍缺少批量真实文件清理、复杂跨设备图谱、正式外部生命周期工作台和更完整物化业务表。 - 建议：下一轮围绕正式管理端生命周期工作台和跨设备图谱，把 embedded 预览聚合推进到跨端运营治理。 8. **审批 / 人工介入增强** - 已吸收：approval 记录、workday decision、ACP permission 响应桥已有雏形；用户处理审批时会写入 `approval_decision` runtime event；评论、转交、超时、风险标记会写入 `approval_action_recorded` / `approval_action_rejected`，并联动 embedded `/api/approval/:approvalId/timeline`、审批列表摘要、管理端 `/api/digital-employee/approval-history` 历史视图、`/api/approval/subscriptions` 订阅策略和 notification 投影；风险审批策略已支持管理端远端下发、手动拉取、本地策略评估、高风险动作前置拦截和本地设置页管理，`/api/risk-approval/policy` 可读写本地策略并记录 `update_risk_approval_policy`；多步审批 workflow 已复用 `digital_approvals.payload`，支持步骤推进、转交/超时/风险动作更新当前步骤、管理端审批更新拉取和审批处理回写，审批动作历史、风险策略、多步流程与通知联动已开始闭环；跨端审批冲突可视化已开始吸收，管理端远端更新与本地终态/更新时间/current step 不一致时会保留本地状态、记录 `approval_conflict_detected`、在业务视图投影 `approval_conflict_*` 字段，并在首页审批卡暂停直接同意/驳回；冲突解决动作闭环已开始吸收，客户端可通过独立 `resolveApprovalConflict` bridge 选择保留本地、采纳管理端或标记已复核，裁决会写入 `approval_conflict_resolved` / `approval_conflict_resolution_rejected`，并在审批业务视图投影 `approval_conflict_resolution`、`approval_conflict_resolved_at` 和裁决人摘要。跨设备批量冲突排查已开始吸收，embedded 新增“介入台”聚合审批冲突、风险审批、路由干预和待处理通知，支持筛选、分页、批量保留本地和批量标记复核；批量采纳管理端被 `batch_accept_remote_disabled` 保护，避免扩大状态分叉。正式管理端审批工作台预览已开始吸收，qiming-backend 新增 `approval_governance` 运营台视图聚合审批冲突、风险审批、路由待审和审批动作历史，qiming“数字员工运营台”新增“审批治理” tab，并只开放保留本地、标记复核、标记已看、忽略和重试策略检查等低风险动作意图。 - 缺口：仍缺少管理端裁决策略 UI、批量采纳远端和高风险审批自动执行。 - 建议：下一轮围绕正式管理端审批工作台，把 embedded 介入台预览推进到外部管理端批量排查和策略化回写。 9. **通知 / Inbox / 用户消息** - 已吸收：运行事件和同步失败能在数字员工页面展示；embedded adapter 已接管 sgRobot 风格 `/api/notifications`、未读数、read/dismiss/reply，本地 UI state 会保存通知已读、忽略和回复 overlay；顶部 Bell 已开始展示 approval、同步失败、服务异常和任务完成通知；本地通知订阅偏好已接入 `/api/notifications/preferences`，可按总开关、桌面通知开关、等级和常用类型过滤 Inbox；`/api/digital-employee/notifications` 已提供管理端可消费的本地通知业务视图，通知动作和订阅偏好事件的 sync `business_view` 会归类为 notification 并提炼状态字段；`need_input` 通知首次回复会同步转化为 `provide_task_input` 治理命令，保留通知回复 overlay 的同时写入 Task/Run/Event/outbox；客户端已支持管理端通知状态拉取与本地通知动作回写，未读 action/warn/error 通知会按偏好触发一次系统级桌面提醒，系统权限引导 UI 已开始吸收，Bell 设置面板可展示桌面通知可用性、测试发送结果、自动通知失败原因，并通过系统设置入口辅助修复，`digital_workday_notification_*` 同步事件只暴露通知 ID、状态、endpoint、错误和回复长度，通知投影、本地订阅策略、桌面提醒、系统权限引导、跨端未读状态与任务输入链路已开始闭环。 - 缺口：正式管理端通知运营预览已开始吸收，embedded 新增“通知运营”入口，可筛选全部/未读/待处理/异常通知，支持批量已读、批量忽略、拉取远端通知、打开系统通知设置和单条回复；qiming“数字员工运营台”的“通知运营”tab 可只读聚合通知业务视图，并通过低风险 admin action 记录 `mark_read` / `dismiss` 意图，等待客户端拉取执行；仍缺少正式外部通知协作工作台、复杂订阅策略 UI、真实通知发送/推送通道和跨设备通知冲突合并。 - 建议：下一轮围绕正式管理端通知工作台，把 Inbox 从嵌入页投影推进到完整跨端协作入口。 10. **入口路由 / 任务分流（路由业务视图与通知联动已开始）** - 已吸收：管理端通过 `/computer/chat` 进入 qimingclaw 后会生成本地任务事实；embedded `/api/ingress/route`、`/api/route-decisions` 和 `/api/digital-employee/route-decisions` 已由 qimingclaw adapter 接管。 - 当前能力：入口请求会按上下文、ready PlanStep、调度、查询和控制动作生成 route decision，并写入 `digital_events.kind = route_decision` 与现有 event outbox；路由时间线优先从 qimingclaw 本地事件读取；低风险 route decision 已开始映射为明确的本地 governance command，并把 `created_command_id` 回填到 route decision；自动映射前会执行低风险/受保护高风险 action guard，未允许的控制动作会记录 `route_action_policy_blocked` 或 `route_action_missing_context`，避免静默创建命令；入口路由策略可从管理端远端下发，支持按 intent 阻断、按 intent 要求审批、限制自动创建 governance command，并在策略干预时先记录 route decision 再停止本地命令执行；首页已展示路由干预队列和治理审计摘要，审批通过/拒绝会写入本地 approval decision 并回写管理端，管理端审批更新拉取后会自动扫描已批准 route approval 并按幂等规则恢复执行；scheduler check 已接入 ready PlanStep 安全派发，首页立即执行后会触发一次派发 sweep 并展示派发结果；路由决策本地业务视图、首页摘要、治理审计、策略来源/拉取错误、阻断/待审/待干预/已恢复计数和通知联动已开始闭环。管理端正式路由 UI 预览已开始吸收，“策略中心”会把入口路由策略纳入统一拉取与状态展示。正式管理端路由治理预览已开始吸收，qiming-backend 的 `route_governance` 运营台视图会聚合 route blocked / approval required / missing context / not mapped / governance audit，qiming“数字员工运营台”的“路由治理”tab 只开放标记已看、忽略和重试策略检查等低风险动作意图。 - 后续缺口：路由策略编辑、跨设备路由干预冲突可视化和高风险恢复执行策略 UI 仍待吸收。 - 建议：下一轮围绕管理端正式路由 UI 和跨设备冲突可视化，把 embedded 批量干预入口推进到管理端运营台。 11. **诊断 / 成本 / 审计视图** - 已吸收：同步失败诊断较完整，部分 sandbox / memory / service 日志在 qimingclaw 其他模块中存在；embedded adapter 已接管 `/api/doctor`、`/api/cost`、`/api/audit`，从 snapshot、runtime records、sync status、managed services 和 artifact delivery facts 生成诊断、估算成本和审计投影；sandbox audit、token/cost 和 CLI/tool 调用事件已开始通过 `digital_events` 与 outbox `business_view` 提炼为 `sandbox_audit`、`token_cost`、`tool_call_audit` 分类，并只同步 session、tool、server、operation、status、exit code、duration、model、token 计数和估算成本等安全字段；数字员工首页已展示诊断/审计/Token/估算成本摘要，`/api/digital-employee/audits` 已提供本地审计业务视图，诊断与审计风险通知联动已开始闭环。管理端正式审计视图预览和正式管理端审计诊断预览已开始吸收，qiming-backend 的 `audits` 运营台视图会聚合 sandbox / token cost / tool call / sync failure / governance 审计业务视图，qiming“数字员工运营台”的“审计诊断”tab 可标记复核、忽略和脱敏归档。诊断修复动作预览已开始吸收，“处置台”可把 doctor/audit/service/policy 风险转为可筛选、可标记和可安全重试的运营事项。发送账单审计外壳已开始吸收，后端提供估算账单查询和审计归档记录接口，qiming 运营台可显示 Token/估算成本并标记脱敏归档；归档记录会剔除 token、authorization、raw_input、prompt 和 command 等敏感字段。 - 缺口：真实计费账单、独立 sandbox audit 文件归档、自动诊断修复动作和正式外部管理端审计视图尚未统一吸收；当前账单仍是估算，审计归档只记录脱敏摘要和归档位置。 - 建议：下一轮围绕管理端正式审计视图和诊断修复动作，把本地可追溯审计继续推进到可运营处置。 12. **管理端业务查询模型** - 已吸收：管理端已有通用 sync record 接收、查询、payload 摘要和深链；后端 sync record 已开始保存客户端顶层 `contract_version`、`entity_summary` 和 `business_view`，并基于现有 `digital_employee_sync_record` 拆出 `/api/digital-employee/plans`、`/plans/{plan_id}`、`/tasks`、`/runs`、`/events`、`/artifacts`、`/approvals` 管理端业务查询模型；列表支持客户端 Key、设备、实体 ID、状态、同步状态和同步时间范围过滤，业务 row 会提炼 title/status/summary、Plan/Task/Run 关联、发生/开始/结束时间、sync record 深链和脱敏客户端 Key；Plan 视图会聚合 task/run 计数与最近事件，Plan 详情会返回关联 tasks/runs/events/artifacts/approvals 摘要。embedded adapter 已拆出同名只读业务查询接口，从 qimingclaw runtime、artifact、approval 和 canonical event 投影生成统一分页视图；embedded 数字员工页已新增“业务视图”入口，支持计划/任务/运行/事件/产物/审批分段、实体/状态/同步状态/时间筛选、分页和详情 JSON 查看；客户端 outbox 的 event `business_view` 已开始按 route decision、governance command、approval action、artifact lifecycle/access、skill call audit 和 ready PlanStep dispatch 细分常用字段，本地与管理端业务视图投影已开始闭环。正式外部管理端台面已开始吸收：qiming-backend 新增 `/api/digital-employee/admin/workbench/{view}`，qiming 管理端新增“数字员工运营台”，统一展示业务视图、介入台、产物治理、通知运营、审计诊断、日报运营和路由治理，只读消费 sync record `business_view` 并提供同步记录深链。管理端低风险动作闭环已开始吸收：后端新增 `/api/digital-employee/admin/actions` 记录动作意图和 `/pending` 拉取队列，qimingclaw 只应用保留本地、标记复核、通知已读/忽略、产物保留/到期、日报交付/确认/审批请求等低风险动作并写入 `admin_action_applied` / `admin_action_rejected` / `admin_action_failed`，qiming 运营台抽屉只提示“已记录，等待客户端拉取”。跨设备策略冲突视图已开始吸收：qimingclaw 将派发、风险审批和入口路由策略同步事件投影为 `policy_snapshot` business view，后端新增 `/api/digital-employee/admin/policies/snapshots` 聚合 client/device 维度差异并输出 `conflict_keys`，qiming 运营台新增“策略冲突” tab 展示 policy drift 与 sync record 深链。业务事实物化查询已开始吸收：后端新增 `digital_employee_business_fact`、`digital_employee_artifact_lifecycle`、`digital_employee_daily_report_fact` 三张增量物化表，同步入库时 upsert 安全业务摘要，业务查询优先返回 `materialized: true` 行，旧记录继续回退 sync record。 - 缺口：复杂组合检索、跨设备聚合图、远程裁决/策略编辑动作和物化业务表仍待吸收。 - 建议：先使用 sync record 派生业务查询模型和 embedded 业务视图预览承接联调，再按容量和查询压力决定是否拆 Plan / Task / Run / Event 物理业务表。 13. **日报实体与导出交付** - 已吸收：embedded 页面可基于当前 workday projection 导出本地文本日报；生成日报时会通过 qimingclaw bridge 写入 `daily_report` text / HTML / PDF Artifact 与 `daily_report_generated` Event，并可通过 `/api/digital-employee/daily-reports` 和详情接口读取只读日报投影。日报 HTML/PDF 导出、发送记录、管理端确认回执和日报发送审批已开始吸收，交付动作会写入 `daily_report_send_recorded` / `daily_report_confirmed` / `daily_report_approval_requested` 事件，sync `business_view.category = daily_report` 可被管理端筛选消费。管理端正式日报页面预览和正式管理端日报运营预览已开始吸收，embedded 新增“日报运营”入口，展示日报生成、交付、确认、审批和关联产物状态，并复用现有生成、记录发送、确认回执和请求审批动作；qiming-backend 的 `daily_reports` 运营台视图会聚合日报生成、发送记录、确认回执和审批请求，qiming“数字员工运营台”的“日报运营”tab 可记录已送达、确认回执、请求审批和发送结果。发送账单审计外壳已开始吸收，qiming-backend 新增 `/api/digital-employee/admin/daily-reports/send-records`，qiming 运营台可在日报详情中“记录发送结果”，但不接真实第三方发送通道。 - 缺口：没有正式 DailyReport 物理表、真实管理端发送通道、正式外部管理端日报页面和审批裁决回写闭环。 - 建议：先稳定 Artifact/Event 派生日报交付模型，再根据管理端联调需要决定是否物化 DailyReport 表与发送记录表。 ## 管理端联动原则 数字员工状态是本地优先，但不能成为本地孤岛。 本地 SQLite 表设计必须同时满足： - 离线可用：客户端无网络时仍能展示任务、运行明细和日报。 - 可追溯：本地每个 Plan / Task / Run / Event 都有稳定本地 ID。 - 可同步：预留管理端 ID 和同步状态。 - 可补偿：同步失败后可通过 outbox 重试。 当前已新增/规划的本地表： ```text digital_plans digital_plan_steps digital_schedules digital_schedule_runs digital_tasks digital_runs digital_events digital_artifacts digital_approvals digital_sync_outbox ``` 同步字段： ```text remote_id sync_status last_synced_at sync_error ``` 同步流建议： ```text 本地写入 Plan/Task/Run/Event -> digital_sync_outbox pending -> 管理端 sync API -> 回填 remote_id -> sync_status = synced ``` 管理端 API 尚未在 qiming-backend 中确认最终路径，因此当前 qimingclaw 先落本地同步契约，不硬编码远端接口。 当前同步 item 契约： ```text contract_version = qimingclaw.digital_employee.sync.v1 outbox_id entity_type entity_id operation entity_summary { title, status, summary } business_view { entity_type, local_id, title, status, ...typed fields } payload ``` `business_view` 按 Plan / Task / Run / Event / Artifact / Approval 归一常用业务字段，管理端可以先消费该稳定视图；`payload` 保留客户端原始上下文，便于后续扩展和审计。 ### 产出 - 数字员工页面可以从源码重新构建。 - `public/sgrobot-digital` 不再手工维护。 - qimingclaw 不启动 sgRobot 也能打开数字员工页面。 ### 验收 - `npm run sync:sgrobot-digital` - `npm run build:sgrobot-digital` - `npm run build:renderer` - qimingclaw“概览”直接显示数字员工首页，不出现配对页。 ## Phase 2：数字员工 API 适配层 目标：让数字员工页面开始读取 qimingclaw 真实数据。 ### 做法 在 qimingclaw main process 或本地 HTTP 服务中新增数字员工 API 适配层。 先实现这些 sgRobot 兼容 API： ```text GET /api/digital-employee/workday POST /api/digital-employee/workday/actions GET /api/debug/plans GET /api/debug/tasks GET /api/skill GET /api/debug/store ``` 数据来源先映射 qimingclaw 当前已有能力： - 当前用户 - 登录状态 - 服务状态 - Agent 状态 - 会话列表 - 最近 `/computer/chat` 请求 - ACP session 状态 - MCP tool 列表 此阶段不追求完整 Plan/Task/Run，只先让页面从 qimingclaw 取真实状态。 ### 产出 - 数字员工首页展示 qimingclaw 的真实运行状态。 - 技能库可以显示 qimingclaw 当前 MCP/ACP 工具能力。 - 任务中心开始展示 qimingclaw 最近执行记录。 ### 验收 - 停止 sgRobot 后端，数字员工页面仍然工作。 - 页面 API 请求命中 qimingclaw。 - 无 qimingclaw 真实数据时展示真实空态 / 错误态，不再用 demo mission/skill 兜底。 ## Phase 3：Run / Event / Artifact 轻量控制平面 目标：把 qimingclaw 当前执行链路正式记录为可展示、可审计的运行对象。 ### 当前 qimingclaw 执行链路 ```text backend -> lanproxy -> computerServer:60006 /computer/chat -> agentService.ensureEngineForRequest -> AcpEngine.chat -> ACP session / prompt -> /computer/progress/{session_id} SSE ``` ### 需要新增的核心表 先落地最小集合： ```text runs events artifacts approvals ``` 推荐语义： - `Run`：一次 qimingclaw 执行尝试。 - `Event`：执行过程中的事实记录。 - `Artifact`：执行结果、文件、报告、截图、日志摘要。 - `Approval`：权限请求、人工确认、风险操作确认。 ### 映射方式 ```text /computer/chat request -> create Run ACP progress event -> append Event permission request -> create Approval tool result / final message -> create Artifact 或 Event session complete -> finish Run ``` ### 产出 - 每次执行都有 Run ID。 - 数字员工“今日执行”“运行明细”读取真实 Run/Event。 - 后续日报和审计有数据基础。 ### 验收 - 发起一次远程 `/computer/chat` 后，数字员工页面能看到执行记录。 - Run 状态能从 running 进入 succeeded / failed / cancelled。 - Event 时间线可追踪主要执行过程。 ## Phase 4：Task / PlanStep / Plan 目标：吸收 sgRobot 的任务操作系统骨架。 ### 先做 Task 把一次业务执行抽象成 Task： ```text Task -> Run attempt 1 -> Run attempt 2 ``` Task 管业务目标，Run 管执行尝试。 ### 再做 Plan / PlanStep 当 Task 稳定后，引入： ```text Plan PlanStep ``` Plan 用于承载多步骤业务流程。 ### 数据关系 ```text Plan -> PlanStep[] -> Task[] -> Run[] -> Event[] -> Artifact[] -> Approval[] ``` ### 产出 - 数字员工任务中心从“执行记录列表”升级为“计划 / 任务 / 步骤”视图。 - 支持多步骤任务展示。 - 支持失败隔离和重试。 ### 验收 - 单步任务能以 Task 展示。 - 多步任务能以 Plan 展示。 - 每个 Task 能看到 Run 历史。 ## Phase 5：PlanTemplate 融合 目标：吸收 sgRobot 的业务流程模板能力。 ### 新增目录 ```text ~/.qimingclaw/plan_templates/ ``` 支持文件： ```text PlanTemplate.toml PlanTemplate.json ``` 当前客户端实现先读取本机目录，不依赖 sgRobot daemon。main process 通过 `digitalEmployee:getPlanTemplates` IPC 暴露模板列表，preload bridge 提供 `window.QimingClawBridge.digital.getPlanTemplates()` 给 embedded digital 页面使用。 模板字段支持： ```text plan_id / id / template_id title / name objective / description status steps[].step_id / steps[].id steps[].preferred_skills / steps[].skills steps[].tasks[].task_id / steps[].tasks[].id ``` ### API ```text GET /api/plan-templates GET /api/plan-templates/:id POST /api/plan-templates/:id/activate ``` ### 与数字员工页面关系 数字员工“任务设置”区域读取 PlanTemplate。 用户可以： - 查看模板 - 选择今日任务 - 一键执行 - 设置定时 页面融合位置： - 任务设置：模板作为可选业务流程展示。 - 任务中心：模板步骤和任务合并到本地运行视图。 - 调度：模板生成 `plan_template` 类型 job。 - 详情/聊天：无运行态时以模板内容生成计划流和消息。 - 执行：点击模板执行会写入正式 `activate_plan` governance command，生成 Plan / Task / Run / Event / outbox，同步给管理后端。 - 创建 / 重新执行：`create_plan` payload 中的 `steps` / `tasks` 会展开为真实 pending Task；后续 `submit_plan`、`approve_plan`、`activate_plan` 保留原计划标题和目标，不再用治理动作名覆盖业务计划。 - 调度去重：任务中心通过 `/api/governance/command` 激活计划时只记录一次治理命令，直接 `/api/debug/plan/:id/dispatch` 入口仍会自行记录本地激活。 ### 产出 - qimingclaw 具备业务流程沉淀能力。 - 数字员工不只是临时聊天入口，而是可选择业务模板执行。 ### 验收 - 放入一个 `PlanTemplate.toml` 后，数字员工页面能展示。 - 放入一个 `PlanTemplate.json` 后，数字员工页面能展示。 - 点击执行后生成 Plan / Task / Run。 - 执行记录进入 `digital_sync_outbox`，后续由本地同步链路上报。 ## Phase 6：Skill Catalog 融合 目标：把 qimingclaw 的 MCP / ACP 工具治理成 sgRobot 风格 Skill。 ### 数据模型 ```text Skill skill_id name description version kind input_schema output_schema timeout_policy retry_policy approval_policy sandbox_policy enabled ``` ### 来源映射 ```text MCP tools ACP commands qimingclaw built-in tools GUI agent tools file server tools ``` ### 与数字员工页面关系 数字员工“技能库”展示 qimingclaw Skill Catalog。 当前客户端实现由 `digitalEmployee:getSkillCapabilities` IPC 输出本地 Skill Catalog， embedded digital 页面通过 `window.QimingClawBridge.digital.getSkillCapabilities()` 合并到 `/api/skill`。目录已覆盖 MCP server / tool，并把 qimingclaw ACP 内建能力 投射为 Skill；GUI agent tool 和 file server tool 也已作为 qimingclaw 本地技能源 进入目录。 MCP 技能字段已包含： ```text server_id transport running tools / tool_count allow_tools / deny_tools governance.effective_policy recent_calls / call_count / last_called_at project_ids ``` ACP 技能目录已包含： ```text qimingclaw-acp-session qimingclaw-computer-control qimingclaw-acp-permission qimingclaw-artifact-reporting ``` 这些技能会展示 Agent 引擎、运行状态、活跃会话数、内建 command/tool 列表， 并从本地 digital runtime events 归集最近调用、项目 ID 和会话 ID。 GUI / File Server 技能目录已包含： ```text qimingclaw-gui-agent qimingclaw-file-server gui_execute_task / gui_analyze_screen / gui_click / gui_type / ... create_workspace / upload_file / download_all_files / export_project / ... ``` 这些本地技能会展示对应服务运行状态、端口、工具列表，并从 runtime event 的 `toolName`、`source`、workspace/upload/download/artifact 等线索归集最近调用。 用户可以： - 查看技能 - 启用 / 禁用（本地持久化到 `digital_employee_skill_policies_v1.local_skills`，并影响入口路由候选技能） - 手动拉取管理端技能策略（远端策略写入 `remote_skills`，远端禁用优先生效） - 查看所属 MCP server - 查看 MCP allow / deny 策略 - 查看 MCP proxy 运行状态 - 查看 ACP 内建能力与最近调用 - 查看 GUI agent / file server 本地工具和最近调用 - 查看输入输出说明 - 查看最近调用记录 ### 产出 - 工具从“技术配置”变成“数字员工能力”。 - PlanTemplate 可以绑定 Skill。 - MCP server 和工具能按治理策略投射成可扫描的技能卡。 - Skill Library 的启用 / 禁用操作会通过 `digitalEmployee:setSkillEnabled` 写入 qimingclaw 本地策略；`拉取策略` 会通过 `digitalEmployee:pullSkillPolicies` 更新管理端远端策略；`/api/skill` 后续读取真实目录状态和本地/远端治理命中。 ### 验收 - MCP tool 能出现在技能库。 - MCP server 能显示 allow / deny、运行状态和最近调用。 - 禁用技能后，入口路由不会再把它作为候选技能；若候选全部被禁用，路由决策会记录 `candidate_skills_disabled`。 - 管理端远端策略禁用某个 skill 后，本地目录、MCP 注入和 ACP permission 审计都会显示远端策略命中并拒绝调用。 ## Phase 7：Approval / Human-in-the-loop 目标：吸收 sgRobot 的人工治理机制。 ### 融合对象 qimingclaw 已有 ACP permission 和 sandbox permission 概念。 需要统一成： ```text Approval ``` 来源包括： - 文件写入 - 命令执行 - 外部服务调用 - 高风险工具 - Plan 执行确认 - Task 重试 / 跳过 / 取消 ### 与数字员工页面关系 数字员工页面展示： - 待审批 - 已批准 - 已拒绝 - 等待输入 - 风险说明 当前客户端实现： - ACP `permission.updated` / `permission.replied` 事件会被 event forwarder 归一成 runtime event。 - `approval_requests` 会抽取到 `digital_approvals`，并进入本地 outbox。 - embedded digital 页面展示这些 runtime approval。 - 用户点击同意 / 驳回时，adapter 从 approval payload 取出 `sessionId` / `permissionId`，通过 preload bridge 调用 `agent:respondPermission`。 - 本地 approval payload 会记录 `acpPermission` 回复结果，供管理端同步和审计。 - 用户处理审批后，主进程会同步写入 `approval_decision` runtime event；embedded adapter 新增 `/api/approval/:approvalId/timeline`，可从 approval 记录和相关 runtime event 投影只读审批动作时间线；多步审批 workflow 会在 timeline 和首页决策卡展示当前步骤、总步骤数、处理人和下一步。 - 管理端可通过 `/api/digital-employee/approval-history` 查询审批动作历史，客户端可通过 `/api/approval/subscriptions` 维护审批订阅策略；订阅更新会写入 `digital_workday_update_approval_subscriptions` runtime event 与同步业务视图。 - 客户端可通过 `POST /api/approval/updates/pull` 手动拉取管理端审批更新，审批处理后会尝试回写 `POST /api/digital-employee/approvals/decisions`；回写失败只进入 runtime event 和 outbox 诊断，不回滚本地决策；拉取发现终态、较新本地状态或多步审批 current step 冲突时，会记录 `approval_conflict_detected`，审批业务视图和首页 decision 卡会展示冲突摘要并暂停直接同意/驳回。 - 客户端可通过 `POST /api/notifications/updates/pull` 手动拉取管理端通知状态，通知 read/dismiss/reply 后会尝试回写 `POST /api/digital-employee/notifications/actions`；回写失败只进入 runtime event 和同步业务视图，不回滚本地通知 overlay。 - 未读且重要的 Inbox 通知会按 `desktop_enabled` 偏好触发一次本机 Electron 桌面通知；触发 ID 记录在 embedded localStorage，避免同一通知反复弹出。 用户可操作： - approve - reject - approve once - approve always - pause - resume - cancel ### 产出 - 人工介入成为主路径能力。 - 数字员工不是黑箱自动执行。 - 数字员工审批动作能继续 ACP permission 链路。 ### 验收 - ACP permission request 能进入数字员工审批区。 - 用户在数字员工页面审批后，ACP 执行继续。 - approval 同步 payload 能看到对应 `permission_id`、`session_id` 和回复结果。 ## Phase 8：Artifact / 日报 / 汇报 目标：把执行结果正式沉淀为产物，并由数字员工生成日报和汇报视图。 ### Artifact 类型 ```text file report screenshot log json markdown diff summary ``` ### 日报数据来源 ```text Run Event Artifact Approval Task status Plan status ``` ### 与数字员工页面关系 数字员工“日报”区域展示： - 今日执行 - 成功 / 失败 / 异常 - 人工介入次数 - 关键产物 - 风险提示 - 可下载报告 当前客户端实现： - adapter 从 `digital_artifacts`、Run payload、Event payload 中抽取 artifact。 - artifact 会携带 `source_type`、`source_label`、`source_event_id`、`plan_id`、`task_id`、`run_id`。 - 日报数据新增 `artifact_sources`，页面展示产物名称、来源和 URI。 - 下载的本地日报文本包含“产物来源”段落。 ### 产出 - qimingclaw 的执行结果可沉淀、可回看、可汇报。 - 日报可以追溯到具体 Run / Event / Artifact 来源。 ### 验收 - 完成任务后能在日报区域看到执行摘要。 - Artifact 可从任务详情进入查看。 - 日报区域能看到产物来源和 URI。 ## Phase 9：ManagedService / 常驻能力治理 目标：吸收 sgRobot 对长期服务能力的治理方式。 qimingclaw 当前已有多个服务： ```text computerServer fileServer lanproxy mcpProxy agent guiServer adminServer ``` 需要把它们建模为： ```text ManagedService ServiceInstance ServiceLease ``` ### 与数字员工页面关系 数字员工页面可以展示： - 服务健康 - 最近错误 - 重启次数 - 当前依赖它的任务 - 是否需要人工处理 当前客户端实现： - `digitalEmployee:getSnapshot` 输出 `managedServices`，由 Agent、MCP Proxy、Computer Server、File Server、Lanproxy、GUI Agent Server 状态投射生成。 - 每个服务包含 `serviceId`、`kind`、`status`、`requiresHumanAction`、`dependentTasks`、`instance`、`lease`。 - embedded adapter 将其转换为 `workday.managed_services`，并写入 overview 指标、首页播报和 delivery lines。 - 服务异常或必需服务未运行时，首页“当前动作 / 下一步”会提示对应服务和受影响任务。 ### 产出 - 服务状态不只在客户端设置页展示，也进入数字员工的运行上下文。 - 常驻服务具备 ManagedService / ServiceInstance / ServiceLease 的业务投影。 ### 验收 - 服务异常时，数字员工首页能提示。 - 服务恢复后，事件和状态同步更新。 - 首页 overview 能看到服务运行数和需处理服务数。 ## Phase 10：Plan Agent / Task Agent 目标：在 qimingclaw 内形成 sgRobot 的双层 Agent 架构。 这是后期能力，不建议提前做。 ### Plan Agent 负责： - 计划生命周期 - 用户对话 - 异常决策 - 审批转发 - 重试 / 跳过 / 重规划 ### Task Agent 负责： - 单个 Task 的执行 - ACP session 调用 - MCP tool 调用 - 进度上报 - 产物回写 ### 推荐链路 ```text User -> Digital Employee -> Plan Agent -> Task Agent -> ACP / MCP -> Event / Artifact / Approval -> Digital Employee Projection ``` 当前客户端轻量实现： - embedded adapter 从本地 Plan / Task / Run 派生 `plan_agents` 和 `task_agents`。 - Plan Agent 包含计划生命周期、托管任务数、失败任务数、下一步动作和是否可重规划。 - Task Agent 包含执行状态、绑定 Skill、最新 Run、是否可 retry / skip / cancel，以及下一步动作。 - 首页 overview 展示 Plan Agent、Task Agent 和可治理任务数量；播报区域优先提示可治理 Task Agent。 - 首页“今日执行”面板已提供 Task Agent 控制条，可对可治理任务发起重试、跳过、取消，并通过 governance command 更新真实 Task / PlanStep / Run / Event / outbox。 - `retry_task`、`skip_task`、`pause_task`、`resume_task`、`provide_task_input`、`cancel_task`、`start_run`、`cancel_run` governance command 会被 qimingclaw adapter 接受并写入正式本地治理记录；其中取消和跳过只更新本地事实，不强制杀掉正在运行的 ACP / `/computer/chat` 流。 ### 产出 - qimingclaw 从“Agent 客户端”升级为“数字员工任务操作系统”。 - 计划/任务执行开始具备 Plan Agent / Task Agent 控制平面投影。 - Task Agent 的 retry / skip / cancel 不再只是提示，已经具备用户可触发、可刷新、可同步的本地治理闭环。 ## 推荐实施顺序 按风险和收益排序： ```text 1. 数字员工前端源码融合 2. 数字员工 API 适配层 3. Run / Event / Artifact 轻量控制平面 4. Task / Plan 基础模型 5. PlanTemplate 6. Skill Catalog 7. Approval / Human-in-the-loop 8. 日报与 Artifact 9. ManagedService 10. Plan Agent / Task Agent ``` ## 第一阶段验收清单 第一阶段完成后，应满足： - qimingclaw 内有数字员工前端源码目录。 - `public/sgrobot-digital` 可由脚本生成。 - `npm run check:digital-employee` 可重复验证数字员工关键单测、main build、embedded build、静态资源引用和本机 SQLite digital schema。 - 不启动 sgRobot 后端也能打开“概览”。 - “概览”直接显示数字员工页面。 - 不出现 sgRobot 配对页。 - 不手工维护压缩后的 `dist/assets/*.js`。 - sgRobot 仓库不参与 qimingclaw 提交。 - `npm run build:renderer` 通过。 ### 本地验证入口 ```bash cd crates/agent-electron-client npm run check:digital-employee ``` 该命令不启动 sgRobot daemon。本机已有 `~/.qimingclaw/qimingclaw.db` 时会检查 `digital_*` 表；数据库尚未生成或 `sqlite3` 不可用时只跳过 schema 检查，代码回归仍继续执行。 ## 最终验收标准 整个融合完成后，应满足： - 数字员工页面显示 qimingclaw 真实数据。 - 远程 `/computer/chat` 请求能生成 Run 和 Event。 - 用户能在数字员工页面看到任务进度、失败、产物和审批。 - PlanTemplate 能创建可执行计划。 - Skill Catalog 能治理 MCP/ACP 工具。 - 日报能基于真实 Run/Event/Artifact 生成。 - qimingclaw 不依赖 sgRobot daemon。 - sgRobot 的核心理念和对象模型被 qimingclaw 吸收，而不是简单嵌入另一个应用。