Agent：规划、记忆与反馈

所属： 模型增强层。本页边界： 模型怎样在环境反馈下维护状态并选择多步工具行动，以及 Skill 如何将领域专业知识封装为可组合、可治理的能力单元。

#核心公式

a_t\sim\pi_\theta(a_t\mid b_t),\qquad b_{t+1}=f(b_t,a_t,o_{t+1})

#符号说明

符号	含义	单位/条件
$t$	Agent 与环境交互的步骤编号	非负整数
$b_t$	第 $t$ 步的工作状态或 belief state	结构化状态/上下文
$\pi_\theta$	参数为 $\theta$ 的行动策略	条件概率分布
$a_t$	第 $t$ 步选择的回答、检索、工具调用或停止动作	动作
$o_{t+1}$	执行动作后从环境得到的真实观察	观察
$f$	根据旧状态、动作和观察更新状态的函数	状态转移
$\tau$	完整交互轨迹	状态—动作—观察序列
$R(\tau),\ C(\tau)$	轨迹效用与 token/时间/工具成本	标量
$H,\ p$	后文中的必要步骤数与单步成功率	正整数、 $[0,1]$
$\mathcal S$	Skill 库	Skill 集合
$s$	单个 Skill 的规范定义	SKILL.md 或等价结构
$\mathcal C_{\mathrm{cat}}$	Skill 目录（元数据层）	名称与描述集合
$L_{\mathrm{skill}}$	Skill 渐进式加载层级	$\{1,2,3,4\}$

$b_t$ 是工程上的状态压缩，不必然是严格的贝叶斯信念分布。

#技术要点

Agent 将历史、记忆和工具结果压缩为 belief state。
Skill 是比工具更高层级的能力抽象：Function Calling 定义“接口”，Skill 封装“知识”。Skill 通过渐进式上下文加载按需提供领域能力，一个 Skill 可整合多个 Tool、脚本和参考文档。
Skill 的核心工程机制是渐进式披露：目录元数据（~50-100 token/技能）常驻系统提示，完整指令仅在触发时加载，资源文件按需读取。一个包含 20 个 Skill 的 Agent 在初始状态下只消耗 20 条描述的上下文。
多 Skill 编排是 Agent 规划的核心问题：将任务分解为子目标，通过 DAG 管道检索、编排和执行多个 Skill。AgentSkillOS 的节点级递归分类使 Skill 发现效率随生态系统规模增长。
Skill 的安全边界需要独立的治理层：OWASP Agentic Skills Top 10 系统化了恶意 Skill、供应链攻击、过度授权等风险。Skills Registry 提供发布前扫描、签名验证和沙箱隔离。
多 Agent 只有在任务可分解且错误可独立验证时才有价值。同模型分解（same-model decomposition）可能比不分解更差，模型多样性而非并行性驱动协作增益。

#原理与演进

#一个最小 Agent 循环

单步闭环为： $b_t$ → 策略 $\pi_\theta$ → $a_t$ → 环境 → $o_{t+1}$ → 状态更新 $f$ → $b_{t+1}$ 。

$b_t$ 是从对话、任务状态和记忆得到的工作状态； $a_t$ 可以是回答、工具调用、检索或停止； $o_{t+1}$ 是环境真实返回。
ReAct 把推理与行动交替进行，使新观察能修正后续步骤；没有观察闭环的多段自说自话不构成可靠验证。原研究
固定流程由人预先决定步骤，适合稳定任务；Agent 动态选下一步，适合分支多、信息不全的任务，代价是更难控制成本和错误传播。

#规划、记忆、反馈各负责什么

模块	作用	失效模式
规划	把目标拆成可执行子问题	分解错误，过多无用步骤
记忆	保留跨步事实、证据和已做动作	摘要丢失关键信息、过时状态
工具	读写外部环境	参数错误、越权、外部结果不可信
Skill	封装领域专业能力，按需加载	描述不精确导致误触发，版本不匹配
验证	用测试、规则或环境反馈判断结果	自评偏差、验证器覆盖不足

#Skill 的定位：从接口定义到知识封装

Function Calling 与 Skill 的本质差异：前者定义的是“接口”，后者传递的是“知识”。

Function Calling 的流程是：用户请求 → LLM 推理 → 生成函数调用 JSON → 开发者代码执行 → 返回结果。LLM 只负责“决定调用什么，生成参数”。Skill 的流程是：用户请求 → LLM 读取 Skill 说明 → LLM 决定调用哪些底层 Tool → 执行 → 返回结果。Skill 本身不是可执行代码，它是写给 LLM 看的自然语言指导，包含领域知识、操作流程、最佳实践和约束规则。

三者的层级关系为：MCP（平台治理层）> Skill（业务聚合层）> Function Calling（原子能力层） 。MCP 解决“能不能连”，Skill 解决“会不会做”，Function Calling 解决“怎么调”。

#1. Agent 的本质：闭环决策

单次语言模型调用给 $y\sim p_\theta(y\mid x)$ ；Agent 至少要有可观察环境、行动集合、内部状态更新与停止规则。若环境部分可观测， $b_t$ 是对下式所示历史的压缩；它未必是严格贝叶斯信念，实际常用会话上下文、结构化状态或外部记忆实现。

h_t=(o_1,a_1,\ldots,o_t)

可把目标写成有限预算下最大化期望效用如下，其中 $\tau$ 是轨迹、 $C$ 是 token/工具/时间成本。多做步骤只有在提高成功率超过成本和风险时才有意义。

\max_\pi\mathbb E_\pi[R(\tau)-\lambda C(\tau)]

#2. Skill 的架构：渐进式披露

#2.1 三层加载机制

Skill 的核心工程机制是渐进式披露（Progressive Disclosure） 。将领域知识注入系统提示的传统方式存在根本性浪费：参考材料在每个请求中都被支付，无论当前轮次是否需要它。一个记录了 20 个操作流程的 Agent，回答“现在几点”也要支付 20 个流程的 token 成本。

渐进式披露将这一成本分解为三个层级：

层级	加载内容	Token 成本	触发条件
Catalog（目录层）	每个 Skill 的名称和描述	~50-100 token/技能	常驻系统提示
Instructions（指令层）	`SKILL.md` 完整内容	~300-500 行	Skill 被激活时
Resources（资源层）	参考文档、脚本	按需	指令中显式引用时

Microsoft Agent Framework 将这一模式描述为四阶段：advertise skill names → load instructions → read resources → run scripts。

这一设计的工程意义是：一个包含 50 个 Skill 的系统，在初始状态下只消耗 50 行元数据的上下文；只有任务真正匹配到某个 Skill 时，才加载完整内容。未使用的 Skill 几乎不产生上下文成本。

#2.2 SKILL.md 规范

SKILL.md 是 Skill 的规范定义文件，使用 YAML frontmatter 定义 name 和 description（均为必填），正文部分是技能的全面描述，包括功能、使用说明、参考资料和示例。文件结构标准形态：

skill-name/
├── SKILL.md          # 主技能定义（必需）
├── reference.md      # 详细参考资料（可选）
├── resources/        # 模板、数据文件（可选）
└── scripts/          # 可执行脚本（可选）

技能描述应短到不能再短，同时清晰说明“什么时候用”。 一个典型的反例是将技能描述写成“处理任何与数据库相关的事情”——这会导致模型在每次触及数据库相关内容时都加载该技能，而非仅在真正需要执行迁移时加载。正确的描述应精确限定触发条件。

渐进式披露是技能设计的核心模式。 读取一个技能会消耗上下文，使模型更接近压缩阈值，并引入可能不适用于当前任务的指导。对于包含多个工作流的技能，根文档应是一个极简的路由器，指向支持性文档和脚本。

#2.3 Skill 与 MCP 的关系

Skill 和 MCP 不是竞争关系，而是不同抽象层级的组件。MCP 解决的是“能不能连”——AI 能不能访问外部工具和数据源，是能力层。Skill 解决的是“会不会做”——AI 知不知道怎么做某件事，是流程层。Skill 是“专业手册（经验包）”，MCP 是“USB-C 接口（标准化连接器）”。

二者可以组合使用：MCP Server 提供数据库连接或 API 访问能力，Skill 封装“什么时候该用哪个 API、按什么顺序调用、遇到错误怎么处理”的领域知识。

#3. 规划与 Skill 编排

#3.1 Skill 编排的架构

多 Skill 编排是 Agent 规划的核心问题。将任务分解为子目标，通过 DAG 管道检索、编排和执行多个 Skill。

AgentSkillOS 是首个系统化的 Skill 选择、编排和生态系统管理框架，包含两个阶段：（i）Manage Skills，通过节点级递归分类组织 Skill，实现高效发现；（ii）Solve Tasks，通过 DAG 基础管道检索、编排和执行多个 Skill。

TROVE（Trace-grounded Route Orchestration via Validation and Editing） 解决了预执行承诺造成的编排瓶颈。Agent 在观察到决定性运行时结果之前就优化、选择或约束执行结构，当中间证据使待定延续失效时，Agent 必须要么执行过时步骤，要么广泛重新规划，导致错误累积和计算浪费。

TROVE 的核心机制是选择性路由编辑：离线阶段将评估的工作流搜索轨迹蒸馏为原子和复合 Skill 以及结果条件转移图；在线阶段将计划路由视为临时的——提交一个顶层 Skill 后，控制器保留有效延续、插入轨迹支持的本地响应，或仅替换无效后缀。

#3.2 规划与执行的结构对比

结构	控制流来源	优点	缺点
固定工作流	人预先定义	可预测、易测	无法灵活应对未知分支
ReAct	每步依据观察选动作	可纠错、适合检索工具	长轨迹错误累积
先计划后执行	先拆任务再调用工具	全局目标清楚	环境变化后计划失效
Skill 编排（DAG）	Skill 图定义依赖	可组合、可复用、可治理	编排开销与 Skill 发现成本
搜索/树状候选	保留多条可能轨迹	避免过早局部选择	分支数与评估成本增长
多 Agent 分工	多策略/角色协作	任务可并行时有用	协调、冲突与信息损失

路线：固定流程解决重复任务 → ReAct 应对未知反馈 → 显式计划处理较长依赖 → Skill 编排将领域知识模块化 → 搜索/验证减少单路径错误 → 多 Agent 处理可分解子任务。

#3.3 多 Agent 与 Skill 共享

在多 Agent 系统中，Skill 可以作为共享的能力单元。Claude Agent 的 500 个技能位由一个会话里的所有 Agent 共享，跑在统一的托管沙盒里，Agent 之间共享内存和环境变量，由协调器统一调度。

LLM-Skill Orchestration 的三层架构展示了另一种模式：推理模型从系统约束生成编排规则，规划模型将任务分解为带显式依赖的 Skill 图，异构 LLM-Skill（纯文本和工具装备）通过共享上下文池并行执行。在 50 个 Agentic 任务、202 个子任务项的评估中，规则增强系统达到 202/202 完成率和 17.5/20 平均质量，而单模型基线仅为 137/202 和 7.4/20。

关键发现：同模型分解（D: 8/22）比不分解（A: 13/22）表现更差，证明模型多样性而非并行性驱动协作增益。规则盲生成（Hb: 96/100）优于规则知情生成（Hi: 76/100），说明从系统不变量进行演绎推理比从失败案例进行归纳学习泛化更好。

#4. 记忆要区分三层

工作记忆是当前上下文里的近期事实；长期记忆是跨会话存储的结构化事实/文档；情景记忆是过去轨迹与结果。压缩后的摘要不是原始证据，必须保留来源和时间，否则旧结论可能被当成当前事实。外部记忆检索本质上与 RAG相连，但 Agent 还需决定什么时候读、写、删和停止。

Skill 可以作为程序性记忆的载体：将交互轨迹和评估器反馈转化为持久化、版本化的可复用过程库，使不断演化的技能库成为可审计的共享程序性记忆。SkillGLoW 进一步将技能组织为“程序族”——一个任务簇共享的解决过程被聚合为程序族并压缩为去实例化的全局先验。

#5. 验证与停止

自评“已经完成”容易与真实环境不一致。验证器可分：程序测试（代码/数学）、结构化规则（格式/权限）、外部系统状态（操作是否生效）、人工评审（开放任务）。验证器若覆盖不全，Agent 会优化可测指标而忽略不可测质量。

停止条件不能只有“模型说完成”：需考虑目标已满足、预算耗尽、连续无进展、错误不可恢复、需要用户授权。若某动作会改变外部状态，工具执行边界仍由程序/用户授权控制，而不是由模型自信程度决定。

#6. Skill 的评估与实证效果

#6.1 SkillsBench

SkillsBench 是首个专为评估 Agent Skills 设计的开源、多领域、带确定性验证器的基准：87 个任务覆盖 8 个真实世界领域，配套人工精编 Skills。核心发现：精心策划的 Skill 将平均通过率从 33.9% 提升至 50.5%（+16.6 个百分点，25.5% 归一化增益），但效果因领域差异显著（+4.1 到 +25.7 个百分点）。

#6.2 SWE-Skills-Bench 的警示

SWE-Skills-Bench 是首个需求驱动的基准，隔离了 Agent Skill 在真实软件工程中的边际效用。结果令人警醒：49 个 Skill 中 39 个产生零通过率改进，平均增益仅为 +1.2%。Token 开销从适度节省到 451% 增加不等，而通过率保持不变。仅 7 个专业 Skill 产生有意义增益（最高 +30%），3 个因版本不匹配的指导与项目上下文冲突而降低性能（最高 -10%）。

这一发现的方法论意义是：Agent Skill 是一种窄干预，其效用强烈依赖于领域匹配度、抽象层次和上下文兼容性。

#6.3 评估维度

指标	含义	推荐阈值
调度正确率	Skill 是否在正确情境下被激活	≥ 0.85
内部轨迹合规率	Skill 定义的步骤是否按序执行	≥ 0.90
输出集成质量	Skill 的输出是否正确整合到最终回答中	≥ 0.80
有效工具调用率	每次工具调用的信息增益	—
权限拒绝率	越权动作被正确拒绝的比例	—

#7. Skill 的安全边界

#7.1 OWASP Agentic Skills Top 10

OWASP 于 2026 年 8 月发布了 Agentic Skills Top 10，系统化了 Agent Skill 生态系统的安全风险。26.1% 的社区贡献 Skill 包含漏洞。

主要风险类别包括：

风险	描述	缓解
AST01：恶意 Skill	同形字仿冒、指令覆盖、内存污染	签名验证、行为沙箱
AST02：供应链攻击	注册表泛洪、依赖混淆、维护者账户接管	依赖锁定、注册表哈希查找
AST03：过度授权	Skill 拥有超出其功能的权限	最小权限原则、权限分级
AST04：不安全元数据	YAML 代码执行、原型污染	元数据验证、安全解析
AST05：不可信外部指令	作者“拉地毯”、审查者“诱饵交换”	来源追溯、内容审查
AST06：弱隔离	主机逃逸、网络透视、Skill 遮蔽	容器隔离、网络禁用

#7.2 Skill Trust 与生命周期治理

Skill Trust and Lifecycle Governance Framework 提出四层、门控的权限模型，将 Skill 来源映射到分级部署能力。企业部署需要 Skills Registry——在 Agent 和 Skill 之间加一道安检门：发布前扫描、签名验证、沙箱隔离、权限最小化，让每个 Skill 从“我信你”变成“我验过你”。

JFrog Agent Skills Registry 提供了面向 MCP、模型、Agent Skill 和 Agent 二进制资产的安全记录系统，企业 AI Agent 可以在内置治理能力下大规模运行。

skillbox 是自托管的执行运行时和 Skill 注册表，为 AI Agent 提供单一 API 来注册、发现和执行沙箱化 Skill 脚本（Python、Node.js、Bash），接收结构化 JSON 输出和文件产物。默认安全——OpenSandbox 隔离且网络禁用。

#8. 多步成功率为什么会下降

若任务有 $H$ 个必须正确的步骤，每步在理想化独立假设下成功率为 $p$ ，整条轨迹成功率为 $p^H$ 。例如满足下式时仅约 $0.60$ 。真实步骤并不独立：前一步错误会改变后一步输入，可能使下降更快。验证、回滚和局部重试的价值，是阻断错误传播，而不是让模型多说几步。

p=0.95,H=10

但重试也可能放大成本和副作用。只有当验证器能区分对错、且动作可恢复时，局部重试才安全。文件写入、资金操作等副作用动作需要额外的幂等和授权边界，不能让 Agent 自己无条件“再试一次”。

#9. 计划的层级与可修正性

高层计划描述子目标和依赖，低层动作规定具体工具参数。若工具观察与计划不一致，应回到当前状态重新规划，而不是沿用已失效的后续步骤。可以把计划看成下式所示的图， $V$ 是子目标， $E$ 是前置条件；并行执行只适用于没有未满足依赖的节点。

G=(V,E)

过度详细的计划会在环境变化时过时；过于抽象则无法检查进度。适当粒度应让每个子目标有可观察的完成条件。TROVE 的选择性路由编辑原则提供了一种折中：保留已执行前缀和有效步骤，仅修复局部不匹配并重新规划无效后缀，而非从头重新生成整个未来。

#10. 评测轨迹而非只评最终文本

最终答案偶然正确不代表行动过程安全或高效。可记录：有效工具调用率、重复/无用步骤、权限拒绝、状态误读、验证器覆盖、成功任务的平均与尾部成本。将“工具调用次数多”当作能力强会激励无用动作；应比较相同任务、相同预算下的完成率与风险。

原始资料： ReAct；Tree of Thoughts；SkillsBench；SWE-Skills-Bench；Agent Skills Survey；OWASP Agentic Skills Top 10；AgentSkillOS；TROVE

交叉阅读： 工具调用规定一次动作怎样校验；RAG提供外部记忆与证据；模型服务决定多步调用的延迟成本；安全体系限制环境可执行动作。

本页由仓库中的 Markdown 生成。具体技术结论请结合正文引用与实验条件理解。