在 2025 年的 10 月份，Anthropic 发布了 Claude 模型的一项重大更新的 Agent Skills，它允许用户将专业知识、脚本和资源打包成模块化的“技能文件夹”（Skill folders），让 AI 能在特定工作场景中更专业地执行任务。

如果我们在做行业 Agent、内部 Copilot、或想把 Claude Code / API 用在业务里，那就需要我们在做之前把「Skill」和「行业 Workflow」这两件事想清楚，并知道从哪里下手。

1. Skill 和行业 Workflow 的概念

1.1 Skill 是什么？

简单说：

Skill = 给模型的一份可复用「操作说明书 + 流程模板」

在 Claude 体系里，Skill 是一个带 SKILL.md 的文件夹，它告诉模型：
“在什么情况下该用我、我要完成什么任务、要按什么步骤做、输出要长什么样。”

特点有几个：

• 面向具体任务，不是一个抽象的「能力标签」
  例如：生成符合公司品牌规范的 PPT，按照内部代码规范重构文件，按财务模板做对账报告。
• 本质上是文字写清楚的 SOP + 可选的脚本
  主体就是 Markdown 文档，有需要时再绑上 Python 脚本去做确定性处理。
• 可以被模型自动发现和按需加载
  模型不会一直把完整 Skill 塞在上下文里，只在命中时再读取详细内容。

它和我们平时说的「提示词」的区别在于：
提示词是一次性、散落的；Skill 是结构化、可版本化、可共享的。

1.2 行业 Workflow 是什么？

Workflow 可以理解为：

把行业中的业务流程，做成清晰的步骤编排和 IF-ELSE 逻辑。

过去这些东西已经存在于：

• 各种脚本、RPA、BPM 系统
• 系统之间的 API 调用编排
• 内部运维 / 运营同学脑子里和文档里的 SOP

在 Agent 语境下，我们关心的是一件事：

怎么把这些已有流程封装成「可由 Agent 触发、可观测、可审计」的工作流节点。

行业 Workflow 的关键特征：

• 强约束：
  对输入 / 输出有严格格式要求，执行过程里有清晰的分支、回滚、告警。
• 强依赖业务 Know-how：
  为什么要这样分支，Why 在流程里，而不是在模型参数里。
• 长期稳定运行：
  一旦跑到生产，就不希望被大模型的「心情」影响。

2. Claude Code 的 Skill

在 Claude 的整体设计里，Skills 是一个非常核心的扩展机制。它解决了两个问题：

1. 如何在不撑爆上下文的前提下，给模型装很多垂直能力？
2. 如何让业务团队通过“写文档”的方式，而不是“写模型”的方式扩展能力？

2.1 一个 Skill = 一个带 SKILL.md 的文件夹

Claude 官方定义里，一个 Skill 的最小单元就是：

• 一个文件夹
• 里面一个 SKILL.md
• 也可以再带一些脚本、资源文件

官方给出的模板是这样的：

---
name: my-first-skill
description: 这是一个关于此 Skill 能做什么以及何时使用它的清晰描述。
---
# 我的第一个 Skill

[在这里添加您的指令，Claude 在激活此 Skill 时会遵循这些指令]

## 示例
- 用法示例 1
- 用法示例 2

几个要点：

• name：唯一标识，最好跟任务直接相关。
• description：非常重要，模型靠这个来判断「什么时候用你」。
• 正文部分：
  写清楚目标、步骤、注意事项、输出格式、示例。

只要这一个 Markdown 写好了，一个可用 Skill 就成立了，不需要额外的配置文件。

2.2 具体例子：PPT Skill

官方仓库里有一个 PPTX 相关的 Skill，SKILL.md 类似下面这种结构：

• YAML Frontmatter：说明 Skill 名称、用途（处理 PPTX）
• 正文：分章节写

  • 如何解析 PPTX
  • 如何修改版式
  • 如何保证品牌颜色与模板统一
  • 输入 / 输出约定
  • 示例调用方式

Claude 的做法是：

1. 会话启动时，只把所有 Skill 的 name + description 读一遍，放到系统级提示里。
2. 当用户输入与某个 Skill 的描述高度匹配时，Claude 再去把这个 Skill 的完整内容加载到上下文中。

这就是文档里提到的「渐进式披露（Progressive Disclosure）」机制。

2.3 渐进式披露

这个词其实有点装，但装得有点厉害，使用这种方式的原因很直接：Token 成本和性能。

• 初始加载时，每个 Skill 只占用几十个 Token（元信息）。
• 真正用到的时候，才把 SKILL.md 的主体搬进来。
• 如果 Skill 还拆成多个文件，Claude 只会读当前任务需要的那部分。

结论：我们可以放心装很多 Skill，而不用太担心上下文被占满。

2.4 Skill 里可以带代码

文档里也提到，Skill 可以带 Python 脚本等可执行文件。

用途主要有两类：

1. 做确定性计算 / 校验

   • 排序、过滤、格式校验
   • 比如：生成 GIF 之后检查文件大小是否符合 Slack 限制
2. 做简单的集成调用

   • 调一个内部 API
   • 读取一个本地文件，然后把内容返给模型

设计上，有一条很实用的边界：

• 流程和策略写在 SKILL.md
• 需要 100% 确定性 的步骤写在脚本里

模型不负责「每次都从零写代码」，而是调用你已经写好、已经验证过的代码。

3. Skill 和 Tool / MCP 的边界

很多人会把 Skill、Tool、MCP 混在一起，这里做个简单对比方便后面聊 Workflow。

3.1 Skill：教模型「怎么做」

• 把我们的 SOP、套路、模板，变成模型可执行的说明书。
• 适合：

  • 结构化写作
  • 格式转换
  • 合规校验
  • 数据清洗 / 整理
• 优点：

  • 写文档就能做定制
  • Token 成本可控
  • 容易版本化和团队共享

3.2 MCP / Tools：帮模型「去做」

• MCP 解决的是：如何以统一协议，让模型调用外部系统 / 数据源 / API。
• 它关注的是：

  • 怎么查 GitHub
  • 怎么调 CI/CD
  • 怎么查数据库
  • 怎么发 Slack 消息

简要总结就是一句话：Skill 面向流程，MCP 面向集成。

3.3 Skill + MCP 的组合

在一个典型任务里：

• MCP 负责：拿到需要的数据、执行动作
• Skill 负责：拿到这些结果后怎么分析、怎么生成符合规范的输出

这其实已经非常接近我们后面要讲的「Workflow + Agent」的拆分思路。

4. 行业 Workflow：Skill 落地的载体

前面讲的是 Skill 这一颗颗能力点”，接下来要看它们怎么和行业 Workflow 结合。

4.1 Agent 是交互方式，不是业务本身

再强调一次我们之前文章中的观点：Agent 是交互方式，不是业务本身

在行业里，Agent 更适合作为：

• 自然语言入口
• 意图理解与参数提取
• 初步判断和分发

真正的行业壁垒在于：

• 我们内部沉淀的 SOP
• 历史案例和边缘场景处理方式
• 审批链路和风控规则

这些东西，应该放在：

• Workflow 编排系统
• 规则引擎
• Skill + MCP 的组合

而不是「指望一个通用 Agent 自己学出来」。

4.2 为什么不能纯 Agent？

1. 幻觉和确定性冲突

   • 行业里很多流程（财务、生产、安全）对错误零容忍。
   • 1% 的错误率，对于 Demo 可以接受，对生产不行。
2. 过程黑盒，难以审计

   • Agent 的推理链路在模型内部
   • 出现问题难以复盘和归责
   • 很难满足合规和审计要求
3. 成本和延迟

   • 让模型去规划每个按钮、每个 if-else，是在烧算力
   • 这些确定性逻辑用传统代码 / Workflow 做更合适

所以，在企业 / 行业场景里，更现实的模式是：

Workflow + Agent
Agent 做理解和决策，Workflow 做执行和兜底。

5. 「Workflow + Agent」的混合架构

把前面的点合起来，可以得到一个常见的分层结构。

5.1 顶层：意图理解与路由（Agent）

职责只有三件：

1. 理解用户在说什么（意图识别）
2. 把需要的参数补齐（参数提取 + 追问）
3. 决定触发哪个 Workflow / Skill 组合（路由）

流程可以简单画成：

用户 → 自然语言
→ Agent：识别意图 + 提取参数
→ 选中对应 Workflow（或再转给某个二级 Agent）
→ Workflow 执行
→ 结果交给 Agent 格式化给用户

这一步里，Skill 可以怎么用？

• 把「意图分类规范」「参数提取规则」「话术模板」写成一个 Skill
• 在 Skill 里明确：

  • 出现哪些关键词 / 条件时，对应什么意图
  • 提取不到关键信息时，按怎样的模板向用户追问

5.2 中间层：RAG + 决策

有些问题不能直接映射到单个 Workflow，需要先查知识再决定走哪条路。

典型例子：

“设备报警 E03，我该怎么办？”

步骤一般是：

1. Agent 调用 RAG，在知识库中检索 E03 的说明和处理方案。
2. Skill 里定义好：

   • 如何解释错误码
   • 不同错误码对应的处理选项
3. 根据检索结果和规则，决定触发：

   • 远程重启流程
   • 提交工单流程
   • 安排现场工程师流程

这里的组合关系是：

• RAG：提供上下文知识
• Skill：约束「如何做决策、如何提问、如何输出」
• Workflow：完成最终执行动作

5.3 底层：确定性执行（Workflow / RPA / 脚本）

这一层的唯一要求：

不要信模型，要信代码和流程编排。

包括：

• API 调用链
• BPM 流程
• RPA 机器人
• 定时任务
• 数据库操作事务

这里非常适合做成「Skill + MCP + Workflow」的组合：

• Workflow 把一串 API / RPC / 脚本串起来
• MCP 把外部系统包装成标准工具
• Skill 负责：

  • 输入规范
  • 输出规范
  • 错误处理策略
  • 不同状态码的解释

最后返回给 Agent 的应该是：

• 清晰的状态（成功 / 失败 / 部分成功）
• 明确的字段（JSON 等结构化结果）
• 标准错误码和错误信息

5.4 最后一层：结果转述（Agent）

Agent 的工作只是：

• 把结构化结果翻译成人能看懂的话
• 必要时附上详细解释和后续建议
• 避免「编故事」，严格按返回字段说话

在这一步也可以挂一个简单 Skill：

• 统一输出口吻
• 统一敏感信息处理方式
• 统一错误提示文案

6. Skill 在行业 Workflow 里的落地方式

回到文章标题里的核心问题：行业 Workflow 如何通过 Skill 落地？

可以拆成三步。

6.1 把「人做事的方式」变成 Skill

先不碰系统，先去梳理：

• 关键流程当前是怎么执行的？
• 有哪些「资深同事会说：新人容易犯错的点」？
• 有没有文档 / 模板 / 复盘材料？

然后做的事情是：

1. 挑出重复度高、流程相对固定的一批任务。
2. 每个任务建一个 Skill 文件夹，写 SKILL.md：

   • 场景描述：什么时候应该用这个 Skill？
   • 输入要求：有哪些字段，格式是什么？
   • 处理步骤：拆成 1、2、3…
   • 输出规范：JSON 字段 + 人类可读的模板
   • 示例：2~3 个高频真实例子

第一轮不用追求覆盖所有流程，重点是把写 Skill 这件事本身跑顺。

6.2 把「系统做事的方式」变成 Workflow + MCP

接下来梳理现有系统资产：

• 哪些已有 API / 脚本 / RPA 可以直接复用？
• 哪些流程现在是人工填表 + 审批 + 抄数？
• 哪些操作有合规 / 风控要求，必须严格走系统？

然后做：

1. 把可复用的系统能力包装成 MCP / 内部 API。
2. 用我们熟悉的方式编排成 Workflow（BPM / 编排平台 / 自写 Orchestrator）。
3. 明确每个 Workflow 的：

   • 输入结构
   • 输出结构
   • 错误码定义
   • 审计日志

这一步的原则是：

尽量少改存量系统，尽量通过「外面包一层」的方式让它变成可调用的 Workflow 组件。

6.3 用 Skill 把「人」和「系统」连起来

最后一步，把 Skill 作为桥梁：

• 上游：Agent 与用户对话
• 中游：Skill 指导 Agent 该怎么理解、怎么提问、怎么路由
• 下游：Workflow/MCP 真正执行动作

一个典型链路会变成：

1. 用户输入需求
2. Agent 用「意图 Skill」判断任务类型
3. 分发给对应领域 Agent
4. 领域 Agent 读取对应 Skill：

   • 补齐参数
   • 调用 RAG 查规则
   • 决定调用哪个 Workflow
5. Workflow 执行，通过 MCP / API 触达系统
6. 返回结果由领域 Agent 按「输出 Skill」转成年类可读结果
7. Agent 统一封装成对用户的话术

所有「经验」、「SOP」、「注意事项」，尽量沉淀在 Skill 里：

• 方便以后版本升级
• 方便新业务线复用
• 方便做变更审计（Skill 本身可以版本控制）

7. 实施过程中的几个注意点

7.1 先把 Skill 写“够细”，再考虑自动化程度

很多团队上来就想着「全自动」，结果 Agent 兜不住，Workflow 无法覆盖异常，最后完全不敢放生产。

相对稳妥的节奏是：

1. 用 Skill 把流程写细写透，先跑一段时间「人机协同」：

   • Agent 给出建议
   • 人来点确认 / 修改
2. 统计哪些环节几乎没有人工干预
3. 把这些环节下沉成 Workflow，逐步提高自动化比例

这样做有一个副作用：整个流程的「隐性知识」会被 Skill 强制写出来，对组织本身也是一种梳理。

7.2 旧系统是企业的「来时路」

很多看起来陈旧的：

• 定时脚本
• 报文接口
• Excel 宏

从「Workflow + Agent」的角度看都是资产。
Skill 负责解释「什么时候、为什么、怎么用它」，MCP / Workflow 负责「怎么安全调用它」。

相比完全重构，一个实用的策略是：

给旧系统加一个 AI 适配层，而不是要求旧系统「变成 AI 原生」。

7.3 结构化数据回流

Agent 与用户的对话里，有大量可以反哺业务的信息：

• 用户真实需求
• 高频异常
• 流程里的瓶颈点
• 新出现的边缘场景

建议在设计时就准备好：

• 把关键字段结构化写入日志 / 数据库
• 定期用这些数据更新：

  • Skill 内容
  • RAG 知识库
  • 流程设计（Workflow）

不要只留下聊天记录，要留下可分析的行为数据。

8. 小结

把前面的内容合在一起，其实可以简化为三条：

1. Skill 把「怎么做事」固化下来

   • 它是 Agent 的“操作手册”
   • 它让流程可以被描述、复用、版本化
2. Workflow 把「谁来做、何时做、按什么顺序做」编排起来

   • 它对接真实系统和资源
   • 它保证执行的确定性和审计能力
3. Agent 把「人类模糊的需求」翻译成「可以被 Skill + Workflow 执行的指令」

   • 它是交互层和调度层
   • 它不是行业壁垒本身

在这个结构下，“降本增效”不再是一个抽象口号，而是一个比较直观的路径：

• 过去那些无法自动化的非结构化需求（邮件、沟通、模糊指令），
• 通过 Agent + Skill 变成可结构化的任务描述，
• 再通过 Workflow + MCP 交给稳定的代码和系统去执行。

从研发团队视角看，这套东西真正改变的是工作方式：

• 从「写提示」变成「设计并维护一套可执行流程」；
• 从「做一次性 Demo」变成「搭一套能长期演进的智能基础设施」。

如果你正在做行业 Agent，或者准备在内部推一个 AI 助手，可以先从一件事开始：

挑一个你们团队最常做、步骤最清晰、但最浪费时间的任务，把它完整写成一个 Skill，再把现有系统封装成一个 Workflow。
这两个拼起来，基本就是你们自己的第一个「行业 Workflow + Agent」原型。

以上。

过去一年，AI Agent 从狂热逐渐回归理性。在企业级应用和垂直行业落地中，我们看到了一个趋势：在行业中，纯粹依靠 Agent 自主决策的构想，正在被「Workflow + Agent」的混合模式所取代。

对于我们一线的同学来说，最重要的是要去解决实际问题。

当前我们能看到的行业 Agent 大多数实际落地的逻辑是：行业 Agent 的壁垒在于行业 Know-how，而落地的最佳路径是利用 Agent 做交互与分发，利用 Workflow 做执行与兜底。

1. 行业 Agent 是什么

很多人把 Agent 想象成一个全能的「超级员工」，指望给它一个模糊的目标（比如“帮我提升下季度销售额”），它就能自动拆解任务、调用工具、完成工作。在通用领域或简单场景下（如订机票、写周报），这或许可行。但在垂直行业（金融、制造、医疗、物流等），这种纯 Agent 模式目前是行不通的。

1.1 Agent 是交互方式，不是业务本身

Agent 在行业应用中的本质，是入口和交互。

它改变了人与系统的互动方式。以前我们需要点击菜单、填写表单、通过 SQL 查询数据库；现在我们可以通过自然语言表达意图。Agent 的核心价值在于它能“听懂”用户的意图，并将其转化为系统能理解的指令。

1.2. 真正的壁垒是行业 Know-how

大模型本身是通用的。GPT-5 或者是 Claude 4.5，它们具备的是通用的逻辑推理能力和语言能力，但它们不懂你们公司的复杂的审批流程，不懂某个特定设备的维修手册，也不懂行业内潜规则式的业务逻辑。

行业 Agent 的「行业」二字，才是重点。

• 什么是 Know-how？ 是我们沉淀了十年的 SOP，是数据库里积累的边缘案例，是针对特定业务场景的异常处理机制。
• Agent 的角色： 它是这些 Know-how 的「调度员」，而不是「创造者」。

如果脱离了行业 Know-how，Agent 就是一个会说话但办不成事的空壳。

2. 为什么「纯 Agent」模式在企业端走不通？

在 Demo 阶段，我们经常看到这样的演示：用户说一句话，Agent 自动规划了五个步骤，调用了三个 API，完美解决了问题。

但在生产环境中，这种全自动的「纯 Agent」模式面临三个无法回避的死结：

2.1 幻觉与确定性的冲突

企业级应用，尤其是涉及到资金、生产安全、合规的场景，稳定压倒一切。 大模型的本质是概率预测，这意味着它永远存在「幻觉」的可能性。哪怕准确率做到 99%，那剩下的 1% 的不可控对于企业核心流程来说也是灾难。

你无法向审计部门解释，为什么系统批准了一笔违规报销，仅仅因为 Agent 觉得「这看起来没问题」。

2.2 流程的黑盒化

纯 Agent 模式下，决策过程往往隐藏在模型的推理链中。当出现问题时，很难复盘和追责。企业需要的是可审计、可监控、可干预的流程。

2.3 成本与延迟

让大模型去规划每一个微小的步骤（比如“点击确认按钮”、“校验手机号格式”），是对算力的巨大浪费。这些确定性的逻辑，用传统的代码实现既快又准，用 LLM 去推理则是大炮打蚊子，且增加了响应延迟。

3. Workflow + Agent 的混合模式

既然大模型的幻觉无法根除，而传统软件的确定性又是刚需，最务实的方案就是将两者结合：Workflow + Agent。

这是一个“动静结合”的架构。

• Workflow（工作流/RPA）： 负责“静”。它是骨架，是肌肉。它包含固定的业务逻辑、SOP、API 调用序列。它保证了核心流程的确定性和可靠性。
• Agent（大模型）： 负责“动”。它是大脑，是神经。它负责理解非结构化的输入（自然语言），进行意图识别，然后决策应该触发哪一条 Workflow。

3.1 核心逻辑

Agent 不直接去操作底层数据库或核心系统，Agent 的输出对象是 Workflow。

• 用户 -> 对话 -> Agent (理解意图/参数提取) -> 触发 -> Workflow (执行/校验) -> 返回结果 -> Agent (格式化输出) -> 用户

3.2 这种模式解决了什么问题？

1. 复用历史沉淀： 企业过去十年建设的 ERP、CRM、以及各种自动化脚本（RPA），不需要推倒重来。它们被封装成一个个 Workflow，成为 Agent 的「工具箱」。
2. 控制风险： 所有的执行动作（写库、转账、发货）都由 Workflow 控制，Workflow 内部包含严格的校验逻辑（If-Else），这是大模型无法绕过的硬规则。
3. 降低成本： 只有在需要理解和决策的环节才消耗 Token，大量的执行环节由低成本的代码完成。

4. 如何设计混合模式

在具体落地时，我们需要构建一个分层的架构体系。

4.1 意图理解与分发

这是系统的入口。用户输入的往往是模糊的、非结构化的自然语言。 这一层的核心任务不是「解决问题」，而是「定义问题」。

• 意图识别： 判断用户是想「查询库存」、「发起退款」还是「投诉建议」。
• 参数提取： 从对话中提取执行 Workflow 所需的关键参数（如订单号、日期、金额）。如果参数缺失，Agent 需要反问用户进行补全。
• 路由分发： 基于意图，将任务指派给具体的 Workflow 或下一级更专业的 Agent。

关键点： 这一层需要极强的语义理解能力，通常需要配合 RAG 来理解特定领域的术语。

4.2 动态决策与 RAG

在某些复杂场景下，直接映射到 Workflow 是不够的。 比如用户问：“我的设备报警代码是 E03，我该怎么办？”

这里不能直接触发一个“维修流程”，因为 Agent 首先需要知道 E03 代表什么。

• RAG 的介入： Agent 调用知识库，检索 E03 对应的故障原因和处理手册。
• 初步决策： 基于检索到的 Know-how，Agent 判断是建议用户重启（触发“重启指引 Workflow”），还是必须派人维修（触发“工单提交 Workflow”）。

关键点： RAG 在这里不仅仅是用来回答问题的，更是用来辅助 Agent 做路由决策的。

4.3 确定性执行（Workflow / RPA）

这是系统的执行层，也是“行业 Know-how”固化最深的地方。 这一层严禁幻觉。

• 形式： 它可以是一个 API 接口，一个 Python 脚本，或者是一个复杂的 BPM（业务流程管理）实例，甚至是一个 RPA 机器人。
• 逻辑： 这里面充满了 If-Else、Try-Catch 和数据库事务。
• 反馈： Workflow 执行完毕后，必须返回明确的状态码和结果数据（JSON 格式），而不是一段模糊的文本。

4.4 结果综合与反馈

Workflow 返回的是结构化数据（例如：{"status": "success", "order_id": "12345", "delivery_date": "2023-12-01"}）。 Agent 的最后一步工作，是将这些冷冰冰的数据，转化为符合人类阅读习惯的自然语言，反馈给用户。

5. 多级 Agent 与 RAG 的协同

在简单的场景下，一个 Agent 配合几个 Workflow 就够了。但在复杂的行业场景（如供应链管理、大型设备运维）中，我们需要更复杂的拓扑结构。

5.1 多级 Agent 架构

不要试图训练一个全知全能的上帝 Agent。应该采用“主帅-将军-士兵”的层级结构。

• L1 调度 Agent（主帅）： 只负责宏观分类。例如，判断是“售前咨询”还是“售后维修”。
• L2 领域 Agent（将军）： 专注于特定领域。例如，“售后 Agent” 拥有查询保修、解读故障码、预约工程师的能力。
• L3 执行单元（士兵）： 具体的 Workflow 或特定的单一功能 Agent。

这种结构的好处是解耦。当售后流程发生变化时，只需要调整 L2 Agent 和对应的 Workflow，不会影响到售前部分。

5.2 RAG 的逻辑化应用

传统的 RAG 主要是为了解决“回答知识性问题”。在混合模式中，RAG 的作用被放大了。

• 动态 Prompt 注入： 在执行 Workflow 之前，系统可以根据当前的上下文，利用 RAG 从知识库中检索出相关的规则或注意事项，动态注入到 Agent 的 Prompt 中。

  • 例子： 在处理一笔“退款”请求时，RAG 检索到“该用户是 VIP 且信用极好”，将此信息注入 Prompt，Agent 可能会选择触发“极速退款 Workflow”而不是“常规审核 Workflow”。

6. 落地实战中的思考

在实施“行业 Workflow + Agent”模式时，有几个非技术性的坑需要注意。

6.1 人机协同

在很长一段时间内，Agent 不会完全取代人，而是成为人的 Copilot 在设计 Workflow 时，必须预留人工介入的节点。 当 Agent 的置信度低于某个阈值，或者 Workflow 执行遇到异常时，系统应自动升级为人工服务，并将之前的上下文完整传递给人工客服。

6.2 存量资产的价值

很多技术团队在做 AI 转型时，倾向于重构一切。这是错误的。 你们公司遗留的那些看起来陈旧的 API、跑了五年的定时脚本、甚至 Excel 里的宏，都是宝贵的资产。 Agent 的落地应当是「局部改造」而非「推倒重来」。 我们要做的，是给这些老旧的系统加上一个 AI 适配层，让 Agent 能够调用它们，而不是替换它们。

6.3 结构化数据的回流

Agent 与用户的交互过程，产生了大量高质量的数据。 不要让这些数据只停留在对话日志里。需要设计机制，将 Agent 收集到的信息（如用户的新需求、报错的高频词、Workflow 的执行结果）结构化地回流到业务系统中，用于优化 SOP 和微调模型。

7. 小结

行业 Agent 的未来，不是科幻电影里的全自动机器人，而是严谨的工程化实践。

我们不需要一个会写诗的 AI，我们需要的是一个能准确理解工单意图，并由后台的 Workflow 准确执行的系统。

• Agent 是面子：提供极简的交互，理解复杂的意图。
• Workflow 是里子：承载行业壁垒，保证执行的绝对可靠。
• RAG 是底子：提供动态的上下文和知识支撑。

降本增效不是靠引入一个昂贵的大模型来实现的，而是靠大模型把过去那些难以被自动化的“非结构化需求”，转化为了可以被低成本代码执行的“结构化指令”。

这才是行业 Agent 的落地。