智能任务自动化协同AI工作流：从设计到落地

上周在复盘咖啡门店智能点单系统的数据时，我发现一个很有意思的变化：接入AI工作流之后，加购推荐的整体点击率翻了将近一倍，但真正让我意外的不是推荐算法本身，而是整个任务流转的链路——从用户说出“一杯热的燕麦拿铁，少糖，打包带走”到订单生成，中间经历了意图识别、库存校验、推荐排序、话术生成、状态回写，十几个任务节点协同完成。这套东西，我把它称作智能任务自动化协同AI工作流。这篇文章就把这套工作流从设计到落地的完整思路拆开聊聊，适合正在做AI Agent、智能客服、自动化流程编排的工程师，也适合刚接触Dify、Coze这类低代码工作流平台、想搞明白背后原理的开发者。

1. 从规则驱动到意图驱动：AI工作流到底改写了什么

1.1 传统工作流像有轨电车：Flowable、Camunda、Jenkins Pipeline的老路子

早些年的任务自动化，玩的是BPMN流程图那一套。Flowable、Camunda这类引擎把业务流程画成节点和连线，每个节点是确定性的：审批通过就走A分支，驳回就走B分支。Jenkins Pipeline也差不多，构建、测试、部署每一步都提前定义好，顺序固定，参数结构固定，输出结果也是可预期的。

这套东西到今天依然有价值，尤其适合审批流、订单状态机、定时任务这类强规则场景。但它有个天然的死穴——输入必须是结构化数据。用户说“我想点一杯燕麦拿铁，少糖”，传统表单根本接不住这句话，你得先让他从下拉框里选“中杯”“大杯”，再选“全糖”“半糖”，再来一个备注框。稍微遇到点自然语言，整个流程就卡死了。

1.2 AI工作流像带目标的出租车：意图驱动才是本质区别

AI工作流的改变，不是简单地把流程图里的某个节点换成“大模型调用”。它的底层逻辑变了：传统流程是“事件驱动”，用户触发了某个表单提交，系统沿着预定义的轨道往下走；AI工作流是“意图驱动”，系统收到一个模糊的目标，由智能体自己去拆解、规划、调用工具、确认结果。

我习惯用一个比喻来解释：传统工作流是有轨电车，轨道铺到哪里，车就只能开到哪里，好处是永远不会出轨，坏处是没法绕路；AI工作流是带着目标的出租车，乘客说“去火车站”，司机自己规划路线，遇到堵车还会绕行，但风险是司机听错目的地、绕路绕出天价账单。所以做AI工作流，核心功夫全在“怎么让司机听懂人话”和“怎么约束司机不乱跑”这两件事上。

1.3 任务自动化和智能任务自动化的清晰分界线

这里必须把概念掰开揉碎。任务自动化是把重复动作脚本化，比如每天凌晨定时同步数据、定时发日报；智能任务自动化则要处理的是不确定性问题——用户意图不明确、条件动态变化、多个子任务之间存在依赖关系、需要随时调用外部工具。

对比一下就很直观：

我在做咖啡门店点单系统时对这点感触特别深。老系统里用户点单靠点单机，每个商品一个按钮，加购推荐靠收银员口头推销。换成智能体系统之后，用户直接对着对话框说需求就行，系统把它变成一个动态任务流，每一步都在实时决策。这才叫从“把人变成机器”到“让机器理解人”的转变。

2. 任务拆解与分配：智能体“大脑”的选择题

2.1 拆解的第一性原理：按执行者能力边界切分

任务拆解是整个工作流最容易被忽视、又最决定上限的环节。很多人以为让大模型把一个复杂任务“想明白”就行，实际工程里完全不是这样。正确的拆解原则是：每个子任务都交给最擅长它的执行者。

大模型擅长意图理解、语义相似度判断、文本生成；规则引擎擅长精确匹配、状态判断；普通API擅长确定性计算——比如算价格、查库存、生成订单号。如果让大模型去算12.5乘以3等于多少，虽然它能算对，但延迟和token成本都浪费了，直接调一个计算函数更稳。反过来，如果让库存服务去理解“少糖”是什么意思，它也做不到。

拿咖啡点单来拆一下：

• 用户输入：“来一杯热燕麦拿铁，少糖，一会儿去店里取”
• 子任务1（LLM负责）：把这句话解析成结构化槽位——温度“热”、基品“燕麦拿铁”、糖度“少糖”、取餐方式“到店自取”
• 子任务2（库存API负责）：校验这款商品当前门店有没有货
• 子任务3（价格服务负责）：计算标准价，判断有没有优惠券可抵扣
• 子任务4（推荐模块负责）：基于用户当前偏好算出加购候选
• 子任务5（LLM负责）：把推荐结果生成一段自然、不反感的话术
• 子任务6（订单服务负责）：创建订单、生成取餐码

每个子任务的能力提供者不同，这就决定了它们不该挤在一个大模型调用里，而应该分布在不同的节点上，通过工作流串起来。

2.2 分配策略：先规则硬路由，再让LLM处理模糊带

任务拆完之后，接下来的问题是：谁来决定每个任务执行到哪里？

我在早期版本里走过弯路，让LLM作为总调度，由它决定下一步调用什么工具。结果功能没多强，问题倒是一大堆：模型偶尔把工具名记错、参数格式给错、该调库存的时候去调了价格服务。后来我把架构改成“规则优先，模型兜底”的混合路由：

优先用编程方式确定的任务流程直接走代码；只有走到模糊地带——比如判断用户意图是否包含加购意愿、是否需要转人工、多个候选商品中哪个更贴合当前对话——才交给LLM。这样既保留了LLM的灵活性，又砍掉了大量不必要的推理延迟。

2.3 上下文传递：协同是否顺畅的分水岭

所有拆出来的子任务必须共享一份上下文，这往往是协同系统的命门。我在第一版工作流里，每个节点只往下一个节点传递自己的输出，结果推荐节点根本不知道用户刚才说过“少糖”，推荐了一堆高糖甜品，当场翻车。

后来我设计了一份统一的任务上下文结构，包含三个部分：

• 全局上下文：会话ID、门店ID、用户身份、当前会话基础信息，全程不变
• 任务上下文：当前任务的目标、状态、已解析出的结构化槽位、各节点的中间结果，随时间流转
• 临时上下文：单个节点的输入输出缓冲，节点结束就清理

传给每个节点的不是“上一个节点的输出”，而是“当前任务上下文的完整快照”。用一段JSON举例：

{ "session_id": "coffee_20250321_184532", "store_id": "SH003", "user_id": "u_10294", "task": { "goal": "完成一杯热燕麦拿铁的加购推荐与下单", "status": "recommendation_generating", "slots": { "product": "燕麦拿铁", "temperature": "hot", "sugar": "less", "pickup": "in_store" }, "inventory_check": { "product_id": "p_1024", "available": true, "stock": 18 }, "recommendation_candidates": ["p_2048", "p_3091", "p_1107"], "final_answer_template": "已为你推荐delicious食谱..." }, "history": [ { "role": "user", "content": "来一杯热燕麦拿铁，少糖，一会儿去店里取" } ] }

每个执行节点只读自己关心的字段，把结果回写到对应的key上。这个设计后来成了整套系统的地基。

3. 多智能体协同的三种跑法以及我为什么放弃“全自动”

3.1 模式A：中心化编排，一个Planner分派任务

中心化编排是最稳妥的架构，也是Dify、Coze这类工作流平台默认采用的思路。一个编排节点扮演“项目经理”角色，负责拆任务、派活、回收结果、做最终汇总；底下的执行Agent各司其职，像模块化团队一样互不打扰。

在咖啡点单系统里，这个模式表现为：意图识别Agent先干活，产出槽位数据；库存Agent接着校验；推荐Agent算候选；话术Agent组合语言。所有Agent不直接通信，都通过中间任务队列交互。

这个模式的优点一眼就能看出来：可控、好排查、每个环节出了问题都能单独定位。代价是任务链路变长，编排节点可能成为性能瓶颈。对于门店点单这种低延迟要求场景，编排逻辑一定要精简，不能把大量文本全塞给模型反复判断。

3.2 模式B：去中心化讨论，多Agent相互评审

去中心化模式参考的是AutoGen、CrewAI那套思路——多个Agent围绕同一个目标各自提出看法，互相评审、挑战、迭代。比如让一个Agent扮演“产品经理”提出推荐策略，另一个扮演“顾客”“挑刺”，再一个扮演“营养师”判断合理性，最终收敛出一个方案。

这种模式在处理研究分析类任务时很出彩，能模拟不同视角碰撞。但放到真实业务里，尤其是点单这种需要秒级响应的场景，就不太合适了。多个Agent来回对话容易发散，收敛时间不可控，token消耗翻好几倍，出了问题你都不知道该怪谁。

3.3 模式C：人机混合，关键节点插入人工审批

最容易被低估的其实是人机混合模式。很多团队做AI工作流追求“全自动”，仿佛哪一步还要人工介入就显得不高级。但企业落地的时候，责任归属问题远远比技术完美更重要。加购推荐如果推荐了用户过敏的食品，谁负责？自动下单扣错了款，谁赔？

所以我在关键节点上主动插入了人工审批环节：推荐方案生成后，如果涉及金额变化较大、推荐了非用户历史品类的商品、或者系统对用户意图的置信度低于阈值，都要推给门店员工做一次确认。这不是技术上的退步，而是系统真正进入生产环境必须付出的成本。

3.4 三种模式怎么选：我给团队的决策表

从我的实践看，绝大多数业务型AI工作流最适合的跑法不是“全自动”，而是“中心化编排为主，人工介入为兜底”。全自动这件事，留给实验场景就好。

4. 工程化深水区：调度、消息、错误恢复与可观测性

4.1 任务调度：从“写完就跑”到“可靠地跑”

AI工作流一旦进入生产，第一件事就是把任务调度做扎实。不要想着用单机脚本顺次跑完所有节点，那只能活在Demo里。真正要考虑的是：任务并发、失败重试、超时控制、优先级排队。

我的做法是引入一张任务状态表，每个任务实例都有一行记录，字段包含task_id、workflow_type、status、payload、retry_count、scheduled_time、finished_time。调度器负责扫描这张表，把status为pending且到达调度时间的任务放入执行队列，执行完成后回写状态。

调度方式可以根据规模选：轻量场景用Celery配合定时任务就行；直接调用次数高、需要持久化执行历史的场景，上Temporal或者自建状态机更稳妥。门店点单系统早期并发量不大，我用的是Celery加数据库状态表，稳定跑了两三个月没出大问题。

4.2 消息与解耦：事件驱动比直接调用更抗冲击

工作流的节点之间如果直接写死调用关系，后期想调整顺序或者插入新节点，就得改一大片代码。更合理的方式是引入事件总线，节点之间通过事件协作，不直接发生函数调用。

咖啡点单系统的事件流大致是：user_message.received事件触发意图解析；intent.parsed事件触发库存校验；inventory.checked事件触发推荐；recommendation.generated事件触发话术生成；order_confirmed事件触发下单。每个服务只订阅自己关心的事件，消费完发布新事件。这样新增一个“优惠券计算”节点，只需要订阅inventory.checked，再发布一个coupon.calculated事件，完全不用影响其他节点。

事件结构也要统一，至少包含event_id、event_type、session_id、timestamp、payload。event_id和session_id是后面做幂等和追踪的关键字段，千万别偷懒不设计。

4.3 错误恢复与幂等：LLM调用是不可靠的

这是全篇最想强调的工程经验：LLM调用本质上是一个高延迟、偶发错误的外部依赖，你必须像对待数据库连接一样对待它。

重试策略要有分级。瞬时错误——比如网络超时、限流（429）、服务端5xx——可以自动重试，我一般设置最多3次，退避间隔为1秒、5秒、15秒。业务错误——比如模型输出格式不符合预期——重试会浪费token，应该直接降级到规则解析。比如意图识别失败时，我让系统退回正则加关键词匹配的老方案，虽然笨，但至少不会让用户干等着。

再来说幂等。这个坑真的刻骨铭心。有次测试环境出现用户重复下单，排查后发现是LLM的function calling在调“创建订单”工具时，因为网络抖动导致客户端重发请求，模型以为第一次没调用成功，又调了一次。订单系统没有做幂等校验，直接生成了两笔订单。后来我在所有写操作工具前都加了一道幂等校验——调用方必须传request_id，同一个request_id在30分钟内只能执行一次。这个设计现在已经成为我所有Agent系统的标配。

4.4 可观测性：没有日志的AI工作流就是黑盒

传统流程排查看日志就够，AI工作流不行。你得同时看到：每轮LLM调用的prompt是什么、用的哪个模型、输入输出完整内容、token消耗、响应延迟、重试了几次、最后走向了哪个分支。否则用户说“推荐的东西不对”，你连是哪一步出了问题都不知道。

建议给整个工作流全局分配一个trace_id，所有节点日志都带上它。工具方面可以用LangSmith这类专门跟踪LLM调用的平台，也可以基于ELK或ClickHouse自建一套。我后来自建了一张token消耗明细表，每天定时统计各工作流节点的token成本，哪个节点变成了吞金兽一目了然。做AI工作流，成本治理不是财务要求，是技术必修课。

5. 把AI工作流交给自动化测试：prompt、函数与编排三层守门

5.1 为什么传统自动化测试框架不够用

做AI工作流之后，我最大的不适应来自测试。以前做接口自动化测试，断言是确定的——返回码是不是200、返回字段有没有带对、数据库落库数据对不对。现在输出是概率性的，模型今天心情好，推荐话术写得漂亮；明天换了模型版本，话术变得啰嗦甚至跑题。你把断言写成“recommendation_content中包含‘燕麦拿铁’”，它可能写成了“为您推荐燕麦拿铁伴侣”，也能过。

所以测试策略要跟着变：不能只断言字符和数值，还要断言意图和规范。所谓意图断言，是验证“推荐的产品是否符合用户糖度约束”；所谓规范断言，是验证“输出JSON结构是否合法、字段是否齐全、取值是否落在枚举范围内”。这类断言用传统的pytest能写，但断言逻辑必须结合语义判断，必要时让另一个LLM来当裁判。

5.2 三个测试层级：函数层、Prompt层、编排层

函数层最简单，用pytest单测覆盖所有工具函数和解析器。库存服务的返回格式、价格计算器的金额精度、状态机的状态流转逻辑，都可以用常规自动化测试手段搞定。这部分是地基，出了问题连锁反应最大。

Prompt层做回归最头疼。我的做法是维护一份黄金样例集，覆盖典型的用户表达——正常点单、少糖加浓度、问他有没有优惠、情绪不好的投诉、夹杂英文的订单。每次改prompt或换模型，都把这份样例集跑一遍，让judge LLM给输出质量打分，低于阈值就不允许上线。

编排层做的是端到端验证，这时候Playwright就派上用场了。我用Playwright模拟用户在前端对话框输入一句话，等待系统回完整订单消息，校验最终落库的订单数据是否符合预期。移动端场景再用Appium补一轮。这套组合拳基本能堵住大部分回归风险。

5.3 Jenkins自动化部署：从提交代码到跑完回归再上线

配套的自动化部署我用的是Jenkins。流水线大致长这样：

pipeline { agent any stages { stage('Checkout') { steps { git 'https://your-repo.git' } } stage('Unit Test') { steps { sh 'pytest tests/unit/ -m "not e2e" --junitxml=report.xml' } } stage('Prompt Regression') { steps { sh 'python scripts/prompt_regression.py --dataset gold_set_v3.json' } } stage('Build Image') { steps { sh 'docker build -t cafe-agent:latest .' } } stage('Deploy Test Env') { steps { sh 'docker compose -f docker-compose.test.yml up -d' } } stage('E2E Smoke') { steps { sh 'pytest tests/e2e/ -m "smoke" --env=test' } } } }

这里要强调一个经验：Prompt回归必须跑在部署之前，而E2E冒烟跑在部署之后。前者是验证模型行为，后者是验证系统联通。两个阶段都会抓出不同的问题，可别合并成一个“大杂烩”步骤。

5.4 灰度发布与线上监控：上线不是结束

Jenkins把新版本部署到测试环境只是第一步，真正上线还得做灰度。我的做法是在网关层做流量染色，最初只有5%的真实会话会走到新版工作流，跑24小时观察核心指标：点单完成率、平均响应时间、推荐点击率、投诉率。一切平稳再逐步放量到30%、100%。

线上监控要设置两个报警阈值：技术层跟业务层分开。技术层看LLM调用错误率、超时率；业务层看推荐点击率是否明显下降、点单流程未完成率是否上升。任何指标异常都自动暂停灰度，把流量切回稳定版本。这套守门机制上线以后，我基本不再担心新版本上线搞出生产事故。

6. 实战拆解：咖啡门店点单与加购推荐智能体系统

6.1 业务目标：先算清楚账再动手

做咖啡门店这个项目时，客户最初只说了四个字：“提升客单价。”需求很不性感，但特别现实。我把它拆成两个可量化指标：点单完成率（用户从发消息到下单成功的比例）和加购推荐点击率（推荐商品被加入购物车的比例）。

决定做任务型点单智能体而非简单聊天机器人，就是因为聊天机器人只负责“聊”，不负责“任务闭环”；而智能体系统能把对话自然引导到下单动作，并且在对话过程中见缝插针地完成加购推荐。这个定位差异决定了整个架构设计：必须有状态机、必须有商品服务对接、必须有订单落库、必须有推荐逻辑，而不是一个孤零零的模型接口。

6.2 系统模块组成与各自职责

整体系统划分为六个核心模块：

工作流主线是：用户消息进来→NLU解析→状态机更新→库存校验→（触发推荐）→话术生成→用户确认→创建订单。整条链路里，LLM只承担理解与生成的部分，其余全部交给确定性服务。

6.3 协同过滤与大模型混合的推荐逻辑

加购推荐的实现，不是简单地把商品列表扔给大模型“你看着推荐”。那太贵也不稳定。我用的是召回+重排+生成三步走：

召回阶段用协同过滤（ItemCF）找出“与当前已选商品经常一起被购买”的候选商品。燕麦拿铁的相似品可能是香草拿铁、肉桂卷、坚果曲奇。这步是离线算好的，结果存Redis，线上查询毫秒级返回。召回宽度控制在10个商品以内，留一小部分随机作为探索。

重排阶段再让LLM参与：把用户当前的槽位信息（糖度、温度、点单时段）和召回列表一起塞给模型，让它从中挑出最贴合当前场景的1到2个商品，并说明推荐理由。这步的意义是过滤掉协同过滤“热门但不符合当前偏好”的商品。比如用户刚说了“少糖”，重排阶段就把高糖点心过滤掉。

最后生成阶段，用LLM把选中的商品和理由变成一句不发腻、不机械的话：“今天天气有点凉，要不要顺带一份现烤的肉桂卷？配热燕麦拿铁正好。”这句话模板和模型生成混合，防止模型说出违背业务规则的话。

6.4 关键实现片段：状态机与工具调用

状态机的核心实现，用一个轻量的Python类就够了：

class OrderStateMachine: def __init__(self, session_id): self.session_id = session_id self.state = "INTENT_PARSING" self.context = { "slots": {}, "candidates": [], "selected_item": None, "order_id": None } self.transitions = { "INTENT_PARSING": ["INVENTORY_CHECK", "CLARIFY_NEEDED"], "INVENTORY_CHECK": ["RECOMMENDATION", "OUT_OF_STOCK"], "RECOMMENDATION": ["AWAIT_CONFIRM", "NO_RECOMMEND"], "AWAIT_CONFIRM": ["ORDER_CREATING", "MODIFY_ORDER"], "ORDER_CREATING": ["ORDER_DONE", "ORDER_FAILED"] } def can_transit(self, target_state): return target_state in self.transitions.get(self.state, []) def transit(self, target_state): if not self.can_transit(target_state): raise IllegalTransition(f"{self.state} -> {target_state}") self.state = target_state # 持久化到Redis redis_client.hset( f"order_state:{self.session_id}", mapping={"state": self.state, "context": json.dumps(self.context)} )

LLM的function calling工具定义，用OpenAI格式写出来就是一个JSON Schema：

{ "name": "create_order", "description": "创建咖啡订单并生成取餐码", "parameters": { "type": "object", "properties": { "product_id": {"type": "string", "description": "商品ID"}, "quantity": {"type": "integer", "default": 1}, "temperature": {"enum": ["hot", "ice"]}, "sugar_level": {"enum": ["regular", "less", "half", "free"]}, "pickup_method": {"enum": ["in_store", "takeaway"]}, "request_id": {"type": "string", "description": "幂等请求ID, 由调用方生成"} }, "required": ["product_id", "request_id"] } }

request_id字段，前面说过的幂等设计就落在这里。模型生成一次调用，就带着这个ID，即使重复触达订单服务，也不会重复落单。

6.5 实测效果与调优体会

系统上线两个月后的数据对比让我比较满意：点单完成率从Web表单的68%提升到82%；加购推荐点击率从原来的收银员口头推荐水平翻了近一倍；平均单次点单响应时间控制在2.8秒左右，用户可接受。Token成本上，单次完整点单流程平均消耗约6000到9000个token，约合人民币不到一毛钱，远低于预期。

调优过程中印象最深的是推荐时机选择。最开始推荐在“用户确认下单后”弹出，点击率很差；后来改成“完成库存校验、尚未形成订单前”推荐，点击率明显上升。原因不复杂：订单还没确认，用户处于决策状态，推荐是被当作“帮你选”的参考；订单确认后再推荐，就成了“多买一个”的推销，心理感受完全不同。这个经验后来应用到了好几个项目里。

7. 云边协同场景下的任务分发与容灾降级

7.1 为什么门店场景必须考虑云边协同

对咖啡门店来说，不可能假设网络永远畅通。门店收银系统的外网偶尔会抖，而大模型服务几乎都部署在云端。如果点单智能体完全依赖云端，一旦门店和云端链路出问题，点单业务就直接瘫痪，这比推荐差一点严重得多。

云边协同的核心思路是：把任务分发到离用户最近、最合适的计算节点上。门店的收银机、小主机是边缘节点，负责收集用户输入、执行轻量任务；云端负责大模型推理、协同过滤重排这类需要强算力的任务。边缘和云端各干各的，又彼此配合。

7.2 正常与降级两种模式下的任务流

正常情况下，用户消息先到边缘网关，网关把消息转发到云端AI工作流，云端解析意图、校验库存、生成推荐、落下订单，结果回传边缘端展示。这个流程体验最好，推荐质量也最高。

当边缘节点检测到云端不可达，就自动切换成本地降级模式。降级模式里，边缘端跑一个轻量NLU——正则加关键词匹配，能识别常见点单表达；商品和库存数据提前同步到本地；推荐直接用热门商品列表。点单请求先在本地落库，等网络恢复后，边缘端把这段时间的订单记录和点击日志批量补传给云端，云端做对账和后续分析。这套机制上线之后，门店在多次网络波动期间都没有停摆过。

7.3 任务分发的同步与补偿细节

云边协同的坑主要在对账与补偿上。边缘端生成了订单但云端迟迟没收到，用户到底付没付款？我的做法是给每笔订单都生成一个全局唯一流水号，边缘端与云端各自落库，云端定期发起对账任务，拉取边缘端增量流水，比对状态。不一致的走补偿流程：边缘有而云端没有的下发到云端，两端都有但状态不一致的以支付结果为准。这部分逻辑不复杂，但必须做，否则时间长了数据就是一个烂摊子。

8. 踩坑清单：上下文漂移、重复调用与Agent乱序

8.1 上下文漂移：少糖的燕麦拿铁差点配了高糖点心

这是我在真实生产环境里踩的最深的一个坑。用户明确说了“少糖”，结果推荐模块在重排时忽略了这条槽位信息，推荐了一款焦糖饼干。原因就是我当时没有把用户偏好固化到结构化槽位里，推荐节点读的是对话历史原文，模型在长上下文中丢失了关键约束。

解法前面提过：把所有用户约束全部解析成结构化槽位写入任务上下文，推荐节点强制校验槽位合规性，不符合直接过滤。从那以后，我再也没让AI系统在用户眼皮底下犯过这种“健忘”的错。

8.2 重复调用：LLM一抖动，订单下了两遍

重复下单问题的完整链路是：客户端网络超时→自动重发请求→LLM第一次调用实际成功了但响应丢失→LLM再次发起创建订单→订单系统没做幂等→生成两笔订单。这种故障比业务逻辑bug更难排查，因为看起来一切正常。

解决方式不复杂，但必须要做两道防线：调用方每次请求带request_id；接收方对相同request_id直接返回首次执行结果。这个设计不仅用于订单服务，所有涉及资金、库存扣减、优惠券核销的工具函数都要加上。

8.3 Agent乱序执行：依赖关系不是靠“建议”

多Agent并行执行时，我遇到过库存节点还没返回结果，下单节点已经开始执行的情况。表面原因是并行调用时机不对，根因是我在设计工作流时没有显式声明任务依赖关系。

后来我把所有任务节点都改造成依赖图驱动执行：每个节点声明依赖哪些前置节点，调度器只执行“依赖已全部完成”的节点。依赖关系写死在代码或配置里，不依赖任何“智能”判断。这是从血的教训里总结出来的：工作流里的顺序控制，永远应该靠确定性的依赖关系，而不是指望模型自己理解先后逻辑。

8.4 Token成本失控：上下文长着长着就超支了

工作流里每个节点都带完整上下文，确实解决了上下文漂移，但也带来了新问题——上下文越长，token消耗越大。尤其是多轮对话里，用户聊了十几句，全局上下文越攒越长，每个节点都把它带上，成本指数级增长。

我的解法是分层管理：核心槽位永远保留，长对话历史压缩成摘要再进入下游节点；不同节点使用不同模型，简单抽槽用又快又便宜的小模型，复杂生成才用大模型。入手是成本，出的是系统整体吞吐与可用性。上线三个月后，这套压缩策略让单会话成本下降了四成。

说实话，从最早用Flowable画审批流，到后来折腾Dify、Coze，再到现在自研带状态机和人机混合机制的智能体工作流，我最大的感受是：AI工作流这个名字很容易让人误以为重点是“AI”，其实真正的门槛一直在“工作流”这三个字上——任务怎么拆、状态怎么管、上下文怎么传、出错了怎么兜底、上线了怎么观测。模型能力决定上限，工程系统决定下限，这句话放在这个领域再合适不过。文章里写的这些设计思路和踩坑记录，都是真金白银买回来的经验，希望对你正在折腾的AI工作流项目有点帮助。