Workflow 编排¶

为什么需要 Workflow Plane¶

企业任务通常不是单轮问答，而是有状态、有审批、有失败恢复的流程。

例如“员工入职办理”不是一句 prompt：

收集候选人和岗位信息。
检查 offer 审批状态。
生成入职清单。
创建账号申请工单。
分配设备和座位。
通知 HRBP、行政、直属主管。
跟踪未完成事项。

这些步骤应该显式编排。

工作流基本结构¶

Workflow
  - trigger
  - input_schema
  - steps
  - policy_checks
  - human_approval_points
  - retry_strategy
  - output_schema
  - eval_cases

示例：研发 Issue 到 PR¶

sequenceDiagram
    participant U as User
    participant H as Harness
    participant C as Codex Adapter
    participant T as RD Tools
    participant R as Reviewer

    U->>H: 提交 issue 链接
    H->>T: 读取 issue、代码库、CI 状态
    H->>C: 创建代码修改任务
    C->>T: 检索代码、编辑文件、运行测试
    C-->>H: 返回 diff 和测试结果
    H->>R: 请求人工 review
    R-->>H: 批准或退回
    H->>T: 创建 PR

示例：报销预审¶

输入：报销单、发票、申请人、费用类型
步骤：
  1. 读取发票信息。
  2. 查询费用制度。
  3. 检查金额、日期、类别和预算。
  4. 生成预审意见。
  5. 高风险或不确定项交给财务人工确认。
输出：通过 / 驳回 / 需补充材料 / 需人工复核

示例：市场资料到内容包¶

输入：产品资料、客户画像、活动目标、参考素材
步骤：
  1. 读取文件空间中的资料。
  2. 检索历史营销素材和成功案例。
  3. 生成多个选题方向。
  4. 市场人员选择方向并补充约束。
  5. 生成内容包：标题、正文、海报文案、短视频脚本、销售话术。
  6. 推送审批或协作修改。
输出：可编辑内容包、素材清单、审批记录

示例：员工请求到工单/审批¶

输入：员工在网页端或企业微信中发起的自然语言请求
步骤：
  1. 判断请求类型。
  2. 补齐必要表单和文件。
  3. 查询制度、权限和历史案例。
  4. 生成办理清单。
  5. 创建工单或审批。
  6. 通知相关人员。
  7. 跟踪状态并归档。
输出：工单/审批编号、办理状态、后续提醒

设计原则¶

任务状态显式存储。
每个步骤可重试。
人工确认点明确。
失败原因可解释。
重要输出结构化。
不把流程只写在 prompt 中。
每个成功 workflow 都要沉淀为模板、培训材料和 eval case。
每个 workflow 都要区分人与 agent 的输入、agent 与 agent 的协作、以及最终业务系统动作。