Agent Loop 适合下一步取决于新发现的开放任务。但代码审查、迁移或发布检查常有固定流程：并行检查多个维度，验证发现，合并结果，再输出统一结构。若顺序只存在聊天历史里，失败后很难继续。
Workflow 把固定编排写成宿主保存的可信脚本。模型只选择名称、参数和可选续跑 ID，不能提交任意可执行代码。
Workflow(name, args) → 可信 registry → parallel/pipeline/agent → journal → 结果为什么编排不只靠模型逐轮决定
开放探索需要模型调整路径；固定流程更需要并行、稳定结果结构、中断续跑，以及独立于对话的进度。Workflow 不取代 Agent，而是把多个 Agent 调用放进确定性的宿主控制流。
Registry 是信任边界
模型 schema 只接受 name、args 和 resume_from_run_id。元数据与函数来自宿主 WORKFLOWS registry，并在启动前校验。安全 slug、描述和 phases 都不是模型临时构造。
这防止“运行 workflow”退化成“提交任意代码”。但 Workflow 脚本仍是高权限宿主代码，需要代码审查与版本管理。
课程中的 Workflow Agent 只看到 args 传入内容，没有文件或 Shell 工具；默认并发上限为 8，每次运行最多 1000 次 Agent 调用，JSON Schema 校验器也只实现了教学所需的部分类型。
核心编排原语
| 原语 | 作用 |
|---|---|
agent() | 子 Agent 调用，可要求结构化输出 |
parallel() | 并行启动并等待全部结果 |
pipeline() | 每个 item 独立通过多个 stage |
phase() / log() | 记录阶段和进度 |
下一步依赖上一阶段全部结果时用 parallel 屏障；每个 item 可独立流过步骤时用 pipeline。
结构化输出也必须校验
agent(schema=...) 要求 JSON，并由运行时解析验证。第一次不合法可提示重试一次，再失败则明确终止。模型输出与工具参数一样不可信，不能直接交给下游代码。
Journal 让运行可续
每次运行保存快照、输出、 JSONL journal 和锁。agent() 完成立即记录结果；恢复同一 run 时脚本重跑，但命中 journal 的稳定调用直接返回缓存。
调用键不能依赖并发完成顺序。课程根据调用类型、标签、prompt 和 schema 计算稳定哈希，避免 parallel 或 pipeline 调度变化让缓存错位。
恢复前要验证名称、参数、快照和 journal，并用 run lock 防止两个进程同时续跑。调用内容变化时，相关步骤应重新执行。
适配器会等待整次 Workflow 结束后才让这次工具调用返回。事件名 async_launched 描述生命周期，不表示 Workflow 已脱离宿主工具调用在后台运行。
中间结果不要全部塞回对话
Workflow 内部变量和 journal 保存中间结果，主 Agent 只接收启动信息、最终结果和任务状态。这样避免多 Agent 输出填满 messages，同时保留审计和恢复线索。
建议覆盖的测试
- 未注册或元数据无效的 workflow 启动前拒绝；
parallel与pipeline语义稳定；- 不合 schema 的输出会重试并失败；
- journal 每步落盘，恢复正确命中缓存；
- 稳定 key 不依赖并发顺序；
- 同一 run 不能并发恢复；
- 进度与最终事件包含 run ID。
小结
Workflow Runtime 把“单步由模型决定”和“流程由代码保证”分层。可信注册表限定脚本，编排原语组织并行，schema 稳定数据，journal 与锁提供恢复。它适合重复且结构固定的流程，不替代开放探索。