建议：让子 Agent 按情况决定是否唤醒主 Agent，而不是每次都唤醒

[B1lli]

希望解决什么问题

我会直接打开子 Agent 的会话，继续提问、讨论方案或处理它提出的决策。子 Agent 已经向我解释清楚后，主 Agent 又因为收到通知而运行，把同一份信息重新讲一遍。

希望把两件事分开：把信息同步给主 Agent，和让主 Agent 现在开始思考、行动或回答。由子 Agent 根据当前情况决定采用哪一种，而不是每次结束一轮就自动唤醒主 Agent。

核心是让子 Agent 可以选择通知方式。“在主会话直接展示子 Agent 原话”只是可选的展示办法，不是这条需求要求所有通知采用的形式。

我的意见和建议原文

以下完整保留我的原始表述：

我认为，让 Sub Agent 自己决定什么时候应该通知主 Agent 并将其唤醒以生成答复，什么时候应该只把上下文塞进 Context 里面会比较好。如果 Sub Agent 还能控制主 Agent 生成答复时需要投入多大的 Effort，以及生成什么内容，那就更加好了。

比如说，我想到的这种情况下的理想方案应该是：

1. Sub Agent 把生成完毕的决策信息同步给 Main Agent。
2. Main Agent 不做复述，而是提示：“Sub Agent 有一些需要你决策的信息如下，你可以直接看”，然后附带一个消息块。
3. 前端将这个消息块渲染为 Sub Agent 发送的原消息的逐字原文本。

这样一来，用户无论是在 Main Agent 还是在 Sub Agent 里面看，都可以处理这条信息，同时不会产生Main agents二次复述这些决策信息所带来的 Token 输出成本。

实际遇到的情况

环境：macOS，DSH Desktop 0.7.2。以下是对 2026-09-09 本地父、子会话持久化记录的核对，不是另行构造的测试；已省略项目、文档、会话标识和内部方案内容。

一个很明确的例子（纽约时间）：

1. 09:35:48，我直接在子 Agent 会话里追问它提出的决策及其背景。
2. 09:36:10，子 Agent 回答完毕。这一轮没有调用 report。
3. 同一秒，主 Agent 收到来自该子 Agent 的 subagent-settled，开始新一轮。
4. 09:36:20，主 Agent 再次解释这些决策、再次让我选择。这一轮还检查了其他任务进度，共有 2 次模型请求，记录的输出合计 1,484 tokens（含推理）。

这不是界面把同一条消息画了两遍，而是主 Agent 确实又运行、又生成了回答。上述 token 数是整轮的用量，不能全部归为逐字复述成本。

另两次直接向子 Agent 提交的请求中，子 Agent 先调用 report，随后又有 subagent-settled。其系统提示仍要求结束前调用 report。因此，只改其中一条通知路径可能不够。

也不希望一刀切地禁止主 Agent 接收结果或继续工作：同一组记录里，主 Agent 有时确实做了有用的文档同步、证据核对。要避免的是每次子 Agent 回答完，都默认值得主 Agent 再运行一轮。

核心建议：由子 Agent 按情况选择通知方式

子 Agent 应能根据自己正在处理的事情、当前结果和协作需要，选择：

1. 叫醒主 Agent，并说明希望它做什么。 例如请主 Agent 理解最新情况，再派发其他任务；可附上工作建议，以及希望投入多大 effort。
2. 叫醒主 Agent，把下一步交给它判断。 子 Agent 提供情况和依据，主 Agent 结合自己的完整上下文，决定接下来做什么，不要求子 Agent 预先指定行动。
3. 不叫醒，只把消息放进主 Agent 的上下文。 主 Agent 下次正常运行时可以看到，不为这次信息同步额外启动一轮模型请求。

这些方式由子 Agent 按情况决定，不应固定为每次都唤醒。子 Agent 对具体行动和 effort 的说明，也不应成为所有通知的必填项；它可以只报告情况，让主 Agent 自己决定。

正在等待子任务结果才能推进工作时，可以选择唤醒；用户直接在子会话里追问、补充信息时，可以选择只同步。它们是使用场景，不是要用固定关键词或“紧急/不紧急”规则替代子 Agent 的判断。

可选办法：在主会话直接展示子 Agent 原话

当消息主要是给用户看的，例如一组待决策事项，可以在主会话显示简短提示和子 Agent 的原消息块，标明来源并能跳回原消息。正文逐字展示，用户从任一会话进入都能处理同一条信息，避免主 Agent 为转述再生成一遍。

这只是其中一种展示方式。需要主 Agent 理解现状、分析或派发任务时，仍然应允许它正常思考、回答和行动。

如果提示只是固定文案，可以直接由前端展示，不必为生成这句提示再启动主 Agent。这里希望消除的是不必要的二次改写开销；不声称后续模型读取这些上下文也没有 token 成本。

对这条建议的进一步澄清（原文）

直接展示原话，别再复述一遍，只是一种可选的方法，我感觉它不应该被放在这个idea的标题里面

子 Agent 也可以采取以下策略：

1. 叫醒主 Agent，并让他理解一下现状，再派发一些别的任务。
2. 叫醒主 Agent，由主 Agent 自己决定接下来该干什么。
3. 完全不叫醒主 Agent，只是把消息注入到 contexts 内部。

这些都应该由 sub agent 自己来按情况决定，而不是总是唤醒主会话。

与已有讨论的区别

• #684 已反馈最终答复后出现追加确认回合，并提出非交互通知方向。
• #2192 讨论 report 与结束通知的重复投递和顺序。
• #471 讨论较旧的汇报晚于新结果到达，触发额外回合。

这条需求的核心是让子 Agent 按情况决定是否唤醒主 Agent，以及唤醒时是否附上行动建议。用户直接与子 Agent 继续对话是一个具体例子，直接展示原消息只是可选方案。上面的实际案例没有主动 report，单独一条结束通知也会触发主 Agent，所以仅做重复消息去重或修复顺序，不能完整解决。

这是产品体验建议，不预设底层必须采用哪种实现。如果已有设置、插件接口或计划能支持这种用法，也请指出。

[argszero]

@B1lli 你这帖把「信息同步」和「唤醒主 Agent」明确拆成两件事，我认为判断是对的：单靠去重/修顺序解决不了。下面是我在 0.1.5-alpha.2 基线沿 packages/subagent/subagent 读出来的实际拓扑，以及缺口到底在哪一层（有些结论和你的推测略有出入，我按源码说）。

一、你看到的两次投递，确实是两条独立路径

1. 子 Agent 自己发的话——走 agent-message（source.form: 'relay'，continuation-messages.ts:15-21）。in-process driver 的场景下，落地形态是子 Agent 调用 structured_output 工具（subagent-in-process-driver/src/structured.ts:19/27，提示词原文 "you MUST report it by calling the structured_output tool"）。
2. 运行时的结算通知——走 subagent-settled（source.form: 'notice'，:27-35）。这条不是子 Agent 写的，源码注释说得很直白："an Agent message is content the sender chose, while this message is the manager stating what became of the child"。它由 Activation 拆除时产生（notifySettlement，continuation-activation.ts:823；消息构造 createSettlementMessage，continuation-messages.ts:135）。

所以 09:36 那次没有 report 仍唤醒主 Agent，只可能是路径 2 单独触发——这正好是你论证的关键点，成立。

二、一个重要修正：核心其实已经有「不唤醒」的档位，只是不由场景决定

我原本也以为是「一律唤醒」，读下来不是。notifySettlement 里是二选一（continuation-activation.ts:826-833）：

const parent = this.ctx.agents.get(activation.parentSession)
if (parent === undefined) return
const message = createSettlementMessage(activation.childId, terminal)
if (this.closingTeardownFor(parent) !== undefined) {
  parent.inject(message)          // 不唤醒：只进上下文
  return
}
this.sendWaking(parent, message, parent.status === 'idle' ? 'queue' : 'steer')  // 唤醒

对照三个原语（agent-loop/src/agent.ts:137-147，都只是 send(message, target, wakeup) 的包装）：

原语	inbox 目标	唤醒
followup()	next-turn	是
steer()	next-step	是
inject()	next-step	否（wakeup=false）

所以你要的第 3 档原语存在，你猜的也没错；真正的缺口是：这个选择由核心按「父 Agent 是否正在拆除」来决定（closingTeardownFor，:563-570），而不是按场景或子 Agent 的意图。拆机窗口里才 inject，其余一律 sendWaking。你要的是把决策权从「拆除状态」换成「子 Agent 的意图」。

顺带回答你「只改一条路径够不够」：不够，而且比你想的更彻底——report 那条（structured_output）是普通工具调用，它的返回值不会回流给核心去影响通知档位，两条路径目前根本没有通信。

三、拆成三个子缺口，好让维护者逐个取舍

(a) 谁决定唤醒。 现代码：核心按拆除状态。期望：子 Agent 按场景。这是最小、最干净的一处——notifySettlement 的 delivery 已经是一个变量（:833 的 'queue'|'steer'），扩成可携带「只注入」即可，语义与 inject 已有注释完全对齐，不需要新原语（Agent.inject 的文档原文就是 "…without waking the driver"，agent/src/runtime-types.ts:236-241）。

(b) 行动建议 / 「希望它做什么」的载具。 现在结算消息是固定 notice（form/summary/senderSessionId 三个字段），没有位置放「叫醒时要它干嘛」。你举的「主 Agent 复述一遍」的 token 成本，根因就在这：要让主 Agent 知道「这是要你决策的」，只能另发一条 agent-message 让它读——于是它自然会转述。

(c) 父 Agent 的 effort。 这条技术上已经有挂载点，但粒度不匹配：agent/request waterfall（agent/src/runtime-types.ts:346）可以整体替换 LlmCallConfig，其中就有 reasoningEffort/maxTokens（llm/src/call-config.ts:23-31）。但它是按步触发、作用于父 Agent 自己正在跑的那一轮，不是按「收到某条消息」触发；而触发时父 Agent 那轮往往已经在跑了——所以「子 Agent 为它这条通知指定 effort」目前没有 per-message 的载具（你帖子里也说了，这不该成为必填项）。

四、插件可挂载面：能「压住唤醒」，但做不出「无唤醒投递」

本期我按任务惯例扫了这一层的可用缝，结论要诚实说明：

• 可用：agent/inbox/inserted / agent/inbox/claimed / agent/pre-step（agent/src/runtime-types.ts:285/296/330）。agent/pre-step 是 waterfall，payload 里带 messages（正是本步 claim 到的那批，含 subagent-settled），决策是 {kind:'enter'|'reject'}；claim 点 agent.ts:249-255、消费点 :289-300。所以插件能观察到「父 Agent 正要为这条通知起一轮」，并把它挡掉。
• 不可用：Agent.inject() 这条「不唤醒的入队」没有对插件暴露的写入口；而 {kind:'reject'} 的语义是 turnEnds = {kind:'blocked'}（agent.ts:290-293）——那是关掉这一轮，不是「静默放进上下文」；更麻烦的是 claim 发生时消息已经从 inbox 里被移除并落了 projection（agent-loop/src/inbox.ts:111-116），插件无法把它原样「退」回一个不额外起轮的状态。

结论：缺口在核心面、插件只是受害者。插件今天能做到的是「抑制这次额外运行」（有损：消息被吞），而你要的「只同步、之后正常运行再看到」，需要核心把注入档位交出来——这件事之后，插件才谈得上做成完整实现。我不会把「能屏蔽」包装成「能实现你的需求」。

五、给你的收敛建议

最小核心改动是把 delivery 的选择权从「拆除状态」移到「子 Agent 意图」：

1. notifySettlement 的 delivery 增加「只注入」一档（复用 inject，不新增原语）；
2. 子 Agent 侧的意图载具 = structured_output 调用参数里加一个可选字段（它本来就要被要求调用这个工具，加个 enum 的成本很低），而不是另立一套协议；
3. 父 Agent effort 若要保留，先做成可选、旁路（agent/request 已有能力），别做成必填——与你的意见一致。

如果你或维护者觉得方向可行，我可以先出一个插件做兜底（用 agent/pre-step 压掉不需要的唤醒 + 明确提示消息被延后），把边界和代价都写在 README 里；等核心开了注入档位再升级成完整版。要我动手的话回一句就行。

[Ronbb]

要我动手的话回一句就行。

动手！