工作流 on 姚玉亮的网络日志

高低模型分工：用最少的 token 做最难的任务

Sun, 30 Aug 2026 18:00:00 +0800

我最初的做法：高模型出计划，低模型执行

在炼丹炉（Alchemy Furnace，我的开源项目）上开发大功能时，我的模型分工一开始是这样的：高模型出计划，低模型去试执行。逻辑听起来无懈可击：计划是最费脑子的活，给最强模型；执行是照着做，给便宜模型省 token。

跑了几轮之后我意识到，这不是最佳实践：省下的 token 在别的地方加倍还了回去。坑在哪、后来怎么分，一条条说。

三个坑：为什么"计划高、执行低"不够

坑一：计划里的任务难度不均。

一个实施计划拆出来的任务，难度天差地别。同一个计划里，既有"写一个纯函数渲染器"这种机械活，也有"设计 SSRF 校验 + 提供者熔断 + 证据等级判定"这种高难活。一刀切全丢给低模型，难任务在低模型手里反复试错，每次失败都是一轮"试错 + 看错误 + 再试"，token 没省多少，时间翻倍，最后往往还是得升级。

坑二：低模型失败没有出口。

低模型试了，失败了，然后呢？如果升级路径不存在，低模型只有两个选项：硬编一个成功（最危险，测试都可能一起编出来），或者卡死空转。我早期踩过前者，代价是返工整个文件。

坑三：验证被一起降级了。

执行降级了，自测也跟着降级：低模型自己测自己，绿灯也不能全信。判断性工作（“这样测算不算数”）和机械性工作（“跑一遍测试”）不是一回事，不能一起降级。

模型分级的问题不在"分级"本身，而在分级的依据：按角色分（计划/执行）是错的，按难度分（任务）才对。

正确框架：按难度分级 + 三个旋钮

Claude Code 的 Workflow 里每个子 Agent 可以独立指定模型档位和努力度，这就是三个旋钮：

旋钮一：模型档位。高（Opus）/ 中（Sonnet）/ 低（Haiku）。

旋钮二：努力度（effort）。从 low 到 max。很多任务根本不用换模型：同一个模型把 reasoning 预算拧低，就是廉价版本。换模型是换"能力上限"，调 effort 是调"用力程度"，两回事。

旋钮三：任务边界清晰度。这是最便宜的杠杆：spec 拆得越细、验收标准写得越死，任务越接近"机械执行"，能用的模型档位就越低。

我的任务分配表：

难度	模型	例子
判断型	高模型 + 高 effort	需求探索与脑暴、接口契约设计、代码评审、根因定位、安全核对
常规型	中模型 + 中 effort	常规功能实现、测试编写、中等重构、普通调试
机械型	低模型 + low effort	模板化改动、纯函数实现、i18n 文案、跑测试与验证

用最少的 token 做最难的任务

说白了就一条：把大部分任务变简单，让高模型 token 只花在"决定"上，不花在"执行"上。

几个真实管用的杠杆：

计划是高模型性价比最高的投资。计划阶段多花的高模型 token，换来的是执行阶段任务边界清晰、可降级给便宜模型。这是"1 单位的贵，换 100 单位的省"。不是精确数字，是量级感受。
低模型任务必须满足三个条件，缺一不可：

边界明确：任务描述到文件级，依赖关系写清
测试兜底：TDD 红→绿，失败能被测试抓住
终止条件：做不了就停，明确写"连续失败就停止报告，不许编成功"

第三条最重要。我在炼丹炉的 Workflow 脚本里给每个子 Agent 都注入了终止条件段（A3：文件不存在、依赖无法确认、连续 3 次修复失败，立即停止报告）。允许低模型说"我卡住了"，比让它硬编一个成功安全一个量级。

升级路径要显式。低模型失败不是终点：带着"红测试 + 尝试过程 + 卡点描述"升级给高模型。高模型拿到的是完整上下文，一次到位给解法或改计划，而不是重新摸底。
评审和验证分开降级。跑回归（机械）可以低模型；安全核对、代码评审（判断）留给高模型。炼丹炉的验收任务里，回归和"ZIP 解压检查有没有泄露 key"是两件事：前者低模型跑，后者高模型过。

炼丹炉实例：一个计划怎么分

以女娲蒸馏 + Skill 导出的开发为例（6 个任务、4 个波次）：

计划本身（文件级任务清单）：高模型出。这是唯一一个"必须先花"的成本。
Task3 Skill 渲染器：纯函数、格式明确（slug 规则、SKILL.md 结构、ZIP 命名全写死）、测试完备，典型的机械型任务，低模型 + low effort 就能扛。
Task2 Python 蒸馏链路：SSRF 校验、来源熔断、证据等级判定，属于判断与工程混合，配中模型 + 中高 effort，比低模型反复试错便宜得多。
Task6 端到端验收：回归跑测低模型，产物安全核对（解压查 sk-、token、内部日志）高模型。
A3 终止条件：给每个"低模型试"的任务一个明确出口，试不动就停，升级。

收尾

用下来我的感觉是：判断性的活给最贵的模型，机械的活给最便宜的；任务写得清就可以降档，失败超过两次就升级，别耗着。

模型分级省的不是高模型的钱，是浪费在错模型上的钱。最难的活依然要最贵的模型，但反过来也成立：大部分活之所以难，是因为你没把它写清楚。把任务写清楚，是高模型 token 花得最值的地方。

封面图：Krzysztof Golik / Wikimedia Commons · CC BY-SA 4.0

Claude Code 的 Workflow 功能：6 任务分 4 波，多 Agent 并行开发三端功能

Thu, 27 Aug 2026 22:30:00 +0800

一个 141 行的脚本，指挥一群 AI 干活

炼丹炉（Alchemy Furnace，我的开源项目）最近在做一个大功能：女娲蒸馏的范围收紧 + Skill 导出。它横跨三个端（Next.js 前端、Go 网关、Python 引擎），拆出来 6 个开发任务，有依赖、有先后、还要并行。

我用的方案是 Claude Code 的 Workflow 功能：写一个 141 行的 mjs 脚本，把 6 个任务分成 4 个波次，每波派多个 AI Agent 并行干活。脚本开头长这样：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


export const meta = {
 name: 'nuwa-scope-skill-export',
 description: '按计划实现女娲炼丹范围收紧 + Skill 导出（6 Task 分波并行）',
 phases: [
 { title: 'Wave A: 并行底座', detail: 'Task1 前端入口 + Task2 Python 链路 + Task3 Skill 渲染器' },
 { title: 'Wave B: 服务端接合', detail: 'Task2b Go/前端错误透传 + Task4 导出接口' },
 { title: 'Wave C: 前端导出 UI', detail: 'Task5 详情导出对话框' },
 { title: 'Wave D: 端到端验收', detail: 'Task6 全量回归与修复' },
 ],
}

Workflow 的编排原语就几个：agent() 派一个 Agent 做一件事，parallel() 并行跑一组，pipeline() 流水线，phase() 分阶段。流程是确定性的（脚本写死的），干活是并行的（agent 同时跑）：确定性编排 + 并行吞吐，这就是 Workflow 和"让 AI 自由发挥"最大的区别。

分波设计：依赖关系决定顺序

6 个任务不是一把梭全并行，它们之间有依赖。分波的核心原则：同一波内的任务互不依赖且文件隔离，波与波之间靠产物衔接。

Wave A 三个任务互不依赖：前端改入口、Python 改链路、Python 写渲染器，改动文件完全不重叠，并行跑。Wave B 接合服务端：错误透传要读 Task2 的产物（Python 结构化错误），导出接口要调 Task3 的渲染器，等 A 波完成再动。C、D 依此类推。

多 Agent 协调的六个细节

分波只是骨架，真正让 6 个 Agent 不打架的是这些细节：

COMMON 纪律注入。每个 Agent 的 prompt 都是 COMMON + TASK + 终止条件 三段拼起来的。COMMON 里写死硬约束：TDD 先红后绿、只改自己任务列出的文件、提交格式 type(scope): 中文描述、绝不 git add -A、绝不提交 docs/superpowers/ 和 specs/ 等元文档、i18n 必须中英双语、测试命令、凭据保密。纪律写进 prompt 而不是靠自觉，6 个 Agent 才不会互相污染。
文件隔离 + 以磁盘为准。每个任务只允许碰自己的文件，但并发任务可能改到同一文件，所以约束里有一条：“编辑前先 Read 磁盘最新内容，不要基于记忆”。并行和踩脚之间的平衡，靠这条纪律兜底。
依赖确认靠 git log。Wave B/C 的任务 prompt 里写着：“先 git log 确认依赖任务已完成，并读它的接口签名再动手”。Agent 之间不通信，通过提交记录对齐。
终止条件。每个任务都附一段 A3：文件不存在或结构差异巨大、关键依赖无法确认、测试连续 3 次修复失败，立即停止并报告，不许硬撑。这防止 Agent 在不确定的情况下编造"成功"。
TDD 是硬约束。每个任务第一步都是"写失败测试 → 跑红 → 最小实现 → 跑绿"。6 个 Agent 并行写代码，质量一致性靠测试框架兜底。
进度可视化。每波完成打一条 log()：task1=ok task2=FAILED，失败的任务肉眼可见，可以在下一波前人工干预。

三端是怎么被协调的

这个功能本身横跨三端，Workflow 的波次刚好和端的分工对齐：

端	技术栈	对应的任务
前端	Next.js	Task1 收紧女娲入口、Task5 导出对话框
Go 网关	Gin + GORM	Task2b 错误透传、Task4 导出接口
Python 引擎	FastAPI	Task2 蒸馏链路、Task3 Skill 渲染器

有意思的是 Python 端同时有 Task2 和 Task3 两个并行 Agent：它们文件不同（链路 vs 渲染器）所以不冲突，但同端并行也要求 prompt 里把边界写得特别清楚：“不要碰 backend/go/ 与 frontend/ 的 UI 文件——那些由另一任务负责”。

复盘：Workflow 教给我的

复杂功能先拆波再并行，依赖决定顺序。先画出任务依赖图，互不依赖的并行，有依赖的排波次。比"一个 Agent 从头做到尾"快得多，比"全并行"稳得多。
纪律要写进 prompt，不是靠提醒。提交纪律、文件边界、TDD、终止条件，每一条都防止一种 Agent 翻车方式。
终止条件比任务本身重要。允许 Agent 说"我卡住了"，比让它硬编一个成功报告安全一个量级。
上下文隔离是并行的前提。每个 Agent 只拿自己的任务片段，看不到其他任务的 prompt：专注 + 不越界。

这个脚本不是银弹：它适合任务边界清晰、文件可隔离、有测试兜底的场景。如果任务互相纠缠，先拆任务再谈并行。项目、计划文档和完整脚本都在 GitHub 上，Wave A 的并行底座写法可以直接抄。

封面图：richard_clyborne / Flickr · CC BY 2.0

复杂任务的快速实现：我的 Claude Code 工作流

Thu, 27 Aug 2026 21:00:00 +0800

复杂任务为什么难

先说结论：复杂任务难的不是写代码，是下面四件事。

需求模糊：说需求的人自己都没想清楚。“文档核验要留痕”，留什么痕？按什么查？入口放哪？全要靠推。
代码陌生：改的不是自己写的代码库，路由注册在哪、DAO 怎么组织、有没有现成的组件，一无所知。
链路长：一个需求横跨后端服务、管理后台、上层服务三个仓库，联调对不上是常态。
步骤多：建表、写记录、加接口、做页面、上层同步，十几步里漏掉任何一步，都要返工。

过去我处理复杂任务靠"经验 + 加班"：经验让我少踩坑，加班补上流程损耗。现在我用 Claude Code 的 workflow 跑，发现上面四类复杂度可以分别拆掉。

一、需求模糊？先探索，再一次一个问题

需求模糊是复杂任务的第一个坑，也是最贵的坑：设计错了，后面全白做。

我的做法是两段式：先让 AI 探索代码，再让它一次只问一个问题。

拿最近一个"核验记录"需求举例。AI 先翻了两个仓库，带回几个关键事实：文档表上已经有"核验状态"字段，核验逻辑集中在文档服务的一个方法里，前端代码里已经有现成的下拉加载 hook。这些事实直接改变了设计：记录表和状态字段是两回事，但很多人第一版会把它们混在一起。

然后进入提问环节，一次一个问题：

我：核验记录存哪些字段？ AI：除了核验人和核验时间，要不要存版本号？这决定表结构。我：先只存核验人和核验时间。 AI：好。那列表按数据集 ID 过滤、分页返回，对吗？

每个答案都在修正下一个问题。一次抛十个问题，AI 只能靠猜排优先级，猜错一半就得返工。模糊需求最怕的不是问得少，而是问得乱。

二、代码陌生？子代理并行探索

复杂任务往往意味着大型代码库。让主会话把每个文件都读一遍，上下文直接爆炸；不让它读，问的问题全是空对空。

我用子代理解决：只读的探索型子代理，各自负责一个方向，跑完只把结论带回来。

还是那个需求。两个仓库，我开了两个子代理并行：

一个查后端：核验逻辑在哪个方法里？用什么 ORM？表结构长什么样？
一个查前端：数据管理页面结构？有没有现成的分页/下拉加载组件？

主会话的上下文只收到两条结论，干净利落。复杂任务拆给子代理，等于给主会话外挂了好几个只读大脑。

三、步骤多？用 spec 锚定，用计划兜底

十几步的任务，光靠"记住"一定会漏。我的流程里有两个强制环节：

第一步，设计获批后写 spec 文档。表结构、接口定义、前端改动点、上层同步点全部落盘。这份文档是后续所有工作的锚点：代码评审不再对着记忆逐条想，而是对着 spec 逐条核对。

第二步，用计划技能把设计翻译成有序任务。先改什么、后改什么、每个任务做完怎么验证，都拆成文件级清单。执行阶段照着走，不会顾此失彼。

复杂任务最怕的不是步子慢，而是做完了发现做的是另一个需求。spec 就是防这件事的。

四、链路长？add-dir 多项目，一个会话挂三个仓库

跨仓库任务的真正成本不在写代码，在于两边对不上：前端叫 page 后端叫 current，接口路径差一个斜杠，联调半天。

Claude Code 的 add-dir 可以把多个项目目录加进同一个会话，三个仓库的上下文同时可见。字段名、接口路径、分页参数在计划阶段就定死，代码照着写就行，联调成本趋近于零。

以前这种需求：拉群 → 各自开工 → 联调发现对不上 → 返工。现在：一个会话、一份 spec、三份代码同时改。

五、改错返工？hooks 门禁 + 验证闭环

复杂任务最容易在最后一步翻车：改完了、自测过了，忘了检查脱敏、忘了跑构建、忘了验证线上。

我的解法是 hooks：把检查前置到事件本身。比如写文件前必须声明事实（这个文件被谁引用、里面有没有敏感内容），执行破坏性命令前必须给出回滚方案。检查不是"记得就做"，而是流程的必经环节，不做就卡住。

收尾阶段再加一道验证：构建无错误、线上返回 200、关键内容比对通过，才算完成。质量不是最后检查出来的，是流程逼出来的。

我的工作流时间线

一个复杂任务在我这里是这样的节奏（示意）：

flowchart LR
 T1["探索 + 脑暴"] --> T2["方案 + spec"] --> T3["实施计划"] --> T4["执行三仓"] --> T5["评审 · 验证 · 部署"]

环节	干什么	用时
探索 + 脑暴	读代码、一次一个问题澄清需求	一个上午
方案 + spec	2-3 个方案对比，获批后落盘设计文档	半小时
实施计划	设计翻译成文件级任务清单	十分钟
执行	按清单改三个仓库	主工作量
评审 + 验证 + 部署	对着 spec 评审，构建、线上验证	收尾

对比以前的节奏：需求评审会一轮、文档两轮、联调两轮、返工一轮，光流程损耗就吃掉一半时间。

收尾

复杂任务的复杂度分布大概是这样：需求 > 链路 > 步骤 > 代码。Claude Code 的 workflow 没有任何魔法，它只是把"该问的、该查的、该记的、该验的"变成了流程的默认动作，让 AI 和人的精力都集中在真正难的地方。

真正快的不是写代码那一下，而是不返工。

封面图：jurvetson / Flickr · CC BY 2.0

一次聊需求，三仓同落地：我的 superpowers 全栈开发工作流

Thu, 27 Aug 2026 09:00:00 +0800

一个跨三个仓库的需求

我最近接到一个挺典型的需求：数据集管理里，“文档核验"这个动作要留痕：谁核验的、什么时候核验的；核验完还要能按数据集分页翻历史记录；管理后台加一个"核验记录"入口，点击弹列表，下拉就能一直加载；上层的知识库问答服务也要同步暴露这个列表接口。

这个需求横跨三个仓库：数据集管理服务、数据管理后台、知识库问答服务。

以前这种需求在我这儿是这么过的：拉群对齐需求 → 各写各的需求文档 → 前后端各自开工 → 联调时发现字段名对不上、分页参数叫法不一样 → 返工。现在我用 Claude Code 的 superpowers 工作流走了一遍完整流程，发现整个链条可以压缩成四步：brainstorming 聊需求 → 方案对比 → 写 spec → 生成实施计划。

flowchart LR
 A["brainstorming 聊需求"] --> B["方案对比"] --> C["写 spec 落盘"] --> D["生成实施计划"] --> E["add-dir 挂三仓并行落地"]

第一步：先探索代码，再开口问

superpowers 的 brainstorming 第一步不是问"你想要什么”，而是先看项目上下文：路由注册在哪、handler 怎么写的、DAO 用的什么 ORM、前端页面结构、有没有现成的分页组件。

我让 Claude 把两个仓库都翻了一遍，结论：

数据集管理服务是 Hertz + GORM 的架构，核验逻辑在文档服务的 revise 方法里，文档表上已经有一个"核验状态"字段，核验时会把它置为"已核验"
管理后台是 React + antd，代码里已经有现成的 useInfiniteScroll 下拉加载 hook，数据详情页结构也很清晰

这一步的价值在于：问题基于真实代码，而不是基于想象。我不用花十分钟给 Claude 讲架构，它自己读出来的上下文，比任何人的转述都准确。比如"核验状态字段已经存在"这个事实，直接影响了后面的设计：记录表和状态字段是两回事，但很多人第一版设计会混在一起。

第二步：一次只问一个问题

brainstorming 最反直觉的一条规则是：一次只问一个问题。

我一开始也觉得慢。但跑下来发现，需求是逐层展开的：先问"核验记录需要存哪些字段"，确定存核验人和核验时间；再问"列表按什么过滤"，确定按数据集 ID；再问"前端入口放在哪"，确定放数据详情页。每个答案都会修正下一个问题，一次抛十个问题，模型只能靠猜排优先级，猜错一半就得返工。

对话节奏大概是这样的（简化示意，实际要比这细致）：

我：核验记录需要展示哪些字段？ Claude：先确认一下，除了核验人和核验时间，要不要把核验前后的版本号也存下来？这会决定表结构。我：先只存核验人和核验时间，跑通第一版。 Claude：好。那列表接口按数据集 ID 过滤、支持分页返回，这个方向对吗？

一次一个问题看着慢，其实最快：每个问题都建立在之前答案的基础上，方向不会歪。

第三步：给 2-3 个方案，而不是直接开写

需求聊清楚之后，brainstorming 会要求给出 2-3 个实现方案对比。这个需求当时有两个主流方案：

方案 A：复用现有的行为记录表。那张表是 JSON 半结构化的流水表，加一种行为类型就能记录，不用建新表。
方案 B：新建独立的核验记录表。字段干净，查询直接，列表接口就是一条简单的 WHERE dataset_id = ? 分页查询。

我选了 B。核验记录是高频查询的业务动作，独立表让列表接口简单直接；方案 A 虽然少建一张表，但查列表要拆 JSON，而且行为流水表的数据量会持续膨胀，不适合做业务查询的底座。

选完方案，设计按块确认：表结构一块、接口定义一块、前端改动一块、上层同步一块，确认完再写进 spec 文档，落盘到 docs/superpowers/specs/ 目录下。这份文档是后续实施计划的输入，也是代码评审时对照的依据：评审不再靠记忆，而是对着 spec 逐条核对。

第四步：add-dir 多项目，前后端同时动

设计获批后进入实施阶段。Claude Code 的 add-dir 可以把多个项目目录加进同一个会话，这个需求一次挂了三个目录：

数据集管理服务：建表、在核验接口里写记录、新增分页列表接口
管理后台：数据详情页加入口、列表抽屉、下拉加载
知识库问答服务：同步暴露列表接口

多目录的意义不只是"能改多个仓库"，而是 AI 同时持有两边的上下文：字段名、接口路径、分页参数天然一致，联调成本趋近于零。以前前后端联调要查半天"到底叫 page 还是 current"，现在在计划阶段就把契约定死了，代码照着写就行。

几个真实的感受

一次一个问题反直觉，但确实是最快的提问方式。需求是逐层展开的，一次一个才能保证每个问题都有价值。
探索比提问重要。让 AI 先读代码，它问出来的问题才有质量；不探索就问，问的都是网上搜得到的通用问题。
设计文档不是走流程。跨仓库改动里，它是唯一让所有人（包括几周后的你自己）对齐的锚点。代码评审对着 spec 审，比对着记忆审靠谱一个量级。
YAGNI。AI 很容易过度设计，比如顺手提一句"要不要顺便做个操作审计"。不需要，砍掉。每个设计阶段都要主动问：这个功能现在真的需要吗？

建议

如果你也在用 AI 写代码，别只停留在"让它写函数"的层面。试试把流程也交给它：从一个小需求开始，完整走一遍 brainstorming → 方案对比 → spec → 计划 → 实现。第一次会不习惯"一次只问一个问题"，但跑完一个需求你就会发现，多花在澄清上的半小时，会在联调阶段加倍省回来。

智能体工作流编排：从知识库问答到多步任务

Tue, 02 Jun 2026 10:30:00 +0800

单轮 RAG 接不住了

知识库问答服务上线初期只有一条链路：用户提问 → 检索 → 拼 Prompt → 调 LLM → 返回答案。简单可控，但很快被顶到了天花板。

有人问"帮我查一下上个月引用量最高的三篇文献，对比它们的方法，再导出成 Word"。这一句话里藏着检索、排序、对比分析、文档生成四步，单轮 RAG 根本接不住。

我当时的判断是两头都不能走极端：全交给 ReAct 让模型自由发挥，可控性和成本都扛不住；全硬编码成固定 DAG，又失去了灵活性。最后落在一个折中上：工作流骨架 + Agent 节点。

一张图，两类节点

我把任务拆成两类节点：

确定性节点：检索、SQL 查询、文件解析、导出，这些用代码写死，输入输出明确
Agent 节点：需要推理、选择、总结的环节，交给 LLM 决定下一步

节点之间用有向图描述，允许条件分支和循环，运行时由一个轻量编排器驱动。每一步的状态写进统一的 WorkflowState，节点之间不直接耦合。

核心结构就这么多：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45


type WorkflowState struct {
 Query string
 Documents []Document
 Draft string
 Artifact string
 Trace []StepRecord
 mu sync.Mutex
}

type Node interface {
 Name() string
 Run(ctx context.Context, st *WorkflowState) error
}

type Orchestrator struct {
 nodes map[string]Node
 edges map[string][]Edge // from -> edges
}

type Edge struct {
 To string
 Cond func(st *WorkflowState) bool // nil 表示无条件
}

func (o *Orchestrator) Run(ctx context.Context, start string, st *WorkflowState) error {
 queue := []string{start}
 visited := map[string]int{}
 for len(queue) > 0 {
 name := queue[0]
 queue = queue[1:]
 if visited[name] >= 5 { // 防止死循环
 return fmt.Errorf("node %s exceeded max retries", name)
 }
 visited[name]++
 if err := o.nodes[name].Run(ctx, st); err != nil {
 return err
 }
 for _, e := range o.edges[name] {
 if e.Cond == nil || e.Cond(st) {
 queue = append(queue, e.To)
 }
 }
 }
 return nil
}

Agent 节点内部走 ReAct 循环：模型输出思考 + 工具调用，执行工具后把结果喂回去，直到给出最终答案或触发步数上限。工具调用走 MCP，上一篇讲过。拿"查文献→对比→导出"来说，检索和导出是确定性节点，中间的对比分析交给 Agent 节点。

四个坑

第一个坑，state 越攒越肥。一开始我们把所有中间结果都塞进 WorkflowState，跑到后面堆满文档全文和历史消息，token 直接爆炸。后来立了规矩：节点只输出下一阶段需要的最小字段，长文本进对象存储，state 里只留 ID 和摘要。

第二个坑，循环没有刹车。LLM 偶尔会陷入"反复检索但不给出答案"的死循环。现在每个节点有最大重试次数，整图有总步数和总 token 预算，超限直接中断，返回当前最优结果，而不是无限烧钱。

第三个坑，没有 trace 就是瞎子。多步工作流出问题，不查 trace 根本说不清哪一步偏了。我们在每个节点进入/退出时写结构化日志（节点名、输入摘要、输出摘要、耗时、token 数），用 trace_id 串起来，在 Jaeger 里能看完整的节点瀑布图。代码里的 StepRecord 就是干这个的。

第四个不算坑，算一条划边界的原则：流程稳定、容错要求高的（支付、对账、数据同步）用确定性 DAG，甚至上 Temporal；探索性、开放式的任务（调研、写作、分析）用 Agent 节点。两者可以混在一张图里，但关键路径上的不可恢复操作，别让 Agent 碰。

后来

回头看，从单轮 RAG 走到多步工作流，是把"模型一次想清楚"换成了"系统分步兜底"：确定性节点负责可靠，Agent 节点负责灵活，编排器把两者粘起来，顺便守住成本和循环上限。

下一步我们在试把常用工作流做成模板，让业务方自己拖拽配置，不用每次都找后端写代码。

封面图：ell brown / Flickr · CC BY 2.0