Agent的Skills体系里的“推理链“

Agent 的 Skills（技能/工具）体系里的"推理链"，一般可以从两个层面拆开看：一个是运行时 ------Agent 拿到任务后怎么靠推理把"调哪个 skill / 传什么参数 / 拿到结果后怎么继续"串成一条链；另一个是设计层------Skill 体系本身怎么组织，才能让这条链跑得通、不断链。下面把这两层串起来讲。

一、运行时视角：Skill 调用的推理链长什么样

主流范式是 ReAct（Reasoning + Acting）的变体，一条链通常长这样：

复制代码

Observation（观察用户输入 / 上一步执行结果）
    ↓
Thought（LLM 推理：我要做什么、缺什么、该调哪个 skill）
    ↓
Action（选定 skill + 生成参数）
    ↓
Execution（执行 skill，拿到返回）
    ↓
Observation（把返回喂回上下文）
    ↓ （循环，直到 Thought 判断可以给出 Final Answer）
Final Answer

关键点 ：推理链不是 LLM 一次性生成的，而是每一步都依赖上一步的 Observation 重新推理。Skill 在这里扮演的是"把外部能力封装成 LLM 能理解的接口"，让 LLM 的推理能从"纯语言"延伸到"操作世界"。

举个具体例子，用户问"杭州明天适合爬山吗？"

Thought ：需要知道杭州明天的天气 → 调 weather_query(city=杭州, date=明天)
Obs：晴转多云，18-25℃
Thought ：还需要知道杭州周边适合爬的山 → 调 poi_search(city=杭州, category=山岳, sort=推荐)
Obs：灵隐、宝石山、玉皇山...
Thought ：结合天气（晴好、温度舒适）和难度，宝石山最合适 → Final Answer

二、设计层视角：Skill 体系怎么支撑这条链不断

光有 LLM 不够，推理链要稳，Skill 层得提供四样东西：

1. Skill 的"自描述"元数据

LLM 选 skill 靠的是描述 + schema，不是靠真去跑。所以每个 skill 至少要暴露：

name ：weather_query
description：「查询指定城市指定日期的天气，返回温度、降水、风力」
parameters schema （JSON Schema 风格）：
- city: string, required
- date: string, enum=[今天,明天,后天]
return 描述：「温度区间、天气状况、降水概率」

描述写得好不好，直接决定推理链第一步就选不选得对。这是 80% 的 bad case 来源。

2. Skill 的注册与路由

当 skill 多了（几十上百个），不能全塞进 prompt，否则：

超 token
LLM 选花眼（choice overload）

常用策略：

全量注入：skill 少（<20）时直接全列
Retrieval-based：用用户 query 召回 Top-K 个相关 skill（RAG 思路）
分层路由：先粗分类（"天气类"/"POI 类"/"计算类"），再精选

3. 参数填充的可靠性

LLM 生成参数这一步最容易翻车：漏必填项、格式错、枚举值瞎编。加固方式：

schema 校验 + 自动纠错（缺 city 就反问，枚举不对就取最近匹配）
few-shot 示例 嵌在 skill description 旁边
constrained decoding（用 grammar 强制 JSON 符合 schema）

4. 执行结果的"回喂"形态

skill 返回的原始数据（JSON/API response）不能直接丢给 LLM，要做一层Observation 封装：

json 复制代码

[weather_query(city=杭州, date=明天)]
→ 返回：{"temp": [18,25], "condition": "晴转多云", "rain_prob": 0.1}
→ 喂给 LLM 的 Obs：「杭州明天天气：晴转多云，18-25℃，降水概率 10%」

原始 JSON 留着给程序，LLM 看到的是自然语言摘要------这一步做得好不好，影响后续 Thought 质量。

三、推理链的几种演进形态

形态	特点	适用
ReAct 单步循环	走一步看一步，灵活但可能绕远	简单任务、工具少
Plan-and-Execute	LLM 先出完整 plan（子目标序列），再逐个执行	复杂多跳、可分解任务
Self-Correction	执行失败 → 反思 → 改参数重调	工具不稳定、参数模糊
Compose（技能组合）	把多个 skill 预编排成一个新 skill	高频固定流程

复杂 Agent（比如 AutoGPT、Devin 那种）其实是 Plan-and-Execute + ReAct + Self-Correction 混着用：高层先拆 plan，每步里 ReAct 循环，出错就反思重规划。

四、推理链常见的"断点"

做 Skill 体系时，链容易在这些地方断：

选错 skill：description 太笼统 / skill 太多没检索
参数瞎填：LLM 臆造枚举值、把"后天"写成"2026-07-03"而 API 不认
Observation 太 raw：扔一大坨 JSON 回去，LLM 下一轮 Thought 开始胡说
无限循环：A 调完调 B，B 又想调 A，没 termination 条件
plan 脱离实际：先 plan 得太细，执行到第三步发现某个 skill 返回根本不支持预期用法

对应的解法大体就是：写好 description + schema 校验 + Observation 自然语言化 + max_steps 兜底 + 失败反思。