AI Agent Layer Routing Edge Cases
Summary
这页专门处理最容易误判的边界场景：skill + cron、memory vs wiki、MCP vs skill、session vs 长期层。目标不是给出抽象定义，而是回答“看起来两个层都能放时，到底该怎么裁决”。校准原则仍然是：memory / skills / cron / MCP 先核对目标宿主能力与官方文档，wiki 视作当前本地知识库的正式知识层。
Applicability
以下为合成案例。skill 可由项目 SOP 承担，cron 泛指定时触发，MCP 仅是外部接入的一种实现，API/CLI/已有连接器同样可用；不要求安装任何新组件。写入任何持久层都需要对应授权，公共 Wiki 还需通过公开准入。人类操作指南可放在 operations/，不能仅因包含步骤就排除出 Wiki。
Question
当一个信息或需求同时看起来像两层甚至三层都能承载时，AI Agent 应该如何避免误放？
Edge case 1: skill + cron
场景
“每 30 分钟检查一次站点状态，异常时通知我。”
正确拆分
- SOP 或
skill：定义检查方法 cron：定义调度频率
为什么容易误判
很多人会直接把整件事理解成“定时任务”，于是只想到 cron。
裁决规则
先问：如果把定时拿掉，这件事本身是否还是一个可复用方法？
- 是 → 先复用现有脚本或 SOP，需要宿主执行契约时再形成
skill - 再看是否已经稳定到值得定时化 → 再上
cron
职责校准点
- 本文将
skills作为可复用方法载体 cron只表示定时触发，会话创建与复用依目标调度器而定- 所以
cron不是方法层，只是调度层
Edge case 2: memory vs wiki
场景
“以后 AI Agent 相关规划要先参考官方文档。”
正确拆分
- 短版行为提醒 →
memory - 如果进一步整理成“官方文档优先的设计准则与使用方法” →
wiki
为什么容易误判
因为它既像一个长期规则，也像一个值得长期查阅的设计原则。
裁决规则
先问两个问题：
- 能不能压成一句稳定规则？
- 是否需要来源、结构、小节和交叉链接？
如果：
- 能压成一句，且主要作用是长期提醒 →
memory - 需要结构化解释、边界、案例、扩写 →
wiki
职责校准点
- 持久记忆应有明确预算与准入，具体容量由宿主决定
- 超过“短小稳定事实”的内容，不该硬塞进 memory
Edge case 3: MCP vs skill
场景
“让 AI Agent 能读 GitHub issues，并按我们的标准生成 triage 结果。”
正确拆分
- GitHub 能力接入 → 已授权 API、CLI、连接器或适配的
MCP - triage 流程与判断方法 → SOP 或
skill
为什么容易误判
因为用户经常把“接能力”和“怎么用能力做事”混成一句话。
裁决规则
拆成两问：
- 这个问题是不是在请求外部实时能力？是 → 复用已授权接入，
MCP是可选实现 - 这个问题是不是在请求固定工作方法？是 → SOP 或
skill
反例
如果只做 skill，没有已授权的实时接入，方法写得再好也拿不到实时 GitHub 数据。
只有工具接入、没有明确的 triage 标准和方法，不能保证结果一致；方法可由当前指令、SOP 或 skill 提供。
职责校准点
- 外部工具接入可使用 MCP、API、CLI 或已有连接器
- skill 或 SOP 承载复用方法，不提供外部数据本身
Edge case 4: session vs memory
场景
“这次排障里临时决定先绕过方案 A，用方案 B，后续未必还会这样做。”
正确拆分
- 默认留在
session - 只有反复验证后，才考虑升到
memory
为什么容易误判
因为它看起来“很重要”，人很容易把“重要”误当成“应该长期保存”。
裁决规则
不要问“重不重要”，要问“稳不稳定”。
- 只是这轮会话里的临时决策 →
session - 已经被反复验证为长期规则 →
memory
职责校准点
- 临时会话状态不应自动进入默认持久记忆
- 临时决策、一次性上下文，不该污染持久记忆层
Edge case 5: session vs wiki
场景
“刚讨论出一个架构想法，但还没验证，也没有形成稳定结论。”
正确拆分
- 默认先留在
session - 等结构和结论稳定后，再编译进
wiki
为什么容易误判
因为它“听起来很像方法论”，容易过早正式化。
裁决规则
如果还处在探索态、争议态、未验证态，不要急着变正式知识页。 只有当它已经能被写成：
- 有明确主题
- 有稳定结论
- 有长期复用价值
- 能和其他页面交叉链接
才值得升 wiki。
Edge case 6: wiki vs skill
场景
“我们总结出一套 AI Agent 知识入库原则。”
正确拆分
- 原理、边界、架构理解 →
wiki - 公开入库操作指南 → Wiki
operations/；宿主中的执行契约 →skill
为什么容易误判
因为“原则”与“执行方法”经常长得很像。
裁决规则
看它回答的问题：
- 回答“是什么 / 为什么这样” →
wiki - 公开说明“具体怎么做” →
operations/；宿主中的可触发执行契约 →skill
实战判断
如果一页内容里大量出现：
- step 1 / step 2 / verification / pitfalls
应先区分公开操作指南与宿主执行契约：前者可进
operations/，后者才适合skill。
如果一页内容里大量出现：
- summary / principles / boundaries / related concepts
那大概率更适合
wiki。
Edge case 7: memory vs skill
场景
“不要把 API keys 写进配置文件，统一放环境变量文件。”
正确拆分
- 用户级长期安全偏好 →
memory - 如果扩展成完整 secrets handling 流程 → SOP 或
skill
为什么容易误判
因为安全规则常常既像偏好，又像操作流程。
裁决规则
如果它只是一个短规则，未来每次都需要默认记住 → memory。
如果它已经变成多步操作方法、需要检查与验证 → SOP 或 skill。
Edge case 8: MCP vs cron
场景
“我想每天从外部监控系统抓错误并汇总。”
正确拆分
- 监控系统接入 → 已授权 API、CLI、连接器或适配的
MCP - 每天执行 →
cron - 如果汇总格式有稳定方法 → 用 SOP 或
skill承载
为什么容易误判
因为用户说的是一个完整结果，里面实际混了接入、方法、调度三层。
裁决规则
按顺序拆：
- 先确认已授权接入可用 → API、CLI、连接器或适配的
MCP - 有了能力后，确定方法是否稳定 → SOP 或
skill - 最后才是定时化 →
cron
Edge case 9: wiki + memory
场景
“先查 wiki，再补 memory / skills / sessions / external。”
正确拆分
- 系统级检索原则全文 →
wiki - 压缩成一条长期行为提醒 → 可补一条
memory
为什么容易误判
因为它既是系统架构知识，也是 agent 的长期默认行为。
裁决规则
主承载层看“内容体积和结构需求”：
- 需要完整解释和扩写 →
wiki - 只需要一句默认提醒 →
memory
通常：
wiki为主memory为辅 而不是反过来。
Edge case 10: 先留 session，别急着升长期层
场景
“这次任务里刚试出一个 workaround，但还不知道是不是通用。”
正确做法
先留在 session，继续观察。
升级条件
只有满足以下之一再升级：
- 重复出现，已证实是稳定 quirk →
memory - 提炼成固定处理流程 → SOP 或
skill - 抽象成长期架构或知识结论 →
wiki
核心原则
长期层不是“重要信息回收站”，而是“稳定资产层”。
Quick arbitration rules
遇到纠结时，用这 6 条裁决：
- 接外部能力 → 已授权 API、CLI、连接器或适配的
MCP - 定义方法 → SOP 或
skill；公开操作指南可进operations/ - 定义调度 →
cron - 短小稳定事实 →
memory - 正式知识资产 →
wiki - 还不稳定 →
session
Common edge-case mistakes
- 把“重要但未稳定”的内容过早写进 memory
- 把公开操作指南误当成已经安装、获准执行的 skill
- 把“接入能力”误写成 skill，结果没有真实工具可用
- 把“定时需求”直接做成 cron，却没有先收敛方法
- 把
wiki当默认收纳层，导致知识页里混进大量未验证的任务态内容
Takeaway
一句话总结：
- 当两个层都像能装下时，不要按“重要性”选，而要按“职责”选；职责仍然是：API/CLI/连接器或
MCP管能力、SOP 或skill管方法、cron管调度、memory管短小稳定事实、wiki管正式知识、session管未稳定过程。
Relations
- depends_on: hermes-layer-routing-decision-checklist
- depends_on: hermes-layer-routing-sample-cases