算算这道题：我们如何接管 ChatGPT 账号

通过绕过 ChatGPT 的沙箱和内容安全策略，我们的研究团队只需发送一条链接，就能接管任何人的账号。

2026 年 10 月 26 日已修复P1严重级别

2026 年 10 月，我们发现了一种方法，可以把一个普通的公开 ChatGPT 分享变成攻击者控制的 JavaScript，并在打开该分享的任何人的已登录会话中运行。

攻击者可以创建一个恶意对话，使用 ChatGPT 的常规分享功能将其发布，然后把链接发送给另一名用户。当受害者打开该分享时，载荷会以 chatgpt.com 的身份执行，并能访问受害者的已认证 Web 会话。

我们确认，这段代码可以枚举受害者的对话列表、从一段从未与攻击者分享过的私密对话中获取内容，并把该对话中的数据发送到外部服务器。该载荷并不仅限于修改页面或弹出提示——它可以直接以受害者身份调用 ChatGPT 的已认证 API，本质上让我们接管受害者的 ChatGPT 账号。

受害者无需安装 App、加入 Project、粘贴代码或打开开发者工具。打开分享链接是唯一需要的操作。

OpenAI 于 10 月 26 日修复了该问题，并将报告定级为 P1。

这条攻击链始于两个单独看似乎无害的功能：一张图和 HTML 预览（HTML Preview）。

flowchart TD
  A["攻击者发布一个 ChatGPT 对话"] --> B["受害者打开公开分享"]
  B --> C["HTML 预览跨越到主站 chatgpt.com 页面"]
  C --> D["JavaScript 在受害者的已登录会话中运行"]
  D --> E["以受害者身份在 chatgpt.com 上执行任意操作：<br/>读取私密聊天和文件、更改账号"]

技术细节详解

一切始于一张图和一次预览

这项研究最初的问题很简单：如果预览代码被关在另一个网站里，它还能与什么通信？

ChatGPT 可以通过预览（Preview）功能把一个 HTML 代码块变成一个小型可运行网页。由于该页面可能包含任意代码，ChatGPT 明智地在不同网址的受限框架（frame）内运行它。预览可以运行 JavaScript，但浏览器会把它视为另一个网站，因此它无法直接检查周围已登录的 ChatGPT 页面。

起初，这种隔离看起来完全按设计工作。预览内的代码无法读取 parent.document，也就是主 ChatGPT 页面。事情本应到此为止。

该对话还包含一张普通的交互式图表。在后台，这张图加载了一个名为 MathLive 的数学库。加载它不只是绘制图表：它还在主 ChatGPT 页面中安装了一个监听器，用于接收与 MathLive 屏幕键盘相关的消息。

浏览器把相关 API 称为 postMessage。即便浏览器阻止两个框架读取彼此的页面，这也是两个框架交换信息的一种正当方式。你可以把它想象成投信口：受限的预览无法走进主页面，但仍然可以通过投信口投递消息。

只有当接收方检查消息是谁发来的时，这才是安全的。

对于我们关注的这项设置，MathLive 并没有做这种检查。它的监听器接受了会更改虚拟键盘布局的消息，而该布局允许包含 HTML。图表安装了接收方；预览给了我们一个不可信的发送方。两个互不相关的功能意外地创造了一条跨越沙箱的路径。

本不该生效的消息

Preview 发送了两条消息。第一条用我们的 HTML 替换了虚拟键盘布局，第二条指示 MathLive 显示键盘，从而渲染出新的布局：

top.postMessage({
  type: "mathlive#virtual-keyboard-message",
  action: "update-setting",
  layouts: [{
    label: "Compatibility",
    layers: [{ id: "compatibility", markup }]
  }]
}, "*");

top.postMessage({
  type: "mathlive#virtual-keyboard-message",
  action: "show",
  animate: false
}, "*");

parameter

MathLive 识别出了这个公开的消息类型，但它的顶层控制器采用的来源策略为 none，这意味着它会接受来自任何网址的消息。它也没有要求 update-setting 消息必须来自此前已获批准的窗口。任何能够触达监听器并知晓消息格式的人，都可以替换布局。

当键盘打开时，MathLive 把收到的布局拼接成一个 HTML 字符串，并将其赋值给真实 ChatGPT 页面中的 innerHTML。一个名为 createHTML 的辅助函数起初看起来似乎会对该值做净化处理。但它并没有；它将字符串标记为可信，并把我们的 HTML 原封不动地传了过去。

这令人兴奋，但我们仍然没有获得 JavaScript 执行能力。通过 innerHTML 插入的脚本标签不会自动运行。

下一步是使用 srcdoc 的 iframe，这是浏览器的一项特性，允许内嵌框架直接在属性中携带其 HTML：

<iframe srcdoc="..."></iframe>

parameter

MathLive 在没有 sandbox 属性的情况下将这个框架插入了 ChatGPT 主文档。这给了我们两个有用的特性。第一，srcdoc 创建了一个全新的文档，外部脚本可以在其中执行。第二，由于该框架是由 ChatGPT 主页面创建的，浏览器赋予了它 https://chatgpt.com 的 Web 身份。因此，新框架内的代码能够访问父页面。

利用 YouTube JSONP 绕过 CSP

ChatGPT 的内容安全策略（Content Security Policy，CSP）再次拦住了我们。CSP 控制页面可以加载哪些脚本，而该策略正确地阻止了内联 JavaScript。不过，它确实允许来自 YouTube 的脚本。

YouTube 的 oEmbed 端点支持一种 JSONP 风格的回调参数。JSONP 响应是 JavaScript 而非普通 JSON。该端点试图拒绝无效的回调，但它在返回校验错误之前就把回调放进了响应里：

https://www.youtube.com/oembed?callback=globalThis.__marker=31337;void

parameter

响应开头是这样的：

// API callback
globalThis.__marker=31337;void({
  "error": {
    "code": 400,
    "message": "Invalid JSONP callback name: ..."
  }
});

parameter

用 ;void 结束我们的回调，使 YouTube 追加的对象变得无害。由于 ChatGPT 的 CSP 本来就允许 YouTube，浏览器将这一响应作为脚本加载，并在新框架内运行了我们的回调。

现在我们有了以 chatgpt.com 身份运行的任意 JavaScript。最初的 Preview 仍被隔离在它自己的独立网址上；我们通过诱使主页面中一个受信任的组件为我们创建一个新的、未沙箱化的文档，从而越过了边界。

把一个实验室漏洞变成一条公开链接

到目前为止，这只是一个有用的沙箱逃逸，但第一个可用版本还不足以构成有说服力的真实攻击。它使用由研究人员控制的 ChatGPT App 作为发送方。受害者需要先连接或调用该 App。

接下来，我们尝试通过原生 HTML 附件投递载荷。ChatGPT 会在同一个沙箱化的 Preview 中打开该附件，因此它可以发送恶意的 MathLive 消息。

然而，当我们把对话导出为公开分享时，附件仍然保留，但之前的图表却没有了。该图表至关重要，因为它会加载 MathLive，并在主页面中安装存在漏洞的消息监听器。没有它，附件仍然可以发送消息，但没有任何东西在监听或处理这些消息。

突破口在于把两部分直接放进同一个普通的公开对话中：

1. 一个真实的图表在主页面中初始化了 MathLive。
2. 稍后由助手编写的 HTML Preview 发送了这两条消息。

生成的 /share/ 链接为另一个用户保留了完整的攻击链。攻击者可以用发送任何共享 ChatGPT 对话的方式投递它——通过电子邮件、聊天、支持工单或社交帖子。受害者无需安装任何东西、加入攻击者的工作区，或通过攻击者控制的流程进行身份验证。他们只需访问攻击者共享的 ChatGPT URL。

我们观察到了两种交互版本。在最稳定的复现中，受害者打开分享链接并点击一次 ChatGPT 正常的 Preview 按钮。后来我们将 HTML 块标记为可预览，以便 ChatGPT 自动打开它。在那个版本中，打开链接是受害者唯一的点击。我们在一个单独的账户中复现了自动路径三次，包括在强制刷新之后，警报大约在 4.5 秒后出现。

图表和 Preview 是独立加载的，因此载荷有时可能会在 MathLive 就绪之前发送消息。最终的载体通过在一段有限时间内重试相同的两条消息来处理这种竞态。主页面中的一个防护措施确保私有对话证明和出站请求只运行一次。

此时，公开分享可以显示一个被浏览器识别为来自 chatgpt.com 的警报，并可以在主页面中添加一个横幅。这证明了我们的代码在哪里运行。但它还没有展示这个漏洞为什么重要。

OpenRouter · 2026 年 10 月 31 日

简要说明（Tl;dr）——常驻 AI Agent 需要什么？——开始之前——第 1 步：给 Agent 提供工具——第 2 步：编写 Agent 的一次运行——第 3 步：让它持续运行——第 4 步：验证它能在重启后存活——第 5 步：审批它想做的事——第 6 步：把它部署到常开的环境——常驻 AI Agent 的成本是多少？——常见问题——后续步骤——参考资料

常驻 AI Agent 是一个按计划自动唤醒的程序：它使用工具查看某些信息，判断哪些内容重要，并采取行动或向你汇报，而无需你每次都手动触发。在 2026 年的 DevDay 上，OpenAI 发布了 Dots，这是他们版本的常驻 Agent。你也可以自己搭建一个，自行选择模型、工具，以及每次运行可花费的额度上限。

在本教程中，我们用 TypeScript 和 OpenRouter Agent SDK 搭建一个常驻 Agent：它监控 Hacker News 上你选定的主题，把值得阅读的内容写成本文摘要，在重启后仍记得已经看过哪些内容，并且当任何一次运行的花费达到 5 美分时立即停止。每次检查的花费在 0.0003 到 0.0012 美元之间。同样的结构适用于任何应该持续运行的 Agent，例如监控某个代码仓库或状态页面并采取行动的 Agent。

简要说明（Tl;dr）

• 常驻 AI Agent 按计划唤醒，用工具检查某些内容，无需每次被要求就自行汇报或行动。本教程用我们的 Agent SDK @openrouter/agent 0.11.0 以 TypeScript 搭建一个这样的 Agent。
• 在 2026 年 10 月 13 日的运行中，使用 Claude Haiku 5.5 时，每次检查花费 0.0003 到 0.0012 美元；若每 15 分钟检查一次，每月约 0.86 到 3.46 美元。
• stopWhen: [stepCountIs(6), maxCost(0.05)] 为每次运行设定上限，API 密钥上的额度限制则限定了总花费。
• 在工具上设置 requireApproval: true 会在该工具执行前暂停运行；下次运行会根据你对这次调用的批准或拒绝结果按 ID 恢复。
• 一个记录已见故事 ID 的文件就是这个 Agent 的长期记忆；每次检查都开启全新的对话，可以让每次检查的成本在数周运行中保持稳定。

常驻 Agent 需要什么？

常驻 Agent 需要四样东西，每样只需几行代码：

1. 一个按计划运行 Agent 的循环。
2. Agent 用来观察世界并采取行动的工具。
3. 能在崩溃或重启后存活的记忆。
4. 限制：对每次运行的步骤数和花费设上限，并对任何有后果的操作要求人工审批。

一次按计划执行的检查。有审批待处理时这次运行会被跳过；否则它会开启一段全新的对话，并受到各项限制的约束。

我们的 Agent SDK 负责运行模型和工具调用、应用限制并保存对话，使暂停的运行能够恢复；而你的代码负责调度和记录 Agent 已经看过的故事文件。如果你想了解 SDK 为你做了什么，我们关于构建工具调用 Agent 循环的教程手工写了同样的循环。

开始之前

你需要 Node.js（我们用的是 22 版）和一个 OpenRouter API 密钥。如果还没有密钥，快速入门会带你创建一个。

创建一个项目，安装 SDK、Zod（SDK 用它定义工具的输入 schema）和 tsx（直接运行 TypeScript），然后让脚本能够读取你的密钥：

mkdir watcher && cd watcher
npm init -y
npm pkg set type=module
npm install @openrouter/agent@0.11.0 zod tsx
export OPENROUTER_API_KEY="your-openrouter-key"

把 type 设为 module 可以让脚本使用顶层 await。SDK 仍处于 0.x 版本，因此命令固定使用 0.11.0。

如果你使用 Bun，bun add @openrouter/agent@0.11.0 zod 会安装脚本所需的全部依赖，并且在本教程运行 npx tsx agent.ts 的地方，你可以运行 bun agent.ts。

第 1 步：给 Agent 提供工具

这个 Agent 会获得三个工具：

• check_hacker_news 通过 Hacker News 搜索 API 搜索最近的帖子，只返回 Agent 尚未看过的那些。
• write_digest 保存一条供你阅读的条目。
• post_to_team_channel 会触达其他人，因此需要你批准后才能运行。

每个工具都有名称、描述、用于输入的 Zod schema，以及一个 execute 函数。如果你来自其他框架，我们关于各 Agent 框架的工具调用 schema 处理方式对比展示了六种框架如何定义相同的组成部分。创建 agent.ts，从导入、设置、记忆和工具开始：

import { OpenRouter, tool, stepCountIs, maxCost, type ConversationState, type StateAccessor } from "@openrouter/agent";
import { z } from "zod";
import { existsSync, readFileSync, writeFileSync, appendFileSync, rmSync } from "node:fs";

const client = new OpenRouter({ apiKey: process.env.OPENROUTER_API_KEY });
const MODEL = "anthropic/claude-haiku-5.5";
const TOPICS = "new AI models, AI agents, and tools for developers who build with LLMs";
const EVERY_MS = Number(process.env.EVERY_MS ?? 15 * 60_000);
const MAX_RUNS = Number(process.env.MAX_RUNS ?? Infinity);

// Memory on disk: which stories the agent has already seen, and the conversation itself.
const SEEN = "seen.json";
const seen: Set<string> = new Set(existsSync(SEEN) ? JSON.parse(readFileSync(SEEN, "utf8")) : []);
// Stories returned during the current run. They join seen.json only when the run finishes,
// so a run that crashes partway doesn't lose them. fetched.json keeps them across a restart.
const FETCHED = "fetched.json";
const fetched: Set<string> = new Set(existsSync(FETCHED) ? JSON.parse(readFileSync(FETCHED, "utf8")) : []);
function markSeen() {
  fetched.forEach((id) => seen.add(id));
  fetched.clear();
  writeFileSync(SEEN, JSON.stringify([...seen]));
  rmSync(FETCHED, { force: true });
}
const STATE = "state.json";
const state: StateAccessor = {
  load: async () => (existsSync(STATE) ? (JSON.parse(readFileSync(STATE, "utf8")) as ConversationState) : null),
  save: async (s) => writeFileSync(STATE, JSON.stringify(s)),
};

const checkHackerNews = tool({
  name: "check_hacker_news",
  description: "Return Hacker News stories from the last 48 hours with at least 20 points that you haven't seen before.",
  inputSchema: z.object({ query: z.string().describe("Search terms") }),
  execute: async ({ query }) => {
    const since = Math.floor(Date.now() / 1000) - 2 * 86400;
    const url = `https://hn.algolia.com/api/v1/search?tags=story&hitsPerPage=20&query=${encodeURIComponent(query)}&numericFilters=${encodeURIComponent(`created_at_i>${since},points>=20`)}`;
    const res = await fetch(url);
    if (!res.ok) throw new Error(`HN search failed: ${res.status}`);
    const hits = (await res.json()).hits as any[];
    const fresh = hits.filter((h) => !seen.has(h.objectID) && !fetched.has(h.objectID));
    fresh.forEach((h) => fetched.add(h.objectID));
    writeFileSync(FETCHED, JSON.stringify([...fetched]));
    console.log(`  check_hacker_news("${query}") -> ${fresh.length} new`);
    return fresh.map((h) => ({ id: h.objectID, title: h.title, points: h.points, comments: h.num_comments, url: `https://news.ycombinator.com/item?id=${h.objectID}` }));
  },
});

const writeDigest = tool({
  name: "write_digest",
  description: "Add a short digest entry for the user. Use only for stories that are genuinely relevant.",
  inputSchema: z.object({ markdown: z.string() }),
  execute: async ({ markdown }) => {
    appendFileSync("digest.md", `\n## ${new Date().toISOString()}\n${markdown}\n`);
    console.log("  write_digest -> digest.md");
    return { saved: true };
  },
});

const postToTeam = tool({
  name: "post_to_team_channel",
  description: "Post a message to the whole team. Only for news the whole team must see today.",
  inputSchema: z.object({ message: z.string() }),
  requireApproval: true,
  execute: async ({ message }) => {
    console.log(`  post_to_team_channel -> "${message}"`); // call your chat API here
    return { posted: true };
  },
});

const tools = [checkHackerNews, writeDigest, postToTeam] as const;

该工具会在把结果交给模型之前，过滤掉 Agent 已经看过的帖子，因此模型无需追踪此前已汇报过的帖子，也不必冒重复汇报同一帖子的风险。

新的 ID 只有在一次运行结束后才会写入 seen.json，所以中途失败的一次运行不会丢它的帖子。在此之前，它们保存在 fetched.json 中，该文件在重启后仍然存在。在测试中，我们在一次返回 20 条新帖子的搜索之后立即杀掉了进程。下一次运行延续了未完成的对话（第 2 步），根据保存的搜索结果写出了摘要，并把全部 20 个 ID 加入了 seen.json，之后的检查发现了 0 条新帖子。代价是：如果一次运行在写出摘要之后失败，可能会把某个帖子列两次。修复重复内容比丢失帖子更容易。

OpenRouter · 2026年10月31日

内容提要：什么是开放权重模型？开放权重与开源有何不同？两者各自能给你带来什么？开发者使用开放权重模型的程度如何？开放权重模型更便宜吗？开放权重模型与闭源权重模型一样好吗？如何在一个应用中同时使用两者？我们如何测量这些数据？常见问题。下一步。

开放权重模型是指训练所得的权重被公开发布的模型，任何人都可以下载它、在自己的硬件上运行它、对它进行微调，或将它提供给他人使用。闭源权重模型则将其权重保密，因此使用它的唯一途径是通过构建它的公司，或该公司授权的云服务。

在 OpenRouter 上，开放权重模型在排名前 50 的模型的 token 中所占比例，从 2025 年 10 月的 27% 上升到 2026 年 9 月下旬的 72%。

内容提要

• 开放权重模型会公开其权重，因此任何人都可以运行、微调或将其作为服务提供。闭源权重模型只能从其制造者及其授权的云服务获取。
• 在 OpenRouter 上，开放权重模型在 2026 年 9 月下旬处理了排名前 50 的模型 token 中的 72%，高于一年前的 27%。
• 它们每 token 的成本约为前者的四分之一，主要原因是有许多提供商竞相为同一个模型提供服务。
• 最好的闭源权重模型在 Artificial Analysis 智能指数上的得分仍高出约 11 分。建议先从一个开放权重模型开始，对它进行测试，并在需要它的步骤上使用闭源权重模型。

什么是开放权重模型？

模型的权重是它在训练过程中学到的数字，也是你下载模型时实际下载的内容。将它们公开（通常发布在 Hugging Face 上）可以让任何人都能运行该模型。DeepSeek V4.1 Flash、GLM-5.3、Kimi K3 和 MiMo-V2.6-Pro 是开放权重的。Claude、GPT 和 Gemini 模型是闭源权重的。

发布权重并不意味着你可以随意使用它们。许可证差异很大。正如我们在六月开放权重模型综述中所指出的，DeepSeek V4 Flash 以 MIT 许可证发布，而 MiniMax M3 的社区许可证要求署名，并要求较大的商业产品事先获得书面许可。在基于某个模型进行构建之前，请先查看其许可证。

开放权重与开源有何不同？

按照开源促进会的定义，开源意味着你能获得研究和重建它所需的一切：对于模型而言，这包括训练数据（或在无法合法共享数据时提供关于数据的详细信息）、代码和权重。

大多数开放权重模型并不发布其训练数据，因此“开放权重”是对它们更准确的称呼。不过，搜索结果和模型页面往往混用这些词，所以当你看到“开源 LLM”时，它几乎总是指开放权重。

两者各自能给你带来什么？

前两行正是某些团队需要开放权重的原因。他们的数据不能离开自己的基础设施，或者他们想要一个在自己的数据上微调过的模型。对于其他所有人来说，选择取决于后三行，而价格通常是决定性因素。使用数据说明了原因。

开发者使用开放权重模型的程度如何？

使用量每个季度都在增长。2026 年初，MIT 斯隆管理学院发表了一项研究，基于 2025 年 5 月至 9 月的 OpenRouter 流量，发现闭源模型处理了近 80% 的 token。我们自己 2025 年末的数据与之相似，而此后情况已发生很大变化。

我们根据模型目录条目是否链接到已发布的权重，将 OpenRouter 排名前 50 的每个模型按每周 token 量归类为开放权重或闭源权重：

两类模型都在增长。闭源权重模型的 token 量增长了近十倍，从每周 3.4 万亿增至 33 万亿，而开放权重模型的 token 量增长了 60 多倍。开放权重占比在 7 月达到 77.5% 的峰值，此后一直保持在三分之二以上。

过去四周使用最多的开放权重模型是 DeepSeek V4.1 Flash、GLM-5.3 Flash、Hunyuan 4 Preview 和 DeepSeek V4 Flash。在闭源方面，GPT-5.6 Luna 以较大优势领先，其次是 Gemini 3.8 Flash 和 GPT-6 Luna。在两边，大部分用量都流向了便宜、快速的模型，而不是得分最高的模型。

开放权重模型更便宜吗？

通常是的。在过去四周里，开放权重模型按 token 加权的标价为每百万输入 token $0.28、每百万输出 token $1.62。闭源权重模型则为 $1.27 和 $6.36，约为前者的四倍。

主要原因是竞争。任何人都可以提供开放权重模型的服务，因此提供商会在同一个模型上展开价格竞争。以下是 2026 年 10 月 21 日 OpenRouter 上六款热门模型分别由多少家提供商提供服务，以及它们各端点的输入价格区间：

开放权重模型的价格区间很宽，因为各家提供商在硬件、量化、速度和数据政策上各不相同。最便宜的端点不一定是你想要的，我们的评估提供商性能指南展示了如何比较它们。提供商路由让你可以按价格排序、按量化或数据政策筛选，或设置价格上限。

这两个类别也存在重叠。Kimi K3 最便宜的端点比 Claude Sonnet 5.5 更便宜，但其最贵的端点价格约为后者的两倍。GPT-6 Luna 的标价为每百万输入 token $0.10，低于任何 Kimi K3 提供商的价格。请比较你正在考虑的具体模型，而不是这两个类别。

我们对这种比较的快捷做法是：先设置价格上限，再按吞吐量对其余选项排序。它只需要一个 provider 对象，{"max_price": {"prompt": 1, "completion": 4}, "sort": "throughput"}。超出你预算的端点会被剔除，而你能负担得起的最快端点会被优先尝试。

开放权重模型与闭源权重模型一样好吗？

价格是权衡的一半，质量是另一半。在这方面，开放权重模型尚未登顶。在由我们的基准测试端点汇总的 Artificial Analysis 智能指数上，最好的闭源权重得分是 Claude Opus 5.5 的 57.6 和 Claude Sonnet 5.5 的 56.0。最好的开放权重得分是 MiMo-V2.6-Pro 的 46.3、GLM-5.3 的 44.8 和 Step 5 Preview 的 43.7，Kimi K3 以 43.6 紧随其后。每个得分都是模型在其最高推理强度设置下的表现。

该设置会影响这些数字，因此请在你计划运行的推理强度下比较模型。

这 11 分的差距是在该指数所衡量的最难任务上最强模型之间的差距，它并不能告诉你这一差距对你自己的工作负载有多大影响。我们六月的综述在更早版本的指数上给出的差距约为 5 分，因此请将确切数字视为一个快照。

面对 11 分的质量差距与 4 倍的价格差距，我们的默认做法是先从一个开放权重模型开始，并在你自己的任务上测试它。只有当测试表明额外质量会改变结果的步骤上，才转向闭源权重模型。这通常是工作流中最难的一步，例如智能体中的规划，而不是每一次调用。

Matthias Bastian 查看 Matthias Bastian 的 LinkedIn 个人资料 2026 年 10 月 31 日

OpenAI 最新一轮融资只筹到 300 亿美元目标的一半不到。 据《华尔街日报》报道，该公司目前仅获得约 110 亿美元。其估值定格在 1.25 万亿美元，低于其原本瞄准的 1.4 万亿美元。据报道，这一差距源于大型投资者兴趣减退，背景是谷歌、亚马逊和英特尔季度业绩疲软引发的科技股抛售。OpenAI 如今计划从家族办公室和高净值个人处再筹集最多 200 亿美元。据报道，该公司正计划于明年初进行首次公开募股（IPO）。

竞争对手 Anthropic 近期的收入增长更快，并且最早可能于 11 月上市。一次强劲的 IPO 可能让 Anthropic 手握远超 1000 亿美元的资本，以抵御未来任何一段艰难时期。OpenAI 最近夺回了一些市场份额，但竞争形势来回拉锯。OpenAI 尤其一直在通过降价和更高效的模型奋力守住阵地。

广告

不带炒作的 AI 新闻——由人工精选

订阅 THE DECODER，即可享受无广告阅读、每周 AI 新闻简报、每年六期独家「AI Radar」前沿报告、完整历史存档访问权限，以及评论区访问权限。

立即订阅 来源：WSJ