同一个搜索能力开成三种接口：API、MCP 与 Skill 的分工在哪
一、三种形态不是三个版本，是三次职责分配
据公开报道，有厂商把一个联网搜索能力同时以 API、MCP 与 Skill 三种方式对外开放，面向大模型与智能体调用。看新闻容易读成”多给了三种写法”，但把工程层摊开就清楚：同一个后端，五种职责在三条链上换了归属。
这五件事是能力发现（调用方怎么知道有这个东西、能做什么）、参数校验（谁保证传进来的东西合法）、鉴权（谁证明这次调用有资格）、计费归因（这一笔算在谁头上）、调用可观测（出了问题能不能定位到调用方与那次会话）。
判断一种接入形态适不适合生产，不看它新不新，看这五件事各自落在哪一层、落得是否可审计。落点不清楚的形态，接进去就是给自己埋一个说不清的故障源。
二、五件事在三条链上的归属
| 职责 | 直连 API | MCP 式能力暴露 | Skill 或插件式封装 |
|---|---|---|---|
| 能力发现 | 靠文档与 SDK，人读；集成成本最高但预期最明确 | 由宿主运行时向服务端取工具清单，模型自己决定用不用 | 由平台分发的能力包决定，用户看到的是功能而不是接口 |
| 参数校验 | 调用方拼参数，服务端做协议层校验，错在谁那里很清楚 | 参数由模型现场填，服务端必须做二次校验与取值白名单 | 参数被写进流程与提示里，错填往往在平台内部被吞掉 |
| 鉴权 | 密钥层，按调用方发放与吊销，归属唯一 | 归因要落到宿主与会话：谁的哪个运行时、哪一次会话 | 归因落到平台账户，真实发起人与执行环境常被合并成一层 |
| 计费归因 | 按调用次数或数据量，粒度可控 | 一次任务可能触发多次调用，要能按会话与任务串起来 | 按使用量还是按交付结果说不清，升级还会改单价语义 |
| 调用可观测 | 请求响应成对，失败语义明确，最容易定位 | 失败可能来自模型选错工具、参数不合理或服务端拒绝三类，要分开计 | 版本由平台推送，升级影响面难预判，问题往往表现为”昨天还好” |
表里最容易被低估的是第二行和最后一行。MCP 式暴露把参数交给模型，等于把一部分输入验证从”调用方的代码”挪到”服务端的防线”；这不是缺点，但它要求服务端把校验当作产品的一部分来做。Skill 式封装把版本升级交给自己，于是原本由调用方控制的变更节奏变成由供方控制，可观测与回滚的责任跟着一起搬过来了。
三、职责换了归属之后，具体多出哪些活
能力发现换了归属，多出的是描述质量这件事。工具清单里每写一句”这个能力适合做什么”，就等于下发一条策略；写得太宽，模型会在不该用的时候用；写得太窄，能力就躺在清单里没人调。所以描述文案要走变更评审，和接口字段的改动同一级。
参数校验换了归属，多出的是取值边界。模型填的参数有三种典型错误：格式不合法、语义不合法（比如时间区间填反）、以及看起来合法但明显越界（一次要极大范围的结果）。服务端要能分别给出可区分的错误语义，让宿主有机会重填而不是整体失败。同时要把可枚举的参数收敛成白名单——枚举项写在校验层，而不是只在文档里写一句。
鉴权与归因换了归属，多出的是身份链路。直连时一把密钥就是一个客户；经由宿主时，同一个客户可能落在多个运行时、多个会话里。审计记录至少要同时存三层：认证主体（哪个客户）、宿主实例（哪个运行时）、会话或任务标识（哪一次编排）。缺中间那层，客户问”这是我们哪个团队的调用”就没人能答。
可观测换了归属，多出的是一句判定：这次失败是模型选错、参数填错，还是能力本身不可用。三类失败的处置方不同——第一类和第二类要改描述与校验，第三类要走服务端故障流程。把它们混成一个错误码，运营侧就只能看总体成功率下降，谁也不知道该修什么。
四、并行开放时必须守的三条一致性
同一能力开三个入口后，一致性问题是必然会遇到的，只有三条能提前守住。
第一，配额是否合并计算。要在文档里写死：同一账户在三种入口下产生的调用，是共用一份额度还是各自独立。合并不算错，分开算也不算错，只有”没说”会出事——客户在自己的用量页面看到远低于上限，却因为另一个入口的消耗被限流。
第二，审计日志能否区分来源形态。每条记录带一个入口标识，且这个标识由服务端判定，不接受调用方自报。有了它，能力上线新入口后可以直接回答”新入口带来的失败率是原来那条链的几倍”这类问题；没有它，所有对比都要靠时间前后猜。
第三，校验规则只能有一份。三种形态共享同一套参数模式、同一份取值白名单、同一套错误语义，由同一个模块生成。校验各写一份的后果是：同一次任务从 API 走通、从工具入口走不通，客户合理地认为这是产品缺陷，而它其实是发布事故。
三条之外还有一条软约束：文档要分开写、口径要统一写。每种形态适合什么场景、不适合什么场景，讲清楚比讲全更重要。
五、企业自建能力开放层的最小设计
如果客户的诉求是”把我们的内部能力也这样开出去”，我们给的最小设计不需要多，五件东西。这五件在洹拓内部被当作能力开放类项目的评审基线，缺任何一件都不建议先开工具入口。
- 能力注册表：一条能力一行记录，含能力标识、入口形态、描述文案版本、负责团队、当前状态（灰度、正式、废弃），以及参数模式所在的校验模块标识。
- 动作级权限：不要停在”能不能读”，要停在”能不能做这件事”。搜索、导出、改写、外发四类动作分开授权，权限项与业务动作同名，方便与客户内控对照。
- 输入校验层：一个模块两处用（API 与工具入口），错误语义可区分，并对可疑取值有独立的限速策略。
- 按调用方记账：记录主体、宿主、会话三层标识；能按调用方出账单与限流，能按入口形态出失败率。
- 灰度与下线策略：每条能力要有生效范围与退出路径。下线的最小承诺是提前通知、保留一条替代链路、给出现有调用方的迁移窗口——“通知”这件事在形态变更后不能只发给人类开发者，因为模型的调用行为不会读公告。
五件里我们通常最晚建好、又最常被客户追责的是第一件的”当前状态”字段。它决定了一条能力在被谁、以什么成熟度被使用，也决定了下线时该通知谁。
六、能被模型调用不等于该被模型调用
最后一个判断线比任何架构选择都重要。技术上能挂进工具清单的能力很多，但三类能力我们默认不交给模型自主触发。
不可逆的动作。删除、注销、对外发布、发送给用户的通知，这些执行完就收不回来。它们的正确形态是模型准备变更集、人按下确认，或者模型只能起草不能投递。
涉及资金与合同的动作。付款、额度调整、报价、任何形式的对外承诺，一旦执行就产生义务。这一类即便客户催着要开，也要先把批准记录与责任字段设计完再开。
有对外效果且需要人的判断的动作。搜索结果本身也是这类：模型抓到的内容会原样进答复，公开信源的可靠性不由接口保证。这类可以交给模型调用，但要把来源与抓取时间一起返回，让上层有可引用的依据。
三条的共同判据是一句话：出错之后，能不能在不联系别人的情况下把状态改回来。改得回来，可以交给模型；改不回来，就要人在链路里。把这条线画清楚，三种形态就不再是三个待选项——它们是同一条能力在不同风险档位上的三种暴露方式，而风险档位由这条线决定，不由协议决定。