任务：填写并提交目标表单
步骤缓存：定位输入框 → 填参 → 点提交 → 校验返回串
备注：无需重新读取页面结构
不是谁的真实配置。是把"行为模型"这一层从这类架构里单独抽出来之后，大概长成的样子。最后那行备注——无需重新读取页面结构——就是这篇要讲的东西。
9 月 11 日挂上 arXiv 的那篇，arXiv:2609.13491，cs.AI，Alexandru Ianta 和 Eleni Stroulia，OdoBot。做法说穿了不复杂：先让它看几遍成功完成任务的演示，把被测应用的行为摸成一份模型，之后执行同类任务照着模型走，不再每轮从头解析界面。Canvas 学习管理系统上跑了 45 个任务，token 用量比 Agent-E 少 44%，比 WebVoyager 少 80%，成功率还压过 WebVoyager 一头。
数字很漂亮。下面讲的不是这个。
每次执行都重新读一遍页面，一直被算作纯成本。它同时是一道安全控制，只是没人这么叫过它。页面现在长什么样、有没有多出来一个字段、提交按钮跳的域名还是不是原来那个、权限提示有没有变宽——每一轮都重新过一遍。这四样里随便哪一样发生，都是典型的前兆信号。行为模型干的事，是把这套逐轮校验换成一次性的、离线的、可以反复复用的缓存。
缓存意味着什么，写过分布式的人都清楚：模型是快照，页面是活的。中间这段时间谁动过它，你的 agent 不会知道。经典 TOCTOU，以前发生在文件系统上，现在发生在 agent 的"记忆"里。
换成攻击者的思路，这套东西的吸引力不在省 token，在于省次数。
在每一次运行的上下文里塞指令，是拼概率的活：赢了检测、绕过了那一次，下一次还得重新来一遍。成本线性，收益单次。可如果 agent 的决策依据来自一份被反复复用的模型，我要对付的就不是每一次执行，是建模那一次。
链条大概是这样：
控制一次演示录制 / 污染一份演示语料 → 建模管线把它吃进去，写成一条谁都没细看的步骤 → 之后每一轮执行照着这条步骤走 → 因为不再重新读页面，没有异常会被呈现给检测层 → 该带出去的东西，沿着这条合法路径自己走出去。
至于具体怎么污染，不用说，这段只是把顺序摆出来。一次投入，长期生效，攻击成本被一次性摊平，剩下的是复利。论文标题叫 Token Efficient Task Execution via Application Behavior Modeling——把前半句的"任务执行"换成"攻击投递"，同一套机制照样成立。它做的本来就是同一件事，只是站在另一边。
这个我一开始判成高危，理由挺直接：注入能持久化，等于把逐轮检测整层绕过。后来把触发条件摊开——得先有人能进到你的建模流程、模型更新这一段没有人工复核窗口、且被建模的那条链路恰好带着敏感数据或者高权限动作。三个前提同时成立才咬得动，凑齐不算便宜。（中概率，高杀伤）级别下调，没归零。
写到这里我又有点想把它调回去。如果建模只做一次、之后再不更新，那这就是个一次性的窄缝，关了门就完了。可惜省 token 的架构为了持续省钱，一定会上增量更新——模型要跟着页面一起长，否则省下来的那点开销很快会被走错路的代价吃回去。而只要它更新，窄缝就变成常开的门。这套逻辑不新，我手上压着的几个洞里有两条就是这个形状。
比持久注入更早咬到你的，其实是演示语料本身。
不管谁来建模，它得先有一批"成功完成的任务"。这类东西以前散在屏幕录像、会话回放、埋点日志里，谁都没把它当资产管。现在它有了明确的消费方：建模管线要读它、存它、很可能还要挪个地方放。而一份演示里装的是什么？真实的表单值、真实的业务对象，有时还有会话凭证和内部端点。一份有组织、有标注、拿来就能用的成功任务演示集，信息密度比一份随机键盘记录高得多。
演示从哪来，是这类架构自己要去回答的问题。它没回答的那部分，就是你手上新的攻击面。而且如果建模这一步跑在别人的基础设施上，这批东西已经出过你的边界了。
——离题了，收：这不是新问题，是老问题被搬到了新地方，然后因为那个新地方第一次有了明确的消费方，它才变得值得偷。
还有一层，成本上的。
token 贵的时候，你不会拿生产账号挂着一个 web agent 整天跑，也不会让它同时接七八个系统。贵本身就是一种刹车。现在单次成本掉了一半、掉了八成，接下来会发生的不难猜：同一条流水线接上更多系统、更多账号、更长的无人值守时段。省下来的 token 不会凭空消失，它会变成更多地方在跑 agent——而权限是跟着部署量一起长的。
顺带说一句成功率那个数字。它才是这套架构最强的一张牌：更省钱、还更准，于是"要不要关掉那几道确认"这个老问题立刻有了新答案。但你得想清楚，成功率是在照旧运行的路径上量出来的。照着记忆走的 agent，一切正常的时候表现更稳——它错的时候，也比你自信。
还有一件没人当回事的副作用：不再重新读页面，等于把检测输入拿掉了。审计日志里你会看到一串漂亮的成功步骤：打开页面 → 定位表单 → 填值 → 提交 → 返回 success。看不到的是这几步里它根本没读过页面，也看不到"当前页面结构和模型对不上"的那个瞬间。异常发生在它没有看的时候，而"没有看"在日志里不留痕。检测层要抓异常，前提是异常有地方露头。
拆弹清单，四条：
- 建模语料按密钥级别管。脱敏在前，存放位置固定在后；录制过程中用过的会话凭证，录完就轮换，别让它躺在 traces 里等下一次复用。
- 首次建模可以自动，增量更新得过人眼。重点看 diff 里有没有冒出新域名、新端点、新字段——模型学到的每一个新出口，都是它以后能去的地方。
- 高权限动作禁止走缓存路径。金额、权限变更、删除、对外发送，这四类每一次都回到实时读一遍页面。慢一点，认了。
- 权限卡在工具调用那一层。模型记错了没关系，只要它物理上够不到那个动作。投毒一份模型值不值，取决于模型背后的 agent 能碰到什么。
别慌，这不是让你别用行为模型。OdoBot 没什么问题，它是一篇把方向做对了的论文，省下来的钱是真金白银。要收紧的只有两个位：建模那一步的输入从哪来，模型记下来的东西能够到哪些动作。这两处握在自己手里，剩下的 token 你尽管省。
排雷记录：模型可以缓存，授权不行。