虚函数与纯虚函数：区别、原理与应用场景详解
2026/8/29 6:27:09
我们的门户机器人，为什么用 Dify 答、不把 skill 搬上云端 Hermes？
基于 2026 年 AI Agent 落地现状撰写。我们团队的实践记录：Dify 1.16.x + Hermes Agent 环境，门户自用机器人真实选型案例。
📖 摘要：我们门户有两个自用机器人（「知鱼」「AI 机器人」），用的是 Dify 回答，而不是把本机的 skill 复制到云端 Hermes Agent。很多人问：Hermes 不是更强吗？为什么不用？这篇文章复盘当时的决策：公开展示面要的是确定性（回答稳定、可审计、可发布），这是 Dify workflow 的结构优势；而 Hermes 的自主执行能力，留给内部交付场景。判断标准只有一条：这个场景要的是「确定性」还是「自主性」。
📌这篇文章要解决的三个疑问：
- 你们不是做 Hermes Agent的吗？为什么门户机器人用 Dify？
- skill 复制到云端 Hermes 不就能回答了吗？为什么不行？
- 怎么判断一个 AI 场景该用工作流还是 Agent？
结论
同一个人，同一套技术栈，不同场景用不同的工具——不是谁更强，是谁更合适。门户机器人用 Dify 回答，不是因为我们只会 Dify，而是因为它是「公开展示 + 固定知识问答」场景：回答必须稳定、可审计、可发布。这是 Dify workflow 的确定性优势。
而 Hermes 的自主执行（多步操作、无人值守、跨系统编排），我们用在自己的内部交付上——那是它擅长的场景。
判断标准只有一条：这个场景要的是「确定性」，还是「自主性」？
场景：门户上的两个小机器人
我们的门户网站上有两个自用机器人：「知鱼」回答我们是谁、做什么、凭什么信；「AI 机器人」回答项目怎么评估、方案怎么输出。
它们本质是公开展示面——任何一个访客点进来都能问，回答的是静态知识。不是内部工具，是「给人看的作品」。
作品要什么？稳定。同一个问题，今天答的和明天答的，结构、格式、结论应该一致。访客不会原谅「时灵时不灵」。
痛点：为什么「更强的 Hermes」反而不合适
有人会问：你不是做 Hermes Agent 的吗？把本机的 skill 复制到云端 Hermes，让它回答业务问题，不是更「AI」吗？
三个原因，每个都是实打实的工程考虑：
1. 自主执行在展示场景是缺陷。Hermes 是自主 agent loop——模型现场决定下一步，路径不可预测。这对内部执行是优点（灵活），对公开展示是缺点（不可预期）：同一个问题，它可能这次调工具、下次不调，答案结构漂移，你没法对访客交代。
2. 展示场景需要发布控制。公共访问需要会话隔离、发布控制（哪个应用上线、哪个下线、怎么限流）。Dify 社区版有现成的 WebApp 发布 + API Key 机制，开箱即用；云端一个裸 Hermes 执行体，没有这层。
解决方案：按场景性质选型
于是门户机器人走了 Dify：知识库（认识我们的内容）+ workflow（固定问答路径）+ 平台发布（WebApp 对外）。
这不是「Dify 比 Hermes 强」，而是「这个场景该用 Dify」。
真正有价值的，是背后那条可以复制的判断标准：
| 场景特征 | 选型 |
|---|---|
| 内部员工 / 机器使用 / 多步自主 / 没人知道确切步骤 | Hermes（自主执行面） |
| 外部客户 / 多租户 / 公开展示 / 非技术要改 | Dify workflow（确定性编排） |
| 静态知识问答 / 固定流程 / 需要稳定可审计 | Dify（知识库 + workflow） |
| 频繁上传管理知识库 + Hermes 负责编排 | Hermes + Dify 知识库桥接 |
这条标准我们用了很久，也用在客户项目上：先问场景要确定性还是自主性，再定工具，而不是先有工具再找场景。
案例启示：选型方法论，不是工具崇拜
这个案例最大的价值，不是「我们选对了 Dify」，而是同一个团队，在自用场景下，主动做出了一组「两套选型」：
- 门户展示 → Dify（确定性、契约化、可发布）
- 内部交付 → Hermes（自主执行、无人值守、跨系统）
客户看到的不只是「你们会用 Dify」，而是「你们懂什么时候该用什么」——这才是架构交付能力。方案里给客户讲架构分工，靠的不是术语，是「我们自己就是这么选的」的真实案例。
边界：这个案例不是「Dify 更好」的证据
说清楚边界，防止误读：
- 不是「Dify 更好」。Hermes 在自主执行面全面更强（多步操作、无人值守、跨系统编排），我们内部交付天天用。门户选 Dify 是场景适配，不是能力排名。
- 不是「skill 不能上云」。skill 上云是可行的工程问题（环境对齐、凭据管理、隔离设计），只是对「公开展示 + 静态问答」这个场景，投入产出不划算。
- 不是「展示场景永远用 Dify」。如果门户机器人未来需要自主操作（比如自动生成方案、调用内部系统），那它就该进化成 Hermes 形态——选型是动态的，场景变了工具就变。
收尾
回到开头那个问题：为什么门户机器人用 Dify 答、不把 skill 搬上云端 Hermes？
因为门户是给人看的作品，作品要稳定；Hermes 是干活的手，手要灵活。把「作品」和「手」换着用，两边都会出问题。
所以下次遇到「这个 AI 场景该用什么」的疑问，先别问「哪个工具强」，先问一句：这个场景，要的是确定性，还是自主性？
💬 你遇到过「选错工具」的场景吗？有没有「Agent 用在展示场景结果翻车」的经历？评论区聊聊。
📚 更多实战记录见我的博客：鱼日先生
本文基于真实工程实践记录撰写（Dify 1.16.x + Hermes Agent 环境，门户自用机器人选型案例）。观点与数据均来自我们自己的实测，不构成任何平台的官方结论。AI 参与创作声明：本文由 AI 辅助写作，内容基于作者真实实测记录。