生态：MCP、Skill 与知识供给

一句话：企业平台的能力供给要分成原子工具、业务技能和知识资产三层，并让它们通过声明式依赖解耦；换来的是可复用与可治理，代价是每一层都要有版本、审核和下线机制。

为什么需要

如果每个 Agent 直接连数据库、直接写业务逻辑、直接把文档塞进提示词，平台会迅速退化成一堆一次性脚本：

• 同一个查询被十个 Agent 各封一遍，参数和权限口径都不同。
• 业务流程散落在各团队的提示词里，改一次审批顺序要改十个地方。
• 知识没有来源、版本和权限标记，模型引用了过期制度也没人知道。

这三个问题对应三种不同粒度的能力：原子操作、业务流程、知识资产。把它们混成一层，任何变更都会牵一发动全身；分成三层，才能各自独立演进。

核心机制

三层供给与调用链

看这张图只需看两类线：实线是声明，Skill 写下“我需要哪些工具、哪些知识域”，里面没有地址也没有凭证；虚线是解析，运行时由编排层把声明翻译成带权限的具体连接。工具和知识之间没有边——它们互不依赖，都是由 Skill 声明后各自注入，这正是三层能独立替换的原因。

三层解耦的关键是声明式依赖：Skill 不硬编码工具地址，只声明需要哪些能力；知识不直接暴露给 Agent，只通过 Skill 声明需要哪些知识域。编排层在运行时解析依赖、做权限过滤、注入连接。这样换一个 MCP 实现或换一个向量库，不需要改 Skill 正文。

MCP 市场：注册、评审、上架、下线

阶段	动作	关键产物
开发	按协议实现 Server，声明工具与输入输出	代码、Schema、测试用例
注册	提交元数据：owner、用途、数据级别、风险等级	注册记录、自动文档
安全评审	静态扫描、依赖扫描、数据流检查、沙箱行为观察	评审结论、阻断原因
灰度	在测试环境由测试 Skill 调用	成功率、延迟、异常行为
上架	进入工具目录，按角色授权	可见范围、调用配额
监控	成功率、延迟、错误分布、异常出站	告警与降级开关
下线	标记废弃、通知依赖方、保留迁移窗口	迁移记录、摘除时间

评审流水线要能自动阻断三类问题：硬编码凭证、声明只读但实际有写操作、内网工具出现外网请求。人工评审只处理语义问题，比如“申请了数据库写权限但功能只需要读”，不要让人重复做机器能做的检查。

MCP 工具的粒度与风险

粒度	示例	风险
一个工具做一件事	get_status、get_logs、restart	选择准确，授权清晰
万能工具	manage_service(action, params)	模型猜参数，权限无法细分
只读工具	查询、检索、Schema 查看	低风险，可自动执行
写工具	创建、修改、发布	需审计，部分需审批
不可逆工具	删除、支付、回滚	默认禁止自动执行，必须人工确认

工具描述本身是不可信输入，可能藏提示注入；只接允许列表内的 Server，版本钉住，凭证最小化并定期轮换，异常时能一键停用。

Skill：声明式业务能力

一个 Skill 至少要有五部分：入口描述（何时用）、输入输出契约、执行步骤、工具与知识依赖、治理属性（数据级别、审计级别、是否需人工）。

执行类型	LLM 参与	适用	代价
规则型	否	格式校验、阈值判断、身份核验	无法处理非结构化输入
工具型	否	查询、拉取、状态检查	无法做综合判断
模型型	是	风险评分、报告生成、异常分析	结果有方差，需评测
混合型	部分步骤	先收集证据再综合判断	编排与排障最复杂

混合型是生产里最常见的：证据收集用规则和工具保证确定性，最后的判断交给模型。把整条流程都交给模型，会让可复现性消失；全部写成规则，又覆盖不了非结构化输入。

Skill 的组合与版本

Skill 可以调用 Skill，形成“原子技能 → 复合技能 → 场景技能”的层级。组合带来两个约束：

• 深度限制：调用链过深会让预算、超时和排障失控，通常限制在两层到三层。
• 版本契约：复合 Skill 声明依赖的子 Skill 版本范围，子 Skill 升级要跑兼容性测试；破坏性变更走新主版本，旧版本保留迁移窗口。

发布流程建议双审：业务负责人审流程正确性，安全负责人审数据与权限。灰度先对少量流量开放，观察成功率、人工接管率和成本，再全量。

知识库：分层、摄入、检索、权限

知识不是一堆文档，而是按来源、更新频率和受众分层的联邦：

层	内容	更新频率	检索方式
制度规范	制度、监管要求、操作规程	月级	全文 + 语义
业务知识	产品手册、流程、FAQ	周级	语义 + 结构化
案例	历史案例、处置记录	日级	相似案例检索
技术文档	接口、运维手册	日级	全文 + 代码检索
实时数据	指标、交易、行情	秒级	结构化查询，非向量
外部知识	法规、行业报告	日级	语义检索

摄入管道不是“切块 → 向量化”两步：解析要处理表格、公式、页眉页脚；分块要按章节和语义边界，保留上下文；元数据要标来源、页码、版本、数据级别和业务域；入库后要抽样校验分块质量和检索准确率。没有元数据的知识，后面既无法做权限过滤，也无法判断时效。

检索用多路召回加融合：语义召回理解意图，关键词召回精确匹配编号和术语，结构化召回按业务域和时间过滤，图谱召回补隐含关系。融合后再用交叉编码器重排，取少量高置信结果注入。单路召回在复杂问题上准确率有限，多路加权能明显提升，但每一路都要独立监控，否则某一路退化会被平均值掩盖。

权限控制的关键是检索前过滤，不是检索后过滤。先按用户的数据级别和业务域裁剪候选集，再排序注入；先召回再提醒模型“别泄漏”，泄漏已经发生。每次检索记录谁、何时、查了什么、给了哪个 Agent。

实战场景

场景一：一个自称只读的 MCP 打穿租户边界

现象：业务团队从社区装了个工单查询 MCP，注册元数据写的是只读、data_level: internal，两天就上了生产。两周后安全抽查发现它的 run_query 接受任意 SQL 字符串、不带租户过滤，一次 Agent 调用返回了另外三个租户共 1.7 万条工单，跨租户可读窗口 14 天。同时它还拖累效果：万能工具让工具选择准确率从 91% 掉到 76%（经验值，需校准）。

排查：看 trace 判是不是提示注入——模型在 THINK 输出的是正常 TOOL_ACTION，参数取自业务问题，没有拼串痕迹，注入排除。看网关判授权依据——网关照注册声明放行，授权依据是“它说自己是只读”。看数据层——MCP 连后端用的是自带的一份高权限凭证，不是调用者身份透传；三层里唯一能兜底的正是这一层，它没兜。根因是注册阶段采信声明、评审阶段没做数据流检查。

对症做法：评审把机器能查的做成自动阻断——硬编码凭证靠静态扫描、声明只读实际有写靠沙箱行为观察、内网工具外发靠出网观测，人只处理“申请了写权限但功能只需要读”这类语义问题。粒度同步收紧：manage_database(action, sql) 拆成 get_ticket_by_id、list_tickets_by_tenant，租户参数缺失即拒绝调用；版本钉住、允许列表外的 Server 不接；写工具需审计，不可逆工具默认禁止自动执行。不这样做会：授权粒度停在“能不能调这个工具”，落不到“能不能读这批数据”，审核结论与真实能力脱节。

mcp_review:
  block_on: [hardcoded_credential, declared_readonly_but_writes, intranet_tool_egress,
             no_tenant_scoping_param, self_minted_credential]
  grant: {style: caller_identity_passthrough, require: [owner, data_level, risk_level]}

复盘要点：协议不是权限系统，真正的授权在后端和网关；工具描述是不可信输入，注册元数据同样是不可信输入，必须用行为观察去验证声明；检索前过滤的原则对工具候选集一样成立。

场景二：Skill 升了版本，老会话跟着变了答案

现象：合同条款核对 Skill 从 v1.4 升到 v1.5，只改了第 2 步（阈值判断换成模型评分）。上线当天法务反馈“上周同一份合同的结论不一样了”，一周内不一致 18 单，人工复核率从 12% 升到 31%（经验值，需校准）。更棘手的是无法归因：会话记录里只存 Skill 名，没存解析后的版本，看不出哪一单跑的是 v1.4。

排查：模型层——固定 prompt 与固定知识重放，输出稳定，不是推理方差。知识层——条款条目版本未变、引用一致，排除知识漂移。工具层——MCP 依赖版本钉住未变，排除实现变更。定义态——skill_version 从未写进会话状态，灰度直接把新版推给了存量会话；版本没和定义态绑定，所以每一层单独看都没错，合起来行为就漂了。

对症做法：版本在会话创建时解析并锁定，升级只影响新会话；恢复与复现一律按快照走，对应正文那条验收——Skill 改版本后旧会话仍按旧版本执行。不这样做会：一次阈值调整同时改写存量会话的行为基线，评测数据失去可比性，故障回溯找不到具体定义。

release:
  pin: session_level              # 会话创建即锁 skill@1.4，不自动跟版
  gray: {traffic: 5%, observe: [success_rate, human_takeover, cost]}
  breaking_change: major_version  # 破坏性变更走新主版本，旧版留一个迁移周期
composite_skill:
  depth_limit: 3
  depends: [{skill: clause-extract, version: "^1.4"}, {skill: risk-score, version: "^2.0"}]
session_state_snapshot: [skill_version, resolved_dependency_tree, knowledge_version]

复盘要点：版本契约要在发布时解一次、记一次，而不是运行时现取最新；子 Skill 升级先跑兼容性测试再动父版本范围；“行为漂移”与“模型方差”必须可区分，区分不了就说明版本没外置。

场景三：知识“查得到但答不对”

现象：运维问答场景，召回监控显示 top-5 命中正确分块的比例 88%，但“答案错或引用错”的投诉每月 60 多起（经验值，需校准），转人工率没降。抽查归出三类：引用已废止的旧版操作规程；表格被切散，引用落在表头块、数值在另一个块；告警码、设备编号被语义召回匹配到相近编号。

排查：模型层——把正确分块手工塞进 prompt，模型答对，说明生成侧没问题。检索层——分路看而不是看融合平均值：语义路 88%、关键词路对编号类查询只有 41%、结构化路根本没生效。摄入层——抽样 200 个分块，表格类完整性只有 62%（经验值，需校准），effective_at、deprecated 缺失，检索无法按时效裁剪候选集。问题出在检索口径与元数据，不在模型。

对症做法：编号和代码类查询交给关键词路做精确匹配，时效与业务域交给结构化路做候选集裁剪，图谱路在文档量不到五千时不上（与正文“小规模两路足够”同口径）。每一路独立监控，某一路退化不能藏在融合平均值里。不这样做会：调 top_k 和 min_score 只是把错答的概率挪了个位置。

retrieve:
  recall:
    - {route: semantic, weight: 0.40}
    - {route: keyword, weight: 0.35, boost: [doc_id, alarm_code]}
    - {route: structured, weight: 0.25, filter: [domain, not_deprecated, effective_at]}
  rank: {fuse: rrf, rerank: cross_encoder, top_k: 5, min_score: 0.72}
ingest:
  chunk: by_section_boundary    # 表格整块保留，不跨表切
  metadata_required: [source, page, version, data_level, domain, effective_at, deprecated]
  sample_audit: {rate: 5%, check: [chunk_quality, retrieval_accuracy]}

症状	归因层	判定信号
答非所问但引用是对的	生成	手工塞正确分块仍答错
引用对但结论错	知识时效	命中分块的 deprecated 为空
编号与代码类总是错	检索口径	关键词路命中率显著低于语义路
表格数值错位	摄入分块	抽样分块完整性低

复盘要点：“查得到”到“答得对”之间的差距由元数据决定——没有版本和时效标记就谈不上检索前裁剪候选集；require_citations: true 只保证引用格式存在，不保证引用的是当前有效版本。

最小上手

先做一条最小供给链：一个只读 MCP 工具、一个工具型 Skill、一个小知识库。

skill: policy-lookup
trigger: 用户询问制度条款时
inputs: { question: string, domain: string }
outputs: { answer: string, citations: array }
steps:
  - type: retrieve
    knowledge: policy-kb
    top_k: 5
    min_score: 0.72
  - type: llm
    instruction: 只依据检索结果回答，逐条给出引用
  - type: validate
    require_citations: true
governance:
  data_level: internal
  audit: full
  human_review: false

验收看四件事：检索结果带来源和版本；权限不足的文档不会进入候选集；工具超时返回可读错误；Skill 改版本后旧会话仍按旧版本执行。

生产动作

• owner 制：每个 MCP、Skill、知识库都有负责人和用途说明，无 owner 不上架。
• 版本钉住：生产会话固定版本，灰度环境用预览版本；破坏性变更保留旧版一个周期。
• 配额与限流：按用户、技能、工具三个维度限并发和调用量，查询默认限量。
• 审计：记录调用者、工具名、参数摘要、结果状态、耗时和 trace；敏感参数脱敏。
• 质量监控：工具看成功率与延迟，Skill 看任务成功率与人工接管率，知识看召回率与引用准确率。
• 下线演练：定期验证废弃标记、依赖通知和摘除流程，避免“永远没人敢下线的工具”。

边界

• 协议不是权限系统：MCP 只负责连接和暴露能力，真正的授权在后端系统和网关。
• Skill 不是越全越好：一个 Skill 覆盖太多场景会导致路由不准、权限过宽；按任务边界拆。
• 知识库不是越大越好：低质量文档会稀释检索结果，摄入前的清洗比检索调参更重要。
• 多路召回有成本：每路都要维护索引和监控，小规模场景两路足够，不必一开始上图谱。
• 社区能力要按供应链审查：来源可信不等于内容可信，版本更新也可能引入新的指令或依赖。

讲清楚

企业平台的能力供给要分三层：MCP 提供原子工具，Skill 提供业务流程，知识库提供受控事实。三层通过声明式依赖解耦，Skill 声明需要哪些工具和知识，编排层在运行时解析并做权限过滤。MCP 要有注册、评审、灰度、监控和下线；Skill 要有输入输出契约、执行类型、双审、版本和组合深度限制；知识要有分层、摄入质量、多路召回和检索前权限过滤。判断这套体系是否成熟，不看上架了多少能力，而看每个能力是否有 owner、有版本、有审计、能下线。

适用：2026 年企业级 Agent 能力供给实践；MCP 与 Skills 的具体规范以官方文档为准 | 初稿 2026-10