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 架构，不是静态的流程图，而是一组能自我适应、自我调用的智能能力簇。
)
)