Workflow 编排

为什么需要 Workflow Plane

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

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

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

这些步骤应该显式编排。

工作流基本结构

text 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

示例：报销预审

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

示例：市场资料到内容包

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

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

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

设计原则

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