不是 multi-agent，是 multi-workspace

OpenAlice产品VS Code工作日志

不是 multi-agent，是 multi-workspace

一段把 OpenAlice 的设计赌注从 "agent" 偏移到 "workspace" 的边想边说。 也是 Cursor / Claude Code / "AI 替你写代码" 这一波热闹之外，我自己的另一种判断。

起点

最开始我只想看一下 OpenAlice 的 web UI session 设计。准备做大幅度的易用性改造，但只能一步步来，从这个手感最直接的地方动起。

可是讨论一展开就发现，session 设计这个表层问题底下挂着一长串没拷紧的抽象。我边想边说，越说越发现自己原来一直没把这件事想透。下面是这一路的思路，记一下，否则下次又要从头想。

第一层：Obsidian 让我看清楚了什么

我先问了一个看似不相关的问题：Obsidian 怎么做到修改 markdown 文件这么实时的？

聊下来发现，Obsidian 的"实时"不是它自己的技术能力——是它脚下站的那块地给的：

  • 文件就是状态。不存在和数据库副本要对账的问题
  • OS-level 的 fs watch 是真免费的，谁改的它都看得见
  • markdown 文件小、parse 廉价、re-render 是幂等的
  • 没有"会话/连接/订阅"概念——状态不在进程里，在磁盘上

Notion 永远做不到这个。它是一个托管的文档 schema 系统，必须自己拥有数据，因为它要保证 embed 的 database/calendar 跨设备一致。代价就是你 cat 不到、grep 不到、git diff 不到、备份等于导出、导出等于丢功能。

那 Obsidian 跟 Notion 的差别本质是什么？我后来意识到一件事：

Obsidian 本质上是一个 workspace 管理器，他只是恰好主要支持 markdown。

它的 plugin 生态能爆是因为大家共享文件系统 substrate——plugin A 写文件、plugin B 读文件，不需要 API contract，文件就是协议。Notion 永远做不到，因为他们 plugin 之间要走 SDK / data model。

第二层：座舱 vs 智能驾驶

那这个 framing 套到 Alice 上是个什么事呢？我开始重新想 OpenAlice 的定位。

这块我之前一直没说清楚的事情是：

OpenAlice 本身虽然是一个 Agent，但她的定位是一个对 workspace 做调度的座舱。 里面各个域的工作可能有自己的 agent 也可能没有，但这不重要，重要的是座舱和智能驾驶本身要分离。

座舱和自动驾驶是两套东西。座舱给你显示状态、给你 throttle 和 yoke；自动驾驶在背后做调度和执行。Alice 是座舱副驾——会跟你对话、能帮你看东西，但不是司机。真正在跑活的是 workspace 里的 domain，它可能跑着自己的 agent loop，也可能完全没有 agent，就是 deterministic 的 task / 状态机 / 用户手操的工具盘。

混在一起的代价我之前没看清——workspace 里的 agent 崩了座舱跟着崩，座舱想看 5 个 workspace 的状态它做不到，agent 之间应该互相隔离但它们共享 cwd。这是个结构性问题，不是产品打磨能解决的。

第三层：multi-conversation 其实是假的

那 chat 这件事呢？正常 chatbot 都有多对话。Alice 现在的 sub-channel 看起来也是。

但我后来想明白这里有个微妙的问题：

不同 sub-channel 之间的共享状态做得非常差。 目前的 chat 其实只是区分了对话上下文，并没有区分 workspace。

举个例子。现在开两个 Claude Code 同时干活，为了避免冲突 Claude Code 会把它们分成两个 worktree。Alice 现在没有这个能力——别说 worktree 了，两个对话真的就只是两个文件而已，并不是两个 workspace。

如果我要跑一些自动量化策略迭代之类的事，目前没办法做区分。所以这里面缺少 workspace 概念的引入。你必须有了这个概念，才能真正去做这种多开对话；否则每个对话只是单独的一个上下文文件，那这功能做了跟没做是一样的。

正常 chatbot 的"新对话"廉价是因为它没有真状态——状态就是 context window，开新对话 = 给个新 window。但 Alice 的对话会触发会改变共享世界的动作：写文件、调 broker、写 brain、跑回测、改 config。所以两个对话同时存在的时候，它们物理上会撞车。

而且——我用过一段时间之后发现，用户想跟同一个 Alice 对话，并不等同于他想在同一个对话上下文内去做对话。比如他突然想聊个新话题，工程本身具有连续性，但他并不需要 Alice 知道之前聊了什么，因为那不重要，现在是在聊一件新的事情。我觉得这种模式才是人和 AI agent 协作的逻辑。

第四层：folder = workspace

那再往前走一步。Obsidian 的结构是"文件即 workspace"，那能不能更进一步——文件夹即 workspace？

这就是 VS Code 的思路。

Obsidian 把"编辑/渲染"限制在单文件内（你不能在 .md 里 grep 整个 vault）。VS Code 把"操作"扩展到了整个 workspace（terminal、tasks、search、debug 都是 workspace-scope）。OpenAlice 应该是 VS Code 这个形态——因为：

  • agent 的工具就是 workspace-scope 的（Read/Write/Bash 都对 cwd 操作）
  • 我们的状态本来就是多文件的（chat + brain + broker config + 产出文件）
  • fs 是天然的隔离边界、可观测面、备份单元

Claude Code 的 worktree 也是这个逻辑——

Claude Code 大部分人也是跑在 IDE 开的 terminal 里面， 也就是说 Claude Code 创建的 worktree 其实是 git 在 terminal 的能力， 而编辑文件是另一个部分的能力。

它没有发明任何隔离机制，它只是站在文件系统这个底座上。隔离能力是文件系统/git 这一层提供的，编辑能力是 LLM + tool 这一层提供的，两层完全正交。

那如果接受 "cwd 即隔离" 这件事，自然往前一步就是文件夹即 workspace。

第五层：UI 和 runtime 必须分离

实操问题来了。Obsidian 是 desktop app。Alice 要不要也做成 desktop app？我对这个真的不熟，人生上一次做能独立运行的可执行文件还是他妈的易语言。

但聊到一半我意识到一个事——VS Code 还有个网页版。

这一点很关键。VS Code 不是"做了个网页版"，是它从根上就把 UI 和 runtime 拆了。这一拆是 Codespaces、Remote SSH、Dev Containers、vscode.dev、github.dev 一整片生态的物理基础。它的几种形态共享同一份 UI 代码：本地 desktop（Electron 包 UI + backend）、Remote SSH（UI 在本地 Electron，runtime 在远端，SSH tunnel 通信）、Codespaces（UI 任意，runtime 在云容器）、vscode.dev（UI 在浏览器，没 runtime，靠 GitHub API 当虚拟 fs）。

那这个 framing 套到 Alice 上其实是替我们解决一个还没意识到正在面对的问题——

Trading 本质需要 24/7 runtime。你笔记本一关，broker 断、cron 不跑、heartbeat 死、自动策略停。这跟 VS Code 完全不一样——VS Code 你关电脑没所谓，Alice 关一夜你 perp 仓位可能就被打爆。

所以"Alice 是个 desktop app"这个想象跟核心场景冲突。真正合理的形态是 VS Code 这套：

  • runtime = service：可以跑在本地、VPS、家用 server / NAS
  • UI = web app：任何浏览器连一个 runtime URL（笔记本、手机、平板）

Tauri 这种桌面包装从此不再是"我们最终要做成桌面应用"的目标，它退化成单机便利包装——给只想本地跑、不会配服务的用户。

第六层：trading = coding

讨论到这里我开始想一个更激进的事——fork VS Code。

这不是开玩笑。我评估了一圈：

我感觉 IDE 把该做的都做差不多了，剩下的就是在 IDE 这个壳上面堆东西。 Multi panel 这种逻辑上最麻烦的部分恰恰是 VS Code 解决过的东西。

但更关键的是这个 framing：

我们做的事情如果做 VS Code extension 又太受限制了。 我们需要的其实是让 Alice 把 Trading 给等效为 Coding， 也就是把 Trading 所需要的流程和资产和上下文像 Coding 一样放在 workspace 里面。

这是一个完全不同的逻辑。

为什么 financial terminal 大概率长得跟 IDE 是一样的？看历史就知道——Bloomberg Terminal 1981 年的版本就是 IDE-shape：多 pane 密度极高、function-based 命令（"equity GP <go>" 本质就是 command palette）、键盘 first、dark theme、多 monitor 撑开布局。IBKR TWS、NinjaTrader、ThinkOrSwim、MultiCharts 全是这个形态。

为什么收敛？因为 trader 的工作和 dev 的工作结构同构：高密度信息、符号导航、需要快速命令、有持久 context、吃 themable + 键盘 first、有"工程"概念（dev 是 repo；trader 是 strategy bundle / 账户组合）。

那 Alice 跟 VS Code 的关系就清楚了：fork 它的壳，自己堆 trading-specific 的 custom editor 和 panel。Cursor 走 fork 是对的，不是因为他们想沾 VS Code 的光，是因为自己造这层壳的 ROI 太负了。

第七层：用户的注意力跟着结果走

为什么我现在敢这么判断？给一个具体例子——

我跟 AI 现在对话的这个 terminal 我已经从 VS Code 里面拽出来了。我根本就没看代码文件。我在这跑纯粹是因为它动代码的话我可以立刻到 VS Code 那边看看情况。

也就是说：

用户在意的东西，他本来就会放在前面。他不在意的东西本来就会扔到后面。 Coding workspace 的修改大部分用户都不在意， 但大部分用户都会在意我开的 20 个 workspace 哪个斗蛐蛐打赢了。

斗蛐蛐这个比喻是认真的。Trader 同时跑 20 个策略，他关心的是哪只赢了——pnl 曲线、回撤、命中率、当前仓位、风控触发。每个 workspace 里 Claude Code 怎么改代码、什么时候 commit、refactor 哪段、跑了几次 backtest——用户不看。除非赢的那只突然输了，才会回头去看过程。

这条原则定义了产品的第一眼：

  • 第一眼如果是 chat → Alice 是 ChatGPT 变种
  • 第一眼如果是 code → Alice 是 Cursor 变种
  • 第一眼如果是 fleet board → Alice 是 trader's 塔台，独此一家

这跟 Bloomberg Terminal 的整个产品 thesis 是一回事：trader 的注意力是稀缺资源，每平方厘米屏幕都得是 actionable 的结果数据。我们差别只在 shell 是 IDE 形态而不是 mainframe 形态。

收敛：不是 multi-agent，是 multi-workspace

经过这一长串折腾，我把所有讨论收敛到一句话：

这个事不是 multi-agent，那个是空词。 我想说的是 multi-workspace，这个东西很重要。 VS Code 就是 file-based workspace 最大的 infra， 然后我只要把别的问题等效转化到 file-based 就完事了。

agent 是动词，workspace 是名词。

agent 是短命的、可替换的、协议复杂的——要协调多 agent 通信你得 invent 一堆协议。workspace 是持久的、可观测的、协议天然的——所有 agent 通过同一文件系统协作，不需要发明新协议。今年 Claude Code 在你 workspace 里跑，明年换 Cursor agent，后年换某个开源的——workspace 不动，agent 来去。

"multi-agent" 是空词的原因就在这——它把不重要的东西（哪个 agent 在跑）抬到台前，把重要的东西（agent 跑在哪个共享状态上）藏起来。

那把别的问题等效转化到 file-based 是什么意思？大概是这样的：

  • 仓位 → positions.json（FileSystemProvider 后挂 broker WS，看起来是文件其实是流）
  • 订单簿 → orderbook://btc-usdt（virtual file，custom editor 渲染成 ladder）
  • 策略 → strategies/momentum.ts（普通代码，Monaco 直接编）
  • 回测报告 → reports/2026-05-03.md（带 frontmatter 的 markdown）
  • chat → chats/*.md（custom editor 渲染成对话）
  • broker config → .alice/connections/okx.json
  • 定时任务 → .alice/tasks.json

文件 schema 一立起来，VS Code 整套 infra 全部为我所用——多 workspace 切换免费、跨 workspace 搜索免费、git 版本化免费、custom editor 渲染各种 trading 视图免费、layout 持久化免费。

这其实把 OpenAlice 的产品定位也钉死了——

它不是"一个 AI 交易 agent"，它是 trading workspace 的 schema + 让这个 schema 在 IDE 里活起来的整套适配。Alice 这个 chatbot 只是 schema 上长出的一个 surface，跟 Claude Code 平起平坐。

这是同样的产品母题：

  • Notion = 文档 schema + 编辑器；agent 不是它的产品定位
  • Obsidian = vault schema + 渲染器；插件来去
  • VS Code = workspace schema + 编辑器；扩展来去
  • OpenAlice = trading workspace schema + IDE shell；agent 来去

"AI 是不是核心"这个问题也解了——AI 不是核心，schema 才是。AI 是用 schema 的方式之一。

写给自己

  1. 边想边说不丢人——他妈开创性的东西真不好做，总得边做边想。但说完得把它整理出来，否则下次又要从头想。
  2. 抓住"用户关心什么"这个原则不动摇——结果优先于过程。第一眼定义产品。
  3. 不要被时髦词带走（multi-agent / agentic / autonomous）——这些词把变量当常量。真正的常量是 workspace 这种长寿命的东西。
  4. 站在巨人肩上不丢人。VS Code 已经做了 95% 的 IDE infra，自己造是 ROI 极差的事。拿来用，把精力花在没人做过的部分。
  5. trading = coding 这个等价不是修辞，是设计纲领。一旦接受这个等价，文件抽象、版本控制、IDE 形态、agent 复用——全都顺了。

下一步是 trading workspace 的最小文件 schema。这是地基，做完所有别的工作都能挂上去。