跳到主要内容

专用工具与 Skill 的形态谱系

能力形态谱系的两端是什么？​

  • 谱系: 同一件事（如“部署应用”）可以做成一个 deploy_app 专用工具，可以拆成构建、打包、部署三个更细的工具，也可以不做工具、只写一份 Skill 文档让 Agent 用 bash 逐步执行;
  • 专用工具: 结构化的函数调用，确定性高、可测试、参数受 schema 约束；代价是每个工具的定义要占去数百个 token;
  • Skill: 用自然语言编写的文档描述操作流程，Agent 通过终端或代码解释器执行；只需少量通用工具就能覆盖大量场景，目录里只占几十个 token，正文用到时才读;

Skill 文档实际长什么样？​

1. 运行 npm run build 构建项目
2. 运行 docker build -t app:latest . 打包镜像
3. 运行 kubectl apply -f deploy.yaml 部署到集群
  • 执行: Agent 通过 bash 工具逐步执行这些指令，无需为每个步骤创建专用工具;
  • 对照: 同一个“部署应用”目标，专用工具路线则对应一个或多个带 schema 的函数调用;

为什么说形态决策与披露决策是两件事？​

  • 形态: 决定每条能力常驻多少 token、参数怎么传、谁能改;
  • 披露: 决定有多少条能力同时摆在模型面前，规模问题见 层次化组织与按需加载;
  • 四种组合都真实存在: 挂着几百个专用工具的 MCP 后端可以只暴露一份索引按需加载，也可以把全部 schema 一次性注入；二十来个 skill 的目录可以全量常驻上下文，成百上千个 skill 同样需要分层检索;
  • 混淆来源: skill 目录条目比工具 schema 便宜一个数量级，把“全量常驻”的可行边界推远了不少——但那只是让披露这一侧更宽松，并没有替你做出披露策略的选择;

Skill 对人类编写者有什么优势？​

  • 门槛: 无论是否会编程，人们都可以编写和修改 Skill，也可以在 AI 生成的 Skill 基础上继续修改;
  • 容错: Skill 对格式和语法没有严格要求，修改往往是局部的，少量错误不会导致整个 Agent 无法运行;
  • 对照: 模型原生工具的 schema 若引号、花括号不匹配或缺失必要字段，会导致模型报错、整个 Agent 无法运行;