流程模版是否支持循环与条件控制流？

[keting]

背景

当前流程模版只能描述静态 DAG：一组任务、每个任务的 assignee、depends_on 和 expected_output。用户在创建项目时选择模版，系统把模版一次性展开为 final plan 和 tasks。

但有一类常见协作流程更像运行时循环，例如：

agent1 干活；
while (true) {
  agent2 评审；
  if (agent2 评审结果为“通过”）结束流程；
  else agent1 根据 agent2 的评审意见修改；
}

也就是：实现 -> 评审 -> 如果不通过则修改 -> 再评审，直到通过。

问题

目前流程模版不支持这种结构。需要讨论：

1. HALF 是否应该增加流程模版中的循环 / 条件控制流？
2. 当前架构能否支持这种流程？
3. 如果要支持，应该先做哪种最小可行形态？

当前架构判断

现有架构不能直接支持真正的 while/if 流程，主要原因：

• 模版校验要求 tasks 形成 DAG，后端会拒绝循环依赖。
• 应用模版时会一次性 finalize，并创建所有 Task；任务集合不是运行时动态展开的。
• Task 只有静态 depends_on，没有条件边、循环计数、控制流节点或 workflow run 状态。
• 任务完成目前只以 result.json 是否存在作为完成哨兵，不解析评审结果里的业务字段来自动决定下一步。
• UI 的 Plan/DAG/Tasks 页面也按静态任务图展示，没有条件分支或循环组的表达。

因此当前只能表达固定轮数的流程，例如：

实现 -> 评审1 -> 修改1 -> 评审2 -> 修改2 -> 评审3

但不能表达“评审不通过就继续追加下一轮修改和评审”。

可选方案

方案 A：固定展开 N 轮

在现有 DAG 模型内，把循环预展开成有限轮数。

优点：实现成本最低，现有架构可直接支持。

缺点：不是真正的循环；如果第一轮通过，后续任务仍然存在，需要人工放弃或不派发。

方案 B：结构化评审结果 + 人工决策门

约定评审任务 result.json 输出类似：

{
  "task_code": "REVIEW-001",
  "summary": "评审完成",
  "decision": "approved",
  "review_comments": []
}

系统展示 decision，由负责人点击“结束流程”或“创建下一轮修改任务”。

优点：符合 HALF human-in-the-loop 定位，不需要一步到位做全自动工作流引擎。

缺点：需要新增 result schema、UI 展示、以及从评审结果创建下一轮任务的机制。

方案 C：真正的 workflow engine

引入新的 workflow template / workflow run 模型，支持 task node、condition node、loop edge、max_iterations 等。

优点：表达能力完整。

缺点：改动大，会影响数据模型、状态机、任务码生成、输出目录、审计、UI 和现有 plan/task 关系。它已经超出当前静态流程模版的能力边界。

初步建议

不建议直接在当前流程模版 JSON 里增加 while/if 语法。

更稳妥的路径可能是：

1. 短期先文档化固定轮数 DAG 的 workaround。
2. 中期支持“结构化评审结果 + 人工决策门”。
3. 长期如果需求稳定，再设计独立的 workflow template / workflow run，而不是继续扩展当前 DAG template。

需要讨论

• 是否接受“循环必须 bounded”，例如必须设置 max_iterations？
• 评审结果是否需要统一 schema：approved / changes_requested / rejected？
• 条件判断应自动执行，还是只辅助负责人做人工决策？
• 动态追加任务时，任务码和输出目录如何命名？
• 通过后，未执行的预展开任务应该自动 abandoned，还是由负责人处理？
• DAG 视图应展示模板级循环，还是展示运行时已展开的实际任务图？