为特定领域业务工作流构建 AI 智能体技能

通用 AI 编码智能体能够胜任的任务范围之广，往往出人意料。它可以阅读文档、编写代码、排查故障，并在上下文充分时分析陌生问题。但大多数将这些智能体用于实际运营的团队都会遇到同一个难点：提供上下文本身就是一项工作，而且领域越复杂，这项工作的负担就越重。

数据分析师需要智能体从包含多种格式采购订单的文件夹中提取供应商交付周期时，不希望每次都要解释什么是采购订单、公司的命名规范如何运作，以及下游系统要求什么输出格式。负责基础设施监控的开发者，也不希望每次对话都粘贴同样的告警阈值和严重程度定义。问题就在于这种重复劳动。

技能是可复用的配置包，将领域知识与行为指令整合为一个可调用的单元，直接解决了这一问题。本文介绍技能如何构建、如何部署到周期性工作流中，以及在哪些场景下能够稳定地创造价值。

技能究竟是什么

技能并不是模型功能或 API 能力，而是一个文件，具体来说，是放在智能体启动会话时会扫描的目录中的 Markdown 文件（例如，在 Claude Code 中，是 ~/.claude/skills/ 或项目的 .claude/skills/ 下某个文件夹中的 SKILL.md 文件；其他智能体运行环境使用各自的位置）。当智能体遇到与技能描述相符的请求时，就会加载并遵循该技能的指令，而不必从头分析该如何处理任务。

这个文件包含四部分：说明何时启用技能的描述块；规定如何处理某一类任务的指令集；可选的工具访问声明，根据运行环境的不同，用于预先批准或限制智能体执行时可用的工具（在 Claude Code 中，allowed-tools 会预先批准工具，但不会限制其他工具）；以及可选的示例，展示如何正确处理实际输入。

文件中不应包含硬编码的业务数据。技能封装的是处理一类任务的方法，包括领域术语、推理方式和输出格式，而不是具体任务本身。封装方法与封装数据之间的区别，是构建能够长期保持实用性的技能时最核心的设计问题。

何时应将领域知识写入技能，何时不应这样做

大多数失败的技能实现，问题都在于写入了太多内容。团队对这个概念热情高涨，把具体供应商名称、当前价格档位、客户偏好的报告格式，以及目前使用的精确 API 端点都写进技能。六个月后，其中一半信息已经不正确，技能与实际情况脱节，也没人能确定哪些内容仍然可信。

实用原则是：将变化缓慢的内容写入技能，让智能体处理频繁变化的内容。

领域术语变化缓慢。处理进口单证的技能应知道什么是原产地证书、海关估价中的倒扣价格法是什么意思，以及目标市场的监管框架如何构成。这些知识的变化远慢于运营细节，不过监管框架会修订，仍需定期复核，适合写入技能。

具体申报格式、交易方名称、当前监管阈值和确切截止日期则不断变化。这些应作为数据在运行时提供给智能体，而不是写进技能定义。技能教智能体如何阅读某一类文档，实际文档则作为上下文传入。

有一个实用的判断方法：如果业务环境每发生一次变化，就需要更新技能，说明技能里放错了内容。设计良好的技能经得起组织变化；设计不佳的技能几乎马上就会过时。

SKILL.md 的结构

标准技能文件的结构很简单：文件头元数据块标识技能并规定启用条件，正文则说明如何使用。

---
name: import-document-processor
description: Use when processing import declarations, ACP applications,
  or customs documentation for Singapore, Japan, or EU markets
---

## Context
Background on the domain: what this class of documents is, why it
exists, what the agent needs to know to interpret one intelligently.

## Approach
Step-by-step instructions for handling the task: what to look for,
how to handle ambiguous cases, what to escalate to human review.

## Output Format
Exactly what the output should contain, in what structure.

## Edge Cases
Known failure modes and how to handle them.

从实际运行的角度看，描述块最为重要。它决定智能体是否会启用技能。像“用于文档”这样的模糊描述，会导致启用行为不稳定；明确列出文档类型、业务场景和相关市场的描述，才能带来可靠的行为。

但描述也不宜规定得过细。范围过窄，智能体就会漏掉真正适用的请求。目标是让有经验的从业者读后能够判断该技能是否适合自己的情况，范围恰到好处。这需要在实践中校准，也值得在初次部署时测试边界情况，确认启用边界符合预期。

用于周期性任务的 /loop 模式

一些业务工作流按固定计划运行，例如每天从 API 端点提取数据、每周汇总供应商报告、每月生成面向客户的摘要。这些不是一次性交互，而是持续运行的运营流程，不取决于是否有人手动发起。

在 Claude Code 中，/loop 命令可以将技能驱动的交互转变为周期性操作：

/loop 24h /process-supplier-reports

这条命令按指定间隔在当前会话内重新运行指定的技能，每次调用的上下文均由该会话提供。技能负责处理工作，循环负责调度。截至 2026 年 10 月，Claude Code 文档说明 /loop 仅在当前会话内有效：任务只会在会话运行期间触发，周期性任务会在七天后过期。因此，长期用于生产环境的调度应交由 cron 作业、CI 流水线或云端定时任务来完成，并由其调用同一技能。

周期性技能需要考虑一些交互式技能不必面对的设计问题。首先必须具备幂等性：对同一输入执行两次，不应创建重复记录、发送重复通知或破坏下游状态。其次，必须明确错误处理方式，清楚规定输入格式有误、API 不可用或预期数据缺失时该怎么做。如果输出会被下游系统使用，还必须采用机器可读的格式，而不能只让人看得懂。

能够可靠循环运行的技能，其范围几乎总是比交互式技能更窄。交互式技能可以妥善处理五种不同文档，并在遇到陌生文档时适度降低处理能力；循环运行的版本则精确处理一种文档，对任何意外输入明确报错。运营可靠性更需要明确的范围，而不是灵活性。

一个实用的经验判断是：如果无法在十分钟内说明技能的全部预期行为，包括错误情况，那么它的范围很可能过于宽泛，难以可靠地定时执行。

生产环境中的实际案例

我们在实际运营环境中使用过以下三种模式：

从供应商沟通内容中提取数据。供应商发送的订单确认、发货通知和发票更新格式各不相同，有时是结构化的，但往往不是。针对每个供应商沟通方式配置的技能，可以从非结构化文本中提取结构化数据。技能知道某个供应商会在确认邮件的第二段写采购订单编号，日期格式是 DD.MM.YYYY，产品编码遵循特定模式。每周变化的是实际邮件内容，不变的是解析方法。提取结果直接进入库存系统，从收到消息到录入数据之间无需人工干预。

根据运营数据生成报告。生成每周运营摘要，需要知道哪些指标重要、哪些阈值具有实际意义、跨期比较如何才有意义，以及如何向特定受众呈现结论。这些要求不会每周改变，只需在技能中定义一次。运行时，智能体接收当前数据，并应用已配置的分析框架。输出格式、语言风格、必须出现的章节，都在技能中规定，不必每次重新说明。由此获得的一致性，是手动编写提示词在规模化使用时很难达到的。

系统监控与告警。基础设施持续产生日志。监控技能定义哪些模式构成值得关注的事件、如何划分严重程度，以及人们需要哪些信息才能有效处理告警。配合短间隔运行的循环模式，这些技能会检查预设条件，并在条件满足时生成结构化告警。

这里最关键的设计问题是管理误报。如果技能对每一个异常都发出告警，就会让从业者逐渐忽略告警。真正需要投入的是校准：精确定义什么情况下的告警值得人工关注。这不是技术问题，而是领域知识问题。要做好这件事，需要目前手动处理问题的人员提供详细意见，因为他们已经掌握了有效信号与噪声之间的界限。技能将这些知识明确地固化下来。

技能不能解决什么

技能封装的是特定领域的专业能力，并不会创造通用能力。

配置良好的技能能够可靠处理已知模式，却不擅长应对真正全新的情况，因为那些让它在熟悉场景中保持可靠的指令，也会在陌生场景中主动限制它。因此，技能最适合边界相对明确的任务，例如处理特定市场的进口单证、围绕固定指标生成报告，或根据已知告警模式分析日志。“协助业务运营”并不是一个边界明确的任务范围。如果没有人投入精力去定义某个领域中合格表现的标准，技能也无法让智能体在该领域具备专业能力。

另一个限制是维护。封装领域知识的技能，需要在知识发生变化时更新。虽然设计良好的技能会避免写入易变信息，不必随每一次变化更新，但有些变化不可避免。保持技能有效，需要与维护文档同样的纪律。不投入维护的组织，会逐渐发现技能与实际情况脱节。这种失效往往悄无声息：技能继续运行、继续输出，但结果存在细微错误，需要一段时间才能察觉。

从技能中获得最大价值的组织，会同时投入初始配置和持续校准。初始投入比大多数人预期的小，持续维护所需的投入却比大多数人计划的多。坦诚地为维护作出安排，正是技能能够长期有用，而不是成为隐性错误来源的关键。