529 lines
19 KiB
Markdown
529 lines
19 KiB
Markdown
# 自动化、监督与记忆平台总体设计
|
|
|
|
## 文档信息
|
|
|
|
| 项目 | 内容 |
|
|
| --- | --- |
|
|
| 状态 | 设计中 |
|
|
| 版本 | 0.1 |
|
|
| 日期 | 2026-08-13 |
|
|
| 适用产品 | GoodBuddy 桌面端 |
|
|
| 文档角色 | 自动任务、目标、并行实验、会话监督、分区记忆与持续学习的总纲 |
|
|
|
|
## 1. 背景
|
|
|
|
GoodBuddy 当前已经具备若干长期助手能力，但它们仍是彼此分离的功能：
|
|
|
|
1. 定时任务支持单次、每日和每周触发，创建 Ask 任务并保存任务和成果。
|
|
2. 智能心跳支持全局或项目范围的每日、每周回顾，读取有界会话、任务和已确认记忆，
|
|
生成摘要、记忆建议和后续任务。
|
|
3. 专家子任务支持有限并发和只读综合，但没有实验变量、重复运行、统一指标和结果晋升。
|
|
4. 记忆已有全局、项目、会话三种作用域，以及偏好、事实、摘要、流程四种类型，
|
|
但检索、来源、时态、冲突和运行级隔离仍不完整。
|
|
5. 魔法笔记已经提供“内容旁持续出现 AI 评论”的交互，可作为会话监督的体验参考，
|
|
但它只分析笔记或待办，不观察会话和任务运行。
|
|
|
|
如果继续把更多能力加入“智能心跳”，心跳将同时承担调度、总结、执行、监督、学习和
|
|
记忆管理，最终无法解释一次后台行为为什么发生、读取了什么、是否越权、产生了什么影响。
|
|
|
|
本设计将这些能力统一到一个平台模型中，同时保留不同产品的清晰边界。
|
|
|
|
## 2. 核心产品判断
|
|
|
|
### 2.1 不把心跳升级成万能后台 Agent
|
|
|
|
智能心跳应继续承担周期性观察和回顾，不直接成为所有自动化的宿主。
|
|
|
|
- 定时任务解决“何时执行一个已知任务”。
|
|
- 目标任务解决“围绕结果持续规划和推进”。
|
|
- 并行实验解决“隔离多个候选并用相同标准比较”。
|
|
- 会话监督解决“独立观察并在必要时评论、告警或暂停”。
|
|
- 记忆系统解决“哪些经验可以在什么范围内被未来运行读取”。
|
|
- 持续学习解决“候选经验如何经过评估后改变未来行为”。
|
|
|
|
这些能力可以共享调度、运行、证据、预算和审计基础，但不能共享一段不断膨胀的提示词。
|
|
|
|
### 2.2 增加会话监督，但不把它等同于第二个聊天 Agent
|
|
|
|
建议新增会话监督功能，并借鉴魔法笔记的右侧 AI 评论流：
|
|
|
|
- 默认只观察和评论，不替用户发言。
|
|
- 只依据可见消息、工具事件、任务状态、成果和目标进行判断。
|
|
- 不读取或展示模型隐藏推理。
|
|
- 评论必须引用具体消息、步骤或证据。
|
|
- 模型监督可以建议暂停，只有确定性安全规则或用户预先批准的门禁才能自动暂停。
|
|
- 监督器不能自动批准工具、扩大目录、跨项目读取记忆或修改安全策略。
|
|
|
|
### 2.3 先做分区和来源，再做知识图谱
|
|
|
|
GoodBuddy 当前最需要的不是立即引入重型图数据库，而是保证：
|
|
|
|
1. 运行只能读取明确允许的记忆分区。
|
|
2. 并行实验的各个 Run 不共享可变记忆。
|
|
3. 每条记忆知道来自哪次会话、任务、监督判断或实验结果。
|
|
4. 新事实与旧事实冲突时保留时态和证据，不静默覆盖。
|
|
5. 记忆进入模型上下文前经过范围、状态、敏感度和预算过滤。
|
|
|
|
SQLite、FTS 和可选本地向量已经足够支撑第一阶段。只有出现明确的关系追踪和跨实体查询
|
|
需求后，才考虑时间知识图谱。
|
|
|
|
### 2.4 学习必须有评估门和回滚
|
|
|
|
“生成一条总结并保存”不等于持续学习。只有当候选经验通过回放或实验验证，并能安全改变
|
|
未来行为时，才构成学习闭环。
|
|
|
|
初期自动学习只允许产生可审查候选，不允许自动修改：
|
|
|
|
- 工具权限和审批策略。
|
|
- Electron 安全边界。
|
|
- 项目根目录和数据访问范围。
|
|
- Runtime 沙箱。
|
|
- 系统级提示词。
|
|
- 远程消息发送或其他外部副作用策略。
|
|
|
|
## 3. 目标
|
|
|
|
### 3.1 用户目标
|
|
|
|
- 用统一入口创建定时、事件、目标和实验型自动任务。
|
|
- 清楚知道自动任务的触发原因、当前目标、运行状态、预算和停止条件。
|
|
- 在一个工作台中观察多个候选运行，并追溯结论到原始证据。
|
|
- 为重要会话启用独立监督，及时发现偏题、遗漏、矛盾、证据不足和风险。
|
|
- 知道每条记忆属于哪个范围、从哪里产生、何时有效以及被哪些运行使用。
|
|
- 审查、批准、拒绝或回滚系统提出的记忆、模板和策略改进。
|
|
|
|
### 3.2 产品目标
|
|
|
|
- 复用现有 Project、Conversation、Task、Run、Artifact、Approval 和 Notification 能力。
|
|
- 为所有后台工作提供统一的幂等、租约、恢复、取消、预算和审计语义。
|
|
- 保持 Ask 只读，Execute 继续经过现有能力和审批控制。
|
|
- 保持本地优先，应用退出后不虚假承诺后台持续执行。
|
|
- 保证项目、会话、自动化和实验 Run 之间的记忆隔离。
|
|
- 先建立可观测和可评估能力，再允许任何形式的自动行为改变。
|
|
|
|
## 4. 非目标
|
|
|
|
本组设计不包含：
|
|
|
|
- 将 GoodBuddy 变为需要常驻服务器、Redis 或云端控制面的多租户平台。
|
|
- 在应用退出后依靠未安装的系统服务继续运行任务。
|
|
- 默认允许无人值守高风险 Execute。
|
|
- 让模型自行扩大工具、目录、知识库、记忆或网络访问范围。
|
|
- 允许多个实验 Run 并发修改同一个用户工作区。
|
|
- 记录键盘、持续录屏或静默监控其他应用。
|
|
- 把隐藏推理链作为监督、记忆或审计数据保存。
|
|
- 初期直接建设通用可视化工作流 DAG 编辑器。
|
|
- 将模型评分当作没有误差的客观真值。
|
|
|
|
## 5. 统一领域模型
|
|
|
|
### 5.1 核心实体
|
|
|
|
```text
|
|
AutomationPlan
|
|
├─ TriggerPolicy
|
|
├─ ObjectiveSet
|
|
├─ ExecutionProtocol
|
|
├─ BudgetPolicy
|
|
├─ ApprovalPolicy
|
|
├─ SupervisorPolicy
|
|
└─ MemoryBinding
|
|
│
|
|
└─ AutomationRun
|
|
├─ Task / Child Task
|
|
├─ Observation
|
|
├─ SupervisorDecision
|
|
├─ Artifact
|
|
├─ Metric
|
|
└─ MemoryCandidate
|
|
```
|
|
|
|
| 实体 | 职责 |
|
|
| --- | --- |
|
|
| `AutomationPlan` | 用户可编辑的长期定义，描述做什么、为何做、何时做和允许做什么 |
|
|
| `TriggerPolicy` | 手动、时间、事件或条件触发，以及错过执行策略 |
|
|
| `ObjectiveSet` | 成功标准、优化指标、约束和停止条件 |
|
|
| `ExecutionProtocol` | 本次运行冻结的提示、步骤模板、变量、Runtime、工具和数据范围 |
|
|
| `BudgetPolicy` | 最大耗时、模型调用、Token、工具次数、子任务数、成果大小和并发 |
|
|
| `ApprovalPolicy` | 哪些动作可自动执行、哪些等待批准、哪些禁止 |
|
|
| `SupervisorPolicy` | 观察维度、触发频率、干预级别和确定性门禁 |
|
|
| `MemoryBinding` | 运行可读取和可写入哪些记忆分区 |
|
|
| `AutomationRun` | 一次触发产生的不可变运行快照和聚合状态 |
|
|
| `Observation` | 对消息、步骤、工具、指标或系统状态的结构化观察 |
|
|
| `SupervisorDecision` | `continue`、`comment`、`warn`、`request_review`、`pause` 或 `stop` |
|
|
| `Metric` | 可复现的运行指标及其计算来源 |
|
|
| `MemoryCandidate` | 尚未进入未来上下文的候选经验 |
|
|
|
|
### 5.2 自动化类型
|
|
|
|
`AutomationPlan.kind` 第一阶段使用有限枚举，而不是任意工作流：
|
|
|
|
| 类型 | 说明 |
|
|
| --- | --- |
|
|
| `scheduled_task` | 到点运行一个固定任务 |
|
|
| `heartbeat_review` | 周期性观察会话、任务和记忆，输出回顾和建议 |
|
|
| `goal_loop` | 围绕目标重复执行“观察、计划、行动、评估” |
|
|
| `experiment` | 生成隔离候选 Run，按统一协议评估和比较 |
|
|
|
|
会话监督不是独立执行任务。它是可附着到 Conversation、Task、AutomationRun 或
|
|
Experiment 的 `SupervisorPolicy` 和监督会话。
|
|
|
|
### 5.3 运行快照
|
|
|
|
每次启动必须冻结：
|
|
|
|
- Plan 版本。
|
|
- 项目和工作目录。
|
|
- Runtime 和模型配置引用。
|
|
- 工作模式。
|
|
- 提示和变量。
|
|
- 工具、Skills、MCP 和知识库范围。
|
|
- 可读、可写记忆分区。
|
|
- 监督策略和评估器版本。
|
|
- 预算和并发限制。
|
|
- 审批策略。
|
|
|
|
运行开始后的设置变化只影响下一次 Run。用户可以查看当前 Run 与最新 Plan 的差异。
|
|
|
|
## 6. 统一状态模型
|
|
|
|
### 6.1 Plan 状态
|
|
|
|
```text
|
|
draft → active ↔ paused → archived
|
|
```
|
|
|
|
- `draft`：未通过配置校验，不能自动触发。
|
|
- `active`：可以被触发。
|
|
- `paused`：保留定义和历史，不产生新 Run。
|
|
- `archived`：只读保留，不能恢复运行，复制后可继续使用。
|
|
|
|
### 6.2 Run 状态
|
|
|
|
```text
|
|
queued
|
|
→ running
|
|
→ waiting_approval
|
|
→ paused
|
|
→ evaluating
|
|
→ completed
|
|
|
|
任意活动状态
|
|
→ failed | cancelled | interrupted | budget_exceeded | superseded
|
|
```
|
|
|
|
规则：
|
|
|
|
- `completed` 只表示协议成功结束，不自动表示目标达成。
|
|
- `goalStatus` 独立为 `met`、`not_met`、`inconclusive` 或 `not_applicable`。
|
|
- 应用退出时活动 Run 标记为 `interrupted`，不自动重放有副作用步骤。
|
|
- `waiting_approval` 不占用 LLM 并发配额。
|
|
- 预算耗尽必须使用 `budget_exceeded`，不能伪装为普通失败。
|
|
|
|
### 6.3 Supervisor 状态
|
|
|
|
```text
|
|
inactive → observing → attention_required → paused → resolved
|
|
```
|
|
|
|
监督状态不覆盖 Run 状态。Run 可以仍在运行但存在 `attention_required`，也可以因确定性门禁
|
|
进入 `paused`。
|
|
|
|
## 7. 统一运行循环
|
|
|
|
### 7.1 调度与执行分离
|
|
|
|
```text
|
|
Trigger
|
|
→ AutomationCoordinator 声明 Run
|
|
→ RunQueue 按优先级和预算排队
|
|
→ AutomationExecutor 创建 Task
|
|
→ Runtime 执行
|
|
→ Supervisor 观察
|
|
→ Evaluator 计算指标
|
|
→ 结果、证据和候选记忆入库
|
|
→ 用户审查或后续 Run
|
|
```
|
|
|
|
`AutomationCoordinator` 只负责触发、声明和恢复，不直接调用模型。执行仍通过任务和 Runtime
|
|
边界完成。
|
|
|
|
### 7.2 优先级
|
|
|
|
默认优先级从高到低：
|
|
|
|
1. 用户正在等待的前台对话。
|
|
2. 用户手动启动的 Run。
|
|
3. 等待批准后恢复的 Run。
|
|
4. 到期定时任务。
|
|
5. 目标循环和实验 Run。
|
|
6. 心跳回顾、记忆巩固和维护。
|
|
|
|
后台任务必须可被背压延后。延后记录为 `deferred`，不得丢失，也不得在系统恢复空闲时一次性
|
|
释放全部积压。
|
|
|
|
### 7.3 幂等和租约
|
|
|
|
- 每次计划触发使用 `planId + scheduledFor + planVersion` 形成幂等键。
|
|
- 手动触发使用调用方提供的单次幂等键。
|
|
- Run 和长步骤使用租约，租约过期后才能恢复或重试。
|
|
- 有外部副作用的步骤还需要工具级幂等键，无法确认结果时进入
|
|
`outcome_unknown`，不得自动重试。
|
|
- 同一个 Plan 可以限制最大活动 Run 数，默认 1。
|
|
|
|
## 8. 触发模型
|
|
|
|
### 8.1 支持顺序
|
|
|
|
| 阶段 | 触发类型 |
|
|
| --- | --- |
|
|
| 第一阶段 | 手动、单次、每日、每周、每月、受限 Cron |
|
|
| 第二阶段 | 应用启动、会话完成、任务完成或失败、文件同步完成、变量变化 |
|
|
| 后续 | 用户定义的组合条件和外部受信任事件 |
|
|
|
|
事件触发必须来自 Main 进程内的持久事件，不允许 Renderer 临时事件直接启动高影响自动化。
|
|
|
|
### 8.2 错过执行策略
|
|
|
|
| 策略 | 行为 |
|
|
| --- | --- |
|
|
| `skip` | 记录跳过，不补跑 |
|
|
| `run_once` | 无论错过多少次，只补一次 |
|
|
| `catch_up_bounded` | 在数量和时间窗口上限内补跑 |
|
|
|
|
默认：
|
|
|
|
- 日常摘要使用 `run_once`。
|
|
- 高频事件使用 `skip` 或事件去重。
|
|
- 不允许无限补跑。
|
|
|
|
## 9. 目标、协议和实验的关系
|
|
|
|
```text
|
|
目标：想得到什么结果
|
|
协议：用什么固定方法尝试
|
|
运行：协议的一次执行
|
|
实验：同一问题下多个隔离协议或变量组合的运行集合
|
|
监督：运行过程中独立判断是否偏离目标、违反约束或需要人工介入
|
|
记忆：运行可读的历史经验，以及运行结束后提出的候选经验
|
|
```
|
|
|
|
关键规则：
|
|
|
|
- 没有可计算或可审查成功标准的目标，不允许宣称“已完成目标”。
|
|
- 实验的最佳结果只在成功 Run 中选择。
|
|
- 全部 Run 失败时，实验状态为失败，不生成伪最佳结果。
|
|
- 模型生成的实验协议必须先由用户审查，或在只读、低成本模板中明确启用自动接受。
|
|
- 实验结果不能直接修改生产自动化，只能创建候选版本。
|
|
|
|
## 10. 监督边界
|
|
|
|
监督分为两层：
|
|
|
|
### 10.1 确定性监督
|
|
|
|
由代码执行，适合：
|
|
|
|
- 权限、目录和工具白名单。
|
|
- Token、耗时、并发和输出大小预算。
|
|
- JSON Schema、状态机和幂等约束。
|
|
- 明确的停止条件和指标阈值。
|
|
- 数据分区和跨范围访问。
|
|
|
|
确定性监督可以阻止、暂停或终止运行。
|
|
|
|
### 10.2 模型监督
|
|
|
|
适合：
|
|
|
|
- 目标偏移。
|
|
- 计划遗漏。
|
|
- 结论与证据不一致。
|
|
- 多个候选之间的定性差异。
|
|
- 用户可能需要澄清的歧义。
|
|
- 质量、表达和风险评论。
|
|
|
|
模型监督默认只评论或请求关注。它不能替代确定性安全边界，也不能自动批准高风险动作。
|
|
|
|
## 11. 记忆边界
|
|
|
|
### 11.1 计划读取链
|
|
|
|
运行只读取显式绑定的分区。推荐优先级：
|
|
|
|
```text
|
|
当前 Run
|
|
→ 当前 Automation
|
|
→ 当前 Conversation（如有关联）
|
|
→ 当前 Project
|
|
→ Global
|
|
```
|
|
|
|
每一层都有独立结果数和字符预算。低层记忆不能通过同名内容自动覆盖高层记忆，
|
|
冲突必须被标记并交给上下文组装器处理。
|
|
|
|
### 11.2 写入规则
|
|
|
|
- Run 只能直接写入自己的运行分区和候选区。
|
|
- 向 Automation、Project 或 Global 晋升需要评估或用户确认。
|
|
- 实验 Run 不能直接互相读取运行记忆。
|
|
- Supervisor 的判断保存为观察或候选，不自动变成事实。
|
|
- 被拒绝的候选保留摘要指纹，避免重复建议，同时不进入模型上下文。
|
|
|
|
## 12. 信息架构
|
|
|
|
建议将现有“智能心跳”逐步扩展为“自动化中心”，但保留心跳作为一种计划：
|
|
|
|
```text
|
|
自动化中心
|
|
├─ 概览
|
|
│ ├─ 正在运行
|
|
│ ├─ 等待审批
|
|
│ ├─ 需要关注
|
|
│ └─ 最近结果
|
|
├─ 计划
|
|
│ ├─ 定时任务
|
|
│ ├─ 智能心跳
|
|
│ ├─ 目标任务
|
|
│ └─ 实验
|
|
├─ 运行
|
|
│ ├─ 时间线
|
|
│ ├─ 任务与步骤
|
|
│ ├─ 监督记录
|
|
│ ├─ 指标与证据
|
|
│ └─ 成果
|
|
├─ 建议
|
|
│ ├─ 记忆候选
|
|
│ ├─ 后续任务
|
|
│ └─ 学习候选
|
|
└─ 设置
|
|
├─ 全局预算
|
|
├─ 后台优先级
|
|
├─ 通知
|
|
└─ 数据保留
|
|
```
|
|
|
|
会话页面增加可折叠“监督”右栏，与任务、上下文和成果并列，或在已有右侧工作栏中新增页签。
|
|
|
|
## 13. 安全与隐私
|
|
|
|
1. Ask 在 Runtime 边界保持只读，而不只是提示词要求只读。
|
|
2. Execute 继续通过现有审批、沙箱、工具和目录控制。
|
|
3. 无人值守只允许用户显式批准的能力集合；遇到未预授权动作时进入等待审批。
|
|
4. Supervisor、Evaluator 和 Heartbeat 都把消息、工具输出、记忆和成果视为不可信数据。
|
|
5. 监督器不能读取隐藏推理，只能读取产品允许持久化和展示的事件。
|
|
6. 所有跨分区读取由 Main 根据绑定关系决定，Renderer 不能提交任意分区 ID。
|
|
7. 记忆和监督证据不得包含密钥、认证头、Cookie、完整私有文件或未经限制的工具输出。
|
|
8. 自动化产生的通知默认隐藏私人内容。
|
|
9. 应用退出时停止调度和新执行，持久化中断状态，释放 Runtime 和租约。
|
|
10. 清除项目时按外键和显式事务清理其计划、运行、运行分区、监督记录和候选，
|
|
不影响 Global 或其他项目。
|
|
|
|
## 14. 可观测性
|
|
|
|
每个 Run 至少展示：
|
|
|
|
- 触发来源和计划版本。
|
|
- 计划目标和当前 `goalStatus`。
|
|
- Runtime、工作模式和工作目录。
|
|
- 实际读取的知识库与记忆分区。
|
|
- 实际调用的模型、Token、工具、耗时和成果大小。
|
|
- 当前预算和剩余预算。
|
|
- 任务、步骤和子任务状态。
|
|
- Supervisor 评论、证据、严重度和处理结果。
|
|
- 评估器版本、指标和证据。
|
|
- 产生的候选记忆或学习产物。
|
|
- 重试、延后、中断和恢复原因。
|
|
|
|
不得只显示一个模糊的“自动化成功率”而隐藏失败 Run、跳过 Run 或无结论 Run。
|
|
|
|
## 15. 建议的数据模型增量
|
|
|
|
以下为设计建议，字段在实现前仍需共享 Zod Schema 和 SQLite 迁移细化：
|
|
|
|
```text
|
|
automation_plans
|
|
automation_plan_versions
|
|
automation_triggers
|
|
automation_runs
|
|
automation_run_events
|
|
automation_metrics
|
|
automation_observations
|
|
supervisor_sessions
|
|
supervisor_decisions
|
|
memory_namespaces
|
|
memory_candidates
|
|
learning_artifacts
|
|
evaluation_cases
|
|
evaluation_results
|
|
experiments
|
|
experiment_variants
|
|
experiment_runs
|
|
```
|
|
|
|
现有 `schedules`、`schedule_runs`、`heartbeat_configs`、`heartbeat_runs`、
|
|
`heartbeat_entries`、`tasks` 和 `runs` 不应一次性重写。迁移顺序应先增加统一只读视图和
|
|
关联字段，再逐步让新计划使用统一模型。
|
|
|
|
## 16. 分阶段实施
|
|
|
|
### 阶段 0：统一术语和可观测性
|
|
|
|
- 固定 Plan、Run、Goal、Protocol、Supervisor、Observation、Memory Candidate 等概念。
|
|
- 为现有定时任务、心跳和专家子任务建立统一活动视图。
|
|
- 补充触发来源、运行版本、预算和读写范围展示。
|
|
|
|
### 阶段 1：调度与运行基础
|
|
|
|
- 统一 Run 声明、幂等、租约、恢复和错过执行策略。
|
|
- 增加月度和受限 Cron。
|
|
- 增加后台优先级与并发预算。
|
|
- 保持现有任务执行器不变。
|
|
|
|
### 阶段 2：会话监督与分区记忆
|
|
|
|
- 上线评论型会话监督。
|
|
- 增加 Automation 和 Run 记忆分区。
|
|
- 建立来源、证据、时态、冲突和晋升流程。
|
|
|
|
### 阶段 3：目标任务
|
|
|
|
- 增加目标、成功标准、约束、预算和停止条件。
|
|
- 支持有界的观察、计划、行动、评估循环。
|
|
- 默认 Ask 或需要逐步审批的 Execute。
|
|
|
|
### 阶段 4：并行实验
|
|
|
|
- 变量和运行隔离。
|
|
- 候选、重复、指标、证据、失败结算和最佳结果选择。
|
|
- 复用现有任务和受限子专家并发。
|
|
|
|
### 阶段 5：持续学习
|
|
|
|
- 先建立回放集和评估门。
|
|
- 再增加候选、Shadow、晋升、监控、衰减和回滚。
|
|
- 初期只晋升记忆和自动化模板，不自动改变安全策略。
|
|
|
|
## 17. 相关文档
|
|
|
|
- [自动任务、目标与调度 PRD](./automation-goals-and-scheduling-prd.md)
|
|
- [并行实验工作台 PRD](./parallel-experiments-prd.md)
|
|
- [会话监督 PRD](./conversation-supervision-prd.md)
|
|
- [分区记忆 PRD](./partitioned-memory-prd.md)
|
|
- [持续学习与评估门 PRD](./continuous-learning-prd.md)
|
|
- [GoodBuddy 长期助手功能规划](../long-term-assistant-roadmap.md)
|
|
- [GoodBuddy 统一界面设计系统](../../UI-DESIGN.md)
|
|
|
|
## 18. 总体验收标准
|
|
|
|
- [ ] 心跳、定时、目标和实验使用统一的 Plan 与 Run 术语。
|
|
- [ ] 每个自动 Run 都能解释触发原因、目标、范围、预算、状态和结果。
|
|
- [ ] Ask 自动化无法调用写工具或产生外部副作用。
|
|
- [ ] Execute 自动化不能绕过现有审批、沙箱和能力控制。
|
|
- [ ] 会话监督默认只评论，不能替用户发言或批准工具。
|
|
- [ ] 并行 Run 的变量、会话、运行记忆、任务和成果相互隔离。
|
|
- [ ] 失败 Run 不参与最佳结果选择，全部失败不报告成功。
|
|
- [ ] 记忆跨分区读取必须显式授权并可审计。
|
|
- [ ] 候选经验在评估门和回滚能力完成前不能自动改变未来行为。
|
|
- [ ] 应用重启后状态可恢复，但不会自动重放结果未知的副作用步骤。
|