尧图网页设计 
Cherry Studio 审批请求通知Agent 等待审批时如何及时触达用户【免费下载链接】cherry-studio Cherry Studio 是一款支持多个 LLM 提供商的桌面客户端项目地址: https://gitcode.com/CherryHQ/cherry-studio当 Agent 或助手Assistant在运行中暂停并等待工具审批tool approval时Cherry Studio 现在会像任务完成通知一样主动触达用户如果用户正在另一个会话中会弹出应用内卡片如果应用在后台则发送系统通知。点击卡片或通知即可一键跳转到等待审批的会话。本文基于仓库中的变更记录与源码实现梳理这一通知能力的触发机制、双通道投递路径、设置开关与点击跳转的完整闭环。背景审批请求为何需要主动触达在引入本通知机制之前工具审批请求只出现在会话内部的消息流中。这带来一个实际问题用户可能在一个会话中发起了包含工具调用如执行命令、访问文件、调用 MCP 工具的 Agent 任务然后切到其他窗口继续工作此时该会话会因等待人工审批而长时间处于阻塞状态awaiting-approval用户却完全不知道需要返回处理。仓库中的变更记录2026-08-13-approval-request-notifications.md明确指出本次变更将审批请求的呈现方式对齐到任务完成通知task-completion notification的既有路径同一 PR、同一投递通道、同一个后台开关。也就是说审批通知不是一套独立的新系统而是复用了会话通知基础设施的一个新事件类型。通知投递的双通道设计从 NotificationService.ts 的实现可以看到会话通知的投递遵循前台优先、后台兜底的双通道策略应用内卡片in-app card当存在处于聚焦状态的 full-chrome 主窗口时通知通过 IPC 事件notification.conversation发送给该窗口的渲染进程由界面呈现为应用内卡片后台系统通知当没有任何窗口聚焦应用处于后台或最小化时改走 Electron 原生通知ElectronNotification通道由操作系统弹出系统通知。两个通道由同一个函数deliverConversationNotification统一决策因此应用内卡片与系统通知永远不会同时出现——这正是变更记录中Clicking either takes you straight to the waiting conversation点击任一即可直达等待中的会话得以成立的统一入口设计。统一的事件模型在类型层面两类会话通知被建模为同一个联合类型ConversationNotification见 notification.tsexport type ConversationNotification | (ConversationNotificationBase { kind: task-completion; type: success }) | (ConversationNotificationBase { kind: approval-request; type: warning })任务完成通知kind: task-completion、type: success审批请求通知kind: approval-request、type: warning。二者共享同一基类meta携带ConversationNavigationTarget会话导航目标actionKey固定为CONVERSATION_NOTIFICATION_ACTION_KEY conversation.open。这个设计让通知的点击跳转逻辑可以完全复用无需区分通知来源。对应地IPC 通道层在 notification.ts 中声明了notification.conversation事件专门用于向前台 full-chrome 渲染器投递呈现就绪的会话通知而后台系统通知则由主进程main process直接持有不走渲染进程。审批事件从何而来事件源链路审批请求通知的触发源有两个均通过ApprovalRequestedEvent事件对象驱动见 approval.tsexport interface ApprovalRequestedEvent { topicId: string approvalId: string requestedAt: number }NotificationService在初始化时同时订阅了两个事件源见 NotificationService.ts流式对话场景AiStreamManager.onApprovalRequested——当 AI 流式输出中出现tool-approval-requestchunk且当前会话属于持久会话stream.isPersistentConversation时触发见 AiStreamManager.tsAgent 会话运行场景AgentSessionRuntimeService.onApprovalRequested——覆盖 Agent 会话运行器runtime在等待工具审批时的场景。两条路径最终汇聚到同一个处理器handleApprovalRequested因此无论审批来自普通助手会话还是 Agent 会话通知行为完全一致。值得注意的是AiStreamManager在触发事件时会通过publishedApprovals集合做去重保证同一approvalId只触发一次通知避免并行工具审批造成重复打扰。通知文案与会话定位审批通知的文案根据会话类型区分见 NotificationService.ts会话类型标题文案i18n key英文示例Agent 会话notification.action_required.agentAgent needs your input助手会话notification.action_required.assistantAssistant needs your input文案在 en-us.json 等多语言文件中均有对应翻译de-de.json、el-gr.json等同样维护中文用户会看到对应的本地化文案。通知正文则解析为会话名称resolveConversationTarget根据 topicId 判断是 Agent 会话isAgentSessionTopic还是普通助手会话进而通过AgentSessionService或TopicService查询会话名称若查询失败或名称为空则回退到新会话/新对话之类的默认文案。点击通知直达等待会话这是本次变更的体验核心。系统通知的点击处理在 NotificationService.ts 中实现点击通知后先检查actionKey CONVERSATION_NOTIFICATION_ACTION_KEY且meta是合法的会话导航目标isConversationTarget校验命中则调用ConversationNavigationService.focusOrOpen(meta, message)——该服务会聚焦主窗口并打开对应会话未命中普通通知则降级为显示主窗口并通过notification.clicked事件交给渲染进程处理。isConversationTarget校验conversationType必须为assistant或agent、且conversationId非空确保只有会话类通知才能触发跳转。应用内卡片走渲染进程的对应交互逻辑同样收敛到打开meta指定的会话。设置开关Agent Assistant Notifications后台系统通知受偏好项app.notification.assistant.enabled控制这一点在deliverConversationNotification中体现只有当没有聚焦窗口、且该开关开启时才会真正弹出系统通知见 NotificationService.ts。开关的 UI 位于设置页的 Notification 设置区NotificationSettings.tsx即Agent Assistant Notifications。本次变更后该开关的说明文案已更新为同时覆盖任务完成与审批请求两类后台通知见原变更记录的 Notes for release manager 部分开启该开关应用在后台时既能收到 Agent/助手任务完成的系统通知也能收到等待审批的系统通知关闭该开关后台系统通知完全静默但应用内卡片不受影响——只要应用处于前台审批卡片依然会正常弹出因为应用内通道不经过该开关。用户需要做什么对普通用户而言无需任何操作应用内卡片是自动出现的。若希望应用在后台时也能收到审批提醒只需在「设置 → 通知」中开启Agent Assistant Notifications即可。开启后审批请求与任务完成两类后台通知共用该开关行为完全一致。行为对比变更前后场景变更前变更后用户在别的会话工作时本会话 Agent 等待审批审批只在会话内部可见用户不知情任务可能长时间阻塞前台弹出应用内卡片点击直达会话应用在后台最小化/切到其他应用无任何提醒系统通知弹出点击直达会话并聚焦主窗口后台通知开关仅覆盖任务完成同时覆盖任务完成与审批请求通知类型仅task-completionsuccess增加approval-requestwarning语义上更醒目审批请求被标记为type: warning而非完成通知的success在系统层面就能区分需要人工介入与任务已完成两种状态用户在通知中心里可以一眼识别出需要处理的事项。小结审批请求通知是 Cherry Studio 会话通知体系的自然延伸它复用ConversationNotification统一类型、notification.conversationIPC 通道、conversation.open点击跳转机制以及同一个后台通知开关只是新增了approval-request这一事件类型与warning呈现语义。从 变更记录 到 NotificationService.ts 的实现可以看到一次小而完整的体验升级用户再也不会因为忙于其他会话而错过需要审批的 Agent 任务。【免费下载链接】cherry-studio Cherry Studio 是一款支持多个 LLM 提供商的桌面客户端项目地址: https://gitcode.com/CherryHQ/cherry-studio创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Cherry Studio 审批请求通知：Agent 等待审批时如何及时触达用户
Cherry Studio 审批请求通知Agent 等待审批时如何及时触达用户【免费下载链接】cherry-studio Cherry Studio 是一款支持多个 LLM 提供商的桌面客户端项目地址: https://gitcode.com/CherryHQ/cherry-studio当 Agent 或助手Assistant在运行中暂停并等待工具审批tool approval时Cherry Studio 现在会像任务完成通知一样主动触达用户如果用户正在另一个会话中会弹出应用内卡片如果应用在后台则发送系统通知。点击卡片或通知即可一键跳转到等待审批的会话。本文基于仓库中的变更记录与源码实现梳理这一通知能力的触发机制、双通道投递路径、设置开关与点击跳转的完整闭环。背景审批请求为何需要主动触达在引入本通知机制之前工具审批请求只出现在会话内部的消息流中。这带来一个实际问题用户可能在一个会话中发起了包含工具调用如执行命令、访问文件、调用 MCP 工具的 Agent 任务然后切到其他窗口继续工作此时该会话会因等待人工审批而长时间处于阻塞状态awaiting-approval用户却完全不知道需要返回处理。仓库中的变更记录2026-08-13-approval-request-notifications.md明确指出本次变更将审批请求的呈现方式对齐到任务完成通知task-completion notification的既有路径同一 PR、同一投递通道、同一个后台开关。也就是说审批通知不是一套独立的新系统而是复用了会话通知基础设施的一个新事件类型。通知投递的双通道设计从 NotificationService.ts 的实现可以看到会话通知的投递遵循前台优先、后台兜底的双通道策略应用内卡片in-app card当存在处于聚焦状态的 full-chrome 主窗口时通知通过 IPC 事件notification.conversation发送给该窗口的渲染进程由界面呈现为应用内卡片后台系统通知当没有任何窗口聚焦应用处于后台或最小化时改走 Electron 原生通知ElectronNotification通道由操作系统弹出系统通知。两个通道由同一个函数deliverConversationNotification统一决策因此应用内卡片与系统通知永远不会同时出现——这正是变更记录中Clicking either takes you straight to the waiting conversation点击任一即可直达等待中的会话得以成立的统一入口设计。统一的事件模型在类型层面两类会话通知被建模为同一个联合类型ConversationNotification见 notification.tsexport type ConversationNotification | (ConversationNotificationBase { kind: task-completion; type: success }) | (ConversationNotificationBase { kind: approval-request; type: warning })任务完成通知kind: task-completion、type: success审批请求通知kind: approval-request、type: warning。二者共享同一基类meta携带ConversationNavigationTarget会话导航目标actionKey固定为CONVERSATION_NOTIFICATION_ACTION_KEY conversation.open。这个设计让通知的点击跳转逻辑可以完全复用无需区分通知来源。对应地IPC 通道层在 notification.ts 中声明了notification.conversation事件专门用于向前台 full-chrome 渲染器投递呈现就绪的会话通知而后台系统通知则由主进程main process直接持有不走渲染进程。审批事件从何而来事件源链路审批请求通知的触发源有两个均通过ApprovalRequestedEvent事件对象驱动见 approval.tsexport interface ApprovalRequestedEvent { topicId: string approvalId: string requestedAt: number }NotificationService在初始化时同时订阅了两个事件源见 NotificationService.ts流式对话场景AiStreamManager.onApprovalRequested——当 AI 流式输出中出现tool-approval-requestchunk且当前会话属于持久会话stream.isPersistentConversation时触发见 AiStreamManager.tsAgent 会话运行场景AgentSessionRuntimeService.onApprovalRequested——覆盖 Agent 会话运行器runtime在等待工具审批时的场景。两条路径最终汇聚到同一个处理器handleApprovalRequested因此无论审批来自普通助手会话还是 Agent 会话通知行为完全一致。值得注意的是AiStreamManager在触发事件时会通过publishedApprovals集合做去重保证同一approvalId只触发一次通知避免并行工具审批造成重复打扰。通知文案与会话定位审批通知的文案根据会话类型区分见 NotificationService.ts会话类型标题文案i18n key英文示例Agent 会话notification.action_required.agentAgent needs your input助手会话notification.action_required.assistantAssistant needs your input文案在 en-us.json 等多语言文件中均有对应翻译de-de.json、el-gr.json等同样维护中文用户会看到对应的本地化文案。通知正文则解析为会话名称resolveConversationTarget根据 topicId 判断是 Agent 会话isAgentSessionTopic还是普通助手会话进而通过AgentSessionService或TopicService查询会话名称若查询失败或名称为空则回退到新会话/新对话之类的默认文案。点击通知直达等待会话这是本次变更的体验核心。系统通知的点击处理在 NotificationService.ts 中实现点击通知后先检查actionKey CONVERSATION_NOTIFICATION_ACTION_KEY且meta是合法的会话导航目标isConversationTarget校验命中则调用ConversationNavigationService.focusOrOpen(meta, message)——该服务会聚焦主窗口并打开对应会话未命中普通通知则降级为显示主窗口并通过notification.clicked事件交给渲染进程处理。isConversationTarget校验conversationType必须为assistant或agent、且conversationId非空确保只有会话类通知才能触发跳转。应用内卡片走渲染进程的对应交互逻辑同样收敛到打开meta指定的会话。设置开关Agent Assistant Notifications后台系统通知受偏好项app.notification.assistant.enabled控制这一点在deliverConversationNotification中体现只有当没有聚焦窗口、且该开关开启时才会真正弹出系统通知见 NotificationService.ts。开关的 UI 位于设置页的 Notification 设置区NotificationSettings.tsx即Agent Assistant Notifications。本次变更后该开关的说明文案已更新为同时覆盖任务完成与审批请求两类后台通知见原变更记录的 Notes for release manager 部分开启该开关应用在后台时既能收到 Agent/助手任务完成的系统通知也能收到等待审批的系统通知关闭该开关后台系统通知完全静默但应用内卡片不受影响——只要应用处于前台审批卡片依然会正常弹出因为应用内通道不经过该开关。用户需要做什么对普通用户而言无需任何操作应用内卡片是自动出现的。若希望应用在后台时也能收到审批提醒只需在「设置 → 通知」中开启Agent Assistant Notifications即可。开启后审批请求与任务完成两类后台通知共用该开关行为完全一致。行为对比变更前后场景变更前变更后用户在别的会话工作时本会话 Agent 等待审批审批只在会话内部可见用户不知情任务可能长时间阻塞前台弹出应用内卡片点击直达会话应用在后台最小化/切到其他应用无任何提醒系统通知弹出点击直达会话并聚焦主窗口后台通知开关仅覆盖任务完成同时覆盖任务完成与审批请求通知类型仅task-completionsuccess增加approval-requestwarning语义上更醒目审批请求被标记为type: warning而非完成通知的success在系统层面就能区分需要人工介入与任务已完成两种状态用户在通知中心里可以一眼识别出需要处理的事项。小结审批请求通知是 Cherry Studio 会话通知体系的自然延伸它复用ConversationNotification统一类型、notification.conversationIPC 通道、conversation.open点击跳转机制以及同一个后台通知开关只是新增了approval-request这一事件类型与warning呈现语义。从 变更记录 到 NotificationService.ts 的实现可以看到一次小而完整的体验升级用户再也不会因为忙于其他会话而错过需要审批的 Agent 任务。【免费下载链接】cherry-studio Cherry Studio 是一款支持多个 LLM 提供商的桌面客户端项目地址: https://gitcode.com/CherryHQ/cherry-studio创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考