Agent Skill Protocol — 把能力像协议一样复用

是什么

“技能 protocol”可以理解成“把一套重复流程先写成一个可执行合同”。

日常类比：你和朋友合伙开店，每次都先把收钱、出库、打包写成同一份 SOP。 有了 SOP，新员工只要按步骤走就能稳定出单；AI Agent 也一样， 把重复任务抽成可复用技能后，模型不用每次重新发明。

这篇论文提到的核心不是“让模型会更多东西”，而是把能力外置成协议化模块。 它更像把“prompt 模板”升级为“技能系统”——有输入、边界、输出和调用契约。

为什么重要

不理解技能 protocol 会卡住的场景有三类：

• 你只看到“做一件事的描述”，但工程系统需要知道“谁可以调用、什么时候失败、如何回滚”；
• 项目规模上来后，每次改一个技能都要改好多文档和脚本；
• 同一个能力在多个模型、不同任务里重复出现，调参成本无限放大。

通过协议化，agent 行为从“自由发挥”变成“有界自治”：

• 研发更可控，出错能定位；
• 能力更容易迁移，换模型只需兼容协议；
• 团队协作时，不再靠口头约定，而是靠统一的能力契约。

核心要点

1. 能力最小单元化：把复杂任务拆成小技能，而不是每个任务都写 10 页说明。类比：把一套完整食谱拆成“备菜/炒菜/摆盘”。

• 目的：复用粒度更细，失败回滚更明确。
• 做法：每个技能约定输入字段、输出格式、可见副作用。

2. 元数据 + 上下文分离：技能本体负责操作，元数据负责说明该在什么情况下调用。类比：菜谱正文告诉配料，封面说明菜系口味和过敏原。

• 目的：同一操作在不同场景更容易被正确选中。
• 做法：把触发条件、置信度、前置依赖写成机器可读字段。

3. 可组合性优先：单个技能不追求“万能”，而是通过协议拼装完成复杂目标。类比：乐高积木先拼小块，再拼大模型。

• 目的：减少重复实现，让 pipeline 更易维护。
• 做法：输出必须可以被下游技能消费，输入输出约束可验证。

实践案例

案例 1：把“部署文档”改造成可复用技能

{
  "name": "gen-doc",
  "inputs": {
    "repo": "string",
    "target": "string"
  },
  "outputs": {
    "doc_path": "string",
    "preview_url": "string"
  },
  "safety": ["no_secret_leak"],
  "rollback": "delete_generated_doc"
}

• 先约定字段类型和失败回滚，再让模型只填充 repo 和 target。
• 下游只读取 doc_path 和 preview_url，不会猜“文档放哪了”。

案例 2：把“依赖修复”拆成检查+执行

def plan_fix(dep):
    if dep == "outdated":
        return ["scan", "prune", "pin"]
    return ["noop"]

• 传统方式模型会直接写 fix 脚本，成功率高但不可控。
• protocol 方式先产出计划，再逐步执行，每步都可记录日志。

案例 3：多模型协作调用同一技能

Model A -> 技能：抽取关键词
Model B -> 技能：查找文档
Model C -> 技能：汇总回答

• 通过统一输入输出，模型之间不再“说方言”。
• 只要接口不变，A/B/C 的模型可以随时替换。

踩过的坑

1. 技能边界写模糊：输入字段没写完整导致模型补字段、误调用其他工具。
2. 输出 schema 不验收：看似成功，但下游拿不到可用结构化字段。
3. 把所有逻辑塞进一个技能：可维护性最差，一旦失败很难定位。
4. 不区分“可执行动作”和“建议动作”：模型被允许做了超权操作。

适用 vs 不适用场景

适用：

• 任务重复度高、步骤清晰的后台工程协作。
• 需要多人协同、模型可替换的 Agent 系统。
• 需要审计、回溯、可复现实验的工作流。

不适用：

• 需求高度发散、创造性探索为主的场景。
• 小脚本场景，纯手工运行效率更高的工作。
• 临时任务，建协议的成本高于收益。

历史小故事（可跳过）

• 2018-2019：Prompt 工程依赖文本文档，迁移成本高。
• 2021-2022：工具调用变普及，开始有统一 schema 的雏形。
• 2024-2025：复杂 agent 链路爆发，能力重用问题被放大。
• 2026：论文将“技能协议化”与可组合执行更明确化。

这条线说明：行业先做了“会调工具”，后面才补齐“会自我限制和复用”。

学到什么

1. 能力协议的本质是“能力边界可验证”。
2. 可复用不等于无脑重用，关键是输入输出和副作用定义清楚。
3. 组合系统比单一大技能更强，因为可以按能力替换、按任务切分。
4. 工程里最重要的不是是否“聪明”，而是失败时可观测和可回滚。

延伸阅读

• 官方文档：Model Context Protocol（MCP）（能力接口标准化思路）
• 相关论文：SoK: Agentic Skills — Beyond Tool Use in LLM Agents（技能框架分类）
• 阅读材料：Generative Skill Composition for LLM Agents（技能组合角度）
• 实践案例：OpenHands 文档（自动化工程 agent 示例）
• 相关讨论：Awesome Agent Skills

关联

• agentic-ai —— 讨论能力层与决策层关系，理解为什么需要协议
• prompt-engineering —— 技能化思路的前身，解决可维护性问题
• llm-workflow —— 多步骤工作流和 skill orchestration 的承接层
• tool-calling —— 技能执行常依赖于稳定的工具定义
• multi-agent —— 协作多模型时协议化更关键
• safety —— 安全边界和权限控制需要协议字段支持

反向链接

（暂无反向链接）