Agent 如何扩展能力：Skill、MCP、ACP 与多代理
一个会读文件、改代码、跑测试的 Agent，已经具备最小工作能力。接下来遇到的问题通常更具体：团队流程怎么复用、外部服务怎么连接、不同界面怎么接入、复杂任务怎么分工。
这些问题不必塞进同一个机制。本篇按职责区分常见扩展方式，并说明它们适合在什么时候加入。
1. Skill：把重复出现的工作方法打包
Skill 通常用一个目录保存说明、脚本和参考资源，入口是 SKILL.md。Agent 可以先读取名称与描述，匹配任务后再加载详细指令，按需读取相关资源。这种渐进加载方式能减少无关内容进入上下文。Agent Skills 概览
例如一个「修复缺陷」技能，可以约定：
Skill 提供工作方法；执行能力来自它使用的工具。技能里写了「运行测试」，宿主仍然要提供测试工具，并执行权限校验。
加载方式取决于宿主实现：可以由用户显式选择，可以根据任务自动匹配，也可以让模型调用读取工具。/<name> 和 load_skill 都是可能的产品设计，不是所有 Agent 必须提供的统一接口。
还有两个容易忽略的细节：
- 名称和描述如果进入模型输入，也会占用 token；按需加载节省的是正文和附属资源的开销。
- 技能正文一旦进入消息历史，不会因为「任务结束」自动消失。清理、压缩和会话隔离需要宿主管理。
2. MCP：用统一协议连接工具和资源
MCP（Model Context Protocol）规定宿主如何与服务端交换能力和数据。以工具为例，客户端通过 tools/list 获取声明，通过 tools/call 调用工具；工具提供输入 Schema 和执行结果。MCP 工具规范
模型不直接维护 MCP 连接。宿主负责连接生命周期、认证、工具名称映射、超时和结果转换。远程结果可能包含文本之外的内容，也不能总是假设它能原样塞进一条文本消息。
Skill 与 MCP 可以配合：Skill 说明如何生成一份业务报告，MCP 提供查询业务数据的工具。两者都不会替代授权策略。
3. ACP：让客户端与 Agent 运行时对话
ACP（Agent Client Protocol）面向编辑器等客户端与 Agent 之间的通信。以 v1 传输规范为例，标准传输使用 stdio 交换 JSON-RPC 消息，也允许保持协议语义的自定义传输。ACP 传输规范
这幅图表达两种连接方向，不代表每个应用都必须同时使用两种协议。单机命令行程序可以直接调用本地函数；自建 Web 界面也可以通过自己的 HTTP、SSE 或 WebSocket 接口与后端通信。
SSE、WebSocket 是传输方式，ACP 是应用协议，不能把它们当成同一层的可替换名词。接入 ACP 需要实现它的消息语义，而不只是建立一条连接。
4. Hooks：在明确的时机插入逻辑
当多个工具都需要相同处理，例如记录耗时、裁剪输出或执行审批，就可以将公共逻辑提取成 Hooks。
下面的名称是设计示例，具体产品可能不同：
| 时机 | 示例名称 | 适合放入的逻辑 |
|---|---|---|
| 请求模型前 | before_model |
组装上下文、检查输入体积 |
| 模型返回后 | after_model |
记录用量、检查响应结构 |
| 工具执行前 | before_tool |
参数校验、权限判断、审批 |
| 工具执行后 | after_tool |
脱敏、截断、记录结果 |
| 执行异常时 | on_error |
分类错误、决定停止或重试 |
必须执行的权限检查不能因为某个 Hook 报错或未注册就被绕过。Hook 的执行顺序、失败行为和参数修改规则，都属于运行时契约。
5. 子代理与多代理：为分工付出协调成本
子代理是被委派任务的独立执行单元，通常有自己的上下文和循环。主 Agent 给它一个明确目标，收回摘要、证据位置和产物。
例如，修复代码时可以让一个只读子代理调查调用方。主 Agent 接收「有哪些调用点、是否依赖旧行为」的结论，再决定修改范围。
| 角色 | 典型权限 | 适合的输出 |
|---|---|---|
| 探索 | 读取与搜索 | 文件位置、事实、未确认问题 |
| 实现 | 在约定范围内修改 | 补丁、测试结果 |
| 审查 | 读取变更与必要验证 | 可复现的问题与影响 |
上下文是否继承、工具与 Skill 是否可用、能否继续派生子代理，都应由宿主配置。它们不是固定的「只能这样」规则。初期限制派生深度，可以减少成本和协调难度。
多代理强调多个执行单元的协作，可以采用协调者，也可以采用其他组织方式。子代理是其中一种实现手段。增加角色不会自动提高质量：共享文件可能冲突，摘要可能遗漏证据，额外调用也会增加延迟和成本。
适合并行的任务通常目标清晰、依赖少、输出可核验。对于只有一个函数的修复，单 Agent 顺序执行已经足够。
6. Context、KV Cache、Memory 分别优化什么
这三个概念经常被混用，但对应不同层次：
| 概念 | 保存的内容 | 主要用途 |
|---|---|---|
| Context | 当前模型请求可用的指令、消息、工具和其他输入 | 支持这一轮决策 |
| KV Cache | 注意力计算中的键和值等中间状态 | 复用计算，降低重复处理开销 |
| Memory | 应用保存并可检索的事实、偏好和任务状态 | 跨步骤、跨会话使用信息 |
应用检索 Memory 后，把相关结果放进 Context；推理服务在处理 Context 时，可能复用缓存。缓存不会替应用检索历史经验，也不能保证模型遵循某条长期偏好。
前缀缓存允许服务复用相同输入前缀的计算。稳定的指令和工具定义有利于复用，但实际命中、保存时间和计费取决于服务及模型。不能把「命中缓存」直接等同于「这部分输入免费」。OpenAI Prompt Caching 文档
7. 根据实际缺口选择扩展
| 当前问题 | 优先考虑 |
|---|---|
| 同样的流程反复解释 | Skill |
| 需要接入外部工具服务 | MCP |
| 需要与支持协议的编辑器互通 | ACP |
| 执行前后有重复的公共逻辑 | Hooks |
| 多个独立任务需要分工 | 子代理或多代理 |
| 长任务重复输入开销高 | 先整理上下文，再评估缓存 |
这些扩展围绕核心循环工作。下一篇先把循环、执行器和界面的接口划清楚，再进入实际代码。