工作流编排

这个 pack 装了什么

这个 pack 收齐了 AI 团队在「prompt 套循环」不够用之后会摸到的 8 个生产级工作流引擎。每个解决的都是同三件事 —— 调度 / 重试 / 观测 —— 但 ergonomics 不同。按你团队已经在的栈选（Python / Node / 无代码 / JVM）。

每个都开源可自托管。多数有 SaaS 托管层，但这个 pack 优先记开源装路径。

为什么 AI agent 需要编排

Prompt 第一次跑是确定的，之后每次都是抛硬币。再加个真实动作 —— 调 API、写库、发 Slack —— 「凌晨三点失败一次」就会变成每周固定节目。工作流引擎解决三件事：

1. 幂等。step 可安全重放。LLM 调用成功但后一步崩了，重试不会重复扣 API 钱
2. 回退 + 死信。失败 step 按指数退避重试，再不行落进 DLQ 让人看
3. 可观测。每个 step 记录输入、输出、延迟、成本。agent 出怪事时能精确回放它当时看到的上下文

没有这些，你的 agent 就是一个加了步骤的 Jupyter notebook。有这些它才是服务。

一条命令装齐

# 装整个 pack（8 个引擎的 manifest）
tokrepo install pack/workflow-orchestration

# 或装你团队在用的那个
tokrepo install n8n
tokrepo install prefect
tokrepo install inngest

TokRepo manifest 给你 Docker Compose / Helm 起步配置 + agent 友好默认值（幂等 key、重试策略、观测钩子）。卸载就 tokrepo uninstall <slug>。

常见踩坑

• 当重试是无限的。多数引擎默认重试 3–5 次。如果你的 LLM 服务商正赶上糟糕一小时，你会把预算烧光还是失败。付费 LLM 调用上限设 3 次，失败后路由到更慢的备用模型
• 幂等 key 设错。常见错误是用每次重试都变的 request_id。用输入 hash 当 key，重试才会针对同一逻辑任务去重
• 少了 token 成本观测。普通编排器记录延迟但不记 LLM token 花费。把模型调用包一层，每个 step 输出 tokens_in / tokens_out / cost_usd 指标，否则爆预算了你都不知道是哪个工作流干的
• 调度粒度选错。基于 cron 的引擎（n8n / Activepieces）拼不过亚分钟触发。要事件驱动亚秒响应，用 Inngest / Trigger.dev / Temporal
• 引擎跟 agent 同节点。野的 agent 会把编排器 OOM。引擎放独立节点或容器并设硬内存上限

这个 pack 单独不够时

工作流编排是 持久化 层。它不给你 agent 本身、LLM 网关或评测。配套：

• Python Agent Frameworks —— 真在 step 里跑的 agent 代码
• MCP Server Stack —— 要让 agent 通过 MCP 触发编排器
• LLM Eval & Guardrails —— 在每个工作流里加评测 step，再决定是否上线

四个 pack 一起，才是无人值守 AI 工作流的最小栈。