题：同一天里，Agent 被同时推向了两个相反的方向——一边涌向云端军团，一边学会"不做生成"
今天最值得记的不是某个模型又涨了多少分，而是 Agent 的基础假设在同一天被两拨人从相反方向推开。Anthropic 把 Claude Code 的项目功能重构成云端"协调器 + 工作线程"：一个目标下去，多条 Git 分支在云上并行干活、自动提 PR，背后是内部每天 3 万个 Agent 常态并发、26% 的研发工作已由 AI 主导——Agent 正在被组织成军团。
而另一边，TypeSafe 的 Jev 给出了完全相反的答案：不做生成了，直接读选项的 logits 返回类型化决策与校准概率，browser-use 用它把 Google Flights 订票压到 7.1 秒。一边把 Agent 做重、做多、做成组织；一边把 Agent 做轻、做快、做成一个 if。
同一天，智谱的 ZCode 被扒出静默上传完整 Git 历史，华为抛出"让百万处理器成为一台计算机"的 Peerium 架构。在能力与信任两条曲线同时陡起来的时候，谁先把自己的账本摊开，谁就先拿到下一次下注的资格。
🔥 1. Claude Code 大重构：协调器 + 云端并行 Git 分支 + 共享记忆，Anthropic 内部 3 万 Agent 的技术被免费开放 — 1000 pts
Projects 从一个放提示词的文件夹，变成了一个会自己拉分支、自己提 PR 的协作中心。
Claude Code 的 Projects 功能迎来全面重构，原生支持多 Agent 玩法——用户下达目标，Claude 在云端派生多条 Git 分支并行干活，写完直接提 PR。整个架构的核心是一个叫 Coordinator（协调器） 的大脑：开发者不需要再手把手教 AI 每一步怎么走，只要在主对话框下达一个高阶目标，比如"把整个鉴权模块重构为 OAuth 2.0 并补齐自动化测试"，协调器就会自动把复杂工程任务拆解为多个子任务，并调度分配给并行的"工作线程"。
关键在于每个工作线程是什么：一个运行在云端独立环境里的 Claude Code 实例，拥有完全隔离的代码副本，各自拉出独立的 Git 分支，在后台同时推进不同模块的代码编写与单测；活干完自动在后台提交代码并生成 PR。协调器还会跟踪各子任务的上下文依赖，提醒开发者先合并哪个分支、后测试哪个模块。
重构真正解决的是过去多 Agent 的老毛病——各写各的、会话间靠人工传递上下文、信息损耗大，结果是"Token 消耗巨大，速度也没快哪去"。A 社给出的答案是共享记忆：所有分支线程在执行过程中沉淀的技术规范、架构决策与团队偏好，都会实时同步回共享记忆，于是 Claude 能记住"发布时间改到了周五""导出功能为什么被取消""访问账单服务前需要联系谁"。整个过程支持完全异步，开发者下完指令合上电脑就能走，甚至可以通过移动端查看各线程进度并微调指令。
但 A 社也在同一天披露了这项能力的上限：在其内部研发平台上，常态化并发运行着多达 3 万个 AI Agent，云端没日没夜地写代码、跑实验、改架构，单月触发的决策量超过 10 亿次；按 Epoch AI 的 AL0–AL5 自动化分级，内部 26% 的研发任务已达 AL4 级（AI 凭高阶指令端到端完成），而这个数字在 2026 年 2 月还不足 1%，半年 26 倍；若把标准放宽到"深度人机协作"（AL3）及以上，占比超过 90%。A 社也坦诚提醒：多 Agent 肯定不便宜，请随时注意自己的 usage。Projects 目前为 beta，首批面向部分 Claude Pro 和 Max 订阅用户（且需使用云会话项目），接下来一周逐步放量，Team、Enterprise、Cowork 还需等待。（本条与本期第 3 条同源于 Anthropic 的自披露报告，分别从产品与治理两个角度呈现。）
→ https://www.qbitai.com/2026/09/491711.html
🔥 2. 智谱 ZCode 被扒静默上传完整 Git 历史：313MB 加密快照直传阿里云 OSS，官方致歉并承诺开源代码库 — 982 pts
"你硬盘上那份 313MB 的密文，你打不开，ZCode 客户端自己也打不开，全天下只有智谱后端的私钥能解。"
智谱的 AI 编程桌面端 ZCode 今天被扒出一个大问题。开发者 ferstar 发布取证博客，称只要登录了账号，ZCode 会在后台静默把整个工作区——包括完整的 .git 历史、LFS 大文件缓存、reflog 和全局配置——打包加密上传到阿里云 OSS。消息迅速在国内技术圈传开，有开发者用自己的 Mac 顺着取证路径重跑了一遍，结论是"属实，而且不是会不会，是已经"。
起点很普通：ferstar 清理磁盘时发现 ~/.zcode 占了 700 多 MB，一路挖下去，在 v2/checkpoints/ 里看到一个 313MB 的 .enc 加密文件，旁附状态元数据——这是一份标记为 baseline 的全量快照，workspaceSizeBytes 345MB，而 failureCount 已经到 564（上传失败了 564 次，还躺在 pending 里等重试）。他把客户端的 app.asar 逆向，还原出完整上传链路：客户端先向 zcode.z.ai 请求上传凭证，拿到 OSS 表单签名、动态 Object Key、大小限制和一把加密公钥；随后在本地打包、流式加密，根本不经过智谱的业务服务器，直接走表单直传阿里云 OSS，再由 OSS 回调通知智谱后端登记。
最讽刺的是加密方式。标准信封加密——内容用随机对称密钥走 AES-256-CTR，对称密钥再用 RSA-OAEP 包裹——但公钥是服务端动态下发的，私钥从头到尾只在云端。快照里装了什么？密文解不开，但生成时留在本地的 Manifest（42,411 个文件的清单）是明文的：.git 一个目录占了 86.6%（.git/lfs 56.8%、.git/objects 29.6%、.git/logs 0.2%），剩下的源码文档只有 13.4%。也就是说一旦上传，云端拿到的不只是当前工作区代码，而是仓库自建库以来的全部历史——早就被删掉的敏感配置和历史 key、没推远端的本地分支名（等于未公开的研发动向）、.git/config 里写的内部 GitLab 域名，连全局配置文件 settings.behavior.json 都会被跨工作区打包随快照上传。
真正让开发者炸毛的是开关形同虚设：设置里"优化体验"和"仓库快照索引"两个开关，一个只管要不要拿数据训练、一个只管服务端要不要建索引，关了本地打包上传一点不落；客户端代码里负责捕获上传的 sidecar 在启动时无条件实例化，唯一门槛是能拿到登录 JWT；触发点是每次发 Prompt 前的 captureBeforePrompt 和任务结束时的 repo-wiki-update，单个活跃会话最多出现 62 次捕获。而隐私政策里只写会收集"对话中提交的文本、文件和代码"，对"打包整个工作区和完整 Git 历史"只字未提。取证者给出的有效防御是在文件系统层加锁（macOS chflags uchg、Linux chattr +i），代价是检查点回滚和时间线界面失效。
智谱官方已作出回应：称问题源于 ZCode 的代码库索引功能，该功能旨在本地生成仓库索引以支持会话检查点恢复、历史版本回退及 Repo Wiki；Repo Wiki 功能在生成 Wiki 页面时可能触发仓库数据上传，上传数据在云端生成页面后立即销毁、不会保存；由于该功能上线初期默认开启，部分用户因此受到影响，官方致歉，并表示相关问题已经修复、近期将开源 ZCode 代码库。
→ https://www.oschina.net/news/502589
🔥 3. Anthropic 首次公开"AI 发展有多快"的三把尺子：26% 研发由 AI 主导、3 万 Agent 常态并发、10 亿决策里拦下 0.002% — 958 pts
与其互相吹"我们芯片多、我们跑得快"，不如直接把实验室内部数据摊开，给"AI 发展速度"定一套可测量的指标。
Anthropic 今天发布三份方法论性质的度量，试图给"AI 发展到底有多快"这件事定标。第一份叫"AI 主导研发（AI-led R&D）"，借用 Epoch AI 的自动化分级（AL0 到 AL5，AL3 是 AI 协作、AL4 是 AI 主导）来统计 Claude 在自己公司内部研发里到底扮演什么角色。结论很克制：截至 2026 年 8 月，Claude 在任何抽样任务子集上都还没有做到完全自主，但已经主导了约 26% 的 AI 研发工作，处于"AI 协作"及以上水平的工作占比超过 90%。这组数字直接连着"递归自我改进"（RSI）这个悬案——Anthropic 想表达的是：AI 还没到完全自己改自己的程度，但"AI 参与研发"已经不是概念，而是正在发生的日常。
第二份量的是"对 AI 智能体的监督"：它称自己最常用的内部平台上，任意时刻都有约 3 万个智能体在做研究和工程。监督分两层——在线监视器实时看、覆盖率 100%，离线监视器事后翻。每周约 10 万份转录被审查，其中约 50 份升到人工处理；在超过 10 亿个决策里，只有 0.002%（约 1/47000）被拦截，监视器每千个会标记 1 到 2 个。
第三份最有意思，量的是"算力分配"。Anthropic 抽查了 7 月 13 到 20 号那一周的全部算力，把工作负载分门别类，看有多少算力给了安全研究。结果：投入 AI 研发的算力里约 6% 给了安全方向，而 AI 主导研发的算力里约 12% 给了安全。它自己强调这些是"刻意保守"的估计——既推进能力又推进安全的任务不计入，模型安全分类器的算力也不算在内。深意在于：算力是 AI 研发流程里"最可验证的输入"，真要搞 AI 发展的调控（pacing），算力分配是最容易盯住的杠杆。
配这几段数据的还有一个政策动作：Anthropic 明确提出要把独立的第三方评估者嵌入实验室、给予和内部团队对等的访问权限，也在推 AAIF 政策提案——Dario Amodei 之前公开呼吁过对整个行业的发展节奏做协调。Anthropic 的立场很清楚：鼓励其他前沿实验室用同一套标准公布同样的数字；同时它承认安全研究与能力研究难以区分，开发者会有动力把界线画得对自己有利，所以举证责任该放在开发者身上，去证明"这是安全相关工作"。这些数字绝对值未必多漂亮，价值在于给"怎么比较"定了一套统一标尺——这在"各家都在说自己最安全"的环境里，至少是个能对着谈的东西。
→ https://www.oschina.net/news/502569
→ https://www.qbitai.com/2026/09/491711.html
🔥 4. 一个"不做生成"的模型正在 GitHub 上炸开：TypeSafe 的 Jev 把浏览器 Agent 压到 7.1 秒，一天内星数从 842 涨到 4637 — 934 pts
它不写回复、不产出代码、不解释推理过程——只回答类型化的选择题，然后让代码去执行。
一条容易被漏掉但可能更重要的信号出现在 GitHub 上：browser-use/jev-ultrafast 昨日还只是简报里的一行脚注（★842），今天已冲到 ★4637、283 fork，一天之内涨了 5.5 倍。它背后是一个正在被单独命名的新模型类别——TypeSafe 的 Jev，官方文档定义为"旗舰模型，也是第一个 System One 模型"。
System One 模型与 LLM 的分野在于它不做生成：输入是一段 state（字符串、JSON 对象或文本数组），输出是类型化答案与概率，而可能答案由开发者用三种原语定义——Choice（从定义好的集合里选一个，如 billing / technical / account）、Score（按有序的描述性层级打分，如 0=平静、1=不满、2=非常不满）、Noul（回答一个 yes/no 问题并返回其为真的概率）。官方明确写着：System One 模型不写回复、不产出代码、不生成推理说明。它们的概率是针对结果优化过的"校准概率"（calibrated），目标是反映不确定性；名字借自卡尼曼《思考，快与慢》——System 1 是快而直觉的判断，这里强调的是快而聚焦的判断。
jev-ultrafast 就是把这套东西装进浏览器：它构造一个动态、带索引的动作空间，每次观测产生一张元素表（[1] button Change ticket type · Round trip、[2] combobox Where from? · San Francisco…），支持的操作只有 CLICK、TYPE_TEXT、SELECT、SCROLL_UP、SCROLL_DOWN、WAIT、DONE、BLOCKED，且只提供被支持的操作与目标。一次 TypeSafe 请求同时回答"选哪个操作"和"操作哪个目标"（目标问题是投机式的——若操作是 CLICK，则只有 click_target 能执行），两个决策只走一次网络往返；只有当操作确实是 TYPE_TEXT 时，才由一个小模型（对照实验用的是 inception/mercury-2.5，关闭文本推理）去生成要输入的文字。作者称整个策略里没有任何站点专用的动作脚本或预置字段字符串。
性能数据来自仓库公开的 performance.md 与测量 JSON：视频里 Google Flights"苏黎世→伦敦"任务用时 7.073 秒（1× 速度，含实际文本生成与加载等待）；更严格的是六次交替对照运行（同一任务、同一 Chrome profile、同一目标与独立结果校验器、1120×780 视口、jev-1.13.0）：中位任务时间 9.450s → 7.092s（降低 25.0%），中位 TypeSafe 请求数 22 → 17，中位浏览器协议调用 1,092 → 101。作者自己也把话说清楚了：三对样本太少，不足以做统计强论断（双侧符号检验 p = 0.25），这是小规模受控输入对比，不是广谱 Agent 基准。
更值得注意的是生态已经成型：tamaratran/fast-jev-compaction（★2618，Claude Code 插件，用 Jev 决策替代内置的压缩摘要——它从不改写内容，只删除 Jev 判定为不再需要的工具调用与结果，用户与助手的文本保持逐字原序，对每个调用问两个 noul 问题：调用本身是否仍然重要、结果是否需要保留原文）、TheoLeeCJ/SemIf（★1460，用开放模型 + WebGPU 在浏览器里本地跑决策模型，把"读选项概率而不解码"与"逐 token 写出同一分布"放在一起对比测速，站点明确声明是独立研究项目、与 TypeSafe 无隶属关系）、vinnylarouge/jevlike（★837）、jarrodwatts/jev-trader（★775，每个 Monad 区块做一次 AI 交易决策）。
→ https://github.com/browser-use/jev-ultrafast
→ https://docs.typesafe.ai/introduction
→ https://github.com/tamaratran/fast-jev-compaction
🔥 5. 华为发布 Peerium 计算架构：让百万级处理器成为一台计算机，同日华为云 All in Agentic Cloud — 912 pts
继昨天的 NPO 超节点昇腾 960 之后，华为把答案往前推了一层——不再问"怎么连更多卡"，而是重写"计算机"本身的定义。
华为今天发布面向 AI 时代的全新计算架构 Peerium，其目标表述异常直接：实现百万级处理器成为一台计算机，以满足不断发展的 AI 算力需求。其技术底座是嵌套并行、统一内存寻址、平等互联。华为的措辞很重：Peerium"突破了图灵范式"，提出 Nested BSP；"突破了冯·诺依曼单机架构"，颠覆了长久以来的主从架构，从而实现百万级处理器真正成为一台更大的计算机。
实现它的关键互联技术是灵衢——一个开放协议，可无限扩展地联接 CPU、NPU、内存、SSD、网卡和交换机的高速总线，有了它才能实现计算、存储和网络的平等互联。基于灵衢的计算系统有四大特征：一是协议归一、内存语义——将十余种互联协议统一为灵衢协议，互联带宽从百 GB 级提升至 TB 级，RTT 通信时延从 7 微秒压缩至 2 微秒，支持超节点内全局内存统一编址；二是多样算力、异构协同——CPU、NPU、内存、SSD 通过灵衢直接互联，实现去中心化平等访问，CPU 和 NPU 资源可灵活配比，并通过分层分级 Transformer 硬加速、解耦 Attention 与 FFN，实现 AF 分离部署；三是分级存储、全局池化——以混合介质资源池化解决激活值缓存问题，把 DDR 作为 NPU 的"第二内存"，千亿级、数千维向量检索性能翻番，同时降低 10T 大模型训练对单卡 HBM 的容量需求，助力提升集群 MFU；四是光电互联、灵活组网。落地节奏上，Atlas 950 超节点是 Peerium 架构的首代产品，25.6 万卡的 Atlas 950 超节点集群已经在部署中，基于 NPO 的 Atlas 960 系统正在测试中。华为轮值董事长徐直军表示："AI 时代，华为基于开创的 Peerium 计算架构，持续打造满足客户训练和推理需求的超节点和集群，让算力无处不在，让智能无所不及。"
同一天，华为云把整场发布会的调子定成了 "Agentic Cloud"。华为云 CEO 周跃峰那句被反复引用的判断是：智能体时代基础设施的核心，不再只是给算力，而是"让每一个 Token 更高效"。最能说明态度的是那个出圈的名字——灵衢昇腾 950 智算集群，面向全球的服务今年 9 月 30 日国内商用、11 月 30 日海外商用：全链路五级快速恢复机制保障云上训练 40 天稳定运行、10 分钟内故障恢复，围绕调度、缓存、算法协同优化后 Token 吞吐比上一代算力提升 20%；配套的 CMS 记忆存储方案提供 PB 级记忆空间、存储容量比业界同类翻一倍、TB 级记忆高速读取性能提升 50%——直接瞄准智能体长程任务对记忆的胃口。平台层走"商用 + 开源"双轮：商用版智果 AgentArts 已服务 100 多家企业、计划 12 月 30 日海外商用；开源版 openJiuwen 社区 Star 超 5 万、下载超 329 万，并拉上中软国际、软通动力、北明软件出伙伴商用版，资产库里有 5000 多个通用资产和 1000 多个行业资产。再往下是"行业 AI 梦工厂"，落地项目超 1000 个，本次新上线政务智能专区（已聚 24 家首批核心伙伴）与 AI 硬件专区（联合 15 家伙伴覆盖 AI 眼镜、AI 玩具等 20 多种终端）。
→ https://www.oschina.net/news/502587
→ https://www.oschina.net/news/502586
🔥 6. 阿里发布 Qwen3.8-Omni-Flash：音频输入价格降幅超 98%，把多模态从"看得懂"推向"干得成" — 888 pts
多模态感知便宜到这个份上，才有资格说往生产力场景走。
阿里通义 Qwen 团队今天放出新一代"原生全模态"模型 Qwen3.8-Omni-Flash，标题文案是"耳聪目明，办事得力"——前四个字是这类 Omni 模型的老本行，后四个字才是这次的重点：从"理解全模态内容"往"规划任务、调用工具并完成创作"推。一个最直接的信号是价格：相比上一代 Qwen3.5-Omni-Plus，API 每小时音频输入价格降幅超过 98%，每小时音视频输入价格降幅超过 93%。
模型本身支持 1M 长上下文，支持文本、图像、音频、视频输入；在累计 29 项评测里，相比 Qwen3.5-Omni-Plus 平均得分提升超过 25%；在音频 Agent、Coding、长程任务这几个方向上，WildClawBench-MM 大幅提升 36.5 分，AgenticVBench 提升 22.3 分。和 Gemini 3.8 Flash 比，Qwen 官方的话术是"音视频能力接近、音频能力整体超过"。
真正值得看的是它把多模态推进到了"端到端干活"的落地。团队开源了两套配套：Qwen-MM-Plugins（音视频生产力插件，支持 Codex、Claude Code、Qwen Code、Gemini CLI 等多个 Agent Harness）和 Qwen-Live Harness（面向实时交互的原生运行环境），并基于它们跑了几个完整工作流——Music2MV 做 MV 创作、短剧翻译出海、两三小时长电影解说、Video2Note 把视频教程榨成带截图的 PDF 笔记、Omni Skill Creator 从操作演示里提炼 SOP 变成可复用的 Agent Skill；翻译还强调能保留原说话人的音色特征。两个技术点值得单独拎出来：其一"Agentic 长音视频理解"——面对数小时视频，模型不再从头到尾逐帧处理，而是从问题出发自主决定该看什么听什么，通过由粗到细的多轮取证定位关键信息；OmniVideoBench 上 Agentic Understanding 把准确率从 63.4 提到 67.8，同时把单次查询的 Token 消耗从 145,736 降到 79,117（降约 45.7%），这种"按需感知"对成本和效率都是实打实的好处。其二是把模型本身当研发工具——团队让 Qwen3.8-Omni-Flash 在 12 小时内提升 Qwen2.5-Omni-3B 的四川话识别能力：它自主选评测集、定基线、听语音样本诊断问题、构建训练数据，4 轮实验累计造了 3,413 条数据，把字符错误率从 25.79% 压到 15.30%（相对降约 40.7%），通义想讲的是一套"大模型负责研发、小模型面向业务"的新范式——Agent 不再只是调用模型，还能参与优化模型。此外还有一条异步更新的线：Qwen3.8-Omni-Flash-Realtime 面向持续低延迟交互，支持 WebSocket 和 WebRTC，首发"听声辨位"——融合空间声音与视觉信息判断声源方向和距离，是首个支持这项能力的全模态大模型。
→ https://www.oschina.net/news/502567
🔥 7. 中国 AI 登上 Science：达摩院 DAMO RADAR 一个模型看腹部 146 种病，准确率超过 26 名放射科医生中的 23 名 — 864 pts
2016 年 Hinton 说"应该停止培养放射科医生"，十年后，医疗影像依然是 AI 的硬骨头——直到今天。
学术期刊的"王者" Science 正式刊发一项来自中国的重磅研究：DAMO RADAR，据介绍是全球首个专家级的通用影像 AI 模型。它能看腹部 18 种解剖结构的 146 种病，比很多影像科医生看得还准，而且模型、代码、框架全部开源。研发团队是阿里达摩院——过去几年他们用 AI 识别 CT 中肉眼难见的早期癌症病灶，在胰腺癌、胃癌、肠癌等专病上取得重大突破，发表过 5 篇 Nature Medicine。但做着做着，达摩院高级算法专家张建鹏说觉得不对劲了：一个病种啃下来至少两三年，人类疾病成千上万种，这么搞一辈子都搞不完；更棘手的是，真实世界里病人不会只带着一种病来，一份 CT 影像里很可能同时存在多种器官、多种病变。
达摩院因此联合浙大一院等全球众多医院向腹部 CT 发起冲击。选腹部，是因为这是临床公认最难的影像场景——浙大一院放射科主任肖文波介绍，年轻医生通常最害怕被分到腹部组，因为腹部涉及消化系统、泌尿系统、生殖系统，肝胆胰脾肠道全挤在一起，肠道还盘绕整个腹腔，所有器官几乎都是软组织、密度接近，全靠肉眼对密度差的敏感度把病灶揪出来；此前虽有针对肺结节之类的 AI 辅助工具，但腹部太复杂，一直是个禁区。
效果做了多层严格验证：在内部近 3.9 万例真实世界连续队列中，RADAR 的平均 AUC 达到 0.913（AUC 衡量区分患者与正常人的能力，超过 0.9 就算优异）；随后在来自 8 家外部医院的超过 2.4 万例 CT 上验证（覆盖不同地区、不同扫描设备），AUC 仍达 0.895；而且 RADAR 还泛化到了急诊场景——急诊因时间紧急、来不及等造影剂发挥最佳效果，CT 成像效果偏差，且 RADAR 的训练目标并未包括急诊，但团队拿 2.7 万例急诊数据一测，AUC 依然有 0.904。在肝癌、胰腺癌、胃癌、肠癌四种癌症上，他们进一步用"病理金标准"（以病理活检结果作为 Ground truth）考验 RADAR，AUC 仍达到 0.891–0.984。最能说明水平的是人机对比：来自 14 家医院的 26 名放射科医生与 RADAR 在同一批病例上各自独立诊断，RADAR 的准确率超过了其中 23 名医生，只稍弱于 3 名资深医生；而在人机协同场景中，医生有 AI 帮助时读片整体敏感度提升约 10%、平均阅片时间减少 30% 以上，"初级医生 + AI"的配置敏感性甚至超过了资深医生独自阅片。
技术路线上，过去的医疗影像 AI 用的是监督学习——让医生一张一张标注 CT，标注成本巨大且模型只认被标注过的那几种病。RADAR 走的是视觉-语言对比学习：医院里天然存在大量 CT 影像与对应的诊断报告，RADAR 直接从影像和报告文本的对应关系中学习，不需要医生额外逐片标注——有点像医学生跟着主任查房，主任看片子时说"肝脏有一个低密度灶，考虑血管瘤"，学生听多了自然就知道什么影像特征对应什么诊断。
→ https://www.qbitai.com/2026/09/491875.html
🔥 8. 智谱上线 GLM-5.3-FlashX：把国产卡上的推理速度顶到 200 token/s — 838 pts
上一代 GLM 在 10 万张国产芯片上从零搭起推理服务的那点底子，这次变成了产品化的速度。
GLM-5.3 前阵子以 "Ox Alpha" 的匿名身份上线时，就已经是 OpenCode 和 OpenRouter 双平台调用量最大的模型。今天智谱给它加了个更快的版本，名字也直白——GLM-5.3-FlashX，最高 200 tokens/s。背后的一张牌值得单独说：上一代 GLM 上线时，团队是在10 万张国产芯片组成的集群上把推理服务从零搭起来的，当时的难点是内存带宽受限、还要扛 1M 上下文和多模态；这个"国产卡上把吞吐压出来"的底子，正是这次 FlashX 提速的前提——智谱的措辞是"在 10 万张国产芯片提供的推理算力基础上，进一步加大对 Infra 侧的投入与推理优化"。
短期看，这是一次产品化的速度升级：Flash 系列本身就是"同尺寸最强智能 + 极高性价比"的定位，这次把速度抬上去，等于在智能、价格、速度三个维度上都要占住；API 使用独立的 Model Key（GLM-5.3-FlashX），和原来的 Flash 分开计费。比较少见的是，智谱这次把发布说明写得特别松弛——"大大方方、好好用用、嗖嗖嗖嗖"，连标题都透着股不端着。对比上一代那段"坦白说，在 GLM-4.7 之前，我们内部用 GLM 写代码多少带着被迫的成分"的长文，同一个团队前后两种语气，也算是自家模型从"亲儿子"变成"每天离不开的伙伴"的一个注脚。作为权重侧的对照，zai-org/GLM-5.3-Flash 目前在 HF 镜像上有 2441 个 likes、266 万余次下载，可见这条 Flash 线的实际装机面。
→ https://www.oschina.net/news/502582
🔥 9. Kimi Code 发布桌面客户端：三种任务模式 + 卡片式审批，把命令行 Agent 搬进图形界面 — 812 pts
目标人群写得很明确：能在 IDE 里用命令行 Agent 的开发者，也想在图形界面里用。
Kimi Code 项目发布了其桌面客户端，支持 Mac 和 Windows 平台。据介绍，客户端支持用图形界面打开本地项目，通过对话让 Agent 读代码、改代码，右侧看改动、底部终端验结果，网页类项目还有内置浏览器随会话常驻、页面信息与 Agent 共享。
模型接入方面，登录 Kimi 账号后可用官方模型（没订会员读不了），也可以手动添加第三方供应商——填 API Key、Base URL 和模型信息就能切过去；支持 @ 引用文件或目录，用 /undo 回退最近修改。
几个值得注意的设计点：任务模式做了三种——"目标"（长任务持续推进）、"计划"（先出计划、确认后再改）、"Swarm"（把可拆分的任务丢给多个子代理并行执行）。审批做成了卡片式：遇到命令、文件修改、计划会弹卡片让你批准或拒绝，权限分三档——始终询问、必要时询问、完全自动；官方建议第一次用它打开不熟悉的项目时先用"始终询问"，确认范围再调。把这条和最近两周的动向放在一起看会更清楚：从 Casbin Gateway 这类本地 Agent 管理网关、到各家 Harness 的图形化客户端，"Agent 的治理层与入口层"正在从命令行参数变成可以直接交付给普通开发者的产品。
→ https://www.oschina.net/news/502565
🔥 10. Manus 重生第 17 天，估值就要翻倍：正在推进 5 亿美元融资，目标 40 亿美元 — 786 pts
绝大多数"被巨头买走、交易撤销、老股东买回"的案例，买回后估值是下跌或持平——Manus 属于极少数后者。
Manus 恢复自由身才半个多月，"突然"身价倍增。最新消息：Manus 正在推进新一轮约 5 亿美元融资，目标估值约 40 亿美元。这是它与 Meta 完成拆分、恢复独立运营后的第一轮融资；据彭博援引知情人士消息，这轮融资已接近完成，但谈判仍在进行，最终金额和条款仍可能变化，最新资方身份尚未披露，腾讯、HSG 和真格基金等现有股东也没有公开确认是否继续加码。
把时间线拉直看，戏剧性相当密集：2025 年 3 月 Manus 发布通用 Agent，一夜刷屏；4 月 Benchmark 领投 7500 万美元，投后估值约 5 亿美元；12 月底 Meta 宣布以 20 亿美元收购 Manus（收购前 Manus 刚宣布 ARR 突破 1 亿美元、拥有数百万用户）；今年年初这笔跨境交易解除，Meta 与 Manus 开始业务和数据拆分；5 月彭博曝出创始人肖弘、季逸超、张涛曾讨论融资约 10 亿美元把公司从 Meta 手中买回，并考虑后续通过合资结构运营、最终赴港 IPO；8 月腾讯、真格基金、红杉中国等原有投资方以约 20 亿美元从 Meta 手里买回 Manus 股份（财新披露：腾讯接下 Benchmark 原先持有的股份，并成为 Manus 最大股东）；9 月 1 日Manus 正式宣布恢复独立运营，创始团队重新领导公司，并把自己重新定义为一家"独立 Agent 实验室"；再过了 17 天，40 亿美元的新报价就来了——从 5 亿到 20 亿再到 40 亿，只用了一年半。
为什么经历这么大一场风波，Manus 还能迅速谋求更高估值？答案在业务数据里：据财新报道，截至今年 6 月底，Manus 的 ARR 已经达到约 4 亿美元——从去年 12 月到今年 6 月底大约半年时间，ARR 增长到此前约 4 倍；The Information 披露的口径甚至更高，称今年 6 月其年化收入运行速率已达 4 亿至 5 亿美元。如果只用公开 ARR 粗略计算：去年底 Meta 以约 20 亿美元收购，对应当时超 1 亿美元 ARR，大约是 20 倍 ARR；若按今年 6 月底约 4 亿美元 ARR 计算，如今 40 亿美元目标估值对应约 10 倍 ARR——也就是说，虽然整体估值绝对值翻倍，但每 1 美元 ARR 对应的估值差不多砍半了。8 月被买回时，Manus 收入已经明显高于 Meta 收购时的水平，所以这其实是原股东按旧估值拿回了一家规模更大、营收更好的公司；而现在曝光的 40 亿美元，是资本市场在给这部分增长定价。
→ https://www.qbitai.com/2026/09/491764.html
📌 今日趋势总览
本文原创作者：易君召，详见：https://www.yijunzhao.cn/authors/yijunzhao，转载请注明出处。
原文链接
欢迎访问 小易撩挨踢