1. 三个词被混着用的真实原因先把结论摆在前面Agent、Skill、Workflow 不是同一层的概念它们解决的是三个不同维度的问题。之所以大家总把它们混在一起聊是因为现在主流的智能体框架在文档和示例里经常把三者塞进同一段代码看多了自然就晕。我最早接触这套东西的时候也走过一段弯路。当时接了一个需求要做一个能自动处理客户工单的系统。我第一反应是这不就是个 Workflow 吗于是吭哧吭哧画流程图、写状态机把每一步都固定死。结果上线两周就崩了——客户的问题千奇百怪固定流程根本覆盖不住每来一种新情况就得改一次代码。后来换成 Agent 架构让它自己决定调用哪些工具、按什么顺序处理维护成本一下子降下来了。那次经历让我彻底明白选错抽象层级后面全是坑。用一句话概括三者的定位Workflow是怎么走——流程的编排谁先谁后、什么条件走哪条分支。Skill是会什么——一个具体能力的封装比如查天气、读文件、调接口。Agent是谁来干——一个能自主决策、动态选择 Skill、必要时自己编排流程的执行主体。打个比方。Workflow 像一份写死的菜谱第一步切菜、第二步下锅、第三步调味Skill 像厨房里的各种工具和食材处理能力刀工、火候、调味各是一样本事Agent 则像一位厨师他手里有菜谱也有工具但会根据今天冰箱里有什么、客人忌口什么临场决定怎么做这顿饭。这个类比能帮你快速建立直觉但真正落地时边界远比比喻复杂。下面我按从静态到动态的顺序把三者逐个拆开讲透再讲它们怎么配合。2. Workflow把确定性流程固化下来2.1 Workflow 的本质是控制流Workflow 的核心不是智能而是可控。它描述的是任务执行的控制流——哪些步骤、按什么顺序、遇到分支怎么走、失败了怎么重试。它不关心每一步内部有多聪明只关心步骤之间的连接关系。在代码层面Workflow 通常表现为几种形态链式ChainA 的输出直接喂给 BB 的输出喂给 C一条直线走到底。图式Graph节点之间可以有条件边根据上一步的结果决定下一步走哪个节点。状态机State Machine显式定义状态和转移条件适合流程复杂、状态多的场景。LangChain 里的 LCEL 链、LangGraph 里的图本质上都是 Workflow 的不同表达方式。它们的共同点是流程结构在运行前就已经确定运行时只是沿着预设的路径走。2.2 什么时候必须用 Workflow不是所有任务都适合交给 Agent 自主决策。以下场景Workflow 反而是更优解场景特征为什么选 Workflow步骤固定、顺序明确比如先校验格式再入库再发通知没必要让模型来决定顺序对延迟敏感Workflow 没有额外的决策开销路径最短对成本敏感每一步调用什么模型、传多少 token 都可控不会因为模型想多了而烧钱需要强审计每一步的输入输出都可追溯出问题能精确定位合规要求高关键操作必须走固定路径不允许模型自由发挥我做过一个数据清洗的流水线每天处理几十万条记录。这种任务用 Workflow 是最合适的——去重、格式化、校验、入库四步固定用图式编排串起来跑得又快又稳。如果硬塞一个 Agent 进去让它自主决定怎么清洗纯属给自己找麻烦还平白多出一大笔模型调用费用。2.3 Workflow 的隐藏成本Workflow 最大的问题在于刚性。流程一旦写死遇到预设之外的情况就束手无策。常见的表现是输入格式稍微变一下某个节点的解析就挂了。业务规则调整得改代码重新部署。分支越加越多最后变成一张谁也看不懂的蜘蛛网。这就是为什么很多团队在 Workflow 跑到一定规模后开始往 Agent 方向迁移——不是 Workflow 不好而是它的适用边界到了。提示判断要不要上 Agent先问自己一句这个流程的分支我能不能穷举完能穷举完Workflow 就够了穷举不完才考虑 Agent。3. Skill把一项能力封装成可复用的单元3.1 Skill 是能力的原子单位Skill 解决的是复用问题。一个 Skill 就是一项被封装好的具体能力有明确的输入、输出和调用方式。它可以是一个函数调用比如查数据库、发邮件一次外部 API 请求比如查天气、搜网页一段提示词模板比如把这段话翻译成英文一个复合操作比如读取 PDF 并提取表格关键点在于Skill 本身不做决策它只负责被调用时把这件事做好。至于什么时候调用、调用几次、传什么参数那是 Agent 或 Workflow 的事。3.2 一个好 Skill 长什么样我踩过不少 Skill 设计的坑总结下来一个好的 Skill 应该满足这几条第一职责单一。一个 Skill 只干一件事。我见过有人把查订单 算运费 生成物流单塞进一个 Skill结果 Agent 想单独查订单时也得把整套流程跑一遍浪费且难维护。拆成三个独立 SkillAgent 就能按需组合。第二描述清晰。Skill 的描述是给模型看的模型靠它判断这个 Skill 能不能解决我当前的问题。描述写得太模糊模型要么不用要么乱用。好的描述应该包含这个 Skill 做什么、什么时候用、输入需要什么、输出是什么。第三参数有约束。参数类型、必填项、取值范围都要明确。模型生成参数时经常出错约束越清晰出错率越低。第四失败可预期。Skill 执行失败时应该返回结构化的错误信息而不是抛一个模型看不懂的异常。这样 Agent 才能根据错误决定是重试、换 Skill 还是放弃。3.3 Skill 和工具Tool的区别很多人把 Skill 和 Tool 当同义词其实在多数框架里它们有细微差别。Tool 通常指最底层的函数调用接口而 Skill 更偏向面向任务的能力封装可能包含多个 Tool 的组合也可能包含提示词逻辑。举个具体的例子。假设你要做一个分析销售数据的能力底层 Tool 可能是query_database、calculate_growth、draw_chart。上层 Skill 则是销售分析——它内部会调用上面三个 Tool先查数据、再算增长率、最后画图对外只暴露一个给我时间段还你分析报告的接口。所以 Skill 是比 Tool 更高一层的抽象。Agent 面对的是 SkillSkill 背后可能是一堆 Tool。这样分层的好处是Agent 的决策空间被压缩到合理范围不用在几十个底层函数里挑花眼。3.4 Skill 的注册与发现机制当 Skill 数量多起来之后怎么让 Agent 找到对的 Skill就成了一个真问题。常见做法有两种全量注入把所有 Skill 的描述一次性塞进系统提示词。简单直接但 Skill 一多就会撑爆上下文而且模型容易选错。检索式发现把 Skill 描述做成向量索引根据当前任务先检索出最相关的几个 Skill再注入给模型。适合 Skill 数量上百的场景。我一般建议Skill 少于 20 个用全量注入超过 20 个就上检索。这个阈值不是绝对的取决于每个 Skill 描述的 token 占用。4. Agent会自己决定用哪个 Skill 的执行者4.1 Agent 的核心是决策循环Agent 和前面两者的根本区别在于它有一个观察—思考—行动的循环。它拿到任务后不是照着预设流程走而是观察当前状态任务是什么、已经做了什么、环境返回了什么思考下一步该干什么要不要调 Skill、调哪个、传什么参数执行动作调用 Skill拿到结果回到第 1 步直到任务完成这个循环就是所谓的 ReActReasoning Acting模式。它让 Agent 能处理那些事先不知道要几步才能完成的任务。4.2 Agent 的决策空间从哪来Agent 能自主决策靠的是三样东西系统提示词告诉它角色、目标、可用能力、行为约束。Skill 列表告诉它手里有哪些牌可以打。记忆告诉它之前发生了什么避免重复劳动或前后矛盾。这三样缺一不可。我见过有人只给 Agent 一个目标不给 Skill 列表结果模型只能干聊什么也做不了也见过 Skill 给了一堆但提示词里没说清楚什么时候用哪个模型就开始乱调。4.3 Agent 不是越自主越好新手容易陷入一个误区既然 Agent 能自主决策那就让它全自主。实际上完全自主的 Agent 在生产环境里几乎不可用原因有三不可控你不知道它下一步会干什么可能调一个你根本不想让它调的 Skill。不稳定同样的输入两次运行可能走完全不同的路径结果不一致。成本不可预测模型可能陷入循环反复调用 Skilltoken 消耗失控。所以成熟的 Agent 设计往往是有限自主——在关键节点上设置约束比如最多循环几次、哪些 Skill 禁止调用、什么情况下必须人工介入。这其实就是把一部分 Workflow 的控制逻辑嵌进了 Agent 里。4.4 Agent 和 Workflow 的边界正在模糊现在很多框架支持Workflow 里嵌 Agent 节点或Agent 里调 Workflow 作为 Skill。这种混合架构往往是最实用的主干流程用 Workflow 保证可控。需要灵活判断的环节交给 Agent 处理。Agent 处理完结果回到 Workflow 继续往下走。我那个工单系统的最终方案就是这样主干是 Workflow接收工单 → 分类 → 处理 → 归档但分类和处理两个环节内部是 Agent因为这两步最需要灵活判断。这样既保证了整体流程可控又保留了应对复杂情况的弹性。5. 三者怎么配合一个完整的落地架构5.1 分层架构的设计思路把三者放到一个系统里合理的分层是这样的最底层是 Skill一堆职责单一、描述清晰的能力单元。中间层是编排Workflow 负责确定性流程Agent 负责需要决策的环节。最上层是入口接收用户请求决定这次走 Workflow 还是交给 Agent。这个分层的关键在于职责不重叠。Skill 不关心被谁调用Workflow 不关心 Skill 内部怎么实现Agent 不关心底层是函数还是 API。每一层只跟相邻层打交道。5.2 一个具体例子智能客服系统假设要做一个智能客服需求是能回答常见问题、能查订单、能处理退换货、搞不定的转人工。拆解下来Skill 层查知识库、查订单状态、发起退货、转人工、查物流。Workflow 层主干流程是接收问题 → 意图识别 → 分流。意图识别如果是查订单这类明确任务直接走固定流程如果是模糊问题交给 Agent。Agent 层处理模糊问题自主决定调用哪些 Skill、按什么顺序。比如用户说我上周买的东西怎么还没到Agent 需要先查订单、再查物流、最后综合回答。这个架构里Workflow 保证了高频明确任务的效率和稳定Agent 兜住了长尾的复杂问题Skill 保证了能力复用。三者各司其职。5.3 选型决策表实际项目里怎么选我整理了一张决策表按任务特征对号入座任务特征推荐方案理由步骤固定、分支可穷举Workflow可控、快、便宜需要调用外部能力Skill封装复用隔离复杂度步骤不固定、需要临场判断Agent自主决策应对长尾主干固定但局部灵活Workflow Agent兼顾可控与弹性能力多、需要组合Skill AgentAgent 负责编排 Skill高频简单 低频复杂Workflow 分流 Agent 兜底成本与体验平衡这张表不是教条实际项目往往是组合使用。但有了它至少能在设计初期快速定位方向不至于一上来就选错抽象层级。6. 实操中最容易踩的几个坑6.1 把 Agent 当 Workflow 用最常见的错误。有人用 Agent 框架但提示词里把每一步都写死了第一步调用 A第二步调用 B第三步调用 C。这本质上是个 Workflow却套了 Agent 的壳结果是既没有 Workflow 的稳定又多了 Agent 的开销。判断标准很简单如果你的提示词里出现了第一步、第二步、第三步这种明确顺序那你需要的其实是 Workflow。6.2 Skill 粒度过粗或过细粒度太粗Agent 没法灵活组合粒度太细Agent 要调十几次才能完成一个任务token 和时间都浪费。我的经验是一个 Skill 对应一个用户能理解的动作。比如查订单是用户能理解的动作执行 SQL 查询就不是。按这个标准切分粒度通常刚好。6.3 忽略 Agent 的循环上限Agent 的决策循环如果不设上限遇到它解决不了的问题时会一直转直到把 token 烧光。一定要设最大循环次数超过就强制退出并返回当前状态。我一般设 5 到 10 次具体看任务复杂度。6.4 Skill 描述写得像技术文档Skill 描述是给模型看的不是给人看的。写调用 REST API 获取用户信息不如写当需要知道某个用户的基本信息姓名、注册时间、会员等级时使用此 Skill。前者模型看不懂什么时候用后者一目了然。6.5 不做失败兜底Agent 调用 Skill 失败是常态——网络抖动、参数错误、外部服务挂了。如果不做兜底整个任务就卡死。正确做法是让 Skill 返回结构化错误Agent 根据错误类型决定重试、换方案还是上报。7. 我个人的一些经验判断聊了这么多概念和架构最后说几个我在实际项目里形成的判断不一定对但都是踩坑踩出来的。第一能用 Workflow 就别上 Agent。Agent 的灵活是有代价的——不稳定、贵、难调试。只有当 Workflow 真的覆盖不住时才引入 Agent。很多团队一上来就全 Agent最后发现 80% 的场景其实用 Workflow 就够了。第二Skill 的质量决定 Agent 的上限。Agent 再聪明手里的 Skill 不行也白搭。与其花时间调 Agent 的提示词不如先把 Skill 的描述、参数、错误处理打磨好。我见过太多项目Agent 表现差不是因为模型不行而是 Skill 设计得太烂。第三混合架构是常态纯架构是例外。真实系统里Workflow、Skill、Agent 往往是交织在一起的。不要执着于这个系统到底是 Workflow 还是 Agent而是问这个环节用哪种方式最合适。第四可观测性比什么都重要。不管用哪种架构一定要能看清每一步发生了什么——调了哪个 Skill、传了什么参数、返回了什么、花了多少 token。没有可观测性出了问题只能靠猜调试效率极低。第五别被框架绑架。LangChain、LangGraph 这些框架很好用但它们的抽象不一定适合你的场景。理解 Agent、Skill、Workflow 这三个概念的本质比会用某个框架重要得多。概念清楚了换任何框架都能快速上手。回到最开始那个问题——Agent、Skill、Workflow 到底有什么区别现在你应该能给出自己的答案了它们不是竞争关系而是三个不同层次的抽象分别回答谁来干会什么怎么走。搞清楚这一点选型和设计就不会跑偏。