一次公众号草稿注入前，我先查看登录状态。旁路检测页停在登录界面，于是我判断“未登录”。可真正执行脚本连接的 9222 端口里，早已有带 token 的公众号编辑器 tab，连 appmsgid 都在地址中。
任务没有删文件，也没有误发文章，只是被一句错误结论耽搁了。这是一次低后果失误，却把边界照得很亮：Agent 一旦混用环境身份，它看到的“这台电脑”，未必是它真正要操作的那一台。
环境身份比页面状态更重要
事后回看，模型并非不懂公众号。问题在于控制面没有先回答三个问题：脚本实际连接哪个端口，端口里有哪些 tab，目标页面是否带 token。一个检测上下文显示登录页，不能替代真实执行上下文。好比保安看见东门无人，便宣布整栋楼停业——判断很勤快，楼门看错了。
正确的核对顺序很朴素：先看脚本实际使用的 CDP 地址，再遍历这个端口上的全部 tab，最后确认目标页是否带 token、编辑器路径与 appmsgid。三项证据一致，才有资格判断登录状态。
发现状态不符时，更不能顺手启动一个 Chrome 来“修复”。9222 等端口由 browserManager 管理，另起实例可能争用端口、丢失会话，把一次误判变成两套身份同时存在。
同样，封面与正文配图可以并行生成，公众号注入却必须串行。两个进程争用同一个编辑器，第二个就可能报告“找不到编辑器”。故障来自共享环境被同时占用，与模型能力无关。
隔离是授权的前置条件
主力电脑的风险来自身份太多、后果难以回滚。同一浏览器里可能同时存在个人邮箱、公司后台、支付页面和公众号 token；同一目录也可能混着临时素材、客户文件与工作凭据。Agent 不必“攻破”任何东西，只要顺着既有登录态点错一个 tab，普通误判就可能变成真实动作。
主力环境的麻烦还在于，错误难以复现：tab 顺序、cookie、临时文件和后台会话不断变化。今天一次误点没有后果，不代表明天同样的动作仍然安全。
所谓“另一台电脑”，并不一定要另买硬件，它可以是 VM、容器、独立浏览器 profile 或可重置远程环境，关键是环境身份单一、可清理、可回滚。
因此，顺序不能颠倒：先隔离环境，再扩大授权。边界清楚后，低风险动作才适合自动运行；边界不清，层层审批也只是在主力电脑上反复弹窗。授权的安全性来自隔离设计。
可托付执行需要四道边界
专用执行环境。 固定设备、端口、浏览器 profile 与工作目录，并由统一管理器启动。发生异常时先核对真实执行上下文，不临时复制一个看似相同的环境。
最小文件与网络范围。 只挂载任务所需目录，只开放必要域名和服务。Agent 看不到的资产，不会因为一次错误点击突然进入动作链。
高后果动作外部确认。 发布、删除、付款和重要配置变更，应在 Agent 执行上下文之外由人确认。确认点必须放在最后一跳，而不是把每个低风险步骤都变成弹窗。
日志与终态回读。 记录它连接了哪个端口、进入了哪个 tab、调用了什么工具，并在动作结束后重新读取真实结果。素材生成可以并行，共享编辑器仍要串行。
能托付的 Agent，权限未必最多；关键是犯错时只会撞上软墙。 环境先隔离，授权才有意义。
