AI Agent 并不是变笨了，而是我们根本没教会它干活

很多人以为 AI Agent 不好用，是模型能力不够。但在这场 Supabase 的分享里，Pedro 直接把锅甩给了我们：Agent 之所以“拉胯”，不是智商问题，而是技能设计、权限边界和评估体系全都没跟上。这是一场把 Agent 从“玩具”拉回“工程系统”的演示。

真正的 Skill Issue，不在模型，在你怎么“教”它

演讲一开始，Pedro 就抛出了一个让人不太舒服的事实：几乎所有人都听过“skills”，但真正把 skills 当成一等公民来设计的人并不多。我们嘴上说 Agent，其实心里想的还是“一个更聪明的 prompt”。问题在于，Agent 并不是靠一次性指令工作的系统，而是一个需要被拆解、约束、复用的技能集合。

他强调，skills 不是装饰品，而是 Agent 行为的最小可控单元。技能之间可以互相引用，像模块一样组合；如果你还在把所有逻辑塞进一个巨大 prompt 里，那 Agent 的失败几乎是必然的。这也是为什么很多团队会感觉：模型明明很强，但一上生产就开始胡来。

当 Agent 变得“太能干”，安全反而先崩了

分享中最有警示意味的一段，来自一次“为了演示方便”的设计选择：在某个场景下，角色级别的安全策略被绕过了。结果很直接——Agent 拿到了它本不该看到的敏感信息。

这个例子点破了一个行业里很少被公开讨论的问题：我们在追求 Agent 能做更多事的时候，往往低估了权限和数据边界的复杂性。Supabase 的行级安全策略（RLS）本来是为人类用户设计的，但当你引入 Agent 这种“半自动操作者”时，原有假设就开始失效。

Pedro 提到的“渐进式披露（progressive disclosure）”尤其值得玩味：不是一开始就把所有数据摊给 Agent，而是根据任务阶段逐步开放。这不是模型能力问题，而是系统设计的成熟度问题。

Prompt 不是艺术创作，而是工程配置

在演示仓库和应用时，Pedro 花了不少时间展示 prompt 的准备过程。这一段传递的信息很明确：prompt 不该是即兴发挥，而应该像配置文件一样被审视、被版本控制。

“看起来还行”并不是一个合格的标准。真正的标准是：在相同输入下，Agent 是否能稳定地产出可预测的行为？当你再次运行同一个 prompt，结果是否一致？这也是为什么他不断强调，要把 prompt、skills 和后端能力（Supabase）一起看，而不是割裂成‘模型问题’和‘数据库问题’。

当 prompt 被当成工程资产管理时，Agent 才第一次有机会变得可靠。

没有评估，就没有所谓“变好”的 Agent

整场分享的落点，其实是评估。Pedro 说得很直白：如果你不能系统性地评估 Agent 的技能，那你永远只是在“感觉它好像进步了”。

他的做法是从定义指标开始，把每个技能放进一个最基础的评估流水线里。这不是炫技，而是最低限度的工程自律。Agent 是否完成任务、是否越权、是否稳定，这些都应该被量化，而不是靠 Demo 成功与否来判断。

这一步看似枯燥，却是 Agent 从演示走向真实产品的分水岭。没有评估，Agent 只是一场运气好的魔术。

总结

这场分享真正击中的，并不是 Supabase，也不是某个具体工具，而是一个残酷现实：AI Agent 的失败，往往是工程失败，而不是模型失败。对从业者来说，最大的 takeaway 是——停止把 Agent 当“更聪明的聊天框”，开始像设计后端系统一样设计它的技能、权限和评估。如果你正在做 Agent，不妨问自己三个问题：它有哪些可复用的 skills？它在什么边界内行动？我如何证明它真的变好了？想清楚这三点，你已经超过了大多数人。

关键词： AI Agent， Skills 设计， Supabase， 评估流水线， 权限与安全

事实核查备注： 需要核查：演讲者 Pedro Rodrigues 的具体职位；视频中关于角色级安全策略被绕过的原始表述；“progressive disclosure”是否为演讲原话；视频实际时长与发布时间。