背景与架构

入口页只负责项目定位和最小摘要；完整背景说明继续看这里。 重点是解释 Mind 为什么要做成现在这个形态，以及控制面、执行面、主要能力方向和云端增强分别承担什么职责。

先判断是不是这页的范围

• 你要理解项目为什么不是传统自动化脚本或 RPA：看这里
• 你要理解 Mind / Helix 和主要能力怎么分：看这里
• 你要理解端侧执行和云端增强为什么分离：看这里
• 你只是想先跑起来或确认能力边界，先回入口页，不必一上来就读完整架构文档

怎么读这页

• 先看“设计原则”和“架构总览”，建立项目骨架
• 再看“能力边界”和“执行闭环与证据链”，理解系统怎么落地执行
• 最后看“云端架构”和“推理集群”，理解增强层为什么不接管端侧执行

设计原则

传统自动化脚本与 RPA 在多工具协作、动态上下文与长期任务上存在断层，执行链路难以复用与回放。

• 执行优先：以工具调用为核心链路，确保任务可落地、可回放
• 约束优先：chat / fast 都是流式对话驱动的 tool_call -> tool_result 闭环；plan 先产出计划，再按步骤顺序执行
• 本地优先：关键决策与执行留在端侧，降低时延与不确定性
• 工程优先：授权、配置、可观测与回收机制齐备

与传统自动化对比： - 传统层面：脚本或流程固定、可复用性弱，跨系统编排成本高，遇到变化容易失效 - 智能代理：以工具协议与编排为核心，支持动态路由与上下文管理，并保留可回放、可追踪的执行证据链

一句话理解：

• Mind 负责控制和编排
• Helix 负责执行和收束
• 云端增强负责更聪明，但不替代端侧确定性执行

架构总览

运行骨架采用 控制面 / 执行面双进程分层，并通过 MCP 工具协议把能力按域组织为可插拔积木，形成稳定的 tool_call -> tool_result 执行闭环。

分层与职责

• 控制面（Mind）：指令解析、会话编排、模型调度、任务路由、模式分流与结果聚合
• 执行面（Helix）：工具注册与发现、调用生命周期管理、域隔离、运行态监测与证据链落盘

补充： - Mind 除了 chat / fast / plan / xtra 四种本地主动执行通道，还提供 agent 订阅入口 - agent 负责向服务端注册会话，并把远端下发任务映射回本地 chat / fast / plan / xtra 执行面 - 具体协议时序、恢复链路和排障不在这页展开，另见 订阅模式

运行架构：

┌────────────┐
│  Mind      │
│  (CLI)     │
└─────┬──────┘
      │
      ▼
┌────────────┐
│  Helix     │
│  (MCP)     │
└─────┬──────┘
      │
      ▼
Tools: 设备与 UI / 协议与校验 / 基础能力 / 多媒体处理

执行通道

• CHAT：流式对话 + 动态工具触发，适合探索、问答、临场协作
• FAST：仍是流式对话闭环，但会裁掉部分设备/UI和重型工具，适合接口、文本、媒体短链路
• PLAN：先生成结构化步骤链，再顺序执行，适合需要可读步骤和更稳路径的任务
• XTRA：连接外接 MCP 服务，适合数据库、浏览器等外部服务协作

能力边界

• 设备与 UI：设备、应用、系统和 UI 动作执行面；对外暴露的是动作型能力，不是底层封装
• 协议与校验：接口协议执行、提取、断言、批量回放，以及性能采样和报告链路
• 基础能力：运行时声明、观测和确定性安全能力
• 多媒体处理：录屏会话、媒体文件处理、抽帧、转码和音轨处理

补充： - 接口能力不是单独的 api 分类，而是归入协议与校验这一类 - 协议能力内部也区分 render / validate / execute 三类边界 - 文档里的接口能力说明，对应的都是协议工具执行面 - 多媒体处理做的是媒体文件与会话处理，不承担内容理解

执行闭环与证据链

执行闭环：

模型生成意图
  ↓
Tool Call
  ↓
Mind 调度
  ↓
Helix 落地执行
  ↓
Enhancer 封装结果
  ↓
Tool Result 回流模型

证据链： - cid / sid 贯穿一次会话或任务 - 日志、媒体、指标、计划统一落盘 - plan 保留结构化步骤与执行证据，便于复盘与审计

协议与传输

• 协议：MCP 工具协议
• 传输：streamable-http
• 鉴权：Bearer Token

云端架构

Mind 的路线是 端侧确定性执行 + 云端智能增强。云端只负责增强认知、策略和治理，不接管确定性执行。

云端职责边界

云端负责： - 检索 / RAG、知识与模板管理、多模型路由、策略下发 - 租户隔离、配额限流、鉴权审计、灰度与版本管理 - Metrics / Tracing / Logs、告警、回归追踪

云端不负责： - 不直接操控端侧设备与执行工具 - 不托管关键执行路径，执行闭环仍由 Helix 承担

参考组件栈

分类	组件
网关	Cloudflare
缓存	Redis
存储	Supabase Postgres + R2
检索	Embedding / Rerank / 向量索引
推理	GPU 容器化推理集群
观测	Metrics / Tracing / Logs
保障	灰度发布 / 金丝雀路由

云端分层

• 执行层（Helix）：MCP 工具宿主与执行闭环，负责运行态监测、健康检查、证据链落盘
• 控制层（AppServerX）：增强与治理中枢，负责模型与工具元数据、策略、检索、网关、安全、缓存、观测和推理编排

示例接口： - Helix：/helix/mcp / /healthz / /ready / /version / /idle

生命周期约定： - Helix 可由 Mind 拉起或独立部署 - 空闲超阈值后自动回收 - 请求和工具调用会刷新 idle 计时

云端增强闭环

请求入口
  ↓
统一鉴权与网关
  ↓
路由与排队
  ↓
GPU 推理集群
  ↓
结果聚合与策略回填
  ↓
指标采集 / 报告生成 / 回归追踪
  ↓
告警与异常归因

设计目标

• 可控：增强可演进，但不破坏端侧确定性执行
• 可观测：端云同链路追踪，与 cid / sid 对齐
• 可治理：租户隔离、配额、灰度、回滚齐备
• 可扩展：模型与检索组件可插拔，推理集群可弹性扩缩容

推理集群

Mind 的云端增强能力由 推理集群 承载，目标是同时覆盖低延迟在线推理和批处理回归。

设计定位

• 在线推理：高并发、低抖动、稳定 P99，面向业务请求与 Agent 增强链路
• 离线批处理：大规模回归、基线对比、数据回灌、模型验证与持续评估

模型矩阵

模型	角色	典型用途
Cross Encoder	重排	工具选择精排、RAG 片段重排、多候选计划收敛
BGE	召回 / 向量表征	语义召回、意图与模板匹配、工具与知识索引
灰度 CNN	结构视觉判别	加载、卡顿、遮罩确认、版式一致性、OCR 前置质量判别
彩色 CNN	色彩视觉判别	提示色识别、主题切换一致性、颜色驱动状态判别
YOLO	目标检测	按钮、弹窗、图标、提示条等 UI 区域定位

组合关系： - BGE 负责召回，Cross Encoder 负责收敛 - 视觉模型负责关键帧状态确认与目标定位，并为设备与 UI 执行提供可视锚点

统一推理流水线

1. BGE 语义召回
2. Cross Encoder 精排
3. 视觉模型做状态确认与目标定位
4. 策略层选择视觉栈与阈值，并定义回退路径
5. 返回增强结果，为端侧执行链提供更稳的决策输入

原则是：云端增强负责更聪明，端侧执行负责更确定。

可观测性

• 与 Mind 的 cid / sid 对齐，实现端云同链路追踪
• 核心指标覆盖延迟、质量、稳定性

工程化能力

• 灰度发布
• 快速回滚
• 压测基准
• 批处理回归对比

工程摘要

• GPU 负责承载多模型并行与混合负载
• 动态路由按任务类型、场景模板和预算门槛选择模型组合
• 质量或延迟异常时支持分段熔断、自愈回退，并保留路由证据
• 常见增强链可模板化复用，并通过回归和成本分级持续优化