标签 OpenAI 下的文章

转载:公众号[星纬智联技术],推荐中转站: https://nicecode.cc/
AI Agent Gateway 赛道的现状:
2026 年初,AI Agent 领域最火的项目非 OpenClaw 莫属。这个前身为 Clawdbot 🦞(后改名 Moltbot ,最终定名 OpenClaw )的项目,在 GitHub 上已经积累了超过 17 万 Star 。它的核心理念很直接:给 LLM 一双"手",让 AI 能操作你的本地系统——执行命令、读写文件、控制浏览器。OpenClaw 的架构确实强大:
• Gateway + Pi Agent:Gateway 是 Node.js WebSocket 服务(默认绑 ws://127.0.0.1:18789 ),内嵌 Pi ( Mario Zechner 写的开源 Coding Agent )通过 JSON-RPC over stdio 做推理和工具调用
• 多模型支持:通过 Pi 的统一 LLM API 接 Anthropic 、OpenAI 、Google 、Ollama 等多家 Provider
• 支持 WhatsApp 、Telegram 、Discord 、iMessage 、Slack 、Signal 等消息通道• 沙箱模式、设备配对审批、加密凭据存储
但它也有明显的代价:43 万行 TypeScript 代码,Node.js 运行时,以及相当复杂的依赖链。
对于只想自托管一个 AI 助手的个人开发者来说,这个体量太重了。myclaw 想做的事情很简单——用 Go 写一个够用的轻量替代。
myclaw 是什么:
myclaw 是一个 Go 编写的自托管 AI Agent Gateway 。设计目标三条:
1. 轻量:核心代码约 2000 行,单二进制部署,无运行时依赖
2. 实用:覆盖日常场景——Telegram 和飞书双通道、定时任务、记忆持久化
3. 可扩展:模块化架构,Channel 接口抽象清晰,加新通道写一个 struct 就行
架构上借鉴了 OpenClaw 的 Gateway 模式,但实现上砍掉了所有我用不到的东西。
架构设计:
myclaw 的整体架构可以用一句话概括:消息总线驱动的服务编排。
┌─────────────┐     ┌──────────┐     ┌──────────────┐
│  Telegram    │────▶│          │────▶│   Claude /   │
│  Channel     │     │ Message  │     │   OpenAI     │
└─────────────┘     │   Bus    │     │   Agent      │
                    │          │     └──────┬───────┘
┌─────────────┐     │          │            │
│  Feishu      │────▶│          │◀───────────┘
│  Channel     │     └──────────┘
└─────────────┘          │
                         ▼
┌─────────────┐     ┌──────────┐
│  Cron        │     │  Memory  │
│  Service     │     │  System  │
└─────────────┘     └──────────┘
       │
┌─────────────┐
│  Heartbeat   │
│  Service     │
└─────────────┘
核心组件包括:
1. Message Bus (消息总线)
消息总线是 myclaw 的中枢。两种消息类型:
• InboundMessage:从通道流入,携带 Channel 、SenderID 、ChatID 、Content 、Timestamp 等字段
• OutboundMessage:从 Agent 流出,携带 Channel 、ChatID 、Content 、ReplyTo 等字段
通过 Pub/Sub 模式( SubscribeOutbound / DispatchOutbound ),各服务之间实现松耦合的事件路由。缓冲区默认 100 条消息,Goroutine 安全。
2. Gateway (网关编排器)
Gateway 是顶层编排器,负责:
• 组装系统 Prompt (从 AGENTS.md + SOUL.md + 记忆上下文拼接)
• 处理入站消息,调用 Agent 运行时(支持 Anthropic 和 OpenAI 两种 Provider )
• 将 Agent 输出路由到对应的消息通道
• 处理 SIGINT / SIGTERM 优雅关闭
Provider 切换的逻辑很直接——配置里 provider.type 写 openai 就走 OpenAI ,其他情况默认 Anthropic 。不搞什么抽象工厂,一个 switch 解决。
3. Channel (消息通道)
Channel 接口定义了四个方法:Name()、Start()、Stop()、Send()。目前实现了两个通道:
Telegram 通道:
• 基于 telegram-bot-api/v5 长轮询
• Markdown → Telegram HTML 格式转换
• 消息分片( 4096 字符限制)
• 发送者白名单过滤
• 代理配置支持(方便国内网络环境)
飞书通道:
• Webhook 模式,启动一个 HTTP Server 监听 /feishu/webhook (默认端口 9876 )
• Tenant Access Token 管理,带缓存和双重检查锁
• URL Verification Challenge 自动应答
• 事件驱动的消息接收( im.message.receive_v1 )
• 发送者白名单过滤(基于 open_id )
• Verification Token 校验
飞书通道需要一个公网可达的 Webhook URL 。本地开发可以用 Cloudflared 临时隧道,生产环境建议配 DNS 。
4. Memory (记忆系统)
记忆系统分为两层:
• 长期记忆( MEMORY.md ):持久化的知识库
• 每日日记( YYYY-MM-DD.md ):按日期归档的交互记录
提供 ReadLongTerm()、WriteLongTerm()、ReadToday()、AppendToday() 和 GetRecentMemories(days) 方法。默认取最近 7 天的日记,和长期记忆一起组装进 LLM 的系统 Prompt 。
文件就是 Markdown ,想手动改也行。
5. Cron (定时任务)
支持三种调度模式:
• cron:标准 Cron 表达式(基于 robfig/cron/v3 )
• every:固定间隔(毫秒级)
• at:一次性定时执行
任务持久化为 JSON (存在 ~/.myclaw/data/cron/jobs.json ),支持状态追踪( LastRunAtMs 、LastStatus 、LastError )和执行后自动删除。任务的执行结果可以通过 deliver 字段指定是否推送到某个消息通道。
6. Heartbeat (心跳服务)
定期读取 HEARTBEAT.md 文件内容,触发 Agent 处理。Agent 返回 HEARTBEAT_OK 表示无需进一步操作。默认间隔 30 分钟,适合做周期性自检或主动提醒。
为什么用 Go:
选 Go 不是为了赶时髦,是几个实际的考量:
1. 单二进制部署:go build 产出一个可执行文件,不需要 Node.js 运行时或 Python 虚拟环境。scp 到服务器直接跑
2. 并发原语:Goroutine + Channel 天然适合消息总线架构。每个通道、每个定时任务、Webhook Server 都是独立的 Goroutine ,代码写起来比 async/await 回调链清爽
3. 内存占用:Go 运行时的内存开销远低于 Node.js / Python ,一个长期驻留的 Gateway 进程,这点差别会累积
4. 交叉编译:GOOS=linux GOARCH=arm64 go build 一行命令编译到任意平台
快速开始:
安装
go install github.com/stellarlinkco/myclaw/cmd/myclaw@latest
初始化
myclaw onboard
这会在 ~/.myclaw/ 下创建配置文件和工作空间:
~/.myclaw/
├── config.json          # 主配置
├── workspace/
│   ├── AGENTS.md        # Agent 角色定义
│   ├── SOUL.md          # 人格特质
│   ├── HEARTBEAT.md     # 心跳任务提示词
│   └── memory/
│       └── MEMORY.md    # 长期记忆
└── data/
    └── cron/
        └── jobs.json    # 定时任务持久化
配置
编辑 ~/.myclaw/config.json:
{
  "agent": {
    "model": "claude-sonnet-4-5-20250929",
    "maxTokens": 8192,
    "temperature": 0.7,
    "maxToolIterations": 20
  },
  "provider": {
    "type": "anthropic",
    "apiKey": "sk-ant-..."
  },
  "channels": {
    "telegram": {
      "enabled": true,
      "token": "your-bot-token",
      "allowFrom": ["123456789"],
      "proxy": ""
    },
    "feishu": {
      "enabled": true,
      "appId": "cli_xxx",
      "appSecret": "xxx",
      "verificationToken": "xxx",
      "port": 9876,
      "allowFrom": ["ou_xxx"]
    }
  },
  "gateway": {
    "host": "0.0.0.0",
    "port": 18790
  }
}
想用 OpenAI 兼容的 API ?把 provider.type 改成 "openai",填上对应的 Key 和 Base URL 就行。
也支持环境变量覆盖:
环境变量 用途
MYCLAW_API_KEY / ANTHROPIC_API_KEY Anthropic API Key
OPENAI_API_KEY OpenAI API Key (自动切换 Provider )
MYCLAW_BASE_URL / ANTHROPIC_BASE_URL API 地址(可接自定义 Endpoint )
MYCLAW_TELEGRAM_TOKEN Telegram Bot Token
MYCLAW_FEISHU_APP_ID 飞书 App ID
MYCLAW_FEISHU_APP_SECRET 飞书 App Secret
一个细节:如果只设了 OPENAI_API_KEY 而没有配 provider.type ,myclaw 会自动把 Provider 切到 OpenAI 。少一步配置。
运行
# REPL 模式(命令行交互)
myclaw agent

# 单条消息模式
myclaw agent -m "今天的任务清单"

# 完整 Gateway 模式(启动所有服务)
myclaw gateway

# 查看状态
myclaw status
部署
Docker
myclaw 提供了多阶段 Dockerfile ( golang:1.24-alpine 构建,alpine:3.21 运行),编译产物约 10MB
# 构建并启动
docker compose up -d --build

# 如果需要飞书 Webhook 的公网隧道
docker compose --profile tunnel up -d --build
Docker Compose 里包含一个可选的 Cloudflared 隧道服务,通过 --profile tunnel 激活。它会自动把飞书 Webhook 端口暴露到公网,省去自己配 Nginx 反向代理的麻烦。
本地开发也可以直接用 Make:
make tunnel  # 启动 cloudflared 临时隧道
拿到 *.trycloudflare.com 的 URL 后填到飞书开放平台的事件订阅里就行。
裸机部署
# 交叉编译
GOOS=linux GOARCH=amd64 go build -ldflags="-s -w" -o myclaw ./cmd/myclaw

# 丢到服务器上
scp myclaw user@server:/usr/local/bin/
ssh user@server "myclaw onboard && myclaw gateway"
myclaw 证明了一件事:构建一个实用的 AI Agent Gateway 不需要 43 万行代码。2000 行 Go ,两个消息通道,一套记忆系统,一个 Cron 调度器——日常够用了。当然它也有明显的不足。没有 Web UI ,没有多用户会话隔离,飞书通道目前只支持纯文本消息。如果你的场景需要这些,OpenClaw 或者自己加功能。Go 的单二进制部署和低内存占用让它特别适合丢在一台小 VPS 上长期跑着。如果你认同"能用 2000 行解决的问题不要用 43 万行"这个理念,可以试试。
转载:公众号[星纬智联技术],推荐中转站: https://nicecode.cc/

OpenAI 发布了Prism,这是一个基于云的免费 LaTeX 工作空间,专为学术写作和协作而设计,并且直接集成了 GPT-5.2。该平台将文档编辑、编译、引文管理及 AI 辅助修订功能整合在单个基于 Web 的工作区中,主要面向需要撰写长篇科学文献的研究人员。

 

Prism 完全支持 LaTeX 原生操作,并且是完全在浏览器中运行。用户可以创建、编译和预览文档,无需安装本地工具或管理 LaTeX 环境。该平台消除了现有 LaTeX 协作工具中常见的限制,对项目数量、协作者数量或编译时间没有任何限制。

 

Prism 的核心优势在于将 GPT-5.2 集成到了文档工作流中。与通过单独的聊天界面操作不同,该模型直接在项目的上下文中运行,可以访问文档结构、公式、参考文献和之前的修订。这使得它能够协助执行诸如修订文本、调整格式、更新公式和表格以及查找相关文献这样的任务,同时保证文档内部逻辑的一致性。

 

Prism 内置了引文管理功能,并支持与 Zotero 同步以发现参考文献。实时协作功能允许多个作者同时编辑文档,内联评论和专题讨论支持同行评审和反馈。自动化错误检查、公式转换和格式化工具旨在减少手动更正和重复的 LaTeX 调整。

 

本次发布在研究人员中间引发了关于 Prism 与 Overleaf 等工具的对比讨论。Povilas Karvelis指出: 

 

我认为这种情况还会持续几年,直到知识图谱和 AI 代理成为主要的研究手段,使精心撰写的研究论文彻底过时。

 

其他早期用户强调了该平台的定价模型所带来的实际影响。一位研究人员评论道:

 

集成 AI 是 Prism 提供的功能中最不实用的。仅仅是让我可以免费拥有无限数量的项目和协作者,就使它成为比 Overleaf 更好的选择。

 

从技术的角度来看,Prism 的定位是一个集成的写作和协作环境,而不是一个 AI 优先的工具。AI 辅助功能是可选的,并且嵌入到了标准的学术工作流中,团队可以有选择地使用。核心功能的使用不依赖自动化辅助。

 

目前,拥有 ChatGPT 个人账户的用户可以通过 Web 访问 Prism。OpenAI 表示,未来版本将陆续支持 ChatGPT 商业版、团队版、企业版及教育版。

 

原文链接:

https://www.infoq.com/news/2026/01/openai-prism/

作者:江昱

在构建 Agent 应用时,凭证管理是一个容易被忽视但又极其重要的问题。一个典型的 Agent 应用会面临两个方向的凭证需求:向内,用户如何安全地调用你的 Agent?向外,Agent 如何安全地调用外部服务?

传统做法存在诸多问题。硬编码在代码里容易泄露且难以更新,存在配置文件中同样有安全风险,每次都手动传递不仅麻烦还容易出错,让大模型处理凭证更是巨大的安全隐患。更棘手的是,当凭证需要更新时(比如 API Key 过期、权限变更),如何在不重启服务的情况下动态更新?函数计算 AgentRun 的凭证管理系统就是为了解决这些问题而生。

image

入站凭证与出站凭证:双向安全保障

函数计算 AgentRun 的凭证管理分为两个维度,分别解决“谁能调用我”和“我能调用谁”的问题。

入站凭证:控制谁能访问你的 Agent

image

入站凭证用于控制外部用户或系统如何访问你的 Agent 应用。当你创建一个 Agent 并对外提供服务时,需要确保只有授权的用户才能调用。函数计算 AgentRun 提供了灵活的入站凭证管理,可以为不同的调用方生成独立的凭证,设置不同的权限和配额,控制每个凭证能访问哪些 Agent、调用频率限制、有效期等。

由于所有请求都经过函数计算 AgentRun 网关,入站凭证可以实现真正的动态更新。 比如你的 Agent 对外提供客服能力,可以为不同的业务部门生成不同的入站凭证,每个部门只能访问各自授权的 Agent。当某个部门的凭证泄露时,可以立即撤销并重新生成,所有变更在网关层实时生效,不影响其他部门的使用,也无需重启任何服务。

出站凭证:安全调用外部服务

image

出站凭证用于 Agent 访问外部服务时的身份认证。Agent 应用通常需要调用各种外部服务:大模型 API(OpenAI、Claude、Qwen 等)、数据库、第三方工具、企业内部系统等,每个服务都需要相应的凭证。传统方式下,开发者要么把这些凭证硬编码在代码里,要么通过环境变量传递,不仅不安全,更新时还需要重启服务。

函数计算 AgentRun 采用了一套巧妙的定时查询与缓存机制来管理出站凭证。 所有出站凭证统一存储在加密的凭证库中,代码里不再出现任何敏感信息。Agent 启动时会从凭证库拉取所需的所有凭证并缓存到本地,运行过程中直接使用本地缓存,避免频繁的网络请求带来的性能开销。同时,系统会定期进行健康检查,主动查询凭证是否有更新,发现变更时只更新发生变化的凭证。如果健康检查失败,会自动重试,确保凭证始终可用。

image

这种定时查询方案带来了多重价值。 从性能角度看,本地缓存避免了每次调用都查询凭证库,大幅降低了延迟和网络开销;从可用性角度看,即使凭证服务短暂不可用,缓存的凭证仍然可用,不会影响 Agent 的正常运行;从安全性角度看,定时健康检查确保凭证泄露或过期时能在几分钟内完成更新,而不需要等到下次部署。最关键的是,整个更新过程对 Agent 代码完全透明,开发者无需编写任何凭证更新逻辑,专注于业务实现即可。

这种最终一致性的设计在实践中被证明是最优的平衡:既保证了性能和可用性,又实现了凭证的动态更新能力。相比于每次都实时查询(性能差)或者只在启动时加载(更新不及时),定时查询方案在三者之间找到了最佳平衡点。

实际应用:工具和模型的凭证配置

函数计算 AgentRun 的凭证管理在两个关键场景发挥作用,展示了从理论到实践的完整闭环。

场景一:大模型调用的凭证管理

当你的 Agent 需要调用多个大模型时,每个模型都需要各自的 API Key。以前你可能需要在代码里硬编码这些 Key,或者通过环境变量传递,但这样做存在安全风险且更新困难。有了函数计算 AgentRun 的凭证管理,你只需要在平台上配置各个模型的出站凭证,给每个凭证命名(如 openai_key、qwen_key),然后在 Agent 配置中引用这些凭证名称。

运行时系统会自动注入实际的 Key,你的代码里完全看不到任何敏感信息。当某个模型的 Key 过期需要更新时,只需在凭证管理界面更新,几分钟后所有使用该凭证的 Agent 会通过定时健康检查自动获取新的 Key,无需修改代码或重启服务。这种体验就像是有一个智能管家在后台默默地帮你管理所有的钥匙,你只需要告诉他你要开哪扇门。

# Agent 配置示例(伪代码)
models:
  - name: gpt-4
    credential: ${credentials.openai_key}  # 引用凭证名称,不暴露实际Key
  - name: qwen-max
    credential: ${credentials.qwen_key}

场景二:工具调用的凭证注入

回到之前提到的 FunctionQ 案例,这是一个更复杂但也更能体现凭证管理价值的场景。Agent 需要通过 MCP 调用 CLI 工具查询用户的函数计算资源,这些工具需要用户的 AccessKey 和 SecretKey。关键问题是:如何在不暴露凭证给大模型的前提下,让工具能够正确调用 API?

函数计算 AgentRun 通过前置 Hook 实现了优雅的动态凭证注入。 用户在平台上配置自己的出站凭证后,Agent 调用工具时请求中只携带用户 ID,不包含任何凭证信息。前置 Hook 拦截请求,根据用户 ID 从凭证库获取对应的凭证,然后将凭证注入到环境变量或请求参数中。工具使用注入的凭证执行实际操作,后置 Hook 再清理敏感信息并记录审计日志。整个过程中,凭证从未暴露给大模型,也不会出现在 Agent 的代码中,真正做到了安全可控。

image

核心价值:让开发者专注业务逻辑

函数计算 AgentRun 的凭证管理系统带来的价值远不止“管理凭证”这么简单。从安全性角度看,凭证不再出现在代码和日志中,集中加密存储大幅降低泄露风险,即使某个凭证泄露也可以快速撤销和更换。从开发效率角度看,开发者不需要关心凭证如何存储、如何传递、如何更新,只需在配置中引用凭证名称,系统自动处理剩下的事情。从运维角度看,凭证更新不需要修改代码、不需要重新部署、不需要重启服务,在管理界面更新后通过定时机制自动生效。

更重要的是,凭证管理让 Agent 应用从“能用”变成“敢用” 。企业不再担心凭证泄露的风险,不再为凭证更新而头疼,不再因为安全问题而犹豫是否将 Agent 应用部署到生产环境。这种信心的建立,才是凭证管理最大的价值所在——它消除了企业拥抱 AI Agent 的最后一道顾虑,让技术真正为业务创造价值。

立即体验函数计算 AgentRun

函数计算 AgentRun 的无代码到高代码演进能力,现已开放体验:

查看更多产品详情:https://www.aliyun.com/product/fc/agentrun

  1. 快速创建:访问控制台(https://functionai.console.aliyun.com/cn-hangzhou/agent/explore),60 秒创建你的第一个 Agent
  2. 深度定制:当需要更复杂功能时,一键转换为高代码
  3. 持续演进:利用函数计算 AgentRun 的基础设施能力,持续优化你的 Agent

从想法到上线,从原型到生产,函数计算 AgentRun 始终是你最好的伙伴。欢迎加入“函数计算 AgentRun 客户群”,钉钉群号:134570017218。

快速了解函数计算 AgentRun:

一句话介绍: 函数计算 AgentRun 是一个以高代码为核心的一站式 Agentic AI 基础设施平台。秉持生态开放和灵活组装的理念,为企业级 Agent 应用提供从开发、部署到运维的全生命周期管理。

image

函数计算 AgentRun 架构图

函数计算 AgentRun 运行时基于阿里云函数计算 FC 构建,继承了 Serverless 计算极致弹性、按量付费、零运维的核心优势。通过深度集成 AgentScope、LangChain、RAGFlow、Mem0 等主流开源生态。函数计算 AgentRun 将 Serverless 的极致弹性、零运维和按量付费的特性与 AI 原生应用场景深度融合,助力企业实现成本与效率的极致优化,平均 TCO 降低 60% 。 

让开发者只需专注于 Agent 的业务逻辑创新,无需关心底层基础设施,让 Agentic AI 真正进入企业生产环境。

前提:需要有一个 Gemini pro 账号,一个服务器,可以和 clawdbot 的服务器共存
一键脚本安装 CLIProxyAPI

复制
curl -fsSL https://raw.githubusercontent.com/brokechubb/cliproxyapi-installer/refs/heads/master/cliproxyapi-installer | bash

修改一下配置,password 是你的密码自己改一下,上边端口也可以改,改完之后 Ctrl+O 保存 Ctrl+X 退出(nano 的命令)

复制
nano ~/cliproxyapi/config.yaml

然后进目录开启,设置开机自启,先写入系统文件,在开启

复制
cd ~/cliproxyapi/
复制
cat >/etc/systemd/system/cli-proxy-api.service <<'EOF'
[Unit]
Description=cli-proxy-api
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
WorkingDirectory=/root/cliproxyapi
ExecStart=/root/cliproxyapi/cli-proxy-api
Restart=always
RestartSec=3
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target
EOF
复制
systemctl daemon-reload
systemctl enable --now cli-proxy-api

不对的查看日志丢给 ai 给你改改

复制
systemctl status cli-proxy-api --no-pager

开始配合机器人配置 API
启动成功后访问 http://127.0.0.1:8317/management.html
用有 Gemini Pro 的账号登录 Antigravity OAuth
登陆完之后会有一个 http://localhost:51121/ 这样的链接,复制下来放到回调 URL 等待验证
然后回到小助理让他帮你配置,像这样 api 地址是 127.0.0.1/v1,类型是 openai 适配的,密钥在你网站的 api 密钥,模型全部复制下来即可
这样模型就变为反重力的了

兄弟们,我是大霖。

今天不说废话,开门见山。

最近我后台的私信快炸了,清一色的哀嚎:“大霖哥,Sora2是不是又崩了?” “我买的中转站API怎么十次失败九次?” “这玩意儿的风控是不是疯了,我就是想生成个小猫跑酷的视频啊!”

看着这些消息,我眼前浮现出一幅赛博朋克末日景象:无数的开发者和内容创作者,对着屏幕上鲜红的“Error”和“Task Failed”提示,默默点上一根电子烟,感觉自己的数字生命正在被无情地燃烧。

哈哈哈,是不是说到你心坎里了?

今天的核心议题就一个:Sora2的“API末日”真的来了吗?以及,我们这些数字世界的游民,该如何找到那艘能稳定航行的诺亚方舟?

一、风暴中心:Sora2 API的“集体沦陷”
首先,得承认一个事实:是的,你们的感觉没错。最近全网的Sora2 API接口,确实正经历一场前所未有的大动荡 。很多之前还能勉强用用的中转站,现在基本处于半瘫痪状态。

我花了两天时间,把我收藏夹里几乎所有的API供应商都测了一遍,结果嘛……只能用“惨不忍睹”来形容。

A平台: 曾经的“性价比之王”,现在提交10个任务,能成功2个就算祖上积德了。失败率飙升,客服永远在排队。
B平台: 号称“官方直连”,结果延迟高到离谱,生成一个10秒视频,我都能看完一集泡面番了。更可气的是,失败了还不退款,钱就这么打了水漂。有家平台失败率甚至超过了30%,退款流程还极其复杂 。
C平台: 玩起了玄学,同样的提示词,上午能出片,下午就“内容安全警告”。这背后就是所谓的Sora2风控(Risk Control)和账号负载(Account Load Balancing)问题。
这背后到底发生了什么?

简单来说,OpenAI官方对于Sora2的API调用,设置了极其严格的风控策略和不透明的账号负载机制 。那些中转站,本质上是“二道贩子”,他们手里可能只有有限的几个官方账号。当大量用户通过他们请求Sora2时,这些账号就会被高并发请求冲垮,或者因为某些用户的“危险”提示词而被风控系统标记,导致整个账号池污染,最后“一锅端”。

结果就是,你,作为一个无辜的终端用户,发现自己的请求莫名其妙就失败了。你不知道是你的提示词有问题,还是中转站的账号被封了。你只知道,你的钱没了,视频也没生成出来 。

这种感觉,就像在黑暗森林里行走,不知道哪一步就会踩空,非常没有安全感。

二、拨开迷雾:如何判断一个API中转站靠不靠谱?
好了,吐槽结束,上点干货。在当前这种混乱的局面下,我们怎么判断一个Sora2 API服务商是不是在“割韭菜”?

记住大霖我总结的黄金三原则,这比你看一百篇评测都有用:

  1. 看失败率,更要看失败是否退款! 这绝对是第一铁律。一个敢于承诺“失败不计费”或“调用失败自动退款”的平台,至少说明两点:第一,他们对自己的技术和渠道稳定性有信心;第二,他们有最基本的商业道德,不赚用户的“冤枉钱”。市面上很多平台,失败了就扣费,你找客服理论,他就跟你打太极。这种平台,有一个算一个,都是垃圾,直接拉黑 。真正靠谱的平台,应该是成功了才计费,这才是对开发者最大的尊重。
  2. 看并发限制,是不是真“无限”? 很多平台嘴上说着“不限并发”,但你稍微上点量,请求就开始排队,甚至直接拒绝。这说明他们的底层架构和账号池根本撑不住。对于需要批量生成视频的团队或应用来说,这一点是致命的。一个真正无并发限制的API,才能保证你的业务在高并发场景下的流畅运行 。
  3. 看接入是否简单,文档是不是人话? 都2026年了,如果一个API的接入还需要你研究半天文档,配置一堆复杂的参数,那它本身就是个失败的产品。好的API应该是“傻瓜式”的,几行代码就能跑通,文档清晰明了,提供现成的代码示例。
    记住这三点,你基本上就能过滤掉市面上90%的坑货。

三、我的选择:速创API,黑暗中的那束光
我知道,你们肯定要问:“大霖,别卖关子了,你到底用的是哪家?”

行,不装了,我摊牌了。

在我几乎要放弃,准备回归Midjourney+Runway的原始人时代时,一个同样在AI圈子里摸爬滚打的朋友,给我甩了个链接——速创API(官网自己搜,我就不贴了,免得说我打广告)。

我当时抱着死马当活马医的心态,充了10块钱进去试试。

然后……卧槽,世界瞬间清净了。

稳定性: 我用脚本挂着跑了一晚上,提交了大概500个任务,涵盖各种刁钻的提示词。你猜怎么着?成功率高得吓人。除了几个我自己写得太离谱的提示词导致内容安全失败外,几乎全部成功生成。官方自己监测的数据说成功率高达98.7% ,我个人体感也差不多。
计费模式: 这才是最骚的。速创API真正做到了“成功才计费,失败秒退款” 。我那几个失败的任务,费用几乎是瞬间就退回到了我的账户余额里,根本不用我操心。有用户实测退款在5分钟内到账 ,我自己的体验是更快。这TM才叫格局!
价格: 价格低到让我怀疑人生,Sora2的调用低至0.2元/次 。什么概念?一杯奶茶的钱,够你一个人一下午的创意挥霍了。这成本,对于独立开发者或者小型工作室来说,简直是天降福音。
并发和接入: 无并发限制,这点我亲测了,短时间提交大量任务毫无压力 。接入过程也极其丝滑,官网注册,拿到API Key,对着文档里的示例代码改两行,直接就能跑。
说实话,我已经很久没有体验过这么流畅的API服务了。它给我的感觉,不像是市面上那些草台班子搭起来的中转站,而是一个真正懂开发者、尊重开发者的技术平台。

四、写在最后
Sora2毫无疑问是AI视频生成的里程碑,它被誉为“世界模拟器” 正在以前所未有的方式降低内容创作的门槛 。但越是强大的工具,就越需要稳定可靠的“管道”来输送它的能量。

在当前这个Sora2 API接口混乱的“战国时代”,选择一个靠谱的供应商,远比你研究如何写出花里胡哨的提示词更重要。因为一个不稳定的API,会不断消耗你的时间、金钱和创作热情。

我今天的分享,不是给速创API打广告,而是把我从坑里爬出来的经验,分享给还在坑里挣扎的兄弟们。

记住,判断一个API中转站靠不靠谱,核心就看两点:失败率高不高,失败了退不退款 。

好了,不废话了。我要生成我的赛博朋克短片了。你们也别在那些“已崩”的平台上浪费生命了。

数字生命,就应该用在更酷的事情上。

大霖, out.

原文链接:https://www.nocobase.com/cn/blog/6-best-open-source-ai-ticket...

之前的文章中,我们梳理了一些可以替代 Zendesk 的开源与自托管 AI 工单系统方案。在文章撰写和资料调研的过程中,我们也持续关注了社区里对相关话题的讨论。 从实际使用体验来看,传统工单系统本质上只是一个记录与流转工具,记录问题、改变状态、最后关闭。至于问题是否被快速理解、是否被正确分派、是否能少走弯路,几乎完全依赖人工经验。 在 Reddit 的技术社区中,有两条讨论引起了我们的注意。

TicketingSystems1.png!

TicketingSystems2.png

越来越多的团队开始尝试引入所谓的 “AI Helpdesk”,希望借助 AI 来缓解支持压力。但在 Reddit 的讨论中,我们看到的反馈却相当一致,也非常直接:

  • AI 往往只是生成一段看起来很聪明的回复
  • 对实际处理效率的提升非常有限
  • 整体流程并没有发生变化,只是在原有系统上多了一个 AI 按钮

如果 AI 只是停留在回复层,而没有真正进入工单流程本身,那它对团队的帮助是非常有限的。


💬 嗨!你正在阅读 NocoBase 博客。NocoBase 是一个极易扩展的 AI 无代码/低代码开发平台,用于构建企业应用、内部工具和各类系统。它完全支持自托管,基于插件架构设计,开发者友好。→ 欢迎在 GitHub 上了解我们


也正是在这样的需求和反馈之下,我们认为,“AI 工单系统”已经不再只是一个简单的产品分类,而更像是一个需要被重新定义的解决方案层级。它不应只是一个会生成回复的系统,而应当是一个能够真正介入流程、自动理解与分派工单、基于知识库给出可用建议,并且能够与企业内部业务系统深度结合的 AI 工单系统。

本文将从 AI 工单系统在 2026 年应具备的核心能力出发,系统性梳理这些能力可以如何在不同系统中实现,帮助你和团队在选型时跳出“是否带 AI”的表层判断,回到效率和结构本身。

2026 AI 工单系统的必备能力

1. 自动理解与摘要 AI 工单系统需要准确理解工单内容,从自然语言描述中提取关键信息,减少人工反复阅读和上下文确认的成本。

2. 智能分类与路由 真正有效的 AI 应当能够自动完成初步分类与优先级判断,并将工单分派给合适的团队或角色,而不是把这些决策继续留给人工处理。

3. 基于知识库的回复建议 AI 的价值在于复用已有知识,通过历史工单和文档给出可编辑的处理建议,而不是直接“自动结案”或输出脱离上下文的通用回答。

4. 流程中的 AI 介入点 AI 应当贯穿工单的完整生命周期,在建单前、处理过程中以及关闭与总结阶段持续发挥作用。

5. 可控、可扩展、可自托管 在企业场景下, AI 工单系统必须支持数据主权和模型可替换,避免被单一 SaaS 锁定,才能在长期发展中保持可控性和扩展空间。

开源 AI 工单系统选型清单

1.NocoBase

官网链接:https://www.nocobase.com/

GitHub 链接:https://github.com/nocobase/nocobase

GitHub Star 数:21.4k

核心定位 NocoBase 是一套以数据模型为核心的开源业务系统平台,通过插件化架构扩展业务能力,并将 AI 能力深度融入系统的核心模块之中。工单、知识库、流程、内部服务台都是其可以构建的业务模块。

🎉基于 NocoBase 2.0 构建的智能工单系统

适合场景

  • 希望高度自定义工单流程的 IT / 内部支持团队
  • 不满足于标准流程,需要结合内部业务系统的组织
  • 对数据主权、自托管、AI 模型可控性有明确要求的企业
  • 希望将工单系统逐步升级为内部智能服务平台的团队

AI 扩展方式

NocoBase 的 AI 能力不是附加功能,而是通过 AI 员工深度融入业务系统。

  1. 自动理解与摘要
  • AI 员工可以理解工单的自然语言描述
  • 结合数据模型与字段结构,自动提取关键信息
  • 支持生成摘要并写回工单字段,减少人工阅读和上下文确认成本

NocoBase1.png

  1. 智能分类与路由
  • AI 可作为工作流中的决策节点
  • 根据工单内容、字段信息和历史数据进行自动分类
  • 计算优先级并分派给对应团队、角色或 SLA 流程

NocoBase2.png

  1. 基于知识库的回复建议(RAG)
  • 工单解决过程可以自动转为知识条目
  • 新工单创建时可基于已有知识推荐相似解决方案
  • AI 员工可以辅助查找已有知识,并生成建议回复

NocoBase3.gif

  1. 流程中的 AI 介入点
  • AI 可介入建单前(表单填写辅助)
  • 处理过程中(分析、建议、补充信息)
  • 关闭阶段(总结工单、沉淀知识)

NocoBase4.gif

  1. 可控、可扩展、可自托管
  • 100% 开源、完全自托管
  • 支持多种 AI 模型(OpenAI、Claude、本地模型)
  • 插件化架构,可基于企业业务灵活调整系统

NocoBase5.png

2. Frappe Helpdesk

官网链接:https://frappe.io/helpdesk

GitHub 链接:https://github.com/frappe/helpdesk

GitHub Star 数:2.9k

核心定位 Frappe Helpdesk 并不是一个孤立的工单系统,而是 Frappe 业务平台中的一部分,天然与 ERP、CRM、项目管理等模块共享数据模型,更偏向业务系统一体化的服务支持方案。

适合场景

  • 已经在使用 ERPNext / Frappe 平台的组织
  • 希望将工单与业务数据、客户、订单、资产等信息打通的团队
  • 对“系统一致性”和内部数据联动要求高,而非只关注客服功能的企业
  • 内部 IT 支持、业务支持型 Helpdesk 场景

AI 扩展方式

Frappe Helpdesk 的可以作为业务平台的一部分,能够让工单自然融入企业已有的数据与流程体系。对于已经使用 ERPNext 的团队来说,它更像是一个业务支持入口,而不是独立的 AI 工单系统产品。

  1. 自动理解与基础分类(可扩展)
  • 可结合 Frappe 平台已有的数据结构
  • 通过外部 LLM 或自建 AI 服务,对工单描述进行基础理解

Frappe Helpdesk1.png

  1. 基于业务数据的辅助建议
  • 工单可直接关联 ERP / CRM 数据
  • AI 可基于已有业务记录,给出处理参考或背景说明
  • 更适合“业务支持型”场景,而非高并发客服场景

Frappe Helpdesk2.png

3. Chatwoot

官网链接:https://www.chatwoot.com/

GitHub 链接:https://github.com/chatwoot/chatwoot

GitHub Star 数: 27.1k

核心定位 Chatwoot 可以统一承载来自不同渠道的对话,并将这些对话转化为可处理的支持请求或工单。

适合场景

  • 需要统一管理 Web Chat、Email、社交媒体、IM 等多渠道支持入口的团队
  • 将“对话”作为服务起点,而不是先生成工单的组织
  • 希望在支持流程前端引入 AI,减轻人工接待和初步沟通压力的团队

AI 扩展方式

Chatwoot 并不以复杂的工单生命周期管理见长,其 AI 能力更多集中在沟通与入口层。

  1. 自动理解与摘要
  • Chatwoot 天然以“对话”为核心对象
  • 通过接入外部 LLM,可实现:

    • 对话摘要
    • 回复草稿生成
    • 常见问题自动应答

Chatwoot1.png

  1. 工单触发与前置分流
  • 对话可根据规则或 AI 判断转化为工单
  • 在建单前完成初步筛选和分流
  • 减少无效或重复工单进入后端系统

Chatwoot2.png

4. Zammad

官网链接:https://zammad.com/

GitHub 链接:https://github.com/zammad/zammad

GitHub Star 数: 5.4k

核心定位 Zammad 以完整的工单生命周期管理为核心,强调多渠道接入、状态流转、权限与 SLA 管理,是一款流程导向非常明确的 Helpdesk 工具。

适合场景

  • 需要一套成熟、结构清晰的 Helpdesk 系统的 IT 支持团队
  • 对工单生命周期、权限和 SLA 管理有明确要求的组织
  • 希望在稳定工单流程之上,引入 AI 做辅助判断与建议的团队
  • 以 Helpdesk 为核心,而非平台化重构的场景

AI 扩展方式

Zammad 本身并不内置 AI 功能,但其规则引擎与 API 设计,使其非常适合在既有流程上叠加 AI 能力。

  1. 自动理解与摘要(可扩展)
  • 可通过 API / Webhook 接入外部 LLM
  • 帮助支持人员快速把握问题核心,减少人工阅读成本

Zammad1.png

  1. 规则驱动的分类与分派
  • Zammad 拥有成熟的规则系统
  • AI 可辅助完成主题识别、优先级判断
  • 结合现有规则,实现更智能的分派与升级逻辑

Zammad2.png

  1. 基于知识库的回复建议
  • Zammad 支持知识库模块
  • 可通过外部 AI 服务,基于已有知识内容生成回复建议

Zammad3.png

5. FreeScout

官网链接:https://freescout.net/

GitHub 链接:https://github.com/freescout-help-desk/freescout

GitHub Star 数:4k

核心定位 FreeScout 可以提供一个简单、可控的共享收件箱与工单管理工具,功能聚焦、学习成本低,更接近“开源版 Help Scout”。

适合场景

  • 中小团队或初期阶段的支持团队
  • 以邮件工单为主要支持渠道的组织
  • 预算敏感、希望避免复杂系统引入成本的团队
  • 对流程复杂度要求不高,但希望逐步引入 AI 辅助的场景

AI 扩展方式

FreeScout 本身并不内置 AI 能力,但其插件机制和简单的数据结构,使其可以在有限范围内叠加 AI 辅助功能。

  1. 基于知识库的回复建议(可扩展)
  • 结合已配置的知识库内容、历史工单或预设回复模板
  • 利用 LLM 生成可编辑的回复草稿,供支持人员参考和调整
  • 更适合处理常见问题或重复性场景,而非复杂、多轮上下文的推理

FreeScout1.png

  1. 基于规则的初步分类
  • 可结合规则与 AI 辅助判断结果
  • 对邮件工单进行初步分类或标签标记

FreeScout2.png

6. Faveo Helpdesk

官网链接:https://www.faveohelpdesk.com/

GitHub 链接:https://github.com/faveosuite/faveo-helpdesk

GitHub Star 数:1.2k

核心定位

Faveo Helpdesk 是基于 Laravel 生态的开源 Helpdesk 系统。内置工单、知识库与基础流程管理能力,强调可读性与可扩展性,适合进行二次开发和功能增强。

适合场景

  • 使用 Laravel / PHP 技术栈的团队
  • 希望在 Helpdesk 基础之上,逐步引入定制功能或 AI 能力的组织
  • 对知识库建设与内容复用有明确需求的支持团队
  • 不追求平台级重构,但需要一定扩展空间的场景

AI 扩展方式

Faveo Helpdesk 的 AI 扩展主要依托其知识库结构清晰、代码可扩展的特点,更适合从“内容与建议层”引入 AI。

  1. 基于知识库的回复建议
  • 内置知识库模块,结构清晰
  • 可结合外部 LLM,对知识库内容进行检索与生成
  • 为支持人员提供可编辑的回复建议

Faveo Helpdesk1.png

  1. 自动理解与摘要(可扩展)
  • 可通过 Laravel 生态中的 AI 服务
  • 对工单描述进行基础语义理解与摘要
  • 帮助支持人员更快把握问题背景。

Faveo Helpdesk2.png

结语

在选型过程中,比起功能数量,更应该关注 AI 能够在多深的程度上参与到你的工单流程中,系统是否具备持续扩展这些能力的空间。

随着使用场景的变化,工单系统的边界也在不断延展,从最初的问题记录工具,到内部服务台,再到如今的 AI 驱动的业务支持平台,新一代的工单系统正在逐步成为企业内部协作与服务交付的重要基础设施。

💕如果你在工单系统选型或 AI 工单系统实践中有类似困惑,希望这篇文章能带来一些参考,欢迎分享给更多感兴趣的朋友。

相关阅读:

在构建问答Agent时,多轮对话的上下文记忆是核心需求——让Agent能记住历史对话内容,结合「历史问题+历史回答+当前问题」给出连贯回复,而非孤立回答每个问题。

LangChain中的ConversationBufferMemory轻量、易用的短期记忆组件,核心作用是按顺序缓存对话历史,并将历史内容注入到模型的输入提示中,实现问答Agent的短期记忆能力,适合中小长度的多轮对话场景。

本文将基于LangChain框架,从核心原理、完整可运行代码、关键细节、进阶优化四个维度,教你为问答Agent集成ConversationBufferMemory,支持OpenAI/国产大模型(通义千问/文心一言),代码可直接复用。

一、核心概念铺垫

1.1 ConversationBufferMemory 核心作用

  • 键值对形式按时间顺序存储对话历史(问题+回答);
  • 支持将对话历史格式化为字符串/消息对象,注入到LLM的输入提示中;
  • 提供清空记忆、获取记忆、修改记忆的便捷方法;
  • 轻量无依赖,无需额外存储,对话历史保存在内存中(会话结束即销毁,符合「短期记忆」定位)。

1.2 核心搭配

ConversationBufferMemory通常与ConversationChain(通用对话链)/RetrievalQA(知识库问答链)搭配使用,本文先实现基础问答Agent(基于ConversationChain),后续补充带知识库的问答Agent优化方案。

1.3 关键参数

参数名作用常用值
memory_key记忆在提示模板中的变量名(需与提示模板一致)chat_history(推荐)
return_messages记忆返回格式:True返回消息对象(HumanMessage/AIMessage)False返回拼接字符串False(基础场景)/True(复杂场景)
input_key输入问题的变量名input(默认,无需修改)
output_key输出回答的变量名output(默认,无需修改)

二、环境准备

安装LangChain核心依赖+大模型适配依赖(以OpenAI/通义千问为例,二选一即可):

# 核心依赖:LangChain核心+社区组件
pip install langchain-core langchain-community -i https://pypi.tuna.tsinghua.edu.cn/simple

# 可选1:OpenAI模型依赖(GPT-3.5/GPT-4)
pip install langchain-openai -i https://pypi.tuna.tsinghua.edu.cn/simple

# 可选2:国产大模型依赖(通义千问/文心一言/智谱清言)
pip install langchain-qianfan langchain-dashscope -i https://pypi.tuna.tsinghua.edu.cn/simple

三、完整实现:基础问答Agent+短期记忆

3.1 方案1:基于OpenAI模型(GPT-3.5/GPT-4)

# 1. 导入核心模块
from langchain_openai import ChatOpenAI
from langchain.chains import ConversationChain
from langchain.memory import ConversationBufferMemory
from langchain.prompts import PromptTemplate
import os

# 2. 配置环境(OpenAI API密钥)
# 国内用户需配置代理:os.environ["HTTP_PROXY"] = "http://127.0.0.1:7890"
os.environ["OPENAI_API_KEY"] = "你的OpenAI API密钥"

# 3. 初始化LLM模型
llm = ChatOpenAI(
    model="gpt-3.5-turbo",  # 推荐gpt-3.5-turbo,性价比高
    temperature=0.1,        # 越低回答越稳定,适合问答场景
    max_tokens=2048
)

# 4. 初始化ConversationBufferMemory(核心:短期记忆)
memory = ConversationBufferMemory(
    memory_key="chat_history",  # 记忆变量名,需与提示模板中的{chat_history}一致
    return_messages=False,      # 返回字符串格式的对话历史,适合基础场景
    input_key="input"           # 输入问题的变量名,默认input即可
)

# 5. 自定义带记忆的提示模板(必须包含{chat_history}和{input})
# 模板说明:chat_history=历史对话,input=当前问题,让模型结合两者回答
prompt = PromptTemplate(
    input_variables=["chat_history", "input"],  # 必须包含记忆变量和输入变量
    template="""你是一个专业的问答助手,善于结合历史对话内容回答当前问题。
    历史对话:{chat_history}
    当前问题:{input}
    请简洁、准确地回答当前问题,无需额外赘述。"""
)

# 6. 构建带记忆的问答链(核心:将LLM、记忆、提示模板绑定)
conversation_chain = ConversationChain(
    llm=llm,
    memory=memory,
    prompt=prompt,
    verbose=True  # 开启详细日志,可查看输入的提示内容(含历史对话)
)

# 7. 测试多轮问答(验证记忆效果)
if __name__ == "__main__":
    # 第一轮问答
    print("===== 第一轮 =====")
    res1 = conversation_chain.invoke({"input": "什么是大语言模型?"})
    print("回答:", res1["output"], "\n")

    # 第二轮问答(结合历史:问大语言模型的核心优势)
    print("===== 第二轮 =====")
    res2 = conversation_chain.invoke({"input": "它的核心优势是什么?"})
    print("回答:", res2["output"], "\n")

    # 第三轮问答(结合历史:问该优势的应用场景)
    print("===== 第三轮 =====")
    res3 = conversation_chain.invoke({"input": "这些优势能用到哪些领域?"})
    print("回答:", res3["output"], "\n")

    # 手动查看记忆中的对话历史
    print("===== 查看短期记忆 =====")
    print(memory.load_memory_variables({}))

    # 清空记忆(可选)
    # memory.clear()
    # print("清空记忆后:", memory.load_memory_variables({}))

3.2 方案2:基于国产模型(通义千问,国内用户推荐)

替换上述步骤2和步骤3即可,其余代码完全不变,适配性拉满:

# 2. 配置环境(通义千问API密钥,从阿里云DashScope获取)
os.environ["DASHSCOPE_API_KEY"] = "你的通义千问API密钥"

# 3. 初始化通义千问模型(替换OpenAI)
from langchain_dashscope import ChatDashScope
llm = ChatDashScope(
    model="qwen-plus",  # 通义千问轻量版,免费额度足够测试
    temperature=0.1,
    max_tokens=2048
)

3.3 运行结果与关键日志

核心输出(记忆生效)

===== 第一轮 =====
回答: 大语言模型是基于大尺度语料训练、具备强大自然语言理解与生成能力的人工智能模型,能完成文本创作、问答、翻译等多种自然语言处理任务。

===== 第二轮 =====
回答: 大语言模型的核心优势包括:1. 强大的上下文理解与语义分析能力;2. 灵活的自然语言生成能力,可输出流畅、贴合语境的文本;3. 泛化能力强,能处理未见过的新问题;4. 多任务适配,无需单独训练即可完成多种NLP任务。

===== 第三轮 =====
回答: 这些优势可应用在智能客服、内容创作、教育辅导、代码开发、数据分析、机器翻译、智能助手等领域,覆盖互联网、教育、金融、制造业等多个行业。

===== 查看短期记忆 =====
{'chat_history': 'Human: 什么是大语言模型?\nAI: 大语言模型是基于大尺度语料训练、具备强大自然语言理解与生成能力的人工智能模型,能完成文本创作、问答、翻译等多种自然语言处理任务。\nHuman: 它的核心优势是什么?\nAI: 大语言模型的核心优势包括:1. 强大的上下文理解与语义分析能力;2. 灵活的自然语言生成能力,可输出流畅、贴合语境的文本;3. 泛化能力强,能处理未见过的新问题;4. 多任务适配,无需单独训练即可完成多种NLP任务。\nHuman: 这些优势能用到哪些领域?\nAI: 这些优势可应用在智能客服、内容创作、教育辅导、代码开发、数据分析、机器翻译、智能助手等领域,覆盖互联网、教育、金融、制造业等多个行业。'}

Verbose日志(关键:验证历史对话注入)

开启verbose=True后,可看到模型的实际输入提示包含了历史对话,这是记忆生效的核心:

> Entering new ConversationChain chain...
Prompt after formatting:
你是一个专业的问答助手,善于结合历史对话内容回答当前问题。
    历史对话:Human: 什么是大语言模型?
AI: 大语言模型是基于大尺度语料训练、具备强大自然语言理解与生成能力的人工智能模型,能完成文本创作、问答、翻译等多种自然语言处理任务。
    当前问题:它的核心优势是什么?
    请简洁、准确地回答当前问题,无需额外赘述。
> Finished chain.

四、关键细节:避免记忆失效的核心要点

ConversationBufferMemory使用简单,但容易因参数不匹配、提示模板错误导致记忆失效,以下是必须遵守的3条铁律:

4.1 提示模板必须包含memory_key指定的变量

比如memory_key="chat_history",则提示模板中必须有{chat_history},且输入变量列表要包含该变量:

# 正确:input_variables包含chat_history和input
prompt = PromptTemplate(
    input_variables=["chat_history", "input"],
    template="历史对话:{chat_history}  当前问题:{input}"
)

# 错误:缺少chat_history,记忆无法注入
prompt = PromptTemplate(
    input_variables=["input"],
    template="当前问题:{input}"
)

4.2 invoke入参必须是字典,且键为input_key

默认input_key="input",因此调用时必须传{"input": "你的问题"},而非直接传字符串:

# 正确
conversation_chain.invoke({"input": "什么是大语言模型?"})

# 错误:入参不是字典,记忆无法关联当前问题
conversation_chain.invoke("什么是大语言模型?")

4.3 避免手动修改对话历史(除非特殊需求)

ConversationBufferMemory自动追加每次的inputoutput到记忆中,无需手动修改:

# 自动追加:无需干预
conversation_chain.invoke({"input": "问题1"})  # 记忆中添加问题1+回答1
conversation_chain.invoke({"input": "问题2"})  # 记忆中追加问题2+回答2

# 手动修改(特殊需求时使用)
memory.save_context(
    inputs={"input": "手动添加的问题"},
    outputs={"output": "手动添加的回答"}
)

五、进阶优化:适配更复杂的问答场景

5.1 优化1:带知识库的问答Agent+短期记忆

实际场景中,问答Agent通常需要结合私有知识库(如PDF/文档),此时将ConversationChain替换为RetrievalQA,并搭配ConversationBufferMemory即可实现「知识库+多轮记忆」的问答能力:

# 新增:导入知识库相关模块
from langchain_community.document_loaders import TextLoader
from langchain_community.vectorstores import FAISS
from langchain_text_splitters import CharacterTextSplitter
from langchain_openai import OpenAIEmbeddings
from langchain.chains import RetrievalQA

# 1. 加载知识库(以文本文件为例,可替换为PDF/Word加载器)
loader = TextLoader("your_knowledge_base.txt")  # 你的知识库文件
documents = loader.load()
# 分割文本为小片段
text_splitter = CharacterTextSplitter(chunk_size=1000, chunk_overlap=100)
texts = text_splitter.split_documents(documents)
# 构建向量库
embeddings = OpenAIEmbeddings()
db = FAISS.from_documents(texts, embeddings)
retriever = db.as_retriever(search_kwargs={"k": 3})  # 每次检索3个相关片段

# 2. 初始化记忆(与基础版一致)
memory = ConversationBufferMemory(
    memory_key="chat_history",
    return_messages=False,
    input_key="question"  # 注意:RetrievalQA的默认输入键是question,需修改
)

# 3. 构建带记忆的知识库问答链
qa_chain = RetrievalQA.from_chain_type(
    llm=llm,
    chain_type="stuff",  # 适合小片段文本,简单高效
    retriever=retriever,
    memory=memory,
    chain_type_kwargs={
        "prompt": PromptTemplate(
            input_variables=["chat_history", "context", "question"],
            template="""结合历史对话和知识库内容回答当前问题,若知识库无相关内容,仅结合历史对话回答。
            历史对话:{chat_history}
            知识库内容:{context}
            当前问题:{question}
            回答要求:简洁、准确,基于知识库内容,不要编造。"""
        )
    },
    verbose=True
)

# 4. 测试:结合知识库+历史对话的多轮问答
qa_chain.invoke({"question": "知识库中提到的大语言模型有哪些应用?"})
qa_chain.invoke({"question": "这些应用中,哪个在教育领域的落地效果最好?"})  # 结合历史

5.2 优化2:限制记忆长度(避免历史对话过长)

ConversationBufferMemory无限制追加对话历史,当对话轮数过多时,会导致提示词过长、推理成本增加、模型注意力分散

解决方案:使用ConversationBufferWindowMemory(窗口记忆),仅保留最近N轮对话,本质是ConversationBufferMemory的进阶版,参数完全兼容:

from langchain.memory import ConversationBufferWindowMemory

# 仅保留最近2轮对话,超出的自动丢弃
memory = ConversationBufferWindowMemory(
    memory_key="chat_history",
    k=2,  # 核心参数:保留最近k轮对话
    return_messages=False
)

# 用法与ConversationBufferMemory完全一致,无需修改其他代码
conversation_chain = ConversationChain(llm=llm, memory=memory, prompt=prompt)

5.3 优化3:记忆格式为消息对象(适合复杂提示)

当提示模板需要更精细的对话格式时,将return_messages=True,记忆会返回HumanMessage/AIMessage对象,而非拼接字符串,便于灵活格式化:

# 初始化记忆:返回消息对象
memory = ConversationBufferMemory(
    memory_key="chat_history",
    return_messages=True,  # 核心:返回消息对象
    input_key="input"
)

# 自定义提示模板:遍历消息对象格式化
from langchain.prompts import ChatPromptTemplate, MessagesPlaceholder

# 使用MessagesPlaceholder接收消息对象,无需手动拼接
prompt = ChatPromptTemplate.from_messages([
    ("system", "你是专业的问答助手,结合历史对话回答问题。"),
    MessagesPlaceholder(variable_name="chat_history"),  # 匹配memory_key
    ("human", "{input}")  # 匹配input_key
])

# 构建链(用法不变)
conversation_chain = ConversationChain(llm=llm, memory=memory, prompt=prompt)

六、常用操作:记忆的增删改查

ConversationBufferMemory提供了便捷的方法操作记忆,满足个性化需求:

# 1. 查看记忆内容
memory.load_memory_variables({})  # 返回字典,键为memory_key

# 2. 清空记忆(会话结束/切换用户时使用)
memory.clear()

# 3. 手动添加记忆
memory.save_context(
    inputs={"input": "手动添加的问题"},
    outputs={"output": "手动添加的回答"}
)

# 4. 手动删除记忆(需先获取记忆,再修改,最后重新保存)
# 步骤1:获取记忆内容
chat_history = memory.load_memory_variables({})["chat_history"]
# 步骤2:修改/删除内容(如删除最后一行)
chat_history = "\n".join(chat_history.split("\n")[:-2])
# 步骤3:重新保存
memory.chat_memory.add_user_message("")  # 清空原有记忆
memory.chat_memory.add_ai_message("")
memory.save_context(inputs={"input": ""}, outputs={"output": chat_history})

七、总结

7.1 核心流程回顾

为问答Agent添加ConversationBufferMemory的核心步骤仅5步:

  1. 安装LangChain核心依赖+大模型依赖;
  2. 初始化LLM模型(OpenAI/国产模型);
  3. 初始化ConversationBufferMemory,指定memory_key
  4. 构建包含记忆变量的提示模板;
  5. 将LLM、记忆、提示模板绑定到对话链,调用invoke实现多轮问答。

7.2 记忆组件选型建议

记忆组件核心特点适用场景
ConversationBufferMemory无限制保存所有对话历史,轻量易用短对话、测试场景
ConversationBufferWindowMemory保留最近N轮对话,限制长度常规多轮问答场景(推荐)
ConversationSummaryMemory对长对话历史做摘要压缩,节省令牌超长对话、高成本模型场景
VectorStoreRetrieverMemory将对话历史存入向量库,按需检索相关历史需精准匹配历史对话的复杂场景

7.3 性能优化建议

  1. 优先使用ConversationBufferWindowMemory,并设置合理的k值(如3-5轮);
  2. 降低LLM的max_tokens,避免无意义的长回答;
  3. 开启verbose=False(生产环境),减少日志开销;
  4. 生产环境中,可将记忆与会话ID绑定,实现多用户隔离。

八、常见问题排查

问题1:记忆失效,模型不结合历史对话回答

  • 原因:提示模板缺少memory_key变量,或input_variables未包含该变量;
  • 解决:检查提示模板,确保包含{chat_history}(或自定义的memory_key),且input_variables列表包含该变量。

问题2:调用时提示「key error: input」

  • 原因:invoke入参不是字典,或键与input_key不匹配;
  • 解决:调用时传{"input": "你的问题"}(默认input_key="input"),若修改了input_key,则传对应键。

问题3:知识库问答Agent记忆失效

  • 原因:RetrievalQA的默认输入键是question,而非input,记忆的input_key不匹配;
  • 解决:初始化记忆时设置input_key="question"

问题4:对话历史过长,模型推理变慢

  • 原因:ConversationBufferMemory无限制追加历史;
  • 解决:替换为ConversationBufferWindowMemory,设置k值限制轮数。

编辑:倾倾

【新智元导读】这是一份迟到三年的行业复盘。牛津大学最新的实证研究撕开了那层遮羞布:2022年全球科技大裁员爆发时,ChatGPT甚至尚未发布。周期性缩编被伪装成技术性迭代,AI替资本背了三年的锅,直到今天真相才被彻底复位。

一场幻觉,竟然持续了三年!

2022年11月,ChatGPT横空出世,随后硅谷开启大裁员,程序员和写手哀鸿遍野。

所有人都觉得,因为AI来了,所以我们失业了。

然而,一项由牛津大学和基尔世界经济研究所团队发布的论文却告诉我们,我们恨错了人!

论文地址:
https://arxiv.org/abs/2601.02554

其实早在ChatGPT上线半年前,这些行业的需求已呈现断崖式下跌。

那时,OpenAI还在调GPT-3.5的参数,根本没有功夫抢你的工作。

既然如此,到底谁才是幕后真凶?又是谁让AI成了替罪羊?

一场持续3年的「集体幻觉」

如果真如传言中那样,2022年的岗位需求应该在11月之后断崖式下跌。

然而,数据显示,下跌其实早就开始了。

计算机、商务、金融等高AI暴露率的职业,其失业风险在2022上半年已远超餐饮与建筑业。

但这会儿,奥特曼还在为算力账单发愁,ChatGPT甚至没有出生。

所以,我们不能贸然将失业和AI划等号,就像你无法指控未出世的婴儿杀了人。

为了进一步验证以防误伤,研究团队开始了一场对照试验。

实验组是科技依赖型岗位。2022年上半年,随着「远程办公泡沫」破裂,LinkedIn数据显示远程职位申请竞争度飙升,但招聘需求却从2022年初的峰值开始滑坡。

对照组是非科技依赖型工作,如餐饮、护理等在同一时间不仅没有崩盘,反而因为「后疫情复苏」出现了严重的用工荒。

不同职业从的失业风险变化,颜色的深浅表示职业的暴露度。颜色越深,暴露度越高

如果说GPT的出现取代了人类的工作,那么最开始取代的也应该是低级脑力工作,高级技能岗位依旧保留。

但数据显示的结果是无差别的行业雪崩。不论你是初级码农还是资深架构师,只要身处科技与外包行业,均被无差别清洗。

这就说明,受害者是按照行业资金充裕度划定的,而不是「是否能被AI替代」。

所以,杀死工作的凶手,肯定不是当时的GPT-3.5,它只是经过,就成了替罪羊。

杀死你的不是算法,是周期

既然GPT只是替罪羊,那么,凶手到底是谁?

如果一定要指名道姓,那么凶手应当是美联储主席Jerome Powell,或者说,是那时的宏观周期。

让我们看向更早的时间点——2021年。

那是一个疯狂的年份,全球疫情导致物理隔绝,科技公司以为这种数字化繁荣将成为常态。

于是,巨头和独角兽们开启了一场史无前例的「抢人大战」,钱也慢慢变得不值钱。

只要你会写代码、会画图、甚至只要简历上沾点「数字化」,你就能拿到溢价50%的Offer。

转折点发生在2022年年初,美联储开启暴力加息周期,全球风险投资瞬间腰斩。

根据Crunchbase的统计数据,2022年第三季度的全球风投融资额仅为810亿美元,同比暴跌53%。

市场上流动的「抢人预算」在一夜之间蒸发了一半。

AI只是其中的原因之一,更多是因为初创公司「账上没钱了」,为了生存,只能裁员。

牛津大学的研究进一步证实了这一点。

如果将2022-2025年的「高科技职位招聘需求曲线」拿出来,就能发现,它与纳斯达克指数的走势惊人地重合,却与GPT-4等模型的发布时间点毫无相关性。

利率上行,纳指下挫,招聘冻结——这完全符合宏观经济学模型,与「技术奇点」无关。

我们必须承认,2020-2021年的抢人大战才是异常现象。

那时,因为无限量化宽松,各类科技公司疯狂囤积人才,许多程序员拿着高薪实际上在做着重复的工作。

2022年的惨烈裁员潮,本质上是市场在暴力纠错——从「泡沫逻辑」回归到「商业常识」,而不是技术性淘汰。

借刀杀人:一场蓄谋已久的「洗白」

如前文所述,裁员是宏观经济造成的,为什么所有公司都要把锅甩给AI?

答案很简单:AI是资本市场上最好用的「遮羞布」。

分析师们给这种现象起了一个专属名词——「AI冗余洗白」

假如你是一位纳斯达克上市公司的CEO。在这个资金寒冬里,你的业绩下滑,现金流紧张,必须要裁掉10%的员工来缩减开支。此时摆在你面前的有两份公关稿:

低情商:因为我们前两年盲目扩张、管理不善,导致现在没钱了,被迫裁员。

  • 后果:股价暴跌,股东愤怒,董事会质疑你的能力,你可能比员工先卷铺盖走人。

高情商:我们要All in AI,所以要进行战略性组织重构,优化冗余人力,打造更高效的AI驱动型企业。

  • 后果:股价大涨,分析师为你鼓掌,称赞你拥有「壮士断腕」的远见卓识。

如果你是CEO,你会选哪一个?答案不言自明。

来看看那些教科书级别的洗白案例:

Dropbox作为最早的「示范单位」,CEO Drew Houston在裁掉16%员工(500人)时,高调宣布:

AI计算时代终于到来了,我们的下一阶段增长需要不同的技能组合。

从物流巨头UPS裁员1.2万人,到各大科技公司如Amazon、Google的滚动式裁员,高管们在解释裁员理由时,「AI」一词的出现频率比「利润」还高。

多项行业调查显示,相当比例的高管承认,将裁员与AI挂钩是为了避免被市场视为「落伍者」。

老板们心里比谁都清楚,现阶段的AI根本干不了那一万名员工的活。

但在资本市场上,只要喊出AI的口号,裁员就不再是「衰退,而是进化。

所以,不是AI抢了你的工作,而是老板借着AI的名义,干掉了那些他早就想干掉、却一直找不到完美理由干掉的人。

从暂时失业到永久出局

既然是经济周期作祟,那是不是只要等到降息、等到经济复苏,属于我们的那个「黄金时代」就会回来?

遗憾的是,这才是本报告最残酷的真相。

经济学中的「疤痕效应」,精准描述了我们此刻的困境:当2024-2025年宏观经济终于开始解冻时,不同行业的命运走向了截然相反的两端。

随着美联储降息预期升温,非科技依赖型行业(如酒店、医疗、建筑)的需求曲线呈现「V型」或「U型」反弹,迅速回到了疫情前的水平。

科技职位信息在 2022 年初之前后翻了一倍以上,但此后已全部回撤,截至 2025 年 7 月 11 日,较疫情前水平低 36%。

然而,高AI暴露职位(文案、初级代码、翻译)的需求曲线却是绝望的「L型」——在经历了2022年的暴跌后,陷入结构性停滞,彻底与经济复苏脱钩。

这就解释了为什么你感觉「经济好像好了,但我的行业还没好」。

因为企业在裁员后发现:虽然当初是因为没钱才裁员,但现在有了AI辅助,似乎确实不再需要把这些人招回来了。

Upwork和Fiverr等前沿市场的数据印证了这种「K型分化」:

  • 下行线(K之下):纯粹的翻译、纯粹的SEO文章写作、纯粹的初级Java外包,需求量几乎归零。
  • 上行线(K之上):标有「AI-Assisted」(AI辅助)、「Prompt Engineering」(提示词优化)或者是能驾驭AI的高级全栈工程师,薪资和需求都在飙升。

如果说美联储是突发性杀手,那么AI就是慢性毒药。

它确保了那些因经济周期消失的岗位,永远不会再回来。它把周期性的「临时失业」,变成了结构性的「永久淘汰」。

2022年,老板因为穷开不起单;2026年,老板因为不需要,所以不开单。

我们耗费三年,将所有焦虑错投给了一个假想敌。

却忽略了在资本寒冬里,真正的生存法则从来没变过:技术只是筹码,谁掌握了资本的流向,谁才拥有定义的权力。

所以,别再问「AI何时会取代我」,这个问题已是过去式了。

你应该问的是:

当所有的借口都被揭穿之后,除了那个随时可以被量化的自己,你手里还有没有底牌?

 在 AI 圈,Sam Altman 的每一次发声都被视为对未来“天气预报”的更新。

 

昨晚,Altman 在 X 上发帖称将举办一场线上研讨会,希望在开始构建新一代工具之前收集大众的反馈和意见。

北京时间今早 8 点,这场由 OpenAI CEO Sam Altman 发起的研讨会如约而至。来自各行业的创业者、CTO、科学家和开发者社区的代表,围绕 AI 的未来形态、模型演进、智能体(Agent)、科研自动化以及安全问题,向 Altman 提出了最尖锐、也最现实的问题。

 

研讨会上,这位 OpenAI 的掌舵人不仅勾勒了 GPT-5 及其后续版本的进化蓝图,同时揭示了一个令所有开发者和创业者不得不面对的现实:我们正在进入一个智力成本极低、软件形态从“静态”转向“即时生成”的剧变期

 

会谈的第一个焦点,落在了 GPT-5 性能表现的“非对称性”上。有开发者敏锐地察觉到,相较于 GPT-4.5,新版本在逻辑推理和编程上极强,但在文采上似乎略逊一筹。对此,Altman 表现出了极高的坦诚。

 

他承认,OpenAI 在 GPT-5.2 的研发中确实“搞砸了”写作能力的优先级,因为团队将有限的算力资源倾斜在了推理、编码和工程能力这些硬核智力指标上

 

在 Altman 看来,智力是一种“可塑的资源”,当模型具备了顶级的推理引擎,写作能力的回归只是时间问题。这种“偏科”实际上反映了 OpenAI 的某种战略重心:先通过 Scaling Law(规模定律)攻克人类智力的最高地带,再回头去填补审美和表达的细节。这意味着,未来模型的竞争将不再是单一维度的比拼,而是看谁能更早地在全维度上实现“智力平权”。

 

如果说智力水平决定了天花板,那么成本和速度则决定了 AI 的渗透率。Altman 在会上给出了一个极具震撼力的承诺:到 2027 年底,GPT-5.2 级别的智力成本将至少下降 100 倍

 

然而,这种“廉价到无需计量”的未来并非终点。

 

Altman 指出,市场正在发生微妙的转向:开发者对“速度”的渴求正在超越对“成本”的关注。随着 Agent(智能体)开始处理数十个步骤的长程任务,如果输出速度不能实现百倍以上的提升,那么复杂的自主决策将变得毫无实用价值。在这种权衡下,OpenAI 可能会提供两种路径:一种是极致廉价的“智力自来水”,另一种则是极速反馈的“智力推进器”。这种对速度的强调,预示着 AI 应用将从简单的问答,彻底跨入高频、实时的自动驾驶阶段。

 

在这种智力成本骤降、速度飙升的背景下,传统软件的概念正在瓦解。Altman 提出了一个颠覆性的愿景:未来的软件不应该是静态的。

 

过去,我们习惯于下载一个通用的 Word 或 Excel;未来,当你遇到一个特定问题时,计算机应该直接为你写一段代码,生成一个“即时应用”来解决它。这种“随需随生、用完即弃”的模式将彻底重构操作系统。虽然我们可能出于习惯保留一些熟悉的交互按钮,但背后的逻辑架构将是高度个人定制化的。每个人手中的工具都会随着其工作流的积累而演化,最终形成一套独属于个人的、动态进化的生产力系统。这不仅仅是软件的定制,更是生产关系的重组。

 

InfoQ 翻译并整理了这场研讨会的重点内容,以飨读者:

 

提问:您如何看待 AI 对未来社会和经济的影响?

 

Sam Altman:说实话,要在一年内完全消化这种规模的经济变革是非常困难的。但我认为这会极大地赋能每一个人:它将带来大规模的资源富足、门槛降低,以及创造新事物、建立新公司和探索新科学的极低成本。

 

只要我们在政策上不出大差错,AI 应该成为社会的一种“平衡力量”,让那些长期以来未被公正对待的人获得真正的机会。但我确实担心,AI 也可能导致权力和财富的高度集中,这必须是政策制订的核心关注点,我们要坚决避免这种情况发生。

 

提问:我发现 GPT-4.5 曾是写作能力的巅峰,但最近 GPT-5 在 ChatGPT 里的写作表现似乎有些笨拙、难以阅读。显然 GPT-5 在 Agent(智能体)、工具调用和推理上更强,它似乎变得更“偏科”了(比如编程极强,写作一般)。OpenAI 怎么看这种能力的失衡?

 

Sam Altman:坦诚说,写作这一点确实是我们搞砸了。我们希望未来的 GPT-5.x 版本在写作上能远超 4.5。

 

当时我们决定将大部分精力放在 GPT-5.2 的“智力、推理、编程和工程能力”上,因为资源和带宽是有限的,有时专注于某一方面就会忽略另一方面。但我坚信未来属于“通用的高素质模型”。即便你只想让它写代码,它也应该具备良好的沟通和表达能力,能清晰、犀利地与你交流。我们认为“智力”在底层是相通的,我们有能力在一个模型中把这些维度都做到极致。目前我们确实在猛攻“编程智力”,但很快就会在其他领域赶上来。

智能将廉价到无需计量

 

提问:对于运行数千万个 Agent 的开发者来说,成本是最大的瓶颈。您如何看待小模型和未来的成本降幅?

 

Sam Altman:我们的目标是,到 2027 年底,让 GPT-5.2 级别的智力成本至少降低 100 倍。

 

但现在有一个新趋势:随着模型输出变得越来越复杂,用户对“速度”的需求甚至超过了“成本”。OpenAI 非常擅长压低成本曲线,但过去我们对“极速输出”的关注不够。有些场景下,用户可能愿意付高价,只要速度能提升 100 倍。我们需要在“极致廉价”和“极致速度”之间找到平衡,如果市场更渴望低成本,我们会沿着那条曲线走得非常远。

 

提问:现在的交互界面并不是为 Agent 设计的。Agent 的普及会加速“微型应用(Micro Apps)”的出现吗?

 

Sam Altman:我已经不再把软件看作是“静态”的东西了。现在如果我遇到一个小问题,我期望电脑能立刻写一段代码帮我解决掉。我认为我们使用电脑和操作系统的方式将发生根本性改变。

 

虽然你可能每天用同一个文字处理器(因为你需要按钮留在熟悉的位置),但软件会根据你的习惯进行极致的定制。你的工具会不断进化、向你个人的需求收敛。在 OpenAI 内部,大家已经习惯用编程模型(Codex)来定制自己的工作流,每个人的工具用起来都完全不同。软件“由于我、且为我”而生,这几乎是必然的趋势。

给创业者的建议:不要做“模型的小补丁”

 

提问:当模型更新不断吞噬创业公司的功能时,创业者该如何建立护城河?有什么是 OpenAI 承诺不碰的?

 

Sam Altman:很多人觉得商业的物理定律变了,其实并没有。现在的改变只是“工作速度变快了”、“开发软件变快了”。但建立成功初创公司的规则没变:你依然要解决获客问题,要建立 GTM(转市场)策略,要创造粘性,要形成网络效应或竞争优势。

 

我给创业者的建议是:你的公司在面对 GPT-6 的惊人更新时,是感到开心还是难过?你应该去构建那些“模型越强,你的产品就越强”的东西。如果你只是在模型边缘打个小补丁,那会过得很艰难。

 

提问:现在的 Agent 执行长流程任务时经常在 5 到 10 步就断掉了。什么时候能实现真正长期的自主运行?

 

Sam Altman:这取决于任务的复杂程度。在 OpenAI 内部,有些通过 SDK 运行的特定任务已经可以近乎永久地运行下去了。

 

这不再是“何时实现”的问题,而是“应用范围”的问题。如果你有一个理解非常透彻的特定任务,今天就能尝试自动化。但如果你想对模型说“去帮我开一家创业公司”,由于反馈环路太长且难以验证,目前还很难。建议开发者先拆解任务,让 Agent 能够自我验证每一个中间步骤,再逐步扩大其职责范围

AI 能帮人类产生好创意吗?

 

提问:现在很多人抱怨 AI 生成的内容是“垃圾(Slop)”,我们该如何利用 AI 提高人类创意的质量?

 

Sam Altman:虽然人们叫 AI 的输出为垃圾,但人类产生的废话也不少。产生真正的新创意是非常难的。我越来越相信,人类的思维边界取决于工具的边界。

 

我希望能开发出帮人产生好创意的工具。当创造的成本骤降,我们可以通过密集的反馈循环快速试错,从而更早找到好的创意。

 

想象一下,如果有一个“Paul Graham 机器人”(YC 创始人),他了解你所有的过去、你的代码和工作,能不断给你提供头脑风暴,即便他给出的 100 个主意里有 95 个是错的,只要能激发你产生那 5 个天才般的念头,对世界的贡献也是巨大的。我们的 GPT-5.2 已经让内部科学家感受到了非平庸的科学进展,一个能产生科学洞察的模型,没理由产生不了优秀的产品洞察。

 

提问:我担心模型会让我们困在旧技术里。现在的模型学习两年前的新技术都很费劲,以后我们能引导模型学习最新出现的技术吗?

 

Sam Altman:这绝对没问题。从本质上讲,模型是一个“通用推理引擎”。虽然现在它们内置了海量的世界知识,但未来几年的里程碑将是:当你交给模型一个全新的环境、工具或技术,只要解释一次(或让它自主探索一次),它就能极其可靠地学会使用。这离我们并不远。

 

提问:作为一名科学家,我发现研究灵感是指数级增长的,但人的精力有限。模型会接管整个科研流程吗?

 

Sam Altman:实现完全闭环的自主科研还有很长的路要走。虽然数学研究可能不需要实验室,但顶尖数学家目前仍然需要深度参与,纠正模型的直觉偏差。

 

这很像国际象棋的历史:Deep Blue 击败卡斯帕罗夫后,曾出现一段“人机协作(半人马)”强于纯 AI 的时期,但很快纯 AI 就再次统领了赛场。

 

现在的 AI 对科学家来说,就像是“无限量的博士后”。它能帮你同时探索 20 个新问题,做广度搜索。至于物理实验,我们也在讨论是该 OpenAI 自己建自动化实验室,还是让全球科研社区贡献实验数据。目前看,科研社区对 GPT-5.2 的拥抱让我们倾向于后者,这会是一个更分布式、更聪明、更高效的科研生态。

 

提问:我更关心的是安全问题,最好是更强的安全性。在 2026 年,AI 有很多可能出问题的方式,其中一个我们非常紧张的方向是生物安全。现在这些模型在生物领域已经相当强了,目前无论是 OpenAI,还是整个世界的总体策略,大多还是试图限制谁可以接触这些模型,并且通过各种分类器,阻止模型帮助人们制造新的病原体。但我不认为这种方式还能持续很久。你怎么看?

 

Sam Altman:我认为,世界在 AI 安全,尤其是 AI 生物安全这件事上,需要完成一次根本性的转变——从“封堵(blocking)”,转向“韧性(resilience)”。

 

我一位联合创始人曾用过一个我非常喜欢的类比:火灾安全。火最初为人类社会带来了巨大的好处,随后它开始烧毁整座城市。人类最开始的反应,是尽可能去限制火。我最近才知道,“宵禁(curfew)”这个词,最早就和“晚上不允许生火”有关,因为城市会被烧掉。

 

后来,我们改变了思路,不再只是试图禁止火,而是提高对火的韧性:我们制定了消防规范,发明了阻燃材料,建立了一整套体系。现在,作为一个社会,我们在应对火灾这件事上已经做得相当不错了。

 

我认为,AI 也必须走同样的路径。AI 在生物恐怖主义方面会成为一个真实的问题;AI 在网络安全上也会成为一个真实的问题;但与此同时,AI 也是这些问题的重要解决方案。

 

因此,我认为这需要的是全社会层面的努力:不是依赖少数“我们信任的实验室”永远正确地封堵风险,而是建设一种具有韧性的基础设施。因为这个世界上,必然会存在大量优秀的模型。我们已经和很多生物研究人员、公司讨论过,如何应对“新型病原体”的问题。确实有很多人投入其中,而且也有不少反馈认为,AI 在这方面是有帮助的,但这不会是一个纯技术问题,也不会是一个完全靠技术解决的问题。整个世界都需要以一种不同于过去的方式来思考这件事。坦率地说,我对当前的状态非常紧张。但我也看不到除“以韧性为核心”的路径之外,还有别的现实选择。而且,从正面看,AI 确实可以帮助我们更快地建立这种韧性。

 

不过,如果今年 AI 真的出现一次“明显、严重”的失败事件,我认为生物安全是一个相当合理的“风险爆点”方向。再往后一年、两年,你也可以想象,还有很多其他事情可能会出大问题。

 

AI 学习效率提高后,人与人之间协作还重要吗?

 

提问:我的问题和“人类协作”有关。随着 AI 模型不断变强,它们在个人学习方面非常高效,比如快速掌握一个新学科。这一点我们在 ChatGPT 和教育实验中已经看到,也非常认可。但我经常会反复想到一个问题:当你可以随时得到答案时,为什么还要花时间、甚至承受摩擦,去向另一个人提问?你之前也提到,AI 编程工具可以用极快的速度,完成过去需要人类团队协作才能完成的工作。所以,当我们谈“协作、合作、集体智能”时,人类 + AI 是很强的组合,那人类与人类之间的协作会发生什么变化?

 

Sam Altman:这里面有很多层问题。我年纪比在座的大多数人都大一点。但即便如此,Google 出现的时候,我还在上中学。那时老师试图让学生承诺“不使用 Google”,因为大家觉得:如果你随手就能查到一切,那为什么还要上历史课?为什么还要记忆?

 

在我看来,这种想法完全不可理喻。我当时的感觉是:这会让我变得更聪明,学到更多东西,能做更多事情,这就是我成年后要长期使用的工具。如果因为它存在,就让我去学那些已经被淘汰的技能,那反而是疯狂的。

 

这就好比:在你明明知道已经有计算器的情况下,却还强迫我去学算盘——那在当时可能是重要技能,但现在已经没有价值了。我对 AI 工具的看法是一样的。我理解,在当前的教育体系下,AI 工具确实成了问题。但这恰恰说明,我们需要改变教育方式,而不是假装 AI 不存在。

 

“让 ChatGPT 帮你写东西”这件事,就是未来世界的一部分。当然,写作训练仍然重要,因为写作是思考的一部分。但我们教人如何思考、以及如何评估思考能力的方式,必须发生变化,而且我们不应该假装这种变化不存在。我对此并不悲观。

 

那 10% 极端自学能力很强的学习者,已经表现得非常出色了。我们会找到新的方式,重构课程体系,把其他学生一起带上来。至于你提到的另一点——如何让这不是一个“你一个人对着电脑变得很厉害”的过程,而是一个协作过程。目前为止,我们并没有看到 AI 导致人类联系减少的证据,这也是我们在持续观察和测量的事情。

 

我的直觉恰恰相反:在一个充满 AI 的世界里,人与人之间的连接会变得更有价值,而不是更没价值。我们已经看到一些人开始探索新的界面,来让协作变得更容易。在我们考虑自研硬件和设备时,甚至一开始就在思考:“多人协作 + AI” 的体验应该是什么样子?

 

虽然现在还没有人真正把这件事完全做对,但我认为,AI 会以前所未有的方式,让这种协作成为可能。你可以想象:五个人围坐在一张桌子旁,旁边还有一个 AI 或机器人,整个团队的生产力会被大幅放大。未来,每一次头脑风暴、每一次问题解决,AI 都会成为团队的一部分,帮助整个群体做得更好。

Agent 大规模进入生产系统,最大的被低估风险是什么?

提问:随着 Agent 开始大规模运行、直接操作生产系统,你认为最被低估的失败模式是什么?是安全、成本、可靠性吗?以及,哪些“艰难但重要的工作”目前投入还不够?

 

Sam Altman:你提到的这些问题,几乎每一个都成立。有一件事让我个人、也让我们很多人都感到意外。我第一次用 Codex 时,非常确信一件事: “我绝对不会给它完全、无人监督的电脑访问权限。”

 

我坚持了大概两个小时。然后我想:它看起来真的在做非常合理的事情;每一步都要我点确认实在太烦了;不如先打开一会儿看看会发生什么。结果,我从来没有再把完全访问权限关掉。我发现,很多人都有类似的经历。

 

这让我真正担心的是:这些工具的能力和便利性太强了,而它们的失败概率可能很低,但一旦失败,后果可能是灾难性的。因为失败发生得不频繁,人们会慢慢滑入一种状态:“应该没事吧。”

 

但随着模型变得越来越强、越来越难理解,如果模型内部存在某种微妙的错位,或者在长时间、复杂使用后出现新的系统性问题,你可能已经在某个系统里埋下了一个安全漏洞。你可以对“AI 失控”的想象有不同程度的科幻倾向,但我真正担心的是:人们会被这些工具的强大和愉悦感牵着走,而不再认真思考它们的复杂性。能力会上升得非常快;我们会习惯某个阶段的模型行为,并因此信任它; 但却没有构建足够健全的、整体性的安全基础设施。

 

于是,我们会在不知不觉中,走向一个危险状态。

 

我认为,围绕这一点,本身就值得诞生一家伟大的公司

AI 应该如何进入幼儿与基础教育?

 

提问:我想回到教育的话题。我在高中时看到身边的同学用 ChatGPT 写作文、做作业;现在在大学,我们在 CS、人文等各个领域都在讨论 AI 政策。我想问的是:在幼儿园、小学、初中这些塑造思维方式的关键阶段,你作为一名父亲,如何看待 AI 对教育的影响?

 

Sam Altman:总体来说,我是反对在幼儿园里使用电脑的。幼儿园应该更多是:在户外跑来跑去,接触真实的物体,学习如何与他人互动。所以,不只是 AI,我甚至觉得大多数时候,幼儿园里连电脑都不应该有。

 

从发展角度来看,我们仍然没有完全理解技术对儿童的长期影响。关于社交媒体对青少年的影响,已经有很多研究了,而且结果相当糟糕。我的直觉是:大量技术对更小年龄儿童的影响,可能更糟,但讨论得却少得多。在我们真正理解这些影响之前,我不认为有必要让幼儿园阶段的孩子大量使用 AI。

 

提问:我们在生物医药领域。生成式 AI 在临床试验文档、法规流程等方面已经非常有帮助。现在我们也在尝试用它做药物设计,特别是化合物设计。但一个很大的瓶颈是 三维推理能力。

你认为这里会出现一个关键拐点吗?

 

Sam Altman:这个问题我们一定会解决。我不确定是不是 2026 年就能完成,但这是一个非常普遍、非常高频的需求。我们大概知道该怎么做,只是目前还有很多更紧急的方向需要推进。但这件事一定会到来。

 

参考链接:

https://www.youtube.com/watch?v=Wpxv-8nG8ec&t=2s

HodlAI: Web3 × AI 的创新融合


一、问题:AI API 的付费模式太"Web2"了

用过 OpenAI/Claude/Gemini 等 API 的人都知道:

  • 先充值,后使用
  • 用多少扣多少
  • 花完再充,无限循环

这本质上是 SaaS 订阅模式——你永远在为使用权付费,而不是拥有什么。

但 Web3 的核心理念是什么?持有即权益。

有没有可能,把这个理念用到 AI 服务上?


二、HodlAI 的解法:代币 = 永久会员卡

HodlAI 提出了一个简单但巧妙的模型:

对比项 传统模式 HodlAI 模式
投入 充 $100 买 $100 代币
使用 用完归零 每天有额度
资金归属 资金锁在平台 代币在自己钱包
性质 纯消费 消费 + 投资
续费 用完再充 每天自动刷新

核心公式

每 5 万代币 = 每日 $1 API 额度

持有 50 万代币,每天就有 $10 免费额度,可以调用 GPT-5 、Claude 4.5 、Gemini 3 等 200+ 模型


三、钱从哪来?交易税驱动的永续资金池

这是最关键的问题。

HodlAI 的答案:3% 交易税,100% 进入 API 资金池。

代币每笔买卖 → 3% 税收 → API 资金池 → 按持有量分配
     ↑                                        ↓
     └──────── 交易越活跃,池子越大 ←─────────┘

正向飞轮效应

  1. 更多人持币
  2. → 更多交易
  3. → 更大资金池
  4. → 更多 API 额度
  5. → 更多人想持币
  6. → 回到 1


四、防作弊:Diamond Hands 钻石手机制

如果没有限制,套利党会这么玩:

买入 → 用光免费额度 → 立刻卖出 → 下次再来

HodlAI 用**"钻石手机制"**解决这个问题:

持有时间 额度释放
0-5 分钟 0%(冷启动)
5 分钟后 10% 额度释放
每小时 +4% 递增
24 小时不卖 100% 满额度(钻石手)
曾经卖过 永久最高 80%(纸手惩罚)

⚠️ 持有时间通过链上数据验证,无法作弊


五、透明度:Stripe 账单公开可查

很多项目说"税收用于开发",但谁也不知道钱去哪了。

HodlAI 做到了真正的透明:

  • ✅ 每一笔 API 充值都公开
  • ✅ 提供 Stripe 官方账单链接
  • ✅ 任何人可以点击验证
  • ✅ 团队 0 抽成

这不是"相信我们",而是"你自己来查"。


六、风险提示

说完优点,也要说风险:

  • ⚠️ 代币价格波动:可能涨,也可能跌
  • ⚠️ 项目早期:模式新颖但未经长期验证
  • ⚠️ 依赖交易量:如果没人交易,资金池增长会停滞


七、项目特点

这个项目的创新点在于:

用 Web3 的代币经济模型,解决 Web2 的订阅付费痛点。

它回答了一个问题:Meme 币除了炒作,能不能有实际用途?

HodlAI 的答案是:可以,把代币变成"AI 服务的永久会员卡"。

这个模式能不能跑通,需要时间验证。

但至少,这是目前有的最有想象力的 Web3 × AI 结合尝试


八、项目愿景

我们相信,AI 服务不应该是永无止境的订阅付费,而应该是持有即权益的价值共享。

HodlAI 是全球首个将 Web3 代币经济与 AI API 服务深度融合的创新平台。


相关链接

平台 链接
🌐 官网 https://hodlai.fun/
🐦 Twitter @hodlai_fun
💬 Telegram https://t.me/hodlai_fun

整理 | 华卫

 

“一圈又一圈的循环融资,投资回报率却不尽如人意,这些 AI 系统实际用起来也远没有想象中好用,或许方向本身就站不住脚。”

 

近日,知名 AI 专家、认知科学家 Gary Marcus 在一场访谈中愤愤表示,“整个世界都在全力押注神经网络,还在这个我始终觉得毫无道理的理念上投入了巨资,但大语言模型根本无法带我们抵达 AGI 这一终极目标。”

 

这场对话由曾因成功预测 2008 年金融危机而闻名的传奇投资人、华尔街最具影响力人物之一 Steve Eisman 发起,他与 Marcus 共同探讨了当下 AI 进展的方方面面,包括商业路径、社区现状和未来方向等。Marcus 认为,大语言模型已经达到了收益递减的阶段。并且,他指出,现在 AI 领域根本没有技术壁垒了,所有 AI 企业的研发思路基本一致。

 

对于大量人才从大厂离职去办初创公司的现象,Marcus 直言道,“如果 OpenAI 真的能在下周推出 AGI,谁会在这个即将改变世界的关键节点离职,去创办一家可能要花四年时间才能做出成果的小公司?显然没人会这么做,大家都会想留在公司见证这个时刻。”在他看来,这些企业内部的人也清楚,他们根本没有做出宣称的那种突破性成果。

 

值得一提的是,他认为,OpenAI 最终会成为 AI 领域的 WeWork,这家公司原本计划以 500 亿美元的巅峰估值风光上市、却在一夕之间破产。“我觉得最终 OpenAI 可能会被微软这样的企业收购。OpenAI 每个月的亏损大概有 30 亿美元,一年就是 300 多亿美元,即便最近完成了 400 亿美元的融资,也只够支撑一年的运营。”

 

谈及各家模型的未来,Marcus 的预测是,“大语言模型会成为一种标准化商品,各家的模型只会比上一年的版本稍有提升,差距微乎其微,最终品牌差异会变得无关紧要。当产品变成商品后,价格必然下跌。”

 

以下是详细对话内容,我们在不改变原意的基础上进行了翻译和删减,以飨读者。

 

2 万亿美元押注 Transformer,根本“毫无道理”?

 

Steve Eisman:大家好,我是 Steve Eisman。今天我们请到了一位特别的嘉宾,他就是 Gary Marcus。他是大语言模型的坚定质疑者,而大语言模型正是整个 AI 领域的核心根基。接下来,Gary 会和我们分享他的观点,聊聊大语言模型到底是什么。

 

Gary Marcus:谢谢你的邀请,也感谢一两个月前你在 CNBC 对我的盛赞。

 

Steve Eisman:不客气,这都是你应得的。在正式开始之前,我的观众大多还不了解你,不如先和大家说说你的背景,让大家知道你在这个领域发表观点是完全有底气的。

 

Gary Marcus:我这辈子几乎都在研究智能相关的问题。我 10 岁学会编程后,就开始涉足 AI 领域了。我的职业生涯中,很大一部分精力都用在研究自然智能上,比如人类的智能、还有孩子是如何学习语言这类问题。我在 MIT 的博士论文围绕两个方向展开,一个是儿童的语言学习机制,另一个就是神经网络。神经网络是 AI 领域的一种特定研究方法,也被用于人类思维的建模,它的设计灵感可以说和大脑有一点松散的关联。这其实是个很巧妙的营销说法,会让人觉得它是完全基于大脑研究的,但事实并非如此,二者只是浅层关联。早年间神经网络就曾风靡一时,我在上世纪 90 年代就研究过这类模型,发现它们并不能很好地模拟人类的思维方式,但我还是投入了大量精力,想弄清楚它们的实际工作原理。

 

2012 年深度学习重新兴起时,我当时就觉得,这些东西我早就研究过了,和我博士论文里的内容高度相似。我在 2001 年写过一本名为《The Algebraic Mind》的书,在书里我其实就预判到了如今大语言模型出现的幻觉问题,还有一些推理层面的缺陷,这些都是我们今天要探讨的话题。所以当深度学习再次成为热点时,我一眼就看出了其中的诸多问题,对我来说这些问题都很熟悉。2012 年,我在《The New Yorker》上发表了一篇文章,标题是《Is Deep Learning a Revolution in Artificial Intelligence?》,我在文中写道:“深度学习确实很有意思,我很佩服 Jeff Hinton,他能长期坚持自己的研究方向。”

 

Steve Eisman:Jeff Hinton 是谁?

 

Gary Marcus:他是去年诺贝尔生理学或医学奖的得主,也是深度学习领域的核心奠基人之一。

 

Steve Eisman:原来如此。

 

Gary Marcus:他的一些学生,最近也开始认同我的观点了。Jeff Hinton 确实是这个领域的大人物,在神经网络一度无人问津的时期,是他一直坚守,这份坚持值得肯定。但当然,他的研究并非全无可议之处,我们这里就不细谈了。他让神经网络重获关注,而更值得你的听众了解的是,真正让这个领域迎来爆发的,是他的学生 Ilya Sutskever,或许还有另外几位研究者。他们找到了方法,能让这套研究了许久的系统落地应用。要知道,神经网络的研究最早能追溯到上世纪 40 年代,Jeff Hinton 也在上世纪 80 年代中期做出了不少重要贡献。而这些研究者发现,借助英伟达研发的图形处理器(GPU),就能实现神经网络的高效运行。

 

彼时的英伟达,生产 GPU 主要是为了满足电子游戏的需求。这些原本为游戏设计的 GPU,核心优势在于并行计算,简单来说,就是能同时处理多个计算任务,而非按顺序逐个完成。传统的中央处理器(CPU),运行软件程序时基本是逐行执行的,虽然现在的技术已经有了改进,但这仍是计算机科学入门课程里会教的基础原理。而 GPU 能把一个复杂问题拆解成无数个小任务,同时进行处理,它的设计初衷就是为了计算机图形处理。比如要渲染电子游戏的下一帧画面,如果逐行处理,耗时会非常久,而用 GPU 的话,能同时处理整个画面,一个子处理器负责一个像素点,以此类推。不得不说,GPU 在图形处理上的表现堪称完美,我偶尔也玩电子游戏,深知 GPU 的算力有多惊人。

 

Ilya Sutskever,还有另一位我一时想不起名字的论文合作者,他们证明了 GPU 是运行神经网络的绝佳载体,至于神经网络的具体定义和实际意义,我们之后可以再聊。他们的这一发现,让神经网络的运行实现了两大突破:一是速度大幅提升,二是能处理海量数据。在此之前,六十多年的神经网络研究做出的基本都是些玩具级的模型,而他们证明,借助 GPU 这项技术能真正实现规模化的实际应用,能在更大的维度上落地。可以说,我们如今看到的所有深度学习成果,都源于 2012 年的这次突破。

 

而在这一突破出现后,两件事接踵而至:《The New York Times》刊发了文章,盛赞深度学习的惊人潜力;第二天,我就在《The New Yorker》的博客上发表了文章。我在文中表示,深度学习固然出色,但也存在诸多问题,它注定会在一些领域表现优异,却在另一些领域束手无策。它擅长模式识别和统计分析,这一点毋庸置疑,但人类的认知活动中还有大量的抽象思维过程。比如我们能理解家谱的逻辑,进而对现实世界的相关问题进行推理,而深度学习模型永远无法擅长这类任务,它的架构本身就不适合做抽象推理。从早年对神经网络的研究以及对人类认知机制的研究中,我早就看清了这一点。你应该读过 Daniel Kahneman 的经典著作《Thinking, Fast and Slow》吧?

 

Steve Eisman:我读过。

 

Gary Marcus:Daniel Kahneman 在书中提出了双系统认知理论,他将人类的认知分为系统一和系统二。系统一的思考速度快,是无意识的、基于统计的、本能的反应;而系统二的思考速度更慢,更具思辨性,核心是逻辑推理。神经网络本质上就相当于人类的系统一,这本身没问题,系统一也是人类认知的重要组成部分,但人类的认知还有系统二的部分。尤其是在理性思考时,我们会依赖系统二,进行更审慎、更有逻辑的推理。而神经网络模型,从始至终都不擅长系统二的这类任务,直到现在依然如此。我在 2012 年就指出,深度学习模型只能实现系统一的功能,却无法完成系统二的思考。

 

而在这之后的 14 年里,整个世界都在全力押注神经网络。这里要说明的是,我们所说的神经网络,就是如今的大语言模型,大语言模型是神经网络的一种形式,抱歉,我之前没明确说明这一点。事实上,2012 年时大语言模型还未出现,后续又有不少技术突破,其中关键的就是 2017 年发表的 Transformer 论文,这也是大语言模型的起源。而全世界在这一领域的投资规模达到了天文数字,据我粗略估算,已经有 1 到 2 万亿美元了,全都投在了这个我始终认为毫无道理的理念上。这些研究者的想法是,只要持续发展神经网络,就能实现智能所需的一切能力,抵达 AGI 的目标,但他们却忽视了系统二的核心价值。

 

一开始,他们只是把神经网络当成一个巨大的黑箱,直到现在,还有很多人抱着这样的想法。他们觉得,只要把海量数据喂进去,就能得到一个拥有智能的系统,却从未从科学的角度深入思考过真正的智能究竟该具备怎样的架构。我认为这些人太过天真,我也一直试图指出这一点,这也让我成了这个领域里的“孤行者”。很长一段时间里,人们对我的观点不屑一顾,甚至不只是不屑,而是鄙夷。

 

Steve Eisman:没错,他们对你的态度远不止是不屑,而是赤裸裸的鄙夷。

 

Gary Marcus:我们还能举出很多这样的例子。我对他们的这种态度感到失望,这个话题我们可以聊很久。他们甚至对我公开表现出敌意,比如我了解到,OpenAI 内部还为我做了专属的表情包。

 

Steve Eisman:我也看到过这个消息。

 

Gary Marcus:某种程度上,这也算是一种认可吧,既觉得荣幸,又觉得有些离谱,你能看出来,我一直试图用平常心看待这件事。但这也能从侧面说明问题,Sam Altman 还在推特上称我为“喷子”。他们就是不想听我的观点,而我核心的观点,都写在了 2022 年发表的论文《Deep Learning is Hitting a Wall》里。我在这篇论文中指出,当时“规模化扩张”的理念已经开始流行,也就是通过不断投入更多数据、更多 GPU,把模型做得越来越大,他们认为只要模型足够大,就会拥有超乎想象的能力。

 

我先暂停一下,和大家解释下这个“规模化扩张”的理念。他们确实有一些数据能支撑这个观点,但这种想法依然太过天真。我把这种理念称作“万亿磅婴儿谬误”,道理很简单:一个婴儿出生时 8 磅重,一个月后长到 16 磅,并不意味着他会一直这样翻倍增长,到上大学时长成万亿磅的巨人。他们就是做出了这样天真的推断,我相信你在商业领域也经常见到这种情况。很多手握巨资的聪明人,都押注了这个理念,他们说,“我们从数据中看到了这样的发展规律,只要投入足够多的数据,就能实现真正的智能。”

 

“大模型不会思考,重构信息碎片致幻”

Steve Eisman:先稍停一下,我们倒回去说。大语言模型到底能做什么?这些研发者又认为它们本该实现什么功能?我真想把这个问题彻底讲清楚。

 

Gary Marcus:你这个问题问得特别好。大语言模型的核心工作原理,就是预测序列中的下一个内容。你可以想想苹果手机的自动校正功能,原理差不多,虽说那功能有时候能把我逼疯,你继续说。这个功能并非总能生效,核心逻辑就是你在输入句子时,它会预判接下来可能要打的内容。比如你打出“在……见我”,它大概率会推测你想说“在餐厅见我”。它会对人类的语言表达做统计分析,效果还算过得去,但绝非完美,偶尔还会出错,让人恼火,这就是我们说的自动补全。

 

而我把大语言模型称作“超级版自动补全工具”,它们只是用一种特殊的方式完成这种预测,这就是其最本质的功能。它们的运作方式里还有些有意思的点,其中一个就是会把所有信息拆解成细碎的片段,之后再重新整合,这就导致信息之间的关联会被切断。也正是因此,它们才会时不时出现幻觉现象,凭空编造内容。

 

Steve Eisman:我们稍后再细说幻觉这个问题。

 

Gary Marcus:好,回头再聊。幻觉是这类模型的典型错误之一,早在 2001 年,大语言模型甚至还没被发明出来的时候,我就指出过这个问题。我当时就说,如果一直沿着这个方向研究下去,必然会出现这个问题,而事实也确实如此。大语言模型把信息拆分成碎片,再通过这些碎片预测后续内容。如果用整个互联网的内容对它们进行训练和数据投喂,它们的表现会好得让人意外,因为几乎任何你能想到的问题,注意,这里的“几乎”是关键,几乎所有问题,此前都有人提出过,也有人给出过答案。从某种程度来说,这些模型就是功能强大的记忆机器。

 

就在前几天,《大西洋月刊》还刊发了相关的文章,而且一直以来都有大量证据能证明这一点。比如你输入《哈利·波特》的部分内容,它能直接补完整段文字,本质上就是因为它记住了这些内容。如果一个模型能记住整个互联网的信息,那确实算得上很厉害。比如你问“道奇队在搬到洛杉矶之前,主场在哪”,网上有大量相关表述,它会告诉你是布鲁克林,大概率能给出正确答案。但仅仅依靠这种方式,模型根本无法形成抽象的概念和思想,还会因为信息碎片的拆解和错误整合出现各种问题。

 

Steve Eisman:那我们现在聊聊幻觉吧。到底什么是 AI 幻觉?举个例子,再说说出现这种情况的原因。

 

Gary Marcus:幻觉就是模型凭空编造内容,还无比笃定地呈现出来,但这些内容根本不符合事实。

 

Steve Eisman:那给我们举个例子。

 

Gary Marcus:我最喜欢的一个例子和 Harry Shearer 有关,你可能听过他的名字,看过《摇滚万万岁》吗?

 

Steve Eisman:当然看过。

 

Gary Marcus:他在这部影片里饰演贝斯手,巧的是,他还是我的朋友。他出演了《摇滚万万岁》,还和 Christopher J. Guest 合作了多部影片,参演了《楚门的世界》,还为《辛普森一家》里的伯恩斯先生等多个角色配音,他的知名度还挺高的,这点对接下来的故事很重要。先倒回说个题外话,我之前遇到的最典型的幻觉案例,主角是我自己。有人发给我一份我的人物简介,里面说我养了一只叫 Henrietta 的宠物鸡,但我根本没养过,这就是个很典型的幻觉案例,纯粹是凭空编造的。后来发现,有位插画师大概叫 Gary Oswald,写过一本关于 Henrietta 去上学的书,模型不过是把这些碎片化的信息胡乱拼凑在了一起。

 

Steve Eisman:那为什么会出现这种幻觉呢?

 

Gary Marcus:这就和我刚才说的信息碎片化拆解有关了。我再给你讲讲 Harry Shearer 的那个例子。我总拿宠物鸡 Henrietta 的事举例,有一天他给我发消息,说他没遇到过宠物鸡这种事,却遇到了和自己相关的幻觉案例。他比我有名多了,至少以前是。我当时也算小有名气,而模型给出的信息里,说他是英国的配音演员和喜剧演员,但他根本不是英国人。你只要花两秒看一下维基百科,就会发现他出生在洛杉矶。他名气不小,你也能在烂番茄、互联网电影数据库上查到他的资料,他接受过很多采访,也聊过自己的成长经历,他小时候还在洛杉矶的《杰克·本尼秀》里当过童星,想找到正确的信息一点都不难。

 

我们会错误地把大语言模型当成和人类一样拥有智能的个体,但实际上,它们所做的只是重构信息碎片之间统计层面的大概率关联,所以难免会出错,这种重构过程也常会出现偏差。Harry Shearer 这个案例就是如此,模型其实就是在构建一个信息集群,用统计学的方式预测各类信息之间的关联。而现实中确实有很多英国的配音演员和喜剧演员,比如 Ricky Gervais、Don Cleeve 等等。模型就把这些信息混为一谈了,这种信息融合的方式整体来看效果还算不错,但你永远无法确定它给出的某一个具体信息是准确的,所以幻觉现象才会频繁出现。

 

有人专门追踪过相关的法律案件,发现律师提交的辩护状里,有很多引用的判例都是模型编造的,根本不存在。我第一次关注这件事时,他已经发现了约 300 起这样的案件,三个月后再看,数量涨到了 600 起。这些律师不仅用 ChatGPT 这类工具代写文书,还因此被法官发现,受到了处罚。模型会出错,而最危险的是,这些错误还很容易被忽略,人们根本发现不了。还有一个例子,CNET 是最早用 AI 写稿的媒体之一,他们首批用 AI 写的 75 篇文章里,有近一半都存在错误,编辑们却没发现。因为这些文章语法通顺、格式规范,也没有拼写错误,人们很容易就放松了警惕。

 

我把这种现象称作“看着没问题效应”。大语言模型带来的这种效应,还催生了一个新词汇,我真后悔不是我发明的,叫“低效工作产物”。这个词大概是去年由几位教授提出的,指的是人们用 AI 写报告、提交给雇主,表面上看没什么问题,实则漏洞百出,因为大语言模型根本不具备真正的理解能力。

 

Steve Eisman:你的意思是,大语言模型并不会思考。

 

Gary Marcus:它们确实不会思考,只是把统计学上大概率关联的内容拼凑在一起。

 

Steve Eisman:只是简单拼凑。

 

Gary Marcus:没错。我还喜欢用“黏合”这个词,它们只是把信息黏合在一起。从统计学角度来说,大部分内容的拼凑是合理的,但总有一部分是错误的,而这些模型根本无法区分对错,也不会主动告知你。它们永远不会说,“维基百科显示 Harry Shearer 出生在洛杉矶,但作为大语言模型,我感觉他可能出生在伦敦,你可以去核实一下”。它们从来不会给出这样的提示,只会把所有内容都当作百科全书里的标准答案呈现出来,无论真假,这也是这类模型的危险之处。

 

Steve Eisman:确实是这样。

 

Gary Marcus:这类问题其实有很多,这个案例属于另一种情况,但也和模型的本质缺陷有关。这个问题的根源在于,所有大语言模型都有数据截止日期,它们的训练都是在某个特定时间点完成的,核心模型所掌握的信息,也只到这个时间点为止。研发者会给它们加各种补救措施,比如接入网络搜索功能,但这些补救措施和核心模型的融合效果都很差,不同系统的表现略有差异而已。这类模型最大的问题就是无法应对新事物、新情况,也是它们最根本的缺陷。早在 1998 年,我就通过研究早早发现了这一点。如果一个模型本质上只是个功能强大的记忆机器,当你向它输入一个超出其训练数据范围的内容时,它就会失灵。

 

有个例子特别能说明问题,具体细节我不太清楚,但特斯拉的 AI 系统也大量采用了这种记忆式的运作方式,而且其系统的复杂程度并不高。有人用过特斯拉的召唤功能,你应该记得马斯克说过,未来可以从纽约远程召唤洛杉矶的特斯拉,但现在显然做不到,不过据说能在停车场里召唤车辆。有人在一场航空展上试过这个功能,你能在油管上找到相关视频。这个人召唤自己的特斯拉,想在航空展上秀一下,结果车子径直撞上了一架价值 350 万美元的私人飞机。

 

原因就是,特斯拉的训练数据里,根本没有教系统如何应对飞机,毕竟谁会专门训练汽车躲避飞机呢?系统对世界没有形成通用的认知,比如“不要撞上挡路的大型贵重物体”,它根本不懂这些,只会识别训练数据里的自行车、行人等目标,它的识别分类里根本没有“飞机”这一项,所以才会直接撞上去。

所有 AI 企业都变了:悄悄复用经典符号式工具

Steve Eisman:那你有没有了解到,随着这场争论的风向转变,各大企业内部现在的情况如何?

 

Gary Marcus:我了解到的情况主要有几点。首先,我一直都在说,单纯的大语言模型行不通,必须结合传统的符号式 AI 技术。但之前他们都对此嗤之以鼻,觉得这套技术早就过时了,没必要用,还说人脑的工作模式本就不是这样。而现在,他们都悄悄在一定程度上采用了这项技术,比如引入代码解释器来运行 Python 代码,这些都是经典的符号式工具。说白了,他们正在偷偷把系统二的相关能力融入模型中,只是没有大肆宣扬,但这一改变确实带来了不小的提升。

 

马斯克发布 Grok 4 时的演示就很能说明问题,我还为此写过一篇文章,标题是《为何 GPT-3 和 Grok 4 无意间印证了神经符号 AI 的正确性》。文章里放了当时的演示图表,能清晰看到,正是那些他们不愿提及的符号式工具的加入,让模型的表现变得更好。如今模型的些许提升,绝大部分都来自这个原因,而非单纯的大语言模型优化,他们其实已经悄悄放弃了纯大语言模型的研发思路。而这对你所关注的商业领域来说意义重大,因为这些符号式工具根本不需要在 GPU 上运行,普通的 CPU 就足够了。

 

Steve Eisman:原来如此。

 

Gary Marcus:对我而言,从技术角度来说,这印证了我一直以来倡导的研发思路是正确的。这是第一个变化。第二个变化是,各大企业的很多人都离职去创办自己的初创公司了。你可以想想,如果 OpenAI 真的能在下周推出 AGI,谁会在这个即将改变世界的关键节点离职,去创办一家可能要花四年时间才能做出成果的小公司?显然没人会这么做,大家都会想留在公司见证这个时刻。

 

所以,大量人才离职的事实就说明,这些企业内部的人也清楚,他们根本没有做出宣称的那种突破性成果。还有一个变化,就是谷歌正在迎头赶上。就像我几年前在 Substack 专栏里预测的那样,因为现在所有企业的研发思路基本一致,这个领域根本没有技术壁垒。

 

Steve Eisman:没错,完全没有技术壁垒。

 

Gary Marcus:你和其他一些人都认为,如果所有人都在做大语言模型的规模化扩张,那么最终的赢家就是最有实力承担这笔扩张成本的企业。而放眼整个行业,谁的资金实力能超过谷歌?根本没有。

 

Steve Eisman:确实。

 

Gary Marcus:我其实也表达过类似的观点,只是表述略有不同,你的这个说法其实也没错。我当时的观点是,行业头部企业会逐渐趋同,而随着大语言模型成为标准化商品,行业内会引发价格战,服务定价会大幅下降。事实也确实如此,现在大语言模型的按 token 计费价格,已经暴跌了 99%。价格战确实爆发了,而最终的受益者自然是谷歌,这一点我当初虽然没有直接点明,但也有所预判。我大概是在 2024 年 3 月,也可能是 2023 年 8 月开始写相关文章,当时就说,所有企业都在遵循同一种研发思路,没人掌握什么独门绝技,这就意味着头部企业的产品会越来越趋同。

 

大语言模型会成为一种标准化商品,各家的模型只会比上一年的版本稍有提升,差距微乎其微,最终品牌差异会变得无关紧要。这一趋势带来的结果就是,谷歌迎头赶上了,中国的企业也追上来了,Anthropic 同样不甘落后。就像你说的,当产品变成商品后,价格必然下跌。这对终端消费者来说是好事,但对企业的商业模式来说却是巨大的打击。毕竟企业原本的设想是,花巨资采购 GPU,然后靠模型服务赚回巨额利润。

推理模型进行不了逻辑分析,再升级也没价值?

Steve Eisman:我们能不能聊聊推理模型?先给我的观众解释一下,推理模型和大语言模型有什么区别?推理模型是基于大语言模型研发的吗?

 

Gary Marcus:推理模型是在大语言模型的基础上运作的,但它不会像大语言模型那样直接给出第一个想到的答案,而是会反复迭代、花费时间去推敲,试图得出最优解。至于具体的研发细节,各家企业都没有公开太多。传统的神经网络模型,在某种意义上都是一次性输出结果的,当然现在行业内对“一次性”的定义有所不同。简单来说,就是把数据输入模型后,神经网络会立刻完成一次正向传播,粗略来讲,模型中的每个神经元都会处理信息并生成对应的结果。而推理模型则会进行多次传播,这是本质上的区别。

 

我有个朋友把传统模型的输出方式称为“恒时推理”,意思是模型生成答案的时间基本固定,无论什么问题,耗时都相差无几:把数据输入模式识别器,模型会根据现有的模式给出最优解。而推理模型采用的是全新的“变时推理”模式,我之后会聊聊它的适用场景和短板,这种模式的特点是,处理不同的问题,耗时会有所不同。目前还没有企业能完全解决推理模型的所有技术难题,但在一些场景下,它的表现确实不错。

 

据我了解,推理模型的研发思路之一,就是让模型模仿人类解决问题的思考过程,毕竟这些模型本质上都是模仿系统。比如在解决几何题或代数题时,模型会刻意模仿人类的解题步骤。人类解决这类问题需要一步步推导,融合了推理能力的神经网络模型,同样需要分步骤完成。

 

Steve Eisman:那推理模型的优势是什么?又有哪些明显的短板?

 

Gary Marcus:在回答这个问题之前,我想先提一点:推理模型的成本天生就更高,因为它需要占用 GPU 更长的时间来生成答案。

 

Steve Eisman:好的。

 

Gary Marcus:那我来说说它的适用场景和短板。推理模型最擅长的,是那些能生成形式规范、可验证的数据来训练模型的领域。比如数学和计算机编程,我们可以编写程序生成各种不同的代码片段来训练模型,也能生成各类几何证明题的解题思路。这类领域之所以适合推理模型,是因为它们都属于封闭领域,相关的知识边界是明确的。

 

Steve Eisman:没错,数据库中的知识量和相关的有效知识量都是有限的。

 

Gary Marcus:对,就是这个意思。所以推理模型在几何、编程这类领域的表现最好,而在开放式的现实世界中,它的表现就差强人意了。我总会从你所熟悉的金融领域举例子,当然你肯定有更贴切的案例,比如长期资本管理公司的破产。其实那也是一种模型失效的情况,只是模型的原理不同,当时没人考虑到俄罗斯债券市场崩盘的可能性,最终导致美国金融市场出现了大幅动荡。这是因为当时的金融模型,其参数设定根本没有覆盖这类极端情况。

 

而现在的推理模型,也面临着类似的问题:它其实并不具备真正的思考能力,哪怕是关于债券的基本问题,它也无法进行真正的逻辑分析。如果用它处理的问题,和训练数据中的内容高度相似,那一切都顺理成章;但一旦超出了它的认知范围,就像我们之前聊到的特斯拉的例子,模型就会立刻失效。

 

Steve Eisman:也就是它依然无法应对新事物、新情况。

 

Gary Marcus:没错,即便升级到了新的推理模型,核心问题依然是无法处理未知信息。它只是在原有基础上做了些许改进,但本质上还是受限于对新事物的适配能力。而关键问题在于,现实世界中,大多数有价值的问题都包含着一定的新要素、新情况,并非全是已知的问题。当然,也有例外,我们确实可以用这种不擅长处理新事物的技术,在一些狭窄的领域做出成绩,比如国际象棋和围棋。这些领域的规则千百年间基本没有太大变化,有海量的历史数据可供参考,模型还能通过自我对弈生成更多训练数据。

 

但在开放式的现实世界中,比如政治、军事战略领域,永远会出现训练数据中没有的新情况。比如,如何应对一位总统授意将军用飞机伪装成民用飞机,去袭击另一个国家的行为?这种情况此前从未发生过,想要分析这类问题,根本无法依靠过往的数据,必须依靠抽象的概念思考,比如权力、外交规则、国际格局的构建逻辑等,这些都是相关领域的学者更擅长的内容。要做到这一点,模型需要接受正确的训练,具备抽象思维能力,而不是单纯依赖数据。即便是在商业应用中,比如看似简单的客户服务,也会遇到类似的问题:用户总会用全新的方式提出问题,而一旦出现这种情况,模型就会因为无法应对新情况而失效。

OpenAI 只够支撑一年,要么倒闭、要么求救微软?

Steve Eisman:假设我任命你为 AI 领域的总负责人,由你掌控所有相关企业,指导整个行业的研发方向。如果你把这些企业的负责人都召集到一起,你会告诉他们,想要实现真正的突破,需要做些什么?

 

Gary Marcus:我会告诉他们,整个行业需要更多的学术思维多样性。就像在你的金融领域,你会告诉人们不要把所有鸡蛋放在一个篮子里,要做资产配置,分散投资股票、债券、黄金、房地产等。而 AI 领域在过去这些年,就是把所有的精力都押在了一个思路上,大语言模型的规模化扩张,这是行业唯一的研发方向。不可否认,这个思路确实带来了一些成果,模型并非毫无用处,我们也确实能利用它解决一些问题,但它终究无法带我们实现所谓的通用人工智能(AGI)这一终极目标,而且这还是一种成本极高、效率极低的研发方式。你可以对比一下,我的孩子只需要少量的信息和学习,就能理解这个世界,而大语言模型却需要学习整个互联网的海量数据,二者的效率差距简直可笑。

 

这些企业花费巨资,做出的却是效率低下、可靠性堪忧,但又有一定使用价值的模型。我们需要的是其他更高效、更经济、更可靠的研发思路,企业应该投入资金去探索这些新方向。但问题的根源,其实也来自你所熟悉的金融领域:风险投资家能从那些听起来合理的投资项目中,赚取 2%的管理费。我很好奇你对这个观点的看法,因为这毕竟是你的专业领域。试想一下,作为风险投资家,如果有一个项目能让你管理一万亿美元的资金,哪怕你根本不在乎项目最终的结果,也能赚到 2%的管理费,这足以让你成为亿万富翁。我并不是说所有的风险投资家都是这样想的,我见过很多投资人,他们确实真心想推动技术进步。

 

但就像任何行业一样,很多投资人都带着功利的心态。对这些功利的投资人来说,最理想的投资标的,就是那些听起来前景广阔、无需真正落地、成本极高的项目,这样他们就能赚取巨额的管理费。我认为,这就是整个行业都沉迷于规模化扩张的原因:投资人能从中赚取不菲的管理费,而且数额极其可观。但从学术研究的角度来说,这绝不是正确的选择,最终也没有带来理想的结果,反而造成了巨额的资金浪费。风险投资家赚走了管理费,而那些有限合伙人,最终会损失大量的资金。

 

Steve Eisman:你是不是觉得,这个行业的泡沫快要破裂了,还是说现在根本没法判断?

 

Gary Marcus:其实炒股的那句老话你我都懂,市场保持非理性的时间,可能比你保持偿付能力的时间还要长。

 

Steve Eisman:没错。

 

Gary Marcus:我去年用一个比喻形容当下的情况,就像《兔八哥》里的歪心狼跑到了悬崖边,它不往下看,就不会掉下去。当然这不符合物理规律,但很有意思。而现在,你所在的投资圈里,已经有人开始往下看了。我觉得从去年 11 月开始,就不断有投资人说,他们看到了一圈又一圈的的循环融资,投资回报率却不尽如人意,这些 AI 系统实际用起来也远没有想象中好用,或许这个赛道本身就不靠谱。我个人觉得,英伟达的产品做得非常出色,生态体系也很完善,不只是芯片本身,配套的软件等方方面面都很好。我见过黄仁勋,他给我留下了很深的印象,英伟达的产品确实很棒。

 

但问题的关键是,他们最终能卖出多少芯片?我认为,目前的芯片销售全靠市场投机,大家都在赌,我稍后再说说其他人的看法。所有人都在投机,认为这类芯片的需求会无限大,而这种投机的底层逻辑,是相信这些 AI 模型最终能实现 AGI。真正的 AGI 能完成人类能做的所有事,其商业价值不可估量,每年创造数万亿美元的价值都有可能。但《华盛顿邮报》几天前报道了一项一个月前完成的研究,研究显示,人类日常的工作中,只有 2.5%的工作能真正由 AI 系统完成。所以人们幻想中 AI 能完成的大部分工作,其实它都做不到,也根本做不好。这就意味着,最终所有在芯片上的投资,都会变得毫无意义。

 

而在这些企业里,OpenAI 可能是最脆弱的那个。OpenAI 有超过一万亿美元的未兑现承诺,却从未实现过盈利,如今又身处一个产品高度同质化的市场。它最大的竞争对手谷歌已经迎头赶上,甚至可以说实现了反超,还拿下了和苹果的合作大单,这可是笔大生意。所以我觉得 OpenAI 现在已经手忙脚乱了,实在看不出它的估值有任何合理性。

 

Steve Eisman:对我所在的投资圈来说,如果投资人开始从 OpenAI 撤资,而它又融不到新的资金,那会给整个生态系统带来连锁反应。

 

Gary Marcus:没错,这正是我认为即将发生的事。我觉得最终 OpenAI 可能会被微软这样的企业收购。我这几年一直说,OpenAI 最终会成为 AI 领域的 WeWork。未来人们都会疑惑,它当初怎么会有那么高的估值,这完全不合逻辑。OpenAI 的年收入只有几十亿美元,却每个月亏损数十亿美元,还有众多竞争对手,这样的企业根本撑不下去。如果投资人撤资,或者不再继续注资,OpenAI 就会陷入巨大的危机。它每个月的亏损大概有 30 亿美元,一年就是 300 多亿美元,即便最近完成了 400 亿美元的融资,也只够支撑一年的运营。

 

Steve Eisman:没错,也就一年的时间。

 

Gary Marcus:而且现在很多人都在持观望态度,他们会觉得,谷歌才是更适合这场竞争的玩家,毕竟谷歌已经追上来了。如果这场竞争只拼规模,那赢家必然是谷歌,这是毋庸置疑的。谷歌有能力做出巨额投入,甚至根本不需要英伟达的芯片,因为他们自研了张量处理单元,能实现类似的功能,所以谷歌的抗风险能力更强。他们有稳定的财务支撑,最终一定会赢。

 

Steve Eisman:没错。

 

Gary Marcus:只要有一部分人意识到,OpenAI 想要活下去,需要的资金量是天文数字,它的处境就会变得岌岌可危。它下一轮可能需要 1000 亿美元的融资,而全世界能拿出这么多钱的人,可能也就五个。就算其中四个愿意投资,只要有一个拒绝,就会出问题;而如果五个都拒绝,它要么倒闭,要么只能去找微软求救。

“脱离世界模型做 AI,根本行不通”

Steve Eisman:Gary,在我们结束访谈前,还有什么我该问却没问的问题吗?

 

Gary Marcus:我觉得这次访谈特别棒。要说还有什么重要的点没聊到,那应该就是“世界模型”这个概念。

 

Steve Eisman:没错,我本来也想聊这个。你一直说我们需要构建世界模型,这个概念完全超出了我的专业领域,不如你给大家解释一下,到底什么是世界模型?

 

Gary Marcus:不同的人对世界模型有不同的定义,简单来说,它就是在计算机系统中,构建一个能表征外部现实世界的体系。我说说我认为我们需要的世界模型是什么样的:软件内部需要有一个结构,能对应现实世界中的各种事物。比如导航系统的世界模型,需要能表征道路的分布、连接方式,以及不同路段的通行时间。在传统的 AI 领域,世界模型是研发的起点,所有的研究都基于此,没人会想过脱离世界模型做研发。Herbert Alexander Simon 是上世纪 50 年代 AI 的奠基人之一,他写过一本自传叫《Models of My Life》,他一生都在研究各类模型和世界模型,并且认为,做好 AI 的关键就是构建正确的世界模型。

 

而大语言模型却试图脱离世界模型运作。构建一个针对特定事物的世界模型,尤其是复杂事物,需要付出巨大的努力。比如过去研发专家系统时,研究者需要构建能模拟医生思考方式的模型,能表征病人身体机能、生理结构的模型,这个过程非常繁琐。当时还有一个专门的领域叫知识工程,做这项工作成本极高,没人愿意做。大语言模型和其他类型的神经网络出现后,研发者宣称,不用再做这些繁琐的工作,只需要让系统从数据中自主学习就行。

 

但事实证明,这根本行不通。就像大语言模型会把出生在洛杉矶的 Harry Shearer 说成是伦敦人,原因就是它没有一个完善的世界模型,无法像设计精良的软件那样,精准调取正确的信息。所以我们必须在 AI 系统中融入世界模型,才能避免幻觉现象的发生。

 

Steve Eisman:我还是不太理解世界模型到底是什么。

 

Gary Marcus:用非专业的语言解释确实有难度,简单说,它就是对世界的一种表征,而且这个“世界”不一定是现实世界。比如我们对《星际迷航》《星球大战》《哈利·波特》这些虚构世界,也会有对应的世界模型。这也是人类和当前 AI 系统最本质的区别:当我们看一部电影、读一本书时,会在脑海中构建出这个世界的运行规则,并且能判断情节是否符合这个世界的逻辑,会不会有不合理的设定。比如看了《哈利·波特》,我们会知道里面的人能骑着扫帚飞,但不会把这个设定和现实世界混淆,不会回家后跳上扫帚就想从窗户飞出去。

 

人类能快速构建并同时掌握多个世界模型,就算看一部新的科幻剧,20 分钟左右就能理解这个全新世界的规则,这是人类的天赋。但在 AI 领域,无论是传统的符号式 AI,还是现在的大语言模型,都做不到这一点。传统 AI 的优势是可以人工构建世界模型,你可以雇一群学者花六周时间,把一个问题的相关规则梳理清楚,构建成模型。最近离世的顶级研究者 Doug Lenat 就做过这样的研究,他为《罗密欧与朱丽叶》构建了世界模型,他的系统能真正理解这部剧的关键情节,而非从网上的读书笔记中获取二手信息,表现非常惊艳。但问题是,我们不知道该如何让传统 AI 自主学习、构建世界模型。而大语言模型则完全做不到构建世界模型,只是在假装自己能做到。

 

我有个很经典的例子,就算用整个互联网的内容训练大语言模型,让它接触海量的国际象棋规则和对局记录,它依然会走出违规的棋步,因为它从未真正抽象出国际象棋的运行逻辑。这一点就足以说明问题了。试想一下,一个人看了一百万盘象棋对局,读了维基百科、象棋网站上的所有规则,还看了 Robert James Fischer 的象棋著作,不可能连基本的棋规都掌握不了,但 AI 就是做不到。

 

所以我们需要研发能自主归纳出世界模型的 AI 系统,这类系统能从数据中挖掘因果规律,识别其中的核心要素。这是一个难题,不是说有人明天回家鼓捣一下就能解决的。长期以来,无论是传统 AI 还是大语言模型,都在回避这个问题,而现在,我们必须直面它。

 

Steve Eisman:看来这需要很长的时间来研究。

 

Gary Marcus:确实需要很久。我想说的是,AI 确实会以我们难以想象的方式改变世界,但绝不是现在,靠当下的这项技术根本做不到。我们需要把这一点考虑进去,做出合理的投资决策。现在的问题是,我们到底是在投资基础研究,还是在为一项已经成熟的技术做规模化投入?答案显然是后者。而当下的市场,大多是在投机,赌那些目前行不通的技术,只要做得更大,就能凭空实现突破。

 

但事实上,单纯的规模化根本解决不了这些核心问题,我们真正需要的是扎实的基础研究。这是我过去五年一直强调的观点,也是 SSG 在去年 11 月提出的观点,而 Ilya Sutskever 也表达了类似的看法。当我们这些背景截然不同的人,都达成了这样的共识,行业内的人其实应该认真听一听。

 

参考链接:

https://www.youtube.com/watch?v=aI7XknJJC5Q

构建过 AI agent 的人大概都遇到过这种情况:LLM 返回的数据"差不多"是你要的但又不完全对。比如会遇到字段名拼错了数据类型不对,或者干脆多了几个莫名其妙的 key。

这是问题出在哪?当前主流的 agentic AI 系统处理输出的方式太原始了,比如说脆弱的 JSON 解析、基于 prompt 的 schema 约束、各种后处理 hack。这套东西在 demo 里能跑通,到了生产环境就是定时炸弹。

PydanticAI 提供了一个根本性的解决方案:类型安全的 LLM 响应。它能把 AI 输出直接转换成经过验证的 Python 对象,配合 CrewAI 这类 agent 框架使用效果是相当不错的。

本文会介绍 PydanticAI 的核心概念,解释为什么类型化响应对 agent 系统如此重要并给出与 CrewAI 集成的实际代码示例。

LLM 输出的核心问题

Agentic 框架功能很强,但在最基础的环节:数据契约上,表现得相当糟糕。

典型的 agent 开发流程是这样的:先让 LLM 返回 JSON,然后祈祷它遵循你定义的 schema,不行就加重试逻辑,最后发现还是得手写验证器。这套流程走下来,agent 变得不稳定,失败时没有任何提示,调试起来痛苦万分。

类型化系统正是为了解决这个问题而存在的。

PydanticAI 是什么


PydanticAI 把 LLM、Python 类型系统和 Pydantic 模型组合在一起。核心理念很简单:LLM 响应必须符合预定义的 Python 类型,不符合就直接报错。

没有残缺数据,没有静默失败,没有靠猜。

为什么 CrewAI 需要这个

CrewAI 的强项在于多 agent 协调、角色分配和任务分解。但 agent 之间的数据传递、工具调用、记忆持久化,都需要结构化输出作为基础。这正是 PydanticAI 填补的空白——它提供了一个可靠的契约层。

安装

 pip install pydantic-ai crewai openai

设置 OpenAI API key:

 export OPENAI_API_KEY="your-key"

第一个示例:类型化响应

从最简单的场景开始。

定义一个响应模型:

 from pydantic import BaseModel  
   
 class Summary(BaseModel):  
     title: str  
     key_points: list[str]  
     confidence: float

这不是注释或文档,这是硬性契约。

创建 agent:

 from pydantic_ai import Agent  
from pydantic_ai.models.openai import OpenAIModel  

model = OpenAIModel("gpt-5-mini")  

agent = Agent(  
    model=model,  
    result_type=Summary  
 )

运行:

 result = agent.run_sync(  
     "Summarize the benefits of typed AI agents"  
 )  
   
 print(result.title)  
 print(result.key_points)  
 print(result.confidence)

这里发生了什么?LLM 被强制返回符合 Summary 结构的数据,验证自动进行,输出不合法会触发重试或直接失败。这才是可以上生产的 LLM 输出。

Agent 间的数据契约

来看一个更实际的例子:两个 agent 协作。

研究 agent:

 class ResearchResult(BaseModel):  
    topic: str  
    findings: list[str]  

research_agent = Agent(  
    model=model,  
    result_type=ResearchResult  
 )

写作 agent,负责消费研究 agent 的输出:

 class BlogDraft(BaseModel):  
    headline: str  
    sections: list[str]  

writer_agent = Agent(  
    model=model,  
    result_type=BlogDraft  
 )

协作流程:

 research = research_agent.run_sync(  
     "Research typed LLM outputs in AI agents"  
 )  
   
 draft = writer_agent.run_sync(  
     f"Write a blog using these findings: {research.findings}"  
 )

整个过程没有 JSON 解析,不用猜测 schema,Python 对象在 agent 之间直接流转。

与 CrewAI 集成

CrewAI 负责编排,PydanticAI 负责类型正确性,这种组合越来越常见。

 from crewai import Agent as CrewAgent, Task  

analysis_agent = CrewAgent(  
    role="Analyst",  
    goal="Generate structured insights"  
)  

task = Task(  
    description="Analyze market trends in AI tooling",  
    agent=analysis_agent  
 )

加入类型化执行层:

 typed_agent=Agent(  
     model=model,  
     result_type=ResearchResult  
 )  
   
 result=typed_agent.run_sync(task.description)

CrewAI 处理 agent 的角色和任务分配,PydanticAI 保证输出的结构正确。

类型化如何改变可靠性

没有类型约束的 agent 系统会出现各种问题:agent 凭空生成不存在的 key,下游步骤因为数据格式错误而静默失败,排查问题时无从下手。

用了 PydanticAI 之后,无效输出会被立即拒绝,重试自动触发,这样bug 在早期就会暴露出来。这其实是软件工程领域早就有的实践:API 用 schema 约束,数据库用约束条件,编译器做类型检查,Agentic AI 只不过是终于跟上了这个标准。

生产环境用例

PydanticAI 加 CrewAI 的组合适合这些场景:研究类 agent、内容生成流水线、数据提取任务、业务流程自动化、AI 辅助决策系统。只要你的应用对输出结构有要求,这套方案就值得考虑。

不过有几个做法应该避免:让 agent 返回原始字符串然后自己解析,用 eval() 处理 JSON(安全隐患太大),盲目相信"格式良好"的 prompt 能约束输出,在 agent 之间传递未经验证的数据。

类型化不是额外负担,是风险控制。

总结

Agentic AI 发展很快,但速度如果没有结构做支撑,系统就会变得脆弱。PydanticAI 把软件工程的类型规范带入了 LLM 系统,让 agent 更安全、更可预测、更容易扩展。

当 AI 输出变成真正的 Python 对象,agent 就不再只是 demo,而是可以正式投入使用的系统。

https://avoid.overfit.cn/post/2a20c5c4c1394c92a252a04388f8e26e

作者:Er.Muruganantham

整理 | 华卫

 

用一个 PostgreSQL 主库和 50 个只读副本,就顶住了 ChatGPT 上的 8 亿用户!

 

近日,OpenAI 的工程师们不仅爆出了这一惊人消息,还直接把 Codex 的“大脑”给扒了个精光。在 OpenAI 官方工程博客主页,OpenAI 工程师、Technical Staff 成员 Michael Bolin 发布了一篇文章,以“揭秘 Codex 智能体循环”为题,深入揭秘了 Codex CLI 的核心框架:智能体循环(Agent Loop),并详细讲解了 Codex 在查询模型时如何构建和管理其上下文,以及适用于所有基于 Responses API 构建智能体循环的实用注意事项和最佳实践。

 

这些消息传出后,在 Hacker News 等技术论坛及社交平台上获得了高度关注。“看似平淡的技术最终会胜出。OpenAI 正在证明,优秀的架构远胜于花哨的工具。”

 

值得一提的是,有网友透露,前不久 Anthropic 的一位工程师称“他们用于 Claude Code UI 的架构糟糕且效率低下”。而就在刚刚,X 上出现一条爆料:Codex 已接管 OpenAI 100%的代码编写工作。

 

对于“你们有多少百分比的编码工作是基于 OpenAI 模型进行”的问题,roon 表示,“100%,我不再写代码了。”而此前,Sam Altman 曾公开发帖称,“roon 是我的小号。”

 

Codex 的“大脑”揭秘

“每个人工智能智能体的核心都是 Agent Loop,负责协调用户、模型以及模型调用以执行有意义的软件工作的工具之间的交互。”

 

据介绍,在 OpenAI 内部,“Codex”涵盖了一系列软件智能体产品,包括 Codex CLI、Codex Cloud 和 Codex VS Code 插件,而支撑它们的框架和执行逻辑是同一个。

 

Agent Loop 的简化示意图

 

首先,智能体会从用户那里接收输入,并将其纳入为模型准备的文本指令集,该指令集被称为提示词。下一步是通过向模型发送指令并要求其生成响应来查询模型,这个过程称为推理。推理过程中,文本提示词首先被转换为一系列输入 token,随后被用于对模型进行采样,生成新的输出 token 序列。输出 token 会被还原为文本,成为模型的回复。由于 token 是逐步生成的,该还原过程可与模型的运行同步进行,这也是众多基于大语言模型的应用支持流式输出的原因。实际应用中,推理功能通常封装在文本 API 后方,从而抽象化词元化的细节。

 

推理步骤完成后,模型会产生两种结果:(1)针对用户的原始输入生成最终回复;(2)要求智能体执行某项工具调用操作。若为第二种情况,智能体将执行该工具调用并将工具输出结果附加至原始提示词中。该输出结果会被用于生成新的输入内容,再次对模型进行查询;智能体随后会结合这些新信息,重新尝试完成任务。这一过程会不断重复,直至模型停止发出工具调用指令,转而生成面向用户的消息(在 OpenAI 的模型中,该消息被称为助手消息)。多数情况下,这条消息会直接解答用户的原始请求,也可能是向用户提出的跟进问题。

 

由于智能体可执行能对本地环境进行修改的工具调用,其 “输出” 并不仅限于助手消息。在很多场景下,软件智能体的核心输出是在用户设备上编写或编辑的代码。但无论何种情况,每一轮交互最终都会以一条助手消息收尾,该消息是智能体循环进入终止状态的信号。从智能体的角度来看,其任务已完成,操作控制权将交还给用户。

 

多轮智能体循环

 

这意味着,对话内容越丰富,用于模型采样的提示词长度也会随之增加。而所有模型都存在上下文窗口限制,即其单次推理调用可处理的 token 最大数量,智能体可能在单次对话轮次中发起数百次工具调用,这有可能耗尽上下文窗口的容量。因此,上下文窗口管理是智能体的多项职责之一。

这套智能体循环如何运行?

据介绍,Codex 正是借助响应 API 来驱动这套智能体循环的,博文曝出许多背后的实际运行细节,包括:

  • Codex 不会把用户的话直接给大模型用,而是会主动“拼接”出一整套精心设计的提示词结构,且涵盖多个角色的指令、用户输入的一句话在结尾才出现。

  • 模型推理与工具调用之间可能会进行多轮迭代,提示词的内容会持续增加。

构建初始提示词

作为终端用户,在调用响应 API 时无需逐字指定用于模型采样的提示词,只需在查询中指定各类输入类型,由响应 API 服务器决定如何将这些信息组织为模型可处理的提示词格式。在初始提示词中,列表中的每个条目均关联一个角色。该角色决定了对应内容的权重占比,优先级从高到低分为以下几类:系统、开发者、用户、助手。

 

响应 API 接收包含多个参数的 JSON 负载,其中三个核心参数有:

  • 指令:插入模型上下文的系统(或开发者)消息

  • 工具:模型生成回复过程中可调用的工具列表

  • 输入:向模型传入的文本、图片或文件输入列表

 

在 Codex 中,若已配置,指令字段的内容会从~/.codex/config.toml 配置文件中的模型指令文件读取;若未配置,则使用与该模型关联的基础指令。模型专属指令存储在 Codex 代码仓库中,并被打包至命令行工具中。工具字段为符合响应 API 定义的模式的工具定义列表。对于 Codex 而言,该列表包含三部分工具:Codex 命令行工具自带的工具、响应 API 提供且开放给 Codex 使用的工具,以及通常由用户通过 MCP 服务器提供的自定义工具。JSON 负载的输入字段为一个条目列表。在添加用户消息前,Codex 会先向该输入中插入以下条目:

 

1. 一条角色为开发者(role=developer)的消息,用于描述仅适用于工具部分中定义的 Codex 内置 Shell 工具的沙箱环境。也就是说,其他工具(如由 MCP 服务器提供的工具)并不受 Codex 的沙箱限制,需自行负责实施自身的防护规则。该消息基于模板构建,核心内容均来自打包在 Codex 命令行工具中的 Markdown 代码片段。

2.一条角色为开发者的消息,其内容为从用户的 config.toml 配置文件中读取的 developer_instructions 配置值。

3.一条角色为用户的消息,其内容为用户指令;该内容并非来源于单个文件,而是从多个数据源聚合而来。一般而言,表述越具体的指令,排序越靠后:

  • 加载 $CODEX_HOME 目录下 AGENTS.override.md 和 AGENTS.md 文件的内容

  • 在默认 32 千字节的大小限制内,从当前工作目录对应的 Git / 项目根目录(若存在)向上遍历至当前工作目录本身,加载任意 AGENTS.override.md、AGENTS.md 文件的内容,或加载 config.toml 配置文件中 project_doc_fallback_filenames 参数指定的任意文件内容

  • 若已配置相关技能,则补充以下内容:关于技能的简短引言、各技能对应的技能元数据、技能使用方法说明章节。

4. 一条角色为用户的消息,用于描述智能体当前的运行本地环境,其中会明确当前工作目录及用户所使用的终端 Shell 信息。

 

当 Codex 完成上述所有计算并完成输入初始化后,会追加用户消息以启动对话。需注意的是,输入中的每一个元素都是一个 JSON 对象,包含类型、角色和内容三个字段。当 Codex 构建好要发送至响应 API 的完整 JSON 负载后,会根据~/.codex/config.toml 中响应 API 端点的配置方式,携带授权请求头发起 HTTP POST 请求(若有指定,还会添加额外的 HTTP 请求头和查询参数)。当 OpenAI 响应 API 服务器接收到该请求后,会使用 JSON 数据来推导出模型的提示信息,(需要说明的是,Responses API 的自定义实现可能会采用不同的方法)。

 

可见,提示词中前三项的顺序由服务器决定,而非客户端。也就是说,这三项里仅系统消息的内容同样由服务器控制,工具与指令则均由客户端决定。紧随其后的是 JSON 负载中的输入内容,至此提示词拼接完成。

模型采样

提示词准备就绪后,模型才开始进行进行采样。

 

第一轮交互:此次向响应 API 发起的 HTTP 请求,将启动 Codex 中对话的第一轮交互。服务器会以服务器发送事件(SSE)流的形式进行响应,每个事件的数据均为一个 JSON 负载,其 type 字段以 response 开头。Codex 接收该事件流并将其重新发布为可供客户端调用的内部事件对象。`response.output_text.delta`这类事件用于为用户界面实现流式输出功能,而`response.output_item.added`等其他事件则会被转换为对象,附加至输入内容中,为后续的响应 API 调用所用。

 

若首次向响应 API 发起的请求返回两个`response.output_item.done`事件,一个类型为推理(reasoning),一个类型为函数调用(function_call),那么当结合工具调用的返回结果再次向模型发起查询时,这些事件必须在 JSON 的输入字段中进行体现。后续查询中用于模型采样的最终提示词结构如下:

 

需要特别注意的是,旧提示词是新提示词的完整前缀。这一设计是有意为之的,因为它能让用户借助提示词缓存提升后续请求的效率。

 

在 Codex 命令行工具中,会将助手消息展示给用户,并聚焦输入编辑区,以此提示用户轮到其继续对话。若用户做出回应,上一轮的助手消息以及用户的新消息均需附加至响应 API 请求的输入字段中,从而开启新一轮对话。同样,由于对话处于持续进行的状态,发送至响应 API 的输入内容长度也会不断增加。

 

弃用简单参数费力做优化,就为了用户隐私?

“在对话过程中,发送至响应 API 的 JSON 数据量,是否会让智能体循环的时间复杂度达到二次方级别?”答案是肯定的。

 

据悉,尽管响应 API 支持通过可选的 previous_response_id 参数缓解这一问题,但目前 Codex 并未启用该参数,主要是为了保证请求完全无状态,并兼容零数据保留(ZDR) 配置,即不存储用户对话数据。

 

取而代之的,是两套需投入大量研发精力、涉及复杂实施流程的技术策略。文中,OpenAI 详细介绍了这两项硬核优化的具体方案。

 

通常,模型采样的开销远高于网络传输的开销,采样环节会成为优化效率的核心目标,这也是提示词缓存至关重要的原因,它能复用前一次推理调用的计算结果。当缓存命中时,模型采样的时间复杂度将从二次方降至线性。OpenAI 相关的提示词缓存文档对这一机制有更详细的说明:仅当提示词存在完全匹配的前缀时,才有可能实现缓存命中。为充分发挥缓存的优势,需将指令、示例等静态内容置于提示词开头,而将用户专属信息等可变内容放在末尾。这一原则同样适用于图片和工具,且其内容在各次请求中必须保持完全一致。

 

基于这一原则,Codex 中可能有以下导致缓存未命中的操作:

  1. 在对话过程中修改模型可调用的工具列表;

  2. 更换响应 API 请求的目标模型(实际场景中,这会改变原始提示词中的第三项内容,因该部分包含模型专属指令);

  3. 修改沙箱配置、审批模式或当前工作目录。

 

因此,Codex 团队在为命令行工具开发新功能时,必须审慎考量,避免新功能破坏提示词缓存机制。例如,他们最初对 MCP 工具的支持曾出现一个漏洞:工具的枚举顺序无法保持一致,进而导致缓存未命中。需要注意的是,MCP 工具的处理难度尤为突出,因为 MCP 服务器可通过 notifications/tools/list_changed 通知,动态修改其提供的工具列表。若在长对话过程中响应该通知,极易引发高成本的缓存未命中问题。

 

在可能的情况下,针对对话过程中发生的配置变更,他们会通过在输入中追加新消息的方式体现变更,而非修改已有的早期消息:

  • 若沙箱配置或审批模式发生变更,我们会插入一条新的role=developer消息,格式与原始的条目保持一致;

  • 若当前工作目录发生变更,我们会插入一条新的role=user消息,格式与原始的条目保持一致。

 

据介绍,为保障性能,OpenAI 在实现缓存命中方面投入了大量精力。除此之外,他们还重点管理了一项核心资源:上下文窗口。

 

其规避上下文窗口耗尽的通用策略是:一旦词元数量超过某个阈值,就对对话进行压缩。具体来说,会用一个更精简、且能代表对话核心内容的新条目列表替代原有输入,让智能体在继续执行任务时仍能理解此前的对话过程。早期的压缩功能实现方案,需要用户手动调用/compact 命令,该命令会结合现有对话内容和自定义的摘要生成指令,向响应 API 发起查询;Codex 则会将返回的、包含对话摘要的助手消息,作为后续对话轮次的新输入。

 

此后,响应 API 不断迭代,新增了专用的/responses/compact 端点,能以更高效率完成压缩操作。该端点会返回一个条目列表,可替代原有输入继续对话,同时释放出更多的上下文窗口空间。该列表中包含一个特殊的 type=compaction 条目,其附带的 encrypted_content 加密字段为透明化设计,可保留模型对原始对话的潜在理解。

 

现在,当词元数量超过 auto_compact_limit 自动压缩阈值时,Codex 会自动调用该端点对对话内容进行压缩。

极限扩容:用 1 个数据库扛住了 8 亿用户

在另一篇技术博文中,OpenAI 工程师 Bohan Zhang 介绍, OpenAI 通过严苛的技术优化与扎实的工程实践,对单个数据库 PostgreSQL 进行深度扩容,实现以单套体系支撑 8 亿用户、每秒数百万次查询的访问需求。

 

据称,多年来,PostgreSQL 一直是支撑 ChatGPT、OpenAI API 等核心产品的核心底层数据系统之一。过去一年,公司 PostgreSQL 的负载增长超 10 倍,且这一增长趋势仍在持续加速。OpenAI 称,PostgreSQL 的横向扩展能力远超此前行业普遍认知,能够稳定支撑规模大得多的读密集型工作负载。“这套最初由加州大学伯克利分校的科学家团队研发的系统,助力我们通过单主节点 Azure PostgreSQL 弹性服务器实例,搭配分布在全球多个区域的近 50 个只读副本,承接了海量的全球访问流量。”

 

而且,OpenAI 表示,其扩容在实现规模提升的同时,始终将延迟控制与可靠性优化放在核心位置:生产环境中,客户端 99 分位延迟稳定保持在十几毫秒的低水平,服务可用性达到五个九标准;过去 12 个月内,PostgreSQL 仅出现过一次零级严重故障,该故障发生在 ChatGPT 图像生成功能爆红上线期间,一周内超 1 亿新用户注册导致写流量突发暴涨超 10 倍。

 

尽管 PostgreSQL 的扩容成果已达预期,OpenAI 仍在持续探索其性能极限。目前,他们已将可分片的写密集型业务负载迁移至 CosmosDB 等分片式数据库系统;对于分片难度更高的剩余写密集型负载,相关迁移工作也在积极推进,以此进一步减轻 PostgreSQL 主节点的写压力。同时,OpenAI 正与微软 Azure 团队展开合作,推动级联复制功能落地,实现只读副本的安全、大规模扩容。随着基础设施需求的持续增长,其将继续探索更多扩容方案,包括基于 PostgreSQL 的分片架构改造、引入其他分布式数据库系统等。

 

有网友评价道,“这招的高明之处,就在于极简。他们没用什么花里胡哨的冷门技术,不过是把最佳实践做到了极致。过去十年,行业里全是 ‘一切皆分片、拥抱 NoSQL、全面分布式,为 CAP 定理折腰’ 的论调,而 OpenAI 倒好, 服务十亿级用户的解法,居然只是一句‘试过加只读副本吗?’”

 

参考链接:

https://openai.com/index/unrolling-the-codex-agent-loop/

https://openai.com/index/scaling-postgresql/

OpenAI 已对部分领导层进行了重组,并挑选了一位 “老熟人” 来领导其向企业客户销售 AI 的业务,因为公司希望在 2026 年赶上竞争对手。
据《The Information》报道,OpenAI 在一份内部备忘录中宣布,任命 Barret Zoph 负责企业业务销售工作。
TechCrunch 已联系 OpenAI 寻求确认和更多信息。
Zoph 上周从 Thinking Machine Labs 回到 OpenAI。他自 2024 年 10 月起在该公司担任联合创始人兼首席技术官,而该公司正是前 OpenAI 首席技术官 Mira Murati 创办的 AI 初创企业。
他离开 Thinking Machine Labs 的具体原因尚不清楚,有传言称 Zoph 和其他几位前 OpenAI 员工是被解雇,也有人说他们是自愿离职,甚至可能早就计划重返 OpenAI。
Zoph 此前在 2022 年 9 月至 2024 年 10 月期间担任 OpenAI 的 训练后推理副总裁。如今他将进入一个完全不同的岗位,并可能在公司中扮演重要角色,因为 OpenAI 正努力扩大其企业业务 —— 这是一个它正逐渐输给竞争对手的领域。
OpenAI 在 2023 年就推出了面向企业的 ChatGPT Enterprise,比 Anthropic 早了一年多,也领先 Google 多年。公司声称该产品拥有超过 500 万企业用户,客户包括 SoftBank、Target 和 Lowe’s 等公司。
但它的市场份额正在下降,而竞争对手正在上升。
在企业级大语言模型使用方面,Anthropic 遥遥领先。根据风投公司 Menlo Ventures 12 月的报告(该公司对 Anthropic 有大量投资),Anthropic 占据了 40% 的市场份额。而在 7 月,该公司的市场份额估计为 32%。
根据 Menlo Ventures 的数据,Google Gemini 的采用率则更为稳定。Google 在去年秋天推出了企业版产品,其企业级 LLM 使用市场份额基本保持不变,从 7 月的 20% 增长到年底的 21%。
相比之下,OpenAI 的市场份额已从 2023 年的 50% 下降到 2025 年底的 27%—— 这一趋势显然让公司感到担忧。几个月前,OpenAI CEO Sam Altman 在一份内部备忘录中特别提到,Google Gemini 的增长开始侵蚀 OpenAI 的市场。
OpenAI 首席财务官 Sarah Friar 在本周日的博客中写道,企业业务增长是公司 2026 年的重点。
此后,公司宣布与 ServiceNow 扩大多年合作关系,ServiceNow 客户将能够使用 OpenAI 的模型。

亚马逊首席执行官安迪・贾西(Andy Jassy)设想,在竞争对手纷纷推出 AI 购物代理的背景下,人工智能将通过复制实体店的 “惊喜发现感” 来改变零售业。亚马逊正在谈判向 OpenAI 投资约 100 亿美元,并与芯片使用量挂钩;与此同时,亚马逊也在开发 “帮我买”(Buy For Me)等内部工具,以维持其主导地位。这一战略转向旨在将创新与合作伙伴关系结合起来,以在未来的 AI 商务领域保持领先。

亚马逊的贾西在 AI 商务大战中前行:在购物代理竞争中押注 OpenAI

在达沃斯世界经济论坛的繁忙大厅里,亚马逊公司首席执行官安迪・贾西最近分享了他对零售业未来的愿景,强调人工智能可能会彻底改变消费者的购物方式。在一场小组讨论中,贾西指出,AI 有潜力弥合线上和线下购物体验之间的差距,并表示先进技术可能很快就能复制在实体店闲逛时那种 “偶然发现好物” 的感觉。
“在我看来,实体零售目前仍有一些优势的地方,是你可以走进店里,不知道自己想要什么,提出问题,不断细化问题,然后有人会给你推荐一些你甚至不知道存在的东西。” 据《The Information》报道,贾西这样说道。
这番评论发表之际,这家电商巨头正面临来自 OpenAI、谷歌和微软等竞争对手开发的 AI 购物代理的激烈竞争。这些工具允许用户直接在聊天界面内完成购买,对亚马逊在在线零售领域的主导地位构成潜在威胁。贾西的言论凸显了亚马逊的战略转向:它不仅在捍卫自己的地盘,还在积极探索合作伙伴关系,以在这个不断演变的领域保持领先。
最近的报道显示,亚马逊正就向 OpenAI 投资约 100 亿美元 进行深入谈判,这笔交易可能使这家 AI 公司的估值超过 5000 亿美元。据路透社 2025 年末的一篇文章详细报道,这笔潜在交易还包括 OpenAI 承诺使用亚马逊的 Trainium AI 芯片,这标志着双方技术联盟的深化。

AI 发展中的战略联盟

贾西对 AI 在提升购物体验方面作用的乐观态度,与更广泛的行业趋势一致。分析师指出,2026 年将是 AI 购物代理的关键一年,消费者将越来越多地为了便利和个性化而测试这些工具。《Modern Retail》的一篇文章指出,零售商和科技巨头正竞相完善这些代理,并押注它们会被广泛采用。
亚马逊面临的困境十分严峻:要么抵制这些可能绕过其平台的外部代理,要么整合类似功能以保留用户忠诚度。根据 CNBC 的分析,OpenAI 的 “即时结账”(Instant Checkout)和 Perplexity 的 “即时购买”(Instant Buy)等创新正在重塑交易方式,有可能将流量从传统电商网站分流。
作为回应,亚马逊一直在测试自己的功能,例如 “帮我买”(Buy For Me)选项,该功能允许用户在不离开亚马逊生态系统的情况下从第三方网站购买商品。行业观察人士在 X 上的帖子指出,这是一种防御策略,有用户注意到 AI 代理现在可以在一次对话中完成从产品研究到结账的所有操作,凸显了竞争压力。

与科技巨头的正面交锋

AI 与商务的融合,使主要参与者走上了直接竞争的道路。《The Information》的一篇报道描述了谷歌、亚马逊和 OpenAI 各自如何追求不同的战略,从专有代理到协作商务模式。这场竞争还延伸到了微软,微软最近推出了 “Copilot Checkout”,允许在其 AI 聊天机器人中无缝完成购买。
GeekWire 报道了微软进入这一领域的消息,并强调其企业关系可能使其相对于亚马逊和其他公司具有优势。“微软正在推出一项新的‘Copilot Checkout’功能,让购物者可以直接在其 AI 聊天机器人内完成购买,”GeekWire 的文章指出,并强调了在 AI 驱动的商务中对零售商关系的押注。
贾西在达沃斯的亮相中也谈到了围绕 AI 投资的泡沫担忧。《The Register》的一篇最新报道援引他的话称,他承认存在炒作,但重申亚马逊致力于从中挖掘价值,即使这些交易看起来有些 “循环”。

OpenAI 合作关系动态

对 OpenAI 潜在的 100 亿美元投资不仅仅是财务上的,更是为了确保技术优势。正如《Fortune》一篇文章所引用的专家观点,这被视为亚马逊在 “下一盘大棋”。分析师查尔斯・菲茨杰拉德(Charles Fitzgerald)表示:“如果 OpenAI 中了‘彩票’,那么他们就有足够的钱来支付这笔费用。” 他指的是芯片使用协议。
这种关系建立在亚马逊现有的 AI 计划之上,包括其 AGI 团队正努力超越 Anthropic 等合作伙伴的模型。2024 年 X 上的历史帖子回顾了亚马逊对 Anthropic 的投资,但此次转向 OpenAI 表明,在 OpenAI 自身内部发生变化的背景下,亚马逊正在采取多元化战略。
《印度时报》最近的消息详细报道了 OpenAI 从其前首席技术官领导的初创公司挖走人才的情况,这表明 OpenAI 内部存在动荡,而亚马逊可能通过投资加以利用。

正在重塑零售互动的创新

除了投资之外,亚马逊还在将 AI 深度嵌入其运营中。贾西 2025 年在 X 上的帖子宣传了新的智能体式 AI(agentic AI)功能,这些功能可以通过分析数据和自动化任务来帮助卖家扩展业务。这种内部关注与外部合作伙伴关系相辅相成,旨在创造无缝的购物旅程。
《Wired》探讨了一些开发者不愿让 AI 代理作为用户互动中介的担忧,正如一篇 WIRED 文章所讨论的那样,AI 正成为下一个平台。然而,亚马逊仍在推进,AI 已用于预测需求、优化配送路线,甚至在仓库中提供协助,正如 2023 年的 X 帖子所展示的那样。
X 上的行业情绪反映了对这些进步的兴奋。有帖子称,像亚马逊这样的数字商务平台正将 AI 转变为核心基础设施,触及从推荐到配送的各个方面。

挑战与消费者采用

尽管热情高涨,但挑战依然存在。贾西在达沃斯的评论提到了实体零售仍然持有的优势,这意味着 AI 必须不断发展,才能匹配那种探索的乐趣。分析师警告称,2026 年消费者对 AI 代理的接受程度将是真正的考验,正如《Modern Retail》的分析所指出的那样。
此外,潜在的 OpenAI 交易引发了有关反垄断审查的问题,考虑到投资规模和市场影响力。路透社关于谈判的报道强调了估值方面的影响,这可能会重塑 AI 融资动态。
a16z 等风险投资公司在 X 上的帖子认为,AI 正在将在线购物模式从 “量” 转向 “质” 和个性化,亚马逊必须谨慎应对这一转变,以免被边缘化。

AI 商务整合的未来轨迹

展望未来,亚马逊的战略似乎是多方面的:投资尖端 AI 公司、开发内部工具,并适应新兴的消费者行为。贾西早些时候在 2023 年 X 帖子中对 “亚马逊在 AI 方面落后” 的说法提出质疑,这表明他一贯强调实质而非炒作。
《The Information》详细描述了亚马逊与谷歌和 OpenAI 的正面竞争,这表明可能会出现共享商务模式,但专有优势将决定胜负。正如 GeekWire 所指出的,微软的 Copilot 举措又增加了一层竞争,它将利用其企业关系。
最终,随着 AI 设备的普及,《Wired》指出开发者存在犹豫,但亚马逊的规模可能使其处于领先地位。贾西在达沃斯提出的愿景强调了 “细化问题” 和 “发现”,指向一个未来:AI 代理将充当虚拟商店助理,将在线效率与线下的惊喜发现感完美结合。

在投资与内部增长之间取得平衡

亚马逊对 OpenAI 的潜在注资并非孤立存在,而是更广泛战略推进的一部分。《Fortune》的专家强调了这种战略耐心,亚马逊押注 OpenAI 的成功将推动芯片的采用。
内部开发项目,例如 2024 年 X 帖子中提到的 Olympus LLM,表明亚马逊在合作的同时也致力于自力更生。这种双轨方式可以减轻 OpenAI 危机带来的风险,正如《印度时报》所报道的那样。
X 用户最近对亚马逊的 “帮我买” 功能表示赞赏,认为它是对 OpenAI 即时结账的反击,有助于维持生态系统的控制权。

竞争压力与市场反应

根据《Modern Retail》的说法,AI 购物大战正在升温,2026 年将是关键时期。正如 CNBC 所描述的那样,亚马逊面临的困境是:与这些代理对抗,还是加入它们。
贾西在《The Register》中对 “泡沫” 的承认反映了他在乐观中的现实态度。“当然这是一个泡沫,而且这些交易是循环的 —— 但这并不意味着亚马逊不会努力从中榨取价值。” 他说。
X 上的情绪强调了 AI 在电商基础设施中的作用,从亚马逊到沃尔玛和 Shopify 等竞争对手,正如一篇帖子所对比的那样。

不断演变的消费者期望

消费者可能很快就会期望 AI 能够无缝处理复杂的购物任务。《The Information》对达沃斯的报道援引贾西的话,强调实体零售的优势,这正推动亚马逊在数字领域进行创新。
《Wired》关于 AI 平台的文章警告称存在开发者的抵制,但亚马逊的整合可能会促进采用。
正如 X 上的帖子所暗示的那样,AI 正在从头开始重塑购物,重点放在用户体验和价格优化上 —— 而这些正是亚马逊擅长的领域。

亚马逊的战略展望

在这种高风险环境下,亚马逊与 OpenAI 的谈判代表着一场大胆的赌注。路透社详细报道了 100 亿美元的数字,并将其与芯片承诺挂钩。
《Fortune》分析师认为,这是一种长期定位,将 OpenAI 视为 “AI 领域的舒洁(Kleenex)”。
贾西的领导能力在他关于卖家工具的 X 帖子中显而易见,这使亚马逊能够将 AI 创新与零售实力结合起来,从而在竞争中脱颖而出。
正如《The Information》所概述的那样,前进的道路包括在竞争中导航,确保亚马逊在 AI 商务的演变过程中保持核心地位。

最近的达沃斯论坛上,科技领袖们纷纷出来发表观点。当 Google 的 Demis Hassabis 和 Anthropic 的 Dario Amodei 在讨论更宏观的 AGI 话题时,微软 CEO Satya Nadella 与英国前首相 Rishi Sunak 的对话,更聚焦在了 AI 应用的话题。

 

Satya 以自己参加达沃斯的准备工作变化为例,来说明在企业内部,AI 正在打破传统层级架构,让信息流实现扁平化。

 

“自从我 1992 年参加以来,直到几年前,流程都没什么变化:我的现场团队会准备笔记,然后送到总部进一步提炼。但现在我直接找 Copilot 说,“我要见 xxx,给我一个简介”。它会给我一个全方位的视角。”“我做的是立即把这个简介分享给所有部门的同事。”

 

他指出,企业 AI 应用呈现出明显的 “杠杆效应”:初创公司能从零开始构建适配 AI 的组织,落地速度更快;大型企业虽手握数据、资源优势,但传统工作流程与组织惯性带来的变革管理挑战更大。而无论大小企业,都需经历 “思维转变 — 技能培养 — 数据整合” 的艰苦过程。

 

人才方面,他认为全球 AI 技术人才与初创公司的质量已无显著差异:“雅加达、伊斯坦布尔的人才技术水平并不逊色于西雅图、旧金山。”真正的差距在于大规模应用的推进力度。

 

Satya 表示,判断 AI 是否存在泡沫,关键也在于落地应用:若仅停留在科技公司的技术讨论,泡沫风险确实存在;但当 AI 加速药物临床试验、提升农业生产效率、优化公共服务时,技术就已转化为实实在在的经济价值。

 

今天,Satya 参加 All-In Podcast 的采访也发布了,这次谈话与 Rishi 那次比,有部分话题重合,但也更微观一些。他谈到,科技行业每十年换一批竞争对手是好事,能倒逼企业保持竞争力,科技产业蛋糕会持续变大,绝非零和博弈。而微软与 OpenAI 合作的核心逻辑:不押注单一模型,而是打造算力+应用服务器层的平台,兼容多模型生态。

 

他还提到,公司内部全球网络团队已用 AI Agent(数字员工)自动化处理光纤挖断、设备故障等 DevOps 重复工作,完全是自下而上的落地实践。此外还将 LinkedIn 等团队各角色合并为“全栈构建者”,重构 AI 产品工作流。现在,微软正在尝试新学徒制模式:由资深 IC 工程师带一组应届生,借助 AI 加速新人生产力爬坡,以适配 AI 时代的人才培养方式,新人仍需持续进入职场。

 

国际竞争方面,他认为,美国技术栈的核心优势是生态效应(平台之上生态收入远超自身收入),而非单纯市场份额,技术“扩散”是做大全球蛋糕,而非抢蛋糕。

 

我们翻译并整理了这次访谈内容,并在不改变原意基础上进行了删减,以飨读者。

 

移民政策下的一段“奇妙经历”

 

Jason:今天非常高兴,能请到重量级嘉宾 Satya Nadella,Microsoft 的第三任 CEO,和我们的 AI 与加密领域负责人 David Sacks 来一场即兴炉边对话。Satya 出生在印度,大学毕业后来到美国,这一路经历本身就很传奇。你在书里写过,为了把太太接来美国,还专门“折返”了一趟。能不能简单和大家讲讲当时是怎么回事?

 

Satya:这件事其实是美国移民政策下的一段“奇妙经历”。我和太太在印度读的是同一所大学,后来我来美国读研究生,我们结了婚。我拿到了绿卡,但问题是由于我们是结婚后才申请,她反而不能直接过来。结果就是,我不得不放弃已经拿到的绿卡。

 

最有意思的是,我去新德里的美国使馆,问工作人员:“请问放弃绿卡要排哪一队?”他们直接说:“没有这种队伍。”在九十年代,主动放弃绿卡绝对算是件“疯狂”的事。但为了让她能以 H1 签证过来,只能这么操作。好在最后一切都解决了,现在想起来更像是一段久远但有点荒诞的回忆。

 

Jason:我想聊聊 Copilot。你们最早在 GitHub 上推出 Copilot,后来做到桌面端,再到直接把它放进 Windows,这对 Microsoft 来说是个非常大胆的决定。我每天都在用。但老实说,在它还不能真正理解文件系统、也没法和应用深度交互之前,市场反应不温不火。不过现在你们明显在持续加码。

 

在我看来,面向知识工作者,AI 正在走向三种形态:一类是 Elon 在 xAI 做的那种“人类模拟器”,据说直接把“虚拟员工”塞进聊天和邮箱系统;一类是 Claude 刚发布的协作型 Agent,强得离谱,很多人已经被震住了,我自己连续玩了四十多个小时。

 

那 Microsoft 的愿景是什么?知识工作者究竟该怎么真正把这些东西用起来?现在大家更多还是在“玩 ChatGPT”,这和真正创造商业价值之间好像还有一道鸿沟。

 

Satya:要理解这些不同形态,最好的切入口其实是编程,代码工作几乎是最典型的知识工作。

 

回头看这条演进路线:最早是“Next Edit Suggestions”,也就是智能补全。老实说,我对这一代 AI 技术真正建立信心,就是从早期 Codex 那一代模型开始的。那还是 GPT-3.5 之前,但补全已经相当准确了。后来我们有了 chat 交互,再往后是可执行的 actions,现在则是全自主 Agent。这些 Agent 既可以在前台,也可以在后台;可以在云端,也可以在本地运行。

 

有意思的是,这些形态今天在编程中都有,而且你会全部用到,而非只选其中一种。比如我在 CLI 里,可以有前台 Agent、后台 Agent,同时直接在 VS Code 里改代码,这些全部并行进行。这说明了不同形态是可以组合的。

 

把这套放到知识工作上也是一样。我们是从 chat 开始,带推理的 chat 不只是一问一答,你能看到它完整的思考过程;现在到了 actions 阶段,通过模拟电脑操作、Skill 和 Agent 调用调用来执行任务,这就是 Copilot 如今的状况。

 

接下来,其实需要一个新的“隐喻”来理解 AI 时代的计算机。Jobs 当年形容 PC 是“思维的自行车”;Bill Gates 说过一句我很喜欢的话:“信息触手可及”。但在 AI 时代,我们需要新的说法。我很喜欢 Notion CEO 的一个比喻:“无限思维的管理者”。这个说法非常形象。

 

Jason:确实是个很棒的产品。不过你们还没收购它。

 

Satya:还没有(笑)。但这个比喻点中了关键:你同时在和大量 Agent 协作。我自己还常用两个词:宏观委派和微观引导,即你把一整块工作交出去,同时在执行过程中不断给细节指令。写代码其实已经是这样了。这正是今天 Copilot 的真实状态。

 

还有一种我特别期待的形态,很快你们就会看到:开发者并不是只待在自己的 repo 里。我们要开会、写设计文档、实现别人写好的规格说明,还要保证代码和这些内容一致。这就意味着,Copilot 需要能通过 MCP Server 之类的方式,把我的工作流、待办事项、上下文全部拉进来。这才是真正的知识工作“组合”。

 

安全领域也是一样。一个安全工程师面对的是海量日志:把日志放进文件系统、用代码分析、生成仪表盘,这些都是 AI 能大幅放大的知识工作场景。

 

数字员工如何进入企业

 

Jason:那“数字员工”“数字同事”这种概念呢?是不是也在你们的规划里?

 

Satya:核心问题其实是“身份”。我们推出了 Agent 365,就是把今天给人用的身份体系、终端防护体系,扩展到 Agent 身上。

 

Jason:也就是说,你可以“克隆”一个我,让他在 HR 或市场部里工作?

 

Satya:没错。在 Office 体系里完全可以做到。这里有两种模式:一种是,每个知识工作者都拥有“无限个大脑”;另一种是,创造完全独立于你个人身份的 Agent。而身份这件事非常关键,权限、决策、责任追溯等全都依赖它。

 

Jason:说到底,就是搞清楚“谁对谁做了什么”。

 

Satya:正是如此。对任何组织来说,最重要的问题之一就是:工作是谁完成的、怎么完成的、来源是什么、能不能追溯,所以要么是“人 + 一堆 Agent”,由人来做宏委派、微观引导,要么就是一个完全独立的身份在运作。

 

Jason:过去几年,Microsoft 的员工数量基本没变,但收入多了 900 亿美元,利润还翻了一倍。你们也像 Alphabet、Meta 一样,削掉了不少中间管理层。这是因为自动化?还是以前人确实有点多?

 

Satya:你抓住了一个非常关键的问题。我认为,这是自 PC 普及以来,知识工作最大的结构性变化。想想 PC 之前,一家跨国公司怎么做预测?传真、内部备忘录满天飞,最后凑出一份结果。后来 PC 成了标配,Excel + Email,让流程和产出物全变了,今天正在发生同样级别的变化。

 

举个例子,在 LinkedIn,我们以前有产品经理、设计师、前端工程师、后端工程师,后来我们把前面这些角色合并、扩大职责范围,统一成“全栈构建者”。这是结构性的调整,它改变了工作本身,也改变了工作流。

 

Jason:沟通成本一下就下来了,速度自然更快,一个人就能“vibe coding”。

 

Satya:没错,而且 AI 产品本身也有一套全新的工作流:从评测、到科学建模,再到基础设施。评测和产品由新的“全栈型 PM / Builder”完成,系统工程师负责支撑后端科学和基础设施,这是一个全新的闭环,必须从组织结构上去适配。

 

当然,对 Microsoft 来说,我们不可能只活在未来。现在,我们要一边把 Windows 的热补丁做好、质量做到位;一边还要持续提升 Copilot 的评测体系和质量,这两件事都必须是第一优先级的。

 

“每十年换一批竞争对手”

 

Jason:这大概是你职业生涯里最具挑战性的阶段吧?过去 Microsoft 在很多领域是双寡头甚至垄断,但现在面对的竞争完全不一样。

 

Satya:确实非常激烈。但我一直觉得,每十年换一批竞争对手,其实是好事,它能让你保持“体能”。我 1992 年加入 Microsoft,那时最大的对手是 Novell;现在是 2026 年,环境完全不同。竞争很残酷,但从 GDP 占比来看,五年后科技产业一定更大,这不是一个零和游戏。

 

Jason:蛋糕在变大。

 

Satya:而且会大得多。整个技术栈对社会的影响会极其深远。最终的问题是 Microsoft 的品牌定位是什么?客户期待我们提供什么?有时候我们会误以为,所有客户对所有厂商的期待都是一样的,但真正重要的是弄清楚客户“希望从你这里得到什么”。这其实是 Peter Thiel 那个观点的另一种表达:不是逃避竞争,而是通过理解客户,找到你真正不可替代的位置。

 

David:这次在达沃斯,既有不少国家领导人,也有大量《财富》世界五百强公司的 CEO。昨晚晚宴上,有人问你一个问题:他们该如何看待 AI,怎样才能真正把 AI 用好。我记得你当时提到了“扩散(diffusion)”这个词,这一点和我最近参与的一些政策研究高度契合。能不能展开讲讲你的想法?

 

Satya:当然可以。事实上,你们一直在做一件非常重要的事,就是确保以美国为代表的技术栈,能在全球范围内被广泛采用、并且被信任。

 

回过头来看,技术本身只是起点,真正的价值来自于被大规模、深入地使用。我一直很喜欢一项研究,是 Diego Comin 做的,研究的是工业革命时期各国是如何实现领先的。结论其实很简单:那些把最新技术引入本国,并在此基础上做价值叠加的国家,最终跑得最快。说白了,不要重复造轮子,而是先用最先进的,再在上面持续创新。

 

这正是“扩散”的意义所在。像 AI 这样的通用型技术,关键在于能不能真正铺开。就拿美国来说,技术我们已经有了,但问题是:它有没有进入医疗?有没有进入金融?有没有进入所有行业?不只是大企业,也包括中小企业和公共部门。如果看不到这种广泛而密集的应用,就谈不上真正的成功。

 

现在我们正处在这样一个阶段:AI 正在更快地“扩散”。你们做的那些政策层面的工作其实非常关键。好消息是,技术已经成熟了,云计算和移动互联网这些“基础设施轨道”早就铺好了,这让 AI 的传播成为可能。现在真正的问题不在算力能不能拿到,而在于具体的应用场景是什么,以及组织如何管理随之而来的变化。

 

在达沃斯,还有一个常被提起的问题:发达国家之外,全球南方怎么办?我反而觉得这里蕴含着巨大的机会。在很多全球南方国家,公共部门在 GDP 中的占比非常高。想象一下,如果 AI 能显著提升政府把纳税人资金转化为公共服务的效率,哪怕只提升一点点,那可能就是几个百分点的 GDP 增长。

 

所以我非常乐观,我认为会形成一种强烈的拉动力,而美国也应该把我们已有的技术栈,推动在欧洲、亚洲、南美、非洲等地广泛落地。

 

David:我经常被问到一个问题:这场 AI 竞赛,怎么判断谁在赢?或者美国是不是领先全球?我给出的答案很直接:看市场份额。如果几年后我们放眼全球,看到美国公司的技术占据了绝大多数市场,那说明我们做对了;如果看到全球到处用的都是中国的芯片和模型,那可能就意味着我们输了。说到底,使用情况才是最真实的检验标准。

 

Satya:我同意。但你也在 Microsoft 工作过几年,应该记得 Bill Gates 对“平台”的理解。对我来说,除了市场份额,更重要的是生态效应。美国一直以来的优势,不只是本国公司的收入规模,而是围绕平台形成的完整生态。

 

我在 Microsoft 学到的一点是,每次去一个国家访问,最先看的不是我们卖了多少软件,而是围绕 Microsoft 平台,在当地创造了多少就业岗位。比如有多少渠道伙伴、多少 ISV、多少相关的 IT 从业者。我们有一整套指标,衡量一个国家的生态是如何围绕平台建立起来的。

 

这正是美国技术栈过去在全球,包括在中国,能够被广泛采用的原因:当地公司能在上面构建自己的产品和业务。这种事情还会再次发生。所以你们推动“扩散”的工作,本质上不是在抢蛋糕,而是在把蛋糕做大,增强对平台的信任,从而带来真正的经济机会。

 

David:你这么一说,我确实想起了一些往事。那还是十多年前,Yammer 被 Microsoft 收购,我们并入了 SharePoint 团队。当时产品经理们非常自豪的一点是:围绕 SharePoint 的生态收入,即非 Microsoft 的咨询公司、实施伙伴创造的收入,其规模是 Microsoft 自身软件收入的好几倍。Bill 也说过一句话:只有当平台之上的收入,显著超过平台自身的收入时,你才算真正拥有一个生态。所以,当我们谈“扩散”,希望美国保持领先地位,并不意味着这对世界其他地方是坏事。恰恰相反,其他国家和公司可以在这个平台之上创造出更大的价值。

 

Satya:完全同意。这一点非常关键。这不是“美国技术、美国收入”的问题,而是在用一个新平台在全球范围内创造机会。

 

我 90 年代做数据库产品时,和 SAP 有过深度合作。SQL Server 和 R/3 的结合,对双方都是巨大的成功。大家常提 Intel 和 Microsoft,但对我个人成长影响很深的一件事其实是和一家欧洲软件巨头的合作。放到今天也是一样,谁知道下一个伟大的 AI 应用会出现在哪里?我始终相信,即便基于美国的技术栈,世界各地都可能诞生顶级的科技公司。

 

与 OpenAI 合作背后:所有公司、应用会同时用多种模型

 

Jason:你不仅是技术领袖,也是一位非常出色的并购操盘手,这一点其实被外界低估了。你和 Sam Altman、OpenAI 的合作,被认为既高明又充满争议。有人说,这笔交易可能让 Microsoft 获得巨额回报,但也有人质疑:你是不是亲手培养了一个未来最强的竞争对手?尤其是考虑到 Microsoft 过去错过了移动互联网浪潮,你们为什么不自己做一个 Gemini、xAI 或 Claude?

 

Satya:我理解这种疑问。很多人问我:你们自己的基础模型在哪里?从知识产权角度说,我们确实拥有相关能力,但更重要的是,Microsoft 现在的战略有几个层面。

 

首先,我们要把“算力工厂”做好。Azure 是我们最大的业务之一,而随着 AI 的发展,它的市场空间会变得极其庞大,这要求我们在异构基础设施管理、软件调度和资源利用率上做到极致。

 

其次,是应用服务器层。未来,每个人都在构建 Agent,有强化学习环境、有评测体系,就像每一代平台都会有自己的应用服务器一样。我们现在在做的 Foundry,就是这个定位。

 

在这一层里,有一点已经非常清楚:任何应用、任何公司,最终都会同时使用多种模型。为什么不用呢,甚至在一个具体任务里,编排多个模型协同工作,效果往往比单一的前沿模型更好。我们在医疗领域做过一个“决策编排”的实践,仅仅通过给模型分配不同角色再进行协同,就能显著提升结果质量。

 

Jason:那是不是可以理解为,你其实看好开源模型,认为大模型本身会逐渐商品化,真正的价值不在这里?

 

Satya:我更愿意把它类比成数据库市场。最早大家觉得数据库就是 SQL,后来才发现并不是。关系型、文档型、NoSQL,各种数据库层出不穷,甚至出现了大量开源项目和围绕它们建立的公司。模型也会是类似的演进路径,会有闭源的前沿模型,也会有达到前沿水平的开源模型。

 

接下来一个非常重要的方向是:企业能否把自身的隐性知识,真正嵌入到自己掌控的模型权重中。有人问我未来会有多少模型,我的回答是:可能和世界上有多少家公司一样多。这听起来极端,但在我看来,这正是“知识经济”向“AI 经济”转变的方式。

 

Jason:那你有没有在 Windows 桌面上,悄悄推进一个本地运行的大模型?

 

Satya:其实已经在发生了,现在已经有完全驻留在本地、基于 NPU 和 GPU 的模型。高性能工作站正在回归,这本身就是一件非常有意思的事。

 

Jason: 明白了。所以 Microsoft 当然会重视 PC,这毕竟是你们的主场,有完整的桌面生态。

 

Satya:是的,本质上这是个商业问题。我们一直认为“形态”非常重要。我常开玩笑说,我的职业生涯是从命令行开始的,说不定最后也会回到命令行。但不管怎样,形态一直在演进。

 

Jason: 你当年起步时用的是 Sun 那种最早的工作站,价格五千到一万美元。你能想象有一天,你会向客户推荐一台一万到两万美元的桌面机,里面内置 LLM 和强悍硬件吗?

 

Satya:完全有可能。你可以插一张 DGX 卡,做出一台非常强的机器。其实在模型架构上,我们可能只差一次关键调整就能实现某种分布式模型架构,比如真正能自我调度的 MoE 架构。这类突破会彻底改变“混合 AI”该是什么样子。

 

但不管怎样,我们非常明确:PC 必须成为本地模型的最佳载体。本地模型可以承担大量 prompt 处理,再按需调用云端能力。这里面还有大量工作空间,这也是我们正在坚定推进的方向。

 

David: 云与本地的协同已经证明了,能直接访问本地文件系统,本身就非常有价值。这让我想到 Yammer。很多人可能不知道 Yammer 当年最大的特点,是用消费级增长打法去攻企业软件。站在今天去看企业 AI 的采用,你觉得未来一年会怎么“扩散”?现在好像正处在一个关键点:会是自上而下,由 CEO 拍板、搞战略转型、走 RFP;还是自下而上,由一批 AI 原生员工先用起来,把工具带进工作中,做出惊人的成果?

 

Satya:说实话,我觉得两种都会发生。自上而下的原因很简单:在客服、供应链、HR 自助这些场景里,AI 的 ROI 非常清晰,IT 和 CXO 很容易拍板,这也是目前最先落地的一波真实 AI 应用。

 

但最终真正改变组织的,一定是自下而上的力量。回看 PC 的历史也是这样:最早是律师把 Word 带进公司、财务把 Excel 带进来,后来有了邮件,最后才变成标配。现在正在重演这个过程。比如说 Agent,现在几乎所有人都在做 Agent,本质是在重构工作流,把大量重复、枯燥的事情自动化掉,这正是自下而上转型的起点。

 

说实话,我最兴奋的也是这种变化。以 Microsoft 为例,我们在全球管理着五百多个光纤运营点,尤其在亚洲。我自己以前都没意识到,这些所谓的 DevOps,其实很大一部分是物理资产:光纤会被挖断、设备会出故障。所谓 DevOps,很多时候就是在不停地发邮件问“这张光纤卡怎么了”“怎么修”。

 

现在负责全球网络的同事,已经构建了一批“数字员工”,本质就是 Agent 在自动处理这些 DevOps 工作。这完全是自下而上的:工具已经在那里了,我就用它来做自动化,减少重复劳动,提高效率和质量。

 

而这些能力最终能不能规模化,关键不在“学会没有”,而在“用不用”。所谓技能提升并不神秘,就是在实际使用中完成的。工具扩散、工具被真正用起来,这才是最重要的事情。

 

“我们在尝试新的学徒制模式”

 

Jason: 正因为如此,现在用这些工具去赋能现有员工,比招人、培养新人要容易得多。站在今天看,如果 Microsoft 规模不变,三、四十年后谁会接我的工作?你们是典型的技术优先公司,理论上已经没有太多理由继续增加员工数量,这几年你们也基本没扩张,只是在内部结构上做了调整。

 

那你怎么看下一代?对那些现在还没拿到 Microsoft offer 的应届生,你会给什么建议?以前你花了很多精力去培养这群人,但现在好像没那么“奢侈”了。

 

Satya:这是个好问题。现在确实有争论:职业早期会发生什么变化、校园招聘还重要吗?我依然坚定相信校园招聘,因为 AI 会彻底改变一个人掌握代码库、建立熟练度的速度。

 

过去,新人进团队的爬坡期很长;现在不一样了,有文档、有技能库,还可以直接问 Agent,本质上就像身边有一个极其强大的导师帮你快速上手代码。换句话说,应届生的生产力曲线会比以往陡得多。

 

我们也在尝试新的学徒制模式:让一位资深 IC 工程师带一组应届生一起工作,因为这本身就是一种全新的工作方式。以前大家进 Microsoft 后会去读 Dave Cutler 的代码,理解什么是顶级工程实践;而现在,顶级实践更多体现在十倍、百倍工程师是如何借助 AI 打造高质量产品的。对于这些经验,新一代毕业生会学得更快。

 

对 Microsoft 这样的公司来说,这是好事。毕竟只要人类还没解决“永生”问题,我们就需要新人进入职场、在 Microsoft 成长。所以我们依然会积极投入,只是会确保岗位的边界和内容,让其既符合现有员工的期望,也符合新入职者的追求。

 

参考链接:

https://www.youtube.com/watch?v=5nCbHsCG334

亚马逊首席执行官安迪・贾西(Andy Jassy)设想,在竞争对手纷纷推出 AI 购物代理的背景下,人工智能将通过复制实体店的 “惊喜发现感” 来改变零售业。亚马逊正在谈判向 OpenAI 投资约 100 亿美元,并与芯片使用量挂钩;与此同时,亚马逊也在开发 “帮我买”(Buy For Me)等内部工具,以维持其主导地位。这一战略转向旨在将创新与合作伙伴关系结合起来,以在未来的 AI 商务领域保持领先。

亚马逊的贾西在 AI 商务大战中前行:在购物代理竞争中押注 OpenAI

在达沃斯世界经济论坛的繁忙大厅里,亚马逊公司首席执行官安迪・贾西最近分享了他对零售业未来的愿景,强调人工智能可能会彻底改变消费者的购物方式。在一场小组讨论中,贾西指出,AI 有潜力弥合线上和线下购物体验之间的差距,并表示先进技术可能很快就能复制在实体店闲逛时那种 “偶然发现好物” 的感觉。
“在我看来,实体零售目前仍有一些优势的地方,是你可以走进店里,不知道自己想要什么,提出问题,不断细化问题,然后有人会给你推荐一些你甚至不知道存在的东西。” 据《The Information》报道,贾西这样说道。
这番评论发表之际,这家电商巨头正面临来自 OpenAI、谷歌和微软等竞争对手开发的 AI 购物代理的激烈竞争。这些工具允许用户直接在聊天界面内完成购买,对亚马逊在在线零售领域的主导地位构成潜在威胁。贾西的言论凸显了亚马逊的战略转向:它不仅在捍卫自己的地盘,还在积极探索合作伙伴关系,以在这个不断演变的领域保持领先。
最近的报道显示,亚马逊正就向 OpenAI 投资约 100 亿美元 进行深入谈判,这笔交易可能使这家 AI 公司的估值超过 5000 亿美元。据路透社 2025 年末的一篇文章详细报道,这笔潜在交易还包括 OpenAI 承诺使用亚马逊的 Trainium AI 芯片,这标志着双方技术联盟的深化。

AI 发展中的战略联盟

贾西对 AI 在提升购物体验方面作用的乐观态度,与更广泛的行业趋势一致。分析师指出,2026 年将是 AI 购物代理的关键一年,消费者将越来越多地为了便利和个性化而测试这些工具。《Modern Retail》的一篇文章指出,零售商和科技巨头正竞相完善这些代理,并押注它们会被广泛采用。
亚马逊面临的困境十分严峻:要么抵制这些可能绕过其平台的外部代理,要么整合类似功能以保留用户忠诚度。根据 CNBC 的分析,OpenAI 的 “即时结账”(Instant Checkout)和 Perplexity 的 “即时购买”(Instant Buy)等创新正在重塑交易方式,有可能将流量从传统电商网站分流。
作为回应,亚马逊一直在测试自己的功能,例如 “帮我买”(Buy For Me)选项,该功能允许用户在不离开亚马逊生态系统的情况下从第三方网站购买商品。行业观察人士在 X 上的帖子指出,这是一种防御策略,有用户注意到 AI 代理现在可以在一次对话中完成从产品研究到结账的所有操作,凸显了竞争压力。

与科技巨头的正面交锋

AI 与商务的融合,使主要参与者走上了直接竞争的道路。《The Information》的一篇报道描述了谷歌、亚马逊和 OpenAI 各自如何追求不同的战略,从专有代理到协作商务模式。这场竞争还延伸到了微软,微软最近推出了 “Copilot Checkout”,允许在其 AI 聊天机器人中无缝完成购买。
GeekWire 报道了微软进入这一领域的消息,并强调其企业关系可能使其相对于亚马逊和其他公司具有优势。“微软正在推出一项新的‘Copilot Checkout’功能,让购物者可以直接在其 AI 聊天机器人内完成购买,”GeekWire 的文章指出,并强调了在 AI 驱动的商务中对零售商关系的押注。
贾西在达沃斯的亮相中也谈到了围绕 AI 投资的泡沫担忧。《The Register》的一篇最新报道援引他的话称,他承认存在炒作,但重申亚马逊致力于从中挖掘价值,即使这些交易看起来有些 “循环”。

OpenAI 合作关系动态

对 OpenAI 潜在的 100 亿美元投资不仅仅是财务上的,更是为了确保技术优势。正如《Fortune》一篇文章所引用的专家观点,这被视为亚马逊在 “下一盘大棋”。分析师查尔斯・菲茨杰拉德(Charles Fitzgerald)表示:“如果 OpenAI 中了‘彩票’,那么他们就有足够的钱来支付这笔费用。” 他指的是芯片使用协议。
这种关系建立在亚马逊现有的 AI 计划之上,包括其 AGI 团队正努力超越 Anthropic 等合作伙伴的模型。2024 年 X 上的历史帖子回顾了亚马逊对 Anthropic 的投资,但此次转向 OpenAI 表明,在 OpenAI 自身内部发生变化的背景下,亚马逊正在采取多元化战略。
《印度时报》最近的消息详细报道了 OpenAI 从其前首席技术官领导的初创公司挖走人才的情况,这表明 OpenAI 内部存在动荡,而亚马逊可能通过投资加以利用。

正在重塑零售互动的创新

除了投资之外,亚马逊还在将 AI 深度嵌入其运营中。贾西 2025 年在 X 上的帖子宣传了新的智能体式 AI(agentic AI)功能,这些功能可以通过分析数据和自动化任务来帮助卖家扩展业务。这种内部关注与外部合作伙伴关系相辅相成,旨在创造无缝的购物旅程。
《Wired》探讨了一些开发者不愿让 AI 代理作为用户互动中介的担忧,正如一篇 WIRED 文章所讨论的那样,AI 正成为下一个平台。然而,亚马逊仍在推进,AI 已用于预测需求、优化配送路线,甚至在仓库中提供协助,正如 2023 年的 X 帖子所展示的那样。
X 上的行业情绪反映了对这些进步的兴奋。有帖子称,像亚马逊这样的数字商务平台正将 AI 转变为核心基础设施,触及从推荐到配送的各个方面。

挑战与消费者采用

尽管热情高涨,但挑战依然存在。贾西在达沃斯的评论提到了实体零售仍然持有的优势,这意味着 AI 必须不断发展,才能匹配那种探索的乐趣。分析师警告称,2026 年消费者对 AI 代理的接受程度将是真正的考验,正如《Modern Retail》的分析所指出的那样。
此外,潜在的 OpenAI 交易引发了有关反垄断审查的问题,考虑到投资规模和市场影响力。路透社关于谈判的报道强调了估值方面的影响,这可能会重塑 AI 融资动态。
a16z 等风险投资公司在 X 上的帖子认为,AI 正在将在线购物模式从 “量” 转向 “质” 和个性化,亚马逊必须谨慎应对这一转变,以免被边缘化。

AI 商务整合的未来轨迹

展望未来,亚马逊的战略似乎是多方面的:投资尖端 AI 公司、开发内部工具,并适应新兴的消费者行为。贾西早些时候在 2023 年 X 帖子中对 “亚马逊在 AI 方面落后” 的说法提出质疑,这表明他一贯强调实质而非炒作。
《The Information》详细描述了亚马逊与谷歌和 OpenAI 的正面竞争,这表明可能会出现共享商务模式,但专有优势将决定胜负。正如 GeekWire 所指出的,微软的 Copilot 举措又增加了一层竞争,它将利用其企业关系。
最终,随着 AI 设备的普及,《Wired》指出开发者存在犹豫,但亚马逊的规模可能使其处于领先地位。贾西在达沃斯提出的愿景强调了 “细化问题” 和 “发现”,指向一个未来:AI 代理将充当虚拟商店助理,将在线效率与线下的惊喜发现感完美结合。

在投资与内部增长之间取得平衡

亚马逊对 OpenAI 的潜在注资并非孤立存在,而是更广泛战略推进的一部分。《Fortune》的专家强调了这种战略耐心,亚马逊押注 OpenAI 的成功将推动芯片的采用。
内部开发项目,例如 2024 年 X 帖子中提到的 Olympus LLM,表明亚马逊在合作的同时也致力于自力更生。这种双轨方式可以减轻 OpenAI 危机带来的风险,正如《印度时报》所报道的那样。
X 用户最近对亚马逊的 “帮我买” 功能表示赞赏,认为它是对 OpenAI 即时结账的反击,有助于维持生态系统的控制权。

竞争压力与市场反应

根据《Modern Retail》的说法,AI 购物大战正在升温,2026 年将是关键时期。正如 CNBC 所描述的那样,亚马逊面临的困境是:与这些代理对抗,还是加入它们。
贾西在《The Register》中对 “泡沫” 的承认反映了他在乐观中的现实态度。“当然这是一个泡沫,而且这些交易是循环的 —— 但这并不意味着亚马逊不会努力从中榨取价值。” 他说。
X 上的情绪强调了 AI 在电商基础设施中的作用,从亚马逊到沃尔玛和 Shopify 等竞争对手,正如一篇帖子所对比的那样。

不断演变的消费者期望

消费者可能很快就会期望 AI 能够无缝处理复杂的购物任务。《The Information》对达沃斯的报道援引贾西的话,强调实体零售的优势,这正推动亚马逊在数字领域进行创新。
《Wired》关于 AI 平台的文章警告称存在开发者的抵制,但亚马逊的整合可能会促进采用。
正如 X 上的帖子所暗示的那样,AI 正在从头开始重塑购物,重点放在用户体验和价格优化上 —— 而这些正是亚马逊擅长的领域。

亚马逊的战略展望

在这种高风险环境下,亚马逊与 OpenAI 的谈判代表着一场大胆的赌注。路透社详细报道了 100 亿美元的数字,并将其与芯片承诺挂钩。
《Fortune》分析师认为,这是一种长期定位,将 OpenAI 视为 “AI 领域的舒洁(Kleenex)”。
贾西的领导能力在他关于卖家工具的 X 帖子中显而易见,这使亚马逊能够将 AI 创新与零售实力结合起来,从而在竞争中脱颖而出。
正如《The Information》所概述的那样,前进的道路包括在竞争中导航,确保亚马逊在 AI 商务的演变过程中保持核心地位。

编者按: 英伟达财报的营收神话是否掩盖了其现金流恶化的现实?而在“循环融资”的质疑声中,OpenAI 与甲骨文等关键客户的供应链“去英伟达化”浪潮,又将如何重塑 AI 硬件的竞争格局?

我们今天为大家带来的这篇文章,作者的观点是:英伟达目前的高速增长依赖于激进的库存策略和宽松的信用条款,但其最大客户正通过定制芯片和直接采购关键组件来构建独立的供应链,这导致双方关系正从深度捆绑走向潜在的激烈竞争。

作者 | Philippe Oger

编译 | 岳扬

过去 48 小时,我完全沉浸在对英伟达 2026 财年第三季度财报[1]的深度研究中。如果你只看新闻标题,一切看起来都完美无缺:营收同比增长 62 %,达到 570 亿美元,黄仁勋还在大谈“AI 的良性循环”。

但我想弄清楚光鲜数据下的真实情况,于是深挖了资产负债表,并将其与围绕 OpenAI 和 Oracle 的所有新闻进行了交叉验证。 我并不是华尔街的专业分析师,但即便仅凭自己梳理线索(并借助了 Gemini 的帮助),我也开始看到这个所谓的“AI 联盟”出现了一些裂痕。就在英伟达创下业绩纪录的同时,他们最大的客户似乎正在悄悄武装自己,准备另起炉灶。

以下是我对硬件市场、OpenAI 与英伟达之间“亦敌亦友”的关系,以及包括迈克尔·贝瑞(Michael Burry)在内大家都在讨论的“循环融资(circular financing)”理论的一些看法。

01 英伟达财报:完美表象下的隐忧

表面看来,英伟达无疑是 AI 时代的绝对王者 —— 数据中心业务已占据公司总营收近九成,这一事实无可辩驳。然而,当我深入研读财报细节时,发现了三处值得警惕的“红色信号”

  • 现金流之谜:英伟达公布的净利润高达 319 亿美元,但我查阅现金流量表时发现,其经营活动产生的现金流仅为 238 亿美元。这意味着有 80 亿美元的利润尚未立即转化为现金。
  • 库存激增:我注意到,今年库存几乎翻倍,达到 198 亿美元。管理层解释称这是为“Blackwell”发布做准备,但在我看来,持有大约 120 天的库存量,会带来巨大的资金占用压力。
  • 应收账款周期拉长:我计算了其应收账款周转天数(DSO),发现已悄然攀升至约 53 天。在营收飙升的同时,英伟达却要等待近两个月才能回款,这暗示他们可能正在向企业客户提供极为宽松的信用条款,以维持增长飞轮的运转。

我的个人判断?英伟达正通过透支现金流来囤积库存,将全部赌注押在 Blackwell 架构[2]能在第四季度被市场瞬间消化。

02 拆解“资金空转”传闻的虚实

我想说清楚一点:接下来这部分内容并不是我最先发现的。最近财经新闻到处都在讨论这件事,而且如果你关注迈克尔·巴里(就是那位电影《大空头》里的“大空头”原型人物),你很可能已经看到他发推文警告所谓的“循环融资”和可疑的收入确认(Revenue Recognition)[3]行为。

我尝试自行理清这其中的关系,看看大家究竟在争论什么。巴里最近分享了一张图表,把这一系列交易描绘成一张交易“关系网”,其结构大致如下:

  • 环节一:英伟达承诺向 OpenAI 投资数十亿美元(这属于已被广泛报道的“千亿美元投资路线图”中的一部分)
  • 环节二:OpenAI 与甲骨文(Oracle)签署了一份高达 3000 亿美元的巨额云服务合同(即“星门计划”,Project Stargate),用于托管其人工智能模型。
  • 环节三:为履行该合约,甲骨文随即向英伟达下达价值 400 亿美元的 GB200 GPU 采购订单。

巴里的核心论点(也是据传美国司法部等监管机构介入调查的原因[4])在于:这套模式形同“资金空转”。这引发了一个尖锐的问题:如果英伟达停止向 OpenAI 投资,OpenAI 还有足够现金去和甲骨文(Oracle)签下那笔大单吗?而甲骨文又是否还会采购那些芯片? 如果答案是“不会”,那么部分营收数据的稳固性可能远不如表面看来那样坚实。

03 OpenAI 正在采取行动降低对英伟达的依赖

我近期一直在关注的另一个重大转变,是 OpenAI 的战略转向。他们曾是英伟达最耀眼的“模范客户”,如今却越来越像一个潜在的竞争对手。一方面,他们仍与 NVIDIA 保持紧密合作 —— 部署 10 吉瓦(gigawatts)的基础设施用于训练 GPT-6;但另一方面,他们似乎正在构建一条能彻底摆脱黄仁勋(Jensen Huang)掌控的供应链。

如果你有所留意,相关迹象其实已经相当明显。 “星门计划”(Project Stargate) 不仅仅是个数据中心,更是一项包含定制硬件在内的庞大基础设施计划。据多家媒体报道(例如此处[5]、此处[6]、此处[7],并在 Hacker News 上引发了激烈的讨论[8]),OpenAI 已直接从三星和 SK 海力士(全球两大 HBM 内存供应商)采购 DRAM 晶圆,绕开了英伟达的供应链。

此外,人才流向也透露出关键信号:OpenAI 已从数个行业巨头处挖走多名芯片人才,包括 2023 年招揽了谷歌前 TPU 负责人 Richard Ho,以及近期从苹果挖走的约 40 名硬件工程师。

结合 OpenAI 与博通(Broadcom)的合作[9],我推测其策略是:用英伟达 GPU 构建智能模型,但最终在自家的定制芯片上运行推理任务 —— 以此大幅削减高昂的运营成本,或押注类似谷歌 Edge TPU 的专用芯片(NPU)来处理推理负载。

但关键问题来了:OpenAI 打算用谁的钱来支持这项事业?而英伟达对其未来规划又究竟有多大影响力?

而且,所谓“英伟达向 OpenAI 投资 1000 亿美元”的说法,至今尚未得到官方证实(如此处[10]所述)。

04 甲骨文一个有趣的思路:收购 Groq

眼下所有人都在讨论推理成本问题(Inference costs) —— 也就是实际运行 ChatGPT 或其他大语言模型(LLM)的花销,远比训练它们更昂贵。我最近在关注 Groq 这家初创公司,他们明确宣称在推理任务上比英伟达更快、更便宜。其创始人乔纳森·罗斯(Jonathan Ross)[11]曾是谷歌 TPU 团队的负责人,甚至可以说是 TPU 概念的最初提出者。

但还有一层情况,我认为被大多数人忽视了:OpenAI 直接采购晶圆所引发的 HBM 短缺问题。

据我所知,目前英伟达最大的瓶颈之一就是 HBM(高带宽内存)。 HBM 由专业内存代工厂生产,而这些产线早已完全超负荷运转。然而,Groq 的架构依赖的是 SRAM(静态随机存储器)。 由于 SRAM 通常是在逻辑制程代工厂(比如台积电 TSMC)中与处理器本身一同制造的,理论上它不会遭遇与 HBM 相同的供应链紧张问题。

综合这些因素,我觉得甲骨文真该认真考虑一下收购 Groq。拿下 Groq 不仅意味着获得更快的芯片,更关键的是 —— 当其他芯片全都售罄时,Groq 的芯片可能仍然有货。这本质上是一种供应链对冲(supply chain hedge)。

对甲骨文的最大客户 OpenAI 而言,这也将带来巨大的优势:更快、更便宜的推理能力。

再结合此前的传闻:甲骨文出租英伟达芯片的利润率极其微薄[12],据传低至 14%,那这笔收购就显得更加合理。通过控股 Groq,甲骨文不仅能摆脱“英伟达税”(NVIDIA Tax),改善自身利润空间,还能彻底绕过 HBM 短缺的困局。

据 Groq 在 2025 年 9 月的最近一轮融资披露[13],其估值约为 69 亿美元。即便支付溢价,以甲骨文的财力也完全有能力完成这笔收购。

但问题是:英伟达会允许这事发生吗?

如果答案是否定的,那又说明了什么?是否意味着当前这套“循环融资(circular financing)”体系中存在某种利益交换 —— 比如,英伟达承诺向 OpenAI 投资 1000 亿美元,条件是甲骨文必须只能使用英伟达芯片?

05 Final Thoughts

进入 2026 年,观察英伟达、OpenAI 与甲骨文之间的博弈,这场三方角力正陷入彼此钳制的僵局。我无从得知英伟达是否事先知晓 OpenAI 与内存厂商之间的晶圆供应协议,亦或其中存在任何合谋?英伟达是否正在极力维持自己在“星门计划”(Stargate)中训练和推理环节的独家地位?而 OpenAI 又到底打算打造什么样的芯片?是类似 TPU/LPU 的架构?还是更偏向 Edge TPU 那样的边缘推理芯片?

迈克尔·巴里(Michael Burry)正在全面做空这套体系[14]。

至于我,只是个读财报的普通人,无力揣测市场走向。但我非常确定一点:AI 硬件市场比以往任何时候都更炽热,未来几个季度的风云变幻必将精彩绝伦。

免责声明:我偶尔会发表些真知灼见,但更多时候说的都是蠢话。阅读本文时请务必谨记这一点。

END

本期互动内容 🍻

❓如果“循环融资”属实,谁最可能成为这个链条中最先断裂的一环?

文中链接

[1]https://nvidianews.nvidia.com/

[2]https://www.nvidia.com/en-us/data-center/technologies/blackwe...

[3]https://www.investing.com/news/stock-market-news/michael-burr...

[4]https://m.economictimes.com/news/international/us/nvidia-reje...

[5]https://openai.com/index/samsung-and-sk-join-stargate/

[6]https://www.asiafinancial.com/samsung-sk-hynix-building-starg...

[7]https://www.kedglobal.com/artificial-intelligence/newsView/ke...

[8]https://news.ycombinator.com/item?id=46169224#46170844

[9]https://openai.com/index/openai-and-broadcom-announce-strateg...

[10]https://fortune.com/2025/12/02/nvidia-openai-deal-not-signed-...

[11]https://www.linkedin.com/in/ross-jonathan/

[12]https://www.fool.com/investing/2025/12/02/michael-burry-just-...

[13]https://groq.com/newsroom/groq-raises-750-million-as-inferenc...

[14]https://www.techradar.com/pro/security/could-the-ai-bubble-be...

本文经原作者授权,由Baihai IDP编译。如需转载译文,请联系获取授权。

原文链接:

https://philippeoger.com/pages/deep-dive-into-nvidias-virtuou...

近日,OpenAI 在其官方网站及官方社交媒体公告中表示,公司计划在“未来几周内”开始在 ChatGPT 对话界面中测试广告投放,这些广告将首先面向美国地区的免费版用户以及新推出的低价订阅层级“ChatGPT Go”用户。

 

广告内容的展示形式预计主要是在 ChatGPT 生成的回答底部以清晰标注的独立模块形式出现,与 AI 生成内容严格区分。

OpenAI 强调,广告不会影响 ChatGPT 的回答逻辑,也不会向广告商分享用户对话内容。付费订阅用户(如 Plus、Pro、Business 及 Enterprise 层级)仍将享受无广告体验。

 

据官方发布内容及多家外媒消息,OpenAI 此举是为了进一步拓展营收来源,以缓解高昂的研发与基础设施支出压力,同时扩大服务的可持续性。

 

公司管理层表示,即便公司业务规模庞大,依靠订阅收入仍难覆盖巨额算力成本,而广告收入是补充营收的一种必要尝试。OpenAI 同时承诺,广告不会改变 AI 应答过程,并且将在敏感话题如健康、政治等领域避免投放广告。

 

OpenAI 此举引发了社区热议,但批评声音居多。

 

在 Hacker News 上,有用户表示,由于他们加了广告,很多用户已经转向了 Gemini,所以长远来看这种行为是得不偿失。

 

“OpenAI 广告的一个问题是,用户已经开始转向 Gemeni,而 Gemeni 并不投放广告。

 

ChatGPT 大多数情况下也比 Gemeni 差(或许如此),而且没有像 Gemeni 那样严格的速率限制。因此,他们已经开始流失用户,并且产品体验也比竞争对手更糟糕。

 

OpenAI 当然能从广告中赚到一些钱,但这能弥补他们巨额的亏损吗?我觉得不太可能。他们真的需要像微软那样,被一位财力雄厚的“金主”收购,才能玩转这种游戏。”

 

还有用户表示即使他们加入了广告,也不会向谷歌和 Facebook 那样赚大钱,只是赚一些小钱罢了。该用户评价道:

 

“就我所了解的广告市场而言,像谷歌和 Facebook 这样的公司之所以能赚得盆满钵满,主要是因为它们在广告市场的垂直整合中占据了绝对优势。而 OpenAI 整合广告的方式在我看来,似乎只是想分得蛋糕里最小的一块——一个投放广告的地方——这意味着,我估计他们的用户收入更接近于报纸网站,而不是最大的社交媒体网站,或者更接近于推特或 Tumblr 这类从未实现过巨额盈利的公司。”

 

明知加广告会被骂,OpenAI 为什么还要这么做?那就要从 OpenAI 的财务状况说起。 

营收增长 10 倍,但算力投入扩大 9.5 倍

 

OpenAI 的财务状况与算力投入呈现出高度协同的增长态势,过去三年,二者均实现了累计十倍左右的扩张,印证了“算力决定营收上限”的核心逻辑。这种强关联不仅是业务发展的结果,更成为 OpenAI 规划未来投入、平衡供需关系的重要依据。

 

在 OpenAI 最新一期博客中,公司首席财务官 Sarah Friar 透露了 OpenAI 的财务细节。

 

从算力投入来看,OpenAI 的扩张速度堪称惊人。

 

  • 2023 年,其算力规模为 0.2 吉瓦(GW);

  • 2024 年,迅速提升至 0.6 吉瓦;

  • 2025 年,进一步增至约 1.9 吉瓦,三年累计扩大约 9.5 倍。

 

为保障未来算力供应,Sarah Friar 称 OpenAI 已与微软、英伟达、AMD、甲骨文等企业签署数千亿美元的合作协议,同时从单一供应商转向多云、多芯片的多元化布局,在高端训练任务中采用最新硬件,在大规模推理场景中使用低成本基础设施,平衡效率与开支。

 

值得注意的是,算力投入存在显著的时间差,当前的投入需提前规划至 2028~2030 年的需求,这也意味着 OpenAI 需要稳定的长期收入来覆盖前置成本。

 

营收方面,OpenAI 同步实现了三倍速年度增长,与算力扩张节奏高度匹配。

 

2023 年,其收入达到 20 亿美元,2024 年增至 60 亿美元,2025 年预计突破 200 亿美元,三年累计增长约十倍。

 

这种增长并非依赖单一业务,而是构建了多元化的收入结构:一是订阅收入,涵盖个人用户的 ChatGPT Go、Plus、Pro 档位及企业订阅服务,满足不同层级用户需求;二是 API 服务收入,为开发者和企业提供模型调用能力,支出与交付成果直接挂钩;三是广告与电商收入,依托免费用户流量开辟新增长曲线;未来还将探索授权许可、知识产权合作、结果导向定价等模式,进一步丰富收入来源。

 

从运营效率看,OpenAI 的算力投入与营收的强相关性,验证了其商业模式的可行性。但当前仍面临算力缺口的核心挑战——由于算力不足,诸多潜在产品与功能无法落地,尚未充分释放价格弹性杠杆

 

这也解释了为何 OpenAI 持续加码算力投资,同时通过广告等业务拓宽收入渠道,本质上是为了打破算力瓶颈,释放更多商业价值。

加入广告,也会坚守三大原则

 

从成本端看,算力是 OpenAI 发展的核心命脉,且需求近乎无限。但 Sarah Friar 在博客中表示,即便在模型中加入广告,也会“死守”三大底线。他表示:

 

“大家普遍会疑惑,广告会对产品本身和公司运营产生怎样的影响?要回答这个问题,我们可以从当前的用户结构说起:如今,我们消费端平台上 95% 的用户都在使用免费版本。这恰恰契合了我们的使命 —— 研发通用人工智能是为了造福全人类,而非仅仅服务于有能力付费的群体。因此,保障用户的访问权至关重要。

 

从广告业务的角度出发,我认为有三点原则必须坚守。第一,我们要让所有人都清楚:模型给出的永远是它能提供的最佳答案,而非付费推广的结果。很多其他平台正是在这一点上栽了跟头,导致用户无法判断看到的内容是付费广告还是真实的最优推荐。而我们的核心准则就是,模型始终以提供最优答案为导向。

 

第二,广告本身可以具备很高的实用价值我们会明确标注广告内容,让用户一目了然。举个例子,如果用户搜索 “圣地亚哥周末短途旅行”,那么一条爱彼迎的广告可能会非常有帮助。用户甚至可能愿意在 ChatGPT 的对话场景中,与广告商展开深度交流 —— 前提是他们清楚这是广告环节。这正是我们需要创新的方向,要打造出与平台生态深度融合的广告形式,而非简单地把传统的横幅广告生搬硬套过来。

 

第三,也是最后一点,我们必须保留无广告的服务层级,让用户拥有选择权和控制权。同时,我们对用户数据的保护始终保持高度谨慎。此前推出医疗健康功能时,我们就明确告知用户,相关数据会被隔离存储,不会用于模型训练。信任是 OpenAI 的立足之本,即便在广告业务上,我们也会坚守这些原则。”

 

Sarah Friar 还表示,其实不只是 OpenAI,未来,消费者很可能会订阅多款人工智能服务,就像现在大多数人都会订阅不止一个流媒体平台一样,这一消费行为模式可以作为很好的参考。不同的人会根据自身需求做出不同选择,包括免费选项 —— 毕竟也有广告支持的免费流媒体服务。

 

而且即便是同一项服务,也会同时提供付费版和免费版两种选择,未来的市场格局会呈现出丰富的多样性。不过,用户切换不同平台时也会面临一个问题 —— 迁移成本。

 

Sarah Friar 还表示模型的记忆功能也是值得探讨的问题。他还进一步表示 OpenAI 不会垄断整个市场:

 

“未来的模型是会实现跨平台统一记忆,还是会分平台独立记忆?其实即便是基于同一个模型,不同服务商也会推出各具特色的服务,在功能取舍上各有侧重。哪怕是依托 OpenAI 模型的服务,也有很多不同的开发者在提供差异化产品,这也是我所理解的 ‘多平台使用’ 的含义。当然,我并不认为 OpenAI 会垄断整个市场。”

 

为维持算力与营收的同步增长,OpenAI 需要持续投入数千亿美元用于基础设施建设与合作伙伴拓展,而单一的订阅制模式难以支撑如此庞大的资金需求。

 

广告业务的引入,能够借助免费用户的流量规模,开辟新的收入来源,为算力投入提供稳定的资金补充,形成“算力支撑业务、业务反哺算力”的循环。

 

此外,广告业务的布局也与 OpenAI 的长期战略相契合。在 ChatGPT 月活用户突破 8 亿且仍有巨大增长空间的背景下,广告成为连接免费用户与商业价值的桥梁。

 

据业内消息,OpenAI 预计 2026 年通过广告获得数十亿美元级收入,未来将逐步放大这一收入来源,与订阅、API 服务等形成互补,降低单一模式的经营风险。

OpenAI 缺钱了?

 

既有巨额的算力成本支出,又有逐年翻倍的营收进账,那 OpenAI 到底是不是真的缺钱了?

 

近日,《纽约时报》的一位专栏作家却做出了一个明确的预测:OpenAI 将在 18 个月内因其在人工智能领域的投入而破产。

 

该作家表示,根据去年的一份外部报告,OpenAI 预计在 2025 年将烧掉 80 亿美元,到 2028 年将烧掉 400 亿美元。鉴于该公司据报道预计到 2030 年实现盈利,不难计算出其中的利害关系。

 

Altman 的风险投资计划在数据中心领域投入 1.4万亿 美元。正如外交关系委员会经济学家 Mallaby 所指出的,即便 OpenAI 重新考虑那些受盲目乐观影响的承诺,并“用其估值过高的股票为其他投资买单”,仍然存在巨大的资金缺口。

 

Mallaby 并非唯一持此观点的人,贝恩公司去年发布的报告显示,即便在最乐观的预期下,该行业也至少存在 8000 亿美元的资金缺口。

 

这位金融专家巧妙地分析了这种情况,他概括地指出,问题的关键不在于终端用户人工智能是否会在技术上得到普及,而在于开发人工智能在中长期内是否具有经济意义。

 

分析师指出,理论上,投资者应该“弥合一项伟大技术出现与最终盈利之间的差距”,但实际上,许多人工智能公司烧钱的速度似乎远远超过了其盈利能力。Mallaby 指出,鉴于微软或 Meta 等“传统”公司在人工智能出现之前就已经拥有盈利业务,并且(实际上)有能力等待必要的时期,直到人工智能最终带来收益,因此,这些新来者的处境比它们要糟糕得多

 

据他所说,大多数人都在使用免费服务,一旦他们常用的 AI 模型添加了广告或使用限制,他们就会毫不犹豫地转向竞争对手。目前各种任务都有无数的选择,也证实了这一点。

 

不过,他认为这对人工智能提供商来说只是暂时的难题,随着智能人工智能越来越深入人们的日常生活,转换将会变得更加困难,因为 AI 模型最终应该能够掌握你所有的购物偏好、愿望和情感特征——甚至可能比你本人做得更好。

 

Mallaby 确实赞扬了 OpenAI 首席执行官 Sam Altman 的“吸金能力”,他成功筹集了 400 亿美元的投资,超过了历史上任何一轮私募融资的规模——甚至超过了沙特阿美 300 亿美元的融资额。不同之处在于,沙特阿美和其他一些上市企业拥有成熟的商业模式和盈利能力,而 OpenAI 目前这两点都不具备。

 

人工智能金融这条衔尾蛇看起来确实像是要吞噬自己的尾巴,但也有人认为它只会失去较新的部分。如果人工智能市场失去一个或多个开创者,那将颇具讽刺意味。

参考链接:

https://www.tomshardware.com/tech-industry/big-tech/openai-could-reportedly-run-out-of-cash-by-mid-2027-nyt-analyst-paints-grim-picture-after-examining-companys-finances

https://news.ycombinator.com/item?id=46663341

在针对 OpenAI 和微软的法律攻势中,埃隆・马斯克要求高达 1340 亿美元 的赔偿。然而与此同时,他自己的人工智能公司 xAI 却收到了加州总检察长罗布・邦塔(Rob Bonta)发出的 “停止并终止”(Cease and Desist)命令,要求其立即停止与聊天机器人 Grok 相关的非法活动 —— 据称 Grok 能够生成未经同意的深度伪造色情图像
马斯克与 OpenAI 之间的激烈对抗已达到新的顶点。据彭博社报道,最新诉讼指控 OpenAI 背叛了其最初的非营利使命。马斯克主张的赔偿金额介于 790 亿至 1340 亿美元 之间,依据是 OpenAI 与微软的合作带来了 “不当得利”。在法庭文件中,马斯克强调自己是 OpenAI 的关键早期捐赠者,曾提供 3800 万美元种子资金—— 约占该非营利组织初始资金的 60%。他还指出,自己在 OpenAI 成立初期付出了大量努力,包括招募核心人才并提供战略指导。
这一巨额赔偿数字由金融经济学家 C. Paul Wazzan 计算得出。他估计 OpenAI 的 “不当收益” 在 655 亿至 1094.3 亿美元 之间,而微软从中获得的收益约为 133 亿至 250.6 亿美元。鉴于 OpenAI 当前估值高达 5000 亿美元,马斯克认为,作为其最重要的早期资助者,他有权获得其增值的相当一部分。
就在马斯克追讨这些巨额款项的同时,xAI 在加州面临严峻的监管压力。经过快速调查,邦塔总检察长发布正式命令,要求 xAI 立即停止生成未经同意的露骨图像。争议焦点集中在 Grok 的图像生成功能 —— 据称用户只需一个提示词,就能让 Grok“脱衣” 真实人物(包括未成年人)或为其添加暴露服饰。邦塔指控 xAI 开发了 “辣模式(Spicy Mode)”,专门用于生成露骨内容,并将其作为一种营销策略。加州司法部严厉要求 xAI 停止 “协助或教唆” 制作和传播非自愿数字色情内容,并指出其涉嫌违反加州多项民事和刑事法规。尽管 X(前身为 Twitter)随后将 Grok 的图像生成功能设为付费墙后方,并在部分地区屏蔽了相关功能,但加州司法部仍要求 xAI 在 5 天内 提交正式的整改措施说明。
在针对 OpenAI 的诉讼中,马斯克似乎占据了道德高地,痛斥其前同事 “忘恩负义”,并指责他们放弃了 AI 安全和非营利承诺。然而,xAI 的运营却暴露出其安全护栏的严重缺失,使 Grok 成为深度伪造违法行为的温床。一边是马斯克利用法律系统追讨数十亿美元的 “不当得利”,另一边却是他自己的产品因标准宽松而遭到监管机构围剿。
这种鲜明反差揭示了马斯克理念中的深层矛盾:他渴望成为人类的 “AI 安全守护者”,但同时又希望利用 AI 的混乱潜力来推动用户互动和增长。在法律与监管审查日益严格的时代,这种双重策略似乎越来越难以为继。

在针对 OpenAI 和微软的法律攻势中,埃隆・马斯克要求高达 1340 亿美元 的赔偿。然而与此同时,他自己的人工智能公司 xAI 却收到了加州总检察长罗布・邦塔(Rob Bonta)发出的 “停止并终止”(Cease and Desist)命令,要求其立即停止与聊天机器人 Grok 相关的非法活动 —— 据称 Grok 能够生成未经同意的深度伪造色情图像
马斯克与 OpenAI 之间的激烈对抗已达到新的顶点。据彭博社报道,最新诉讼指控 OpenAI 背叛了其最初的非营利使命。马斯克主张的赔偿金额介于 790 亿至 1340 亿美元 之间,依据是 OpenAI 与微软的合作带来了 “不当得利”。在法庭文件中,马斯克强调自己是 OpenAI 的关键早期捐赠者,曾提供 3800 万美元种子资金—— 约占该非营利组织初始资金的 60%。他还指出,自己在 OpenAI 成立初期付出了大量努力,包括招募核心人才并提供战略指导。
这一巨额赔偿数字由金融经济学家 C. Paul Wazzan 计算得出。他估计 OpenAI 的 “不当收益” 在 655 亿至 1094.3 亿美元 之间,而微软从中获得的收益约为 133 亿至 250.6 亿美元。鉴于 OpenAI 当前估值高达 5000 亿美元,马斯克认为,作为其最重要的早期资助者,他有权获得其增值的相当一部分。
就在马斯克追讨这些巨额款项的同时,xAI 在加州面临严峻的监管压力。经过快速调查,邦塔总检察长发布正式命令,要求 xAI 立即停止生成未经同意的露骨图像。争议焦点集中在 Grok 的图像生成功能 —— 据称用户只需一个提示词,就能让 Grok“脱衣” 真实人物(包括未成年人)或为其添加暴露服饰。邦塔指控 xAI 开发了 “辣模式(Spicy Mode)”,专门用于生成露骨内容,并将其作为一种营销策略。加州司法部严厉要求 xAI 停止 “协助或教唆” 制作和传播非自愿数字色情内容,并指出其涉嫌违反加州多项民事和刑事法规。尽管 X(前身为 Twitter)随后将 Grok 的图像生成功能设为付费墙后方,并在部分地区屏蔽了相关功能,但加州司法部仍要求 xAI 在 5 天内 提交正式的整改措施说明。
在针对 OpenAI 的诉讼中,马斯克似乎占据了道德高地,痛斥其前同事 “忘恩负义”,并指责他们放弃了 AI 安全和非营利承诺。然而,xAI 的运营却暴露出其安全护栏的严重缺失,使 Grok 成为深度伪造违法行为的温床。一边是马斯克利用法律系统追讨数十亿美元的 “不当得利”,另一边却是他自己的产品因标准宽松而遭到监管机构围剿。
这种鲜明反差揭示了马斯克理念中的深层矛盾:他渴望成为人类的 “AI 安全守护者”,但同时又希望利用 AI 的混乱潜力来推动用户互动和增长。在法律与监管审查日益严格的时代,这种双重策略似乎越来越难以为继。