SIGNALFEED文章库 ↗论文库 ↗归档 ↗

8月17日2026 · 星期一

从 33 条抓取中筛选 12 条 · twitter × 4 账号 · 00:45 UTC 生成

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

  1. 开源工具移除AI文本水印，获1万星标8.0
  2. Anthropic 解释基于 SynthID-Text 的 Claude 文本水印8.0
  3. Qwen3.8-27B 通过 Atomic Chat 的 GGUF 量化在笔记本上本地运行8.0
  4. 阿里巴巴通义千问模型下载量突破30亿，领跑全球AI8.0
  5. GPT-5.6 Sol 在 Codex 中为 ChatGPT 账户开放 100 万 Token 上下文8.0
  6. AI 模型的 token 价格因分词方式不同而不可直接比较8.0
  7. 10个用于保护AI代理技能的开源项目8.0
  8. Pi 作者：代码即真相，Bash 优先于 MCP7.0
  9. ChatGPT 现可通过 GitHub 集成直接修改代码并提交 PR7.0
  10. Claude Code 桌面版新增用量限制自动继续复选框7.0
  11. AI 智能体在既定框架内优化却难寻新路：视频转录优化案例7.0
  12. Qwen3.8-27B 登顶 Hugging Face 热门模型榜7.0
018.0

开源工具移除AI文本水印，获1万星标

一个名为 watermarks-remover 的 MIT 许可开源项目在 Anthropic 公布 Claude 文本水印系统细节后数天内，GitHub 星标数达到 10,000。该工具针对 Claude、SynthID-Text 和 OpenAI 的水印，以及图像和 PDF 中的 C2PA 和 EXIF 元数据。这一进展直接挑战了 Anthropic 新推出的溯源机制。 该工具削弱了 AI 内容溯源系统的有效性，而此类系统正日益受到欧盟 AI 法案等法规的强制要求。如果水印可以被轻易移除，那么用于问责、防止虚假信息和版权执法的 AI 生成文本检测能力将严重受损。该工具的迅速流行表明社区对绕过此类控制有强烈兴趣，这引发了关于水印作为信任机制稳健性的紧迫问题。 该仓库采用 MIT 许可，针对多种水印方案：Claude 的统计文本水印、Google 的 SynthID-Text、OpenAI 的标记，以及图像和 PDF 中的 C2PA 和 EXIF 元数据。Anthropic 的文本水印在 token 选择过程中嵌入，因此不可见但可被统计检测。该工具迅速获得 10,000 星标表明其易用性和广泛适用性，但提供的来源中未详细说明具体的移除成功率。

@dotey引用推文已经有移除文本水印的开源项目了 https://github.com/guillaumemeyer/watermarks-remover展开原推文收起原推文

@dotey

已经有移除文本水印的开源项目了 https://github.com/guillaumemeyer/watermarks-remover

GitHub - guillaumemeyer/watermarks-remover: Strip multi-vendor AI provenance marks: Unicode text...github.com · 直连原文

@AiBreakfast

WATERMARK STRIPPER HITS 10,000 STARS DAYS AFTER ANTHROPIC SHIPS PROVENANCE Anthropic detailed how Claude's text watermark works last week. By this morning a MIT-licensed repo that strips it has 10,000 stars, targeting Claude, SynthID-Text and OpenAI marks, plus C2PA and EXIF in images and PDFs. https://github.com/guillaumemeyer/watermarks-remover

背景
AI 文本水印通过微妙地改变 token 选择，在生成的文本中嵌入统计模式，从而在不留下可见标记的情况下实现检测。Anthropic 最近详细介绍了其 Claude 水印系统，并在全球范围内应用，而 Google 的 SynthID-Text 对 Gemini 采用了类似方法。C2PA 是一个由 Adobe、Microsoft 等支持的开源标准，为媒体文件添加加密签名的元数据以证明来源。EXIF 是图像和 PDF 中常见的元数据格式。这些机制旨在区分 AI 生成内容与人类创作内容，以实现透明度和问责制。

8月16日 20:43在 X 打开#AI watermarking #open source #content provenance #Claude #security

028.0

Anthropic 解释基于 SynthID-Text 的 Claude 文本水印

Anthropic 发布了一篇官方技术常见问题解答，解释了 Claude 文本水印的工作原理。该方法基于 Google DeepMind 2024 年提出的 SynthID-Text 方案，并可追溯到 Scott Aaronson 2022 年的提案。水印通过改变选词时使用的随机种子，在输出中留下统计痕迹，事后可用密钥检测。 这是为了遵守欧盟《人工智能法案》，约 190 个签署方已承诺实施类似水印。它影响所有 Claude 用户，因为带水印的文本对读者不可见，但 Anthropic 可以检测。该方法可能成为各大模型提供商 AI 内容溯源的标准做法。 Anthropic 表示水印不会强迫模型选择原本不会选的词，内部测试未发现对质量、创意或可读性的影响。Google DeepMind 在 Gemini 流量上的 A/B 测试显示用户反馈无统计显著差异。水印在短文本、事实性内容和代码上效果较弱，且不携带用户身份信息。检测 API 计划推出但尚未上线。

@dotey引用推文1 个视频Anthropic 的篇官方技术说明，解释 Claude 文本水印的具体工作方式。https://x.com/trq212/status/2088721023223132213/video/1 Claude 用的是 Google DeepMind 2024 年发表在《Nature》上的 SynthID-Text 方案，往上追溯可以到 Scott Aaronson 2022 年的提案。这一脉方案的共同特征是在模型选词时，用密钥改变随机数的来源，从而在输出中留下统计痕迹。 Anthropic 举了个例子帮助理解。假设模型写到“今天天气很冷，而且……”，下一个词可能是“阴沉”，也可能是“灰蒙蒙的”，对读者来说意思差不多。正常情况下，模型用一个随机数在这些候选词里选一个。加了水印之后，选词过程还是随机的，但随机数的来源变了，变成由密钥和前面的词共同决定。文本读起来完全一样，但事后拿着密钥去核对选词序列，就能算出这段话是 Claude 写的概率。 Anthropic 在文中特别强调了一点：水印不会让模型选它本来不会选的词。模型不会因为水印而突然用一个生僻词（文中举的例子是 nubilous，一个几乎没人用的“阴天”的同义词）。水印只在模型本就犹豫的那些选择上起作用。 然后是大家最关心的：会不会降低输出质量？ Anthropic 说他们内部测试没有观察到水印对内容质量、创意水平或可读性的影响。他们援引了 Google DeepMind 的数据作为佐证：Google 在 Gemini 的实际流量中给一部分用户提供了带水印的模型，对比用户的点赞点踩反馈，两组没有统计显著差异。同时在受控实验中，人类评估者把带水印和不带水印的回答放在一起对比，也看不出区别。 打个比方：想象你在玩大富翁，本来每回合掷骰子决定走几步。现在改成查圆周率的小数位来决定，从某一位开始，依次读下去。对玩家来说，每一步还是随机的，游戏体验没有变化。但如果有人事后看走步的完整序列，再对照圆周率，就能判断这盘游戏用的是圆周率而不是骰子。 关于代码，Anthropic 的解释是：水印只在选哪个词都行的地方起作用。代码大量地方必须精确，“2+2=”后面只能跟 4，水印无从施加。所以代码的水印密度天然就比自然语言低。不过在代码注释、变量命名这些有选择余地的地方，水印仍然可以嵌入。 还有一个之前没怎么讨论的重要信息：水印不携带任何用户身份信息。不能追溯到具体的用户、组织或对话。水印只回答一个问题，“这段文字是否可能经过 Claude 处理”，仅此而已。 文章中也提到了水印的局限。短文本检测不了，信号太弱。纯事实性内容（比如“牛顿最著名的著作叫《自然哲学的数学原理》……”）水印也没什么发挥空间，因为下一个词几乎没有选择余地。你让 Claude 校对一篇文章只改语法标点，大部分词还是你的，水印可能根本不够形成可检测的信号。 轻度编辑大概率不会完全去掉水印。但如果把每个词都换一遍，水印就没了，当然到这个程度，这段文字算不算 AI 生成的本身也值得商榷了。 至于为什么全球统一加水印而不只在欧盟范围内执行，Anthropic 给出的理由是他们目前没有一个可靠的方式按地区区分是否施加水印。所以干脆全球统一上线，后续再评估是否调整。 检测端还没有完全就位。Anthropic 表示很快会推出水印检测 API，但具体时间和使用方式还在敲定中。这也呼应了 Alex Cui 之前提到的一个关键问题：检测器是公开还是内部使用，会直接影响水印的实际安全性。 顺便说一下，签署这份欧盟透明度行为准则的不止 Anthropic 一家，总共有大约 190 个签署方。水印不是 Claude 独有的事情，其他大模型厂商也会陆续跟上各自的方案。原推文媒体预览展开原推文收起原推文

@dotey

Anthropic 的篇官方技术说明，解释 Claude 文本水印的具体工作方式。https://x.com/trq212/status/2088721023223132213/video/1 Claude 用的是 Google DeepMind 2024 年发表在《Nature》上的 SynthID-Text 方案，往上追溯可以到 Scott Aaronson 2022 年的提案。这一脉方案的共同特征是在模型选词时，用密钥改变随机数的来源，从而在输出中留下统计痕迹。 Anthropic 举了个例子帮助理解。假设模型写到“今天天气很冷，而且……”，下一个词可能是“阴沉”，也可能是“灰蒙蒙的”，对读者来说意思差不多。正常情况下，模型用一个随机数在这些候选词里选一个。加了水印之后，选词过程还是随机的，但随机数的来源变了，变成由密钥和前面的词共同决定。文本读起来完全一样，但事后拿着密钥去核对选词序列，就能算出这段话是 Claude 写的概率。 Anthropic 在文中特别强调了一点：水印不会让模型选它本来不会选的词。模型不会因为水印而突然用一个生僻词（文中举的例子是 nubilous，一个几乎没人用的“阴天”的同义词）。水印只在模型本就犹豫的那些选择上起作用。 然后是大家最关心的：会不会降低输出质量？ Anthropic 说他们内部测试没有观察到水印对内容质量、创意水平或可读性的影响。他们援引了 Google DeepMind 的数据作为佐证：Google 在 Gemini 的实际流量中给一部分用户提供了带水印的模型，对比用户的点赞点踩反馈，两组没有统计显著差异。同时在受控实验中，人类评估者把带水印和不带水印的回答放在一起对比，也看不出区别。 打个比方：想象你在玩大富翁，本来每回合掷骰子决定走几步。现在改成查圆周率的小数位来决定，从某一位开始，依次读下去。对玩家来说，每一步还是随机的，游戏体验没有变化。但如果有人事后看走步的完整序列，再对照圆周率，就能判断这盘游戏用的是圆周率而不是骰子。 关于代码，Anthropic 的解释是：水印只在选哪个词都行的地方起作用。代码大量地方必须精确，“2+2=”后面只能跟 4，水印无从施加。所以代码的水印密度天然就比自然语言低。不过在代码注释、变量命名这些有选择余地的地方，水印仍然可以嵌入。 还有一个之前没怎么讨论的重要信息：水印不携带任何用户身份信息。不能追溯到具体的用户、组织或对话。水印只回答一个问题，“这段文字是否可能经过 Claude 处理”，仅此而已。 文章中也提到了水印的局限。短文本检测不了，信号太弱。纯事实性内容（比如“牛顿最著名的著作叫《自然哲学的数学原理》……”）水印也没什么发挥空间，因为下一个词几乎没有选择余地。你让 Claude 校对一篇文章只改语法标点，大部分词还是你的，水印可能根本不够形成可检测的信号。 轻度编辑大概率不会完全去掉水印。但如果把每个词都换一遍，水印就没了，当然到这个程度，这段文字算不算 AI 生成的本身也值得商榷了。 至于为什么全球统一加水印而不只在欧盟范围内执行，Anthropic 给出的理由是他们目前没有一个可靠的方式按地区区分是否施加水印。所以干脆全球统一上线，后续再评估是否调整。 检测端还没有完全就位。Anthropic 表示很快会推出水印检测 API，但具体时间和使用方式还在敲定中。这也呼应了 Alex Cui 之前提到的一个关键问题：检测器是公开还是内部使用，会直接影响水印的实际安全性。 顺便说一下，签署这份欧盟透明度行为准则的不止 Anthropic 一家，总共有大约 190 个签署方。水印不是 Claude 独有的事情，其他大模型厂商也会陆续跟上各自的方案。

@AnthropicAI

We’ve written an FAQ to answer some of the questions we've received about watermarking. In summary: • We’re implementing watermarking to comply with the EU AI Act. Other major model developers have signed the same Code of Practice and will also be implementing watermarking; • Our watermarking method doesn’t have any practical impact on the quality or content of Claude’s outputs; • The difference between watermarked and un-watermarked text will not be distinguishable to readers; • Nothing is added to the text and there are no hidden characters; • Watermarking doesn’t require extra tokens, and will not be more expensive; • Watermarks can’t be traced to a specific person, organization, or chat. Read more: https://www.anthropic.com/news/claude-text-watermark

背景
文本水印通过改变选词过程在生成文本中嵌入统计信号，从而在不改变可见输出的情况下实现事后检测。SynthID-Text 由 Google DeepMind 于 2024 年发表在《自然》杂志上，采用带密钥的锦标赛采样方法。Scott Aaronson 于 2022 年在 OpenAI 提出了类似想法。欧盟《人工智能法案》要求提供商标记 AI 生成内容，许多公司已签署行为准则以遵守规定。

8月16日 01:40在 X 打开#AI #watermarking #Claude #Anthropic #LLM

038.0

Qwen3.8-27B 通过 Atomic Chat 的 GGUF 量化在笔记本上本地运行

Atomic Chat 为 Qwen3.8-27B 发布了动态 GGUF 量化版本，从 8-bit（28.9 GB）到 1-bit（8.5 GB）不等。其中 AD-IQ3_S 版本可在 16GB 内存的 MacBook Air 上运行，并与原始 BF16 模型达到 92.4% 的 token 一致率。 这使得 270 亿参数的模型能够在消费级笔记本上实用运行，大幅降低了高质量本地 AI 的硬件门槛。它支持隐私保护、离线 AI 应用，并减少对云 API 的依赖，符合端侧 AI 的发展趋势。 AD-IQ3_S 量化版本专门针对 16GB 内存的 MacBook Air 进行了优化，在体积和性能之间取得了平衡。92.4% 的 token 一致率表明与全精度模型相比质量损失极小。量化级别从 8-bit 到 1-bit 不等，为不同硬件限制提供了灵活性。

@Alibaba_Qwen引用推文1 张图片🚀Qwen3.8-27B flies on a laptop, becoming part of our work and daily lives. Thanks for the shoutout! @atomic_chat_hq原推文媒体预览展开原推文收起原推文

@Alibaba_Qwen

🚀Qwen3.8-27B flies on a laptop, becoming part of our work and daily lives. Thanks for the shoutout! @atomic_chat_hq

@atomic_chat_hq

Run Qwen3.8 27B locally via Atomic Chat💥 We released Atomic Dynamic GGUF quants, from 8-bit (28.9 GB) down to 1-bit (8.5 GB), and measured all other Qwen3.8 GGUFs in the community AD-IQ3_S runs on a 16GB MacBook Air and picks the same next token as the BF16 original 92.4% of the time

背景
GGUF 是一种用于存储量化大语言模型的文件格式，能够在 CPU 和消费级硬件上高效推理。量化通过降低模型精度（例如从 16-bit 降到 3-bit）来减少内存占用并加快推理速度，但会牺牲一定的输出质量。Token 一致率衡量量化模型与原始全精度模型预测相同下一个 token 的频率，是质量保留程度的代理指标。BF16（bfloat16）是一种常用于大模型训练和推理的 16 位浮点格式，在数值范围和精度之间取得了良好平衡。

8月16日 07:32在 X 打开#Qwen #local LLM #GGUF quantization #on-device AI #open-source

048.0

阿里巴巴通义千问模型下载量突破30亿，领跑全球AI

阿里巴巴的通义千问（Qwen）开源权重模型在过去六个月内全球下载量累计超过30亿次，超越Meta和谷歌，成为全球下载量最高的AI模型。该消息由阿里巴巴通义千问官方X账号于2026年8月15日发布，并引用了彭博社的报道。这一里程碑反映了通义千问开源模型家族的快速普及。 这一里程碑标志着AI格局的转变，中国的开源权重模型家族在全球采用率上处于领先地位。它展示了阿里巴巴AI生态系统日益增强的竞争力，以及市场对可自由下载和定制的开源权重模型的偏好日益增长。对于开发者和企业而言，通义千问的流行可能会影响模型选择，并减少对西方专有模型的依赖。 30亿次下载的数据涵盖了过去六个月，包括所有通义千问开源权重模型，如Qwen 3.5旗舰版以及各种编程、视觉和音频模型。许多通义千问模型采用Apache 2.0许可证发布，其他模型则使用通义千问许可证或通义千问研究许可证。彭博社文章指出，通义千问在下载量上已超越Meta的Llama和谷歌的Gemma。然而，下载量并不一定反映实际使用情况或生产部署。

@Alibaba_Qwen引用推文3000000000 downloads! Can you count the zeros at a glance? 😎 Thank you all for the incredible love. Let's keep growing together! 🌱展开原推文收起原推文

@Alibaba_Qwen

3000000000 downloads! Can you count the zeros at a glance? 😎 Thank you all for the incredible love. Let's keep growing together! 🌱

@business

Alibaba's open-weight models have accumulated more than 3 billion global downloads in the past six months, eclipsing Meta, Alphabet and domestic peers to become the world’s No. 1 artificial-intelligence model https://www.bloomberg.com/news/articles/2026-08-15/alibaba-ai-models-hit-3-billion-downloads-passing-meta-google?taid=6a804463f20fc3000195ecef&utm_campaign=trueanthem&utm_content=business&utm_medium=social&utm_source=twitter

背景
开源权重AI模型是指训练好的参数被公开发布的模型，任何人都可以下载、检查、修改并在自己的基础设施上运行。这与GPT-4等闭源模型形成对比，后者仅提供API访问。通义千问是阿里巴巴云开发的大型语言和多模态模型系列，其中许多模型以Apache 2.0等宽松许可证发布。下载量指标常被用作流行度的代理指标，但它并不能反映实际使用情况或商业影响。

8月16日 06:50在 X 打开#Alibaba #Qwen #AI models #open-source #industry milestone

058.0

GPT-5.6 Sol 在 Codex 中为 ChatGPT 账户开放 100 万 Token 上下文

OpenAI 的 GPT-5.6 Sol 模型现在在 Codex 中为 ChatGPT 账户支持 100 万 token 的上下文窗口，而不再仅限于 API 密钥。用户可以在 ~/.codex/config.toml 中添加 model_context_window = 1000000 和 model_auto_compact_token_limit = 900000 来启用该功能。这一变化由 OpenAI 员工 Tibo Sottiaux 在推特上宣布。 更大的上下文窗口使 Codex 能够在总结旧内容之前保留更多代码、工具输出和对话历史，这可以提升在大型代码库或长任务上的表现。这一扩展使该功能面向更广泛的 ChatGPT 用户开放，而不仅仅是 API 客户。不过，OpenAI 警告称默认上下文限制经过调优，在性能和成本上达到最佳平衡，因此用户需要权衡利弊。 该配置要求在 ~/.codex/config.toml 的顶层设置 model = "gpt-5.6-sol"、model_context_window = 1000000 和 model_auto_compact_token_limit = 900000。该模型文档中标注的最大上下文窗口为 1,050,000 token，因此 100 万留有缓冲。自动压缩从 900,000 token 开始，以避免溢出。用户还可以使用 codex -m gpt-5.6-sol -c model_context_window=1000000 -c model_auto_compact_token_limit=900000 命令在单个 CLI 会话中测试这些设置。然而，最近的 GitHub 问题表明上下文窗口设置可能并不总是被遵守，且有报告称尽管宣传为 1.05M，Codex 中的有效上下文被削减至 258K token。

@thsottiaux引用推文GPT-5.6 Sol 1M in Codex. This used to only work for API keys, but we just flipped the switch and works for usage through ChatGPT accounts now too. The same warning applies, there is a reason the current context length is the default, we have tuned it to ~perfection. But you do you!展开原推文收起原推文

@thsottiaux

GPT-5.6 Sol 1M in Codex. This used to only work for API keys, but we just flipped the switch and works for usage through ChatGPT accounts now too. The same warning applies, there is a reason the current context length is the default, we have tuned it to ~perfection. But you do you!

@thsottiaux

Here is how to enable a 1M-token context window in Codex for GPT-5.6 Sol. Even though we have tuned the context limit in Codex to be set optimally when it comes to performance and cost, this is a common ask, so here it is documented. A larger context window lets Codex retain more code, tool output, and conversation history before summarizing older material. You need a model that supports it. And GPT-5.6 Sol, for example, has a documented 1,050,000-token window. Open ~/.codex/config.toml and add or update these settings at the top level, before any [section] headers: ``` model = "gpt-5.6-sol" model_context_window = 1000000 model_auto_compact_token_limit = 900000 ``` The first setting selects the model. The second tells Codex to use a one-million-token context budget. The third starts automatic history compaction around 900,000 tokens, leaving some headroom. Restart Codex client and start a new session after saving. To try the configuration for a single CLI session without changing your defaults: ``` codex -m gpt-5.6-sol \ -c model_context_window=1000000 \ -c model_auto_compact_token_limit=900000 ``` Have fun, but also know that we tuned the default carefully!

背景
Codex 是 OpenAI 的 AI 编码代理，在终端或 IDE 中运行，使用 config.toml 文件进行设置。上下文窗口是模型一次能够考虑的最大文本量（以 token 衡量），包括提示、文件、对话历史和响应。自动压缩是一项功能，当上下文接近限制时，它会总结较早的对话内容以避免溢出。GPT-5.6 Sol 是 GPT-5.6 系列中的一个模型，文档标注的上下文窗口为 1,050,000 token。此前，100 万上下文仅可通过 API 密钥使用，但现在 ChatGPT 账户用户也可以在 Codex 中使用。
社区讨论
社区反应不一。一些用户对更大的上下文感到兴奋，而另一些用户（如提供内容中的评论者）则不愿更改设置，因为他们认为默认设置已经调优得很好，较短的上下文可能性能更好且成本更低。GitHub 上也有关于上下文窗口设置未被遵守以及有效上下文被削减的报告，这增加了人们的怀疑。

8月17日 00:13在 X 打开#GPT-5.6 #Codex #context window #AI coding #OpenAI

068.0

AI 模型的 token 价格因分词方式不同而不可直接比较

@thsottiaux 的一条推文解释了不同 AI 模型的 token 价格不能直接比较，因为不同的分词器对相同文本会产生不同数量的 token。推文用披萨切片的比喻和一个具体例子说明：在相同文本上，GPT-5.6 Sol 使用了 766 个 token，而 Claude Opus 5 估计使用了 1,170 个，相差约 34.5%。 这一见解对于任何比较 AI 模型成本的人都至关重要，因为较低的每 token 价格并不一定意味着总账单更低。它强调真正的衡量标准应该是每次成功结果的价格，而不是每 token 的价格，这会显著影响 AI 应用的预算和模型选择。 推文提供了一个具体比较：对于涵盖英语、技术、多语言和数字内容的文本，GPT-5.6 Sol 的分词器使用了 766 个 token，而 Claude Opus 5 估计使用了 1,170 个。这 34.5% 的差异意味着即使 Claude Opus 5 的每 token 价格更低，总成本仍可能更高。作者还指出，即使修正了分词器的差异，也忽略了更重要的一点：真正重要的是每次成功结果的价格，这需要在自己的用例上进行基准测试。

@thsottiaux原推文1 张图片On tokens and prices per token. I said I’d write more about this, so here goes: an OpenAI token != another model’s token. We compare AI prices in dollars per million tokens as if a token were a standardized unit, like a gram or a kilowatt-hour. It isn’t. Different models use and produce the exact same text using different numbers of tokens, which means a lower price per token does not necessarily mean a lower bill. Imagine two identical pizzas. One is cut into 8 slices at $2 each. The other is cut into 16 slices at $1.25 each. The second place advertises cheaper slices, but the whole pizza costs $20 instead of $16. Bummer ... your stomach doesn't actually care about the number of slices you just ate. I know you are hungry now, but back to tokens. In one small comparison spanning English, technical, multilingual, and numerical text, the tokenizer we use for GPT-5.6 Sol used 766 tokens versus an estimated 1,170 for Claude Opus 5. That's a very significant difference of about 34.5% fewer tokens. You can get the same exact text, but pay for all those extra tokens. The price per token doesn't really tell this story. Even correcting for tokenizer differences misses the bigger point. What actually matters is price per successful outcome, and for that you can use benchmarks as a starting point, but really you have to try it and measure on your own use cases. That's all. May the tokens flow.原推文媒体预览展开原推文收起原推文

@thsottiaux

On tokens and prices per token. I said I’d write more about this, so here goes: an OpenAI token != another model’s token. We compare AI prices in dollars per million tokens as if a token were a standardized unit, like a gram or a kilowatt-hour. It isn’t. Different models use and produce the exact same text using different numbers of tokens, which means a lower price per token does not necessarily mean a lower bill. Imagine two identical pizzas. One is cut into 8 slices at $2 each. The other is cut into 16 slices at $1.25 each. The second place advertises cheaper slices, but the whole pizza costs $20 instead of $16. Bummer ... your stomach doesn't actually care about the number of slices you just ate. I know you are hungry now, but back to tokens. In one small comparison spanning English, technical, multilingual, and numerical text, the tokenizer we use for GPT-5.6 Sol used 766 tokens versus an estimated 1,170 for Claude Opus 5. That's a very significant difference of about 34.5% fewer tokens. You can get the same exact text, but pay for all those extra tokens. The price per token doesn't really tell this story. Even correcting for tokenizer differences misses the bigger point. What actually matters is price per successful outcome, and for that you can use benchmarks as a starting point, but really you have to try it and measure on your own use cases. That's all. May the tokens flow.

背景
分词是将文本分解为 AI 模型可以处理的更小单元（token）的过程。不同的模型使用不同的分词器，这可能会将相同的文本拆分为不同数量的 token。AI API 的定价通常按每百万 token 报价，但由于 token 数量不同，直接比较价格可能会产生误导。推文使用披萨比喻：两个相同的披萨切成不同数量的片，每片价格更便宜并不意味着整个披萨更便宜。

8月16日 05:52在 X 打开#AI pricing #tokenization #LLM economics #model comparison

078.0

10个用于保护AI代理技能的开源项目

Bilgin Ibryam（@bibryam）整理了一份包含10个开源项目的清单，用于在扫描、沙箱和治理方面保护AI代理技能。该清单包括来自NVIDIA、Cisco、Microsoft和Kubernetes SIGs的工具，如SkillSpector、Cisco AI Defense Skill Scanner和Microsoft Agent Governance Toolkit。它涵盖了从安装前扫描和供应链控制到运行时沙箱和策略执行的完整生命周期。 AI代理技能是一个快速出现的攻击面，恶意或存在漏洞的技能可能导致提示注入、数据外泄和供应链攻击。这份精选清单为从业者提供了一个实用的起点来保护代理生态系统，并得到了主要行业参与者的支持。它填补了传统代码审查或应用安全工具尚未覆盖的代理安全治理关键空白。 该清单包括用于安装前扫描的NVIDIA SkillSpector、用于多层威胁检测的Cisco AI Defense Skill Scanner，以及声称覆盖OWASP Agentic Top 10全部10项的Microsoft Agent Governance Toolkit。Kubernetes Agent Sandbox提供运行时隔离，而NVIDIA Verified Agent Skills提供能力治理。完整文章可在generativeprogrammer.com上获取，并对每个项目进行了更深入的分析。

@bibryam原推文1 张图片10 open-source projects for securing AI agent skills From pre-install scanning and supply-chain controls to sandboxing and runtime governance. 1. NVIDIA SkillSpector → https://github.com/NVIDIA/SkillSpector 2. Cisco AI Defense Skill Scanner → https://github.com/cisco-ai-defense/skill-scanner 3. SkillWard → https://github.com/Fangcun-AI/SkillWard 4. Agent Audit → https://github.com/HeadyZhang/agent-audit 5. AgentShield → https://github.com/affaan-m/agentshield 6. Microsoft Agent Package Manager → https://github.com/microsoft/apm 7. NVIDIA Verified Agent Skills → https://github.com/NVIDIA/skills 8. NVIDIA OpenShell → https://github.com/NVIDIA/OpenShell 9. Kubernetes Agent Sandbox → https://github.com/kubernetes-sigs/agent-sandbox 10. Microsoft Agent Governance Toolkit → https://github.com/microsoft/agent-governance-toolkit → Full article https://generativeprogrammer.com/p/10-open-source-projects-for-securing原推文媒体预览展开原推文收起原推文

@bibryam

10 open-source projects for securing AI agent skills From pre-install scanning and supply-chain controls to sandboxing and runtime governance. 1. NVIDIA SkillSpector → https://github.com/NVIDIA/SkillSpector 2. Cisco AI Defense Skill Scanner → https://github.com/cisco-ai-defense/skill-scanner 3. SkillWard → https://github.com/Fangcun-AI/SkillWard 4. Agent Audit → https://github.com/HeadyZhang/agent-audit 5. AgentShield → https://github.com/affaan-m/agentshield 6. Microsoft Agent Package Manager → https://github.com/microsoft/apm 7. NVIDIA Verified Agent Skills → https://github.com/NVIDIA/skills 8. NVIDIA OpenShell → https://github.com/NVIDIA/OpenShell 9. Kubernetes Agent Sandbox → https://github.com/kubernetes-sigs/agent-sandbox 10. Microsoft Agent Governance Toolkit → https://github.com/microsoft/agent-governance-toolkit → Full article https://generativeprogrammer.com/p/10-open-source-projects-for-securing

背景
AI代理技能是可复用的能力或指令，用于扩展代理的功能，通常以包或插件的形式分发。由于技能可能包含可执行代码、提示词和元数据，它们引入了类似于软件依赖的供应链风险。针对技能的开源安全工具旨在在安装前和执行过程中对这些组件进行扫描、沙箱和治理。随着代理采用的增长，NVIDIA、Microsoft和Cisco等主要科技公司正在积极开发此类工具。

8月16日 20:24在 X 打开#AI security #open-source #AI agents #supply chain #governance

087.0

Pi 作者：代码即真相，Bash 优先于 MCP

Pi 编码代理工具包的作者分享了两条关键见解：代码本身就是真相来源，因此不需要记忆系统或 RAG；Bash 工具对大多数代理任务已经足够，MCP 在很大程度上没有必要。这些观点由 @dotey 发布在 X 上，引用了 Pi 开发者的周日沉思。 这些观点挑战了当前 AI 工程的趋势，即广泛采用 RAG 和 MCP 来实现代理记忆和工具集成。如果代码确实是真相，开发者可以大幅简化代理架构，降低复杂性和潜在故障点。对 Bash 而非 MCP 的认可表明，工具链可能转向更轻量、可组合的方向。 这些见解来自 Pi 的作者，包括 @badlogicgames 和 @mitsuhiko，他们以开发 Zig 和 Flask 等工具而闻名。他们认为模型已经擅长理解代码结构，因此不需要外部记忆。Bash 被描述为一种可以任意组合的编程语言，大多数情况下 skill + 脚本就足够了。帖子中没有提供基准测试或定量证据。

@dotey引用推文2 个视频Pi 两位作者的见解： 1. 代码即真相，代码不需要记忆系统，不需要 RAG，模型很擅长理解代码结构 2. Bash 工具足够用，Bash 类似于编程语言，可以任意组合；大部分时候没必要 MCP，skill + 脚本足够。原推文媒体预览+1展开原推文收起原推文

@dotey

Pi 两位作者的见解： 1. 代码即真相，代码不需要记忆系统，不需要 RAG，模型很擅长理解代码结构 2. Bash 工具足够用，Bash 类似于编程语言，可以任意组合；大部分时候没必要 MCP，skill + 脚本足够。

@pidotdev

Good morning from Vienna People of Pi 🌞 Sunday meditations from @badlogicgames and @mitsuhiko - On memory: code is the truth - Bash is all you need - Build context efficient tools

背景
Pi 是一个 AI 代理工具包，提供统一的 LLM API、代理循环、TUI 和编码代理 CLI。RAG（检索增强生成）是一种检索外部信息以增强模型响应的技术，常用于记忆。MCP（模型上下文协议）是一个开放标准，用于将 AI 应用连接到外部工具和数据源。Bash 是一种 Unix shell 和命令语言，可用于组合各种命令行工具。

8月16日 23:09在 X 打开#AI agents #coding #RAG #Bash #MCP

097.0

ChatGPT 现可通过 GitHub 集成直接修改代码并提交 PR

一位用户发现，ChatGPT 在连接 GitHub 后，可以克隆仓库、分析代码库、生成详细的实现方案，然后直接实现更改并提交拉取请求（PR）。该用户使用的是 ChatGPT Pro，过程中只需确认一次 GitHub 操作权限。这一工作流仅需向 ChatGPT 发送 GitHub 仓库地址即可触发。 这一集成通过让 AI 在一个连续流程中完成代码分析、规划、实现和 PR 提交，简化了开发工作流。它减少了手动上传代码或在工具之间切换的摩擦，使 AI 辅助开发在日常任务中更加实用。这可能会加速依赖 GitHub 进行版本控制的开发者对 AI 编码助手的采用。 用户必须先在 ChatGPT 的设置 → 应用（或插件）中连接 GitHub，并授权 ChatGPT 应用访问特定仓库。该集成遵循 GitHub 权限，意味着 ChatGPT 只能访问用户已授权的仓库。用户提到 ChatGPT 在执行 GitHub 操作前会请求一次确认。根据搜索结果，代码更改和 PR 审查由 Codex 处理，Codex 现已集成到 ChatGPT 桌面应用中。

@dotey原推文2 张图片可能是太久没用 ChatGPT 了，才发现从 ChatGPT 就能直接让它修改代码提交 PR。（我是用的 ChatGPT Pro） 起因是我在做一个 Deep Research 调研，完了后就想让它基于我的代码库做一个方案，但是整个代码库都打包上传太麻烦了，我就把 GitHub 地址发给它了，没想到它自己就 clone 到本地开始分析代码了，最后给了一份很详细的结合当前代码库现状的方案。 一看方案写挺好，想着干脆帮我实现吧，让它自己去提交个 PR，结果它真的就基于方案帮我实现并提交 PR 了，中间确认了一次 GitHub 操作权限。 需要先在 ChatGPT 的设置的 Plugins 里面连上 GitHub 才能访问你的 GitHub Repo，以及以你的名义提交 PR。原推文媒体预览+1展开原推文收起原推文

@dotey

可能是太久没用 ChatGPT 了，才发现从 ChatGPT 就能直接让它修改代码提交 PR。（我是用的 ChatGPT Pro） 起因是我在做一个 Deep Research 调研，完了后就想让它基于我的代码库做一个方案，但是整个代码库都打包上传太麻烦了，我就把 GitHub 地址发给它了，没想到它自己就 clone 到本地开始分析代码了，最后给了一份很详细的结合当前代码库现状的方案。 一看方案写挺好，想着干脆帮我实现吧，让它自己去提交个 PR，结果它真的就基于方案帮我实现并提交 PR 了，中间确认了一次 GitHub 操作权限。 需要先在 ChatGPT 的设置的 Plugins 里面连上 GitHub 才能访问你的 GitHub Repo，以及以你的名义提交 PR。

背景
ChatGPT 是 OpenAI 开发的 AI 助手，可以执行包括代码生成和分析在内的各种任务。GitHub 是一个版本控制和协作平台，开发者将代码存储在仓库中，并通过拉取请求（PR）管理更改。拉取请求是将代码更改从一个分支合并到另一个分支的提案，通常在合并前由其他开发者审查。ChatGPT 与 GitHub 的集成允许 AI 访问仓库内容，并在权限范围内代表用户执行操作。

8月16日 19:32在 X 打开#ChatGPT #GitHub #AI-assisted development #workflow #PR

107.0

Claude Code 桌面版新增用量限制自动继续复选框

Claude Code 桌面版现在包含一个自动继续复选框，可以在达到用量限制后自动恢复工作。该功能不仅适用于主 Agent，也适用于子 Agent，使它们无需手动干预即可继续。用户不再需要输入“return”或重新启动子 Agent；可以重用现有的子 Agent。 该功能解决了依赖 Claude Code 进行长时间任务的开发者的常见痛点，减少了停机时间和手动干预。通过自动化恢复过程，它提高了工作流效率，使开发者能够专注于更高层次的任务。这也表明 Anthropic 致力于提升 AI 编码工具中的开发者体验。 自动继续复选框在 Claude Code 桌面应用程序中可用。启用后，它会在用量限制重置后自动继续会话，保留主 Agent 和任何子 Agent 的上下文。该功能对于超过 5 小时用量窗口的任务特别有用。除了切换复选框外，无需额外配置。

@dotey引用推文1 张图片 · 1 个视频Claude Code （Claude Desktop）这个功能很好用，就是你5小时限制到了，可以自动继续，不只是主 Agent 到时间继续，子 Agent 到时间也会继续。不需要手工输入 return，也不需要重新开 subagent，可以重用之前的 subagent原推文媒体预览+1展开原推文收起原推文

@dotey

Claude Code （Claude Desktop）这个功能很好用，就是你5小时限制到了，可以自动继续，不只是主 Agent 到时间继续，子 Agent 到时间也会继续。不需要手工输入 return，也不需要重新开 subagent，可以重用之前的 subagent

@ClaudeDevs

Hit your usage limit in Claude Code desktop? There's now an auto-continue checkbox. Turn it on, and it'll automatically continue where you left off once your limit resets.

背景
Claude Code 是 Anthropic 推出的一款 AI 驱动的编码助手，可在终端或桌面环境中运行。它使用用量限制系统来管理 API 消耗，通常在一段时间（例如 5 小时）后重置。子 Agent 是 Claude Code 可以生成的专用 AI 助手，用于处理具有自己上下文窗口的特定任务。自动继续功能建立在现有机制之上，以自动恢复会话。

8月16日 06:36在 X 打开#Claude Code #AI tools #developer experience #feature update

117.0

AI 智能体在既定框架内优化却难寻新路：视频转录优化案例

一位开发者报告称，像 Fable 5 和 Codex 这样的 AI 智能体在给定优化视频转录的目标时，倾向于在现有方法上打磨，而不是发现根本不同的解决方案。开发者通过手动分析数据包发现，冗长的 JSON 输出格式是瓶颈，改用纯文本或简单 HTML 后降低了 token 消耗和解析复杂度。这一改动将 API 调用次数从 33 次降至 12 次，处理时间从 31 分钟降至 18 分钟。 这凸显了目标驱动型 AI 智能体的一个关键局限：它们擅长局部优化，但难以跳出初始框架的约束。对实践者而言，这强调了需要人类监督来发现智能体可能忽略的范式转变。具体的性能提升——时间和调用次数几乎减半——表明在 LLM 流水线中，输出格式的选择会对成本和延迟产生巨大影响。 优化涉及将 JSON 输出替换为纯文本或简单 HTML，这减少了 token 生成和校验时间，但使程序解析更复杂（例如字幕润色需要 diff 比较）。改进后的流水线处理近 7 小时的访谈，完整润色仅需 42 分钟。使用云模型（DeepSeek v4 Flash）而非智能体，一小时的视频完整翻译校对成双语字幕成本约 ¥0.4。BaoCut 提供 Mac 应用，Windows 通过 CLI 或 skill 支持。

@dotey引用推文7 张图片我最近就发现，即使聪明如 Fable 5，如果你只是给它一个目标让它优化，它可能也就是在既定的框架下想办法帮你优化到极致，但是它很难跳出既定框架，发现一条完全不同的路线。 比如说最近有用户反映使用 BaoCut 转录速度慢，我就反复的用 Codex 去转录视频，然后让 Codex 或者 Fable 去分析瓶颈在哪里，该怎么优化，然后每次它们都能给我一堆理由和看起来靠谱的优化方案。 比如它会建议多开启 workers（subagent），对 workers 预热之类。让它按照方案优化后，似乎有效果但是又不明显。 最后还是自己去分析数据包，发现耗时长还是输出的 JSON 格式太长了，导致生成、校验时间较长。 如果不用 JSON 格式，比如纯文本，或者简单的 html 格式，会更节约 token，只不过这样程序解析会很复杂，比如对字幕润色分段，输出是纯文本的话，就要做 diff 比较润色后更改的内容，还要把变更后的部分，重新对应到原始字幕的单词上。 简单来说，就是以前为了让程序简单就让模型输出复杂更费 token；如果要节约 token，就可以让模型的输出简单，但是程序解析会很复杂。 按照这个思路改进后，效果很明显（对比图2图3），调用次数从 33 次降低到 12 次；时间从 31 分钟降低到 18 分钟。测试张小珺那期将近 7 小时的访谈，完整润色也只需要 42 分钟。 如果不走 Agent 走 Cloud 模型的话，一个小时的视频，完整的翻译校对成双语字幕，用 DeepSeek v4 Flash，成本大于是 ¥0.4元。 有兴趣可以试试看效果，Mac 有专门的 App，Windows 支持 cli 或者 skill。 BaoCut ：https://baocut.app/原推文媒体预览+6展开原推文收起原推文

@dotey

我最近就发现，即使聪明如 Fable 5，如果你只是给它一个目标让它优化，它可能也就是在既定的框架下想办法帮你优化到极致，但是它很难跳出既定框架，发现一条完全不同的路线。 比如说最近有用户反映使用 BaoCut 转录速度慢，我就反复的用 Codex 去转录视频，然后让 Codex 或者 Fable 去分析瓶颈在哪里，该怎么优化，然后每次它们都能给我一堆理由和看起来靠谱的优化方案。 比如它会建议多开启 workers（subagent），对 workers 预热之类。让它按照方案优化后，似乎有效果但是又不明显。 最后还是自己去分析数据包，发现耗时长还是输出的 JSON 格式太长了，导致生成、校验时间较长。 如果不用 JSON 格式，比如纯文本，或者简单的 html 格式，会更节约 token，只不过这样程序解析会很复杂，比如对字幕润色分段，输出是纯文本的话，就要做 diff 比较润色后更改的内容，还要把变更后的部分，重新对应到原始字幕的单词上。 简单来说，就是以前为了让程序简单就让模型输出复杂更费 token；如果要节约 token，就可以让模型的输出简单，但是程序解析会很复杂。 按照这个思路改进后，效果很明显（对比图2图3），调用次数从 33 次降低到 12 次；时间从 31 分钟降低到 18 分钟。测试张小珺那期将近 7 小时的访谈，完整润色也只需要 42 分钟。 如果不走 Agent 走 Cloud 模型的话，一个小时的视频，完整的翻译校对成双语字幕，用 DeepSeek v4 Flash，成本大于是 ¥0.4元。 有兴趣可以试试看效果，Mac 有专门的 App，Windows 支持 cli 或者 skill。 BaoCut ：https://baocut.app/

@dotey

很多人不知道该怎么用好 Agent 的 /goal 功能，也就是说给 Agent 一个目标，让它长时间运行，直到目标完成为止。 其实没你想的那么复杂，注意几个点： 1. 你的目标是什么 2. 如何验证结果 3. 停止条件 比如说我这两天做的一个性能优化的任务，Fable 5 帮我把视频转录性能优化了2倍多（图2），提示词很简单（图1）： > /goal 帮我优化当前 cli 的转录大视频的性能，在遇到像这样大体积的视频时，需要优化转录性能，请以 Moss 模型测试这个视频（英文为主，多语言）转录，建立基准，然后分析性能瓶颈，尝试优化，直到你觉得已经没有优化空间了。注意你的主要任务是分析、编排和验证，具体任务尽可能交给 subagent（Opus5）去执行 首先用 /goal 表示这是一个需要长时间执行的任务，需要反复执行，不能运行一会就结束了。 然后给它一个视频让它先自己跑一遍转录，记录一下关键数据，建立基准。 基于转录时收集的数据，Agent 自己可以去分析原因，去自己优化，优化完成后再去跑一遍，记录数据，对照前面的基准看是更好了还是更坏了。 结束条件是它自己觉得已经没有优化空间了就结束。之所以我没给它一个具体指标，是因为我也不知道能优化多少，如果指标太容易达到，它一轮可能就结束了；如果指标太难超出物理极限也没意义，反而可能会出现为了优化去做一些极端的事情。 最后一句让它开subagent执行子任务是因为 Fable 5 太贵，全程 Fable 5 用不了多久就要额度不够了，加了这句就耐用多了，而且质量也挺好。 --- 还有些时候，想到一个新的技术方案，但并不知道这方案是不是有效，那也可以让它开个worktree，去验证一下是不是靠谱，看数据是更好还是更坏，如果没提升就没必要做了。（参考图3）

背景
BaoCut 是一款 AI 驱动的视频转录和字幕工具，可在 Mac 上本地运行，并提供开源的 Agent Skill 用于 CLI。Fable 5 是 Anthropic 用于长时间自主编码任务的最强模型，Codex 是 OpenAI 的编码智能体。智能体中的 /goal 功能允许设定一个长期目标，并带有验证和停止条件。JSON 是 LLM 常用的结构化输出格式，但与纯文本相比，它可能消耗更多 token，且生成和校验速度较慢。

8月16日 04:01在 X 打开#AI agents #performance optimization #LLM #video transcription #practical tips

127.0

Qwen3.8-27B 登顶 Hugging Face 热门模型榜

阿里巴巴通义千问宣布 Qwen3.8-27B 已成为 Hugging Face 上排名第一的热门模型，并向社区表示感谢。该模型大约在四天前发布，迅速获得了大量关注，相关公告帖子的点赞数已接近一万。 这一里程碑反映了社区对开源 AI 模型的强烈采用和兴趣，尤其是具备多模态和智能体能力的模型。这表明 Qwen3.8-27B 正在引起开发者和研究人员的共鸣，可能影响 AI 生态系统中未来的模型开发和部署选择。 Qwen3.8-27B 是一个原生视觉语言模型，具有灵活的思考控制能力，专为复杂的多步骤任务而设计。它拥有 256K 上下文窗口，可在 17GB 内存/显存的配置上本地运行。该模型提供 FP8 和其他量化格式，并支持智能体编码、视觉和聊天任务。

@Alibaba_Qwen引用推文2 张图片Huge thanks to the whole community! Qwen3.8-27B is now the #1 trending model on Hugging Face! 🏆 Try it out and let us know what you think. 🤗原推文媒体预览+1展开原推文收起原推文

@Alibaba_Qwen

Huge thanks to the whole community! Qwen3.8-27B is now the #1 trending model on Hugging Face! 🏆 Try it out and let us know what you think. 🤗

@julien_c

soon 10k

背景
Hugging Face 是一个流行的机器学习模型托管和分享平台，其热门榜单反映了当前社区的兴趣。Qwen 是阿里云开发的一系列大语言模型，以其开源发布和在各种基准测试中的强劲表现而闻名。模型名称中的“3.8”表示 Qwen3 系列中的特定版本，“27B”指的是参数数量（270 亿）。
社区讨论
社区反响非常积极，许多用户表达了兴奋之情并祝贺 Qwen 团队。一些评论强调了该模型令人印象深刻的能力和本地部署的便利性，而另一些评论则指出 Qwen 发布速度之快。

8月16日 06:34在 X 打开#AI #Open Source #Model Release #Hugging Face #Qwen