Skip to content

[Draft RFC / Experimental] Async Workbench:独立 manager 与 loop worker 的上下文和生命周期 #295

Open

Description

@Dong1017

Current state: Draft RFC opened on 2026-11-01 with no assignee; a same-day scope review proposed an external side-effect and recovery contract, which the body records as a pending suggestion, not an accepted requirement.
Decision needed: Whether to adopt the proposed recovery contract (unknown/in-flight state, one execution controller, separate launch, charge and adoption counts) as an acceptance requirement, from the RFC owner (author Dong1017).
Next action: No assignee; the RFC owner decides the execution boundary; no implementation, experiment or change to #249/#268 ownership is authorized.

Status: Proposed / Draft discussion。 探索 Workbench 能否采用独立 manager thread 协调多个 loop worker threads,让主任务在等待实验时仍可处理反馈、调整后续计划。以 DSH 为首个讨论实例,参考 dsh-superagent 的分层管理。本 Issue 先澄清想法与验证方法,尚未进入实施或实验阶段,不预设异步一定更快或更省成本。

核心想法与边界

  • Task、thread、environment 分开。 Task 是目标与完成条件;thread 是 agent 上下文;environment 是源码、进程和资源边界。一个 worker 可负责一个有界优化方向并进行多轮迭代,不默认“一次工具调用一个 agent”,也不把独立 thread 当作隔离环境。
  • 控制异步,测量受控。 Manager 可同时接收状态、准备下一步和等待结果;worker 仍复用已有 Workbench runner、独立验证与证据。异步不意味着同设备上的 baseline/candidate 可以互相干扰,也不意味着再建一个 runner。
  • 上下文有边界。 Manager 保留目标、决策与结果索引;worker 获取任务相关、固定版本的资料。优先返回简短结论、产物/证据链接和未决问题,按需读取详情,而非回灌全部转录。需讨论 worker 延续、fork、压缩或重建的时机;fork 快照不等于实时共享上下文。探索过程的上下文延续与正式对照的独立会话应分别考虑。
  • 对话不能代替持久任务状态。 明确谁拥有任务、何时算启动/交付/验证,以及断线、取消、超时、重试和迟到结果如何处理。无法访问的 session 保持未知;重试不能遗忘既有执行、费用或资源占用。Worker 自报完成不等于目标验收;并发数量限制也不等于费用上限。
  • 先协调已有工作。 #249 / Draft #268 已涉及 parallel round、队列和资源控制,后者仍有未解决 review,不能直接视为安全底座。本议题不接管其 owner,不重复 #152 宿主插件或 #220 compaction campaign,也不成为 [Tracking] SkillEval evolution: local evidence, PR review and optional LLM judge #253 的新前置条件。

待讨论:恢复与外部副作用

执行语义评审提出:最多采纳一个结果,不等于外部调用只执行一次或只计费一次。外部调用已接收、但确认尚未持久化时发生崩溃,应如何对账?建议保留 unknown/in-flight、明确唯一执行控制者,并分别观察实际启动次数、资源/费用保留量和采纳结果。上述为待决建议,尚未接受为实现要求;下方“不重复执行”的验证目标需结合执行端幂等或可查询收据明确适用边界,不能仅凭 stub 通过宣称 exactly-once。

要验证的事项(拟议,未执行)

  • 用一个具体任务对照同步与异步流程,确定 worker 粒度、manager 何时介入,以及哪些信息必须持久保留。
  • 先用无模型 stub 检查乱序完成、重复回报、断线/重启、取消及迟到结果:不重复执行、不丢负面证据、不误采纳陈旧结果;取消后核对资源清理,启动前核对资源/预算认领。
  • 检查上下文裁剪/交接是否保留关键约束、版本、失败与来源,以及不同 worker 或对照组之间的信息污染。
  • 若后续接受实验,事前固定任务、质量判据与总预算,对比同步 baseline:manager 响应性、独立工作重叠、完成质量、总耗时/tokens、重复工作及协调失败。保留“更快但更贵”、无收益或退化结果,不只统计并发数。
  • 根据证据决定继续、缩小或停止;实现前明确与现有 round/宿主接口的职责分工。具体 schema、调度策略、实现者和实验资源留待讨论。

References

Activity

  1. added
    area:workbenchCLI workbench: profile, A/B loop, quality gates, evidence reports
    kind:rfcProposal / design discussion; scope review before build
    on Nov 1, 2026
  2. Dong1017 commented on Nov 1, 2026

    @Dong1017
    CollaboratorAuthor

    范围结论(P2|待明确的执行语义,而非实施阻塞): 这个 Draft 已正确区分 task/thread/environment,也明确不得重复建设 runner。还建议把“stub 检查不重复执行”改成可判定的外部副作用与恢复契约:仅凭 manager 的 thread 状态,无法保证外部调用 exactly-once。

    • 可触发反例: manager 已派发、外部调用已接收,但 ACK/claim 未持久化时崩溃;重启若把“无回执”当“未启动”补派,会重复执行或重复计费。即使迟到的两个结果最终只采纳一个,也不等于仅执行一次。类似风险已在 #249 的执行绑定讨论 和 Draft #268 的 claim 持久化 review 中指出:该 draft 当前在 build/trial 调用后才推进 ledger 的 claimed → finished(parallel_round.py 对应路径),尚不能作为已验证的安全底座。
    • 最小建议: 在本 RFC 中先明确 task_id / thread_id / round+attempt binding / generation 的映射与唯一状态所有者。manager 只负责上下文和结果索引;启动许可、尝试身份、预算/资源 claim、deadline 和恢复对账仍由已有执行控制层拥有,不再维护第二份可独立发令的 ledger。无法确认外部调用是否已开始时应保留 unknown/in-flight 并先对账,不能自动把它重试成新尝试。
    • 判别性 stub(仅为验收建议,不授权执行): 故障注入至少覆盖“持久预留前”“已持久 claim、外部调用接收后但确认回写前”“重启后收到旧 generation 的迟到结果”。分别记录实际启动次数、已收费/占用的保留量、最终被采纳结果;把“最多采纳一个有效结果”和“外部调用恰好执行一次”分开表述。若外部执行端没有幂等令牌/可查询收据,后者不应被无模型 stub 的绿灯替代。

    这并非要求 #295 等待 #249 全部交付,也不建议扩大到新调度器;现阶段可先评估无外部副作用的控制面异步,具体执行边界由原 owner 取舍。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:workbenchCLI workbench: profile, A/B loop, quality gates, evidence reportskind:rfcProposal / design discussion; scope review before buildstatus:proposedWaiting for the decision named in the status block

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions