root/goodbuddy
1
0
Fork 0
Code Issues Pull Requests Actions 4 Packages Projects Releases Wiki Activity
Files
a83f24a3344756bde4f75974d1f229b4eaa6f906
goodbuddy/docs/features/automation-platform-architecture.md
T
lofyer de497b9553 docs: expand product planning
2026-08-14 13:24:42 +08:00

19 KiB
Raw Blame History

自动化、监督与记忆平台总体设计

文档信息

项目 内容
状态 设计中
版本 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 核心实体

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 状态

draft → active ↔ paused → archived
  • draft：未通过配置校验，不能自动触发。
  • active：可以被触发。
  • paused：保留定义和历史，不产生新 Run。
  • archived：只读保留，不能恢复运行，复制后可继续使用。

6.2 Run 状态

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 状态

inactive → observing → attention_required → paused → resolved

监督状态不覆盖 Run 状态。Run 可以仍在运行但存在 attention_required，也可以因确定性门禁 进入 paused。

7. 统一运行循环

7.1 调度与执行分离

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. 目标、协议和实验的关系

目标：想得到什么结果
协议：用什么固定方法尝试
运行：协议的一次执行
实验：同一问题下多个隔离协议或变量组合的运行集合
监督：运行过程中独立判断是否偏离目标、违反约束或需要人工介入
记忆：运行可读的历史经验，以及运行结束后提出的候选经验

关键规则：

  • 没有可计算或可审查成功标准的目标，不允许宣称“已完成目标”。
  • 实验的最佳结果只在成功 Run 中选择。
  • 全部 Run 失败时，实验状态为失败，不生成伪最佳结果。
  • 模型生成的实验协议必须先由用户审查，或在只读、低成本模板中明确启用自动接受。
  • 实验结果不能直接修改生产自动化，只能创建候选版本。

10. 监督边界

监督分为两层：

10.1 确定性监督

由代码执行，适合：

  • 权限、目录和工具白名单。
  • Token、耗时、并发和输出大小预算。
  • JSON Schema、状态机和幂等约束。
  • 明确的停止条件和指标阈值。
  • 数据分区和跨范围访问。

确定性监督可以阻止、暂停或终止运行。

10.2 模型监督

适合：

  • 目标偏移。
  • 计划遗漏。
  • 结论与证据不一致。
  • 多个候选之间的定性差异。
  • 用户可能需要澄清的歧义。
  • 质量、表达和风险评论。

模型监督默认只评论或请求关注。它不能替代确定性安全边界，也不能自动批准高风险动作。

11. 记忆边界

11.1 计划读取链

运行只读取显式绑定的分区。推荐优先级：

当前 Run
→ 当前 Automation
→ 当前 Conversation（如有关联）
→ 当前 Project
→ Global

每一层都有独立结果数和字符预算。低层记忆不能通过同名内容自动覆盖高层记忆， 冲突必须被标记并交给上下文组装器处理。

11.2 写入规则

  • Run 只能直接写入自己的运行分区和候选区。
  • 向 Automation、Project 或 Global 晋升需要评估或用户确认。
  • 实验 Run 不能直接互相读取运行记忆。
  • Supervisor 的判断保存为观察或候选，不自动变成事实。
  • 被拒绝的候选保留摘要指纹，避免重复建议，同时不进入模型上下文。

12. 信息架构

建议将现有“智能心跳”逐步扩展为“自动化中心”，但保留心跳作为一种计划：

自动化中心
├─ 概览
│  ├─ 正在运行
│  ├─ 等待审批
│  ├─ 需要关注
│  └─ 最近结果
├─ 计划
│  ├─ 定时任务
│  ├─ 智能心跳
│  ├─ 目标任务
│  └─ 实验
├─ 运行
│  ├─ 时间线
│  ├─ 任务与步骤
│  ├─ 监督记录
│  ├─ 指标与证据
│  └─ 成果
├─ 建议
│  ├─ 记忆候选
│  ├─ 后续任务
│  └─ 学习候选
└─ 设置
   ├─ 全局预算
   ├─ 后台优先级
   ├─ 通知
   └─ 数据保留

会话页面增加可折叠“监督”右栏，与任务、上下文和成果并列，或在已有右侧工作栏中新增页签。

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 迁移细化：

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. 相关文档

18. 总体验收标准

  • 心跳、定时、目标和实验使用统一的 Plan 与 Run 术语。
  • 每个自动 Run 都能解释触发原因、目标、范围、预算、状态和结果。
  • Ask 自动化无法调用写工具或产生外部副作用。
  • Execute 自动化不能绕过现有审批、沙箱和能力控制。
  • 会话监督默认只评论，不能替用户发言或批准工具。
  • 并行 Run 的变量、会话、运行记忆、任务和成果相互隔离。
  • 失败 Run 不参与最佳结果选择，全部失败不报告成功。
  • 记忆跨分区读取必须显式授权并可审计。
  • 候选经验在评估门和回滚能力完成前不能自动改变未来行为。
  • 应用重启后状态可恢复，但不会自动重放结果未知的副作用步骤。
Reference in New Issue View Git Blame Copy Permalink