智能体安全，别从第三步开始

You're building agent security in the wrong order

智能体安全市场突然醒了。短短两周，我看到有公司在推出运行时身份验证方案，有平台能发现影子智能体，还有实时权限撤销功能等等。背后都是正经团队，我尊重他们的工作。

但他们都在解决第三步的问题。

顺序问题

过去两年，我观察了大量企业团队部署智能体的过程，CrewAI 也处理了数十亿次执行。发现大家的模式出奇地一致。

团队接到任务：“部署 AI 智能体。”安全负责人马上问安全方案，董事会要合规报告。于是团队从身份和访问管理（IAM）策略、授权范围、运行时监控开始，围绕智能体搭建安全栈。

然后他们真的运行智能体。结果智能体找不到合适的工具，状态在步骤间漂移，智能体间的协调在每次交接时中断。安全层很牢固，但它保护的东西根本没法用。

我见过一家财富 500 强公司，团队花了三个月走完这条路，实现了完整的企业级智能体 IAM。合规文档写得漂亮，但接入智能体后才发现，执行框架（Harness）根本没到位。

这不是能力问题，工程师都很优秀，但我觉得确实是顺序搞错了。

第一步，执行框架（Harness）。 想想内存管理、高效的工具调用、步骤间不漂移的状态。当出错时，你的智能体如何反应？是上报给人类，还是自己编造答案？你得问问自己是否在优化正确的东西，可能会发现你还没有值得保护的东西。

CrewAI 的 Flows 架构通过确定性路由、可观测执行和预设升级路径来解决这个问题。这不是因为我们偏执，而是我见过跳过这一步的团队会遭遇什么。

第二步，治理（Governance）。 执行框架可靠后，才能定义智能体允许做什么、接触哪些数据、哪些操作需要人工审批、审计日志存哪里。别把这步当成合规打勾，而是架构设计。它会塑造整个工作流如何运行、如何升级，是你将信任设计进系统的过程。

第三步，身份和认证（Identity and Auth）。 现在你知道智能体做什么、允许接触什么。零信任、最小权限、运行时范围控制，这些都能正确落地，因为你在对已知的攻击面执行规则，而不是猜测一个不可预测的智能体会尝试什么。

行业里，有些人可能主张在第三步砸钱，而大多数团队连第一步都没完成。

因为安全是企业采购的门槛。

团队用安全故事开路，因为这样才能拿到预算，供应商自然跟着需求走。执行框架问题没有明确截止日期，它只在测试环境悄悄失败，直到生产环境才变得非常刺耳。

我理解。不是说这些供应商做错了，智能体治理是真实需求，身份工作也必要。这些都是好产品，解决真问题。但除非执行框架到位，否则它们解决不了问题。

先构建执行框架，让它变得无聊但可靠，变成你能用一句话向安全团队描述的东西：“这个智能体具体做什么，具体在哪里可能失败，失败时具体会发生什么。”

那些大规模运行生产智能体的团队都搞对了顺序。让安全步骤做它该做的事，给它一个真实、可理解的东西去保护。到那时，治理自然就位，你也知道攻击面在哪里，可以定义符合现实的策略。

区别几乎从来不是智力，大多是顺序。从第一步开始。