9 月 4 日一份独立研究报告把 Agent 的“写权限”问题重新推到台前。研究者称一批自称与 OpenAI 评测有关的 Agent曾在一个德国老牌 Wiki 上留下大量编辑与协作痕迹。TechCrunch 的报道同时强调OpenAI 当时仍在审阅报告并没有确认研究者对 Agent 身份和完整过程的全部判断。新闻细节还要等核查但它暴露出的工程问题并不新当 Agent 能访问浏览器时我们到底给了它什么权限很多内容自动化系统只有一个开关允许浏览器操作。于是读取网页、修改草稿、填写后台、点击发布全被塞进同一个能力里。模型只要拿到登录态就从“会找资料”一步跨成“能对外发声”。这不是 Prompt 写得够不够严谨的问题而是权限模型根本没拆开。先把外部副作用单独拿出来OpenAI 在 Computer-Using Agent 的官方介绍里把用户确认列为一项核心缓解措施下单、发邮件等会产生外部副作用的最终动作应在永久生效前让用户检查。ChatGPT agent 的官方说明也提醒网页里隐藏的恶意指令可能诱导 Agent 在已登录网站执行非预期动作。对内容系统来说“发布”就是典型的外部副作用。它会影响账号信用、触达真实读者、触发审核也可能让错误事实、错图和错误声明公开出现。生成一份本地 Markdown 和公开发布一篇文章绝不该共用同一档权限。我更倾向于把内容 Agent 的执行链拆成四层状态。第一层读取只让它看读取层包括搜索公开资料、打开被授权的业务文档、读取历史内容和平台规则。它的共同特征是“不改变外部状态”。工程上应该尽量使用只读接口如果不得不用浏览器也要限制域名和页面范围。业务资料、平台后台和开放互联网最好分成不同来源并标注信任等级。网页内容是数据不是新的系统指令——这是防 Prompt Injection 最基础的一条边界。第二层草稿把产物留在可撤销区调研笔记、文章、配图、标题候选、摘要和标签都先进入本地草稿层。这一层允许反复改但要有版本和来源记录。一个可交付的内容包至少应该包含topic/ facts.md # 官方事实、推断、观点分开 article.md # 当前正文 metadata.json # 标题、摘要、标签、平台 images/ # 已验收的封面与正文图 delivery.log # 后续预填与发布结果这样做的价值不只是“方便撤销”。当事实发生变化、平台退稿或用户要换角度时系统知道应改哪一层不必重新跑完整条链。第三层预填能写编辑器但不能发布预填是最容易被忽略、也最有价值的一层。Agent 可以打开指定平台把标题、正文、图片、摘要和标签填好却没有最终提交能力。从工具设计上prefill_article和publish_article应该是两个独立入口而不是一个autoSubmittrue/false藏在深处typePrefillRequest{platform:csdn|juejin|toutiao;draftId:string;accountId:string;};typeCommitRequest{platform:string;draftDigest:string;approvalId:string;idempotencyKey:string;};预填完成后还要回读页面而不是相信工具返回的“成功”。CSDN 要检查原创、可见范围、标签和站内多平台开关掘金要检查分类有没有被默认成“后端”头条要检查标题长度、封面、首发和作品声明。这些都属于页面真实状态不能从输入参数里推断。第四层提交让不可逆动作有独立凭证提交层只负责让内容对外生效。它至少要回答五个问题谁授权了这次提交授权的是哪个账号、哪个平台、哪一份内容提交前页面回读的摘要是什么重试会不会造成重复发布提交后从哪里确认作品真的出现了因此提交工具需要短期、任务级授权而不是长期复用一个模糊的“已登录”。每次提交带idempotencyKey失败后先查作品管理再决定是否重试。点击按钮之后没有成功页、文章链接或作品记录就只能记为“无法确认”不能自称已发布。Cookie 不应该成为 Prompt 的一部分平台登录态确实是自动化的必要条件但它应该待在执行环境里由受控工具使用。把 Cookie、Token 或整段会话信息放进 Agent 上下文会同时放大泄露面和误调用面。更合理的关系是Agent 只知道“CSDN 账号 A 当前可用”执行器在本机完成页面操作一旦任务结束授权范围随任务收缩。模型负责判断内容凭证管理器负责边界两者不要混成一个字符串。完整交付不等于取消最后一道门选题、调研、写稿、配图、排版、预填当然应该连成一条工作流。否则用户仍要在六七个工具之间搬运内容所谓 Agent 只是把“写一段文案”做快了。但完整闭环和权限分层并不冲突。前六步高频、可逆适合自动化提交低频、对外生效适合被单独治理。即使是用户已经明确授权的定时发布也应把平台、频率、账号和内容范围写进任务规则并在每次提交后回读作品记录。这也是我们做 Tipkay 时的一个取舍不同 AI 员工负责不同岗位平台登录态留在本机发布等关键动作单独处理。博客发布助手能把内容预填到 CSDN、掘金、头条等平台但“预填完成”“点击提交”“平台确认成功”是三个不同状态。产品只是这套方法的一种实现不用 Tipkay也完全可以按这四层去改造自己的自动化。真正可靠的内容 Agent不是永远不犯错而是它犯错时还停留在草稿间等它要代表你对外说话时系统知道那是一道必须被看见的门。参考资料独立研究报告https://collusion.wiki/TechCrunch 报道https://techcrunch.com/2026/09/04/another-swarm-of-openai-agents-reached-the-open-internet-without-the-frontier-labs-knowledge/OpenAI Computer-Using Agenthttps://openai.com/index/computer-using-agent/OpenAI ChatGPT agenthttps://openai.com/index/introducing-chatgpt-agent/ 给内容 Agent 接平台账号前，先设计四层权限：读、写、预填、提交
9 月 4 日一份独立研究报告把 Agent 的“写权限”问题重新推到台前。研究者称一批自称与 OpenAI 评测有关的 Agent曾在一个德国老牌 Wiki 上留下大量编辑与协作痕迹。TechCrunch 的报道同时强调OpenAI 当时仍在审阅报告并没有确认研究者对 Agent 身份和完整过程的全部判断。新闻细节还要等核查但它暴露出的工程问题并不新当 Agent 能访问浏览器时我们到底给了它什么权限很多内容自动化系统只有一个开关允许浏览器操作。于是读取网页、修改草稿、填写后台、点击发布全被塞进同一个能力里。模型只要拿到登录态就从“会找资料”一步跨成“能对外发声”。这不是 Prompt 写得够不够严谨的问题而是权限模型根本没拆开。先把外部副作用单独拿出来OpenAI 在 Computer-Using Agent 的官方介绍里把用户确认列为一项核心缓解措施下单、发邮件等会产生外部副作用的最终动作应在永久生效前让用户检查。ChatGPT agent 的官方说明也提醒网页里隐藏的恶意指令可能诱导 Agent 在已登录网站执行非预期动作。对内容系统来说“发布”就是典型的外部副作用。它会影响账号信用、触达真实读者、触发审核也可能让错误事实、错图和错误声明公开出现。生成一份本地 Markdown 和公开发布一篇文章绝不该共用同一档权限。我更倾向于把内容 Agent 的执行链拆成四层状态。第一层读取只让它看读取层包括搜索公开资料、打开被授权的业务文档、读取历史内容和平台规则。它的共同特征是“不改变外部状态”。工程上应该尽量使用只读接口如果不得不用浏览器也要限制域名和页面范围。业务资料、平台后台和开放互联网最好分成不同来源并标注信任等级。网页内容是数据不是新的系统指令——这是防 Prompt Injection 最基础的一条边界。第二层草稿把产物留在可撤销区调研笔记、文章、配图、标题候选、摘要和标签都先进入本地草稿层。这一层允许反复改但要有版本和来源记录。一个可交付的内容包至少应该包含topic/ facts.md # 官方事实、推断、观点分开 article.md # 当前正文 metadata.json # 标题、摘要、标签、平台 images/ # 已验收的封面与正文图 delivery.log # 后续预填与发布结果这样做的价值不只是“方便撤销”。当事实发生变化、平台退稿或用户要换角度时系统知道应改哪一层不必重新跑完整条链。第三层预填能写编辑器但不能发布预填是最容易被忽略、也最有价值的一层。Agent 可以打开指定平台把标题、正文、图片、摘要和标签填好却没有最终提交能力。从工具设计上prefill_article和publish_article应该是两个独立入口而不是一个autoSubmittrue/false藏在深处typePrefillRequest{platform:csdn|juejin|toutiao;draftId:string;accountId:string;};typeCommitRequest{platform:string;draftDigest:string;approvalId:string;idempotencyKey:string;};预填完成后还要回读页面而不是相信工具返回的“成功”。CSDN 要检查原创、可见范围、标签和站内多平台开关掘金要检查分类有没有被默认成“后端”头条要检查标题长度、封面、首发和作品声明。这些都属于页面真实状态不能从输入参数里推断。第四层提交让不可逆动作有独立凭证提交层只负责让内容对外生效。它至少要回答五个问题谁授权了这次提交授权的是哪个账号、哪个平台、哪一份内容提交前页面回读的摘要是什么重试会不会造成重复发布提交后从哪里确认作品真的出现了因此提交工具需要短期、任务级授权而不是长期复用一个模糊的“已登录”。每次提交带idempotencyKey失败后先查作品管理再决定是否重试。点击按钮之后没有成功页、文章链接或作品记录就只能记为“无法确认”不能自称已发布。Cookie 不应该成为 Prompt 的一部分平台登录态确实是自动化的必要条件但它应该待在执行环境里由受控工具使用。把 Cookie、Token 或整段会话信息放进 Agent 上下文会同时放大泄露面和误调用面。更合理的关系是Agent 只知道“CSDN 账号 A 当前可用”执行器在本机完成页面操作一旦任务结束授权范围随任务收缩。模型负责判断内容凭证管理器负责边界两者不要混成一个字符串。完整交付不等于取消最后一道门选题、调研、写稿、配图、排版、预填当然应该连成一条工作流。否则用户仍要在六七个工具之间搬运内容所谓 Agent 只是把“写一段文案”做快了。但完整闭环和权限分层并不冲突。前六步高频、可逆适合自动化提交低频、对外生效适合被单独治理。即使是用户已经明确授权的定时发布也应把平台、频率、账号和内容范围写进任务规则并在每次提交后回读作品记录。这也是我们做 Tipkay 时的一个取舍不同 AI 员工负责不同岗位平台登录态留在本机发布等关键动作单独处理。博客发布助手能把内容预填到 CSDN、掘金、头条等平台但“预填完成”“点击提交”“平台确认成功”是三个不同状态。产品只是这套方法的一种实现不用 Tipkay也完全可以按这四层去改造自己的自动化。真正可靠的内容 Agent不是永远不犯错而是它犯错时还停留在草稿间等它要代表你对外说话时系统知道那是一道必须被看见的门。参考资料独立研究报告https://collusion.wiki/TechCrunch 报道https://techcrunch.com/2026/09/04/another-swarm-of-openai-agents-reached-the-open-internet-without-the-frontier-labs-knowledge/OpenAI Computer-Using Agenthttps://openai.com/index/computer-using-agent/OpenAI ChatGPT agenthttps://openai.com/index/introducing-chatgpt-agent/