# 自动化、监督与记忆平台总体设计 ## 文档信息 | 项目 | 内容 | | --- | --- | | 状态 | 设计中 | | 版本 | 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 不参与最佳结果选择，全部失败不报告成功。 - [ ] 记忆跨分区读取必须显式授权并可审计。 - [ ] 候选经验在评估门和回滚能力完成前不能自动改变未来行为。 - [ ] 应用重启后状态可恢复，但不会自动重放结果未知的副作用步骤。