吴思扬1. 不是所有任务都适合扔给 AI：先理解"顺序"为什么成了瓶颈
先讲一个我最近的真实经历。团队里有个小伙伴用 Claude Code 处理一批文本清洗任务，需求很简单：先按规则拆分段落，再对每个段落做实体识别，最后把结果汇总成结构化 JSON。他当时为了省事，把整个流程写进一个巨大的 prompt，让模型"自己看着办"。结果模型确实照办了，但顺序完全乱了——先做了实体识别，再回头拆分段落，导致后面所有实体都挂在错误的上下文上，输出质量一塌糊涂。
这个问题不是偶发，而是当前大模型工作方式的必然结果。无论是 Claude、GPT 还是其他主流模型，本质上都是"下一步 Token 预测器"，它们擅长的是"根据上下文生成合理的下一步"，但天生不擅长"严格保证用户指令中被隐含的先后依赖关系"。你告诉它"先 A 再 B 再 C"，它大概率会照做；可一旦 A、B、C 之间还存在数据依赖、输出格式依赖、需要中间校验的环节，模型的短期注意力很容易丢失这种约束。尤其是任务一旦超过三五个步骤，或者每一步的输入都是上一步的产物时，纯靠 prompt 去约束执行顺序，基本等于赌运气。
很多人第一反应是：那我给 AI 写个 ToDo 清单总行了吧？比如：
- 读取输入文件
- 拆分段落
- 提取实体
- 汇总结果
看起来逻辑清晰，但问题在于：ToDo 清单只是向模型描述了一个愿望，模型并没有被"锁死"在每一步的边界里。 它可能在执行第 2 步时顺便做了第 3 步的判断，也可能在第 4 步突然觉得第 1 步的数据格式不对，擅自回头调整。模型的工具调用（tool use）本身也是流式的，Claude Code 这类 Agent 产品会自主决定何时调用工具、调用哪个工具、以什么顺序调用。一旦任务复杂，这种自主性就变成了失控源。
那真正靠谱的做法是什么？答案是：把任务的"顺序约束"从模型的大脑中剥离出来，交给一个它无法随意篡改的调度结构。这就是 DAG——有向无环图（Directed Acyclic Graph）。
我第一次把 DAG 用在 Claude Code 工作流里时，团队里有人质疑：这不就是把 ToDo 换个名字吗？实际跑完两轮后所有人都闭嘴了。区别在于：ToDo 是写给模型看的"建议"，DAG 是交给执行框架的"法律"。DAG 里的每个节点是一个明确且独立的执行单元，节点之间的边是强制依赖关系。模型可以在每个节点内部自由发挥，但它无法跳过某个节点，无法逆转节点顺序，也无法在上一个节点没有成功产出的情况下贸然进入下一个节点。
这篇文章我写给谁？如果你正在用 Claude Code、Cursor 这类 AI 编程/Agent 工具处理多步骤任务；如果你发现自己每次给 AI 布置复杂任务都要反复强调先后顺序，结果还是经常出错；如果你已经受够了"prompt 越写越长，模型却越来越糊涂"——那这篇文章就是写给你的。我会从 DAG 的核心原理讲起，然后给出可以在 Claude Code 里直接落地的方案，最后聊聊落地时的坑和排查思路。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 为什么 Claude Code 这类 Agent 特别需要外部顺序约束
2.1 Agent 的自主性与任务稳定性之间的天然矛盾
Claude Code 本质上是"能调用工具的 Agent"。它有自己的"想法"能力——模型在生成最终回复之前，会先经过一段内部推理过程，决定下一步做什么。这个设计带来了极大的灵活性，但也带来了一个副作用：模型会依据自己每一步的中间状态决定下一步动作，而这个决策过程对用户来说往往是不可控的。
用一个不太恰当但很形象的类比：你雇了一个能力很强的实习生，你跟他说"今天把这份报告整理好"。实习生很卖力，但他可能会因为觉得某个数据不太对，就先去找其他数据源核实；又可能觉得某个段落结构不顺眼，顺便帮你重写了。结果到下班时，报告确实出来了，但结构跟你要的完全不一样。ToDo 清单就像你贴在实习生桌上的便利贴，他忙起来根本顾不上看；而 DAG 则像一份带强制节点的项目计划，每一项交付物必须经过检查点确认，才能进入下一阶段。
在 Claude Code 中，这种"自主决策"的能力体现在多个层面：它可以选择调用工具、读取文件、执行 bash 命令、甚至修改自己的记忆文件。当我给 Claude Code 布置一个包含数据抓取、清洗、分析、出图四个阶段的任务时，模型很可能会自作主张地在"清洗"阶段就开始做部分"分析"——因为分析逻辑恰好被它联想到了。这种提前执行在单步任务中或许无害，但在多依赖链路上，一个节点提前执行往往意味着它使用的数据还没准备好，最后结果自然崩。
2.2 模型的 Token 窗口与"长任务失忆"
做过复杂任务的朋友一定有过这种感觉：Claude Code 跑一个长链路任务时，前面的上下文越堆越长，到了后半程，模型对早期指令的遵循度明显下降。这不是错觉，而是 Transformer 架构的一个天然短板：当输入 Token 数量逼近窗口上限时，模型对早期 Token 的注意力权重会被大量后续 Token 稀释。
比如你给 Claude Code 的初始指令是"严格按照这个流程执行：第一步做数据清洗，第二步做特征工程"，然后任务跑到中段时，上下文中已经积累了五十多轮工具调用记录和日志，每轮都有几千 Token。此时模型再读到"特征工程"阶段的任务描述，它对"数据清洗已完成"这个状态记忆已经变得模糊了。它可能觉得某些字段需要回炉重造，于是调用了清洗脚本，覆盖了原本已经干净的数据。
ToDo 清单在这种场景下几乎是无效的。因为 ToDo 本身也在上下文里，同样会被稀释；而且 ToDo 项之间没有"完成/未完成"的强语义绑定，模型不会主动去勾选。DAG 的解法是把任务状态外置——节点是否执行完毕，由外部调度器记录，不依赖模型记忆。模型每次进入新节点时，只需要面对这一个节点的输入和指令，不需要时刻背着整个流程。这就好比你给实习生安排了一天的工作，不是让他背下所有任务，而是每做完一步就回来找你领下一步的任务单，你手里有个总进度表，他完成到哪一步由你说了算。
2.3 工具调用的不确定性依赖
在 Claude Code 这类环境中，真正的风险还不只是模型乱序，而是工具调用的结果不可预测。一个写文件的工具，可能会因为磁盘权限失败；一个执行 python 脚本的工具，可能会因为依赖缺失而报错；一个读取远程 API 的工具，可能会因为网络超时而返回空结果。这些不确定性意味着：每个节点执行后，都必须有明确的成功/失败校验，否则后续节点基于错误的数据继续执行，会一路错到底。
我自己踩过一个非常深刻的坑：当时让 Claude Code 批量抓取网页摘要并存入本地文件。原始流程写在一个大 prompt 里，没有对"写入文件"做校验。结果某次运行时，网页抓取部分因为目标站点改版返回了 403，Claude Code 在日志中看到 403 后，居然"聪明地"抓取了缓存页面并存入了文件。下游的摘要节点不知道