Skip to content

05-orchestration-and-data.md

Latest commit

 

History

History
239 lines (201 loc) · 8.25 KB

05-orchestration-and-data.md

File metadata and controls

239 lines (201 loc) · 8.25 KB
Raw

05 · 编排与数据面

对应传统 RPA 的 Orchestrator：运行调度、队列、密钥/资产、观测审计、存储模型。 定位：本地优先的单守护进程 praxisd，但数据模型与接口为将来服务化（多机 Robot 集群）预留。

1. 控制面全景

flowchart TB
    subgraph PRAXISD["praxisd（Go 单二进制守护进程）"]
        subgraph API["接口"]
            MCP["MCP Server"]
            RPC["gRPC/REST"]
        end
        subgraph SCHED["编排与调度"]
            RUNMGR["Run Manager 运行管理"]
            QUEUE["Work Queue 工作队列"]
            SCHEDULER["Scheduler 排程(cron/触发)"]
            POLICY["Policy Engine 站点/护栏策略"]
            HEALCO["Self-Heal Coordinator"]
        end
        subgraph STORE["存储与治理"]
            REG["Skill Registry 技能注册表"]
            LOCDB["Locator Repository"]
            VAULT["Vault 机密/身份"]
            RUNDB["Run Store 运行留痕"]
            METRICS["Metrics/Trace"]
        end
        POOLMGR["Browser Pool Manager(见 04)"]
    end
    API --> SCHED
    SCHED --> STORE
    RUNMGR --> POOLMGR
    HEALCO --> REG
Loading

2. 运行（Run）模型

一次执行是一个 Run，统一承载探索与回放：

stateDiagram-v2
    [*] --> Queued
    Queued --> Admitted: 通过策略/护栏准入
    Queued --> Rejected: 违反站点策略/超预算
    Admitted --> Running
    Running --> Healing: 回放触发自愈
    Healing --> Running
    Running --> NeedsHuman: 命中硬挑战/审批点
    NeedsHuman --> Running: 人处理后恢复
    Running --> Succeeded
    Running --> Failed
    Succeeded --> [*]
    Failed --> [*]
    Rejected --> [*]
Loading

Run 记录字段（要点）： run_id、mode(explore|replay)、skill_ref、inputs、tier/identity、token_cost（回放应为 0，I-4 的可观测抓手）、status、artifacts(截图/动作/网络摘要)、heal_events、escalations。

  • 准入门（Admission）：Policy Engine 校验站点速率/禁行/高风险动作许可、预算、并发上限；不过则 Rejected（责任使用护栏落点）。
  • 审批点（NeedsHuman）：高风险动作（下单/支付）或硬挑战暂停，走人类审批/处理再恢复——默会知识的显式确认点。

3. 工作队列（批量/参数化回放）

借鉴 RPA 的 Queues：把"同一技能 × 大量输入"变成可弹性消费的工作项。

flowchart LR
    FEED["输入源(CSV/JSON/上游 Run 输出)"] --> Q["Work Queue<br/>item{skill_ref, inputs, priority}"]
    Q --> W1["Worker: 会话A(身份1)"]
    Q --> W2["Worker: 会话B(身份2)"]
    Q --> W3["Worker: 会话C(身份3)"]
    W1 --> RES["结果汇聚(统一 schema)"]
    W2 --> RES
    W3 --> RES
    W1 -. 失败重入队(退避) .-> Q
Loading
  • 幂等与去重：item 带业务键，避免重复执行副作用（尤其涉及下单类动作）。
  • 退避重试：失败项按指数退避重入队；连续失败触发技能信任分下降 / 重探索。
  • 身份分片：多身份并行消费，天然分散风控压力（与 T3 轮换协同）。

4. Vault（机密 / 身份 / 代理资产）

对应 RPA 的 Assets/Credentials，但把"身份画像"也纳入机密治理。

flowchart TD
    subgraph VAULT["Vault(加密静态存储)"]
        CRED["凭据: 站点账号/密码/OTP种子"]
        IDENT["身份画像: (profile,seed)+cookies+行为参数"]
        PROXY["代理: 住宅出口凭据"]
    end
    SKILL["技能包(只含 %vault:...% 占位)"] -->|解引用请求| BROKER["Secret Broker"]
    BROKER -->|仅注入运行内存| DRV["Transport Driver"]
    VAULT --> BROKER
    LOG["日志/留痕"] -. 默认脱敏 .-> BROKER
Loading
  • 占位符解引用：技能/日志只见 %vault:ecom.login%，明文只在运行时注入驱动内存（I-5，与 04 §4 secretRef 一致）。
  • 身份即资产：Profile 的 cookies/画像被当作机密管理，支持"身份轮换池"（T3）。
  • OTP/2FA：支持 TOTP 种子托管或人工回填审批点（不把二次验证自动绕过为对抗手段）。

5. 存储模型（数据实体关系）

erDiagram
    SKILL ||--o{ SKILL_VERSION : has
    SKILL_VERSION ||--o{ ACTION_NODE : contains
    ACTION_NODE ||--o{ LOCATOR : uses
    ACTION_NODE ||--o{ ASSERTION : has
    SKILL_VERSION ||--o{ VARIABLE : declares
    SKILL_VERSION ||--o{ RUN : executed_by
    RUN ||--o{ HEAL_EVENT : records
    RUN ||--o{ ARTIFACT : produces
    IDENTITY ||--o{ RUN : used_in
    IDENTITY ||--o{ SITE_MEMORY : accumulates
    SITE_MEMORY }o--|| SITE_POLICY : governed_by

    SKILL {
        string skill_ref PK
        string site
        float trust_score
    }
    SKILL_VERSION {
        string version
        string status
        json diff_from_prev
    }
    ACTION_NODE {
        int idx
        string type
        string intent
    }
    LOCATOR {
        string kind
        string value
        float rank
    }
    ASSERTION {
        string kind
        string expr
    }
    VARIABLE {
        string name
        string type
        bool required
    }
    RUN {
        string run_id PK
        string mode
        int token_cost
        string status
    }
    IDENTITY {
        string profile
        string seed
        json fingerprint
    }
    SITE_MEMORY {
        string domain
        string best_tier
        string best_identity
    }
Loading
  • 技能版本化 + diff：每版存与上一版差异，支持回滚/审计（与 02 §7 呼应）。
  • SiteMemory：域→最优档位/身份的记忆（03 §3 的落库），跨 Run 复用。
  • 本地存储实现建议：SQLite（关系+全文检索技能）+ 文件系统（artifacts/截图）；服务化时换 Postgres+对象存储，schema 不变。

6. 可观测性与审计

flowchart LR
    RUN["每个 Run"] --> TR["动作级 Trace(每步:定位器命中/耗时/断言)"]
    RUN --> SHOT["关键帧截图 + 会话回放"]
    RUN --> NET["网络摘要(域/状态码,默认脱敏)"]
    RUN --> COST["Token 计量(回放应=0)"]
    TR --> DASH["本地看板 / MCP 查询"]
    COST --> ALERT["异常告警:回放出现 Token>0 / 自愈频发 / 被拦升档"]
Loading
  • 回放 Token 计量是 I-4 的守门员：若某"回放"Run 出现 token_cost>0，说明触发了自愈或误配，需告警排查。
  • 自愈频率是技能健康度指标：频发 → 主动重探索或人工复核。
  • 会话回放（session replay）：留痕支持像 Browserbase 那样回看整段操作，便于 Review 与调试。

7. 排程与触发

  • 手动：Agent/人经 MCP 触发。
  • 定时：cron 式（如"每日抓价比对"）。
  • 事件：上游 Run 输出、Webhook、文件落地触发（借鉴 Skyvern 的 workflow 触发多样性）。
  • 护栏叠加：所有触发都过 Policy Engine 准入门。

8. 本地优先 → 服务化的演进（数据面视角）

flowchart LR
    subgraph V1["v1 本地(单机)"]
        D1["praxisd + SQLite + 本机 Chrome 驱动"]
    end
    subgraph VN["vN 服务化(多机)"]
        CP["控制面(Postgres+对象存储)"]
        N1["执行节点1(形状一致宿主+驱动)"]
        N2["执行节点2"]
        N3["执行节点N"]
        CP <-->|mTLS gRPC| N1
        CP <-->|mTLS gRPC| N2
        CP <-->|mTLS gRPC| N3
    end
    V1 -->|接口/schema 不变，仅换存储与传输| VN
Loading
  • 关键：BrowserNode 契约（04）+ 技能包规范（07）+ 存储 schema（本篇）在本地与服务化之间保持不变，演进只是"把 UDS 换 mTLS、把 SQLite 换 Postgres、把单机驱动扩成多宿主执行节点"。
  • 执行节点必须各自形状一致（每台真实宿主+真实 Chrome），不能用"一台 Linux 起一堆 headless"——那会重蹈 03 的形状矛盾覆辙。

验收检查表（本篇）

  • Run 模型统一承载探索/回放，含准入门与审批点（SC8）。
  • 工作队列支持批量参数化回放、幂等、退避重试。
  • Vault 治理凭据/身份/代理，技能与日志只见占位（I-5/SC8）。
  • 存储模型含技能版本 diff、SiteMemory、Run 留痕。
  • 回放 Token 计量作为 I-4 守门员，异常告警。
  • 接口/schema 稳定，本地→服务化仅换存储与传输。