Workflow 的天花板极低。你无法在节点里表达复杂的递归逻辑难以复用模块更无法进行版本管理GitOps。当你想要把一个写好的工作流分享给别人时导出导入的过程充满了环境依赖的深坑。这是典型的「低代码陷阱」在 AI 时代的重演。最近在 X 上看到有人为了 Dify 这类可视化编排工具辩护抛出了一个观点“80 多个节点的 Workflow其稳定性和可调整性绝非 Subagent 能比拟。”这话听起来很耳熟。五年前低代码平台火的时候大家也是这么说的。作为架构师我必须泼一盆冷水可视化编排Workflow给了你一种「掌控全局」的错觉但在构建真正的复杂系统时它往往会变成难以维护的技术债务。可视化的核心价值在于「确定性」和「审计」。A 节点之后必然是 B 节点路径清晰适合合规审查。但它的死穴也很明显僵化。一旦业务逻辑变得非线性或者输入数据结构发生抖动那张精心编排的“蜘蛛网”就会瞬间卡死。而且试问有谁愿意去 Code Review 一个几千行的 JSON 配置文件我的观点很明确在大部分复杂场景下Agent Skills 的架构才是正解。这不仅是替代更是降维打击。Split screen comparison. Left side: A messy, tangled web of 80 nodes in a visual editor causing a bottleneck. Right side: A clean, modular stack of glowing Skill blocks autonomously assembling into a structure.为什么 Workflow 只是过渡态拖拽连线是给非技术人员的“奶嘴”。它让你觉得在编程其实是在配置参数。Workflow 的天花板极低。你无法在节点里表达复杂的递归逻辑难以复用模块更无法进行版本管理GitOps。当你想要把一个写好的工作流分享给别人时导出导入的过程充满了环境依赖的深坑。而Agent Skills的本质是用自然语言作为胶水去编排模块化的能力。如果你把 Skill 仅仅理解为“一个翻译插件”或“一个联网工具”那你就把路走窄了。在系统架构层面Skill 是可组合的原子业务单元。基于宝玉的实践和我自己的工程经验我总结了一套将 Workflow 重构为 Agent Skills 的五步架构框架。第一步原子化拆分SRP 原则别试图做一个全能 Agent。软件工程的第一原则是单一职责Single Responsibility Principle。把那个 80 节点的庞然大物拆解开。以「自动化写作」为例不要试图用一个 Prompt 搞定所有事。•Article-Analyzer (Skill): 只负责读输出analysis.md。不写稿只做结构化分析。•Outliner (Skill): 只负责生成骨架输出 2-3 个方案。•Writer-Agent (Subagent): 纯粹的执行者拿大纲填肉。•Polisher (Skill): 最后的润色工序。这种拆分不仅是为了清晰更是为了解耦。第二步语义化编排这是最反直觉的一点扔掉连线用自然语言写逻辑。在主 Agent 的 Prompt 里你像给高级下属布置任务一样描述流程“先调用 Analyzer 分析素材拿到 analysis.md 后生成 3 个大纲方案并发启动 Writer-Agent 进行撰写。”自然语言具有代码无法比拟的容错性和分支处理能力。传统的 Workflow 遇到异常需要你画专门的错误处理分支而 Agent 能根据语义理解自动重试或调整参数。A conceptual diagram showing a central Brain (Agent) issuing natural language commands to satellite modules (Skills), forming a dynamic star network instead of a linear chain.第三步文件系统即数据库File-based State这是很多 AI 开发者容易忽视的最佳实践中间态落盘。不要在内存里传递巨大的 Context 字符串。把每一步的输出都保存为本地文件source.md-analysis.md-draft.md-final.md。这样做有三个架构级的优势1.可追溯Traceability任何一步崩了打开文件就能 debug。2.断点续传系统挂了重启后读取上一个文件继续跑不用从头烧 Token。3.人工介入Human-in-the-loop觉得大纲不好直接打开 Markdown 改改完让 Agent 继续跑。第三步引用传递而非值传递这是优化 Token 成本和上下文窗口的关键。Subagent 之间只传文件路径不传内容。当 Writer-Agent 启动时不要把几万字的背景资料塞进它的 System Prompt。只给它一个路径./data/analysis.md。让它自己去读。这不仅保持了上下文的纯净更使得并行处理成为可能。你可以同时启动 5 个 Writer-Agent分别读取不同的路径互不干扰。这在单线程的 Workflow 图里是很难优雅实现的。A visualization of data flow where File Paths (like glowing links) are passed between robots, while the heavy Content Books stay in a central library shelf.第五步自我进化的闭环这是 Agent Skills 彻底碾压 Workflow 的杀手锏可进化性Evolvability。Workflow 搭好了就是死的。随着时间推移它会变成一座僵化的屎山。 但 Skill 是代码是文本是 Prompt。你可以让 Claude Code 或其他强模型充当“架构师 Agent”去分析现有的 Skill 表现并自动重写 System Prompt。甚至可以让 Subagent 在运行中记录错误自我迭代。McKinsey 的报告中提到过这种模式法律审核 Agent 记录人工修正的记录反向优化自己的 Prompt。你的系统是用得越多越聪明而不是越用越臃肿。面对质疑架构师的防御性思考当然从 Workflow 转到 Agent 代码化会有三个典型的质疑。质疑一Agent 这种概率模型怎么保证稳定性回答混合架构Hybrid Architecture。谁让你把所有逻辑都交给 LLM 了确定性的逻辑比如格式化 Markdown、数学计算、正则提取请写成 Python/TypeScript 脚本封装成 Skill。让代码做代码的事让 AI 做推理的事。这种“确定性脚本 概率性推理”的组合才是工程落地的常态。质疑二Token 成本太高回答算总账TCO。Workflow 也就是省了点运行时的钱但开发和维护成本极高。乐天Rakuten用 Skills 处理财报效率提升 8 倍。这种业务价值的提升足以覆盖 Token 成本。况且通过“按需加载文件”的策略实际上比把所有上下文塞进 Workflow 更省 Token。质疑三门槛太高不会写代码回答让 AI 写 AI。现在是 2026 年了Context你不需要手写每一个 Skill 的 YAML 配置。使用/skill-creator这种工具描述需求让 Claude Code 帮你生成 Skill。 更重要的是Skill 是文本文件可以 Git 管理可以做 Code Review可以跨团队复用。Workflow 导出的 JSON 能做到吗总结别再沉迷于拖拽节点的快感了。如果你只是想做一个玩具Workflow 很好。 但如果你想构建一个可维护、可扩展、可进化的企业级自动化资产请把你的 Workflow 拆解沉淀为 Skills。未来的 AI 架构不是静态的流程图而是一组能自我适应、自我调用的智能能力簇。