← 返回博客
作者：Harness Academy

Agent 能力增强开源生态分类图（能力域 × 抽象层）

这张图回答一个问题:「给编码 agent 加能力」的开源项目,到底该怎么归类,才不重不漏。

单看某一根轴(只看技能、只看 MCP、只看记忆)都会漏——比如不少记忆类项目用 MCP + hooks 投递、却既不在技能榜也不在 MCP 榜。真正说得清的做法是把生态拆成二维矩阵 + 两条横切竖轨:

  • X 轴 · 能力域——给 agent 补的是哪种能力(会做事 / 调工具 / 记得住 / 查得到 / 会协作 / 会规范做事)。
  • Y 轴 · 抽象层——项目落在哪个抽象级别(定义标准 → 具体实现 → 聚合导航 → 工具链)。
  • 两条竖轨 · 横切所有能力——观测&评估、治理&安全:它们不是某一种能力,而是每种能力都要被看见、被治理,所以横切全表(这与业界 O'Reilly / Letta 的 AI Agents Stack 等主流分层一致,见文末「参考」)。

本图只画分类骨架,不列具体项目与 star——那些归各能力域的详表管。给项目归位时:先定 X(哪种能力)、再定 Y(哪个抽象层),两问定一格;横切所有能力的观测/安全则归竖轨。

配套榜单(本图为上位索引,下钻到数据):

底座:宿主 / 模型(被增强的对象,不算能力域)

前面所有能力都挂在运行 agent 的本体上,并由底层模型驱动。二者都是"被增强 / 被调用"的对象,不是"增强物",故单列为底座——这也是各能力域详表(Top 100)明确排除的那类。

层说明
Agent 本体 / 运行框架跑 agent 循环的宿主
客户端 / 交互界面人机交互层
模型 / 推理 · 路由供给与分发底层模型

沙箱 / 运行时隔离(如 E2B 类)更偏底座,本图未单列。

主矩阵:能力域 × 抽象层

横向读一行 = 某种能力从"标准"到"工具链"的完整栈;纵向读一列 = 同一抽象层里不同能力的项目类型。"—"表示该格在编码 agent 语境下较薄或尚无统一形态。

能力域 \ 抽象层规范 · 协议实现聚合 · 导航 · 注册表工具链(装 / 转 / 扫)详表
① 技能
"会不会做事"		技能格式标准、官方技能库具体技能包技能精选清单 / 市场技能转换器、安装器→ Skills Top 100
⑥ 软件开发方法论
"怎么规范做事"		方法论标准、规约格式方法论框架、SDD 工具包———
② 工具接入 / MCP
"能不能调外部"		MCP 协议规范 + 官方 SDK具体 MCP serverserver 清单 / 注册表 / 网关MCP 构建框架、调试器→ MCP Top 100
③ 记忆 / 上下文
"记不记得住"		—(尚无统一规范)记忆 / 上下文系统—(薄,散见于合集)上下文压缩工具记忆系统落点;可另立《记忆系统榜》
④ 检索 / 知识
"查不查得到"		—(复用通用 RAG)RAG / 代码图谱引擎—(并入合集类)代码检索 MCP、索引器与③相邻,按主身份归此
⑤ 编排 / 多 agent
"会不会协作"		—(多为框架约定)多 agent 编排框架agent / 插件市场—偏框架,跨宿主

两条横切竖轨(横切上面每一种能力)

这两类不归属任一能力域——每种能力都要被观测、被治理,所以画成竖轨,横切全表。业界主流分层图(O'Reilly/Letta、Tensorlake、aimultiple)也一致把它们画成 vertical rails 而非横层。

竖轨干什么
观测 · 评估(observability & evals)追踪、监控、评测 agent 行为
治理 · 安全(governance & security)扫描、护栏、审计、准入

编码 agent 语境下,这两条竖轨的代表项偏少、且多为通用 LLMOps/安全工具(非专为编码 agent),少数专属者如 CC 面板、MCP inspector、技能/MCP 扫描器。

怎么用这张图

  • 给一个项目归位:先问"它给 agent 补哪种能力"(定 X),再问"它是标准 / 实现 / 合集 / 工具"(定 Y)——两问定一格;若它是"横切所有能力的观测/安全",则归竖轨。
  • 为什么记忆类项目常两榜都漏:典型记忆/上下文系统的 GitHub topics 多是 ai-memory / long-term-memory / rag,不带 mcp topic,MCP 关键词搜不到;又因核心不是 SKILL.md 技能,技能榜也不收——夹在两榜之间,只有升到这张图(③记忆 × 实现)才接得住。
  • 三张榜的位置:Skills Top 100= 第①行展开;MCP Top 100= 第②行展开;Top 200 全景总榜= 全表跨域合并 + 底座。这张图是它们的上位索引。

各能力域怎么选(选型建议)

一句话原则:star ≠ 适合你;库大 ≠ 写得好。按需装、少而精,先看活跃度与是否官方,再看 star。

  • ① 技能:通常 3-5 个就够,贪多易致技能冲突/上下文膨胀;先装一个导航合集,其余按方向补。
  • ⑥ 软件开发方法论:先确定工作流模式——如规约驱动开发(SDD)、规划优先等,按方法论选框架;不要与具体技能混淆。方法论工具通常不与技能冲突,可以常年开启。
  • ② 工具接入 / MCP:优先官方 + 高活跃度(官方 server/SDK、大厂 server);第三方 server 装前过一遍权限与来源,别无脑堆。
  • ③ 记忆 / 上下文:尚无统一规范、方案分裂,慎押单一方案;先明确要"跨会话记忆"还是"上下文压缩",两类目标不同。
  • ④ 检索 / 知识:按数据规模选——小库直接读文件/repomix 即可,大库才上 RAG/代码图谱;别为小项目引入重型向量栈。
  • ⑤ 编排 / 多 agent:多 agent 是最后手段,单 agent 能解决就别上;编排框架有学习与调试成本。
  • 竖轨(观测 / 安全):上生产再认真配;编码 agent 语境下多借用通用 LLMOps/安全工具,专属方案还少。

口径与局限

  • 归一格,不重复上榜:跨层项目按"主身份"归一格。如网关聚合类归②;代码检索的 MCP 按主身份"代码检索"归④,在②备注里点一句。
  • X 轴为什么收敛到 6 类:对应 agent 跑起来要补的核心能力——会做事(①)、调工具(②)、记得住(③)、查得到(④)、会协作(⑤)、会规范做事(⑥)。方法论原来与技能合为一行,现单独列出——"技能"解决具体会不会干,"方法论"解决怎么组织工作流,两者互不取代。原先并列的"观测""安全"已按业界共识改为横切竖轨(它们横切每种能力,不是能力本身)。
  • 底座单列不入矩阵:宿主与底层模型是被增强/被调用的对象而非增强物,故拎出为底座;各能力域详表(Top 100)亦排除宿主,口径一致。
  • 本图不列项目:分类图只定骨架;具体项目、star、排名归各能力域详表,避免图随 star 过期。

参考:业界已有的同类分类图

本图与业界主流「AI Agent Stack / 市场图」骨架一致(横向能力层 + 观测、安全两条竖轨),差异在于:业界图多为厂商/商业产品视角(SaaS),本图是开源仓库视角,且明显偏「编码 agent / Claude Code / SKILL.md / MCP」生态——SKILL.md 技能与 Claude Code 插件这块,业界图基本不覆盖。校准与补全参考了:

← 返回博客