我在 Claude Code 中构建了一套完整的内容创作工具链。写文章、生成配图、制作播客、抓取网页内容，甚至一键发布到公众号。这些 skills 配合得天衣无缝，我只需要用自然语言描述需求，它们就能自动协同工作。
但有个致命局限，它只能在我的 Claude Code 环境中运行。
我不可能让每个想用这些功能的人都去安装 Claude Code、配置 skills、学习命令行。更重要的是，如果想实现定时抓取、批量生成、自动发布，总不能一直守着 Claude Code 手动操作吧？
真正的需求是，让这些能力可以通过 Web 界面访问，可以通过 API 被其他系统调用，可以自动化运行。
这篇文章就是要解决这个问题。我会先带你理解 Skills、Agents、Subagents 的本质，然后给出具体可行的解耦方案。
要解耦 skills，首先要理解它们的本质。我用做菜来比喻。
Skills 就像菜谱。比如我的"写文章 skill"里写着："先理解主题 → 问清楚目标读者 → 提出 3 种文章结构 → 用户选择后，分段写作并逐段确认"。这就是一份"菜谱"，重点是它不是代码，而是 Markdown 文档。
Agents 就像请来的专业厨师。比如 code-reviewer agent 就像一位专门负责品鉴的大厨，他有自己的评判标准、专业术语、沟通方式。你把做好的菜交给他，他会按照专业标准给出反馈。Agent 和主 Claude 是分开的。
Subagents 就像临时工。比如要做 10 道菜，每道菜都叫一个新的临时厨师来做，做完就走。为什么？因为每个临时工只专注做一道菜，不会被之前的菜影响判断，也不会把上一道菜的调料带到下一道菜里。
它们怎么配合？你（Claude Code 主实例）手里拿着菜谱（Skills），决定做什么菜。需要专业意见时请来大厨（Agent）。需要批量做菜时雇一堆临时工（Subagents）。
既然 Skills 只是 Markdown 文档，为什么离开 Claude Code 就不行了？因为 Claude Code 在背后做了大量"脏活累活"。
第一件事是自动加载和触发。你把 skill 文件放到 .claude/skills/ 目录，Claude Code 会自动扫描、解析、在合适时机触发。就像你把菜谱放进菜谱架，厨房系统会自动识别"今天要做新菜，应该先看这份'准备工作菜谱'"。
第二件事是提供工具箱。Claude Code 内置了一堆工具：读文件（Read）、写文件（Edit）、执行命令（Execute）、搜索代码（Grep）。我的"发布公众号 skill"能工作，是因为它可以调用这些工具，读取文章、调用发布 API、保存结果。
第三件事是管理上下文。所有 skills 共享同一个"工作台"：同样的文件系统、同样的 git 仓库、同样的对话历史。"写文章 skill"生成的内容，"生成配图 skill"可以直接读取，"发布公众号 skill"可以直接使用。
这三件事任何一件缺失，Skills 都无法正常工作。
Claude Agent SDK 是 Anthropic 官方提供的 Agent 开发框架。核心理念是，给 Claude 一台计算机。
就像程序员工作需要终端、文件系统、代码编辑器，Claude 也需要这些工具才能真正"干活"。SDK 就是提供这些能力的框架。
整个系统分三层：
用户层是你和系统交互的地方。可以是网页、可以是 API、可以是命令行。你在这里提需求，系统在这里给你结果。
编排层是"大脑"。主 Agent 在这里工作，听懂你要什么、决定该调用哪些 skills、协调执行顺序、管理上下文。Skills 也在这一层，它们是"工作手册"，告诉 Agent 该怎么做事。
执行层是"手脚"。Subagents 在这里干具体的活：写文件、调用 API、生成图片、发布内容。Tools（工具函数）也在这里，它们是具体的能力。
层级 | 核心职责 | 关键组件 |
------|---------|---------|
用户层 | 接收需求、返回结果 | Web 界面、API 端点、CLI |
编排层 | 理解需求、调度执行 | 主 Agent、Skills |
执行层 | 完成具体任务 | Subagents、Tools、文件系统 |
简单说，用户层接需求，编排层做决策，执行层干活。
场景：你要写一篇文章并发布到公众号。
Skills 是"剧本"。比如"内容创作 skill"的剧本是：
1. 先问用户写什么主题，目标读者是谁
2. 提出 3 种文章结构让用户选择
3. 分段写作，每段写完确认一次
4. 生成配图
5. 发布到公众号
Skills 不干活，它只告诉 Agent"该做什么、按什么顺序做"。
Agent 是"项目经理"。当你说"我要写一篇关于 AI 的文章"，主 Agent 会理解需求、找到"内容创作 skill"这份剧本、按照步骤工作、决定什么时候派发 Subagent、收集所有结果并交付。
Subagents 是"临时工"。主 Agent 会派发多个 Subagents：
- 写作 Subagent 负责写某一段
- 配图 Subagent 负责调用图片生成 API
- 发布 Subagent 负责调用公众号 API
每个 Subagent 只关注自己的任务，完成后就消失。写作 Subagent 不需要知道配图细节，配图 Subagent 不需要知道发布逻辑。这样每个任务都是"干净"的。
如果想把 skills 搬到 Web 或 API 环境，Claude Code 帮你做的那些事，你都得自己做。具体是四件事：
第一，Skill 加载和触发。读取 skill 文件，判断什么时候用哪个 skill。Claude Code 有自动扫描和智能匹配机制，你需要自己实现。
第二，工具函数。实现图片生成、公众号发布等具体功能。Claude Code 提供了标准工具，你需要把业务能力封装成可调用的函数。
第三，上下文管理。让不同 skills 之间能传递数据和结果。这涉及状态存储、会话管理、数据持久化。
第四，Agent 管理。派发和协调多个 AI 实例。需要处理并发、错误处理、资源回收等复杂问题。
关键在于编排层。执行层相对简单（调用 API、操作文件），用户层也好办（做个网页或 API 接口）。难的是编排层，如何让主 Agent 理解需求、选择 skills、协调执行。
方案一：直接使用 Claude Agent SDK。用 Anthropic 官方的 Agent SDK 来构建系统。把 skills 改造成 SDK 能识别的格式、用 SDK 提供的 Agent 作为编排层、把工具封装成 SDK 的 Tool。
优点是官方支持、架构成熟、文档完善。缺点是需要深入学习 SDK、改造现有 skills、部署相对复杂。
方案二：用现成的 AI Agent 平台。比如 LangChain、AutoGPT、n8n 等，它们提供了完整的 Agent 管理能力。你只需要把 skills 的逻辑用平台的方式重新实现，把工具接入平台的工具市场。
优点是开箱即用、社区生态好、有现成模板。缺点是平台学习成本、可能需要重写 skills、受限于平台能力。
方案三：自建轻量级编排层。自己写一个简单的 Agent 管理器。用 Claude API 作为核心能力、用简单的规则引擎做 skill 匹配、用 HTTP 接口封装工具函数、用数据库管理上下文。
优点是完全可控、轻量级、定制灵活。缺点是需要自己处理各种细节、维护成本较高。
方案 | 优点 | 缺点 | 适合场景 |
------|------|------|---------|
Claude Agent SDK | 官方支持、架构成熟 | 学习成本高、需改造 skills | 长期项目、需稳定性 |
AI Agent 平台 | 开箱即用、生态好 | 受限平台能力、可能需重写 | 快速验证、标准化需求 |
自建编排层 | 完全可控、轻量级 | 需处理细节、维护成本高 | 定制化需求、小规模应用 |
不管选择哪种方案，有几个建议可以帮你少踩坑。
第一，先做最小可行版本。不要一上来就想把所有 skills 都搬过去。选一个最简单的 skill，比如"生成文章摘要"，先把它跑通。这个过程会让你理解整个技术栈，发现隐藏的问题。
第二，保持 skill 的纯粹性。skill 应该只定义"做什么"，不应该包含"怎么做"的实现细节。比如"生成配图"这个 skill，应该只说"根据文章内容生成 3 张配图"，而不应该写死"调用 DALL-E API，参数是..."。
第三，工具函数要标准化。所有工具都应该遵循统一的接口规范。输入是什么格式、输出是什么格式、错误怎么处理，都应该标准化。
第四，做好上下文管理。这是最容易出问题的地方。你需要明确哪些数据需要跨 skill 共享（比如用户 ID、文章主题），哪些应该隔离（比如某个 subagent 的临时变量）。建议用显式的数据传递，而不是全局状态。
第五，监控和日志。一定要记录每个 skill 的执行情况、每个 agent 的调用、每个工具的输入输出。出问题时，这些日志是你唯一的线索。
如果你的 skills 真的解耦成功了，变成了可以通过 API 调用的服务，下一步会发生什么？
可能是其他人开始用你的 API，集成到他们的系统里。可能是你把多个 skills 组合成更复杂的工作流。可能是你开始卖这些能力，变成一个 SaaS 服务。
但更有意思的可能性是，这些 skills 会相互调用，形成一个 AI Agent 网络。你的"写文章 skill"会调用别人的"图片生成 skill"，别人的"内容分发 skill"会调用你的"文章优化 skill"。每个人贡献自己擅长的能力，所有能力组合起来，能做的事情远超单个 skill 的总和。
这才是解耦的真正意义。不只是让 skills 可以独立运行，而是让它们可以自由组合、相互增强、涌现出新的可能性。
就像互联网刚出现时，没人想到会有今天的生态。当 AI 的能力可以像 API 一样自由调用和组合，会出现什么？这个问题，我也在探索。
完全已实现截图：