本期共 22 条 AI 资讯，涵盖实用技巧 7 条、行业资讯 5 条、项目推荐 10 条。推荐关注：FastWan-QAD：单卡5090上1.8秒生成5秒视频；京东全栈开源JoyAI-VL-Interaction，从“一问一答”走向“边看边说”；网易有道发布 Confucius4-TTS：14 语种跨语种无口音语音克隆开源模型。
单张 RTX 5090 上 1.8 秒生成 5 秒视频，把消费级延迟压到了‘即时生成’的临界点，做短视频和互动应用的开发者可以认真把这个模型放进技术栈。
(1/5) 5 秒视频。1.8 秒生成。一块搭载 FastVideo 的 NVIDIA GeForce RTX 5090。🤯🚀
📜 博客：https://haoailab.com/blogs/fastwan-qad/ 💻 代码：https://github.com/hao-ai-lab/FastVideo 💽 模型：https://huggingface.co/FastVideo/FastWan-QAD-1.3B
京东这个实时交互模型不是又一个刷榜模型，它把「什么时候该说话」变成了模型自己的判断。全栈开源且对比豆包、Gemini 胜率惊人，做安防、看护、直播的开发者可以直接试了。
公众号正文需在微信内阅读，站内仅提供摘要。
网易有道把语音克隆的门槛压到了 3 秒，跨 14 种语言还能保持无口音，而且全量开源、商用无限制，对多语种配音和短剧出海是直接可用的工具。
IT之家 6 月 23 日消息，网易有道今日发文，宣布推出“子曰 4.0”TTS 语音合成引擎 ——Confucius4-TTS。
据网易有道官方介绍，Confucius4-TTS 是业内首个支持 14 种语言跨语种无口音、且无需参考文本即可完成语音克隆的开源模型。
在技术性能方面，Confucius4-TTS 实现了零样本语音克隆能力。用户仅需提供 3 秒音频素材，无需参考文本与前期训练，模型即可完成音色克隆，克隆音色与原声相似度超过 85%，克隆任务准确度达 97%。
据介绍，该模型全面支持中文、英语、西班牙语、法语、德语、韩语、泰语、越南语等 14 种语言的自然流利表达。其核心突破在于解决了语音合成领域长期存在的跨语种口音问题 —— 用户上传中文音频，AI 即可用该音色流利说出日语、英语等外语，发音地道自然。
在情感表达方面，Confucius4-TTS 区别于传统 TTS 依赖文本标签控制情感的粗放方式，创新性地支持音频 Prompt 情感克隆迁移。系统可自动提取参考音频中的情感特征，精准复刻其语调、韵律，实现跨语种无损迁移。
在底层架构上，Confucius4-TTS 实现了全面革新。相较于初代 EmotiVoice 采用的 HiFi-GAN 声码器和 Speaker ID 查表方案，Confucius4-TTS 引入了 GPT 式语义大模型作为主干，搭配基于 SSL 预训练特征和 ECAPA-TDNN 的可学习说话人编码器，并采用 Flow Matching 流匹配生成框架，不再沿用传统声码器方案。
网易有道已将 Confucius4-TTS 全量开源，采用 Apache 开源协议，面向全球开发者开放完整模型权重和配套工具链，商用无限制。开发者可下载 54GB 完整资源包进行本地离线部署，满足数据安全与定制化需求。
在应用场景方面，Confucius4-TTS 可为多语种内容生成、数字人配音、跨语言教学、短剧出海及全球化传播提供低门槛的国产化技术底座。网易有道表示，希望通过全量开源 Confucius4-TTS，降低语音克隆和情感合成的门槛，让每一个声音都能跨越语言的边界。
该模型已在 GitHub 面向全球开发者开源。IT之家附官方地址：
https://github.com/netease-youdao/Confucius4-TTS
Krea 2 开源了两个图像模型权重，一个未蒸馏适合微调，一个快速蒸馏版覆盖多样审美。对于做图像生成应用和模型融合的团队，这次开放权重比很多大厂都实在。
我们的技术报告已经发布。
深入探讨了用于创建 Krea 2 的数据、架构和训练技术。
https://www.krea.ai/blog/krea-2-technical-report
今天，我们开放了 Krea 2 的模型权重。
欢迎 Krea 2 Raw 和 Krea 2 Turbo——前者是一个来自中期训练的非蒸馏模型，适合进行微调；后者是一个快速蒸馏版本，具有广泛的审美多样性。
详情请见下文 👇
### 引用推文
> Krea：today, we release the open weights of Krea 2. welcome Krea 2 Raw and Krea 2 Turbo, an undistilled model from mid-training meant to be fine-tuned, and a fast dis...
豆包音频生成模型把多角色配音、音效、配乐压缩进一条 Prompt，长时一致性解决了一直以来‘串戏’的痛点，音频创作者的生产流程可能会被改写。
公众号正文需在微信内阅读，站内仅提供摘要。
Mistral OCR 4 把 bounding box 和置信度输出做进了产品，自托管部署和多语言能力很务实，做文档 RAG 和智能体的团队可以认真看看。
Studio：构建、测试并运行 AI 智能体和应用。 Forge：训练、对齐并评估自定义 AI 模型。 Vibe：面向长周期任务的 AI 智能体。 Vibe for Code：终端、IDE 及后台环境中的编码智能体。 Compute：面向训练和推理的一流基础设施。
定价
方案 / API 定价 / 企业版
服务
交付方法论 / 模型定制
行业
金融服务 / 公共部门与政府 / 制造业
使用场景
使用场景概览 / 编码 / 文档智能 / 语音
最新模型
Mistral OCR 4 / Mistral Medium 3.5 / Mistral Small 4 / Voxtral TTS
查看全部模型
文档 / API 参考 / Cookbooks
最新文章
Introducing Mistral OCR 4 / AI Now Summit 2026 / Vibe gets to work.
阅读全部新闻
分类
产品 / 研究 / 工程 / 解决方案 / 公司
精选案例
ASML / CMA CGM / HSBC / BMW
查看全部
关于我们
关于我们 / 招聘 / 品牌
联系
社区 / 合作伙伴 / 帮助中心
产品 / 解决方案 / 研究 / 开发者 / 博客 / 客户 / 公司
定价
方案 / API 定价 / 企业版
服务
交付方法论 / 模型定制
行业
金融服务 / 公共部门与政府 / 制造业
使用场景
使用场景概览 / 编码 / 文档智能 / 语音
最新模型
查看全部模型
文档 / API 参考 / Cookbooks
最新文章
阅读全部新闻
分类
产品 / 研究 / 工程 / 解决方案 / 公司
精选案例
ASML / CMA CGM / HSBC / BMW
查看全部
关于我们
关于我们 / 招聘 / 品牌
联系
社区 / 合作伙伴 / 帮助中心
开始构建
Studio / Vibe / Vibe for Code
联系销售
研究 Introducing OCR 4
2026 年 6 月 23 日
作者：Mistral AI
返回博客 阅读时间：10 分钟
分享此文章
复制到剪贴板 已复制
标题
副标题
文本
图片
表格
今天，我们发布了 Mistral OCR 4，它在提取文本的同时，还支持边界框、区块分类以及内联置信度分数。该模型覆盖 10 个语系的 170 种语言，可在单个容器中运行以实现完全自托管部署，并能作为企业搜索、RAG 以及领域特定检索管道的输入组件使用。OCR 4 是一个小巧、聚焦的模型，本文介绍了它的新特性、在公开及内部基准上的表现、这些基准的已知局限，以及何时应使用模型 API 而非 Document AI 的指导建议。
视频 1
**亮点**
**突破性性能。** 独立标注员将 OCR 4 与所有领先的 OCR 和文档 AI 系统进行了对比测试，结果表明 OCR 4 更受青睐，平均胜率达 72%，同时在 OlmOCRBench 上取得了最高总分（85.20）。关于方法及已知评分限制，请参见下方的基准测试部分。
**分割，不止是文本。** 除了提取的文本之外，OCR 4 还会返回边界框、类型化的区块分类（标题、表格、公式、签名等）以及逐行置信度分数。边界框是我们最常被要求提供的功能，可实现文本在上下文中的高亮显示，并构建可靠的数据管线。同时，区块类型和置信度分数还能驱动基于来源的引用、内容编辑以及人工参与验证流程。
**与 Mistral 搜索工具包（公开预览版）集成。** OCR 4 是搜索工具包的一个输入组件。搜索工具包是 Mistral 推出的开源、可组合的搜索框架，在 AI Now 峰会上发布。其结构化输出为工具包在 RAG 和企业搜索场景下的输入、检索与评估工作流提供了可直接用于引用的输入内容。
**多语言覆盖。** 支持 10 个语系共 170 种语言，且在多种竞争系统性能下降的稀有语言和低资源语言上取得了可衡量的提升。
**部署在自有基础设施上。** OCR 4 足够轻量，可部署在单个容器中，使文档数据留在您的环境中以满足数据驻地、数据主权和合规性要求，同时支持高效、高吞吐量的批量处理。自管部署面向企业客户开放。
**概述**
Mistral OCR 4 可从多种文档中提取并结构化内容。前几代产品侧重于将页面转换为清晰的文本和表格，而 OCR 4 则返回文档的结构化表示。每个区块都通过边界框进行定位，按类型分类，并逐页、逐词生成行内置信度分数。因此，下游系统不仅能获取文档说了什么，还能知道每个元素在什么位置、扮演什么角色，以及模型对每个区域的置信度有多高。
这种结构支持多种下游工作负载： **语义分块（RAG）**：干净、分类清晰的文本块能成为更好的检索单元。 **用于 AI 智能体的结构原语**：AI 智能体从读取文档转向对文档执行操作（如填写表单、处理发票、合规性检查）。 **面向连接器的结构化内容**：为数据摄入和索引管道提供一致、类型化的输出。
OCR 4 支持常见的企业格式，包括 PDF、DOC、PPT 和 OpenDocument，并覆盖 10 个语系中的 170 种语言，其中包括许多系统处理不好的稀有语言和低资源语言。作为可在单个容器中部署的紧凑型模型，它既适合对成本敏感的场景，也适合高吞吐量部署。它可以完全自托管运行，使有数据主权要求的组织能够将文档数据保留在自己的基础设施内。
开发者通过 API 集成该模型，团队则可以在 Mistral Studio 中使用 Document AI，通过应用层面的无代码路径访问同一引擎。Mistral OCR 4（通过 API）的定价为 $4 per 1,000 pages，批量 API 可享受 50% 折扣，成本降至 $2 per 1,000 pages。Document AI 的定价为 $5 per 1,000 pages。
**基准测试**
> “我们将 Mistral OCR 4 与领先的智能体文档解析器进行了基准测试，使用的数据集是图表和图片密集的金融问答数据集，结果达到了同等精度，但成本降低约 8 倍，延迟降低约 17 倍。对于大规模生产用例，这种差异会迅速累积。” > > _— Aidan Donohue，Rogo 公司 AI 工程师_
为了评估 OCR 4，我们将其与领先的 AI 原生 OCR 模型、前沿通用模型、企业文档服务以及我们自己的 Mistral OCR 3 进行了比较。
**人类偏好评估**
自动基准测试存在上述评分伪影问题，因此我们通过一项面对面对比的人类评估来加以补充，评估所使用的文档均经过精心挑选，以反映真实使用场景。我们收集了 600 多份涵盖 12 种以上语言的文档，这些文档来自第三方供应商，能代表真实的行业用例，然后请独立标注员逐一将每个竞品的输出与 OCR 4 的输出进行盲评排名。在所有被测试的系统中，标注员在大部分文档上都更偏好 OCR 4。由于这些是基于真实文档的人类判断，而非与固定参考文本进行字符串比对，因此它们规避了影响自动评分的许多标注和格式噪声。
**整体表现**
> “Mistral OCR 每页的处理速度比我们现有的供应商快约 4 倍，对于大批量文档处理工作流而言，这是一个令人印象深刻的结果，因为速度对于管理客户的知识产权时间线至关重要。” > > —— Ivan Mihailov，AI 工程师，Anaqua
除了在我们的人工偏好评测中排名第一之外，OCR 4 在我们测试的模型中，在公开的 **OlmOCRBench（85.20）** 上取得了最高总分，并在我们内部的 **Crawl Multilingual 评测（.98）** 上领先，同时超越了 AI 原生方案和企业级解决方案。
在 **OmniDocBench** 上，OCR 4 取得了 **93.07** 的分数。我们在报告这一分数时附带一个说明：**OlmOCRBench** 和 **OmniDocBench** 在评估某些输出时均存在已知的局限性，单一的汇总数字既可能低估也可能高估实际性能。
当我们审核分数背后的不匹配项时，发现大多数并非模型错误，而是基准测试比较输出结果时产生的伪影。反复出现的类别有：
**真实标注错误。** 某些参考标注本身有误：遗漏或多余的文本、被遮盖区域的转录、或者拼写错误（例如，参考文献中某位作者的名字拼写错误，但模型从页面上正确读取了该名字）。输出与源文档一致，却被标记为错误。
**等效的数学符号。** 渲染后完全相同的不同 LaTeX 会被计为不匹配。渲染出的公式是正确的，但字符串比较却认为不匹配。
**公式分段。** 一个表达式是作为单个公式输出，还是拆分为多个内联片段，会影响匹配结果——即使渲染后的内容完全相同，因为匹配器无法对齐这些片段。
**多栏阅读顺序。** 跨栏边界分割的单词（例如 “certifi-cates”）以及栏序假设，会导致正确的提取被判定为阅读顺序错误。
**区块类型归属。** 基准测试预期输出中不包含页眉/页脚。为解决此问题，我们在评分前从输出中移除页眉页脚。但测试随后会检查某个恰好也是页面标题的字符串，而该标题实际应当保留，于是错误地标记为异常。
这些伪影主要集中在数学、科学类和多栏文档中，而且它们更多时候是惩罚正确的输出，而非奖励错误的输出。因此我们将汇总分数视为方向性指标，而非决定性结论。
我们报告这些数字是为了说明 OCR 4 的水平，并建议您在自己的文档上进行评估。
**性能详情**
**Crawl 多语言分解。** 在我们的内部多语言评估中，OCR 4 在所有八种语言组中均领先——英语、西欧、东欧、中东、中文、东亚、东南亚以及稀有语言（印地语、日语、格鲁吉亚语、孟加拉语、亚美尼亚语、希伯来语、希腊语、古吉拉特语、泰米尔语、马拉雅拉姆语、卡纳达语、泰卢固语）。差距在稀有语言和低资源语言上最为显著，许多竞品系统在这些语言上性能急剧下降，而 OCR 4 仍保持高准确率。
英语 西欧 东欧 中东 中文 东亚 东南亚 稀有语言
**推荐使用场景**
OCR 4 既支持大规模流水线处理，也支持交互式文档工作流，包括：
**文档解析与提取：**复杂多语言文档。
**检索增强生成（RAG）：**经过结构化、分类并可直接引用的内容，用于语义分块和基于源的答案。结合 Search Toolkit，OCR 4 的输出可直接馈入检索流水线。
**智能体工作流：**为智能体提供结构原语，以完成表单填写、发票处理和合规检查等任务，尤其适用于法律、金融服务和医疗保健领域。
**利用置信度分数的高效人工验证结构化数据流水线：**表单/发票提取、编辑和合规驱动流程。
**企业搜索与知识库：**OCR 作为自定义摄取和实体提取的数据源组件。
早期用户正在利用 OCR 4 将发票转换为结构化字段、数字化公司档案、从技术和科学报告中提取干净文本，以及支持企业搜索。
**关于范围外使用的说明。** OCR 4 是一个文档理解模型，而非决策者。它**不**适用于医疗诊断、法律建议或判决、高风险金融决策、安全关键系统、实时/延迟敏感处理或非文档输入（原始音频、视频等）。
**OCR 4 API：了解您的选项**
Mistral 的 OCR 4 通过单一 API 端点提供。……
字节 Seed2.1 这次更新把 Agent 和代码交付稳定性提到新高度，官方测评在多个硬核基准上不输 Claude Opus。虽然技术细节少，但豆包和 TRAE 直接可用，做 Agent 和开发的值得上手试试。
该来源未收录可展示正文，站内仅提供摘要。
CUGA 把 agent 的规划、状态、策略等繁琐工程压缩成配置，开发者只写工具列表和 prompt 就能跑起 agent，配套的二十多个单文件应用是现成的模板库，对自建 agent 的团队来说省去了八成重复工作。
使用 CUGA 构建真正的智能体应用：轻量级框架上的二十几个可运行示例
Enterprise Article
发布于 2026 年 6 月 23 日
Anupama Murthi
anupamamurthi
ibm-research
Hamid Adebayo
harmedox
ibm-research
Sami Marreed
samimarreed
ibm-research
Praveen
praveenv
ibm-research
Asaf Adi
AsafAdi
ibm-research
摘要——构建智能体大部分是管道工作：工具、状态、护栏、从单个智能体扩展到多个智能体。CUGA（`pip install cuga`），全称可配置通用智能体（Configurable Generalist Agent），是 IBM 面向企业的智能体框架，它替你处理这些，你只需编写工具列表和提示词。我们构建了二十几个单文件应用来证明这一点。在这里从头到尾阅读其中一个，然后看看同一个智能体如何无重写地以受管控和受治理的方式在生产环境中运行。
大多数智能体应用在智能体做任何有用的事情之前，先花一周时间做管道工作。你挑选一个框架，连接模型客户端，编写工具适配器，构建某种将状态流式传输到 UI 的方式，然后在这过程中你还得决定智能体到底用来做什么。有趣的部分最后才到来。
CUGA 颠覆了这一点。它是 IBM 的开源智能体框架，替你处理规划、执行循环、工具调用和状态管道。剩下的才是真正属于你的部分：智能体可以访问哪些工具，以及你告诉它做什么。为了展示这在实践中是什么感觉，我们构建了 `cuga-apps`：二十几个小型但可运行的应用，每个都是一个包装了单个 `CugaAgent` 的 FastAPI 文件，从电影推荐器到 IBM Cloud 架构顾问。它们的存在是为了被阅读和复制。你可以点击浏览实时展示页。
本文详细解析其中一个应用，指出该框架为你省去了什么工作，并展示当你需要以受治理的方式投入生产时，同样的代码会去往何处。无需先学习新框架。如果你写过 FastAPI 路由，你就能读懂每一行。
为什么是框架（harness），而不是框架（framework）
在这个领域，对任何东西的合理问题是：它让你免于编写什么？CUGA 的回答是：围绕模型的编排工作，否则你每次都要重新构建。
它在行动前先计划，然后通过工具调用和生成代码（CodeAct）的组合来执行。在需要执行二十步的长时间任务中，大多数智能体失败的原因是丢失中间结果的跟踪，并在下一轮重新推导（常常出错）；而CUGA则保持这些状态，并运行一个反思步骤，能够捕获错误的调用并重新规划，而不是一味地向前推进。正是这种机制使其在AppWorld和WebArena等智能体基准测试中名列前茅，而不是通过手动调参来达到的效果。
你还可以通过配置文件而非代码来设置成本/延迟权衡：Fast、Balanced、Accurate三种推理模式，代码执行可置于任何你信任的沙箱（本地、Docker/Podman或E2B云）。相同的智能体定义，不同的旋钮。这个旋钮的重要性远超表面所见。大多数框架假设底层有一个前沿模型，并在计划偏离时依赖它进行恢复；而CUGA则自行完成这项工作。规划、反思步骤、使长时间运行保持正轨的变量跟踪——这些正是框架承载的负载，否则模型将不得不自己承担，这使得较小的开源权重模型在通常无法胜任的场景下也能坚持运行。这也是为什么托管应用运行在gpt-oss-120b上，而不是前沿API上。调用能调用的最大模型是常见的赌注；而CUGA的赌注是一个较小的开源模型就足够了。
没有任何单个组件是CUGA独有的。不同之处在于它们被预先组装好，因此你只需配置它们，而无需将它们逐一连接。你接触的API非常精简——用工具列表和提示词构建一个CugaAgent，然后await agent.invoke(...)。这行代码以下的一切都是框架。
具体来说，就是可互换的工具（OpenAPI、MCP 和 LangChain 函数都以相同方式绑定）、带有变量管理和自我修正的长周期规划（驱动 AppWorld 从 07/25 到 02/26 以及 WebArena 从 02/25 到 09/25 排行第一的底层机制）、声明式护栏、基于 A2A 的多智能体委派、由 Docling 驱动的 RAG，以及通过一个环境变量切换提供商（`pip install cuga`，然后可选 OpenAI、watsonx、Ollama 等）——每项功能都是你原本需要自己构建的东西。名字的首个词点明了作用：可配置（Configurable）；难点已由框架处理，你的工作只剩下任务本身。
一个应用，从头到尾
下面是 IBM Cloud 顾问——一个能够为架构推荐真实 IBM Cloud 服务的智能体。整个功能都放在一个文件里：一个包含 agent 工厂、工具和提示词的 main.py，外加一个小型 UI。
整个 agent 就是这样的：
def make_agent():
from cuga import CugaAgent
from _llm import create_llm
return CugaAgent(
model=create_llm(
provider=os.getenv("LLM_PROVIDER"),
model=os.getenv("LLM_MODEL"),
),
tools=_make_tools(),
special_instructions=_SYSTEM,
cuga_folder=str(_DIR / ".cuga"),
)
四个参数。模型来自一个小型工厂（create_llm），它根据环境变量与 OpenAI、Anthropic、watsonx、LiteLLM 或 Ollama 对接。应用代码里完全不知道背后是哪个模型。cuga_folder 是此应用保存状态和策略的地方。承载应用的两个参数是 tools 和 special_instructions。
工具将本地函数与托管函数混合在一起：
def _make_tools():
from langchain_core.tools import tool
@tool
def search_ibm_catalog(query: str) -> str:
"""Search the IBM Cloud Global Catalog for real IBM Cloud services.
Always call this before recommending services to verify they exist."""
...
from _mcp_bridge import load_tools
web_tools = load_tools(["web"])
return [search_ibm_catalog, *web_tools]
这里有一个适用于每个应用的固定模式：MCP 工具与内联工具的分隔。通用、无状态的能力来自共享的 MCP 服务器；`load_tools(["web"])` 会拉取网络搜索能力，而你无需托管任何东西。任何特定于此应用的能力都以内联方式定义为普通的 Python 函数，比如 `search_ibm_catalog`，其文档字符串就是 agent 判断何时调用它的依据。你只需编写那个属于你自己的工具，其余部分借用即可。
云顾问的提示词指示智能体在提及任何服务之前先搜索目录，推荐三到七项服务并说明每项服务在设计中的作用，且绝不可编造服务名称。最后这条规则至关重要：推荐不存在的 IBM Cloud 服务的智能体比没有智能体更糟，因此提示词强制要求每项推荐都必须先经过目录查询。按有序步骤编写、包含明确“不许编造”规则的提示词表现良好；而基于角色设定的提示词则容易偏离主题。
这就是应用本身：一个工具、一个流程、四行构造函数。围绕它的 FastAPI 路由是普通的 web 代码：浏览器向 /ask 端点发送问题，实时面板轮询 /session/{thread_id} 端点获取状态。没有数据库；状态是基于 thread_id 的 Python 字典，只有智能体通过其工具写入。当智能体在运行中途调用某个工具时，面板会立即重绘。UI 并非逻辑的第二个副本，而是智能体修改过的状态的视图。
承担主要工作的约定
有一个细节很容易被忽略，却实际承担着关键作用：每个内联工具都返回相同的小型信封结构。成功时返回 `{"ok": true, "data": {...}}`；失败时返回 `{"ok": false, "code": "...", "error": "..."}`。
这看起来像样板代码，其实不然。CUGA 的计划器能够优雅地处理声明过的错误（例如“地理编码未返回任何结果，跳过该部分继续执行”），但遇到未声明的错误时就会卡住——原始堆栈跟踪在计划过程中冒出来，导致运行偏离轨道。在所有应用中，那些运行可靠的应用，其工具从未向智能体抛出未处理的异常。这是一个枯燥的约定，但正因如此，智能体才能恢复运行，而不是当场崩溃。
上述拆分之所以有效，是因为通用部分已经在某处运行。应用反复调用的能力——web 搜索、Wikipedia/arXiv、地理编码和天气、金融行情等——存在于部署在 IBM Code Engine 上的 7 个公共 MCP 服务器（共 36 个工具）中，无需认证即可访问。一个小型桥接器会自动解析它们的 URL，而在线展示区附带了一个 MCP 工具探索器，你可以在将其接入智能体之前，通过表单调用其中任何一个工具。
一个库，而非演示
之所以有二十多个精心打磨的应用，其意义远大于任何一个单独的应用：一旦你了解了云顾问，你就了解了所有应用。它们共享一个骨架——电影推荐器将 IBM 目录工具换成了知识 MCP 服务器，网页研究者几乎完全依赖网页——因此 cuga-apps 实际上是起点的目录。你克隆仓库，找到最接近你创意的应用，然后编辑它的工具列表和提示词（HOW_TO_BUILD_AN_APP_FAST.md 和 ADDING_AN_APP.md 详细介绍了这一点）。有些应用甚至是只给编码助手一个规格文件和一行的简短说明生成的——这种规律性足以让模型重现，也就意味着规律性足以让你学习。在克隆任何东西之前，你可以在实时图库中点击浏览每一个应用。
它们还分布在不同的类别中，因此无论你在构建什么，总有一个应用已经实践了你需要的部分。有一个研究集群（Paper Scout 按引用数对 arXiv 论文排序；Wiki Dive 和 Web Researcher 进行引用综合），一组日常生产力应用（城市简报、旅行、食谱、路线），一个文档和媒体组（对 PDF、音频和视频进行 RAG），一个监控实时指标的运维角落，以及一个基于真实 IBM 产品文档的企业示例。Ouroboros 是一个七智能体的线索生成系统；打开它以了解多智能体架构。Meetup Finder 通过 Playwright 驱动无头 Chromium，从 Meetup、Luma 和 Eventbrite（这些平台都关闭了公共搜索 API）提取结构化活动；打开它以了解浏览器自动化——这正是 CUGA 的起点，也是其强大 WebArena 成绩背后的力量。
在克隆之前有两个注意事项。真实的目录位于内部的 cuga-apps/cuga-apps/apps/ 目录中，而不是外层的那个。而且并非每个应用都同样精心打磨，因此 UI 将其标记为“可投入使用”、“待后续”或“探索性”，默认显示“可投入使用”；从云顾问或电影推荐器开始，以获得一个可工作的基线。
让你的智能体保持在边界之内
一个用来搜索目录的演示智能体是低风险的。把同样的模式用在会写文件、运行 shell 命令或接触生产环境的任务上，问题就变了：如何阻止它做出让你后悔的事？
CUGA 在运行时中回答这个问题，而不是在你事后添加的包装器里。这个开源智能体附带了一个策略系统，你可以把策略附加到同一个智能体对象上：
await agent.policies.add_intent_guard(
name="Block force-push",
keywords=["--force", "--no-verify"],
response="Blocked: destructive git flags are not permitted.",
)
那就是意图守卫，六种策略类型之一，每种策略都回答团队在让智能体投入使用之前会问的一个问题：
意图守卫——它能直接拒绝一个请求吗？
工具审批——它能在运行有风险的工具之前暂停并等待人工确认吗？
工具指南——我能否在不重写工具的情况下，引导某个具体工具的使用方式？
剧本——我能否针对一个重复性任务固定一个已知有效的流程？
输出格式化器——我能否强制最终响应符合某种要求的形状？
第六种类型 CustomPolicy 是当其他策略都不适用时的逃生口。时机的把握很重要，因为这不只是一个阶段：意图守卫在智能体选择工具之前检查请求，工具审批在智能体生成代码之后运行并检查该代码使用了哪些工具，而输出格式化器只在最终消息生成后才触发。触发条件也不只是关键词匹配：它们存储在一个 sqlite-vec 存储中并进行语义匹配，因此策略是基于用户的实际意图触发，而不仅仅是精确的关键词。可以匹配语义相似度、智能体状态或某个具体工具的触发。策略本身存放在构造函数中提到的 .cuga 文件夹里，与代码一起版本管理，而不是散布在独立的配置中。
以一个工作示例为例：打开 Ouroboros——一个由七个智能体组成的线索生成应用，它为其主管智能体附加了三个策略（一个意图守卫、一个工具指南和一个输出格式化器），因此这是同一个文件里同时演示了治理和多智能体架构的应用。
从一个智能体扩展到更多智能体。
当一个应用超出单次对话循环的规模时，有两种扩展方式变得重要。如果一个智能体会在自己的上下文中陷入困境（工具太多、需要保持的证据太多），就需要拆分工作。一个 CugaSupervisor 将任务委派给专门的 CugaAgent，每个 CugaAgent 都有自己的工具、提示词和隔离的上下文，而 Supervisor 只负责推理应将子任务交给哪个专家。无论底层有多少工具，它的规划面始终保持精简；一个有问题的工具只会让一次委派失败，而不是整个运行失败。专家甚至不必是本地部署的；它可以是通过 A2A 协议访问的外部智能体，以同样的方式被委派。增加一项能力意味着添加一个专家，而不是重写协调器。
另一种扩展方式封装的是知识而非工具：Agent Skills，一个包含 SKILL.md 操作手册的文件夹，只有当任务需要时，智能体才会将该手册拉入上下文，这样单个提示词就不必承载智能体可能需要了解的一切。两者都使用相同的构建模块（工具、提示词、状态、策略），只是组合层级更高一层。
之前的潜在客户开发应用 Ouroboros 让这个模式变得具体。它有一个 Supervisor 管理七个专家（侦察兵、站点审计员、客户之声、人员查找器、技术栈扫描器、收入估算器以及一个汇总并撰写推销邮件的专家）。每个专家都是一个加载到 CugaAgent 中的技能，Supervisor 通过一个自动生成的 `delegate_to_<name>` 工具调用该专家。添加第八个专家只需一行工厂代码，而不是重写协调器。如果你想了解多智能体架构的完整形态，可以阅读它的 main.py 和 ARCHITECTURE.md。
还有第三种扩展方式，它又回到了技能本身。借助 ALTKEvolve（CUGA 的岗位学习框架），智能体可以从自身的运行中优化一项技能，从而使今天完成的任务能让明天的工作更快、更准确。专家加载的 SKILL.md 最终会包含智能体在你编写的内容基础上学习到的东西。同样的构建模块，只是现在，使用一个技能的过程也在教会下一个技能。你不再需要对你上周已经解决的问题重新编写提示词。
由构造方式约束
治理在堆栈中的位置决定了生产环境的故事如何展开。一个极简的智能体库会提供良好的原语，而将治理（策略、审批、审计、身份）留给你自行组装。CUGA 则走另一条路：策略、人工在环审批、.cuga 状态文件夹以及自托管，从第一行代码起就是框架的一部分，而非后来附加的层。
这改变了将智能体投入生产时的工作方向。你不需要为原本为开放访问构建的系统 retrofit 控制措施；控制面已经存在。治理路径是默认路径，而未经治理的快捷方式才是你需要主动选择的。因此，剩下的工作就变得很窄：收紧围绕少数真正接触外部世界的工具的沙箱，而不是凭空发明围绕它们的治理。
同一个智能体最终落地的位置
这就是回报，也是所有东西如此构建的原因。因为框架小、开源、模型无关，并且已经自我治理，你在笔记本电脑上编写的智能体，与在锁定部署中运行的智能体是同一个。你不需要移植它，只需重新部署它。
这是 IBM Sovereign Core 所构建的基础，也是我们下一步将 CUGA 带向的地方。我们单独写了细节，但简短版本是：Sovereign Core 在我们所谓的边界隔离（Boundary Isolation）下运行 CUGA 智能体：数据、控制面和执行引擎都在同一逻辑边界内，智能体在租户自己工作空间内的临时隔离容器中运行。模型也在那里运行。部署默认使用完全气隙运行在你基础设施内的 gpt-oss-120b，工具仅能访问私有 VNET，且每个工具都需要审批。每个推理步骤都会发出 OpenTelemetry 链路追踪数据到租户内部的 Grafana Tempo 后端，没有遥测数据回传。没有任何东西离开边界。
智能体的定义本身无需改变；变化的是其周围的部署环境。而这一切之所以可能，正源于上述所有要素——能力、策略与模型选择都驻留在一个可读取的运行时中。这正是我们构建它时所押注的理念：当智能体的运行时是一个黑箱时，主权不过是一句承诺；但当运行时是开放代码时，主权便成为可验证的事实。你克隆的应用和你编写的智能体，都运行在同一个开放运行时之上，这正是这一主张的基石。
不过，对于开发者而言，核心要点不言自明。一个智能体应用可以只是一个你完全掌握在自己手中的文件。你真正需要编写的只有工具和提示词。这些应用是一套可供学习借鉴的库，而非封闭的演示。当风险升级时，治理机制已经内置于运行时之中——你无需重构智能体来确保其安全。
后续步骤
克隆仓库并运行一个应用。托管的 MCP 服务器意味着你无需第三方密钥，只需一个 LLM 提供商即可。本文中的应用运行于开源权重的 gpt-oss-120b 模型上——与托管画廊及我们 Sovereign Core 部署所使用的模型相同——但由于模型切换仅需一行代码（create_llm 读取单一环境变量），你可以将任何应用指向 OpenAI、Anthropic、watsonx 或本地 Ollama 模型，无需修改代码，且使用本地模型时完全没有 API 成本：
首先，查看我们的快速入门指南，点击此处。如果你想设置所有应用程序，请确保 Docker 正在运行，然后按照以下步骤操作。
git clone https://github.com/cuga-project/cuga-apps.git
cd build
cp .env.example .env
docker compose up --build
然后打开 apps/ibm_cloud_advisor/main.py 并从头到尾通读一遍——这是展示内联工具加 MCP 模式最清晰的示例。修改系统提示词、添加一个工具，然后观察行为的变化。MCP 工具浏览器列出了所有托管工具，并配有直接调用的表单，这是在将工具接入智能体之前快速检查连接是否正常的方式。
所以试试看。运行 pip install cuga，克隆 cuga-apps，然后运行一个应用——或者先直接点击浏览实时画廊。基础设施位于 cuga-agent，项目主页是 cuga.dev。如果出现问题、应用表现异常，或者你有任何想法，我们都期待你的反馈：提交 issue、发起 PR、放入你自己的应用，或者直接联系我们——这个仓库本就是为不断扩充而建，我们会阅读所有收到的反馈。
资源
cuga-apps — 本文中的应用、MCP 服务器和用户界面
cuga-apps/apps — 约二十个经过打磨的单文件智能体应用（内部目录；从此处克隆）
cuga-apps/mcp_servers — 共享的 MCP 服务器（网络、知识、地理、金融、代码、文本……等），应用可调用它们
实时应用画廊 + MCP 工具浏览器 — 每个应用都配有启动按钮，外加一个可直接调用各托管 MCP 工具的表单
cuga-agent — CUGA 运行环境与策略系统
cuga.dev — CUGA 项目主页（pip install cuga）
开放设计：主权核心中的通用型与预构建智能体 — IBM 社区关于 CUGA 如何在 Sovereign Core 内运行的帖子（Srivastava, Marreed, Thomas，2026 年 4 月）
IBM Sovereign Core — 产品页面
社区
· 或发表评论
Runway 一次性推出 Seedance 4K 等多个模型，视频生成画质再升级，对 Sora 等的追赶信号明显，做视频的可以直接上手试试。
Seedance 4K。Seedance Mini。Kling 3.0 Turbo。现已推出。全球顶尖模型，尽在一处。
使用优惠码 30RUNWAY，首三个月享 30% 折扣。
点击下方链接开始使用。
百度把能处理超长文档的 OCR 系统开源了，宣称一次推理搞定整份文件，做发票、合同、档案数字化的可以马上跑起来试试。
无限OCR：一次性长时域解析（github.com）
19:35 ↑ 112 HN 积分
千问高考志愿Agent的测评报告，数据看着漂亮，但全是阿里自家实验室出品，参考意义不大，真填志愿还是得找独立第三方。
公众号正文需在微信内阅读，站内仅提供摘要。
Anthropic 这次把 Claude 从对话助手变成了团队里的主动队友，Slack 里的多人协作、上下文学习和异步代理是个新思路。内部 65% 代码由它生成的数据，让这个方向不再只是实验。
产品
推出 Claude Tag
2026 年 6 月 23 日
Claude Tag 是一种让团队与 Claude 协作的新方式。
我们先从 Slack 开始，Claude 可以以团队成员身份加入其中。授权 Claude 访问特定频道，并将其连接到你选择的任何工具、数据——甚至是代码库。然后，频道中的任何人都可以 @Claude，并在专注于其他工作时把任务委派给它。Claude 通过记住所在频道中的相关信息来建立上下文，并能够规划未来完成的任务。
我们将 Claude Tag 视为 Claude Code 演进的开端：它让模型变得更加主动，并且能够更好地与整个团队协作。在 Anthropic，@Claude 现在已成为我们完成工作的主要方式之一。目前，我们产品团队 65% 的代码是由我们内部的 Claude Tag 版本创建的。同样的模式现在已远远超出工程领域——我们使用 @Claude 来追踪产品指标和数据、处理支持工单，甚至帮助查找棘手 Bug 的根本原因。
我们在 Slack 上推出 Claude Tag，因为它是团队与 AI 之间协作的自然场所，也是 Anthropic 大部分日常工作已在进行的地方。该功能目前以 Beta 版形式提供给 Claude Enterprise 和 Team 客户。我们的目标是将其扩展到更广泛的使用场景，让团队能够在他们工作的其他许多地方也能 @Claude。
与 @Claude 协作
如果你之前用过 Claude Code 或 Cowork，那么 Claude Tag 会让你倍感熟悉。用简单语言 @Claude 提出请求，它会将任务拆解为多个阶段，然后利用其可访问的工具依次完成。任务完成后，它会在 Slack 的对话线程中回复所创建的内容。
但 @Claude 还带来了一些新优势：
@Claude 支持多人协作。在给定的 Slack 频道中，只有一个 Claude 与所有人交互。这意味着任何人都能看到它正在做什么，并且可以接续上一个人留下的对话。这使得 @Claude 与单次聊天或单次任务中的工作方式截然不同——它更像与一位队友进行协作式互动。
@Claude 会随着时间推移不断学习。当 Claude 跟随其所在频道时，它会积累更多关于工作的上下文。这意味着用户无需反复从头向它解释事情。而且，如果获得授权，Claude 还能自动从其他 Slack 频道和数据源中学习（它不会从私密频道获取信息）。这让它具备提供最佳工作成果所需的隐性知识。
@Claude 会主动采取行动。如果启用了“环境感知”行为，Claude 会主动向你更新它认为你可能需要了解的任何信息。它会从它所在的各个频道以及它连接的工具中标记出相关情报，并跟进那些已经沉寂但尚未解决的讨论串或任务。
@Claude 可以异步工作。交给 Claude 一个任务，你就可以专注于其他优先事项，而它在一旁工作。它还能为自己安排任务，自主地花数小时甚至数天推进项目。我们在 Anthropic 内部发现这一点特别有用：现在我们将更多时间用于并行地向多个 Claude 委派任务。
你也可以向 Claude 发送私信：它将使用你已设置的个人工具和连接器，私下进行回复。
快速上手
我们设计 Claude Tag 时充分考虑到了团队和组织的需求：@Claude 对敏感数据和任务特定工具的访问权限可以得到非常严格的控制。
要启动并运行，系统管理员需要指定模型应有权访问哪些工具和信息，以及在哪些频道中。可以把它看作是为不同用途创建独立的 Claude 身份：包括记忆在内的所有内容都将限定在管理员定义的频道范围内。例如，为销售工作设置的模型不会将其记忆传递给为工程工作设置的模型；也不会让工程师访问任何销售数据或工具。关于设置访问权限的更多信息，可在此处获取。
权限设置完成后，每个人可以立即开始使用 @ 提及功能。管理员可以为 token 消耗设置限额（既适用于整个组织，也适用于单个频道），并且可以查看 @Claude 所做的一切操作日志，以及每个任务的请求者是谁。
如果你是 Claude Enterprise 或 Team 客户，从今天起你可以试用 Claude Tag（测试版）。要开始使用，请访问此处并按照以下四个步骤操作：
将 Claude Tag 绑定到你的 Slack 工作区
授予 Claude 访问你的工具的权限
为你的组织设置每月支出上限
在私密频道中测试 Claude，确认其正常运行
Claude Tag 将取代原先 Slack 中的 Claude 应用。如需迁移，管理员可在 30 天内选择启用。我们为符合条件的 Enterprise 和 Team 组织提供首次启动积分，以便整个公司都能试用。
Claude Tag 与 Opus 4.8 配合使用。你可以查看我们的文档和产品页面。
Anthropic 开设首尔办事处，并宣布与韩国 AI 生态系统建立新的合作伙伴关系
Read more
关于美国政府指令暂停 Fable 5 和 Mythos 5 访问权限的声明
美国政府已发布出口管制指令，要求暂停所有对 Fable 5 和 Mythos 5 的访问。
Read more
来自首次 Anthropic 公开记录的结果
Read more
What's changed
Added sandbox.credentials setting to block sandboxed commands from reading credential files and secret environment variables
Added org-configured model restrictions to the model picker, --model, /model, and ANTHROPIC_MODEL, with a "restricted by your organization's settings" message when a restricted model is selected
Added mouse click support to select menus (permission prompts, /model, /config, etc.) in fullscreen mode
Fixed --resume failing with "No conversation found" when the original -p run produced no model turns
Fixed --json-schema and workflow agent({schema}) structured output: the model can no longer re-call StructuredOutput indefinitely after a successful call, and follow-up turns now reliably return structured output
Fixed remote MCP tool calls that hang with no response for 5 minutes — they now abort with an error instead of blocking indefinitely (override with CLAUDE_CODE_MCP_TOOL_IDLE_TIMEOUT)
Fixed Claude Code Remote sessions taking ~2.7s longer to start after the agent proxy CA system-trust install was added
Fixed pasted Korean/CJK text turning into mojibake in terminals that deliver paste as per-byte extended-key events
Fixed /update over Remote Control hanging when a startup trust dialog would have shown
Fixed background jobs in the agents view getting stuck in "working" indefinitely when the agent ended a turn without producing structured output
Fixed channel connections dropping after navigating to the agents view and back, and after /bg, /tui, or /update
Fixed agent stop notifications not correctly attributing who stopped the agent, and improved wording ("finished"/"stopped" instead of "came to rest")
Fixed subagent depth tracking: resumed subagents now restore their original spawn depth, and forked subagents now count toward the depth cap
Fixed leaked agent worktree registrations: locked .git/worktrees/ entries from killed agents are now cleaned up automatically
Fixed Cmd+click not opening URLs in fullscreen mode in Ghostty on macOS
Fixed claude --help not listing the --bg/--background flag
Fixed Esc, Ctrl-C, and Ctrl-D not working while /share is uploading
Improved /install-github-app: GitHub Actions workflow setup is now optional — you can install just the GitHub App and skip the workflow/secret steps
Improved /btw with ←/→ arrow navigation to step through earlier answers
Improved /plugin to surface plugins you haven't used recently so you can clean them up
[VSCode] Fixed extension becoming unresponsive when resuming a large session
Oracle裁员2.1万人并大举借债押注AI，这既是AI替代人力的鲜活案例，也暴露了云巨头激进投资背后的财务风险，做投资和战略的该看看。
文章正文
根据周一美国证券交易委员会（SEC）的一份申报文件，AI使用量的增长导致甲骨文（Oracle）一年内裁减了21,000名员工。
在截至5月31日的财年年度监管申报文件中，Oracle表示其拥有141,000名全职员工。在其2025年的申报文件中，Oracle称拥有162,000名员工。此次报告的12.9%裁员幅度，此前3月已有报道称这家数据库管理软件公司进行了大规模裁员。
申报文件称：“AI技术在我们业务中的采用和部署已经导致，并可能继续导致员工规模的缩减。”
然而，此次裁员也与建设Oracle数据中心基础设施以支持AI工作负载所需的大额资本支出有关。
本周的申报文件称：“2026年重组计划所采取的大部分举措，都是为了落实我们对开发、营销、销售和交付云服务产品的持续重视。”
Oracle在2月表示，计划在2026年筹集450亿至500亿美元，以扩大其Oracle云基础设施，服务于OpenAI、xAI、AMD、Nvidia和Meta等客户。其中约一半资金将通过债务筹集，其余来自股权。当Oracle宣布这一计划时，投资者早已对Oracle因推动AI而不断增加的债务感到担忧。根据其2026财年财报，Oracle总债务超过1200亿美元。
路透社报道，2月份债券持有人起诉Oracle，声称他们蒙受损失，因为Oracle隐瞒了其需要增加债务以建设AI基础设施的事实。
投资者还对Oracle依赖OpenAI表示担忧，OpenAI是一家尚未盈利的客户，据报道每年亏损数十亿美元。
分析师指出，Oracle的裁员将有助于公司的现金流。据CNBC当时报道，3月份巴克莱银行（Barclays）表示，Oracle每位员工的利润低于其竞争对手。
Oracle在SEC申报文件中表示，其本财年重组成本支出为18亿美元，较上一财年的3.74亿美元增长了481%。
甲骨文也指出了大规模裁员常伴随的弊端，包括可能导致“生产力下降”、“某些岗位合格员工短缺、宝贵机构知识流失，以及对员工士气和留存率造成损害”。
甲骨文在给 CNBC 的一份声明中表示：“随着我们的云和 AI 业务不断增长，我们将持续平衡资源并重组研发团队，以确保我们拥有合适的人才，为全球客户提供最佳的云和 AI 产品。”
虽然生成式 AI 重新引发了人们对 AI 取代工作的担忧，但甲骨文展示了一种 AI 导致失业的方式，其方式超越了直接替代人类。话虽如此，企业在裁员时引用 AI 正变得越来越普遍。
职业过渡服务公司 Challenger, Gray & Christmas 的首席营收官 Andy Challenger 在 2026 年 5 月（报告于 6 月发布）的一份报告中表示：“AI 如今是公司裁员时给出的首要原因，而引用这一原因最多的行业是科技行业。科技行业已经是今年裁员最多的行业，其裁员幅度创下 2023 年初以来的最高水平，尽管它仍然是今年招聘计划最多的行业。”
这家职业过渡服务公司 1 月份报告称，从 2023 年到 2025 年，AI 被列为 71,825 项“裁员公告”的原因。
Scharon Harding 资深科技记者
Scharon 是 Ars Technica 的资深科技记者，负责撰写消费电子设备及服务的新闻、评论和分析。她从事科技报道已超过 10 年，文章曾发表于 Tom’s Hardware、Channelnomics 和 CRN UK。
上一篇报道
下一篇报道
1. 男子用按摩枪按摩疲劳的眼球。结果和你预想的一样糟。
2. 特朗普或成 79 岁老人接受实验性减肥药奇特病例中的神秘患者
3. 报告：肯尼迪航天中心尚未为超重型火箭时代做好准备
4. 通用汽车在裁减 1300 名员工后，在其旗舰电动汽车工厂安装机器人
5. 如何戳破 AI 泡沫：从根源入手
五眼联盟罕见联合预警，未来几个月 AI 将让网络犯罪自动化且更难识别，普通用户是直接目标而非旁观者，开启双重认证不能再拖了。
AI 与我们
顶级间谍机构警告：AI 网络威胁将在数月内影响你。原因如下
Dashveenjit Kaur
2026 年 6 月 23 日
分享这个故事：
标签：
AI 网络威胁 网络安全 五眼联盟警告 在线安全 网络钓鱼诈骗 科技新闻
分类：
AI 与我们 AI 在行动 AI 市场趋势 人工智能 网络安全 AI 信任、偏见与公平
全球范围内 AI 网络威胁的激增，对于企业数据中心而言，已不再是一个遥远的问题。世界上最强大的情报联盟发出紧急公开警告称，2026 年 6 月 22 日，五眼联盟——包括美国、英国、加拿大、澳大利亚和新西兰——的网络安全负责人发布了一份罕见的联合情报简报。简报指出，即将推出的人工智能模型将在数月（而非数年）的时间尺度上大幅增强攻击性黑客能力。
虽然该建议特别要求企业高管全面整顿其网络防御体系，但这些工具的快速演进意味着普通互联网用户即将面临一个更加诡谲多变的数字环境。
AI 网络威胁的巨大转变
这份情报简报强调了一个迫在眉睫的危险：即将推出的先进模型，如 OpenAI 的“GPT-5.5-Cyber”和 Anthropic 的“Mythos”，正在积极降低数字犯罪的技术门槛。恶意行为者不再需要顶尖的编码技能来构建复杂且具有毁灭性的软件漏洞利用程序。
相反，自动化数字智能体可以全天候扫描连接到互联网的基础设施，以便在人类工程师修补漏洞之前找到软件漏洞。这极大地缩短了技术公司赖以保持用户应用程序安全的“安全窗口期”。
这对普通用户有何切身影响？
当犯罪网络使用自动化工具攻破大型数据库时，其直接后果就是普通消费者数据的被盗。你的个人信息、已保存的密码和云备份，正是这些加速进行的企业入侵行为的最终目标。
此外，恶意行为者正利用对话式模型在工业规模上生成高度个性化的钓鱼诈骗。这一趋势对亚太地区打击尤为严重，由于人工智能辅助的目标锁定，印度等国家在2026年初的勒索软件事件激增了惊人的165%。
自动系统不再依靠容易被识别的、拙劣的垃圾邮件，而是可以扫描你的公开社交媒体资料，生成完美且极具说服力的消息，旨在窃取你的登录凭证。
用同样的技术进行反击
网络安全防御者面临的主要挑战是，机器驱动的攻击自然比人类主导的检测速度更快。根据世界经济论坛的《全球网络安全展望》，高达94%的企业高管将人工智能视为最大的威胁向量，然而三分之二的组织报告称存在中度到严重的网络安全人才短缺。
当恶意AI智能体能在几分钟内发现并利用软件漏洞时，网络管理员发现手动审查和部署传统安全补丁已变得不可能。
五眼联盟强调，抵御这些不断加速的AI网络威胁最有效的方法是部署自动化防御。安全团队正在积极集成防御型人工智能模型，以监控异常行为并隔离网络入侵。
对于个人用户而言，互联网安全的基本规则正变得强制性。开启多因素认证并删除旧的、不再使用的在线账户，仍然是打破AI驱动攻击自动链条的最有效方法。
另请参阅：AI网页搜索风险：减轻企业数据准确性威胁
想从行业领袖那里了解更多关于AI和大数据的信息？请关注即将在阿姆斯特丹、加利福尼亚和伦敦举办的AI与大数据博览会。这一综合性活动是TechEx的一部分，并与网络安全与云博览会等其他领先技术活动同期举行。点击此处了解更多信息。
AI News由TechForge Media提供技术支持。在此探索更多即将举办的企业技术活动与网络研讨会。
相关
利用Sakana AI的Fugu多智能体模型降低供应商锁定风险
2026年6月22日
欧莱雅将美宝莲虚拟试妆功能引入ChatGPT
2026年6月22日
SAP与Google Cloud部署智能体商务架构
2026年6月19日
e2e-assure推出Cumulo，英国唯一主权级、AI驱动、零日SOC平台，保障IT与OT环境安全
2026年6月19日
加入我们的社区
立即订阅，将我们所有高级内容和最新科技新闻直接送达您的收件箱
点击此处
热门
物理AI
Asylon与Thrive Logic将物理AI引入企业周界安全
7831次浏览
AI商业战略、人工智能、特色、金融AI、职场世界
摩根大通开始追踪员工在工作中如何使用AI
7308次浏览
AI实战、AI市场趋势、人工智能、人机关系、AI内幕、制造与工程AI、物理AI
Google正式官宣工业机器人AI战略——这次是认真的
6336次浏览
多模态AI
公民开发者如今有了自己的Wingman
6309次浏览
查看全部
最新
查看所有最新内容
零售与物流AI
2026年6月19日
SAP与Google Cloud部署智能体商务架构
赞助内容
2026年6月19日
e2e-assure推出Cumulo，英国唯一主权级、AI驱动、零日SOC平台，保障IT与OT环境安全
物理AI
2026年6月18日
计算机视觉部署助力零售业生产力提升
管理Cookie同意
我们使用cookie等技术来存储和/或访问设备信息。我们这样做是为了改善浏览体验并展示个性化广告。同意这些技术将允许我们在此网站上处理浏览行为或唯一标识等数据。不同意或撤回同意，可能会对某些功能和特性产生不利影响。
功能 始终启用
偏好
统计
营销
管理选项
管理服务
管理{vendor_count}家供应商
详细了解这些目的
查看偏好
{title}
{title}
{title}
所有高级内容和最新科技新闻直接送达您的收件箱
GitHub 联合 Hugging Face 等开源玩家公开呼吁修正加州 AI 透明法案，核心矛盾是许可撤销条款与开源许可的‘永久不可撤销’冲突，对开源开发者是个明确的政策信号，值得留意。
Margaret Tucker·@margaret-tucker
June 23, 2026
| 2 分钟
分享：
GitHub 已加入由 Black Forest Labs、Hugging Face 和 Mozilla Corporation 组成的开源联盟，呼吁对加州 AI 透明度法案（SB 942，如 SB 1000 所提议修正）进行有针对性的修订。在此阅读完整信函。
问题的核心是一个对开发者来说狭窄但重要的问题：根据目前的草案，该法案的许可证撤销条款与开源许可证在实际中的运作方式存在冲突。开源许可证被设计为永久且不可撤销，这使得开发者能够可靠地在不同项目和组织之间构建、重用和共享代码。
拟议的措辞将要求开发者在下游用户未能履行某些义务时撤销许可证。这种方法与广泛使用的开源许可证不兼容，并可能在整个软件供应链中引入不确定性——尤其是对于协作和社区驱动的项目。
该联盟的信函解释道，这一要求并非实现法案目标所必需。修改和部署 AI 系统的开发者已经直接受到法律约束，执法机制也已存在。同时，有一个可行的替代方案：与欧盟 AI 法案透明度实践准则的方法保持一致，该准则认可开源生态系统的独特性，并认为将文档中的最佳实践告知下游用户就已足够。
GitHub 支持这些修订，因为它们在保持与开源开发兼容性的同时，保留了法案的透明度目标。正确实现这一平衡对于确保加州继续同时支持 AI 问责制以及开放协作式创新至关重要。
行动号召
我们鼓励您仔细阅读这封信函，并与政策制定者分享您的观点。包含开源开发者和民间社会在内的清晰且基于技术的反馈，有助于确保 AI 透明度要求在实践中发挥作用，同时不损害作为 AI 创新基石的开源生态系统。
点击阅读完整信函。
标签：
政策
Helping build shared standards for advanced AI | OpenAI
June 23, 2026
Global Affairs
Helping build shared standards for advanced AI
Increasingly capable models can strengthen cyber defense, accelerate scientific discovery, and expand access to expertise. But they can also create safety and security risks if their capabilities are misunderstood, their safeguards are inadequate, or governments lack the information they need to respond. To realize the benefits safely and confidently, societies will need institutions with the technical and governance capacity to evaluate, secure, and govern increasingly capable systems.
That is one reason OpenAI helped found the Appia Foundation , hosted by the Linux Foundation. Appia will develop open, modular specifications intended to translate international standards and established frameworks into practical assessment criteria across the AI value chain. Its work can help develop a critical missing trust layer by which third parties check conformity with standards, producing clearer and more reusable evidence when models, infrastructure, and applications are developed by different organizations. In doing this work, Appia will help create a shared technical language that will allow national and international institutions to trust each other’s work.
We see this effort as an important next step in a broader body of work to strengthen the institutions, standards, and assessment practices needed for advanced AI systems.
Our recent blueprint for democratic governance of frontier AI offers a roadmap for that work. It calls for a durable U.S. framework, a strengthened Center for AI Standards and Innovation (CAISI), and a broader resilience strategy across government. It also recognizes that frontier risks are international in scope. Nations should work together to develop compatible safety frameworks, trusted channels for sharing risk findings, and coordinated responses to incidents.
National capacity and international cooperation should reinforce one another. Strong institutions such as CAISI can develop technical expertise, evaluate frontier systems, and support an independent assessment ecosystem. A network of capable national institutions can then establish shared methods, recognize trusted evidence, and give governments the common technical understanding needed to act together.
Standards are central to that effort, and they must be grounded in credible evaluation practice and technical rigor. In our shared playbook for trustworthy third-party evaluations, we set out what frontier assessments increasingly need to disclose: the system tested, its tool access and evaluation harness, the methods used to elicit capabilities, the resources available, and the checks performed to validate the results. We have also put these principles into practice through testing partnerships with US CAISI and UK AISI, whose work on frontier capability assessments and biological-misuse safeguards led to concrete improvements in our systems. This work serves an important function to create the foundation for practices that can be standardized to check performance in a comparable way.
These practices complement OpenAI’s broader safety infrastructure. Our Preparedness Framework is the foundation for how we define and operationalize our approach to managing the most serious risks from advanced AI systems, including our internal practices. Our Frontier Governance Framework applies relevant parts of that approach into a public governance document focused on specific regulatory obligations, including risk assessment, model reporting, security controls, incident response, and incorporating external expert input. Together, these artifacts help translate broad commitments into operational practices that can be validated and improved.
Appia’s work is aimed at the next challenge: making those practices interoperable across organizations, jurisdictions, and the supply chain.
OpenAI already contributes across a broader ecosystem of standards and pre-standardization efforts. We participate in the International Organization for Standardization and International Electrotechnical Commission Joint Technical Committee 1, Subcommittee 42 on Artificial Intelligence and the National Institute of Standards and Technology-led Artificial Intelligence Consortium ; helped found the Frontier Model Forum and the Linux Foundation’s Agentic Artificial Intelligence Foundation ; participate in the Coalition for Secure Artificial Intelligence ; serve on the steering committee of the Coalition for Content Provenance and Authenticity ; and engage in Internet Engineering Task Force and Fast Identity Online Alliance processes to advance interoperable technical standards.
Across these forums, including now through Appia, our goal is to translate lessons from frontier development into open, technically grounded practices that governments, companies, and independent assessors can use across jurisdictions.
2026
How Omio is building the future of conversational travel | OpenAI
June 23, 2026
How Omio is building the future of conversational travel
From AI-powered trip planning to company-wide transformation, Omio is working with OpenAI to reinvent how travel is discovered, booked and delivered.
Contact sales
00:00 01:50
Company size: Mid-market
Region: Global
Industry: Technology, Travel
Products: ChatGPT, Codex, API
3000+
Transportation providers connected through AI-powered travel experiences
47
Countries covered across Omio’s global transportation network
20%
Of previous development effort required to build new products
3 months → 1 month
From multiple developers over a quarter to one developer in a month
Moving from search to conversation
Omio is one of the world’s leading multimodal travel platforms, connecting millions of travelers with trains, buses, ferries and flights. The company works with more than 3,000 transportation providers across 47 countries. As travel becomes increasingly digital, Omio is reimagining how people discover and book journeys through conversational AI.
As consumer expectations shift toward conversational interfaces, Omio saw an opportunity to rethink how travel discovery works. Traditional travel planning often requires navigating multiple websites, comparing transportation modes, and piecing together itineraries across providers. Omio believed AI could create a fundamentally different experience—one where travelers simply describe where they want to go and receive personalized, bookable journeys in return.
As an early OpenAI customer and partner, Omio became one of the first travel companies to experiment with conversational travel experiences powered by real-time transportation data. At the same time, the company recognized that the same technology reshaping customer experiences could transform how work gets done internally.
We sat down with Tomas Vocetka, Omio’s CTO, to discuss the company’s vision for conversational travel, its journey toward becoming AI-native, and how OpenAI is helping accelerate innovation across both customer experiences and internal operations.
Bringing conversational travel to life
In 2023, Omio launched one of the earliest travel experiences available through ChatGPT, connecting OpenAI models directly to Omio’s transportation inventory and booking systems.
The integration enabled travelers to ask natural-language questions such as “What’s the fastest route from Rome to Florence?” or “Should I take a train or flight from Paris to Barcelona?” Rather than relying on static information, the experience connected ChatGPT to live transportation inventory and pricing data, helping users discover real, bookable journeys through conversation.
More recently, Omio expanded that vision with a dedicated ChatGPT experience built on OpenAI models and connected to its global transportation network. By grounding responses in verified travel data, the company is helping building towards a new category of conversational commerce where AI serves as the interface layer between customers and real-world transportation systems.
For Omio, conversational travel is not simply a new feature. It represents a broader shift from search-based interfaces to AI-native customer experiences.
Inside the rollout
While Omio was building AI-powered experiences for travelers, it was also transforming how teams operate internally.
The company began by rolling out ChatGPT to employees across the organization, enabling teams to experiment, learn, and identify opportunities to improve their work. As adoption matured, Omio expanded into Codex, embedding it deeply into engineering workflows and increasingly extending it to non-technical functions.
“We rolled out ChatGPT. That was a teaser. Codex is where the real work gets done.”
—Tomas Vocetka, CTO, Omio
Today, every engineer uses Codex throughout the software development lifecycle—from research and planning to coding, testing, code reviews, monitoring, and maintenance. Omio is also building custom integrations and connectors that bring internal systems, data, and workflows directly into AI-powered tools, allowing employees to move beyond information retrieval and into execution.
The company’s broader goal is to become AI-native—not by layering AI onto existing processes, but by rethinking how work gets done from the ground up. “All functions need to rethink how they do the work” explains Vocetka.
That mindset has already reshaped the way Omio builds products. Teams are able to move from idea to execution significantly faster, reducing the cost and effort required to test new concepts and validate customer needs.
Omio estimates that many products can now be built in roughly 20% of the time previously required. “Projects that used to take several developers a quarter can now be done by one developer in around a month.” says Vocetka. Faster development cycles have enabled more experimentation, quicker decision-making, and a greater ability to test and refine ideas before making larger investments.
Throughout the transformation, Omio has maintained a clear principle around responsible deployment.
“The responsibility and accountability stay with people. AI helps us develop faster, analyze faster, and make decisions faster, but people stay in charge.”
—Tomas Vocetka, CTO, Omio
By combining broad access to OpenAI tools with strong governance and human oversight, Omio is creating an operating model where AI accelerates execution while employees remain accountable for outcomes.
Results at a glance
Built one of the earliest conversational travel experiences on ChatGPT
Connected OpenAI models to 3,000+ transportation providers across 47 countries
Reduced product development effort to approximately 20% of previous levels
Accelerated projects from one quarter to roughly one month
Expanded AI adoption beyond engineering into business functions across the company
Enabled faster experimentation, product iteration, and decision-making
Leadership lessons
Treat AI as a business transformation initiative, not a technology project
Drive adoption from the top while enabling experimentation throughout the organization
Focus on redesigning workflows rather than simply automating existing tasks
Maintain human accountability while using AI to accelerate execution
View AI as both a product strategy and an operating model
What’s next
Omio sees AI reshaping both sides of its business.
Externally, conversational interfaces are changing how travelers discover, compare, and book transportation. Internally, AI is becoming a foundational layer for how teams build products, make decisions, and operate at scale.
The company believes the future of travel will be less about navigating search results and more about interacting with intelligent systems connected directly to live transportation networks.
“It’s changing how we work, what we build, how we build, and how we operate.”
—Tomas Vocetka, CTO, Omio
As Omio continues expanding its AI-native approach, the company is helping define what conversational commerce looks like in travel—combining OpenAI models with real-world transportation infrastructure to make travel planning faster, simpler, and more personalized.
For Omio, becoming AI-native is not a future ambition. It is an active transformation already changing how travel is discovered, booked, and delivered today.
Join the new era of work
More than 1 million businesses around the world are achieving meaningful results with OpenAI.
Contact sales
这个Chrome提案让不同网站的AI模型共享缓存，对用Transformers.js的Web开发者是切实的性能改进，但还只是早期实验。
实验性：在 Transformers.js 中使用提议的跨源存储 API
发布于 2026 年 6 月 23 日
Thomas Steiner
tomayac
(This is a guest post by Developer Relations Engineer Thomas Steiner from the Chrome team at Google.)
Transformers.js 为 Web 开发者提供了一种简单的方法，通过特定任务的流水线（pipeline）在其 Web 应用中使用 Transformer 架构的强大能力。为了在浏览器中运行推理，开发者创建 pipeline() 的实例并指定他们想要使用的任务。作为一个具体示例，以下代码片段展示了如何设置自动语音识别（ASR）流水线。
import { pipeline } from 'https://cdn.jsdelivr.net/npm/@huggingface/transformers@4.2.0';
const asr = await pipeline(
'automatic-speech-recognition',
'Xenova/whisper-tiny.en',
{ device: 'webgpu' },
);
const result = await asr('jfk.wav');
console.log(result);
缓存挑战
你会注意到在源代码中，我指定了 Xenova/whisper-tiny.en 作为模型，这对于常见的英语自动语音识别任务来说是一个非常合适的选择。事实上，根据引用的片段，按照 Transformers.js 默认模型解析规则，它甚至是默认模型。
模型资源
当你在浏览器中运行这个示例时，Transformers.js 会自动下载并缓存相关的模型资源和 Wasm 文件。以下截图显示了访问该应用后的 Chrome DevTools 缓存存储部分。当你重新加载页面时，资源会从 Cache API 中提供，模型几乎立即返回结果。
然而，Xenova/whisper-tiny.en 是一个流行的模型（并且如前所述，甚至是 Transformers.js 中的 ASR 默认模型），你可以想象不止一个你访问的应用会使用它。为了模拟这种情况，这里提供了与之前相同的示例应用，但通过不同的源（origin）提供服务。当你访问这个不同源的应用时，浏览器无法几乎立即使用它，而是必须重新下载并缓存所有模型资源，即使这些资源与之前的逐字节完全相同。即使在这个玩具示例中，这也会导致 177 MB 的重复下载和存储，你可以在 Chrome DevTools Application 面板的 Storage 部分中查看。你可以想象这很快就会累积起来。
Wasm 运行时资源
但情况更糟。让我们给这个玩具示例添加第二条管道：情感分析。情感分析默认使用 Xenova/distilbert-base-uncased-finetuned-sst-2-english 模型。由于没有指定模型，Transformers.js 的默认模型解析机制会自动为你选择它。
const classifier = await pipeline('sentiment-analysis');
const sentiment = await classifier(result.text);
pre.append('\n\n' + JSON.stringify(sentiment, null, 2));
两个完全不同的 AI 模型，但它们都依赖同一个 4,733 kB 的 ort-wasm-simd-threaded.asyncify.wasm 文件——这是来自 Transformers.js 底层 ONNX Runtime 库的 WebAssembly（Wasm）运行时文件。在另一个源（origin）上打开扩展演示时，你会在“网络”标签页中注意到 Wasm 运行时也会被重新下载并再次缓存。
因此，即使你运行的应用不共享相同的 AI 模型，浏览器仍会对你已拥有的共享 Wasm 资源发出冗余请求，而且还会再次缓存它们，从而占用你硬盘上的空间。
缓存隔离
AI 模型资源分发
默认情况下，AI 模型资源来自 Hugging Face Hub，最终来自 Hugging Face CDN。浏览器会请求像 `https://huggingface.co/Xenova/distilbert-base-uncased-finetuned-sst-2-english/resolve/main/config.json` 这样的资源，然后该请求会被重定向到最终的 CDN URL，例如本例中的 `https://huggingface.co/api/resolve-cache/models/Xenova/distilbert-base-uncased-finetuned-sst-2-english/0b6928efcb76139cae2c6881d49cda67fe119f42/config.json?%2FXenova%2Fdistilbert-base-uncased-finetuned-sst-2-english%2Fresolve%2Fmain%2Fconfig.json=&etag=%223c36342ef1f74de2797d667c68c6b7b988d0b87c%22`。
Wasm 运行时资源分发
Wasm 运行时资源默认由 jsDelivr CDN 提供服务。例如，在撰写本文时，`ort-wasm-simd-threaded.asyncify.wasm` 来自 `https://cdn.jsdelivr.net/npm/onnxruntime-web@1.26.0-dev.20260416-b7804b056c/dist/ort-wasm-simd-threaded.asyncify.wasm`。
你可能会说，如果不同应用虽然运行在不同源上，但最终都从同一个 CDN URL 提供资源，那么只要最终 URL 相同，缓存应该不是问题。遗憾的是，很长一段时间以来浏览器缓存的运作方式并非如此。《通过分区缓存提升安全性和隐私性》这篇文章详细解释了所有细节，但本质上，缓存是按源隔离的，以防止时序攻击：网站响应 HTTP 请求所用的时间可能会暴露浏览器过去是否访问过同一个资源，这使得浏览器容易遭受安全和隐私泄露。
Chrome 的实现
具体实现可能因浏览器而异，但在 Chrome 中，缓存资源除了按资源 URL 索引外，还会额外使用网络隔离键（Network Isolation Key）进行键控。网络隔离键由顶层站点（top-level site）和当前帧站点（current-frame site）组成。以之前托管在源 `https://googlechrome.github.io` 和 `https://rawcdn.rawgit.net` 上的玩具示例为例。如果它们都使用来自 `https://cdn.jsdelivr.net/npm/onnxruntime-web@1.26.0-dev.20260416-b7804b056c/dist/ort-wasm-simd-threaded.asyncify.wasm` 的 Wasm 运行时，那么它们的缓存键将如下表所示。
网络隔离键 资源 URL
顶层站点 当前帧站点
https://googlechrome.github.io
https://googlechrome.github.io
https://cdn.jsdelivr.net/npm/onnxruntime-web@1.26.0-dev.20260416-b7804b056c/dist/ort-wasm-simd-threaded.asyncify.wasm
https://rawcdn.rawgit.net
https://rawcdn.rawgit.net
https://cdn.jsdelivr.net/npm/onnxruntime-web@1.26.0-dev.20260416-b7804b056c/dist/ort-wasm-simd-threaded.asyncify.wasm
因此，即使资源 URL 完全相同，由于网络隔离键不匹配，也不会出现缓存命中，这意味着重复下载和重复存储。这正是跨源存储提案试图解决的挑战。
跨源存储 API 登场
💡 注意：跨源存储 API 是一项早期阶段的提案，尚未最终定稿。虽然提议的 API 尚未在任何浏览器中原生实现，但你无需等待即可进行实验。安装 Cross-Origin Storage 扩展，即可在所有页面上注入 `navigator.crossOriginStorage` 的 polyfill，并测试完整流程。
提议的跨源存储（COS）API 引入了一个专用的 `navigator.crossOriginStorage` 接口，通过该接口，Web 应用可以跨源边界存储和检索大文件，这些文件不由 URL 标识，而是由加密哈希标识。
关于加密哈希的最后一点很关键。因为 COS 通过哈希值而非 URL 或来源来标识文件，所以当你访问 https://googlechrome.github.io 时下载的同一个 `ort-wasm-simd-threaded.asyncify.wasm` Wasm 运行时，会被识别为与 https://rawcdn.rawgit.net 即将请求的文件相同，无论这两个来源是从哪里获取的。请看以下代码片段，它展示了基本流程。
const hash = {
algorithm: 'SHA-256',
value: '8f434346648f6b96df89dda901c5176b10a6d83961dd3c1ac88b59b2dc327aa4',
};
try {
const handle = await navigator.crossOriginStorage.requestFileHandle(hash);
const fileBlob = await handle.getFile();
} catch (err) {
const fileBlob = await fetch('https://cdn.jsdelivr.net/.../ort-wasm-simd-threaded.asyncify.wasm')
.then(r => r.blob());
const handle = await navigator.crossOriginStorage.requestFileHandle(
hash,
{ create: true, origins: '*' },
);
const writableStream = await handle.createWritable();
await writableStream.write(fileBlob);
await writableStream.close();
}
如果该资源存在于 COS 中，你将获得一个 `FileSystemFileHandle`，通过 `getFile()` 可直接从中读取 blob（得到的 `File` 继承自 `Blob`）。如果资源不在 COS 中，则回退到网络，并将该资源写入 COS，供下一个需要它的应用使用——这个应用可能是你的应用，也可能是另一个无关的应用，甚至可能来自完全不同的来源。
该 API 刻意模仿了文件系统标准中的 `FileSystemDirectoryHandle.getFileHandle()` 方法，你很可能从源私有文件系统（OPFS）API 中熟悉它。哈希参数的作用与 OPFS 中的名称参数相同：唯一标识一个资源。`options.create` 标志的工作方式也相同：缺失或为 `false` 表示只读访问，为 `true` 则表示你打算写入。
控制谁可以读取什么
并非所有资源都应该全局共享。COS 通过存储文件时的 `origins` 选项，让开发者能够精确控制可见性。
设置 `origins: '*'` 可使文件全局可用。任何来源都可以通过哈希找到它。这对于 AI 模型资源或 Transformers.js 示例中的 Wasm 运行时来说是正确的选择：关键在于，所有网络应用都能从单一缓存副本中受益。
传入一个明确的来源列表，例如 `origins: ['https://write.example.com', 'https://calculate.example.com']`，则限制只有这些站点能访问。这种做法适用于公司自有资产之间共享的专有资源（不应被其他任何人发现），比如商业办公套件中使用的专有校对 AI 模型。
完全省略来源会使该文件仅对同站点来源可用。这对于跨组织所有子域共享的资源来说是合理的默认设置，但并非旨在跨越组织边界使用。
一条重要规则：可见性可以升级，但绝不能降级。如果某个文件已经全局可用，后续尝试用受限来源列表存储该文件的操作会被静默忽略。这可以防止恶意行为者重新存储公共资源并缩小其可用范围。相反的情况是允许的：最初以受限来源列表存储的文件，之后可以放宽其权限。任何站点（而不仅仅是原始存储者）都可以针对同一哈希（哈希并非秘密）调用 `requestFileHandle()`，并传入 `create: true` 以及范围更广的 origins 值，且由于浏览器会验证哈希匹配，该资源从此便可供更广泛的受众使用。请注意，执行升级的站点仍然需要通过返回的句柄写入完整文件。这一要求是为了防止站点利用升级路径作为侧信道来检测特定文件是否已存储在 COS 中。
设计中的完整性保障
COS 一个微妙但重要的特性是，当您写入文件时浏览器会验证哈希值。如果您写入的数据与声明的哈希值不匹配，写入操作会失败并报错。这使得完整性检查自动化：从 COS 读取文件的应用程序可以确信它获取的正是预期的字节。这与它通过网络下载后自行计算哈希值所能获得的保证相同。
事实证明，这一点在 Transformers.js 场景中具有双重作用。如今，大多数应用程序在下载模型权重后，实际上没有办法验证 CDN 是否提供了正确的字节。而使用 COS，存储中的每个文件在写入时都会被隐式验证，无论它来自何处——无论是官方的 Hugging Face CDN 还是某个随机站点的自建镜像。
不牺牲实用性的隐私保护
当然，跨源共享缓存反过来也提出了与分区HTTP缓存相同的问题：如果任何网站可以通过哈希值探测某个文件是否存在，那么攻击者难道不能通过检查某个游戏引擎的Wasm模块是否被缓存，来了解用户的浏览历史吗？
COS通过两种互补机制来解决这个问题：
首先，origins字段：不应被全局探测的专有资源，就不应该使用 origins: '*' 来存储。通过开发者教育，我们鼓励开发者在任何合理的情况下都考虑这一点。
其次，可用性门控：即使对于全局声明的文件，如果浏览器还未在足够数量的不同源上遇到该文件，它也可能抑制对文件存在的确认。仅在一两个网站上出现的文件仍可能作为跨站标识符，因此浏览器可能会返回错误，就好像该文件根本不存在一样，无论磁盘上实际是否有存储。在Chrome团队中，我们意识到不常见资源可能导致的隐私泄露，并计划通过限制具体哪些资源可以被缓存来普遍缓解这一问题。具体的缓解措施仍在完善中。
关键在于，这意味着错误并非确定的答案。它可能表示“未存储”，也可能表示“已存储，但浏览器不告诉你”。应用应始终以相同方式处理：回退到网络。
这对Transformers.js示例意味着什么
回到之前的玩具示例：`ort-wasm-simd-threaded.asyncify.wasm` 运行时大小为 4,733 kB，且被所有基于 Transformers.js 的应用共享，无论它们使用哪个 AI 模型。有了 COS，第一个加载该文件的应用会将其下载一次，并以 SHA-256 哈希为键、`origins: '*'` 为策略存储起来。之后每个其他应用，无论位于 `https://googlechrome.github.io`、`https://rawcdn.rawgit.net` 还是其他任何域名，都能立即在 COS 中找到它。那 177 MB 的重复 Whisper 模型权重呢？同理：`Xenova/whisper-tiny.en` 只会被下载一次，第二次再遇到时通过哈希识别，直接从 COS 中以毫秒级速度提供服务。当然，`Xenova/distilbert-base-uncased-finetuned-sst-2-english` 也是一样的情况。
Transformers.js 本身已经在库级别试点了 COS API。Pull Request #1549 引入了一个实验性的 COS 缓存后端，通过一个可选启用标志来控制。只需在设置 pipeline 之前添加一行代码即可启用：
import { env, pipeline } from "https://cdn.jsdelivr.net/npm/@huggingface/transformers@4.2.0";
env.experimental_useCrossOriginStorage = true;
const asr = await pipeline('automatic-speech-recognition', 'Xenova/whisper-tiny.en', { device: 'webgpu' });
const result = await asr('jfk.wav');
console.log(result);
设置该标志后，Transformers.js 会通过获取原始 Xet 指针（示例原始指针文件）并提取其中的 `oid sha256:` 字段，来解析每个由 Xet 跟踪的模型文件（即大型 ONNX 权重文件）的 SHA-256 哈希。然后它将该哈希用作 `navigator.crossOriginStorage` 的键。如果模型已经存在于 COS 中（因为其他网站之前已将其存入），则无需网络往返即可立即提供服务。如果不存在，则回退到常规下载，并将结果存入 COS 以供后续调用者使用。以玩具示例为例，实际优势在于：`Xenova/whisper-tiny.en`、`Xenova/distilbert-base-uncased-finetuned-sst-2-english`（当然还有 `ort-wasm-simd-threaded.asyncify.wasm`）无论被多少个不同域名请求，都只需从网络中传输一次。
注意标志上的 `experimental_` 前缀。这是有意为之，表示底层浏览器 API 尚未标准化，且可能在不进行主版本号更新的情况下发生变化。
今天就试试吧。
COS API 尚未在任何浏览器中原生实现，但您无需等待即可进行试验。安装 Cross-Origin Storage 扩展，在所有页面上注入 navigator.crossOriginStorage polyfill，并测试完整流程。您可以查看扩展的源代码并按照使用说明开始使用。
安装扩展后，您可以立即体验完整的端到端流程：打开第一个启用了 COS 的玩具示例，让它加载 Xenova/whisper-tiny.en，然后从第二个源打开启用了 COS 的玩具示例。模型不再像之前那样需要重新下载 177 MB，而是通过 COS 在毫秒级别提供。当您打开扩展的弹出窗口时，可以看到 COS 的运行情况。如果按资源查看，您会看到 SHA-256 哈希值为 950978b1dbcbf250335358c1236053ba19a7f7849b33dc777f4421b72b7626fa 的资源在 https://googlechrome.github.io 和 https://rawcdn.rawgit.net 之间共享。这可能不太明显，但您可以通过对比 Hugging Face 上的 SHA-256 哈希值来验证，您看到的是 https://huggingface.co/Xenova/whisper-tiny.en/blob/main/onnx/decoder_model_merged.onnx。目前，该扩展主要面向像您这样的高级用户。一旦在浏览器中实现，浏览器设置页面将提供更友好的集成。以下截图显示了扩展的弹出窗口，其中"按资源查看"选项卡处于活动状态，您可以看到共享资源及其哈希值，以及两个在各自 COS 缓存中拥有该资源的源。
行动号召
如果您正在构建自己的 Transformers.js 应用，行动号召很简单：在首次调用 pipeline() 之前，添加 env.experimental_useCrossOriginStorage = true，安装扩展，然后看着重复下载从"网络"选项卡中消失。每个选择加入的站点都会让其他站点的用户体验更快、成本更低。选择加入完全没有风险：如果用户没有安装 COS 扩展导致不支持 COS API，代码会默认回退到默认路径（Web Cache API）。
Transformers.js 并非唯一在尝试 COS 的项目。WebLLM（可选启用，详见文档）和 wllama（自动启用，参见 PR）同样对这一提议的 API 感到兴奋。
在 Chrome 团队，我们正在考虑在浏览器中原生实现 COS API。作为一个早期阶段的提议，我们欢迎大家对 API 本身以及提议形态提出反馈。Cross-Origin Storage 仓库是提交问题、表达支持或发起 PR 的地方。
本文提及的模型 2
博客更多文章
guidetransformers.jsjavascript
如何在 Chrome 扩展中使用 Transformers.js
39
April 23, 2026
announcementtransformers.jstransformers
Transformers.js v4：现已可在 NPM 上获取！
96
February 9, 2026
社区
· 或发表评论
本文提及的模型 2
Smart glasses like the Ray-Ban Meta and Oakley Meta Vanguards need to pack enough energy to power features like cameras, speakers, AI workloads, and even a display. But it all has to fit into the glasses’ temple arms.
So how do you place a battery with enough power to run a pair of smart glasses all day into a form factor narrower than an adult’s pinky finger? You have to rethink how batteries are made.
In episode 86 of the Meta Tech Podcast, host Pascal Hartig sat down with Karthik and Myuran, the engineers behind Meta’s steel can battery technology, for a conversation on powering the newest and next generation of wearables.
Why Traditional Batteries Fall Short for Smart Glasses
Traditional pouch cells — the batteries in most phones and laptops– can’t cut it for devices like smart glasses because they’re difficult to reshape and shrink down. Their folds waste volume, their tolerances eat into precious millimeters of space, and at smaller sizes they can difficulty providing peak power for multitasking (for example, if someone is using the camera and asking the AI model to perform a task at the same time).
Smart glasses need a battery that can claim every micron of space – something rigid, precise, and shaped to the product rather than the other way around.
Enter Steel-Can Cells (at Never-Before-Seen Widths)
Steel-can batteries aren’t new. Power tools and watches use them. But Meta’s AI glasses needed batteries with widths as narrow as 7mm, narrower than anything that existed before. Getting there meant rethinking nearly every internal component of the battery.
The Electrode Architecture
Traditional steel-can cells use a wound “jelly roll” of electrode material. Meta’s engineers replaced that with die-cut stacked layers, similar to wiring small resistors in parallel. The result is dramatically lower impedance, which matters when peak power is required so that the device can avoid brownouts if a lot of power is being demanded at the same time (because someone may be making a recording while asking the AI a question at the same time).
Tolerances
A steel-can cell holds its shape to roughly 100 microns. On a 10mm-wide battery, that gives back real usable volume that translates directly into additional energy density and runtime.
New Challenges With Each Generation
From Gen 1 to Gen 2 the Meta Ray-Ban’s, cell capacity grew from 160 mAh to 210 mAh — roughly a 30 percent bump. Yet the product shipped with claims of double the runtime. The chemistry didn’t change. The extra gains came from system-level efficiency improvements across hardware and software such as better power management, tighter firmware control, and a form factor that allowed for a larger cell
The Oakley Meta Vanguards actually feature a battery in each temple arm, which introduced a real systems puzzle at the intersection of electrical, firmware, and mechanical engineering. The cells in each temple arm are symmetric, but the electronic loads aren’t split evenly between the two sides. That creates cross-charging risks and sequencing complexity at boot and shutdown.
Then the Meta Ray-Ban Display glasses introduced the most demanding power profile yet. Its screen draws sustained power rather than short bursts, which required designing a 248 mAh steel-can cell, the largest in Meta’s lineup.
More Power to the Wearables
The ultra-narrow steel-can approach we developed for our smart glasses is proving adaptable to other form factors across Meta’s hardware portfolio.
Meta is now focused on scaling and democratizing this technology across multiple vendors, ensuring we have resilient supply and can bring these batteries to the next generation of wearables.
Listen to the full episode to hear the complete story — from first sketch to global shelf — including details on cross-charging two-battery systems, software versus hardware iteration cycles, and what it’s really like to collaborate across time zones to build something the world has never seen.
Listen now
You can also find the episode wherever you get your podcasts, including:
Spotify
Apple Podcasts
PocketCasts
Timestamps
0:06 — Intro and News
1:49 — Guest intros
4:16 — The problem with existing batteries
6:40 — Pouch vs. steel-can batteries
10:27 — What lower impedance means
12:25 — Power requirements
16:02 — Synchronizing two batteries
23:11 — Manufacturing never-done-before batteries
28:12 — Software vs. hardware iteration cycles
30:51 — Collaborations across the globe
37:00 — Market compliance
42:24 — Outro
The Meta Tech Podcast is a podcast, brought to you by Meta, where we highlight the work Meta’s engineers are doing at every level – from low-level frameworks to end-user features.
Send us feedback on Instagram, Threads, or X.
And if you’re interested in learning more about career opportunities at Meta visit the Meta Careers page.
Agent identity in Claude Tag: a new access model for autonomous, team-wide AI
How Claude Tag’s agent identity access model works, and best practices for configuring it in your team’s workspace.
Category
Claude Code
Product
Claude Tag
Date
June 24, 2026
Reading time
5
min
https://claude.com/blog/agent-identity-access-model
For an AI agent to do its best work on a human-agent team, it needs access to the same tools, documents, and context humans have.
In a “single player” AI experience (where one person chats with one assistant), that’s straightforward: you connect your own accounts and the agent acts on your behalf. But in a “multiplayer” AI experience like Claude Tag, Claude sits in a shared channel alongside many people at once, and it draws on the tools and context that belong to the workspace, rather than any one individual.
To make multiplayer experiences work, Claude needs its own accounts for those tools, set up by an admin and tied to the workspace. We call this access model agent identity.
In this post, we explain how agent identity works, how it moves permissions from per-user to per-channel, and how to scope it well in your own workspace.
Why “act as the user” breaks down
When you use AI as a personal assistant, you can connect platforms like Google Drive, GitHub, and your calendar, and let the model use your access permissions to read and write in them.
This model doesn’t work for Claude Tag for two reasons:
Increasing agent autonomy. The length of a task that an AI agent can reliably complete on its own has been doubling roughly every four months. Agents now schedule their own tasks for later and respond to events long after the person who asked has logged off. While users set up routines that trigger them to act given certain situations, the agent works largely autonomously.
Multiplayer teams. Claude Tag places Claude in shared spaces where teams are already working—e.g., a channel where three engineers and a PM are debugging together. But when more than one person is steering, whose permissions apply? There’s no single choice of person that’d be right all of the time. This gives admins the ability to define what an agent can do in Slack independent from the humans involved, and a distinct tracking of what is done in Slack.
Claude acts as itself
In a channel where Claude Tag is active, Claude isn’t acting on behalf of a single user. It has its own account in each system it touches: it posts in Slack as the Claude app, opens pull requests as the Claude GitHub App, and queries your warehouse under a service account provisioned by an admin.
And because there are no personal user credentials in play, a shared channel can never become a side door into someone’s private documents.
Inheriting permissions
In the agent identity model, admins define an identity—the baseline set of connections and skills Claude holds everywhere—at the workspace level, and every channel inherits it by default. Then, where it makes sense, they can override it at the channel level, such as by granting the engineering channel access to GitHub and the data warehouse, or confining a CRM connection to a single private channel.
In addition to credentials, admins also define:
Repository access: which repos Claude can read and write to.
Connectors: the tools and API keys that Claude uses to do its job. Across an organization, different API keys can connect to the same service at different permission levels (e.g., Claude might be given read-only warehouse access in a general channel, and write access in the data team’s private one).
Skills and plugins: folders of instructions, scripts, and resources Claude loads dynamically to improve performance on specialized tasks.
Standing instructions: custom instructions and context for each channel.
Because this model works around distinct Claude identities, revoking the identity ends Claude’s access everywhere that the identity was used. This takes much less effort to manage than auditing individual agent actions across dozens of user accounts.
How the agent identity model works
Agent identity replaces the question “what can this user do?” with “what can this agent do in this compartment?” That’s a departure from per-user Access Control Lists: it means that a channel member without direct access to the repo can ask Claude to read that repo, if the channel’s profile grants Claude that permission.
This is unusual, but we think it is a necessary step toward an access model that works for autonomous, multiplayer agents. Below, we sketch out how to think about setting those boundaries.
How identity boundaries work
Claude Tag creates a distinct identity for each private channel; public channels in a workspace share a workspace-level identity. Claude's identity in a legal channel can't reach code that wasn't granted there, and its identity in an engineering channel can't read legal documents that weren't granted there. Memory and access respect those boundaries: what Claude learns in a private channel never appears in the wider workspace.
The identity belongs to the channel, so anyone in it can tag Claude by default, and admins can scope each channel's profile to the least-privileged member. On Enterprise plans, role-based access control lets admins go further and decide which members can invoke Claude at all, so a channel governs both what the agent can reach and who can ask.
Broad default access to tools and context
How teams scope Claude's tool access in Claude Tag: broad, low-risk integrations run in shared channels under an agent identity, while personal or team-specific tools stay in DMs and run as the user.
Running Claude Tag inside Anthropic, we found that its value compounds with tool and context access. Each connected system makes every other one more useful, because Claude can combine context across them—pulling a thread from Slack, a doc from Drive, a ticket from a tracker, and a query from a warehouse into one answer that no single tool could provide.
The teams that get the most out of Claude are the ones that grant it generous access from the start, and pare access back depending on their organization’s admin preferences. Agent identity gives admins broad enough scope for Claude to do useful cross-system work, with boundaries firm enough that the access never travels somewhere it wasn’t granted. Our advice is to start with a baseline profile in a few channels, read the audit trail, and then extend access where the work justifies it, one deliberate grant at a time.
For organizations that require even more granularity, admins can disable Claude Tag in specific channels. Admins can also apply role-based access controls (RBAC) to limit access to Claude Tag to specific users.
Direct messages
With Claude Tag, direct messages work differently than in shared channels. DMs run on users’ individual claude.ai accounts—their connectors, credentials, and name on the result. This makes DMs the right place to work with Claude on tasks and with tools that should never live in a channel, like email drafts or software only you have a license for.
Security and audit
When an admin adds a connection to a channel's profile, the credential is stored independently and mapped to that channel's identity, then injected at the network boundary at request time. Outbound traffic to any host an admin hasn't allowed is blocked outright. On the audit side, every routine, memory write, and network call made with agent credentials is recorded, and because Claude acts under its own service accounts, those actions also land in each connected system's own logs.
What’s next
Agent identity is the foundation of Claude Tag's access model. In the future, we plan to strengthen our Claude Tag’s security offerings to include just-in-time credential grants—so that a user can approve a single sensitive action in the moment without permanently widening the agent's scope—and an identity-aware overlay for organizations with more complex clearance structures. This will add user-level checks on top of an agent’s scope, so Claude only acts when both the channel's profile and the requesting user's own permissions allow it.
The shift from single player to multiplayer AI in products like Claude Tag makes long-running, team-based work possible. Agent identity ensures that Claude’s access to tools is broad enough to be useful, but scoped enough to be secure at enterprise scale.
Learn more about Claude Tag.
This article was written by Noah Zweben, a member of technical staff on the Claude Code team.
No items found.
Prev
0/5
Next
eBook
FAQ
No items found.
Transform how your organization operates with Claude
See pricing
Contact sales
Get the developer newsletter
Product updates, how-tos, community spotlights, and more. Delivered monthly to your inbox.
OpenAI
June 23, 2026
Applied AI
How GPT‑5 helped immunologist Derya Unutmaz solve a 3-year-old mystery
The model’s ability to augment human expertise could help advance fields including cancer research, autoimmune disease, and infections.
Loading…
Doctor and immunologist Derya Unutmaz has been interested in artificial intelligence for years. But his “aha” moment came in late 2025, when GPT‑5 Pro helped him and his lab revisit a three-year-old puzzle centered on a special type of immune cell that helps the human body fight cancer and other illnesses.
The mystery centered on a basic but consequential question in immunology: how does glucose affect the way T cells develop and specialize? T cells are immune cells that help the body fight viruses, kill cancerous cells, respond to some bacteria and parasites, and distinguish healthy cells from threats. As they develop, they take on different jobs, including roles that can shape cancer, autoimmune disease, and infection. Understanding what pushes T cells toward one specialization or another could help researchers better understand, and eventually, better treat those diseases.
Today, Unutmaz—a professor at The Jackson Laboratory and the University of Connecticut—says AI has become so central to his work that he can’t imagine doing science without it. “That would be like taking both of your hands away, or half of your brain away,” Unutmaz said.
The puzzle began in 2022, when Unutmaz performed an experiment trying to understand how a type of sugar called glucose affected the development of T cells. The cells use glucose as a fuel source, but also to build proteins and carry out other functions.
The results of Unutmaz’s experiment could have implications for ailments like cancer, autoimmune disease, and infections. But at the time, Unutmaz and his lab couldn’t make sense of what they were seeing.
Solving a problem with GPT‑5 Pro
Previous studies provided strong evidence that glucose metabolism influenced how T cells specialize. To better understand this relationship, Unutmaz and his team exposed T cells early in their development to either a low-glucose environment or to one containing a glucose-like molecule called deoxyglucose. Deoxyglucose interferes with a cell’s ability to use glucose, disrupting energy production and protein construction. Proteins matter because they coordinate activity within a cell and act as messengers that send and receive information outside the cell.
The team expected the two conditions to produce similar results. In both cases, glucose, and therefore the energy the T cells needed to function, would be limited. But that’s not what happened.
The T cells exposed to deoxyglucose overwhelmingly produced cells involved in the body’s inflammatory response. Some of the T cells exposed to low concentrations of glucose specialized as inflammatory-response cells, but not at the numbers seen for deoxyglucose. The effects of early exposure to deoxyglucose persisted even when researchers removed the glucose-like molecule.
This difference couldn’t be attributed to a lack of energy alone. Something else was going on. But Unutmaz and his lab were unable to figure out what was happening, so they shelved the experiment and moved on to other urgent tasks that needed their attention.
Then GPT‑5 Pro came out in late 2025 and Unutmaz decided to resurface the experiment. He uploaded the results into the model and asked it to analyze the data.
GPT‑5 Pro suggested that deoxyglucose interfered with the construction of a protein called IL-2. This protein can prevent T cells from becoming an inflammatory-response cell known as Th17. Deoxyglucose essentially removed a barrier to a T cell’s ability to become a Th17 cell. That’s potentially why T cells in the low-glucose environment didn’t become Th17 cells at nearly the numbers seen in the deoxyglucose environment.
“GPT‑5 came up with this really remarkable insight that retrospectively, makes perfect sense,” Unutmaz said. It was just enough outside of his own area of expertise that he didn’t see the connection himself, and neither did anyone in his lab.
Unutmaz then decided to see if GPT‑5 could predict the outcome of an experiment. The immunologist started with one he had already conducted on a T cell that targets a type of lymphoma. His experiment showed that these particular T cells, called CD8+, had an enhanced ability to kill the lymphoma cells.
When Unutmaz asked GPT‑5 Pro to simulate the same experiment, it correctly predicted the boost in the CD8+ cells’ ability to kill lymphoma cells. The model couldn’t have gleaned the results from the internet because Unutmaz hadn’t yet published the results.
“That was the moment that I felt like, okay, these models have now come to a point where they really, truly understand,” he said.
What this means for scientific research
Unutmaz said that models like GPT‑5 Pro function more like collaborators now. They can streamline literature reviews, processing hundreds of new academic papers published every week and helping scientists identify questions that remain unanswered. They can also help researchers hone their hypotheses, reducing the amount of time it takes to identify the most worthwhile experiments to conduct.
“The number of things you can do to address your hypothesis is vast,” Unutmaz said. “You have countless approaches, and you don’t know which one will be the best strategy.” So he uses GPT‑5 Pro to simulate experiments and predict outcomes to help narrow down which experiments are worth repeating in the lab. This can cut out weeks to months, even years, of work for researchers, drastically accelerating the field of biology.
Despite this, subject matter expertise is still key. AI may generate an insight, but people must still evaluate its significance and plausibility. For instance, someone without Unutmaz’s expertise wouldn’t have been able to tell if the mechanistic insight GPT‑5 Pro flagged in his immune cell experiments was important or not.
The ability to generate insights and accelerate work is why these capabilities need to be handled responsibly. AI could help researchers move faster in biology and medicine, but those capabilities could also lower barriers for misuse, including by bad actors seeking to design or use biological or chemical weapons. OpenAI’s Preparedness Framework outlines our approach to tracking these risks and building safeguards against AI capabilities that could create severe harm.
Unutmaz is optimistic about where AI is headed. It’s unlike anything that has come before, he says—not the internet or the industrial revolution. Most recently, Unutmaz has experimented with advanced AI tools, including Codex and GPT‑5.2 Deep Research, to help compile large-scale cancer mutation datasets and generate research materials—including an extensive T-cell-focused draft textbook—aimed at accelerating efforts in precision immunotherapy.
Unutmaz feels fortunate to be part of this time of discovery. “To not only be able to witness it historically but participate a little bit, I feel truly lucky and privileged to do that.”
2026
GPT