近日，Kimi AI 对其订阅政策进行了更新，Allegre...
Anthropic 近日发布声明，指控 DeepSeek（深...
近日，有 tech 爱好者在 V2EX 社区发帖吐槽热门 A...
当前AI行业普遍存在“跑分高、体验差”的怪象。文章揭露了两大...
本文曝光了月之暗面 Kimi K2.5 模型的完整系统提示词...
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 秒。
但真正值得看的是另一组数据。
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 个活跃会话，所以多任务的上限不在模型，在人。然后用一组能复现的实验补了一刀：靠提示词管不住分工。
这两件事，比任何一张架构图都有用。
要点：骨架已经收敛，接下来比的不是谁的架构更漂亮，而是谁敢让用户把判据和权限都握在自己手里。前者是论文，后者才是产品。
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 爆发后，管理 agent 本身成了新赛道，多 agent 编排层正成为 AI 开发工作流的下一个竞争焦点。
原文链接：V2EX 分享发现
一位开发者在 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 式的保守设计将成为自动化优化的第一波红利。
原文链接：V2EX 分享发现
开源项目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的开发门槛，但权限安全与隐私边界才是决定其能否走向大众的真正门槛。
原文链接：Linux.do
开发者发布桌面端隧道管理工具 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 发烫，该工具性能表现明显更优。
核心观点：隧道管理这类细分痛点，正成为独立开发者借 AI 编程快速切入效率工具市场的典型切口。
原文链接：V2EX 分享发现
libcr 项目组在 V2EX 发布开源远程桌面应用 crDesk，支持 Windows、Linux 和 macOS 三大平台。项目采用 C++ 实现，底层基于 Chromium、GPU 与 WebRTC 技术，可调用设备硬件视频加速能力，保障远程画面传输的流畅度与低延迟。功能方面，crDesk 支持屏幕共享、远程键鼠控制、文本与图片剪贴板同步，以及系统声音和麦克风共享；文件传输支持队列管理、进度显示和完整性校验。应用还提供局域网自动发现、多标签页与独立窗口等体验优化。安全机制上，通过连接密钥、临时访问令牌、可信设备配对和独立权限管理控制访问。针对不同操作系统特性，项目分别提供 Windows 服务集成、Linux Portal/EIS 与 KMS/UHID 集成，以及 macOS 登录后自动共享能力，可按平台配置锁屏访问或无人值守模式。该工具定位于局域网或 VPN 环境下的远程操作场景，源代码已在 GitHub 平台开源，供社区使用与审查。
核心观点：WebRTC + GPU 硬件加速的架构路线正在成为开源远控的技术主流，自托管远程桌面正向企业内网与隐私敏感场景加速渗透。
原文链接：V2EX 分享发现
