给 Agent 一段 Cookie，再告诉它“只帮我把文章填好，千万别点发布”，这不是权限设计，只是一句愿望。
模型可以遵守，也可能在页面提示、工具描述、重试逻辑或状态误判里越过边界。尤其当同一个浏览器工具既能读 DOM、又能输入、还能点击任意按钮时，所谓只读、预填和提交，实际上共享同一组能力。
9 月 4 日，一组独立研究者披露，他们在德国 DseWiki 上发现了自称与 OpenAI 评测有关的 Agent 留下的大量编辑痕迹。TechCrunch 报道时保留了一个关键限定：OpenAI 尚未确认研究者对 Agent 身份和完整过程的判断，正审阅报告。
具体事件要继续核查，但“一个本应检索网页的 Agent 为什么拥有公开写入路径”很值得工程团队复盘。对内容发布系统，我认为最重要的不是再加一段安全 Prompt，而是建立 Capability Boundary。
不要用一个 canUseBrowser 表示所有权限
布尔开关表达不了真实世界的差异：读取网页不会改变平台状态，保存草稿可以撤销，预填编辑器会修改私有后台，提交发布则会产生外部副作用。
可以把任务状态机拆成四态：
READ -> DRAFT -> PREFILL -> COMMIT
READ：只读数据平面
允许搜索、读取公开页面和被授权的业务资料，但不能修改外部资源。开放网页内容应被视作不可信数据，不能让页面里藏着的指令升级成工具调用。
如果执行器支持域名白名单，最好按岗位配置：博客发布 Agent 需要访问内容平台和资料源，不等于它也需要邮箱、网盘与支付站点。
DRAFT：可版本化的工作区
模型生成的正文、图片、摘要和标签先落到本地工作区。这个阶段允许重写、删除和重新生成，所有变化都能通过版本记录复盘。
事实层也应该在这里结构化：官方事实、合理推断、作者观点分开保存。这样发布前的审核不是泛泛“看起来对不对”，而是能定位每个关键断言的来源。
PREFILL：有限写入，不产生公开副作用
预填层只允许写进指定账号的编辑器。它应该是窄工具，而不是任意浏览器控制：
interface PrefillArticle {
platform: Platform;
accountRef: string; // 引用，不是 Cookie 本体
draftId: string;
expectedFields: string[];
}
执行完必须回读页面：标题是否截断、图片是否真的上传、摘要是否超限、标签是否被平台接受、分类是否仍是默认值。输入没报错，不代表页面状态正确。
COMMIT：独立授权的事务边界
提交不应是 prefill 里的隐藏参数，而应是单独工具：
interface CommitArticle {
platform: Platform;
draftDigest: string;
approvalId: string;
idempotencyKey: string;
}
draftDigest 把授权绑定到某一版内容；approvalId 记录用户或定时任务规则；idempotencyKey 防止超时后盲目重发。工具返回后，还要从成功页、公开链接或作品管理记录确认结果。
为什么 Cookie 不能直接进入 Agent 上下文
Cookie 不是普通参数，它代表一段真实身份和一组隐含权限。如果它出现在 Prompt、工具日志或模型上下文里，任何不该看见这段上下文的组件都可能获得额外能力。
更好的方式是让凭证留在本地执行器：Agent 只拿到 accountRef 和“当前登录态有效”之类的最小状态。工具根据岗位、平台和任务范围调用会话，模型本身看不到凭证内容。
OpenAI 的 Computer-Using Agent 官方说明也把有外部副作用的最终动作确认列为缓解误操作的重要层；ChatGPT agent 的说明则专门提示，网页中的恶意指令可能诱导 Agent 对已登录网站采取非预期动作。这里没有哪一段 Prompt 能替代工具边界。
自动任务怎么处理：授权规则，而不是永久放行
定时发布不可能每次都等人在电脑前点一下，但也不意味着把 COMMIT 永久开放。可以把授权写成策略：
platforms: [csdn, juejin, toutiao]
accounts: [brand-main]
max_posts_per_platform_per_day: 2
allowed_window: ["10:15-11:00", "20:15-21:00"]
require_page_readback: true
stop_on_captcha_or_risk_control: true
这相当于用户提前批准一个清晰的事务范围。超出平台、数量、时间窗口，或页面出现验证码、风控和未知选项时，提交能力立即收回。失败后先查作品记录，绝不能靠重复点击“碰碰运气”。
把完整交付与最小权限放在一起
内容 Agent 如果只生成 Markdown，价值确实有限。选题、调研、写稿、配图、排版、预填、发布和核验应该形成闭环。关键在于，闭环是一条有闸门的流水线，不是一把万能钥匙。
这也是我们设计 Tipkay 时坚持的做法：垂类 AI 员工按岗位配置能力，平台登录态留在本机；博客发布助手可以完成多平台预填，但预填、提交和验证被当成不同阶段。这个实现并非唯一答案，不过它让“会不会写”和“有没有权发”不再混为一谈。
评价一个发布 Agent，除了问完成率，我会再问三个问题：它拿到的是哪一级能力？失败后会不会重复产生外部状态？出了问题能不能沿授权、草稿版本和作品记录追溯？
模型越强，这三个问题越不该交给模型自己回答。
参考：
