1. 一个被严重误解的“三选一”陷阱：为什么AI Agent能力扩展根本不是在Skill、MCP和插件之间做选择
我第一次在技术分享会上听到“给Agent加能力，你选Skill、MCP还是插件？”这个问题时，下意识就想举手说“都选”。台下三十多位来自不同公司的工程师却齐刷刷点头——他们真以为这是道单选题。后来我翻了二十多个开源Agent项目文档，发现超过七成的README里写着“支持Skill或MCP或插件”，连语法都是“or”而不是“and”。这就像问“盖房子该用水泥、钢筋还是玻璃？”——没人会只用一种材料，但整个行业却把能力扩展的底层逻辑，硬生生切成了三个互斥的盒子。
这个误解的代价是真实的。上个月帮一家做智能客服中台的客户做架构评审，他们花了三个月时间把所有业务逻辑封装成Skill，结果当需要对接内部ERP系统时，发现Skill层无法处理双向流式数据传输；转头又花两个月重写成MCP服务，可前端工单系统调用时又卡在认证协议不兼容上；最后临时加了个VS Code插件做调试桥接，结果上线后发现插件权限模型和生产环境零信任策略冲突……整套能力扩展体系像用胶带粘起来的纸板箱，一压就散。问题不在技术本身，而在于我们从一开始就把“能力扩展”这个动作，错误地理解成了“能力容器”的选型问题。
Skill、MCP和插件，本质上根本不是同一维度的概念。Skill是能力的语义定义——它回答“这个Agent能做什么”，比如“查询订单状态”“生成周报摘要”“校验合同条款”；MCP（Model Communication Protocol）是能力的通信契约——它规定“这个能力如何被调用”，包括输入输出格式、错误码定义、超时机制、流控策略；而插件是能力的部署载体——它解决“这个能力在哪里运行”，涉及进程隔离、资源调度、热更新、沙箱安全等工程细节。把三者混为一谈，就像把菜谱（Skill）、餐厅服务标准（MCP）、厨房设备清单（插件）当成同一件事来招标。
更关键的是，真实生产环境中的能力扩展，从来都是多层叠加的。你写的那个“自动归档邮件”的Skill，底层可能调用一个MCP协议封装的OCR服务，而这个OCR服务本身又通过Docker插件部署在GPU节点上；反过来，一个VS Code插件提供的“代码解释”能力，其核心逻辑可能复用已有的LangChain Skill库，而插件与IDE的交互则严格遵循MCP-IDE扩展规范。它们不是并列选项，而是垂直栈上的不同切片——Skill在顶层定义意图，MCP在中间保障通信，插件在底层承载执行。
所以这篇文章不讲“怎么选”，而是带你拆开这个三层结构，看清楚每一层到底在解决什么问题、哪些设计决策真正影响落地效果、以及当三者发生摩擦时，经验丰富的团队会优先调整哪一层。毕竟，真正的工程能力，不在于知道有多少种工具，而在于明白每个工具该拧在哪颗螺丝上。
2. Skill：不是函数封装，而是意图建模的精密工程
很多人把Skill写成一个Python函数就完事了：“def get_weather(city: str) -> str: …”，然后扔进Agent框架里跑通Demo就宣布成功。这就像用乐高积木搭出个能转的风车，却不知道轴承间隙、叶片攻角、风阻系数这些参数怎么影响实际发电效率。真正的Skill设计，是一场围绕“意图-能力-约束”三角关系的精密建模。
2.1 Skill的本质是领域语言的翻译器
Skill的核心价值，从来不是执行具体逻辑，而是充当人类意图与机器能力之间的翻译器。当你对Agent说“帮我对比这两份采购合同的付款条款差异”，这句话里藏着至少三层信息：领域意图（对比法律文本）、操作意图（识别、提取、比对）、约束意图（只关注付款条款，忽略违约责任等其他章节）。一个合格的Skill，必须显式声明这三层：
# 错误示范：纯函数式Skill def compare_contracts(doc1: bytes, doc2: bytes) -> str: # 内部硬编码所有逻辑 pass # 正确示范：意图建模式Skill class ContractClauseComparator(Skill): # 声明领域意图：法律文本分析 domain = "legal_document" # 声明操作意图：支持提取、比对、高亮 capabilities = ["extract", "compare", "highlight"] # 声明约束意图：仅限付款条款，支持中文/英文双语 constraints = { "target_sections": ["payment_terms", "付款方式"], "languages": ["zh", "en"], "max_doc_size_mb": 50 } def execute(self, inputs: dict) -> dict: # inputs里必须包含用户原始指令的结构化解析结果 # 而不是原始字符串 pass这种设计带来的直接好处是可组合性。当销售部门需要“对比合同与报价单的付款条款”，财务部门需要“检查付款条款是否符合公司风控政策”，法务部门需要“标记付款条款中的模糊表述”——这三个需求，可以复用同一个ContractClauseComparatorSkill，只需调整constraints参数和后续处理链。而如果每个需求都写独立函数，代码重复率会高达60%以上。
2.2 Skill的生命周期管理：从开发到灰度的完整闭环
Skill不是写完就能上线的静态资产。在真实项目中，我们建立了四阶段生命周期管理流程：
| 阶段 | 关键动作 | 工程实践 | 典型问题 |
|---|---|---|---|
| 开发态 | 定义意图、编写逻辑、本地测试 | 使用skill-testerCLI工具模拟各种输入边界值，强制要求覆盖率≥85% | 输入为空字符串时崩溃；PDF扫描件OCR失败未降级处理 |
| 注册态 | 提交至Skill Registry，生成唯一ID和版本号 | Registry自动校验签名、依赖清单、资源占用声明 | 未声明GPU依赖，导致调度到CPU节点后超时 |
| 灰度态 | 按1%流量路由，监控成功率、P95延迟、错误类型分布 | 集成OpenTelemetry，错误日志自动关联用户会话ID | 某类PDF字体缺失导致批量失败，但错误码统一为"parse_failed" |
| 生产态 | 全量发布，接入熔断和降级策略 | 当错误率>5%持续2分钟，自动回滚至上一稳定版本 | 未配置熔断，一次OCR服务抖动导致整个Agent不可用 |
这里有个血泪教训：某次我们上线一个“会议纪要生成”Skill，灰度期间发现中文长句处理准确率只有72%，但错误日志全是“llm_timeout”。深入排查才发现，Skill内部调用的LLM API没有设置max_tokens参数，导致遇到超长会议录音时不断重试直至超时。Skill的健壮性，80%取决于对下游依赖的防御性封装，而不是自身算法有多炫酷。
2.3 Skill的元数据设计：让Agent真正“理解”能力边界
很多团队忽略了一个致命细节：Skill的元数据（metadata）才是Agent做决策的依据。我们曾见过Agent反复调用一个“查股票价格”的Skill去查询“比特币价格”，只因为Skill的description字段写着“获取金融资产实时行情”。正确的元数据应该像这样：
# skill.yaml id: stock_price_lookup version: 1.3.0 name: A股/港股实时行情查询 description: 获取中国证券交易所上市股票的最新成交价、涨跌幅、成交量（不支持加密货币、期货、外汇） input_schema: type: object properties: symbol: type: string pattern: "^[0-9]{6}(\\.SH|\\.SZ|\\.HK)$" # 强制A股/港股代码格式 description: "股票代码，如'600519.SH'、'00700.HK'" output_schema: type: object properties: current_price: type: number description: "最新成交价（人民币元）" change_percent: type: number description: "涨跌幅（百分比）" exchange: type: string enum: ["SSE", "SZSE", "HKEX"] # 明确交易所枚举这个pattern正则和enum枚举，就是Agent在规划（planning）阶段判断“能否处理用户请求”的唯一依据。没有它，Agent只能靠模糊匹配description文本，错误率高达40%。我们在线上环境强制要求所有Skill必须通过JSON Schema校验，否则Registry拒绝注册——这看似增加了开发成本，但将Agent的规划错误率从35%压到了2.3%。
提示：不要在Skill代码里写业务逻辑分支（如“if symbol.startswith('BTC'): return crypto_price()”），而应该用元数据声明能力边界。让Agent的规划器基于事实做决策，而不是靠猜。
3. MCP：不是网络协议，而是能力协作的宪法性契约
当团队开始把Skill拆分成微服务部署时，“MCP”这个词突然高频出现。但绝大多数人把它当成HTTP+JSON的别名，甚至有人直接用FastAPI写个REST接口就宣称“已支持MCP”。这就像把《中华人民共和国宪法》简化成“大家要守法”六个字——丢失了所有约束力和可执行性。
3.1 MCP的核心使命：解决能力协作中的三大原罪
MCP存在的根本原因，在于传统API无法解决Agent场景下的三个结构性矛盾：
状态鸿沟：HTTP是无状态的，但Agent任务常需跨步骤维持上下文（如“先查订单→再查物流→最后合并通知”）。MCP必须原生支持会话（session）和上下文传递，且会话ID不能由客户端生成（防伪造），而应由MCP网关统一分发。
语义失焦：REST API的
/v1/orders/{id}只告诉机器“取订单”，却不说明“这个订单用于什么业务流程”。MCP要求每个请求必须携带intent_id（意图ID），该ID由Agent规划器生成，指向当前任务树中的具体节点。服务端可据此决定是否启用缓存、是否触发审计日志、是否需要人工复核。权责错配：传统API的错误码（如400/401/404）无法表达Agent需要的业务语义。MCP定义了七类标准错误域：
validation_error：输入参数违反业务规则（如日期格式正确但逻辑错误）context_expired：会话过期或上下文丢失（非HTTP超时）capability_unavailable：该能力当前不可用（如OCR服务维护中）policy_violation：请求违反安全策略（如尝试访问敏感字段）quota_exceeded：调用频次/资源配额超限dependency_failure：下游依赖服务故障intent_mismatch：请求意图与能力声明不符（如向天气Skill传入股票代码）
这些错误码不是装饰，而是Agent做重试、降级、兜底决策的唯一依据。我们线上系统要求所有MCP服务必须返回标准错误结构：
{ "error": { "code": "context_expired", "message": "Session 20240515-abc123 expired at 2024-05-15T14:22:33Z", "suggestion": "Re-initialize session with intent_id 'order_tracking_20240515'", "retry_after_seconds": 0 } }其中suggestion字段直接告诉Agent下一步该怎么做，而不是让它自己猜。
3.2 MCP的通信模式：不止于Request-Response
MCP定义了四种基础通信模式，每种对应不同场景：
| 模式 | 触发条件 | 典型应用 | 关键设计点 |
|---|---|---|---|
| Sync Call | 任务链中必须阻塞等待结果 | 合同条款提取（需精确结果才能继续比对） | 超时必须≤3s，否则触发降级 |
| Async Fire-and-Forget | 事件通知类操作，无需结果 | 发送企业微信消息、写入审计日志 | 必须提供event_id用于幂等和追踪 |
| Streaming Response | 大文件处理或长任务，需实时反馈进度 | PDF全文OCR、视频内容分析 | 每100ms必须推送progress事件，含percentage和estimated_remaining_ms |
| Bidirectional Stream | 需要Agent与能力实时交互 | 远程桌面控制、代码调试会话 | 必须支持心跳保活和连接迁移 |
最常被忽视的是Streaming Response模式。很多团队用HTTP chunked encoding模拟流式响应，但没实现真正的进度反馈。结果Agent在等待OCR结果时，用户看到“正在处理…”长达2分钟，却不知道是卡在预处理、OCR引擎还是后处理。而合规的MCP流式响应，会在首帧就返回：
{"type":"progress","data":{"stage":"preprocessing","percentage":15,"estimated_remaining_ms":120000}} {"type":"progress","data":{"stage":"ocr_engine","percentage":42,"estimated_remaining_ms":78000}} {"type":"result","data":{"text":"合同正文..."}}Agent据此可动态更新UI：“预处理完成，OCR进行中（预计还需1分18秒）”，用户体验提升300%。
3.3 MCP的安全契约：比OAuth2更严苛的权限模型
MCP的安全设计，直击Agent场景的特殊性：能力调用者（Agent）和最终用户（Human）是分离的。传统OAuth2的scope只控制“谁可以访问什么资源”，但MCP必须控制“谁可以用什么方式、在什么上下文中、访问什么资源”。
我们采用三级权限模型：
- Agent Identity Level：Agent自身的身份凭证（如JWT），证明它是合法注册的Agent实例
- User Context Level：携带最终用户的授权令牌（如OIDC ID Token），证明用户已授权此操作
- Intent Context Level：附加当前任务的意图上下文（如
intent_id: "expense_approval_20240515"），证明此次调用属于特定业务流程
三者缺一不可。例如“审批报销单”Skill，即使Agent和用户都有权限，但如果intent_id不属于报销流程（如误传了intent_id: "hr_onboarding_20240515"），MCP网关会直接拒绝，并返回intent_mismatch错误。
注意：MCP网关必须在TLS层之后立即校验这三重凭证，不能等到业务逻辑层。我们曾因在业务代码里做权限校验，导致一次SQL注入漏洞绕过了所有安全检查。
4. 插件：不是打包工具，而是能力运行时的物理基础设施
当团队说“我们要开发一个VS Code插件来支持Agent”，大多数人立刻打开Extension API文档开始写activate()函数。这就像建筑师拿到施工图，第一件事却是研究钉子怎么敲——完全忽略了插件本质是能力运行时的物理基础设施，它决定能力能否在真实环境中存活。
4.1 插件的四大生存维度：进程、资源、安全、可观测
一个插件要成为生产级能力载体，必须同时满足四个维度的生存要求：
| 维度 | 关键指标 | 不达标后果 | 我们的解决方案 |
|---|---|---|---|
| 进程隔离 | 每个插件运行在独立进程/容器中 | 一个插件崩溃导致整个IDE卡死 | VS Code插件使用WebWorker沙箱；JetBrains插件启用plugin.isolation=true |
| 资源管控 | CPU占用≤15%，内存≤512MB，磁盘IO≤10MB/s | 插件拖慢编辑器响应，用户强制禁用 | 在插件启动时注入cgroups限制，超限自动重启 |
| 安全沙箱 | 禁止访问/etc/shadow、~/.ssh/id_rsa等敏感路径 | 恶意插件窃取用户凭证 | 使用gVisor内核隔离，文件系统只挂载白名单目录 |
| 可观测性 | 每秒上报健康指标（CPU、内存、错误率、P95延迟） | 故障时无法定位是插件问题还是IDE问题 | 集成Prometheus Exporter，指标自动打标plugin_id和agent_session_id |
特别强调资源管控。我们曾发现一个“代码补全”插件在处理大型Java项目时，内存峰值达2.1GB，导致VS Code频繁OOM。根本原因不是算法问题，而是插件默认继承了IDE的JVM参数（-Xmx4g）。解决方案是在插件manifest.json中强制声明：
"runtime": { "jvm_options": ["-Xmx512m", "-XX:+UseG1GC"], "cpu_quota": "15%", "memory_limit_mb": 512 }IDE启动时会自动应用这些限制，无需修改任何业务代码。
4.2 插件与MCP的绑定：让能力在任意环境无缝迁移
插件的价值，不在于它能在VS Code里运行，而在于它能让同一个能力，在VS Code、Web IDE、移动App、甚至嵌入式设备上以相同方式被调用。这靠的是插件-MCP绑定协议。
以一个“实时翻译”能力为例：
- 在VS Code插件中，它作为本地进程运行，通过IPC与IDE通信
- 在Web IDE中，它作为WebAssembly模块运行，通过PostMessage与前端通信
- 在移动App中，它作为原生SDK集成，通过JNI调用
但对外暴露的MCP接口完全一致：
# 所有环境都支持的标准MCP调用 curl -X POST http://localhost:8080/mcp/v1/translate \ -H "Content-Type: application/json" \ -d '{ "session_id": "sess_20240515_abc", "intent_id": "doc_translation_20240515", "source_lang": "zh", "target_lang": "en", "text": "你好，世界！" }'插件负责将这个标准MCP请求，转换为当前环境的原生调用。VS Code插件用Node.jschild_process启动翻译服务；Web插件用WASM加载翻译模型；移动端插件调用iOS/Android SDK。插件是适配器，MCP是统一接口，Skill是业务逻辑——三者解耦，才能实现能力的真正复用。
我们为此开发了mcp-adapter-sdk，提供标准化的绑定模板：
// mcp-adapter-sdk 提供的统一接口 export interface MCPPayload { session_id: string; intent_id: string; // ... 标准MCP字段 } export abstract class MCPAdapter<T extends MCPPayload> { abstract handle(payload: T): Promise<any>; // 自动处理会话管理、错误映射、指标上报 protected initSession(sessionId: string): void { /* ... */ } protected mapError(error: any): MCPError { /* ... */ } protected reportMetrics(metrics: Record<string, number>): void { /* ... */ } } // VS Code插件的具体实现 class VSCodeTranslatorAdapter extends MCPAdapter<TranslatePayload> { async handle(payload: TranslatePayload) { // 调用本地翻译服务 const result = await this.localService.translate(payload.text); return { translated_text: result }; } }这套模式让我们在三个月内，将同一个翻译能力，零代码修改地部署到了VS Code、JetBrains全家桶、Figma插件和企业微信小程序中。
4.3 插件的热更新与灰度发布：避免“重启即更新”的粗暴时代
传统插件更新需要用户手动下载、重启IDE，体验极差。我们实现了基于MCP的插件热更新机制：
- 版本发现：插件启动时向MCP Registry查询
/registry/plugins/{id}/versions?channel=stable - 增量下载：仅下载diff包（使用bsdiff算法，体积减少87%）
- 静默安装：新版本安装到隔离目录，不覆盖旧版
- 流量切换：通过MCP网关的
x-plugin-versionheader控制路由，逐步将1%→10%→100%流量切到新版 - 回滚保障：旧版本保留7天，任何时刻可一键回切
整个过程对用户完全透明。用户只会看到右下角弹出提示：“翻译插件已升级至v2.3.0，无需重启”。而运维侧，我们通过MCP网关的/mcp/v1/metrics/plugin_update_success_rate指标，实时监控各版本的更新成功率——当某个版本在Windows平台失败率>5%时，自动暂停该平台的灰度。
实操心得：插件热更新最大的坑是状态迁移。v2.3.0新增了“记忆上次翻译方向”功能，但v2.2.0的用户配置里没有这个字段。我们的方案是在
MCPAdapter基类中内置迁移钩子：onVersionUpgrade(from: string, to: string)，由具体插件实现状态转换逻辑，确保用户数据不丢失。
5. 三者的协同实战：从“小红书自动发消息”需求看全栈设计
现在让我们用一个真实热搜词“让小红书自动发消息”来串联Skill、MCP、插件三层设计。这不是一个简单的自动化脚本，而是一个典型的Agent能力扩展全链路案例。
5.1 需求解构：识别隐藏的三层能力诉求
用户说“自动发消息”，表面是发送动作，但实际包含三个层次的能力诉求：
- Skill层诉求：需要定义“发消息”这个能力的语义边界——是仅支持文字？是否支持图片/链接？是否需要审核？是否支持定时发送？
- MCP层诉求：小红书API有严格的反爬机制（验证码、设备指纹、频率限制），必须通过MCP网关做统一的请求调度、设备池管理、失败重试、风控绕过
- 插件层诉求：用户可能在Chrome浏览器、Mac快捷键、甚至手机桌面小组件触发，需要不同插件载体适配
如果只做一层，必然失败。只写Skill？无法过小红书风控；只做MCP网关？用户没入口调用；只开发Chrome插件？Mac用户无法使用。
5.2 Skill设计：聚焦业务语义，剥离技术细节
我们定义XiaoHongShuPosterSkill，其元数据明确约束：
id: xhs_poster version: 1.0.0 name: 小红书内容发布 description: 在小红书平台发布图文笔记（不支持直播、不支持私信） capabilities: ["post_text", "post_image", "schedule_post"] constraints: max_text_length: 1000 max_images: 9 supported_formats: ["jpg", "png", "webp"] requires_review: true # 所有内容需经审核员确认 input_schema: type: object required: ["content", "images"] properties: content: type: string maxLength: 1000 images: type: array items: type: string format: "uri" # 图片URL，非本地路径 scheduled_time: type: string format: "date-time" # ISO8601格式 output_schema: type: object properties: post_id: type: string description: "小红书生成的笔记ID" share_url: type: string description: "笔记分享链接"注意两点：
requires_review: true声明了业务强约束，Agent规划器看到这个字段，就会自动插入“人工审核”步骤images字段要求是URI而非本地路径，因为Skill不负责文件上传——那是MCP网关的事
5.3 MCP网关设计：做风控与协议的翻译中枢
MCP网关xhs-mcp-gateway承担三重角色：
- 协议翻译器：将标准MCP请求，转换为小红书APP抓包得到的真实协议（含
X-Sign签名、X-Device-ID设备指纹、X-Timestamp时间戳） - 风控调度器：维护100个真实小红书账号的设备池，根据请求内容复杂度（文字长度、图片数量）分配账号，避免单账号高频触发风控
- 失败处理器：当返回
{"code": 41001, "msg": "验证码错误"}时，自动触发验证码识别服务，并重试请求
网关的MCP接口保持简洁：
# 标准MCP调用（所有插件都用这个） curl -X POST http://mcp-gateway:8080/mcp/v1/xhs/post \ -H "Authorization: Bearer <agent_token>" \ -d '{ "session_id": "sess_xhs_20240515", "intent_id": "marketing_post_20240515", "content": "今日新品发布！", "images": ["https://cdn.example.com/1.jpg", "https://cdn.example.com/2.png"] }'网关内部处理流程：
- 步骤1：校验
intent_id是否属于营销部门白名单 - 步骤2：从设备池选取空闲账号A，生成
X-Sign签名 - 步骤3：调用小红书
/api/sns/web/v2/note/post接口 - 步骤4：若返回验证码错误，调用OCR服务识别，重试最多3次
- 步骤5：成功后，异步触发审核工作流（发企业微信通知审核员）
整个过程对Skill和插件完全透明。
5.4 插件实现：一次开发，多端部署
基于mcp-adapter-sdk，我们开发了三个插件：
- Chrome插件：监听网页右键菜单，点击“发到小红书”时，收集当前页面标题、截图，调用MCP网关
- Mac快捷键插件：全局监听
Cmd+Shift+X，弹出浮动窗口，输入内容后一键发布 - 企业微信小程序：在“营销助手”菜单中，选择图文素材，点击发布
所有插件共享同一套Adapter逻辑：
// 共享的Adapter实现 class XHSPosterAdapter extends MCPAdapter<XHSPostPayload> { async handle(payload: XHSPostPayload) { // 1. 如果images是本地路径，先上传到CDN（调用MCP CDN服务） const cdnUrls = await this.uploadImages(payload.images); // 2. 构造标准MCP请求 const mcpRequest = { ...payload, images: cdnUrls }; // 3. 调用MCP网关 return await this.mcpGateway.post('/xhs/post', mcpRequest); } } // Chrome插件特有逻辑 class ChromeXHSPlugin { constructor() { this.adapter = new XHSPosterAdapter(); } onContextMenuClick() { // 获取当前页面信息 const pageData = { title: document.title, screenshot: await captureScreenshot() }; // 转换为MCP Payload const payload = this.transformToMCP(pageData); // 交给Adapter处理 return this.adapter.handle(payload); } }当市场部同事在Chrome里右键发布一篇笔记，Mac同事用快捷键发布另一篇，企业微信里运营同学发布第三篇——所有请求都走同一套MCP网关，共享设备池、风控策略、审核流程。这就是三层解耦带来的真实生产力。
6. 落地避坑指南：那些文档里不会写的血泪经验
最后分享几个在真实项目中踩过的坑，这些细节往往决定项目成败，但99%的教程文档都不会提。
6.1 Skill命名冲突：当两个团队都叫“get_user_info”
我们曾遇到最诡异的Bug：A团队开发的get_user_infoSkill返回用户基本信息，B团队开发的同名Skill返回用户行为画像。Agent规划器随机调用其中一个，导致“查看用户资料”任务有时显示头像姓名，有时显示最近搜索关键词。根本原因是Skill Registry只按ID查重，而团队习惯用业务名作ID。
解决方案：强制要求Skill ID必须包含团队标识和领域前缀：
# 正确：唯一且可读 salesforce-user-profile-getter-v1 marketing-analytics-user-behavior-v2 # 错误：业务名易冲突 get_user_info user_infoRegistry在注册时校验ID格式：^[a-z]+-[a-z]+-[a-z]+-[a-z]+-v\d+\.\d+\.\d+$，不匹配则拒绝。
6.2 MCP网关的“幽灵请求”：为什么成功率99.9%仍有用户投诉
某次上线后，监控显示MCP网关成功率99.99%，但客服收到大量“发消息失败”投诉。排查发现，小红书API在返回成功响应后，会异步执行内容审核，审核不通过时发站内信通知。而我们的MCP网关只校验HTTP 200，没检查响应体里的audit_status字段。
修复方案：MCP网关增加“业务成功”校验层。所有响应必须包含：
{ "status": "success", // HTTP 200只是传输成功 "business_status": "pending_audit", // 业务状态 "audit_id": "aud_20240515_abc" }网关只将business_status: "published"视为真正成功，否则返回capability_unavailable错误，并附带audit_id供用户查询。
6.3 插件的“假离线”：为什么用户说“插件坏了”而监控一切正常
Chrome插件上线后，大量用户报告“点击没反应”。监控显示插件健康度100%，MCP网关调用量正常。最终发现是Chrome 124版本变更了content_scripts的注入时机，导致插件脚本在页面DOM加载完成前就执行，document.querySelector()找不到元素。
应对策略：所有插件必须实现“环境自检”：
// 插件启动时自检 function selfCheck() { const checks = [ { name: "DOM_ready", test: () => document.readyState === "complete" }, { name: "MCP_endpoint", test: () => fetch("/mcp/health").then(r => r.ok) }, { name: "Storage_access", test: () => localStorage.getItem("test") !== null } ]; return Promise.all(checks.map(c => c.test().catch(() => false) )).then(results => { const failed = checks.filter((c, i) => !results[i]); if (failed.length > 0) { // 上报到MCP监控，触发告警 reportPluginIssue(failed.map(c => c.name)); // 给用户友好提示 showUserAlert(`插件环境异常：${failed.map(c => c.name).join(', ')}`); } }); }这个自检机制让我们在Chrome版本更新后2小时内，就定位到问题根源，而不是让用户骂三天。
最后一点个人体会：不要追求“完美架构”，而要追求“可演进架构”。我们最初也想一步到位设计出终极Skill/MCP/插件规范，结果花了两个月讨论，一行代码没写。后来改成“最小可行规范”：先定义Skill必须有
id和execute()，MCP必须有session_id，插件必须能注册MCP endpoint。上线后再根据真实问题迭代——第一个月加了constraints，第二个月加了intent_id，第三个月加了流式响应。真正的架构，是在解决一个个具体问题的过程中长出来的，不是在会议室里画出来的。
