拒绝让 AI“无脑开工”：我们在真实项目中沉淀的 5 种 Agent Skill 设计模式

最近，我在推特上读到了 Google Cloud Tech 分享的一篇关于 Agent Skill 设计模式的帖子（原文链接）。这短短的一篇总结，却在我的脑海里引发了一场强烈的共鸣。过去这段时间，我们团队一直在将大模型能力深度接入到日常的研发工作流中，也有了一些真实的项目经验。

在我们的实际服务中，我们已经不知不觉地将这些模式付诸了实践，虽然一开始有那么点粗糙，但随着大家对 skill 进一步了解后，就可以让 AI 协助生成及重整出组织清晰有规范的 skill 资源模块。

模式一：The Tool Wrapper（工具包装器）—— 按需加载的智慧

原帖中提到，工具包装器的本质是为 Agent 提供按需加载的能力。这听起来很简单，但在实际开发中却极其有效。

在我们的一个新的业务服务中，我们创建了一个 open-api-gen 的 skill。当我们需要新增一个接口时，不再是让 AI 漫无目的地从头瞎写，而是通过这个 wrapper，按需加载生成 OpenAPI 接口的基础骨架。它精准地涵盖了路由、控制器、入参约定与校验、出参约定，甚至业务服务层的调用实现。通过这种方式，AI 变成了一个精准的“代码组装机”，指哪打哪。

模式二：The Generator（生成器）—— 强制一致性的艺术

如果说工具包装器是让 AI 应用知识，那么生成器就是强制输出一致性。原帖里有一个很生动的比喻：生成器就像是一个严谨的项目经理。它会加载模板、阅读样式指南、询问缺失的变量，然后填充内容。

我们在服务的 api-docs skill 中应用了这一点。目前用它来生成接口文档，效果不错。不过，对照这套标准模式，也有一些反思：我们目前的资源文件组织还可以更严谨。未来，我们可以进一步按照 skill 的官方标准，将“资产/存储输出模板”和“引用/保存样式指南”分离。只有让 skill 结构化、更严谨，生成的 API 文档或项目架构才能达到绝对的可预测性。

模式三：The Reviewer（审查器）—— 将“标准”与“执行”剥离

让 AI 自己写代码，再让 AI 自己审查？听起来像个悖论，但 Reviewer 模式给出了优雅的解法：将检查内容和检查方式分开。

在一个旧服务的 code-review skill 中，我们的 creator 自动创建了一个 REVIEW_STANDARDS.md 的检查清单。这就是 Reviewer 模式的精髓。AI 审查代码时，过程是静态的，但审查的策略和标准是动态配置的。接下来，我们甚至可以把特定项目和 GitLab 的特有资源从“如何检查”的逻辑中剥离出来。这样一来，流水线本身坚如磐石，而审查规则却可以随需应变。

模式四：Inversion（反转/访谈模式）—— 把提问权交还给 AI

这是最让我拍案叫绝的一个模式。我们常常苦恼于如何写出完美的 Prompt，却忘了沟通应该是双向的。Inversion 模式就是在 Agent 做计划和需求分析阶段，让它主动开口向人类提问，澄清那些不确定的细节，从而避免 Agent 拿到任务就“无脑开工”。

在处理特定领域的 FAQ 时，我们引入了这种访谈机制。比如，在排查最近遭受的分布式登录攻击时，如果没有边界，AI 可能会在大范围的数据中迷失。通过 Inversion 模式，Agent 会先“访谈”我们：“请问需要查询哪个具体时段？”通过这种互动，排查范围被大幅缩小，目标更加明确，执行的确定性也呈指数级上升。

模式五：The Pipeline（流水线）—— 用检查点构筑信任

最后一个模式是 Pipeline，它通过设立检查点（Checkpoints），强制执行严格的多步骤工作流程。这其实也是大型工程项目中最核心的思想。

在我们一个工具服务的开发 skill 中，流水线模式让每一步都一环扣一环：

  1. 环境准备；
  2. 文件生成：生成 Python 文件和 Doc 文档；
  3. 自我审查：如果审查失败，强制退回修正；
  4. 进阶生成：审查通过后，再生成 DSL 文件；
  5. 完整审核：对所有输出产物进行最终 audit；
  6. 集成测试：审核通过后生成集成测试，最后汇总结果。

在这个流水线里，AI 不再是单打独斗的孤胆英雄，而是变成了一套精密运转的齿轮系统。

写在最后：模式的自由编排与进化

这 5 种模式并不是互斥的孤岛，它们是乐高积木，是可以自由编排和协作的。比如，在一个大型任务中，我们可以先用 Inversion 澄清需求，再用 Pipeline 拆解步骤，在每一个节点用 Generator 产出代码，最后用 Reviewer 把控质量。

AI 技术发展得太快，以至于我们常常被各种炫酷的 Demo 晃花了眼。但当我们真正把 AI 落地到企业级服务中时才会发现，工程化的本质，依然是控制复杂度和增加确定性。我们不仅需要聪明的模型，更需要优秀的架构设计。只有这样，AI 才能真正从“玩具”蜕变为“工具”，与我们并肩作战。

你在日常的 AI 工程实践中，最常用的是哪种模式？或者踩过哪些坑？欢迎和我们一起探讨。

在创建 Skill 过程中，我们可以告知 skill creator 我们可能会考虑哪些模式创建，或是把这些模式告知，让 creator 自己去判断使用什么模式更合适，所以我们需要知道有这些模式。