AI Workspace 为什么诞生：从产品入口到工作闭环
摘要
AI Workspace 并不是把聊天窗口换成更大的侧边栏。它诞生于一个更具体的工程问题：用户希望为了真实工作使用 AI，却不得不在模型、客户端、终端、远程主机和各种会话之间来回搬运上下文。XWorkmate 的方向因此逐步从“提供一个 AI 入口”转向“提供一个可持续的工作入口”。
真实问题
单次 Chat 适合问答，却不自然地承载目标、计划、审批、工具调用、长任务和结果回放。一个任务可能先在 App 中提出，再由 Bridge 转发，交给某个执行器，经过模型连接器调用上游，最后把状态和制品带回用户界面。如果这些环节没有共同的任务标识和证据，用户看到的只是“模型说完成了”。
已确认的产品动机是让 XWorkmate APP 真正运行起来：先把 Console、Bridge、Gateway、模型路由、Vault 和 Terminal 等基础部件打包，再逐步收敛到简洁 App 与可替换执行器。它不要求依赖 Home-Lab；Mac 和其他 Workspace 可以独立运行，并通过授权的异步同步保持进度。
设计变化
早期思路容易把所有能力都塞进一个“万能 Router”：它既选模型，又决定谁执行，还负责会话、权限和重试。后来的规划把职责拆开：App 负责交互与审批，Bridge 负责共享控制面或连接映射，Executor 负责实际工作，Gateway 只负责模型连接，Accounts/Session Center 负责任务状态，记忆层负责可检索上下文。
这也是从 Chat 到 Workspace 的关键变化：产品不再把回答当作唯一结果，而是把请求、选择、审批、执行、事件、回执和可追溯制品视为一个生命周期。
时间线与证据
-
2026-03-10 的 xworkmate-app 初始 Flutter 提交 是可核验的产品起点；3 月 28 日 TaskThread 提交 把工作推进到任务表达。
-
4 月 9 日 Bridge 独立提交 与 4 月 20 日 Hermes ACP 提交 显示连接层和执行协议开始分离；Hermes 与 OpenClaw 是并行探索。
-
5–6 月的 任务隔离产物提交，以及当前 App #296 和 Accounts #212，构成后续实现基线。
-
公开产品文案已把 XWorkmate 描述为连接动态模型路由、多会话 Agent、技能和执行环境的统一工作空间；这是产品定位，不等于全部链路已完成 E2E 验收。
-
仓库已有多会话任务架构文档，明确 Bridge、桌面 App、Accounts 与任务索引之间的边界；这是架构记录。
-
2026-10-12 的白皮书规划进一步提出 App、Bridge、DSH/插件、执行器、可选 Gateway 与三级记忆的目标结构；这是规划输入。
尚未完成事项
仍需用具体提交、PR、测试回执和运行环境确认：哪些执行器已经接通、哪些只存在适配器、跨 Workspace 的同步是否经过授权、断线恢复和真实端到端是否成立。不能用 fork 创建时间替代项目诞生时间，也不能把旧 README 当作当前状态。
相关引用与导航
上一篇：无。下一篇：OpenClaw、Hermes 与 Bridge。
