📊 sgClaw 团队协作架构图

5 人团队 · 2 周开发计划 · 职责分工与接口对接全景

一、团队协作总架构（5 人分工全景）

⚡
P1a · 核心通信
赵义仑 关键路径
干什么？
打通 AI 引擎和浏览器之间的"通信管道"，让 AI 能控制浏览器操作
Rust STDIO Pipe ~900 行
为什么？
这是整个系统的"心脏"，如果 AI 和浏览器通信不通，后续所有功能都无法实现
产出物
• Pipe 双向通信协议
• 15 个浏览器操作 API
• MAC 安全策略模块
🧠
P1b · 业务支持
Rust 工程师
干什么？
让 AI 能"记住"操作经验，能加载业务技能包，让 AI 越用越聪明
Rust SQLite ~600 行
为什么？
AI 不能每次都重新学习，需要记忆系统沉淀经验，需要技能加载器复用业务逻辑
产出物
• Skill 加载器与沙箱
• 三层记忆系统
• AI 推理引擎集成
🌐
P2 · 浏览器对接
C++ 工程师
干什么？
在浏览器内核中嵌入 sgClaw 进程，接收 P1a 的指令，调用现有 70+ 浏览器能力
C++ Chromium ~600 行
为什么？
浏览器是 C++ 写的，需要 C++ 工程师在内核中启动子进程、转发指令、管理安全白名单
产出物
• SgClawProcessHost
• Pipe 监听器
• MAC 白名单检查器
🤖
P3 · AI 辅助迁移
业务 + AI 工程
干什么？
用 AI 把现有 400+ 个业务场景自动翻译成 Skill 技能包，人工制作黄金样本
JavaScript Qwen/DeepSeek 400+ Skill
为什么？
400+ 场景人工翻译不现实，但全靠 AI 质量没保证。需要人 + AI 配合：人做样本，AI 批量翻译
产出物
• 10-15 个黄金样本
• 翻译提示词工程
• 400+ AI 生成 Skill
🖥️
P4 · 前端发布
前端 + DevOps
干什么？
做 AI 助手面板让用户输入指令，做 Skill 管理后台，搭建测试并打包发布
Vue Jest ~150 行
为什么？
AI 能力再强，用户看不到也用不了。需要界面让用户交互，需要 DevOps 发布安装包
产出物
• Side Panel UI
• Skill 管理后台
• .deb + .exe 安装包
💡 总结： P1a 是关键路径（通信不通，全项目停摆）→ P2 配合 P1a 打通链路 → P1b 让 AI 有记忆和技能 → P3 用 AI 批量生成内容 → P4 做界面和发布。 5 人各司其职，Day 4-5 全员等 P1a+P2 联调成功。

二、人员接口对接关系图

1. 关键路径对接：P1a ↔ P2（Day 4-5）极高优先级

P1a · Rust 端
发送 JSON 指令
STDIO Pipe
P2 · C++ 端
接收指令调用浏览器
为什么这是关键路径？
这两人如果没对接成功，整个系统就是"两张皮"——AI 引擎和浏览器无法通信，其他人的工作全部白做。 Day 4-5 必须打通，否则启动降级方案（HTTP 替代）。
接口协议示例：
{
  "sequence_id": 1,
  "action": "click",
  "params": {
    "selector": "#submit-button",
    "button": "left"
  }
}

2. Runtime 集成对接：P1a ↔ P1b（Day 6）

P1a
提供 BrowserPipeTool
Rust trait
P1b
注册到 AgentRuntime
为什么？P1b 的 AI 引擎需要能调用 P1a 的浏览器操作工具，通过 Rust trait 实现插件式对接。

3. Skill 加载对接：P1b ↔ P3（Day 6-7）

P3
提供 Skill.js 文件
Ed25519 签名
P1b
扫描、验签、沙箱执行
为什么？P3 写的业务技能需要被 P1b 的加载器识别并执行，签名保证安全性。

4. UI 交互对接：P2 ↔ P4（Day 6）

P4 · Vue 前端
调用 IPC 接口
window.superrpa.sgclaw.*
P2 · C++ 后端
暴露浏览器 API
为什么？用户界面（Vue）需要调用 C++ 暴露的接口来启动/停止 sgClaw、查看 Skill 列表等。

三、数据流全链路（端到端完整流程）

从用户输入到浏览器执行，数据经过 5 个角色的系统
1
P4 · Vue 前端
用户在 Side Panel 输入："导出 ERP 月度报表"
2
P2 · C++ 浏览器层
Vue 通过 IPC 调用 C++ 的 sendCommand(text)，C++ 启动 sgClaw 子进程
3
P1b · AI Runtime
接收用户指令，查询记忆系统（L2 SQLite）：上次怎么导出的？检索到 P3 提供的 Skill
4
P3 · Skill（被加载）
Skill 内容："访问 ERP → 点击报表 → 选择月份 → 导出 Excel"，转换成浏览器操作序列
5
P1a · Pipe 通信
把操作序列包装成 JSON，通过 STDIO Pipe 发送给 P2：{"action":"click", "selector":"#export"}
6
P2 · CommandRouter
C++ 接收 JSON，调用现有 CommandRouter，CommandRouter 通过 CDP 协议操作浏览器
7
浏览器
真实执行：打开 ERP 页面 → 点击按钮 → 下载文件 → 完成✅
8
P1b · 记忆系统
把这次成功的操作记录到 L2 长期记忆，下次直接复用，从 8 步降到 1 步
🚀 自进化： 第一次需要 AI 推理 8 步，第二次查到 Skill 缩短到 4 步，多次执行后记忆沉淀，一句话直接执行。 这就是为什么需要 P1b 的记忆系统 + P3 的 Skill 仓库。

四、关键路径时间轴（Day 4-5 为什么是瓶颈？）

⭐ Day 4-5：P1a + P2 联调 Pipe 通信
为什么是极高风险？
1. 阻塞所有人：如果 P1a 和 P2 的 Pipe 通信打不通，AI 引擎就是空转，浏览器接收不到指令。 P1b 做的记忆系统、P3 准备的 Skill、P4 做的界面，全部无法联动测试。
2. 技术难度高：STDIO Pipe 是进程私有通道，需要 C++ 正确传递文件描述符给 Rust 子进程， 一旦出错（如管道被关闭、缓冲区满、JSON 格式错误），排查困难。
3. 跨语言调试：C++ ↔ Rust，两种语言的调试工具不互通，需要两人高度配合才能定位问题。
如果成功（Day 5 晚）✅
• W1 里程碑达成，演示全链路
• P1b 可以对接 P1a 的工具
• P3 可以测试 Skill 执行
• P4 可以联调 UI 交互
• 全员进入并行开发模式
如果失败（Day 5 中午）❌
预案 1：P1b 全力支援排查
预案 2：启动降级方案（HTTP 替代 Pipe）
后果：项目延期 2-3 天，或者牺牲安全性（HTTP 有端口暴露风险）

五、技术栈分层（每层对应的人员）

📱 用户交互层 → P4 负责
用户看到的界面，输入指令、查看进度、管理 Skill
Side Panel (Vue)
Skill Manager (Vue)
IPC 调用层
🌐 浏览器内核层 → P2 负责
在 Chromium 中嵌入 sgClaw 进程，转发指令，调用 70+ 现有浏览器能力
SgClawProcessHost (C++)
PipeListener (C++)
MacWhitelistCheck (C++)
CommandRouter (已有)
⚡ 通信与工具层 → P1a 负责 关键
Pipe 协议、JSON 消息序列化、浏览器操作 API、MAC 安全策略
PipeReader/Writer (Rust)
BrowserPipeTool (Rust)
MacPolicy (Rust)
15 个 BrowserAction
🧠 AI 引擎层 → P1b 负责
AI 推理、记忆系统、Skill 加载、自进化能力
AgentRuntime (Rust)
SkillLoader (Rust)
Memory (Ring Buffer + SQLite)
Critic 评估器
📦 业务技能层 → P3 负责
400+ 业务场景的 Skill 定义，用 AI 批量生成 + 人工质检
10-15 黄金样本 (手写)
Prompt Engineering
400+ AI 生成 Skill
Ed25519 签名工具
📐 设计原则： 从下往上依赖，上层可以调用下层，下层不依赖上层。 P1a 是最底层（Pipe 通信），P2 调用 P1a，P1b 调用 P1a，P4 调用 P2。 这样保证模块独立，任何一层出问题不会波及其他层。

六、为什么这样分工？（设计依据）

❓ 为什么 P1 要拆成 P1a 和 P1b？
原因 1：P1a 的 Pipe 通信是关键路径， 如果一个人承担 ~1500 行代码，Day 4-5 压力太大，容易延期。拆分后 P1a 专注通信（900 行）， P1b 做业务支持（600 行），风险分散。

原因 2：P1a 负责的模块（Pipe/MAC）和 P1b 负责的模块（Skill/Memory） 技术栈不同，耦合度低，可以并行开发。Day 6 之前互不依赖，Day 6 再对接。
❓ 为什么 P3 用 AI 辅助而不是全手写？
现实约束：agent-vue 有 400+ 个业务场景，全靠人手写 Skill 需要 2-3 个月。 项目只有 2 周，不可能做到。

方案：人工精选 10-15 个代表性场景，写成"黄金样本"（高质量、带详细注释）。 然后用内网大模型（Qwen-72B/DeepSeek）批量翻译剩余 390 个场景，准确率 85%-90%。 最后人工抽检 20 个，确保质量。人 + AI 配合，2 周完成 400 个 Skill。
❓ 为什么 P4 工作量这么少（~150 行）？
复用现有：SuperRPA 浏览器已经有 Side Panel 框架和 IPC 通道， P4 只需要写两个 Vue 组件（AI 助手面板 + Skill 管理）。

测试与发布：P4 的主要工作在后期（Day 8-10），搭建测试框架、运行 E2E、 打包 .deb 和 .exe。前期（Day 1-7）工作量确实少，可以支援其他人（如帮 P3 做 Skill 质检）。
❓ 如果 P1a + P2 联调失败怎么办？
预案 1（Day 4 晚）：P1b 暂停自己的工作，全力支援 P1a 排查 Pipe 问题。 三人配合比两人快。

预案 2（Day 5 中午）：如果 Pipe 实在调不通，启动降级方案—— 改用 HTTP 本地端口通信。牺牲一些安全性（端口可被检测），但能保证项目按时交付。