给样本，比讲规则管用：我花了 20 多天，把 Hermes Agent 训练成能独立交付的 Dify 开发助手

作者前言：本文由我与 AI 协作完成，数据来源于 2026 年 7 月至 8 月的本地真实交付记录，可溯源、可验证。旨在分享 AI 工程化的落地经验。

摘要

在 Dify 应用开发过程中，传统的 Console API 调用方式常面临渲染异常、无法静态检查、编排能力受限等痛点。本文提出一种基于「样本驱动」的 AI 训练方法论，通过将 Hermes Agent 从「规则学习者」转变为「样本模仿者」，成功构建了从需求分析（TR1）到验收交付（TR4）的全链路自动化流水线。实战数据显示，该方案在 10多天内交付了 69 个实验、87 份可运行 DSL、9 个插件及 4 套 MCP Server，全部通过 TR4 验收。本文将深入拆解训练五步法、契约预检机制及「错误单次消除」闭环，为 AI 辅助开发提供可复用的工程范本。

一、结论先行

过去一个多月，我用「一个人 + 一个 Hermes Agent（开源 AI Agent 框架）」的方式，从需求分析到测试验收，完整交付了六个批次的 Dify 应用：

69 个实验、87 份可运行的 DSL、14 个知识库种子、9 个插件、4 套 MCP Server 交付包，每个应用都带 TR4 验收报告，全部通过测试验证。

这篇文章不是「AI 很厉害」的演示，而是我踩过坑之后的完整复盘。核心方法论浓缩成一句话：

给样本，比讲规则管用。

二、起点：用官方 API 开发，撞了一周的墙

一开始我走的是最「正统」的路线——通过 Hermes Agent 调用官方 Console API 登录后直接操作。结果三个问题一直解决不了：

问题 1：UI界面渲染问题无解。 API 方式创建的应用跑起来效果总是不对，反复出现渲染问题，你分不清是接口参数的问题还是平台本身的逻辑。

问题 2：本地没有文件。 应用只存在于平台上，本地不产出任何可检查的文件——没法静态检查（导入前预判报错）、没法批量生产（每个都要手工处理）、没法版本管理（无记录、无对比、无回滚）。

问题 3：编排能力受限。 复杂多节点的工作流在 API 方式下很难搭，天花板很低。

三个问题叠加，结论很清晰：API 方式适合「操作平台」，不适合「生产应用」。

三、转折：从「操作平台」到「生产文件」

Hermes Agent 卡在那里反复试、反复错。我盯着它报的错，突然冒出一个念头：

「这些工作流，能不能不通过 API 建，而是直接生成 yml 文件？让 Hermes Agent 来写？」

现在回头看很普通，但当时是个转折——我把思路从「操作平台」换成了「生产文件」。

换成 yml（DSL 文件）之后，之前的三个问题全部消失：

痛点	DSL 方式的解法
渲染问题无解	本地文件可反复校验、对照 UI 导出逐字段比对，问题可定位
无法静态检查	DSL 是文本，导入前就能做契约校验、格式检查、拓扑检查
无法批量生产	一个脚本批量生成 N 个 DSL，一批实验从 2-3 天缩到半天
编排受限	文件里可以完整描述复杂拓扑：多分支、多节点、并行、迭代

四、第一次尝试：Hermes Agent 写 DSL，漏洞百出

刚开始时，我让 Hermes Agent 写 yml。结果是：能写，但写得一塌糊涂。

• 节点不会用：工作流有哪些节点、各干什么，它根本不了解，经常用错类型
• 数据结构不懂：字段该是字符串还是数组分不清，该传 list 的地方传 string，下游一接就崩
• 前后变量对不上：上游定义的变量，下游引用一个根本不存在的名字
• 知识库不会联动：检索结果怎么进 LLM 上下文，它不知道
• 提示词里的变量引用不会写：写出来就是错的

说白了，当时它对 Dify 的理解停留在「听说过这个平台」的程度，写出来的 yml 十个里能跑通一个就算运气好。

换个人可能就放弃了——「Hermes Agent 写不了，还是自己来吧」。

五、顿悟：AI 的优势是模仿，不是创造

我做过软件开发，见过各种新人怎么上手新系统。新人最快的成长路径从来不是读文档，而是看老员工怎么写，照着模仿。

AI 也是一样——让它凭空设计 Dify 工作流，它当然不行；但让它模仿一份优秀的 DSL，它可能学得比人快。

而 Dify 上恰好有一堆权威样本：官方示例、社区分享、UI 里导出的成熟工作流。这些就是「老员工写好的代码」。

训练方法就此定下：别急着教它规则，先给它看样本，让它自己从样本里总结规律。

六、训练五步法：给样本 → 观察 → 筛选 → 沉淀

每轮训练都走固定流程：

第一步，给样本（Input）。 一次给四五个从 Dify UI 导出的权威 DSL 文件。这些是官方/社区的成熟设计，是权威格式。

第二步，观察学习（Observe）。 立规矩：拿到样本先观察，只看不操作，不许动手改数据。它要做的第一件事是把样本拆开、读懂、和已有知识对比、找出差异。

第三步，列学习点清单（List）。 把发现整理成清单，标价值等级——哪些是高价值认知、哪些是中价值、哪些是架构级的，一条条列清楚。

第四步，逐条筛选（Filter）。 清单交给我，我一条条过：这条收录，那条排除。铁律一条——只收录实测验证过的结论，它「以为」的不算，要有样本或实测支撑。

第五步，沉淀（Solidify）。 确认过的经验写进它的技能库（skill），下次开工先加载。每学完一批样本，能力就永久提升一截。

这套流程的效果是惊人的：仅 2026-07-29 一天，就修正了它 12 处以上的错误认知——很多它之前「自信满满」的写法，跟权威样本一对，全是错的。

七、开窍的那一天

训练进行到某个阶段，我明显感觉到它不一样了。

以前它写 DSL 是「猜」——凭语感拼凑，错了再改，改完再错。学了那批优秀样本之后，它写 DSL 是「照着已知的正确范式填参数」——格式、结构、变量引用、知识库联动，一次到位。

那一天它产出的 yml，我第一次不用返工改十几处就能导入跑通。

那种感觉，就像带一个新人：前面两个月天天讲规则，他左耳进右耳出；后来你直接甩给他一摞老员工写的优秀代码让他自己读，读了一个月，他忽然开窍了——写出来的东西有模有样了。

八、升级：从「会写 DSL」到「会做完整工程」

会写 DSL 只是第一步。后来我把同样的训练思路用在更大的范围——从需求到交付的完整链路：

需求 → TR1 概念设计 → TR2 架构设计 → TR3 需求详细设计 → DSL 生成
     → 导入验证 → TR4 验收报告 → 交付

TR1 概念设计：教它先想清楚做什么再动手。立「文档先行」的规矩——没有概念设计，就没有后面的一切。

TR2 架构设计：立「唯一真相源」的纪律——变量名、字段名、Mock Schema 定了就不许改，禁止同义词替换。我前后拒绝过它 8 次路径占位符的错误写法，立场始终没变。命名是承诺，改了就是违约。

TR3 需求详细设计：教它把验收标准写进需求——「怎么算过」在设计阶段就定死，不许验收时现编。用例是需求的一部分，不是测试的附属品。

TR4 验收：投入最深的一环，四批实验每批暴露一个问题，总结成一条规则：

• 第一批：立六属性验收框架（功能/性能/安全/可靠性/压力/异常）
• 第二批：发现它用例设计方法不对，立「用例设计前置 Gate」——先读方法论再设计，不许凭感觉；用例基线化，基线冻结后严格执行
• 第三批：暴露 13 条用例缺陷，反推出「契约预检」5 项——逐字段核对、禁描述性输入、形态显式确认、可达性三问、判定字段绑定
• 第四批：教它判定词纪律——错误路径的判定词要写「错误显式呈现」，不写死「失败」形态，否则修复后判定就过时了

每一批的教训都沉淀成规则，下一批按新规则干。四批下来，它从「会写文件」长成了「会验收、会归因、会写报告」。

九、人到底在干什么？

所有人最关心的问题：Hermes Agent 都干了，人干嘛？

我的答案是：人做 Agent 做不了的决策。

1. 定方向：做什么应用、用什么节点、覆盖什么业务——方向决策是人的
2. 审文档：TR1-TR4 每份文档，人要过目、要评审、要拍板
3. 守底线：核心节点不可绕过替代；内容真实性不可妥协，数据不擅自模拟
4. 验收把关：用例基线化后严格执行，中途不因应用特殊性改用例；FAIL 先修应用，重跑确认归因

一句话：Agent 是执行者，人是所有者。 Agent 负责把事做对（效率），人负责决定做什么事（方向），以及出了问题谁来负责（责任）。

十、最有价值的部分：错误只发生一次

这套流程里最让我意外的是 Hermes Agent 的自我进化循环：每踩一个坑，就把经验沉淀进 skill（程序性记忆），下次遇到同类问题直接复用，不再踩。

真实例子：给用户消息里的手机号打码（138****5678），AI 写的脱敏正则表达式转义出了问题，手机号没被遮住、原样漏了出去——这是隐私泄露级别的错误。它把这个坑沉淀进 skill 之后，后续所有实验的脱敏都一次通过，再没犯过。类似的坑还有很多：插件执行参数覆盖、测试用例检查清单……每一个都只犯一次。

这套循环的积累效果是：同一个错误，在这个项目里只发生一次。

这跟传统开发区别很大。传统团队的错误会重复发生——换人、换项目、经验会流失；而 Agent 的「踩坑 → 沉淀 → 复用」是强制性的，它每次开工前都会先加载 skill。

十一、数据复盘（截至 2026-08）

批次	内容	规模
DIFY-102	入门/基础实验	20 实验 / 39 DSL
DIFY-103	中级实验	10 实验 / 11 DSL（49/49 用例全过）
DIFY-104	企业级实验	12 实验 / 25 应用
DIFY-105/106	应用/插件批次	9 插件 + 15 验证应用（106 批次 45/45 全过）
DIFY-107	MCP Server 批次	4 套交付包 + 36+4 验收用例
合计	—	69 实验 / 87 DSL / 14 种子 / 9 插件 / 4 MCP

配套产出：69 篇技术文章、每应用 1 份 TR4 报告、全部交付物同步 Gitee 公开仓库、沉淀 8+ 个可复用 skill（设计/开发/验证/验收闭环）。

十二、这套方法，任何人都能复制

回头看，整个训练过程本质上就四句话：

1. 给样本，比讲规则管用 —— AI 的优势是模仿，让它从优秀样本里自己总结规律，比讲一百条规则管用
2. 观察学习，只看不碰 —— 学习阶段不许动手，防止它拿猜测污染真实数据
3. 经验只进可信仓库 —— 逐条筛选它学到的内容，只收录实测验证过的，保证知识库干净
4. 错误只犯一次 —— 每个坑都沉淀成规则，下次开工先加载，同样的错不再犯

这套方法不挑工具、不挑平台。你手里任何一个 AI 助手，都可以用同样的路子，教成你专属的「开发 + 验证」搭档。

你缺的不是一个聪明的 AI，是一套训练它的方法。

---

附录：Hermes Agent Dify 开发训练核查清单

为了方便读者实践，我整理了以下核查清单，建议收藏备用：

• 样本准备：收集 4-6 份从 Dify UI 导出的权威 DSL（覆盖 Loop、Agent、HTTP 等节点类型）。
• 静态检查：配置 DSL 静态检查脚本，确保 yaml 格式及基础字段合规。
• 纪律确立：
  • 观察期不修改：学习阶段禁止 AI 随意篡改样本数据。
  • TR2 唯一真相源：变量名、字段名一经定义禁止同义词替换。
  • 契约预检：生成前强制运行「逐字段核对、形态确认、可达性三问、判定字段绑定」等检查。
• Skill 沉淀：建立技能文件记录「踩坑记录」和「修正规则」，下次开工先加载。
• 版本管理：所有 DSL 及 TR 文档纳入 Git 管理，便于追溯。

---

讨论：你在 AI 辅助开发 Dify 工作流时遇到过哪些「玄学」Bug？或者你认为在 AI 工程化中，还有哪些规则是必须坚守的？欢迎在评论区分享你的见解。

声明：本文由作者与 AI 协作完成。训练过程为真实经历，成果数据来自本地交付记录（2026-07 至 2026-08），可溯源可验证。