LAYER 05 · 从单 Agent 扩到协作系统
Workflow Engine 与持久 Schedule
模型编写短期编排脚本，Schedule 在未来把提醒作为普通 Follow-up 送回原 Session
worker-thread script + agent() fan-out + durable wakeupWorkflow、Job 与 Schedule 为什么不能合成一个“后台任务”概念？
先建立直觉
Workflow 是导演的分镜与现场调度，Job 是正在拍摄的机位状态，Schedule 是未来某个时间重新开机的通告。
MECHANISM
机制拆解
ctx.workflowEngine 每个 Context 只有一个实现；worker-thread 在隔离 vm 中运行模型脚本，提供 agent()、phase() 与 JSON args，拥有总 Agent 数与并发上限。
Schedule 只在同一 Session 内持久 after/at/every 记录；到期后排队普通 followup。重复调度固定速率、至少五分钟，错过区间只合并为最新一次到期。
第 1 步 / 共 6 步
提交脚本与 Meta
纯 JSON 身份与参数先通过 schema 校验。
INVARIANTS
无论怎么扩展，都不能破坏
- Workflow result promise 不拒绝，而以封闭 stopReason 结算
- dispose 在有界宽限期后强制终止卡死 worker
- Schedule 永不隐式读取环境时区
FAILURE MODES
最容易踩中的坑
- ×把脚本 meta 当可执行表达式解析
- ×重复 Schedule 枚举所有错过区间造成风暴
- ×把 dispatch 当成用户已收到回执
VERIFY IN SOURCE
不要相信结论，去源码里复核
以下链接固定到官方 deepseek-harness@47f9438；查看当前上游时请留意后续 breaking changes。
KNOWLEDGE CHECK
先停十秒，再揭晓答案
为什么 Schedule 的 at 字符串必须带 UTC 偏移？
为什么下一章紧接在这里
系统还需要发现外部能力：Skills、MCP、LSP 与 Web 都通过不同 seam 进入，而不是绕过工具管线。