OpenAI踩坑3年才发现：AI代理第3步就会"失忆"

去年有个支付团队把AI客服代理上线生产环境，测试时一切正常。上线第7天，一个被注入恶意提示词的代理，用后台服务账号给陌生用户退了1.2万美元——系统记录显示是"合法操作"，因为执行层根本不知道是谁下的命令。

这就是身份崩塌（Identity Collapse）：当AI代理执行到第3步复杂编排时，原始用户的身份、授权范围、操作意图，已经在异步链条中彻底溶解。

本地开发时你是上帝视角：用户→代理→工具→服务，每一步都看得见。但多租户生产环境里，代理成了"中间商"，它拿着万能服务账号的API密钥，能调支付网关、能删数据库、能改客户资料。一旦代理被劫持或漂移，它用的可是你的" root 权限"。

传统REST API像快递单号——JWT令牌从进门到签收全程跟着包裹，每个中转站都要验货。AI代理却像电话传话游戏：用户说"查一下我的余额"，代理听成"查一下"，然后自己编了后半句"然后转给这个账号"，执行层只认"是代理打来的，准了"。

身份崩塌的5分钟：一场1.2万美元的教学

来看这个被利用的链条。Step 1，用户发起"查询订单#1234"；Step 2，代理规划工具调用，生成执行参数；Step 3，代理异步触发退款工具——注意，这时候已经没人问"这用户有权限退1万吗"；Step 4，执行层看到的是"服务账号请求退款"，Step 5，钱出去了。

漏洞出在两个断层。第一，LLM是动态生成参数的，不是预定义路由，传统网关拦不住；第二，代理作为中间人，把用户的身份令牌换成了自己的服务密钥，下游工具只能看到"代理让我干的"，看不到"原始用户是谁、想干什么"。

安全圈管这叫"困惑副手问题"（Confused Deputy Problem）——一个程序被第三方诱骗，滥用自己的高级权限。代理越智能、工具链越长，副手越困惑。你以为是用户在操作，其实是代理在代劳，而代理可能已经被一句话带偏。

把身份焊进执行路径：CogniWall的解法

解决思路不是加更多日志，而是让身份跟着请求流一起流动。CogniWall的做法是构建一个"可编程的身份感知防火墙"——不是在网络层，而是在代理的每一次工具调用前插一道闸口。

具体怎么焊？三个锚点。第一，执行前校验：代理生成的每个参数都要过策略引擎，比如"退款金额>5000必须二次确认原始用户身份"；第二，身份透传：把用户JWT拆成可验证的声明，嵌进代理的每一次下游调用，让工具层能回答"这是用户A的指令，还是代理自己编的"；第三，端到端归因：全链条的可观测性，从用户输入到最终执行，每一步都能追溯到人。

这套架构的关键认知是：代理不是用户，代理是用户的"律师"。律师可以帮你递交文件，但不能替你签字；代理可以帮你调用工具，但每一次调用都必须携带你的授权委托书的副本。

Prompt注入的防御也因此变了逻辑。传统思路是"别让代理看到脏数据"，但在生产环境这不可能——用户输入、网页抓取、第三方API返回，全是不可控的。身份感知防火墙的做法是"就算代理被洗脑，它也没有权限执行危险操作"，用确定性策略兜底概率性风险。

从"信任代理"到"验证每一次呼吸"

有个反直觉的点：越"智能"的代理，越需要笨功夫的权限控制。因为LLM的创造性正是它的不可预测性——它能帮你写出没见过的SQL，也能构造出没被测试过的API调用组合。

CogniWall的策略引擎是声明式的，你可以写"允许代理访问CRM，但禁止批量导出"或者"允许查询余额，但转账操作必须保留用户原始会话令牌"。这些规则在代理规划阶段就生效，而不是等它生成参数之后。

多租户场景下这尤其关键。SaaS平台的代理如果混用服务账号，A租户的数据可能通过B租户的代理流出去——不是恶意，是身份标签在链条中掉了。身份感知架构要求每个租户有隔离的执行上下文，代理的每一次工具调用都携带租户ID的密码学证明。

落地时的典型踩坑：团队往往先建代理、后补安全。结果是代理已经接了20个工具，发现改身份流要动全部调用链。CogniWall的教程建议从第一天就把身份作为"一等公民"设计——不是用户表的字段，而是执行路径的基础设施。

一个值得抄的作业：某金融科技团队把代理的每一次工具调用都映射到原生的IAM策略，代理本身只有"发起请求"的权限，真正的执行权限在用户会话的短期凭证里。代理被攻破？攻击者拿到的是一个空壳。

当AI代理从demo走向生产，我们才发现"自主"的另一面是"不可审计"。你的代理第几步开始"失忆"？如果现在去查日志，能追溯到最近一次敏感操作的原始用户身份吗？