AI 日报 · 2026-10-29

Google DeepMind 发布的 Gemini 4 Carbon 是今日头条:它被定位为当前最强前沿模型,在漏洞发现、漏洞利用和补丁修复等网络安全指标上领先,但会先向防御人员开放,再逐步扩大访问范围。Mistral Large 4(Le Chonk)则以开放权重形式发布,主打多模态、MoE、1…

Google DeepMind 发布的 Gemini 4 Carbon 是今日头条:它被定位为当前最强前沿模型,在漏洞发现、漏洞利用和补丁修复等网络安全指标上领先,但会先向防御人员开放,再逐步扩大访问范围。Mistral Large 4(Le Chonk)则以开放权重形式发布,主打多模态、MoE、1M 上下文和网络安全/编码智能体能力。Replit 的 ViBench 2.0 与 Elorian 的 DecoyCount 从不同侧面提醒,长周期构建和真实视觉推理仍是短板:顶级模型在完整产品构建中只通过 49%-65% 的测试,Glimpse 在视觉计数上也仅刚过半。企业侧,OpenAI 与 ServiceNow 深化工作流集成,LangChain 密集推出浏览器操作、定时调度与证据支撑记忆,Supabase 和 IBM 也在向 agent 友好、可增量更新的基础设施演进。生态方面,Hugging Face 发起 ProtoStar 推动公共资助科研 AI-ready,GitHub Octoverse 2026 则显示 PR、commit 和新建仓库年内成倍增长。

北美一手(LLMs 官方 & 关联账号)

OpenAI

⭐⭐ [产品更新] OpenAI and ServiceNow expand partnership across enterprise workflows

OpenAI News · 2026-10-28 · 原文 ↗
OpenAI 与 ServiceNow 扩大合作,把更多 OpenAI 模型和智能体引入 ServiceNow 产品,并让 ServiceNow 工作流接入 ChatGPT 与 Codex。新的 ServiceNow 集成会把业务上下文和工作流操作带入 ChatGPT,使 IT 人员无需离开对话即可查找相似事件、评估变更风险并更新 ServiceNow 记录;客户连接自己的 ServiceNow 实例并选择开放哪些能力,由 ServiceNow 的 Action Fabric 执行既有业务规则和权限。ServiceNow 还在预览 ChatGPT 内的交互体验,例如值班工程师可在 ChatGPT 中查看关联监控告警、近期变更和受影响服务,并指派团队处理。双方计划在三个方向开发新能力:在 ServiceNow 的 AI Workflow Factory 中集成 Codex,并由 OpenAI 模型驱动 Build Agent 和 Autonomous Engineer;联合网络安全解决方案;以及 ServiceNow 产品中的 OpenAI 语音体验。
打分理由
这是 OpenAI 与 ServiceNow 的企业合作扩展,涉及 ChatGPT 与 Codex 的具体产品集成,但多项能力仍处于计划或预览阶段,且没有新模型发布,重要度有限。

⭐⭐ [观点] The future of the firm

OpenAI News · 2026-10-28 · 原文 ↗
OpenAI 两位二十四岁即开始带团队的作者撰文,讨论 AI 进入企业后会落在组织架构的什么位置。文章提出三种示意性情形:AI 在「我们之下」,每个人座位不变、但底下长出一层 AI 劳动力,人人都变成管理者;AI 在「我们身旁」,作为类似同事的角色进入组织图,直接向现有的人类管理者汇报,并逐步承担更宽泛的职能、汇报层级上移;最不直观的是 AI 在「我们之间」,人上有人、人下有人,AI 居中协调与监督工作。作者称三种情形都不会完全照描述发生,但认为三者都会以某种方式成真,且已以微妙形式存在。文章的关注点不是全自动化,而是转型中的经济与「混合型公司」,并提出一个判断:模型只做部分任务时,由熟悉工作的一线员工采纳最容易;当模型能端到端完成宽泛职能时,高层便可直接使用——在他们看来,能力更强的 AI 反而更易被采纳。文章还表示将讨论这对繁文缛节、员工能动性、公司规模与薪酬差距的含义。作者注明该文属于其「下一个经济」系列,代表个人观点而非 OpenAI 立场。
打分理由
这是 OpenAI 员工署名的观点随笔,提出 AI 进入组织架构的三种情形,属于有框架的行业思考,但无模型、产品、数据或可操作方案,按一手渠道非模型内容给到 2。

Google

⭐⭐⭐⭐⭐ [模型发布] Gemini 4 Carbon: Our next frontier model

Google DeepMind Blog · 2026-10-28 · 原文 ↗
Google DeepMind 发布新一代前沿模型 Gemini 4 Carbon,称其是当前最强模型,在网络安全与长时程任务能力上处于领先水平。Carbon 在更新后的 Artificial Analysis Intelligence Index v5.0 上以 59 分排名第一,并在 SEC-bench Pro(88.2%,漏洞发现)、ExploitGym(54.8%,漏洞利用)和 CWE-bench(71.0%,补丁修复)上领先;在 WebDev Arena 上提升 89 个 elo 分,以 1768 分位列第 4。该模型建立于两周前发布的 Gemini 4 Argon 之上。推出节奏较为审慎:DeepMind 正参与美国政府自愿性的发布前模型测试流程,本周起先向部分网络安全防御人员开放,并通过 Fairwind Program 逐步向更多可信伙伴开放,之后才会通过产品面向开发者、企业和消费者提供。定价与 Argon 相同:输入每百万 token 2 美元、输出每百万 token 10 美元,缓存输入 token 按输入价格的 95% 折扣计费。
打分理由
一手厂商发布主线旗舰前沿模型,且在第三方智能指数排名第一并大幅刷新网络安全类 benchmark,属最高优先级。

衍生 & 周边(产品 / Agent / Tools / 观点)

模型发布

⭐⭐⭐⭐ [模型发布] Welcome Le Chonk: Mistral Large 4 on Hugging Face

Hugging Face Blog · 2026-10-29 · 原文 ↗
Hugging Face 博客介绍了 Mistral 发布的 Mistral Large 4(昵称 Le Chonk):一个多模态、多语言、采用 MoE 架构的模型,输入文本与图像、输出文本,总参数约 1T、激活参数 49B,上下文窗口 1M tokens。官方提供 FP8 与 NVFP4 两个版本,Unsloth 与 llama.cpp 团队另做了 GGUF;模型以「Mistral Ecosystem Open-Weight License」发布,该许可证由 MIT 派生,对模型即服务(model-as-a-service)用途设有限制。架构上它结合了大量专家、稀疏注意力与 Pixtral 视觉编码器:语言模型为每个 token 选择一小部分专家,注意力索引器选则要关注的历史 token 位置;文本解码器有 72 层。Mistral 表示该模型在网络安全、编码智能体和多模态方面表现较强,在 Artificial Analysis Cyber Index 上得分 82%,该测试要求模型复现开源软件中的真实漏洞并打补丁。文中还给出 Transformers、vLLM、llama.cpp 的推理支持,以及用 TRL 微调、Inference Endpoints 与 Dell Enterprise Hub 的使用方式。
打分理由
Mistral 旗舰级开源权重模型的重大版本发布(约 1T 总参数、1M 上下文、多模态 MoE),属改变开源模型格局量级的发布;因信源为 secondary 按规则封顶 4 分。

⭐⭐ [模型发布] Granite Switch 4.1.1 — Update models like you update software

Hugging Face Blog · 2026-10-29 · 原文 ↗
IBM 发布 Granite Switch 4.1.1,这是 4.1 的补丁版本,版本号含义与软件一致:完全向后兼容、无需迁移,改动都在底层,属于增量改进。此次更新了 Granite Speech ASR 模型,支持 10 种语言的多语种语音转文字,原生输出标点与大小写,转录结果无需再做一次格式化即可交给下游模型;同时更新了 granitelib-core 中的 Decision 适配器,在 Jev Decision Index 测试集上的整体表现有所提升。文章强调,除了训练新的 ASR 模型和 Decision 适配器之外,其他部分都没有重新计算,基础模型保持不动,用户只需组合所需的最新适配器并部署。作者表示,正在制作教程和 Adapter SDK,让开发者与第三方提供方能够自行构建适配器、迭代版本、测试功能,并像发布软件一样发布更新。
打分理由
这是一次补丁级的模型与适配器更新,给出的是版本号与可下载产物,但没有量化指标,影响范围主要限于该模型线的使用者。

⭐⭐ [模型发布] Can Frontier Models See Past a Decoy? Elorian Tests Visual Reasoning

Latent Space (swyx) · 2026-10-29 · 原文 ↗
Elorian 发布了其首个视觉推理模型 Glimpse,被宣传为「一种新类别的视觉思维模型:从所见内容对物理世界进行推理」。Elorian 于今年 4 月结束隐身状态,获得 5500 万美元种子轮融资,由 Striker Venture Partners、Menlo Ventures 和 Altimeter Capital 联合领投。该公司与 AI 数据公司 Mercor 合作发布 DecoyCount 基准,用于检验语言模型是真正在数物体,还是依赖视觉捷径和替代启发式;配套论文称前沿模型在该基准上准确率均低于 50%,最高的是 GPT-6 Astra,为 43.17%。CEO Andrew Dai 表示,Glimpse 在 1660 道 DecoyCount 题目上得分 50.48%,是唯一超过 50% 的模型,Gemini-3.8-flash 为 32.71%、Qwen3.8-max 为 28.31%、Claude-Fable-5.1 为 25.22%;但他也说明 Glimpse 是模型单独单次运行、未使用 agent 或工具框架,而论文中的六个模型是各自在报告设置下三次运行的平均值。Dai 曾任职 Google,2015 年与 Quoc Le 合著「Semi-supervised sequence learning」,此后在 Google DeepMind 参与 GLaM MoE、PaLM 2 和 Gemini,今年离职共同创办 Elorian。
打分理由
衍生信源报道初创公司的首个模型与自建基准,虽有具体分数,但基准由该公司联合发布、Glimpse 成绩为内部单次测试,影响面有限。

产品更新

⭐⭐ [产品更新] Introducing AnySpeechRecognizer and AnyDecisionModel: Open Models for Speech and Decisions on Apple Platforms

Hugging Face Blog · 2026-10-29 · 原文 ↗
Hugging Face 博客介绍两个面向 Apple 平台的 Swift 包:AnySpeechRecognizer 与 AnyDecisionModel。AnySpeechRecognizer 沿用 Apple 在 macOS 26 / iOS 26 引入的 SpeechAnalyzer 等 API,默认使用 Apple 引擎,也可切换到在本地 Core ML 上运行的 NVIDIA Parakeet 系列或阿里巴巴 Qwen3-ASR,并增加说话人分离功能。Parakeet v3 支持 25 种欧洲语言并自动识别语种,Parakeet Ultra 是 Moondream 对 v3 进行后训练得到的版本,Parakeet Unified 是 NVIDIA 的英文版;Qwen3-ASR 提供 0.6B 和 1.7B 两种规模,支持 30 种语言和 22 种中文方言,按不超过 40 秒的片段输出最终结果,不提供 volatile results、词级时间戳或置信度,运行在 GPU 上。AnyDecisionModel 用于回答是/否、多选和评分量表问题,返回带类型的答案和概率,答案由模型概率推导而非生成文本,可调用设备上的 MLX、Core AI 或 llama.cpp 模型,或 Jev、Ollama 的决策模型。两个包都可从 Hugging Face Hub 下载开放模型并在设备端运行。
打分理由
这是面向 Apple 平台的 Swift 包发布,封装已有语音与决策模型并提供可用的开源工具,但不涉及新模型或行业格局变化,按 secondary 给 2 分。

⭐⭐ [产品更新] Browser Use in Managed Deep Agents

LangChain Blog · 2026-10-29 · 原文 ↗
LangChain 为 Managed Deep Agents 增加了浏览器能力,让智能体可以像人一样读取页面渲染后的内容,并执行点击、滚动和填写表单;这些能力适用于 API 无法覆盖的操作(如订票、取消订阅)以及端到端测试。该功能由 LangSmith 托管运行,并提供针对上下文效率调优的浏览器工具。浏览器会话可按 thread 或 user 共享:thread 默认让每个会话使用独立浏览器,user 则在同一个已登录用户的多个会话之间共享 Cookie 与登录状态;无活动达到 idle_ttl_seconds(默认 10 分钟)后浏览器会停止。遇到登录等需要人工的步骤时,智能体可调用 browser_handoff 将浏览器交给用户,用户在 LangSmith Studio 中自行登录后再交还控制权。
打分理由
这是面向托管智能体的浏览器功能更新,加入了会话隔离与人工接管,但属于常规产品迭代。

⭐⭐ [产品更新] How We Built Our Design Agent

LangChain Blog · 2026-10-28 · 原文 ↗
LangChain 的 GTM 工程团队与设计团队合作,构建了名为 Content Studio 的设计 agent,它运行在 Slack 中,基于 Managed Deep Agents 实现,用户只需用一句提示就能生成视频、社交图、UI 图、幻灯片等资产,所有产物都以代码形式产出。文章总结了几条经验:把设计师的原则、防护规则与反馈理由写进 agent 的 skill 与检查项;为每个 Slack 线程提供独立沙箱,让 agent 在多轮对话之间保留项目状态,并能调用视频引擎、图像工具和共享画布、检查自己渲染的结果;为长时间运行的异步任务提供多人可见的进度、计划与发布前审批;随着模型能力提升,删掉那些为弥补模型弱点而设的规则。团队称该 agent 已产出 3000 多个资产、80 多份幻灯片,其作品在 X 上的帖子获得约 450 万次浏览。文章同时提供了开源仓库,可接入自家品牌 token、字体与 skill,并通过 Managed Deep Agents 部署到团队 Slack。
打分理由
厂商工程博客,介绍了开源的设计 agent 仓库与具体做法(沙箱、审批流程、skill 设计),有可用产物,但属自家内部工具经验分享,行业影响面有限。

⭐⭐ [产品更新] Context Engineering with Deep Agents: How To Remember Without Keeping Everything In Context

LangChain Blog · 2026-10-28 · 原文 ↗
LangChain 博客文章介绍「上下文腐坏」问题:长任务 agent 累积的指令、工具结果、文件等上下文超出模型窗口后,准确率与推理能力会下降。文章称其开源 agent harness「Deep Agents」通过五种方式把上下文移出活跃窗口而不删除:卸载(大工具结果与用户消息存入文件系统,模型只看预览)、摘要(接近上限时压缩旧消息)、技能(任务知识按相关性加载)、子 agent(嘈杂工作在独立上下文窗口运行,只回传结果)、长期记忆(写入文件并延续到下一次对话)。文章用一个「竞品分析 agent」的例子说明这些技术如何应用,并称这些技术通过「中间件」插入 agent 循环的特定节点实现。文章还将上下文工程手法分为两类:阻止不必要信息进入窗口,以及管理过滤已在窗口内的内容。
打分理由
厂商工程博文,未发布新版本或新 API,但给出了五种可操作的具体上下文管理做法与实现路径,属于值得一读的常规产品说明。

⭐⭐ [产品更新] How to Build Proactive, Always-On Agents with the Schedules SDK in Managed Deep Agents

LangChain Blog · 2026-10-28 · 原文 ↗
LangChain 博客介绍了如何用 Managed Deep Agents 中的 Schedules SDK 构建主动式、常驻运行的 agent;其核心机制是把 agent 当作 cron 任务来运行。作者称,LangSmith 上超过 70% 的 Managed Deepagent 运行来自定时调度,而不是人工发消息。cron 带来几类能力:后台任务定期压缩历史对话以更新长期记忆,也就是所谓「dreaming」;按固定节奏唤醒 agent 去推进目标,并主动向用户发消息;定期扫描 Slack、邮件等信息源并做筛选提醒;按用户要求定时提醒;以及编排 agent 定期唤醒自己,以监控 agent 集群、检查异步子任务进度。文章随后说到,构建这类 agent 需要两部分:一个易用的 cron 服务器,以及第二个(正文在此截断)关键组件,并给出在 Managed Deep Agents 中的示例。
打分理由
厂商工程博文,给出了具体的实现模式(cron 驱动的记忆压缩、主动触达、信息筛选)和一个可核对的调度占比数据,但属于对既有产品能力的说明性内容,非重大发布。

⭐⭐ [产品更新] How to build evidence-grounded agent memory with OpenWiki and Graphs

LangChain Blog · 2026-10-28 · 原文 ↗
LangChain 博客介绍如何用开源工具 OpenWiki(基于 Deep Agents 构建的命令行工具)配合证据图谱,为 agent 构建可作为记忆层的编译式 wiki:它把源材料合成为带引用、互相链接的页面,并随源文档变化而更新。作者称,在需要跨源关联的问题上,以该 wiki 作记忆层的 agent 准确率约为仅靠 grep 搜索工具的 5 倍。在此基础上,用证据图谱把引用和文档引用关系连成显式边后,agent 引用同一证据的一致性翻倍、准确率再提升 27%,每个正确答案的成本降低 58%。对于简单查询,不使用记忆层的 agent 准确率相当且速度更快。OpenWiki 的每条陈述都锚定为一条 claim,并关联到支撑该陈述的源文件行及其哈希;源行变化时哈希随之改变,因此无需调用模型即可标记受影响的 claim,只把这些 claim 交给模型确认、修订或撤回。评测使用由 111 篇长文档合成的保险文档库,并配有一份 972 条事实的账本,用来控制每条事实应出现的位置、文档间的引用关系以及版本之间的变化。
打分理由
LangChain 工程博客用可复现的基准数字(跨源问题准确率约为 5 倍、+27%、每个正确答案成本降 58%)说明给开源工具 OpenWiki 加证据图谱后的 agent 记忆效果,属于有数据有论证的工具实践,但仍是厂商自述的衍生内容。

研究

⭐⭐⭐ [研究] ViBench 2.0: A Benchmark for Long-Horizon Software Building

Replit Blog · 2026-10-28 · 原文 ↗
Replit 发布 ViBench 2.0,一个面向长周期软件开发(long-horizon software development)的基准测试,并被纳入其推理与训练合作伙伴 Fireworks 的 Specialized Intelligence Index(SII)。与 DeepSWE 等在既有代码库内给定明确任务的编码基准不同,ViBench 2.0 让智能体从空项目开始,参照 Uber、GitHub、Google Docs 这类产品,逐个功能地构建完整产品。该基准包含 17 个产品、241 条功能需求和 544 份测试计划;表现最好的模型 GPT-6.1 Sol、GPT-6 Astra 和 Opus 5.5 也只在 49%-65% 的构建中通过全部测试计划。ViBench 1.0 曾发现模型在修改自己写的代码时得分更低(论文称为 Vibe-on-Vibe),ViBench 2.0 通过模拟产品演进进一步扩展了这一设定。其中 8 个产品以 Harbor 格式公开在 GitHub 上,其余 9 个保留未公开。
打分理由
这是一份带具体数据(17 个产品、544 份测试计划、头部模型 49%-65% 通过率)的长周期编码基准,并接入 Fireworks 的 SII 评测体系,属于值得关注的重要 benchmark,但为二手指信源,按规则封顶 3 分。

⭐⭐ [研究] GitHub Octoverse 2026

Simon Willison's Weblog · 2026-10-28 · 原文 ↗
GitHub 执行副总裁 Jay Parikh 在 GitHub Universe 上公布了 2026 年度 Octoverse 报告,Simon Willison 在现场记录并转述了其中的关键数字:2026 年合并的 pull request 在不到一年内增至三倍,达到每月 2.2 亿次;commit 数增长超过三倍,达到每月 73.8 亿次,其中大部分增长发生在本年下半年;新建仓库的速度翻倍,达到每月 3030 万个。报告新增了按行业划分的数据,并单独统计了涉及「互操作性或逆向工程」的仓库。方法说明部分提到:按公开仓库 push 量排序的国家数据依据用户 profile 所在地进行调整,并使用 LLM 分类从 profile 中提取 ISO 3166-1 alpha-2 国家代码,以减小 VPN 使用带来的偏差;行业归类则用微调的多语言 embedding 模型,依据名称、描述、topics 和 README 将 2022 至 2026 年创建的公开仓库分入 NAICS 部门;互操作性统计的口径是仓库的名称、描述、topics 或 README 中提及 interoperability、reverse engineering,以及 clean room implementation、drop-in replacement、protocol re-implementation 等相关术语。
打分理由
这是一篇转述 GitHub Octoverse 年度报告数据的 link blog,给出了具体的量化指标与统计方法,但属于二手转述而非一手发布。

观点

⭐⭐ [观点] Why Agents Love Supabase

Latent Space (swyx) · 2026-10-28 · 原文 ↗
这是 Latent Space 对 Supabase 创始人 Paul Copplestone 和 Ant Wilson 的播客访谈配套文章,也是两人首次共同上播客——此时距离他们以 YC S20 项目起步已过去六年,公司从开源、全员远程做到 100 亿美元估值。文章围绕「为什么 agent 喜欢 Supabase」展开:swyx 称自己跑的 AEO 追踪显示,从 Astra 到 Fable 到 Muse 的各个前沿模型几乎都把 Supabase 选为应用后端首选。在 Select 大会上,Supabase 把发布分成 Build、Operate、Scale 三类,作者重点提到三项:无需 Docker 即可在本地运行 Supabase 的 alpha 运行时、把目标数据库 schema 以声明式文件保存在 Git 中供 agent 读取和修改、以及在数据库旁运行计算(Supabase Compute,目前为私有 alpha),用于文档切分、生成 embedding 等耗时任务。Operate 一侧则围绕日志、检查、连接和上下文,让 agent 理解自己正在改什么。创始人表示 Supabase 每月约新开 500 万个数据库,他们也在考虑 agent 把这一数字推向数十亿应用时的情形,同时现有客户仍在增长。
打分理由
这是播客访谈的配套评论文章,虽包含无 Docker 本地运行、声明式 schema、Supabase Compute 私有 alpha 等具体产品信息,但属二手转述与个人评论,并非模型发布或行业格局级事件。

其他

⭐⭐ [其他] Announcing Project ProtoStar: Making Publicly Funded Science AI-Ready

Hugging Face Blog · 2026-10-29 · 原文 ↗
Hugging Face 博客宣布发起「Project ProtoStar」计划,联合大学、研究机构、产业界与开放科学社区,推动公共资助科研成果以「AI-ready」、机器可操作的格式发布数据集、模型与代码,使其更易被发现、复用和二次开发。创始合作方包括卡内基梅隆大学、普渡大学、佐治亚理工学院、亚利桑那州立大学和乔治·华盛顿大学(通过 Open Forum for AI 作为高校联盟伙伴)、Astera Institute、作为基础设施伙伴的 Hugging Face,以及作为社区伙伴的 ORCA。参与机构以谅解备忘录的形式确认参与,首个挑战赛由卡内基梅隆大学主办,于 11 月 2 日开放。文中给出的背景是:美国联邦政府每年在研发上投入约 1900 亿美元,NIH、NSF 等机构已加强公共获取要求,Hugging Face 是 NIH 列出的十个通用数据仓库之一;但科研成果公开并不等于可用,科学数据、模型与代码常散落在互不兼容的系统中、以静态或遗留格式存储,或缺少文档、元数据与来源信息。该计划参考了美国国家癌症研究所的 AI Data-Readiness Challenge 与 Hugging Face 的公共部门数据准备指南;目前 Hugging Face 在基因组学、蛋白质设计、化学、天气与气候、地球观测、天文学等核心科学领域托管了超过 1.7 万个公开数据集,若计入医学与数学则接近 2.9 万个,并有数量相当的科学模型。
打分理由
多方参与的科研数据开放联盟计划,参与方与目标明确,但尚无具体落地成果与资金规模,属值得一读的行业动向。

⭐⭐ [其他] How We Built LangChain’s Paid Media Agent

LangChain Blog · 2026-10-28 · 原文 ↗
LangChain 介绍了其为支撑付费广告投放而搭建的 Paid Media Agent:该 agent 会跟踪产品发布、草拟广告系列、添加关键词、测试变体,并把建议的实验提交给团队审批,目标是形成「分析—改动—观察—沉淀」的持续学习闭环。文中给出的结果包括:付费媒体在六个月内从贡献营销管道的 0 提升到 20%;6 月至 8 月每个合格线索的成本下降 30%,同期月支出增加约 60%;在 LinkedIn 上每次合格线索成本(CPL)比 1 月低 40%;把分析与报表收归内部后,每月节省约 5K 美元。工程经验包括:把 agent 当作知识工作者,为它提供包含沙盒、软件、业务上下文和操作说明的工作区;把计算、事实来源规则与防护措施交给代码处理,让模型专注于解读结果并给出下一步建议;围绕完整工作流设计,改动提案需经人工审批,并验证改动是否被正确执行;使用托管的 Deep Agents 处理托管、沙盒、Slack 集成和定时调度。该 agent 已开源,可作为其他人自建 agent 的起点。
打分理由
这是厂商的工程案例博文,给出了可核对的效果数据,并开源了 agent 代码,但它属于教程和案例性质,不涉及模型发布或产品能力更新。

📬
每天 3–5 条 agent 生态一手信号,中英双语。不错过重要更新 → 订阅邮件
Loading...