OCWS：为一人公司和多机器人协作设计的轻量工作空间协议

OCWS：为一人公司和多机器人协作设计的轻量工作空间协议

引言

如果你正在尝试让多个 AI Agent 或机器人长期协作，通常很快会遇到一个问题：

大家都在“能做事”，但系统却越来越难管理。

任务从哪里进入？谁负责规划？谁负责执行？谁负责监督？结果写到哪里？失败怎么回滚？历史怎么追溯？如果这些问题没有统一答案，再强的模型也会在协作过程中逐渐失序。

我做 OCWS，就是想解决这个问题。

OCWS 的全称可以理解为 OpenClaw Workspace Specification。它不是一个复杂平台，也不是一个新的 orchestration framework，而是一套面向多机器人协作的共享工作空间协议。它基于目录结构、文档规范和通知机制，试图用最轻量的方式，为项目、任务和机器人之间建立清晰的协作边界。

这篇文章会系统介绍 OCWS 的设计背景、核心思想、目录模型、状态流转、角色分工、适用边界和演进方向。我希望把它作为一个开源思路抛出来，看看社区是否也遇到类似问题，以及这条路线是否值得继续打磨。

为什么会有这个项目

这不是“项目管理工具”的问题，而是“协作协议”的问题

很多 Agent 系统在 Demo 阶段都很顺畅：给一个任务，模型执行，得到结果。

但一旦进入更长期的使用场景，问题会立刻出现：

• 多个任务同时存在，彼此上下文混在一起
• 多个机器人或 Agent 角色开始分工，但边界并不稳定
• 执行记录散落在聊天记录、脚本输出和临时文件里
• 同一个任务的状态同时存在于多个地方，越来越难判断哪个才是真的
• 结果产物虽然生成了，但回头很难知道它是怎么来的

这里真正缺的，往往不是“更强的模型”，而是一个足够稳定的协作协议。

我面对的是“一人公司 + 多机器人”的场景

OCWS 并不是为大团队协作设计的。

它最初针对的是一个很具体的场景：一人公司。
在这个模型里，除了我本人外，没有其他人类同事，其余协作者都是我定义职责边界的小龙虾机器人。

这些机器人不是泛化的“万能助手”，而是角色明确的工作单元，例如：

• 规划者：负责任务规划、拆解、排期和推进
• 执行者：负责任务执行和产出生成
• 监督者：负责过程监督、检查偏差和跟踪风险
• 审计者：负责验收、复核、审计和归档建议

这意味着我有一个非常适合协议化的前提：

• 角色可以被我清晰定义
• 规则可以被强执行
• 管理规模可控
• 我不需要为了组织复杂度去引入重平台

从这个角度看，OCWS 更像是一套数字组织操作系统，而不只是一个目录规范。

为什么不直接上更重的系统

社区里已经有很多现成方向：

• 项目管理系统
• workflow engine
• Agent orchestration framework
• 数据库驱动的任务平台
• 带 UI 的控制面系统

这些方案并非不好，但它们通常默认了几件事：

• 需要较大的协作规模
• 需要较多结构化运行时数据
• 需要长期维护平台能力
• 需要先接受一套既定抽象

对于我当前的场景，这些成本并不划算。

我真正想先解决的是下面这些更基础的问题：

• 项目资料应该放在哪
• 任务实体应该放在哪
• 机器人如何收到新任务
• 处理中和已完成如何表达
• 结果应该如何回写
• 历史应该如何保留

如果这些边界都还没有稳定，过早上复杂平台，最后大概率只是把混乱封装起来，而不是把问题解决掉。

所以 OCWS 的核心判断是：

先建立协作秩序，再引入自动化能力。

OCWS 的核心设计目标

OCWS 不是追求“最强功能”，而是追求“最稳边界”。

它当前的设计目标主要有 6 个：

1. 用统一目录结构承载项目、任务和机器人协作
2. 用规则文档定义命名、状态和通知协议
3. 用模板降低任务创建和回写的格式成本
4. 用通知文件驱动机器人协作，而不是让机器人直接篡改任务结构
5. 保持人工可读，便于从小规模开始运行
6. 为后续自动化保留清晰升级路径

换句话说，OCWS 当前想做的不是一个平台，而是一层Workspace Protocol。

核心设计理念

1. 项目实体和机器人工作流分离

这是 OCWS 最关键的设计决定之一。

在很多临时化的 Agent 协作系统里，任务经常直接跟着某个执行者走，久而久之，任务信息就会散落在不同机器人自己的目录或上下文里，导致追溯困难。

OCWS 的做法是：

• 项目和任务的事实信息留在项目目录
• 机器人目录只负责收件、执行和状态流转
• 机器人通过通知文件与项目任务建立联系

这样做的好处很明确：

• 任务上下文不会因为执行者变化而丢失
• 多机器人协作时职责边界更清楚
• 审计和复盘可以回到统一的任务事实源

2. 通知文件是指针，不是任务副本

OCWS 明确反对把完整任务正文复制到机器人收件箱里。

通知文件的职责是“分发”，不是“存储任务主体”。
它只需要携带最小必要信息，例如：

• 任务 ID
• 项目路径
• 任务路径
• 分配对象
• 优先级
• 状态
• 结果回写路径

这背后的考虑非常现实：

如果通知文件也存一份任务正文，项目目录里再存一份任务正文，那么只要任务中途被修改，系统很快就会出现多个版本。对机器人系统来说，状态分叉比“字段少一点”更危险。

3. 先用 Markdown 和目录跑通，再考虑结构化自动化

我没有在第一版就强行上数据库，也没有先定义一套复杂的 API。

原因不是这些东西不重要，而是因为在当前阶段：

• 目录和文档更容易讨论
• Markdown 更容易人工检查
• 共享文件系统的成本最低
• 真正的问题还在协作结构，而不是吞吐量

这套思路不是“永远拒绝自动化”，而是明确分阶段：

• 第一阶段：目录 + Markdown + 通知文件
• 第二阶段：补元数据，如 status.json、meta.yaml
• 第三阶段：增加自动派发、状态校验、统计和审计脚本
• 第四阶段：如有必要，再演化为更强的控制面

4. 规则先于工具

很多系统失败，不是因为工具不够多，而是因为规则根本没定清楚。

OCWS 选择先把规则写成文档，原因很简单：

• 命名不统一，后续无法自动解析
• 状态不统一，后续无法统一流转
• 通知字段不统一，后续无法稳定分发
• 模板不统一，后续无法沉淀可复用流程

所以在项目中，我先建立了以下规则层：

• 命名规范
• 任务状态流转规范
• 通知文件字段规范

同时建立了：

• 项目说明模板
• 任务说明模板
• 通知模板
• 结果回填模板

这套规范层本身，就是 OCWS 最重要的资产之一。

OCWS 的目录模型

当前版本的 OCWS 使用三层主结构：

OCWS/
├── 00-system/
│   ├── rules/
│   ├── templates/
│   └── robots/
├── 10-projects/
└── 20-robots/

00-system/

系统级公共目录，用于保存所有跨项目、跨机器人共享的规则、模板和注册信息。

它的职责不是保存运行时状态，而是提供稳定的底层协议。

其中：

• rules/ 定义命名规范、状态流转、通知字段等规则
• templates/ 定义项目、任务、通知、结果回填的标准模板
• robots/ 用于描述机器人角色、能力边界和职责说明

10-projects/

项目目录是任务事实源所在层。

项目目录下会包含：

• 项目说明
• 共享输入资料
• 共享输出成果
• 项目下的任务目录
• 历史归档内容

每个任务目录都拥有自己的：

• task.md
• input/
• workspace/
• output/
• logs/

这意味着任务不仅有说明，还有执行过程和交付物的结构化承载位置。

20-robots/

机器人目录是每个角色化机器人自己的工作入口。

每个机器人可以有如下目录：

• inbox/：待处理通知
• working/：处理中通知
• done/：已完成通知
• failed/：失败通知
• cache/：可丢弃缓存

注意，这些目录不是任务事实源，而是工作流视图。

核心协议机制

1. 命名协议

为了让目录能被人工识别，也能被脚本解析，OCWS 当前采用统一命名规则：

• 项目：PRJ-001-demo/
• 任务：TASK-001-research/
• 通知：NOTICE-TASK-001-research.md
• 机器人：robot-coder/

这种命名方式看起来朴素，但它非常重要，因为：

• 目录天然可排序
• 对象类型一眼可见
• 脚本容易解析和校验
• 后续引用更稳定

2. 状态协议

任务状态统一为：

• new
• assigned
• working
• done
• failed
• archived

标准流转路径为：

new -> assigned -> working -> done -> archived
                       └------> failed
failed -> assigned
failed -> archived

这套状态流转的关键不是“状态名字”，而是它定义了系统行为：

• 什么时候允许机器人领取
• 什么时候必须回写结果
• 什么时候需要人工介入
• 什么时候任务已经退出活动集

3. 单一事实源

在 OCWS 里，我刻意强调一条规则：

任务最终事实源是项目目录中的 task.md。

机器人目录中的通知文件只是分发视图，不是最终事实源。

这条规则可以显著减少系统内的状态分叉问题。
否则一旦通知文件和任务文档都在不断变化，最终谁都说不清哪个状态是真的。

4. 通知驱动

机器人不是去扫描整个项目目录找活，而是只看自己的通知目录。

一个典型通知至少包含：

• notice_id
• task_id
• project_id
• project_path
• task_path
• assignee_robot
• priority
• status
• result_path

这种设计让任务的“事实存储”和“执行分发”分开了，也让机器人职责边界更明确。

为什么这个模型适合一人公司

如果这是一个大团队项目，我对 OCWS 的态度会更谨慎，因为大团队最大的问题往往是规则执行不一致。

但在一人公司的语境里，情况完全不同。

1. 规则可以强执行

人类团队里，规则经常会沦为“建议”。
而在你的使用场景里，机器人角色、模板、状态、输入输出都可以被明确限制。

这意味着 OCWS 的规则不是参考文档，而是真正的运行协议。

2. 规模可控，不需要为遥远未来过度设计

如果项目和任务数量不会爆炸增长，那么：

• Markdown 仍然可管理
• 共享目录仍然可检索
• 人工监督成本仍然可接受
• 不需要提前引入复杂平台

这会让系统保持非常高的投入产出比。

3. 角色分工天然适合协议化

你已经定义了规划者、执行者、监督者、审计者等角色。

这些角色有几个特点：

• 输入输出清晰
• 职责可拆分
• 行为可约束
• 流转可定义

这正是协议化系统最需要的条件。

一个典型工作流会怎么运转

为了更具体说明 OCWS 的意义，可以看一个简化流程。

场景：启动一个内容生成项目

1. 规划者创建项目 PRJ-001-content-pipeline
2. 在项目下拆出若干任务，例如：
   • TASK-001-topic-research
   • TASK-002-outline-design
   • TASK-003-article-draft
3. 规划者为 TASK-001-topic-research 生成通知文件
4. 通知文件进入 20-robots/robot-writer/inbox/
5. 执行者领取任务，通知文件移动到 working/
6. 任务执行过程中产生的材料写入任务目录中的 workspace/ 和 output/
7. 完成后，任务结果回写到 task.md，通知文件进入 done/
8. 监督者或审计者根据任务输出进行检查，决定是否接受、打回或归档

这里最有价值的不是“流程很多”，而是每一步都有明确位置和责任归属。

这套方案解决了什么问题

从工程角度看，OCWS 主要解决以下问题：

1. 任务归属问题

任务实体在项目目录中，不再跟着执行机器人四处漂移。

2. 责任边界问题

规划、执行、监督、审计这些角色都可以围绕统一目录协议协作，而不是靠口头约定。

3. 状态一致性问题

通过状态流转规范和单一事实源原则，降低多处状态不一致的概率。

4. 历史追溯问题

项目目录、任务目录、输出物和通知文件可以共同形成可追溯链路。

5. 自动化升级问题

由于命名、状态和字段都被规范化，后续引入脚本和工具的门槛大幅降低。

我认为它不适合什么场景

任何设计都应该明确边界，OCWS 也一样。

它当前不适合这些场景：

• 大量并发任务、高吞吐实时调度场景
• 需要复杂权限控制和组织审批流的企业场景
• 强依赖数据库查询、聚合统计和实时监控的任务平台
• 多团队、多部门、多租户的大规模协作系统

换句话说，OCWS 当前最适合的是：

• 一人公司
• 小规模团队
• 强规则、多角色 Agent 协作
• 希望先从轻量协议层开始，而不是先造平台

OCWS 和其他方案的关系

我并不认为 OCWS 要替代 workflow engine 或 Agent framework。

更准确的说法是：

• OCWS 可以作为轻量协议层单独运行
• 也可以作为未来更复杂系统之前的前置基线
• 还可以作为更强控制面的底层目录约定

如果后续需要引入数据库、Web UI、任务调度器，我更希望是在 OCWS 已经把边界定义清楚之后再加，而不是反过来。

这样做的好处是：

• 不会被工具抽象反向绑架
• 目录和协议仍然可读、可迁移
• 未来更换实现层时，组织模型不需要推倒重来

目前我最看重的三个原则

第一，轻量优先

只解决当前真实存在的问题，不为未来可能不会发生的复杂度付出过高成本。

第二，协议优先

先把目录、状态、命名、通知和模板说清楚，再谈脚本、界面和平台。

第三，闭环优先

优先验证一个项目能否完整经历：

项目创建 -> 任务拆解 -> 通知分发 -> 机器人执行 -> 结果回写 -> 审计验收 -> 归档

只要这条闭环跑通，后续增强都建立在真实问题之上。

如果继续演进，我会怎么做

如果社区反馈这条路线有价值，我下一阶段会优先考虑这些方向：

1. 角色职责矩阵

明确每个机器人角色：

• 能做什么
• 不能做什么
• 输入输出是什么
• 在什么节点介入

2. 任务分级机制

不是所有任务都应该走完整流程。
我更倾向于定义：

• 轻任务：简化流程
• 标准任务：完整流程
• 关键任务：必须经过监督和审计

3. 自动校验工具

例如：

• 检查命名是否规范
• 检查任务状态是否合法
• 检查通知字段是否完整
• 检查任务结果是否回写

4. 结构化元数据

在保持 Markdown 可读性的前提下，逐步增加结构化状态文件，用于更稳定地支撑自动化处理。

5. 示例工程

做一个真正可运行的 demo，把目录、任务、通知和角色流转跑起来，而不是只停留在规范层。

我希望社区帮我看什么

如果你读到这里，我最希望得到的不是泛泛评价，而是更具体的反馈：

• 这种“目录即协议”的路线是否合理？
• 在多 Agent 协作里，任务事实源应该如何定义才更稳？
• 通知文件作为“分发指针”的设计是否足够清晰？
• 对一人公司场景来说，这套设计是偏重还是偏轻？
• 如果未来做开源项目，最值得优先补的是哪一层：规则、工具、示例还是控制面？

结语

我做 OCWS 的出发点很简单：

不是为了再造一个大而全的系统，而是为了让多个机器人在同一个工作空间中，能够长期、稳定、有边界地协作。

如果把它说得更直接一点：

OCWS 不是为“模型能力展示”服务的，它是为“数字组织秩序”服务的。

在一人公司场景里，我越来越相信，真正重要的不是你有多少个机器人，而是这些机器人之间有没有一套清晰、稳定、可追溯的协作协议。

OCWS 目前只是第一步。
如果这个方向成立，我会继续把它打磨成一个真正可用、可演进、可开源的多机器人工作空间规范。

如果你对这个思路有兴趣，欢迎直接提出批评、反例和改进建议。真正有价值的设计，应该经得起实际场景和不同视角的推敲。