[RFC] Personal assistant architecture: Bot, discovery, durable work and memory / 个人助手架构

[xxhZs]

Summary

Maka's personal assistant presents one conversation to the user, while four modules handle coordination, proactive discovery, durable work and memory maintenance. This RFC documents their responsibilities and scheduling boundaries, using the locally deployed two-stage discovery variant as the reference implementation.

Status: architecture discussion, not a claim that this entire variant is on main. The shared-notebook discovery/judgement implementation is on the experimental branch linked below. This write-up is based on source, built modules and persisted runtime state inspected on 2026-10-23; no new end-to-end or paid-model test was run for this RFC.

Architecture

All four modules use Maka's existing Agent Runtime. The Runtime Host owns timers, persistence and worker lifecycle; it is not another scheduling LLM. Solid connections below summarize control/results, and dotted connections mean on-demand reads.

flowchart TB
  U(["User · 用户"])
  subgraph BOT["01 · Bot · 个人助手与调度"]
    direction LR
    I["Inbox<br/>接收与批量投递"] --> B["Agent loop<br/>交流 · 调度 · 配置"]
    B --> S["SendUser<br/>发送用户消息"]
    B --> Z["Sleep<br/>新输入唤醒后继续"]
  end
  subgraph DIS["02 · Proactive discovery · 主动发现"]
    direction LR
    D["Discovery<br/>广度探索"] --> N["Notebook<br/>简洁认识 · 仅追加"]
    N <--> J["Judgement<br/>深度调查 · 是否交流"]
  end
  subgraph MAT["03 · Durable work · 持续工作"]
    direction LR
    A["Task Agent + state<br/>目标 · 会话 · 工作记录"] --> E["Settle<br/>继续 / 等待 / 完成"]
    E --> A
  end
  subgraph MEM["04 · Memory maintenance · 记忆维护"]
    direction LR
    R["Sources + originals<br/>Session / 外部来源"] --> W["Indexing Agent<br/>创建 · 增量维护"]
    W --> X["Multiple indexes<br/>多视角 · 独立覆盖"]
    X <-->|"原文引用 / 反向导航"| R
  end
  U <-->|"聊天 / Chat"| BOT
  BOT <-->|"启停与周期 / 有价值的结果"| DIS
  BOT <-->|"委派与追加 / 进展与阻塞"| MAT
  DIS -.->|"按需查询索引与原文"| MEM
  MAT -.->|"按需查询索引与原文"| MEM
  classDef bot fill:#eef2ff,stroke:#6366f1,color:#1e293b;
  classDef discover fill:#f5f3ff,stroke:#8b5cf6,color:#1e293b;
  classDef matter fill:#fff7ed,stroke:#f59e0b,color:#1e293b;
  classDef memory fill:#ecfdf5,stroke:#10b981,color:#1e293b;
  class I,B,S,Z bot;
  class D,N,J discover;
  class A,E matter;
  class R,W,X memory;
  style BOT fill:#fafbff,stroke:#818cf8,stroke-width:2px
  style DIS fill:#fdfbff,stroke:#a78bfa,stroke-width:2px
  style MAT fill:#fffcf7,stroke:#fbbf24,stroke-width:2px
  style MEM fill:#f8fefa,stroke:#34d399,stroke-width:2px

Loading

For readability, the diagram omits the Bot's direct memory queries and index-management calls. Index completion/failure notifications also return to its Inbox.

What each module does

Module	Responsibility	Important boundary
Bot — personal assistant and coordinator	Receives user messages and background results, handles short operations, delegates longer work, manages indexes and discovery settings, and communicates with the user.	Its worker is a resumable loop. Only SendUser sends a chat message; ordinary model text does not. Sleep yields until new input.
Proactive discovery	Discovery explores broadly; Judgement investigates deeply and decides what is worth communicating. Both append concise observations to a shared notebook.	These are separate, reusable Sessions. Judgement chooses from the whole notebook, not a fixed candidate list. It can produce zero, one or several messages, which go to the Bot. Investigation is intended to be read-only.
Durable work / Matter	Advances a user objective in its own Session, maintains task state and work records, and resumes after a concrete wait. Reports progress, results, blockers and clarification requests to the Bot.	continue / wait / complete are explicit settlement outcomes. Independent model review applies to waiting and completion, not ordinary continuation; rejection asks the executor to correct the gap and continue.
Memory maintenance	Makes multiple indexes over Session history and authorized external sources, preserving links back to originals. Background indexing Agents create and maintain those views.	Each index has its own criteria and coverage checkpoint. Reading or refreshing source observations does not advance index coverage. Feishu remains a source plugin.

The Bot is a loop, not a long-running foreground task

A durable Inbox batches user input and background messages into the Bot worker. InboxCheck delivers new input; delivery bookkeeping is not proof that a task was completed. The Bot can send multiple messages, handle more input, or sleep without sending anything. Sending and sleeping are independent. New input wakes a sleeping worker; it cannot settle into sleep while newly undelivered input remains.

Long work runs independently through Matter or an indexing worker. This reduces foreground blocking; it is not a guarantee of preemption or instant replies if the Bot itself invokes a slow tool.

Indexes and the notebook serve different purposes

• Originals and indexes: evidence plus different searchable projections of it. Index entries lead back to source material; raw history remains directly searchable. Indexes may lag.
• Discovery notebook: short, time-aware observations about the user's world—interests, situations, resources, unknowns and connections. Both stages append new understanding and corrections. It is not a transcript, evidence dump or authoritative task list.
• Matter state: an explicit task objective, execution progress and waiting/completion decisions.
• Inbox: communication and delivery between the user, Bot and background workers.

Discovery reads indexes, history and the notebook as useful entry points, and may investigate outside them. Judgement reads the notebook from a file, investigates relevant originals/current information and appends what it learns, whether or not it recommends anything. Notes can therefore remain useful after a round that sends no message. A prepared recommendation is not the same as a message actually sent through SendUser.

Who wakes what?

Module	Trigger	What is scheduled
Bot	New Inbox input	Resume communication and coordination; the Bot does not set its own heartbeat.
Discovery → Judgement	Configured Host heartbeat or manual check	Run broad discovery, commit notebook additions, then run judgement. A pending judgement can be resumed without repeating completed discovery.
Matter	Delegation, additional input, or a registered time/condition	Resume that specific objective. Following one task must not change the global discovery interval.
Memory maintenance	Creation, explicit maintenance, or its configured maintenance cycle	Update eligible indexes, with independent checkpoints. This cycle is separate from discovery and task wake-ups.

Source observation and index maintenance are also separate: observations describe what is available; a successful indexing checkpoint records what has been organized. coveredCursor, observedCursor and pending-change counts locate covered/uncovered information, not its value. No new data does not mean there is nothing worth discovering in existing information. Agents can read uncovered history or query originals directly. An observation error must remain visible rather than looking like zero changes.

For Feishu messages, explicit synchronization populates the local source cache; index observation is not an implicit download of all remote chat history. Other source types retain their adapter-specific access behavior.

Future directions

These are directions for discussion, not claims of completed deployment or a committed delivery schedule. The main thread is discover → investigate → advance the work → deliver something useful → learn from the outcome.

Direction	Intended result
1. Connect discovery with durable work	Turn a worthwhile finding into a task with a clear objective when appropriate. Bring task progress and new understanding back into memory and discovery, avoiding duplicate investigations and conflicting updates.
2. Fast / incremental discovery	Respond quickly to new messages, source changes and approaching time-sensitive events. Keep this timely, accurate path alongside slower, broader exploration; run it outside the Bot so investigation does not occupy the conversation loop.
3. From findings to useful outputs	Go beyond suggestions: decide when to produce a usable result, build a lightweight demo, ask a meaningful question or delegate execution. Judge success by utility to the user, not by the number of generated files. Acting remains subject to the applicable user authorization.
4. Coordinate across devices and Hosts	Extend the existing multi-Host code into a coherent single-assistant experience: choose where work runs based on capability, data location and availability; support continuity, source/index access, task ownership and message synchronization across devices. End-to-end integration still needs verification.
5. Voice interaction	Let users speak, listen, interrupt and add requirements while work continues, sharing conversation and task context with text interaction.
6. Autonomous memory and index maintenance	Create, adapt and maintain useful indexes as needs emerge, detect missing perspectives and stale content, and reduce the amount of manual memory setup required from the user.
7. External sources and action capabilities	Connect email, calendars, work applications, browser/computer activity and other relevant sources with usable tools, so the assistant can both learn about changes and help address them.
8. Learn from actual interaction and outcomes	Relate delivered messages to explicit user feedback and subsequent results. Update what seems useful, outdated or worth approaching differently without treating silence as rejection or permanently discarding a direction because it was not recommended once.

Multi-device access and voice make the assistant easier to use; source and tool integrations determine what it can know and do; autonomous memory maintenance reduces manual upkeep. Across all directions, users should be able to understand what is happening, why the assistant is contacting them, and how to correct or stop it.

Scope and open questions

This describes the current module boundaries, not a new orchestration framework. Minute-level external-event discovery, autonomous graph expansion and automatic action execution are not claimed here. Recent local work tightening links between actual delivery and user feedback is not counted as verified active behavior: some rebuilt files postdate the running process.

The existing discussion in #6247 covers discovery boundaries and heartbeat cost. The ownership and capability concerns in #6249 and #6250 remain relevant; this diagram does not claim they are solved or that prompting alone enforces read-only behavior.

Feedback sought:

1. Are these four responsibilities and their scheduling boundaries clear enough to maintain independently?
2. Does the distinction between source-backed indexes, an append-only discovery notebook and task state make sense?
3. What evidence should we require before promoting the two-stage variant: user-visible usefulness, missed/repeated information, latency and cost—not just more notes or tool calls?

中文版（点击展开）

概要

个人助手对用户呈现一个对话入口，内部由四个模块分别承担调度、主动发现、持续工作和记忆维护。本 RFC 以当前本地部署的两阶段发现版本为参照，说明它们各自做什么、由谁唤醒，以及数据如何流动。

**状态：**架构讨论，不表示整套方案已经进入 main。共享记事本的发现／判断实现位于下方链接的实验分支。此次核对依据是 2026-10-23 查看过的源码、构建产物和运行持久化状态，没有为这篇 RFC 额外运行端到端测试或付费模型测试。上方架构图为中英双语。

四个核心模块

模块	做什么	边界
Bot：个人助手与调度	接收用户消息和后台结果，处理简短操作、委派长工作，管理索引和主动发现配置，与用户交流。	是可恢复的 Agent loop。只有 SendUser 会发送聊天消息，普通文本不会；Sleep 后等待新输入。
主动发现	发现端负责广度探索，判断端负责深入调查和决定是否值得交流；共同向记事本追加简短认识。	两个独立且可复用的 Session。判断从整份记事本自主选方向，不接收固定候选清单。可以没有推荐，也可以有一条或多条，交给 Bot；调查的设计意图是只读。
持续工作 / Matter	用独立 Session 推进一个用户目标，维护状态和工作记录，在明确的等待条件之后继续；把进展、结果、阻塞和澄清请求交给 Bot。	明确提交 continue / wait / complete。等待和完成需要独立模型审核，普通继续不需要；拒绝时返回缺口，让执行者修改后继续。
记忆维护	把 Session 历史及有权访问的外部来源整理成多个视角的索引，保留原文关联；由后台建索引 Agent 创建和维护。	每个索引独立维护整理要求和覆盖 checkpoint。读取及刷新来源观察不推进覆盖。飞书继续作为来源插件。

四者复用 Maka 已有的 Agent Runtime。定时器、持久化和 worker 生命周期由 Runtime Host 代码管理，不再添加一个调度模型。图中的实线概括控制与结果流，虚线表示按需读取。为保持清楚，图中省略了 Bot 直接查询记忆、创建与配置索引的连线；索引完成和失败也会反馈到 Bot 的 Inbox。

Bot 是循环，不是把长任务塞进前台

用户输入和后台反馈通过持久化 Inbox 批量投递给 Bot worker。InboxCheck 接收新增输入，投递记录不等于任务完成证明。Bot 可以发送多条消息、继续处理输入，也可以不说话就休眠；发送与休眠互不绑定。新输入唤醒休眠中的 worker；有尚未投递的新消息时，不能直接进入休眠。

耗时工作由 Matter 或建索引 worker 独立执行。这能减少前台阻塞，但不代表已有抢占能力，也不能保证 Bot 自己调用慢工具时仍然立即回复。

索引、记事本、任务状态不是一回事

• **原文与索引：**原始依据及其不同视角的可查询投影。索引条目可以回到原文，原始历史也可以直接搜索。索引允许滞后。
• **发现记事本：**关于用户相关世界的简短认识，包括兴趣、处境、资源、未知和联系，并保留时间。发现和判断都可以追加补充与修正；它不是对话全文、证据堆或权威待办表。
• **Matter 状态：**某项明确目标的执行进度，以及等待、完成等决定。
• **Inbox：**用户、Bot 和后台 worker 之间的通信与投递。

发现可以从索引、历史和记事本出发，也可以继续调查外部信息。判断从文件读取记事本，自主选择方向，核对相关原文与当前信息。无论是否推荐，新认识都可以追加，所以一轮不发消息不代表积累没有价值。准备好的推荐也不等于已经通过 SendUser 发给用户。

调度：谁唤醒谁？

模块	触发条件	推进什么
Bot	Inbox 新输入	恢复交流与调度，不自行登记助手心跳。
发现 → 判断	Host 中配置的心跳，或手动检查	先探索并提交记事本增量，再判断；待完成的判断可以恢复，不必重跑已完成的发现。
Matter	委派、追加信息、登记的时间或条件	恢复这个具体目标。跟进某一件事不等于修改全局发现周期。
记忆维护	创建、手动维护、独立配置的维护周期	更新符合条件的索引，各自推进 checkpoint。它和发现周期、任务唤醒是不同机制。

来源观察和索引整理也要区分：观察记录有哪些信息可用，成功的 checkpoint 才记录整理到了哪里。coveredCursor、observedCursor、待处理变化数量只定位存量和增量，不判断信息价值。没有增量，不代表已有信息里没有值得发现的东西。Agent 可以读未覆盖历史，也可以直接查原文；来源观察失败必须显式呈现，不能看起来像没有变化。

飞书消息通过显式同步进入本地来源缓存；读取索引时刷新来源观察，不等于遍历下载全部远端聊天。其他来源保留各自适配器的访问方式。

后续方向

以下是待讨论的发展方向，不表示已经部署完成，也不承诺交付排期。主线是：发现 → 调查判断 → 推进工作 → 交付有用成果 → 从结果中修正认识。

方向	想达到的效果
1. 发现与持续工作联动	在合适时把值得推进的发现转成有明确目标的任务；任务进展和新认识再回到记忆与发现，避免重复调查、各说各话。
2. 快速发现／增量发现	针对新消息、来源变化、时间临近等信号，及时判断值得通知的变化。与慢速、广度探索并存；快速调查也在 Bot 之外执行，不占用用户交流的循环。
3. 从发现到成果	不止建议用户做什么，而是判断什么时候直接产出结果、做轻量 Demo、问一个有意义的问题，或委派执行。以用户能否用上衡量价值，不以生成了多少文件衡量；实际行动仍遵循相应的用户授权。
4. 多端协调	基于已有多 Host 代码，把多个设备组织成一个助手：根据能力、数据位置和在线情况安排工作，打通跨端接续、来源与索引访问、任务归属和消息同步。完整接通的效果仍需验证。
5. 语音支持	支持自然地说、听、打断和追加要求，与文字共享对话和任务上下文，执行过程中仍能交流。
6. 记忆与索引自主维护	根据实际需要创建、调整和维护索引，发现缺失视角和过期内容，减少用户手动配置记忆的负担。
7. 外部来源与能力生态	接入邮件、日历、工作软件、浏览器或电脑活动等来源，并衔接可执行的工具，既知道世界发生了什么，也能帮用户处理。
8. 从真实交互和结果中调整理解	关联实际送达的消息、明确的用户反馈及后续结果，理解什么有用、什么过时、什么应该换个方式推进。不把沉默当拒绝，也不因一次没有推荐就永久封死某个方向。

多端和语音让助手更容易使用；来源与工具决定它能知道什么、做到什么；自主记忆维护减少手动养护。贯穿所有方向的要求是：用户能看懂它正在做什么、为什么来找自己，以及怎样纠正或停止它。

范围与讨论点

这里整理现有模块边界，不扩展新的调度框架。分钟级外部事件发现、自主扩图、自动执行行动，不作为本次已实现能力。近期本地正在加强实际送达与用户反馈的关联，但部分构建文件晚于当前进程启动时间，因此也不计入已确认运行的能力。

#6247 已在讨论发现边界和心跳成本；#6249、#6250 提出的任务归属和能力边界问题仍然相关。本图不表示这些问题已解决，也不表示仅靠提示词就实现了严格只读。

希望讨论三个问题：

1. 四个模块的职责和唤醒边界是否清楚，能否分别维护？
2. 基于原文的索引、仅追加的发现记事本、持续任务状态，是否应该保持这样的分工？
3. 两阶段版本进入主线前，应如何验证用户得到的价值、遗漏与重复、耗时和成本，而不只是比较笔记数量或工具调用数？

Implementation references / 实现参考

Reference snapshot: 198dfe4c7, experimental branch test/discovery-split-20261020. These are reproducible source references, not a claim that every later local edit is loaded in the running process.

• Bot runtime and tools / Bot 循环与工具
• Discovery orchestration / 两阶段调度
• Discovery, judgement and notebook instructions / 分工与记事本规则
• Notebook persistence / 记事本持久化
• Durable work / 持续工作
• Memory maintenance / 记忆维护

---

AI-assisted write-up, prepared and posted by Codex at the author’s request. / 本文由 Codex 协助整理，并按作者要求发布。