OpenBitFun 智能体工作流交互与边界补充设计

September 4, 2026 · View on GitHub

范围:为 ../agent-workflow-staged-plan.md 中的场景提供交互和边界补充。 本文不定义新的 Agent Kernel、Harness、QDP 或 DeepReview 核心对象模型;实现时优先复用既有 session、task、Agent Kernel/Harness long-running queue、DeepReview manifest、runtime events 和质量数据面契约。新受管 work packets 仅服务大目标 L1 Review,历史 packet 继续兼容读取。

1. 设计定位

这份设计只回答三个问题:

  1. 用户在不同场景下应该看到什么。
  2. 什么时候允许增加审查、并发和 token。
  3. 哪些 owner 已经存在,不能因为 workflow 补充设计而重复造状态。

不回答的问题:

  • 不定义新的 workflow DSL。
  • 不定义新的 P0/P1/P2/P3/P4。
  • 不定义新的持久化实体作为 P0/P1 前置。
  • 不把固定多 reviewer 严格审查或任务控制台放入默认路径。

2. 复用边界

能力Owner本文约束
任务生命周期、取消、恢复、事件顺序Agent Kernel只消费状态,不新增并行生命周期
工具执行、验证命令、subagent 调用Execution只返回工具/验证结果,不写产品结论
DeepReview 内部 capacity queue、只读 reviewer、report enrichment现有 DeepReview 架构显式 L3 与大目标受管 L1 内部复用;L1 对外仍呈现普通 Review,不作为通用 workflow/task queue
权限、执行域、沙箱、凭据和网络Security Boundary成本或审查确认不能绕过安全确认
证据、指标和回放Quality Data PlaneP0/P1 不新增默认事件;先用既有最小事件
GUI 展示和用户决策Product Surface展示状态、预算、风险和下一步,不拥有权威事实

3. 场景投影

场景默认投影允许升级
低风险任务任务完成摘要用户显式要求更稳时可做本地 L1
本地显式审查Review 面板小目标一个只读 reviewer;大目标使用有界受管批次;不进入 PR/团队流程
PR / 受保护分支 / 团队规则审查Review 面板 + 就绪度摘要当前仅显式 strict 入口进入 L3;受管策略只能提示
CI/测试失败长任务条 + 失败摘要多独立失败且 oracle 可用时队列化
PR comments 批量修复单一任务控制台评论冲突或高风险路径由同一 reviewer 定向复核;不自动扩展 reviewer
大迁移/审计样本报告 + 预算确认 + 控制台样本成功后扩大并发

4. Review 交互

Review 是用户唯一需要理解的审查入口。普通小目标 Review 使用一个只读 reviewer;大目标 Review 在同一个 L1 结果内使用受管、前台等待的只读工作包;显式 Strict Review 复用 L3 DeepReview,由主审直接完成更深检查并自行决定是否需要一次专家或条件质量检查。用户不需要理解 DeepReview、subagent 或 work packets。

入口兼容约束:

  • /DeepReview 只作为迁移窗口内的历史兼容输入,等价路由到 “Review: Strict”,不作为高级别名、调试入口或长期产品入口。
  • child session、auxiliary pane 和受管工作包都是内部实现;普通用户只看到统一 Review 面板,worker 不得在所属 Review 回合结束后延迟回传。
  • 如果辅助 pane 因排障需要暴露,必须折叠到高级详情,并同步更新 DeepReview 架构文档,避免形成第二套产品入口。
强度用户看到默认限制
L0快速检查摘要不创建 reviewer
L1独立审查结果小目标一个只读 reviewer;大目标最多 8 个受管文件批次、2 路并发,统一聚合并明确 deferred coverage
L3严格审查结果和覆盖说明/review strict/DeepReview 兼容输入或内部显式 strict follow-up;直接启动,无例行确认框

Review 面板只按问题呈现:

  • 必须修复。
  • 建议确认。
  • 已覆盖范围。
  • 未覆盖风险。
  • 下一步动作。

不按 reviewer 原始输出拼接,不默认展示完整日志。

5. 成本交互

成本交互的核心是让用户知道“为什么值得继续”。

触发UI 行为
显式 Strict Review直接启动;在运行状态和结果中展示范围、耗时倾向和只读边界,不估算底层模型请求或 token
主审决定请求专家或质量检查只在具体不确定性、高严重度、冲突或低置信度时发生,不提前承诺固定覆盖角色
需要并发 worker说明节省墙钟时间和冲突风险
预算接近上限暂停扩大执行,给出追加预算、保留核心检查、只收敛已完成
oracle 不可靠停止扩大,改为人工确认或小样本建议

小任务不显示成本面板。结束摘要只需要说明已验证、未验证和残余风险。

成本确认最低契约:

  • Review、Strict Review 和受管 L1 工作包都不弹例行预算确认;范围、覆盖、耗时倾向和只读边界通过非阻塞状态与结果呈现。
  • 只有特殊异常、权限/安全边界或缺少必须由用户决定的信息时才请求确认;底层模型请求与 Token 估算、启动前范围调整和停止选项尚未实现,不写成当前能力。
  • 预算确认不能替代安全确认;执行位置、沙箱等级、写入范围、网络/凭据状态仍由安全边界提供。

6. 批量任务 GUI

任务控制台只在批量或长任务出现。默认信息顺序:

  1. 需要用户决策的异常。
  2. 执行位置、沙箱等级、写入范围、网络/凭据状态。
  3. 已完成、运行、等待、阻塞、失败、跳过数量。
  4. token、耗时和并发预算。
  5. 阶段摘要。
  6. 可下钻 item 详情。

控制台禁止默认展示:

  • 多个 agent 聊天窗口。
  • 每个 worker 的完整日志。
  • 内部 lease、artifact store、work packet 等实现术语。
  • 模型推理过程。

7. 升级和范围收敛规则

情况默认动作
小任务且无风险不升级,结束时列未验证项
用户准备 PR建议一个 L1 reviewer;风险信号作为模型关注点,不自动增加 reviewer
验证失败且可分解先聚类,再决定是否队列化
多个 item 共享同一 contract串行或请求用户决策
两轮审查无新增有效问题建议停止或保留核心检查
token 接近预算暂停扩大并发或跳过低价值审查
缺少 oracle不扩大 workflow,输出人工验收建议

8. 实现顺序约束

  1. 先保证普通任务摘要和未验证项稳定。
  2. 再把 DeepReview 投影为 Review 的严格档,并把 /DeepReview 处理为迁移窗口内的历史兼容输入。
  3. 再给长任务补轻量后台任务条和预算提示。
  4. 只对 CI/测试失败和 PR comments 这类明确场景做队列化。
  5. 大规模迁移/审计必须等样本 gate、预算确认和冲突处理稳定后再做。

9. 验证重点

验证目的
低风险任务不显示 workflow UI防止默认体验变重
本地显式 L1 审查保持用户给定的目标范围防止静默扩大审查
PR/团队审查不进入 P0 默认路径保持既有阶段边界
显式 L3 前有成本说明防止 token 无感知上涨
CI 多失败能只收敛已完成部分提升解决率而不是追求全量完成
大迁移样本失败不会扩大执行控制大规模自动化风险
安全确认不能被 review 或预算确认替代保持安全边界独立

10. 指标约束

本文不新增正式指标。workflow 方向只能作为指标保护 lens 使用:

  • 首个有用结果时间优先映射既有速度指标。
  • 用户打断率和弹窗触发率继续保护默认体验。
  • 成本预期偏差、任务解决率和审查有效问题率必须先补齐 metrics spec 口径。
  • 需要新事件时,必须先进入 QDP 事件注册表;review feedback 稳定前,审查有效问题率不能作为 P0 默认门禁。

队列吞吐、工作流回退率、后续返工率和维护 churn 只在 P3/P4 或真实批量场景稳定后启用。