智能体技能评估，为什么光看文档没用？
你给智能体装了一个新技能，文档写得规范、安全扫描也过了，结果真到用时 agent 根本不会调用——这类问题，静态检查一个都发现不了。
企业级智能体正在从原型走向生产，可复用的技能、工具和工作流包越来越多，但上线前的评审关口大多还停留在”看文档、扫代码”的阶段。这些静态检查能发现格式问题和明显的安全隐患，却回答不了一个最核心的部署问题：这个技能真的能帮智能体更好地完成任务吗？
为什么你装的智能体技能，可能根本没用？
想象一下你买了一本菜谱，封面精美、目录齐全、纸张也合格——但翻开一看，步骤写得含糊不清，关键调料没说放多少，你照着做根本做不出菜来。静态扫描就像是检查菜谱的”外观和格式”，它能告诉你有没有缺页、有没有错别字，却没法告诉你”照着做能不能做出好菜”。
智能体技能也是一样。目前常见的评审流程包括结构检查（有没有必填字段、格式对不对）、LLM 文档质量评审（描述清不清楚）、安全扫描（有没有危险代码），但这些都属于静态评估——只看技能本身的文档和代码，不看智能体实际用起来怎么样 [1]。
那静态评估到底靠不靠谱？论文对 145 个真实企业技能做了测试，发现了一个反直觉的结果：结构检查得分和 LLM 文档质量得分的 Spearman 相关系数只有 0.14，几乎没什么相关性 [1]。换句话说，有的技能格式完美但内容含糊，有的内容扎实但缺元数据，连”什么是好技能”这两种扫描方法都没达成共识。
更关键的是，这些静态指标完全无法预测运行时表现。一个技能通过了所有静态检查，智能体可能根本不会在用户提问时发现它，或者调用错了脚本，甚至和其他技能冲突——这些问题只有真跑一遍才能发现 [1]。
当然，实际情况比这个比喻更复杂。静态扫描并非没有价值，它能发现很多作者层面的问题，比如缺少元数据、缺少局限性声明等。论文数据显示，99.3% 的技能没在 frontmatter 声明工具，97.9% 缺少局限性章节，97.2% 缺少作者字段——这些都是静态扫描能有效捕捉的 [1]。问题在于，它只能覆盖”结构”这一个维度，而技能的真实价值远不止结构。
ACES框架：用配对实验测出技能的真实贡献
ACES（Agentic Continuous Evaluation of Skills，智能体技能持续评估）框架的核心思路很朴素：是骡子是马拉出来遛遛。它不看技能文档写得怎么样，而是直接让智能体在真实任务中运行，用”有技能”和”没技能”的表现差来衡量技能的实际价值 [1]。
这个差值有个专门的名字，叫 Skill Lift（技能提升度）。它的定义是：在固定任务、固定智能体框架（harness，即运行智能体的执行环境）、固定工作空间和固定评分规则的前提下，加入目标技能后智能体的得分减去不加该技能时的基线得分 [1]。这个设计很像医学里的随机对照试验——控制所有其他变量，只改变”有没有这个技能”这一个因素，得到的就是技能的净贡献。
为了实现这个目标，ACES 有几个关键设计：
第一，配对运行。同一个任务、同一个智能体、同一个模型，分别在”有目标技能”和”无目标技能”两种条件下各跑一遍，确保结果可比。而且无技能的基线不是完全裸跑，而是保留支持技能和干扰技能，这样才能测出真实的边际贡献 [1]。
第二，ATIF（Agent Trajectory Interchange Format，智能体轨迹交换格式）。不同的智能体框架输出的轨迹格式五花八门，没法直接用同一套评分逻辑。ATIF 就是一个统一的中间格式，把不同框架的轨迹都归一化后再评分，这样同一套评估器就能评估 Claude Code、Codex 等多种智能体 [1]。
第三，六大默认指标。ACES 从六个维度评估技能效果：安全性、技能执行、技能效率、准确率、目标准确率、行为检查，等权平均为综合得分 [1]。这里面既有结果类指标（准确率、目标准确率），也有过程类指标（技能执行、行为检查、技能效率）——而过程类指标恰恰是静态扫描完全观测不到的。
第四，两种测试模式。隔离模式只放目标技能，测技能本身的内容质量；组模式则放上一堆其他技能，测智能体能不能在众多技能中正确发现并调用目标技能 [1]。这就像一本菜谱，“内容好不好”和”食客能不能在书架上找到它”是两回事——后者才是真实工作环境里的常态。
ACES 还设计了一套”评估资产一等公民”的机制，要求技能附带 evals.json 文件，里面包含用户问题、预期行为、标准答案。这些测试用例可以由作者手写，也可以用 LLM 四桶种子生成（显式/隐式/上下文/负例），还能基于真实轨迹迭代优化 [1]。
证据：静态扫描为什么靠不住？
说了这么多设计，ACES 实际效果怎么样？我们来看论文里的硬数据。
首先是核心结果：对 64 个生产技能中的 58 个、4 种主要智能体框架的 947 个配对案例，平均综合 Skill Lift 为 0.2134（95% 配对置信区间 [0.1967, 0.2301]），平均仅结果类提升（准确率+目标准确率的平均）为 0.1799。72.8% 的配对案例中，技能带来了正向提升 [1]。
这个数字意味着什么？简单说，加入一个技能后，智能体的综合表现平均提升了约 21 个百分点——这是一个相当可观的增益，而且完全无法通过静态扫描预测。
更有意思的是过程指标和结果指标的对比。技能执行、行为检查、技能效率这三类过程指标的提升最显著，而这些恰恰是文档扫描完全无法观测的信号 [1]。静态扫描只能看”文档写了什么”，但智能体实际调用技能时走了哪些步骤、用得对不对、效率高不高，这些运行时的行为细节，不跑一遍根本无从得知。
再来看静态扫描的局限性。论文做了一个相关性实验：145 个真实技能中，94.5% 通过了默认结构检查（70 分门槛），86.2% 通过了 LLM 评审，但两者的 Spearman 相关系数仅 ρ=0.14 [1]。这说明两种静态方法衡量的根本不是同一个东西——结构检查看的是格式规范，LLM 评审看的是内容质量，两者几乎不重叠。连”什么是好技能”都没达成共识，又怎么能指望它们预测实际效果呢？
还有一个有趣的实验是路由压力测试。当可见技能数量在 1-20 个范围内时，平均 Skill Lift 稳定在 0.133-0.149；但当可见技能增加到 50 个时，通过率从 0.725 降至 0.55，耗时从 258 秒升至 1290 秒 [1]。这说明技能越多，智能体”找对技能”的难度越大，技能的实际价值也会打折扣——而这个发现，静态扫描更是完全不可能得到。
当然，ACES 也不是完美的。论文承认了几个局限：技能效率指标方差很大，只有 41.7% 的案例中出现正向提升；评估依赖作者提供的任务集，任务质量直接影响评分结果；目前只验证了四种主要智能体框架的适用性 [1]。另外从读者角度看，论文没有提供与其他技能评估方法的直接量化对比，也没有测试多个技能协同或冲突的复杂场景 [1]。
从技能评估到智能体系统评估：更广泛的挑战
技能评估不是孤立的问题，它只是更大的智能体系统评估图景中的一块。当多个智能体协同工作时，评估的复杂度会指数级上升。
比如多智能体系统的协调拓扑——也就是智能体之间怎么分工、怎么通信——会从根本上改变系统的行为模式。有研究对比了顺序、星型、全连接三种协调拓扑，发现拓扑不仅影响任务完成质量，还会改变底层 LLM 调用的流量模式：星型拓扑下超过一半（54.9%）的请求间隔小于 50 毫秒，形成密集的请求突发，对推理后端的冲击远大于顺序模式 [2]。经典的泊松到达假设在多智能体流量里完全站不住脚，推理阶段的间隔更符合对数正态分布 [2]。
这意味着什么？意味着当你评估一个由多个智能体组成的系统时，不能只看单个技能或单个智能体的表现，还要考虑它们的协作方式对整个系统的影响。一个技能在单智能体环境下表现很好，放到多智能体协作场景里可能因为通信开销、协调 overhead 而收益大打折扣。
再比如，多智能体系统的评估本身也可以用多智能体来做。Tree-of-Concerns 框架就是一个例子：它用 5 个专业的”怀疑论者”角色（分别盯适用范围、实验方法、理论严谨性、可复现性、公平性）各自独立地从科学论文中挖掘未声明的局限性，最后再由一个全局面板校准结果 [3]。实验显示，这种专业化角色+并行辩论的方式，比最强基线（Single-skeptic CoT）的精度高 79%、覆盖高 11% [3]。这个思路反过来也启发我们：技能评估本身是不是也可以用多智能体辩论的方式，从多个维度交叉验证？
还有一个容易被忽视的问题：评估指标本身可能存在不对称性。有研究发现，结构标记对模型”读文档”有帮助，但对”按指令写文档”反而有害——同一指令内容，用嵌套 XML 形式输入时，回答合格数从 23/31 降到了 15/31 [4]。这提醒我们，技能评估的指标设计不能想当然，同一个结构设计在不同任务类型上的效果可能完全相反，必须通过实验验证。
更有意思的是，系统与人类表现的差距，很多时候不是能力问题而是信息问题。还是刚才那项投标书撰写系统的研究，系统比人类写得差的地方，68% 根本不是写作水平问题，而是人类作者知道的信息（比如分包商的税号、之前和甲方的私下沟通）从来没放进 AI 的资料库 [4]。技能评估也是一样——如果评估任务的背景信息不完整，或者技能本身就缺少必要的输入，那评估结果很可能低估了技能的真实价值。
技能评估的过去、现在和未来
技能评估这个领域正在经历一场范式转变。过去我们关注的是”怎么创建技能”，现在越来越转向”怎么评估和进化技能”。有综述把技能进化分为四大范式：执行反馈、轨迹蒸馏、压缩、强化学习，每一种范式都依赖不同的评估机制 [7]。
早期的评估更多聚焦于大模型本身的价值观对齐，但智能体的行为不仅取决于底层模型，还受到执行框架和嵌入技能的深刻影响。Agent-ValueBench 是首个专门针对智能体价值观的基准，它发现智能体的价值观与底层 LLM 的价值观存在明显差异，执行框架（harness）和技能才是引导智能体对齐的关键杠杆 [6]。这意味着，技能评估不能只看功能对不对，还要看它会不会改变智能体的行为边界和价值倾向。
评估的另一个趋势是从”有标签”走向”无标签”。现实场景中，很多任务根本没有标准答案——你怎么定义”写一份好的项目计划”的金标准？SkillAudit 框架提出了配对轨迹审计的思路：同一个任务，分别在有候选技能和无候选技能的情况下执行，通过对比两条轨迹的差异来隔离技能的影响，完全不需要外部标签或奖励 [8]。它还设计了 PACE（Process-Aligned Contrastive Evaluation，过程对齐对比评估）方法，把轨迹中的行为差异映射到技能文档的具体段落，从而指导针对性的修改 [8]。实验显示，SkillAudit 在 89 个容器化任务上达到了 73.9% 的平均任务奖励，显著优于无技能的 40.9% 和静态专家技能的 56.7% [8]。
当然，这个领域还有很多开放问题。比如，Skill Lift 在模型更新后的纵向稳定性如何？现在测出来技能有用，换个模型版本会不会就没用了？再比如，当前评估主要集中在系统访问、部署、平台、数据基础设施类技能，对故障排查、创意类等代表性不足的技能类别，评估方法的泛化性还不清楚 [1]。还有，怎么自动选择有代表性的干扰技能或前置技能集合，让组模式测试更贴近真实环境？这些都是有待解决的问题 [1]。
从更大的视角看，技能评估正在从”单点测试”走向”持续评估”——不是上线前测一次就完事，而是集成到 CI/CD 流水线里，每次技能更新、每次模型升级、每次框架变更都自动跑一遍评估 [1]。只有这样，才能在技能库不断膨胀的情况下，保证每一个上线的技能都是真正有用的。
如果你只记住一件事
别光看技能文档写得怎么样，让智能体带着技能和不带技能各跑一遍，差值就是技能的真实贡献。
参考文献
- Evaluating Skills, Not Just Agents: Agentic Continuous Evaluation of Skills（arXiv、2026、全文精读）
- Towards Traffic Modelling of Multi-Agent Systems: The Role of Coordination Topology（arXiv、2026、全文精读）
- Tree-of-Concerns: Hierarchical Multi-Agent Debate for Unstated-Limitation Extraction in Scientific Critique（arXiv、2026、全文精读）
- Structure for Reading, Prose for Writing: Asymmetric Structural Conditioning in Multi-Agent Document Authoring（arXiv、2026、全文精读）
- Artificial Leviathan: Exploring Social Evolution of LLM Agents Through the Lens of Hobbesian Social Contract Theory（arXiv、2026、全文精读）
- Agent-ValueBench: A Comprehensive Benchmark for Evaluating Agent Values（arXiv (Cornell University)、2026、仅摘要）
- Agent Skill Evaluation and Evolution: Frameworks and Benchmarks（arXiv (Cornell University)、2026、仅摘要）
- SkillAudit: Ground-Truth-Free Skill Evolution via Paired Trajectory Auditing（arXiv (Cornell University)、2026、仅摘要）