Skills 还是 Workflows：Mistral 两种 AI 自动化方案怎么选，决策框架加代码示例

一句话结论

Skill 是给智能体加”能力”，一个 markdown 文件几分钟搞定；Workflow 是在基础设施上编排”流程”，能扛住崩溃、暂停等人审批、留下完整审计——选错方向，要么过度工程化简单任务，要么给关键流程埋雷。

一个真实场景引出的问题

最近宣布 Connectors 进入 Workflows 后，Mistral 在示例应用里加了一个工作流：每周汇总 Linear 工单。第二天和同事演示时，一位工程师展示了他们为 Vibe 写的 Agent Skill 文件——同样从 Linear 工单生成汇总、每周加进 Notion 规划。

这让我意识到 Skills 和 Workflows 都能做 AI 方案，但运作方式截然不同。那怎么决定用哪个？

作为开发者，你现在有 Skills、Agents、Connectors 和 Workflows，都能处理多步 AI 任务自动化的组成部分。但它们的设计哲学根本不同，选错意味着要么把简单任务过度工程化，要么给关键流程建设不足。

这份指南全部拆解：每个工具的定位、正面对比、具体的决策框架，以及个人和企业场景的真实代码示例。

Skills 是什么

Skills 是可复用的智能体级扩展，给 Vibe 新能力。它们遵循开放的 Agent Skills 规范。

用 Vibe CLI 时，Skills 放在 ~/.vibe/skills/（全局）或 .vibe/skills/（项目本地）。

在 Vibe Work 里，Skills 可以通过选择菜单加进对话，或用斜杠命令调用。

关键心智模型： Skill 是你加给智能体的一个能力。Workflow 是你在基础设施上编排的一个流程。Skills 跟着开发者或用户走；Workflows 活在平台上。

Skill 怎么定义

每个 Skill 是一个目录，内含带 YAML frontmatter 的 SKILL.md 文件。你可以让 Vibe 基于你想完成的任务帮你写 Skill，然后加进你的库。

这是一个 PR 审查 Skill 示例：frontmatter 写 name 为 pr-review、description 为 Automated code review for pull requests、allowed-tools 列出 read_file/grep/ask_user_question；正文写”你是做代码审查的高级工程师，被 /pr-review 调用时分析暂存 diff 并做四件事：识别安全、性能和逻辑问题；标记缺失测试；建议命名和结构改进；输出带严重级别（critical/warn/info）的结构化审查”。

Skills 能做什么：

• 作为斜杠命令加载——在 Vibe 会话里用 /skill-name 调用。

• 限制工具访问——精确定义 skill 能调哪些工具（read_file、grep、bash 等）。

• 跨团队共享——把 .vibe/skills/ 目录提交进仓库。

• 用户级或项目级作用域——全局 skill 处处可用；项目 skill 在正确目录自动加载。

• 驱动自定义智能体和子智能体——Vibe Code 子智能体可以带特定技能集被委派。

Skills 适合的场景： 你在扩展智能体在会话里会做什么。任务是交互式的、短生命周期的、或绑定开发者工作流的。你想要约定强制的行为而不需要平台基础设施。你想要一个你和团队随需调用的 /command。

Workflows 是什么

Workflows 于 2026 年 4 月公开预览，是 Mistral Studio 的一部分。它是根本不同的产品：面向需要扛住崩溃、暂停等人审批、失败重试、留下可审计轨迹的多步 AI 流程的生产级编排引擎。

底层由 Temporal 驱动——Netflix、Stripe 和 Salesforce 用的同一套容错编排引擎。Mistral 加了 AI 专用原语：流式 LLM 响应、大载荷处理、智能体循环和 OpenTelemetry 可观测性。

架构是混合的：Mistral 托管编排器（状态、历史、任务分发），你的 worker 代码跑在自己的环境——笔记本、Kubernetes 集群或私有云 VPC。

核心概念：

• Workflow——决定什么以什么顺序运行的确定性编排逻辑。

• Activity——实际的工作单元（一次 LLM 调用、一次数据库写入、一次 API 请求）。

• Execution——带自己 ID、事件历史和结果的单次运行。

• Deployment——共享定义和任务队列的一组 worker。

Workflows 的超能力

• 持久执行——每步都有记录。worker 崩溃后另一个从精确断点继续。

• 长时间编排——工作流可以从秒级跑到月级，在外部事件或人工信号上暂停。

• 一行代码的人在环——单个 SDK 调用暂停工作流等待审批，从 Vibe Work、webhook 或任何连接面恢复。

• 默认可观测——事件实时流出；完整执行历史可查询。OpenTelemetry 追踪无需额外接线。

• 处处可触发——通过 Mistral API、Mistral Studio、Vibe Work 作为助手、或按计划（cron 式）。

• 数据驻留控制——SDK 层载荷加密，或把大载荷卸载到你自己的存储桶。

Workflows 适合的场景： 你在建业务流程，不只是开发者便利。步骤必须扛住重启。有人需要在继续前审批。你需要六个月后的审计轨迹。多个智能体需要互相交接状态。任务按计划跑或被外部系统触发。

Skills 与 Workflows 全面对比

最好理解的办法是逐项对比功能和设置要求。

存放位置：Skills 是 ~/.vibe/skills/ 或 .vibe/skills/ 里的 SKILL.md 文件；Workflows 是部署到 Mistral Studio 的 Python 代码加你基础设施里的 worker。

运行方式：Skills 加进 Vibe Work 或 Vibe Code 按需触发；Workflows 灵活运行——也能在 Vibe 里，还能被 webhook、调度器等触发。

调用方式：Skill 是会话里的斜杠命令；Workflow 是 API 调用、Studio 界面、Vibe Work、webhook 或 cron 计划。

执行持久性：Skill 无状态、绑定会话；Workflow 完全持久——扛住崩溃和重启。

可观测性：Skill 只有会话内可见的工具调用；Workflow 有完整 OpenTelemetry 追踪和可查询事件历史。

重试：Skill 手动处理；Workflow 每个活动一等重试加可配置退避。

人在环：Skill 是智能体在会话中提问；Workflow 暂停等待信号、从任何界面恢复。

定时调度：Skill 不支持；Workflow 内置 cron 和一次性计划。

多智能体交接：Skill 靠会话内子智能体；Workflow 共享状态、跨智能体交接和并行执行。

审计合规轨迹：Skill 无持久轨迹；Workflow 每个分支、重试和状态变更都有记录。

搭建复杂度：Skill 是一个 markdown 文件——几分钟创建；Workflow 需要 Python SDK、worker 部署和 Mistral Studio 设置。

团队共享：Skill 提交 .vibe/skills/ 进仓库；Workflow 发布到 Studio，业务用户经 Vibe Work 访问。

数据驻留：Skill 留在你的 Vibe 会话/本机；Workflow 混合模式，载荷加密加卸载到你的云。

什么时候不要用：不该用 Skills 的场景是必须扛住崩溃或跑几小时的多步流程；不该用 Workflows 的场景是终端里简单、交互式、一次性的开发者任务。

试验一个方案想法时，用 Skill 很有帮助，因为迭代指令快速简单。但借助 Workflows SDK 和入门应用里的 Skills，迭代 Workflows 代码也比想象中直接。如果你知道方案需要确定性结果，别怕用 Workflows 建。

真正的张力：智能体式与确定性

上面对比表映射的是持久性、调度、搭建成本这些可观察差异。但 Skills 与 Workflows 之间更深的张力关于行为如何表达：智能体自己推理着完成任务，还是代码冻结了特定的步骤序列。

写 Skill 时，你给智能体一组指令和工具，然后让它自己琢磨怎么满足请求。这种灵活性强大。

同一个 /ship-check skill 在小型 Python 工具上能用，换到单体仓库或 TypeScript 项目上不用改代码也能用。智能体读上下文、决定调哪些工具、什么顺序、迭代到合理结果。

这种适应性的代价真实存在：推理的每一步都在烧 token——加载 skill、理解任务、决定调什么工具、处理结果、决定下一步。对一天交互式跑几次的任务，这成本没问题。

对按计划对着几千条记录跑的任务，成本快速复利。

确定性工作流做了不同的取舍。工作流开发者已经完成了推理：研究问题、识别步骤、把它们编码成代码里的活动。

工作流不想下一步做什么；它已经知道。这既是限制也是力量。

你失去了智能体对新颖、模糊、依赖上下文任务的适应性；你获得可复现性、更低的单次运行 token 消耗、以及可推理、可监控、可优化的可预测执行画像。当你的文档分类管线处理过一万份合同、每个活动的提示词都已调优，你大概不想一个通用智能体每次调用都重新推导同样的策略。

这个框架也澄清了什么时候用混合方案。工作流可以包含智能体式步骤——比如一个活动调用 LLM 处理判断题——周围用确定性编排处理路由、重试和状态持久。需要智能体灵活性的地方得到灵活性，其他所有地方得到 Workflow 的可靠性。

本地与远程：另一根轴

智能体/确定性的区分关于任务怎么跑。本地/远程的区分关于任务在哪跑、那个环境给你什么保证。

Skill 本地跑、在 Vibe 会话内跑，意味着执行随会话而生灭。关掉终端智能体就停了。

笔记本断网任务就失败。会话没有之前运行的记忆、没有外部触发机制、没有会话窗口之外审计轨迹。

对交互式、面向开发者的工作，这些是可接受的取舍——你在场、能重启、任务够短不重要持久性。

工作流远程跑意味着把执行交给对任务完成负责的基础设施。Mistral 托管编排器；你的 worker 代码可以跑在任何地方，但跟踪已发生和待发生的状态机被持久管理。

工作流扛住 worker 重启、网络分区和部署。它可以暂停数天等人工信号、从精确断点恢复。

它生成独立于触发者的可查询事件历史。对睡觉时也在跑、或无论瞬时故障都必须完成的任务，远程执行不是可选项——这正是全部意义所在。

有趣的是两轴交叉的地带。现在，带完整可观测性、持久性和审计地远程跑一个 Skill，还开箱即配置不出来。

但下一代 Agents 可能把让 Skill 强大的智能体循环带进工作流运行时——同一个智能体加载同一个 Skill，开发时本地跑求便利，生产时远程跑，接入 Workflows 基础设施的一切：可观测、持久、人在环、审计轨迹。Skill 文件不变，变的是执行环境和它提供的保证。

从智能体式到确定性的路径

沿这两根轴思考最有用的推论之一：它们提示了构建生产系统的自然进程，而不是一次性决策。

任何新自动化的正确起点几乎总是智能体式。你不知道确切需要哪些步骤，不确定哪些边界情况存在。

你写一个 Skill，或配一个无硬编码逻辑的智能体式 Workflow，让模型自己搞清楚。这个阶段你要的是高于一切的灵活性。

智能体适应、优雅处理意外输入、向你展示方案空间实际长什么样。你还从第一天起就获得 Workflow 运行时的可观测性：每次运行被追踪、每次工具调用被记录、每个决策可查询。

一旦积累了足够多的运行、理解了问题的形状，更强大的事情成为可能。第二个流程（也是一个工作流）审视智能体跨这些运行实际做了什么。

它识别哪些步骤持续重复、哪些工具调用每次顺序相同、哪些分支从未走过。基于这个分析，它提出确定性或半确定性的编码化：一个把已理解部分冻结成显式活动、把真正可变部分保留智能体调用做判断的 Workflow。

结果是做同样工作但 token 成本是零头、吞吐量高得多的 Workflow。你每次推理花费更少、减少 GPU 时间、获得可复现可监控的流程——不必从第一性原理推导正确实现。

这是行业正在建设的方向：智能体执行作为原型环境，确定性工作流代码作为从观察行为中涌现的生产工件。对开发者的启示是：不必被迫预先决定某件事该是 Skill 还是确定性 Workflow。

从智能体式开始、收集追踪、让执行历史引导你走向具体用例的正确确定性水平。基础设施支持光谱两端和中间地带。

个人场景

个人开发者是 Skills 的主要受众，因为它们快、开销低、正好嵌入你已有的 Vibe Code 和 Vibe Work 工作方式。

Skill 个人用例：

• 按需 PR 审查：/pr-review 读暂存 diff、检查测试覆盖、标记安全模式、推送前输出结构化审查。

• 提交信息生成器：/commit 读 git diff、识别变更范围和类型、生成符合团队约定的提交信息。

• 文档生成器：/docs 为指定文件或函数生成 docstring、README 章节和 API 文档，尊重项目已有文档风格。

• 测试编写器：/test 读模块并生成匹配现有测试框架和模式的单元加集成测试。

Workflow 个人用例：

• 每周收件箱汇总：每周一早 8 点定时运行，经 Connectors 读 Gmail/Outlook，合成优先级摘要发到 Slack。
• 通宵 PR 智能体：日终触发：挑出标记 agent-ok 的 GitHub issue，写代码、在沙箱会话跑测试、开好 PR 等第二天早上审查。

企业场景

企业层面天平向 Workflows 大幅倾斜，因为企业 AI 需要持久性、一致性和日志记录。客户交接超时或文档处理上下文丢失时，需要可追溯且易解决。话虽如此，企业环境里仍有适合 Skills 的常见任务。

Skills 在企业的位置：

• 规模化开发者生产力：把共享 Skills 提交进单体仓库的 .vibe/skills/ 目录，让 PR 审查、文档生成和代码迁移约定在工程组织标准化。每个工程师自动获得同样的质量基线。

• 代码库感知的入职：/onboard skill 读你的 AGENTS.md 和项目结构，用 Vibe Code 为新人生成引导式代码库走读。

• 安全扫描：/security-scan skill 对会话中每个被触及的文件运行，推送前检查硬编码密钥、OWASP top-10 模式和许可违规。

Workflows 在企业的位置：

• 文档处理管线：提取、分类和路由进来的合同或发票。每个路由决策在 Studio 可追溯。

分类错误时在工作流层修正——不必从头重跑。（ASML、CMA-CGM 和 La Banque Postale 已在跑这个模式。

）

• 客服自动化：分析进线工单、按意图和紧急度分类、路由到下游流程、置信度低时浮出人工升级步骤——每个路由决策有完整审计轨迹。
• 合规门审批：多步流程（贷款处理、供应商准入）必须暂停等合规官审查后继续。

审查者从 Vibe Work 或 webhook 批准。工作流带着完整历史恢复。

• 通宵批量报告：定时工作流从连接数据源聚合指标、经 Mistral 智能体跑分析、在团队上班前把格式化报告投递到 Slack 频道或邮箱。
• 多智能体代码现代化：一个工作流编排研究子智能体（映射遗留模式）、转换子智能体（应用现代化改造）和验证子智能体（跑测试和 diff）——跨数千文件——带检查点保存，中断不丢工作。

代码与 Skill 示例

到目前为止我们比较了使用 Skills 和 Workflows 的功能与收益、过了决策框架、讨论了个人和企业环境的常见用例。把它们带到一起，通过几个高层代码例子实践一遍。

示例一：一个实用的 Lint 加文档 Skill。 开发者在 Vibe Code 输入 /ship-check 时，这个 skill 同时触发 lint 检查和文档补全。

提交进仓库让所有贡献者共享同一个发布前质量门：frontmatter 声明 allowed-tools 为 read_file/grep/bash/ask_user_question，正文分四步——Lint 跑 ruff check . 或 eslint src/，Test Coverage 检查改动文件有无对应测试文件，Docs 为 diff 里新增或修改的公开函数验证 docstring 存在并生成缺失的桩，Summary 输出带优先级修复清单的 ship/no-ship 结论。只关注 git diff --staged 的文件，未经用户确认不改生产文件。

示例二：PR 审查专用子智能体。 给 skill 配一个自定义智能体档案，让它在受限的只读上下文运行——auto-approve 下也安全因为不能写文件。

档案放 ~/.vibe/agents/pr-reviewer.toml：display_name 设 PR Reviewer，safety 设 safe，agent_type 设 subagent，auto_approve 开 true，enabled_tools 只给 read_file、grep、bash。

示例三：你的第一个持久化 Workflow。 这是 Workflows 文档的经典 hello-world，给出最小但完整的工作流结构：类型化输入、一个活动（真正的副作用工作单元）、一个把它们接起来的工作流类。

用 uvx mistralai-workflows-cli@latest setup 可以在自己的环境脚手架这个项目。

Python 代码三个部件：HelloInput 继承 BaseModel 定义 name 字段；@workflows.activity() 装饰的 greet 函数返回问候语；@workflows.workflow.define 装饰的 HelloWorkflow 类里，@workflows.workflow.entrypoint 标记的 run 方法调用 greet 返回结果。

示例四：带人工审批的生产级 Workflow。 这个模式实现合同审查流程：LLM 提取关键条款，风险分析活动标记关注点，然后工作流暂停等合规官批准。和所有 Workflow 一样在 Studio 留下完整执行追踪。

Python 实现里 ContractInput 定义 contract_text、contract_id、submitter_email 三字段；extract_key_clauses 活动让 mistral-medium-latest 从合同文本提取责任、付款和知识产权条款；flag_risk 活动让模型给条款打 1-10 风险分并列出需法律审查的条款；contract-review 工作流的 run 方法串联两个活动后，调用 self.wait_for_signal(signal_name="compliance-decision", timeout_seconds=7*24*3600)——一行暂停等审批，窗口七天，执行留在 Studio 带完整追踪。

示例五：定时通宵批量报告 Workflow。 展示每个工作日早 7 点触发的工作流：聚合 Jira 产出、合成通俗语言摘要、全自动全可追踪地发到 Slack。

实现里 fetch_jira_metrics 活动从 Jira REST API 拉本周关闭的工单数；generate_summary 活动让 mistral-small-latest 把原始指标写成友好的 Slack 周报文案；post_to_slack 活动用 httpx 把消息推到 webhook。Studio UI 里配 cron 0 7 * * 1-5 即可。

底线

Mistral 生态通过 Skills 和 Workflows 提供两种根本不同的自动化原语，选哪个取决于问题的性质而非复杂度。

选 Skills 当： 你在扩展智能体在会话里能做的事；任务交互式且面向开发者；搭建时间重要（分钟不是小时）；不需要审计轨迹；你想要 Vibe 里的 /斜杠命令 体验。

选 Workflows 当： 崩溃不能丢进度；有人必须在流程中途审批；你需要审计轨迹（合规、监管行业）；任务按计划跑而没有开发者在场；多个智能体需要交接状态。

两者坐在同一个生态里且组合得漂亮。你最好的生产配置很可能是：Skills 在 Vibe Code 里做开发者人机工程，Workflows 在 Studio 里跑真正运转业务的流程。

给选型者的操作参考

拿不准时的四步判断法：第一步问”这个任务失败重跑的代价大吗”——代价大选 Workflow；第二步问”需要别人审批或按时间自动跑吗”——需要选 Workflow；第三步问”我只是想在终端里少打几个字吗”——是就写 Skill，几分钟的事；第四步按混合思路落地——先 Skill 起步收追踪，跑顺了把重复步骤冻结成 Workflow 活动，可变环节保留 LLM 调用，token 成本降一个量级。

原文信息

• 作者：MistralDevs（@MistralDevs），Mistral AI 官方开发者账号
• 发布时间：2026-07-01 原文地址：