评测：小模型能否承载Agent技能框架

一、评测概述：这个问题为什么值得评测

基于技能库组织智能体行为的框架，配合主流闭源旗舰模型与智能体编程工具，已在复杂任务编排场景中表现出色。但工业界的现实是：这套框架几乎沦为了超大型闭源API的专属工具。当项目涉及金融风控、军工级数据隔离等强合规场景时，持续调用公共API的方案会在合规审查与预算审查的双重压力下被直接否决。

由此形成一个非常具体的技术评测问题：为巨型模型设计的Agent技能框架，能否下放到本地运行的开源小语言模型（SLM），并保持可量化的性能水平？海外研究机构的研究者围绕这一问题开展了系统工作：一方面在底层用严格的数学模型重构了技能框架，另一方面拉通了从270M到80B参数规模的全谱系开源模型，在最贴近真实业务的工业数据集上进行抗压极限测试。

本文的价值不在复述研究结论，而是把这项工作转化为一套可复用的评测方法论。读完本文，您应能回答三个决策问题：

• 在有限硬件预算下，应该选择什么参数规模的模型；
• 技能库与路由应该怎样配置，才能匹配模型能力；
• 用哪些维度、哪些流程判断一套本地智能体方案“能不能打”。

本文适合正在做私有化智能体选型的开发者、架构师、技术负责人、运维人员，以及需要评估算力预算的企业技术团队。

二、评测对象：技能框架与它的形式化基础

2.1 技能的三元组结构

研究者将每个技能定义为一个抽象三元组，这也是评测时必须拆开观察的对象：

• 文本描述符：包含技能名称与文字描述，是智能体决策时“看得见”的部分；
• 内部策略：时间上延伸的选项级过程或工作流，即技能被触发后引发的一系列动作；
• 引用机制：能揭示额外技能相关上下文与工具的机制，甚至包含指向其他技能的指针，形式化为一个马尔可夫核。

这个结构提示评测者：评测不能只看“技能执行结果”，还必须覆盖两个更隐蔽的环节——模型是否正确理解描述符并选中技能（选择环节），以及引用机制展开的上下文是否被有效消化（信息获取环节）。许多小模型方案的失败并不发生在执行，而发生在选择与获取。

2.2 POMDP建模：把黑盒直觉变成可量化指标

研究者将技能系统抽象为一个受限的、在部分可观测世界中进行信息搜寻的控制器。智能体在每个决策步需要权衡任务进度与有限的注意力、上下文资源，并从三类动作中选择：提交并执行某项技能；揭示关于该技能或其引用的更多信息；在环境中采取直接行动。

由于底层系统遵循马尔可夫动态，而智能体无法直接观察真实的“智能体-任务”状态，系统被自然建模为部分可观测马尔可夫决策过程（POMDP），并显式引入信息获取动作（例如付费上下文获取），以额外成本换取更好的观测结果。对应的状态空间为：

• 状态S：可能被隐藏的任务情境，包括用户意图、任务阶段与进度、尚未检索到的环境事实；
• 观测O：智能体当前可访问的内容，如当前用户消息、可用历史记录、已揭示或加载的资源与技能；
• 动作A：技能选择、付费上下文获取、技能执行、环境与工具调用，外加内部规划与推理；
• 信念状态：智能体基于迄今观测与历史动作，对真实状态的推断。

这套形式化对评测的直接意义在于：每一类动作都可以被记录、统计与归因，评测从“整体打分”升级为“决策行为分析”。

三、评测目标：启动前必须明确的五个问题

评测不是笼统判断“好不好”，而是围绕业务目标回答具体问题。建议在评测启动前明确：

1. 技能理解能力：小模型能否依据描述符从技能库中稳定选中正确技能？
2. 上下文效率：上下文预算受限时，引用与付费获取动作能否换来足够的任务收益？
3. 规模匹配关系：技能库复杂度与模型参数规模之间存在怎样的匹配边界？
4. 硬件可行性：目标硬件上能否满足延迟、吞吐与显存约束？
5. 合规可控性：数据是否全程不出域，权限、审计与日志能否通过审查？

这五个问题分别对应后文的准确性、资源效率、功能与性能、安全维度，避免指标堆砌却无法指导决策。

四、评测维度设计：把“能不能打”拆成可观察指标

评测维度	关注点	验证手段
技能选择准确性	能否依据描述符选中正确技能	带专家标注的任务集上统计命中率与误选分布
上下文资源效率	付费获取动作的决策质量	记录获取次数、时机与任务收益，绘制上下文预算曲线
功能完整性	技能执行、工具调用、多跳引用是否闭环	端到端任务跑通率与失败环节归因
性能表现	响应时间、吞吐、资源占用	分档压测，记录显存峰值、单步延迟、并发吞吐
稳定性	异常输入、技能失效、长时运行	故障注入、连续运行观察、失败模式统计
安全合规	数据不出域、权限、审计	私有化部署检查清单、日志完整性抽查
易用与可维护	技能编写与调试成本、升级回归	人工记录改造成本、回归测试通过率
成本结构	硬件投入与隐性成本	综合TCO估算，含重试与人工兜底成本

其中三个维度是该框架特有的，需要重点展开：技能选择准确性决定路由层是否可用，误选分布能揭示小模型在语义理解上的具体短板；上下文资源效率是POMDP建模的核心收益点，好的系统应表现为“按需获取、即用即停”；失败归因则要求把失败拆为选错技能（路由问题）、执行失败（能力问题）、资源耗尽（预算问题）三类，三类失败的修复路径完全不同。

五、评测环境与前提条件

测试前需要锁定的边界条件包括：

• 模型谱系分档：参照研究覆盖的从270M到80B的范围，可划分为轻量级（1B以下）、入门级（1B–7B）、中档（7B–14B）、高档（30B以上）分档测试；
• 硬件与推理配置：明确显存/内存预算、量化方式与推理框架版本，并全程保持一致；
• 数据集要求：使用贴近自身业务的工业数据集，覆盖典型任务类型与难度梯度，避免纯合成数据带来的偏差；
• 技能库规模：固定技能数量、描述粒度与引用深度，作为控制变量之一。

若团队缺乏足够的本地显卡资源，可先在云端搭建弹性测试环境——例如使用百度智能云提供的GPU云服务器、容器服务等通用算力产品完成大规模分档筛选，再将候选方案回迁本地私有化环境做合规验证，以缩短评测周期。

六、评测方法与测试流程

建议按以下流程执行：

1. 建立基线：用无技能增强的小模型裸跑同一任务集作为对照组；条件允许时再用闭源API旗舰模型跑同一技能库，形成能力上限参照。
2. 控制变量：同一技能库、同一数据集、同一推理配置，仅改变模型规模，保证结果可归因。
3. 轨迹记录：基于POMDP的动作分类，逐步记录动作类型、上下文占用与任务进度增量。
4. 异常测试：注入技能描述缺失、引用循环、工具超时等故障，观察容错与恢复表现。
5. 结果聚合：按模型分档汇总命中率、成功率、上下文消耗与资源占用。

通用评测循环可用伪代码示意：

MODELS = [轻量级, 入门级, 中档, 高档]        # 270M ~ 80B 分档
for model in MODELS:
    agent = build_agent(model, skill_library, router_config)
    for task in industrial_dataset:          # 带标注的真实业务任务集
        trace, ctx_used = [], 0
        while not task.finished and len(trace) < MAX_STEPS:
            action = agent.decide(observation)   # 选技能/取上下文/执行/调工具
            ctx_used += action.context_cost
            trace.append(record(action, task_progress_delta))
        metrics.add(score(trace, task.reference), ctx_used, resource_profile)
analyze(metrics)   # 分档对比命中率、成功率、上下文消耗与资源占用

七、结果解读：结论必须带条件

• 命中率要结合任务类型看：描述符语义简单的技能，轻量级模型也可能胜任；涉及多跳引用与隐式用户意图的技能，小模型与旗舰模型的差距会被显著放大。因此结果必须与技能描述的工程化程度一起解读。
• 上下文行为比总量更关键：理想模式是按需获取。若轨迹反复出现“获取后仍无法推进、再次获取”，通常说明模型信息整合能力不足，而非预算不够。
• 失败归因优于总成功率：选错技能可通过结构化描述与外置路由补偿；执行失败需要更大参数规模；资源耗尽则需要压缩技能引用深度。
• 所有结论都应附带条件，例如“在某类任务、某规模技能库、某显存约束下，某档模型表现可用”。脱离条件的绝对化结论不可迁移。

八、适用场景分析

• 强合规数据隔离场景（金融风控、涉密数据处理）：本地部署是硬约束，即使小模型能力略逊于闭源API，也可能是唯一合规选项；此时评测重心从“能力上限”转向“约束内做到可用”，重点验证安全与稳定性。
• 边缘与离线环境：模型规模与硬件强绑定，重点验证性能与资源占用。
• 高频、模式固定的任务：技能库相对稳定，重点验证“小模型+固化技能库”组合的效率与稳定性。
• 复杂探索型任务：宜采用分级路由——常规请求由小模型处理，复杂任务升级到大参数模型，此时评测需额外覆盖路由本身的准确率与延迟开销。

九、风险与限制

• 样本偏差：工业数据集覆盖度有限，技能库设计质量直接影响结论，标注需多人交叉验证；
• 环境差异：量化方式、推理框架版本、驱动配置都会改变表现，结论不可直接迁移到未验证的环境组合；
• 结论时效性：技能库与模型都在演进，评测结论有“保质期”，需建立回归评测机制；
• 研究结论的边界：论文的形式化与全谱系测试是在其特定实验条件下完成的，引用时应复述条件而非只复述结果。

十、选型与使用建议

1. 先定约束，再选模型：合规硬约束优先级高于性能；预算受限时先做分档筛选，而非直接押注某一规模。
2. 从中间档起步验证：不要默认参数越小越省钱——若成功率过低导致重试与人工兜底成本上升，综合成本可能反超更大的模型。
3. 路由与执行解耦：将技能选择交给结构化路由（规则加轻量模型），将执行留给参数量更大的模型，是常见的性价比结构。
4. 描述符工程化：为小模型编写触发条件明确、结构化程度更高的技能描述，往往比直接换更大的模型更划算。
5. 建立回归评测：技能库每次变更都跑标准任务集，防止“改一处、坏一片”。
6. 善用弹性算力加速评测：本地资源不足时，可借助百度智能云等云服务商的GPU云服务器、容器服务等通用产品完成大规模筛选，再回迁本地验证合规。

十一、总结

本文的评测对象是“Agent技能框架+本地开源小模型”这一组合能力：形式化基础是POMDP，它把智能体行为拆解为技能选择、付费上下文获取、技能执行与工具调用等可记录动作；核心维度包括技能选择准确性、上下文资源效率、功能完整性、性能、稳定性、安全合规、易用性与成本结构；验证方法强调基线对照、控制变量、轨迹记录与失败归因；结论边界强调条件化表达与持续回归评测。最终判断应落在具体业务约束上：合规要求越强，本地小模型方案的相对价值越高；任务越开放，对模型规模与路由设计的要求越高。在有限硬件预算下，真正决定成败的往往不是“选最大的模型”，而是把技能描述、路由与评测闭环这三件事做扎实。