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

Agent 的 Skills技能/工具体系里的推理链一般可以从两个层面拆开看一个是运行时——Agent 拿到任务后怎么靠推理把调哪个 skill / 传什么参数 / 拿到结果后怎么继续串成一条链另一个是设计层——Skill 体系本身怎么组织才能让这条链跑得通、不断链。下面把这两层串起来讲。一、运行时视角Skill 调用的推理链长什么样主流范式是ReActReasoning Acting的变体一条链通常长这样Observation观察用户输入 / 上一步执行结果 ↓ ThoughtLLM 推理我要做什么、缺什么、该调哪个 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 至少要暴露nameweather_querydescription「查询指定城市指定日期的天气返回温度、降水、风力」parameters schemaJSON Schema 风格city: string, requireddate: string, enum[今天,明天,后天]return 描述「温度区间、天气状况、降水概率」描述写得好不好直接决定推理链第一步就选不选得对。这是 80% 的 bad case 来源。2. Skill 的注册与路由当 skill 多了几十上百个不能全塞进 prompt否则超 tokenLLM 选花眼choice overload常用策略全量注入skill 少20时直接全列Retrieval-based用用户 query 召回 Top-K 个相关 skillRAG 思路分层路由先粗分类“天气类”/“POI 类”/“计算类”再精选3. 参数填充的可靠性LLM 生成参数这一步最容易翻车漏必填项、格式错、枚举值瞎编。加固方式schema 校验 自动纠错缺 city 就反问枚举不对就取最近匹配few-shot 示例嵌在 skill description 旁边constrained decoding用 grammar 强制 JSON 符合 schema4. 执行结果的回喂形态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-ExecuteLLM 先出完整 plan子目标序列再逐个执行复杂多跳、可分解任务Self-Correction执行失败 → 反思 → 改参数重调工具不稳定、参数模糊Compose技能组合把多个 skill 预编排成一个新 skill高频固定流程复杂 Agent比如 AutoGPT、Devin 那种其实是Plan-and-Execute ReAct Self-Correction混着用高层先拆 plan每步里 ReAct 循环出错就反思重规划。四、推理链常见的断点做 Skill 体系时链容易在这些地方断选错 skilldescription 太笼统 / skill 太多没检索参数瞎填LLM 臆造枚举值、把后天写成2026-07-03而 API 不认Observation 太 raw扔一大坨 JSON 回去LLM 下一轮 Thought 开始胡说无限循环A 调完调 BB 又想调 A没 termination 条件plan 脱离实际先 plan 得太细执行到第三步发现某个 skill 返回根本不支持预期用法对应的解法大体就是写好 description schema 校验 Observation 自然语言化 max_steps 兜底 失败反思。