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

8月30日2026 · 星期日

从 23 条抓取中筛选 12 条 · twitter × 4 账号 · 02:30 UTC 生成

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

  1. OpenAI 在 SpaceX 收购后切断 Cursor 模型访问9.0
  2. OpenAI 重置 Codex 额度并修复多项浪费 Token 的缺陷8.0
  3. Warp 通过人类反馈构建自我改进智能体的方法8.0
  4. Claude Code 周限额自 9 月 14 日起永久增加 25%7.0
  5. 定义AI原生公司：以AI代理而非人为核心的工作流程7.0
  6. 开源网页应用 anatomy 提供 9 个人体器官的交互式 3D 模型7.0
  7. Semantica：面向 AI Agent 的开源知识图谱基础设施7.0
  8. Drawio-skill 从文本或代码生成可编辑的 draw.io 图表7.0
  9. WolfCut：免费开源的剪映替代品，支持本地自动字幕7.0
  10. Anthropic 与 Cursor 重申合作，增加 Claude 模型算力支持7.0
  11. 发布19个适用于AI与非AI应用的延迟优化模式7.0
  12. 谷歌白皮书描绘AI智能体从开发到生产的全生命周期7.0
019.0

OpenAI 在 SpaceX 收购后切断 Cursor 模型访问

OpenAI 宣布终止与 Cursor 的合作，从 2026 年 11 月 12 日起停止提供 GPT 系列模型。这一决定是在 SpaceX 两周前以 600 亿美元收购 Cursor 之后做出的。OpenAI 以信任问题为由，指出马斯克旗下公司过去的合同违规行为以及 xAI 承认蒸馏 OpenAI 模型。 此举直接影响在 Cursor 中使用 GPT 模型的开发者，迫使他们更换模型或自带 API 密钥。这也标志着 AI 编程工具生态中竞争和信任的碎片化加剧，模型提供商越来越愿意切断竞争对手的访问。这一决定可能加速向 Anthropic 的 Claude 集中，后者已经在 Cursor 使用中占据主导地位。 断供日期为 2026 年 11 月 12 日，这是合同控制权变更条款允许的最晚日期。OpenAI 将立即停止向 Cursor 添加新模型，并特别提到其即将推出的 Astra 模型，该模型无法排除“关键”网络能力，需要更严格的控制。Cursor 用户可以通过自带 OpenAI API 密钥或安装 Codex 插件继续使用 GPT 模型，但费用从 Cursor 订阅转为直接支付给 OpenAI。据 Cursor CEO 称，OpenAI 模型目前约占 Cursor 用户流量的 5%。

@dotey引用推文OpenAI 断供 Cursor，11 月 12 日起停止提供模型 OpenAI 今天宣布终止和 Cursor 的合作，停止向 Cursor 提供 GPT 系列模型，日期定在 11 月 12 日。触发点是两周前 SpaceX 以 600 亿美元完成对 Cursor 的收购。OpenAI 给的理由是，它无法相信马斯克旗下的公司会按服务条款使用它的技术。 OpenAI 在博客里点了两桩旧账。一桩是马斯克收购 Twitter 之后，Twitter 违反了和 OpenAI 签的合同。Twitter 后来并入 xAI，xAI 今年 2 月又并入 SpaceX，所以现在都算 SpaceX 的事。另一桩更近：今年 4 月 30 日，马斯克起诉 OpenAI 的案子开庭，他在证人席上承认 xAI 曾蒸馏 OpenAI 的模型，也就是拿 OpenAI 模型的输出当训练数据来训练 Grok，OpenAI 的服务条款明文禁止这么干。那场官司马斯克在 5 月输了，正在上诉。 OpenAI 和 Cursor 的合同里有一条控制权变更条款，Cursor 易主后 OpenAI 有一个时间窗口可以解约。OpenAI 选了合同允许的最晚日期，给开发者留两个半月缓冲，但从现在起不再给 Cursor 接入新模型。它特别提到了 Astra，这是 OpenAI 本月刚披露的下一代模型，内部评估无法排除它的网络攻击能力达到"关键"级别。OpenAI 说，这样的模型交到谁手里、怎么用，它需要比以前更严格的把关。 负责 OpenAI 全部核心产品的 Tibo 在 X 上说，这件事说到底是信任问题。他也给了替代方案：Cursor 用户可以继续绑定自己的 OpenAI API key 调用 GPT 模型，OpenAI 的 Codex 插件也会继续支持在 Cursor 里运行。区别是钱从 Cursor 订阅里出，变成直接付给 OpenAI。 对 Cursor 用户的直接影响：11 月 12 日之后，订阅里的 GPT 模型选项会消失。想继续用 GPT，自带 key 或者装 Codex 插件；不想折腾的，换成 Claude、Gemini、Grok，或者 Cursor 自家的 Composer。 OpenAI 也不是局外人。它 2024 年和 2025 年两次接触过 Cursor 想收购，被拒后转向 Windsurf，那笔交易最后也黄了。它现在的 Codex 和 Cursor 是直接竞品，信任之外，少给对手的产品供货本身就是生意。 接下来最大的变数是 Anthropic。Claude 一直是 Cursor 里用得最多的模型，Anthropic 到现在没有表态。它有跟进的先例：去年 6 月 OpenAI 传出要收购 Windsurf，Anthropic 几天内就切断了 Windsurf 的 Claude 接入，联合创始人 Jared Kaplan 的原话是“把 Claude 卖给 OpenAI 太奇怪了”。 今年 1 月，xAI 工程师通过 Cursor 调用 Claude 做竞品研究被发现，Anthropic 封了 xAI 的访问。但它也有不跟进的理由：今年 5 月 Anthropic 租下 SpaceX 的 Colossus 1 整个集群，22 万张 GPU，Claude Code 限额翻倍就靠这批算力。展开原推文收起原推文

@dotey

OpenAI 断供 Cursor，11 月 12 日起停止提供模型 OpenAI 今天宣布终止和 Cursor 的合作，停止向 Cursor 提供 GPT 系列模型，日期定在 11 月 12 日。触发点是两周前 SpaceX 以 600 亿美元完成对 Cursor 的收购。OpenAI 给的理由是，它无法相信马斯克旗下的公司会按服务条款使用它的技术。 OpenAI 在博客里点了两桩旧账。一桩是马斯克收购 Twitter 之后，Twitter 违反了和 OpenAI 签的合同。Twitter 后来并入 xAI，xAI 今年 2 月又并入 SpaceX，所以现在都算 SpaceX 的事。另一桩更近：今年 4 月 30 日，马斯克起诉 OpenAI 的案子开庭，他在证人席上承认 xAI 曾蒸馏 OpenAI 的模型，也就是拿 OpenAI 模型的输出当训练数据来训练 Grok，OpenAI 的服务条款明文禁止这么干。那场官司马斯克在 5 月输了，正在上诉。 OpenAI 和 Cursor 的合同里有一条控制权变更条款，Cursor 易主后 OpenAI 有一个时间窗口可以解约。OpenAI 选了合同允许的最晚日期，给开发者留两个半月缓冲，但从现在起不再给 Cursor 接入新模型。它特别提到了 Astra，这是 OpenAI 本月刚披露的下一代模型，内部评估无法排除它的网络攻击能力达到"关键"级别。OpenAI 说，这样的模型交到谁手里、怎么用，它需要比以前更严格的把关。 负责 OpenAI 全部核心产品的 Tibo 在 X 上说，这件事说到底是信任问题。他也给了替代方案：Cursor 用户可以继续绑定自己的 OpenAI API key 调用 GPT 模型，OpenAI 的 Codex 插件也会继续支持在 Cursor 里运行。区别是钱从 Cursor 订阅里出，变成直接付给 OpenAI。 对 Cursor 用户的直接影响：11 月 12 日之后，订阅里的 GPT 模型选项会消失。想继续用 GPT，自带 key 或者装 Codex 插件；不想折腾的，换成 Claude、Gemini、Grok，或者 Cursor 自家的 Composer。 OpenAI 也不是局外人。它 2024 年和 2025 年两次接触过 Cursor 想收购，被拒后转向 Windsurf，那笔交易最后也黄了。它现在的 Codex 和 Cursor 是直接竞品，信任之外，少给对手的产品供货本身就是生意。 接下来最大的变数是 Anthropic。Claude 一直是 Cursor 里用得最多的模型，Anthropic 到现在没有表态。它有跟进的先例：去年 6 月 OpenAI 传出要收购 Windsurf，Anthropic 几天内就切断了 Windsurf 的 Claude 接入，联合创始人 Jared Kaplan 的原话是“把 Claude 卖给 OpenAI 太奇怪了”。 今年 1 月，xAI 工程师通过 Cursor 调用 Claude 做竞品研究被发现，Anthropic 封了 xAI 的访问。但它也有不跟进的理由：今年 5 月 Anthropic 租下 SpaceX 的 Colossus 1 整个集群，22 万张 GPU，Claude Code 限额翻倍就靠这批算力。

@OpenAI

We’re ending our partnership with Cursor following its acquisition by SpaceX. Under our proposal, Cursor’s direct access to our models would end on November 12. We know that the people most affected by this decision are the developers who rely on OpenAI models in Cursor. We care about their experience in this transition and we’re ready to go above and beyond to support them. https://openai.com/index/our-decision-on-cursor-following-its-acquisition-by-spacex/

背景
Cursor 是一款基于 VS Code 的 AI 代码编辑器，以深度集成大语言模型辅助开发者而闻名。由埃隆·马斯克领导的 SpaceX 以 600 亿美元收购了 Cursor，使其与开发 Grok 模型的 xAI 处于同一企业集团之下。模型蒸馏是一种利用更大、能力更强的模型的输出来训练较小模型的技术；OpenAI 的服务条款禁止使用其模型输出来训练竞争模型。OpenAI 的 Astra 是一个未发布的下一代模型，表现出强大的性能，包括解决开放数学问题，但也引发了对其潜在“关键”网络能力的担忧。
社区讨论
社区反应不一。一些人指出讽刺之处：Anthropic 此前曾切断 Windsurf 的访问，现在却承诺继续支持 Cursor；另一些人则认为 Anthropic 的决定可能出于其对 SpaceX 算力资源的需求。Cursor 的 CEO 表示失望，并质疑 OpenAI 的说法，认为 token 份额不能代表价值，且 OpenAI 模型在 token 效率上更高。

8月29日 03:28在 X 打开#OpenAI #Cursor #AI industry #SpaceX #model access

028.0

OpenAI 重置 Codex 额度并修复多项浪费 Token 的缺陷

OpenAI 已为所有 Codex 和 ChatGPT Work 的付费用户重置使用额度。团队修复了多个浪费 Token 的缺陷，涉及上下文压缩、记忆机制、目标指令、自动化任务、子智能体、计算机历史记录、滚动任务总结以及 MCP 工具编码等问题。这些修复预计可根据使用习惯将可用时长提升 10% 至 50%。 此次更新直接回应了用户普遍反映的 Codex 额度消耗过快问题。通过修复浪费 Token 的缺陷，OpenAI 提升了付费订阅的实际价值，并减轻了依赖 Codex 进行编码任务的开发者的挫败感。架构层面的调整和计划中的用量透明化功能，也表明其对长期可靠性的重视。 具体修复包括：压缩时不再保留旧图片，重度图片用户用量下降约 10%；记忆后台程序不再继承停止挂钩，修复了极端情况下检查 15,000 次的罕见严重循环；目标指令现在能正确停止，解决了消耗每周额度 15% 至 70% 的问题；子智能体不再无故调用更强模型或以 /fast 模式运行；计算机历史记录不再重复总结重叠活动，此前该问题每周最多可消耗五分之一的额度；滚动任务总结已被禁用，节省约 1% 的 Token；MCP 工具结果不再被双重编码或截断。OpenAI 还进行了架构调整以防止问题复发，并正在开发应用内用量明细功能。

@dotey串推 2 条2 段Codex 正在重置额度，并且已经做了 Token 消耗的优化，理论上来说现在 Codex 的额度会更耐用了。 --- 以下来自 Tibo 推文 --- Tibo：我们正在为所有 Codex 和 ChatGPT Work 的付费用户重置使用额度。 如果你想了解 Codex 额度消耗问题的最新进展，请接着往下看。最近，我们的团队一直在日夜奋战，翻阅了成千上万份用户报告，并马不停蹄地发布了一系列修复补丁。 接下来，根据你使用 Codex 的习惯不同，你会发现自己的额度比以前变得更“耐用”了——使用时长大约能增加 10% 到 50%。 这次我们真的是拿着“显微镜”进行了地毯式排查，揪出了许多潜伏已久的小毛病。以下是我们发现并修复的核心问题： - Compaction（上下文压缩）。 在进行压缩时，我们之前错误地保留了旧图片，有时这会让上下文体积依然很大，从而再次触发压缩操作。修复后，对于重度使用图片的用户来说，额度消耗下降了约 10%。已修复。 - Memory（记忆机制）。 后台负责处理记忆的程序有时会继承“停止挂钩”（Stop hooks），导致在挂钩阻止它们结束时，这些程序依然在无意义地空转。这虽然只影响了不到 1% 的用户，但在极端情况下表现得非常糟糕——我们甚至观察到一个线程循环检查了 15,000 次自己“是否可以停止”。已修复。 - Goals（目标指令）。 在某些情况下，设定好的 `/goal` 指令在完成后，并没有乖乖停下，而是越过了预定的停止条件继续运行；或者，模型会死磕那些已经失效的工具，无限重试而不停止。我们看到的一些极端案例中，这竟然白白消耗了用户每周 15% 到 70% 的额度！已修复。 - Automations（自动化任务）。 部分自定义的定时任务，其运行频率超出了用户的实际设定。已修复。 - Subagents（子智能体）。 执行复杂任务时，主模型有时会调用其他专门的模型来协助）较小的模型（例如 Luna）有时会在没有被明确指令要求的情况下，擅自“请外援”调用能力更强（也更耗费额度）的助手模型。同样，如果负责调度的模型本身没有开启 `/fast`（快速）模式，它却会错误地要求子智能体以 `/fast` 模式运行。已修复。 - Computer History（计算机历史记录）。 旧版的代码实现会导致系统反复对重叠的活动记录进行总结。在部分案例中，单是这个小失误，每周就能吃掉用户高达五分之一的额度。已修复。 - Rolling task summaries（滚动任务总结）。 在普通的对话轮次中，系统会触发额外的后台请求。这不知不觉中增加了大约 1% 的 token（词元）消耗。虽然每次只扣一点点，但积少成多也是一笔不小的开销。我们现在已经禁用了这个功能。 - MCP。 部分工具返回的结果被系统重复编码了两次。我们还发现，一些工具的指令会被意外截断，导致系统不得不重新获取。已修复。 为了彻底斩草除根，我们对系统架构进行了底层调整，以防止这些问题卷土重来。退一万步说，即便问题真的复发，我们的团队也会第一时间收到警报。此外，我们正在开发一项新功能，未来你将可以直接在应用内清楚地看到额度究竟花在了哪里，再也不用瞎猜了。 毫无疑问，我们现在正在为大家重置所有的使用额度。祝大家度过一个愉快的周六！ > 引用 @thsottiaux: We are reseting usage for all paid users of Codex and ChatGPT Work. > > Please continue reading for an update on Codex usage limits. The team has been working around the clock, going through thousands of reports and shipping fixes. > > Depending on how you use Codex, you should see your usage go between 10% and 50% further than before. > > We really went with a fine comb, with many uncovered small things being longstanding and here is what we found and fixed: > - Compaction. We were keeping old images during compaction, sometimes making the context large enough to trigger compaction again. After the fix, usage dropped around 10% for users making heavy use of images. Fixed. > - Memory. Background memory workers could inherit Stop hooks and keep running when the hook wouldn’t let them finish. This affected fewer than 1% of users, with the long tail being pretty bad and we saw one example thread check whether it could stop 15,000 times. Fixed. > - Goals. In some cases, a set /goal could finish and then keep going past the intended stop condition, or the model would keep retrying broken tools without stopping. We saw examples consume anywhere from 15% to 70% of a weekly allowance. Fixed. > - Automations. Some custom schedules could run more frequently than configured. Fixed. > - Subagents. Smaller models (e.g. Luna) sometimes picked more capable helpers without being explicitly asked. The same was true where the orchestrating model not running in /fast mode could request sub-agents to run /fast. Fixed. > - Computer History. The older implementation could lead to repeatedly summarizing overlapping activity. For some cases we saw it consume up to one fifth of the weekly usage per week. Fixed. > - Rolling task summaries. Ordinary turns were triggering extra background requests. These added about 1% to token usage. Small each time, but it adds up. We have disabled this. > - MCP. Some tool results could be encoded twice. We also found tool instructions getting cut off and fetched again. Fixed. > > We’ve also made architectural changes to prevent these from regressing and our teams will get paged if it happens regardless. We are also working on showing you directly in the app where your usage goes so you don’t have to guess. > > Goes without saying that we’re resetting usage limits and I hope you enjoy a very nice Saturday!展开原推文收起原推文

@dotey串推 2 条

Codex 正在重置额度，并且已经做了 Token 消耗的优化，理论上来说现在 Codex 的额度会更耐用了。 --- 以下来自 Tibo 推文 --- Tibo：我们正在为所有 Codex 和 ChatGPT Work 的付费用户重置使用额度。 如果你想了解 Codex 额度消耗问题的最新进展，请接着往下看。最近，我们的团队一直在日夜奋战，翻阅了成千上万份用户报告，并马不停蹄地发布了一系列修复补丁。 接下来，根据你使用 Codex 的习惯不同，你会发现自己的额度比以前变得更“耐用”了——使用时长大约能增加 10% 到 50%。 这次我们真的是拿着“显微镜”进行了地毯式排查，揪出了许多潜伏已久的小毛病。以下是我们发现并修复的核心问题： - Compaction（上下文压缩）。 在进行压缩时，我们之前错误地保留了旧图片，有时这会让上下文体积依然很大，从而再次触发压缩操作。修复后，对于重度使用图片的用户来说，额度消耗下降了约 10%。已修复。 - Memory（记忆机制）。 后台负责处理记忆的程序有时会继承“停止挂钩”（Stop hooks），导致在挂钩阻止它们结束时，这些程序依然在无意义地空转。这虽然只影响了不到 1% 的用户，但在极端情况下表现得非常糟糕——我们甚至观察到一个线程循环检查了 15,000 次自己“是否可以停止”。已修复。 - Goals（目标指令）。 在某些情况下，设定好的 `/goal` 指令在完成后，并没有乖乖停下，而是越过了预定的停止条件继续运行；或者，模型会死磕那些已经失效的工具，无限重试而不停止。我们看到的一些极端案例中，这竟然白白消耗了用户每周 15% 到 70% 的额度！已修复。 - Automations（自动化任务）。 部分自定义的定时任务，其运行频率超出了用户的实际设定。已修复。 - Subagents（子智能体）。 执行复杂任务时，主模型有时会调用其他专门的模型来协助）较小的模型（例如 Luna）有时会在没有被明确指令要求的情况下，擅自“请外援”调用能力更强（也更耗费额度）的助手模型。同样，如果负责调度的模型本身没有开启 `/fast`（快速）模式，它却会错误地要求子智能体以 `/fast` 模式运行。已修复。 - Computer History（计算机历史记录）。 旧版的代码实现会导致系统反复对重叠的活动记录进行总结。在部分案例中，单是这个小失误，每周就能吃掉用户高达五分之一的额度。已修复。 - Rolling task summaries（滚动任务总结）。 在普通的对话轮次中，系统会触发额外的后台请求。这不知不觉中增加了大约 1% 的 token（词元）消耗。虽然每次只扣一点点，但积少成多也是一笔不小的开销。我们现在已经禁用了这个功能。 - MCP。 部分工具返回的结果被系统重复编码了两次。我们还发现，一些工具的指令会被意外截断，导致系统不得不重新获取。已修复。 为了彻底斩草除根，我们对系统架构进行了底层调整，以防止这些问题卷土重来。退一万步说，即便问题真的复发，我们的团队也会第一时间收到警报。此外，我们正在开发一项新功能，未来你将可以直接在应用内清楚地看到额度究竟花在了哪里，再也不用瞎猜了。 毫无疑问，我们现在正在为大家重置所有的使用额度。祝大家度过一个愉快的周六！ > 引用 @thsottiaux: We are reseting usage for all paid users of Codex and ChatGPT Work. > > Please continue reading for an update on Codex usage limits. The team has been working around the clock, going through thousands of reports and shipping fixes. > > Depending on how you use Codex, you should see your usage go between 10% and 50% further than before. > > We really went with a fine comb, with many uncovered small things being longstanding and here is what we found and fixed: > - Compaction. We were keeping old images during compaction, sometimes making the context large enough to trigger compaction again. After the fix, usage dropped around 10% for users making heavy use of images. Fixed. > - Memory. Background memory workers could inherit Stop hooks and keep running when the hook wouldn’t let them finish. This affected fewer than 1% of users, with the long tail being pretty bad and we saw one example thread check whether it could stop 15,000 times. Fixed. > - Goals. In some cases, a set /goal could finish and then keep going past the intended stop condition, or the model would keep retrying broken tools without stopping. We saw examples consume anywhere from 15% to 70% of a weekly allowance. Fixed. > - Automations. Some custom schedules could run more frequently than configured. Fixed. > - Subagents. Smaller models (e.g. Luna) sometimes picked more capable helpers without being explicitly asked. The same was true where the orchestrating model not running in /fast mode could request sub-agents to run /fast. Fixed. > - Computer History. The older implementation could lead to repeatedly summarizing overlapping activity. For some cases we saw it consume up to one fifth of the weekly usage per week. Fixed. > - Rolling task summaries. Ordinary turns were triggering extra background requests. These added about 1% to token usage. Small each time, but it adds up. We have disabled this. > - MCP. Some tool results could be encoded twice. We also found tool instructions getting cut off and fetched again. Fixed. > > We’ve also made architectural changes to prevent these from regressing and our teams will get paged if it happens regardless. We are also working on showing you directly in the app where your usage goes so you don’t have to guess. > > Goes without saying that we’re resetting usage limits and I hope you enjoy a very nice Saturday!

@thsottiaux

We are reseting usage for all paid users of Codex and ChatGPT Work. Please continue reading for an update on Codex usage limits. The team has been working around the clock, going through thousands of reports and shipping fixes. Depending on how you use Codex, you should see your usage go between 10% and 50% further than before. We really went with a fine comb, with many uncovered small things being longstanding and here is what we found and fixed: - Compaction. We were keeping old images during compaction, sometimes making the context large enough to trigger compaction again. After the fix, usage dropped around 10% for users making heavy use of images. Fixed. - Memory. Background memory workers could inherit Stop hooks and keep running when the hook wouldn’t let them finish. This affected fewer than 1% of users, with the long tail being pretty bad and we saw one example thread check whether it could stop 15,000 times. Fixed. - Goals. In some cases, a set /goal could finish and then keep going past the intended stop condition, or the model would keep retrying broken tools without stopping. We saw examples consume anywhere from 15% to 70% of a weekly allowance. Fixed. - Automations. Some custom schedules could run more frequently than configured. Fixed. - Subagents. Smaller models (e.g. Luna) sometimes picked more capable helpers without being explicitly asked. The same was true where the orchestrating model not running in /fast mode could request sub-agents to run /fast. Fixed. - Computer History. The older implementation could lead to repeatedly summarizing overlapping activity. For some cases we saw it consume up to one fifth of the weekly usage per week. Fixed. - Rolling task summaries. Ordinary turns were triggering extra background requests. These added about 1% to token usage. Small each time, but it adds up. We have disabled this. - MCP. Some tool results could be encoded twice. We also found tool instructions getting cut off and fetched again. Fixed. We’ve also made architectural changes to prevent these from regressing and our teams will get paged if it happens regardless. We are also working on showing you directly in the app where your usage goes so you don’t have to guess. Goes without saying that we’re resetting usage limits and I hope you enjoy a very nice Saturday!

This celebration is moved to tomorrow as the button was already pressed today.

背景
Codex 是 OpenAI 的 AI 编码智能体，采用基于 Token 的计费模式，用户需为输入、缓存输入和输出 Token 付费。上下文压缩是一种在对话历史过长时减小其体积的技术，但该过程中的缺陷可能导致重复压缩并浪费 Token。子智能体是 Codex 可以委派任务的较小专用模型，它们会消耗额外的 Token。MCP（模型上下文协议）是一种将 AI 模型连接到外部工具和数据源的标准。

8月29日 21:21在 X 打开#OpenAI #Codex #Token optimization #Bug fixes #AI tools

038.0

Warp 通过人类反馈构建自我改进智能体的方法

Warp 发布了一篇博文，详细介绍了他们如何在 Claude 上构建用于代码审查的自我改进智能体。他们采用双技能系统：一个技能执行代码审查，另一个改进技能定期收集人类工程师的审查评论（尤其是对智能体审查结果的评论），用于更新代码审查技能。这种方法利用人类标注作为反馈，以极低的摩擦成本进化智能体的技能。 该方法解决了 AI 智能体的一个核心挑战：缺乏持久记忆和对团队特定规范的适应能力。通过自动将人类反馈纳入技能更新，它使智能体能够持续改进，而无需手动调整提示词。这代表了一种最佳实践：人类提供高层反馈，智能体负责执行和自我改进，可能适用于许多领域。 Warp 最初尝试手动修改提示词和 AGENTS.md 文件，但效果不佳。他们的解决方案使用一个基础技能进行代码审查，以及一个改进技能从 PR 和 issue 中收集人类评论，然后更新基础技能。他们强调编写原则而非死板规则、解释规则背后的原因、让反馈无摩擦、保持技能精简并采用渐进式披露、重视反馈质量而非数量。他们还指出改进技能本身可复用于改进其他技能。为处理可能错误的反馈，他们从不盲目接受反馈；提供上下文进行合理性检查，限制谁的反馈可以影响更新，并始终保留人工审核环节。

@dotey原推文1 个视频Claude 新的一篇博文《How Warp builds self-improving agents on Claude》 https://claude.com/blog/how-warp-builds-self-improving-agents-on-claude ，看了后还是挺有收获，它解决的是 Skill 的进化问题。 这个问题我以前也研究过，我写了一个反编译 JS 代码的 Skill（http://github.com/JimLiu/decode-codex/blob/main/.agents/skills/deobfuscate-javascript/SKILL.md#maintaining-this-skill-self-improvement-protocol），每次 Agent 反编译的时候遇到新的场景解决了就自己更新自己的 Skill，效果还不错，能一直优化，就是 Skill 文件越来越大。 我还研究过写作的自我进化 Skill，那个就一言难尽，因为它其实没有自己统一的标准，经常负优化，越写越糟糕。 说回来 Warp 这个，Warp 是一个挺有名的终端工具，内部尝试借助 AI 做 Code Review。一开始让 Agent review 代码，效果并不理想，主要问题体现在 Agent 不了解你的项目，不知道你的团队规范，不知道历史经验教训，就算你指出来问题它下次还记不住。简单来说就是没有记忆。 初期他们采取了很多补救措施： - 手动根据失败案例改系统提示词 - 完善项目的 AGENTS.md 文件（有意思的是这篇文章是 Claude 发的，但是用的是 AGENTS.md 而不是 CLAUDE.md，我记得 Claude 默认不支持 AGENTS.md 的😅） 但效果并不理想，一方面它依赖于人主动去做，成本较高；另一方面团队成员在 Code Review 时人工在 PR 写的高质量评论完全没用上。 所以他们搞了个解决方案，一个基础 Skill 负责做代码审查，一个改进 Skill 负责定期收集人类工程师在代码审查时的评论，尤其是对 Agent 审查结果的评论，根据人类工程师的评论去更新代码审查的 Skill。 换句话说，它不是依赖于模型自己去改进自己，而是 Agent 根据人类对模型结果的标注（人类对代码审查的评论），去改进技能。 只不过它把这个事做的摩擦力极低，不需要人手工去收集整理评论，不需要填写调查问卷，人只要自然的去代码下写评论，后面的事情都是 Agent 自动完成。 这可能正是 Agent 的最佳实践方案之一：人负责高纬度的标注、评论、反馈这些事情，Agent 去做执行的工作，Agent 根据人类的反馈去改进 Skill。 除此之外，他们还总结了一些最佳实践： 1. 写原则，不要写死规则。 编写 skill 时，要像在指导一个聪明人，而不是在给计算机编程。在 Skill 中写“寻找重复代码”，比列出详尽的变量命名规则更有效。 2. 解释为什么。 说明规则背后的理由，能让智能体针对问题进行推理，而不是机械执行僵化指令，也因此更容易举一反三。 3. 让反馈没有摩擦毫不费力。 在人们原本工作的地方收集反馈，例如直接评论 PR 或 issue。同时让收集过程自动发生，不要增加额外的提交步骤。低摩擦才能让信号持续流动。如果反馈太麻烦，你就收不到反馈，也就无法改进 Skill。 4. 保持 Skill 精简，并使用渐进式披露。 优秀的 skill 文件不会很庞大；它会引用资源文件和脚本，而不是一次性把所有内容都塞进上下文。 5. 反馈质量大于数量，但数量也有帮助。 一位资深工程师给出的少量、详细且与领域相关的反馈，可能比大量草率反馈更有价值，因为简单的赞成／反对并不能说明“为什么”。 即使样本量相对较小，只要反馈来自掌握领域知识的人，而且足够详细，你也能得到非常好的信号——这些知识是智能体通过其他方式根本无法获得的。话虽如此，优质信号的语料越多，效果越好。 6. 做好改进 Skill 的 Skill，可以用来改进其他 Skill。 把改进 Skill（也就是前面提到的一个代码审查 Skill 一个改进 Skill）做好，收益不只限于眼前这套 Agent 循环，因为改进 Skill 在不同用例之间具有很高的复用性。除了领域专用知识这一部分，它其实是一套相当通用、可复用的机制。代码审查 Agent 的改进 skill，也可以应用到其他 Skill 的改进上。 可能有人会担心：如果反馈本身是错的呢？ Warp 的做法是永远不让 Agent 盲目接受反馈。给它足够的上下文来做基本的合理性检查，限制谁的反馈有权影响技能更新（不是所有人的意见都同等重要），最后始终保留人在循环中审核改动。 对于那些有明确标准答案的领域，比如代码是否通过了测试、部署是否成功，可以先建一个验证基准，让 Agent 自己对着基准跑。没有标准答案的领域，比如代码风格、文档质量，就靠领域专家的判断，不要开放给所有人随意反馈。原推文媒体预览展开原推文收起原推文

@dotey

Claude 新的一篇博文《How Warp builds self-improving agents on Claude》 https://claude.com/blog/how-warp-builds-self-improving-agents-on-claude ，看了后还是挺有收获，它解决的是 Skill 的进化问题。 这个问题我以前也研究过，我写了一个反编译 JS 代码的 Skill（http://github.com/JimLiu/decode-codex/blob/main/.agents/skills/deobfuscate-javascript/SKILL.md#maintaining-this-skill-self-improvement-protocol），每次 Agent 反编译的时候遇到新的场景解决了就自己更新自己的 Skill，效果还不错，能一直优化，就是 Skill 文件越来越大。 我还研究过写作的自我进化 Skill，那个就一言难尽，因为它其实没有自己统一的标准，经常负优化，越写越糟糕。 说回来 Warp 这个，Warp 是一个挺有名的终端工具，内部尝试借助 AI 做 Code Review。一开始让 Agent review 代码，效果并不理想，主要问题体现在 Agent 不了解你的项目，不知道你的团队规范，不知道历史经验教训，就算你指出来问题它下次还记不住。简单来说就是没有记忆。 初期他们采取了很多补救措施： - 手动根据失败案例改系统提示词 - 完善项目的 AGENTS.md 文件（有意思的是这篇文章是 Claude 发的，但是用的是 AGENTS.md 而不是 CLAUDE.md，我记得 Claude 默认不支持 AGENTS.md 的😅） 但效果并不理想，一方面它依赖于人主动去做，成本较高；另一方面团队成员在 Code Review 时人工在 PR 写的高质量评论完全没用上。 所以他们搞了个解决方案，一个基础 Skill 负责做代码审查，一个改进 Skill 负责定期收集人类工程师在代码审查时的评论，尤其是对 Agent 审查结果的评论，根据人类工程师的评论去更新代码审查的 Skill。 换句话说，它不是依赖于模型自己去改进自己，而是 Agent 根据人类对模型结果的标注（人类对代码审查的评论），去改进技能。 只不过它把这个事做的摩擦力极低，不需要人手工去收集整理评论，不需要填写调查问卷，人只要自然的去代码下写评论，后面的事情都是 Agent 自动完成。 这可能正是 Agent 的最佳实践方案之一：人负责高纬度的标注、评论、反馈这些事情，Agent 去做执行的工作，Agent 根据人类的反馈去改进 Skill。 除此之外，他们还总结了一些最佳实践： 1. 写原则，不要写死规则。 编写 skill 时，要像在指导一个聪明人，而不是在给计算机编程。在 Skill 中写“寻找重复代码”，比列出详尽的变量命名规则更有效。 2. 解释为什么。 说明规则背后的理由，能让智能体针对问题进行推理，而不是机械执行僵化指令，也因此更容易举一反三。 3. 让反馈没有摩擦毫不费力。 在人们原本工作的地方收集反馈，例如直接评论 PR 或 issue。同时让收集过程自动发生，不要增加额外的提交步骤。低摩擦才能让信号持续流动。如果反馈太麻烦，你就收不到反馈，也就无法改进 Skill。 4. 保持 Skill 精简，并使用渐进式披露。 优秀的 skill 文件不会很庞大；它会引用资源文件和脚本，而不是一次性把所有内容都塞进上下文。 5. 反馈质量大于数量，但数量也有帮助。 一位资深工程师给出的少量、详细且与领域相关的反馈，可能比大量草率反馈更有价值，因为简单的赞成／反对并不能说明“为什么”。 即使样本量相对较小，只要反馈来自掌握领域知识的人，而且足够详细，你也能得到非常好的信号——这些知识是智能体通过其他方式根本无法获得的。话虽如此，优质信号的语料越多，效果越好。 6. 做好改进 Skill 的 Skill，可以用来改进其他 Skill。 把改进 Skill（也就是前面提到的一个代码审查 Skill 一个改进 Skill）做好，收益不只限于眼前这套 Agent 循环，因为改进 Skill 在不同用例之间具有很高的复用性。除了领域专用知识这一部分，它其实是一套相当通用、可复用的机制。代码审查 Agent 的改进 skill，也可以应用到其他 Skill 的改进上。 可能有人会担心：如果反馈本身是错的呢？ Warp 的做法是永远不让 Agent 盲目接受反馈。给它足够的上下文来做基本的合理性检查，限制谁的反馈有权影响技能更新（不是所有人的意见都同等重要），最后始终保留人在循环中审核改动。 对于那些有明确标准答案的领域，比如代码是否通过了测试、部署是否成功，可以先建一个验证基准，让 Agent 自己对着基准跑。没有标准答案的领域，比如代码风格、文档质量，就靠领域专家的判断，不要开放给所有人随意反馈。

背景
Warp 是一款流行的 AI 原生终端工具，一直在将 AI 集成到代码审查中。在 AI 智能体的语境下，“技能”指指导智能体行为的可复用指令或能力。Claude 是 Anthropic 的 AI 模型，AGENTS.md 是为智能体提供项目上下文的文件格式，而 CLAUDE.md 是 Claude 专用的。自我改进智能体的挑战在于它们往往缺乏对过去错误和团队特定规范的记忆，导致重复犯错。Warp 的方法利用人类反馈作为训练信号来更新智能体的技能，类似于人类从代码审查评论中学习。

8月29日 03:22在 X 打开#AI agents #self-improving #Claude #code review #skill evolution

047.0

Claude Code 周限额自 9 月 14 日起永久增加 25%

Anthropic 宣布，自 9 月 14 日起，Claude Code 的标准周限额将针对 Pro、Max、Team 和按席位计费的 Enterprise 计划永久提高 25%。在此之前，临时 50% 的提升仍然有效。这意味着用户将从临时的 50% 提升降至永久的 25% 提升，与当前临时水平相比，可用周用量实际减少约 17%。 这一政策调整直接影响 Claude Code 用户的开发体验，因为相比临时促销期间，他们习惯的每周用量有所减少。这一变化可能表明 Anthropic 对其竞争地位充满信心，或需要重新分配计算资源，并可能影响重度依赖 Claude Code 的用户的满意度和生产力。 根据 Help Net Security 的报道，临时 50% 的提升原定更早结束，但已多次延期，最近一次延期至 2026 年 7 月 19 日。新的永久 25% 提升适用于 Pro、Max、Team 和按席位计费的 Enterprise 计划，但不适用于 API 按量付费。这些计划的用户在 Claude Code、Claude.ai 聊天和 Cowork 之间共享限额，高峰时段（工作日太平洋时间上午 5 点至 11 点）的限流可能进一步降低实际可用额度。

@dotey串推 2 条2 段 · 1 张图片之前 Claude Code 周额度临时加 50% 一再延迟之后，最终结果是 9/14 之前，还是加 50%，之后变成了加 25%，但是是永久的。 好吧，直观感受就是 -25%，现在 Fable 5 本来就不够用，还降 25%，更加不经用了 > 引用 @ClaudeDevs: Starting September 14, we're permanently raising standard weekly limits in Claude Code by 25% for Pro, Max, Team, and seat-based Enterprise plans. Until then, the current 50% increase will be in place.原推文媒体预览展开原推文收起原推文

@dotey串推 2 条

之前 Claude Code 周额度临时加 50% 一再延迟之后，最终结果是 9/14 之前，还是加 50%，之后变成了加 25%，但是是永久的。 好吧，直观感受就是 -25%，现在 Fable 5 本来就不够用，还降 25%，更加不经用了 > 引用 @ClaudeDevs: Starting September 14, we're permanently raising standard weekly limits in Claude Code by 25% for Pro, Max, Team, and seat-based Enterprise plans. Until then, the current 50% increase will be in place.

@ClaudeDevs

Starting September 14, we're permanently raising standard weekly limits in Claude Code by 25% for Pro, Max, Team, and seat-based Enterprise plans. Until then, the current 50% increase will be in place.

社区标记简单直接：9/14 日起，Claude Code 周用量降低 17%

背景
Claude Code 是 Anthropic 推出的 AI 编程助手，可在开发者的终端或 IDE 中运行。Pro、Max、Team 和 Enterprise 等订阅计划包含一定量的每周用量（以 token 或交互次数衡量），并在 Claude Code、Claude.ai 聊天和 Cowork 之间共享。Anthropic 会定期开展临时提升限额的促销活动，当前的 50% 提升就是其中之一，并已多次延期。转为永久 25% 的提升意味着促销力度的常态化，但水平低于临时峰值。
社区讨论
社区情绪复杂，一些用户对实际减少 17% 表示不满，指出即使是临时 50% 的提升也不够用。另一些人猜测这一变化可能是因为来自 OpenAI 的竞争压力减小，或需要为新模型分配更多算力。还有用户批评 Anthropic 的沟通令人困惑，尽管承认团队本意良好。

8月29日 17:42在 X 打开#Claude Code #AI tools #pricing #developer experience

057.0

定义AI原生公司：以AI代理而非人为核心的工作流程

@dotey 的一条推文提出，当公司的工作流程围绕 AI 代理作为主要执行者来设计，由人来定义问题和验收结果，而不是仅仅在现有以人为中心的流程中添加 AI 时，这家公司才是 AI 原生的。该推文线程引用了 @yangyi 的帖子，提出了“智能数据比率”的概念——即公司数据中可被代理获取使用的比例——作为衡量 AI 原生就绪度的关键指标。另一条被引用的 @tangpanqing 的帖子则认为，这种转变只是用代理取代了人类下属，领导角色基本没有变化。 这一观点将 AI 采用的焦点从工具增强转向根本性的工作流程重新设计，这可能决定哪些公司能真正从 AI 代理中受益。“智能数据比率”指标强调了数据可访问性是代理有效性的先决条件，可能指导企业数字化转型的优先事项。这场讨论还涉及组织层面的影响，表明 AI 原生公司可能需要新的管理范式，即人类监督代理而非人员。 该推文将 AI 原生定义为以 AI 代理为执行主体，人类负责定义问题和验收。@yangyi 的“智能数据比率”指出，数据分散或纸质化的公司会限制代理的上下文和能力，因此数字化是迈向 AI 原生的第一步。@tangpanqing 反驳说，从管理人到管理代理的转变并没有从根本上改变领导工作，因为领导者仍然要定方向、找问题、看结果。该讨论是概念性的，没有提供实证基准或案例研究。

@dotey串推 2 条2 段我觉得判断一家公司是不是 AI Native，看他们做事的流程，是围绕人做事设计流程还是围绕 AI Agent 做事设计流程。 AI Native 很重要的一点就是 AI Agent 是执行主体，人负责定义问题和验收。如果只是在原来做事的方式流程里面加一点 AI，那不 AI Native。 > 引用 @yangyi: 判断一个公司是不是AI Native > 我认为有一个指标及其关键 > 就是这个公司有多少数据是可以被Agent获取使用的 > > 我称之为：智能数据比率 > > 如果一个企业里 > 各种生产数据，进销存数据，营销投放数据，销售数据，客服数据，全部散落在四处 > 甚至有的数据还是纸质化的 > 那么势必会影响Agent获得上下文 > > 如果Agent没有这些上下文 > 那么就会限制Agent的能力，就很难谈得上「使用」 > > 所以AI Native的第一步，是数字化这些数据 > 数据的数字化程度越高，就越容易AI Native > > 互联网公司，数据大部分在系统里 > 实体公司，可能还需要一些终端设备来收集现实世界数据 > > 如果你公司内的数据，Agent都可以轻松获取 > 那么你大概是步入AI Native公司的行列了展开原推文收起原推文

@dotey串推 2 条

我觉得判断一家公司是不是 AI Native，看他们做事的流程，是围绕人做事设计流程还是围绕 AI Agent 做事设计流程。 AI Native 很重要的一点就是 AI Agent 是执行主体，人负责定义问题和验收。如果只是在原来做事的方式流程里面加一点 AI，那不 AI Native。 > 引用 @yangyi: 判断一个公司是不是AI Native > 我认为有一个指标及其关键 > 就是这个公司有多少数据是可以被Agent获取使用的 > > 我称之为：智能数据比率 > > 如果一个企业里 > 各种生产数据，进销存数据，营销投放数据，销售数据，客服数据，全部散落在四处 > 甚至有的数据还是纸质化的 > 那么势必会影响Agent获得上下文 > > 如果Agent没有这些上下文 > 那么就会限制Agent的能力，就很难谈得上「使用」 > > 所以AI Native的第一步，是数字化这些数据 > 数据的数字化程度越高，就越容易AI Native > > 互联网公司，数据大部分在系统里 > 实体公司，可能还需要一些终端设备来收集现实世界数据 > > 如果你公司内的数据，Agent都可以轻松获取 > 那么你大概是步入AI Native公司的行列了

@yangyi

判断一个公司是不是AI Native 我认为有一个指标及其关键 就是这个公司有多少数据是可以被Agent获取使用的 我称之为：智能数据比率 如果一个企业里 各种生产数据，进销存数据，营销投放数据，销售数据，客服数据，全部散落在四处 甚至有的数据还是纸质化的 那么势必会影响Agent获得上下文 如果Agent没有这些上下文 那么就会限制Agent的能力，就很难谈得上「使用」 所以AI Native的第一步，是数字化这些数据 数据的数字化程度越高，就越容易AI Native 互联网公司，数据大部分在系统里 实体公司，可能还需要一些终端设备来收集现实世界数据 如果你公司内的数据，Agent都可以轻松获取 那么你大概是步入AI Native公司的行列了

以前你这样的leader很少，管的是人 现在每个人都是leader，管的是agents https://x.com/tangpanqing/status/2093734084535288174?s=20 > 引用 @tangpanqing: 我觉得妳们的这些讨论，没啥意义 > > 我之前带团队的时候，基本上都是定方向，找问题，看结果 > > 具体的事情，都是我下属去干。 > > 现在讲AI，AGENT，目前看只是把我的下属换掉了而已，我的工作并没有多少变化。😂

背景
“AI 原生”一词越来越多地用于描述从一开始就将 AI 作为核心组件设计的产品或公司，与将 AI 改造到现有流程上的“AI 优先”或“AI 增强”方法形成对比。AI 代理是能够感知、决策和行动以实现目标的自主系统，通常使用工具和外部数据。在企业环境中，工作流程设计决定了任务如何分解和分配，从以人为中心转向以代理为中心的工作流程是一项重大的组织变革。数据可访问性对 AI 代理至关重要，因为它们依赖来自各种来源的上下文来做出明智的决策。
社区讨论
社区讨论中包括 @tangpanqing 的反驳，他认为这些讨论没有意义，并指出用代理取代人类下属并不会改变领导工作。这反映了一种怀疑观点，即 AI 原生的概念可能被过度炒作，或者只是对现有管理实践的重新包装。

8月29日 14:55在 X 打开#AI-native #AI agents #enterprise AI #workflow design

067.0

开源网页应用 anatomy 提供 9 个人体器官的交互式 3D 模型

GitHub_Daily 分享了开源网页应用 anatomy，它能在浏览器中渲染 9 个人体器官的可旋转 3D 模型。该项目据称完全使用 GPT-5.6 Sol 构建，心脏、大脑、肺等器官模型上带有标注点，点击即可查看部位名称和功能，并配有器官位置图和显微镜下组织图。界面支持包括中文在内的 12 种语言，并采用国际标准解剖学术语。 该工具让解剖学教育更直观、更有吸引力，尤其适合难以理解平面图的孩子和非专业人士。作为开源且多语言的项目，它降低了全球使用和二次开发的门槛。同时，它也展示了 GPT-5.6 Sol 等先进 AI 模型在生成实用教育软件方面的应用潜力。 该应用涵盖 9 个器官，每个器官都有交互式 3D 模型、标注的解剖点、位置图和显微镜组织图。它支持 12 种语言，并使用标准解剖学术语而非随意命名。项目托管在 GitHub 上：http://github.com/thebuggeddev/anatomy。值得注意的是，它声称使用 GPT-5.6 Sol 构建，该模型于 2026 年 7 月发布，以擅长复杂编码任务而闻名。

@GitHub_Daily原推文1 张图片想跟孩子解释心脏长什么样、肾在哪个位置，翻百科全是平面图，比划半天也讲不明白。 anatomy 把 9 个人体器官做成了浏览器里能转着看的 3D 模型，打开网页就能用，项目介绍里写着整个应用是用 GPT 5.6 Sol 做出来的。 心脏、大脑、肺这些模型上都布了标注点，点一下就能看这个部位叫什么、管什么，还配了器官在身体里的位置图和显微镜下的组织图。 GitHub：http://github.com/thebuggeddev/anatomy 界面支持中文在内的 12 种语言，翻代码时留意到标注用的是国际标准解剖学术语那套体系，不是随手起的名，挺讲究。 当科普工具给孩子玩、自己涨涨知识都合适。原推文媒体预览展开原推文收起原推文

@GitHub_Daily

想跟孩子解释心脏长什么样、肾在哪个位置，翻百科全是平面图，比划半天也讲不明白。 anatomy 把 9 个人体器官做成了浏览器里能转着看的 3D 模型，打开网页就能用，项目介绍里写着整个应用是用 GPT 5.6 Sol 做出来的。 心脏、大脑、肺这些模型上都布了标注点，点一下就能看这个部位叫什么、管什么，还配了器官在身体里的位置图和显微镜下的组织图。 GitHub：http://github.com/thebuggeddev/anatomy 界面支持中文在内的 12 种语言，翻代码时留意到标注用的是国际标准解剖学术语那套体系，不是随手起的名，挺讲究。 当科普工具给孩子玩、自己涨涨知识都合适。

背景
解剖学教育传统上依赖二维图表和教科书，学习者很难在脑海中将其转化为三维结构。交互式 3D 模型允许用户从任意角度旋转和探索器官，从而提升空间理解能力。GPT-5.6 Sol 是 OpenAI 于 2026 年 7 月发布的大型语言模型，以强大的编码和智能体工作流能力著称。国际标准解剖学术语（如 Terminologia Anatomica）为全球医疗专业人员提供了一致的词汇体系。

8月29日 13:30在 X 打开#3D #education #open-source #anatomy #GPT

077.0

Semantica：面向 AI Agent 的开源知识图谱基础设施

Semantica 是一个面向 AI Agent 的开源知识图谱基础设施，在 GitHub 上已获得超过 11000 颗星。它把企业数据抽取成知识图谱，每条事实都带来源，每个决策都是可查询的对象。该项目将自己定位为 AI Agent 版的开源 Palantir，强调可问责性和可追溯性。 这很重要，因为它为 AI 系统提供了结构化、可审计的基础，尤其是在金融和医疗等受监管行业，来源和可复现性至关重要。通过将推理与大语言模型解耦并使用规则引擎，Semantica 提供了确定性的、可解释的输出，解决了基于 LLM 的 Agent 的一个关键局限。它与 LangChain 和 CrewAI 等流行框架的集成降低了采用门槛。 Semantica 使用基于规则的推理引擎，而不是依赖大语言模型，确保结果可复现，并标记相互矛盾的事实，而不是悄悄用新的覆盖旧的。它支持包括 Neo4j 在内的八种图数据库，并提供与 LangChain、CrewAI 的集成，以及一个 MCP 服务器，供 Claude 等工具连接。安装只需一条 pip 命令，并提供 CLI、REST API 和知识探索器界面。

@GitHub_Daily原推文1 张图片semantica 给 AI 系统底下垫了一层图谱基础设施，号称 Agent 版的开源 Palantir，已斩获 11000+ Star！ 它把企业数据抽成知识图谱，每条事实都带来源，每个决策都是能查的对象，为什么做、依据什么、影响了啥都能追。 GitHub：http://github.com/semantica-agi/semantica 推理走的是规则引擎不靠大模型，结果可复现，遇到互相矛盾的事实会标出来，而不是悄悄用新的盖掉旧的。 Neo4j 在内的 8 种图数据库随便换，LangChain、CrewAI 能直接接，还带 MCP 服务，Claude 这类工具也能连上用。 比较适合金融、医疗这些行业，普通项目拿它当 Agent 的长期记忆也够用，一条命令就装上。原推文媒体预览展开原推文收起原推文

@GitHub_Daily

semantica 给 AI 系统底下垫了一层图谱基础设施，号称 Agent 版的开源 Palantir，已斩获 11000+ Star！ 它把企业数据抽成知识图谱，每条事实都带来源，每个决策都是能查的对象，为什么做、依据什么、影响了啥都能追。 GitHub：http://github.com/semantica-agi/semantica 推理走的是规则引擎不靠大模型，结果可复现，遇到互相矛盾的事实会标出来，而不是悄悄用新的盖掉旧的。 Neo4j 在内的 8 种图数据库随便换，LangChain、CrewAI 能直接接，还带 MCP 服务，Claude 这类工具也能连上用。 比较适合金融、医疗这些行业，普通项目拿它当 Agent 的长期记忆也够用，一条命令就装上。

背景
知识图谱将数据表示为实体和关系，支持语义查询和推理。Palantir 是一个商业平台，以其本体驱动的数据集成和分析而闻名，常用于政府和大型企业。MCP（模型上下文协议）是一个开放标准，允许 AI 应用连接外部工具和数据源。LangChain 和 CrewAI 是用于构建大语言模型应用和编排多 Agent 系统的流行框架。

8月29日 10:00在 X 打开#knowledge-graph #AI-agents #open-source #data-infrastructure #LLM

087.0

Drawio-skill 从文本或代码生成可编辑的 draw.io 图表

一个名为 drawio-skill 的新工具可以根据自然语言描述，或直接从代码库、Terraform 配置和 Kubernetes 清单生成 draw.io 图表。它支持 11 种图表类型，包括 UML、时序图、网络拓扑、泳道图、架构图和流程图。输出结果是可编辑的 .drawio 源文件，而非静态图片，并且可以导出为 PNG、SVG 或 PDF。 文档中的架构图经常过时，因为手动在 draw.io 中重绘既繁琐又耗时。该工具实现了自动化，使图表更容易保持最新，并减少了文档维护的阻力。对于管理复杂基础设施的团队来说尤其有价值，因为它可以直接从代码和配置文件反向生成图表。 该技能包含超过 10,000 个官方图形和 321 个 AI 品牌标志（如 OpenAI 和 Claude）的库，消除了在大模型架构图中使用灰色占位框的需要。它还具有“地铁图”模式，可将流水线渲染为伦敦地铁风格的彩色线路图。根据 GitHub 仓库，该技能会规划布局、生成 .drawio XML、导出为所选格式、自检结果，并支持迭代优化。

@GitHub_Daily原推文1 张图片文档里的架构图还是半年前那张，谁都知道过时了，谁都不想开 http://draw.io 拖一下午重画。 最近发现了 drawio-skill 技能，用一句话描述就能生成 http://draw.io 图。 现成预设了 UML、时序图、网络拓扑、泳道图、架构图、流程图等11 种图型。 更省事的是反向生成，指着代码库、Terraform 配置或 Kubernetes 清单直接出架构图。 GitHub：http://github.com/Agents365-ai/drawio-skill 生成的不是死图片，是能继续在 http://draw.io 里改的源文件，也能直接导出 PNG、SVG、PDF。 内置 1 万多个官方图形的检索，连 OpenAI、Claude 这些 AI 品牌标志都补了 321 个，画大模型架构图不用再放灰方块。 最好玩的是地铁图模式，把一条流水线画成伦敦地铁那种彩色线路图，文档配图里就有一张它自己的。原推文媒体预览展开原推文收起原推文

@GitHub_Daily

文档里的架构图还是半年前那张，谁都知道过时了，谁都不想开 http://draw.io 拖一下午重画。 最近发现了 drawio-skill 技能，用一句话描述就能生成 http://draw.io 图。 现成预设了 UML、时序图、网络拓扑、泳道图、架构图、流程图等11 种图型。 更省事的是反向生成，指着代码库、Terraform 配置或 Kubernetes 清单直接出架构图。 GitHub：http://github.com/Agents365-ai/drawio-skill 生成的不是死图片，是能继续在 http://draw.io 里改的源文件，也能直接导出 PNG、SVG、PDF。 内置 1 万多个官方图形的检索，连 OpenAI、Claude 这些 AI 品牌标志都补了 321 个，画大模型架构图不用再放灰方块。 最好玩的是地铁图模式，把一条流水线画成伦敦地铁那种彩色线路图，文档配图里就有一张它自己的。

背景
draw.io（也称为 diagrams.net）是一款流行的免费开源绘图工具，它以基于 XML 的 .drawio 格式存储图表，便于日后编辑。Terraform 是一种基础设施即代码工具，通过声明式配置文件定义云资源；Kubernetes 清单则是描述集群资源（如部署和服务）的 YAML 或 JSON 文件。drawio-skill 似乎是一种“Claude 技能”——一种可由 Anthropic 的 Claude AI 助手调用来执行专门任务的模块化能力。

8月29日 07:30在 X 打开#diagramming #AI-tools #developer-tools #automation #drawio

097.0

WolfCut：免费开源的剪映替代品，支持本地自动字幕

WolfCut 是一个新开源的免费跨平台视频编辑器，定位为剪映/CapCut 的替代品。它提供多轨时间线、语音滤镜、模板复用，以及本地自动字幕转写，无需上传视频。该项目提供 Windows、macOS 和 Linux 的安装包，导出的视频没有水印。 剪映/CapCut 的许多功能现在需要付费会员，并且频繁提示升级，这让许多短视频创作者感到困扰。WolfCut 通过提供免费、开源、注重隐私的替代方案来解决这一痛点，其本地转写功能对担心数据离开设备的用户很有价值。其跨平台支持也扩大了不同操作系统创作者的使用范围。 该项目刚开源不久，目前功能集有限，但覆盖了常见的短视频剪辑需求。自动字幕通过本地转写技术生成，确保视频不会上传到外部。编辑器包含多轨时间线、语音滤镜和模板复用；导出的视频没有水印。提供 Windows、macOS 和 Linux 的安装包。

@GitHub_Daily原推文1 张图片现在的剪映不少功能都需要会员才能使用，还动不动就提示升级，剪个短视频也得掂量掂量。 WolfCut 干脆做了个免费开源的替代，开箱即用，装上就能剪，无需注册。 GitHub：http://github.com/jub0t/WolfCut 项目刚开源不久，功能目前还不是很多，但剪短视频常用几个功能都有。 包括多轨时间线、语音滤镜、模板复用，自动字幕还是本地转写的，视频不外传。 剪辑出来的视频不加水印，提供 Windows、macOS、Linux 三个平台安装包。原推文媒体预览展开原推文收起原推文

@GitHub_Daily

现在的剪映不少功能都需要会员才能使用，还动不动就提示升级，剪个短视频也得掂量掂量。 WolfCut 干脆做了个免费开源的替代，开箱即用，装上就能剪，无需注册。 GitHub：http://github.com/jub0t/WolfCut 项目刚开源不久，功能目前还不是很多，但剪短视频常用几个功能都有。 包括多轨时间线、语音滤镜、模板复用，自动字幕还是本地转写的，视频不外传。 剪辑出来的视频不加水印，提供 Windows、macOS、Linux 三个平台安装包。

背景
CapCut（在中国称为剪映）是一款流行的视频编辑应用，但许多高级功能现在需要付费订阅，用户还经常遇到升级提示。WolfCut 是一个托管在 GitHub 上的开源项目，旨在免费且无需注册地复制 CapCut 的核心功能。本地转写意味着音频在用户设备上处理，而不是发送到云服务器，从而增强了隐私保护。跨平台支持使该软件能够在 Windows、macOS 和 Linux 上运行，而一些专有编辑器仅限于特定操作系统。

8月29日 04:00在 X 打开#open-source #video-editing #CapCut-alternative #cross-platform #privacy

107.0

Anthropic 与 Cursor 重申合作，增加 Claude 模型算力支持

Anthropic 与 Cursor 公开重申了双方的合作关系，Anthropic 承诺将增加算力资源，以支持 Cursor AI 编程工具中的 Claude 模型。双方通过社交媒体发布的消息还暗示未来将在 SpaceX 相关项目上展开合作。这一合作关系可追溯至 Claude Sonnet 3.5 发布之时。 这一重申表明双方将继续投资于 AI 编程工具，而这类工具正日益成为开发者工作流程的核心。为 Cursor 中的 Claude 模型增加算力，有望为庞大的 Cursor 用户群体带来更好的性能、更低的延迟以及更可靠的 AI 辅助。提及 SpaceX 则暗示合作可能扩展到要求更高或更专业的工程环境。 公告并未明确说明算力增加的具体幅度、时间表，或哪些 Claude 模型将受益。Cursor 以其 AI 聊天支持和调试功能著称，但 AI 聊天功能在未付费情况下存在使用限制。Anthropic 为 Claude API 提供基于用量的分级服务，但公告未提及 Cursor 的定价变化。

@trq212引用推文Long-time admirer of the Cursor team, few have done more to bring AI coding to the world. Excited to continue to partner with them.展开原推文收起原推文

@trq212

Long-time admirer of the Cursor team, few have done more to bring AI coding to the world. Excited to continue to partner with them.

@NotTomBrown

Cursor has been a trusted partner of Anthropic since Sonnet 3.5. We’ll continue to increase compute to support Claude models in Cursor and are excited for what comes next with them at SpaceX.

背景
Cursor 是一款基于 Visual Studio Code 的 AI 驱动代码编辑器，集成了大型语言模型，用于代码补全、聊天和调试。Anthropic 是一家 AI 安全公司，开发了广泛用于编程任务的 Claude 系列大型语言模型。两家公司的合作始于 Claude Sonnet 3.5 发布前后，使 Claude 模型成为 Cursor 中的核心选项之一。SpaceX 是一家私营航空航天制造商和太空运输公司，但所提及合作的具体性质尚不清楚。

8月29日 03:29在 X 打开#AI coding #Anthropic #Cursor #Claude #partnership

117.0

发布19个适用于AI与非AI应用的延迟优化模式

Bilgin Ibryam（@bibryam）宣布发布了19个通用的延迟优化模式，这些模式同时适用于AI和非AI应用。这些模式受到Pekka Enberg的著作《Latency》的启发，并已在Generative Programmer网站上发布。该公告强调，大多数AI延迟讨论都集中在模型上，但用户等待的是包括上下文、路由、工具、代理循环和验证在内的完整路径。 延迟是用户体验和系统性能的关键因素，尤其是在AI应用中，多个组件都会影响端到端的延迟。通过提供一套结构化的模式，该资源帮助从业者系统地解决模型推理之外的延迟问题。它弥合了通用软件延迟优化与AI特定挑战之间的差距，对广大工程师具有重要价值。 这19个模式发布在Generative Programmer网站上，该平台由Bilgin Ibryam运营。这些模式受到Pekka Enberg的著作《Latency》的启发，该书涵盖了软件工程、分布式系统、数据库和操作系统等领域的技术。公告强调，延迟涉及整个应用路径，而不仅仅是模型，包括上下文、路由、工具、代理循环和验证。公告中未提供具体的基准测试或定量结果。

@bibryam引用推文1 张图片🥳 It’s live: 19 general latency optimization patterns that apply to both AI and non-AI applications. Inspired by Pekka Enberg’s excellent book Latency 👏. https://generativeprogrammer.com/p/latency-patterns-for-faster-ai-applications原推文媒体预览展开原推文收起原推文

@bibryam

🥳 It’s live: 19 general latency optimization patterns that apply to both AI and non-AI applications. Inspired by Pekka Enberg’s excellent book Latency 👏. https://generativeprogrammer.com/p/latency-patterns-for-faster-ai-applications

Latency Patterns for Faster AI Applicationsgenerativeprogrammer.com · 直连原文

@bibryam

Most AI latency discussions focus on the model. But users wait for the full path: context, routing, tools, agent loops, and verification. Latency concerns appki I mapped these concerns to 19 patterns. Publishing soon Subscribe so you don’t miss it: https://generativeprogrammer.com/

背景
延迟是指请求与响应之间的时间差，是软件系统中的关键性能指标。在AI应用中，延迟不仅包括模型推理时间，还包括数据预处理、网络调用和后处理。Pekka Enberg是一位软件专家，以在操作系统、数据库和分布式系统方面的工作而闻名，他的著作《Latency》提供了一种全面的降低延迟的方法。Bilgin Ibryam是一位技术专家和作家，在Generative Programmer平台上撰写关于软件架构和AI的文章。

8月29日 19:13在 X 打开#latency #performance #AI applications #optimization #patterns

127.0

谷歌白皮书描绘AI智能体从开发到生产的全生命周期

Bibryam 分享了谷歌关于将AI智能体投入生产的白皮书摘要，强调了四个关键领域：受管控的数据与记忆、发布前的评估、安全与防护栏，以及上线后的可观测性。该白皮书可在 Kaggle 上获取，描绘了从开发到生产的完整生命周期。这为实践者提供了一个超越简单部署的结构化框架。 随着AI智能体变得更加自主并融入业务流程，确保其可靠性、安全性和合规性至关重要。该框架填补了原型开发与生产之间的空白，而许多智能体项目正是在此阶段失败。它为希望负责任地扩展智能体AI的企业提供了可操作的指导。 白皮书强调四大支柱：受管控的数据与记忆以防止数据泄露并确保上下文完整性；发布前的评估以对照基准衡量性能；安全与防护栏以约束智能体行为；上线后的可观测性以实时监控和调试。该白皮书发布在 Kaggle 上，可免费获取。该框架与 Grid Dynamics 和 Arthur 等来源的行业最佳实践一致，这些实践强调生命周期管理和安全覆盖。

@bibryam原推文1 张图片Taking AI agents to production takes more than deployment: • governed data and memory • evaluation before release • security and guardrails • observability after launch Google maps the lifecycle from development to production. https://www.kaggle.com/whitepaper-prototype-to-production原推文媒体预览展开原推文收起原推文

@bibryam

Taking AI agents to production takes more than deployment: • governed data and memory • evaluation before release • security and guardrails • observability after launch Google maps the lifecycle from development to production. https://www.kaggle.com/whitepaper-prototype-to-production

背景
AI智能体是使用大语言模型自主执行任务的系统，通常会串联工具调用并做出决策。从原型转向生产涉及非确定性行为、凭证管理以及持续监控需求等挑战。适用于智能体的MLOps实践包括生命周期管理、评估和可观测性。谷歌的白皮书是旨在使智能体AI具备企业级就绪能力的日益增长的资源的一部分。

8月29日 12:00在 X 打开#AI agents #production #MLOps #governance #observability