Codex、Claude等四大Agent的Skill管理复用方案探讨

背景

随着大语言模型（LLM）在软件开发和自动化工作流中的应用日益深入，AI Agent（智能体）的概念已从简单的对话机器人演变为具备执行复杂任务能力的独立实体。当前，开发者社区中涌现出多种主流的 AI Agent 框架或平台，包括 OpenAI 的 Codex、Anthropic 的 Claude、以及开源社区中活跃的 OpenClaw 和 Hermes 等。

这些工具虽然底层模型或交互界面不同，但核心诉求趋于一致：如何高效地管理、复用和共享 Agent 的“技能”（Skills）。这里的“技能”通常指代预定义的提示词模板、工作流脚本、工具调用配置或领域特定的知识库。然而，现有的实践缺乏统一的标准，导致开发者在面临“技能归属权”和“复用机制”的选择时感到困惑。本文基于 LINUX DO · AI 社区的一篇讨论帖，深入探讨这一架构设计中的核心矛盾与解决方案。

核心内容

原文提出了一個在 AI Agent 开发中极具代表性的架构决策问题：当使用 Codex、Claude、OpenClaw 和 Hermes 这四个不同的 Agent 时，应该如何管理并复用它们的 Skill（技能/能力模块）？

讨论的核心焦点在于存储与调用架构的二选一：

1. 单体隔离模式（Agent-Local Storage）： 将 Skill 直接放置在每个 Agent 自己的专属目录下。例如，Codex 的技能放在 .codex/skills，Claude 的技能放在 .claude/skills。这种模式下，每个 Agent 拥有独立的技能库，互不干扰。

2. 集中共享模式（Centralized Personal Directory）： 创建一个统一的“个人 Skill 目录”（如 ~/skills 或 ~/.config/ai-skills），然后让所有 Agent（Codex、Claude、OpenClaw、Hermes）通过配置指向该共享目录，从而读取和复用相同的技能模块。

原文作者指出，目前社区中关于这一具体架构的最佳实践尚不成熟，存在 1 个帖子和 1 位参与者进行了初步探讨，但尚未形成共识。这反映了当前 AI 工具链在“标准化”与“定制化”之间的张力。

关键要点

• 多 Agent 异构性挑战：Codex（通常指 OpenAI 的代码解释器或相关 API 封装）、Claude（Anthropic 的模型及其 Claude Code 工具）、OpenClaw 和 Hermes 代表了不同生态的 Agent 实现。它们对技能加载机制、文件格式（如 JSON、YAML、Markdown）和权限管理的要求各不相同，增加了统一管理的难度。
• 隔离 vs. 共享的权衡：
  • 隔离模式优势：配置简单，无需处理跨 Agent 的依赖冲突，适合技能具有强特定性（如仅针对某个模型优化的 Prompt）的场景。
  • 共享模式优势：避免重复劳动，实现“一次编写，多处运行”，有利于建立个人知识库和团队协作。
• 缺乏统一标准：目前没有一个跨平台的“Skill 管理协议”。OpenClaw 和 Hermes 作为较新的或开源项目，其技能系统可能尚未完全成熟，而 Codex 和 Claude 则更多依赖官方提供的工具链或 API 规范。
• 社区探索阶段：该话题在 LINUX DO 社区仅有一位参与者发起，说明这是一个前沿且尚未被大规模解决的技术痛点，开发者正处在从“能用”向“好用”过渡的探索期。

意义与影响

这一讨论触及了 AI 工程化（AI Engineering）中的一个关键基础设施问题：可移植性与复用性。

1. 对开发者的影响： 如果采用集中式 Skill 目录，开发者可以构建一个“个人 AI 操作系统”，将常用的代码生成规则、调试流程、文档写作模板等抽象为通用 Skill，从而在不同模型间无缝切换，降低对单一厂商的锁定风险。反之，若坚持隔离模式，则可能导致技能碎片化，增加维护成本。

2. 对工具生态的影响： 随着 OpenClaw、Hermes 等开源 Agent 框架的兴起，社区有望推动形成开放的 Skill 标准（类似 VS Code 的 Extension 市场或 Docker 的镜像仓库）。这将促进 AI 技能的模块化、商品化和社区共享，加速 AI 应用开发的标准化进程。

3. 未来趋势： 未来可能会出现专门的“Skill 管理平台”或“Agent 中间件”，负责统一解析、版本控制和分发 Skill，屏蔽底层不同 Agent 框架的差异。对于当前开发者而言，建议初期采用“核心通用技能集中管理，特定模型技能隔离存放”的混合策略，以平衡灵活性与复用性。