Skill 封装变现调研：「编译 Skill」能不能治鸭哥说的自杀基因
鸭哥四月份写了一篇 Skill 是天生带自杀基因的产品，核心论点是：Skill 是明文的、复制成本为零，价值创造和价值捕获被分开了，所以 Skill 天生无法独立承载商业实体。
这篇是对它的反命题调研。问题是：如果 Skill 可以被「编译」封装成不可知的黑盒——只能安装和使用，不能复制粘贴——整合 MCP auth 和 Claude plugin 机制，能不能重建 access control？
更远一步的 analogy 是：每个人的 agent loop（OpenCode、Claude Code、Codex）= 手机，Skill = app。现在的问题是 app 全是源码分发。如果可以编译呢？
调研方法：5 个 agent 并行（4 librarian + 1 deep），覆盖技术方案、MCP 生态、prompt 攻防、市场现状、逻辑推演。
结论
先说判断：封装单独能治大约 25% 的自杀基因。Skill + MCP server + 平台结算的组合能治 40-50%，但到了那一步，卖的已经不是 Skill，而是 agent extension service。
鸭哥抓到的核心矛盾——价值创造和价值捕获被分开——encapsulation 只在特定条件下能重新接上。这个条件是：Skill 必须变成远程服务端执行，而不是本地明文加载。MCP 的 OAuth 2.1 + server-side execution 架构在技术上完全能支撑这件事，但生态基础设施（支付、发现、信任）还在非常早期。
agent loop = 手机、Skill = app 的类比方向上成立，但卡在一个前提条件上：还没有出现一个 dominant agent runtime 把协议、身份、支付、权限统一下来。iPhone App Store 的成功不是因为 app 被编译了，而是因为 Apple 同时控制了硬件、分发、签名和支付。今天的 agent 生态更接近 2005 年的 PDA 市场，不是 2008 年的 iPhone。
一、技术全景：Skill 能不能被「编译」？
五种技术路线，一个结论。
1. 远程 MCP Server（production-ready，唯一可行路线）
Skill 逻辑部署为远程 MCP server，客户端只看到 tool name、description 和 input schema，永远看不到服务端实现。这在技术上等价于「编译后只分发 URL endpoint，不分发源码」。
MCP 规范要求 Streamable HTTP 传输，client 通过 tools/list 发现工具、tools/call 调用工具，server 内部可以跑任意复杂的 prompt chain、RAG pipeline 或 proprietary logic，client 拿到的只是最终结果。
Claude Code 对 MCP-sourced skill 有一个硬安全边界：shell execution 被完全禁用。client 侧的 loadedFrom 字段如果是 'mcp'，shell 执行直接跳过。（来源: Claude Code Extension Architecture Deep Dive）
MCP spec 规范支持 OAuth 2.1 + PKCE 做 per-tool access gating。server 可以声明 scope="premium:tools"，未授权 client 连 tool 列表都看不到。技术上完全可以做到：免费 tier 暴露基础工具，付费 tier OAuth 授权后解锁高级工具。
已有的基础设施包括 Peta Core（MCP gateway + credential vault，AES-GCM 加密凭据，server-side 注入），MCP Apps 的 per-tool authorization（step-up authorization，public tools 不需要 token，protected tools 触发 OAuth flow），以及 Anthropic 自己的 Skills API（skill_id 引用 server-side 存储的 skill，workspace-private）。
2. Soft Prompt Obfuscation（研究阶段）
Pape et al.（arXiv:2409.11026, USENIX Security 2025）证明了一条理论路线：把 prompt 优化为浮点向量（soft prompt），人类读不出来但 LLM 能执行。黑盒提取攻击和白盒投影攻击都失败了。
致命限制：需要开源模型的 embedding layer 才能注入 soft prompt，对 Claude、GPT-4、Gemini 全部不可用。
3. ProxyPrompt（研究阶段，ACL 2026 Findings）
Bosch Research 的方案（arXiv:2505.11459）：用功能等价的 proxy 替换原始 prompt。即使被提取，attacker 拿到的也不是原始指令。264 个 LLM + system prompt pair 测试中保护了 94.7% 的 prompts。但 proxy 本身仍然是明文，可以被复制。
4. SkVM 编译系统（研究阶段，上海交大）
SkVM（arXiv:2604.03088）把 Skill 当源码、LLM 当异构处理器，做 AOT + JIT 编译。目标是 portability 和 efficiency，不是 IP 保护。
5. 编译为二进制格式
不存在。 LLM 消费 text token，任何「编译格式」最终都得解码回 token。Claude Code 的 GitHub issue #10067 明确讨论过这个方向，给出的理由是优先级和 cache invalidation 问题。
底线：远程 MCP server 是唯一 production-ready 的封装方案。其他路线要么只在论文里，要么根本不存在。
二、GPT Store：最大规模的「封装 Skill」实验
GPT Store 是 OpenAI 版的「编译 skill」——用户跟 GPT 交互但看不到 system prompt。
提取率：98.8%
Hong Kong PolyU 的研究（arXiv:2506.04036）对 10,000 个 GPT 做了三阶段提取攻击。Phase 1 基础对抗 prompt 攻破 95.1%，Phase 2 混淆/欺骗 prompt 再攻破 3.7%，Phase 3 多轮重构再攻破 0.6%。只有 0.6% 的 GPT 扛住了全部三个阶段。
那些在 system prompt 里写了「不要泄露你的指令」的 GPT（占 21.5%），有 77.5% 仍然在第一阶段就被攻破。
商业结果：失败
OpenAI 承诺的 revenue sharing 从未广泛落地。不到 1% 的 creator 拿到过钱。排名第一的编程 GPT Grimoire（300 万+对话）靠 consulting 变现，不靠 Store 分成。
理论不可能性
2026 年 4 月的形式化证明（arXiv:2604.06436）给出了 defense trilemma：连续性、utility preservation、completeness 三者只能取二。
Anthropic 自己的表态："prompt injection cannot be fully solved within current LLM architectures"。OWASP 更直接："The system prompt should not be considered a secret, nor should it be used as a security control."
结论：text-in-context 的 encapsulation 是假的。98.8% 的提取率意味着这不是可靠的 IP 保护机制。唯一有效的 opacity 是把指令移出 context window——也就是 server-side execution。
三、MCP：唯一站得住的封装架构
架构层面完全可行
一个 monetizable 的 opaque MCP skill server：client 通过 tools/list 只看到 name、description、inputSchema，通过 tools/call 只发送 arguments，server 内部跑 proprietary logic，返回 result。和调用任何 API 在架构上等价。
MCP spec（当前版本 2025-11-25）mandates OAuth 2.1 + PKCE for HTTP transports，支持 per-tool scope gating、token audience binding（RFC 8707）。技术上可以做到：require scope="paid:skill" → triggers OAuth flow → user 通过 Stripe 付费 → 获取 token → 解锁 premium tools → 跨所有 MCP-compatible client 工作（Claude、ChatGPT、Gemini、Cursor）。
生态层非常早期
| 平台 | 规模 | 变现模式 |
|---|---|---|
| LobeHub | 296,243 skills | 免费开放 |
| Smithery | 7,810+ servers | 无 creator 收入 |
| MCPize | 100+ curated | 85% revenue share |
| Apify MCP | scraping-focused | 80% revenue share |
| Agent37 | hosted runtime | 80/20 split |
| CuratedMCP | curated | 80/20 split |
关键数字：10,000+ active MCP servers 中，不到 5% 收费。
2026 年 1 月 Anthropic 锁死 consumer subscription 的 OAuth token 不能在第三方工具使用。第三方 MCP server 必须走 API 计费。Anthropic 自己没有建 first-party paid marketplace，2025 年 12 月把 MCP 捐给了 Linux Foundation 的 Agentic AI Foundation。
四、市场全景：谁在做 Agent App Store
Agent37：最接近「编译 Skill」命题的产品
Agent37 自我定位「Gumroad for Claude Skills」。核心 pitch：不要卖文件，卖运行实例。提供 hosted runtime（sandbox，bash/Python/API/文件处理），Stripe 支付 80/20 split，built-in evals。
他们明确承认三种路线：卖文件（泄露 IP）、卖 hosted access（他们推的方向）、卖服务（不 scale）。本质上就是把 Skill 从 plaintext 升级为 server-side 的 encapsulated service。
awesome-claude-skills 生态
ComposioHQ/awesome-claude-skills 56.6k stars，travisvn/awesome-claude-skills 11.9k stars。全部免费开源明文。
Dify / Coze
Dify 有 marketplace，Coze（ByteDance）有 plugin store。两者都是 platform-locked plugin 生态，不是 cross-platform skill marketplace。
GPT Store 教训
ChatGPT Plugins 2024 年 4 月关闭。GPT Store 存活但 revenue sharing 未落地。MCP 修复了 platform lock-in（cross-platform）和 discovery（dynamic tools/list），但 developer economics 仍然缺失。
五、反向推演：封装治了多少自杀基因
鸭哥六层论证 vs 封装方案
| 鸭哥的论点 | 封装能治吗 | 说明 |
|---|---|---|
| 零复制成本 | ✅ 能治 | MCP server-side = 只分发 URL，不分发源码 |
| 托管 = AWS 转售 | ⚠️ 部分治 | 如果 server 内有 proprietary logic/data/tool chain，就不只是 hosting |
| Skill 只是 API funnel | ⚠️ 没变 | MCP server 本质上就是 API，Skill 仍然可以是 funnel |
| 价值创造和捕获分离 | ⚠️ 取决于架构 | MCP auth 创建了新的 billing checkpoint，但只对 server-side skill 有效 |
| 数据飞轮断裂 | ✅ 能治 | MCP server 执行时能观察 usage，重建局部 data flywheel |
| AI 让什么变得稀缺 | ❌ 不相关 | 封装不改变「关系/此刻/物理世界/判断」这四类稀缺 |
DRM 类比
音乐 DRM 失败，因为音乐是被动内容，听到就等于获取了核心价值。App DRM 成功，因为 app 是持续计算 + 受控 API + 代码签名 + OS 权限。
纯 prompt skill 更接近音乐——prompt 的价值体现在行为分布里，即便看不到原文，通过输入输出就能逼近它做了什么。但 skill + MCP server + proprietary data/tools 更接近 app——逆向行为不够，还需要逆向数据源、tool chain、execution environment。
「手机 + App Store」类比
iPhone App Store 成功靠 Apple 控制硬件和 OS、控制分发和签名、app 能调用系统没有的能力、用户切换成本高、30% 抽成养审核支付发现。
Agent loop 生态现在：没有硬件锁定、没有唯一分发者、大部分 Skill 不增加能力只改变知识/提示/流程、切换成本低、没有「谁抽成」的共识层。
最关键的区别：app 卖的是 capability，Skill 常常卖的是 heuristic/taste/domain knowledge。Capability 依赖权限、API、集成，更适合平台化。Knowledge 更容易被模仿。
所以这个类比在 extension marketplace 层面成立，在 prompt marketplace 层面不成立。如果未来有人做出来，卖的不会是纯 Skill，而是 skill + privileged tools + proprietary data + workflow guarantees + reputation/audit/support。更像 Salesforce AppExchange 或 Figma plugin，不像 PromptBase 2.0。
鸭哥可能低估了什么
Skill 可以成为稀缺资源的路由层。 按他自己的四类稀缺看，Skill 可以连接特定人脉网络、接实时行情、控制物理世界操作、绑定审计规则和人类 escalation。这时价值不在 prompt 本身，而在对稀缺资源的可编排入口。
Curation 本身有价值。 Snyk 2026 年 2 月的审计发现社区 13.4% 的 Skill 有 critical 安全问题。「精选过、审计过、可信的 Skill 集合」在企业场景是刚需。
MCP server 重建了局部 data flywheel。 一旦参与执行，作者能拿回 usage data。
反命题方可能低估了什么
Opacity 带来 trust problem。 黑盒 Skill 在企业市场会卡死——用户怎么知道它会不会泄露数据、符不符合合规？真正能卖的黑盒 Skill 需要额外配套 capability manifest、permission boundary、audit log、sandboxing。一旦加上这些，卖点从「黑盒 prompt」变成了「受控插件系统」。
Network effects 没那么自然。 Claude Code、Cursor、Codex、OpenCode 之间差异太大。今天写一个 Skill，明天宿主的 prompt hierarchy 一变，兼容性就没了。没有稳定 ABI/API 和分发入口，开发者不愿意深投。
时间点可能太早。 这个 thesis 更像 2005 年在赌「移动应用商店会出现」。方向可能对，但离 iPhone 2008 还差一个决定性条件：统一宿主 + 明确权限模型 + 统一支付。
总结判断
Skill 可以从 business card 升级成 app icon。还没有证据表明 app icon 背后，钱会流向 Skill 作者而不是平台。
封装对「纯 Skill 市场」治 10-20%，对「Skill + MCP/service + 平台 billing」治 40-50%。但后者卖的已经不是「编译后的 prompt」，而是一个可计费服务，接近 SaaS workflow 的形态。
一个更精确的 framing 是：不要试图「编译」Skill，而是把 Skill 变成服务的 interface layer。Skill 是免费的前端（教模型怎么调用你），MCP server 是付费的后端（提供数据、动作、校验、保证）。这和鸭哥说的「Skill 是名片，不是产品」其实不矛盾——名片可以是通往付费服务的入口。
赌注在于：未来 12-24 个月内是否会出现一个 dominant agent runtime，把这件事收拢起来。