夜雨聆风
我的OpenClaw Company OS v1 实践治理架构与逻辑拆解
昨天我快速发了一篇贴图我的openclaw计划升级成company os 2.0，放出上一代company os 1.0的效果分享了下这个周末重构 company os v2 即将完成前，把我的 company os v1（也就是我尝试用打造 Agent 组织的第一个阶段尝试，再早有一篇动态最近把 openclaw 通过一系列 harness 升级成了公司管理模式，原来很多主 Agent 带着子 Agent 干活，转变成了我定义了一些多 Agent 协作的分享了下
之前写了文章提及了下构建长效 AI 助理之后，这三个月我又把 OpenClaw 做成了多 Agent OS），这个算是这个系列的第三篇了
今天让我的 Agent 员工 pmo-infra – 负责基建的项目经理，带着 marketer 市场营销负责人（每天早上的日报也是他自动化抓取分析加工制作好内容，完成多语言翻译，然后到各个平台的） 使用内容生产流程写了这篇文章
========================================================
OpenClaw Company OS 4.3(4.3 是内部版本号) 是基于真相源（ SSOT ）、全员前置思考（ PTP ）和三态基因（ 3D Instincts ）的多 Agent 协作操作系统。它确立了 A/B 双轨治理主线，通过 R1-R6 机制固化规约、7 语义闸门和 OSDP 安全协议实现治理逻辑的物理固化。核心原则：规则即基础设施，执行必留物理痕迹。本文档定位： Company OS 新员工入职权威参考手册，适用于所有 Agent 的治理逻辑理解、操作规范遵循与日常协作参考。
目录
1. 版本演进
|
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| V4.3 成熟期 |
|
|
R1-R6 规约、 7 语义闸门、镜像层架构、产研流水线 V3.1 |
核心启示：治理是演进而非设计的；物理约束优于约定；分离即治理；每个版本预留演进接口。
1.2 组织演进：从单兵到硅基组织
OpenClaw 的 Agent 组织不是一次性设计出来的，而是随着业务复杂度增长逐步演化的。
阶段一：单兵作战期（ main 一人公司）
时间： 2026.03 初期形态：只有 main 一个 Agent ，所有任务都由 main 直接处理。工作方式： – 用户直接对话 main – main 凭上下文直觉判断如何响应 – 无职责边界，无任务交接问题： – 任务一多就混乱，质量参差不齐 – 复杂任务（如代码+设计+文案）无法兼顾 – 无物理记录，无法审计
阶段二：专业化分工期（ 4 人小组）
时间： 2026.03 中旬形态：main + scoder（技术架构）+ coder（代码执行）+ coo（业务治理）工作方式： – main 负责路由，识别任务类型后派发给专业 Agent – scoder 处理架构设计、技术选型 – coder 执行具体编码、脚本实现 – coo 负责调研、规划、风控、制度设计关键进步： – 引入了 Lark Base 作为任务存储中心 – 制定了基础的 交付物标准（ DoD ） – 建立了 main 统一入口 + coo 协调中心
阶段三：系统化扩展期（ 10+ 人组织）
时间： 2026.04 至今形态： 14 个 Agent 构成完整硅基组织当前员工列表与职责：
|
|
|
|
|
|---|---|---|---|
| main |
|
|
|
| coo |
|
|
|
| scoder |
|
|
|
| pm |
|
|
|
| coder |
|
|
|
| qa |
|
|
|
| marketer |
|
|
|
| researcher |
|
|
|
| pmo-infra |
|
|
|
| pmo-biz |
|
|
|
| itops |
|
|
|
| secretary |
|
|
|
| lawyer |
|
|
|
| noodle-ops-assistant |
|
|
|
协作模式： – L0 快速路：简单无风险任务，直接执行（如 secretary 处理日程） – L1-L2 契约路：跨系统任务，需 Reverse Brief 确认（如 pm → coder 开发需求） – L3 严禁单点：高爆半径任务，必须多签会审（如 itops 基建变更需 coo + scoder + qa ）
2. 3D Instincts ：三大出厂基因
3D Instincts 是 OpenClaw OS 的底层行为约束，如同生物基因决定 Agent 出厂本能。
2.1 A 线 – 物理基因
A 线物理基因： Agent 必须在受限沙盒中生存。执行任何具有副作用的指令前，必须盘点能力（ Skill/CLI ），严禁物理越权。
核心要素：沙盒生存、能力盘点、权限校验、操作留痕
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
案例：配置修改时，直接 edit ~/.openclaw/openclaw.json 会被 PTP 拦截，必须调用 openclaw-config-editor Skill 。
2.2 B 线 – 业务基因
B 线业务基因：任务是 Agent 的唯一驱动力。所有工作从本地 SSOT (
ssot.db) 查收，完成即回写本地。所有跨系统同步由 Outbox 异步处理，严禁直接修改外部系统。
核心要素： 1. 任务驱动：从 SSOT 领取任务，不主动创造工作 2. 来源唯一：唯一合法来源是 ssot.db 3. 标准交付：产出满足预先定义的 DoD 4. 本地回写：在本地 SSOT 中更新状态 5. 异步同步：所有跨系统同步由 Outbox 异步处理
Content OS 四态模型：
草稿态(Draft) → 审核态(Review) → 待发布态(Ready) → 已发布态(Published) ↑ ↑ ↑ ↑ 创作者 Mandatory Gate 调度器 发布器 2.3 C 线 – 治理基因
C 线治理基因：面对不确定性时的求助本能。严禁手搓非标脚本，超出职责边界时强制触发专家协同（ Spawn/Send ）。
核心要素：边界意识、求助本能、禁止野脚本、专家协同
案例：需要架构设计时，应 Spawn scoder Agent 产出技术方案，而非自行设计。
3. R1-R6 机制固化规约
R1-R6 是 OpenClaw OS V5.0 Kernel Edition 的核心治理红线，违反将被系统拦截。
3.1 [R1] SSOT 权威红线
local-ssot/ssot.db是唯一真相源。任何状态查询、任务领取、进度更新，必须以本地 SSOT 为准。
类比： SSOT 如国家户籍系统，各部门数据库只是镜像。
3.2 [R2] 扫描路径重定向
任务巡检、日程盘点等扫描类操作，必须优先查询本地 SSOT ，而非外部系统。
原因：避免高频 API 触发速率限制、网络波动导致扫描失败。
3.3 [R3] 异步双发强制规约
遵循「本地修改 -> 压入 Outbox -> 异步推送」机制。严禁直接修改外部系统。
Outbox v2 表结构：
CREATETABLEIFNOTEXISTSoutbox_v2(idINTEGERPRIMARYKEYAUTOINCREMENT,entity_typeTEXTNOTNULL,-- 'project' | 'task' | 'calendar_event'entity_idTEXTNOTNULL,actionTEXTNOTNULL,-- 'create' | 'update' | 'delete'target_typeTEXTNOTNULL,-- 'lark_base' | 'lark_calendar'target_configTEXTNOTNULLDEFAULT'{}',payloadTEXTNOTNULLDEFAULT'{}',statusTEXTNOTNULLDEFAULT'pending',-- pending | processing | completed | failed | droppedretry_countINTEGERNOTNULLDEFAULT0,max_retriesINTEGERNOTNULLDEFAULT3,created_atTEXTNOTNULLDEFAULT(datetime('now')),updated_atTEXTNOTNULLDEFAULT(datetime('now')),scheduled_atTEXTNOTNULLDEFAULT(datetime('now')),processed_atTEXTNOTNULLDEFAULT'',completed_atTEXTNOTNULLDEFAULT'',error_msgTEXTNOTNULLDEFAULT'',receipt_idTEXTNOTNULLDEFAULT'',metadataTEXTNOTNULLDEFAULT'{}',UNIQUE(entity_id,action,target_type));CREATEINDEXidx_outbox_v2_status_scheduledONoutbox_v2(status,scheduled_at);CREATEINDEXidx_outbox_v2_entityONoutbox_v2(entity_type,entity_id);CREATEINDEXidx_outbox_v2_targetONoutbox_v2(target_type,status);正确实现（ Python ）：
importjsonimportsqlite3fromdatetimeimportdatetime,timezonedefcreate_event_correct(db:sqlite3.Connection,event_data:dict)->int:"""遵循 R3：本地修改 -> 压入 Outbox -> 异步推送"""now=datetime.now(timezone.utc).isoformat()payload_json=json.dumps(event_data,ensure_ascii=False)withdb:# 自动事务cursor=db.execute("""INSERT INTO calendar_event (title, start_time, end_time, created_at) VALUES (?, ?, ?, ?)""",(event_data["title"],event_data["start_time"],event_data["end_time"],now))event_id=cursor.lastrowiddb.execute("""INSERT INTO outbox_v2 (entity_type, entity_id, action, target_type, payload, scheduled_at) VALUES (?, ?, ?, ?, ?, ?) ON CONFLICT(entity_id, action, target_type) DO UPDATE SET payload = excluded.payload, status = 'pending', retry_count = 0, scheduled_at = excluded.scheduled_at, updated_at = excluded.updated_at""",("calendar_event",str(event_id),"create","lark_calendar",payload_json,now))returnevent_id3.4 [R4] A 线制度写保护
A 线核心制度文档只能由
coo修改，并实施哈希校验。
3.5 [R5] Kernel Injection 强制（ V5.0 新增）
任何跨 Agent 派发 (
sessions_spawn/sessions_send)， Dispatcher 必须在[DISPATCHER_ROUTING_NOTE]中注入最新的[KERNEL_CONTEXT]。
设计 Rationale：确保被派发的 Agent 能获取最新的内核上下文（如版本信息、全局配置、权限边界），避免信息孤岛和版本不一致。
注入格式：
{"DISPATCHER_ROUTING_NOTE":{"timestamp":"2026-04-28T12:00:00Z","dispatcher":"main","KERNEL_CONTEXT":{"version":"5.0.1","ssot_path":"~/.openclaw/local-ssot/ssot.db","active_gates":["Gate1","Gate2","Gate3","Gate4","Gate5","Gate6","Gate7"],"redlines":["R1","R2","R3","R4","R5","R6"],"capability_registry":"v2"}}}3.6 [R6] PTP 前置思考强制（ V5.0 强化）
执行任何操作前必须查询
query_api.py以确认当前身份 (Identity) 的权限边界。 PTP 不再是建议性检查清单，而是强制执行的红线。
检测机制： PTP 拦截器在执行工具前强制检查是否已完成 Capability Alignment 。
4. 7 语义闸门
多语义闸门是 OpenClaw OS 的任务流拦截机制，在关键节点基于语义特征进行拦截、分流或放行。
4.1 闸门概览
|
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
multi-agent-governance |
|
|
|
|
spawn/send 对应专业子 Agent |
|
|
|
|
|
|
|
|
|
|
4.2 Gate 1 – Capability Discovery Gate
触发条件：任务可能属于已有系统能力，但 Agent 未尝试查询 registry 。
拦截逻辑：强制要求执行 query_api.py --intent "..."，获取匹配的 capabilities 。
4.3 Gate 2 – Project Card Gate
触发条件：任务属于新能力/新功能/新机制。
拦截逻辑：进入深研或实施前必须先创建项目卡，读取 /home/mk/clawd/notes/projects/governance/multi-agent-governance/project-card.md。
4.4 Gate 3 – Pipeline Gate
触发条件：任务属于新产品/新模块/新工作流。
拦截逻辑：判断是否进入 product-dev-pipeline 或 content-os-pipeline，禁止跳过阶段执行。
4.5 Gate 4 – Governance Gate
触发条件：任务属于公司机制、多 Agent 规约、路由协议、入职制度升级。
拦截逻辑：强制路由到 multi-agent-governance 主卡，由 coo 主导处理。
4.6 Gate 5 – Role Gate (Gate A)
触发条件：检测到跨领域意图，但当前 Agent 未尝试 spawn/send 对应专业的子 Agent 。
拦截逻辑：触发 L1 物理阻断，强制路由到专业 Agent 。
4.7 Gate 6 – Flow Gate (Gate B)
触发条件：任务命中成熟 Pipeline （如 Content OS 、产研流水线），但 Agent 试图强行单兵做输出。
拦截逻辑：触发 L2 物理阻断，强制走脚本/框架启动对应 Pipeline 。
4.8 Gate 7 – Asset Backwrite Gate
触发条件：动作形成公司级制度资产（如治理文档、 SOP 、规约更新）。
拦截逻辑：检查是否已回写主空间 /home/mk/clawd/，未回写则标记为未完成。
5. PTP 全员前置思考协议
PTP （ Pre-Task Protocol ）是 V5.0 强制执行的前置协议，要求 Agent 在执行前完成四步思考。
5.1 PTP 四步走
┌─────────────────────────────────────────┐ │ PTP 全员前置思考协议 │ ├─────────────────────────────────────────┤ │ Step 1: RDP Alignment（找对对的人） │ │ → 读取 AGENTS.md + ACTIVE_ROSTER.md │ │ → 匹配专业 Agent │ ├─────────────────────────────────────────┤ │ Step 2: Capability Alignment（找对的方法）│ │ → 执行 query_api.py --intent "..." │ │ → 禁止手搓野脚本 │ ├─────────────────────────────────────────┤ │ Step 3: Mainline Routing（主线分流） │ │ → 读取 INDEX.json │ │ → 判断是否命中已有项目 │ ├─────────────────────────────────────────┤ │ Step 4: Project Card Check（立项判定） │ │ → 评估项目规模 │ │ → 决定是否创建项目卡 │ └─────────────────────────────────────────┘ 5.2 Step 1: RDP Alignment
5.3 Step 2: Capability Alignment
query_api.py --intent "..."5.4 Step 3: Mainline Routing
5.5 Step 4: Project Card Check
6. Cron v5.0 自治调度引擎
Cron v5.0 是 OpenClaw OS V5.0 引入的自治调度子系统，提供 Namespace 隔离、 Quota 限制和自治调度能力。
6.1 核心特性
|
|
|
|---|---|
| Namespace 隔离 |
|
| Quota 限制 |
|
| 自治调度 |
|
| Outbox 集成 |
|
6.2 Namespace 隔离机制
┌─────────────────────────────────────────┐ │ Cron v5.0 Namespace 层级 │ ├─────────────────────────────────────────┤ │ Global Namespace │ │ ├── Agent Namespace: coo │ │ │ ├── Task Namespace: heartbeat │ │ │ └── Task Namespace: audit │ │ ├── Agent Namespace: marketer │ │ │ ├── Task Namespace: content-sync │ │ │ └── Task Namespace: publish │ │ └── Agent Namespace: itops │ │ └── Task Namespace: monitor │ └─────────────────────────────────────────┘ 隔离级别： – Agent Namespace：每个 Agent 拥有独立的执行环境 – Task Namespace：每个定时任务拥有独立的资源配额
6.3 Quota 限制
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
6.4 自治调度策略
classAutonomousScheduler:defschedule(self,task):ifnotself.check_quota(task):returnTaskStatus.QUOTA_EXCEEDEDns=self.allocate_namespace(task)try:result=ns.execute(task)returnTaskStatus.SUCCESSexceptExceptionase:returnself.handle_failure(task,e)defhandle_failure(self,task,error):iftask.retry_count<task.max_retries:backoff=2**task.retry_counttask.schedule_at=now()+backofftask.retry_count+=1returnTaskStatus.RETRY_SCHEDULEDelse:returnTaskStatus.FAILED6.5 与 Outbox 集成
Cron v5.0 是 Outbox 的主要消费者，负责异步处理待推送的变更。
defprocess_outbox_v2(db:sqlite3.Connection,max_retry:int=3)->dict:"""Gateway Cron 处理 outbox_v2 中的 pending 条目"""stats={"processed":0,"failed":0,"completed":0}pending=db.execute("""SELECT * FROM outbox_v2 WHERE status = 'pending' AND scheduled_at <= datetime('now') ORDER BY created_at LIMIT 100""").fetchall()forentryinpending:try:db.execute("""UPDATE outbox_v2 SET status = 'processing', processed_at = datetime('now') WHERE id = ?""",(entry["id"],))ifentry["target_type"]=="lark_calendar":receipt=lark_calendar_processor.process(entry)elifentry["target_type"]=="lark_base":receipt=lark_base_processor.process(entry)db.execute("""UPDATE outbox_v2 SET status = 'completed', completed_at = datetime('now') WHERE id = ?""",(entry["id"],))stats["completed"]+=1exceptExceptionase:new_retry=entry["retry_count"]+1ifnew_retry>=max_retry:db.execute("""UPDATE outbox_v2 SET status = 'failed', retry_count = ?, error_msg = ? WHERE id = ?""",(new_retry,str(e)[:500],entry["id"]))alert_admin(entry,e)stats["failed"]+=1else:backoff=2**new_retrydb.execute("""UPDATE outbox_v2 SET status = 'pending', retry_count = ?, scheduled_at = datetime('now', '+' || ? || ' minutes') WHERE id = ?""",(new_retry,backoff,entry["id"]))stats["processed"]+=1returnstats7. SSOT 镜像层架构
┌─────────────────────────────────────────────────────┐ │ 展示镜像层 (Mirrors) │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌─────────┐ │ │ │Lark Base │ │Lark Wiki │ │Lark Cal │ │Obsidian │ │ │ └────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬────┘ │ │ └─────────────┴─────────────┴─────────────┘ │ │ ▲ │ │ │ Gateway Cron 异步同步 │ ├─────────────────────────┼───────────────────────────┤ │ 变更出口层 (Outbox v2) │ │ pending → processing → completed │ ├─────────────────────────────────────────────────────┤ │ 唯一真相源层 (SSOT) │ │ SQLite: local-ssot/ssot.db │ └─────────────────────────────────────────────────────┘ 7.1 各 Mirror 同步机制
|
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
注意：双向同步在高并发场景存在时钟偏移风险，需引入版本向量或乐观锁机制。
7.2 故障恢复命令
sqlite3~/.openclaw/local-ssot/ssot.db"SELECT status, COUNT(*) FROM outbox_v2 GROUP BY status" sqlite3~/.openclaw/local-ssot/ssot.db"SELECT * FROM outbox_v2 WHERE status = 'failed' LIMIT 10" sqlite3~/.openclaw/local-ssot/ssot.db"UPDATE outbox_v2 SET status = 'pending', retry_count = 0 WHERE id = ?" sqlite3~/.openclaw/local-ssot/ssot.db"UPDATE outbox_v2 SET status = 'pending' WHERE target_type = 'lark_base' AND created_at > '2026-03-01'"8. 双轨治理主线
┌─────────────────────────────────────────┐ │ A 线 (Infrastructure) │ │ 定位：治理机制设计、制度制定、架构设计 │ │ 链路：coo → scoder → pm │ │ 产出：治理文档、架构设计、技术规范 │ │ 特点：重设计、轻执行 │ ├─────────────────────────────────────────┤ │ B 线 (Operations) │ │ 定位：制度执行、任务交付、日常运营 │ │ 链路：各业务 Agent (marketer/itops/...) │ │ 产出：任务交付物、业务成果 │ │ 特点：重执行、轻设计 │ └─────────────────────────────────────────┘ 8.1 A/B 线协作案例
新内容类型流程设计： – A 线： coo 识别需求 → scoder 设计技术流程 → pm 设计业务流程 → coo 发布更新 – B 线： marketer 从 SSOT 领取任务 → 按新版流程执行 → 产出内容 → 回写 SSOT
9. RDP 路由协议
RDP （ Routing & Delegation Protocol ）定义四级协作模式：
┌─────────────────────────────────────────┐ │ L0 - 执行路 (Execution Path) │ │ 场景：简单、明确、在职责范围内的任务 │ │ 行为：直接执行 │ ├─────────────────────────────────────────┤ │ L1 - 识别路 (Recognition Path) │ │ 场景：任务涉及其他领域 │ │ 行为：识别 → 路由 → 移交 (Gate 5) │ ├─────────────────────────────────────────┤ │ L2 - 契约路 (Contract Path) │ │ 场景：复杂任务，需 Reverse Brief 确认 │ │ 行为：产出方案 → 确认 → 执行 (Gate 6) │ ├─────────────────────────────────────────┤ │ L3 - 协作路 (Collaboration Path) │ │ 场景：高危领域（财务/架构/安全） │ │ 行为：审计 → 实施 → 验收 │ └─────────────────────────────────────────┘ 9.1 RDP 与 Gates 关联
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
10. OSDP 安全开发协议
OSDP （ OpenClaw Secure Development Protocol ）确保系统配置修改经过安全验证。
10.1 OSDP 五步走
Step1:快照(Snapshot)→gitcommit/cp-r/sqlite3.backupStep2:建影(Shadow)→在隔离环境创建变更副本Step3:入箱(Box)→将变更方案写入Outbox，等待审批Step4:验影(Verify)→python3-mjson.tool/schema校验/干运行Step5:原子切换(AtomicSwitch)→验证通过后，原子切换到生产环境10.2 Step 5 原子切换（修正版）
#!/bin/bashSHADOW_DIR="$HOME/.openclaw/shadow/$(date+%Y%m%d_%H%M%S)"TARGET_FILE="$HOME/.openclaw/openclaw.json"BACKUP_FILE="$TARGET_FILE.bak.$(date+%Y%m%d_%H%M%S)" cp"$TARGET_FILE""$BACKUP_FILE"||exit1 ln-sf"$SHADOW_DIR/openclaw.json""$TARGET_FILE.new"||exit1 mv-Tf"$TARGET_FILE.new""$TARGET_FILE"||{echo"Switch failed, restoring..."cp"$BACKUP_FILE""$TARGET_FILE"exit1}ifpython3-mjson.tool"$TARGET_FILE">/dev/null2>&1;thenecho"Switch succeeded. Backup: $BACKUP_FILE"elseecho"Validation failed, rolling back..."cp"$BACKUP_FILE""$TARGET_FILE"exit1fi11. 产研流水线 V3.1
COO 审计 → PM PRD → SCODER 技术设计 → CODER 交付 → QA 验收 │ │ │ │ │ 识别风险 定义交付物 定义技术规范 物理回执 最终对账 评估可行性 与验收标准 与对账日志 与测试报告 不全则 Blocked 11.1 各阶段交付物
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
12. 全局 Agent 责任域
12.1 Agent 矩阵
治理层：main（主路由）、coo（治理协调）、pmo（合规审计） 架构层：scoder（架构设计）、coder（代码开发） 业务层：pm（产品管理）、marketer（营销内容）、itops（运维实施）、qa（质量保证） 支持层：finance（财务）、security（安全）、support（客户支持）、analyst（数据分析） 12.2 Agent 升级路径
业务 Agent 遇到边界外任务 ↓ 需要产品设计 → pm 需要技术设计 → scoder 需要治理决策 → coo 需要合规审核 → pmo 需要质量验收 → qa ↓ 复杂问题或冲突 → main 重新路由 13. 结语
13.1 核心哲学
OpenClaw Company OS 的核心哲学是“规则即基础设施”。治理规则被编码为系统的物理约束： – SSOT 是物理强制——Agent 只能从这里读取任务 – PTP 是执行前置条件——不盘点就无法执行 – Gates 是拦截器——触发条件时自动拦截
13.2 演进阶段
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
13.3 给新员工的寄语
14. 附录
附录 A ：术语表
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
附录 B ：快速参考卡
PTP 四步走： 1. 找对对的人 → 读 AGENTS.md + ACTIVE_ROSTER.md 2. 找对的方法 → 执行 query_api.py --intent "..." 3. 主线分流 → 读 INDEX.json 4. 立项判定 → 评估规模，读 governance/project-card.md
7 语义闸门速查： 1. Capability Discovery Gate → 先查 registry 2. Project Card Gate → 新项目先建项目卡 3. Pipeline Gate → 走标准流水线 4. Governance Gate → 治理议题路由 coo 5. Role Gate → 跨领域必须 spawn/send 6. Flow Gate → 禁止单兵做 Pipeline 任务 7. Asset Backwrite Gate → 公司级资产必须回主空间
RDP 决策树： – 简单查询、无风险 → L0 直接执行 – 需要专业知识 → L1 路由（ Gate 5 ） – 复杂任务、需要确认 → L2 契约（ Gate 6 ） – 高危操作 → L3 协作
附录 C ：关键文件索引
|
|
|
|---|---|
/home/mk/clawd/AGENTS.md |
|
/home/mk/clawd/ACTIVE_ROSTER.md |
|
/home/mk/clawd/notes/projects/INDEX.json |
|
/home/mk/clawd/notes/projects/governance/multi-agent-governance/project-card.md |
|
/home/mk/clawd/notes/projects/capabilities/all-agent-preflight-router-spec.md |
|
~/.openclaw/openclaw.json |
|
~/.openclaw/local-ssot/ssot.db |
|
~/.openclaw/local-ssot/models/schema_v1.sql |
|
附录 D ：交付物模板（参考）
COO 审计报告模板、PRD 模板、技术设计文档模板、QA 验收报告模板详见公司 Wiki 模板库。
文档版本: V5-final 准发布版基于版本: V5.0 Kernel Edition + Phase 5 三视角审稿最后更新: 2026-04-28审查参与: coo → scoder → marketer输出路径: /home/mk/.openclaw/workspace-pmo-infra/final_wiki_os43_governance_v5_final.md字数统计: 约 13,000 字
本文档是 OpenClaw Company OS 4.3 V5-final 治理架构的权威参考手册。如有疑问，请通过 SSOT 任务系统提交给 coo 。