在构建复杂 AI Agent 时，如何管理成百上千个专业技能（Skills）？
如果把所有操作规范全塞给大模型，上下文瞬间撑爆；如果不给，模型又会变成"一本正经胡说八道"的外行。行业内的共识是走向动态按需加载（Just-in-Time Loading） 。
但具体怎么加载？ Anthropic 官方的 Claude Code 方案 与开源社区的 OpenClaw 框架 给出了截然不同的答案。如果从第一性原理往下挖，你会发现它们在对"知识路由权"的归属上，代表着两种完全不同的系统设计哲学。
一、 核心差异：大模型主动寻址 vs 框架底座编排
为了直观理解这两种架构的边界划分，我们先看系统流转的核心差异：
| 维度 | Claude Code（官方方案） | OpenClaw（开源框架） |
|---|---|---|
| 触发机制 | 模型基于意图，在 API 层显式输出技能工具调用 | 引擎基于上下文，在后台隐式匹配并注入知识 |
| 路由权归属 | 以模型为中心的主动探索系统 | 以系统为中心的自动编排系统 |
| 披露边界 | 按需索取：模型决定需要什么，主动请求加载 | 前置匹配：系统预判执行条件，底层自动寻址注入 |
| 核心权衡 | 极高的通用灵活性与跨技能组合能力 | 极高的执行确定性与运行规则约束 |
二、 第一性原理：同样是三层架构，谁来承担"路由"的心智成本？
要理清架构，首先要明确概念。在 Agent 系统中：
- Tool（原子工具） ：是模型改造世界的"手"。比如
Bash（执行命令）。 - Skill（技能） ：是指导模型如何使用这些手的"知识库/说明书"。比如"如何符合特定规范去提交代码"。
所谓"渐进式披露"，本质上是系统在什么时机把"知识库"喂给模型。有趣的是，这两者在物理设计上都采用了三层披露架构，但它们在"由谁来触发"上走向了相反的分野。
1. Claude Code 的探索模型：把路由权交给大模型
根据 Anthropic 的设定，Claude Code 是一套依赖大模型主动探索的渐进式披露系统。
- 第一层（轻量曝光） ：系统启动时，向模型注入技能的元数据（仅包含
name和description，约占 100 个 Token）。 - 第二层（模型拉取） ：当用户下达任务时，模型通过自身的逻辑推理，判定需要某项技能。于是它在 API 层显式输出一个
Skill(name="xxx")的工具调用（注：对终端用户而言，只需用自然语言表达意图，这层 API 调用完全由模型在后台自动完成，体验极其流畅）。框架收到指令后，将SKILL.md正文扩展进对话上下文。 - 第三层（手动寻址） ：如果技能中包含额外的
references/，模型还需要主动使用文件读取工具去获取。
架构意图：Anthropic 将模型视为"通用规划者"。模型必须先做一个抽象的元决策（"我要先调取技能包，再干活"）。这种设计的代价是偶尔会出现模型忘记调用技能的幻觉，但换来的是极高的灵活性——模型可以自由探索、组合多个技能，或者在阅读完技能包后决定使用框架外的其他工具。
2. OpenClaw 的编排模型：把路由权收归底座网关
OpenClaw 同样拥有三层数据，但它的思路是"系统级自动编排"，最大程度剥离模型的心智负担。
- 第一层（全量底座） ：系统启动时，向模型注入 25 个底层原子 Tool 的完整定义。模型一上来就拥有了改造世界的全套工具集。
- 第二层（隐式映射） ：当用户提交请求时，OpenClaw 的核心引擎（Core Engine）会在后台基于任务上下文与技能的
capabilities字段，执行确定性的规则匹配或启发式检索。一旦条件命中，引擎会在模型执行前或执行中，隐式地将技能说明书注入上下文。 - 第三层（按需注入） ：外部依赖资源由框架级别的规则负责解析，并在推进到特定节点时自动加载。
架构意图：在 OpenClaw 中，模型压根没有"选技能"这个动作，它只负责依据手头的原子工具干活。这本质上是一套高度工程化的规则路由系统。它的泛化探索能力不如 Claude Code，但在预设的专业场景下，执行的确定性和鲁棒性极高。
三、 架构的权衡：灵活性 vs 确定性
回顾这场底层推演，我们发现并没有绝对的优劣，只有基于系统边界划分的 Trade-off：
- 选择 Claude Code 模式：如果你希望 Agent 具有极强的泛化能力，能处理超出预设脚本的复杂长尾问题。它让技能加载成为可观测的中间步骤，将最大的自由度交给了 LLM 的通用推理能力。
- 选择 OpenClaw 模式：如果你在构建企业级专业 Agent，追求极高的任务完成稳定性和权限安全控制。通过网关级别的严格管控，用规则替代大模型的概率路由，能带来更可控的工程交付。
四、 工程落地：一次编写，两处运行
幸运的是，作为技能的开发者，我们不需要被迫站队。目前这两种框架在 SKILL.md 的核心规范上已趋于一致。遵循以下实践，你的技能包即可跨生态通用：
-
统一目录与核心文件：打包为独立文件夹，核心指令写入
SKILL.md（建议 500 行以内）。 -
精心打磨 YAML Frontmatter：
name字段必须标准化（小写字母/连字符）。description必须极度精准。在 Claude 中，这决定了模型是否主动拉取；在 OpenClaw 中，这辅助了引擎的匹配检索。
-
兼容 OpenClaw 的能力声明：在 YAML 中加入 OpenClaw 特有的
capabilities或环境门控字段（如metadata.openclaw.requires）。Claude Code 解析时会自动忽略这些未知字段，互不干扰。
五、 结语：用系统性思维划定 Agent 的边界
回顾这场架构分野，其实这不仅仅是两个框架的碰撞，更是 AI 时代软件工程演进的一个缩影。
不论是构建基于大模型的 Agent 应用，还是设计复杂的微服务与事务处理系统，核心永远是权衡（Trade-off）与边界的划定。Claude Code 选择了将"路由控制权"上浮给 AI，换取了极大的开放性和探索力；而 OpenClaw 选择了将"路由控制权"下沉到工程底座，用确定的系统规则托底了 AI 的不确定性。
当我们用更宏观的系统性思维来看待 Agent 时就会发现：真正优秀的架构，从来不是盲目迷信大模型能解决一切问题，而是清晰地界定"智能"与"工程"的边界。
让大模型聚焦于语义理解、意图识别与多步规划这类擅长的不确定性任务，而将确定性的知识路由与状态流转下沉给底层的系统网关。 这是两种架构在边界划分上给出的不同答案，也是我们在构建 Agent 系统时无法回避的本质选择。这不仅是第一性原理的体现，更是我们在面对越来越复杂的 Agent 生态时，走向成熟架构的必经之路。
