工作流引擎
龙山灵码的工作流引擎用于把多智能体任务写成可恢复、可记录、可重复执行的工程流程。
它解决什么问题
当任务开始同时涉及下面几件事时，工作流会比单轮对话更合适：
- 要分阶段推进
- 要派发多个子智能体
- 要记录中间结果
- 要在失败或中断后恢复
- 要把一个流程多次重复执行
这时，工作流引擎可以把“先做什么、并行做什么、什么时候收敛结果”写成明确结构。
与 compose、goal、subagent 的关系
| 能力 | 更适合解决什么问题 |
|---|---|
compose | 让主智能体按结构化方式组织复杂任务 |
goal | 让任务在停止前持续检查目标是否满足 |
| subagent | 让局部任务由独立角色执行 |
| workflow | 让整个多阶段过程变成可脚本化、可恢复的流程 |
可以把 workflow 理解成更显式、更可复用的编排层。
运行模型
工作流脚本运行在受限环境中，通过显式 host 函数组织任务：
| 函数 | 作用 |
|---|---|
agent(prompt, opts?) | 派生子智能体执行一步任务 |
parallel(thunks) | 并行执行多个任务 |
pipeline(items, ...stages) | 按阶段处理一批对象 |
phase(title) | 标记当前阶段 |
log(message) | 写入运行日志 |
workflow(name, args?) | 调用内置或已保存的工作流 |
这类脚本不能随意访问宿主环境的全部能力，目的是让工作流执行边界更清晰、更容易恢复。
Journal 与恢复
工作流引擎会记录运行过程，而不是把一次执行当成不可回放的瞬时动作。
典型持久化内容包括：
- 当前 phase
- 关键日志
- 子智能体结果
- 错误信息
- 脚本内容和运行标识
这使得工作流在中断后更容易恢复，也便于判断是“继续执行”还是“从头重跑”。
内置工作流
当前主线已经内置 deep-research 这类多阶段工作流。它适合把搜索、抽取、归类、交叉核验和报告组织成一条稳定流程，而不是全部塞进同一轮上下文里。
工作流的价值在于把阶段、并行、日志、恢复和结果回收写成明确结构。
什么时候应该用 workflow
下面这些情况通常值得从普通会话切换到 workflow：
- 一个任务会被多次重复执行
- 需要把调查、实现、评审、验证拆成明确阶段
- 需要同时调度多个子智能体
- 需要保存中间结果并允许恢复
如果任务只是一次性的小修小补，直接使用主智能体或 compose 往往更轻。