AI技能目录的本质：声明式规范与运行时安全的鸿沟

一、被忽视的“最后一公里”

大模型的能力上限在快速抬升，但“让AI真正替人干活”的落地卡点，往往不在生成能力，而在权限与能力的匹配上。在自动化代码生成与智能体（Agent）工具调用领域，这被称为“最后一公里”问题：如何让AI安全、可控、可审计地使用外部能力。

想象几个典型场景：写代码时让AI顺手查一下API文档；分析日志时让它自动去数据库拉取数据；处理工单时让它调用内部系统接口。听起来简单，工程上全是坑。

二、三个绕不开的核心诉求

1. 安全。 你不能把生产数据库的凭证直接塞给AI。模型存在幻觉，也可能被精心构造的输入诱导——一次误触发的 DROP TABLE，足以让“AI提效”瞬间变成“事故复盘”。安全的底线是：最小权限、默认拒绝、高危操作可拦截。

2. 可控。 AI需要“知道什么时候该用什么工具”。事事请示（“老板，我现在能调用这个吗？”），体验崩塌；事事自作主张，风险失控。可控的本质是：行为边界可预期、异常动作可干预。

3. 可组合。 今天写好的查天气技能，明天应能与订票、行程规划等技能自然联动，而不是每个场景推倒重来。可组合的前提是统一的元数据格式与标准化的发现机制。

这三条诉求彼此牵制：收紧安全往往牺牲灵活，追求灵活往往放大风险。于是行业长期在两个极端之间摇摆。

三、两条传统路径的困境

路径一：硬编码。 开发者写死一堆 if-else——“看到关键词‘天气’就调用 get_weather()”。这条路线笨拙但安全：每个调用都在人的预料之内。代价是脆弱、难维护，能力扩展完全依赖人力堆叠，与“智能体”的初衷背道而驰。

路径二：完全放权。 把工具与凭证全部交给AI，由它自行决策调用时机与方式。灵活，但等同于在服务器上开了一个不受控的后门：行为无法约束，出事无法追责。

检索增强生成（RAG）与简单的函数调用（Function Calling）在不同维度上缓解了上述问题，但都没有跳出“权限过大或能力过窄”的怪圈：RAG解决的是“知识供给”，管不住“行为边界”；裸的函数调用解决的是“接口可达”，管不住“权限纵深”。

四、第三条路：声明式技能目录

近期业界出现了“技能目录”一类方案，核心是一套声明式技能元数据规范：技能提供者编写一份 YAML 格式的描述文件，声明技能名称、触发条件、所需权限与功能说明，提交进一个结构化目录；AI 运行时按需发现技能、按声明调用。一份技能清单的通用形态大致如下：

name: query-flight-status
trigger: 用户询问航班动态
permissions:
  - scope: flight_db:read
description: 查询航班实时状态，返回起降时间与延误信息
version: 1.0.0

这套设计的愿景可以概括为：给AI发一本盖过章的《工具使用白皮书》——所有能力统一格式报备、统一入口发现、按声明权限调用。理论上它同时回应了三大诉求：格式统一带来可组合，声明权限带来可控，集中目录带来可治理。

理想很丰满。但一个关键问题悬而未决——

五、深层矛盾：没有执法队伍的“法律条文”

一本没有任何执法队伍与法庭配套的法律条文，真的能约束行为吗？对这一思路做一次基于真实代码仓库状态的“技术审计”，会发现三条结构性裂缝：

1. 声明不等于执行。 清单里写“本技能只需读权限”，运行时谁来验证？如果调用侧没有强制的策略校验，声明就只是君子协定。一个粗心（或恶意）的技能完全可以声明 read、实际执行 write；一条越权调用链可以完全绕开清单里那句轻飘飘的权限声明。

2. 静态菜单覆盖不了动态攻击面。 声明式规范管的是“写什么”，管不住“运行时发生什么”。提示注入可以让AI“自愿”组合出超出用户意图的调用；技能的描述文本本身也可能被污染，成为注入载荷的载体——自然语言描述越丰富，攻击面反而越大。

3. 组合性会放大风险。 单个技能各自无害，不等于组合无害。“读取内部数据”与“发送外部消息”两个技能单独看都合规，串起来就是一条数据外泄管道。静态目录记录的是单点权限，无法推理组合调用的累积后果。

结论很直接：声明式技能规范解决的是“可发现、可描述、可分发”，它本身不是安全机制。把规范当护栏，是工具化进程中最典型的架构错觉。这份“菜单”有价值，但只是必要条件，远非充分条件。

六、弥合鸿沟：四层架构实践

要让技能目录真正可用，必须在“声明”之外补上“校验、隔离、审计”三层，形成闭环：

第1层：声明层——带签名的技能清单。 元数据格式统一（名称、触发条件、权限声明、版本、提供者签名），技能入库需审核与签名，防止描述文本投毒。清单回答“有什么、是什么”。

第2层：网关层——策略执行点。 所有工具调用必须经过统一网关，由策略引擎基于“当前用户、当前会话、当前意图、当前参数”动态判定放行与否。关键原则：默认拒绝（deny by default）、最小权限、敏感参数过滤。清单回答“声称要什么”，网关回答“此刻允许什么”。

第3层：运行层——沙箱与凭证隔离。 技能在受限沙箱中执行，文件系统、网络、数据库访问均按策略放行；凭证不进入模型上下文，由网关代持、按次签发短期凭证——AI只拿到“技能句柄”，永远拿不到原始密钥。删表、删除资源、对外发送等高危操作强制人工审批。

第4层：审计层——全链路可回放。 记录每次调用的主体、时间、技能、参数与结果，支持回放与归因。异常行为能一路追溯到具体技能的具体声明，反过来为声明层的治理提供反馈。

一次调用的策略校验伪代码示意：

def invoke_skill(skill_id, params, session):
    spec = registry.get_signed_spec(skill_id)        # 读取签名清单
    decision = policy_engine.decide(session, spec, params)
    if not decision.allowed:
        raise PermissionDenied(skill_id)            # 默认拒绝
    creds = vault.issue_short_term(decision.scopes) # 短期凭证
    result = sandbox.run(spec, params, creds)       # 沙箱内执行
    audit.log(session, skill_id, params, result)    # 全链路留痕
    return result

七、工程落地建议

• 权限分级：按“只读 < 幂等写 < 危险操作”对技能分级，级别越高，审批强度与审计密度越高；
• 跨技能风险推理：不只审查单点权限，要评估整条调用链的累积效果，必要时对组合调用设置额外的人工确认阈值；
• 目录不等于信任：入库审核、签名校验、运行时强校验，三道门缺一不可，任何一道都不能因为“清单里写了”而豁免；
• 善用通用云能力：沙箱可用容器平台承载，审计可依托日志与监控告警服务，凭证隔离可借助密钥管理能力。企业基于百度智能云等平台的对象存储、日志服务、密钥管理等通用类目能力即可搭建上述分层，无需重复造轮子。

八、结语：技能目录的本质

回到最初的问题：技能目录的本质是什么？

它不是AI能力的升级，而是一份“权限说明书”——把AI能用什么、怎么用、要什么权限白纸黑字写清楚。这份说明书有真实价值：它让能力可发现、可复用、可治理，是智能体工具化进程的必要基础设施。

但它天然解决不了另一半问题：运行时安全。声明与执行之间的鸿沟，无法靠一份更厚的菜单弥合，只能靠“策略引擎＋沙箱隔离＋全链路审计”的运行时机制补上。

一句话总结：规范负责“说清楚”，运行时负责“管得住”。只有当二者闭环，AI才真正配得上拿到那把钥匙——而且是一把尺寸刚好的钥匙。