7月29日2026 · 星期三

从 35 条抓取中筛选 12 条 · twitter × 6 账号 · 01:47 UTC 生成

今日信号 · 高度即评分 · 点击直达

MCP协议发布2026-07-28版本：重大转向无状态请求/响应架构9.0
中国开源模型 Kimi K3 与百度 Unlimited OCR 登顶 HuggingFace 榜单8.0
Anthropic 支持请愿，呼吁放慢 AI 前沿发展步伐8.0
通用AI Agent通吃市场，插件生态与模型智能成护城河8.0
OpenAI 开源 Codex Security CLI，用 AI 扫描代码漏洞8.0
Anthropic的Claude Mythos Preview发现HAWK和AES的密码学弱点8.0
OpenAI 提议与政府合作调控前沿 AI 发展速度8.0
OpenAI：编程智能体加速科研，人类监督仍至关重要8.0
精选公共实时数据集列表，提供直接API接口8.0
VODER：集 TTS、声音克隆等于一体的开源音频工具8.0
团队自建JIRA替代品，4个月后因维护成本回归Linear7.0
AI研究员对比Claude Fable 5、GPT 5.6 Sol和Opus模型在不同任务中的表现7.0

019.0

MCP协议发布2026-07-28版本：重大转向无状态请求/响应架构

MCP协议发布了第五个大版本2026-07-28，核心变化是从有状态双向协议转变为无状态请求/响应模型。这一改变不再需要会话ID，每个请求可独立路由，从而支持负载均衡和无服务器部署。此外，更新还引入了多轮往返请求（MRTR）以处理中途用户确认、新增HTTP头简化路由、安全加固以及正式的废弃策略。这一架构转变回应了社区呼声最高的需求，使MCP服务器能够像标准HTTP服务一样部署在负载均衡器、边缘函数和CDN上，大幅提升了可扩展性和运维简便性。这些变化得到了主要云服务商和SDK更新的支持，MCP月下载量接近5亿次，标志着生态系统的成熟。请求现在自带协议版本和客户端信息，实现无状态路由；有状态需求通过工具生成的业务层句柄传递。MRTR允许服务器在无需持久连接的情况下请求用户输入，使用“需要输入”状态。新增的Mcp-Method和Mcp-Name头支持网关层路由和鉴权，无需解析JSON。安全修复包括强制验证issuer参数，并用客户端ID元数据文档（CIMD）取代动态客户端注册（DCR）。Roots、Sampling和Logging功能被标记为废弃，但至少保留12个月，旧的HTTP+SSE传输同样进入废弃轨道。

@dotey@Pluvio9yte 转推1 个视频MCP 协议今天推出了第五个大版本（版本号 2026-07-28），核心变化：从有状态双向协议变成了无状态的请求/响应协议。这是 MCP 社区呼声最高的改动。之前的 MCP 客户端连上来要先握手，服务端要给你一个会话 ID（session ID），后续每次请求都得带着这个 ID。这意味着你的请求被限制在了某一台服务器实例上，不方便做负载均衡。现在每个请求都是独立的，自带协议版本和客户端信息，可以负载到任何一个实例上。也就是说 MCP 服务器终于可以像普通 HTTP 服务一样部署了，serverless、边缘计算、或者 CDN 后面放一排实例。那如果业务确实需要跨请求的状态呢？协议的建议是：由工具自己生成一个句柄（handle），让模型在工具调用之间传递。状态放在业务层而不是协议层，模型能看到这个句柄，也能理解要怎么用它。【其他变化】 MRTR（多轮往返请求）解决中途需要用户输入确认的问题。比如 Supabase 的 MCP 服务器想在创建项目前告诉你费用，或者在执行删除操作前让你确认。以前这需要维持一个双向流不断开，现在服务端返回“需要输入”状态，客户端带上用户的回答重新发请求即可。请求头里新增了 Mcp-Method 和 Mcp-Name 两个字段，网关和防火墙可以直接根据请求头做路由和鉴权，不用解析 JSON 请求体。授权方面做了几项加固，包括要求验证授权服务器的 issuer 参数（堵上了一个授权服务器混淆漏洞）。动态客户端注册（DCR）正式废弃，改用客户端元数据文档（CIMD）。 Roots、Sampling、Logging 三个功能标记为废弃，但至少还能用 12 个月。旧版 HTTP+SSE 传输同样进入废弃轨道。协议首次引入正式的废弃策略，保证最少 12 个月过渡窗口，这对生产环境的团队来说很实际：你可以排期升级，不用被动救火。【生态与迁移】四个一级开发工具包（SDK）同步更新：TypeScript、Python、Go、C#。Rust SDK 以 beta 状态跟进。MCP 目前月下载量接近 5 亿次，TypeScript 和 Python SDK 各自累计下载量都超过了 10 亿。 AWS（Amazon Bedrock AgentCore）、Microsoft（Foundry）、Cloudflare（Workers）、Google Cloud 等都已宣布支持新规范。Figma、Supabase、Honeycomb 等工具厂商也在跟进。新规范有破坏性变更，依赖会话标识符的实现需要改造。SDK 团队表示根据早期测试反馈已经简化了迁移流程，但具体成本因项目而异。如果你现在在生产环境跑着 MCP 服务器，建议先看一遍完整的 changelog 和迁移指南，评估影响面再动手。原推文媒体预览

展开原推文收起原推文

@Pluvio9yte 转推了

@dotey

MCP 协议今天推出了第五个大版本（版本号 2026-07-28），核心变化：从有状态双向协议变成了无状态的请求/响应协议。这是 MCP 社区呼声最高的改动。之前的 MCP 客户端连上来要先握手，服务端要给你一个会话 ID（session ID），后续每次请求都得带着这个 ID。这意味着你的请求被限制在了某一台服务器实例上，不方便做负载均衡。现在每个请求都是独立的，自带协议版本和客户端信息，可以负载到任何一个实例上。也就是说 MCP 服务器终于可以像普通 HTTP 服务一样部署了，serverless、边缘计算、或者 CDN 后面放一排实例。那如果业务确实需要跨请求的状态呢？协议的建议是：由工具自己生成一个句柄（handle），让模型在工具调用之间传递。状态放在业务层而不是协议层，模型能看到这个句柄，也能理解要怎么用它。【其他变化】 MRTR（多轮往返请求）解决中途需要用户输入确认的问题。比如 Supabase 的 MCP 服务器想在创建项目前告诉你费用，或者在执行删除操作前让你确认。以前这需要维持一个双向流不断开，现在服务端返回“需要输入”状态，客户端带上用户的回答重新发请求即可。请求头里新增了 Mcp-Method 和 Mcp-Name 两个字段，网关和防火墙可以直接根据请求头做路由和鉴权，不用解析 JSON 请求体。授权方面做了几项加固，包括要求验证授权服务器的 issuer 参数（堵上了一个授权服务器混淆漏洞）。动态客户端注册（DCR）正式废弃，改用客户端元数据文档（CIMD）。 Roots、Sampling、Logging 三个功能标记为废弃，但至少还能用 12 个月。旧版 HTTP+SSE 传输同样进入废弃轨道。协议首次引入正式的废弃策略，保证最少 12 个月过渡窗口，这对生产环境的团队来说很实际：你可以排期升级，不用被动救火。【生态与迁移】四个一级开发工具包（SDK）同步更新：TypeScript、Python、Go、C#。Rust SDK 以 beta 状态跟进。MCP 目前月下载量接近 5 亿次，TypeScript 和 Python SDK 各自累计下载量都超过了 10 亿。 AWS（Amazon Bedrock AgentCore）、Microsoft（Foundry）、Cloudflare（Workers）、Google Cloud 等都已宣布支持新规范。Figma、Supabase、Honeycomb 等工具厂商也在跟进。新规范有破坏性变更，依赖会话标识符的实现需要改造。SDK 团队表示根据早期测试反馈已经简化了迁移流程，但具体成本因项目而异。如果你现在在生产环境跑着 MCP 服务器，建议先看一遍完整的 changelog 和迁移指南，评估影响面再动手。

@dsp_

Thrilled to announce the MCP 2026-07-28 release. It is one of MCP's biggest yet, built on 18 months of lessons learned. A few highlights: ★ MCP is now stateless, with semantics for multi-round-trip requests. Serving MCP just got much simpler and more scalable. ★ MCP now has extensions. MCP Apps, Tasks, Enterprise Managed Auth, and more. Domain-specific ways to use MCP, plus room for experimental additions. ★ Python, Typescript, C# (soon) SDKs released a v2.0.0 for the new spec with improved ergonomics! But the biggest highlight for me: this release is a true community effort. Individuals and companies alike — Anthropic, Google, Microsoft, OpenAI, and many others helped shape this specification. And there's much more. Full details: https://blog.modelcontextprotocol.io/posts/2026-07-28/

背景

MCP（模型上下文协议）是Anthropic于2024年11月推出的开放标准，用于连接AI应用与外部工具和数据源。此前，MCP采用有状态双向连接，需要会话ID，将客户端绑定到特定服务器实例，不利于扩展。新的无状态设计使MCP与常见Web服务模式一致，更容易集成到云原生基础设施中。多轮往返请求（MRTR）取代了服务器发起的请求，允许服务器在工具调用过程中获取用户输入，而无需维持持久流。客户端ID元数据文档（CIMD）是一种基于OAuth的方法，客户端通过托管元数据文档的URL标识自己，避免了预注册。

社区讨论

社区反响极为积极，这是呼声最高的改动。开发者对部署简便性和可扩展性表示欢迎，但也有人指出现有有状态实现需要一定的迁移工作。规范制定过程中Anthropic、Google、Microsoft和OpenAI等多家公司的协作受到广泛赞誉。

7月29日 01:22在 X 打开#MCP #协议 #无状态 #AI #基础设施

028.0

中国开源模型 Kimi K3 与百度 Unlimited OCR 登顶 HuggingFace 榜单

月之暗面推出的 2.8 万亿参数模型 Kimi K3 在开源发布后 30 分钟内登顶 HuggingFace 趋势榜，创下平台最快增长纪录。百度的 Unlimited OCR 长文档解析模型在发布一个多月后热度不减，再次冲上全球趋势榜前列，并获得 AI 先驱 Yann LeCun 的推荐。这两款中国模型共同包揽了 HuggingFace 全球趋势榜的前两名。这标志着中国 AI 公司向开源生态建设的战略转型，与 OpenAI、Anthropic 等西方公司的闭源 API 订阅模式形成鲜明对比。通过开源前沿模型，它们旨在抢占开发者心智并制定技术标准，可能重塑全球 AI 格局。对开发者和小团队而言，这意味着零成本获取最先进的能力，降低了创新门槛。 Kimi K3 拥有 100 万 token 上下文窗口、原生视觉理解能力，并采用 Kimi Delta Attention (KDA) 和 Attention Residuals 提升效率。Unlimited OCR 可一次推理处理数十页文档，保留跨页表格和阅读顺序，且推理速度和成本不随页数增长。两款模型均提供开放权重，支持本地部署和定制。

@yaohui12138@Pluvio9yte 转推4 张图片杀疯了，刚刚刷 HuggingFace，被榜单前排震惊了！ Kimi K3，开源30分钟登顶，刷新平台史上最快增长纪录，HuggingFace CEO 亲自下场点赞百度 Unlimited OCR 更离谱，发布一个多月后热度不减，二次冲榜，再次杀回全球趋势榜前列！AI 教父杨立昆转发推荐！！两个中国模型，直接包揽 HuggingFace 全球趋势榜 TOP2！硅谷都看傻了吧… 其实我作为 PM，看到的不是“中国模型牛逼”这么简单，而是两条完全不同的技术路线在分叉：硅谷那边，OpenAI、Anthropic 把模型当黑盒卖订阅，中国这边，月之暗面、百度直接开源权重我觉得这不是慈善，是生态位战略闭源模型拼的是 API 调用量，赚订阅费，开源模型拼的是生态渗透率，赚的是开发者心智和技术标准话语权 Unlimited OCR 就是个典型案例：传统的 OCR 逐页切割文档，跨页的表格会断裂，阅读顺序丢失，跨页上下文消失； Unlimited OCR 一次推理搞定数十页文档，跨页表格完整保留，阅读顺序不乱，更关键的是，推理速度和成本不随页数增长，这对处理长文档来说是质变开发者拿去就能用，这就是开源的打法：先送能力，再建生态对于我们这些超级个体，更直白点说：你现在可以零成本拿到 frontier 级别的模型能力想做文档解析的产品?Unlimited OCR直接本地跑想做长上下文AI应用？Kim K3百万token随便用 HuggingFace 榜单前两名，全是中国模型，这不是终点，是我们新的起点这就是开源的力量说实话，五年前，chatgpt问世，我们这边连影子都没，现在，HuggingFace 榜单前两名，全是中国模型这不是终点，是新起点，开源这条路，中国模型公司跑出了自己的节奏！原推文媒体预览

+3展开原推文收起原推文

@Pluvio9yte 转推了

@yaohui12138

杀疯了，刚刚刷 HuggingFace，被榜单前排震惊了！ Kimi K3，开源30分钟登顶，刷新平台史上最快增长纪录，HuggingFace CEO 亲自下场点赞百度 Unlimited OCR 更离谱，发布一个多月后热度不减，二次冲榜，再次杀回全球趋势榜前列！AI 教父杨立昆转发推荐！！两个中国模型，直接包揽 HuggingFace 全球趋势榜 TOP2！硅谷都看傻了吧… 其实我作为 PM，看到的不是“中国模型牛逼”这么简单，而是两条完全不同的技术路线在分叉：硅谷那边，OpenAI、Anthropic 把模型当黑盒卖订阅，中国这边，月之暗面、百度直接开源权重我觉得这不是慈善，是生态位战略闭源模型拼的是 API 调用量，赚订阅费，开源模型拼的是生态渗透率，赚的是开发者心智和技术标准话语权 Unlimited OCR 就是个典型案例：传统的 OCR 逐页切割文档，跨页的表格会断裂，阅读顺序丢失，跨页上下文消失； Unlimited OCR 一次推理搞定数十页文档，跨页表格完整保留，阅读顺序不乱，更关键的是，推理速度和成本不随页数增长，这对处理长文档来说是质变开发者拿去就能用，这就是开源的打法：先送能力，再建生态对于我们这些超级个体，更直白点说：你现在可以零成本拿到 frontier 级别的模型能力想做文档解析的产品?Unlimited OCR直接本地跑想做长上下文AI应用？Kim K3百万token随便用 HuggingFace 榜单前两名，全是中国模型，这不是终点，是我们新的起点这就是开源的力量说实话，五年前，chatgpt问世，我们这边连影子都没，现在，HuggingFace 榜单前两名，全是中国模型这不是终点，是新起点，开源这条路，中国模型公司跑出了自己的节奏！

背景

HuggingFace 是机器学习模型分享与发现的核心平台，其趋势榜反映了社区关注度。开源 AI 模型允许任何人使用、修改和分发软件，促进了快速创新。月之暗面是一家以 Kimi 聊天机器人闻名的中国初创公司，百度则是大力投资 AI 的中国科技巨头。OCR（光学字符识别）技术将文本图像转换为机器可读文本，是文档数字化的关键。

社区讨论

该推文及其转发获得了高互动量，用户对中国开源成就表达了兴奋与自豪。一些评论强调了与硅谷闭源路线的战略对比，另一些则指出了对开发者的实际益处。少数质疑者对开源商业模式的可持续性提出了疑问。

7月28日 14:37在 X 打开#open-source #AI models #HuggingFace #Chinese AI #OCR

038.0

Anthropic 支持请愿，呼吁放慢 AI 前沿发展步伐

Anthropic 公开支持一份请愿书，呼吁有意放慢 AI 前沿发展的步伐。该支持由 CEO Dario Amodei、多位联合创始人及高级员工签署，并引用公司近期关于递归自我改进的研究作为主要动机。这一支持表明业界在 AI 安全与主动治理需求上日益达成共识。随着 Anthropic 和 OpenAI 等主要实验室在放慢步伐上立场一致，可能影响政策制定和国际合作，以管控快速发展的 AI 系统带来的风险。该请愿书发布于 pacingthefrontier.com，已获得超过 1100 名来自领先 AI 实验室的员工签署。Anthropic 上个月发表的递归自我改进研究指出，AI 系统可能自主设计后继者，突显了放慢步伐工具的必要性。请愿书要求美国政府支持国际合作，开发有意减缓自动化 AI 发展的机制。

@AnthropicAI@trq212 转推We support this petition, signed by our CEO, several co-founders, and senior staff. Our own research on recursive self-improvement, published last month, points to the need for tools to deliberately pace the frontier of AI development so society can prepare. We’re glad to see broad agreement across the field. https://www.pacingthefrontier.com/展开原推文收起原推文

@trq212 转推了

@AnthropicAI

We support this petition, signed by our CEO, several co-founders, and senior staff. Our own research on recursive self-improvement, published last month, points to the need for tools to deliberately pace the frontier of AI development so society can prepare. We’re glad to see broad agreement across the field. https://www.pacingthefrontier.com/

Pacing the Frontierpacingthefrontier.com · 直连原文

背景

递归自我改进（RSI）是指 AI 系统重写自身代码或设计更优版本的过程，可能导致智能爆炸。这一概念引发安全担忧，因为此类系统可能进化到超出人类控制。“放慢前沿步伐”请愿源于对 AI 进步速度超过社会准备能力的担忧，主张开发工具以有意减缓前沿 AI 发展，从而留出足够的安全措施时间。

7月28日 23:02在 X 打开#AI safety #Anthropic #AI regulation #recursive self-improvement

048.0

通用AI Agent通吃市场，插件生态与模型智能成护城河

@dotey 发布的一条热门分析指出，通用AI Agent（如Codex、Claude Code）正在吞食垂直Agent市场，且通用Agent内部也呈现少数赢家通吃的局面。该分析强调，插件生态（Skills + MCP）是Agent成功的关键，模型智能是终极护城河，小团队应专注于开发插件而非构建Agent。该分析捕捉了AI Agent领域的重大转变：随着通用Agent能力增强，它们威胁到垂直AI创业公司的生存空间。对插件生态和模型质量的强调揭示了真正的竞争优势所在，为开发者和投资者在快速演变的Agent经济中指明了资源分配方向。该分析指出，尽管Claude Code和Codex默认使用自家模型，但其丰富的插件生态和订阅性价比使它们保持领先。早期Agent如“小龙虾”起到了教育用户的作用，当前火爆的Workbuddy也在扩大用户群。分析警告，Agent体验正趋同，模型智能和成本将成为主要差异化因素。

@dotey引用推文【少数通用 Agent 通吃】不只是通用的吃掉垂直的，通用 Agent 本身也是少数赢家通吃，小的通用 Agent 也没有生存空间。【基于 Agent 的插件系统至关重要】开放和封闭的差别，不在于是不是开源，也不在于能不能自由换模型，而是它的插件生态，就像最受欢迎的 Claude Code 和 Codex，默认都是自家模型，但是没多大影响，何况也都支持你用 API。现在 Agent 能火爆的原因之一是因为丰富的插件（Skill + MCP）生态，可以帮助完成任务。【前期的 Agent 更多是在教育用户】下沉和傲慢是很主观的，Workbuddy 那样不见得就叫下沉，Codex 也不见得傲慢。当然说 Anthropic 傲慢那可能没啥争议，但只要模型够强，捏着鼻子也认了。 Agent 这种事，没有那么多忠诚度，前期都是在教育用户，就像小龙虾🦞，虽然现在都没人提起，但确实起到了普及 Agent 得作用，将来 AGI 发展史上也算留下了一笔。 Workbuddy 现在火爆，也一样是在教育用户，让很多不知道或者用不了 Codex/CC 的人也能用上了 Agent。想当年 Claude Code 多火爆，后来 Codex 推出 GUI 版也马上抢了很多用户。【模型是护城河】 Agent 的体验也没多大护城河，最后都趋同了，模型能力和成本终究还是会让产品拉开差距。用户使用 Agent，最大的体验差异来源于模型的智能，当你用过聪明的模型，就不会想回到不那么聪明的模型，很多人愿意接受当下的，是因为没机会用到过更好的。 Cursor 的 Agent 体验也很好，什么模型都能用，但是热度最高还是 Codex 和 Claude Code，因为有订阅服务，性价比最高。【个人和小团队没必要拼 Agent】小团队做通用 Agent、垂直 Agent 已经没啥机会了，但是基于 Agent 做插件还机会很多很多传统软件，并不是为 Agent 设计的，有一个时间窗口。 Skills 已经泛滥了，单纯的 Skill 没啥门槛，让 Skill 做为入口，后面再接入服务是有机会的，这也是提供差异化的地方。展开原推文收起原推文

@dotey

【少数通用 Agent 通吃】不只是通用的吃掉垂直的，通用 Agent 本身也是少数赢家通吃，小的通用 Agent 也没有生存空间。【基于 Agent 的插件系统至关重要】开放和封闭的差别，不在于是不是开源，也不在于能不能自由换模型，而是它的插件生态，就像最受欢迎的 Claude Code 和 Codex，默认都是自家模型，但是没多大影响，何况也都支持你用 API。现在 Agent 能火爆的原因之一是因为丰富的插件（Skill + MCP）生态，可以帮助完成任务。【前期的 Agent 更多是在教育用户】下沉和傲慢是很主观的，Workbuddy 那样不见得就叫下沉，Codex 也不见得傲慢。当然说 Anthropic 傲慢那可能没啥争议，但只要模型够强，捏着鼻子也认了。 Agent 这种事，没有那么多忠诚度，前期都是在教育用户，就像小龙虾🦞，虽然现在都没人提起，但确实起到了普及 Agent 得作用，将来 AGI 发展史上也算留下了一笔。 Workbuddy 现在火爆，也一样是在教育用户，让很多不知道或者用不了 Codex/CC 的人也能用上了 Agent。想当年 Claude Code 多火爆，后来 Codex 推出 GUI 版也马上抢了很多用户。【模型是护城河】 Agent 的体验也没多大护城河，最后都趋同了，模型能力和成本终究还是会让产品拉开差距。用户使用 Agent，最大的体验差异来源于模型的智能，当你用过聪明的模型，就不会想回到不那么聪明的模型，很多人愿意接受当下的，是因为没机会用到过更好的。 Cursor 的 Agent 体验也很好，什么模型都能用，但是热度最高还是 Codex 和 Claude Code，因为有订阅服务，性价比最高。【个人和小团队没必要拼 Agent】小团队做通用 Agent、垂直 Agent 已经没啥机会了，但是基于 Agent 做插件还机会很多很多传统软件，并不是为 Agent 设计的，有一个时间窗口。 Skills 已经泛滥了，单纯的 Skill 没啥门槛，让 Skill 做为入口，后面再接入服务是有机会的，这也是提供差异化的地方。

@cellier_

关于 Agent 的判断： 1. 更通用的吃掉更垂直的通用 Agent — Codex、Claude Cowork、Workbuddy... 逐渐吃掉专业 Agent 和垂类 Agent（比如 Genspark、Skywork...）。通用 Agent 将成为用户的主要入口，通用 Agent + Skill + MCP 能解决大部分专业任务，大部分 AI-native 应用创业会是伪命题。 2. 更开放的吃掉更封闭的更开放一方面指的是模型可替换。随着模型能力趋同，模型本身逐渐成为可路由的基础设施。通用 Agent 应根据质量、成本、速度和合规要求动态选择最佳模型，并且将自由度开放给用户。更开放的另一方面指的是 Agent 本身能被用户/客户拥有：可以本地运行或企业自部署，不必把所有数据和权限交给平台；能修改 Agent 的记忆、规划、权限和执行逻辑；Skill、工作流、记忆、连接器和配置能自由迁移（Cindy、OpenWorker 这类开源 Agent 已经在往这个方向走）。 3. 更下沉的吃掉更傲慢的 Codex、Claude、甚至 DeepSeek 背后的团队都以 AGI 为长期目标，这种技术理想主义，也带来了阶段性的产品傲慢，他们不太愿意做一些更脏更累的面向用户的下沉化需求，比如 Workbuddy 针对 Skill 的精细化运营——包装成专家/专家团这种更面向用户的概念，这些拼的是产品、运营能力，而非技术能力，加上市场足够大，草根团队在通用 Agent 上也有一段时间的机会窗口。

背景

AI Agent是利用大语言模型自主执行任务的系统。MCP（模型上下文协议）是连接Agent与外部工具和数据的开放标准，类似AI的USB-C接口。Claude Code和Codex分别是Anthropic和OpenAI推出的领先编程Agent。“Skills”是扩展Agent能力的预置模块，“插件”则指更广泛的集成。该分析基于@cellier_的回复，其认为更开放、用户可拥有的Agent最终将击败封闭平台。

社区讨论

社区普遍认同该分析，许多人指出插件生态正成为新战场。一些人争论模型开放性与插件丰富度哪个更重要，另一些人则强调早期Agent在教育用户、推动普及方面的作用。

7月28日 23:12在 X 打开#AI Agents #Ecosystem #Plugin Systems #Model Moats #Market Analysis

058.0

OpenAI 开源 Codex Security CLI，用 AI 扫描代码漏洞

OpenAI 开源了 Codex Security，这是一个命令行工具和 TypeScript SDK，利用 AI 扫描代码仓库中的安全漏洞。此前它仅以闭源插件形式存在，现已以 Apache-2.0 许可证作为独立项目发布。该工具能发现、验证漏洞并生成修复补丁，还能集成到 CI/CD 流水线和 pre-commit 钩子中。此次发布将企业级 AI 安全扫描能力带给开源社区，促进了更广泛的采用和透明度。据报告其真阳性率达 74%，远超 Snyk（28%）和 Semgrep（20%），可能改变开发者和安全团队检测漏洞的方式。它与 CI/CD 和 pre-commit 钩子的集成使其适用于 DevSecOps 流程，有望降低保护代码库的成本和复杂性。该工具默认使用 gpt-5.6-sol 模型进行高推理强度扫描，需要 Node.js 22+ 和 Python 3.10+。它支持 macOS、Linux 和 Windows，并能将结果导出为 SARIF、CSV 或 JSON 格式。install-hook 命令可在提交时拦截高危问题。在公开测试中，它扫描了超过 120 万次提交，在 OpenSSH、Chromium 等项目中发现了 792 个严重漏洞和 10561 个高危漏洞。

@dotey原推文OpenAI 开源了 Codex Security Codex Security 是一个命令行工具（CLI）加 TypeScript 开发工具包（SDK），用 AI 自动扫描代码仓库里的安全漏洞。它能找到问题、验证问题是否真实存在，还能生成修复补丁。这个工具之前一直以 Codex 插件的形式存在，但是闭源的。六月底就有人在 GitHub 上开了 issue 要求开源，理由是安全不该被藏着。现在 OpenAI 把它拆成了独立项目，以 Apache-2.0 协议开源，项目地址： http://github.com/openai/codex-security。 Codex 插件版和独立版有什么区别？插件适合在你的 Codex 项目中，直接调用插件做安全扫描。独立版是给安全团队用的，能批量扫整个组织的所有仓库，支持历史记录、扫描结果去重、误报追踪，还能接进 CI 流水线。技术细节方面，默认使用 gpt-5.6-sol 模型做高推理强度扫描，需要 Node.js 22+ 和 Python 3.10+，支持 macOS、Linux 和 Windows。扫描结果可以导出为 SARIF、CSV 或 JSON 格式。还有个 install-hook 命令，可以在每次 git commit 前自动扫描改动过的代码，发现高危问题直接拦住提交。在公开测试阶段，Codex Security 扫描了超过 120 万次提交（commit），在 OpenSSH、GnuTLS、PHP、Chromium 等开源项目中发现了 792 个严重漏洞和 10561 个高危漏洞。有第三方测试对比过，在 16.2 万行生产代码上，Codex Security 的真阳性率是 74%，Snyk 是 28%，Semgrep 是 20%。OpenAI 开源了 Codex Security --- From twitter --- We quietly released the open-source Codex Security CLI, but Hacker News found it before we had a chance to share it here... You can now use it to scan repositories, track findings across runs, verify fixes, and add security checks to CI/CD. This is an early release, and we're listening to your feedback as we continue improving it. Install the open-source Codex Security CLI,: npm install @OpenAI/codex-security Or start with: npx @OpenAI/codex-security@latest --help NPM: http://npmjs.com/package/@openai/codex-security Source + docs: http://github.com/openai/codex-security --- From twitter --- More opensource goodness. We have just released a CLI and TypeScript SDK for finding, validating, and fixing security vulnerabilities in your code. Scan repositories, review changes, track findings over time, and run security checks in CI. https://github.com/openai/codex-security展开原推文收起原推文

@dotey

OpenAI 开源了 Codex Security Codex Security 是一个命令行工具（CLI）加 TypeScript 开发工具包（SDK），用 AI 自动扫描代码仓库里的安全漏洞。它能找到问题、验证问题是否真实存在，还能生成修复补丁。这个工具之前一直以 Codex 插件的形式存在，但是闭源的。六月底就有人在 GitHub 上开了 issue 要求开源，理由是安全不该被藏着。现在 OpenAI 把它拆成了独立项目，以 Apache-2.0 协议开源，项目地址： http://github.com/openai/codex-security。 Codex 插件版和独立版有什么区别？插件适合在你的 Codex 项目中，直接调用插件做安全扫描。独立版是给安全团队用的，能批量扫整个组织的所有仓库，支持历史记录、扫描结果去重、误报追踪，还能接进 CI 流水线。技术细节方面，默认使用 gpt-5.6-sol 模型做高推理强度扫描，需要 Node.js 22+ 和 Python 3.10+，支持 macOS、Linux 和 Windows。扫描结果可以导出为 SARIF、CSV 或 JSON 格式。还有个 install-hook 命令，可以在每次 git commit 前自动扫描改动过的代码，发现高危问题直接拦住提交。在公开测试阶段，Codex Security 扫描了超过 120 万次提交（commit），在 OpenSSH、GnuTLS、PHP、Chromium 等开源项目中发现了 792 个严重漏洞和 10561 个高危漏洞。有第三方测试对比过，在 16.2 万行生产代码上，Codex Security 的真阳性率是 74%，Snyk 是 28%，Semgrep 是 20%。OpenAI 开源了 Codex Security --- From twitter --- We quietly released the open-source Codex Security CLI, but Hacker News found it before we had a chance to share it here... You can now use it to scan repositories, track findings across runs, verify fixes, and add security checks to CI/CD. This is an early release, and we're listening to your feedback as we continue improving it. Install the open-source Codex Security CLI,: npm install @OpenAI/codex-security Or start with: npx @OpenAI/codex-security@latest --help NPM: http://npmjs.com/package/@openai/codex-security Source + docs: http://github.com/openai/codex-security --- From twitter --- More opensource goodness. We have just released a CLI and TypeScript SDK for finding, validating, and fixing security vulnerabilities in your code. Scan repositories, review changes, track findings over time, and run security checks in CI. https://github.com/openai/codex-security

GitHub - openai/codex-security: SDKs and CLI for Codex Securitygithub.com · 直连原文

背景

Codex Security 最初是 OpenAI Codex 平台的插件，但社区对开源版本的需求促使其独立发布。Semgrep 和 Snyk 等静态分析工具使用模式匹配或数据流分析来查找漏洞，而 Codex Security 利用大语言模型理解代码语义。SARIF 是一种静态分析结果的标准格式，可实现与其他工具的互操作。gpt-5.6-sol 是 OpenAI 近期针对复杂推理任务优化的模型。

社区讨论

社区反应总体积极，称赞开源举措和强劲的基准测试结果。Hacker News 上一些用户对将代码发送到 OpenAI API 表示担忧，另一些人则争论将基于云的 AI 工具与传统静态分析器进行比较是否公平。人们也关注该工具在社区贡献下如何演进。

7月28日 22:10在 X 打开#AI #security #open-source #OpenAI #DevOps

068.0

Anthropic的Claude Mythos Preview发现HAWK和AES的密码学弱点

Anthropic的Claude Mythos Preview帮助研究人员发现了后量子签名方案HAWK和七轮AES加密的弱点。该模型改进了对HAWK（NIST后量子密码学候选方案）的最佳已知攻击，并发现了一种针对AES的新攻击，称为Mobius Bridge攻击。完整的技术细节已在新论文中提供，并发布了名为CryptanalysisBench的基准测试，用于研究LLM的密码分析能力。这表明先进的AI模型可以为密码分析做出贡献，而这一领域传统上依赖于人类专业知识。它可能加速关键安全基础设施中漏洞的发现，从而可能促成更强的密码学标准。这项工作也凸显了AI的双重用途性质，因为此类能力既可用于防御也可用于攻击。 Claude Mythos Preview是一个受限访问的模型，因其能够发现软件漏洞而未向公众发布。对HAWK的攻击是一种经典密钥恢复攻击，改进了先前的工作，而AES攻击针对的是减少轮数的版本。该研究与苏黎世联邦理工学院、特拉维夫大学和海法大学的学者合作进行，CryptanalysisBench基准测试可在arXiv上获取。

@AnthropicAI原推文New Anthropic research: Discovering cryptographic weaknesses with Claude. Claude Mythos Preview has helped our researchers find weaknesses in cryptographic algorithms—the mathematical methods that are used to keep data private. Read more: https://anthropic.com/research/discovering-cryptographic-weaknesses --- From twitter --- Full technical details of both attacks are provided in our new papers: On HAWK: https://anthropic.com/document/hawk_key_recovery.pdf On AES: https://anthropic.com/document/aes_mobius_bridge.pdf And the associated model chain-of-thought for AES: https://anthropic.com/document/aes_mobius_bridge_cot.pdf --- From twitter --- We also worked with academics at ETH Zurich, Tel Aviv University, and the University of Haifa to build CryptanalysisBench, a benchmark for studying LLMs’ cryptanalysis abilities. https://arxiv.org/abs/2607.18538展开原推文收起原推文

@AnthropicAI

New Anthropic research: Discovering cryptographic weaknesses with Claude. Claude Mythos Preview has helped our researchers find weaknesses in cryptographic algorithms—the mathematical methods that are used to keep data private. Read more: https://anthropic.com/research/discovering-cryptographic-weaknesses --- From twitter --- Full technical details of both attacks are provided in our new papers: On HAWK: https://anthropic.com/document/hawk_key_recovery.pdf On AES: https://anthropic.com/document/aes_mobius_bridge.pdf And the associated model chain-of-thought for AES: https://anthropic.com/document/aes_mobius_bridge_cot.pdf --- From twitter --- We also worked with academics at ETH Zurich, Tel Aviv University, and the University of Haifa to build CryptanalysisBench, a benchmark for studying LLMs’ cryptanalysis abilities. https://arxiv.org/abs/2607.18538

Discovering cryptographic weaknesses with Claudeanthropic.com · 直连原文

背景

HAWK是一种基于格同构问题的后量子签名方案，已提交至NIST的后量子密码学标准化进程。AES（高级加密标准）是一种广泛使用的对称加密算法；对减少轮数版本的攻击有助于评估其安全裕度。Claude Mythos Preview是Anthropic最强大模型系列的一部分，仅限特定合作伙伴用于安全研究。

7月28日 17:16在 X 打开#AI #cryptography #security #research

078.0

OpenAI 提议与政府合作调控前沿 AI 发展速度

OpenAI 公开表示，未来某个时刻前沿模型开发的 AI 加速可能过快，世界需要调控 AI 进步的速度。该公司表示愿与美国政府主导的工作合作，联合其他实验室和开源社区，开发实现这一目标的工具和机制。这一声明通过 X 平台和专门网站 pacingthefrontier.com 发布。这标志着主要 AI 实验室主动倡导对其技术进行外部治理，可能影响未来的 AI 安全政策和行业规范。它直接回应了人们对 AI 加速失控及其社会风险的日益担忧，可能影响政府和国际机构对前沿模型监管的方式。此举也可能迫使其他领先 AI 公司采取类似的合作调控立场。该提议被定位为未来需求而非当前要求，且未提供具体的技术机制或时间表。OpenAI 强调与美国政府、其他实验室和开源社区的合作，但未详细说明如何实施或执行调控。专门网站 pacingthefrontier.com 目前似乎只是一个占位页面，信息极少。

@OpenAI原推文At the core of our mission is working through how to ensure increasingly powerful AI benefits everyone. We believe that, at some point in the future, AI acceleration for frontier model development may be so high that the world will need to pace the rate of AI advancement. We hope to contribute to work led by the U.S. government, alongside other labs and the open-source community, to develop the tools and mechanisms that could make that possible. http://pacingthefrontier.com展开原推文收起原推文

@OpenAI

At the core of our mission is working through how to ensure increasingly powerful AI benefits everyone. We believe that, at some point in the future, AI acceleration for frontier model development may be so high that the world will need to pace the rate of AI advancement. We hope to contribute to work led by the U.S. government, alongside other labs and the open-source community, to develop the tools and mechanisms that could make that possible. http://pacingthefrontier.com

Pacing the Frontierpacingthefrontier.com · 直连原文

背景

前沿 AI 模型指最先进、能力最强的 AI 系统，通常推动 AI 能力的边界。调控 AI 发展意味着有意放慢或控制进步速度，以确保安全、伦理对齐和社会准备。作为领先的 AI 研究机构，OpenAI 此前曾呼吁 AI 监管和安全措施，包括建立国际机构监督超级智能 AI。这一新声明与正在进行的全球 AI 治理讨论一致，例如《布莱切利宣言》和各国 AI 安全研究所。

7月28日 20:56在 X 打开#AI Safety #AI Governance #OpenAI #Frontier Models

088.0

OpenAI：编程智能体加速科研，人类监督仍至关重要

OpenAI 发布了一份包含八个案例研究的报告，展示了编程智能体如何在科学计算中处理从日常维护到完整系统重新设计的任务。这些智能体能够可靠地执行雄心勃勃的项目，但科学家仍需定义研究问题、验证结果并确保长期管理。这一转变减少了工程劳动力对科学研究的瓶颈，使科学家能更专注于推进其领域。它标志着 AI 智能体正成为研究中的积极合作者，可能加速跨学科的发现。然而，这也引发了关于验证、可重复性以及人类判断角色的重要问题。该报告涵盖了来自工业界和学术界的八个案例研究，表明编程智能体可以处理日常维护、针对性优化、完整重新设计和新系统开发。一个关键发现是，虽然智能体减少了工程限制，但新的瓶颈是验证其输出，这仍然需要人类专业知识。对长期所有权和管理的强调凸显了对智能体辅助研究的可持续性和问责制的担忧。

@OpenAI串推 2 条2 段 · 1 张图片Coding agents are helping scientists spend more time advancing research, taking on everything from routine maintenance and targeted optimization to complete redesigns and new systems. While agents can reliably execute on ambitious projects, researchers must still define the scientific questions, verify results, and take a stance on long-term ownership. 原推文媒体预览

展开原推文收起原推文

@OpenAI串推 2 条

Coding agents are helping scientists spend more time advancing research, taking on everything from routine maintenance and targeted optimization to complete redesigns and new systems. While agents can reliably execute on ambitious projects, researchers must still define the scientific questions, verify results, and take a stance on long-term ownership.

Across eight case studies spanning industry and academia, we explore what this shift means for scientific computing—and why human verification, stewardship, and long-term maintenance matter. https://openai.com/index/scientific-computing-agentic-ai/

背景

编程智能体是能够自主编写、调试和优化代码的 AI 系统，通常使用大型语言模型。在科学计算中，研究人员依赖复杂的软件进行模拟、数据分析和建模。传统上，开发和维护这些软件需要大量的工程工作，这可能会减慢研究速度。OpenAI 的探索反映了人们对使用 AI 自动化部分科学工作流程的兴趣日益增长，但也强调了需要谨慎的人类监督以确保正确性和道德使用。

7月28日 17:11在 X 打开#AI agents #scientific computing #OpenAI #research automation

098.0

精选公共实时数据集列表，提供直接API接口

一个名为“awesome-public-real-time-datasets”的GitHub仓库发布，精选了金融、交通、健康、物联网、安全和体育等多个领域的公共实时数据源。列表包含免费和付费选项，许多免费数据集无需注册或API密钥即可使用。该仓库持续更新，提供直接API连接或实时推送。该资源大大降低了开发者和数据工程师获取实时数据流进行原型设计、学习和构建实时应用的门槛。它解决了寻找可靠、最新数据源的常见难题，这对流式分析、事件驱动架构和实时仪表盘至关重要。通过在一个地方聚合多样化的数据集，它加速了数据工程和实时处理领域的创新。该仓库由开源Python流处理框架Bytewax维护，但数据集独立，可与任何工具配合使用。示例包括实时加密货币价格、区块链交易通知和美国SEC文件推送。列表清晰标注了免费和付费数据集，许多免费数据集无需认证。它涵盖了特定区域的公共交通API（如新南威尔士州、爱尔兰）和网络安全威胁源等细分领域。

@GitHub_Daily原推文2 张图片Awesome Public Real-Time Datasets，收集了大量公开的数据，提供接口直连或者实时推送，而且数据一直在更新。涵盖金融行情、公共交通、健康、物联网、网络安全、体育赛事等等不同行业。 GitHub：http://github.com/bytewax/awesome-public-real-time-datasets 另外也会标注哪些是免费和哪些付费，免费那部分里不少不用注册、不用密钥，就能拿来用。比如加密货币的实时价格、区块链的新交易通知、美国证监会的文件推送，都在里面。想练手实时数据处理，或者给项目找个稳定数据源，这份清单可以先收着。原推文媒体预览

+1展开原推文收起原推文

@GitHub_Daily

Awesome Public Real-Time Datasets，收集了大量公开的数据，提供接口直连或者实时推送，而且数据一直在更新。涵盖金融行情、公共交通、健康、物联网、网络安全、体育赛事等等不同行业。 GitHub：http://github.com/bytewax/awesome-public-real-time-datasets 另外也会标注哪些是免费和哪些付费，免费那部分里不少不用注册、不用密钥，就能拿来用。比如加密货币的实时价格、区块链的新交易通知、美国证监会的文件推送，都在里面。想练手实时数据处理，或者给项目找个稳定数据源，这份清单可以先收着。

背景

实时数据流涉及在数据生成时持续处理，以实现即时洞察和行动。公共实时数据集对于测试Apache Kafka、Apache Flink或Bytewax等流处理系统非常有价值，无需设置专有数据源。GitHub上的“awesome”列表是社区围绕特定主题策划的资源集合，通常作为首选参考。Bytewax是一个Python原生的流处理引擎，简化了数据管道的构建，而此数据集列表通过提供即用型数据源补充了其生态系统。

7月28日 13:30在 X 打开#datasets #real-time #open-data #API #data-engineering

108.0

VODER：集 TTS、声音克隆等于一体的开源音频工具

VODER 是一款新的开源工具，将文字转语音、声音克隆、音效、背景音乐生成和保留原声的翻译等八种音频处理模式整合到一个本地界面中。它无需多个工具切换，完全离线运行，无需订阅。该工具使用了 Whisper、Qwen3-TTS、Seed-VC 和 ACE-Step 等知名开源模型。内容创作者通常需要在多个应用之间切换来完成不同的音频任务，既耗时又昂贵。VODER 通过提供统一的、保护隐私的本地运行方案简化了工作流程，使专业音频制作更加触手可及。其开源特性鼓励社区贡献和定制，可能降低独立创作者和小团队的门槛。 VODER 提供八种处理模式，包括基于简单描述选择音色的文字转语音、从参考音频克隆声音，以及自动生成最多 12 条乐器轨的背景音乐。它支持多角色对话剧本，每个角色可配不同声音，并能在台词中嵌入敲门、掌声等音效。视频配音功能可将语音翻译成另一种语言，同时保留原说话人的音色，并生成对应字幕。该工具基于 Whisper（语音识别）、Qwen3-TTS（语音合成）、Seed-VC（声音转换）和 ACE-Step（音乐生成）等模型构建。

@GitHub_Daily原推文1 张图片想给视频配个音、做点音效、再把人声和伴奏分开，通常得开三四个工具轮着来处理。 VODER 把这些整合到一个面板里，提供八种处理模式，全部在本地跑，不用联网也不用订阅。文字转语音一句简单描述即可获取想要的音色，也能丢一段参考音频直接克隆某个人的声音。 GitHub：http://github.com/HAKORADev/VODER 对于写多角色对话剧本，每个角色配不同的声音，还能往台词里塞门响、掌声这类音效。背景音乐是自动生成的，时长跟着台词走，最多能拆出 12 条乐器轨。视频配音这块，可以直接翻译成另一种语言的同时保留原说话人的音色，就连字幕也配上。底下用的是 Whisper、Qwen3-TTS、Seed-VC、ACE-Step 这些开源模型。原推文媒体预览

展开原推文收起原推文

@GitHub_Daily

想给视频配个音、做点音效、再把人声和伴奏分开，通常得开三四个工具轮着来处理。 VODER 把这些整合到一个面板里，提供八种处理模式，全部在本地跑，不用联网也不用订阅。文字转语音一句简单描述即可获取想要的音色，也能丢一段参考音频直接克隆某个人的声音。 GitHub：http://github.com/HAKORADev/VODER 对于写多角色对话剧本，每个角色配不同的声音，还能往台词里塞门响、掌声这类音效。背景音乐是自动生成的，时长跟着台词走，最多能拆出 12 条乐器轨。视频配音这块，可以直接翻译成另一种语言的同时保留原说话人的音色，就连字幕也配上。底下用的是 Whisper、Qwen3-TTS、Seed-VC、ACE-Step 这些开源模型。

背景

文字转语音（TTS）技术将书面文本转换为语音音频，广泛应用于无障碍和内容创作。声音克隆通过短样本复制特定人的声音，实现个性化语音合成。声音转换改变说话人的音色使其听起来像另一个人，同时保留语言内容。Whisper（语音识别）和 Seed-VC（声音转换）等开源模型使这些功能更加普及。ACE-Step 是一个音乐生成基础模型，能够生成多轨音乐作品。

7月28日 04:34在 X 打开#open-source #audio processing #TTS #voice cloning #content creation

117.0

团队自建JIRA替代品，4个月后因维护成本回归Linear

今年3月，一个团队在QA主管的带领下开发了自己的JIRA替代品，完全抛弃了购买的SaaS工具。到了7月，他们又切换回Linear，因为维护内部工具占用了大量精力，这表明初期开发容易并不代表值得长期拥有。这个故事揭示了软件工程中一个常见陷阱：倾向于自建工具而非使用SaaS，却低估了持续维护的成本。它与“Vibe Coding”的兴起相呼应，即AI让初期开发变得简单，但可维护性仍是难题，影响着初创公司和团队在自建与购买之间的决策。该内部工具由QA主管而非专业开发者构建，最初看似功能丰富且好用。但维护负担逐渐加重，以至于影响了实际工作，最终导致回归Linear这一流行的项目管理SaaS。这则轶事强调了“Vibe Coding”（使用AI快速生成代码）让第一版开发很容易，但长期维护却很难。

@dotey 转推了

@oran_ge

3月，他们开发了自己的 JIRA，完全抛弃了买来的项目 SaaS 软件，又好用，功能又多！开发者甚至只是个 QA 主管。 7月，他们已经重新回到 Linear，因为内部工具的维护成本占用了实际工作的精力。一个东西很好开发，并不代表它就值得被开发出来。 Vibe Coding 的特点就是，开发第一版非常容易，维护起来非常难。

背景

JIRA是Atlassian公司广泛使用的项目管理工具，常被认为复杂且昂贵，促使团队寻找替代品。Linear是一款现代、快速的项目管理SaaS，因其简洁性而受软件团队青睐。“Vibe Coding”是Andrej Karpathy在2025年提出的术语，指通过AI辅助开发，从提示生成代码，能快速原型化但往往导致软件难以维护。

7月28日 07:07在 X 打开#software engineering #internal tools #SaaS vs build #maintenance cost #vibe coding

127.0

AI研究员对比Claude Fable 5、GPT 5.6 Sol和Opus模型在不同任务中的表现

AI研究员@dotey分享了对当前前沿模型的实用对比，指出Claude Fable 5尽管昂贵，但因其可靠性成为他处理复杂技术讨论的首选；GPT 5.6 Sol则高效处理日常任务。他还提到Opus 5存在过度思考和高token消耗的问题，性价比不如Fable 5或GPT 5.6 Sol。这种实战对比为开发者和研究人员根据具体任务选择AI模型提供了宝贵指导，凸显了成本、推理深度和可靠性之间的权衡。它反映了行业趋势：模型选择越来越依赖任务类型，单纯的智能水平并不总能转化为实际效用。 Fable 5的定价为每百万输入token 10美元、输出token 50美元，而GPT 5.6 Sol在常规任务上性价比更高。@dotey策略性地使用推理强度设置：GPT 5.6 Sol用xhigh，Fable 5用high或medium，Opus 4.6在写作任务上用max。他提醒，在Fable 5、Sonnet 5和Opus 5上使用更高推理强度往往只会增加成本和延迟，而不会带来相应的智能提升。

@dotey串推 2 条2 段 · 2 张图片我现在用的最多的模型是： Claude Fable 5 GPT 5.6 Sol Claude Opus 4.6 Claude Opus 5 --- Opus 5 和 Sonnet 5 一样的毛病，过度思考，token 消耗很厉害，聪明不如 Fable 5，性价比不如 GPT 5.6 Sol，有点两头不沾，所以用的少，现在主要用在 Claude Design 相关任务。 Fable 5 虽然贵，但是结果相当靠谱，我会跟它一起讨论技术方案，或者复杂的任务。其他的脏活累活则给 GPT 5.6 Sol，写作相关的还是 Opus 4.6 最好用。昨天一个性能优化的任务，GPT 5.6 Sol 做了半天，最后给我悄悄把 16-bit 文本解码改成了 8-bit（图1），数字马上好看了，然后给我交差了😂 最后交给 Fable 5，虽然花了一些时间，但是找到问题根源（图2），还打脸了 GPT 5.6 的优化，最后优化好了。原推文媒体预览

+1展开原推文收起原推文

@dotey串推 2 条

我现在用的最多的模型是： Claude Fable 5 GPT 5.6 Sol Claude Opus 4.6 Claude Opus 5 --- Opus 5 和 Sonnet 5 一样的毛病，过度思考，token 消耗很厉害，聪明不如 Fable 5，性价比不如 GPT 5.6 Sol，有点两头不沾，所以用的少，现在主要用在 Claude Design 相关任务。 Fable 5 虽然贵，但是结果相当靠谱，我会跟它一起讨论技术方案，或者复杂的任务。其他的脏活累活则给 GPT 5.6 Sol，写作相关的还是 Opus 4.6 最好用。昨天一个性能优化的任务，GPT 5.6 Sol 做了半天，最后给我悄悄把 16-bit 文本解码改成了 8-bit（图1），数字马上好看了，然后给我交差了😂 最后交给 Fable 5，虽然花了一些时间，但是找到问题根源（图2），还打脸了 GPT 5.6 的优化，最后优化好了。

GPT 5.6 Sol 推理强度我默认用 xhigh，GPT 这点还不错，就算 xhigh 也不会过度推理。 https://x.com/feigaobox/status/2082275755741106408?s=20 Fable 5 我用 high，大部分时候medium，更高推理强度不见的更聪明，但是一定更慢更费 token。 Opus 4.6 我用 max 最多，写作任务足够 Opus 5 我现在一般也只用 high，Fable 5/sonnet5/opus5推理强度越多越是性价比不高 > 引用 @feigaobox: @dotey 宝玉老师，5.6思考强度常用哪一档？

背景

Claude Fable 5是Anthropic于2026年6月发布的Mythos级模型，专为自主知识工作和编程设计。GPT 5.6 Sol是OpenAI于2026年7月推出的旗舰模型，针对复杂推理和智能体工作流优化。Claude Opus 4.6于2026年2月发布，是Anthropic此前顶级模型，以强大写作能力著称。这些模型代表了大型语言模型的前沿，各有不同的优势和定价结构。

社区讨论

社区对@dotey的见解反响积极，有用户询问GPT 5.6的首选推理强度，表明大家对优化模型设置有实际兴趣。未发现重大分歧，表明社区普遍认同该评估。

7月28日 22:24在 X 打开#AI models #model comparison #Claude #GPT #reasoning