Claude有MCP也会翻车？Supabase工程师揭穿AI Agent最大的认知幻觉

当所有人都在争论MCP是不是AI Agent的“终极接口”时，Supabase的一次内部实验给出了一个让人不安的结论：只给工具，不给“正确用法”，最强模型也会把你的产品用错。这场分享讲的不是概念，而是为什么“Skill+MCP”才是当下最现实的解法。

最反直觉的结论：给了MCP，Agent反而更容易把事做错

Pedro Rodrigues一上来就戳破了一个行业幻觉：我们总以为只要把MCP工具接好，Agent自然就会“学会”正确使用你的产品。但Supabase的实测结果恰恰相反——在同样的任务下，只有MCP的Claude Sonnet 4.6，会频繁踩安全坑，比如遗漏Row Level Security；而带有Skill的Agent，反而能一步到位把事情做对。

问题不在模型不聪明，而在“上下文断层”。Agent依赖的是训练时的陈旧知识，对你最新的产品设计、安全约束、最佳实践一无所知；更糟的是，它们还很“倔”——不知道，也不主动查。这直接导致一个现实后果：工具越强，错误的放大效应越大。这正是Pedro所说的“Context Gap”，也是他写下那份“比硕士论文还费劲”的Skill文档的真正原因。

Skill到底是什么？它不是文档，而是Agent的行为边界

在Pedro的定义里，Skill不是一篇给人看的说明书，而是一套给Agent看的行为说明书。它是一个结构化的文件夹：前置的front matter决定“什么时候加载我”，核心的skill.md定义“你必须怎么做”，其余脚本和资源则按需加载，避免污染上下文。

这里有个关键洞察：Skill的价值不在于信息量，而在于选择权。Agent不是一次性把所有内容塞进上下文，而是“逐步发现”。这意味着，写Skill的人，本质上是在为Agent设计一条探索路径。

Supabase的经验是：如果你不告诉Agent什么是不可跳过的，它一定会跳过；如果你不告诉它什么是推荐流程，它一定会自作主张。Skill存在的意义，就是提前把这些“你绝不希望出错的地方”钉死。

三条写给产品团队的血泪原则

Pedro总结的三条原则，几乎每一条都踩中过真实团队的坑。

第一，不要重复文档。Skill不是另一个docs站点。Supabase的做法是直接暴露现有文档结构，让Agent“导航”，而不是“背诵”。

第二，所有不能被跳过的东西，必须进skill.md。任何你觉得“它应该知道”的前提，一旦没写进去，就等于不存在。Agent永远走最省力的路。

第三，也是最容易被低估的一点：要足够主观、足够有偏见。听起来很反AI，但事实证明，明确告诉Agent“在Supabase，我们就是这么建schema的”，比给它十种可能性更安全、更高效。

这不是限制Agent，而是在替它承担决策成本。

为什么Skill + MCP，会成为下一阶段的标配

在测试阶段，Supabase把不同模型、不同配置拉到同一条起跑线，结果非常一致：Skill + MCP 的组合，在所有模型上都跑赢了单独方案。

MCP负责“我能做什么”，Skill负责“我应该怎么做”。前者解决能力问题，后者解决责任问题。当Agent开始被用在真实生产环境，这个区分会变得越来越重要。

Pedro最后给出的建议也很务实：从最小Skill开始，不要追求一次写完；大胆版本化，把Skill当成产品的一部分来迭代。Agent生态的竞争，很可能不只是在模型，而是在“谁教得更好”。

总结

这场分享真正有价值的地方，在于它把一个抽象问题落到了工程现实：如果你希望AI Agent真的能“正确”使用你的产品，你就不能只交付接口，而必须交付判断标准。Skill不是可选项，而是你对Agent负责的方式。

对从业者来说，一个直接的行动点是：回到自己的产品，问三个问题——哪些地方绝对不能出错？哪些流程我有明确偏好？哪些知识如果Agent不知道会造成灾难？答案，就是你Skill的第一版目录。

未来，Agent会越来越强，但是否可靠，很大程度取决于你有没有认真教过它。

关键词： AI Agent， MCP， Skill设计， 上下文缺口， Supabase

事实核查备注： 需要核查：1）测试所用模型是否为Claude Sonnet 4.6；2）Supabase Skill是否在该演讲当天正式发布；3）“Skill+MCP在所有模型上表现更好”的测试范围与具体模型列表；4）Lisbon AI Week举办时间为10月下旬。