从小龙虾的爆火回看Skills：把“会做事”拆成可复用模块的技术抓手｜从 Options 到 Tool Calling

最近刷到一堆 agent 框架都在讲 Skills / Tools / Plugins，我顺手点开看了下，发现大家讲的其实是同一件事：把“能力”做成可调用的模块。

学术上 1999 年的强化学习就把它叫“temporally extended actions/Options”（技能的一个祖先），LLM 这波是在 2022–2023 年被 ReAct、Toolformer、函数/工具调用这条线重新产品化了（见文末入口）。

Skills当前显然是炙手可热的研究对象， 是 agent 从“会聊”变成“能交付”的分水岭，它把不确定的生成，改造成可验证的执行。

• 它是什么：Skills 就是“可被选择、可被参数化、可被观测”的能力单元。
• 发展路线：学术窗口大致 1999（Options 框架），LLM 工程化窗口大致 2022–2024（ReAct/Toolformer/Tool Calling 文档持续迭代）。
• 它解决什么问题：让复杂任务可拆解、可复现、可控成本，尤其是把“查/算/写/改/发起动作”这类确定性操作从模型嘴里搬到系统里。
• 它的特点：模块化、可组合、可评估、可治理（权限/审计/配额）。

Skills 解决的是“把自然语言意图变成可执行动作”的落地链路——复现路径更短（同一套 Skill 接口），成本更可算（每次调用可计费/可限流），上手更像搭积木（组合而不是重训）。

特点/卖点清单

• 可组合：一个复杂任务=多个技能串起来，学术上对应 Options 的“策略+终止条件”，工程上对应 planner/router 生成调用序列（Options 论文入口见文末）。
• 可验证：技能返回结构化结果，能做断言、重试、回滚；函数/工具调用强调用 JSON Schema 约束输入输出（OpenAI Function Calling 文档见文末）。
• 可观测：每次技能调用都能记日志、打点、做审计；ReAct 的“Reason/Act/Obs”格式本身就是可追踪轨迹（ReAct 论文见文末）。
• 可自举数据：工具调用轨迹可以变成训练/微调数据，Toolformer 就是在讲“模型学会何时调用什么工具”这件事（Toolformer 论文见文末）。
• 可治理：技能天然是权限边界，能做 allowlist、参数白名单、租户隔离，比“让模型自己上网乱逛”更像线上系统。

技术拆解

第一块：技能的“学术原型”是什么？

在强化学习里，技能常被形式化成 Options：你可以把它理解成一个小型策略（policy），加一个“什么时候能启动”(initiation set) 和 “什么时候结束”(termination) 的包装。1999 那篇论文的贡献是把“宏动作/技能”放进更通用的 SMDP 框架里，让分层决策有数学定义（Sutton/Precup/Singh 1999，见文末）。

这条线的直觉很产品：把长任务拆成可复用的子能力，复用带来更快学习/更稳执行。

第二块：LLM 时代的技能长什么样？

LLM 里 Skills 更像“带 schema 的 API”。模型负责选哪个技能、填什么参数；系统负责执行并回结果。Function/Tool Calling 把这件事标准化成“模型输出一个函数名+JSON 参数”，并强调可以用 JSON Schema 严格约束参数形状（OpenAI 文档见文末）。

这里的关键不是“能不能调用”，而是“参数能不能被系统无歧义解析”。

第三块：编排（Planner/Router）怎么把技能串起来？

一种思路是 ReAct：让模型在“思考/行动/观察”之间交替，行动就是技能调用，观察就是技能返回（ReAct 论文见文末）。它的好处是轨迹天然可读，出了错也能定位在某一步。

另一种思路是 SDK 把循环封装掉，比如 Semantic Kernel 把函数调用循环和 planner 打包，开发者重点写技能描述和边界（Semantic Kernel 文档入口见文末）。

不管哪条路，本质都是：从“一次性回答”变成“多轮控制回路”。

第四块：技能库怎么长出来（演进路线）？

最早像“专家系统/脚本函数库”，后来变成“可发现的插件市场”，再到今天更像“企业内部能力中心”：每个技能都要有权限、配额、审计、版本、回滚。

Toolformer 这类工作还在推一件事：技能调用不只是规则路由，也可以用数据让模型学“何时该调用工具、调用哪个工具”（Toolformer 论文见文末）。这会让技能从“人为配置”走向“半自动增长”。

工程取舍 1：为什么 Skills 往往更快、更稳？

因为它把不确定的 token 生成，换成确定的系统调用。比如“算税后价”这种事，用模型算=高波动；用技能算=可复现、可测、可缓存。

代价是系统复杂度上升：你要维护技能的版本兼容、错误语义、超时重试，还要防模型乱填参数。速度和稳定性是用工程治理换来的。

工程取舍 2：技能粒度怎么定？

粒度太细：编排步数暴涨，token 成本上升、失败点变多；粒度太粗：复用差、权限难拆、可观测性变差。

一个实用的定法是按“可验证边界”切：能被单测断言的、能被审计的、能被授权的，就值得单独做成技能。

剩下的“写文案/总结/改写”留给模型或许会更划算。

它像谁、又不像谁

它像移动互联网的“能力开放平台”：登录、支付、地图都做成 SDK/接口，业务只管编排。

但它又不像传统 SDK：技能的“调用者”不是人写死的 if/else，而是模型在运行时做选择，所以你必须把不确定性前移到“接口设计+约束+观测”上。

也有点像机器人里的“技能树/行为树”，区别是 LLM 让编排更灵活，但也更需要护栏。

最短复现路径

下面是一个极简“技能注册 + 路由 + 执行”的 Python 例子，不依赖第三方库。你可以把它当作 Skills 的最小骨架：技能=函数；路由=根据意图选技能；返回=结构化 dict。

# python 3.10+
import json
from typing import Callable, Any

Skill = Callable[[dict], dict]

def skill_calc_vat(args: dict) -> dict:
    amount = float(args["amount"])
    rate = float(args.get("rate", 0.13))
    return {"ok": True, "vat": round(amount * rate, 2), "currency": args.get("currency", "CNY")}

def skill_lookup_user(args: dict) -> dict:
    user_id = str(args["user_id"])
    fake_db = {"42": {"name": "Ada", "tier": "pro"}}
    user = fake_db.get(user_id)
    return {"ok": bool(user), "user": user}

SKILLS: dict[str, Skill] = {
    "calc_vat": skill_calc_vat,
    "lookup_user": skill_lookup_user,
}

def route(intent: str) -> tuple[str, dict]:
    intent = intent.lower()
    if "vat" in intent or "增值税" in intent:
        return "calc_vat", {"amount": 1000, "rate": 0.13, "currency": "CNY"}
    if "user" in intent or "用户" in intent:
        return "lookup_user", {"user_id": "42"}
    return "lookup_user", {"user_id": "0"}

if __name__ == "__main__":
    tool, args = route("帮我算一下 1000 的增值税")
    result = SKILLS[tool](args)
    print(json.dumps({"tool": tool, "args": args, "result": result}, ensure_ascii=False, indent=2))

运行方式：

python skill_demo.py

坑位注意点

• 参数口径漂移：技能 schema 改了但 router 还按旧字段填，结果“看似成功其实错算”。
• 超时与重试：技能调用有网络/IO，必须定义超时、幂等键、重试策略，不然会重复扣费/重复下单。
• 权限穿透：模型能不能调用“删库/转账”类技能，必须靠 allowlist+审批，不靠提示词。
• 观测缺失：只看最终回答不够，必须记录每次技能调用的输入输出（脱敏后）、耗时、失败原因。
• 上下文膨胀：编排步数多会把轨迹塞满上下文，反过来影响路由质量，需要摘要/缓存/截断策略。
• 回答与结果不一致：技能算出来是 A，模型复述成 B，要么强制“以技能结果为准”，要么做一致性校验。

怎么评估 Skills？

• “成功率”要定义清楚，是任务完成（端到端）还是单次技能调用成功。两者差很多。
• “成本”不能只看 token，还要算外部调用次数、延迟、以及重试带来的放大。

或许大家可以把每条轨迹的 tool calls 抽出来，固定同一套断言，跑回放对比（同输入、同技能版本）。