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

Source discussion / 原讨论: #6252

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

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.
9. External Inbox integration	Add an external intake inbox, distinct from the existing internal Inbox used for communication and delivery between the user, Bot and background workers. Bring messages and other content from external sources, such as Feishu, into this separate intake so the personal assistant can understand them, relate them to relevant context and help process them. Access depends on each source’s available APIs and granted permissions; incoming external content is context, not an instruction from the user or authorization to act.

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:

Are these four responsibilities and their scheduling boundaries clear enough to maintain independently?
Does the distinction between source-backed indexes, an append-only discovery notebook and task state make sense?
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. 从真实交互和结果中调整理解	关联实际送达的消息、明确的用户反馈及后续结果，理解什么有用、什么过时、什么应该换个方式推进。不把沉默当拒绝，也不因一次没有推荐就永久封死某个方向。
9. 外部 Inbox 接入	增加独立的外部收件入口，区别于现有用于用户、Bot 和后台 worker 之间通信与投递的内部 Inbox。让飞书等外部来源中的消息及其他内容进入这个入口，由个人助手理解、关联相关上下文并协助处理。接入范围取决于各来源可用的 API 和已授予的权限；外部内容是上下文，不直接视为用户指令或行动授权。

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

范围与讨论点

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

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

希望讨论三个问题：

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

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.

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

@xxhZs

Thanks for writing this down. I'm working on the same Bot on rust-preview (#6464 is merged, the sleep tool is in #6505), so here is how the four modules line up with it and where I'd like feedback. These are my views, not decisions.

1. Bot loop: same shape, one deliberate difference. rust-preview has the same split: only SendUser speaks, ordinary model text stays internal, and sending and sleeping are independent. sleep takes no duration and ends the Turn; a user message, a WorkHub result or a due schedule starts the next one. The difference is the rule "it cannot settle into sleep while undelivered input remains". Here queued user messages are durable and start the next Turn by themselves, and the model cannot read them mid-Turn, so refusing sleep for them would only make it retry. In #6505 sleep is refused only when a message is already bound to the running Turn's next step (a promoted message). @xxhZs, is there a case on main where input must be seen before sleeping that this would miss?

2. Matter and WorkHub. My intention is for WorkHub to be folded into the Bot, as a separate and later step than the current PRs. For that I'd use Matter as the reference for what to carry over: explicit continue / wait / complete settlement with independent review on wait and complete is something WorkHub does not have today. The list I have for WorkHub is the dependency graph, preset freezing, idempotent receipts, and a worker result waking the Bot.

3. External content is context, not instruction (direction 9). Agreed, and it is the rule I plan for IM channels on rust-preview: one allow-listed owner, with external senders never treated as the owner.

4. Discovery and memory. I have not started either on rust-preview, and I would not copy the two-stage variant or the index design as is. I'd wait for the review of this RFC first. Keeping fast discovery outside the Bot loop fits the Bot being a coordinator.

5. Question 3, evidence before promotion. What I'd want to measure on the same machine, with the same model: messages sent versus acted on, repeated or missed information, time to the first useful message, and model calls and cost per wake. Counting notes or tool calls would not show whether the user got more value.

简体中文

感谢整理。我在 rust-preview 上做的是同一个 Bot（#6464 已合入，sleep 工具在 #6505），下面说明四个模块和它的对应关系，以及想听的意见。以下是我的看法，不是决定。

1. Bot 循环：形状一致，有一处刻意的不同。 rust-preview 也是这样分的：只有 SendUser 对外说话，普通模型文字保持内部，发送和休眠互相独立。sleep 不带时长、结束本轮；用户消息、WorkHub 结果或到点的定时任务会开启下一轮。不同的是“有未投递输入时不能进入休眠”这条：这里排队的用户消息是持久的，会自己开启下一轮，而模型在本轮里读不到它们，对它们拒绝休眠只会让模型反复重试。#6505 里只在“已有消息注定在本轮下一步送达”（被提升的消息）时拒绝休眠。@xxhZs，main 上有没有必须在休眠前看到输入、而这个规则会漏掉的情况？

2. Matter 与 WorkHub。 我的打算是把 WorkHub 并入 Bot，作为晚于当前这些 PR 的独立一步。并入时我想以 Matter 为参照来决定带过去什么：显式的 continue / wait / complete 结算，加上对等待和完成的独立审核，是 WorkHub 目前没有的。我列出的 WorkHub 需要带过去的有：依赖图、预设冻结、幂等回执，以及 worker 结果唤醒 Bot。

3. 外部内容是上下文，不是指令（方向 9）。 同意，这也是我给 IM 渠道设想的规则：只有一个白名单所有者，外部发送者不会被当作所有者。

4. 发现与记忆。 这两块我在 rust-preview 上还没有开始，也不会原样照搬两阶段版本或索引设计，想先等这个 RFC 的评审结果。把快速发现放在 Bot 循环之外，和“Bot 是协调者”一致。

5. 问题 3，晋升前要什么证据。 我想在同一台机器、同一个模型下衡量：发出的消息与被用户采纳的比例、重复或遗漏的信息、第一条有用消息的耗时，以及每次唤醒的模型调用次数和成本。只数记事本条数或工具调用数，看不出用户是否真的得到更多价值。

A few thoughts based on using a local build of TypeScript main, as input to the personal assistant architecture discussion.

1. How the Bot presents information

Ordinary conversation, proactive discoveries and task progress currently appear mainly as chat messages, and the distinction between them is not always clear. One matter may have progressed through several steps, but the Bot delivers its updates separately, interleaved with other topics. Looking back, it takes some effort to piece together what happened.

My impression is that, for a Bot continuously advancing multiple things, the current conversation format may have relatively low information density. More messages do not necessarily make it easier to understand what has progressed, what is finished, and what needs attention.

Different tasks also need different levels of visibility. For some tasks, the final result is enough, and showing every intermediate step adds reading overhead. For tasks that require careful verification, we need to see the execution process, supporting evidence and key decisions to assess whether the result is reliable. Even if that information exists in separate messages or background Sessions, making it easy to find and understand remains a separate problem.

As the Bot becomes more capable of discovering and advancing work proactively, presenting everything through chat messages may become less suitable. At least in my view, conversation alone may not be the Bot’s final interaction model.

I do not yet have a sufficiently good alternative presentation in mind. These are personal observations and questions, offered as input to the architecture and product discussion.

2. Could discovery contexts be organized around related investigations?

A concrete example comes from my local usage. On 2026-11-01 at 23:17–23:18 (UTC+8), using deepseek/deepseek-v4.1-flash through Command Code, a sample of five completed requests had 487,203–509,120 input tokens per request. Local records identify three as discovery requests and two as judgement requests.

Two examples:

Stage	Total input tokens	Input tokens served from cache	Uncached input tokens
Discovery	487,203	486,400	803
Judgement	509,120	446,464	62,656

These totals include substantial cached input, so actual cost needs to account for cached input, uncached input and output separately. Still, the observations raise a question: while retaining broad discovery, could related investigations continue in the same investigation Session, with unrelated investigations starting in separate contexts?

The potential benefits worth evaluating are less interference from unrelated history, more focused ongoing investigations, and better long-term operating cost. A new Session may also introduce additional work to recover background information, reread material and establish a cache, so any savings would need to be measured.

This would also require considering how discoveries, recommendations and feedback are recorded and associated. What has already been investigated, what has actually been delivered, whether the user wants a topic continued or stopped, and what has changed since then should remain available across Session changes. Otherwise, splitting contexts could lead to repeated recommendations or forgotten feedback.

3. The read scope of proactive discovery

Another concern is the filesystem read boundary of background exploration—for example, whether .ssh, .env and other credential files should be excluded by default, and how access to a specific location would be authorized when needed.

Read-only access can still bring file contents into model context. It would be useful for the architecture discussion to cover this boundary and how users can understand what information background discovery is allowed to access.

These are observations and ideas from local use, offered for discussion.

AI assistance: OpenAI Codex assisted with checking the local usage records and drafting this comment. I reviewed the content before posting.

简体中文

补充几点基于 TypeScript main 本地实际使用的想法，希望能为个人助手的架构讨论提供参考。

1. Bot 的对话展示与信息密度

目前普通对话、主动发现和任务进展主要以聊天消息呈现，几类消息的区别不太明显。同一件事可能已经推进了多个步骤，但更新由 Bot 分次发来，又与其他话题交错，回看时需要自己把过程拼起来。

个人感觉，对于持续推进多件事的 Bot，目前这种对话形式展示信息的密度可能偏低。消息越来越多，但不容易快速理解哪些事情有了进展、哪些已经完成，以及哪些需要自己关注。

不同任务对展示的需求也不一样。有些任务只需要得到最终结果，中间每一步都呈现出来会增加阅读负担；而一些需要严谨核对的任务，我们又需要看到执行过程、使用的依据和关键判断，才能确认结果是否可靠。即使这些信息已经存在于不同消息或后台 Session 中，用户能否方便地找到并理解它们，仍然是另一个问题。

这让我觉得，随着 Bot 能够主动发现并持续推进更多事情，单纯依靠聊天消息来承载所有信息，可能会逐渐显得不够合适。至少在我看来，对话未必是 Bot 最终的交互形态。

目前我还没有想到一种足够好的替代展示方式，所以先把这些使用感受和疑问提出来，作为架构与产品讨论的参考。

2. 主动发现的上下文是否可以按关联事项组织？

这里可以补充一组本机实际数据。2026 年 11 月 1 日 23:17–23:18（UTC+8），通过 Command Code 使用 deepseek/deepseek-v4.1-flash 时，抽取的五次已完成请求，其单次总输入为 487,203–509,120 tokens。核对本地记录后，其中三次属于主动发现，另外两次属于发现判断。

两个请求示例如下：

阶段	总输入 tokens	缓存读取 tokens	未缓存输入 tokens
主动发现	487,203	486,400	803
发现判断	509,120	446,464	62,656

总输入中包含大量缓存输入，实际成本需要分别考虑缓存输入、未缓存输入和输出。不过，这些观察让我想到：在保留全局广度探索的同时，是否可以让相关事项沿用同一个调查 Session，无关事项则使用新的工作上下文？

希望探索的是，这样能否减少无关历史的干扰，让持续调查更聚焦，并改善长期运行的成本。新 Session 也可能增加重新了解背景、读取材料和建立缓存的开销，因此是否更划算仍需要比较实际效果。

这也会涉及发现、推荐和反馈的记录与关联方式。哪些内容已经调查、哪些消息已经实际送达、用户希望继续还是停止，以及后来发生了什么变化，都需要在 Session 切换后保留下来。否则，拆分上下文也可能造成重复推荐，或忘记用户已经给出的反馈。

3. 主动发现的读取范围

另一个关心的点是后台探索的文件读取边界，例如 .ssh、.env 和其他凭据文件是否应该默认排除，以及确有需要时怎样针对特定位置授权访问。

只读访问也可能使文件内容进入模型上下文，因此希望架构讨论能够覆盖这部分，并让用户理解后台探索实际被允许接触哪些信息。

以上是本地使用过程中产生的一些观察和想法，供讨论参考。

AI 协助说明：OpenAI Codex 协助核对本地运行数据和整理文字，本评论由我审核后发布。

Following up on the first point in my earlier comment, I have now put together a UI prototype that feels reasonably close to what I had in mind.

The idea is to keep conversation as the main entry point, while making reply relationships and execution details easier to follow:

Execution details in a side panel. Clicking the completion status opens the associated Session’s workflow on the right, including its execution history and tool inputs/outputs. Users can inspect the process while keeping the main conversation visible.
Quoted context in both user and assistant replies. Selecting text lets users quote one or several excerpts. Replies retain nested quotation relationships and links back to the original messages.
Proactive discoveries in the same conversation. They appear directly in the main timeline with a clear source label, and users can quote and follow up on them in the same way.
Ordinary attachment presentation. Files remain separate attachments alongside the response.

For tasks where the result is enough, the main conversation provides it. When closer verification is needed, the execution history is available alongside it. The quotation structure also makes it easier to see what a follow-up refers to when unrelated topics appear in between.

Overall view — conversation, proactive discovery and Session workflow

Reply detail — nested quotations and a separate attachment

These screenshots show a local UI prototype with simulated messages, attachments and execution records. This is a concrete direction for discussion; the interaction details can still be refined.

AI assistance: OpenAI Codex assisted with building the prototype and drafting this comment. I reviewed the content before posting.

简体中文

补充一下上一条评论中的第一点：目前我做出了一版感觉大体合适、比较接近自己设想的 UI 原型。

思路是继续保留对话作为主要入口，同时让回复之间的关系和执行过程更容易查看：

执行详情从侧栏展开。 点击消息下方的完成状态，在右侧打开关联 Session 的工作流程，包括执行历史、工具输入和输出。查看过程时，主对话仍然保留在旁边。
用户和助手的回复都保留引用上下文。 拖选文字即可引用，也可以同时引用多处内容。回复中保留嵌套引用关系，并能回到原消息。
主动发现直接出现在同一对话中。 在消息上明确标识来源，用户同样可以引用它并继续追问。
附件正常展示。 文件作为独立附件显示在回复中。

只需要结果的任务，可以直接看主对话；需要严谨核对时，再展开旁边的执行记录。中间即使插入其他话题，也可以通过引用关系看清这次追问接的是哪段内容。

上面第一张图展示整体对话、主动发现和 Session 侧栏；第二张图展示回复中的嵌套引用与独立附件。

这些截图来自本地 UI 原型，消息、附件和执行记录均为模拟数据。目前先把这个方向具体展示出来，供讨论参考，交互细节仍可以继续调整。

AI 协助说明：OpenAI Codex 协助制作原型和整理文字，本评论由我审核后发布。

This is a very clear prototype, thanks for making it concrete. Keeping conversation as the entry point while opening the execution record beside it, instead of replacing the chat, seems the right balance to me. The nested quotation also answers the "which message is this follow-up about" problem well.

I'm working on the same Bot on rust-preview, so here is how your prototype maps onto what exists there. This is only to help decide what to build first.

Your prototype	On `rust-preview` today
Completion status opens the Session workflow on the right	Bot work already runs in real child Sessions (`parentSessionId` = the Bot), so a status line can link to a concrete Session. The workflow is shown in a separate page, not beside the chat. The side panel is the missing part.
Proactive discoveries with a source label	Messages already carry an origin, so the label has data to read. Nothing shows it in the chat yet.
Quoting one or several excerpts, nested	Not there. It needs a message reference stored with the reply, which is a data-model change and would need agreement first.
Files as separate attachments	Not for Bot messages yet (Feishu/attachments are later in my list).

Given that, I think the side panel is the cheapest first step and shows the most: it needs no new data, only a link from a Bot message to its worker Session. I'm happy to take that one if you haven't started it, or to review yours if you are going to send it. Tell me which you prefer so we don't build it twice.

简体中文

这个原型很清楚，感谢做得这么具体。保留对话作为入口、在旁边展开执行记录而不是取代聊天，我觉得是合适的平衡；嵌套引用也很好地解决了“这条追问接的是哪一段”的问题。

我在 rust-preview 上做同一个 Bot，下面是你的原型和现状的对应关系，只用来帮助决定先做哪一块：

原型里的做法	`rust-preview` 现状
点完成状态，右侧打开 Session 工作流程	Bot 的活已经在真实的子 Session 里跑（`parentSessionId` 指向 Bot），状态行可以链接到具体 Session。目前执行过程在单独页面里，不在聊天旁边，缺的是侧栏。
主动发现带来源标识	消息已带来源，标识有数据可读，但聊天里还没有展示。
引用一处或多处，可嵌套	还没有。需要在回复里存消息引用，属于数据模型改动，要先达成一致。
文件作为独立附件	Bot 消息暂时没有（附件在我的后续计划里）。

所以我觉得侧栏是最便宜、也最直观的第一步：不需要新数据，只需要把 Bot 消息链接到对应的 worker Session。如果你还没开始做，我可以来做；如果你打算提交，我来评审。告诉我你的倾向，避免重复开发。

@liugddx

Thanks, @liugddx! Please go ahead. I have only built the UI prototype and haven’t started implementation on rust-preview, so there is no overlapping work. I can help test it and provide feedback once it is ready.

Following up on the second point in my earlier comment, I have extended the local observation of the experiment in my fork.

The initial results are in #6360. The experimental sample now includes 13 completed cycles, compared with the same five-cycle baseline, using the same model connection.

Comparison	Previous persistent-session mode	Experimental per-cycle mode
Exploration and judgement Sessions	Reused across cycles	Fresh pair after each successful cycle
Shared notebook, feedback and delivery history	Retained	Retained and read on demand
Completed cycles observed	5	13
Median input tokens per model request	623,259	52,383.5
Average model-call attempts per cycle	7.2	116.8
Average cycle duration	1.84 min	18.29 min
Run outcomes	5 `no_report`	13 `reported`
Estimated model-token cost per cycle, using observed time-of-day rates	¥1.37	¥0.72
Estimated cost per cycle, with both samples priced at the same peak rates	¥1.62	¥1.05

Costs use DeepSeek’s official rates, accounting for cached input, uncached input and output. They are estimates, not the actual provider invoice. Four failed requests in the experimental sample had no usage data and are excluded. Subsequent Bot and worker execution is outside these figures.

I think this approach should help mitigate the attention drift previously observed with very long discovery contexts. Starting each cycle with a fresh working context, while retaining shared knowledge and relevant history, seems a useful direction to explore.

I also view the increased number of model calls and longer exploration time positively. For background discovery, I want it to have enough room to investigate different directions, inspect sources and verify potentially useful findings. Finishing a cycle quickly is not my main priority.

During actual use, I also encountered one issue worth sharing for reference:

Previous decision reasons can be lost while preparing tool results for the model. In one run, model-generated Code Mode code read the topic history but extracted only payload.text. The reasons for earlier withheld decisions were stored in payload.reason, so eight previous decisions reached the model with empty text even though the underlying records were intact. This may make it harder to use earlier investigation decisions reliably across fresh Sessions, and seems worth considering in the memory-retrieval design.

This remains an observational comparison with changing local data. The run outcomes do not establish that all reports were useful or that fewer useful discoveries were missed. The evaluation in #6360 is still needed to assess those results alongside duration and cost.

AI assistance: OpenAI Codex assisted with source inspection, log analysis, and drafting. I reviewed the findings and final text before posting.

简体中文

补充一下我此前评论中的第二点：目前已经延长了自己 fork 中这项实验的本机观察时间。

最初的结果已经发布在 #6360。现在实验版本累计完成 13 个周期，与之前相同的五轮基线进行对比，使用相同的模型连接。

对比项	旧版：持续复用 Session	实验版：每轮新建 Session
探索和判断 Session	跨周期持续复用	每轮成功后，下一轮分别新建
共享记事本、反馈和送达历史	保留	保留，按需读取
已观察的完整周期数	5	13
每次模型请求的输入 token 中位数	623,259	52,383.5
每轮平均模型调用尝试次数	7.2	116.8
每轮平均耗时	1.84 分钟	18.29 分钟
运行结果	5 次 `no_report`	13 次 `reported`
按实际调用时段估算的每轮模型 token 费用	¥1.37	¥0.72
双方统一按高峰价估算的每轮费用	¥1.62	¥1.05

费用采用 DeepSeek 官方价格，分别计算缓存输入、未缓存输入和输出。这是估算值，并非实际供应商账单。实验样本中有四次失败请求缺少用量数据，未计入费用；Bot 和执行任务的后续消耗也不包含在这些数字中。

我认为，这种方式应该能够在一定程度上缓解此前在超长主动发现上下文中观察到的注意力发散问题。每轮使用新的工作上下文，同时保留共享知识和相关历史，是一个值得继续探索的方向。

同时，主动发现调用模型的次数增加、探索时间更长，我反倒倾向于把它看作积极变化。 对于后台主动发现，我希望它有更充分的空间探索不同方向、查看原始资料，并核实可能有用的发现。尽快结束一轮，并不是我最在意的目标。

当然，实际使用过程中也遇到了一个问题，列在下面供参考：

历史判断的理由，可能在整理工具结果时丢失。 某轮中，模型生成的 Code Mode 代码读取了主题历史，但只提取 payload.text。此前 withheld 判断的理由实际存放在 payload.reason 中，导致八条历史判断返回给模型时文本为空，而底层记录本身完好。这可能影响新 Session 对既有调查判断的有效利用，值得在记忆检索的设计中一并考虑。

这仍然是本机数据持续变化情况下的观察性对比。运行结果不能证明所有报告都有用，也不能证明漏掉的有用发现减少了。仍需要 #6360 的评估，将这些结果与耗时、成本一起衡量。

AI 辅助说明：OpenAI Codex 协助进行了源码检查、日志分析和正文起草。相关发现及最终正文均由我审核后发布。

@sunrioa

A correction to what I said above about the side panel needing no new data. I checked the history rows the UI reads: a tool call or result there carries only references and positions, not its content, so the worker Session id that SessionCreate/SessionSend return is not in the row. Linking a Bot message to a specific worker would need one extra source read per such call (the same read the tool card uses), or the id recorded next to the message.

What does need no new data is a list of the Bot's workers: every worker already records the Bot as its parentSessionId, and the sidebar already uses that. So I plan to do it in two steps:

A panel beside the Bot conversation that lists its workers with their state and opens the selected worker's execution record on the right.
Linking a completion status under a message to its worker, once we agree whether to read the id from the tool result or record it.

@sunrioa, is step 1 close enough to your prototype to be worth building first?

简体中文

更正我上面说的“侧栏不需要新数据”。我核对了界面读取的历史行：工具调用和结果在行里只有引用和位置，不带内容，所以 SessionCreate/SessionSend 返回的 worker 会话号不在行里。要把某条 Bot 消息链接到具体 worker，需要对每个这类调用多做一次 source 读取（工具卡片用的同一种读取），或者在消息旁记录这个 id。

不需要新数据的是“Bot 的 worker 列表”：每个 worker 都把 Bot 记为 parentSessionId，侧边栏已经在用。所以我打算分两步：

在 Bot 对话旁边做一个面板，列出它的 worker 和状态，选中后在右侧打开该 worker 的执行记录。
把消息下方的完成状态链接到对应 worker，这一步等我们商定是从工具结果读取 id，还是另外记录。

@sunrioa 第 1 步和你的原型接近吗？值得先做吗？

@liugddx

Thanks for checking and clarifying, @liugddx. I think step 1 would already be useful and is close enough to what I had in mind. Keeping the Bot conversation visible while viewing a selected worker’s execution record sounds like a good starting point.

If there’s a version ready for testing, I’d be happy to try it and share feedback.

@sunrioa

A correction to my earlier comment here: I said the worker Session id would not be available to the UI without an extra read of the tool result. That was wrong. When the Bot is woken because a worker finished, the opening message of that Turn already carries the worker as its origin (bot_worker), and the app already has side panes ("Open to the side").

So a Bot reply to such a Turn can link to the worker's record with no new data. A first version is on the branch feat/bot-worker-panel: under the reply there is a link, "View the record of ", which opens the worker's conversation beside the Bot's. A reply to the user's own messages shows no link. I have not opened a PR yet; it is not verified in the window.

@sunrioa, once there is a build to try I will say so here.

简体中文

更正我之前在这里说的话：我说过界面不额外读取工具结果就拿不到 worker 的会话号，这是错的。Bot 因为某个 worker 完成而被唤醒时，那一轮的开头消息本身就带着这个 worker 作为来源（bot_worker），而且应用已经有“在右侧打开”的并排窗格。

所以对这种轮次的回复，不需要新数据就能链接到 worker 的执行记录。第一版在分支 feat/bot-worker-panel 上：回复下方有一个链接“查看「xxx」的执行记录”，点击后在 Bot 对话旁边打开该 worker 的会话；回复用户自己消息的轮次不显示链接。我还没有开 PR，界面效果还没有在窗口里验证过。

@sunrioa 有可试用的版本时我会在这里告诉你。

Written by Claude Code on behalf of @liugddx.

feat(workbench): reach a Bot's workers from its Chat (#6637)

@sunrioa

@sunrioa The first step is now in rust-preview (#6637): under a Bot reply that reports a finished worker there is a link to that worker's conversation, and the end of the Bot's Chat lists each conversation the Bot created that is running or waiting for you, opening beside the Bot's Chat (or in the same pane when the window is too narrow). It is the "keep the Bot conversation visible while viewing a worker's record" part; quoting and attachments from your prototype are not in it.

If you try a current build, any feedback is welcome, in particular on whether the worker's record is what you expected to see beside the conversation.

简体中文

@sunrioa 第一步已经合入 rust-preview（#6637）：Bot 汇报某个已完成 worker 的回复下方有指向该 worker 会话的链接；Bot 对话末尾会列出它创建的、正在处理或在等你回复的会话，点击后在 Bot 对话旁边打开（窗口太窄时在当前面板打开）。这是“查看 worker 执行记录时仍保留 Bot 对话”的部分，你原型里的引用和附件还没有包含。

如果你试用了当前版本，欢迎反馈，尤其是旁边显示的 worker 记录是不是你期望看到的内容。

Written by Claude Code on behalf of @liugddx.

Navigation Menu

Repository navigation

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

Summary

Architecture

What each module does

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

Indexes and the notebook serve different purposes

Who wakes what?

Future directions

Scope and open questions

概要

四个核心模块

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

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

调度：谁唤醒谁？

后续方向

范围与讨论点

Implementation references / 实现参考

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Summary

Architecture

What each module does

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

Indexes and the notebook serve different purposes

Who wakes what?

Future directions

Scope and open questions

概要

四个核心模块

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

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

调度：谁唤醒谁？

后续方向

范围与讨论点

Implementation references / 实现参考

Activity

liugddx commented on Oct 31, 2026

sunrioa commented on Nov 1, 2026

sunrioa commented on Nov 3, 2026

liugddx commented on Nov 3, 2026

sunrioa commented on Nov 3, 2026

sunrioa commented on Nov 3, 2026

liugddx commented on Nov 4, 2026

sunrioa commented on Nov 4, 2026

liugddx commented on Nov 4, 2026

liugddx commented on Nov 6, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions