这五个词,就是AIAgent的骨架

同样一句指令，扔给两个 agent，结果常常天差地别。一个像换了个物种，自己拆任务、自己找工具、自己检查、自己收尾；另一个蠢到你怀疑人生，连个文件都能改错。多数人的第一反应是模型不行，其实差别往往不在模型，而在它外面套了什么。

模型只是发动机。真正决定一个 agent 好不好用的，是围在它外面的那几个零件。

这篇文章给我自己理一遍，也分享给你：五个词、三层结构、一张能看懂 agent 内部骨架的地图。框架来自 GitHub Think Series 的一期分享，我把它拆开重讲了一遍。读完你会发现，今天所有跑在前面的 agent，在底层长得其实很像。

先看骨架：五个词的三层地图

这五个词不是并列的五个词条，而是一张三层地图。

层	术语	它管什么
内部	agents.md、agent skill	agent 自己怎么做事
对外	MCP、A2A	agent 怎么连工具、怎么连别的 agent
规模	subagent	一个 agent 不够时，怎么放大

前两层管的是“一个 agent 怎么活”，第三层管的是“一个 agent 干不完时怎么办”。下面逐层拆。

一、agents.md：写给 agent 看的项目说明书

这是内部层的第一个，也是最基础的一个。它要解决的问题很具体：agent 来到一个项目，怎么知道这里该怎么干活？

答案就是把规矩写成一个文件，放在项目根目录，名字叫 agents.md。这个名字里的 .md 就是 markdown，所以它本质上就是一个纯文本文件，没有任何神秘格式。

agent 每次在这个项目里开始干活，都会先去把它读一遍。

文件里写什么？都是项目里那些“新人第一天就该知道”的事：

•跑测试要用什么命令•这个代码库用什么编码规范•PR 标题该怎么格式化•需要用什么初始化命令

你可以把它理解成一份 README，但它是专门写给 agent 看的 README。人看的 README 讲这是个什么项目，agents.md 讲的是在这个项目里活该怎么干。

关键在于，agent 不只是读，它会在上下文相关的时候执行里面的命令。文件里写着提交前先跑 pnpm test，那它提交前就会老老实实先跑一遍这条命令。规矩被写下来，它就会照做。

agents.md 还能嵌套。一个项目里可以有好几份，根目录一份，各个子项目各自一份，带各自的规则。那冲突了怎么办？机制很简单：

离当前工作目录更近的文件会覆盖前面的，因为它出现得更晚。

离得越近，优先级越高。这条规则让 monorepo 里的每个子项目可以有自己的脾气，又不必推翻全局约定。

它从哪来？agents.md 由 OpenAI 提出，后来捐给了 Linux 基金会下面的 agentic AI 基金会。还有一个必须写出来的细节：有些 agent 用的是别的文件名，Claude 用的是 CLAUDE.md。名字不一样，思路基本一样。

二、agent skill：让 agent 按需取用的技能包

agent skill（可以理解成给 agent 用的技能包）解决的是另一类问题。有些知识 agent 只是偶尔需要，而且不是项目专属的。

打个比方。agent 得知道怎么搭一份 PowerPoint。可如果每次启动都把这套上下文加载进来，纯粹是白白占满上下文窗口，尤其当眼前的任务跟幻灯片毫无关系的时候。

上下文窗口是最贵的资源，不该为“可能用得上”的知识付费。

agent skill 的做法很克制。它本身是一个文件夹，文件夹里有 SKILL.md（也是 markdown），还有这个任务需要的脚本和资源。SKILL.md 里放的是元数据，其中包含一段描述，用来告诉 agent：当用户想做某件事的时候调用我。这件事，可以就是用户想做一份 PowerPoint。

逻辑就一句话：用户的请求和这段描述匹配，agent 就把这个 skill 拉进来；不匹配，它就安静待在一边，一点上下文都不占。

agent skill 也是一个开放标准，被多个 agent 平台支持。

这里必须把和 agents.md 的区别写清楚，这是最容易混的地方：

•agents.md 说的是这个具体项目怎么运作•agent skill 说的是某一类具体任务怎么做

一个针对项目，一个针对任务类型。前者回答“这里有什么规矩”，后者回答“这类活我该怎么干”。

三、MCP：agent 怎么跟工具和数据说话

从这里开始，进入外层。前面两个管的是 agent 内部怎么想，接下来管的是它怎么伸手到盒子外面去。

agent 需要连各种各样的外部东西：API、数据库、开发工具、SaaS 平台，你能想到的都有。难点在于，每一个外部目标都有自己的接口。没有统一标准的话，每接一个新东西就要写一个专门的连接器，接十个就是十套，接一百个就是一团乱麻。

MCP（模型上下文协议，Model Context Protocol）就是来收拾这个乱局的。它是一个开放协议，用来把 AI 应用连接到工具、数据源和工作流。

它带着一个东西，叫 MCP server。MCP server 的作用是把一个工具或数据源包装成标准接口，于是任何能说 MCP 的 agent，就都能跟它对话。

MCP 一句话定位：解决 agent 怎么跟工具和数据说话。

举个具体例子。agent 想从 Notion 拉数据，或者要接一个 Stripe 的支付链接。agent 不需要懂 Notion 或 Stripe 各自的 API 怎么调，它只用 MCP 跟 server 说话，底层那些 API 由 server 去处理。对 agent 来说，外部世界从一堆各说各话的接口，变成了都说同一种话的插口。

来历也值得记一笔：MCP 起源于 Anthropic，现在归到 AAIF 管理，也是在 Linux 基金会下面，行业支持面很广。

四、A2A：agent 怎么跟另一个 agent 说话

MCP 解决了 agent 跟外部工具的沟通，但它没解决另一件事：agent 跟 agent 之间怎么说话。

A2A（agent 到 agent，Agent to Agent）就是干这个的。场景要写具体一点。假设有一个采购 agent，负责厂商合同；还有一个财务 agent，负责审批支出。采购 agent 谈完一份合同，需要把它交给财务 agent 去审批。

如果没有 A2A，这两个 agent 要么得写一套定制集成，要么根本配合不起来。每多一种协作，就多一套一次性对接。

有了 A2A，做法很干净：每个 agent 会发布一张 agent card。这张卡本质上就是一段描述，说清楚两件事，这个 agent 是干什么的，以及怎么跟它对话。

别的 agent 读到这张卡，就知道该怎么把活派过去。

回到刚才的例子。采购 agent 找到财务 agent 的 agent card，读完，然后把合同交出去。不用提前写死集成，两个此前不认识的 agent 也能配上。

A2A 标准来自 Google，现在也是 Linux 基金会下面的开放标准。

一句话对照：MCP 是 agent 跟工具和数据说话，A2A 是 agent 跟 agent 说话。 这两个一定要分清，同样是向外的接口，一个连工具，一个连同类。

五、subagent：一个上下文窗口装不下的活，交给子代理

到这里，agent 已经知道自己该干什么，也知道怎么向盒子外面伸手了。但还有一种情况：一个 agent 不够用。

主要有两种场景。第一种，任务太大，一个上下文窗口装不下。比如 agent 要审查一个有上万文件的代码库，把所有文件都读进来，上下文直接爆掉。第二种，任务天然可以并行。比如你要对 20 个函数各跑一次检查，每次检查互相独立。一个一个跑很慢，一起跑就快 20 倍。

subagent（子代理）就是应对这两种场景的。定义很简单：subagent 是主 agent 派出去做某一块具体工作的子 agent 或子代理。

机制也很清楚：每个子代理跑在自己全新的上下文窗口里，干完自己的活，返回一个结果，然后结束。

子代理的上下文是干净的，主 agent 的上下文也是干净的。

举个例子。主 agent 派一个子代理出去，让它读 500 个文件，然后只交回一份摘要。那 500 个文件的原文从头到尾没有污染主 agent 的上下文窗口，主 agent 只拿到它真正需要的那点结论。

也可以同时开很多个子代理并行干活。比如 20 个子代理同时处理 20 个互相独立的检查，时间一下就压下来。

这里要特别点明它和另外四个的区别。subagent 是现代 agent 系统里的常见模式，但它背后没有一份正式的标准文档。不过这个概念的形态，几乎在所有地方都长得一样。最基本的样子是这样：

•一个大的父 agent•派出一个或多个子 agent•子 agent 拿到同样的上下文，干完活返回结果•父 agent 带着自己完整的上下文继续往下走

形态高度一致，却没有人给它写统一文档。这本身就说明，它是从工程实践里长出来的，而不是被谁规定出来的。

真正的信号：零件正在被标准化

把三层合起来看：

•agents.md 和 agent skill 活在 agent 内部，决定它的行为方式。•MCP 和 A2A 负责向外伸手，一个连工具和数据，一个连别的 agent。•subagent 负责处理装不进一个上下文窗口的工作。

这三层，就是今天一个前沿 AI agent 在底层真实的样子。看懂了这五个词，再看任何 agent 产品，你关注的不再是它吹的功能列表，而是这几个零件是怎么配的。

但更值得说的是另一层观察。

这五样东西，正在从各家私有的玩法，收敛成公共标准。agents.md 从 OpenAI 交出去，MCP 从 Anthropic 交出去，A2A 从 Google 交出去。而且其中三个，agents.md、MCP、A2A，都被交到了同一个地方：Linux 基金会。

这不是巧合。三家最有动机互相竞争的公司，各自把手里最关键的 agent 基础设施标准，放进了同一个中立基金会。

真正的信号，从来不是某个 agent 有多强，而是它的零件正在被标准化。而标准化发生的地方，才会长成基础设施。

一个东西能被叫作基础设施，前提是大家都用它、谁也离不开它，而且它不属于任何一家。当竞争者们开始把自己的零件交到同一个地方时，它们其实已经承认，这块地不是用来打差异化的，是用来盖路的。

那么问题留给你：当一个 agent 的骨架被完全标准化之后，剩下的差异化，会跑到哪里去？