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 封装：

[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	高频固定流程