AI Agent Layer Routing Sample Cases
Summary
这页把 [[hermes-layer-routing-decision-checklist]] 从规则页推进到实战页：不给抽象定义，直接给样板案例。目标不是证明某一层“更重要”，而是训练稳定路由直觉——一个新信息、新需求或新流程出现时，为什么它应该进 wiki、memory、skill、cron、MCP，或者只留在 session。
Applicability
以下为合成案例。skill 可由项目 SOP 承担，cron 泛指定时触发，MCP 仅是外部接入的一种实现，API/CLI/已有连接器同样可用；不要求安装任何新组件。写入任何持久层都需要对应授权，公共 Wiki 还需通过公开准入。人类操作指南可放在 operations/，不能仅因包含步骤就排除出 Wiki。
Question
在真实使用 AI Agent 时，常见信息和需求应该如何稳定分流到正确层，而不是在 memory、wiki、skill、cron、MCP 之间混放？
Case 1: “以后默认参考 AI Agent 官方文档，避免方案跑偏”
- 归类：
memory - 为什么：这是稳定工作偏好与长期校准规则，短、小、长期有效
- 为什么不是 wiki：它不是一篇需要长期扩写的知识页
- 为什么不是 skill：它不是可执行步骤本身
Case 2: “这个服务器是 Debian 13，时区 Asia/Shanghai，运行 AI Agent 和 Caddy”
- 归类：
memory - 为什么：已核验且值得跨任务保留的环境背景可作为记忆候选；执行前仍须核对当前系统状态
- 为什么不是 wiki：实例环境事实保留在私有或项目记录；只有脱离实例且适合公开的方法可进入 Wiki
- 边界：软件、版本和配置会变化，memory 不替代 live 检查；未经核验的观察先留在当前任务
Case 3: “把安全修改 AI Agent 配置的做法标准化”
- 归类：公开指南进
operations/；项目 SOP 或宿主执行契约按需承载方法 - 为什么：核心是重复执行的方法，有明确步骤、备份要求、验证要求
- 为什么不是 memory：太长，不适合压成短记忆
- Wiki 边界：公开操作指南可进
operations/；需要宿主触发、工具和执行约束的部分才形成 skill
Case 4: “总结 AI Agent 当前知识库架构和层次关系”
- 归类：
wiki - 为什么：这是长期查阅、持续扩写、需要交叉链接的正式知识
- 为什么不是 skill：它不是操作 SOP
- 为什么不是 memory：信息量太大，且需要结构化章节
Case 5: “接入 GitHub issue、PR、code search 到 AI Agent”
- 归类：外部接入（已有 API、CLI、连接器或适配的
MCP） - 为什么：这是外部实时能力接入，应优先复用已有授权工具，只有适配时才使用 MCP
- 为什么不是 wiki：wiki 只能记知识，不能提供实时操作能力
- 为什么不是 skill：skill 可以规定怎么用 GitHub，但不能替代接入本身
Case 6: “每天早上 9 点检查 CI 失败并给我发摘要”
- 归类：稳定方法（SOP 或
skill）+ 已授权调度器/cron - 为什么：先需要一套稳定检查方法，再需要定时调度
- 为什么不是单独 cron：cron 只负责什么时候跑，不负责方法定义
- 为什么不是 memory：这不是偏好或事实，而是自动化任务
Case 7: “最近某次排障里临时发现一个奇怪报错，最后一次性修掉了”
- 归类：默认留在
session - 为什么：如果它没有形成稳定规则、知识或方法，大概率不该入长期层
- 什么时候升级：
- 如果暴露了稳定环境事实 →
memory - 如果形成固定排障流程 → SOP 或
skill - 如果抽象成长期结论 →
wiki
- 如果暴露了稳定环境事实 →
Case 8: “把一篇外部 agent 架构文章整理成 AI Agent 可复用资产”
- 归类：
wiki，必要时再加skill - 为什么：文章结论通常先沉淀成正式知识页
- 什么时候加 skill：如果“外部文章入库流程”本身变成稳定可复用方法
- 为什么不是 memory：文章内容通常过长，不适合记忆预算
Case 9: “某个 quick command 的参数展开有坑，需要长期记住这个工具 quirks”
- 归类：
memory - 为什么：这是短小但高价值的工具怪癖，未来会反复影响判断
- 为什么不是 wiki：如果只是一个简短 quirk，升成页面成本过高
- 为什么不是 skill：除非它演化成完整处理流程
Case 10: “如何把外部监控、工单、知识库一起编排成巡检工作流”
- 归类：已授权外部接入 + SOP 或
skill - 为什么：
- 外部系统接入本身 → 已授权 API、CLI、连接器或适配的
MCP - 利用这些能力执行固定巡检方法 → SOP 或
skill
- 外部系统接入本身 → 已授权 API、CLI、连接器或适配的
- 为什么不是 cron：如果方法还没跑稳，先别定时化
Case 11: “每次回答知识问题时，先查 wiki，再补 memory / skills / sessions / external”
- 归类：
wiki，必要时可辅以memory - 为什么：这是系统级检索路径规则，适合成为正式知识页
- 什么时候也进 memory：如果要把它压成一条长期行为提醒，可保留一条简短 rule
- 不建议只放 memory：太容易丢掉结构化上下文
Case 12: “用户说：以后 API keys 统一放环境变量文件，不写进配置文件”
- 归类：
memory - 为什么：这是稳定偏好和长期安全约束
- 为什么不是 wiki：它更像用户级工作规则，而非一页公共知识
- 为什么不是 skill：除非未来要扩展成完整 secrets 管理流程
Case 13: “把层间路由规则写成正式判定清单”
- 归类：
wiki - 为什么：这是高复用、可链接、可维护的正式知识页
- 为什么不是 skill：它定义的是判断框架，不是执行步骤
- 为什么不是 memory：信息超出记忆层的合理密度
Case 14: “某个重复巡检流程已经人工跑顺十几次，输入输出都很稳定”
- 归类：先固化方法（SOP 或
skill），获准后再接调度器/cron - 为什么：
- 先固化方法
- 再上调度
- 反例：如果直接跳到 cron，方法一变就会把噪声自动化
Case 15: “这一轮聊天里临时决定先用 A，再不用 B，后续未必还成立”
- 归类：
session - 为什么：这属于当前线程的临时决策态，不该立刻污染长期层
- 什么时候升级：只有当它被反复验证为稳定规则或稳定偏好时，才考虑进
memory/wiki
Distilled routing heuristics
从这些样板里，可以压出 5 条最实用启发：
- 外部能力接入，先复用已有授权工具；
MCP是可选实现 - 重复方法，先复用 SOP；需要宿主执行契约时再形成
skill - 定时执行，先问方法是不是已经稳定到足以上
cron - 短小稳定事实，才进
memory - 需要长期查阅、扩写、交叉链接的，才进
wiki
Common mistakes these cases prevent
- 把短期决策过早写进 memory
- 把公开操作指南误当成已经安装、获准执行的 skill
- 把外部接入需求误当知识页处理
- 在方法未成熟时急着上 cron
- 把本该正式沉淀的知识只留在 session 里
Takeaway
一句话总结：
- API/CLI/连接器或
MCP管能力接入，SOP 或skill管做事方法，cron管调度，memory管短小稳定事实，wiki管正式知识资产；分不清时，宁可先留在 session，也不要急着污染长期层。
Relations
- depends_on: hermes-layer-routing-decision-checklist
- depends_on: hermes-memory-skills-wiki-boundaries