cfdaily
601 lines
23 KiB
Markdown
601 lines
23 KiB
Markdown
# 三国 AI Native 平台 - PRD v2.0
|
||
|
||
**产品名称**: sanguo_moziplus
|
||
**作者**: 庞统(副军师)
|
||
**日期**: 2026-05-13
|
||
**状态**: 📋 v2.0 初稿,基于用户深度讨论后的方向重定位
|
||
**前置**: PRD v1.0 的经验教训作为输入,v2.0 从核心理念重新出发
|
||
|
||
---
|
||
|
||
## 0. 一句话定义
|
||
|
||
> **用户提一个方向,AI 帮他梳理成清晰目标,然后自主组织 Agent 团队执行,全程持续指挥、自主协调、主动汇报,人只在关键决策点介入。**
|
||
|
||
v1.0 的定义:"用户提一句话需求,平台自动组织 Agent 团队完成全生命周期工作。"
|
||
|
||
区别在哪?v1.0 假设用户知道自己要什么。v2.0 假设用户只有一个模糊方向,**帮用户想清楚要什么**是系统的核心能力之一。
|
||
|
||
---
|
||
|
||
## 1. 为什么要推倒重来
|
||
|
||
### 1.1 v1.0 的根本问题
|
||
|
||
v1.0 的定位是"AI Native DevOps Platform",但实际做出来的东西是**用传统 Web 应用的方式管理 AI Agent**:
|
||
|
||
- 编排是确定性状态机(engine.py 1589 行硬编码流转)
|
||
- 用户交互是点按钮、填表单
|
||
- 前端是 12 个固定 Tab
|
||
- Agent 之间靠邮件异步通信
|
||
- AI 只在"执行节点"里出现,其余全是传统代码
|
||
|
||
这不是 AI native。这是**给 AI 团队做了一套 ERP**。
|
||
|
||
### 1.2 核心洞察
|
||
|
||
> **AI native 不意味着系统里用了 AI,而意味着 AI 参与系统的每一个决策层。**
|
||
|
||
传统系统:人做所有决策 → 系统执行。
|
||
AI native:AI 做大部分决策 → 人在关键点介入。
|
||
|
||
### 1.3 v1.0 的资产
|
||
|
||
推翻的是方向和架构,不是所有工作:
|
||
|
||
| 资产 | 保留原因 |
|
||
|------|---------|
|
||
| 6 个 Agent 的角色定义和 Skills | 核心能力,花了很多时间调教 |
|
||
| SQLite 数据模型 + 任务存储 | 任务追踪是通用需求 |
|
||
| WebSocket 实时推送基础 | 实时能力是 AI native 的基础设施 |
|
||
| 结构化产出规范 | Agent 产出需要可解析 |
|
||
| 质量门禁思路(做 + 挑战) | 差异化能力 |
|
||
| 苏格拉底需求分析 Skill | v2.0 的核心入口能力 |
|
||
|
||
---
|
||
|
||
## 2. 核心理念
|
||
|
||
### 2.1 四条信念
|
||
|
||
**B1. AI 帮人想清楚要什么,比 AI 替人干活更有价值**
|
||
|
||
用户提出模糊方向 → AI 通过对话帮用户梳理成清晰目标 → 再执行。
|
||
需求越清晰,执行越精准,返工越少。需求探索不是前置步骤,是**系统最有价值的部分**。
|
||
|
||
**B2. 编排层应该是一个 AI 指挥官,不是一段确定性代码**
|
||
|
||
不是"状态 A 满足条件 → 转到状态 B",而是"AI 感知全局 → 判断局势 → 决定下一步"。
|
||
确定性引擎可以保留作为底层执行保障,但决策层必须是 AI。
|
||
|
||
**B3. Agent 之间共享意识,不传递消息**
|
||
|
||
Agent 之间不互发消息,而是通过 Daemon 共享状态空间,按需查询其他 Agent 的产出和状态。
|
||
|
||
不是 A 写信 → B 读信 → B 回信(异步、延迟、有损)。
|
||
而是所有 Agent 共享一个实时信息空间,随时读写,看到全局。
|
||
|
||
**B4. 人退到系统的边缘**
|
||
|
||
人的角色:提出方向 → 确认共识 → 关键决策 → 验收。
|
||
其余时间人不参与,AI 主动汇报,人可以随时介入。
|
||
|
||
### 2.2 与 v1.0 铁律的关系
|
||
|
||
v1.0 有四条铁律(IR-1~IR-4)。v2.0 不再叫"铁律",因为铁律暗含"人在约束 AI"。v2.0 的信念是从 AI 的能力出发定义系统该长什么样。
|
||
|
||
但 v1.0 的核心精神保留:
|
||
|
||
| v1.0 铁律 | v2.0 对应 | 变化 |
|
||
|-----------|----------|------|
|
||
| IR-1: 每个任务至少 2 个 Agent | B2 指挥官模式 | 挑战机制不取消,但由指挥官动态决定什么时候需要、挑战到什么程度 |
|
||
| IR-2: Plan → Execute → Validate | B2 指挥官模式 | 保留三阶段,但不是每个节点都强制走完,由指挥官判断 |
|
||
| IR-3: 全局视野 | B3 共享意识 | 从"任务主页给人看"变成"共享空间所有参与者都能读写" |
|
||
| IR-4: 安全红线 | B4 人退到边缘 | 保留安全拦截,但加入 AI 自主判断什么时候该拉人 |
|
||
|
||
---
|
||
|
||
## 3. 系统画面
|
||
|
||
### 3.1 用户视角的理想体验
|
||
|
||
```
|
||
你: "我想搞一个基于成交量的动量策略"
|
||
|
||
庞统: "好,动量方向有很多种走法。你现在的直觉是基于什么?
|
||
- 价格动量(追涨杀跌)
|
||
- 成交量动量(放量突破)
|
||
- 还是两者结合?"
|
||
|
||
你: "成交量吧,最近观察到放量之后经常有一波行情"
|
||
|
||
庞统: "有意思。那你观察的是什么周期?日线级别还是分钟线?
|
||
另外'一波行情'你的预期是持有多久?"
|
||
|
||
你: "日线级别,持有大概 3-10 天"
|
||
|
||
庞统: "明白了。我整理一下我们的共识:
|
||
|
||
方向: 基于成交量的日线动量策略
|
||
持仓周期: 3-10 天(波段交易)
|
||
核心假设: 放量后趋势延续
|
||
|
||
还想确认几个约束:
|
||
1. 标的池?全 A?还是指数成分?
|
||
2. 资金量级?
|
||
3. 能接受的最大回撤?"
|
||
|
||
你: "全A,100万,回撤不超过15%"
|
||
|
||
庞统: "需求清晰了。我来安排执行,预计40分钟出初步结果。"
|
||
|
||
[15分钟后]
|
||
|
||
庞统: "赵云数据准备完了,发现2024-08分钟线有缺失,
|
||
我让赵云用日线补齐了。张飞已经开始写策略。"
|
||
|
||
[30分钟后]
|
||
|
||
庞统: "张飞写完了,司马懿review提了2个问题:
|
||
1. 止损逻辑有未来函数风险(已修)
|
||
2. 建议加入仓位管理(张飞认同,在加)
|
||
预计再10分钟。"
|
||
|
||
[40分钟后]
|
||
|
||
庞统: "策略完成。年化收益23%,最大回撤12.3%,Sharpe 1.6。
|
||
司马懿已验收。策略代码和回测报告在这里。
|
||
你看一下?"
|
||
```
|
||
|
||
**全程用户说了三句话。** 中间庞统自主处理了数据缺失、协调了 review 意见、调整了计划。
|
||
|
||
### 3.2 系统内部发生了什么
|
||
|
||
```
|
||
用户的模糊方向
|
||
│
|
||
▼
|
||
┌──────────────────────────┐
|
||
│ Phase 1: 需求探索 │
|
||
│ 苏格拉底式对话 │
|
||
│ 你和庞统共创清晰目标 │
|
||
│ 输出: 目标+约束+验收标准 │
|
||
└────────────┬─────────────┘
|
||
│
|
||
▼
|
||
┌──────────────────────────┐
|
||
│ Phase 2: 动态规划 │
|
||
│ 庞统规划 → 司马懿挑战 │
|
||
│ 输出: 活的执行计划 │
|
||
│ (不是固定DAG,可随时调整) │
|
||
└────────────┬─────────────┘
|
||
│
|
||
▼
|
||
┌──────────────────────────┐
|
||
│ Phase 3: 自主执行 │
|
||
│ Agent群共享意识,自主协作 │
|
||
│ 庞统持续观察,实时调整 │
|
||
│ 异常自动处理,解决不了拉人 │
|
||
│ 执行过程中计划可演进 │
|
||
└────────────┬─────────────┘
|
||
│
|
||
▼
|
||
┌──────────────────────────┐
|
||
│ Phase 4: 主动汇报 │
|
||
│ AI推送结果和关键发现 │
|
||
│ 用户验收,可追问可调整 │
|
||
└──────────────────────────┘
|
||
```
|
||
|
||
人的参与密度:Phase 1 高 → Phase 2 可选确认 → Phase 3 几乎不参与(可随时介入)→ Phase 4 验收。
|
||
|
||
---
|
||
|
||
## 4. 架构理念
|
||
|
||
### 4.1 从四层变四相
|
||
|
||
v1.0 的架构是传统分层:前端 → API → 编排引擎 → Agent 层。
|
||
|
||
v2.0 不分层,而是定义四个**交互相位(Phase)**,每个相位内部由 AI 驱动:
|
||
|
||
### Phase 1: 需求探索(苏格拉底对话)
|
||
|
||
**谁参与**: 用户 + 庞统
|
||
**AI 的角色**: 不只是"理解需求",而是**帮用户发现需求**
|
||
**核心技术**: 苏格拉底式提问 Skill
|
||
**输入**: 用户的一句话方向
|
||
**输出**: 清晰的目标、约束、验收标准(用户确认后的共识)
|
||
|
||
**关键设计点**:
|
||
- 对话是多轮的,不是一次性的
|
||
- 庞统根据领域知识主动提问,不是被动等待
|
||
- 用户可以随时补充、修改、推翻之前的说法
|
||
- 最终形成的共识要**用户明确确认**才能进入下一阶段
|
||
|
||
### Phase 2: 动态规划(AI 规划 + 挑战)
|
||
|
||
**谁参与**: 庞统(规划)+ 司马懿(挑战)+ 用户(可选确认)
|
||
**AI 的角色**: 规划者 + 质量守门人
|
||
**核心技术**: 动态规划能力 + 质量门禁
|
||
|
||
**关键设计点**:
|
||
- 规划不是一次性的。执行过程中计划可以调整
|
||
- 规划结果不是固定 DAG,而是**活的执行方案**
|
||
- 司马懿挑战规划的合理性,多轮协商达不成共识则升级
|
||
- 用户可以选择确认计划,也可以直接让 AI 开始执行
|
||
|
||
**和 v1.0 的区别**:
|
||
- v1.0: plan.json 一次性生成 → engine 固定执行
|
||
- v2.0: 计划是活的,庞统全程在场随时调整
|
||
|
||
### Phase 3: 自主执行(Agent 协作群)
|
||
|
||
**谁参与**: 所有 Agent + 庞统(持续指挥)
|
||
**AI 的角色**: 执行者 + 指挥官
|
||
**核心技术**: 共享意识空间 + 持续指挥
|
||
|
||
**关键设计点**:
|
||
|
||
**共享意识空间(Blackboard)**:
|
||
```
|
||
┌──────────────────────────────────────┐
|
||
│ 共享任务空间 │
|
||
│ │
|
||
│ 目标: 基于成交量的日线动量策略 │
|
||
│ 约束: 最大回撤15%, 资金100万 │
|
||
│ 当前阶段: 策略编码 │
|
||
│ │
|
||
│ 赵云: 数据准备完成,2024-08有缺失已补齐 │
|
||
│ 张飞: 正在写策略,进度60% │
|
||
│ 姜维: 回测环境就绪 │
|
||
│ 庞统: 判断正常,张飞完成后进review │
|
||
│ 司马懿: 待命 │
|
||
│ │
|
||
│ 风险: 无 │
|
||
│ 阻塞: 无 │
|
||
└──────────────────────────────────────┘
|
||
```
|
||
|
||
每个 Agent 随时可以:
|
||
- 读取全局状态和其他 Agent 的状态
|
||
- 写入自己的状态、发现、意图
|
||
- 感知到其他 Agent 的变化
|
||
|
||
**持续指挥官(庞统)**:
|
||
- 不是提交 plan 后退场,而是全程在线
|
||
- 每个关键节点完成后被通知,评估全局状态
|
||
- 出现异常时自主决策(换人、换方案、调整优先级)
|
||
- 解决不了的问题才升级给用户
|
||
|
||
**Agent 自主协作**:
|
||
- Agent 不只是被动接任务,可以主动发起协作
|
||
- 赵云发现数据问题 → 直接在共享空间标记 → 张飞看到后调整工作
|
||
- 不需要通过中央调度器传递信息
|
||
|
||
**和 v1.0 的区别**:
|
||
- v1.0: Agent 之间通过 Sanguo Mail 异步通信
|
||
- v2.0: Agent 通过共享空间实时感知 + 必要时直接对话
|
||
|
||
### Phase 4: 主动汇报(AI 推送)
|
||
|
||
**谁参与**: 庞统 → 用户
|
||
**AI 的角色**: 汇报者
|
||
**核心技术**: 自然语言生成 + 主动推送
|
||
|
||
**关键设计点**:
|
||
- AI 主动推送进度和结果,不需要用户查 Dashboard
|
||
- 汇报内容是自然语言,不是结构化数据的展示
|
||
- 用户可以追问细节、要求调整、推翻结论
|
||
- 关键决策点(花钱、发交易、删数据)AI 主动请求确认
|
||
|
||
### 4.2 编排层的范式转变
|
||
|
||
**v1.0**: 确定性引擎(状态机 + 固定流转)
|
||
```
|
||
for node in sorted_nodes:
|
||
execute(node)
|
||
if failed: retry or wait
|
||
```
|
||
|
||
**v2.0**: AI 驱动的指挥循环(感知 → 推理 → 行动)
|
||
```
|
||
while 任务未完成:
|
||
全局状态 = 感知所有Agent和共享空间()
|
||
下一步 = 庞统(全局状态) → "该做什么,谁来做"
|
||
执行(下一步)
|
||
观察结果 → 更新共享空间
|
||
如果需要人的决策 → 暂停并汇报
|
||
```
|
||
|
||
这不意味着完全砍掉确定性引擎。底层执行仍然需要状态追踪、超时保护、故障恢复。但在执行层之上,有一个 AI 指挥层做动态决策。
|
||
|
||
### 4.3 界面的范式转变
|
||
|
||
**v1.0**: 12 个固定 Tab 的 Dashboard 是主入口
|
||
**v2.0**: 自然语言对话是主入口,Dashboard 降级为监控面板
|
||
|
||
| 界面 | v1.0 | v2.0 |
|
||
|------|------|------|
|
||
| 主入口 | Dashboard (8082端口) | 对话(OpenClaw session) |
|
||
| 监控 | Dashboard 内的多个 Tab | 轻量监控面板(只看不操作) |
|
||
| 操作 | 点按钮 | 说话 |
|
||
| 信息获取 | 人去查 | AI 主动推 |
|
||
| 干预 | Dashboard 上的操作按钮 | 对话中说"暂停""换人""调整方向" |
|
||
|
||
Dashboard 不会消失,但它变成**可选的后台监控工具**,不是必须的操作界面。
|
||
|
||
---
|
||
|
||
## 5. 核心能力清单
|
||
|
||
### 5.1 能力 vs 现状
|
||
|
||
| # | 能力 | 说明 | v1.0 现状 | v2.0 目标 |
|
||
|---|------|------|----------|----------|
|
||
| C1 | **需求探索对话** | 苏格拉底式提问,帮用户梳理需求 | ✅ 有 Skill | 核心入口,深度融合 |
|
||
| C2 | **动态规划** | AI 规划 + 挑战,计划可演进 | ⚠️ plan.json 一次性 | 活的执行方案,全程可调 |
|
||
| C3 | **持续指挥** | 庞统全程在线,实时观察调整 | ❌ 交完 plan 退场 | 指挥官模式,关键节点介入 |
|
||
| C4 | **共享意识** | Agent 通过 Daemon API 查询共享状态 | ❌ Sanguo Mail 异步 | Daemon HTTP API + SQLite |
|
||
| C5 | **自主协作** | Agent 通过共享空间感知并协调 | ❌ 全靠中央调度 | 中央调度为主,v2.1+ 目标 peer-to-peer |
|
||
| C6 | **质量门禁** | 独立挑战者评审产出 | ✅ 有基础实现 | 保留,指挥官动态决定深度 |
|
||
| C7 | **主动汇报** | AI 推送进度和结果 | ❌ 人查 Dashboard | AI 主动推送自然语言摘要 |
|
||
| C8 | **经验沉淀** | 每次执行自动提炼经验 | ❌ 无 | 自动沉淀到知识库,下次复用 |
|
||
| C9 | **安全护栏** | 危险操作拦截、审批 | ✅ 有基础 | AI 自主判断 + 红线拦截 |
|
||
| C10 | **工具链集成** | lint/test/build 自动触发 | ❌ 未实现 | 按需调用,结果驱动流转 |
|
||
|
||
### 5.2 能力依赖关系
|
||
|
||
```
|
||
C1 需求探索
|
||
│
|
||
▼
|
||
C2 动态规划 ─────────────────┐
|
||
│ │
|
||
▼ ▼
|
||
C3 持续指挥 ←→ C4 共享意识 ←→ C5 自主协作
|
||
│ │
|
||
│ ▼
|
||
│ C8 经验沉淀
|
||
│
|
||
├──→ C6 质量门禁
|
||
├──→ C7 主动汇报
|
||
├──→ C9 安全护栏
|
||
└──→ C10 工具链集成
|
||
```
|
||
|
||
核心环是 C3 + C4 + C5(持续指挥 + 共享意识 + 自主协作)。这是 AI native 和传统系统的根本区别。
|
||
|
||
---
|
||
|
||
## 6. 技术方向
|
||
|
||
### 6.1 编排层:全新实现
|
||
|
||
**v2.0 是全新代码、全新仓库、全新部署，与 v1.0 完全隔离。**
|
||
|
||
- v1.0 继续运行，v2.0 独立开发
|
||
- 保留的只有设计思想（状态机守卫、幻觉门控等经验教训），不保留代码
|
||
- v2.0 的编排引擎是全新设计的 Daemon（FastAPI + SQLite + 事件循环）
|
||
|
||
底层:轻量确定性引擎（状态机、超时保护、故障恢复）
|
||
上层:AI 指挥层（庞统在每个关键决策点介入）
|
||
|
||
关键决策点:
|
||
- 规划完成后（验证计划合理性）
|
||
- 每个节点完成后（评估全局,决定下一步）
|
||
- 异常发生时（诊断原因,决定应对策略）
|
||
- 任务完成时（汇总结果,生成汇报）
|
||
|
||
### 6.2 通信层:中央调度 + 共享状态
|
||
|
||
**v2.0 采用中央调度模式（Daemon 是唯一中枢）。**
|
||
|
||
- **Daemon API**:所有 Agent 通过 HTTP API 查询共享状态、回报结果
|
||
- **`openclaw agent` CLI**:Daemon 通过 CLI 调度 Agent
|
||
- **邮件保留**:Sanguo Mail 作为 fallback（v2.0 不直接依赖，但保留兼容性）
|
||
- **v2.1+ 目标**:Agent 主动感知 + peer-to-peer 协作（当前不做）
|
||
|
||
### 6.3 入口层:从 Dashboard 到对话
|
||
|
||
**主入口迁移到 OpenClaw session**。moziplus 的能力通过对话暴露,而不是通过 Web 页面。
|
||
|
||
Dashboard 保留为:
|
||
- 监控面板(只读视图,看全局状态)
|
||
- 调试工具(出问题时排查)
|
||
- 历史归档(查看已完成的任务)
|
||
|
||
### 6.4 经验层:从无到有
|
||
|
||
每次任务完成后,AI 自动提炼:
|
||
- 任务模式(什么类型的需求走了什么路径)
|
||
- 时间模型(每个 Agent 处理什么类型任务需要多久)
|
||
- 常见陷阱(什么情况下容易出错)
|
||
- 最优实践(什么做法效果最好)
|
||
|
||
沉淀到知识库,下次类似任务自动复用。
|
||
|
||
---
|
||
|
||
## 7. 里程碑规划
|
||
|
||
> ⚠️ 以下为方向级规划,具体排期待调研完成后细化。
|
||
> 调研目标:吸收当前业界 AI native agent 系统的理念和做法。
|
||
|
||
### M0: 调研与设计(当前)
|
||
|
||
- 调研业界 AI native agent 框架/平台的设计理念
|
||
- 梳理可借鉴的模式和做法
|
||
- 输出:调研报告 + v2.0 详设文档
|
||
|
||
### M1: 核心原型
|
||
|
||
- 需求探索对话(C1 深度融合)
|
||
- 共享意识空间(C4 基础版)
|
||
- 持续指挥官实验(C3 最小版:节点完成回调中加庞统调用)
|
||
- 用一个真实任务跑通全链路
|
||
|
||
### M2: 协作增强
|
||
|
||
- Agent 自主协作(C5)
|
||
- 动态规划演进(C2 活计划)
|
||
- 主动汇报(C7)
|
||
- 经验沉淀 v1(C8 基础版)
|
||
|
||
### M3: 完善与生产化
|
||
|
||
- 质量门禁深化(C6 动态挑战)
|
||
- 安全护栏(C9)
|
||
- 工具链集成(C10)
|
||
- 稳定性、监控、故障恢复
|
||
|
||
---
|
||
|
||
## 8. 调研发现与待回答问题
|
||
|
||
以下问题基于 2026-05-13 调研（知识库 14 个项目 + 业界 5 个方向），部分已有答案。
|
||
|
||
### 8.1 编排智能化 — 已有部分答案
|
||
|
||
**业界共识**: “可预测骨架 + LLM 动态填充”，不纯 DAG 也不纯 ReAct。
|
||
|
||
- LangGraph：图定义结构，条件边动态路由
|
||
- OpenAI Agent SDK：Handoff 显式转交 + 对话历史传递
|
||
- Google ADK：层级树 + LLM 做委派决策
|
||
- open-multi-agent：Goal-first，Coordinator 动态分解为 DAG
|
||
- Ouroboros：后台意识循环（比"持续指挥官"更激进——不是任务来了才调度，而是一直在思考）
|
||
|
||
**待深入**: 确定性保障机制（防死循环/乱调度）的具体实现方式
|
||
|
||
### 8.2 共享意识 — 已有部分答案
|
||
|
||
**通信模式递进**（按 AI native 程度）:
|
||
1. 点对点异步消息（Sanguo Mail）——最基础
|
||
2. 共享工作区 + 结构化产出（Claude Code）——简单有效
|
||
3. 对话历史传递（OpenAI Handoff）——"surprisingly effective"
|
||
4. Blackboard 广播（学术前沿：LbMAS/bMAS）——最强但最复杂
|
||
5. Canonical IR 中间表示（Opal-Bridge）——N 个 Agent 只需 2N 个 adapter
|
||
|
||
**冲突解决**（wiki 已蒸馏）: 写冲突用锁、逻辑冲突用仲裁、资源冲突用队列
|
||
**并行安全**: Network-AI 的 propose→validate→commit 原子写入
|
||
|
||
**待深入**: 信息过载的具体解决方案（分层黑板 + LLM 控制单元路由）
|
||
|
||
### 8.3 Agent 自主协作 — 已有框架
|
||
|
||
**4 种编排模式**（wiki 已蒸馏）: 线性/并行/主从/网状，有明确选择指南
|
||
**Agent 自主协作参考**: Ouroboros 的后台意识、wanman 的 Steer/FollowUp 优先级
|
||
**多模型交叉验证**: Ouroboros 用 o3/Gemini/Claude 评审自己的变更
|
||
|
||
**待深入**: peer-to-peer 协作中“两个 Agent 同时改同一文件”的防竞态方案
|
||
|
||
### 8.4 经验沉淀 — 已有成熟框架
|
||
|
||
**Memory → Skills → Rules 三层压缩**（Experience Compression Spectrum）
|
||
**闭环学习**: DISCOVER → DISTILL → APPLY → IMPROVE（wiki 知识管理体系）
|
||
**五层蒸馏**: 表达DNA → 心智模型 → 决策启发式 → 反模式 → 诚实边界（nuwa-skill）
|
||
**五路径增长**: 调研驱动 / 问题驱动 / 外部注入 / 反向触发 / 交叉碰撞
|
||
**反向触发特别重要**: Agent 发现好实践时主动建议"可以改善我们的 X"——AI native 的经验沉淀
|
||
|
||
**待深入**: 经验自动从执行 trace 中提取的具体方法、过时经验处理
|
||
|
||
### 8.5 人的介入方式 — 已有成熟做法
|
||
|
||
**分阶段介入**: 设计时深度 → 执行时旁观 → 完成时审查
|
||
**权限光谱**: Claude Code 7 种权限模式（全自动到每步审批）
|
||
**安全机制**: Scope Reduction Detection（防偷懒）、Change Capsule（变更审查）、Steer 优先级（紧急中断）
|
||
|
||
**待深入**: “AI 主动求助”的触发条件设计、人介入后无缝交还控制权
|
||
|
||
### 8.6 端到端参考 — 部分覆盖
|
||
|
||
**最接近全链路的**: get-shit-done（idea→research→requirements→roadmap→discuss→plan→execute→verify→ship）
|
||
**最大规模多 Agent**: Hermes v0.13 Kanban（运维保障好但编排传统）
|
||
**最激进 AI native**: Ouroboros（自修改 + 后台意识 + 宪法驱动）
|
||
**跨 Agent 互操作**: Opal-Bridge（Canonical IR + Moments + Fidelity 三档）
|
||
|
||
**待深入**: 从“需求探索”到“交付验收”全链路 AI native 的完整系统尚未出现
|
||
|
||
---
|
||
|
||
## 9. 与现有系统的关系
|
||
|
||
| 系统 | v1.0 关系 | v2.0 关系 |
|
||
|------|----------|----------|
|
||
| **OpenClaw** | 底层基础设施 | **主入口**(对话通过 session)+ 基础设施 |
|
||
| **Sanguo Mail** | Agent 间异步通信 | 降级为 fallback,主通信走共享空间 |
|
||
| **Mozi** | 经验来源 | 不变,经验教训是输入 |
|
||
| **moziplus Dashboard** | 主入口 | 降级为监控面板 |
|
||
| **知识库** | 存基础数据 | 经验沉淀的核心载体 |
|
||
|
||
---
|
||
|
||
## 10. 风险
|
||
|
||
| 风险 | 说明 | 缓解思路 |
|
||
|------|------|---------|
|
||
| AI 指挥不稳定 | AI 调度可能做出错误决策 | 底层确定性引擎兜底 + 人可随时介入 |
|
||
| 共享空间信息过载 | Agent 写入太多信息 | 结构化 + 摘要 + 按需读取 |
|
||
|
||
## 10.1 安全红线（C9 详细定义）
|
||
|
||
以下操作必须 AI 拦截并拉人确认，不允许自主执行：
|
||
|
||
| 红线 | 说明 | 拦截方式 |
|
||
|------|------|----------|
|
||
| 实盘交易 | 任何涉及真实资金的操作 | 强制人工确认 |
|
||
| 数据删除 | 删除历史数据、回测结果 | 强制人工确认 |
|
||
| 系统配置变更 | 修改 daemon/API/Agent 配置 | 强制人工确认 |
|
||
| 大额 token 消耗 | 单步 > 100K token | 自动暂停 + 通知 |
|
||
| Agent 不受控行为 | Agent 执行超出步骤范围 | 自动终止 + 升级 |
|
||
| 连续失败 | 同一任务连续 3 个步骤失败 | 暂停 + 人工介入 |
|
||
|
||
## 10.2 v2.0 范围声明
|
||
|
||
**v2.0 实现范围**：
|
||
- ✅ 四相循环（需求探索→动态规划→自主执行→主动汇报）
|
||
- ✅ 中央调度模式（Daemon 是唯一中枢）
|
||
- ✅ 配置化零硬编码
|
||
- ✅ 质量门控 + 异常处理 + 经验沉淀
|
||
- ✅ 人工介入（steer/takeover/intervene）
|
||
|
||
**v2.1+ 后续版本**：
|
||
- 🔜 Agent 主动感知（不依赖庞统调度）
|
||
- 🔜 peer-to-peer 协作
|
||
- 🔜 工具链自动集成（lint/test/build）
|
||
- 🔜 Fidelity 信息路由（按角色分级）
|
||
- 🔜 Boids 协作规则注入
|
||
- 🔜 Dashboard 监控面板
|
||
|
||
## 10.3 多任务并发
|
||
|
||
用户可能同时发起多个任务。v2.0 处理方式：
|
||
- Agent 是有界资源（每个 Agent 同时只执行一个步骤）
|
||
- Daemon 维护 Agent 可用性表，调度时检查
|
||
- 任务间资源冲突时按优先级排队（critical > standard > exploratory）
|
||
- 每个任务独立 artifacts 目录，无文件冲突
|
||
|
||
## 10.4 任务失败恢复
|
||
|
||
Phase 3 执行中途失败的处理策略：
|
||
- **单步失败**：重试（max_retries=3），换 Agent，或升级
|
||
- **计划失败**：AI 判断是否需要 replan，或从中断点继续
|
||
- **用户改主意**：steer/replan 重新规划，不从头开始
|
||
- **不可恢复**：标记 failed，保留所有产出物和执行历史，支持用户事后分析
|
||
|
||
---
|
||
|
||
## 附录: v1.0 → v2.0 变化摘要
|
||
|
||
| 维度 | v1.0 | v2.0 |
|
||
|------|------|------|
|
||
| 核心假设 | 用户知道自己要什么 | 用户只有模糊方向,AI 帮他梳理 |
|
||
| 编排方式 | 确定性状态机 + 固定 DAG | AI 指挥循环 + 活计划 |
|
||
| Agent 通信 | Sanguo Mail 异步邮件 | Daemon HTTP API + openclaw agent CLI |
|
||
| 主入口 | Web Dashboard | 自然语言对话 |
|
||
| 人的参与 | 全程驾驶 | 提方向 → 关键决策 → 验收 |
|
||
| 前端定位 | 操作面板 | v2.0 不做前端，对话为主 |
|
||
| 经验沉淀 | 无 | 每次执行自动提炼 |
|
||
| AI 的位置 | 只在执行节点 | 参与每一层决策 |
|