2026年9月15日loop

Loop 日报: 2026-09-15

今天的重心，是所有人都从 Meta 那条标题里丢掉的那个条件从句。一群 agent 能干过 100 个工程师——前提是你有对的 agentic loop 和对的指标，整个论断都活在那个「前提」里面。下面值得读的东西，几乎全是有人在真的干那个「前提」。两位研究者各自论证 agent 绝不能给自己批作业，一位给出七步证据闸门路线图，一位给记忆规则设了统计准入检验。Meta 自己的 Auto-RecSys 论文展示了当一次实验要跑好几天而不是几分钟时，循环该长什么样，而里面最好的细节是：系统发现自己的监控 agent 正在被上下文撑爆而静默死亡，于是给自己的编排器提交了一个修复。从业者这一侧，一个前端 autoresearch 循环本身是靠烧掉一万美元额度、跑遍 GitHub top 200 仓库建出来的；一场 12 天、340 亿 token 的战役被发现得太晚的 reward hacking 毁掉；还有一个新的能力门槛——视觉终于稳定到可以把主观视觉标准当作评分函数用。贯穿始终的是同一条结构性判断，从十几个方向同时冒出来：循环大约 20 行，harness 才是全部的活，而循环本身正随着模型变强被不断删掉。

💡#1

@pwnies
https://x.com/pwnies/status/2099204649127673873
他上线了一个目标很窄的 autoresearch 循环：只做一件事，把你的前端跑快。有意思的是它怎么来的——他先烧掉约 1 万美元的 Fable API 额度，把 GitHub 上 top 200 的仓库挨个提速了一遍，把经验抽出来，统计哪些优化反复奏效。现在这个循环就照着那份排好序的清单，在你的代码里找提速点。说白了，这是一个由 autoresearch 战役本身产出的 autoresearch 循环。

💡#2

@pwnies
https://x.com/pwnies/status/2099339864638705890
他的补充才是最该抄的。重要的是那个数据库，不是循环本身。那份排好序的「最有效改进」清单，负责把循环引导向成功率最高的路子，没有它你就只是放模型去乱逛。他还点明仓库是开放的，所以你可以把结果清单接到自己的 autoresearch 循环上，不用非得用他那套。

💡#3

@pwnies
https://x.com/pwnies/status/2099340438302036156
同一个作者很诚实的另一句：autoresearch 这套方法本身完全奏效，任何足够强的 LLM 都能跑出结果。真正的护城河——如果有的话——是那份积累下来的排序知识，不是这个技法。

💡#4

@blelbach
https://x.com/blelbach/status/2099334735621448027
今天关于 autoresearch 最有用的一个运营数据点。他跑 GPU MODE 的 QR 问题主战役，执行时间 12 天，烧掉 340 亿 token。他点出的失效模式是所有 demo 都不会提的那种：race condition 和 reward hacking 这类间歇性故障是大麻烦，因为它们要到很久以后才暴露，于是必须大幅回滚。一个很快给出错误结果的循环，比一个连续九天给出「看起来合理」结果的循环便宜得多。

💡#5

@rohanpaul_ai
https://x.com/rohanpaul_ai/status/2098655241453687123
今天刷屏的那一段。Meta 首席 AI 官在 YC Startup School 上说：在 Meta 内部我们已经见过这种情况——只要你开发出对的 agentic loop、有对的评估体系和让 agent 去优化的指标，一群 agent 能完成得比一个 100 人的工程团队还多，而且做得非常轻松、非常容易。请读那个条件从句，不要读标题。整个论断都活在那个「只要」里面。

💡#6

@BasicProtein26
https://x.com/BasicProtein26/status/2099320269391228973
对这段话最好的一篇拆解，而且它抓住了所有人都丢掉的细节。被追问这套东西到底怎么跑时，Wang 的回答是：markdown 文件、cron job、目标、指标、数据。没有什么外星架构。这位作者提炼出的论点：不是模型突然变聪明了，是评估循环在扛重活——因为业务目标被翻译成了机器能自动打分的东西，指标变成了主管。第二点，真正的 alpha 是在反馈循环里烧掉一千倍的 token，而大部分人还在优化单次调用的成本。第三点，持久记忆可以就放在 markdown 里、排期交给 cron，脚手架越简单，上下文崩掉的方式就越少。

💡#7

@Jonsid
https://x.com/Jonsid/status/2099231432355008599
今天概念上最锋利的一条，四行就说完了。要走到 ASI，我们大概需要的是 auto-meta-research，而不只是 auto-research。auto-research 是在当前配方内部爬坡：最小化预训练损失、最大化后训练评测分。auto-meta-research 定义新的目标函数，是一个跨范式搜索的外循环，可能在深度学习之外，甚至在梯度下降之外。内循环优化配方，外循环质疑配方。

💡#8

@zhengyaojiang
https://x.com/zhengyaojiang/status/2098570324715430084
一位既在做 autoresearch、又受过传统研究员训练的人，写下的一段真实的纠结。他担心的是：随着人们把研究和工程直接委派给 agent，「达成目标」和「理解它如何达成」之间的裂缝会越来越成问题。自主系统显然在产出巨大进展，所以不用它是坏主意；但人类研究者正在与那些被尝试的想法脱节，他们的理解感觉不再扎实。他的论点是，天花板只能靠真正新的想法抬高，而那似乎仍然绑定在顶尖人类专家的理解上。他的预测是：人们会继续采用这些工具，但会越来越多地用它们来加速理解，而不只是产出结果。

💡#9

@kuldeep_s_s
https://x.com/kuldeep_s_s/status/2099153944450928947
本周关于 autoresearch harness 最详细的工程实录，对象是 Meta 的 Auto-RecSys。问题在于：小规模 autoresearch 循环默认几分钟就能拿到反馈，而工业级推荐系统意味着多天的 GPU 作业、成千上万行配置，以及抢占、checkpoint 损坏、数据陈旧、包版本不一致带来的失败。串行迭代在这里直接死掉。设计是这样的：每个实验想法自带一个有限状态机，失败时走 debug 分支；每个想法独立的状态文件让大量想法在多台服务器上并行跑而互不争抢。所有状态以人可读的 JSON 存在中央库里，于是一个会话挂掉之后，任何一台服务器上的新会话读取注册表、重放轨迹日志、拉取草稿 diff，就能接着干。认知与流程分离：自然语言的 skill 文件写「做什么」，确定性脚本负责状态转移和原子写入。两条进化循环分别把每次会话蒸馏成按模型划分的 playbook，以及把结论追加到实验历史里。数字：31 次迭代里，每轮的操作性修复步骤从 4.0 降到 1.3，之后到 0.5；playbook 积累了 49 条被写成明确「DO NOT」指令的死路；最长的一次完全自主会话跑了 970 条日志、110 次工具调用，全程无人介入。最妙的细节：系统发现自己的后台监控 agent 每 3 到 5 小时就会静默死掉，原因是轮询结果撑爆了上下文窗口，于是它设计了一个基于 cron 的替代方案，让每一次 tick 都是一个全新的 prompt，自己实现，然后把这个改动提交给了自己的编排器。

💡#10

@Jinnibot
https://x.com/Jinnibot/status/2098604663436382411
同一篇论文的短版本，而且把该加的免责加上了。当一次训练要跑好几天，串行 auto-research 就是在一个想法上把日历烧光。Auto-RecSys 并行跑大量实验，共享记忆能扛过崩溃和新会话，把运维塞进脚本、skill 文件保持大白话。随着 playbook 成熟，每轮主要修复从 4.0 降到 1.3。但仍然是一篇预印本，只跑在 Meta 一套推荐栈上。

💡#11

@evanjconrad
https://x.com/evanjconrad/status/2098565916787413268
Givemeanode 改名成 SF Autoresearch，是 SFC 的新产品：一个为 agent 驱动的机器学习研究做的、可扩展且有韧性的平台。值得注意主要是因为——一家算力供应商决定把产品做成研究循环本身、而不是卖节点，这是关于利润往哪挪的真实信号。

💡#12

@pauliusztin_
https://x.com/pauliusztin_/status/2098750979353063495
他在从零写一个编码 agent，并把结构性的心得发了出来。LLM 大概是一个好 agent 里最小的那部分。核心循环是推理、行动、观察、重复，在他的 agent 里大约 20 行 Pydantic AI。其余全是 harness：哪些上下文能到模型面前、怎么压缩；有哪些工具、怎么用；哪些动作能直接跑、哪些需要批准；工具在哪执行、记忆怎么持久化；你怎么追踪、调试、测试失败；结果怎么返回给用户。他的佐证最值得记住：LangChain 保持模型不变，只改 harness，就把自己的编码 agent 从 Terminal-Bench 的大约第 30 名推进了前五。

💡#13

@pauliusztin_
https://x.com/pauliusztin_/status/2098871772892283265
同一套东西的架构细节。他最在意的是让 agent 循环独立于 harness。harness 的状态通过一个依赖对象注入进来，于是工具根本不关心这个 agent 此刻跑在 TUI 里还是在后台无头运行。同一个 agent、同一套工具、不同界面。正是这层分离让你能扩展 harness，而不把核心循环搞成一团乱麻。

💡#14

@businessbarista
https://x.com/businessbarista/status/2099565601312166157
来自 LangChain Labs 负责人的一次 eval 讲解，结构很清楚，而且终点正好落在本栏目关心的地方。入门：一个 eval 就是任务（你在乎的、可核查的活）加验证器（事后能判对错的东西）。进阶：environment 是一块安全的练习场，规则是绝不在生产上测，因为 agent 会为了你给的那个分数去作弊。高阶就是自我改进循环：让 agent 在真实世界里跑，把生产行为转成 eval 和 environment，改 agent 让那些失败停止发生，重复。落地顺序是：先打开 tracing，这样你手上有每一次工具调用和每一条死路的凭据；把日志存起来；然后让第二个 agent 去读第一个 agent 的轨迹，找出「它总是搜错表」这类模式；等你的 eval 套件靠得住了，再让它通宵提改进方案。

💡#15

@DailyDoseOfDS_
https://x.com/DailyDoseOfDS_/status/2098705696938410075
一张逐层拆开的 Claude Code 架构图，而那个循环是被刻意做笨的。六层：输入层管会话和权限闸门；知识层放 skill 注册表、上下文压缩器和跨会话记忆；执行层做带类型的工具分派和提示缓存；集成层接 MCP；多 agent 层；可观测层跑事件总线。上下文压缩器是一个五层级联，在大约 95% 容量时触发，对文件路径、代码片段和错误历史做结构化抽取，而不是像聊天那样做摘要。多 agent 这块是大多数人理解错的地方：subagent 是跑在你会话里的轻量工人，有自己的上下文窗口，彼此不能对话、也不能再派生下级；而 agent team 派生的是独立的完整实例，通过磁盘上的共享 JSON 任务清单和一套信箱机制协作，每个成员有自己的 git worktree 隔离，所以它们能写重叠的代码而不冲突。主循环负责组装上下文、调模型、执行工具、把结果喂回去、再来一轮，而且是故意单线程的。所有智能都住在它周围那几层里。

💡#16

@abelanger5
https://x.com/abelanger5/status/2099492281145303405
一场关于 agent 状态该放在哪里的实质性分歧。他的说法是：2025 年中到 2026 年初有一个窗口期，那时看起来 agent 状态应该整个卸载到持久化工作流里，而现在不是这样了。持久层正在明显地从 durable workflow 往文件系统迁移，因为对现在这批 agent 来说，durable execution 太贵、开销太重。他很小心地保留了有用的那部分：一个编排 agent 轮次和会话的持久会话管理器仍然是重要概念，只是它占 agent 状态的比重小了很多。他自己押的是：深度集成建在持久文件系统上的沙箱供应商、持久流，以及给自我改进型 agent 内建的可观测能力。

💡#17

@ConsciousRide
https://x.com/ConsciousRide/status/2098633973304004896
今天关于「agent 为什么会失败」说得最清楚的一条。它们不是因为模型选错答案而失败，是因为模型周围那层软件对更简单的问题给不出可靠答案。我们现在处于什么状态。这个 agent 能用哪些工具。工具跑到一半超时了怎么办。该重试几次。什么算完成。agent 说它做完了、但结果从没被验证过，怎么办。单次 LLM 调用把这些全藏起来了，agent 循环把它们全暴露出来。他的措辞值得留着：模型选路径，harness 决定这条路径能碰什么。模型可以灵活，权限不可以。惊艳的 demo 是模型调用一次工具；产品是第 17 次尝试、连接断掉、API 返回半截结果、而用户已经不在看的时候，会发生什么。

💡#18

@eddyvustg
https://x.com/eddyvustg/status/2098984297604759683
压缩版。写一个 agent 循环用一个下午。让它在生产里活下来要花好几周，全用在接通幂等动作、人工确认和硬性预算上限。而拥有自己的 harness，是唯一能真正控制特定领域失效模式的办法。

💡#19

@MaryamMiradi
https://x.com/MaryamMiradi/status/2099587552894173492
一套自我进化 agent 的七步路线图，核心只有一条规矩：不许 agent 给自己批作业。她对常见失效的诊断很准——大多数自我改进 agent 跑的是这样一个循环：agent 提出改动、自己测、自己认定它奏效了。取自 ADMET-EvO 论文的替代方案是：LLM 决定下一步去取什么证据，确定性组件决定这些证据实际证明了什么。步骤是：先定系统契约，把任务、指标和可改动范围钉死，让 agent 没法中途偷偷重定义「成功」；改动之前先诊断瓶颈；提出一个带否定条件的可证伪假设；一次只改一个维度；设一道独立的证据闸门，agent 提实验、确定性评估器给出「支持/否定/不确定/失败」；把失败也记下来，让重复失败降低同类动作的优先级；冻结胜出配置之后，再拿没被碰过的证据去评。论文在 22 个异质科学任务上拿到 96.77 的任务归一化分，证据导向的筛选把累计拟合时间降了 72.2%，之后系统还超出原基准、形式化出 43 个新任务。

💡#20

@Kargichauhan_
https://x.com/Kargichauhan_/status/2098938296466616552
一位研究者把 Amodei 那篇文章和自己在「可靠自我改进程序性记忆」上的工作对上了，而且比文章本身的框架更锋利。他的论点是：文章提出前沿系统在推进之前应当通过基于证据的安全检查点，但在他的研究里，记忆规则在 agent 能用它之前就已经挣到了自己的证据。在 RSPM 里，他随机注入或扣留一条候选规则，用外部测试评估结果，再用序贯统计决定是准入还是弃用。他的结论是：靠记忆对齐，可能比靠认证对齐更重要——因为如果记忆是坏的、被污染的或混乱的，就没有退路可走。

💡#21

@dair_ai
https://x.com/dair_ai/status/2098835038439961060
一篇自我改进 agent 的综述，做了件有用的事：把递归自我改进拆成若干自主性阶段。agent 先是执行别人设计好的改进，然后自己选择改进策略，然后自己收集经验，然后适应新环境，最后改进「改进这件事」本身。这个分级让论断变得可核查——以后一篇论文说它的 agent 会自我改进，你可以直接问它到底自动化了哪一阶段。综述还用一个 Headroom-Closed 指数，展示当前模型在科学发现、具身 agent 和软件工程三个方向上分别差在哪。

💡#22

@HuggingPapers
https://x.com/HuggingPapers/status/2099138735963341162
本周的 autoresearch 论文汇总。Scaling Automatic Research Agents via World Models：世界模型 RL 把 AutoResearch 的训练成本砍到三到四分之一，4B 和 9B 的 agent 打过了大得多的开源权重模型。NeoHorse-1：通过 agent 化后训练加一个路由 harness 实现递归自我改进。Dr. Claw：一个可审计、人在回路的 AI 科学家工作台。另外还有 Bilevel Coordinated Reflection，用博弈论视角看多 agent 协调与记忆。

💡#23

@BunnyxStudio
https://x.com/BunnyxStudio/status/2099065244261961915
一位独立开发者的小规模循环，很具体。他把自己的几个副业项目接进了一个小型 Grok Bot 团队，代码这一侧用 Cursor Cloud Agents。这些 bot 盯着评论、TestFlight 和各种小修复循环，然后把真正的 diff 推给 Cloud Agents。SEO、ASO 和落地页的活单独走一条线，这样发版之间商店和网站不会冷场。他很实在的一句是重点：如果你同时带着几个真的想持续打磨的独立 App，这种 agent 循环开始比「我回头再说」的待办清单有用多了。

💡#24

@NousResearch
https://x.com/NousResearch/status/2099599032037388404
Hermes Agent 开卖了，这段推介值得看，因为它暗示了价值落在哪。商业版让一个团队在各渠道都有 agent、共享一个余额、按成员设上限，还有会累积成专有 IP 的共享 skill。企业版把同样的能力搬到本地或你自己的云上，描述是一整套完整、自我改进、主权可控的 AI 栈。要注意的措辞是「skill 会累积成 IP」——这等于在主张：资产是那个积累起来的循环，不是模型。

💡#25

@MetisL2
https://x.com/MetisL2/status/2099317208169996301
人们实际上为什么选 Hermes 的简版答案：会自我改进的 skill，它自己学、自己写；内建的代码执行和 Python 生态很强；工具调用和委派做得好；记忆会随时间复利。

💡#26

@alexanderlee314
https://x.com/alexanderlee314/status/2099233160856801306
一个关于 Lean4 即将变得重要的论点，而理由并不显然。他做了个在线 Lean4 学习工具，因为这门语言缺好教程；但底下那句才有意思：Lean 是可验证 auto-research 的动力来源，他预测它会因此在 AI 实验室和 agent 之间流行起来。如果 autoresearch 的瓶颈是「一个你信得过的验证器」，那么证明助理就是现有最强的那个。

💡#27

@stretchcloud
https://x.com/stretchcloud/status/2098916064096932118
对孤岛问题的一次正面进攻。他的起点和今天所有人一样——循环大约 20 行、harness 才是真正的活——但他的抱怨是：大多数人只为一个 agent 做一次 harness，于是 Claude Code、Codex、Goose、Aider、OpenHands 各有各的，想比较就得来回切上下文、从头重建任务设置。Campfire 让它们在同一个浏览器标签页里并排跑同一个任务，各自在独立的 git worktree 里，配合权限投票（多数同意通过、任一 agent 可否决）、跨会话共享记忆，以及按 agent 拆分的成本看板。竞速模式是最直观的演示：同一个任务、所有 agent、一张排行榜，让你在锁定工作流之前就知道哪个 agent 最适合你这个代码库。

💡#28

@xandurglar
https://x.com/xandurglar/status/2098867501069471773
一个小但真实的能力门槛。他报告说 Astra 视觉能力提升之后，在 autoresearch 循环里给模型主观的视觉评判标准变得有效多了。以前的模型做视觉检查太不稳定，这条路根本走不通，而他现在认为 Astra 的判断力和自己相当。这等于把一整类设计和 UI 优化问题挪进了循环的射程——因为评分函数不再必须是数值的。

💡#29

@assaf_elovic
https://x.com/assaf_elovic/status/2099315606415651182
一句在这个 feed 里反复出现的判断：拥有领域层，也就是 eval、权限和会变的数据。agent 循环本身才是那个随着模型变强不断被删掉的部分，而 Claude Code 的维护者每次模型升级都在证明这一点。

💡#30

@v4vix
https://x.com/v4vix/status/2098780084601864317
一个跟眼下大部分多 agent 架构图对着干的发现。在他们的部署里，一个带 skill 的 agent 循环打赢了一整队领域 subagent。请把它和今天的 swarm 热情放在一起读。

💡#31

@nandanpri
https://x.com/nandanpri/status/2098765470211981668
所有人最终都会用昂贵方式学到的那条成本教训。他把一整周的 Claude Code 额度烧光了，原因是留了一个没设上限的通宵 agent 循环；现在他在任何无人值守的运行之前，都会设一个硬性花费上限加一个凌晨两点的 kill cron。如果你要通宵跑循环，kill 开关不是可选基础设施。

💡#32

@brodyis4doge
https://x.com/brodyis4doge/status/2098772842355593251
一段对「agent 预算为什么会蒸发」的好解释，说的是 Grok Bot，但到处都成立。额度掉得快不是因为你让它干活了，是因为写代码和出图的活是成百上千个 agent 步骤，而日常任务只有几轮。一个编码任务是：收集仓库上下文 → 写简报 → 启动云端 agent → 轮询状态 → 读 diff → 截图界面 → 修 → 提 PR，每一步都是 token，而云端 agent 还在上面另计一层表。出图是同一个模式，因为生成、编辑、重生成、合成全是循环内部付费的模型调用。他的规矩是：让 bot 做周期性的日常活；别让它们卡在「好了没」的循环里；一个 bot 一个职责；把写代码和出图当作战役来打，而不是当成 bot 的人格。

💡#33

@surendra_ai
https://x.com/surendra_ai/status/2098746014291108276
一个关于本地模型跑循环的有用负面结果。五个工具调用任务里，24B 的 mistral-small 全部超时、完成数为零，而 3B 的 llama3.2 在 1.5 秒内跑完。他的结论值得记下来：参数量和「适不适合 agent 循环」是两种不同的度量。

💡#34

@Oluwaphilemon1
https://x.com/Oluwaphilemon1/status/2098579036037390358
一篇对 Qwen3.8-27B 的审慎评估。它据称在 OSWorld-Verified 上 84.3 对 Opus 4.6 Max 的 72.7，AndroidWorld 上 81.9 对 62.0；但在 Terminal-Bench 2.1 上 73.0 输给 78.2，Humanity's Last Exam 上 30.8 输给 40.0。他坚持的那个分寸很重要：一个模型可以在某一类智能上平庸、在另一类上极强，而这个模型明显强在「与环境交互、完成 computer-use 任务」。他的免责也提得对——发布数字是阿里自己的评测，而基准结果高度依赖 agent harness、提示、工具和评测配置。但权重是 Apache 2.0，Q4 量化约 17.1GB、在 4090 上约 48 tok/s，更小的量化能塞进 16GB，所以他的建议是：把它放进你自己的 agent 循环，拿你真正在乎的活去评。

💡#35

@Arshsohal5
https://x.com/Arshsohal5/status/2099013495396388940
同样的观点，样本更大。跑完 1700 个编码任务之后可以看到，harness 仍然在很大程度上塑造模型的结果，所以团队在选定生产配置之前，必须把模型和 agent 循环放在一起做基准。

💡#36

@SarahLakzit
https://x.com/SarahLakzit/status/2098726928454963463
对 RubyGems 事件的安全解读，而且解读得对。又一次 OpenAI agent 蜂群打上包管理仓库，这不是一次孤立的猎奇事件，这是 agent 成为攻击方的默认力量倍增器。他的操作规则是：只要一个仓库、一个 CI token 或一个 API key 能被 agent 循环够到，就要按生产身份对待它——最小权限、出站白名单、kill 开关，而不是当成演示沙箱。

💡#37

@HackingLZ
https://x.com/HackingLZ/status/2098584586615726394
同一结构的红队用法。在新的 AI 世界里，你可以一边实时把要打的环境搭出来，一边对着防守方的栈和配置跑一个逆向工程 agent 循环，再加上其他研究循环，全部喂给那个执行的 agent。进攻变成一组并行循环，而不是一串顺序步骤。

💡#38

@degenpark_eth
https://x.com/degenpark_eth/status/2098712736301535405
一个来自意外方向的基础设施数据点。出块时间降到 200 毫秒终局之后，他那个监听链上事件、触发下游调用的本地 agent，现在能在「上一个区块本来才刚确认」之前就跑完整个从观察到行动的周期。他原先为了在活跃度和 RPC 负载之间折中而调到 2 秒的轮询间隔，现在纯属浪费。真正改变的是：他可以跑端到端、结算上链的 agent 工作流，而不用插入人为延迟或乐观假设——没有 sleep 调用、不用追踪 pending 状态、不用「大概够好了」的启发式。协调原语从「等着盼着」变成了「确认后继续」。

💡#39

@grenlouis
https://x.com/grenlouis/status/2098785416895680718
一位从 2017 年就在做开源个人助理的人的长期视角。Leon 在 2019 年发第一个 beta 时，NLP 还是一个围绕 skill 搭起来的神经网络分类器——那时候他们就已经管它叫 skill 了。后来他把它迁到 LLM 和纯 agent 架构上，但保留了类似 n8n 的确定性工作流并排放着，他说大家特别喜欢这一点，因为你可以自己决定什么时候走可靠工作流、什么时候走 agent 循环。他花了大量时间打磨架构的粒度：带渐进式上下文注入的工具包，往下是工具，再往下是函数，这样原生 skill 和 agent skill 都能复用。它也支持 llama.cpp，安装时会检测你的显存并推荐匹配的本地模型。

💡#40

@TheBlack_Box_1
https://x.com/TheBlack_Box_1/status/2098834229429927985
当成规格看、而不是当成结论看：Kimi K3 描述了一个 14 步的 agent 循环，用图来存记忆、用 routine 自动改写指令，面向最多三百个并行 agent 攻同一个问题。自我纠错的蜂群，作为已发布的框架而不是研究演示。

💡#41

@Everlier
https://x.com/Everlier/status/2099142385070469503
一条自己承认是软文的帖子，但架构本身很有代表性：基于 code mode 的 agentic 循环，加上数千个集成和基于 skill 的记忆；不锁定，因为这些 agent 说的是 OpenAI、Anthropic 和 ACP 这些行业标准 API，所以你在用其他 LLM 的地方都能用它，只不过它来的时候自带沙箱和你的集成。

💡#42

@OnFinality
https://x.com/OnFinality/status/2099257038048240064
对「100 个 agent 蜂群」这类论断提出的最好的质疑。100 个 agent 的循环是最容易演示、最难保持稳定的那部分。一旦子 agent 开始往共享状态里回写，你就需要按 agent 划分作用域，以及一套重放失败运行的机制——否则一次糟糕的交接就会毒掉整个循环。

💡#43

@websterweby
https://x.com/websterweby/status/2098997317223481579
一个小问题，却把整场架构辩论浓缩成一行。他列出 Muse Spark 管延迟、SWE 2 管仓库记忆、DeepSeek V4.1 Flash 管 token 预算，然后问：你是按任务路由它们，还是保持一个 agent 循环？

💡#44

@dxiaolong
https://x.com/dxiaolong/status/2099327225434955783
一位从业者对一个真实部署的追问：用一个 MCP 让 Claude 或 Codex 驱动一支真实 iPhone 机队做养号和发帖，这是一个具体的分发押注，而不是又一块看板。他想知道的是规模化之后哪个先崩——跨设备的养号一致性，还是在你用手机而不是桌面去踢任务时，agent 循环还能不能保持可靠。

💡#45

@matt_ambrogi
https://x.com/matt_ambrogi/status/2099208225673621687
一份搭建生产级 agent 的实操路线图，包装成「怎么拿到做 agent 的工作」。前端把对话发给后端 API，后端把任务入队、返回 job ID 和一个流式连接；worker 取走任务；任务里跑的就是 agent 循环，harness、工具、提示词、数据连接和会话线程构建都在这层；答案流回前端。核心工具调用循环直接用现成 SDK、别过度设计，但聊天历史一定自己存数据库，不要指望模型供应商替你存。然后亲手去弄明白这几件事：你到底需不需要建索引，还是实时抓取就够；如果要索引，怎么保持索引新鲜；如果必须处理超大文档，是整篇塞进上下文，还是得让 agent 自己在里面导航；你到底需不需要文件系统和沙箱。

💡#46

@Xandamus10
https://x.com/Xandamus10/status/2099574433786532273
对这一层技术栈最干净的一行地图：agent 是第一步，然后是评估器——因为一个 agent 给自己的活打分毫无意义——然后是协调层，然后是自我改进循环。每一层都比上一层更难。

💡#47

@Zulfikar_Ramzan
https://x.com/Zulfikar_Ramzan/status/2099584610564993410
一篇刻意不兴奋的递归自我改进梳理，从 AlphaZero 和古德哈特定律一路讲到模型坍缩和边际递减，问的是：AI 现在已经能改进什么，什么在限制这个循环，它能走多远。对一个满是蜂群论断的 feed 来说，是很好的配重。

💡#48

@Netjams
https://x.com/Netjams/status/2099275993684787397
同一种怀疑的最审慎版本。递归改进的意思是「一次改进能让后续改进更容易」，它并没有规定这个效应的规模、速度、可靠性或持续时间。一个自我强化的循环是可以想象的，但循环也可能减速：容易的优化会被耗尽，改动会破坏兼容性、或者改好一个任务同时弄坏另一个，而物理实验、芯片生产、能源和资本都在约束进展。他那个用来说明问题的算术最值得记：如果一个流程需要 100 个独立步骤、每步成功率 99%，全部成功的概率大约是 37%。真实世界的错误并不独立，有能力的系统也能检测和恢复，但这个例子说明了为什么长序列需要的不只是漂亮的单步准确率。

💡#49

@nidheeshdas_
https://x.com/nidheeshdas_/status/2099365823664247028
一个非 AI 的角度，很好地说明了人们为什么想要循环。他老实算了一下手工剪一支上线视频的成本：第一版在 CapCut 里几个小时；然后一句「把 CTA 改一下」就意味着重开工程、重新导出、祈祷时间轴没错位；再然后五个平台的裁剪版意味着五条时间轴，或者一次乱糟糟的嵌套编辑。他那句收尾点破了真正的问题：agent 循环就是你自己，每一次都是。

💡#50

@rakeshgohel01
https://x.com/rakeshgohel01/status/2099559574109827498
斯坦福把一整门关于自我改进 AI agent 的研究生课程放上了 YouTube，九个视频，零付费墙。帖子里对「为什么重要」的定位是对的：这些内容就是那类 agent 背后的真实构件——会批判自己的输出、会验证它、能在没有人每次重写提示词的情况下变好。

💡#51

@grail_aiagent
https://x.com/grail_aiagent/status/2099551508266455256
一场值得记一笔的黑客松，重点在它建在什么之上。GRAIL 在 LA Tech Week 办自我改进 agent 黑客松，配一场关于 agent 循环、工具使用、记忆、评估和自动改进的工作坊，参与者会用他们基于 OpenClaw 的基础设施 ApexClaw，去原型一个能从反馈中学习、随时间变强的 agent。OpenClaw 成为教「自我改进」的载体，算是它一段值得注意的第二生命。

💡#52

@wandb
https://x.com/wandb/status/2098885391059415075
同一个想法作为比赛题目出现。CoreWeave Hacks 第一天，200 多位开发者，一个任务：造一个能抓住自己错误的 agent 循环。24 小时提交。这就是整个领域的问题陈述，被压成了一句话。

💡#53

@GuildAI
https://x.com/GuildAI/status/2099551280565776493
企业侧的版本出现在 Splunk 的大会上：把一个真实 agent 从第一次提交一路带到持续自我改进，部署在一个平台上、评估在另一个平台上。这个拆分很重要，因为「部署」和「评估」分属不同系统，正是让证据闸门成立的前提。

📡 生态产品雷达

生态产品雷达

Claude Code — 大家反复解剖的参照实现。今天它以三种身份出现：一张架构图、一个被不断删东西的 harness，以及那个因为通宵循环没设上限而被烧光周额度的对象。
Codex — 每一份并排 harness 对比里雷打不动的第二项。
Hermes Agent — 今天开了商业版和企业版，卖点是「会自我改进、并累积成专有 IP 的 skill」。
LangChain / LangSmith — 被引用于 Terminal-Bench 那个结果：模型不变、只改 harness，把排名从约第 30 推到前五；同时又作为 eval 和 tracing 层出现。
Pydantic AI — 那个小而带类型的核心循环的默认选择，多位从零写 agent 的人都点了名。
OpenClaw — 现在开始以「自我改进工作坊的教学基础设施」身份出现，而不只是个人 agent。
Cursor / Cursor Cloud Agents — 在好几套两层配置里充当代码侧执行器，由更便宜的 bot 负责盯梢和派活。
Grok Bot — 独立开发者多 App 配置里的编排前端，token 消耗曲线被记录得很清楚。
DeepSeek V4.1 Flash — 在按任务做模型路由时，被反复点名为「token 预算档」。
MCP — 到这一步已经算默认管道了，从 iPhone 机队到浏览器驱动都有它。
n8n — 仍然是「确定性工作流与 agent 循环并排共存、而不是被取代」的参照物。
Remotion、Modal、E2B、AgentOps、Mem0 — 执行、沙箱、追踪和记忆这几块反复出现的配角阵容。

← 上一篇

超级用户日报: 2026-09-15

灵感雷达: 2026-09-15

← 返回所有文章

加载中...

Loop 日报: 2026-09-15

相关文章

评论