[RFC] Subagent task cards: grouping, settings and retry / 子 Agent 任务卡：分组、配置与重试

[Totoro-qaq]

English · 中文

English

Are the existing subagent task cards enough for day-to-day use? Before adding anything, I'd like to hear which information or actions people actually miss, if any.

The mockups below explore three options: lightweight grouping, details of the settings used, and stopping one subtask before retrying it with another model or thinking effort. These are separate ideas, not an agreed feature set or a commitment to implement them. Keeping the current interface is also a valid outcome.

Why

When work fans out to several subagents, it can become harder to find what is still running, which settings it used, what remains after a failure, and whether one task can be retried. Do these become practical problems in real use, or do the existing cards already cover them well enough?

DeerFlow already has collapsible subtask cards with model, status, steps and results. If changes are useful, the examples keep them in those cards, without another task dashboard or repeated display of the main conversation's model.

What is already available

Checked on 2026-10-29:

• Each task() call already has a card in the conversation, with expandable steps and results. See the existing documentation.
• task() supports choosing a model for one delegation. #7668 continues #4875 / #4895 with native subagent thinking defaults and records of the settings applied. feat(subagents): configure thinking and reasoning effort for native workers #7668 is still under review.
• Todos currently store content and status. If grouping by plan item proves useful, reliably associating an item with its subtask executions would need an ID and related UI/API work.
• #7515 proposes subtask recovery and is also under review. This proposal does not introduce a separate recovery mechanism.

Possible improvements, if useful

Where grouping is useful, add a single collapsible label and a local completion count above the cards in that reply. The model chooses names for the actual work; there is no fixed build/review/fix sequence. Older records without reliable associations keep their existing display.

If grouping is adopted, count current completed tasks in that group, not historical attempts or a percentage of the whole job. A plan item would need an ID that survives renaming to associate delegations and retries reliably, rather than matching titles. write_todos can keep its existing internal tool name.

Open configuration details from the model/effort row of that task's card. Show the model, thinking setting and settings source used for the attempt. Distinguish Off, Model default, a recorded effort, and Not recorded. Missing data should remain missing. Passing effective settings into the task details still needs to be connected and checked; saved defaults are not a substitute for what actually ran.

Keep steps, errors, results and previous attempts in the same card. Notes from an earlier attempt should remain openable after a retry. Leave the main model picker, existing plan area and final file area where they are.

Associating plan items and executions

Gray is the existing path; blue is the proposed addition. Task IDs are internal association data, not ordinary UI labels.

flowchart TD
    P["Main agent plans<br/>when needed"] --> I["Plan item"]
    I --> D["Existing task()<br/>dispatch"]
    D --> E["Subagent runs"]
    E --> R["Status events<br/>and results"]
    R --> L["Main agent continues<br/>with the result"]
    I -. "Plan item ID" .-> A["Keep attempts linked<br/>to their task"]
    R -. "Execution and result" .-> A
    A --> V["Existing task cards<br/>Groups, settings, results"]
    classDef existing fill:#f4f5f7,stroke:#778396,color:#172033
    classDef proposed fill:#edf4ff,stroke:#3568b6,color:#172033
    class P,I,D,E,R,L existing
    class A,V proposed

Loading

Rendered flow diagram

This groups delegated work only. Work done directly by the main agent stays in its existing plan area. Execution order, concurrency and goal completion continue to use the existing runtime.

A separate discussion: stop and retry with new settings

If a subtask goes off track or uses the wrong model, the user could request a stop from its card. Once the previous attempt is confirmed to have ended, they could choose a model and thinking effort for the retry. Until then, the card stays in a waiting state and no replacement starts.

The retry stays under the same task, with both attempts retained. New settings apply only to that retry; the main conversation and other subtasks keep theirs. Model choices should come from the current user's available catalog.

Stopping does not undo actions already taken. Existing results and the point of failure should remain visible before a retry.

The following flow is proposed; its control APIs are not connected. It describes a fresh attempt after stopping, not seamless continuation from the previous model's last step.

sequenceDiagram
    actor U as User
    participant V as Task card
    participant R as Runtime
    participant L as Main agent
    Note over V,L: Proposed flow, control APIs are not connected
    U->>V: Stop this subtask
    V->>R: Request a stop
    V-->>U: Stopping
    alt Previous attempt is confirmed stopped
        R-->>V: Stopped, existing results retained
        U->>V: Pick model and thinking effort
        V->>L: Request a retry of the same task
        L->>R: Dispatch through existing task() when ready
        R-->>V: New attempt status
        R-->>L: New result
        V-->>U: Show both attempts under one task
    else Stop is not confirmed
        R-->>V: Still stopping or status unknown
        V-->>U: Keep waiting, do not start a replacement
    end

Loading

Rendered sequence diagram

How a busy main agent receives a retry request, when it dispatches again, and which previous material it reuses still need to be checked through the existing run path and aligned with #7515. This is a separate discussion, not backend functionality already promised by the card-display changes.

Local prototype and screenshots

Everything below is a local simulated prototype, not a screenshot of current main or a real execution. Task content, model choices, configuration records, stop confirmations, dispatch and results are synthetic. No backend or model is connected, and the interface carries the same disclosure.

Demo controls only drive synthetic events for the preview; they are not part of the proposed product UI.

The prototype reuses existing UI components, theme and conversation layout. There is no separate board or duplicated main-model display. Configuration and retry start from the relevant task card.

Figure 1 · Grouping. One of the three current tasks in this group is complete.

Figure 2 · Configuration. Details belong to the selected task. Not recorded is not displayed as Off.

Figure 3 · Choosing retry settings after stopping. The stop confirmation is simulated by the demo controls; this does not demonstrate a working stop API.

Figure 4 · Previous and new attempts. After the main agent receives and dispatches the retry, the new attempt is running (simulated). Old notes remain accessible, and the task count does not grow. The waiting state is linked below.

More states: Waiting for stop confirmation · Awaiting dispatch · Opening old notes · Narrow layout · Narrow retry dialog · Dark narrow retry dialog.

Checks and next steps

The prototype passed 21 browser checks and TypeScript checking. Coverage includes configuration details, waiting without stop confirmation, queued retries, old notes, refresh, unchanged parent/sibling settings, both languages, both themes and narrow layouts. The bilingual figures were recaptured through the same interaction scenario.

These checks cover UI and simulated state changes. Real stopping, permission checks, applied runtime settings and cross-model handoff have not been tested. There is also no user study or before/after comparison establishing a usability gain.

If the discussion identifies a real need, existing records could be replayed through the page at no model cost, then walked through with users: can they find the chosen task, applied settings, errors and retained results more easily? Does it remain consistent after refresh or delayed events? That would help decide which changes, if any, are worth implementing.

Questions to discuss:

• Are the current cards already enough? In which real tasks is information or an action difficult to find?
• If something is missing, what matters most: grouping, the settings actually used, errors/results, or stopping and retrying one task? Are any of these unnecessary?
• Would grouping help, or is the existing flat list easier to follow? What would you want grouped together?
• Is stop-and-retry worth a dedicated action, or is asking the main agent to dispatch again enough? If a dedicated action is needed, what should happen while the main agent is busy?

---

中文

现有子 Agent 任务卡对日常使用来说是否已经够用？在加东西之前，想先听听大家实际还缺哪些信息或操作，也可能没有必要再加。

下面的模拟原型展示了三个可分别讨论的方向：轻量分组、本次配置详情，以及停止某个子任务后换模型或思考强度重试。这不是已经定好的功能清单，也不表示已经决定开发；维持现状同样是可以接受的结论。

为什么想做

一个任务派出几个子 Agent 后，哪项还在跑、用了什么配置、失败后留下了什么，以及能否只重试其中一项，可能会变得不容易找。这些在实际使用中是否构成问题，还是现有卡片已经能解决？

DeerFlow 已有可折叠的子任务卡，能显示模型、状态、步骤和结果。如果确实需要改，下面的例子尽量沿用这些卡片，不另开任务页，也不重复显示主会话模型。

已有基础与需要补的部分

核对日期为 2026-10-29：

• 每个 task() 调用已有一张对话内任务卡，可展开查看过程和结果。见现有说明。
• task() 已支持单次选择子任务模型。子 Agent 的默认思考配置和生效值记录由 #7668 接续 #4875 / #4895 补充；feat(subagents): configure thinking and reasoning effort for native workers #7668 目前仍在审。
• 当前 Todo 保存内容和状态。如果按计划项分组确实有用，还需要编号来准确对应子任务执行，并补充相关显示和接口。
• #7515 正在讨论子任务恢复，目前仍在审。这里不另做一套恢复机制。

如果确实需要，可以补哪些

需要分组时，在这段回复里的任务卡上方放一行可折叠标题和本组完成数。名称由模型按本次工作生成，不固定成 build、review、fix。没有可靠关联的旧记录继续按原样显示。

如果采用分组，数量表示本组当前完成了几项任务，不计入历史执行，也不换算整个任务的完成百分比。计划项需要一个不随改名变化的编号，用来把子任务和重试放回原项；不靠标题相似度匹配。write_todos 可以保持现有内部工具名。

配置详情从对应任务卡的模型或强度一行打开，显示本次实际采用的模型、思考设置和配置来源。要区分“已关闭”“模型默认”“具体强度”和“未记录”；缺少记录时不猜值。生效配置如何进入任务详情，需要接通后再验证，不能只拿保存的默认配置代替。

过程、错误、结果和历史执行继续留在该卡里。旧执行的笔记应能直接打开，不被新尝试覆盖。主模型选择框、原计划区和最终文件区保留现有位置。

计划项与执行怎样对应

灰色是已有路径，蓝色是提议补充的部分。任务编号用于内部关联，不在普通界面展示。

flowchart TD
    P["主 Agent 按需列出计划"] --> I["计划项"]
    I --> D["现有 task() 派发"]
    D --> E["子 Agent 执行"]
    E --> R["状态事件与执行结果"]
    R --> L["主 Agent 收到结果<br/>继续工作"]
    I -. "计划项编号" .-> A["把每次执行归回原任务"]
    R -. "执行与结果" .-> A
    A --> V["现有任务卡<br/>分组、配置与结果"]
    classDef existing fill:#f4f5f7,stroke:#778396,color:#172033
    classDef proposed fill:#edf4ff,stroke:#3568b6,color:#172033
    class P,I,D,E,R,L existing
    class A,V proposed

Loading

流程图预览

这部分只组织已委派的子任务。主 Agent 自己完成的工作仍留在原计划里；执行顺序、并发和目标完成判断继续使用现有流程。

另一个讨论项：停止后换配置重试

用户发现某个子任务跑偏或选错模型时，可以从那张卡发起停止。收到旧执行结束的确认后，再选择本次重试的模型和思考强度。未确认停止时，页面保留等待状态，不启动替代执行。

重试仍属于原任务，新旧执行分别保留。新配置只作用于这次重试，主会话和其他子任务的配置保持不变；模型选项应来自当前用户可用的列表。

停止不会撤销已经发生的操作；重试前应能看见已有结果和失败位置。

下图是拟议流程，控制接口尚未接通。它表示停止后重新执行，不承诺从原模型的最后一步继续。

sequenceDiagram
    actor U as 用户
    participant V as 子任务卡
    participant R as 运行时
    participant L as 主 Agent
    Note over V,L: 拟议流程，控制接口尚未接通
    U->>V: 请求停止所选子任务
    V->>R: 提交停止请求
    V-->>U: 正在停止
    alt 确认旧执行已结束
        R-->>V: 旧执行结束，保留已有结果
        U->>V: 选择模型与思考强度
        V->>L: 请求重试同一个任务
        L->>R: 接收后沿现有 task() 派发
        R-->>V: 新执行状态
        R-->>L: 新执行结果
        V-->>U: 同一任务下保留两次执行
    else 尚未确认停止
        R-->>V: 仍在停止或无法确认
        V-->>U: 继续等待，不发起替代执行
    end

Loading

时序图预览

主 Agent 忙碌时怎样接收重试要求、何时重新派发，以及复用哪些已有材料，需要沿现有运行路径验证，并与 #7515 的恢复工作对齐。这个操作单独讨论，不作为卡片展示改动已经承诺的后台能力。

可点击原型与截图

以下均为本地模拟原型，不是当前主线截图或真实运行效果。 任务内容、模型列表、配置记录、停止确认、派发和结果都为模拟；不连接后端或模型。页面和弹窗也有相应标注。

“演示控制”只用于切换模拟事件，不是正式界面要新增的功能。

原型复用现有 UI 组件、主题和消息布局，没有独立看板，也没有重复的主模型显示。配置和重试均从对应子任务卡进入。

图 1 · 分组。 1/3 表示本组当前有一项任务完成。

图 2 · 配置详情。 只查看所选任务；“未记录”不会显示成关闭。

图 3 · 停止后选择重试配置。 停止确认由演示控制模拟，不代表接口已经实现。

图 4 · 新旧执行。 主 Agent 接收并派发后，新尝试进入运行中（模拟）；历史笔记仍有入口，任务数量不增加。等待派发的状态见下面的补充截图。

补充：等待停止确认 · 等待派发 · 打开旧笔记 · 窄屏 · 窄屏重试 · 深色窄屏重试。

验证与下一步

原型的 21 项浏览器检查和 TypeScript 检查已通过，覆盖配置查看、无停止确认时等待、重试排队、历史笔记、刷新、主会话与其他任务设置不变，以及中英文、深浅色和窄屏。中英文配图使用相同场景重新点击并截图。

这些检查验证的是界面与模拟状态变化。实际停止、权限校验、运行中的配置生效和跨模型材料交接还没有验证，也没有用户走查或前后对比数据证明效率提升。

如果讨论后确认有实际需要，可以先用现有记录做零费用页面重放，再请用户试用：能否更快找到所选任务、实际配置、错误和已有结果？刷新或延迟事件后是否一致？根据这些反馈，再决定哪些值得做，哪些不做。

希望先讨论：

• 现有卡片是否已经够用？哪些真实任务里，信息或操作不容易找到？
• 如果确实缺东西，最需要补的是分组、实际配置、错误和结果，还是单任务停止后重试？哪些没有必要？
• 分组会更好找，还是现在平铺的方式更清楚？如果分组，大家希望按什么分？
• 停止后重试值得单独做入口吗，还是让主 Agent 重新派发就够了？如果需要专门入口，主 Agent 忙碌时希望怎么处理？