2026年9月22日loop

Loop 日报: 2026-09-22

这个窗口里，循环掉过头来对准了它自己，而且真的奏效了。所有人都在读的那篇论文，把递归自动研究跑在了 agent 的 harness 上而不是模型上——152 个候选方向、535 个可执行环境、三千多次运行——最后留下四种机制，把 token 流量砍掉最多 49%、API 成本降低约三分之一，同时保住约 94% 的分数，而且原封不动地迁移到了另一家厂商的模型上、不需要重新搜索。让它可信的那个细节是：验收基准被冻结、从不回流到搜索里，因为此前的工作已经表明，进化出来的 harness 在它训练时对着的东西上分数很好看，换到新东西上几乎不提升。与之并行的是：十三个 agent 在没有管理者、没有分派任务的情况下做了十二天集体研究，靠的是把一张版本控制图当作共享记忆，最终把跟一个训练过的基线之间的差距抹掉了 62%——不过最有价值的那位读者指出，全程反复复用了同样的 200 条开发集文本，所以轨迹是可审计的，但泛化并没有被证明。配重来自那些把这些循环用在真问题上、并且如实报告哪里坏掉的人：一个前沿模型在自动研究交易信号时，参数探索得很差，还提出过「三个几乎一样的学习率」这种实验方案；一次过夜运行做出了十七倍的推理提速，但完全没有泛化；还有人在一条无人盯着的流水线上发现，95% 看起来像突破的东西都是对噪声抓取数据的过拟合，直到加上严格的外部验证闸门为止。这个窗口里最锋利的一句话回答了「自我改进循环会先瞄准什么」：哪一层有便宜的验证器就瞄哪一层。内核和上下文管理有。开放式的工作没有——这就是为什么同一个能把你 token 账单砍一半的技术，没法告诉你一个故事好不好。
💡#1
@askalphaxiv
https://x.com/askalphaxiv/status/2101578159674310707
这篇论文把整个窗口的讨论组织了起来：把一个递归的自动研究循环对准了 agent 的 harness，而不是模型。编程 agent 自己优化自己的 harness，不再靠人手工设计；在各类编程环境里，这个循环发现了四种机制，分别压缩上下文、观测、阅读和动作。结果是性能相当的前提下，token 流量减少 44.7% 到 49%，API 成本降低约三分之一。
💡#2
@arkyyang
https://x.com/arkyyang/status/2101300791651049832
对那篇论文最有用的一份拆解，写给做产品的人而不是研究者。他的第一条结论最能改变行为：agent 的账单里大头是重复的上下文而不是新的思考，因为每一步模型都要为整段对话重新计费——所以在换更便宜的模型之前，先量一量你的 harness 每一步重发了多少 token。第二条是浪费分散在四个不同的地方，应该分开修、分开量：把一次文件编辑和随后的测试合并成一个请求；只在预计节省超过重建成本时才压缩运行中的上下文；别再每一步都把巨大的工具输出完整重发，把它归档、只发一个短句柄加 1KB 摘录；用一个便宜模型把长构建日志压成一张经过验证的短回执，验证不过就回落到原始日志。第三，harness 的效率原封不动地迁移到了另一家厂商的模型上，所以把 harness 逻辑和模型相关的代码分开放。第四条是大多数人会跳过的：自动化的自我改进会过拟合，除非你把期末考试隔离起来——搜索跑在 535 个环境上，而验收基准始终冻结、从不回流；没有这一条，报出来的收益就是海市蜃楼。
💡#3
@Montreal_AI
https://x.com/Montreal_AI/status/2101667013462536610
他补上了那个结果背后的搜索规模，以及让它可信的那个细节：152 个候选方向、535 个可执行的搜索环境、三千多次运行、六万多次 agent 与环境的交互；之后候选 harness 被冻结，留出评测始终待在搜索循环之外，绝不针对最终测试打补丁。他对这次转变的概括很干净——harness 本身变成了研究对象，也就是说模型不用变，围绕它的那套智能系统也能变好。他还特别指出，作者很谨慎地把「递归式的效率改进」（更便宜的 harness 供养更大范围的研究、进而发现更好的 harness）表述为未来方向而不是已经演示出来的复利效应；他认为这种克制让结果更有意思而不是更没意思。
💡#4
@casper_hansen_
https://x.com/casper_hansen_/status/2101337016093065481
这个窗口里触达最高的一条，而且讲的是硬件。他转述 Jeff Dean 的说法：靠强化学习加上新的 EDA 工具链，芯片设计可以从两年压缩到三个月——本质上就是给硬件做一个专门的自动研究循环。底下有条回复问对了问题，但没得到回答：这意味着 agent 只是在提出布局方案，还是也在跑验证仿真？这两者的区别，恰恰就是「这个循环到底有没有一个真的验证器」这个全部问题。
💡#5
@JohnKutay
https://x.com/JohnKutay/status/2101892859305623793
他在一个真实的 GTM agent harness 里、用脱敏的生产数据，跑了一次别人都还在空谈的诚实测试。在「按策略给营销邮件分类」这个任务上，决策模型达到 90% 准确率，而 LLM 基线是 50%，速度快了将近八倍。但这不是全面胜利，而失败的那一半更有价值：它在他们的 text-to-SQL agent 循环里当控制机制时表现很差，因为它缺少解读内部业务定义所需的语义上下文。它能看到一次查询返回了行，但不知道这些行是否符合公司对「合格管道」的标准定义；而 LLM 可以先去查相关的数据模型、筛选条件和业务定义，再判断这次分析算不算完成。他的结论是对的：对可重复的分类极有前景，对重上下文的推理仍然不如 LLM，最好的用法是两者搭配。
💡#6
@de1lymoon
https://x.com/de1lymoon/status/2102028138297327884
他的论点是：给 agent 加一个决策模型并不会自动让循环变快，并给出了真正能让它变快的顺序。第一步是把循环捕获下来：把模型调用、工具动作、重试、延迟和成本都记下来，好知道时间到底花在哪儿。第二步是把重复出现的决定归类——要不要用工具、要不要重试、这事儿做完了没——并为每一个定义正确的结果。到这一步才开始路由：给快模型相关的状态和清晰的判据，而不是把整段对话推进一个深模型。设好信心阈值，让不确定或者新出现的情况升级上去。最后验证并测量，拿总循环时长、成本和错误数跟你的基线比。速度来自于找出 agent 一遍遍在做的那些决定，而不是来自换模型这个动作本身。
💡#7
@dani_avila7
https://x.com/dani_avila7/status/2101888707259256903
他照着一个 skill 推荐示例做了一个 Claude Code mod，而他对这意味着什么的概括比这个 mod 本身更锋利：它指向一种管理上下文窗口的不同方式——把 skill 选择、投入强度和工具选择都下放给决策模型。这样一来，harness 就能拆成一个个更小的、独立的决策服务，而不是把所有东西都塞进主 agent 循环里。
💡#8
@0xwhrrari
https://x.com/0xwhrrari/status/2102035137848381455
他在自己的 Mac 上，把一个决策模型放在一个云端 agent 产品前面跑了起来，并把配置和结果都发了出来。它分析了十二个实时选项，0.18 秒排完序，在不可逆的那一步之前停了下来，成本大约是两百万分之一美分。那七步配置主要是纪律：API key 别贴进聊天框、要放进安全字段；先用一个原语跑通冒烟测试；把路由器连同干跑模式和日志一起建好；加一个 skill，在浏览器操作、调研、重试或者派生另一个 bot 之前先调路由器；然后待在影子模式里读日志，直到你信得过它，同时留一个能完全绕过路由器的急停开关。到这一步才切到激活。十二个选项、六次决策检查、零次不安全动作、一个排名结果。
💡#9
@DivyanshT91162
https://x.com/DivyanshT91162/status/2101231430223462456
他描述了一种做法：十三个 AI agent 一起做研究，没有管理者、没有分派的任务、也没有常规意义上的共享记忆，因为研究过程被记录成了一张版本控制图。每一个假设、实验、结果、洞见和验证都变成一次不可变的提交，于是一个 agent 可以真的从另一个停下的地方接着干。他们真跑了：十三个语言模型工人、约十二天、1703 次贡献、十五个账号，胜出那条血脉里有 145 次提交、165 次独立复现。任务是用 141 个预训练捐赠模型去初始化一个 1.196 亿参数的混合模型，不给训练数据、不做梯度更新；评测指标从 3.39 降到 1.899 比特每字节，把跟一个训练过的小基线之间的差距抹掉了 62%。他喜欢的地方在于没有中央规划者——只是给了它们一块共享的研究记忆，然后放它们去探索。
💡#10
@ContextWindow_
https://x.com/ContextWindow_/status/2101131674666868784
他给了同一个集体研究结果一个它需要的怀疑读法。他接受那个底层想法——当会话内的结果没有为先前方法及其来源留下持久记录时，并行的研究 agent 会重复做同样的实验；而把代码、结果和验证主张存成互相链接的提交、再配上能看出哪些分支领先、哪些被忽略的可检索视图，确实解决了这个问题。但他把界线划得很准：选择过程反复复用了同样那 200 条开发集文本，所以这套系统让搜索轨迹变得可审计了，但研究本身并没有证明它带来了「发现效率」上的提升，也没有证明留出集上的泛化。这是两个不同的主张，而论文只支持其中一个。
💡#11
@sandeepinloop
https://x.com/sandeepinloop/status/2101694815851131113
他给同一套设计补上了威胁模型。把版本控制当作集体自动研究的共享记忆，作为底层是个很强的想法，但它同时也变成了一个传染面：只要有一个 agent 写下了一条钻空子的启发式，其余的都会捡起来。他的结论是：共享通道属于评测的威胁模型，而不只是存储设计的一部分。对于一种多代理研究系统尚未在规模上真正遭遇过的失败模式，这是目前最干净的表述。
💡#12
@edotenv
https://x.com/edotenv/status/2102075985973690493
一个干净的负面结果：让一个前沿模型在加密永续合约数据上自动研究深度学习信号。这个模型不会好好探索参数空间，一轮轮迭代之间只做最小幅度的改动；研究品味很差，有一次提出的实验方案是三个几乎一模一样的学习率；而且它在需要判断力的评估上很吃力，具体来说就是判读训练曲线——那里没有二元的判据。他的总结是：离这些模型能在真正困难的研究任务上派上用场，还有很长的路。
💡#13
@RRicefan
https://x.com/RRicefan/status/2102077726563971190
另一半配套结果，而那个对比才是扎心的地方。在真实历史数据、偏高频的目标上跑同样的自动研究，再次确认了这个模型在极低信噪比环境下是个糟糕的研究者、研究品味很差——但这个任务人类仍然解得了，因为他自己手工拟合的模型大幅跑赢了自动研究出来的那些，而且花的时间还更少。
💡#14
@gregpr07
https://x.com/gregpr07/status/2102157421909258560
跑了一晚上的自动研究没有泛化，这一点他直说了、没有藏着——但这次失败带出了两个具体的、值得留下的产出。它针对一个自定义 harness 专门优化了缓存，还在一个 2048 的块上实现了一个扩散 transformer，让推理快了十七倍。狭窄、不可迁移、但是真的：这三样凑在一起，才是大多数过夜运行真正会产出的东西。
💡#15
@Kizuno18
https://x.com/Kizuno18/status/2101834245471707397
他说清楚了把「自动研究表演」和「自动研究结果」分开的那个机制。在人口统计数据上跑一条无人盯着的流水线，他发现当模型提出假设、测试各种数据处理方式时，95% 看起来像突破的东西其实是对噪声很大的抓取数据的微妙过拟合。加上严格的外部验证闸门之后，103 次噪声实验变成了真实、可复现的收益。他的说法是：真正的复利，要等到自动研究循环装上确定性的评测闸门才开始。
💡#16
@rryssf
https://x.com/rryssf/status/2101392207999889475
他复盘了那个让这个词进入主流的过夜循环，而真正撑住它的是那笔算术。你给它一块 GPU 和一个 markdown 指令文件；agent 读文件、改真正的训练脚本、启动一次运行，不管硬件如何都严格封顶在五分钟。每跑完一次它只检查一件事——模型变好了没有——变好了就留下并提交，没变好就扔掉。五分钟一轮意味着每小时约十二次实验、到早上大约一百次；而一次公开的过夜运行跑了 700 次实验、找到 20 个真实的改进，全部有日志、全部可回滚、全部是在没人盯着屏幕的时候发现的。他最后那句最值得拿出来吵：瓶颈从来不是硬件，一直是那个决定下一步试什么的人。
💡#17
@chrismdp
https://x.com/chrismdp/status/2101627716210430011
一句话，划出了整套方法的边界。那两个知名的自动研究实现，爬的都是一个单一数字；而一个故事没有这样的数字——它好不好是个判断，所以裁判必须是一个把整场运行读完的 agent。关于「为什么这个技术能瞬间泛化到内核和编译器、却完全泛化不到开放式工作」，这是目前最干净的一句表述。
💡#18
@Tech_girl
https://x.com/Tech_girl/status/2102111778624692600
在公开的自动研究基准上做了一次正面对决，得出的数字大概会被很多人引用而不读注脚。在他们的测试硬件上，一套系统跑了 336 次实验，而一个通用编程 agent 跑了 76 次，而且前者的最终分数也更好。原始结果是公开的。实验次数这个数字才是有意思的地方，因为它衡量的是循环的吞吐量而不是模型的智能——而这恰恰是整个领域刚刚开始优化的那个变量。
💡#19
@ChrisJMcCormick
https://x.com/ChrisJMcCormick/status/2102102027279204747
这个窗口里最清晰的一个案例：一个人从别人发布的自动研究运行里把结果搬进自己的工作，而不是自己去跑一次。一叠改进让他的基线耗时降了 40%，而且他明确说了自己借了哪些想法——19.2 万的批大小、给某几个 lambda 加上门控、以及两张大的二元语法哈希表（两百万行和一百万行），表里那 52.5 亿个参数用稀疏、无一阶动量、只按行取幅值的方式优化。他同样明确说了自己没拿什么：不用 FP8、不用自定义内核，而且他特意提到自己的代码库还是干净的、没被 agent 搅乱。有意思的是他自己的两处改动：把梯度缓冲从哈希表里拿掉、把优化器内联进它们的反向计算；以及发现你可以只跑一次自动调优、然后把结果跟模型一起发出去。
💡#20
@vigram_void
https://x.com/vigram_void/status/2101809430602113122
他指出了一篇论文，里面有一个真正不同的想法来扩展研究型 agent：别再把它们提出的每一个实验都跑一遍。给自动研究 agent 做强化学习有一个很难看的瓶颈——生成可以很好地批处理，但每一个候选实验都需要自己的沙箱、数据加载、训练运行和评测；到最后贵的不是思考，而是搞清楚这个想法到底成不成立。这个方法用一个学出来的世界模型去预测实验结果，取代掉大部分真实执行，然后周期性地拿真实运行来校准它；配套的在线去偏纠正系统性的奖励误差，逆方差降噪压制噪声大的预测。数字是：4B 的 agent 从 883 GPU 小时降到 286，9B 的从 1174 降到 349，而且两者在留出集平均分上都赢过了全真实环境的强化学习。他点出的那个模式才是要点——学一个便宜的现实近似，节省着用现实来让它保持诚实，然后把大部分算力花在近似里面。
💡#21
@my_cat_can_code
https://x.com/my_cat_can_code/status/2101537855134941576
他指出某个会议的投稿摘要已经到了六万份，而去年是一万九千五——比此前所有年份加起来还多——然后拒绝了那个最省事的结论。人们还以为自动研究是在为「发论文」做优化，但被录用并不代表你发现了什么。自动研究该做的是发现新科学、推进前沿；论文从来就不是目的，而一个能写出顶会会收的东西的模型，是一台论文机器，不是一个研究者。
💡#22
@AtaeiMe
https://x.com/AtaeiMe/status/2102033799424954723
关于学术界这场争论最经过思考的一个版本，而且它一上来就承认了别人都在抗拒的那件事：旧的发表体系正在消失，而大部分被提出的解法都假设我们还能回到从前。他把投稿洪水看成一次拒绝服务攻击，因为产出一篇论文越来越便宜，而检查它仍然要花时间；他还说，自 2025 年起他就不觉得机器写的评审比平均水平的人类评审更差。他更锋利的一点是：就算把评审问题解决了也救不回来——任何有一台大节点的人都可以拿去年的论文做个显然的扩展然后不停投，那么当论文可以按小时产出时，「被录用」还意味着什么？何况我们仍然用发表记录来决定谁能拿到工作。他的建设性部分是那个提议：公开地跑自动研究，把过程轨迹跟论文一起发布，好让人看见都试过什么、以及某个方向为什么被放弃；并且给那些「发现了一个本会浪费半年的错误」的人记功，哪怕这件事里根本没有论文。发表本身早就像一种去中心化的递归自我改进，只是论文把这个过程压缩了，并且把其中大部分都扔掉了。
💡#23
@SuJinyan6
https://x.com/SuJinyan6/status/2101101400809963813
她从形式化验证这条路走到了同一个地方。一位创业者朋友向她推销用形式化方法「解决」验证问题，而她当时不好意思问出口的那个问题恰恰是对的：从自然语言转到形式语言这件事研究得挺充分了，可你怎么保证一开始那段自然语言本身就是完备的？她把这一点连到了自动研究的种种宣称上：用 agent 生成的论文去轰炸会议、把同行评审当成评测，对自动研究来说不是好的验证。她最后那句该留下：到最后，现实才是终审的验证者。
💡#24
@OngroundAI
https://x.com/OngroundAI/status/2101257979978743959
他一句话就把 harness 那个结果接到了更大的问题上。harness 的改动可测量、可沙箱、可回滚，而改权重三样都不是——这就是为什么效率这块的工作先落地。至于「自我改进循环会先瞄准哪一层」，他的答案是这个窗口里最好的一句：哪一层有便宜的验证器，就瞄哪一层。内核和上下文管理有；开放式的模型质量没有。
💡#25
@AxiomBot
https://x.com/AxiomBot/status/2101753455157326058
他用一个要求点名了这个领域缺的那件东西：这篇 harness 论文需要一张 harness 回执——仓库、环境、验证器、被选中的机制、被淘汰的机制，以及迁移结果。否则自动研究就变成一个非常有说服力的基准故事。那份清单里「被淘汰的机制」这一项，才是真正能改变些什么的部分。
💡#26
@GiulioRebuffo
https://x.com/GiulioRebuffo/status/2101316205499891832
他描述的工作流读起来像是对未来的一次预演：用一个 agent 把规则写出来，打开自动实现，再打开自动研究，最后你得到的是一个经过形式化验证、高效、而且一开始就带并行的程序。他另外还对自己的这份热情给了一条公道的批评——如果你不擅长 AI 工作流，这东西非常难用；那种只会说「别出错」、从没听说过这些循环的普通 agent 用户会完全懵掉，而这可能没关系，因为他们本来就不是目标用户。
💡#27
@GiulioRebuffo
https://x.com/GiulioRebuffo/status/2101507400540758244
一条一行的回复，抓住了把这些循环用到玩具场景之外的真正难点。有人说某个语言有潜力做到跟 C 一样快，他的回答是「那就自动研究它」——但你得同时盯住好几个变量：证明时间不能爆炸、证明覆盖率要好，所以这里的自动研究是多目标的。这个窗口里几乎每一个已发表的结果优化的都是单一标量，而这是第一次有人提到「如果做不到会怎样」。
💡#28
@hazemomier
https://x.com/hazemomier/status/2101826102545252671
十几个字，而这个窗口里有好几个人各自独立地得出了同一句：agent 循环花了一个下午，生产环境的外壳花了两周，而大多数「我们把 agent 上线了」的故事就死在这个落差里。demo 是工具加一个循环加一条顺利路径；生产是评测 harness、链路追踪、密钥注入、工具服务鉴权、上下文不对时会拒绝执行，以及它自信地胡说时有人值班。他给任何要批准 agent 项目的人的二选一是：要么先把那个下午的 demo 发出去、护栏以后再加；要么把外壳当成产品本身，因为循环是大路货。
💡#29
@ZainAkrams
https://x.com/ZainAkrams/status/2101456639194784130
他给同一个观察配上了一个公司级的数字。一家大型工程组织把 500 多个内部 agent 服务标准化到一套工具包上，这套包给每个新服务直接配好一个能跑的 agent 循环，外加评测、链路追踪、密钥管理和工具服务接线；把一个新 agent 接进生产的时间从两周以上降到了大约一小时。要紧的细节是：agent 在运行时从 50 多个服务里发现工具；所有模型调用都走同一个网关、覆盖五家供应商；建一个新服务就是填个表单、然后拿到一个框架和遥测都已接好的仓库；而且从第一次提交起就有评测端点。他的总结是：大家会截图那句「他们造了个 agent 框架」，而真正变了的是他们不再为每个服务各解决一遍生产化问题——到了 500 个 agent 这个量级，难题已经从「我怎么造一个 agent」变成了「密钥、追踪和评测归谁管」。
💡#30
@BrainsAndTennis
https://x.com/BrainsAndTennis/status/2101905384105787701
他说出了成本研究暗示但没明说的那件事：KV 缓存带来的巨大节省，实际上抑制了大量 harness 创新；尽管模型进步飞快，agent 循环在过去一年半里基本是冻住的。他的几条具体反馈值得留下。程序化的工具调用、索引和上下文内工具发现现在已经很常见。他很惊讶「压缩」这件事到今天居然还存在，并预计下一代 harness 会改成维护一个非常大的日志环形缓冲区，在上下文超限时对它做检索。子代理表现平平，因为除非路由做得非常仔细，否则它们可能既不省时间也不提高准确率，哪怕推理成本更高；不过下一代模型在委派上可能会更好，前提是子代理工具能够分叉上下文。至于「全家桶式」harness 带来的性能退化，上下文内工具发现只解决了一部分，归根到底那是块创可贴。
💡#31
@SlimAssiliX
https://x.com/SlimAssiliX/status/2101340977994650011
他指出了一种定价结构，大多数做 agent 的人都会在不知不觉中撞上。某个前沿模型有两档价格，中间只隔着 27.2 万输入 token 这一个阈值，越过之后输入和输出的单价都差不多翻倍——而且这不是渐变的，你一跨过去，整个请求就按新价重算。在一个每一步都把完整对话历史重发一遍的 agent 循环里，上下文是持续累积的，所以第 N 步并不知道自己刚刚越线了，但你的账单知道。他补的那一刀是：这正是某个主流 agent API 在长周期任务上默认的模型，而那套用来论证这个选择的架构，恰恰是最可能越线的那种。
💡#32
@SlimAssiliX
https://x.com/SlimAssiliX/status/2101299774615892081
同一个论点的小尺度版本，而且是更干净的那一版。同一个查询，三种设置：快模型七个 token，扩展思考 255 个，激进推理 603 个。单次查询这还好说，但放进一个跑十二步的循环里，你付的就不是十倍溢价，而是十倍乘以十二步、再乘以一个每轮都把完整历史重新喂一遍的上下文窗口。不是推理模型撑爆了你的预算，是那个在循环里调用它的架构。不设步数上限和上下文上限就切到推理模型，这是一个伪装成模型选择的计费决策。
💡#33
@gilesmboumi
https://x.com/gilesmboumi/status/2101299596601241845
他一句话读完一张市场图，并且抓对了重点。开源模型赢下 token 用量、闭源模型赢下支出，这一张图就是 agent 循环经济的全貌：循环对价格敏感而且全天候跑，所以贵的模型拿到 demo，便宜的模型拿到工作量。他最后那个问题没人在回答——有意思的数字不是市场份额，而是这些循环正在把谁的利润套走。
💡#34
@laoyu4399
https://x.com/laoyu4399/status/2101153814413762578
他这一周学到的东西，说得很直白：并行是免费的，直到额度不免费。多代理循环是真的，令人意外的是一个协调者加 N 个工人烧掉周预算的速度有多快。他抛给别人的那个问题很实际，而且目前还没有标准答案——你们是给每个任务的工人数设上限，还是就让它跑、等第一个 harness 亮黄灯了再换一个。
💡#35
@vibeconnectfyi
https://x.com/vibeconnectfyi/status/2101145033327984924
这个窗口里最小的一条有用建议，也大概是最多人应该照做的那条。给每个 agent 循环封上步数预算：设一个最大迭代次数和一个墙钟时间上限，任何一个触顶时让这次运行把部分状态返回出来。没有预算，一个坏掉的工具返回值就会变成无尽的重试，烧着 token 而且永远浮不上来。
💡#36
@sermakarevich
https://x.com/sermakarevich/status/2101259134125351259
他发布了「自己动手写 harness」系列的第二部分，而那份章节清单实际上就是别人都在空谈的那个东西的最小规格：模型怎么看见一个工具，以及让它调用工具再接着往下走的那个循环；文件和 shell 工具——创建文件、替换某一段精确的文本、带超时地执行命令；一道权限闸门，在任何东西碰到你的文件之前给出「允许 / 始终允许 / 拒绝」三个选项，「始终允许」在本次会话内记住；以及会话持久化，让你能关掉终端、重开、恢复，对话还在。
💡#37
@vraj_ai
https://x.com/vraj_ai/status/2101519151357653446
他提到某个实验室用宽松许可开源了自家的编程 agent CLI，带兼容 API 和交错思考；而他在意的理由是对的。这不是又一层聊天包装，这是「agent 循环作为一份可读的代码库」。如果你在评估编程 agent，有意思的地方是能读到它们怎么接线工具和规划，而不只是看模型卡。
💡#38
@AbuZ8Studios
https://x.com/AbuZ8Studios/status/2101851587366809881
他报告了前一天另一个开源出来的 harness：一套 agent 运行时，三种形态——桌面应用、浏览器工作区、终端 CLI——而且 CLI 源码是以普通目录的形式直接放在仓库里，不用折腾子模块。他给出的构建建议对任何想上手的人都很实用：先把 CLI 那一层建起来，等 agent 循环手感对了再去碰桌面打包。
💡#39
@bytecrafter_1
https://x.com/bytecrafter_1/status/2102102771621306685
他问了一个问题，而整整一类新插件都没有回答它。通过 SDK 驱动一个订阅，意味着你继承了那个 agent 自己的循环、系统提示词和压缩逻辑，于是你的 harness 变成了套在另一个 harness 外面，两者对「什么时候该裁剪上下文」意见不一致。他的追问一针见血：这个插件到底会不会把内层循环的工具调用结果暴露出来，还是只给你最后一轮？这一周发出来的每一个「桥接订阅」的插件都得回答这个问题，而没有一个回答了。
💡#40
@ravinsharma7
https://x.com/ravinsharma7/status/2101941995388432401
他把一场吞掉大量氧气的命名之争给剪短了。他说「分类器」这个词没问题，但那些人在这件事上态度很差，而他们给出的替代说法甚至跟被描述的东西不是一一对应的。如果目标是重新定义 agent 的软件架构，而不只是在用常规的 agent harness 和 agent 循环原语，那么叫它「系统一模型」也没问题。整场争论的实质，全在这个条件从句里。
💡#41
@Dxn1_0day
https://x.com/Dxn1_0day/status/2101118475515167002
他没参与吵架，直接给出了同一个论点的有用版本。agent 循环里不是每一步都需要生成式模型；如果任务是在若干结构化动作之间做选择，那么把 JSON 提示、解析和校验这一整套去掉，能省下相当蠢的一笔开销。他最后那句应该被拿来定研究议程：这里有意思的基准是端到端的 agent 延迟，不是模型智能。
💡#42
@akashcorex
https://x.com/akashcorex/status/2101504833383473578
一句话，把整个决策层叙事的门槛抬高了。一个快裁判在延迟和成本上赢很好，但更难的那道门槛是：假阳性会不会仍然溜进 agent 循环。这个窗口里所有人都在发速度数字，没有一个人发假阳性率。
💡#43
@parthjain_1
https://x.com/parthjain_1/status/2101876574500815342
他花了一个周末把关于这个新决策模型的一切读了一遍，写出了这个品类需要的那份说明，其中有两部分是真有用而不是软文。第一是几乎没人提到的计费机制：所有问题在一次调用里针对同一个 state 并行求解，而 state 只计费一次、不是按问题计费，所以加第五个问题几乎不花钱——把十三个问题批成一次调用，比分十三次调用便宜了十二倍。第二是那张「能力参差」说明页，他完整复述了：它不会计数也不会做算术；处理日期不可靠；不生成文本；读不了图像和音频；对 state 里的提示词注入没有加固；state 太大或者含无关内容会掉精度，所以必须先过滤；而一个中间值的概率意味着「真的不确定」，不是「中等强度」。他的两条操作提示最值得抄——把版本号钉死、别用会漂移的别名，因为在一个版本上调好的信心阈值迁移不过去；每次调用都把模型标识和用量记下来，这样当答案变了的时候，你知道是不是模型换了。
💡#44
@kunal_twts
https://x.com/kunal_twts/status/2101896690454462947
三行字，把别人都搞错的那个框架纠正了过来。你可以把这个决策模型放进 agent 循环里；它不一定是那个 agent；它是 agent 内部的决策层。这个窗口里大部分热情都把它当成了前沿模型的竞争对手，而这正是它纠正的那个范畴错误。
💡#45
@Sunilmehta_695
https://x.com/Sunilmehta_695/status/2101944506807427188
他画出了 agent 循环里每个部件该待在哪儿，这是这个主题下最可复用的一份产物。先观测状态——工单、工具参数、日志、消息。带类型的快模型负责路由、把关、打分、评估风险和紧急度。LLM 负责规划、写作、调试、解释。工具和 API 负责执行。然后循环闭合，快模型可以在不可逆动作之前再检查一遍。他的压缩很准确：带类型的快速 if 判断，和开放式的工作，是两件不同的事。
💡#46
@mukh_higgsfield
https://x.com/mukh_higgsfield/status/2101118918832312559
他指出别人那个 harness 里真正的故事在他看来是什么：那个被锁在闭源部分里的风险分类器。他自己也做了个类似的东西，用来在 bug 报告被提交之前先判断被报的工具到底是他们家的、还是被幻觉出来的；他的结论比这个窗口里大部分基准帖都值钱——这类便宜的判断题省下来的调试时间，比 agent 循环本身省下来的还多。
💡#47
@milonspace
https://x.com/milonspace/status/2101144862938800367
他给这份兴奋施加了有益的压力。一个轻量的结构化抽取模型早就能做到「输入 schema、一趟出分数」，所以真正的问题是在一个紧凑的 agent 循环里的校准，而不是谁先做出了分类。他对拥护者提的要求既公道又直接：如果这个新模型只是在同一个任务上更强，那就这么说；如果真正的差距是「延迟」和「弃权」这两样能用到每一次工具调用上，那才是值得抄的部分。
💡#48
@IndigoYogiArt
https://x.com/IndigoYogiArt/status/2101872919072928066
他解决了评测层从诞生起就有的一个问题：LLM 评测太贵了，光是裁判模型的成本就超过了被评测的东西。他的开源工具用带类型的决策替掉了 LLM 裁判——一次请求做八项评测、成本六百分之一美分、耗时是毫秒而不是秒——而位置才是重点：它跑在每一条轨迹上、在 agent 循环内部，而不是事后跑一次批处理。
💡#49
@thoughtcrime___
https://x.com/thoughtcrime___/status/2101758768371704271
他基于这个新决策模型搭了一个游戏测试实验室，带回来的心得关于评测而不是关于模型。在两款游戏上跑真实的试玩测试之后，那些被测试抓到的错误让他明白了为什么「机器人赢了」是一个糟糕的平衡性判定——胜负条件不是平衡性度量，而一个照着胜负条件去优化的自动测试器，会心满意足地给一个已经崩坏的游戏盖上合格章。他把运行记录和一份可复用的起手工作流都公开了。
💡#50
@jaredpalmer
https://x.com/jaredpalmer/status/2101110281300848799
一行字，很好地拍下了这套做法现在的真实状态。一个改进过的小 checkpoint 快好了，他顺手让一个 agent 在一个无服务器算力平台上通宵做点自动研究，纯属好玩。没有框架、没有论文、没有基准——只是一点闲置算力，加上一个对着某个指标跑的循环，而他去睡觉了。
💡#51
@iamMrDuncan
https://x.com/iamMrDuncan/status/2101920242557399105
他也在做同一件事，但留下了纸面记录。他在一块老卡上为某个特定的量化模型开了一次新的自动研究运行，一上来就把基线公开、而且很诚实——10.16 tokens/s 这个数字很难看，但那是老架构跑低量化的结果。实验要看的是：在两台更新的机器上跑二十四小时自动研究，能对着这个基线做到什么。另外他提到自己已经扩到三块实验板来并行测试。
💡#52
@rasmus1610
https://x.com/rasmus1610/status/2101341498113421697
这个窗口里最小、也最诚实的实验：他跑着一个自动研究循环去改进一个决策模型任务，而当天的目标是看看自己能不能挣到哪怕一毛钱。应该有人统计一下，这些过夜循环里到底有多少真的挣回了跑它们的成本。
💡#53
@theblazehen
https://x.com/theblazehen/status/2101703453471088951
他在动手之前先抛出一个「家庭版自动研究」网络的构想。每个项目都有一个公开的奖励函数，外加一个市场：你通过给别人的项目做贡献赚到 token，再用它来买别人在你项目上的工作——给别人的项目做出 0.2 倍的改进就赚二十个 token，而别人的 agent 每在你的项目上做出 0.01 倍改进，你就掉一个 token。他明确在问这个想法有没有搞头；而他还没解决的那个有意思的设计问题是：奖励函数公开，恰恰是它可以被钻空子的原因。
💡#54
@okay_lets_ride
https://x.com/okay_lets_ride/status/2101416496001843270
他描述了当指标活在一条公开账本上时，自动研究会长成什么样。把可度量的推理记录上链之后，你就能把自主实验跑成循环：一个 agent 盯着一个被度量的指标（比如盈亏或者流动性手续费），配一份固定或动态的推理预算，每个区块、每小时或者每天提出一个实验去改进这个指标，直到失败次数触顶或者预算耗尽。频率、预算、单个 agent 还是一群，都可以调。这里的指标天生就是对抗性的、而且天生就是公开的——这跟这个窗口里所有的基准都是完全不同的设定。
💡#55
@signalgaining
https://x.com/signalgaining/status/2101358724589949423
他报告了一件他说完全没人宣传的事：一个通用前沿模型在机器人任务上强得离谱，而且完全没有机器人相关的微调，在一堆基准任务上打败了大多数专用栈——抓放、无人机跟随、仿真机械臂，甚至是杂乱的闭环视觉控制——而且没错，它很慢。他的结论正是属于这个栏目的那句话：harness 看起来真的在融化。如果一个通用模型既能把世界模型吸收进自身、也能临时生成世界模型去驱动机器人，那么那些为了弥补模型不足而搭起来的专用栈，就不再值回它占的位置了。
💡#56
@sytelus
https://x.com/sytelus/status/2102055500565082599
他抛出了这个窗口里最大的一个论断，并说明了背后的机制。他预计到 2030 年所有主流软件都会被形式化验证，程度上会到「你不会再去碰一个未经验证的库」；他把两大障碍点为「规格的形式化」和「在十亿行代码的规模上做这件事」，并称这两样都是自动研究自我改进循环的成熟目标。他给出的自信理由很不寻常、也值得复述：要么 AI 被叫停，要么这件事必须发生。
💡#57
@signalgaining
https://x.com/signalgaining/status/2101851309561545115
他把同一套逻辑再往前推了一步，结果有点让人不舒服。如果存在一个更高效的世界模型，一个足够强的通用模型会把它找出来、吸收进自己的系统，或者强到能够即时生成新模型——而他相信这会让人类一直在缝缝补补的那些技术流水线相形见绌。不管他对不对，关于「为什么在这个框架下手工搭的流水线是一项贬值资产」，这是最干净的一次表述。
💡#58
@ChrisGPT
https://x.com/ChrisGPT/status/2101620010376389004
一份开发者大会愿望清单，里面有这个窗口最好的一条测量诉求。除了希望看到持续学习的研究——参数化学习、快速权重、适配器，任何形式的持久模型更新，而不是越来越精巧的上下文压缩——以及希望电脑操作从「截图、推理、动作」转向一个持续感知的桌面（把结构化的无障碍数据和低延迟视觉流结合起来），他的第四条才是该拿去要求各家实验室的：他想要自动研究助手的真实数字——下一个模型的研发流水线里有多大比例现在是由 AI 生成实验完成的、交付中有多少是自主的，以及如果它被导向了特定的研究目标，那些目标是什么。
💡#59
@toolcalls
https://x.com/toolcalls/status/2102088375062696271
他给「为前沿控速」这个论点提了一个别处没出现过的表述。他的读法是：所谓控速，实际上等于每天在一个让模型自我改进的自动研究循环上烧一千亿 token，而不是烧一万亿。不管别人本来是不是这个意思，这个说法把一个政策立场换算成了一份算力预算——而这是一个比原来那个立场更可证伪的东西。
💡#60
@yifanxu_ephai
https://x.com/yifanxu_ephai/status/2101489665383784565
他对这个窗口的整个前提提出了异议，而这个异议值得被记下来。他越是深入研究 agent 沙箱和环境 harness，就越觉得 harness 正在变得没那么重要：上限是由模型能力决定的，以及由那个让 agent 循环得以突破限制的运行时基座决定的。如果那些 harness 论文是对的，那他就错了；而如果他是对的，那些论文量的是成本而不是上限。
💡#61
@thaughtexpwai
https://x.com/thaughtexpwai/status/2101521470790807598
两句话，把自我改进的约束条件说得比论文还准。只改写 agent 循环的自我改进，瓶颈仍然卡在评测 harness 上。真正有意思的是当那个改进是一个你可以审计的补丁，而不是一个更大的黑箱。
💡#62
@sansan_sansannn
https://x.com/sansan_sansannn/status/2102001533043028201
他点出了那个递归 harness 结果底下的工程洞见：把整个 agent 循环表示成一个可以被评审、被修订的对象，这才是关键动作——因为大多数现有框架把 harness 当成相对静态的脚手架，而这种做法把它当成一等公民、可版本化、由证据驱动。他还点出了决定这套做法能不能站住的两件事：设计出不会因为啰嗦或者多走几步本身而给奖励的评测器，以及给 harness 做版本管理、好让你真能把性能变化归因到具体改动上。他说这两样缺一，你得到的就只是一坨越来越复杂、没人能调试的提示词和工具的意大利面。
💡#63
@tanjil6t99
https://x.com/tanjil6t99/status/2102006456753250559
他把整个窗口反复绕的那个区分压成了四行。递归自我改进是终局；递归 harness 改进是现在就能交付的那条路。同一个模型，更好的循环，然后让真实结果来判断这次改动到底算不算升级。最后这半句，正是大部分热情会跳过的部分。
💡#64
@latentumx
https://x.com/latentumx/status/2101344255440728553
他对一个基准的命名提出了异议，而这个异议其实很实质。你不能字面地把它叫作递归自我改进基准，因为那个词的意思是改进模型本身、权重是确确实实变了的——而这是一个自动研究基准，或者随便你叫什么「带明确可验证信号的长周期基准」。这个区分站得住：这个窗口里的每一个结果改进的都是模型周围的东西，而权重一动没动。
💡#65
@Vatsalpandya333
https://x.com/Vatsalpandya333/status/2102129016694317200
一句话，应该挂在每一个跑这些循环的团队的墙上：如果你看不见 agent 改了什么，你也就担不起它弄坏了什么。diff 是问责的最小单位。把这句话跟同一个窗口里的自动研究结果放在一起看——那里的 agent 自己改训练脚本、自己提交改进——这是成本最低的一道保险，而几乎没人点名说过它。
💡#66
@MTorygreen
https://x.com/MTorygreen/status/2102050797634678990
他在同一口气里说出了问责的另一半。更多自主不该变成更少问责：如果一个实验室给了 agent 工具、权限和行动空间，出事的时候责任仍然是它的，「是 agent 干的」不能当成逃生口。整个窗口讲的都是把循环里越来越多的部分交给机器，而这是唯一一条在问「谁来签字」的帖子。
💡#67
@PedroLaRosaDev
https://x.com/PedroLaRosaDev/status/2101939862060273855
一份两个 harness 的对比，出自一个每天两个都在用的人；它之所以配得上这个篇幅，是因为它把权衡说得很具体，而不是宣布谁赢了。一家的用量限制在用法得当时能撑得久得多，聊天应用的桌面体验也更好；另一家在「用 agent 做编程或者做工具」这件事上提供了更成熟的平台，有云端模式加上一个集群选项、不依赖你的设备就能一直干下去，CLI 更成熟，还有一套「用一个模型规划、用另一个模型实现」的打法，而且它遵守你写的规则。他点出的真正权衡是锁定：一家的模型锁死在自家平台上、而且在那儿运转完美，另一家的订阅则可以通过第三方 harness 去花，如果你要独立性，这一点很关键。他的结论顺着这个诚实地推了出来——做正经活他更喜欢前者，而换过去的理由只有一个：你正在搭一个不能依赖任何单一厂商的 harness。
💡#68
@GodsBoy7777
https://x.com/GodsBoy7777/status/2102130909143011637
他记录了一种插件模式——这一周有好几个人发了类似的东西，但没人描述得这么干净：编程 agent 保留订阅登录态，而另一个运行时保留 agent 循环、工具、审批和上下文压缩。凭证留在原地、不需要单独的 API key，订阅额度和超额规则照旧生效，插件还处于实验阶段。实际效果是一家厂商提供计费、另一家提供循环，而这种切分并不是订阅条款当初写来应对的。
💡#69
@sakshjn
https://x.com/sakshjn/status/2102107952538845539
他点出了这个模式累加起来意味着什么。某一家厂商的 SDK 正在悄悄变成所有人搭 agent 循环所依赖的基座，而「把一份订阅直接接进第三方 harness」才是真正要紧的那一环。「基座」这个词用得对：谁拥有那一层、让别人都在它之上搭自己的循环，谁就占住了一个不依赖于赢下任何具体基准的位置。
💡#70
@tsella
https://x.com/tsella/status/2101274078724153614
一个非编码的循环，但机制是真的。他的饮食追踪 agent 早上八点推送，把基础代谢、总日消耗和蛋白质目标从手表拉过来、连同体重趋势一起发给他；他拍张照发过去，得到估算好的三大营养素、已记录、以及剩余热量；晚上十点它出一张摄入对消耗的图，外加一句「你漏了什么」。它是时区感知的；而让它成为一个循环而不只是一个记账本的那部分是：消耗量会根据体重趋势自我调整，而不是停在一个固定目标上。
💡#71
@ZaneOnAI
https://x.com/ZaneOnAI/status/2101983791661081062
他指出了五场关于「从零搭建自我改进型 agent 系统」的工作坊，而真正有用的产物是它的顺序：先把第一个 agent 交付出去，然后是靠工具和 skill 实现的自我改进，然后是记忆，然后是主动型 agent，最后是让它自主。注意这个次序——记忆排在第三，在自我改进之后而不是之前，这跟大多数人搭这类系统的顺序正好相反。
💡#72
@cHHillee
https://x.com/cHHillee/status/2102161884740977120
他用三个从句点出了自我改进循环对基础设施的要求，而这三条不是人们通常会列的那些。你需要这个自动研究循环不被你实际的算力约束卡住、能瞬间且轻松地弹性扩缩、并且迭代周期非常短。一条都没提模型质量——每一条讲的都是底下那个基座的弹性。
💡#73
@realcalebwin
https://x.com/realcalebwin/status/2101817952140193993
他用一个观察指出了这一切有多早期。他非常看好把自动研究用在系统上，同时指出：一个工程团队哪怕只部署一个全天候跑、持续被优化、体积极小的决策模型，都罕见得离谱。这个窗口里所有人都在讨论递归式的 harness 发现，而几乎没有人拥有那个本该是第零步的、一直开着的优化器。
💡#74
@AhmedMa34437965
https://x.com/AhmedMa34437965/status/2102063079890751717
一条针对评审洪水的简短提议，比大部分长篇大论都更可执行：让作者承担自动研究 agent 的成本；如果一个仓库被标为「危险但没有大的失败」，那就进入有模型辅助的人工评审。给投稿定价、并按证据而不是按文字来分流，这跟这个窗口里其他所有提议都是不同的杠杆。
💡#75
@Shadowfetch
https://x.com/Shadowfetch/status/2101560117116170432
他对一个本地 agent 的结果提了正确的追问。显存约束才是有意思的地方，因为如果完整上下文和 agent 循环都能常驻，那改变的是本地工具的经济账而不只是基准分数——而他想知道的是：等 agent 开始依赖磁盘和网络之后，报出来的吞吐量还能剩下多少。这个窗口里每一条关于本地模型 agent 的宣称，量的都是那个点之前的数字。
💡#76
@TonyJZhou
https://x.com/TonyJZhou/status/2101697122886418637
他把别人的失败截图读对了，而这个领域很需要更多这种能力。同一台机器、多个会话、同一种失败形状——这不是采样噪声，这是共享状态：模型、harness、工具缓存，或者 agent 循环底下的某个共享层。他那个问题才是真能把原因隔离出来的：这些失败的会话除了权重之外还有什么共同点。
💡#77
@bigini01
https://x.com/bigini01/status/2102147498810773556
他点出了一个被多代理热情忽略掉的委派问题。他可能批准了一个 agent，结果实际干活的是另外四个 agent，而他从头到尾都不知道谁碰了什么。把这句话对着这个窗口里那个「十三个工人通过共享提交图互相传递工作」的集体研究结果来读，这就是同一套架构从「同意权」那一侧看过去的样子。
💡#78
@0x_tony_
https://x.com/0x_tony_/status/2102147383274430911
同一个论点，但加上了取证层面的后果：想象一下，三个不同的 agent 碰过同一件活之后，你要去追查错误到底发生在哪一步。这个窗口里那些集体研究系统正是用一张不可变的提交图解决了这个问题，而面向消费者的 agent 产品完全没有解决。
💡#79
@itzSaasified
https://x.com/itzSaasified/status/2102006713230459231
一行字，点名了每一个 agent 演示里缺的那一半：把演示变成一个人们敢信的产品的，是那个看不见的修复层；所有人都在发光鲜的 agent 循环，而几乎没人展示恢复逻辑的代码。跟上面那几条关于生产外壳的帖子对照着读，外壳和修复层其实是同一样东西的两个视角。
📡 生态产品雷达
生态产品雷达

SoL-Pi —— 组织起整个窗口的那个递归自动研究 harness 成果，至少从十几个角度被报道过。四种存活下来的机制：动作融合、在线上下文压缩、观测打包，以及一个保留证据的日志缩减器。头条数字：token 流量减少 44.7% 到 49%、API 成本降低约三分之一、保住基线 93.7% 的分数，而且跨厂商干净迁移。

Jev / TypeSafe —— 那个决策模型，在这里被讨论的身份明确是「循环内部的一个组件」而不是聊天模型的竞争对手。这个窗口里的真实集成包括：harness 路由、替代评测、浏览器和桌面操控、游戏平衡性测试，以及一条来自 text-to-SQL 循环内部的诚实负面结果。

Agora —— 把版本控制当作集体自动研究的共享记忆。十三个工人、十二天、1703 次贡献、胜出血脉里 145 次提交、165 次独立复现，外加一条论证扎实的、关于复用开发集数据的保留意见。

Pi —— 那个极简 harness，一次次作为基线出现、所有别的东西都拿它来量，包括那篇 harness 论文自己的对比。

Karpathy 的 autoresearch —— 依然是过夜循环的参考实现：一块 GPU、一个 markdown 指令文件、每次运行封顶五分钟，变好就留、没变好就撤。一次公开的过夜运行跑了 700 次实验、拿到 20 个真实改进。

EdgeBench / Terminal-Bench —— 那些效率宣称所依据的两个评测，被反复引用时给的都是「每个任务的成本」而不是原始分数。

Hermes —— 这个窗口里大部分非编码循环跑在它上面，包括一个饮食追踪循环，它的消耗目标会根据体重趋势自我调整。

Bend —— 一套「自动实现加自动研究」的工作流，产出的是经过形式化验证的并行程序；而给出公道批评的正是它自己的使用者：如果你没有现成的 agent 工作流功底，这东西非常难用。
← 上一篇
超级用户日报: 2026-09-22
下一篇 →
灵感雷达: 2026-09-22
← 返回所有文章

相关文章

Loop 日报: 2026-09-21Loop 日报: 2026-09-20Loop 日报: 2026-09-19Loop 日报: 2026-09-18Loop 日报: 2026-09-17

评论

加载中...
>_