【免费下载链接】OpenAliceYour one-person Wall Street. An AI trading agent covering equities, crypto, commodities, forex, and macro — from research through position entry, ongoing management, to exit.项目地址https://gitcode.com/gh_mirrors/op/OpenAlice点击查看免费下载本文基于 OpenAlice 仓库default/skills/workspace-manager/SKILL.md编写围绕 launcher 级 Workspace Manager Agent 展开讲解如何从产品索引出发快速建立「责任地图」、区分--resume-id与--ws-id两条对话路径、守住「只协调不代做业务」的边界以及 template upgrade 的 preview-first 变更纪律。读完本文你将掌握用alice peer/alice conversation/alice template系列命令完成楼层审计、定向追问、历史意图重建与受控变更的完整实战套路并理解这些命令背后的源码实现。目录Workspace Manager 是什么起点从产品索引出发而不是全盘爬目录单桌深挖peer 定位与两套对话路径exact 与 reconstructed不可混淆的 provenance 语义同步等待与异步分发--await 的正确用法Manager 拥有协调权不拥有业务文件变更必须预览先行template upgrade 与生命周期操作源码级证据这个 Skill 如何被加载和执行验证清单与常见误区Workspace Manager 是什么OpenAlice 的 Workspace Manager 是一个launcher 级control-planeAgent它不隶属于任何具体业务 Workspace而是站在「活跃工作区楼层」active Workspace floor之上负责审计与协调。它的职责可以概括为三问每个活跃桌desk负责什么哪些工作存在重复哪些 Issue 计划schedule过期、失败或缺少可归属的负责人某条 Inbox 记录或某个历史决策应该由哪条现存 Session 来解释对应的产品级说明见 docs/workspace-manager.md它与 docs/workspace-lifecycle.md、docs/conversation-provenance.md、docs/workspace-agent-guidance.md、docs/workspace-template-upgrade.md 互为参照。这个 Skill 文件default/skills/workspace-manager/SKILL.md是注入给 Manager 运行时的操作契约它不描述「如何写业务报告」而是描述「如何不变成另一张业务桌」——所有命令、路径选择、provenance 语义与预览纪律都在为这个边界服务。起点从产品索引出发而不是全盘爬目录SKILL 的第一个铁律是先看产品索引再做无边界文件系统爬取。Manager 的工作目录就是活跃楼层本身直接子目录就是当前在服务的桌已离场departed的桌已经移走不应在索引中出现。楼层审计的第一步永远是两条命令alice peer list alice issue list --mode detailedalice peer list返回活跃 Workspace 的 id、tags、模板、已配置运行时、Session 总数、实时交互计数、实时 headless 计数以及有限数量的最近可归属 Session 标题与 resume 身份。alice issue list --mode detailed提供跨桌的 Issue 全局读视图在 src/server/cli-commands.ts 中issue组的读取是 GLOBAL 的——list扫描所有 workspace 的标题而写入只落在调用者自己的.alice/issues/。为什么要用索引而不是遍历因为peer list 里的最近 Session 标题本身就是第一版责任地图。SKILL 明确禁止逐目录循环、到处读同一份模板 README、或通过 shell 命令把整个楼层 dump 出来。如果索引存在歧义就明确指出来只深入检查那少数几个真正重要的桌。一次快速、可读的初扫胜过一次穷举式文件爬取。底层实现上peer list对应workspace_list工具src/tool/workspace-list.ts它的工具描述直接写明了使用规则用最近 Session 标题形成首轮责任地图peer path/peer sessions只用于真正需要深挖的选定 Workspace且「缺失的 Workspace 可能是 departed 而不是 deleted」。workspace_list的输入 schema 为空对象z.object({})执行时调用ctx.workspaceInventory()返回活跃楼层清单departed 桌不会出现。单桌深挖peer 定位与两套对话路径当某个桌确实需要深挖时先用 peer 命令把「人」和「位置」定下来alice peer path --id workspaceId alice peer sessions --id workspaceIdpeer path解析某个活跃桌的绝对文件系统位置peer sessions列出该桌的 Session。在 src/server/cli-commands.ts 中peer组的定位被明确注释为「只提供协作地址」Coding Agent 一旦拿到path就用自己原生的文件/搜索/Git 工具工作而不是再靠 CLI 去读写文件。拿到身份之后对话路径有两条区别不是修辞而是语义# 继续某个确切 coworker 及其工作记忆 alice conversation ask --resume-id resumeId --prompt ... --await # 为全新工作招募一个新鲜 coworker alice conversation create --ws-id workspaceId --prompt ... # 显式的历史重建当没有可归属 Session 时 alice conversation create --ws-id workspaceId --prompt ... --reconstruct --await注意 SKILL 中同时出现了conversation ask与conversation create两种写法ask带--resume-id延续确切 coworkercreate带--ws-id在该桌招募新人。CLI 层 src/server/cli-commands.ts 把conversation组映射为conversation_create/conversation_ask/conversation_await/conversation_collect/conversation_read五个工具覆盖「新建—提问—等待—收集—读取」的完整生命周期。两条路径的语义边界--resume-id延续的是确切的 coworker 及其工作记忆答案应报告resolution.mode: exact。--ws-id招募的是该桌的新鲜 worker其回答可能有参考价值但不携带已离场历史主人的记忆。prompt 默认是普通 coworker 消息除非--reconstruct显式要求重建前导reconstruction preamble无论哪种方式新鲜 worker 都不得冒充缺席的所有者。exact 与 reconstructed不可混淆的 provenance 语义当exact与reconstructed的差别影响答案可信度时Manager必须保留并报告resolution.mode。这不是装饰性字段而是 provenance 的承重结构。源码侧conversation工具在 src/tool/conversation.ts 中定义。其公共参数 shapeconversationAskCommonShape第 29-40 行明确标注prompt新 Session 的首个任务或既有 Session 的后续消息trim 后 1~16000 字符agent可选运行时仅用于 reconstructed/fresh 工作——确切 Session 的运行时不可被覆盖timeoutMs可选的 headless 看门狗毫秒数缺省则 Session 无时间限制await是否在服务端等待答复默认 falsereconstruct显式添加工件重建引导默认 false。askWorkspaceConversation的返回中第 127-138 行resolution.mode reconstructed时会附带reason例如explicit-workspaceexact则不带 reason——UI 与 Manager 都必须保留这一区分而不是把一个新鲜 worker 包装成原作者。对应的测试见 src/tool/conversation.spec.ts验证exact/reconstructed模式投影与 src/tool/conversation-artifacts.spec.ts验证仅在显式请求reconstruct: true时才传递重建引导以及「fresh Issue 无稳定 owner 时要求 exact run」的约束。同步等待与异步分发--await 的正确用法SKILL 给出了明确的取舍需要现在就要的短答案加--await服务端轮询等待任务完成轮询间隔在 src/tool/conversation.ts 中为 250ms见AWAIT_POLL_MS。委托工作或多桌并行先分发不带--await拿到taskId之后再用conversation await --task-id id/conversation collect收取答案。awaitConversationTask的实现说明了--await的机制先conversation.read(taskId)只要状态仍是running就按 250ms 间隔轮询直到退出running、超时或任务消失超时返回时会给出提示alice conversation await --task-id taskId供后续续接。这与你直接敲--await拿短答案、或不加--await先拿taskId再收集的模式一一对应。Manager 拥有协调权不拥有业务文件这是 SKILL 的边界条款逐条展开不得在楼层根目录创建报告、Issue 或研究文件。楼层根目录是 control-plane不是任何业务桌。创建持久工件前先选定目标 Workspace。读 peer 文件没问题如果用户授权直接编辑就在目标 Workspace 内编辑、并在该 Workspace 提交commit附上清晰消息——「不得编辑完就离开」edit-and-walk-away 被明确禁止。优先使用已知的、可归属的resumeId。peer list里的最近 Session 标题只是线索只用peer sessions --id去解析少数相关桌的确切身份。否则就从相关 Workspace 用conversation create --ws-id招募 worker仅在缺失历史意图时加--reconstruct且永远不要声称新鲜 worker 携带原 coworker 的记忆。--await只用于「现在就要的短答案」委托或多桌场景先分发、后收集。这套边界在 Manager 的系统提示词中同样是硬约束见下文源码证据。变更必须预览先行template upgrade 与生命周期操作模板对账template reconciliation是预览优先的alice template upgrade --id workspaceId只有在用户明确要求执行这份已评审的变更之后才追加--applyalice template upgrade --id workspaceId --apply同样的原则适用于 offboarding离场、consolidation合并或 purge清理先清点并解释绝不把一次审计请求变成不可逆操作。CLI 注册表 src/server/cli-commands.ts 注释写明「Preview 是默认--apply显式执行已评审的安全操作」template upgrade映射到workspace_template_upgrade工具。SKILL 与 Manager 系统提示词都要求除非用户明确要求该变更否则不得 offboard、merge、purge 或 apply 升级。源码级证据这个 Skill 如何被加载和执行Manager 的运行时契约与 Skill 加载路径都在 src/workspaces/manager-workspace.ts保留身份MANAGER_WORKSPACE_ID workspace-managertag 为Workspace Manager第 10-11 行。它的目录被刻意设为 launcher 根的workspaces/子目录第 19 行不进workspaces.json与普通WorkspaceRegistry——避免库存自指、避免隐藏 peer 桌、避免把活跃桌与状态/配置混在 launcher 根下。产品侧对应 docs/workspace-manager.md 的 Identity and Cwd 章节。系统契约MANAGER_SYSTEM_PROMPT第 30-49 行把 SKILL 的要点固化成了「Operating contract」用aliceCLI 而非裸 localhost API首轮必须只用结构化产品索引peer list / issue list--resume-id延续确切 coworker、--ws-id招募新人、--reconstruct仅在缺失历史意图时使用禁止批量爬目录先预览再变更直接编辑必须在该 Workspace 内 commit。注入方式Pi 的结构化 WebPi 面把契约作为系统提示词追加managerTerminalPrompt第 57-59 行原生 TUI 没有统一的 system-prompt flag所以把契约放进 fresh interactive seed。Skill 目录通过managerSkillPath第 61-62 行解析到default/skills/workspace-managerPi 每次 Web 启动含重启后 resume都会加载它。对话运行时Manager Session 与 resume 身份仍使用普通持久化注册表reserved id 之下其无密钥的 AI 启动文件位于launcherRoot/state/workspace-manager-sessions/resumeId.json不得在活跃楼层根创建.alice/普通业务 Session 的启动文件仍归各自 Workspace 的.alice/sessions/resumeId.json所有。UI 面Chat 侧边栏提供独立的可折叠入口ui/src/components/workspace/ChatWorkspaceSection.tsx其子项复用普通 Session 的 open / stop / resume / delete 控件Manager 页面ui/src/pages/WorkspaceManagerPage.tsx拥有管理专属的 quick start而不是第二个 recent-conversation 列表。运行时选择器与 Quick Chat 共用同一个 Agent 列表、保存的默认值、安装状态、就绪度、凭据、模型与上下文契约——useAgentLaunchConfig负责该解析AgentLaunchControls组件在两个表面复用ui/src/hooks/useAgentLaunchConfig.ts、ui/src/components/workspace/AgentLaunchControls.tsx。跨桌保护Manager 可以读所有 peer但既有命令级保护仍然生效——跨 Workspace 的变更需要交互式 Manager Sessiontemplate apply 保持预览优先。验证清单与常见误区SKILL 对应的验证来自 docs/workspace-manager.md 的 Verification 章节至少包括npx tsc --noEmit cd ui npx tsc -b pnpm vitest run src/tool/workspace-list.spec.ts \ src/workspaces/adapters/ai-config.spec.ts \ src/webui/routes/workspaces.spec.ts随后在真实/chat/manager路由上至少两个可用运行时验证运行时/provider 选择器与 Quick Chat 一致并保留保存的默认值Pi/OpenCode 上显示的 model/context 与 Manager Workspace 配置一致、切换 provider 后启动使用新值分别启动一个 Pi/Web 与一个原生 TUI Manager Session再从 Chat 侧边栏的可折叠 Manager 列表重新打开两者用真实peer list工具清点活跃楼层对比--ws-id重建与--resume-id延续的 resolution mode 可见性预览一次不含--apply的模板升级确认楼层根没有出现任何业务工件从侧边栏停/启每个 Session、确认暂停页不自动启动、再通过确认删除一个可弃 Session重载 Manager 对话并确认同一 resume 身份可打开。实践中最常见的三个误区把--reconstruct当默认它只在「必须重建缺失的历史意图」时使用普通新任务直接--ws-id即可且新鲜 worker 永远不能冒充原作者。把「缺席桌」当「已删除桌」departed Workspace 刻意不在楼层索引中出现应按生命周期状态查询而不是直接下「未知/删除」结论。把审计请求升级成变更inventory 与 explain 是审计offboard、merge、purge、apply 是变更。两者之间隔着一道「用户明确要求执行」的闸门。小结Workspace Manager 的 SKILL 把「协调者」与「业务桌」的边界落实为一组可执行的命令纪律索引优先于爬取、resume-id优先于ws-id、reconstructed永远显式标注、预览先于--apply、持久工件永远落在选定的目标 Workspace 内。无论是想自动化楼层审计还是为多桌协作接入对话委托这套契约都值得直接复用于你自己的 Agent 配置——而它背后的实现证据保留身份、系统提示词、CLI 注册表与工具 schema都可以在src/workspaces/manager-workspace.ts、src/server/cli-commands.ts、src/tool/conversation.ts 与 src/tool/workspace-list.ts 中逐行核对。赞分享【免费下载链接】OpenAliceYour one-person Wall Street. An AI trading agent covering equities, crypto, commodities, forex, and macro — from research through position entry, ongoing management, to exit.项目地址https://gitcode.com/gh_mirrors/op/OpenAlice点击查看免费下载相关推荐OpenAlice 交易执行指南alice-uta CLI 的账户、合约、订单与交易即 Git 审批流OpenAlice 交易执行指南 alice uta CLI 的账户、合约、订单与交易即 Git 审批流 alice uta 是 OpenAlice 放在 sData Formulator 工作区存储架构深度解析磁盘布局、Manager/Workspace 双层设计与三种后端模式Data Formulator 工作区存储架构深度解析磁盘布局、Manager/Workspace 双层设计与三种后端模式 本篇技术指南以 Data Form数据可视化人工智能AI 应用数据分析前端后端AI AgentToolJet 工作区Workspace完全指南层级结构、权限模型与多工作区管理ToolJet 工作区Workspace完全指南层级结构、权限模型与多工作区管理 本篇技术指南围绕 ToolJet 的多工作区Multi Workspa低代码后端前端AI 应用MCP 服务上一篇LifeOS 学术论文摘要模式summarize_paper让 LLM 以审稿人视角结构化解读论文下一篇Friend 后端整账号批量迁移Account Cutover架构解析状态机、代际栅栏与故障安全访问控制创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
OpenAlice Workspace Manager：用 alice CLI 审计与协调活跃工作区楼层（SKILL 全解析）
【免费下载链接】OpenAliceYour one-person Wall Street. An AI trading agent covering equities, crypto, commodities, forex, and macro — from research through position entry, ongoing management, to exit.项目地址https://gitcode.com/gh_mirrors/op/OpenAlice点击查看免费下载本文基于 OpenAlice 仓库default/skills/workspace-manager/SKILL.md编写围绕 launcher 级 Workspace Manager Agent 展开讲解如何从产品索引出发快速建立「责任地图」、区分--resume-id与--ws-id两条对话路径、守住「只协调不代做业务」的边界以及 template upgrade 的 preview-first 变更纪律。读完本文你将掌握用alice peer/alice conversation/alice template系列命令完成楼层审计、定向追问、历史意图重建与受控变更的完整实战套路并理解这些命令背后的源码实现。目录Workspace Manager 是什么起点从产品索引出发而不是全盘爬目录单桌深挖peer 定位与两套对话路径exact 与 reconstructed不可混淆的 provenance 语义同步等待与异步分发--await 的正确用法Manager 拥有协调权不拥有业务文件变更必须预览先行template upgrade 与生命周期操作源码级证据这个 Skill 如何被加载和执行验证清单与常见误区Workspace Manager 是什么OpenAlice 的 Workspace Manager 是一个launcher 级control-planeAgent它不隶属于任何具体业务 Workspace而是站在「活跃工作区楼层」active Workspace floor之上负责审计与协调。它的职责可以概括为三问每个活跃桌desk负责什么哪些工作存在重复哪些 Issue 计划schedule过期、失败或缺少可归属的负责人某条 Inbox 记录或某个历史决策应该由哪条现存 Session 来解释对应的产品级说明见 docs/workspace-manager.md它与 docs/workspace-lifecycle.md、docs/conversation-provenance.md、docs/workspace-agent-guidance.md、docs/workspace-template-upgrade.md 互为参照。这个 Skill 文件default/skills/workspace-manager/SKILL.md是注入给 Manager 运行时的操作契约它不描述「如何写业务报告」而是描述「如何不变成另一张业务桌」——所有命令、路径选择、provenance 语义与预览纪律都在为这个边界服务。起点从产品索引出发而不是全盘爬目录SKILL 的第一个铁律是先看产品索引再做无边界文件系统爬取。Manager 的工作目录就是活跃楼层本身直接子目录就是当前在服务的桌已离场departed的桌已经移走不应在索引中出现。楼层审计的第一步永远是两条命令alice peer list alice issue list --mode detailedalice peer list返回活跃 Workspace 的 id、tags、模板、已配置运行时、Session 总数、实时交互计数、实时 headless 计数以及有限数量的最近可归属 Session 标题与 resume 身份。alice issue list --mode detailed提供跨桌的 Issue 全局读视图在 src/server/cli-commands.ts 中issue组的读取是 GLOBAL 的——list扫描所有 workspace 的标题而写入只落在调用者自己的.alice/issues/。为什么要用索引而不是遍历因为peer list 里的最近 Session 标题本身就是第一版责任地图。SKILL 明确禁止逐目录循环、到处读同一份模板 README、或通过 shell 命令把整个楼层 dump 出来。如果索引存在歧义就明确指出来只深入检查那少数几个真正重要的桌。一次快速、可读的初扫胜过一次穷举式文件爬取。底层实现上peer list对应workspace_list工具src/tool/workspace-list.ts它的工具描述直接写明了使用规则用最近 Session 标题形成首轮责任地图peer path/peer sessions只用于真正需要深挖的选定 Workspace且「缺失的 Workspace 可能是 departed 而不是 deleted」。workspace_list的输入 schema 为空对象z.object({})执行时调用ctx.workspaceInventory()返回活跃楼层清单departed 桌不会出现。单桌深挖peer 定位与两套对话路径当某个桌确实需要深挖时先用 peer 命令把「人」和「位置」定下来alice peer path --id workspaceId alice peer sessions --id workspaceIdpeer path解析某个活跃桌的绝对文件系统位置peer sessions列出该桌的 Session。在 src/server/cli-commands.ts 中peer组的定位被明确注释为「只提供协作地址」Coding Agent 一旦拿到path就用自己原生的文件/搜索/Git 工具工作而不是再靠 CLI 去读写文件。拿到身份之后对话路径有两条区别不是修辞而是语义# 继续某个确切 coworker 及其工作记忆 alice conversation ask --resume-id resumeId --prompt ... --await # 为全新工作招募一个新鲜 coworker alice conversation create --ws-id workspaceId --prompt ... # 显式的历史重建当没有可归属 Session 时 alice conversation create --ws-id workspaceId --prompt ... --reconstruct --await注意 SKILL 中同时出现了conversation ask与conversation create两种写法ask带--resume-id延续确切 coworkercreate带--ws-id在该桌招募新人。CLI 层 src/server/cli-commands.ts 把conversation组映射为conversation_create/conversation_ask/conversation_await/conversation_collect/conversation_read五个工具覆盖「新建—提问—等待—收集—读取」的完整生命周期。两条路径的语义边界--resume-id延续的是确切的 coworker 及其工作记忆答案应报告resolution.mode: exact。--ws-id招募的是该桌的新鲜 worker其回答可能有参考价值但不携带已离场历史主人的记忆。prompt 默认是普通 coworker 消息除非--reconstruct显式要求重建前导reconstruction preamble无论哪种方式新鲜 worker 都不得冒充缺席的所有者。exact 与 reconstructed不可混淆的 provenance 语义当exact与reconstructed的差别影响答案可信度时Manager必须保留并报告resolution.mode。这不是装饰性字段而是 provenance 的承重结构。源码侧conversation工具在 src/tool/conversation.ts 中定义。其公共参数 shapeconversationAskCommonShape第 29-40 行明确标注prompt新 Session 的首个任务或既有 Session 的后续消息trim 后 1~16000 字符agent可选运行时仅用于 reconstructed/fresh 工作——确切 Session 的运行时不可被覆盖timeoutMs可选的 headless 看门狗毫秒数缺省则 Session 无时间限制await是否在服务端等待答复默认 falsereconstruct显式添加工件重建引导默认 false。askWorkspaceConversation的返回中第 127-138 行resolution.mode reconstructed时会附带reason例如explicit-workspaceexact则不带 reason——UI 与 Manager 都必须保留这一区分而不是把一个新鲜 worker 包装成原作者。对应的测试见 src/tool/conversation.spec.ts验证exact/reconstructed模式投影与 src/tool/conversation-artifacts.spec.ts验证仅在显式请求reconstruct: true时才传递重建引导以及「fresh Issue 无稳定 owner 时要求 exact run」的约束。同步等待与异步分发--await 的正确用法SKILL 给出了明确的取舍需要现在就要的短答案加--await服务端轮询等待任务完成轮询间隔在 src/tool/conversation.ts 中为 250ms见AWAIT_POLL_MS。委托工作或多桌并行先分发不带--await拿到taskId之后再用conversation await --task-id id/conversation collect收取答案。awaitConversationTask的实现说明了--await的机制先conversation.read(taskId)只要状态仍是running就按 250ms 间隔轮询直到退出running、超时或任务消失超时返回时会给出提示alice conversation await --task-id taskId供后续续接。这与你直接敲--await拿短答案、或不加--await先拿taskId再收集的模式一一对应。Manager 拥有协调权不拥有业务文件这是 SKILL 的边界条款逐条展开不得在楼层根目录创建报告、Issue 或研究文件。楼层根目录是 control-plane不是任何业务桌。创建持久工件前先选定目标 Workspace。读 peer 文件没问题如果用户授权直接编辑就在目标 Workspace 内编辑、并在该 Workspace 提交commit附上清晰消息——「不得编辑完就离开」edit-and-walk-away 被明确禁止。优先使用已知的、可归属的resumeId。peer list里的最近 Session 标题只是线索只用peer sessions --id去解析少数相关桌的确切身份。否则就从相关 Workspace 用conversation create --ws-id招募 worker仅在缺失历史意图时加--reconstruct且永远不要声称新鲜 worker 携带原 coworker 的记忆。--await只用于「现在就要的短答案」委托或多桌场景先分发、后收集。这套边界在 Manager 的系统提示词中同样是硬约束见下文源码证据。变更必须预览先行template upgrade 与生命周期操作模板对账template reconciliation是预览优先的alice template upgrade --id workspaceId只有在用户明确要求执行这份已评审的变更之后才追加--applyalice template upgrade --id workspaceId --apply同样的原则适用于 offboarding离场、consolidation合并或 purge清理先清点并解释绝不把一次审计请求变成不可逆操作。CLI 注册表 src/server/cli-commands.ts 注释写明「Preview 是默认--apply显式执行已评审的安全操作」template upgrade映射到workspace_template_upgrade工具。SKILL 与 Manager 系统提示词都要求除非用户明确要求该变更否则不得 offboard、merge、purge 或 apply 升级。源码级证据这个 Skill 如何被加载和执行Manager 的运行时契约与 Skill 加载路径都在 src/workspaces/manager-workspace.ts保留身份MANAGER_WORKSPACE_ID workspace-managertag 为Workspace Manager第 10-11 行。它的目录被刻意设为 launcher 根的workspaces/子目录第 19 行不进workspaces.json与普通WorkspaceRegistry——避免库存自指、避免隐藏 peer 桌、避免把活跃桌与状态/配置混在 launcher 根下。产品侧对应 docs/workspace-manager.md 的 Identity and Cwd 章节。系统契约MANAGER_SYSTEM_PROMPT第 30-49 行把 SKILL 的要点固化成了「Operating contract」用aliceCLI 而非裸 localhost API首轮必须只用结构化产品索引peer list / issue list--resume-id延续确切 coworker、--ws-id招募新人、--reconstruct仅在缺失历史意图时使用禁止批量爬目录先预览再变更直接编辑必须在该 Workspace 内 commit。注入方式Pi 的结构化 WebPi 面把契约作为系统提示词追加managerTerminalPrompt第 57-59 行原生 TUI 没有统一的 system-prompt flag所以把契约放进 fresh interactive seed。Skill 目录通过managerSkillPath第 61-62 行解析到default/skills/workspace-managerPi 每次 Web 启动含重启后 resume都会加载它。对话运行时Manager Session 与 resume 身份仍使用普通持久化注册表reserved id 之下其无密钥的 AI 启动文件位于launcherRoot/state/workspace-manager-sessions/resumeId.json不得在活跃楼层根创建.alice/普通业务 Session 的启动文件仍归各自 Workspace 的.alice/sessions/resumeId.json所有。UI 面Chat 侧边栏提供独立的可折叠入口ui/src/components/workspace/ChatWorkspaceSection.tsx其子项复用普通 Session 的 open / stop / resume / delete 控件Manager 页面ui/src/pages/WorkspaceManagerPage.tsx拥有管理专属的 quick start而不是第二个 recent-conversation 列表。运行时选择器与 Quick Chat 共用同一个 Agent 列表、保存的默认值、安装状态、就绪度、凭据、模型与上下文契约——useAgentLaunchConfig负责该解析AgentLaunchControls组件在两个表面复用ui/src/hooks/useAgentLaunchConfig.ts、ui/src/components/workspace/AgentLaunchControls.tsx。跨桌保护Manager 可以读所有 peer但既有命令级保护仍然生效——跨 Workspace 的变更需要交互式 Manager Sessiontemplate apply 保持预览优先。验证清单与常见误区SKILL 对应的验证来自 docs/workspace-manager.md 的 Verification 章节至少包括npx tsc --noEmit cd ui npx tsc -b pnpm vitest run src/tool/workspace-list.spec.ts \ src/workspaces/adapters/ai-config.spec.ts \ src/webui/routes/workspaces.spec.ts随后在真实/chat/manager路由上至少两个可用运行时验证运行时/provider 选择器与 Quick Chat 一致并保留保存的默认值Pi/OpenCode 上显示的 model/context 与 Manager Workspace 配置一致、切换 provider 后启动使用新值分别启动一个 Pi/Web 与一个原生 TUI Manager Session再从 Chat 侧边栏的可折叠 Manager 列表重新打开两者用真实peer list工具清点活跃楼层对比--ws-id重建与--resume-id延续的 resolution mode 可见性预览一次不含--apply的模板升级确认楼层根没有出现任何业务工件从侧边栏停/启每个 Session、确认暂停页不自动启动、再通过确认删除一个可弃 Session重载 Manager 对话并确认同一 resume 身份可打开。实践中最常见的三个误区把--reconstruct当默认它只在「必须重建缺失的历史意图」时使用普通新任务直接--ws-id即可且新鲜 worker 永远不能冒充原作者。把「缺席桌」当「已删除桌」departed Workspace 刻意不在楼层索引中出现应按生命周期状态查询而不是直接下「未知/删除」结论。把审计请求升级成变更inventory 与 explain 是审计offboard、merge、purge、apply 是变更。两者之间隔着一道「用户明确要求执行」的闸门。小结Workspace Manager 的 SKILL 把「协调者」与「业务桌」的边界落实为一组可执行的命令纪律索引优先于爬取、resume-id优先于ws-id、reconstructed永远显式标注、预览先于--apply、持久工件永远落在选定的目标 Workspace 内。无论是想自动化楼层审计还是为多桌协作接入对话委托这套契约都值得直接复用于你自己的 Agent 配置——而它背后的实现证据保留身份、系统提示词、CLI 注册表与工具 schema都可以在src/workspaces/manager-workspace.ts、src/server/cli-commands.ts、src/tool/conversation.ts 与 src/tool/workspace-list.ts 中逐行核对。赞分享【免费下载链接】OpenAliceYour one-person Wall Street. An AI trading agent covering equities, crypto, commodities, forex, and macro — from research through position entry, ongoing management, to exit.项目地址https://gitcode.com/gh_mirrors/op/OpenAlice点击查看免费下载相关推荐OpenAlice 交易执行指南alice-uta CLI 的账户、合约、订单与交易即 Git 审批流OpenAlice 交易执行指南 alice uta CLI 的账户、合约、订单与交易即 Git 审批流 alice uta 是 OpenAlice 放在 sData Formulator 工作区存储架构深度解析磁盘布局、Manager/Workspace 双层设计与三种后端模式Data Formulator 工作区存储架构深度解析磁盘布局、Manager/Workspace 双层设计与三种后端模式 本篇技术指南以 Data Form数据可视化人工智能AI 应用数据分析前端后端AI AgentToolJet 工作区Workspace完全指南层级结构、权限模型与多工作区管理ToolJet 工作区Workspace完全指南层级结构、权限模型与多工作区管理 本篇技术指南围绕 ToolJet 的多工作区Multi Workspa低代码后端前端AI 应用MCP 服务上一篇LifeOS 学术论文摘要模式summarize_paper让 LLM 以审稿人视角结构化解读论文下一篇Friend 后端整账号批量迁移Account Cutover架构解析状态机、代际栅栏与故障安全访问控制创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
