1Claw：面向多智能体协同的跨端控制中心架构设计
1Claw：面向多智能体协同的跨端控制中心架构设计
介绍 1Claw 这一多智能体跨端控制中心的三层架构设计，涵盖 Profile 隔离与运行时派生、WebSocket 与 JSON 管道两级协议、双域历史持久化与近邻优先上下文合并，并给出原型实现与架构质量评估，适合智能体系统与研发协作工具的架构设计者参考。
1Claw：面向多智能体协同的跨端控制中心架构设计
研究背景与问题
背景：LLM 推动智能体由对话工具演进为软件实体
具备角色设定、长期记忆、工具调用、持续任务能力
用户需同时保留多个智能体角色（研发/写作/检索/规划助手）
期望桌面端与移动端保持一致状态
现有框架：AutoGPT、LangChain、CrewAI
侧重任务分解、工具调用与角色协作
主要形态仍是脚本、链式执行或一次性工作流
缺少面向终端用户的持续控制面：多实例并存、运行时创建副本、跨设备回看历史、取消响应、追加消息、稳定携带上下文
缺口：多智能体持续接入、运行隔离、跨端同步、长会话上下文治理
本文贡献
三层控制中心架构：分离跨端交互、实时路由与智能体执行
基于 Profile 的运行隔离模型：角色模板与运行实例分离，支持运行时 spawn
WebSocket 与 stdin/stdout 两级 JSON 协议：实现确定性消息关联
双域历史持久化 + 近邻优先上下文合并：解决跨端历史与长会话上下文不稳定
定位：1Claw 位于 OpenClaw 与 Hermes Desktop 之上
OpenClaw 更接近智能体内核与工具执行框架
Hermes Desktop 偏向单端交互入口
1Claw 承担多 Profile 运行控制、跨端同步、历史治理与消息路由
三层总体架构
交互层：Flutter Client
负责跨端 UI 与本地状态
Profile 工作台 / Chat Panel / reasoning / queue
维护 Profile 列表、当前会话、草稿、未读状态、流式回复、本地近邻历史
不直接执行智能体逻辑
控制网关层：Go Gateway
系统的控制面
WebSocket Hub / Router / Profile Manager / SQLite
Agent Bridge / REST API
连接注册、消息路由、Profile 查询与创建、消息持久化、事件广播
执行层：Hermes Agent Kernel
具体推理与会话记忆
Profile subprocesses / AIAgent / SessionDB / Tools
一个 Profile 对应一个 Python 子进程运行智能体
层间只通过协议通信，避免 UI、网络、存储与模型调用耦合
设计取舍：牺牲一定进程开销，换取清晰故障边界
某一 Profile 的阻塞、异常或取消不会污染其他 Profile
Profile 隔离与运行时模型
Profile 是 1Claw 的核心抽象
贯穿配置、执行、存储和状态展示的统一标识
包含控制层 ID、底层 Hermes Profile 名称、模型配置、人格设定、会话状态、运行状态
映射为运行实体：子进程、标准输入输出管道、当前状态、会话集合
运行时派生模型：spawn(P_i, k) -> P_i^k = <id_i-k, hermes_profile_i, proc_i^k, sessions_i^k>
派生实例共享底层角色模板，但拥有独立控制 ID、进程空间和会话集合
将“角色定义”与“运行实例”分离，同一人格可并行处理多任务
三层隔离
配置隔离：各 Hermes Profile 目录保存模型配置、环境变量、人格说明
进程隔离：Go 网关经 HermesBridge 启动独立子进程，设置 HERMES_PROFILE 与 HERMES_HOME
会话隔离：请求携带 session_id，wrapper 以 session 为粒度复用 AIAgent 实例
冷启动优化：目录索引 + 懒加载
启动时只扫描 Profile 目录并构建轻量索引（名称/路径/类型/修改时间）
人格文件、长期记忆、模型客户端仅在首次进入或发消息时加载
可交互时间主要受活跃 Profile 数影响，而非 Profile 总数
协议桥接与流式交互
两级协议边界
客户端 ↔ Go 网关：WebSocket JSON
Go 网关 ↔ Hermes 子进程：行分隔 JSON-over-stdin/stdout
以 profile_id、session_id、message_id 维护请求响应关联
Client -> Server 原语
chat：向指定 Profile 发送消息，携带 session_id 与近邻历史
cancel_chat：取消当前 Profile/session 的活动响应
get_profile_history：拉取 Profile 维度跨端历史
delete_message：删除消息并触发多端同步
Server -> Client 原语
thinking：请求已进入智能体执行层
reasoning：返回中间推理或思考增量
chat_chunk：返回正文流式增量
chat：返回最终响应
message_deleted：广播跨端删除事件
进程间统一字段：消息类型、消息 ID、Profile ID、Session ID、业务负载、时间戳
响应事件携带原始消息 ID 与 Profile ID
取消请求携带 Session ID 时校验活动响应归属
保证多 Profile、多端连接、流式事件并存时请求与响应可确定匹配
语义分离：已受理 / 正在推理 / 正文生成中 / 最终完成
客户端收到 thinking 即进入处理状态，chat_chunk 到达时原地更新，最终 chat 到达后落库
比传统请求—响应模式更适合长耗时 LLM 推理
双域历史与上下文治理
双域持久化
conversation-scoped 历史：按 conversation_id 保存消息，用于客户端会话连续
profile-scoped 历史：按 profile_id 保存消息，用于跨设备共享同一 Profile 时间线
二者非替代关系，分别服务「会话边界」与「角色边界」
保存时同时写入两类历史；删除时同时删除两侧并广播删除事件
客户端收到服务端历史后按消息 ID 去重、按时间插入，实现本地缓存与远端历史合并
近邻优先上下文合并
问题：仅用服务端 SessionDB 可能丢失刚发生的对话；仅用客户端本地历史会丢失服务端长期记忆
定义重叠长度：ω = max{k | suffix(H_s,k) ≈ prefix(H_r,k)}
合并历史：H_m = H_s ⊕ tail(H_r, l-ω)
预算裁剪：Context = C(normalize(H_m), U, L, B)
U=10（最多保留最近 10 轮用户回合）、L=2000（单条消息字符上限）、B=12000（总字符预算）
不追求塞入全部历史，而是在有限预算内优先保证近期语义链不断裂
更早内容应通过摘要或检索召回，而非长期常驻模型输入
成本观察
相同代码修改任务中，Profile/session 边界约束可减少无关工作区历史进入上下文
1Claw + DeepSeek V4 Pro 的 token 消耗显著低于 VSCode Copilot + DeepSeek V4 Pro 的通用上下文模式
后者常出现约 5~10 倍 token 消耗差距；该现象仍需统一基准进一步验证
实现与架构评估
原型构成
服务端 1claw-server：internal/ws、internal/agent、internal/store、internal/api、internal/model
客户端 1claw-app：websocket_service.dart、chat_provider.dart、profiles_provider.dart、聊天面板组件
架构质量属性
隔离性：Profile 独立子进程 → 单个智能体故障不扩散；代价是进程数随 Profile 增长
实时性：WebSocket + chat_chunk → 降低感知等待；代价是需处理流式合并
可恢复性：本地缓存 + SQLite 双域历史 → 支持重连和跨端切换；代价是最去重与合并
上下文质量：近邻优先与预算裁剪 → 降低近期上下文丢失；代价是远期记忆需摘要/检索
成本控制：Profile/session 边界约束上下文 → 降低代码修改任务 token 消耗；需持续评估不同任务类型
可扩展性：Agent Bridge 接口 → 可替换智能体后端；协议需保持稳定
可管理性：Profile/Spawn 模型 → 支持运行时实例扩展；模板与实例需分离
原型观测效果
两阶段初始化使可交互时间从全量加载的近似线性增长，转为主要依赖目录索引和少量活跃 Profile 初始化
流式事件使首段回复可早于完整响应呈现
双域持久化使同一 Profile 的历史能够跨设备合并
Profile 子进程隔离使单个智能体异常不会破坏整个网关
清晰上下文边界降低了代码修改类任务中的无效 token 输入
突破点：控制面设计
让多个智能体成为可持续接入、可观测、可恢复和可运行时扩展的软件实体
当前局限
Go 网关仍是单节点控制面
profile-scoped 历史在大规模部署下需要分片或事件日志支持
智能体之间主要通过控制中心间接并存，尚未形成标准 Agent-to-Agent 通信协议
远期记忆还需从固定历史窗口演进为摘要和检索结合的分层记忆体系
结论
以 Profile 为核心抽象，将角色配置、运行进程、会话状态和跨端展示统一起来
以 WebSocket 与 JSON 管道协议建立客户端、网关和智能体进程之间的解耦边界
以双域持久化和近邻优先上下文策略解决跨设备历史与长会话连续性问题
意义：把多智能体系统从一次性任务流程推进为可长期交互的软件运行环境，为面向个人工作流和研发协作的多智能体应用提供可复用的架构范式
Published copy · Updates require review / 公开副本，更新需重新审核。