标签：内容安全

前沿哨所

• 五家的 Agent 越来越像：DeepSeek 是第五个

  10 月 31 日，DeepSeek 发了一篇 Super-agent 设计长文。同一条赛道上，这已经是 71 天里的第五份答卷。把五份并排放，会发现一件比“谁更强”更值得说的事：骨架已经收敛了。

  时间线与产品能力取自各家官方发布页与公开报道，截至 2026-10-31。DeepSeek 的实验数据引自其公开长文第 7 节，数字未做二次加工；产品侧描述以官方页面为准，未验证的功能不予采信。

  同一道题，五份答卷

  10 月 31 日，DeepSeek 产品部与 Harness 团队发了一篇长文，《Super-agent 设计探索》。开头先压预期：这是面向工程实践的架构思路探讨，不是产品介绍。文末又补一句，相关实现只是验证技术路线的原型，不是正式产品。

  往回倒 71 天，这条赛道上已经站了四家。8 月 11 日 Grok Bot 进入测试，9 月 8 日 Meta 的 Muse 上线，9 月 29 日 OpenAI 的 Dots 发布，10 月 21 日 Anthropic 的 Claude Duet 开放研究预览。DeepSeek 是第五个，也是唯一一个用一篇长文、而不是一个产品来表态的。

  把这五份放在一起，第一反应不是“谁更强”，而是“怎么长得这么像”。四家产品对外披露的能力项几乎可以逐条对齐；DeepSeek 那篇长文里画的架构图，也能和 Duet 的产品说明一一映射过去。

  这种相似不是抄来的。它来自同一组约束：环境事件是持续到达的，人的注意力是稀缺的中断源，上下文窗口是有限的缓存。约束一样，就导出相近的结构，这在工程史上反复发生过。当年从单机进程到多线程、从单体到服务网格，走的也是这条路。

  指标	数值	说明
  71 天	四家入场	从 Grok Bot 到 Claude Duet
  5 份	同一道题	含 DeepSeek 的设计长文
  6,000+	连接器	Duet 官方口径可调用数量
  40 条/分	Router 压测	DeepSeek 单次实验的触发速率上限

  五家的入场顺序

  

  条形长度按距 8 月 1 日的天数计，标签为实际发布日。四家用 71 天完成入场，节奏是 28 天、21 天、22 天；DeepSeek 在第 81 天发出一篇长文。

  骨架确实一样，五个模块对得上

  Duet 和 Super-agent 分处产品与原型两端，但只要把两边的公开描述并排放，会发现它们回答的是同一串问题，而且答案高度重合。

  Duet 的路子是：云端独立虚拟机上跑一个常驻 Agent，自带浏览器，继承你原有账户里的记忆、技能和授权应用，每天早上推一份晨报，白天持续监控，只在需要你拍板时出声，发消息、付款、签字、删除这类动作一律先给审批。

  Super-agent 的路子是：常驻的 Router 会话负责承接人类交互与全局记忆，上下文隔离的 Worker 各自订阅事件流并行执行，执行环境留在用户原来的机器上，端侧只放一个不保存状态的 daemon。

  两套话术背后，是同一张图。

  两端的能力映射

  问题	Claude Duet	DeepSeek Super-agent
  常驻在哪	云端独立虚拟机 + 自带浏览器	云端无状态容器，执行环境留在原地
  记忆从哪来	继承 Claude 账户的记忆与技能	常驻 Router 会话 + 引用图链式召回
  被什么驱动	晨报 + 全天后台监控	环境事件 Trigger + 两级过滤
  何时打断人	只在需要决策时出声	有价值才交付，否则保持安静
  谁能动手	发消息、付款、签字、删除均需批准	未展开，归入开放问题
  凭证怎么管	由 Managed Agents 托管，模型不见密码	列为 8.4 开放问题

  左列为共同问题，中右两列为两家各自的答案。前四项同构，第五项开始分叉。

  六行里前四行几乎同构，连措辞都能对上。“只在需要你拍板时出声”和“没有价值就保持安静”，说的是同一件事；一个用了晨报加监控，一个用了事件驱动加两级过滤，抽象掉实现细节也是同一件事。

  后两行开始分叉，而且分叉的位置很关键：一个把它写成了上线的前提，另一个把它写进了待解决问题清单。这个差别比架构图上的任何一处都更值得说。

  没收敛的两件事之一：什么算急

  主动式 Agent 真正难的不是干活，是决定“现在要不要找你”。这件事做不对，产品就退化成一天推八十条通知的看板，用户三天就关掉。

  Anthropic 的处理是把判断实体化：一个专门的分类器加一套安全系统提示词，逐条检查消息；模型侧则靠 Opus 5.5 的判断力。他们在发布里引了内部一句话，说这是他们第一个“有足够判断力、能以合适方式主动做事”的模型。同时也很坦白地写了限制：可能误读对话线索，可能把紧急程度判断错。

  DeepSeek 走的是另一条路：把判断拆成两层。程序层用确定性规则先滤掉大部分噪音，剩下交模型判语义；确定归属的后续事件由程序直接发往对应的 Worker，不再经过中心节点。它甚至做了一组压测，证明单个 Router 会话扛得住——触发速率从每分钟 1 条升到 40 条，单次请求耗时只从 2.5 秒涨到 3.9 秒，摊到每个决定上是 6.4 秒降到 1.6 秒。

  但真正值得看的是另一组数据。

  5 次运行里，模型主动把活分出去了几次

  

  DeepSeek 公开的消融实验原始结果。同一场景、同一个模型，只换提示词，5 次运行里一次都没主动派活；换成系统层的订阅分派，不需要模型自觉。编码工作被替换成只消耗时间的工具，所以衡量的是调度能力。

  左侧那根柱子是 0。中性提示下，模型在 5 次运行里一次都没有调用子 Agent，所有活都在主会话里干，不断被新消息打断，p95 完成时间 29.5 分钟。改成明确要求优先委派之后，4 次派了，但还有 1 次它判断“这活很小”又自己干了，形成长尾。

  这一组数字真正说清的事是：分工不是意愿问题，是机制问题。你可以在提示词里写一百遍“请优先委派”，它每次都会重新判断一遍；而如果归属关系落在库里、事件直接路由过去，就不需要它判断。

  我在自己的体系里踩过同一个坑。曾经把“什么时候该派给子 Agent”写成提示词规则，结果它每次都觉得“这活不大，我自己来”，然后在主循环里被后续事件打断。后来改成任务归属落库、新事件按订阅直接进对应执行单元，这个问题才消失——不是模型变自觉了，是它不再有机会偷懒。

  要点：一个能干活的 Agent，和一个能自己组织工作的系统，中间隔的不是模型能力，是机制。模型再强，也不该被要求每一轮都重新回答“这件事该谁做”。

  没收敛的两件事之二：谁有权按下确认

  第二处是安全，也是我更在意的。

  Anthropic 把安全写在了功能前面。凭据由 Managed Agents 托管，模型从头到尾看不到密码和登录令牌；发消息、动钱、签文件、删数据一律弹审批；prompt injection 的防御来自他们做浏览器操作时积累的那套研究；上线前过了内部红队、一家外部渗透测试公司，再加公开漏洞赏金。分类器的职责也写得很具体：检查每条消息里有没有信用卡号这类高敏信息被带出来。

  DeepSeek 的处理更诚实，也更刺眼。它在 8.4 节自己写下了这两句：一旦云端的 Agent Loop 遭遇服务端入侵或提示词注入而被攻破，其连接的全部端侧设备都面临被控制的潜在风险；即使云端没被攻破，只要端侧环境中的凭据能够进入模型上下文，正常执行过程中同样存在凭据泄露的风险。

  写得很准。然后它把这一段归进了“开放问题”。

  注意：我不认为这是开放问题，这是这套形态唯一的否决项。BYOM 把执行权铺到用户每一台机器上，攻击面随设备数量线性放大，而整个设计里没有一处是默认安全的——它的安全性全部押在“云端那个 loop 不被攻破”这一件事上。押注型的架构可以拿来做原型，不能拿来做产品。

  这不是说 DeepSeek 想得少。恰恰相反，它把风险描述得比谁都清楚——清楚到能直接当作攻击方的路线图。问题在于它选择了先证明调度可行，把信任问题留到下一阶段。这是个合理的工程排序，但它决定了两篇文章的读者不是同一批人。

  交付形态的差别，比架构差别更大

  四家交出来的是产品：有候补名单、限定国家、限定订阅档位、真实用户在用、误判有真实代价。Duet 的公开演示里，那位咖啡品牌老板要为一个 640 美元的卫生许可在支付链接上点批准，要点头一封录用邮件的措辞，要决定要不要试两周包邮。这些动作做错了，损失是真金白银和真人员工。

  DeepSeek 交出来的是原型加一篇长文。它的验证范围写得同样清楚，藏在实验小节的小字里：编码工作用一个只消耗时间的工具代替，因此实验衡量的是系统的调度与协作能力，而非对单个任务的执行能力。

  这句话很关键。它意味着那组 12.4 分钟的中位数、15.7 分钟的 p95，证明的是“这套调度比单会话调度得好”，而不是“这套东西能把活干对”。前者是系统问题，后者是模型问题，两者不该混为一谈。

  所以这两件事的性质不同：一个在验证产品能不能交付，一个在验证架构成不成立。拿长文的深度去要求产品，或者拿产品的完成度去要求原型，都是错位的比较。

  顺带说一个容易被忽略的细节。那篇长文的成本数字并不好看：同样一次实验，完整方案的读缓存 token 是 2323 万；去掉订阅直通后涨到 3177 万，增加 37%，而任务完成时间几乎没变。多会话各自维护上下文，这是纯粹的增量开销。文章自己也承认，这是用更多 token 换更短更稳的完成时间。这笔账在团队规模内可以不算，规模化之后会是主要成本项。

  所以差别落在哪

  我同意一个判断：这五家的实现，本质上是差不多的。

  但这个“差不多”不是贬义。骨架收敛是必然结果——约束相同，最优结构就那么几个。真正的问题是，当骨架不再构成差异，选型该看什么。

  我看两处，都是可校准性。

  第一处是判据能不能被你调。什么叫急、什么值得打断你、哪些事它自己决定就好——这些不该是模型出厂时的一次性判断，应该是你能看见、能改、改完立刻生效的配置。DeepSeek 那套两级过滤里，语义层被明确设计成“面向人类的自然语言扩展点”，这一点比它的架构图更值得抄。

  第二处是权限能不能被你收。哪些动作必须过你的手，是产品设计问题，不是模型能力问题。把审批门做在动作层，比写在提示词里可靠得多——同一个道理，分工不该靠自觉，放权也不该。

  至于 DeepSeek 这篇长文真正的价值，我认为不在它提出了什么。它提出了五个模块，每一个都能在操作系统教科书里找到出处，作者自己也这么说。它的价值在于把“人的注意力是瓶颈”这句体感，写成了一条可测量的工程约束：一个人同时只能跟进 3 到 5 个活跃会话，所以多任务的上限不在模型，在人。然后用一组能复现的实验补了一刀：靠提示词管不住分工。

  这两件事，比任何一张架构图都有用。

  要点：骨架已经收敛，接下来比的不是谁的架构更漂亮，而是谁敢让用户把判据和权限都握在自己手里。前者是论文，后者才是产品。

  引用与来源

  本文依据

  • DeepSeek 产品部 · Super-agent 设计探索：迈向更自主的 Agent 系统 — 原文，2026-10-31。第 2 至 6 节为架构，第 7 节为实验数据，第 8 节为开放问题
  • Anthropic · Introducing Claude Duet — 官方产品说明，2026-10-21
  • Robots Atlas · Claude Duet：6,000 connectors and a morning brief — 含安全栈分层归因表，2026-10-22
  • Technexa · Anthropic introduces Claude Duet, a proactive AI agent — 含 Muse 与 Dots 的横向定位，2026-10-22
  刚刚

• 开源 AI Agent 管理工具 Runner 0.19.0 发布：新增 Linux 支持，分屏界面重构

  Runner 是一款开源桌面应用，用于统一管理 Claude Code、Codex 等 CLI AI 编程代理，开发者可在同一应用内运行多个 agent，或将不同 agent 组成 crew 协同执行任务，通过 runner 命令互相通信。0.19.0 版本对分屏和新建会话界面进行了重构：分屏中每个聊天和终端面板独立成卡片，状态、停止与恢复按钮直接置于标题栏，会话停止后中间显示停止原因和 Resume 按钮，可继续原对话；Mission 模式的内容区、成员侧栏和终端抽屉也分别独立成卡片，并优化了浅色主题配色。新建会话方面，⌘N 快捷键、侧栏、项目页和空面板等多个入口统一为同一个启动器，支持搜索 agent 和 role，显示最近使用的四项，按 1-4 直接启动并沿用保存的配置。此前 0.18.2 版本已开始提供 Linux beta 支持，包含 ARM64 和 x86_64 安装包，Debian/Ubuntu 可安装 .deb 包，其他发行版可解压 .tar.gz 运行 install.sh 安装到 ~/.local，后续支持在设置中更新，下载包会验证签名。此外，新版本修复了 Windows 上 Claude Code 状态 hook 因 shell 启动慢报两秒超时错误的问题，修复共享主账号配置的额外账号在 mission 启动时卡住的问题，Mission 的 inbox 通知改为等 agent 进入 Idle 后再投递。项目目前支持 macOS（Apple Silicon）、Windows x64 和 Linux（beta），采用 MIT 许可证开源。

  事件分析

  CLI agent 的多会话管理正成为 AI 编程工作流中的新兴需求。随着 Claude Code、Codex 等终端 AI 工具普及，开发者常需同时运行多个会话并行处理任务，而 tmux 等传统终端复用方案缺乏对 AI agent 状态的感知能力，Runner 这类专门的编排层工具由此填补空白。其 crew 模式让多个 agent 组队协作、通过命令互相通信，体现了从单个 AI 助手向多 agent 协同的演进方向，与当前业界探索的 agent 编排趋势一致。Linux 支持的加入扩大了潜在用户群，但官方仅在一台 ARM64 虚拟机上验证过，多发行版兼容性和稳定性仍待观察。随着 Conductor 等同类工具涌现，agent 编排赛道竞争将加剧，能否沉淀差异化工作流体验是该类产品能否立足的关键。

  核心观点：CLI 编程 agent 爆发后，管理 agent 本身成了新赛道，多 agent 编排层正成为 AI 开发工作流的下一个竞争焦点。

  原文链接：V2EX 分享发现

  刚刚

• 一条链接即可接管ChatGPT账户：OpenAI紧急修复沙箱逃逸漏洞

  安全研究团队Parameter Labs披露了一个ChatGPT账户接管漏洞的完整攻击链。攻击者只需构造一条普通的公开分享链接并发送给目标用户，受害者点击后，攻击者的JavaScript便能在受害者已登录的chatgpt.com会话中执行，进而以受害者身份调用ChatGPT认证API。整个过程无需安装应用、加入工作区或开启开发者工具，打开链接是唯一必要操作。漏洞链条始于两个看似无害的功能：交互图表与HTML Preview。图表加载的数学库MathLive在主页面注册了postMessage监听器，但未验证消息来源，且允许键盘布局数据中嵌入原始HTML。沙箱内的Preview通过两条消息将恶意HTML注入主页面，再借助srcdoc iframe创建无沙箱文档，该文档继承chatgpt.com的可信身份。面对CSP对内联脚本的封锁，研究人员利用YouTube oEmbed端点的JSONP回调校验缺陷注入载荷——由于CSP本就放行YouTube域名，代码得以顺利执行。验证结果显示，注入代码可枚举受害者对话列表、读取从未分享过的私人对话内容，并将数据外传至攻击者控制的服务器，等效于完全接管账户。OpenAI于10月26日修复该漏洞，定级为P1，复现确认后发放共计5000美元赏金。

  事件分析

  技术层面，该漏洞的精髓在于跨特性组合攻击：Preview沙箱、MathLive消息监听、innerHTML注入、srcdoc iframe、CSP白名单各自单独审视均属合理设计，串联后却构成完整攻击路径。这暴露出postMessage接收方必须同时校验event.origin与event.source，而Trusted Types的身份包装策略不能替代真正的输入清洗，CSP也只能作为纵深防御而非唯一屏障。产业层面，ChatGPT等AI助手沉淀的对话数据敏感度远超普通应用，认证API一旦被同源脚本劫持，影响等同于账户全面失守；第三方开源组件嵌入核心页面的消息通道，也是AI产品供应链安全的典型风险点。后续预计各家AI厂商将加强对分享功能、代码预览等交互面的同源隔离审计，AI安全领域的漏洞赏金机制与红队测试投入也将持续加码。

  核心观点：AI对话沉淀的隐私密度远超普通应用，安全边界必须经受住特性组合的考验，否则一次点击即可致账户全面失守。

  原文链接：Hacker News

  15分钟前

• Codex 优化 Apifox 插件：接口同步耗时从 277 秒降至 100 秒

  一位开发者在 V2EX 分享了借助 AI 编程工具 Codex 优化 Apifox 同步插件性能的完整实践。该项目需同步 2,960 个类、162 个 Controller，并进行 210 次返回类型推断，原始版本完整任务耗时高达 277.2 秒，同步体验缓慢。开发者将问题交给 Codex 分析，发现每个类处理完毕后会固定执行 sleep 100ms 的等待操作，源码中未说明原因，推测是为了给编译器让出资源。基于这一发现，开发者进行了三项改动：将方法处理后的固定等待从 100 毫秒缩短至 1 毫秒；减少无用的调试日志输出；去掉上传 JSON 的格式缩进和换行，改用紧凑 JSON，减小字符串体积与传输量。优化后两次测试显示，类扫描与解析耗时从 245 秒分别降至 90 秒和 72 秒；解析后处理及上传从 31.8 秒降至 16.7 秒和 27.5 秒；完整任务耗时降至 107.4 秒和 100.3 秒。按最新一次计算，总耗时减少 176.9 秒，性能提升约 63.8%。作者建议遇到类似问题的开发者可参考这些改动思路，直接让 Agent 工具执行修改，并在新空间中测试验证效果。

  事件分析

  这则案例展示了 AI 编程 Agent 在存量代码性能优化上的实用价值。sleep 100ms 这类保守设计在工程实践中并不罕见，通常是开发者对资源竞争的防御性处理，但随着代码规模增长，累积延迟会成为显著瓶颈。AI Agent 的优势在于能快速定位这类人工容易忽略的细节，并通过前后数据对比量化验证改动效果。对 Apifox 而言，官方插件存在明显优化空间，社区反馈或推动官方版本跟进改进。更具启发意义的是工作流的转变：开发者不再逐行分析代码，而是将问题定位和方案实施交给 Agent，自己把控改动方向与测试验证，这种人机分工模式正在成为日常开发的新常态。

  核心观点：AI Agent 正把开发者从逐行调试中解放出来，存量代码里祖传 sleep 式的保守设计将成为自动化优化的第一波红利。

  原文链接：V2EX 分享发现

  2小时前

• 开源安卓智能体Droy v0.3发布：AI可操作手机，还能养电子宠物

  开源项目Droy发布v0.3版本，这是一款基于DeepSeek Harness构建的Android端AI Agent应用，项目已在GitHub上完整开源。相比早期版本，新版本采用全原生APP交互方式，摆脱了此前简陋的WebView套壳方案，交互体验明显提升。该项目参考maibot、memos的实现思路，在应用内加入了虚拟宠物玩法，用户可以在应用中养鱼，此次更新还新增了土拨鼠和羊驼两种宠物。值得注意的是，这些宠物人设目前仅为纯陪伴型功能，开发者并未开放宠物人设直接操作手机的权限，以规避潜在风险。在硬件能力方面，v0.3版本补充了手机蓝牙、红外、NFC等硬件的使用能力，进一步扩展了AI Agent对真实设备的控制范围。用户可直接下载APK文件安装使用。开发者表示欢迎用户试用，遇到问题可以在社区留言或到GitHub提issue反馈。该项目此前曾以豆包AI手机平替版的名称在社区推广，定位为利用DeepSeek模型驱动、可实际操作安卓手机的AI智能体应用，兼具工具属性与陪伴属性。

  事件分析

  该项目体现了个人开发者借助开源模型快速构建手机端Agent的可行性。技术架构上存在一个值得注意的设计：操作手机的人设与陪伴型宠物人设被严格隔离，后者不具备设备控制权限，这种权限分层降低了AI误操作的风险；而蓝牙、红外、NFC等硬件接口的接入，则将Agent能力从屏幕交互延伸到物理世界控制。产业层面，此类社区项目与手机厂商力推的端侧智能体方向形成呼应，也反映出DeepSeek等开源模型对个人开发者生态的拉动效应。后续走向上，安全性将是关键瓶颈：允许AI直接操作手机的权限边界如何划定、隐私数据如何保护、误操作如何兜底，这些决定着此类应用能否从极客玩具走向大众产品。

  核心观点：开源模型大幅降低了手机Agent的开发门槛，但权限安全与隐私边界才是决定其能否走向大众的真正门槛。

  原文链接：Linux.do

  3小时前

• Loris Tunnel 2.0 发布：一站式管理 SSH、Dev Tunnel、Cloudflare Tunnel 与 FRP

  开发者发布桌面端隧道管理工具 Loris Tunnel 2.0。该工具最初于今年3月上线，定位为 SSH Tunnel 图形化管理工具，采用 Go 语言与 Wails 框架开发，用于解决本地访问远程 MySQL、ClickHouse、Redis 等服务的连接管理问题，支持自动重连，避免命令行操作和断线逐一排查的繁琐。2.0 版本的升级源于一个实际需求：作者在本地搭建 DevSpace 后，希望在 Codex 额度不足时通过 ChatGPT 网页版调用本地服务。在尝试海外 VPS 反向隧道但延迟不理想后，作者转向微软 Dev Tunnel，其免费、无需自建中转服务器、Tunnel ID 域名可复用，且延迟表现良好，江苏移动连接 Azure 美西节点约 200ms，亚洲节点可低于 100ms。作者借助 Codex 完成 Dev Tunnel 集成改造，并顺势加入 Cloudflare Tunnel 与 FRP 支持。2.0 版本现支持四种隧道方案：SSH Tunnel（本地/远程端口转发、SOCKS5、多级跳板机）、Microsoft Dev Tunnel（公开与私有访问）、Cloudflare Tunnel（借助自有域名暴露本地服务）、FRP（自建 frps 服务器内网穿透），同时保留自动重连、状态监控、日志查看、配置导入等功能。文中还提到有后端同事反馈，相比 DBeaver 基于 Java 实现的 SSH Tunnel 导致 Mac 发烫，该工具性能表现明显更优。

  事件分析

  内网穿透与隧道管理是后端开发和远程协作的刚需场景，此前 SSH、Cloudflare、FRP、Dev Tunnel 各自成体系且均依赖命令行，工具层的统一整合填补了体验空白。值得关注的是开发方式的变化：2.0 的集成改造由 Codex 辅助完成，独立开发者借助 AI 编程快速扩展软件能力的路径愈发清晰，这类中小型工具项目的迭代周期正在被显著压缩。此外，微软 Dev Tunnel 以免费和稳定节点切入，与 Cloudflare Tunnel 形成竞争，隧道服务正成为云厂商争夺个人开发者的入口之一。该工具后续的跨平台稳定性与多隧道并行管理能力，将决定其能否从个人项目走向更广泛的用户群体。

  核心观点：隧道管理这类细分痛点，正成为独立开发者借 AI 编程快速切入效率工具市场的典型切口。

  原文链接：V2EX 分享发现

  3小时前