全文为解析该开源项目arscontexta一、TL;DR随着 AI Agent 越来越普及写单一 Prompt 的时代正在过去未来必然是写 Skills技能的时代。当个人的 Skills 数量激增且互相调用、嵌套时必然会引发“技能通胀”和逻辑冲突。关键判断技能分级Skills 必须遵循“原子 (Atoms) - 分子 (Molecules) - 化合物 (Compounds)”的三级抽象保持极简的单点边界。架构借鉴arscontexta本是一个为 Agent 提供持久化外脑的插件但其“三度空间”与“6 Rs 流水线”架构为我们管理庞大的Skill Graph技能图谱提供了绝佳的范本。上下文隔离通过派生子代理Subagent执行原子 Skill能有效解决深层调用时的逻辑“打架”和幻觉问题。“未来的核心竞争力不在于你写了多长多牛的 Prompt而在于你能否编织一张边界清晰、能被 Agent 自动调度的 Skill Graph。”二、背景与痛点技能通胀时代的混乱最近看了一篇微信公众号文章以及推特上的探讨里面提到的一个思路非常戳中我每个人日后都会生产出各种各样的 SkillsSkills 之间可能会互相调用甚至一个高阶的 Skill 就是基于其他几个底层 Skills 拼装而成的。在我的实战中这种现象已经开始显现。当你只有 3 个 Skill 的时候你靠大脑记忆就能轻松调度但当你有 30 个、50 个 Skill并且一个“做一份周报”的 Skill 需要同时调用“查阅日历”、“抓取 GitHub”、“排版 Markdown”等底层 Skill 时灾难就来了。如果 Agent 的依赖链深度很深使用 Skills 很多就会出现Skills 之间的逻辑打架。Agent 会在超长的上下文里迷失不知道到底该听哪个指令的。个人感觉这时候我们就需要给这些海量的 Skills 做归纳整理。这里**Skill Graph技能图谱**就是一种极具前瞻性的解法。三、核心理念Skill 的三级抽象参考 Claude Code 的源码解析以及软件工程的单一职责原则一个独立优秀的 Skill必须是功能最小粒度只要干好一件事即可。只有当每一个 Skill 都有足够清晰的边界日后互相调用才不会出现冲突。我们可以将 Skills 的层级分为三类1. 原子级Atoms这是最小粒度的基础组件。它不包含复杂的业务逻辑只负责单一的、确定的输入输出。比如获取当前日期、将本地图片转为 OSS 链接、读取指定 URL 的纯文本。2. 分子级Molecules / Multi-skill chains将几个原子 Skill 组合起来完成一个有上下文的小型任务流。比如抓取 GitHub 仓库信息下载源码 (Atom)扫描目录结构 (Atom)。3. 化合物级Compounds / End-to-end workflows这通常是用户直接触发的入口代表一个完整的端到端工作流。它不需要自己去干脏活累活而是作为一个“指挥官Coordinator”去调度底层的分子和原子。举个完善的例子生成一份高质量 PPT如果你把所有要求大纲、字体、排版、颜色都塞进一个generate-ppt的巨无霸 Skill 里Agent 一定会发疯排版和配色指令极易互相覆盖。合理的 Skill Graph 应该是这样的Atom 1 (extract-outline)专门负责从长文章中提取 5 页 PPT 的骨架。Atom 2 (ppt-theme-picker)专门负责根据主题决定字体组合与色板只管颜色和字体。Atom 3 (ppt-layout-renderer)专门负责将文案注入到 HTML 骨架中只管排版。Atom 4 (ppt-qa-auditor)专门负责审核比如检查大标题是否超过 10 个字图片比例是否正确。Compound (auto-ppt-maker)它只做一件事——按照顺序依次调用上面 4 个 Atom将上一个的输出作为下一个的输入。“边界越清晰组合越强大。把巨无霸拆成原子是构建图谱的第一步。”四、从 arscontexta 借鉴的 Skill Graph 架构有了这么多的原子和分子怎么管理它们我们可以从arscontexta这个开源项目里偷师。arscontexta的本质是给 Claude Code 生成一套量身定制的知识系统Vault。但仔细看它的架构你会发现它完美契合了 Skill Graph 的管理需求。1. 三度空间映射它采用了严格的self/、notes/、ops/目录隔离self/身份与索引我们可以把它当作 Agent 的“技能调度中枢”。里面存放着 Agent 当前可用的所有 Compound 级别的工作流入口。notes/原子节点映射到技能图谱中这里就是存放数以百计的 Atom 和 Molecule 级别 Skill 的地方。每个 Skill 都是图谱上的一个节点。ops/执行队列用于存放临时状态和任务队列。当 Compound 开始调度时当前的执行进度比如已经跑完了字体选择等待排版就记录在这里。2. 通过 MOCMap of Content进行路由arscontexta极度依赖 MOC内容映射图来让 Agent 不至于迷路。在 Skill Graph 中我们可以为同一领域的 Skills 建立 MOC。比如前端开发 MOC下关联了创建 React 组件、编写 CSS 样式等原子技能。Agent 在接到大任务时先查 MOC再顺藤摸瓜找到具体要调用的原子 Skill这就避免了全局盲目搜索带来的幻觉。五、源码级剖析如何避免上下文污染在多 Skill 嵌套调用的场景中最致命的坑就是上下文污染。Agent 的 Context Window 填满了前几个 Skill 的执行日志后注意力机制会严重退化。arscontexta的做法堪称教科书级别。源码位置README.md/ralph 5 |-- Read queue, find next unblocked task |-- Spawn subagent (fresh context) | -- Runs skill, updates task file, returns handoff |-- Parse handoff, capture learnings这段逻辑深度解读它实现了一个名为/ralph的队列管理器。当系统需要连续执行 6 RsRecord, Reduce, Reflect, Reweave, Verify, Rethink等多个流水线任务时它并没有在一个对话上下文里硬扛。相反每执行一个 Phase也就是调用一个 Skill它都会Spawn subagent (fresh context)——派生一个全新的子代理。子代理拿着纯净的、仅包含当前单一原子 Skill 所需上下文的 Prompt 去执行。执行完毕后仅返回高度浓缩的handoff交接结果给主 Agent。“主 Agent 负责统筹全局图谱子 Agent 拿着单程票去执行原子技能这是解决逻辑打架的唯一正解。”六、实战排障与避坑指南如果你准备开始构建自己的 Skill Graph请务必注意以下几点故障现象根因剖析防御性解决方案Agent 在执行复杂任务时突然“忘记”了早期的约束巨无霸 Skill 导致 Token 过载Attention 机制失效强制拆分。将任务拆解为 Atom 级使用 Subagent 隔离执行。Agent 找不到该用哪个 Skill或者用错了 Skill原子 Skill 的命名或描述不够正交Orthogonal存在歧义强化接口描述。每个 Skill 必须像 API 文档一样在description中写清楚输入什么、输出什么、绝对不做什么。多个同类 Skill 互相打架如两个格式化代码的 Skill缺乏统一的路由中心引入 MOC内容映射图按领域对 Skill 进行分类让 Agent 遵循图谱路径寻路。七、总结研究完arscontexta和微信上的那几篇探讨个人感觉AI 时代的知识管理和工作流管理正在发生底层范式的转移。以前我们把精力花在如何写出几万字的 Prompt 上而现在真正的壁垒在于如何像搭乐高一样把最小粒度的积木Atoms拼接成复杂的机器Compounds。你的 Skill Graph 有多大、边界有多清晰、调度有多智能你在 AI 时代的杠杆率就有多高。参考文献agenticnotetaking/arscontexta 源码关于 Skill Graph 与技能调用的探讨 (微信公众号)arscontexta 核心思路 (Twitter) Skill Graph：skills时代如何搭建技能图谱
全文为解析该开源项目arscontexta一、TL;DR随着 AI Agent 越来越普及写单一 Prompt 的时代正在过去未来必然是写 Skills技能的时代。当个人的 Skills 数量激增且互相调用、嵌套时必然会引发“技能通胀”和逻辑冲突。关键判断技能分级Skills 必须遵循“原子 (Atoms) - 分子 (Molecules) - 化合物 (Compounds)”的三级抽象保持极简的单点边界。架构借鉴arscontexta本是一个为 Agent 提供持久化外脑的插件但其“三度空间”与“6 Rs 流水线”架构为我们管理庞大的Skill Graph技能图谱提供了绝佳的范本。上下文隔离通过派生子代理Subagent执行原子 Skill能有效解决深层调用时的逻辑“打架”和幻觉问题。“未来的核心竞争力不在于你写了多长多牛的 Prompt而在于你能否编织一张边界清晰、能被 Agent 自动调度的 Skill Graph。”二、背景与痛点技能通胀时代的混乱最近看了一篇微信公众号文章以及推特上的探讨里面提到的一个思路非常戳中我每个人日后都会生产出各种各样的 SkillsSkills 之间可能会互相调用甚至一个高阶的 Skill 就是基于其他几个底层 Skills 拼装而成的。在我的实战中这种现象已经开始显现。当你只有 3 个 Skill 的时候你靠大脑记忆就能轻松调度但当你有 30 个、50 个 Skill并且一个“做一份周报”的 Skill 需要同时调用“查阅日历”、“抓取 GitHub”、“排版 Markdown”等底层 Skill 时灾难就来了。如果 Agent 的依赖链深度很深使用 Skills 很多就会出现Skills 之间的逻辑打架。Agent 会在超长的上下文里迷失不知道到底该听哪个指令的。个人感觉这时候我们就需要给这些海量的 Skills 做归纳整理。这里**Skill Graph技能图谱**就是一种极具前瞻性的解法。三、核心理念Skill 的三级抽象参考 Claude Code 的源码解析以及软件工程的单一职责原则一个独立优秀的 Skill必须是功能最小粒度只要干好一件事即可。只有当每一个 Skill 都有足够清晰的边界日后互相调用才不会出现冲突。我们可以将 Skills 的层级分为三类1. 原子级Atoms这是最小粒度的基础组件。它不包含复杂的业务逻辑只负责单一的、确定的输入输出。比如获取当前日期、将本地图片转为 OSS 链接、读取指定 URL 的纯文本。2. 分子级Molecules / Multi-skill chains将几个原子 Skill 组合起来完成一个有上下文的小型任务流。比如抓取 GitHub 仓库信息下载源码 (Atom)扫描目录结构 (Atom)。3. 化合物级Compounds / End-to-end workflows这通常是用户直接触发的入口代表一个完整的端到端工作流。它不需要自己去干脏活累活而是作为一个“指挥官Coordinator”去调度底层的分子和原子。举个完善的例子生成一份高质量 PPT如果你把所有要求大纲、字体、排版、颜色都塞进一个generate-ppt的巨无霸 Skill 里Agent 一定会发疯排版和配色指令极易互相覆盖。合理的 Skill Graph 应该是这样的Atom 1 (extract-outline)专门负责从长文章中提取 5 页 PPT 的骨架。Atom 2 (ppt-theme-picker)专门负责根据主题决定字体组合与色板只管颜色和字体。Atom 3 (ppt-layout-renderer)专门负责将文案注入到 HTML 骨架中只管排版。Atom 4 (ppt-qa-auditor)专门负责审核比如检查大标题是否超过 10 个字图片比例是否正确。Compound (auto-ppt-maker)它只做一件事——按照顺序依次调用上面 4 个 Atom将上一个的输出作为下一个的输入。“边界越清晰组合越强大。把巨无霸拆成原子是构建图谱的第一步。”四、从 arscontexta 借鉴的 Skill Graph 架构有了这么多的原子和分子怎么管理它们我们可以从arscontexta这个开源项目里偷师。arscontexta的本质是给 Claude Code 生成一套量身定制的知识系统Vault。但仔细看它的架构你会发现它完美契合了 Skill Graph 的管理需求。1. 三度空间映射它采用了严格的self/、notes/、ops/目录隔离self/身份与索引我们可以把它当作 Agent 的“技能调度中枢”。里面存放着 Agent 当前可用的所有 Compound 级别的工作流入口。notes/原子节点映射到技能图谱中这里就是存放数以百计的 Atom 和 Molecule 级别 Skill 的地方。每个 Skill 都是图谱上的一个节点。ops/执行队列用于存放临时状态和任务队列。当 Compound 开始调度时当前的执行进度比如已经跑完了字体选择等待排版就记录在这里。2. 通过 MOCMap of Content进行路由arscontexta极度依赖 MOC内容映射图来让 Agent 不至于迷路。在 Skill Graph 中我们可以为同一领域的 Skills 建立 MOC。比如前端开发 MOC下关联了创建 React 组件、编写 CSS 样式等原子技能。Agent 在接到大任务时先查 MOC再顺藤摸瓜找到具体要调用的原子 Skill这就避免了全局盲目搜索带来的幻觉。五、源码级剖析如何避免上下文污染在多 Skill 嵌套调用的场景中最致命的坑就是上下文污染。Agent 的 Context Window 填满了前几个 Skill 的执行日志后注意力机制会严重退化。arscontexta的做法堪称教科书级别。源码位置README.md/ralph 5 |-- Read queue, find next unblocked task |-- Spawn subagent (fresh context) | -- Runs skill, updates task file, returns handoff |-- Parse handoff, capture learnings这段逻辑深度解读它实现了一个名为/ralph的队列管理器。当系统需要连续执行 6 RsRecord, Reduce, Reflect, Reweave, Verify, Rethink等多个流水线任务时它并没有在一个对话上下文里硬扛。相反每执行一个 Phase也就是调用一个 Skill它都会Spawn subagent (fresh context)——派生一个全新的子代理。子代理拿着纯净的、仅包含当前单一原子 Skill 所需上下文的 Prompt 去执行。执行完毕后仅返回高度浓缩的handoff交接结果给主 Agent。“主 Agent 负责统筹全局图谱子 Agent 拿着单程票去执行原子技能这是解决逻辑打架的唯一正解。”六、实战排障与避坑指南如果你准备开始构建自己的 Skill Graph请务必注意以下几点故障现象根因剖析防御性解决方案Agent 在执行复杂任务时突然“忘记”了早期的约束巨无霸 Skill 导致 Token 过载Attention 机制失效强制拆分。将任务拆解为 Atom 级使用 Subagent 隔离执行。Agent 找不到该用哪个 Skill或者用错了 Skill原子 Skill 的命名或描述不够正交Orthogonal存在歧义强化接口描述。每个 Skill 必须像 API 文档一样在description中写清楚输入什么、输出什么、绝对不做什么。多个同类 Skill 互相打架如两个格式化代码的 Skill缺乏统一的路由中心引入 MOC内容映射图按领域对 Skill 进行分类让 Agent 遵循图谱路径寻路。七、总结研究完arscontexta和微信上的那几篇探讨个人感觉AI 时代的知识管理和工作流管理正在发生底层范式的转移。以前我们把精力花在如何写出几万字的 Prompt 上而现在真正的壁垒在于如何像搭乐高一样把最小粒度的积木Atoms拼接成复杂的机器Compounds。你的 Skill Graph 有多大、边界有多清晰、调度有多智能你在 AI 时代的杠杆率就有多高。参考文献agenticnotetaking/arscontexta 源码关于 Skill Graph 与技能调用的探讨 (微信公众号)arscontexta 核心思路 (Twitter)