Awesome Agent-Native Services：给 AI 智能体准备的一整套"上岗装备清单"

一、故事从一次真实的困境开始

想象一下这个场景：你在给团队搭一个能真正干活的 AI 智能体。模型有了，提示词也调好了，但接下来这一步卡住了——智能体要发邮件，用哪个邮箱？它要记住上周用户的偏好，用什么记忆服务？它要在沙箱里跑一段自己生成的 Python 代码，怎么隔离？它要访问网页，是用 Playwright 自己起浏览器还是用托管浏览器？它要调用第三方 API，凭证怎么管？它要是花超了预算，谁来拦？

于是你打开十几个标签页，开始一个个搜"AI agent email API"、"agent memory API"、"sandbox for AI agents"。每个搜索结果都给你一篇博客，每篇博客都推荐三到五个工具，其中两到三个已经停更或者根本没有面向智能体的接口。你花了一整个周末，最后得到的是一张写满了候选名的便利贴，而不是一个能跑的东西。

这个仓库就是那根便利贴的终点。它的作者（GitHub ID haoruilee，同时运营着 lihaorui.com）把这件苦活做成了产品：一份只收录"智能体原生"服务的精选目录，并且为每一个条目写清楚"智能体到底怎么把它接进去"。

二、背景：什么是 "Agent-Native"，为什么这个词不是新包装

仓库的 README 里有一个明确的分类体系，用三个标签区分不同形态的服务：

标签	含义
agent-native	从设计之初就为智能体而生，或专门用于操作智能体原生状态
agent-adapted	原本面向人类，后来扩展了智能体接口
agent-builder	给人类用的，用来搭建和编排智能体的平台

关键在于：这个仓库只收录 agent-native。所有 agent-adapted 和 agent-builder 类的产品（LangChain、CrewAI、各种通用编排框架）都被明确排除在主体之外。这不是故作高深，而是因为"给智能体用的服务"和"给人用的、顺便加了 AI 功能的平台"在工程上是两种完全不同的东西——前者的接口形状、身份模型、计费单位、错误语义，都是照着智能体设计的。

作者在 CONTRIBUTING.md 里写了五条硬性准入标准，任何一条不满足都进不来：

1. Agent-First 定位 —— 官方文档或主页明确把 AI 智能体写为核心消费者；
2. 智能体特有原语 —— API 暴露的抽象在人类场景下没有对应物（什么叫"人类场景下没有对应物"？比如智能体专用的钱包、可以代表智能体对外发信并拥有独立身份与审计轨迹的邮箱）；
3. 自治兼容的控制面 —— 智能体操作时不需要每一步都找人确认；
4. 机对机的集成面 —— 主接口是 SDK / REST / MCP / webhook，而不是 GUI；
5. 智能体身份与委派语义 —— 智能体身份、被授予的权限、审计轨迹是一等概念。

第五条是这批标准里最"重"、也最有价值的一条。2026 年前后关于"智能体基础设施"的主流讨论（比如 Builder.io 提出的 agent-native 架构、Cosmic 讲的内容基础设施改造）大多停留在"API 友好"这一层，而这里把"智能体有没有自己的身份、能不能被代表、被委派、被追责"直接写成了准入门槛——这恰恰是智能体从 demo 走向生产时最先崩掉的地方。

三、一个生活化的类比：这不是"应用商店"，而是"持证上岗清单"

打个比方。普通的 awesome-list 像一本大众点评合集——告诉你哪家餐厅好吃、评分多少、值不值得去。而这个仓库更像一份外卖骑手持证上岗的装备与资质清单：每一样装备都要说清楚"你是以什么身份上岗的""你能接什么单""出了事谁负责""证件在哪办""多久要复查一次"。

这种视角差异带来的直接结果是信息颗粒度完全不同。随便打开一个服务条目（比如 services/memory-and-state/mem0.md），你会看到这样的结构：

• 官网、官方文档、官方仓库、官方 MCP Server 分别的地址；
• "Quickest verified path"（最快验证路径）——不是"先注册账号然后随便看看文档"，而是一行可以直接执行的最小命令（对 mem0 是 pip install mem0ai 然后 m.add(messages, user_id=...)）；
• Agent Skills 区块——这个服务有没有官方或社区的 SKILL.md，装到 Claude Code / Cursor / Codex 里之后，智能体会被教成什么样；
• MCP 区块——官方 MCP Server 在不在，覆盖哪些工具；
• Funding / Adoption——融了多少轮、开发者数量，这种数据直接关系到"这家服务活不过半年吗"；
• 以及最关键的：能力边界与缺口要显式披露——只读类服务必须明说自己没有自治、没有 MCP、没有身份与委派，不能给智能体一种它其实不拥有的控制感。

四、核心功能：一套"目录 + 机器契约 + 可执行安装器"的组合

这个仓库真正的技术含量不在 README，而在它围绕目录构建的一整套工程化设施。

4.1 目录规模与结构

当前 catalog_version 为 2026-10-23，共收录 258 个服务条目，分布在 16 个分类里。实际分布如下（按条目数）：

分类	条目数	分类	条目数
Agent Runtime & Infrastructure	34	Agent Harnesses & Control Planes	14
Memory & State	30	Observability & Tracing	14
Browser & Web Execution	28	LLM Gateway & Routing	11
Tool Access & Integration	24	Search & Web Intelligence	9
Commerce & Payments	19	Voice & Phone	8
Code Execution	17	Meeting & Conversation	7
Agent Social & Community	16	Durable Execution & Scheduling	6
Communication	16	Oversight & Approval	5

这张分布图本身就是一份行业报告：运行时与基础设施（34）+ 记忆（30）+ 浏览器（28）三块占了三分之一以上，说明当下智能体工程的主要难点已经从"把模型调通"转移到了"让智能体在真实世界里持续、可靠、有状态地工作"。而"人工审批"（Oversight & Approval）只有 5 条、"持久化执行与调度"只有 6 条——这两个恰恰是企业落地时最需要、但供给最少的方向，值得作为选型时的重点关注区。

4.2 三种消费形态，覆盖人和机器

一个值得称道的设计是：同一份目录同时提供人读版和机器读版。

• 人读版：README.md（12.5 万字符）、skill.md（6.2 万字符）、以及 docs/ 下的 Jekyll 静态站（发布在 lihaorui.com/awesome-agent-native-services/）。
• 机器读版：catalog.json（37 万字符，带 JSON Schema）、catalog.schema.json（Draft 2020-12 校验契约）、llms.txt（给 LLM 读的索引）。

llms.txt 里把入口写得很清楚——发现用 skill，做确定性过滤用 JSON catalog，看证据去 service dossier。这种分层对 AI 原生项目来说很关键：现在越来越多的项目干脆不再维护人类 README，而是直接提供 llms.txt + skill.md，让智能体自己去读。

4.3 四个 Agent Skills + Claude Code 插件市场

仓库的 .skills/ 目录下有四个 SKILL.md：

Skill	作用
find-agent-service	按任务路由找到匹配的服务
install-agent-service	把选中的服务真正装上（URL 接入 → Agent Skill/plugin → MCP → CLI → SDK 的优先级排序）
evaluate-agent-native	评估某个候选服务是否真的符合 agent-native 标准
add-to-awesome-list	把新服务按格式提交进目录

同时通过 .claude-plugin/marketplace.json 挂到了 Claude Code 插件市场，安装方式是标准的：

/plugin marketplace add haoruilee/awesome-agent-native-services
/plugin install awesome-agent-native-services@awesome-agent-native-services

或者直接把 .skills/find-agent-service 拷到 ~/.claude/skills/。这意味着一个 AI 编码助手可以直接把这份目录当成自己的"服务选型大脑"——这大概是这个仓库最锋利的地方：它不是给人读的清单，它是给智能体读的清单。

4.4 CI 里的"目录保鲜"机制

.github/workflows/ 下有三条流水线，其中 catalog-freshness.yml 值得单独说：每周一早上 6:17 定时运行，做四件事——

1. python3 scripts/build-machine-catalog.py --check 校验机器契约；
2. check-repository-health.py --local --freshness-max-days 45 检查每个条目距上次复核是否超过 45 天，超期即视为过期；
3. --external-canonical --workers 16 并发抓取每个条目的官方链接做存活审计，还带重试；
4. bash scripts/check-agent-endpoints.sh 验证部署出去的站点端点真的可用。

对"第三方服务清单"这种最容易腐烂的内容来说，45 天保鲜窗口 + 每周自动链接巡检，是把 awesome-list 从"一次性整理"变成"可持续维护"的必要条件。脚本里还专门把 HTTP 402（x402 付费墙的设计行为）、419（Hacker News 反爬）列为"受保护状态"，不做误判——这种细节说明作者踩过坑。

五、上手门槛：三种完全不同的使用姿势

这个项目的"部署"和一般软件项目不太一样，得按三种姿势区分：

姿势一：读者姿势（零成本） 直接访问 https://lihaorui.com/awesome-agent-native-services/ ，或者把 skill.md 的 raw URL 喂给你的智能体。不需要装任何东西，不需要网络代理之外的任何配置。仓库克隆后不装依赖也能直接读。

姿势二：贡献者姿势（本地构建） 需要 Python 3.12+、requirements-validation.txt 里的 jsonschema==4.26.0 与 llms-txt==0.0.6（仅用于校验，不参与运行），以及 Jekyll 构建环境（docs/Gemfile）。改动 README.md / skill.md / llms.txt / services/** 之后，必须依次跑：

python3 scripts/build-machine-catalog.py
bash scripts/build-github-pages.sh

CI 会用 git status --porcelain 检查生成物是否是最新的，没提交生成物就直接红——这条约束让目录的机器契约永远不会和内容脱节。

姿势三：使用者姿势（装进智能体） 需要支持 Claude Code 插件或 AgentSkills 标准的客户端（Claude Code、Cursor、Codex、Windsurf 等）。装完 skill 之后，智能体就能自己按任务去查目录、按优先级选接入方式。

值得注意的是：仓库本身没有 Dockerfile、没有 docker-compose、也没有 pyproject.toml。因为它压根不是一个需要跑起来的服务——它是一个内容仓库 + 一个静态站 + 一份机器契约。这直接决定了它的部署评估结论。

六、争议与局限：不回避的四个问题

第一，标准严到可能漏掉真正有用的东西。 五条硬性准入（尤其是"至少有一个人类场景无对应物的原语"）是一把双刃剑。它成功过滤掉了大量"给 SaaF 加了个 /ai 接口"式的伪原生服务，但也可能把一些过渡阶段最有性价比的 agent-adapted 服务排除在外——对一个刚起步的团队来说，先用 Resend 而不是 AgentMail，往往是更务实的选择。目录本身用 "Excluded / Boundary Cases" 一节显式列出了被排除项，这点值得肯定。

第二，收录的是服务，承保的却是可用性。 目录能告诉你 mem0 存在、怎么装、官方 MCP 在哪，但当 mem0 的 API 改版或停止免费额度时，这个仓库不会替你承担后果。它只承诺"在你看到这条信息的 45 天内，我复核过链接还活着"。

第三，条目质量依赖社区，且不可完全自动验证。 仓库目前有 38 位贡献者，最近提交里能看到外部贡献者的名字（sibi-narendran、rezearcher、Lakshman Turlapati、0x4C33 等），这对多样性是好事，但也意味着不同条目的写作深度、证据密度不可能完全一致。CI 能查链接存活，查不了"这个服务到底是不是真的 agent-native"——后者仍靠人工评审。

第四，它终究是目录，不是基础设施。 如果你的团队照着它选型，得到的仍然是一堆需要你自己去注册、去鉴权、去付费、去写集成代码的服务。目录降低了搜索成本，但集成成本、供应商锁定风险、账单风险，一点没少。README 自己也写了 "Each service is either infrastructure an AI agent consumes directly or a narrowly qualified, purpose-built surface"，并把"给人类搭智能体的通用平台"明确划到边界外。

第五，作者利益相关。 .github/FUNDING.yml 与 README 底部的 Stripe 赞助分级（☕/🚀/🏗️）说明维护成本真实存在；同时作者本人运营 lihaorui.com 这个站点，目录与站点同源。这不构成"内容不可信"的证据，但读者应当知道：目录是一个人的策展判断 + 社区的补充，而不是某个中立机构的评测结果。

七、行业意义：一条正在成型的技术分层

抛开具体项目，这个仓库折射出的趋势比它本身更有意思：智能体基础设施正在分化出自己的一层，而且这一层已经厚到值得被系统化整理。

回想 2024 年前后，Agent 生态的讨论基本围绕"框架"展开——LangChain、AutoGen、CrewAI 谁更好用。到 2026 年，讨论重心明显下沉了一层：不再问"用什么编排框架"，而是问"邮件怎么发、状态怎么存、代码在哪跑、钱怎么付、谁来审批"。编排框架在收敛，运行时原语在分化。这个目录收录的 258 个服务，就是这种分化的实证。

三个更细的观察：

1. "智能体身份"正在成为一等基础设施。 通信类 16 条、支付类 19 条、智能体社交 16 条，这些条目的共同前提是"智能体需要有自己独立于人类的邮箱、钱包和公开身份"。谁能提供带委派语义、审计轨迹、预算控制的智能体身份，谁就掌握了下一层入口。

2. MCP 已经把"集成"从工程问题变成了选型问题。 目录里每个条目都标注了 MCP 支持状态和官方 Server 地址。对 MCP 客户端来说，选一个服务等于挑一个 Server，目录实际上在做"Server 生态的可用性索引"——这在 MCP 协议快速演进的阶段是极高的实用价值。

3. 对中文团队的可借鉴性。 这个仓库展示了一种"内容即接口"的思路：把人工维护的目录，做成 schema 约束、可校验、可被 CI 保证新鲜度的机器契约。相比之下，中文开源项目里大量"精选清单"还停留在纯 Markdown 阶段——没有 schema、没有生成物校验、没有保鲜窗口。光是那 45 天保鲜窗口的自动巡检，就足以让大多数同类项目拉开一个身位。

八、总结

Awesome Agent-Native Services 不是又一个 awesome-list。 它更像一份"智能体基础设施的选型许可证"，把三件事同时做到了：定义了一套可争议但可执行的准入标准（agent-native 的五条硬指标 + 三类标签）；为每个条目提供可验证的最小接入路径（最快验证命令、Agent Skill、MCP Server、官方文档）；用 CI 把"内容腐烂"这个所有清单类项目的通病系统性地压制住。

它当然不能替代你自己的技术选型——目录里的 258 个服务，你需要按自己的信任边界、账期、区域合规和锁定风险再筛一遍。但它把筛选的第一轮做得极其扎实：省掉了周末开十几个标签页的那部分。

对做开源情报的团队来说，这个仓库本身也是高价值样本：一份内容型项目如何通过"schema + 生成脚本 + CI 保鲜 + 机器契约"把静态内容升级成可被智能体消费的活资产。 这套模式可以直接迁移到任何"精选清单"类项目上。

---

项目地址：https://github.com/haoruilee/awesome-agent-native-services ｜ 站点：https://lihaorui.com/awesome-agent-native-services/ ｜ 许可：CC0-1.0 ｜ 数据采集时间：2026-10-24