External Agent Skills Design Patterns

wiki/ai/concepts/External-Agent-Skills-Design-Patterns.md

分类：ai / concepts · 更新：2026-08-03 09:06 最近更新

外部 Agent Skills 设计模式

这篇笔记总结了 Hermes Skills Hub 和 skills.sh 中高安装量 skill 的设计模式。目标不是盲目安装这些外部 skill，而是提炼出可以迁移到 Hermes 本地技能体系里的工程原则。

核心结论

高质量 agent skill 不是一段 prompt 片段，而是一份工作流契约。它应该明确告诉 agent：

什么情况下触发；
行动前必须检查哪些前置条件；
应该沿着哪条路径执行；
哪些事情不要做；
报告成功前要用什么证据验证；
需要更深资料时应该加载哪些 reference。

当前归档里比较有代表性的样本包括：

vercel-labs/skills/find-skills：skill 发现与筛选工作流。
anthropics/skills/skill-creator：skill 创建与评估闭环。
microsoft/azure-skills/microsoft-foundry：复杂上下文解析与子 skill 路由。
supabase/agent-skills/supabase：安全不变量与操作纪律。
browser-act/skills/browser-act-skill-forge：从一次性网页探索沉淀为可复用 skill 的流程。
mattpocock/skills/improve-codebase-architecture：架构审查与“拷问式”追问循环。

模式 1：强触发描述

好的 skill 会在 frontmatter 的 description: 里放入具体触发词，而不是依赖模型自己猜测何时适用。

常见要素包括：

产品或工具名：Supabase、Cloudflare、Azure Foundry、agent-browser。
用户可能说出的短语：例如 “review my UI”、“run azd deploy”、“find a skill for X”。
任务动词：deploy、validate、troubleshoot、migrate、generate、inspect。
负面边界：明确写出 DO NOT USE FOR。

对 Hermes 的启发：本地 skill 应该使用具体触发语和边界条件。像“debugs code”这种描述太弱；更好的描述要说明触发场景、输入要求，以及相邻场景应该交给哪个 skill。

模式 2：执行前上下文解析

最强的操作型 skill 都要求先做 discovery，而不是直接执行命令。

例子：

Azure Foundry 会先解析 azd 上下文、.foundry/ 目录、agent 元数据、环境、project endpoint 和 eval 意图。
Supabase 会检查 CLI/MCP 可用性、认证状态、RLS 上下文和 migration 纪律。
Browser skill forge 会先区分“只做一次网页操作”还是“要沉淀一个可复用 skill”。

对 Hermes 的启发：任何有副作用的 skill，都应该以显式前置发现开始。目标、环境、凭证或产物不清楚时，不能直接跳到命令执行。

模式 3：验证门禁

有用的 skill 会定义可观察的完成标准：

deploy 前后都要做 deployment validation；
抽取网页前检查 browser/network 稳定性；
数据库 schema 或 migration 后要验证；
skill 创建时做 eval 或 baseline 对比；
写入外部状态后要 read back 或查询状态。

对 Hermes 的启发：skill 必须说明“什么证据才算完成”。这和 Hermes 的基本执行规则一致：交付物必须是经过真实工具输出验证的工作产物，而不是描述性的承诺。

模式 4：Fallback 路径

好的 skill 不只写 happy path，还会写失败后的退路。

例子：

Supabase：根据工具可用性和 CLI 版本，在 MCP、CLI、psql 之间切换。
Azure Storage：优先 MCP，失败后走 CLI。
Skill discovery：先看 leaderboard，再搜索，再做质量审查，最后才在用户确认后安装。

对 Hermes 的启发：把 fallback ladder 直接写进 skill。这样当 API、CLI 或网络失败时，不需要每次重新摸索。

模式 5：渐进披露

大型 skill 不应该把所有内容都塞进 SKILL.md。更好的做法是链接 references 和 scripts，并告诉 agent 什么时候加载它们。

例子：

Azure Foundry 有 setup references、SDK quick references、metadata contracts 和子 skill 路由。
Supabase 为 feedback 和具体操作域链接更深的参考资料。
Browser-act skill forge 链接网页探索指南。

对 Hermes 的启发：SKILL.md 应该是 routing/workflow 层。长资料放进 references/，模板放进 templates/，重复机械步骤放进 scripts/。

模式 6：安全与权限边界

高质量平台 skill 会明确写出 credentials、role assignments、RLS、auth sessions、secret handling 或 permission scopes。

对 Hermes 的启发：任何涉及云平台、浏览器、消息、数据库、购买、部署或用户数据的 skill，都应该有“安全/权限”章节和验证章节。

模式 7：Skill 质量评估闭环

anthropics/skills/skill-creator 的价值在于：它把 skill 写作当成 eval 问题，而不是一次性写文档。

典型流程是：

定义意图；
写初稿；
分别运行 with-skill、baseline 或 old-skill 版本；
做定性和定量评分；
根据结果迭代。

对 Hermes 的启发：创建或大幅修改 skill 时，至少应该用样例 prompt 检查触发、过触发和漏触发；更成熟的场景要做对照评估。

模式 8：主 agent 编排，脚本只做薄壳

一些外部 skill 会把复杂工作流塞进 CLI。对 Hermes 来说，更好的结构是：

主 agent 负责推理、分支判断、总结和用户沟通；
脚本只执行薄的、可重复的机械操作；
后台 agent 或 delegation 负责有边界的子任务，而不是隐藏的持久编排。

这和用户已经明确过的 Hermes 设计原则一致：脚本不应该变成隐藏 orchestrator。

模式 9：Coding-agent 行为护栏

multica-andrej-karpathy-skills 是一个紧凑例子：把公开观察到的 LLM coding 失败模式，转成 CLAUDE.md 行为契约。它的四条规则可以直接映射到 Hermes skill 设计：

先思考再编码：skill 应要求 agent 在不可逆操作前暴露假设并处理歧义。
优先简单：skill 应抑制投机性抽象和过度实现。
外科手术式修改：skill 应约束修改范围；无关清理要报告，而不是顺手改掉。
目标驱动执行：skill 应定义成功标准和验证命令，而不只是建议行为。

重要的设计模式不是“复制这份 CLAUDE.md”，而是：把反复出现的 agent 失败模式转成明确、可检查的规则。这也和 AI-Self-Improvement-Lab 兼容：一条行为规则最终应该有 eval、lint 或 review rubric 来证明它确实改善了结果。

模式 10：经验采集与晋升门槛

[[self-learning-skills

Self-learning skills for AI coding agents]] 补充了一个生命周期模式：skill 不只来自外部发现，也可以从本地成功 session 中采集。真正值得保存的单位是经过验证的 golden path：一个真实跑通、可复用、并且明确避开了哪些死路的流程。

对 Hermes 的启发：复杂调试、入库、部署或雷达任务结束后，应做一次 harvest check。只有满足三个条件才晋升为 skill：有真实通过的验证、失败模式被命名、至少记录了一个被排除的死路。否则应先作为临时 wiki note 或 memory，而不是自动加载的 skill。这样可以避免未经验证的猜测变成长期指令。

模式 11：Agent 配置 lint 作为质量门禁

[[agnix-agent-config-linter Agnix agent config linter]] 提醒我们：CLAUDE.md、AGENTS.md、SKILL.md、hooks 和 MCP config 都应该被当作可 lint 的工程制品。一个 skill 概念上再好，如果 frontmatter、命名、触发语法或跨工具格式错误，运行时也可能完全不可见。

对 Hermes 的启发：skill 设计检查清单需要有机器可检查的一层。安装或改造外部 skill 前，要验证 schema、触发特异性、负面范围、权限边界和工具兼容性。对 llm-wiki cron prompt 也一样：prompt 是运行配置，应该检查是否包含 orientation、raw/hash 处理、index/log 更新、reindex 和静默投递规则。

模式 12：插件粒度与上下文预算

[[context-engineering-kit

Context Engineering Kit]] 提醒我们：技能生态的质量不取决于“装了多少 skill”，而取决于是否能按需加载最小必要上下文。好的插件应具备：明确任务边界、低 token footprint、不与其他插件重复、引用标准或 benchmark、能卸载/替换。

对 Hermes 的启发：skills 不应该长成一个常驻的巨型 prompt。更好的结构是：SKILL.md 做 routing，references/ 承载深内容，命令或脚本处理重复机械步骤，子代理承担可隔离判断。新增外部 skill 前，应先判断它是一个可复用 workflow package，还是只是通用建议集合。

Hermes skill 设计检查清单

保存或安装 skill 前，检查：

[ ] description: 是否包含具体触发短语？
[ ] 是否说明什么时候不要使用这个 skill？
[ ] 是否列出前置条件和 discovery 步骤？
[ ] 目标不清楚前，是否避免副作用？
[ ] 是否包含验证门禁？
[ ] 是否定义 fallback 路径？
[ ] 是否保持“脚本薄壳、主 agent 推理”的结构？
[ ] 是否用渐进披露承载长资料？
[ ] 是否识别安全/权限边界？
[ ] 是否包含样例 prompt 或未来评估用例？

优先改造到 Hermes 的模式

Skill discovery / ranking：来自 find-skills。
Skill creator / eval harness：来自 Anthropic skill-creator。
架构拷问循环：来自 Matt Pocock 的 architecture skill。
Browser skill forge：来自 browser-act，但需要谨慎适配 Hermes 工具。
操作型 runbook：Supabase、Cloudflare、Expo、Firebase 风格的 skill；只改造用户实际会用的生态。

2026-07-03 补充：skill package 的评测、编排与真实性约束

[[caliper-skill-reliability-testing

Caliper]] 说明高质量 skill 需要可重复 eval：with-skill 与 no-skill baseline 对比、pass@k、回归结果保存。[[ai4s-skills

AI4S Skills]] 则展示了 domain skill package 的另一面：多 skill 通过 shared slug 和 output tree 传递中间产物，并对 citation、number、experiment 和 review disclosure 做 provenance 约束。

因此外部 skill 值不值得迁移，不应只看 star 或 README 漂亮程度，而要看三件事：是否有明确触发和输出契约；是否能被 Caliper 类工具评测；是否对事实、数字、引用和实验结果有真实性约束。

模式 13：Skill 安全从静态 lint 走向动态 detonation

[[agent-skill-malware

Cloak and Detonate]] 提醒我们：第三方 agent skill 已经接近软件供应链组件，不能只按 README、frontmatter、star 数或 LLM 静态审查判断安全。攻击者可以保持恶意语义不变，只改变 payload 外观，甚至用 self-extracting packing 在安装期隐藏真正行为。

对 Hermes 的启发：外部 skill 发现应分成“可学习设计模式”和“可安装执行包”两级。前者可以入 wiki；后者必须经过权限边界、可执行脚本、网络/文件/环境变量访问和 sandbox 行为观察。skill lint 的下一步不是更多文本规则，而是最小行为测试。

模式 14：Skill supply chain 与 lockfile

[[agent-skill-supply-chains

Skills Are Not Islands]] 把 skill 视为依赖图组件，而不是孤立 Markdown。一个 skill 可能依赖其它 skill、脚本、Python/Node 包、外部 API、MCP server 或账号权限；只审查 skill 本体会漏掉依赖里的安全和可复现性风险。

对 Hermes 的启发：外部 skill 评估应增加 dependency manifest：dependencies、external_services、scripts、permissions、version/commit/hash。如果未来安装或同步外部 skill，应维护 lockfile-like 记录，并提供 risk-warning audit command。Caliper 式评测也要固定 skill 版本与依赖版本，否则 pass@k 或回归结果不可复现。

模式 15：从技能创建到 SOP 生命周期管理

[[evosop-iterative-tool-optimization

EvoSOP]] 把外部 skill / agent workflow 的问题从“如何写一个好 prompt”推进到“如何管理一个会增长的高阶工具集”。可复用 workflow 不应无限追加，而要经过 construction、merging、evaluation、pruning：从真实成功/失败轨迹中提取，合并重复例程，用 baseline 对比评估，删除低效或高错 SOP。

对 Hermes 的启发：外部 skill 借鉴应优先学习生命周期机制，而不是照搬更多技能。一个技能只有在触发边界、验证证据、安全 effect metadata 和回归样例都清楚时，才值得晋升为长期加载资产。否则它应停留在 wiki source note 或 raw digest 中。

[[action-graded-severity-scale-tool-agents

Action-Graded Severity Scale]] 和 [[deterministic-gates-tool-agent-policy

Deterministic Gates]] 还提示：skill 评估必须记录可执行 effect。一个 skill 即使提高成功率，如果引入跨 scope 写入、外传或不可逆 side effect，也不应被视为净收益。

模式 16：Skill 安全要覆盖发现、检索、选择、执行与演化

[[agent-skill-security-lifecycle-threats

Agent Skill Security]] 把 reusable skill 的风险拆到 repository admission、semantic retrieval、planner selection、runtime execution、skill evolution 五个阶段。它提醒：一个 skill 即使 README 写得清楚、触发描述具体，也可能在检索/路由/依赖/自我演化阶段出问题。

对 Hermes 的启发是，外部 skill discovery 应维护两条通道：design-pattern ingestion 和 execution-package adoption。前者可以通过 wiki 学习；后者必须有 dependency manifest、权限边界、版本/commit/hash、脚本审计、sandbox 行为测试和回归样例。未来如果做 skill marketplace/lockfile，同一个 skill 也应记录 admission decision、retrieval aliases、planner negative triggers、runtime permissions 和 evolution policy。

模式 17：Skill 需要回归评测与身份/权限声明

[[coder-eval-skill-evaluation-ci

coder_eval]] 说明，skill 质量不应只靠 README、star 或一次成功演示判断；它应有可重复任务、with-skill / no-skill 对照、trigger criterion、成本/工具调用记录和 CI verdict。[[chancery-agent-identity-writ-control

Chancery]] 则提醒，操作型 skill 还应声明 agent 身份、可调用资源、凭证隔离方式、TTL、审计字段和撤销路径。

对 Hermes 的 skill 设计检查清单应新增两项：一是至少一个最小回归样例，证明 skill 真的改变行为且没有明显副作用；二是 permission manifest，说明该 skill 是否会读写文件、联网、调用 MCP/server、接触 secret 或启动后台任务。

模式 18：Skill catalog 要按需加载，并把“是否生效”变成可检查对象

[[microsoft-agent-skills-context-driven-development Microsoft Agent Skills]] 提供了平台级 skill catalog 样本：skills、custom agents、AGENTS.md templates、MCP configs 和 installer 共同组成 context package 生态。但它同时明确警告不要一次性加载全部 skills，因为这会造成 context rot、token 浪费、注意力稀释和模式混淆。高质量 skill 生态因此需要 catalog/routing/budget，而不是无限扩展常驻 prompt。

[[vigiles-agent-harness-audit

Vigiles]] 则补上“skill/rule/hook 是否真的生效”的检查层：broken refs、dead hooks、skill collisions、rules-not-enforced 都可能制造 false confidence。对 Hermes 的启发是，外部 skill 进入长期 profile 前应经过四级门禁：静态 lint（格式、触发、负面边界）、audit（权限/依赖/安全）、adoption test（是否被 agent 采用）、eval/regression（是否稳定改善任务）。llm-wiki 自身也应把 cron prompt 的要求变成可检查 contracts，而不是只靠最终报告自证。

模式 19：Skill 可以承担 research-first gate 与本地治理 workbench

[[nothing-new-under-the-sun-research-first-scouting

Nothing New Under The Sun]] 展示了一个重要 skill 形态：不是教 agent 怎么更快实现，而是在实现前阻止 agent 过早写代码。它用 REUSE / USE / FORK / BUY / INTEGRATE / BUILD ladder、evidence matrix、skip 条件和 dedicated read-only scouting agent，把 build-vs-buy / reuse-vs-build 做成前置 gate。对 Hermes 来说，这类 skill 的价值在于降低不必要代码和依赖，而不是增加执行能力。

[[pm-manager-local-project-governance PM Manager]] 则展示了 skill pack 如何扩展成本地治理 workbench：CLI、.pm/ 状态、slash commands、templates、adapters、dashboard 共同构成 project health/control layer。它提醒：一个高价值 skill 可能不是单个 prompt，而是一组 repo-local artifacts 和日常节奏；但这也要求更明确的权限、版本、噪音过滤和状态边界。

模式 20：跨宿主 skill 要分离核心方法论与 host dialect

[[octopus-skill-long-horizon-agent-discipline

octopus-skill]] 提供了一个可迁移模式：核心 methodology 解释每条规则对应的失败模式；host dialect 只负责 Claude Code、Codex、Cursor、grok 等宿主的 loop/goal/stop/notification 差异；实际 arm 再组合 executor、clean-context supervisor 和 durable files。这样避免同一套长任务纪律在不同 agent runtime 中复制、漂移、互相矛盾。

对 Hermes 的启发：llm-wiki、代码修改、浏览器自动化、CVM 发布等 skill 应尽量维护稳定的 methodology 层，再为 cron/交互/批量 ingest/发布等场景做 adapter。新增外部 skill 前，也应要求有真实 consumer/proven run；没有真实任务消费的 prompt 不进入长期 profile，最多作为 source note 学习设计模式。

2026-07-24 补充：skill 与 plugin 需要操作循环和安装治理

[[agentops-bounded-operating-loop

AgentOps]] 显示高价值 skill 不只是提示文本，而是可安装的操作循环：intent、plan、implement、fresh validate、durable verdict、policy hooks 和 day-2 operations。[[bossconsole-agent-operator-console

BOSS Console]] 则提醒 plugin/toolbox 热加载会把 skill 安全问题扩展到运行中 workspace：工具能否被 agent 修改、何时启用、如何禁用、是否接触 secret，都需要 admission 和 audit。

因此外部 skill 评估应增加两项：一是 operating-loop evidence（是否定义停止条件、验证者和 verdict），二是 installation/runtime governance（是否有版本、禁用、权限、secret、hook 生效检查）。

2026-07-27 补充：token 预算、安全 catalog 与设计证据板

[[token-diet-token-efficiency-skill

token-diet]] 提醒，skill 可以专门治理 agent 的 token / 输出 / 读取 / 工具调用纪律：先搜再读、只读必要行、批处理工具、targeted tests、YAGNI，并把 concision 限定在输出与操作冗余上，而不是牺牲推理、关键测试、错误原文或证据。[[sail-skill-secure-ai-lifecycle

SAIL Skill]] 则展示了 catalog-backed skill：安全评估不应靠模型临场列清单，而应引用风险 ID、生命周期阶段、标准映射和缓解措施。

[[design-harness-evidence-board

design-harness]] 和 [[okf-gem-local-knowledge-bundles

OKF Gem]] 共同说明，高价值 skill 越来越像 multi-artifact knowledge/workflow package：Markdown workspace、source/idea/output cards、CLI/lint/search、graph/canvas 和 agent skill 一起组成可审计工作台。对 Hermes 的启发是：外部 skill discovery 应从“是否有用”升级为三问：是否节省或塑形上下文；是否有 catalog/contract/verification；是否把知识和决策保存在可版本化 artifact 中。

这也给 skill 采用门槛增加两个检查项：一是 token/context impact（是否减少 bloat，还是引入常驻噪音）；二是 grounding substrate（是否有真实 catalog、schema、source cards 或 run artifacts 支撑）。尤其是安全、设计和知识管理类 skill，不应只看 README 漂亮程度或 star 数。

2026-07-28 补充：field-tested admission contract

[[hermes-field-kit-skill-admission-contract Hermes Field Kit]] 把外部 skill 采用门槛明确化：一个 skill 只有在解决真实任务、经过真实 workflow 使用、别人能从仓库复现时，才应该进入长期目录。它还要求 Hermes-compatible SKILL.md、tap discovery、triggers/counter-triggers、现实示例、行为测试、已知限制、平台/tool 要求、独立版本和无凭据/私密数据。

这给本页的设计模式增加一个更硬的准入结论：外部 skill 可以先作为 wiki source 学习，但进入 active Hermes profile 前必须通过 field-tested admission、permission/audit、behavior test 和 regression gate。没有反触发、没有真实示例、没有限制说明的 skill，即使 star 高，也只应保留为 raw/digest 候选。

2026-07-29 补充：skill 应有 source / compiled output、预算与漂移检查

[[kitbash-cross-host-agent-skill-format

Kitbash]] 把 agent skill 从“复制一段 Markdown”推进到“源格式 + 编译目标 + 预算 + lockfile”的工程模型。它支持把同一份 skill 编译到 Claude Code、Cursor、Copilot、Cline、Devin、Gemini CLI、Aider 和 AGENTS.md 等目标，并在编译期报告 standing token cost、维护 content-hash lockfile 和 drift detection。

这对 Hermes 的启发是：外部 skill 评估不应只问“能否安装”，还要问它在每个宿主上的加载模式、常驻 token 税、版本/hash、权限和过期产物。未来如果把 llm-wiki 方法论迁移到不同 agent runtime，也应维护 methodology source 与 host adapter / compiled output 的边界，避免手工复制导致规则漂移。

2026-07-30 补充：skill 生命周期比 skill 数量更重要

[[hermes-skill-loop-closed-skill-learning-loop

hermes-skill-loop]] 和 agent-registry 类项目共同说明，外部/本地 skill 的问题正在从“如何写一个好 skill”扩展为“如何治理一组 skill”：来源身份、跨宿主同步、使用次数、最近使用、自动学习、归档、pin、合并、迁移和防重复触发都应成为 skill contract 的一部分。

对 Hermes 来说，低风险方向不是自动安装更多 skill，而是给现有 skill 建立 lightweight registry：触发条件、来源、风险等级、验证方式、最近使用、是否自动生成、是否已验证。自动学习产生的 skill 必须带 origin marker，并进入 curator review；否则一次 session 的 workaround 会污染长期技能层。

2026-07-31 补充：外部技能/插件应通过 admission cell，而不是直接安装

redstamp-deterministic-agent-firewall、contextforge-deterministic-context-budget 和 vibe-loop-bounded-coding-agent-loops 共同说明，外部 agent skill/plugin/CLI 的价值不只在 README，而在它是否有可审计的触发、权限、预算、失败恢复和验证机制。尤其是带 hooks、worker pool、MCP proxy 或 shell scripts 的工具，应先作为 source note 学习设计模式，再经过 admission cell 决定是否安装。

建议的 admission cell 字段包括：source URL、版本/commit/hash、scripts/dependencies、权限与网络、读写路径、代表性任务、runner-observed verification、输出污染扫描、漂移/更新策略、卸载路径。没有这些字段时，默认只入 wiki，不进入 Hermes 执行环境。

2026-08-01 补充：skill governance 需要 scope、preflight 与晋升路径

qm-multiplayer-agent-harness 的 shared skills、grant sharing、admin-gated promotion 与 git skill packs 说明，skill 采用不是“复制到本地目录”这么简单，而是需要 owner、scope、授权、组织级晋升和撤回路径。forgeos-skill-intelligence-control-plane 进一步把 skill 变成 technique retrieval + RoutePlan + ContextPack + evidence contract；agentdoctor-coding-agent-config-audit 则说明 skill/agent 配置本身要被 lint，防止敏感上下文、绕过权限和过期规则进入执行层。

loop-board-autonomous-pr-task-board 的 onboarding skill 也提示：好 skill 不只是命令入口，而应先采访用户的 readiness criteria，并把“何时可看、何时可合并、何时必须停”固化为工作流合同。对 Hermes 来说，外部 skill 的 admission cell 应新增三项：适用 scope、配置 preflight、晋升/撤回策略。

模式 17：Skill 从说明书升级为可路由、可评测、可读写控制的契约

agent-graph-fact-routed-skill-workflows 展示了一个重要方向：Skill 不一定要把完整流程塞进 SKILL.md，而可以把 workflow 编成 graph，由 host facts 选择当前 Route、所需资源和完成证据。simpleenglish-controlled-language-agent-skill 则从表达层补充：skill 输出本身也可以受控语言化，用可测规则减少歧义和 AI slop。optmem-permanent-agent-memory 提醒长期 skill 学习需要 append-only 经验层和显式合并/撤销，而不是自动把所有反馈写进常驻指令。

对 Hermes 的启发：未来评估外部 skill 时，应同时看三件事：是否有 route/fact/outcome contract；是否有可测输出质量或行为指标；是否把记忆、依赖和副作用边界写清楚。只有 README 漂亮但缺少这些合同的 skill，应留在 raw/digest，不应直接安装或长期加载。

模式 20：从用户演示到可验证 skill

record-and-replay-skill 把 skill 采集从“让模型凭空写流程”推进到“用户演示 → 结构化事件流 → compact evidence summary → skill candidate → replay/self-test”。浏览器轨迹中的 selector candidates、DOM snapshot、screenshot 和桌面事件流，比口述步骤更能暴露真实顺序、状态和边界条件。

对 Hermes 来说，这适合作为高价值但高风险的 skill 生成路径：录制材料先作为 raw/source 入库；只有经过 replay、验证步骤、fallback 和敏感信息检查后，才可晋升为长期 skill。它也提示 skill 生态需要 provenance：一个 skill 是从真实演示、外部 README、失败复盘还是人工设计中来，应该影响置信度与安装门槛。

模式 21：外部工具 catalog 需要 operator-safety score

awesome-agentic-devops 提供了 skill/MCP/agent catalog 的更高门槛：官方优先、action capability、human approval、tracing evidence、maturity、operational risk。对于能触达云资源、CI/CD、secret 或生产系统的工具，catalog 的核心不是“收集更多”，而是帮 operator 在安装前判断 blast radius。

对 Hermes 来说，外部 skill 发现页应逐步增加 official/source、permissions、approval、audit、installability、risk 字段。未通过 operator-safety score 的工具可以学习设计模式，但不应自动安装或进入无人 cron 的写路径。

写入记录

2026-08-03 09:00 CST：补充 Awesome Agentic DevOps、ultracodex、record-and-replay-skill、Claude Starter Kit 对 operator-safety catalog、agent-as-function、示范到 skill、tool-level gates 的启发。

2026-08-02 09:01 CST：补充 OptMem、AxisAgentic、Agent Graph、SimpleEnglish 对长期记忆、轨迹证据、事实路由 skill 和受控语言评测的启发。

2026-08-01 09:06 CST：补充 QM、ForgeOS、AgentDoctor、loop-board 对 skill scope、配置 preflight、RoutePlan/ContextPack/evidence contract 和晋升治理的启发。
2026-07-31 09:01 CST：补充外部 skill/plugin/CLI 的 admission cell 字段，强调 source-note 与安装执行包分离。
2026-07-30 09:00 CST：补充 hermes-skill-loop 与 agent-registry 对 skill origin、usage telemetry、curator 生命周期和跨宿主同步治理的启发。
2026-07-29 09:00 CST：补充 Kitbash 对跨宿主 skill 编译、standing token cost、lockfile/drift detection 和 source/compiled output 边界的启发。
2026-07-28 09:00 CST：补充 Hermes Field Kit 对 field-tested skill admission、trigger/counter-trigger、行为测试、限制和外部 skill 采用门槛的启发。
2026-07-27 09:07 CST：补充 token-diet、SAIL Skill、design-harness、OKF Gem 对 token/context 纪律、catalog-backed security skill、证据板和 repo-local knowledge bundle 的启发。

2026-07-23 09:00 CST：补充 Nothing New Under The Sun 与 PM Manager 对 research-first gate、本地治理 workbench、read-only scouting 和 multi-artifact skill pack 的启发。
2026-07-22 09:00 CST：补充 Microsoft Agent Skills 与 Vigiles 对 skill catalog、按需加载、context budget、harness audit/lint/test/eval 和 false confidence 的启发。
2026-07-19 09:04 CST：补充 coder_eval 与 Chancery 对 skill 回归评测、trigger criterion、permission manifest 和身份/权限声明的启发。
2026-07-18 09:00 CST：补充今日 radar 对证据门控、上下文质量、技能安全或控制原语的启发。

2026-07-01 15:00 CST：补充 self-learning-skills 的 experience harvesting / promotion gate，以及 Agnix 的 agent configuration lint 作为技能质量门禁。
2026-07-02 09:00 CST：补充 Context Engineering Kit 对插件粒度、上下文预算和按需加载的启发。
2026-07-03 09:00 CST：补充 Caliper 式 skill eval 与 AI4S Skills 的 provenance-heavy 多技能编排模式。
2026-07-02 09:45 CST：将面向公开发布的正文、小标题、检查清单和说明文字中文化；保留必要的专有名词、仓库名、文件名、命令和技术术语。
2026-07-05 09:02 CST：补充 agent skill malware 对外部 skill 安装前动态安全评估的启发。
2026-07-06 09:00 CST：补充 agent skill supply chain、dependency manifest 和 lockfile-like 记录模式。
2026-07-09 09:00 CST：补充 deterministic gates、action-graded severity 与 EvoSOP 对 harness / benchmark / skill 生命周期的启发。