你可能不再需要 workflow,大部分场景 skills 足矣——五步框架把 Workflow 变成可进化的 Skill ✍ 宝玉🕐 2026-01-11📦 12.3 KB 🟢 已读 𝕏 文章列表 文章通过对比传统 Workflow 编排与 AI Agent + Skills 架构,提出大部分场景下后者可以取代前者。作者提出了五步框架(拆分、编排、存储、分摊、迭代),并结合自身写作工作流演示了如何利用 Claude Code 的 Skills 功能构建可进化的自动化系统。文章还回应了关于稳定性、成本和门槛的三大质疑,指出 Skills 在灵活性、可维护性和自我迭代方面的显著优势。 Claude CodeAgentWorkflow自动化Skill架构设计LLMAI # 你可能不再需要 workflow,大部分场景 skills 足矣——五步框架把 Workflow 变成可进化的 Skill **作者**: 宝玉 **日期**: 2026-01-09T15:32:54.000Z **来源**: [https://x.com/dotey/status/2010176124450484638](https://x.com/dotey/status/2010176124450484638) ---  “80 多个节点的 workflow,稳定性和可调整性,不是 subagent 能比拟的。” 上面这话这是我在 X 上和朋友 pippingg 的一次围绕 Dify 这样可视化拖拽 workflow 和 Claude Code Skills 的一次讨论。 这话对,也不对。 对在哪里?传统 workflow 编排的确有它的核心价值——每次执行结果可预测,出了问题能一步步排查,普通人也能看懂流程图。这些优势实实在在。 不对在哪里?很多人低估了 AI Agent + Skills 架构的潜力。我的观点是:大部分 workflow 编排场景,都可以被 Agent + Skills 取代。 ## Workflow 编排的“舒适区” 可视化工作流工具能火起来,是有道理的。 拖拽节点、连连线,一个自动化流程就搭好了。不用写代码,改起来也直观。更重要的是,它给你确定性——节点 A 执行完一定是节点 B,不会突然跳到节点 C。对于需要审计、需要合规的业务场景,这种确定性很重要。 但 workflow 编排也有硬伤。 它不够强大。可视化节点能做的事情有限,复杂逻辑很难表达。 它不够灵活。一旦流程定死,遇到输入变化就容易出错。你设计的流程是处理 A 类文档的,来了 B 类文档,整个流程可能就卡住了。 它难以移植。你搭了个很厉害的工作流,想给别人用?导出导入一通操作,还得在对方环境里调半天。平台锁定效应明显。 ## Agent + Skills 的"降维打击" 我的看法可能比较激进:几乎所有能用 workflow 完成的 AI 任务,都可以用 Agent + Skills 实现。 关键在于怎么理解 skill。很多人把 skill 当成单一技能——比如一个 skill 负责翻译,另一个负责总结。这样用太浪费了。 Skill 应该被看作可组合的模块。你可以把多个 skill 串起来,用自然语言描述它们之间的协作关系。换句话说,用自然语言去编排工作流,而不是用拖拽。 我总结了一个五步框架,用我自己的写作工作流来演示。 第一步,拆分 把工作流拆成单一职责的 skill 或 subagent。每个模块只做一件事,做好一件事。 以我的写作工作流为例,拆成了这些模块: - `article-analyzer`:分析素材,输出 analysis.md - `outliner`:生成 2-3 个提纲方案 - `writer-agent`:根据提纲写草稿(可并行启动多个) - `polish`:润色定稿 再看配图工作流,也是同样的思路: - `generate-image`:原子技能,调用图像生成 API - `article-illustrator`:组合技能,分析文章内容,在需要视觉辅助的位置生成插图 - `cover-image`:组合技能,基于文章内容生成 2.35:1 的封面图 然后写作和配图又可以组合成一个更完整的写作工作流。 你原来在 workflow 工具里画的每个功能节点,基本都可以对应一个 skill。 第二步,编排 在主 skill 里用自然语言描述整个流程。不需要写代码,就像给同事交代任务一样说清楚就行。 比如我的 outliner 技能里会写:“先调用 article-analyzer 分析素材,分析完成后保存 analysis.md,然后根据分析结果生成 2-3 个不同风格的提纲方案,为每个方案并行启动 writer-agent 写草稿。” 条件分支、并行执行、错误处理,都可以用自然语言描述。Agent 能理解。 再看 article-illustrator 的编排逻辑:“读取文章内容,识别需要配图的位置(概念抽象处、信息密集处、情感转折处),为每个位置生成图像描述,调用 generate-image 生成图片,最后将图片插入文章对应位置。” 一个 skill 可以调用另一个 skill,组合出复杂的工作流。  第三步,存储 这一步特别重要:所有中间结果都保存成本地文件。 三个好处: - 可追溯:出问题了能看到每一步的输出 - 可断点续传:中途停了,下次从上次的位置继续 - 可人工干预:不满意某一步的结果,手动改完让 Agent 继续 我的文件结构是这样的: > source.md → analysis.md → outline-a.md → draft-outline-a.md → final.md 每一步的产出都有迹可循。配图流程同理,生成的图片按目录组织,和文章关联。  第四步,分摊 Subagent 之间只传文件路径,不传内容。 这条规则很重要。如果你把一大段内容直接塞给 subagent,上下文窗口很快就撑满了。但如果只传路径,subagent 自己去读文件,上下文就干净很多。 我的 writer-agent 启动时只需要三个参数:source 文件路径、analysis 文件路径、outline 文件路径。它自己读取内容,写完保存到指定路径,返回输出文件路径。 这样做还有个好处:可以并行启动多个 subagent。三个 writer-agent 同时跑,各自处理一个提纲方案,互不干扰。  第五步,迭代 这是 Agent + Skills 相比传统 workflow 最大的优势:可以持续进化。 发现某个 skill 的提示词不够好?让 Claude Code 帮你改。某个流程步骤可以优化?随时调整。你的 skills 会越用越好,而不是搭完就放在那儿吃灰。 这一点是 pippingg 在讨论中特别强调的:subagent 可以自己迭代 system prompt,配合一些自动化工具,甚至能完成自我迭代进化。在 token 和系统资源充足的情况下,这套系统会变得越来越强。  ## 正面应对三大质疑 有人会说:你这套东西听起来挺美,但…… 质疑一:稳定性怎么办? 这是最有力的反驳。80 个节点的 workflow 确实经过了反复验证,每个分支都测试过,稳定性有保障。Agent 呢?每次执行可能走不同的路径,结果不可预测。 我的回应是:确定性逻辑不一定要交给 Agent。 你可以把需要确定性的部分写成脚本。那 80 个节点里,有多少是需要 AI 判断的?有多少只是固定的数据处理?固定的部分用脚本实现,skill 调用这个脚本就行。 举个例子,我的写作流程里有个格式化步骤:把中文引号换成全角、中英文之间加空格。这种规则明确的操作,我写了个 `format-markdown.ts` 脚本。polish 技能执行完润色后,自动调用这个脚本处理格式。 Anthropic 在设计 Skills 时也强调了这一点:“Skills 可以包含可执行代码,用于那些传统编程比 token 生成更可靠的任务。”这是混合架构的思路:代码处理确定性逻辑,Agent 处理需要判断的任务。两者各司其职,取长补短。 质疑二:成本太高 没错,Agent 执行确实更费 token。每调用一次模型都在烧钱,复杂任务可能要调用几十次。 但成本要算总账。 - 开发成本:workflow 的节点要一个个配,skill 可以用自然语言描述。后者更快。 - 维护成本:workflow 改起来要小心翼翼怕影响其他节点,skill 改起来更灵活。 - 迭代成本:workflow 优化需要人工分析,skill 可以让 AI 帮你改进。 几个案例很说明问题。 Rakuten(乐天) 用 Claude Skills 处理财务报表,自动处理多个电子表格、捕捉关键异常、按公司流程生成报告。原本一天的工作现在一小时完成,8 倍效率提升。 Box 用 Skills 让用户可以即时将存储的文件转换为 PowerPoint、Excel、Word 文档,并自动遵循企业风格指南。为团队节省了数小时的手工操作。 这些案例说明:token 成本在整体效率提升面前根本不算什么。而且 Skills 采用“按需加载”的设计——只加载当前任务需要的信息,而不是把所有上下文都塞给模型。这本身就是在优化成本。 质疑三:门槛太高 把 workflow 转化成 skill 需要抽象能力。普通用户搭可视化流程可以,让他写 skill 配置文件?太难了。 但这个问题正在被解决。AI 本身就能帮你创建 skill。借用 `/skill-creator`,你把需求描述清楚,Claude Code 可以帮你生成 skill 的配置。我自己就是这么干的——很多 skill 不是我手写的,是让 AI 帮我生成然后再调整。 长期来看,skill 比 workflow 更易维护。因为它是文本文件,可以用 Git 管理版本,可以代码审查,可以在不同机器间同步。Workflow 呢?锁在平台里,换个环境就得重来。 ## 边界在哪里 我不是说 workflow 毫无价值。两种方案各有适用场景。 Agent + Skills 更适合: - 输入多变、需要判断的任务。比如处理不同格式的文档,分析各种类型的数据。Agent 可以根据输入灵活调整处理方式。 - 跨系统协调的复杂流程。需要调用多个 API、访问多个数据源、协调多个工具。Agent 配合 MCP(Model Context Protocol)可以即插即用地接入各种服务。 - 需要频繁迭代的工作流。今天这样做,明天可能要调整。Skill 改起来比 workflow 方便得多。 - 需要分享复用的自动化逻辑。Skill 就是几个文件,打包发给别人就能用。比导出 workflow JSON 再导入方便多了。 Workflow 仍有优势的场景: - 严格审计要求的合规流程。金融、医疗这类行业,每一步操作都要可追溯、可审计。固定的 workflow 更容易满足监管要求。 - 超高频执行的简单任务。每秒执行几百次的简单操作,固定脚本比 Agent 划算得多。 - 非技术用户的可视化需求。让业务人员自己看懂、自己调整流程,可视化编排确实更友好。 ## 一个被低估的优势:可进化 Skill 架构有个经常被忽略的好处:它是活的,可以不断进化。 传统 workflow 一旦搭好,基本就定型了。改动需要人工介入,要小心测试,改完可能还会引入新问题。 但 skill 不一样。它是基于本地文件系统的,你可以让 Claude Code 帮你维护更新。用了一段时间,积累了一些问题,直接让 AI 分析并改进。 更激进一点的玩法是 pippingg 提到的:subagent 可以自我迭代 system prompt。 听起来有点科幻,但已经有人在实践了。 McKinsey 的报告也印证了这一点:在一个法律文档审核流程中,agent 系统会记录每次人工修正,然后用这些反馈来改进自己的 prompt,逐渐将新的专业知识编码进系统。 这意味着什么?你投入时间打造的 skill,会随着使用越来越好。而不是像 workflow 那样,搭好就开始慢慢过时。  --- 把你常用的 workflow 沉淀为 skill 吧。这不只是换个工具的问题,而是在积累可复用、可进化的自动化资产。 下次有人说“这个流程太复杂,只能用 workflow”,不妨想想:真的吗?还是只是没找到正确的拆分方式? ## 相关链接 - [@dotey](https://x.com/dotey) - [22K](https://x.com/dotey/status/2010176124450484638/analytics) - [Jan 9](https://x.com/dotey/status/2009649588442140907) - [@dotey](https://x.com/dotey) - [9.5K](https://x.com/dotey/status/2009649588442140907/analytics) - [Jan 9](https://x.com/dotey/status/2009474762070691904) - [39K](https://x.com/dotey/status/2009474762070691904/analytics) - [analysis.md](https://analysis.md/) - [analysis.md](https://analysis.md/) - [source.md](https://source.md/) - [analysis.md](https://analysis.md/) - [outline-a.md](https://outline-a.md/) - [draft-outline-a.md](https://draft-outline-a.md/) - [final.md](https://final.md/) - [Jan 9](https://x.com/Suyanzhenq/status/2009496471234912751) - [@dotey](https://x.com/dotey) - [9.8K](https://x.com/Suyanzhenq/status/2009496471234912751/analytics) - [Upgrade to Premium](https://x.com/i/premium_sign_up) - [10:25 AM · Jan 11, 2026](https://x.com/dotey/status/2010176124450484638) --- *导出时间: 2026/1/11 15:56:01*
H How to master graph engineering 本课程教授如何构建 AI 智能体图,涵盖图的基本概念、关键模式(如菱形模式)、停止规则及人工审批环节。包含三个实战案例:深度研究台、SEO 内容生成器和市场推广套件,旨在提升业务效率并控制成本。 技术 › Agent ✍ Machina🕐 2026-07-23 AgentGraphLLMClaudeWorkflow工程化自动化架构设计效率实战
C Claude Code Dynamic Workflows:把编排逻辑搬进代码的新原语 Anthropic 推出的 Claude Opus 4.8 引入了 Dynamic Workflows 功能,旨在解决大型代码库迁移和复杂任务编排的难题。该功能通过将编排过程生成本地 JavaScript 脚本,利用运行时管理逻辑,突破了传统 Agent 上下文窗口的限制,实现了对海量并行任务的高效处理。文章详细解析了其与 Subagent 和 Agent Teams 的区别、核心架构、脚本编写规范以及触发机制。 技术 › Claude ✍ riba2534🕐 2026-05-30 ClaudeClaude CodeDynamic WorkflowsAgentLLM架构设计开发工具自动化
如 如何编写工业级 Agent Skill 指南 文章深入探讨了如何编写高质量的工业级 Skill(AI 技能/工作流)。文章指出 Skill 不同于简单的 Prompt,它需要具备按需加载、限制工具边界、配置适配模型、分层管理内容(SKILL.md 与 references/scripts 分离)以及建立评估测试闭环等特性。通过遵循最小权限原则、渐进式披露和迭代验证,可以将经验固化为稳定、可维护的自动化工作流。 技术 › Skill ✍ Ren🕐 2026-05-04 AgentSkillCLAUDE.md工程化提示词技巧WorkflowDevOps自动化最佳实践Claude Code
解 解剖 Skill:Skill 工程化实战指南(二) 文章深入剖析了 AI 编程中 Skill 的内部结构与生命周期。作者指出 Skill 不仅是高级 Prompt,而是包含元数据、入参结构、核心提示词及执行器的标准件。文章详细解释了 Skill 从注册发现到意图匹配再到沙盒执行的全过程,并提出了判断何时封装 Skill 的三个标准,旨在帮助开发者通过工程化手段稳定 AI 输出。 技术 › Skill ✍ 老金🕐 2026-04-30 AI工程化LLMClaude CodeSkill代码审查Agent开发工具技术原理架构设计Schema
A Agent 开发的惨痛教训:移除封装,拥抱原生 文章阐述了 Agent 开发中的“惨痛教训”:不应过度封装 LLM 及其工具。作者指出,通过提供最小化的辅助脚本(如 CDP 接口)和 SKILL.md,让 LLM 直接访问底层能力,能够显著提升其自主解决问题的能力。这种“自愈循环”机制使得 Agent 能在遇到缺失功能时自动编写代码修复,无需人工预设复杂的中间层。 技术 › Agent ✍ Gregor Zunic🕐 2026-04-24 AgentCDPLLMBrowser Use工程实践Claude Code自动化架构设计
我 我做了个 Skill:让 AI 帮你生成 Logo 和图标 本文介绍了作者开发的一个名为 Logo Generator 的 Skill,旨在解决开发者和开源项目缺乏专业 Logo 的痛点。该 Skill 利用 Gemini 强大的 SVG 生成能力,通过信息收集、生成设计变体、制作高级展示图三步流程,快速生成“够用的好 Logo”。文章详细阐述了其工作原理、12种静态背景与6种动态 WebGL 背景的展示方案,以及 SVG 相比图片生成在精度和可编辑性上的优势。 技术 › Skill ✍ 歸藏(guizang.ai)🕐 2026-04-16 AILogo设计SVGGeminiSkill开源工具前端设计AgentWorkflow自动化
s skill-refiner — 一个让你的长程 skill 更听话的 skill 针对 Agent 长程任务中常见的跳步、幻觉和状态丢失问题,作者开发了 skill-refiner 工具。该工具基于 FSM(有限状态机)设计,通过三原语约束执行流程。此外,它还提供了通过强模型改写提示词以降低弱模型运行成本的策略。 技术 › Agent ✍ Hytidel聊商业🕐 2026-04-05 AgentSkillLLMWorkflow提示词工程FSM自动化工具开发
技 技能链:将智能体技能重新定义为情境行动 本文探讨了智能体系统中技能实现的局限性,指出技能不应是静态提示,而应是动态的情境行为。作者介绍了在 Slate 系统中通过引入“线程”和“分叉”机制,实现了上下文隔离的自动化技能调用,并提出了“编排技能”的概念,即通过组合其他技能来完成复杂任务链。 技术 › Skill ✍ akira🕐 2026-04-02 AgentLLM智能体SkillSlate技能链架构设计上下文管理自动化多智能体
A Agent Skills 复利工程:你的烂笔记比代码值钱 文章介绍了“复利工程”的理念,即利用 Claude Code 等 AI Agent 审计个人技术笔记,自动提取出可复用的 Agent Skills。作者通过实战演示,将 200 多篇零散笔记转化为 4 个高优先级的自动化技能,从而将一次性解决问题的经验固化为系统永久能力,实现知识的指数级复利积累。 技术 › Agent ✍ 吕立青_JimmyLv🕐 2026-03-25 AgentClaude Code复利工程Skill知识管理自动化工作流LLM效能工具技能提取
装 装完 Codex 不知道干什么?这 6 个 GitHub Skills 让你做视频搞钱 文章介绍了 6 个适用于 Codex 的 GitHub Skills,涵盖动效生成、视频剪辑、批量制作、AI 生成及中文剪辑等工具,帮助用户构建自动化视频工作流以提升效率。 技术 › Codex ✍ Kay🕐 2026-07-30 Codex视频制作AgentSkill自动化HyperFramesRemotionAI剪辑工作流
如 如何利用AI构建和扩展单人企业 文章介绍了利用AI构建和扩展单人企业的完整蓝图。通过使用AI员工(如Viktor)在内容、项目、拓展、财务和广告五个领域实现自动化,只需保留决策环节。文章探讨了两种构建方式:快速路径和自定义构建,强调业务知识库和操作规则的重要性。 技术 › Agent ✍ Machina🕐 2026-07-26 AI单人企业自动化Agent生产力Viktor商业模式知识库LLM效率
管 管理 AI 员工团队:Ryan Carson 的高效工作系统 Ryan Carson 分享了如何作为唯一员工,通过管理云端 AI Agent 团队日处理 40 个 Pull Request 的经验。文章详细介绍了将工作迁移至云端、建立工作节奏、将重复检查自动化以及控制 Token 成本四个关键步骤,强调在 AI 时代,优秀的工程管理能力比以往任何时候都重要。 技术 › Agent ✍ The Startup Ideas Podcast (SIP)🕐 2026-07-25 AIAgentDevin工程管理自动化云端开发成本控制DevOpsLLM