[DISCUSS] From task execution to an Always-on Agent harness

[Astro-Han]

Grok Bot, Meta Muse, ChatGPT Dots and Today.ai point toward a direction I think matters for Maka: an Agent that keeps responsibility for work between conversations. Grok Bot's architecture walkthrough and Raft are the main references I'd like to use here.

Maka's current “Bot” connects messaging channels to existing conversations. An Always-on Bot is a different harness: it maintains a continuing conversation and work process, can wake without a new user request, and decides when to contact the user.

Boundary	Current task/channel experience	Always-on Bot
Conversation	Organized around individual tasks	One continuing conversation, without a new task for each request
Trigger	User input and existing task schedules	User input, scheduled wakes, and eventually external events
Output	Assistant output appears in the task conversation and is forwarded by the WorkHub channel bridge	Internal execution stays separate; only explicit send user reaches the Bot conversation

My preference is to evolve WorkHub into this Bot, reusing its Session and task-management capabilities. I'd like @ARE404, @xxhZs and @M4n5ter's views on whether this is the right foundation and what can be removed.

Use the same names in product copy and code: Bot means the Always-on Agent; Channels means messaging ingress and delivery; Remote connection means client access to a Runtime Host. Rename the current messaging “Bot” surface to Channels. Session remains the internal conversation and work-state container.

First phase

• One Bot, existing Host. Runtime Host retains execution, Session, queuing and recovery authority. Messages and scheduled wakes continue the same Session; a Turn or Run ending does not end the Bot's conversation. Multiple Agents remain possible later.
• User input and schedules. Reuse existing queuing and steering, and ScheduledTask for one-time and recurring schedules. Control work through conversation, including stopping current work and changing or cancelling schedules; do not add a stop button.
• Files and context. Reuse WorkHub's persistent workhub-coordination directory for MEMORY.md, drafts and artifacts. Project files stay in their original directories under existing permissions; changing projects does not require a new Bot Session. Between compactions, append to a stable model context rather than rebuilding history on each wake.

Tools and interaction

• Send results deliberately. One send user tool supports Markdown, inline images, playable audio/video, files and links, including mixed content.
• Ask without blocking unrelated work. Questions offer choices, free text or skipping. Confirmations and editable approval drafts show the concrete action, destination, content and attachments. Requests return immediately; only dependent work waits. Replies stay linked to the original request, and the Host enforces approval of the final version.
• Use cards where there is an action or changing state. Connection authorization, questions, confirmations and drafts update their original card. Clients render the cards; the Host owns interaction state.
• Reuse connections and browser tools. Show configured services' connection status and authorization action in cards, reuse existing authorization, and continue the original work after connection. Prefer OpenCLI MCP with the connected browser's login state; keep the embedded browser as an optional supplement. Human handoff uses a card to open the browser and continue afterward, while the Bot stops operating that interface.
• Reuse tool and skill discovery. Keep basic tools directly available; use existing tool_search, SkillSearch and Skill for the rest. Save a workflow as SKILL.md when the user asks. No automatic plugin installation, automatic skill extraction or new memory system.

Questions for discussion

1. WorkHub as the foundation: can it become the Bot directly, and which existing mechanisms should be removed?
2. Cache-aware compaction: with a known one-hour cache TTL, should the Bot compact once after 45–50 minutes idle, measured from the last cache-using request's start? New requests reset the deadline. The next wake resumes from the saved compacted context. TTL depends on the provider and configuration; compare total cost and information loss before adopting this policy.
3. Remote connection: I think this needs a redesign covering setup, authentication, transport, reconnection and UI, without assuming the existing stack must remain. How can connection be simple and recovery return to the same Host and Session?

Defer external event triggers such as Slack messages and GitHub notifications until there is a concrete need. A separate message box like Raft's inbox is more likely to matter for group channels; first-phase direct messages use existing queuing.

Host lifecycle is a separate topic, including Desktop exit and channel/MCP connection ownership. This phase does not change it or add process sleep, VM snapshots or cloud suspension. Rust/GPUI rewrites and performance belong in a separate Discussion, linked with this one.

---

中文版（点击展开）

Grok Bot、Meta Muse、ChatGPT Dots 和 Today.ai 指向一个我认为对 Maka 很重要的方向：Agent 在两次对话之间仍然承担工作。Grok Bot 的架构分享和 Raft 是这次讨论的主要参考。

Maka 当前的“Bot”是把消息渠道接到已有对话。Always-on Bot 则是另一种 harness：维持一段持续的对话和工作过程，不需要用户每次重新发起请求才能继续，也由模型决定什么时候联系用户。

边界	当前任务／渠道体验	Always-on Bot
对话	围绕各项任务组织	一段持续对话，不因每次请求新建任务
触发	用户输入和已有任务调度	用户输入、定时唤醒，后续加入外部事件
输出	assistant 输出显示在任务对话中，并由 WorkHub 渠道桥接转发	内部执行另存，只有显式 send user 才进入 Bot 对话

我倾向于直接把 WorkHub 演进成 Bot，复用 Session 和任务管理能力。想请 @ARE404、@xxhZs 和 @M4n5ter 一起讨论：这个基础是否合适，哪些东西可以删掉。

产品文案和代码统一命名：Bot 指 Always-on Agent；Channels（消息渠道） 指消息接入和投递；Remote connection 指客户端连接 Runtime Host。当前表示消息接入的“Bot”改称消息渠道。Session 保留为内部对话和工作状态承载。

第一阶段

• 一个 Bot，复用 Host。 执行、Session、排队和恢复仍由 Runtime Host 管理。消息和定时唤醒继续同一个 Session；Turn 或 Run 结束不结束 Bot 的对话。后续不排除 multiple agents。
• 用户输入和定时任务。 复用已有排队、插话和 ScheduledTask，支持一次性与周期安排。用户直接通过对话要求停止当前工作，或修改、取消定时安排，不新增停止按钮。
• 文件和上下文。 复用 WorkHub 的持久目录 workhub-coordination，保存 MEMORY.md、草稿和产物。项目文件留在原目录，沿用已有权限；换项目不因此新建 Bot Session。两次压缩之间维持稳定的模型上下文，只追加，不在每次唤醒时重组历史。

工具与交互

• 主动发送结果。 一个 send user 工具支持 Markdown、直接展示的图片、可播放的音视频、文件和链接，也支持混合内容。
• 非阻塞提问。 支持选项、自由输入或跳过。操作确认和可编辑审批草稿展示具体动作、发送位置、正文和附件。请求立即返回，只暂停依赖回答的工作。回复关联原请求，最终版本的审批由 Host 执行。
• 需要操作或状态变化时用卡片。 连接授权、提问、确认和草稿在原卡片上更新。客户端负责展示，Host 管理交互状态。
• 复用连接与浏览器工具。 卡片展示已配置服务的连接状态和授权操作，沿用现有授权流程，连接成功后继续原工作。浏览器优先使用 OpenCLI MCP，沿用所连接浏览器的登录状态；内嵌浏览器作为按需补充。需要用户接手时，卡片提供打开浏览器和完成后继续的操作，Bot 同时停止操作该界面。
• 复用工具和技能发现。 基础工具直接可用，其余通过已有 tool_search、SkillSearch 和 Skill 使用。用户要求保存流程时写成 SKILL.md。第一阶段不自动安装插件、不自动提炼技能、不另建记忆系统。

想讨论的问题

1. WorkHub 是否适合作为基础？ 能否直接演进成 Bot，哪些已有机制应该删除？
2. 缓存失效前压缩是否值得做？ 已知缓存 TTL 为一小时时，是否从最后一次使用缓存的请求开始计时，空闲 45–50 分钟后压缩一次？新请求重置计时，下次从保存的压缩上下文继续。TTL 取决于供应商和配置，采用前需要比较总成本和信息损失。
3. Remote connection 怎么重做？ 我认为应该覆盖首次接入、认证、传输、重连和 UI，不预设保留现有网络栈。怎样让连接简单，恢复后回到同一个 Host 和 Session？

Slack 消息、GitHub 通知等外部事件触发，有具体需求后再做。类似 Raft inbox 的独立 message box 更可能在群频道里需要；第一阶段的直接消息复用已有排队。

Host 生命周期单独讨论，包括退出 Desktop 后的行为，以及渠道／MCP 连接的归属。第一阶段不改生命周期，不做进程休眠、VM 快照或云资源挂起。Rust／GPUI 重写和性能另开 Discussion，与本篇相互链接。

[Astro-Han]

Related implementation: PR #6004 by @xxhZs.

It already implements proactive checks in a continuing Session and delegates work through Host-created background Sessions. I'd like to use it as a concrete implementation reference for this discussion.

Three points to compare:

1. Can the personal-assistant entry in feat(assistant): integrate native assistance, indexed memory, and durable tasks #6004 and WorkHub converge on one Bot entry and continuing Session?
2. feat(assistant): integrate native assistance, indexed memory, and durable tasks #6004 notifies through ordinary assistant replies; this proposal uses explicit send user. How should that communication boundary be unified?
3. How should Matter delegation and scheduling relate to existing WorkHub and ScheduledTask? What can be reused or removed?

One user-facing Bot can still use internal worker Sessions. I'd like to compare these boundaries before deciding which implementation to carry forward.

中文版（点击展开）

相关实现：@xxhZs 的 PR #6004。

它已在持续的 Session 中实现主动检查，并通过 Host 创建后台 Session 执行委派任务。我想把它作为本次讨论的具体实现参考，重点对比三处：

1. feat(assistant): integrate native assistance, indexed memory, and durable tasks #6004 的个人助手入口和 WorkHub 能否收敛成一个 Bot 入口和持续 Session？
2. feat(assistant): integrate native assistance, indexed memory, and durable tasks #6004 通过普通 assistant 回复通知用户，这里的提案使用显式 send user，这个通信边界怎样统一？
3. Matter 的委派和调度与已有 WorkHub、ScheduledTask 怎样衔接，哪些可以复用或删除？

一个面向用户的 Bot 仍可使用内部 worker Session。我想先把这些边界讨论清楚，再决定沿用哪些实现。

[Astro-Han]

Why

Maka already connects IM messages to WorkHub, runs work and sends text replies back. The existing bridge also saves pending inputs and delivery records. I’d keep that foundation.

The gaps show up when I try to use it for everyday work:

• Attachments do not reach the Agent properly. Incoming media without text currently gets an unsupported-message response, and the shared outgoing interface only accepts text. Sending a screenshot or receiving a file should be part of the normal conversation. Current message handling, sending interface.
• Decisions still pull me back to Desktop. Some questions work through letter-based text replies, but permission requests and unsupported forms fall back to Desktop. Common choices and approvals should be answerable from the IM. Current interaction handling.
• Visible messages are still derived from execution output. The bridge collects assistant text and forwards it after the Turn finishes. An Always-on Bot needs to decide when to contact me, including during ongoing work. Current forwarding.
• Some message semantics are incorrect. Slack currently uses the thread root as the source message ID, so different replies in one thread can be mistaken for duplicates. Current Slack mapping.

These gaps make the phone an incomplete entry point. I want to delegate work, answer questions and receive results there without repeatedly returning to Desktop.

What

For the first phase, I’d focus on private chats with the same persistent WorkHub Bot:

• Prefer QR login or existing platform authorization. Connection cards show the connected identity, reconnect automatically after temporary network failures, and offer re-login when needed.
• Send and receive text, images, audio, video and files, preserving captions.
• Use native buttons/cards for common choices and approvals, with text and free-text answers as fallbacks. Complex forms can retain their Desktop entry.
• Let send user control visible messages. Replies return to their source chat; schedules keep their creation-time destination; other proactive messages use one default IM destination. A user instruction can override it.
• Keep activity quiet: native typing indicators during direct requests, deliberate progress messages, and no automatic tool logs or token-by-token previews.

New requests and follow-ups go directly to WorkHub. The IM entry does not need new/reset/switch-Session commands.

How

Reuse the existing adapters, login flows, WorkHub bridge, attachment storage and Host interactions. Extend the current message interfaces for media and cards. Runtime Host retains execution and interaction authority.

Remove the separate task-mode path and automatic assistant-output forwarding. Separate message ID, thread ID and reply-to ID. Keep existing WorkHub recovery, preserve pending send user messages and receipts, retry definite delivery failures, and use platform send deduplication where available.

OpenClaw and Hermes are useful implementation references. Group chats, channel monitoring, MessageBox, external event triggers, voice transcription and video processing can wait. No new channel plugin framework, multi-platform failover or Host lifecycle changes in this phase.

@ARE404 @xxhZs @M4n5ter — which gaps can be closed by extending the existing adapters, and which parts genuinely need replacement?

---

中文版（点击展开）

Why：为什么做

Maka 已经能把 IM 消息交给 WorkHub，执行工作，再把文字结果发回来。现有桥接也已经保存待处理输入和投递记录。这些基础值得保留。

真正拿它处理日常工作时，还存在几个具体缺口：

• 附件没有完整进入 Agent。 目前收到没有文字的媒体消息，会回复暂不支持；统一发送接口也只接受文字。发一张截图让它分析、收到一个处理好的文件，都应该是正常对话的一部分。现有接收逻辑、发送接口。
• 需要作决定时，仍会被拉回 Desktop。 部分问题可以回复字母选项，但权限请求和不支持的表单仍要到 Desktop 处理。常见选择和审批应该能直接在 IM 里完成。现有交互处理。
• 用户消息仍从执行输出中转发。 当前桥接收集 assistant 文字，等 Turn 结束后发送。Always-on Bot 需要自己决定什么时候联系我，也包括工作还没结束的时候。现有转发逻辑。
• 部分消息语义有问题。 Slack 当前把线程根消息当成来源消息 ID，同一线程里的不同回复可能被误判为重复消息。现有 Slack 映射。

这些缺口让手机端还不能完整承担工作入口。我希望在那里交代事情、回答问题、接收结果，不用反复回到 Desktop。

What：第一阶段做什么

先做好我与同一个持久 WorkHub Bot 的私聊：

• 优先扫码或已有平台授权。连接卡片展示连接对象；临时断网自动重连，需要重新登录时提供入口。
• 收发文字、图片、音频、视频和文件，保留附带文字。
• 常见选项和审批使用原生按钮／卡片，文字回复和自由输入兜底。复杂表单可以保留 Desktop 入口。
• 由 send user 决定用户看到的消息。普通回复原路返回，定时任务保留创建时的投递位置，其他主动消息使用一个默认 IM 入口；用户可以直接指定其他位置。
• 保持安静：直接请求使用原生“正在输入”提示，进度说明按需发送，不自动转发工具日志，不增加逐字答案预览。

新事情和追问直接交给 WorkHub。IM 入口不需要新建、重置或切换 Session 的命令。

How：怎么做

复用现有适配器、登录流程、WorkHub 桥接、附件存储和 Host 交互，扩展当前消息接口，让媒体和卡片能完整收发。执行和交互状态继续由 Runtime Host 管理。

删除独立的 task 模式路径和 assistant 输出自动转发。消息 ID、线程 ID、被回复消息 ID 分开。保留已有 WorkHub 恢复能力，保存待发送的 send user 内容和回执，明确发送失败时重试，平台支持发送去重就直接使用。

实现参考 OpenClaw 和 Hermes。群聊、频道监听、MessageBox、外部事件触发、语音转写和视频处理后移。这一阶段不新增渠道插件框架、多平台故障切换，也不改 Host 生命周期。

@ARE404 @xxhZs @M4n5ter，想听听你们的判断：哪些缺口可以直接扩展现有适配器解决，哪些部分确实需要替换？

[xxhZs]

[Colafornia]

English

Building on the #6004 comparison and @xxhZs's diagram, I think three questions still need to be settled. Here is where I lean:

1. Who manages Bot state across Runs? I suggest keeping WorkHub as the first user entry, with the Host responsible for durable inputs, pending questions, outgoing messages and recovery. Today, pending interactions end with the Run they belong to, while pending IM inputs and delivery receipts are kept in the Desktop bridge. The Inbox in the diagram seems like a good direction to follow: user messages, linked answers, scheduled wakes and task progress all enter the same Bot Session. For the implementation, I'd lean toward extending the existing Host queues and recovery first, adding only the state they cannot express, while Channels and Desktop handle delivery and presentation. Does this split of responsibilities match the intent of the diagram?

2. When unattended, when must the Bot ask the user? Approval cards decide how to ask; the Bot also needs to know when it must ask. My suggestion: a scheduled wake may continue working within the authorization already recorded, but waking does not extend that authorization; actions outside that scope, or changes that invalidate an earlier approval, should go back to the user. WorkHub currently runs with bypass together with a narrow tool profile, so expanding the Bot's tools should come with a matching permission design. Could we use this to decide the first-phase tool set and default autonomy scope?

3. Should ongoing work reuse existing mechanisms, or add a new lifecycle? My starting point: Goal manages goal state, ScheduledTask manages timing, and WorkHub delegation manages the link to worker Sessions. I suggest comparing Matter with this combination item by item to find the semantics it adds, such as coordinating a waiting condition with timed re-checks, acknowledging processed events at settle, and explicit settle with model review, and then judging whether those semantics fit as extensions of existing mechanisms or justify keeping Matter. The key is that every state change has a clear owner, so completion, waking, pausing and cancellation stay consistent. Which essential Matter semantics do you think existing mechanisms do not yet provide?

中文

结合 #6004 的对比和 @xxhZs 的图，我认为还有三个问题需要先确认，我的倾向如下：

1. 跨 Run 的 Bot 状态由谁管理？ 我建议保留 WorkHub 作为第一个用户入口，由 Host 负责持久输入、待回答问题、待发送消息和恢复。目前，待处理交互会随所在 Run 结束，而 IM 的待处理输入和投递回执保存在 Desktop 桥接里。图里的 Inbox 是一个值得沿用的方向：用户消息、关联回答、定时唤醒和任务进展进入同一个 Bot Session。实现上，我倾向于先扩展现有的 Host 队列和恢复机制，只补充它们无法表达的状态；渠道和 Desktop 负责投递与展示。这个职责划分是否符合图里的意图？

2. 无人值守时，什么时候必须询问用户？ 审批卡片解决的是"怎样询问"，Bot 还需要明确"什么时候必须询问"。我的建议是：定时唤醒可以在已记录的授权范围内继续工作，但唤醒本身不扩大授权；超出范围的操作，或者让此前批准失效的变化，应重新交给用户决定。WorkHub 当前使用 bypass，配合较窄的工具 profile，所以扩展 Bot 的工具时需要同时设计权限。是否可以据此确定第一阶段的工具集和默认自主范围？

3. 持续工作是复用现有机制，还是增加一套新的生命周期？ 我的出发点是：Goal 管目标状态，ScheduledTask 管时间安排，WorkHub 委派管理与 worker Session 的关联。建议把 Matter 和这个组合逐项比较，找出它额外提供的语义，例如等待条件与定时复查的配合、settle（结算）时确认已处理的事件、显式 settle 和模型审核，再判断这些语义适合扩展现有机制，还是足以支持保留 Matter。关键是每个状态变化都有明确的管理方，让完成、唤醒、暂停和取消保持一致。你们认为 Matter 中有哪些必要语义是现有机制尚未提供的？

[Astro-Han]

Following up on the conversation in #6124, I’d like to bring the simplification question back here too.

After looking at that PR alongside WorkHub and Lee’s lecture, I keep coming back to one Bot per Host: I can talk to it from the desktop or IM, it keeps track of ongoing work, and it decides when to act directly, delegate, ask or stay quiet.

The Inbox and explicit SendUser boundary look like useful pieces of that. I’d also like to take the opportunity to simplify WorkHub itself. There are quite a few concepts, states and special flows across both implementations now, and I think there is room to remove more as they come together.

For example, I don’t need every task to go through an independent model review or a required draft/checkpoint/settlement process. A simple query should be easy to answer directly. Longer work can use execution Sessions, with the Host handling execution and recovery and ScheduledTask handling future wakes. Where existing capabilities cover the need, I’d prefer to reuse them and retire the overlapping paths.

The reliability pieces still matter: accepted messages shouldn’t disappear, retries shouldn’t duplicate actions, and permissions and delivery receipts need clear ownership. I’d like to keep those guarantees with fewer concepts and less coordination machinery.

No need to make all of this a prerequisite for #6124. I mainly wanted to share the direction I’d like to work toward. @ARE404 @xxhZs @M4n5ter, curious how you see it, and which parts you think could disappear as this comes together.

中文版

接着 #6124 里的交流，也把简化这个想法带回这里聊聊。

结合那个 PR、WorkHub 和 Lee 的公开课看下来，我还是希望每个 Host 最后就是一个 Bot：桌面和 IM 都能找它，它记得正在做的事，自行判断什么时候直接处理、委派、询问，或者保持安静。

Inbox 和显式 SendUser 都是有用的部分。同时，我也希望借这个机会把 WorkHub 本身一起简化。两边现在的概念、状态和专用流程都有点多，合到一起时，应该还有不少东西可以去掉。

比如，我不需要每个任务都经过独立模型审核，也不需要强制走草稿、checkpoint、结算这一整套流程。简单问题就直接回答，耗时工作交给执行 Session；执行和恢复由 Host 管，未来唤醒由 ScheduledTask 管。已有能力能解决的，就尽量复用，把重叠的路径退掉。

可靠性这部分还是要保住：收到的消息不能丢，重试不能重复执行，权限和投递回执要有明确归属。我希望用更少的概念和协调机制做到这些。

不用把这些都变成 #6124 的前置条件，我主要想先说说自己希望往哪个方向走。@ARE404 @xxhZs @M4n5ter，也想听听你们怎么看，两边收敛时哪些东西可以一起删掉。

[liugddx]

Following the switch discussion in #6366, here is a proposal for how the Always-on Bot could land on rust-preview, plus a capability inventory of what main has today. It is meant as input for the "written list" switch condition, not as a decision. Corrections are welcome.

What I checked

I read rust-preview at 3f60d59d5 and main at ed3f91707. On rust-preview there is no Inbox, SendUser or channel sender yet. The scheduler, the durable message queue (admit_notification), WorkHub and Goal already exist, so I'd reuse them instead of porting main's separate bot.sqlite and its own scheduling.

Proposal: port the semantics, not the code

main	rust-preview
bot.sqlite Inbox	Reuse the message queue and admit_notification; add one MessageOrigin variant for external input
Sleep + finish guard	Not ported. A Run is bounded; when it ends the Bot is idle, and a new admitted message starts the next Run
SendUser	Keep as the only way the Bot speaks to the user; messageId idempotent; sending nothing is a valid outcome
Outbox	Delivery state kept separate from Run state; an unknown result is never resent automatically
setInterval heartbeat	Scheduler Interval task that wakes the Bot Session through the existing user-approved background execution
Bot tool allow-list	The Session's immutable tools allow-list

Placement: a module inside the main Agent native crate behind a config switch (default off), because a separate plugin cannot reach Owner or admit_notification.

Authorization: a scheduled wake works inside what was already approved and does not widen it; anything outside that goes back to the user.

Questions

1. Matter. Goal, ScheduledTask and WorkHub delegation already cover most of what main's Matter does. Could we compare them item by item and keep only the semantics they lack (waiting conditions with timed re-checks, acknowledging events at settle, revision-checked settle)? Who should own that review?
2. Crash recovery. I could not confirm what happens to a long-lived Session when a Run crashes after a tool call was dispatched but before its result was recorded (history::project returns ReconciliationRequired, and the queue path does not allow prior unknown outcomes). Does anyone know the intended behavior? I would start with a small spike to find out.
3. First channel. Only the platform enum exists on rust-preview. Which single channel should come first?
4. Capability inventory. I drafted 37 items (19 to rebuild, 11 to fold into existing mechanisms, 3 already equivalent, 4 suggested to drop). Where should it live so it can be reviewed and corrected, a doc in the repository or a Discussion thread?

I'd like to help with the inventory and a first prototype if the direction is agreed. I have not started any implementation.

中文版

接着 #6366 的切换讨论，这里给出常驻 Bot 在 rust-preview 上落地的一个方案，以及 main 现有能力的清单草案。它是为"成文清单"这个切换条件提供输入，不是决定，欢迎指正。

我核对了什么

读取的是 rust-preview 的 3f60d59d5 和 main 的 ed3f91707。rust-preview 上还没有 Inbox、SendUser 和渠道发送端；但调度器、持久消息队列（admit_notification）、WorkHub 和 Goal 已经有了，所以我建议复用它们，而不是照搬 main 里独立的 bot.sqlite 和自带调度。

提议：移植语义，不移植代码

main	rust-preview
bot.sqlite Inbox	复用消息队列和 admit_notification；为外部输入新增一个 MessageOrigin 变体
Sleep + finish guard	不移植。Run 是有界的，结束即空闲，新消息被接收后启动下一个 Run
SendUser	保留，作为 Bot 对用户说话的唯一出口；messageId 幂等；"什么都不发"是合法结果
Outbox	投递状态与 Run 状态分开；结果未知时不自动重发
setInterval 心跳	用调度器的 Interval 任务，通过已有的、用户批准的后台执行唤醒 Bot Session
Bot 工具白名单	Session 创建时的不可变 tools 白名单

位置：放在主 Agent native crate 里，用配置开关控制（默认关闭），因为独立插件访问不到 Owner 和 admit_notification。

授权：定时唤醒只在已批准的范围内工作，不扩大授权；超出范围的回到用户手里。

想讨论的问题

1. Matter。 Goal、ScheduledTask 和 WorkHub 委派已经覆盖了 main 里 Matter 的大部分功能。能否逐项对照，只保留它们缺少的语义（等待条件配合定时复查、结算时确认事件、带版本检查的结算）？这件事谁来牵头？
2. 崩溃恢复。 我没能确认：Run 在工具调用已派发、结果尚未记录时崩溃，长期存在的 Session 会怎样（history::project 会返回 ReconciliationRequired，而队列路径不允许承认此前的未知结果）。有人知道预期行为吗？我打算先做一个小 spike 验证。
3. 第一个渠道。 rust-preview 上只有平台枚举。应该先做哪一个渠道？
4. 能力清单。 我起草了 37 项（19 项需重做、11 项合并进现有机制、3 项已有等价、4 项建议放弃）。放在哪里便于评审和修正，仓库里的文档，还是 Discussion 的一个帖子？

如果方向达成一致，我愿意参与清单和第一个原型。目前没有开始任何实现。

[liugddx]

Follow-up on the crash-recovery question from my earlier comment. I ran a test instead of guessing, and I'd like your view on which way to go.

What I tested. A native-layer test on rust-preview (3f60d59d5), reusing the todo.rs fixture and its reopen. A Run calls a tool; the tool dispatch is persisted but its settlement is not (a SQLite trigger rejects the tool_settled insert); the application is restarted from the same store; then another message is sent to the same Session. A control does the same with a Run that finishes normally.

Case	Next message
Control: first Run finished normally, restart	Accepted and reaches the model
Dispatch persisted, settlement missing, restart	Rejected with agent_execution_unavailable; never reaches the model; one message left pending
Same, then restart again and send a third message	The pending message is dropped (not retried); the third message is rejected the same way

So once a Session has one unsettled tool dispatch, every later message to it is rejected, and I found no way back. For a long-lived Bot Session that means every user message, wake and Inbox delivery would fail after a single crash.

Where it comes from (from reading the code). The queue path builds RunWork::Message with allow_prior_unknown: false (plugins/agent/native/src/owner/queue.rs:442), and ReconciliationRequired ends in fail_pending (queue.rs:265). The engine already has the other behavior: with allow_prior_unknown: true it tells the model the earlier effect may have happened and does not replay the tool (startup_recovery.rs, explicit_new_message_after_unknown_dispatch_informs_model_without_replaying_tool). I only found it used from engine/src/runner.rs:57, not from the native queue.

Limits of this evidence.

• I injected the failure with a trigger instead of killing the process. Both leave a ToolDispatched without a ToolSettled, and the engine's own crash test shows the same block, but I did not run a real process kill at the native layer.
• public_error folds several errors into agent_execution_unavailable. I did not print the inner error, so "it is ReconciliationRequired" is an inference from the code path.
• Only todo_write was tested.

Question. For a Session that is meant to live for a long time, which direction do you prefer?

1. Let the native queue admit a new message after an unknown outcome (the model is told, the tool is not replayed), at least for Bot Sessions.
2. Reconcile the unknown dispatch first, then let messages through.
3. Keep the engine as it is and design Bot tools so they cannot leave an unknown outcome (for example, record the outbound message before dispatching).

Is the current behavior intended for ordinary Sessions? I would like to keep any change scoped so it does not weaken it there.

简体中文

接着我上一条评论里关于崩溃恢复的问题。我没有猜，而是跑了一个测试，想听听你们倾向哪条路线。

测试方法。 在 rust-preview（3f60d59d5）上写了一个 native 层测试，复用 todo.rs 的夹具和 reopen。一次 Run 调用了工具，工具的派发已持久化，但结算没有落盘（用 SQLite 触发器拒绝 tool_settled 的插入）；然后用同一个存储重启应用，再向同一个 Session 发一条消息。对照组是 Run 正常结束。

情形	下一条消息
对照：第一次 Run 正常结束，重启	被接受，到达模型
派发已持久化、结算缺失，重启	被拒绝，返回 agent_execution_unavailable；没有到达模型；留下一条待处理消息
同上，再重启一次并发第三条消息	待处理消息被丢弃（不是重试）；第三条以同样方式被拒绝

也就是说，Session 一旦出现一次未结算的工具派发，之后发给它的每条消息都会被拒绝，我没找到恢复的办法。对长期存在的 Bot Session 来说，一次崩溃之后，所有用户消息、唤醒和 Inbox 投递都会失败。

原因（读代码得出）。 队列路径构造 RunWork::Message 时固定 allow_prior_unknown: false（plugins/agent/native/src/owner/queue.rs:442），ReconciliationRequired 最终进入 fail_pending（queue.rs:265）。引擎本身已有另一种行为：设为 true 时，会告诉模型此前的副作用可能已经发生，并且不重放工具（startup_recovery.rs 里的 explicit_new_message_after_unknown_dispatch_informs_model_without_replaying_tool）。我只在 engine/src/runner.rs:57 找到使用它的地方，native 队列没有用。

这份证据的局限。

• 我是用触发器注入故障，而不是杀进程。两者都会留下有 ToolDispatched、没有 ToolSettled 的日志，引擎自己的崩溃测试也表明同样会被挡住，但我没有在 native 层跑真实的进程崩溃。
• public_error 把多种错误折叠成 agent_execution_unavailable，我没有打印内层错误，所以“是 ReconciliationRequired”是依据代码路径的推断。
• 只测试了 todo_write。

问题。 对于要长期存在的 Session，你们倾向哪个方向？

1. 让 native 队列在出现未知结果后仍接收新消息（告知模型、不重放工具），至少对 Bot Session 这样做。
2. 先对账未知的派发，再放行消息。
3. 引擎保持不变，把 Bot 工具设计成不会留下未知结果（例如派发前先记录要发出的消息）。

普通 Session 目前的行为是有意为之吗？我希望任何改动都限定范围，不削弱普通 Session 的保护。

[M4n5ter]

English

I've been working mostly on rust-preview lately, so I'm a bit behind on the Bot work on main and may be missing some requirements.

When I mentioned opening up plugin APIs, I didn't mean that Bot should necessarily be a separate plugin. I was wondering whether it could simply be an Agent mode: keep using the same persistent Session, wake it when messages or scheduled events arrive, and keep ordinary model output internal. The model would use SendUser when it actually wants to say something to the user.

I'm not sure whether that covers everything Bot needs today. Are there capabilities in the current implementation that wouldn't fit this model, or would become awkward to implement? It would help me catch up if we could look at a few concrete examples before settling on the boundary between Bot and Agent.

As for the recovery issue, thanks for reproducing it. I'll take care of that separately a little later, so it doesn't need to hold up this discussion.

简体中文

我最近主要在做 rust-preview，对 main 上 Bot 的进展有些落后了，可能还不了解一些具体需求。

前面说可以开放插件 API，并不是说 Bot 就应该做成独立插件。我其实在想，它能不能就是 Agent 的一种模式：持续使用同一个 Session，收到消息或定时事件时唤醒，普通模型输出留在内部，模型想联系用户时通过 SendUser 发消息。

但我不确定这能不能覆盖目前 Bot 需要的所有能力。现有实现里，有哪些能力放进这个模型会做不了，或者做起来比较别扭？可以举几个具体例子，帮我补一下上下文，再一起讨论 Bot 和 Agent 的边界怎么划更合适。

至于恢复问题，感谢你实际复现了它。我稍后会单独处理，不用让它卡住这边的讨论。

[liugddx]

@M4n5ter Thanks, and understood on both points. I misread "open the plugin APIs" as "make Bot a plugin"; an Agent mode is simpler and I think it fits most of what Bot needs. Here are concrete examples from main, split by how well they fit.

Fits an Agent mode directly

• Inbox and wake. User messages, scheduled wakes and task progress all enter the same persistent Session; a Run ends and the Bot is idle until the next admitted message. One thing to design: a Session can hold only one pending Turn at a time (SessionBusy), so several arrivals while a Run is active need to be coalesced into one admission.
• SendUser as the only voice. messageId idempotency, several messages per call, and "send nothing" as a valid outcome. Ordinary model text stays internal.
• Heartbeat. A scheduler Interval task that wakes the Bot Session through the existing user-approved background execution.
• Tool ceiling. main keeps the Bot from using shell, edit or browser tools. That is a per-mode tool allow-list.

Fits, but needs a decision

• Delivery state. On main the Outbox is separate from the Run: a message can be registered, delivered or unknown regardless of whether the Run finished. In an Agent mode I'd keep that state outside the Run record, so a crash between "model called SendUser" and "message shown" neither loses nor repeats it.
• A visible conversation that is only a transport. On main the assistant conversation does not start Turns itself, rejects turn.start, and is hidden from the ordinary Session list. An Agent mode needs a Session kind or flag that clients can read, not only a label users can edit.
• Discovery. main runs two background Sessions (explore and judge) that share an append-only notebook and report to the Bot. That is one Bot Session plus worker Sessions, which WorkHub delegation already resembles; I'd treat it as "Bot delegates to workers" rather than part of the mode.

Awkward as part of the mode

• IM channels. Eight platform bridges with pairing, allow-lists, QR login, credentials, typing indicators and attachments. The Bot only needs an inbound origin and an outbound target for SendUser; the channel work itself belongs in separate components.
• Memory index network. Its own database, a maintenance clock and source readers. The Bot would call it as tools, not contain it.
• Matter. Durable items with waiting conditions and revision-checked settle. It overlaps with Goal, ScheduledTask and WorkHub delegation, so I'd compare them item by item before deciding whether any of it needs a place in the mode.

If that matches your picture, I'd first write down the Bot–Agent boundary as a short list (what the mode adds, what stays outside) and put it in the inventory in #6413. Does that sound right?

The recovery issue is fine to handle separately. I only noted that the Bot design depends on it, because one crash would otherwise leave a long-lived Session unusable.

简体中文

@M4n5ter 谢谢，两点都明白了。我把“开放插件 API”误读成了“Bot 要做成插件”；做成 Agent 的一种模式更简单，我认为也能覆盖 Bot 的大部分需求。下面按契合程度，列出 main 上的具体例子。

可以直接放进 Agent 模式

• Inbox 与唤醒。 用户消息、定时唤醒和任务进展都进入同一个持久 Session；一次 Run 结束后 Bot 空闲，直到下一条被接收的消息。有一点需要设计：一个 Session 同一时刻只能有一个待处理 Turn（SessionBusy），所以 Run 运行期间到达的多条输入，需要合并成一次准入。
• SendUser 是唯一出口。 messageId 幂等、一次调用可发多条、“什么都不发”是合法结果。普通模型文本保持在内部。
• 心跳。 用调度器的 Interval 任务，通过已有的、用户批准的后台执行唤醒 Bot Session。
• 工具上限。 main 不允许 Bot 使用 shell、编辑或浏览器工具，这相当于每种模式一份工具白名单。

可以放进去，但需要做决定

• 投递状态。 main 的 Outbox 与 Run 是分开的：一条消息可以处于已登记、已投递或未知状态，与 Run 是否结束无关。放进 Agent 模式后，我倾向把这个状态放在 Run 记录之外，这样“模型调用了 SendUser”和“消息已展示”之间发生崩溃时，既不丢也不重复。
• 只做传输的可见会话。 main 里助理的会话自己不会启动 Turn、会拒绝 turn.start，并且不出现在普通 Session 列表里。Agent 模式需要一个客户端可读的 Session 种类或标记，而不是用户能改的标签。
• 发现（Discovery）。 main 运行两个后台 Session（探索和判断），共用一个只追加的笔记本，并向 Bot 汇报。这是“一个 Bot Session 加若干 worker Session”，与 WorkHub 的委派很接近；我倾向把它当作“Bot 委派给 worker”，而不是模式本身的一部分。

放进模式里会比较别扭

• IM 渠道。 八个平台桥，涉及配对、白名单、扫码登录、凭据、输入中提示和附件。Bot 只需要一个入站来源和一个供 SendUser 使用的出站目标；渠道本身的工作应放在单独的组件里。
• 记忆索引网络。 有自己的数据库、维护时钟和来源读取器。Bot 应把它当作工具来调用，而不是把它包含进来。
• Matter。 带等待条件和版本检查结算的持久事项。它与 Goal、ScheduledTask 和 WorkHub 委派重叠，我倾向先逐项对照，再决定其中是否有需要放进模式的部分。

如果这和你的想法一致，我会先把 Bot 与 Agent 的边界写成一份简短清单（模式新增什么、什么留在外面），放进 #6413 的清单里。这样可以吗？

恢复问题单独处理没有问题。我只是想说明 Bot 的设计依赖它，因为没有它，一次崩溃就会让长期存在的 Session 无法再用。

[liugddx]

@M4n5ter I went back through my examples against main (ed3f91707) line by line and found three things I got wrong, plus one decision I should have raised. Corrections first.

Corrections to my previous comment

1. "Pairing" does not exist. I listed it among the channel features. There is no pairing-code mechanism for IM channels. In assistant mode the allow-list must contain exactly one user, the chat must be private, and the first private message binds the chatId (apps/desktop/src/main/assistant-im-bridge.ts:126-127,243,302-307); WeChat and Feishu QR login adds the scanner to the allow-list automatically. The channel trust model is simpler than I described.
2. SessionBusy is narrower than I said. It is returned when a pending admission already exists or an interruption fence is in place (platform/event-log/src/message_admissions/insert.rs:126-127,75). A new TurnStarted during an active Run fails with a different error, and Steering / Followup into the same Run are accepted (insert.rs:96). So "several arrivals need to be coalesced into one admission" overstated it: first check whether Steering / Followup already cover the Bot's input.
3. The tool ceiling is not read-only. main keeps the Bot away from shell, edit and browser tools, but its 37-tool allow-list still includes write tools such as MemoryIndexCreate, Matter* and Initiative* (packages/runtime-host/src/assistant/bot/capabilities.ts:20-58).

Two wording fixes: "hidden from the Session list" only holds in the desktop UI rail (by tag); the backend can still list those Sessions. And discovery's two Sessions run serially within one heartbeat (explore, then judge), not in parallel.

A decision I should have raised: one Session or two?

You described the mode as "the same persistent Session, ordinary output stays internal". main does it differently. The conversation the user sees is a ledger copied out of the outbox, and it never starts the model. The model's own Run history lives in a separate, hidden worker Session (assistant/bot/conversation.ts, assistant/bot/controller.ts:140-163). With a single Session, the model's internal output and the SendUser messages share one history, so clients would have to tell them apart by source. Which do you prefer?

Boundary list

I wrote the Bot–Agent boundary down with main evidence for each row and will add it to #6413. Short version:

• In the mode: durable input, SendUser (idempotent messageId, up to 100 messages / 48,000 characters per call), delivery state kept apart from the Run, a tool allow-list, a scheduler-driven heartbeat, and an immutable Session-kind marker (labels are user-editable on rust-preview).
• Outside the mode: the eight IM bridges, the memory index network (own database, 30 s tick, 12 h interval), discovery (own notebook database), Matter, and the character / pet / sticker layer.
• To decide: one Session or two (above); how an input's origin changes trust (on main, external_connector messages are not the owner's instructions, bot/host.ts:44); whether IM delivery receipts and retries need a ledger-like concept in the mode; and the feedback loop (notNotified audit and DiscoveryFeedback).

Not checked: whether the rust-preview scheduler already guarantees a single owner for background work, which main handles with leases and fences.

简体中文

@M4n5ter 我把自己的例子逐条对照 main（ed3f91707）核对了一遍，发现有三处说错了，另外还有一个我应该早点提出的决定。先更正。

对我上一条评论的更正

1. “配对（pairing）”并不存在。 我把它列进了渠道功能。IM 渠道没有配对码机制。助手模式下，白名单必须恰好有一个用户，必须是私聊，首条私聊消息会绑定 chatId（apps/desktop/src/main/assistant-im-bridge.ts:126-127,243,302-307）；微信、飞书扫码登录后会自动把扫码人加入白名单。渠道的信任模型比我描述的更简单。
2. SessionBusy 的范围比我说的窄。 它在已有待处理 admission 或存在中断围栏时返回（platform/event-log/src/message_admissions/insert.rs:126-127,75）。Run 运行期间再来一条 TurnStarted 会报另一个错误，而同一 Run 的 Steering / Followup 是允许入队的（insert.rs:96）。所以“多条输入需要合并成一次准入”说得过头了：应先看 Steering / Followup 是否已经能覆盖 Bot 的输入。
3. 工具上限不是只读的。 main 不让 Bot 使用 shell、编辑和浏览器工具，但它的 37 项白名单里仍有写类工具，比如 MemoryIndexCreate、Matter*、Initiative*（packages/runtime-host/src/assistant/bot/capabilities.ts:20-58）。

另有两处措辞修正：“从 Session 列表隐藏”只在桌面 UI 侧栏成立（按标签），后端仍能列出这些 Session；发现（discovery）的两个 Session 在同一次心跳里串行执行（先探索，再判断），不是并行。

一个我应该早点提出的决定：一个 Session 还是两个？

你把这个模式描述为“同一个持久 Session，普通输出留在内部”。main 的做法不一样：用户看到的会话是从 outbox 复制出来的账本，它从不启动模型；模型自己的 Run 历史在另一个隐藏的 worker Session 里（assistant/bot/conversation.ts、assistant/bot/controller.ts:140-163）。如果只用一个 Session，模型的内部输出和 SendUser 消息会在同一份历史里，客户端需要按来源区分它们。你倾向哪一种？

边界清单

我把 Bot 与 Agent 的边界写下来了，每一行都附了 main 的证据，会补进 #6413。简要如下：

• 属于模式本身： 持久输入、SendUser（messageId 幂等，每次最多 100 条、48000 字符）、与 Run 分开的投递状态、工具白名单、由调度器驱动的心跳，以及不可变的 Session 种类标记（rust-preview 上 labels 用户可改）。
• 留在模式之外： 八个 IM 桥、记忆索引网络（独立数据库、30 秒 tick、12 小时间隔）、发现（独立 notebook 数据库）、Matter，以及角色、宠物、表情包这一层。
• 需要决定： 一个还是两个 Session（见上）；输入来源如何影响信任（main 里 external_connector 的消息不等于主人的指令，bot/host.ts:44）；IM 的投递回执和重试在模式里是否需要类似账本的概念；以及反馈闭环（notNotified 审计和 DiscoveryFeedback）。

未核对：rust-preview 的调度器是否已保证后台任务只有单一所有者，main 是用租约和围栏处理这一点的。

[M4n5ter]

English

Thanks for checking the details again. These examples help me catch up with the Bot work on main.

For the Session question, I currently lean toward one persistent Session, with different views for execution history and the conversation shown to the user. The normal conversation view would show user messages and explicit SendUser messages, while ordinary model output and tool activity stay in the execution view.

Delivery state should also survive individual Runs. It seems possible to keep those records associated with the same Session. What I’m still trying to understand is what the separate conversation Session gives us beyond that.

@xxhZs, since you’ve been developing this part on main, I’d like to hear your thoughts too. What led to separating the visible conversation from the Bot’s execution Session? Are there concrete requirements that would be difficult or awkward with one Session and separate views? I’m still catching up with that implementation and may be missing some context.

Putting the capability list in #6413 sounds useful. I’d suggest distinguishing the capabilities we need from the choices made by the current implementation. In particular, I wouldn’t carry over the fixed tool list or message-count/size limits by default; we can discuss any necessary restrictions against concrete needs.

I’d treat this as a direction to explore, with the Session arrangement and component boundaries still open for discussion.

简体中文

感谢再次核对，这些具体例子帮我补上了不少 main 上 Bot 的上下文。

关于 Session，我目前更倾向于一个持久 Session，执行历史和用户看到的对话采用不同的展示视图。普通对话视图显示用户消息和明确通过 SendUser 发出的消息，普通模型输出和工具活动则留在执行视图里。

投递状态也应该跨 Run 保留。我理解这些记录可以关联同一个 Session；我还想进一步了解的是，单独维护一个展示会话，在此之外具体解决了什么问题。

@xxhZs，你一直在负责 main 上这部分的开发，也想听听你的看法。当时把用户可见会话和 Bot 的执行 Session 分开，主要考虑是什么？如果采用一个 Session 加不同展示视图，有哪些实际需求会比较难做，或者实现起来不自然？我对现有实现的上下文还有些落后，可能遗漏了一些考虑。

把能力清单补进 #6413 很有帮助。我建议把需要支持的能力和当前实现的选择分开记录。尤其是固定工具名单、消息条数和大小上限，我倾向于先不默认沿用；确实需要哪些限制，可以结合具体需求再讨论。

这些先作为一个探索方向，Session 的组织方式和组件边界都还可以继续讨论。

[liugddx]

Following up on folding WorkHub into the Bot (my comment on #6504). I read the WorkHub code and the Borges write-up (zh-CN), and I have two questions where I'd rather ask before building. These are my readings, not decisions.

1. Should the dependency graph come along?

My earlier list of what to carry over from WorkHub included the dependency graph and frozen inputs (a downstream task receives the upstream task's final answer). The Borges write-up argues against pre-splitting work into a pipeline: a plan can organize order, but new information should change the current state first and the agent then decides what to do. The graph and swarm tools (agent_list, view_agent_graph, update_agent_graph, yield_agent_graph, agent_swarm_status) are a separate layer on top of workhub_tasks. As far as I can tell only a coordinator Session that picked Graph or Swarm mode sees them, never the Bot. So there are two options:

• A. Drop the graph from the Bot's path: the Bot delegates through Session tools, one worker at a time, and decides the next step itself when a result comes back. The graph stays where it is, for now.
• B. Carry dependencies and frozen inputs into the Bot's delegation.

I lean towards A for the first step, because it keeps the Bot's tool set small and matches the "no pre-split pipeline" direction. @M4n5ter @xxhZs, does that match your intent, or is there a use of dependencies you want to keep?

2. Which Owner hosts the Bot, and what does it get?

In a real desktop session I looked at the model request recorded in the event log: the Bot's direct tools were exec, wait, ScheduledTask, SendUser and sleep. workhub_tasks was not among them. It is registered DirectOnly and, as far as I can tell, only on the WorkHub Owner, while the UI opens the Bot through the agent import. So today's Bot cannot delegate through workhub_tasks at all; the standing instructions had promised it, which #6508 fixes by naming only tools the Bot holds.

That makes the Session tools (the 14 projected own-service tools) the natural path for delegation. Two different things are involved, and I'd treat them separately:

• Managing the user's conversations (find, rename, archive, delete, message): open under the confirmation tiers already discussed in feat(agent): add Bot mode with SendUser and a Host-owned outbox #6464.
• Controlling the workers the Bot itself started (send to, stop, resume, read progress): I'd like these checked in code against parentSessionId, as WorkHub does for task ownership, so a mistaken call cannot stop or message a conversation the Bot did not start. Is that acceptable, or do you prefer to rely on confirmation alone?

Waking the Bot when a worker finishes has no equivalent for plain Sessions today (WorkHub polls task state and admits a WorkhubTask message), so it would need a small watch record plus a new message origin. I'd do that as its own step.

简体中文

接着 #6504 里提到的“把 WorkHub 并入 Bot”。我读了 WorkHub 的代码和 Borges 这篇文章（中文版），有两个问题想先问清楚再动手。以下是我的理解，不是决定。

1. 依赖图要不要一起并入？

我之前列的“需要从 WorkHub 带过去的东西”里有依赖图和冻结输入（下游任务拿到上游任务的最终答案）。Borges 这篇文章反对把工作提前拆成流水线：计划可以用来组织顺序，但新信息应先改变当前状态，再由 Agent 决定下一步。图和蜂群工具（agent_list、view_agent_graph、update_agent_graph、yield_agent_graph、agent_swarm_status）是叠在 workhub_tasks 之上的另一层，据我所知只有选了 Graph 或 Swarm 模式的协调者会话能看到，Bot 看不到。所以有两个方案：

• A. Bot 这条路径不带图：Bot 通过 Session 工具逐个委派，结果回来后自己决定下一步。图暂时留在原处。
• B. 把依赖和冻结输入带进 Bot 的委派里。

我倾向第一步先做 A，因为这样 Bot 的工具集更小，也符合“不预先拆流水线”的方向。@M4n5ter @xxhZs，这符合你们的想法吗？还是有依赖关系的用法你们希望保留？

2. Bot 在哪个 Owner 里，它能拿到什么？

我查看了一个真实桌面会话的事件日志里记录的模型请求：Bot 的直接工具是 exec、wait、ScheduledTask、SendUser 和 sleep，没有 workhub_tasks。它注册为 DirectOnly，据我所知只注册在 WorkHub 的 Owner 上，而界面是通过 agent import 打开 Bot 的。所以目前的 Bot 根本无法通过 workhub_tasks 委派；常驻提示词却承诺了这一点，#6508 修的就是这个：只点名 Bot 真有的工具。

这样委派的自然路径就是 Session 工具（上游投影出的 14 个自身服务工具）。这里有两件不同的事，我想分开对待：

• 管理用户的会话（查找、改名、归档、删除、发消息）：按 feat(agent): add Bot mode with SendUser and a Host-owned outbox #6464 里已经讨论过的确认分级开放。
• 控制 Bot 自己启动的 worker（发消息、停止、恢复、读进度）：我希望在代码里按 parentSessionId 校验，和 WorkHub 校验任务归属一样，避免误调用去停止或打扰 Bot 没有启动过的会话。这样可以吗？还是你们更倾向只靠确认？

worker 完成后唤醒 Bot，对普通 Session 目前没有对应机制（WorkHub 是轮询任务状态，再写入一条 WorkhubTask 来源的消息），需要一个小的监视记录和一个新的消息来源，我打算作为单独一步来做。

[M4n5ter]

English

This sounds reasonable to me. I’d lean towards A for the first step too; I don’t think we need to bring the dependency graph and frozen inputs into the Bot’s delegation path.

One clarification: leaving out the graph shouldn’t mean the Bot can only run one worker at a time. It should still be able to delegate independent work in parallel, then decide what to do next as results come back.

Checking parentSessionId sounds fine for operations specifically meant to control the Bot’s own workers. I’d just keep that separate from the general Session tools: users may also ask the Bot to organize or manage their existing conversations, and those operations should remain available under the permission and confirmation model we discussed.

Handling worker completion notifications as a separate step also makes sense to me.

简体中文

我觉得这个方向基本没问题，第一步我也倾向 A，不必把依赖图和冻结输入一起带进 Bot 的委派流程。

有一点想澄清：不带图不应该意味着 Bot 一次只能运行一个 worker。独立的工作仍然可以并行委派，再根据陆续返回的结果决定下一步。

对于专门用来控制 Bot 自己派出的 worker 的操作，检查 parentSessionId 我觉得可以。只是需要和通用的 Session 工具区分开：用户也可能让 Bot 整理、管理自己已有的会话，这些操作仍应按照前面讨论的权限和审批机制开放。

worker 完成后的通知和唤醒机制，单独一步来做也合理。

[liugddx]

Thanks @M4n5ter, that matches how I read it. I'll start without the dependency graph, keep parallel delegation (several independent workers), scope parentSessionId checks to controlling the Bot's own workers, and do worker-completion wake as a separate step. The read-only Session tools landed in #6528.

Before building delegation I hit one thing in the code that I'd rather ask about than decide myself.

A Bot-created worker can only hold the Bot's own tools. In Owner::create (owner.rs, the block under "Agent derivation also inherits the parent's tool ceiling"), a Session created by an Agent identity gets the parent's tool list, or the intersection of the requested tools with it. The Bot's list is only the coordination tools (SendUser, sleep, todo, and now the read-only Session tools), so a worker it creates would have no file or command tools and could not do real work. User-created sessions are not affected (new_conversation_from_bot_uses_installed_tools_in_the_same_workspace covers that).

Options I can see:

1. Explicit tools on SessionCreate for the Bot, not intersected with the Bot's list. Workers get what the Bot asks for, bounded by what the Host installed and by the same approval rules as any Session. Smallest change, but it means a Bot can hand out tools it does not hold itself.
2. A fixed worker preset the Bot can pick (for example the same tools a user-created conversation gets), with no free-form tool list. Narrower, easier to audit, less flexible.
3. Keep inheritance as is and give the Bot the working tools directly. Avoids the question, but it undoes the "coordinator, not doer" boundary.

I lean towards 2 first, and widening to 1 only if a real need shows up. Either way, confirmation: "required" on anything destructive would stay unchanged, and parentSessionId would be checked only for the controls that act on the Bot's own workers.

Which direction do you prefer, or is there a fourth option I'm missing? I won't change this until there is an answer.

[M4n5ter]

English

Thanks for raising this before changing it. I think there is a simpler fourth option: a Session created by the Bot should follow the same creation rules as an ordinary user-created Session, with the Bot recorded as its parentSessionId.

The Bot’s own tool list defines what it can call directly. It should not also be the tool ceiling for the workers it delegates to. Keeping the Bot as a coordinator does not require its workers to be coordinators too.

Concretely:

• With tools omitted, use the same installed-tool defaults as a user-created Session.
• With tools specified, use the ordinary tool-selection rules, without intersecting the list with the Bot’s tools.
• Keep the same Host permission, authorization and confirmation mechanisms as for ordinary Sessions.
• The worker remains an ordinary Session. It does not inherit Bot identity or gain SendUser / sleep.
• Record the Bot as parentSessionId for identifying its workers, the worker-specific controls we discussed, and the later completion-notification/wake step. This should remain separate from general Session management.

I don’t think we need a fixed worker preset for this. Please keep the change scoped to Bot-created Sessions; we don’t need to change ordinary Agent-to-Agent tool inheritance as part of this step.

简体中文

谢谢你在修改前把这个问题提出来。我觉得有一个更简单的第四种方案：Bot 创建的 Session 应该遵循与用户创建普通 Session 相同的创建规则，只是将 Bot 记录为它的 parentSessionId。

Bot 自身的工具列表定义的是它能直接调用什么，不应该同时成为它所委派的 worker 的工具上限。让 Bot 保持协调者定位，不意味着它的 worker 也只能做协调。

具体来说：

• 不传 tools 时，采用与用户创建 Session 相同的已安装工具默认规则。
• 显式传入 tools 时，沿用普通的工具选择规则，不再与 Bot 自身的工具列表取交集。
• 沿用普通 Session 的 Host 权限、授权和确认机制。
• worker 仍然是普通 Session，不继承 Bot 身份，也不会因此获得 SendUser / sleep。
• 将 Bot 记录为 parentSessionId，用于识别它创建的 worker、前面讨论的 worker 专属控制，以及后续的完成通知和唤醒。这些仍应与通用 Session 管理分开。

我觉得这里不需要新增固定的 worker preset。请把这次修改限定在 Bot 创建 Session 的场景，不必在这一步同时改变普通 Agent 派生 Session 时的工具继承规则。

---

Posted by Maka on behalf of @M4n5ter.

[liugddx]

Thanks @M4n5ter, that is simpler and I agree. I changed #6538 accordingly: a Session the Bot creates follows the ordinary creation rules with the Bot as parentSessionId, with no preset and no intersection with the Bot's list. SendUser/sleep are still refused for workers, and ordinary Agent-to-Agent inheritance is untouched.

One thing I kept deliberately narrow for now: the Bot holds the general SessionSend/SessionStop, and they only work on its own workers (checked by parentSessionId). Managing the user's other conversations stays for the confirmation-tier step. Next I'll do worker-completion wake as its own PR.

[liugddx]

Status update and a proposal for folding WorkHub into the Bot. #6528 (read-only Session tools), #6538 (create/send/stop for the Bot's own workers) and #6540 (the Bot is woken when a worker finishes a run) have landed. I verified the whole loop with a real model: the Bot created a conversation, handed it a task, the worker ran real commands, and the Bot woke on its own and read the result before answering.

That leaves the question of what WorkHub still has to contribute. My reading of what the Bot path does not cover today:

WorkHub behaviour	In the Bot path today
Parallel workers	Yes: several independent conversations, each reported separately
Wake on result	Yes (#6540), one report per finished run, retry-safe
Dependency graph, frozen inputs, swarm tools	No, deliberately (agreed above)
Settle step (continue / wait / complete)	No. The Bot decides in free text; nothing records that a piece of work is finished versus waiting
Independent review of a result	No
A task record of its own (status, history)	The worker conversation itself plays that role

Proposal, smallest first:

1. Do not carry the graph, frozen inputs or per-task review. If a task wants review, the Bot can hand the result to another worker.
2. Settle is the only real gap. A small Bot-side tool, or just a convention in the wake message, so that "this worker's piece is done / still waiting / needs more" is recorded durably and the Bot stops getting woken for work it already closed. I would start with the convention and add a tool only if a real need shows up.
3. Then retire workhub_tasks for the Bot only, which it does not hold today anyway; WorkHub stays for other Owners until someone wants it gone.

Questions: is (1) acceptable, and is there a WorkHub behaviour I have missed that you want in the Bot path? If not, I will do (2) as a separate PR.

[liugddx]

Proposal: let the Bot attach files to a SendUser message

Why. The Bot's only voice is SendUser, which carries text. A user who asks the Bot for something a worker produces (a screen recording, a report, an image) gets a sentence about it and has to find the file. The Bot itself cannot read or write files, so the file has to come from a worker, and the Bot has to be able to point at it without being trusted with arbitrary paths.

The security question comes first. If the model can name any path and the Host sends it to the user, a prompt-injected Bot can exfiltrate local files. In the app the recipient is the owner, so the damage is limited; once a Bot speaks through an external channel (the Feishu discussion), it is not. The design should hold for the second case so it does not need redoing.

Proposed rules

1. Reference, not copy. A message may carry attachments: [{ name, ref }], where ref is one of the existing StorageRef shapes, limited to:
   • a file in a Session the Bot created (SessionFile, checked against parentSessionId, the same check as SessionSend), or
   • a regular file under the Bot's own workspace root (WorkspaceFile). Workers created from the Bot share that workspace, so this is where a recording would land.
     Never ExternalFile, never an absolute path from the model.
2. Validated by the Host when SendUser runs. The path must resolve inside the allowed root without following a symlink out of it, be a regular file, and be under a size cap. A failed check is a tool error the model sees, like tools_unavailable today.
3. Pinned. The outbox record stores the reference, the size, the media type and a SHA-256 taken at send time. What the user was shown cannot silently change, and a later read can say "the file changed since it was sent".
4. Idempotent like the text. The call fingerprint covers the references and hashes, so a retry of the same messageId is a no-op and a different attachment under the same id is refused.
5. Deny-list for the obvious. Paths under .git, .ssh, and files named like credentials (.env*, *.pem, id_*) are refused even inside the workspace.
6. No new authority for the Bot. It still cannot read a file; it can only name one a worker made. Reading happens in the client through the existing attachment read path, with the Host checking the reference again.

Out of scope for the first PR

• Uploading to an external channel (needs its own confirmation step; the pinned hash is what the adapter would upload).
• Inline video playback; the first UI is a file card that opens or reveals the file.
• Attachments from the user to the Bot.

Plan

1. Contract + Host validation + outbox record + tests (no UI).
2. File card in the Bot's Chat, reading through the existing attachment path.

Questions for the maintainers

• Is "under the Bot's workspace root" acceptable, or should a Bot only be able to attach files in a worker Session's own file area? The second is stricter, but I have not confirmed that workers write their output there; if they write to the workspace, it would exclude the common case.
• A size cap: what is reasonable for a recording (I would start at 64 MiB)?
• Should the hash pin be enforced on read (refuse a changed file) or only reported?

简体中文摘要

提案：让 Bot 在 SendUser 消息里带文件附件。 Bot 本身不能读写文件，文件只能由它创建的 worker 生成，所以 Bot 需要“指向”文件，但不能被信任去指任意路径（被提示注入的 Bot 可能外泄本机文件；接入飞书等外部渠道后风险更大）。

规则：(1) 只引用引用，不复制，且仅限 Bot 创建的 worker 的文件，或 Bot 工作区根目录下的普通文件，不允许 ExternalFile 和模型给出的绝对路径；(2) SendUser 执行时由 Host 校验（不跟符号链接出界、必须是普通文件、有大小上限），失败时作为工具错误返回给模型；(3) 发送时记录 SHA-256，之后可以提示“文件发送后已变化”；(4) 幂等指纹包含引用和哈希；(5) 拒绝 .git、.ssh、.env*、*.pem、id_*；(6) Bot 不获得新权限，读取走现有附件读取路径并由 Host 再次校验。

首个 PR 不含：上传到外部渠道、视频内嵌播放、用户向 Bot 发附件。计划：先做契约、Host 校验、发件记录和测试，再做界面文件卡片。

想请维护者定：是允许“Bot 工作区根目录下”的文件，还是只允许 worker 自己的文件区（更严，但我没确认 worker 的产物写在哪）；大小上限（我倾向从 64 MiB 起）；哈希是强制拒绝已变化的文件，还是只提示。

Written by Claude Code on behalf of liugddx.