AWS 宣布更新 Amazon Bedrock AgentCore 运行时——其面向智能体的托管计算层，会话启动速度现已提升至多 15 倍，算力扩展至 4 倍（最高 8 vCPU 和 32 GB，容器镜像最大 10 GB），运行效率提升至多 68%，同时每个会话仍运行在各自硬件隔离的 Firecracker MicroVM 中。无论镜像大小或并发量如何，会话启动均在 2 秒以内，空闲智能体可缩容至零，智能体可挂载文件系统（如支持 FUSE 的 Amazon S3 桶）并保存工作成果，使数据始终留在信任边界内。该运行时现已在北美、南美、欧洲和亚太地区的 AWS 区域可用。
推荐理由：AgentCore 运行时的新版本将会话启动、算力上限和内存计费一并调整，为需要长时间运行的智能体在隔离与成本之间提供了新的取舍。
AWS 已开源 UAEF（Universal Agent Evaluation Framework，通用 Agent 评估框架），这是一个与框架无关的系统，通过适配器将来自 LangGraph、LangChain、Strands Agents、Amazon Bedrock AgentCore 和 Langfuse 的 Agent 轨迹归一化为统一的 AgentTrace，然后用覆盖 7 个维度的 36 项内置指标进行打分。结果按实验存储在 Amazon DynamoDB 和 Amazon S3 中，使团队可以将 Agent 版本与基线进行比较，用默认 5% 的阈值标记回归，并生成统计报告以及由 LLM 撰写的洞察。文章称，来自电信、医疗和金融服务领域 12 个组织的客户在发布前使用了 UAEF，Apache 2.0 代码、Python 库、CDK 部署和各框架 notebook 均位于 awslabs/uaef GitHub 仓库中。
推荐理由：AWS 团队开源 UAEF，用适配器把不同框架的 Agent 轨迹统一成一种格式，再以 36 项指标跨 7 个维度打分，为跨框架比较 Agent 版本提供了一套可复用的评测层。
vLLM-Omni 将 MiniMax H3-Image 引入 NVIDIA Vera Rubin，在四块 GPU 上测得原生 4096×4096 文本到图像的中位延迟为 0.87 秒，并在另一吞吐配置下达到每小时 6,115 张图像。H3-Image 是一个开放权重的文本到图像与编辑模型，将 Qwen3-VL 编码器与 33.1B 稠密 DiT 及图像 VAE 相结合，在六步采样内处理两项任务，最多支持 16 张参考图像。团队报告了 MXFP8 DiT GEMM、Ulysses SP4、AdaLN 缓存以及一项将解码时间从 2.635 秒缩短至 0.213 秒的 VAE 解码改动，并列出了面向 AMD、Intel、华为昇腾和摩尔线程硬件的配置方案。
推荐理由：vLLM-Omni 的基准测试显示 MiniMax H3-Image 在 Vera Rubin 上以亚秒级 4K 延迟运行，并提供了各硬件配置及服务经济性成本模型。
vLLM 在 day 0 支持 Thinking Machines 的 Inkling 2 Small，这是一个多模态文本与视觉 MoE，总参数 594B、激活参数 17B，上下文最高可达 1M token。该集成加入了带 PDL 的内核融合、用于 prefill 的序列并行（在 TP4 下将 8K token 的 prefill 步骤缩短 22%，TP8 下缩短 26%），以及一个 Gluon 相对注意力解码内核，将 100K 上下文下 batch-1 的解码步骤从 15.1 ms 降至 4.8 ms。vLLM 报告在 GB200 上 TP4 时每用户最高 630 TPS，接受长度为 3.5，并且还通过 SkyRL 支持 LoRA 和 RL。
推荐理由：vLLM 在发布当天即支持 Inkling 2 Small，并给出内核融合、序列并行和 Gluon 解码内核的具体优化数据，可供部署大 MoE 模型的团队参考。
vLLM 报告称，在单台 NVIDIA Vera Rubin NVL72 机架上服务 DeepSeek-V4.1-Flash，每 GPU 达到 170 万 tokens/s，每用户 387 tokens/s，是 GB300 NVL72 的 58 倍，峰值达 252 万 tokens/s，单用户达 1,810 tokens/s。性能提升来自为 Rubin 的分裂内存域和 FP4 张量核心重建的 kernel、专用的 TP8 解码路径，以及通过 NVLink 共享的机架级 KV 和 Engram 池。借助跨机架池化前缀和 Dynamo 工作负载感知路由，即使在高并发下前缀命中率也保持在 96.5-97%。
推荐理由：vLLM 关于 DeepSeek-V4.1-Flash 的第三篇文章详细说明了 Rubin 专用 kernel 和机架级内存池化如何将吞吐量提升至 GB300 NVL72 的 58 倍，为大规模服务优化提供了具体参考。
Google 推出了 Gemini Decisions API，由新的 Gemini Decision 1 模型（gemini-decision-1）驱动，可通过 Google AI Studio 中的 Gemini API 使用。单次多模态输入最多 256K token，可在一次前向传递中对照最多 1,000 个是/否、多项选择和评分标准打分问题进行检查，返回概率和置信度分数，端到端延迟为 150-250 毫秒，每 100 万输入 token 收费 0.10 美元，不收取输出 token 费用。Google 表示，该模型在其基准测试套件中领先，校准误差最低，并且比使用 Interactions API 的 Gemini 3.5 Flash-Lite 便宜近 5 倍；内部用途包括 Gemini Notebook 中的模型路由、Stitch 中的线框图生成，以及 Search 中 MCP 工具的对抗性内容检查。
推荐理由：Google 的新端点可在一次传递中以 150-250 毫秒对最多 1,000 个多模态是/否、选择和评分标准问题进行评分，为智能体路由和政策检查提供了比生成式调用更便宜的替代方案。
OpenRouter 在 Claude Sonnet 5.5、GPT-6 Luna 和 Gemini 3.8 Flash 上，用 GitHub MCP server、gh CLI 和一个 gh skill 测量了同一个 GitHub 任务。在 Sonnet 5.5 上三者都回答正确，但 CLI 用了 1,421 个输入 token，skill 用了 3,315 个，而 MCP server 用了 59,417 个——它带有 46 个默认工具，仅这些工具的定义每次请求就增加 19,436 个 token。把 server 限定为两个工具后，该任务降到 23,228 个 token；将结果上限设为 4,000 字符后降到 5,357 个；Tool Search 把 46 个工具的前置成本降到 600 个 token 以下，不过在 Sonnet 5.5 上它把整个任务的成本减半，在 Claude Haiku 5.5 上却提高了。
推荐理由：OpenRouter 的实测对比展示了 MCP server、CLI 和 skill 在同一个 GitHub 任务上各自消耗多少上下文，以及裁剪工具结果或延迟加载定义会在哪里改变账单。
OpenRouter 于 2026 年 10 月 20 日针对 Qwen3.8 27B 的六个端点运行了 280 个精确答案任务，未发现 fp16、fp8 和 fp4 之间存在准确率差异，六个端点的得分均在 98.3% 至 99.2% 之间。在 1,455 个端点中，59.5% 完全未报告精度，fp8 是最常见的标注格式，占 23.6%。对大多数模型而言，较低精度更便宜，但并非所有模型都如此；提供商选择对价格的影响大于精度，同精度下最贵端点的价格中位数是最便宜端点的 1.72 倍。
推荐理由：OpenRouter 在一个模型的 fp8、fp4 和 fp16 端点上测量了 240 个精确答案任务，未发现可检测的准确率差距，而价格差异更多与提供商相关，而非精度。
LangChain 详细说明了其开源 Deep Agents 框架如何使用中间件来对抗长时间智能体运行中的上下文腐化。超过约 20,000 token 的工具结果和超过 50,000 token 的用户消息会被卸载到文件中，仅显示预览；而当使用量达到上下文窗口的 85% 时，摘要功能会压缩较早的消息。技能、子智能体和一个 markdown 长期记忆文件使主智能体的窗口保持较小，并让记忆能够跨模型和提供商延续。
推荐理由：LangChain 解释了其开源 Deep Agents 框架如何使用中间件来卸载、摘要和隔离上下文，为执行长任务的智能体提供了一种可复用的模式。
NVIDIA 正将其用于保护和治理自主 Agent 的开源运行时 OpenShell 作为 Sandbox 项目贡献给云原生计算基金会，同时也为 Google 主导的 Agent Substrate 做出贡献。NVIDIA 宣布了三个新的 DSX AI Factory 平台组件：NVIDIA Kubernetes Engine 和 NVIDIA Kubernetes Recipes（现已进入公开预览），以及 NVIDIA Snapshot，后者可在数秒内恢复检查点副本，无需重新加载模型或预热。Crusoe 在 Crusoe Cloud 上测试了 GLM-5.3，将工作负载就绪时间从大约八分钟缩短至 31 秒，而 Saturn Cloud 将 vLLM 启动时间从 2 到 8.5 分钟缩短至 6 分 34 秒。
推荐理由：NVIDIA 将其 Agent 安全运行时 OpenShell 贡献给 CNCF，并为 GPU AI 工厂新增 Kubernetes 工具，早期 Snapshot 结果将推理启动时间从数分钟缩短至数秒。
Hugging Face 发布了一篇关于决策模型的说明文章，这类模型接收一个状态和带类型的问题，返回预定义答案上的概率，而不是生成文本。文章详细介绍了 choice、score 和 noul 原语、置信度公式，以及通过 Transformers 的 DecisionPipeline 和 AutoModelForDecision 提供的新支持、Transformers 和 llama.cpp 中共享的 /v1/systemone 端点、用于发现的 Hub 标签，以及使用 Trainer API 进行微调。文章指出，同一端点也可通过在一次批量前向传播中对答案 logits 打分，与兼容的自回归 LLM 配合使用。
推荐理由：Hugging Face 解释了决策模型如何将分类转变为带类型的非生成式接口，并展示了如何用 Transformers 和 llama.cpp 来服务和微调它们。
OpenRouter 在八份自制的退化扫描件上测试了 15 个视觉模型、Mistral OCR 和 Tesseract，Claude Opus 5.5 最准确，264 个关键值中答对 262 个，每 1,000 页成本 16.42 美元；Mistral OCR 性价比最高，264 个中答对 258 个，成本 2.02 美元。在一张褪色收据上，GPT-6 Luna 和 GPT-6.1 Sol 编造了卡号数字、一个服务器名称和 wifi 密码，这些错误是字符错误率无法揭示的。文章附有代码，可转录扫描件、关闭推理、交叉核对来自不同实验室的两个模型，并通过 file-parser 插件运行 Mistral OCR。
推荐理由：对 15 个视觉模型以及 Mistral OCR 和 Tesseract 在八份退化扫描件上的实测基准，附可运行代码，用于交叉核对两个模型以捕捉编造的数值。
Anthropic 发布了一份指南，建议开发者将大多数编程和知识工作从 Claude Opus 5.5 的默认中等努力水平开始，因为其每 token 成本仅为 Fable 5.2 的一半。该指南将 Sonnet 5.5 对应到范围明确的日常工作，Haiku 5.5 对应到高容量分类、路由和子代理任务，Fable 5.2 对应到最困难的编程、金融和科学项目或长时间无人值守运行。它还建议在切换模型之前调整努力水平，并指出在 SWE-bench Pro 上，Opus 5.5 在低努力下运行、失败任务以高努力重跑，通过了约 97% 的任务，每个任务约 $0.17，而所有任务均以高努力运行时为 95.3%，每个任务 $0.29。
推荐理由：Anthropic 自己的指南将每个 Claude 模型和努力水平映射到具体任务类型，并提供了用于在它们之间选择的每任务成本和基准比较。
Zyphra 发布了 ZONOS3-Mini，这是一款稀疏 MoE 文本转语音模型，激活参数 100M、总参数 800M，采用 Apache 2.0 许可，在 112 块 NVIDIA H100 上训练了 2.5 天。它在 Pixel 9 的浏览器中首音频延迟低于 570 毫秒，在 M3 MacBook Air 上低于 150 毫秒，并提供 WebGPU、SGLang、vLLM 和 GGML 运行时。该模型增加了对身份、口音、质量、情绪和表达方式的控制，包括词级调控，Zyphra 报告称其在其新的 ZTTS2-Eval 基准上在开源模型中排名第一。
推荐理由：Zyphra 的紧凑型 MoE TTS 模型将零样本语音克隆与词级表达控制相结合，同时能在手机和笔记本电脑上实时运行。
Google Cloud 在其开源 JAX 训练框架 MaxText v0.2.4 中发布了长上下文训练支持，在 Cloud TPU 上新增四种上下文并行策略：All-gather、A2A（DeepSpeed Ulysses）、P2P（Ring Attention）以及 A2A + P2P 混合（USP）。Llama 3.1 8B 的基准测试在 TPU 5p 上、序列长度最高达 400 万 token 时达到 70% MFU，上下文在 TPU 5p 和 TPU 7 上均扩展至 1400 万 token，其中 TPU 7 在低于 600 万 token 时保持 50% MFU。该版本已在 PyPI、Docker 镜像和 GitHub main 上提供，并附有 TPU 7 和 TPU 5p 的示例配方。
推荐理由：MaxText 在 Cloud TPU 上的四种上下文并行策略，以及 Llama 3.1 8B 的基准 MFU 数据，为团队选择如何在数百万 token 序列长度下进行训练提供了具体参考。
Anthropic 报告称，Claude Fable 5.2 仅凭极简提示就设计了三款电子设备——免提扬声器、语音助手中枢和手持虚拟宠物，Diode Computers 依据其设计文件制作出可工作的原型，且未做电路修正。在 Diode 内部的 PCB Gym 基准上，Fable 5.2 得分 69%，而 Fable 5 为 25%；在公开的 BenchCAD 2.1 上达到 83.5%，几乎是 Claude Fable 5.1 的两倍。这些设备仍是原型，尚未经过电气验证、天线调谐、热测试或认证，Claude 也未连接测试设备或制造机器。
推荐理由：Anthropic 亲自披露 Claude Fable 5.2 设计出三款可工作的电子设备，表明模型已从局部 PCB 布局推进到端到端硬件原型制作。
Google 宣布，其用于 Gemini 等大模型的分布式训练系统 Pathways 已在 Google Cloud Platform 上正式可用（General Availability）。Pathways 用单个 Python 客户端将整个计算声明为数据流图，取代了锁步 SPMD 执行方式；分布式运行时负责把块放到虚拟设备上、移动并重新分片张量，以及在整个集群范围内对工作排序。Google 表示，这种设计可以让故障主机被重新映射到健康芯片上，而无需重启任务；并且一个共享的 Pathways 服务可以从单个集群为多个客户端提供服务。
推荐理由：Google 解释了 Pathways 的单控制器模型与 SPMD 有何不同，以及它如何处理跨组张量传输、调度和主机故障恢复。
NVIDIA Research与Inferact的REINFORCE Zero论文表明，对齐rollout与训练器内核后，未裁剪的token级重要性采样能够纠正剩余的权重滞后，在策略滞后64时稳定训练20,000次更新，并在内核对齐的情况下达到同步训练训练步吞吐量的2.40倍。使用标准内核时，整个运行过程中rollout到学习器的KL中位数上升83.33倍，在线AIME24 pass@1从34.27%降至13.96%，而序列门控虽能稳定训练，但在最后1,000次更新时拒绝了24.48%的序列。零失配设置现已覆盖DeepSeek-V4.1-Flash、发布当日的Kimi K3.1，以及AMD MI355X上的DeepSeek-V4-Flash和Kimi K3.1，代码位于Inferact/zero-mismatch-rl和NVIDIA-NeMo/labs-molt。
推荐理由：NVIDIA Research与Inferact将异步强化学习的rollout-学习器差距拆分为权重滞后和内核失配，表明对齐内核可使未裁剪的重要性采样在策略滞后64时保持稳定训练。
) 引用。智能体在 6% 的遇到情况下对 bug ID 采取了行动，其中 83% 的行动并非由开发者提示；41% 的未提示绕行追逐的是已关闭的工单，而 57% 触及的是仍然开放的 bug 并扩大了范围。在控制开发者、代码库复杂度、任务类型、模型层级和其他因素后，未提示的 bug 绕行使每次会话增加了 70% 的步骤、77% 的 token 和 105% 的等待时间。
推荐理由：谷歌的大规模追踪分析显示，过时的 TODO bug 引用会将编码智能体拖入未提示的绕行，而其清理智能体移除了数千条过时引用，审查者接受率超过 95%。
Mistral 扩展了其企业 AI 平台 Studio，新增托管智能体与应用，以及新的工作流、企业上下文、智能体可观测性和评估能力，运行于 Mistral Large 4 (Le Chonk) 模型之上。开发者可以借助技能、沙箱、子智能体和钩子构建多步骤智能体，并通过新的 Mistral MCP 服务器用一条命令部署到 Studio。Mistral 表示，包括 ABANCA、BNP Paribas、Capgemini 和 TCS 在内的客户已在生产环境中使用 Studio，部署方式可选云端、VPC 或本地。
推荐理由：Mistral 扩展 Studio，新增托管智能体、工作流和应用，展示了企业如何将部署和数据控制保留在自己的环境中。