AI 日报 · 2026年07月04日

Wan Video 新功能：**音乐转舞蹈（Music to Dance）** 💃 上传一个角色，添加一首歌曲，让 Wan Video 生成一段与节奏同步的舞蹈视频。 可用舞蹈风格： • 街舞 • 踢踏舞 • 拉丁舞 • K-Pop • 中国古典舞 从节拍到动作，你的角色随音乐起舞。

快来试用音乐转舞蹈功能：http://wan.video 👉 https://int.alibabacloud.com/m/1000412428/

为 Web 开发者推出 Safari MCP 服务器

2026 年 7 月 1 日

作者：Saron Yitbarek

在 Safari Technology Preview 247 中，我们推出了 Safari MCP 服务器——这是一个面向 Web 开发者的模型上下文协议（Model Context Protocol）服务器，能让你的 Web 开发和调试工作流程更快速、更强大。我们知道智能体在编码过程中正变得不可或缺，而 Safari MCP 服务器通过将你的智能体连接到 Safari 浏览器窗口，使其能够了解你的代码在浏览器中的实际渲染效果。

任何兼容 MCP 的客户端都可以连接到 Safari MCP 服务器。通过将你的智能体连接到 Safari 浏览器窗口，智能体可以模拟用户的实际体验，从而获取自主调试所需的信息，例如访问 DOM、网络请求、截图和控制台输出。

它能加快你的调试速度，让你始终在舒适的终端中操作，这意味着减少了来回切换窗口和输入提示词来调试代码的轮次。

使用场景

如果你从事 Web 开发，你一定了解那种调试的“舞蹈”。通常流程是这样的：

你在浏览器中发现网站某处有问题。打开控制台来定位问题。点击样式标签。查看哪里出错了。返回代码进行修复。或者，你截个图，把问题详细描述给智能体，然后让它替你修复。希望它能正确修复，bug 被解决，你就可以继续了。

但如果没有修复成功，你就得再次经历这个工作流程——浏览器。提示词。智能体。

一次又一次，直到你最终消灭这个 bug。

无论你使用哪种浏览器或工具，调试工作流程都需要大量的点击、工具切换和窗口跳转才能完成一次修复，但事情本不必如此。如果你已经在开发流程中使用智能体，那么 Safari MCP 服务器能让你的调试更快速、更高效。

Safari MCP 服务器能让你的智能体自行完成更多调试和故障排查工作。以下仅列举一些它可以协助的示例：

Safari 中的 Web 开发。下一次你在 Safari 中开发时，将受益于升级的工作流程。你的智能体已经能帮你处理代码，现在它还能检查代码在 Safari 中的实际渲染效果，从而做得更多。

提升与 Safari 的兼容性。仅在一个浏览器中测试，意味着会遗漏另一个浏览器中可能存在的 bug，从而给那些用户带来糟糕的体验。通过 Safari MCP 服务器，你的智能体可以在 Safari 中打开你的网站，检查计算样式、查看布局，并与你的预期进行比较，无需切换窗口。

分析性能。了解网站中哪些部分拖慢了速度。Safari MCP 服务器让你的智能体能够评估页面上的 JavaScript，从而给出性能指标，如导航计时和资源加载时间，以便精准定位拖慢网站的因素并制定正确的修复方案。

检查无障碍性。Safari MCP 服务器让你的智能体能够检查常见的无障碍性问题，如缺少标签、不正确的 ARIA 属性和对比度不足，从而让你发现影响用户的问题。

验证任何用户状态。确保页面按预期工作并呈现正确。你的智能体可以检查表单的状态、使用选择器查询元素、确认特定交互、展示结账流程的不同状态等。减少手动检查的时间，让智能体替你完成这些工作。

以上只是部分用例。无论你如何实现，Safari MCP 服务器都能帮助你的智能体为你做更多事情，减少 Web 开发中常见的那种反复切换工作。更简便的工作流程意味着修复更多 bug、更满意的用户以及更好的产品。

工具

以下是可用的工具及其功能：

工具 描述

browser_console_messages 返回当前或指定标签页的缓冲控制台日志

browser_dialogs 列出并响应浏览器对话框（接受、关闭或为 JS 提示框输入文本）

close_tab 通过标签页句柄关闭一个浏览器标签页

create_tab 创建一个新的浏览器标签页，可选择性加载一个 URL

evaluate_javascript 在页面中执行 JavaScript 代码并返回结果

get_network_request 获取单个记录的网络请求的完整详情（头部、正文、时序）

获取页面内容 以多种格式（Markdown、HTML、JSON 等）提取页面的文本内容

列出网络请求 列出当前标签页的网络请求摘要（URL、方法、状态、时序）

列出标签页 列出所有打开的浏览器标签页及其句柄和 URL

导航到 URL 导航到指定 URL 并返回加载后的页面内容

页面信息 获取当前页面的信息：URL、标题和加载状态

页面交互 按顺序执行 DOM 交互：点击、输入、滚动、悬停、按键等

截图 将当前页面截取为 PNG 格式的截图

设置模拟媒体类型 模拟 CSS 媒体类型（例如“打印”），用于响应式设计测试

设置视口大小 以 CSS 像素为单位设置浏览器视口大小

切换标签页 通过句柄切换到不同的浏览器标签页

等待导航完成 等待当前页面完成加载；返回最终 URL 和标题

有了 Safari MCP 服务器，你不再需要编写完美的提示词，仔细向智能体描述你在浏览器中看到的内容。你可以让智能体自己具备发现能力。

如何开始

首先，你需要安装 Safari Technology Preview。安装完成后，请确保启用 Safari 设置 > 高级 > 为 Web 开发者显示功能。然后进入 Safari 设置 > 开发者 > 启用远程自动化和外部代理。

如果你在 Claude 中使用，可以在终端执行以下命令：

claude mcp add safari-mcp-stp -- "/Applications/Safari Technology Preview.app/Contents/MacOS/safaridriver" --mcp

如果你在 Codex 中使用，可以在终端执行以下命令：

codex mcp add safari-mcp-stp -- "/Applications/Safari Technology Preview.app/Contents/MacOS/safaridriver" --mcp

对于其他智能体，你可以将以下内容放入 mcp.json 或 config.json 中：

"safari-mcp-stp": {

"command": "/Applications/Safari Technology Preview.app/Contents/MacOS/safaridriver",

"args": ["--mcp"]

}

请注意，虽然上述代码将服务器命名为 safari-mcp-stp，但你可以随意命名，甚至可以就叫 safari。安装好 Safari MCP 服务器后，可以尝试以下提示词之一：

Find bugs on my site in Safari

How accessible is my site in Safari?

See how my website performs in Safari

虽然每个智能体的工作方式略有不同，但它不需要被明确告知要使用 Safari MCP 服务器——它会自己发现。像上面这样简单的提示词就足以启动 MCP。

以下是使用 Safari MCP 服务器的智能体与你的对话示例：

你：收到一个 Bug 报告——Safari 中航班页面上有些功能出了问题。你能查明是怎么回事吗？

智能体：好的，让我看看。

智能体：我在 Safari 的航班页面上发现了两个不同的错误。要我把它们都修复吗？

你：是的。还有其他可能给 Safari 用户带来问题的地方吗？

智能体：是的，还有两件事值得提一下。结果展示动画存在静默失败问题，API 服务器启动日志也是错误的。这两项也要一并处理吗？

你只需要发出初始请求就能开始，借助 Safari MCP 服务器，你的智能体就能继续推进后续工作。

Safari MCP 服务器完全在你的本地机器上运行，不会主动发起任何网络调用。它也无法访问你在 Safari 中的个人信息（例如自动填充或其他浏览器活动）。当它捕获页面内容、截图或控制台日志时，这些数据会直接发送给你正在运行的智能体——而非苹果公司。这些数据后续如何处理，取决于你使用的智能体和模型。与任何允许访问你浏览器的智能体一样，请只使用你信任的。

我们为何构建这个工具

构建 Web 应用的方式有很多，既包括有 AI 的，也包括没有 AI 的。如果 AI 是你工作流程的一部分，我们认为这个工具将帮助它变得更高效。如果不是，那也没关系。

通过创建这个资源，我们希望帮助你的智能体更好地理解内容在浏览器中的呈现方式和工作原理，从而让在 Safari 中进行测试和调试比以往任何时候都更简单。

如果你最终尝试使用它，或者这是你第一次使用 MCP 服务器，请告诉我们你的想法。

在社交平台上找到我们：Saron Yitbarek 在 BlueSky，Jen Simmons 在 Bluesky / Mastodon，Jon Davis 在 Bluesky / Mastodon。如果遇到任何问题，请提交 WebKit 缺陷报告。提交问题确实能带来改变。

公众号正文需在微信内阅读，站内仅提供摘要。

公众号正文需在微信内阅读，站内仅提供摘要。

What's changed

Changed AskUserQuestion dialogs to no longer auto-continue by default; opt into an idle timeout via /config

Changed the "default" permission mode to "Manual" across the CLI, --help, VS Code, and JetBrains; --permission-mode manual and "defaultMode": "manual" are accepted alongside default

Fixed a crash at startup when disabledMcpServers or enabledMcpServers in .claude.json is set to a non-array value

Fixed background sessions silently stopping mid-turn after sleep/wake or when reopening a stalled session

Fixed background sessions re-running a turn cancelled with Esc after a stall respawn

Fixed background agents never starting again after a crash left a stale daemon.lock whose PID the OS reused

Fixed background-agent daemon handover so a reinstalled older build can no longer take over the daemon; build recency is now judged by the version's embedded build timestamp

Fixed background-agent roster issues: transient corruption permanently disabling orphan cleanup, older binaries not preserving fields written by newer versions, and socket auth tokens being stripped during daemon restarts

Fixed subagents cut off by a rate limit before producing any text output returning an empty result instead of failing cleanly

Fixed control bytes from background-agent output reaching the terminal in the agent view

Fixed claude agents --plugin-dir <dir> not showing the plugin's agents and skills in the agent view when the flag is placed after agents

Fixed project-scoped plugins not loading correctly from git worktrees of the same repository

Fixed /mcp server list not tracking focus for screen readers and magnifiers

Fixed voice dictation showing a misleading "Voice connection failed" message when a recording captures no audio

Fixed rendering flicker under tmux 3.4+ by enabling synchronized terminal output

Improved screen-reader output: decorative glyphs are now hidden, transcript symbols read as short labels, and nested tables read as Header: value. lines

Improved the install script to explain when installation is killed by the system running out of memory

IT之家 7 月 3 日消息，国家互联网信息办公室今日发布通知，就《互联网信息服务管理办法（修订草案征求意见稿）》再次向社会公开征求意见。

此前，国家互联网信息办公室已会同工业和信息化部、公安部起草了该修订草案并完成首轮征求意见。此后，根据修改后的《中华人民共和国网络安全法》等法律和社会公众反馈意见，有关部门对草案进行了修改完善，现再次公开征求意见。

现行《互联网信息服务管理办法》自 2000 年施行以来，作为互联网信息服务管理的重要基础性立法，对规范网络信息传播秩序、促进互联网产业持续健康发展发挥了积极作用。随着我国信息技术迅猛发展，互联网信息服务的管理体制机制、方式手段、作用对象等均发生了深刻变化，同时人工智能生成合成、深度伪造等新技术的广泛应用进一步加剧了治理复杂性，现行办法亟需修改完善。此外，近年来《中华人民共和国网络安全法》《中华人民共和国个人信息保护法》《中华人民共和国未成年人保护法》等相关法律相继修订制定，网信等部门围绕网络生态治理、互联网账号管理、人工智能信息服务等出台了一系列部门规章和规范性文件，修订工作亦需与相关法律法规做好衔接。此次修订已被列入《国务院 2026 年度立法工作计划》。

国家网信部门负责统筹协调全国网络安全工作和相关监督管理工作，国务院电信主管部门负责互联网行业管理，国务院公安部门负责网络安全保护和监督管理。

在准入与管理方面，草案规定从事互联网信息服务应当依法取得电信主管部门核准，使用符合要求的网络资源。互联网新闻信息服务相关从业人员应当取得相应资质并接受培训、考核。在运行规范方面，草案进一步强化了用户账号管理，要求互联网信息服务提供者建立健全用户注册、账号管理、信息发布管理等制度，及时对注册账号信息进行动态核验；对于超过 6 个月不登录、不使用的互联网账号，应当依法依约采取合理提示、暂停或限制功能直至注销账号等措施。草案同时明确了互联网信息服务提供者和使用者不得制作、复制、发布、传播的九类禁止内容，并规定应当采取措施防范和抵制制作、复制、发布、传播含有炒作重大形势政策、突发事件、重大案件等不良信息。

此次修订的一大亮点是增设了“平台信息服务”专章。草案要求具有较大影响力的互联网用户公众账号生产运营者不得制作、复制、发布、传播违法和不良信息。平台信息服务提供者应当建立健全网络暴力信息特征库和典型案例样本库，采用技术手段和人工审核相结合的方式加强对网络暴力信息的识别监测，并为用户提供屏蔽特定对象、禁止转载或评论、拒绝接收私信等防护选项以及快捷取证功能。此外，草案还规范了互联网信息内容多渠道分发机构的签约账号管理，要求平台加强入驻核验并按国家有关规定备案。

另一新增专章为“智能信息服务”，对应用人工智能技术提供互联网信息服务的情形进行专门规范。草案明确，智能信息服务提供者应当按照国家有关规定公示其相关技术的基本原理、主要运行机制、训练数据来源等信息。提供生成合成服务的，应当依法对人工智能生成合成内容进行标识，任何组织和个人不得恶意删除、篡改、伪造、隐匿相关标识。提供算法推荐服务的，应当建立完善人工干预和用户自主选择机制，不得强制用户使用智能信息服务，不得利用算法实施扰乱网络舆论或规避监督管理的行为。草案还要求智能信息服务提供者加强与平台信息服务直接相关的劳动者权益保护，在招聘、调度、考核等环节确保算法透明、公平、合理。

在法律责任方面，草案结合互联网治理实践，建立了互联网领域严重失信主体名单管理制度，增设了限制账号功能、禁止注册新用户账号等管理措施，并与《中华人民共和国网络安全法》《中华人民共和国未成年人保护法》《中华人民共和国行政处罚法》等做好衔接。IT之家注意到，草案同时明确了网信、电信、公安等主管部门的监督检查职责，要求建立联合执法机制，避免不必要的检查和交叉重复检查。

公众可通过电子邮件将意见发送至 law@cac.gov.cn，或通过信函将意见寄至北京市西城区车公庄大街 11 号国家互联网信息办公室网络法治局（邮编 100044），信封上请注明“互联网信息服务管理办法征求意见”字样。意见反馈截止日期为 2026 年 8 月 2 日。

参考资料：

《国家互联网信息办公室关于〈互联网信息服务管理办法（修订草案征求意见稿）〉再次公开征求意见的通知_中央网络安全和信息化委员会办公室》

IT之家 7 月 3 日消息，安全厂商 Sysdig 昨日宣布，其威胁研究团队首次记录到一例由 AI Agent（智能体）自主完成整个攻击流程的勒索软件攻击，并将该攻击者命名为 JADEPUFFER。

研究人员指出，这是目前公开披露的全球首个有完整记录、完全由 AI Agent 自动执行的勒索软件攻击案例，它利用公开漏洞入侵系统后，自主完成了从侦察、窃取凭证、横向移动到最终加密和摧毁数据库的完整攻击链路，全程无需人类操作。

IT之家注意到，此次事件中的 AI 攻击者并未采用新的漏洞或攻击技术，而是依靠 AI 自主组合现有攻击手法，完成了一条完整的自动化攻击链。

根据 Sysdig 报告，攻击起点是一台暴露在互联网的 Langflow 服务。攻击者利用已修复但仍存在于部分系统中的高危漏洞 CVE-2025-3248，在无需身份验证的情况下远程执行 Python 代码，从而获得目标主机控制权。

研究人员指出，虽然 Langflow 已在 1.3.0 版本修复该漏洞，并于 2025 年被美国网络安全和基础设施安全局（CISA）列入“已知遭利用漏洞”名单，但仍有大量互联网暴露实例没有及时更新，因此成为攻击目标。

成功入侵后，JADEPUFFER 会自动收集主机中的敏感信息，包括 OpenAI、Anthropic、DeepSeek、Gemini 等大模型服务 API 密钥，以及阿里云、腾讯云、华为云、AWS、Google Cloud、Azure 等云平台的登录访问凭证，同时还会搜索数据库账号、配置文件、加密货币钱包及助记词等信息，并导出 Langflow 使用的 PostgreSQL 数据库内容。

研究人员还发现，该 AI 使用 MinIO 默认账号密码“minioadmin”访问对象存储，下载包含访问密钥的配置文件，并在受害服务器创建计划任务，每隔 30 分钟主动连接攻击者控制服务器，以维持长期访问权限。

完成初始侦察后，JADEPUFFER 将攻击目标转向另一台部署生产业务的服务器，该服务器运行 MySQL 数据库及阿里巴巴开源配置中心 Nacos。

研究显示，AI 通过数据库 Root 账号登录 MySQL，并结合 Nacos 身份验证绕过漏洞 CVE-2021-29441 以及长期未修改的默认 JWT 签名密钥，成功获取 Nacos 管理权限，在数据库中植入隐藏管理员账号，实现对配置中心的完全控制。

Sysdig 表示，本次攻击最具代表性的特征并非使用了新的攻击方式，而是 AI 展现出的自主决策能力。攻击过程中，JADEPUFFER 生成的大量恶意代码均包含自然语言注释，对每一步操作目的、攻击优先级和执行逻辑进行说明。

当首次创建管理员账号失败后，它没有简单重复尝试，而是在 31 秒内完成错误分析、重新生成密码哈希、删除失败账号、重新创建管理员并再次验证登录，整个修复过程完全自动完成。

研究团队统计，此次攻击累计执行了超过 600 个具有明确目的的攻击载荷，多次根据实际执行结果调整后续策略。

在勒索阶段，JADEPUFFER 使用 MySQL 的 AES_ENCRYPT () 函数加密了 Nacos 中全部 1342 条配置数据，随后删除原始配置表及历史记录表，并创建 README_RANSOM 表留下包含比特币钱包地址和 Proton Mail 联系方式的勒索信息。

不过，Sysdig 发现，AI 在生成加密密钥后仅输出到终端一次，并未保存或上传给攻击者，这意味着即使受害者支付赎金，也无法获得解密密钥恢复数据。

此外，AI 在后续还删除了多个数据库。虽然其生成的代码声称数据已备份至外部服务器，但研究人员未发现任何数据成功外传的证据，因此无法证实这一说法。

Sysdig 认为，JADEPUFFER 最大的意义在于证明 AI Agent 已能够自主串联漏洞利用、权限提升、凭据窃取、横向移动、持久化控制及勒索破坏等多个环节，从而显著降低实施勒索攻击所需的技术门槛。

研究团队建议企业尽快升级 Langflow 至修复版本，不要将其代码执行接口直接暴露在公网，同时加强 Nacos 安全配置，更换默认 JWT 签名密钥，避免数据库使用 Root 权限对外提供服务，并加强运行时行为检测、限制服务器对外通信能力以及妥善管理各类访问凭据，以降低类似 AI 自动化攻击造成的风险。

By Eli Collins| VP Product, Google DeepMind

Jun 22, 2026

Google DeepMind and A24 announce first-of-its-kind research partnership

Today, Google DeepMind and A24 are announcing a first-of-its-kind partnership focused on research. The collaboration pairs a world-leading research lab with the industry’s most filmmaker-forward studio to help artists develop new workflows and techniques. This ensures the tools of the future are shaped by the creators who use them.

This partnership creates a deep research and development collaboration between A24 and Google DeepMind spanning multiple projects over time. By anchoring Google DeepMind's innovations directly within the creative process, A24 and its filmmakers can help shape new technology in service of their vision and expand their storytelling possibilities. This hands-on collaboration provides Google DeepMind with invaluable feedback and guidance from leading artists. In addition, Google has made an investment in A24.

Looking ahead, the partnership represents the beginning of a collaborative journey, one rooted in research and shared curiosity. While the initial focus is on bridging the gap between cutting-edge technology and next generation entertainment, the specific goals, technical outputs and creative milestones of this initiative will evolve over time. As A24 and Google DeepMind’s researchers work side-by-side to test, iterate and build, this partnership aims to expand what is possible in the future of entertainment.

POSTED IN:

IT之家 7 月 3 日消息，阿里达摩院通过公众号宣布，7 月 3 日（今天），阿里达摩院联合中国人民大学、中国科学院大学等发布首个超导材料发现 AI 智能体 Elements Claw，预测出 6.8 万个可能的超导材料，其中 4 种全新材料已合成并证实存在超导性。相关数据已全部开放。

目前，国际主流超导数据库 SuperCon 历经数十年积累，仅收录约 2000 种材料。为此，阿里达摩院发挥 AI for Science 技术优势，联合中国人民大学、中国科学院大学等机构研发 ElementsClaw，不仅可预测材料是否具有超导性，更能像人类材料学家一样查阅文献、评估合成可行性、设计实验方案，大幅提升材料发现效率和成功率。

据IT之家了解，ElementsClaw 采用“专通融合”架构。专有模型层面，团队基于包含 1.25 亿个分子和晶体结构的数据库，预训练出 1B 参数原子基础模型 Elements，判断材料是否具有超导性的 AUC 达 0.996，预测材料超导临界温度的平均误差在 1K 以内。通用智能体框架层面，ElementsClaw 实现了工具制造、流程编排、文献复核等整套自动化材料筛选流程，并能在文献中挖掘到新线索后“自我进化”。

AI 仅用 28 个 GPU 小时完成 240 万晶体结构筛选，预测出 6.8 万个超导候选材料。研究团队已实验合成并验证其中 4 种：

从现有数据库中捞出的“漏网之鱼”Hf21Re25

纠正数据库构型错误后“正名”的 Zr4VRe7

AI 从头设计生成的 HfZrRe4

基于类似结构举一反三得到的 Zr3ScRe8，临界温度最高达 6.5K。

达摩院科学智能负责人荣钰表示，这是 AI 智能体发现并获验证的第一批超导材料，初步验证了 AI 智能体框架在材料发现领域的潜力。后续，大量候选材料仍待探索。达摩院开放了 ElementsClaw 预测的所有 240 万稳定晶体的数据库，科研人员可免费使用。

中国人民大学高瓴人工智能学院副教授黄文炳表示，该 AI 智能体也有望应用于发现固态电池电解质、多相催化剂和热电材料等新材料。

论文链接：Agentic Fusion of Large Atomic and Language Models to Accelerate Superconductor Discovery

超导数据库链接：DAMO AI for Science Portal

pxpipe

将庞大上下文渲染为图片，以此削减 Claude Code 的输入 token——同样的系统提示词、工具文档和历史记录，只需原来 token 数的一小部分。

一张图片的 token 成本由其像素尺寸决定，而非内含文本量。在真实的 Claude Code 流量中，密集内容（代码、JSON、工具输出）每个图片 token 约可容纳 3.1 个字符，而每个文本 token 仅约 1 个字符。pxpipe 是一个利用这一差异的本地代理：它在请求离开你的机器之前，将请求中的庞大部分（系统提示词、工具文档、较早的历史记录）重写为紧凑的 PNG 图片。

节省量取决于工作负载——pxpipe 在 token 密集内容上优势明显，而对稀疏/小型请求不做改动——因此这些是实测快照，并非固定值。主要且持久的结果是输入 token 的减少：密集的系统提示词、工具文档和历史记录以紧凑图片而非文本形式输入（上例中约 25k 文本 token 被渲染为约 2.7k 图片 token），每个请求都对照自身的 count_tokens 反事实进行测量。费用节省由此衍生——按当前 Fable 标价，token 削减带来约 59–70% 的整体账单降低（压缩请求上约 72–74%；完整定价计算见 FAQ）。但标价明天就可能变化，而 token 数量不会，因此应关注 token 而非美元。可从 ~/.pxpipe/events.jsonl 复现两者。

这就是模型看到的，而非文本：

约 4.8 万字符的系统提示词 + 工具文档（即本仓库自身的 README、FINDINGS 和源代码），作为文本约 25k token，作为此页面约 2.7k 图片 token。由真实的 transformRequest 管道生成：空白压缩，重新排列为满行，用 ↵ 标记原始换行，顶部叠加 OCR 指令横幅。模型在纯净评测中以 100/100 的成绩读取此类渲染（见基准测试）。

演示

Fable 5 演示（默认，阅读器得分 100/100）：

Fable-AB-Demo.mp4

双窗格演示（左侧为纯文本，右侧为 pxpipe），均在 Fable 5 上运行。

Fable 能读取 Opus 无法处理的内容。Opus 拒绝处理的图片化短语计数（见下方 Opus 演示）：pxpipe 分支在 39 个图片化填充文件中精确统计了 10/10 个 token（与 grep 真实结果逐行匹配），并正确完成了多步骤账本算术（8037 → … → 15,021）。

相同的答案，成本降低约7倍。两次演示后的会话总量：普通版本为42.21美元，上下文窗口已满96%（964.5k/1M——距离强制压缩仅差一个任务）；而pxpipe版本为6.06美元，上下文空间充足（73.5k/1M）。

诚实的提醒，视频片段中可见：pxpipe分支先回答了计数问题，但需要一次后续提示才能按要求的一行格式打印账本余额；普通分支首次尝试就遵循了格式。在Fable上可读性已解决——单次回复格式遵循是剩下的粗糙边缘。

Opus 4.8演示（Opus默认禁用）：

Opus-AB-Demo.mp4

并排对比——普通Claude（左）与pxpipe（右），两者均运行在Opus 4.8上（需手动启用；pxpipe针对Fable进行了调优——参见上方Fable片段）。点击图片观看（Google Drive）。

演示1——修复失败的测试套件：两者均通过；仪表盘显示pxpipe将请求压缩至token数的一小部分（真实的、服务端测量的上下文/token缩减）。

演示2——一个大型文件上下文（40个文件，约382k token）加上一个数学问题和一个“统计此短语”任务：数学答案（一个小的文本“针”）两者均可读取。短语计数需要读取图像填充内容——因此运行在Opus上的pxpipe无法读取，并诚实地表明它不会编造数字（有文档记载的有损限制：精确数值保持为文本形式）。与此同时，普通版本在逐文件计数时陷入困境。

尝试一下（30秒）

npx pxpipe-proxy # proxy on 127.0.0.1:47821

ANTHROPIC_BASE_URL=http://localhost:47821 claude # point Claude Code at it

打开 http://127.0.0.1:47821/ 查看实时仪表盘：节省的token数、每会话统计、每次文本到图像转换的并排对比、全局终止开关，以及包括GPT 5.6和GPT 5.5在内的运行时模型芯片。

其他一切不变。响应正常流式输出；pxpipe仅压缩请求（即你发送的上下文），绝不压缩模型的输出。最近的轮次保持文本形式；系统提示词、工具文档和较旧的批量历史被转换为图像。

诚实的部分，在依赖之前请先阅读。

它有损。pxpipe 属于 gist 层级存储，并非无损存储。在一项“大海捞针”式评测中，密集图像内容里的精确 12 字符十六进制字符串，在 Opus 上返回结果为 0/15，在 Fable 5 上返回结果为 13/15，且失败模式是无声的虚构：给出一个看似合理但错误的值，而非报错。任何需要字节级精确返回的内容（ID、哈希值、密钥、精确数字）都必须保持文本形式。最近的版本已经实现了这一点；但尚未内置专门的逐字风险防护。

精确召回逃生通道。pxpipe 仅对 Fable 请求进行图像化处理（PXPIPE_MODELS=claude-fable-5），因此任何使用非 Fable 模型的子智能体都会以文本形式通过。将需要字节级精确值的工作路由到这类模型——全局设置 CLAUDE_CODE_SUBAGENT_MODEL=claude-sonnet-4-6，或在智能体 frontmatter 中按智能体设置 model: sonnet。它从源文件（file/JSONL）读取，而非从图像化历史中读取。这覆盖了你有意路由的精确召回场景；但无法捕获你未预料到的无声误读——正是上面提到的那项尚未构建的防护。

它会破坏实际工作吗？在我们衡量的指标上具有一致性：一个包含 10 个实例的 SWE-bench Lite 试点（简单子集），两组均解决了 10/10，pxpipe 开启时 token 等价成本为 $27，关闭时为 $54；19 对 SWE-bench Pro（更困难、长周期）测试中，开启组解决了 14/19，关闭组解决了 15/19，每次请求成本降低 60%：两组在 18/19 个案例上判定一致，唯一的分歧（一个开启组失败案例）在复制测试中 3/3 重新解决，即属于运行间智能体方差，而非压缩问题。样本量较小，详细说明和注意事项见下文。

节省成本取决于工作负载。它在 token 密集内容（约 1 字符/token：代码、JSON、哈希值）上表现优异，而在稀疏的英文散文（约 3.5 字符/token）上则不划算。内置门控仅对数学计算上划算的内容进行图像化处理，并基于 N=391 条生产数据行进行了校准。

模型范围：一个 PXPIPE_MODELS CSV 文件控制着两个模型族中哪些底座会被成像——默认是 claude-fable-5、gpt-5.6（GPT 5.5 为可选加入；它在成像上下文上会降级）。将 PXPIPE_MODELS 设为 off 可完全禁用成像，或使用 ~/.config/pxpipe/config.json 并写入 { "models": "off" }（或一个列表）。对于 GPT，pxpipe 以原生 JSON 格式保存工具定义（只有冗长的模式描述会被放入图像），因此工具调用保持可靠；与 Claude 路径不同，GPT 路径不会添加或依赖 Anthropic 的 cache_control 提示缓存标记。仪表盘上的面板可以实时切换任何模型，无需修改客户端配置。Opus 4.7/4.8 是初始的 Claude 范围，但它在约 7% 的渲染中发生了误读（10200→9400），因此在 Fable 5 达到 100/100 且图像计费相同后，默认关闭了它——你可以通过 PXPIPE_MODELS 或仪表盘面板自行选择重新开启，风险自负。其他所有内容原样通过。

可复现的基准测试

使用模型无法记住的新颖随机数问题进行测量：

测试 样本数 文本 pxpipe（图像） token数

新颖算术，claude-fable-5 100 100% 100% –38%

新颖算术，claude-opus-4-8 100 100% 93% –38%

要点回忆A/B（决策、数值、路径、名称、否定；含干扰项；15k-45k字符会话），Fable 5 98/arm 98/98 98/98 –

状态跟踪（值变化3次，最终/首次/计数），Fable 5 18/arm 18/18 18/18 –

对从未陈述的事实的虚构（越低越好），Fable 5 16/arm 0/16 0/16 –

逐字12字符十六进制回忆，密集渲染，Opus 15 15/15 0/15 –

逐字12字符十六进制回忆，密集渲染，Fable 5 15 – 13/15 –

SWE-bench Lite 试点（端到端任务质量）

10个SWE-bench Lite实例，Claude Code + Fable 5，通过pxpipe开启与关闭进行配对运行，使用官方swebench Docker框架评分：

pxpipe 开启 关闭

解决 10/10 10/10

请求大小与自身未压缩主体对比 –65% ±0

–65% 是每次请求（压缩前对每个主体进行count_tokens探测）的数据，因此没有轮次混淆。n=10/arm，Lite偏向简单。运行总计、收据、注意事项：eval/swe-bench/。

SWE-bench Pro 基准测试（更难，长期）

两次运行共完成19对（2对放弃：两个分支检出失败），相同设置，官方SWE-bench_Pro-os Docker框架：

pxpipe 开启 关闭

解决 14/19 15/19

请求大小 vs 自身未压缩的响应体 −60% ±0

在 19 个实例中，18 个的评价结果一致（三个实例的两端均失败，其中一个是两端字节完全相同的补丁）。唯一的分歧（navidrome，ON 端失败）在 ON 端重复了 3 次：三次运行均产生了相同的补丁并成功解决，因此最初的损失是运行间智能体方差造成的，与压缩无关。凭证：eval/swe-bench-pro/。

我们还运行了 GSM8K：获得了 96% 的成像结果。但 GSM8K 存在于训练数据中，因此模型会通过自身误读来回忆已记忆的答案，从而虚增分数，所以我们改用干净的新数字评测作为主要依据。复现方式：eval/gsm8k/ · eval/needle-haystack/ · eval/gist-recall/ · 完整分析见 FINDINGS.md。

常见问题

这个数据是端到端的，还是仅针对你处理过的请求？是端到端的，涵盖全部费用。大多数压缩工具只报告它们所处理的输入部分的节省量，这会让数字更好看。端到端的分母是所有生产请求：包括 pxpipe 正确保留的小请求、所有缓存写入和读取、以及所有输出 token（代理从不压缩输出）。在 13,709 个请求的快照中，节省了 59%（100 美元 → 约 41 美元）；后续一个 8,904 个压缩请求的跟踪测得约 70%。仅压缩部分则更高（约 72–74%），并单独列出，从不作为标题数据。具体数据取决于工作负载——请在自己的日志上复现。

这个数学计算是如何完成的？对同一个请求的两端，在同一时刻进行。对于每个 /v1/messages POST，代理会并行地对原始未压缩体（反事实情况）发出一个免费的 count_tokens 探测，同时进行实际转发，并从响应中读取 Anthropic 实际计费的使用情况块。两端都会记录在 ~/.pxpipe/events.jsonl 的同一行中，因此不存在轮次或运行间混淆。美元换算使用 Fable 5 列表比率：输入 ×1.0，缓存写入 ×1.25，缓存读取 ×0.1，输出 ×5。缓存定价对两端相同，因此缓存折扣相互抵消，不会重复计算为“节省”。您可以从事件日志中自行推导：公式和字段名称在 src/core/baseline.ts 中有文档说明。

它实际上压缩了什么？三种输入块，每种都经过一个盈利性门控：

大型工具结果体（文件读取、命令输出、日志）中，超过约 6k 字符的密集 token 内容。

较早折叠的历史记录：位于实时尾部之后的轮次会被重新渲染为图像页面，而最近的轮次始终保留为文本。

静态系统提示词 + 工具文档模块。

其他所有内容都原样逐字节通过：你的消息、最近轮次、模型输出（它就是响应本身，代理从不触碰它）、稀疏的散文，以及任何太小以至于不值得转换的内容。非 Fable 模型则完全原样通过。

在真实场景中（基准测试之外）它真的失败过吗？是的，在数周的日常使用中发生过一次：模型从图像化的聊天历史中回忆了一个人的名字，并自信地给出了错误答案。没有报错，只是一个看似合理但错误的名字。这就是文档中记录的错误模式：图像化内容中的精确字符串不具备字节安全性。编码会话可以容忍这种情况，因为代理在编辑前会重新读取文件；纯聊天回忆则没有这样的检查。

工作原理

tool_result string ──► wrap at 1928px-wide columns ──► pack ~92,000 chars/page ──► PNG[]

代理拦截 /v1/messages，将符合条件的批量历史记录重写为图像块，然后以缓存友好的方式将它们拼接回去（保留静态前缀，使提示缓存继续工作），并转发。每次请求的事件记录到 ~/.pxpipe/events.jsonl。

经济性计算：一张 1928×1928 的图像需要约 4,761 个视觉 token，最多可容纳约 92,000 个字符（在观察到的密度下约相当于 48,000 个文本 token），因此纯文本只有在密度超过约 19 字符/token 时才更便宜。Claude Code 的转录内容远低于该密度（观察值为 1.91 字符/token，N=391）。运行时估算器（estimateImageCount）加上一个字符/token 阈值决定每次请求的处理方式；稀疏散文则保留为文本。

库使用（无代理）

同样的引擎，无代理。将文本渲染为 PNG，或运行完整的缓存安全转换：

import { renderTextToPngs, transformAnthropicMessages } from "pxpipe";

const imgs = await renderTextToPngs(toolResultText); // RenderedImage[]

const { body, applied, info } = await transformAnthropicMessages({

body: requestBytes,

model: "claude-fable-5",

});

options.keepSharp(block) 将某些块强制保留为文本（覆盖对 ID、哈希值、路径的启发式判断）；options.emitRecoverable 返回已图像化块的原始内容，以便有状态的调用方可以恢复它们——这是针对下面有损限制的保真契约的两个部分。运行环境为纯 JS（Node 和 edge/Workers）；@napi-rs/canvas 仅在构建时使用。完整 API、类型和常量参见：src/core/index.ts。

开发

pnpm install && pnpm test # 376 tests

pnpm run build # regenerates dist/

限制

有损：请参阅上方“诚实的一面”。从图像中逐字回忆是不可靠的。

渲染延迟：编码 PNG 会为大型请求在离开前增加额外时间（部分被模型消耗更少 token 所抵消）。响应正常流式输出。

ASCII/Latin-1 已充分测试；CJK（中日韩字符）可用但处理较保守。

运行时是纯 JavaScript——可在 Node 和边缘/ Workers 上运行。@napi-rs/canvas 仅在构建时作为开发依赖使用（用于重新生成字形图集），不是运行时依赖。

仅支持 Fable 5。

路线图

以上所有内容均已实测。以下内容尚未实测。这些是假设，而非声明；它们要么作为带 n 前缀的数字发布，要么被砍掉。

更清晰的字形。13/15 逐字差距部分是由于字体可读性，而不仅仅是模型本身。跨渲染风格的逐字符混淆矩阵正在运行中（eval/glyph-matrix/）；如果某种零成本风格能降低阅读错误，那么在相同保真度下，门控压缩会更激进。

有效上下文。密集文本作为图像传输时，token 消耗约为直接使用图像的 1/3。如果这一结论在实时窗口中成立（而不仅仅是账单层面），那么 1M token 实际上能承载约 2 倍的真实内容。开放问题：当一个需要约 2M 原始上下文的任务在 Fable 的 1M 上下文中运行时，如果大部分内容已被图像化，是否仍能执行？

更少的活跃文本，更锐利的模型。长上下文会随着填充而降低推理能力。将旧的大块内容图像化，可以缩小模型主动读取的范围，同时使其仍可访问。假设：相同信息，更小的活跃上下文，更好的长任务准确率。

一个赌注：更长的有效上下文和更锐利的长任务模型，来自同一个 Fable 5。要么出数字，要么撤回，中间不炒作。

许可证

MIT。

关于

通过将文本上下文渲染为图像来降低 Fable 5 的 token 用量

资源

Readme

许可证

MIT 许可证

动态

55 个 Star

观察者

0 人关注

2 个 Fork

举报仓库

发布版本 2 个

v0.7.1 最新版

2026 年 7 月 3 日

+ 1 个发布版本

包

贡献者

语言

TypeScript 96.1%

JavaScript 1.8%

Shell 1.1%

Python 1.0%

claude-real-video

让 Claude —— 或者任意大语言模型 —— 真正看一段视频。

大部分 AI 工具并不能真正“看”视频。你把一个 YouTube 链接粘贴到 ChatGPT 里，它读的是字幕文本，而不是画面。Claude 根本不接受视频文件。即使是原生的 Gemini，能直接读取视频，也得把视频上传到谷歌，并以固定间隔（默认每秒 1 帧）采样帧，因此快速切换的镜头就会漏掉。

claude-real-video 的做法不同，而且是本地运行的：指向一个 URL 或文件，它会提取真正有意义的帧（每次场景切换，而不是固定数量），丢弃近乎重复的帧，转录音频，然后在你自己的电脑上整理出一个干净的文件夹，任何大语言模型都能读取——数据不上传。

crv "https://www.youtube.com/watch?v=..."

# → crv-out/frames/*.jpg + crv-out/transcript.txt + crv-out/MANIFEST.txt

接着把帧加上 `MANIFEST.txt` 拖入 Claude / ChatGPT / Gemini，然后随便提问。

为什么不直接按固定间隔采样帧？

大多数“让大语言模型看视频”的脚本（以及 Gemini 自身的流程）都是按固定间隔抓取帧——比如每秒一帧。这样对静态屏幕录制会过度采样，而对快速切换的剪辑则采样不足。claude-real-video 更聪明：

固定间隔采样 claude-real-video

帧选择 每 N 秒一帧 场景变化检测 + 密度下限

重复镜头（A-B-A 剪切） 每次都重复发送 滑动窗口去重，每个镜头只发送一次

静态幻灯片（10 分钟） 约 600 张近乎相同的帧 压缩为 1 帧（去重）

快速切换剪辑 会漏掉采样间隔之间的帧 捕捉每一次视觉变化

音频 通常被忽略 Whisper 转录，含语言检测

视频去向 通常上传到云端 留在你的机器上

输入方式 通常仅支持本地文件 支持 URL（yt-dlp）或本地文件

你喂给模型的帧更少，但更有意义——上下文成本更低，理解效果更好。

安装

pip install claude-real-video # core (frames + dedup)

pip install "claude-real-video[whisper]" # + audio transcription

系统要求：ffmpeg

ffmpeg / ffprobe 用于帧提取和音频处理，不能通过 pip 安装。请先安装一次：

操作系统 命令

macOS brew install ffmpeg

Linux sudo apt install ffmpeg（或使用你的发行版包管理器）

Windows winget install Gyan.FFmpeg — 或 choco install ffmpeg — 或下载一个构建版本，将其 bin\ 文件夹加入 PATH

确认它已在 PATH 中：

ffmpeg -version

转录使用 whisper CLI（通过 [whisper] 额外选项安装，或 pip install openai-whisper）。Whisper 也依赖 ffmpeg。

支持 macOS、Windows 和 Linux——Python 3.10 以上。

使用方法

# A YouTube / Instagram / TikTok / ... link

crv "https://www.instagram.com/reel/XXXX/"

# A local file, English transcript, output to ./out

crv lecture.mp4 -o out --lang en

# Frames only, no transcription

crv clip.mp4 --no-transcribe

# A login-gated video (your own / authorised use): pass a Netscape cookie file

crv "https://..." --cookies cookies.txt

python -m claude_real_video ... 也可以简写为 crv。

选项

标志 默认值 含义

-o, --out crv-out 输出目录

--scene 0.30 场景切换敏感度（值越低，提取的帧数越多）

--fps-floor 1.0 每 N 秒至少提取一帧

--max-frames 150 总帧数的硬上限

--lang auto Whisper 语言（en, zh, auto, ...）

--dedup-threshold 8 像素变化比例，超过该比例才视为新帧；值越高，帧数越少

--dedup-window 4 与最近保留的 N 帧进行比较——模型已看过的镜头不会在切回后再次出现（1 表示仅与前一帧比较）

--report off 将丢弃的帧保存在 ./dropped 中，并写入 report.html，可视化展示每一帧的保留/丢弃决策

--no-transcribe off 跳过音频转录

--keep-audio off 同时保存完整音轨（audio.m4a），以便音频模型可以收听

--cookies – 用于登录受限源的 Netscape cookie 文件

通过 Python 使用

from claude_real_video import process

r = process("https://youtu.be/...", "out", lang="en")

print(r.frame_count, r.transcript_path)

工作原理

获取（Fetch）——使用 yt-dlp 处理 URL（可选 cookie），或直接复制本地文件。

提取（Extract）——通过一次时序 ffmpeg 选择通道，捕获每个场景切换点，并确保密度下限（每 --fps-floor 秒至少一帧），从而同时覆盖快速剪辑和慢速录屏。

去重（Dedup）——基于真实像素差异（降采样 RGB，而非感知哈希——哈希在纯色和等亮度色相变化时会失效），与最近 --dedup-window 个保留帧构成的滑动窗口进行比较，从而避免 A-B-A 切回镜头向模型重复发送已看过的画面。启用 --report 会生成 report.html，展示每个保留/丢弃决策及其差异百分比，便于调参。

文本（Text）——如果视频已有字幕（本地文件旁挂载的 .srt/.vtt，或内嵌字幕轨道），则直接使用这些字幕作为转录文本——比重新转录更快、更准确。仅在没有字幕时才回退到对音频使用 Whisper（若无声轨则干净跳过）。

音频（可选，--keep-audio）——保存完整原始音轨（audio.m4a：音乐+语音+音效，尽可能无损复制）。转录仅包含文字部分；音频文件则允许支持听力的模型（如 Gemini、GPT-4o 等）实际听到音乐和语调。

清单文件（Manifest）——MANIFEST.txt 汇总所有信息，供模型使用。

因此，模型能够看到（关键帧）、读取（文字记录），并且——使用 --keep-audio 参数——听到（完整音轨）视频内容。文字记录是任何模型都能读取的纯文本；该工具不会将字幕烧录到视频中——烧录是一种呈现选择，并非让视频可被 AI 读取的必要条件。

备注

仅下载你有权访问的内容。--cookies 选项用于你自己的授权访问——切勿在仓库中提交凭证。

重新运行会覆盖输出目录。

许可证

MIT

关于

让 Claude（或任何大语言模型）真正观看视频——具有场景感知、去重帧与文字记录，支持来自 URL 或本地文件。本地运行，采用 MIT 许可证。

资源

自述文件

许可证

MIT 许可证

动态

星标

230 个星标

关注者

0 关注

派生

8 个派生

举报仓库

版本发布

尚未发布任何版本

包

贡献者

语言

Python 100.0%

藏师傅的 PPT Skill 再配上 Pencil 太爽了！

昨天评论里有个朋友分享给了我启发：

把藏师傅的 PPT 配上 Pencil，就可以直接在 Pencil 里一次性看到所有生成的 PPT 页面。

这种方式不仅编辑起来非常方便，还能导出网页和对应的编辑文件。我试了一下，体验确实非常爽。

虽然 AI 生成内容时不可避免会出现一些排版上的小问题，比如元素重叠或者对齐不准之类的情况，但在 Pencil 里你完全可以手动调整，比如：

1. 对齐元素

2. 修改字体

3. 调整重叠的部分

而且 Pencil 作为一个专业的设计软件，它的可编辑性非常强，甚至比 PPT 软件本身能做的还要多很多，尤其是对齐、嵌套和打组等操作非常方便。

我录了个视频教一下大家，推荐你们也试试这种用法。

这样的话，你可以从它导出 PNG 图片，然后直接放到你的 PPT 里边。

或者也可以直接在 PPT 里进行演示，然后你直接替换对应 PPT 页面的图片就行了

### 引用推文

> 歸藏(guizang.ai)：http://x.com/i/article/2053655813877870592

这是一则列表来源，站内未收录完整正文。

公众号正文需在微信内阅读，站内仅提供摘要。

微软推出25亿美元“前沿公司”部门，拟在企业客户内部嵌入6000名AI工程师

Matthias Bastian 查看 Matthias Bastian 的 LinkedIn 资料

Jul 2, 2026

微软正通过其新设立的“前沿公司”部门，在企业客户现场派驻6000名工程师和行业专家，旨在将AI融入其核心运营。

微软宣布成立一个名为“前沿公司”的新业务部门。该部门拥有25亿美元预算，其使命是推动企业客户的AI转型。

据微软商业业务首席执行官Judson Althoff称，6000名行业与工程专家将直接嵌入客户现场，“共同设计、共同创新、部署并基于可衡量的业务成果持续大规模改进AI系统。”

这一时机耐人寻味。随着AI预算面临越来越严格的审视，而生产力提升仍难以量化，客户希望证明这些部署确实能带来回报。Althoff表示，新部门应当超越行业标准的“Forward Deployed Engineering”（前向部署工程）模式，成为“行业中规模最大、以结果为导向的工程组织”。

Althoff有意将微软定位为OpenAI和Anthropic的平台中立替代方案——后者仅通过自己的部署公司部署自身模型（见下文）。与OpenAI的紧密合作关系看起来越来越像过去式。不过，微软这家公司本身居然在反对供应商锁定，多少有些讽刺意味。

为扩大这一举措的规模，微软正依赖其现有的合作伙伴网络，包括埃森哲、凯捷、安永、毕马威和普华永道等系统集成商。他们的任务是将这一方法推广到全球所有市场和细分领域。Rodrigo Kede Lima将领导这个新部门。

将AI引入企业的三方竞赛

OpenAI和Anthropic最近也设立了专门的部署公司，这一举动相当于承认AI的采用远远不止需要一个聊天工具。三家公司都得出了相同的结论：只有当AI融入现有业务流程、数据管道和合规架构时，它才能带来真正的价值。

OpenAI 成立了“落地公司”（DeployCo），这是一家拥有超过 40 亿美元资本的子公司，约 150 名工程师派驻客户现场工作。据 DeployCo 首席技术官 Arnaud Fournier 表示，直接在客户现场工作能够形成反馈循环，有助于发现模型弱点，并将改进成果反馈回研究环节。

与此同时，Anthropic 宣布与 Blackstone、Goldman Sachs 及其他投资方合作成立自己的公司，目标客户是那些缺乏内部资源自行开展 AI 项目的中型企业。

Anthropic 与五角大楼之争，焦点与其说是 Claude 的访问权限，不如说是军方如何使用前沿 AI 的控制权。

《华尔街日报》近期报道的法庭文件显示，Anthropic 首席执行官 Dario Amodei 与五角大楼副部长 Emil Michael 之间就 AI 驱动的武器和国内监控的护栏问题，进行了长达数月的邮件往来。

Anthropic 希望禁止完全自主的武器以及某些监控用途。而五角大楼则要求 Claude 能够用于所有合法的国家安全用例。

据报道，Michael 表示，如果双方分歧过大，他并不想“强求不自然的事”。

五角大楼后来将 Anthropic 列为供应链风险，实质上阻止了合作伙伴在国防部工作中使用其模型。一名法官已暂停了该举措的部分内容，但政府正在提起上诉。

Michael 表示，使用 Anthropic 模型的三分之二五角大楼业务，已经转用其他 AI 工具。