AI agent演示总能成功。但一旦投入生产，你就会意识到'它能跑'从来不是最难的。

我一直在构建处理真实业务数据的RAG系统和AI agent：CRM、内部文档、能实际执行操作的系统——而我不断看到同样的事情发生。演示运行完美，所有人都被说服了，而真正的难题甚至还没被触及。演示证明了模型能够回答问题，但它丝毫不能证明将系统对准生产数据是否安全。这是完全不同的问题，而人们总是将它们混为一谈。根据我的经验，真正令人头疼的是： 系统提示词并不等同于访问控制。我见过有人把'只向用户显示他们自己的数据'写在提示词里就算完事。这很容易被攻破。授权必须存在于确定性层——身份、策略、源系统自身的ACL——在任何内容到达模型之前强制执行。模型本身永远不应持有常驻访问权限。 过度权限通过服务账户悄悄引入。没有人会主动决定'给这个agent上帝模式'。这种事的发生是因为有人为了节省时间，重用了已有的高权限令牌，结果agent的实际权限就变成了该账户所能触及的一切。独立的身份、受限的权限、每项工具的允许列表——枯燥但至关重要。 检索泄露。混合了不同权限模型的向量存储，会欣然将一个用户从未被授权查看的、完美匹配的内容片段交给他们。'正确'和'已授权'不是同一回事，语义搜索并不了解其中的区别。 自由格式的模型输出直接进入执行层：SQL层、消息工具、API调用。将模型输出视为建议，通过类型化模式和验证加以限制，绝不能让模型输出直接成为指令。 没有可重建的追踪链。如果你无法追溯：请求→检索到的来源→决策→操作→结果，那么你拥有的不是审计日志，而是模糊的感觉。而当你某天被问到'它为什么要这么做？'时，你才会发现这一点。 所有这些背后的模式是：真正重要的控制措施位于模型之外。换一个更智能的模型无法解决其中任何一个问题。而证明系统可信赖的证据必须在开发过程中逐步建立——等到事件发生后或安全问卷调查时才收集，已经为时已晚。 很好奇大家在这里遇到过什么。你希望自己在面对客户之前就发现的失败模式是什么？