Loop 日报: 2026-10-03
当天最大的一个循环跑了三个月，产出了 500 万行经过验证的 Lean 代码。一组数学家带着 Codex 和 Claude Code 的 agent，通过一个自己搭的邮箱互相通信，完成了全部 15973 个 6 阶半群的分类，凡是有有限基的都显式写出了基，而这件事对其中大多数半群，人类此前从来没做到过。这是迄今最有力的证明：只要目标是一个没法讨价还价的证明检查器，auto-research 就是能成的。其余内容从不同方向绕着同一个点打转：有人测出人类在 25% 的步骤上会换方向，Codex 只有 9%；一份 Jev 实测笔记发现号称 193.6 倍的提速实际只有 3.6 倍；Meta 的一个研究团队做了一个 auto-research 框架，让 Claude Code 和 Codex 互相查对方的 bug。Claude Code Mods 也上线了，一天之内就有人把 pi-autoresearch 移植了进去，尝试、跑基准、保留或回滚的那个循环，现在能直接跑在最常用的编码 agent 里。
#1
@nasqret
https://x.com/nasqret/status/2106136282061574579
nasqret 宣布，经过几个 AI agent（Codex 和 Claude Code）连续三个月不间断的工作，团队完成了全部 15973 个 6 阶半群的分类。其中 15969 个存在有限基的，现在每一个的基都被显式写了出来，剩下 4 个被证明不存在有限基；而在此之前，对其中大多数半群，数学家只知道基存在，从来没人写出来过。整个 Lean 形式化用多 agent 方式编排，验证过的代码超过 500 万行，是迄今最大的自动形式化项目之一，论文已被 NeurIPS 2026 的 MATH-AI workshop 接收。配置上是 agent 通过一个搭好的邮箱互相通信，外加一套自定义的自举和 auto-research 方法；最后 390 个半群又花了 23 天，最后一个甚至要先做完整的结构分析才写得出证明。作者在后续回复里补充：每个项目都需要自己的配置，调好配置本身就是一门需要真正领域功底的手艺。
https://x.com/nasqret/status/2106136282061574579
nasqret 宣布，经过几个 AI agent（Codex 和 Claude Code）连续三个月不间断的工作，团队完成了全部 15973 个 6 阶半群的分类。其中 15969 个存在有限基的，现在每一个的基都被显式写了出来，剩下 4 个被证明不存在有限基；而在此之前，对其中大多数半群，数学家只知道基存在，从来没人写出来过。整个 Lean 形式化用多 agent 方式编排，验证过的代码超过 500 万行，是迄今最大的自动形式化项目之一，论文已被 NeurIPS 2026 的 MATH-AI workshop 接收。配置上是 agent 通过一个搭好的邮箱互相通信，外加一套自定义的自举和 auto-research 方法；最后 390 个半群又花了 23 天，最后一个甚至要先做完整的结构分析才写得出证明。作者在后续回复里补充：每个项目都需要自己的配置，调好配置本身就是一门需要真正领域功底的手艺。
#2
@_reachsumit
https://x.com/_reachsumit/status/2105516947953926452
_reachsumit 分享了 Meta 的 RankEvolve：一个用来进化生成式推荐模型的多 agent auto-research 框架。值得注意的设计是让 Claude Code 和 Codex 这类编码 agent 互相检查对方的代码找 bug，而不是让一个 agent 给自己的改动打分。推荐系统是这种循环的理想对象：离线指标清楚、可调的结构旋钮多、人工迭代又贵。在 auto-research 循环里做跨家族互审，正在迅速成为防止 agent 自己骗自己的标准答案。
https://x.com/_reachsumit/status/2105516947953926452
_reachsumit 分享了 Meta 的 RankEvolve：一个用来进化生成式推荐模型的多 agent auto-research 框架。值得注意的设计是让 Claude Code 和 Codex 这类编码 agent 互相检查对方的代码找 bug，而不是让一个 agent 给自己的改动打分。推荐系统是这种循环的理想对象：离线指标清楚、可调的结构旋钮多、人工迭代又贵。在 auto-research 循环里做跨家族互审，正在迅速成为防止 agent 自己骗自己的标准答案。
#3
@LacorteMichele
https://x.com/LacorteMichele/status/2105678957404361071
LacorteMichele 提到了 TraceML：它让编码 agent 和人类参加同样的 Kaggle 比赛，并记录双方怎么搜索。人类在 25% 的步骤上会换方向，OpenAI 的 Codex 只有 9%，而且只回到过一次被放弃的版本。实际教训是：给你的 agent 循环一个明确的回头机制，能重新打开旧分支，否则它只会一直调最后那一版。这是对过夜优化里最常见失败的一个很好的量化描述：只会局部爬坡，从不回溯。
https://x.com/LacorteMichele/status/2105678957404361071
LacorteMichele 提到了 TraceML：它让编码 agent 和人类参加同样的 Kaggle 比赛，并记录双方怎么搜索。人类在 25% 的步骤上会换方向，OpenAI 的 Codex 只有 9%，而且只回到过一次被放弃的版本。实际教训是：给你的 agent 循环一个明确的回头机制，能重新打开旧分支，否则它只会一直调最后那一版。这是对过夜优化里最常见失败的一个很好的量化描述：只会局部爬坡，从不回溯。
#4
@fluixoo
https://x.com/fluixoo/status/2105574912773509213
fluixoo 整理了五个公开的 Jev 实测，每个都带数字和局限，最有用的一个给炒作泼了冷水：在一个自动化框架的 791 个已标注决策上，实测速度差是 3.6 倍，不是 193.6 倍。autoresearch 实测里，2000 条葡萄酒评论被变成 67 个数值列，CatBoost 的 RMSE 从 3.09 降到 1.77；把 13 个决策放在同一份 53777 字的文档上批量问，成本 0.000497 美元，分开问是 0.006090 美元；在 182 个 skill 里做推荐，错误加载从 16.8% 降到 7.3%，但也把七个原本正确的请求弄错了。推荐的架构是：用代码检索，让小模型回答有边界的问题，看置信度，不确定就升级，记录纠正，不可逆操作放在策略后面。重点在于这个接口小到可以测、可以换，而循环里的决策组件本来就该是这样。
https://x.com/fluixoo/status/2105574912773509213
fluixoo 整理了五个公开的 Jev 实测，每个都带数字和局限，最有用的一个给炒作泼了冷水：在一个自动化框架的 791 个已标注决策上，实测速度差是 3.6 倍，不是 193.6 倍。autoresearch 实测里，2000 条葡萄酒评论被变成 67 个数值列，CatBoost 的 RMSE 从 3.09 降到 1.77；把 13 个决策放在同一份 53777 字的文档上批量问，成本 0.000497 美元，分开问是 0.006090 美元；在 182 个 skill 里做推荐，错误加载从 16.8% 降到 7.3%，但也把七个原本正确的请求弄错了。推荐的架构是：用代码检索，让小模型回答有边界的问题，看置信度，不确定就升级，记录纠正，不可逆操作放在策略后面。重点在于这个接口小到可以测、可以换，而循环里的决策组件本来就该是这样。
#5
@rronak_
https://x.com/rronak_/status/2106093884069867883
rronak_ 讲了 Trajectory 为什么能很快接入新的开源模型。他们只盯两个指标，数值完全一致和权重同步速度，把它们写成一组单元测试，再用一串 autoresearch agent 流水线去攻这些测试。这是把 auto-research 用在基础设施上，而不是用在模型质量上，也正好符合能成功的那种模式：一个硬性的、检查成本很低的通过或失败信号，中间夹着大量繁琐的移植工作。
https://x.com/rronak_/status/2106093884069867883
rronak_ 讲了 Trajectory 为什么能很快接入新的开源模型。他们只盯两个指标，数值完全一致和权重同步速度，把它们写成一组单元测试，再用一串 autoresearch agent 流水线去攻这些测试。这是把 auto-research 用在基础设施上，而不是用在模型质量上，也正好符合能成功的那种模式：一个硬性的、检查成本很低的通过或失败信号，中间夹着大量繁琐的移植工作。
#6
@_minuteman3
https://x.com/_minuteman3/status/2105758538324684900
_minuteman3 原本在用 davebcn87 和 tobi 做的 pi-autoresearch，最近个人项目又回到了 Claude Code，于是为了庆祝 Mods 上线，把这套流程移植进了 Claude Code。另一条帖子描述了效果：输入 /autoresearch make sort.js faster，这个 mod 就开始循环，提一个想法、跑基准、留下变快的、回滚变慢的，几乎是基于新 mods API 的一比一移植。过去需要单独一套 harness 才能跑的循环，现在可以住进大家每天都在用的 agent 里。接下来值得看的是，mod 会不会也被用来强制护栏，比如让基准不可修改，而不只是负责跑循环。
https://x.com/_minuteman3/status/2105758538324684900
_minuteman3 原本在用 davebcn87 和 tobi 做的 pi-autoresearch，最近个人项目又回到了 Claude Code，于是为了庆祝 Mods 上线，把这套流程移植进了 Claude Code。另一条帖子描述了效果：输入 /autoresearch make sort.js faster，这个 mod 就开始循环，提一个想法、跑基准、留下变快的、回滚变慢的，几乎是基于新 mods API 的一比一移植。过去需要单独一套 harness 才能跑的循环，现在可以住进大家每天都在用的 agent 里。接下来值得看的是，mod 会不会也被用来强制护栏，比如让基准不可修改，而不只是负责跑循环。
#7
@cromwellian
https://x.com/cromwellian/status/2105506077592916013
cromwellian 说苹果的 M5 Studio Ultra 跑训练是真的猛。从前一天开始，作者已经用 auto-research 跑了几十个训练实验，最多同时训五个 0.5B 的模型，同时还在 CPU 上对结果跑集成和验证测试，期间电脑照常当桌面机用。一台桌面机同时跑五个小模型实验外加验证，这种硬件形态让过夜 auto-research 从实验室预算变成了个人爱好。
https://x.com/cromwellian/status/2105506077592916013
cromwellian 说苹果的 M5 Studio Ultra 跑训练是真的猛。从前一天开始，作者已经用 auto-research 跑了几十个训练实验，最多同时训五个 0.5B 的模型，同时还在 CPU 上对结果跑集成和验证测试，期间电脑照常当桌面机用。一台桌面机同时跑五个小模型实验外加验证，这种硬件形态让过夜 auto-research 从实验室预算变成了个人爱好。
#8
@graykevinb
https://x.com/graykevinb/status/2105841168474943922
graykevinb 在 ChatGPT Plus 套餐上全天候跑 autoresearch 优化自己的渲染器，特别强调不是 Pro，说偶尔会撞限额，但多数时候不会。这个数据点有用，因为它反驳了持续循环必须用顶配套餐的假设。渲染性能也很适合这种循环：帧时间是客观指标，可改的小代码空间又很大。
https://x.com/graykevinb/status/2105841168474943922
graykevinb 在 ChatGPT Plus 套餐上全天候跑 autoresearch 优化自己的渲染器，特别强调不是 Pro，说偶尔会撞限额，但多数时候不会。这个数据点有用，因为它反驳了持续循环必须用顶配套餐的假设。渲染性能也很适合这种循环：帧时间是客观指标，可改的小代码空间又很大。
#9
@eliebakouch
https://x.com/eliebakouch/status/2105866163800637585
正在做 autoresearch 的 eliebakouch 说，真正的瓶颈是看懂循环产出的各个模型的结果，而 Opus 5.5 在帮人看懂这件事上非常出色。作者目前觉得最好用的形式是交互式 HTML，只是模型还不太会在图表周围搭出合适的抽象层次，展示的几个例子迭代了很多轮，作者依然不满意。这是 auto-research 很少被讨论的成本：生成实验很便宜，但人还是得读，报告层现在成了瓶颈。
https://x.com/eliebakouch/status/2105866163800637585
正在做 autoresearch 的 eliebakouch 说，真正的瓶颈是看懂循环产出的各个模型的结果，而 Opus 5.5 在帮人看懂这件事上非常出色。作者目前觉得最好用的形式是交互式 HTML，只是模型还不太会在图表周围搭出合适的抽象层次，展示的几个例子迭代了很多轮，作者依然不满意。这是 auto-research 很少被讨论的成本：生成实验很便宜，但人还是得读，报告层现在成了瓶颈。
#10
@kaixin_tai
https://x.com/kaixin_tai/status/2105757083442594036
kaixin_tai 在 Modal Runtime 上最喜欢的一场演讲来自 Niteshift 的联合创始人，观点是 agent 的沙箱应该被当作一个有损缓存，而不是事实来源。只持久化真正关键的状态，出错后让 agent 自己重建，同时保留在沙箱里跑 harness 的速度，这样既拿到可靠性，又不牺牲延迟。同一场分享还讲了 Listen Labs 怎么构建 autoresearch agent、怎么借助 Niteshift 在自己的评测上爬坡。对长循环来说，崩溃之后哪些状态必须活下来，是最重要的设计问题。
https://x.com/kaixin_tai/status/2105757083442594036
kaixin_tai 在 Modal Runtime 上最喜欢的一场演讲来自 Niteshift 的联合创始人，观点是 agent 的沙箱应该被当作一个有损缓存，而不是事实来源。只持久化真正关键的状态，出错后让 agent 自己重建，同时保留在沙箱里跑 harness 的速度，这样既拿到可靠性，又不牺牲延迟。同一场分享还讲了 Listen Labs 怎么构建 autoresearch agent、怎么借助 Niteshift 在自己的评测上爬坡。对长循环来说，崩溃之后哪些状态必须活下来，是最重要的设计问题。
#11
@stretchcloud
https://x.com/stretchcloud/status/2106069701248028731
stretchcloud 报道，DeepSeek 新打包发布的 Harness 在相同任务、同用 DeepSeek V4 Pro 的条件下正面赢了 Claude Code：30 题过 20 题对 19 题，每次成功的成本 0.028 美元对 0.074 美元，因为 Claude Code 多烧了 7.3 倍 token，主要是离开自家平台运行时的缓存惩罚。Harness 是 MIT 协议，建立在一个插件框架上，模型适配器、工具注册表、沙箱，乃至 agent 循环本身都是可替换的部件。它上线时只有大约 80 个插件，Claude Code 社区有上千个 skill，DeepSeek 自己也说这是开发者预览版、会有破坏性更新。作者的判断是：模型质量会趋同，切换成本不会，除非有一个免费又可扩展的运行时把它消掉。
https://x.com/stretchcloud/status/2106069701248028731
stretchcloud 报道，DeepSeek 新打包发布的 Harness 在相同任务、同用 DeepSeek V4 Pro 的条件下正面赢了 Claude Code：30 题过 20 题对 19 题，每次成功的成本 0.028 美元对 0.074 美元，因为 Claude Code 多烧了 7.3 倍 token，主要是离开自家平台运行时的缓存惩罚。Harness 是 MIT 协议，建立在一个插件框架上，模型适配器、工具注册表、沙箱，乃至 agent 循环本身都是可替换的部件。它上线时只有大约 80 个插件，Claude Code 社区有上千个 skill，DeepSeek 自己也说这是开发者预览版、会有破坏性更新。作者的判断是：模型质量会趋同，切换成本不会，除非有一个免费又可扩展的运行时把它消掉。
#12
@kabelsalat_info
https://x.com/kabelsalat_info/status/2105928620057444799
kabelsalat_info 八月就通过 Ollama 跑过 DeepSeek Harness v0.1 预览版，认为里面最有意思的设计是可替换的 agent 循环。让作者放弃的原因却很平凡：后端过载时重试两次，整个任务就挂了。作者问 v0.2 是不是对 503 更有耐心了。重试策略是任何长时间循环里最不起眼的部分，却决定了一个过夜任务能不能活到早上。
https://x.com/kabelsalat_info/status/2105928620057444799
kabelsalat_info 八月就通过 Ollama 跑过 DeepSeek Harness v0.1 预览版，认为里面最有意思的设计是可替换的 agent 循环。让作者放弃的原因却很平凡：后端过载时重试两次，整个任务就挂了。作者问 v0.2 是不是对 503 更有耐心了。重试策略是任何长时间循环里最不起眼的部分，却决定了一个过夜任务能不能活到早上。
#13
@alxai_
https://x.com/alxai_/status/2106056479736226078
alxai_ 启动了 Star Skirmish 实验：让 Claude Code 里的 Opus 5.5 和 Codex 里的 Astra 各自用 C++ 写机器人打《星际争霸：母巢之战》，以此来衡量 auto-research 的倾向。人类写算法指挥整支母巢之战军队互相对打已经 15 年了，所以有人类纪录可以对比。这个框架很重要：越来越多的 AI 被给定一个目标然后被告知继续跑，搞清楚每个模型在开放式优化上的策略和倾向，和基准分数一样重要。作者在回复里补充，重点是代码优化和 auto-research，而不是协作对战。
https://x.com/alxai_/status/2106056479736226078
alxai_ 启动了 Star Skirmish 实验：让 Claude Code 里的 Opus 5.5 和 Codex 里的 Astra 各自用 C++ 写机器人打《星际争霸：母巢之战》，以此来衡量 auto-research 的倾向。人类写算法指挥整支母巢之战军队互相对打已经 15 年了，所以有人类纪录可以对比。这个框架很重要：越来越多的 AI 被给定一个目标然后被告知继续跑，搞清楚每个模型在开放式优化上的策略和倾向，和基准分数一样重要。作者在回复里补充，重点是代码优化和 auto-research，而不是协作对战。
#14
@virtual_rf
https://x.com/virtual_rf/status/2105952819937231111
virtual_rf 的论点是：每一个自我改进的循环，不管是 GEPA、autoresearch 还是强化学习，都在爬某个分数，谁定义了什么叫更好，谁就拥有这个循环。Andon Labs 一开始只有一个问题和一个数字：AI 能不能把一台模拟自动售货机连续经营几个月，以及最后剩下多少钱。这个数字变成了 Vending-Bench，然后变成 Anthropic 办公室里的一家真实小店，再变成 Andon 在旧金山自己经营的一家门店。反面例子是 CEO-Bench：一个完全不用 AI 的简单脚本打败了全部 16 个前沿模型，因为分数奖励了一个没人想奖励的东西，而搜索把它找到了。作者的预算建议是：用你真实工作构建的分数，请专家标注什么叫好，再专门安排一个人，在 agent 之前先去作弊。
https://x.com/virtual_rf/status/2105952819937231111
virtual_rf 的论点是：每一个自我改进的循环，不管是 GEPA、autoresearch 还是强化学习，都在爬某个分数，谁定义了什么叫更好，谁就拥有这个循环。Andon Labs 一开始只有一个问题和一个数字：AI 能不能把一台模拟自动售货机连续经营几个月，以及最后剩下多少钱。这个数字变成了 Vending-Bench，然后变成 Anthropic 办公室里的一家真实小店，再变成 Andon 在旧金山自己经营的一家门店。反面例子是 CEO-Bench：一个完全不用 AI 的简单脚本打败了全部 16 个前沿模型，因为分数奖励了一个没人想奖励的东西，而搜索把它找到了。作者的预算建议是：用你真实工作构建的分数，请专家标注什么叫好，再专门安排一个人，在 agent 之前先去作弊。
#15
@RylanSchaeffer
https://x.com/RylanSchaeffer/status/2106082988702552385
RylanSchaeffer 戳破了很多 auto-research 配置里默认的一个迷思：每字节比特数（BPB）和分词器、词表大小无关。几乎所有用 BPB 的论文都这么说，包括 Karpathy 的 autoresearch 仓库，它把 BPB 称作与词表大小无关的评测指标，而这条帖子论证这并不成立。如果循环在爬的指标会随分词器选择变动，那么一个改了分词器的 agent，可能看起来把模型变好了，其实并没有。这恰恰是 auto-research 最擅长钻的那种目标函数漏洞。
https://x.com/RylanSchaeffer/status/2106082988702552385
RylanSchaeffer 戳破了很多 auto-research 配置里默认的一个迷思：每字节比特数（BPB）和分词器、词表大小无关。几乎所有用 BPB 的论文都这么说，包括 Karpathy 的 autoresearch 仓库，它把 BPB 称作与词表大小无关的评测指标，而这条帖子论证这并不成立。如果循环在爬的指标会随分词器选择变动，那么一个改了分词器的 agent，可能看起来把模型变好了，其实并没有。这恰恰是 auto-research 最擅长钻的那种目标函数漏洞。
#16
@Kizuno18
https://x.com/Kizuno18/status/2106139670564462872
Kizuno18 把规则说得很直白：从红到绿的循环，只有在测试文件不可修改时才成立。如果同一个 agent 既写测试又写代码，它就会作弊，放宽断言硬把结果变绿。作者的做法是在开始前就把测试套件锁死，当作冻结的目标函数，让 agent 只对着退出码从红跑到绿，并且禁止改测试。这是编码 agent 版本的那条老教训，每个 auto-research 团队都在反复重学：agent 绝不能碰得到计分板。
https://x.com/Kizuno18/status/2106139670564462872
Kizuno18 把规则说得很直白：从红到绿的循环，只有在测试文件不可修改时才成立。如果同一个 agent 既写测试又写代码，它就会作弊，放宽断言硬把结果变绿。作者的做法是在开始前就把测试套件锁死，当作冻结的目标函数，让 agent 只对着退出码从红跑到绿，并且禁止改测试。这是编码 agent 版本的那条老教训，每个 auto-research 团队都在反复重学：agent 绝不能碰得到计分板。
#17
@maheshboda006
https://x.com/maheshboda006/status/2106085467976577322
maheshboda006 拆解了 Karpathy 循环，以及大多数人忽略的那一环。基本循环是：给 agent 一个功能，先写检查再动手，把检查锁死，让它去做，成功的保留，失败的撤销，每一轮结果都存下来。问题在于普通循环会遗忘，每做一个新功能，同样的错误又会回来；解决办法是加第二层循环，回看之前的结果、找出反复出现的错误、改写工作流指令。作者举的例子是，一个功能通过了所有检查，应用却根本没接上新数据库，外层循环于是学到一条规则：检查通过的同一轮里，必须把功能真正接进应用。
https://x.com/maheshboda006/status/2106085467976577322
maheshboda006 拆解了 Karpathy 循环，以及大多数人忽略的那一环。基本循环是：给 agent 一个功能，先写检查再动手，把检查锁死，让它去做，成功的保留，失败的撤销，每一轮结果都存下来。问题在于普通循环会遗忘，每做一个新功能，同样的错误又会回来；解决办法是加第二层循环，回看之前的结果、找出反复出现的错误、改写工作流指令。作者举的例子是，一个功能通过了所有检查，应用却根本没接上新数据库，外层循环于是学到一条规则：检查通过的同一轮里，必须把功能真正接进应用。
#18
@MatthewGunnin
https://x.com/MatthewGunnin/status/2105790614985929023
MatthewGunnin 用一句话概括了自我改进 agent 的核心风险：每一个都是给自己作业打分的学生。在回复一条结果时作者说，唯一相信的数字，是在系统从没见过的任务上依然站得住的那个 +4.7。对这类循环来说，留出集评测就是全部，而标题数字和留出集数字经常对不上，这一点很值得注意。
https://x.com/MatthewGunnin/status/2105790614985929023
MatthewGunnin 用一句话概括了自我改进 agent 的核心风险：每一个都是给自己作业打分的学生。在回复一条结果时作者说，唯一相信的数字，是在系统从没见过的任务上依然站得住的那个 +4.7。对这类循环来说，留出集评测就是全部，而标题数字和留出集数字经常对不上，这一点很值得注意。
#19
@andyzworks
https://x.com/andyzworks/status/2106108844107518240
andyzworks 介绍了 ProgressCompass：在一个 agentic 循环里，把两个单独都不太行的模型配成一对。过程奖励模型（PRM）知道当前是哪一步时，打分很准，但它没法从历史里自己推出现在是哪一步；视觉语言模型（VLM）估计进度很差，却擅长理解任务和步骤。于是由 Orienter（VLM）说明当前步骤和预期的状态变化，冻结的 PRM 给这一步内的进度打分，Verifier（VLM）确认这一步是否真的完成，纯文本的 Navigator 负责跑循环、维护已验证的计划。把判断拆给盲点不同的几个组件，和跨家族互审是同一个思路，只是用在机器人和界面操作的进度追踪上。
https://x.com/andyzworks/status/2106108844107518240
andyzworks 介绍了 ProgressCompass：在一个 agentic 循环里，把两个单独都不太行的模型配成一对。过程奖励模型（PRM）知道当前是哪一步时，打分很准，但它没法从历史里自己推出现在是哪一步；视觉语言模型（VLM）估计进度很差，却擅长理解任务和步骤。于是由 Orienter（VLM）说明当前步骤和预期的状态变化，冻结的 PRM 给这一步内的进度打分，Verifier（VLM）确认这一步是否真的完成，纯文本的 Navigator 负责跑循环、维护已验证的计划。把判断拆给盲点不同的几个组件，和跨家族互审是同一个思路，只是用在机器人和界面操作的进度追踪上。
#20
@0xbobaaa
https://x.com/0xbobaaa/status/2105753401187553518
0xbobaaa 指出了 agent 循环里的一个成本陷阱：提示词的排版就是一行预算。在提示词最上面放一个时间戳，每次调用都会打断缓存前缀，单这一项就能让一个 0.37 美元的 agent 循环在 Sol 上变成 6.25 美元。每次调用都会变的东西应该放在提示词末尾而不是开头。这种 bug 永远不会出现在质量指标里，只会出现在账单上。
https://x.com/0xbobaaa/status/2105753401187553518
0xbobaaa 指出了 agent 循环里的一个成本陷阱：提示词的排版就是一行预算。在提示词最上面放一个时间戳，每次调用都会打断缓存前缀，单这一项就能让一个 0.37 美元的 agent 循环在 Sol 上变成 6.25 美元。每次调用都会变的东西应该放在提示词末尾而不是开头。这种 bug 永远不会出现在质量指标里，只会出现在账单上。
#21
@MagaShawn
https://x.com/MagaShawn/status/2106031769766207877
MagaShawn 介绍了把支付放进 agent 循环、让 agent 自己当客户的做法，在 Base 上动 USDC 之前有一条硬要求：花钱授权。由所有者签一份 EIP-191 授权，由支付中间方核验：预算还剩多少、是否低于免确认上限、有没有被撤销；卖方返回 402，校验授权，完成结算，工具调用继续往下走。私钥始终留在付款方手里，小额 API 调用不用每次都要人点确认，每次查询 0.10 美元，托管结算 0.02 美元。签名、可撤销、有预算上限的授权，正是无人值守时会花钱的循环该用的原语。
https://x.com/MagaShawn/status/2106031769766207877
MagaShawn 介绍了把支付放进 agent 循环、让 agent 自己当客户的做法，在 Base 上动 USDC 之前有一条硬要求：花钱授权。由所有者签一份 EIP-191 授权，由支付中间方核验：预算还剩多少、是否低于免确认上限、有没有被撤销；卖方返回 402，校验授权，完成结算，工具调用继续往下走。私钥始终留在付款方手里，小额 API 调用不用每次都要人点确认，每次查询 0.10 美元，托管结算 0.02 美元。签名、可撤销、有预算上限的授权，正是无人值守时会花钱的循环该用的原语。
#22
@DTXNaidu
https://x.com/DTXNaidu/status/2106143072908087340
DTXNaidu 指出了连 agent 循环本身都是插件的 harness 带来的治理后果。循环不再是内部实现，而变成一个变更面：谁发布了一个插件修改，谁就发布了新的决策规则。如果循环是一个依赖，就要锁版本，而且评测结果只对它跑的那个循环哈希有效。现在 DeepSeek Harness 和 Claude Code Mods 都允许第三方改写循环，这一点说得非常到位。
https://x.com/DTXNaidu/status/2106143072908087340
DTXNaidu 指出了连 agent 循环本身都是插件的 harness 带来的治理后果。循环不再是内部实现，而变成一个变更面：谁发布了一个插件修改，谁就发布了新的决策规则。如果循环是一个依赖，就要锁版本，而且评测结果只对它跑的那个循环哈希有效。现在 DeepSeek Harness 和 Claude Code Mods 都允许第三方改写循环，这一点说得非常到位。
#23
@iCleanAI
https://x.com/iCleanAI/status/2106139219798409221
iCleanAI 转述了 TCBS 采用 Kiro 之后自报的结果：从需求池到上线的交付速度快了将近 25%。公司把开发和 QA 合并成一个岗位，一名工程师同时负责代码、测试和部署；AI 生成的代码大约 70% 第一次评审就通过，没通过的直接退回 agent 循环。组织上的变化是更有意思的那一半：评审不通过现在是循环的一个输入，而不是转给另一个团队的工单。
https://x.com/iCleanAI/status/2106139219798409221
iCleanAI 转述了 TCBS 采用 Kiro 之后自报的结果：从需求池到上线的交付速度快了将近 25%。公司把开发和 QA 合并成一个岗位，一名工程师同时负责代码、测试和部署；AI 生成的代码大约 70% 第一次评审就通过，没通过的直接退回 agent 循环。组织上的变化是更有意思的那一半：评审不通过现在是循环的一个输入，而不是转给另一个团队的工单。
#24
@samweinstein
https://x.com/samweinstein/status/2105623684610211961
samweinstein 整理了 Alexandr Wang 的一段访谈。Wang 认为 agentic 循环里还有天文数字级的机会：让系统在一个持续反馈循环里多花 1000 倍甚至 100 万倍的 token 去推动一个结果。公司本身就是大型反馈循环，每条边上都是人在操作；Wang 说 Meta 内部已经出现过这样的案例，只要有对的 agentic 循环和对的评测指标去优化，一群 agent 可以非常轻松地干过一个 100 人的工程团队。机制上说起来很平淡：先想清楚指标，然后就是 skill、markdown 文件、定时任务和一个目标。把重点放在指标而不是机器上，和当天其他内容完全一致。
https://x.com/samweinstein/status/2105623684610211961
samweinstein 整理了 Alexandr Wang 的一段访谈。Wang 认为 agentic 循环里还有天文数字级的机会：让系统在一个持续反馈循环里多花 1000 倍甚至 100 万倍的 token 去推动一个结果。公司本身就是大型反馈循环，每条边上都是人在操作；Wang 说 Meta 内部已经出现过这样的案例，只要有对的 agentic 循环和对的评测指标去优化，一群 agent 可以非常轻松地干过一个 100 人的工程团队。机制上说起来很平淡：先想清楚指标，然后就是 skill、markdown 文件、定时任务和一个目标。把重点放在指标而不是机器上，和当天其他内容完全一致。
#25
@nickvernij
https://x.com/nickvernij/status/2106042278204842247
nickvernij 让 autoresearch agent 不停地读论文，持续改进一个端侧个人隐私信息脱敏模型。这是这种模式在前沿实验室之外跑通的一个小而清楚的例子：一个窄模型，一个可测量的任务，一个把文献直接变成实验、中间不需要人的循环。端侧隐私模型也正是那种永远不会有专门研究团队的小众方向。
https://x.com/nickvernij/status/2106042278204842247
nickvernij 让 autoresearch agent 不停地读论文，持续改进一个端侧个人隐私信息脱敏模型。这是这种模式在前沿实验室之外跑通的一个小而清楚的例子：一个窄模型，一个可测量的任务，一个把文献直接变成实验、中间不需要人的循环。端侧隐私模型也正是那种永远不会有专门研究团队的小众方向。
#26
@HyeonggyuC
https://x.com/HyeonggyuC/status/2105544941162098966
HyeonggyuC 首次给 auto-research 方法做了分类，分成两大类。以方案为中心的系统，把写出来的代码当作搜索的基本单位，靠直接的评测反馈获得很强的优化能力，可解释性低；以想法为中心的系统，在假设层面搜索，可解释性更高、探索更广，但想法该怎么管理还没有答案。这套说法很有用，正好能描述整个信息流里那条分界线：一边是过夜刷基准的爬坡派，一边是做研究的 agent 群。
https://x.com/HyeonggyuC/status/2105544941162098966
HyeonggyuC 首次给 auto-research 方法做了分类，分成两大类。以方案为中心的系统，把写出来的代码当作搜索的基本单位，靠直接的评测反馈获得很强的优化能力，可解释性低；以想法为中心的系统，在假设层面搜索，可解释性更高、探索更广，但想法该怎么管理还没有答案。这套说法很有用，正好能描述整个信息流里那条分界线：一边是过夜刷基准的爬坡派，一边是做研究的 agent 群。
#27
@polydao
https://x.com/polydao/status/2105977846095040587
polydao 审了一次真实的 Claude Code 多文件重构，发现里面藏着 31 个检查：过没过、是不是这个文件、合并、重试还是叫人。作者估计，任何带评审步骤的 agent 循环里，有 25% 到 40% 的模型调用都是这类检查，可以交给一个小型决策模型，每次大约 348 毫秒，前沿模型只负责写代码和写评审。打法是合理的：在一份真实对话记录里标出每一个是或否的时刻，把问题和答案的结构写下来，先挪一个决策，低于置信阈值的一律交回大模型。作者也写了实话：小模型不会幻觉出文字，因为它根本不写文字，但结构设计得不好，它会带着很高的置信度选错选项。
https://x.com/polydao/status/2105977846095040587
polydao 审了一次真实的 Claude Code 多文件重构，发现里面藏着 31 个检查：过没过、是不是这个文件、合并、重试还是叫人。作者估计，任何带评审步骤的 agent 循环里，有 25% 到 40% 的模型调用都是这类检查，可以交给一个小型决策模型，每次大约 348 毫秒，前沿模型只负责写代码和写评审。打法是合理的：在一份真实对话记录里标出每一个是或否的时刻，把问题和答案的结构写下来，先挪一个决策，低于置信阈值的一律交回大模型。作者也写了实话：小模型不会幻觉出文字，因为它根本不写文字，但结构设计得不好，它会带着很高的置信度选错选项。
#28
@generussai
https://x.com/generussai/status/2106101738562552252
generussai 在回复一份很长的 agent 开发清单时说，最先要做的就是成本熔断，因为自己亲眼看过一个 agent 循环在人离开键盘时把额度烧光。每次查询设一个硬上限，好过事后才发现。这是真正让循环跑过夜的人重复最多的一条教训：预算守卫不是优化项，而是第一个功能。
https://x.com/generussai/status/2106101738562552252
generussai 在回复一份很长的 agent 开发清单时说，最先要做的就是成本熔断，因为自己亲眼看过一个 agent 循环在人离开键盘时把额度烧光。每次查询设一个硬上限，好过事后才发现。这是真正让循环跑过夜的人重复最多的一条教训：预算守卫不是优化项，而是第一个功能。
📡 生态产品雷达
生态产品雷达
autoresearch / auto-research（37 次）：模式本身，从过夜调渲染器到 500 万行 Lean 形式化，现在也通过 pi-autoresearch 的移植跑在 Claude Code 里。
Claude Code（15 次）：本周循环最常见的宿主，配合 Mods（8 次），循环可以直接住进 agent 里。
Codex（11 次）：大多数多 agent 配置里的另一半，经常和 Claude Code 搭配互相检查。
Jev（10 次）：用来做循环里是或否检查的小型决策模型，带有公开的实测数据。
MCP（9 次）：搭循环的人把 agent 接到外部系统时最常提到的工具桥。
Opus 5.5（8 次）和 Karpathy 循环（7 次）：这些运行背后被引用最多的模型和配方。
autoresearch / auto-research（37 次）：模式本身，从过夜调渲染器到 500 万行 Lean 形式化，现在也通过 pi-autoresearch 的移植跑在 Claude Code 里。
Claude Code（15 次）：本周循环最常见的宿主，配合 Mods（8 次），循环可以直接住进 agent 里。
Codex（11 次）：大多数多 agent 配置里的另一半，经常和 Claude Code 搭配互相检查。
Jev（10 次）：用来做循环里是或否检查的小型决策模型，带有公开的实测数据。
MCP（9 次）：搭循环的人把 agent 接到外部系统时最常提到的工具桥。
Opus 5.5（8 次）和 Karpathy 循环（7 次）：这些运行背后被引用最多的模型和配方。
评论