sanguo/sanguo_moziplus_v2

Fork 0

Files

T

cfdaily b336c29d58 auto-sync: 2026-05-16 10:30:48

2026-05-16 10:30:48 +08:00

24 KiB

Raw Blame History

三国 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: Agent 对话 + Dashboard 双入口

界面	v1.0	v2.0
主入口	Dashboard (8082端口)	Agent 对话 + Dashboard 双入口
监控	Dashboard 内的多个 Tab	Dashboard AI Native 监控(AI Briefing + 智能摘要)
操作	点按钮	对话中说"暂停""换人""调整方向" + Dashboard 操作
信息获取	人去查	AI 主动推 + Dashboard 实时展示
干预	Dashboard 上的操作按钮	对话或 Dashboard 均可

Dashboard 不降级为可选监控工具,而是进化为 AI Native 的可视化入口,与 Agent 对话互为补充。Dashboard 如何做到 AI Native 是独立课题。

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

v2.0 有两个入口：Agent 对话和 Dashboard。

Agent 对话入口（OpenClaw session）：

主力入口，大部分交互通过自然语言完成
需求探索、任务下达、进度查询、方向调整
适合日常操作和移动端场景

Dashboard 入口（Web 前端）：

可视化监控面板，展示全局状态和任务详情
适合全局观察、批量查看、调试排查
Dashboard 如何做到 AI Native 是独立课题（如 AI Briefing、智能摘要、上下文感知布局）

两个入口共享同一套黑板数据，操作一致。

6.4 经验层:从无到有

每次任务完成后,AI 自动提炼:

任务模式(什么类型的需求走了什么路径)
时间模型(每个 Agent 处理什么类型任务需要多久)
常见陷阱(什么情况下容易出错)
最优实践(什么做法效果最好)

沉淀到知识库,下次类似任务自动复用。

7. 开发策略

核心原则：不分阶段，不妥协，直奔 AI Native。

每个部分设计到清楚为止，不强求按固定阶段交付。不做"先做个简单版再迭代"——简单版往往变成永久版。宁可某个部分多花时间想清楚，也不急着上线一个妥协方案。

设计推进方式

按课题（Topic）逐个推进，每个课题包含：调研→设计→评审→定稿。

课题之间允许并行推进，不强制串行。每个课题设计清楚就定稿，不等其他课题。

已完成课题：课题1（三层执行模型）、课题2（事件驱动+Inbox）、课题3（挑战/评审体系）、课题4（拆解+上下文）、课题6（经验沉淀）、课题7+9（交互+Dashboard）、课题10（上下文管理）。

待推进课题：见各课题方案文档。

开发启动条件

所有核心课题设计完成后启动开发。开发顺序由设计依赖关系决定，不由阶段划分决定。

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 程度）:

点对点异步消息（Sanguo Mail）——最基础
共享工作区 + 结构化产出（Claude Code）——简单有效
对话历史传递（OpenAI Handoff）——"surprisingly effective"
Blackboard 广播（学术前沿：LbMAS/bMAS）——最强但最复杂
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	主入口	AI Native 可视化入口(与 Agent 对话双入口)
知识库	存基础数据	经验沉淀的核心载体

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	自然语言对话
人的参与	全程驾驶	提方向 → 关键决策 → 验收
前端定位	操作面板	Agent 对话 + Dashboard 双入口，Dashboard AI Native 化
经验沉淀	无	每次执行自动提炼
AI 的位置	只在执行节点	参与每一层决策

24 KiB Raw Blame History Unescape Escape

三国 AI Native 平台 - PRD v2.0

0. 一句话定义

1. 为什么要推倒重来

1.1 v1.0 的根本问题

1.2 核心洞察

1.3 v1.0 的资产

2. 核心理念

2.1 四条信念

2.2 与 v1.0 铁律的关系

3. 系统画面

3.1 用户视角的理想体验

3.2 系统内部发生了什么

4. 架构理念

4.1 从四层变四相

Phase 1: 需求探索(苏格拉底对话)

Phase 2: 动态规划(AI 规划 + 挑战)

Phase 3: 自主执行(Agent 协作群)

Phase 4: 主动汇报(AI 推送)

4.2 编排层的范式转变

4.3 界面的范式转变

5. 核心能力清单

5.1 能力 vs 现状

5.2 能力依赖关系

6. 技术方向

6.1 编排层:全新实现

6.2 通信层:中央调度 + 共享状态

6.3 入口层:双入口——对话 + Dashboard

6.4 经验层:从无到有

7. 开发策略

设计推进方式

开发启动条件

8. 调研发现与待回答问题

8.1 编排智能化 — 已有部分答案

8.2 共享意识 — 已有部分答案

8.3 Agent 自主协作 — 已有框架

8.4 经验沉淀 — 已有成熟框架

8.5 人的介入方式 — 已有成熟做法

8.6 端到端参考 — 部分覆盖

9. 与现有系统的关系

10. 风险

10.1 安全红线（C9 详细定义）

10.2 v2.0 范围声明

10.3 多任务并发

10.4 任务失败恢复

附录: v1.0 → v2.0 变化摘要

24 KiB

Raw Blame History