你给手上的智能体装过一堆东西：连数据库的、连代码仓库的、读文档的，还有几个自己攒的小技能。装完那一周还挺新鲜，过了两周你发现问题来了——很多能力它压根没调用过，偶尔用错地方，你也说不清该怪谁。这种乱，问题常常不在能力本身，而在于你把两类完全不同的东西混在了一个抽屉里。更麻烦的是，这种乱不会自己暴露。它不报错，只会让你在某个下午突然意识到，装了半年的东西，真正用上的其实就那么两三个。
先说其中一类。官方把它拆成三个角色：Host是AI应用本身，负责协调一个或多个Client；Client是Host内部的组件，跟一个Server维持专用连接；Server才是向Client提供上下文和能力的那个程序。它要解决的是“连得上什么”的标准化问题——你的智能体怎么跟外部系统说话，不用每接一家就重写一遍。
这套协议分两层。数据层用JSON-RPC 2.0承载消息、能力发现、工具与资源；传输层只管连接建立、消息成帧和认证，两层是解耦的。官方给出的标准传输只有两种：本地进程走标准输入输出，远程服务走可流式传输的HTTP。这个设计的实际好处是，同一套对接逻辑，换传输方式不用重写业务部分。两层解耦带来的直接好处是：你换一种连接方式，比如从本地进程换成远程服务，对接的那部分代码不用动。这也是为什么一开始就按协议分层来设计，比堆一堆各写各的对接脚本要省力得多。
这里面还有一层容易被忽略的分工。协议把服务端能力分成三种原语，各自的控制方是不一样的：工具由模型决定什么时候调用，资源由应用决定什么时候拉取，提示模板由用户主动选用。理解这层区别，你就能解释为什么有些能力它老是自己去用、有些从来不碰——那不是它偷懒，是控制权本来就不在它手上。
再说另一类。一个技能就是一个目录，核心是里面的SKILL.md，文件开头必须有元数据，至少包含名称和描述。关键在启动那一刻：智能体只把所有已安装技能的名称和描述预载进系统提示，不会把内容全部读进来。这是第一层，它只需要够用来判断哪个技能在什么时候可能有用。
当任务和某个技能的描述对上了，它才把完整的SKILL.md读进上下文，这是第二层。如果这个技能还捆绑了别的文件，比如一份参考文档、一份填表说明，它会在真正需要的时候再按名字去读，这是第三层。三层是层层收窄的：先知道有这个东西，再知道大致怎么做，最后才去翻细节。官方把这套机制叫渐进披露，是技能能装很多个却不把上下文撑爆的根本原因。这套机制还有一个副作用值得注意：因为启动时只加载名称和描述，所以描述写得好不好，直接决定这个技能会不会被用到。描述写得含糊，它压根不会被想起来；写着写着把描述写成了长文，又失去了渐进披露的意义。
技能里还可以带代码。官方说明提到，技能不只是文档，还能包含供智能体自行决定要不要执行的脚本。有些操作交给传统代码去跑，比让模型一步步推理既便宜又稳。这一条把技能从单纯的说明书，变成了说明书加随身工具的组合，也解释了为什么有些看起来该靠推理完成的事，实际执行得又快又一致。
两者的分工可以一句话概括：前者解决能连到什么，后者解决遇到这类活该按什么流程做。一个是接口层的标准化，一个是知识层的封装。你要接一套外部系统，那是前者的活；你要让它在你自己的项目里按你们团队的规矩办事，那是后者的活。混着装、混着理解，就会出现你现在这种装了很多、用得很乱的局面。还有一类容易被混进来的是记忆类能力——那种把历史对话存起来、下次接着用的东西。它既不是外部系统连接，也不是流程说明，属于第三类。把它和前面两类分开，你对自己这套能力清单的理解会清楚很多。
技能还有一个变化值得留意：官方已经把它作为开放标准发布，方向是跨平台可移植。这个决定的影响比它看起来要大——技能是可版本管理、可搬家的文件夹，你投入在里面的整理成果不会因为换了工具就归零。对个人站点来说，这意味着一件事：现在花时间把流程沉淀成技能，比花时间追着每个工具的最新玩法跑，回报更稳。
给你一个简单的判据。如果一个能力需要跟外部某套系统通信、涉及凭证和协议，那它属于前者；如果一个能力本质上是“这类任务在我们这里应该这么做”的流程说明，那它属于后者。按这个判据过一遍你现有的清单，通常会得出一个不太舒服的结论：你缺的不是更多能力，而是把已有的两类分清楚，并且承认其中有一半根本没被用起来。还有一条更省事的判据：如果这个能力的核心内容是给谁用、什么时候用、做完长什么样，那它属于技能；如果核心内容是连哪个地址、用什么凭证、返回什么结构，那它属于协议。照着这条分，几乎不会分错。
装能力的顺序，应该是先把要做的事说清楚，再决定用什么方式把它接进来。反过来的结果就是你开头遇到的那种：工具列表很长，能真正落地的很少。清单长度从来不等于能力，能稳定复现的那几条才算数。
A5创业网 版权所有