Loop 日报: 2026-09-23
本轮最清晰的自动研究结果，把循环对准的是 harness 而不是模型，而且它压根没在追更高的分数：性能持平，token 流量少了大约 45% 到 49%，API 成本降了约三分之一。当能力天花板临近时，这类循环干的就是这件事——不再优化准确率，开始优化账单。今天几乎所有其他内容都贯穿着同一条主线。报告出来的最大单点增益，既不来自更好的模型，也不来自更好的检索器，而来自代理开始搜索之前的那一步。最具体的数字来自本地硬件：真实的多步骤代理任务平均 55 轮交互，跑在一张消费级显卡上。而与这一切相对的，是一条必要的纠正：把训练循环自动化，买到的是实验吞吐量，不是递归自我改进，因为假设仍然来自人，目前还没有任何评测循环能写出假设。
#1
@askalphaxiv
https://x.com/askalphaxiv/status/2101578159674310707
本轮最清晰的一个自动研究结果，而且它把循环对准的是 harness 而不是模型。这篇论文让编码代理递归地优化自己的 harness，而不是靠人手工设计。在多种编码环境里跑下来，这个循环自己发现了四种不同的机制，分别压缩上下文、观测、读取和动作。回报不是分数更高：性能基本持平，而 token 流量下降了大约 45% 到 49%，API 成本降了约三分之一。这正是能力天花板临近之后，自动研究反复呈现出的形状——循环不再追准确率，开始追账单。
https://x.com/askalphaxiv/status/2101578159674310707
本轮最清晰的一个自动研究结果，而且它把循环对准的是 harness 而不是模型。这篇论文让编码代理递归地优化自己的 harness，而不是靠人手工设计。在多种编码环境里跑下来，这个循环自己发现了四种不同的机制，分别压缩上下文、观测、读取和动作。回报不是分数更高：性能基本持平，而 token 流量下降了大约 45% 到 49%，API 成本降了约三分之一。这正是能力天花板临近之后，自动研究反复呈现出的形状——循环不再追准确率，开始追账单。
#2
@omarsar0
https://x.com/omarsar0/status/2102171057612566585
一个很扎眼的结果，说明深度研究循环里的杠杆到底在哪：在第一步。检索器不变、代理循环不变，只是在代理开始搜索之前加一步，就把某个前沿模型在浏览类基准上从 83.1% 抬到了 90.5%。方法是把问题拆成若干线索，每条线索转成互补的检索，汇总结果再重排，于是代理一开始循环，上下文里就已经有一组排好序的材料。同样的改动也把另外两个模型往上抬了一截，并把校准误差大致砍半，代价是每个问题多两到五次工具调用。真正值得琢磨的是错误分析：剩下的 79 个失败里，只有 3 个是因为正确文档压根没被检索到。
https://x.com/omarsar0/status/2102171057612566585
一个很扎眼的结果，说明深度研究循环里的杠杆到底在哪：在第一步。检索器不变、代理循环不变，只是在代理开始搜索之前加一步，就把某个前沿模型在浏览类基准上从 83.1% 抬到了 90.5%。方法是把问题拆成若干线索，每条线索转成互补的检索，汇总结果再重排，于是代理一开始循环，上下文里就已经有一组排好序的材料。同样的改动也把另外两个模型往上抬了一截，并把校准误差大致砍半，代价是每个问题多两到五次工具调用。真正值得琢磨的是错误分析：剩下的 79 个失败里，只有 3 个是因为正确文档压根没被检索到。
#3
@JohnKutay
https://x.com/JohnKutay/status/2101892859305623793
少见的一份诚实报告：把决策模型放进真实的代理 harness 里测，连失败的地方也写了出来。在一家薪酬公司的 GTM 代理 harness 中，用脱敏过的真实数据，这个分类器在「按策略给营销邮件分类」这件事上拿到 90% 准确率，而语言模型基线只有 50%，速度快了将近八倍。但它在文本转 SQL 的循环里当控制机制时表现很差，原因说得很精确：它能看到查询返回了若干行，却不知道这些行是否符合公司对「合格销售管线」的标准定义。语言模型则可以先去查看数据模型、过滤条件和业务口径，再判断这次分析算不算做完了。分类这件事可以迁移，语义上的完成度判断不行。
https://x.com/JohnKutay/status/2101892859305623793
少见的一份诚实报告：把决策模型放进真实的代理 harness 里测，连失败的地方也写了出来。在一家薪酬公司的 GTM 代理 harness 中，用脱敏过的真实数据，这个分类器在「按策略给营销邮件分类」这件事上拿到 90% 准确率，而语言模型基线只有 50%，速度快了将近八倍。但它在文本转 SQL 的循环里当控制机制时表现很差，原因说得很精确：它能看到查询返回了若干行，却不知道这些行是否符合公司对「合格销售管线」的标准定义。语言模型则可以先去查看数据模型、过滤条件和业务口径，再判断这次分析算不算做完了。分类这件事可以迁移，语义上的完成度判断不行。
#4
@de1lymoon
https://x.com/de1lymoon/status/2102028138297327884
这一周流传的一条有用的纠偏：把一个快速决策模型塞进代理，并不会自动让循环变快。速度来自先找出代理反复在做的那些决策，然后有意识地去路由它们。分阶段的配方是：记录、路由、回退、验证——先把模型调用、工具动作、重试、延迟和成本都记下来，才知道时间到底花在哪；再把「要不要用工具」「要不要重试」「是不是做完了」这类反复出现的选择归类，为每一类定义正确的结果；然后把相关状态和明确判据交给分类器，让它不必把整段对话推给深度模型就能决策；设置置信度阈值，让新奇的情况回退给更强的模型；最后拿总循环时间、成本和错误率跟基线对比。绝大多数人跳过的，恰恰是第一步的埋点。
https://x.com/de1lymoon/status/2102028138297327884
这一周流传的一条有用的纠偏：把一个快速决策模型塞进代理，并不会自动让循环变快。速度来自先找出代理反复在做的那些决策，然后有意识地去路由它们。分阶段的配方是：记录、路由、回退、验证——先把模型调用、工具动作、重试、延迟和成本都记下来，才知道时间到底花在哪；再把「要不要用工具」「要不要重试」「是不是做完了」这类反复出现的选择归类，为每一类定义正确的结果；然后把相关状态和明确判据交给分类器，让它不必把整段对话推给深度模型就能决策；设置置信度阈值，让新奇的情况回退给更强的模型；最后拿总循环时间、成本和错误率跟基线对比。绝大多数人跳过的，恰恰是第一步的埋点。
#5
@Oluwaphilemon1
https://x.com/Oluwaphilemon1/status/2102026214302978138
有人在认真做本地硬件上的代理基准测试，而且发布的结果跟直觉预期相反。二十个真实的多步骤修 bug 任务，跑在一个极简代理 harness 上，全部在一张 12GB 显存的消费级显卡加 16GB 内存的机器上完成，而问题的提法很有用：不是抽象地问哪个模型最强，而是问在这种硬件上你实际能跑起来并当代理用的最强模型是哪个。最抢眼的发现是，一个 27B 模型在两比特量化下追平了最高分，并且打败了这一轮里所有四比特的模型；而一个更新的蒸馏版本，反而比它被蒸馏进去的那个架构少完成了六个任务。
https://x.com/Oluwaphilemon1/status/2102026214302978138
有人在认真做本地硬件上的代理基准测试，而且发布的结果跟直觉预期相反。二十个真实的多步骤修 bug 任务，跑在一个极简代理 harness 上，全部在一张 12GB 显存的消费级显卡加 16GB 内存的机器上完成，而问题的提法很有用：不是抽象地问哪个模型最强，而是问在这种硬件上你实际能跑起来并当代理用的最强模型是哪个。最抢眼的发现是，一个 27B 模型在两比特量化下追平了最高分，并且打败了这一轮里所有四比特的模型；而一个更新的蒸馏版本，反而比它被蒸馏进去的那个架构少完成了六个任务。
#6
@Oluwaphilemon1
https://x.com/Oluwaphilemon1/status/2101462798031061362
同一个人早一点的那次实验值得对照着看，因为任务设计才是让数字有意义的地方：二十个多步骤修 bug 任务，每个平均约 55 轮交互，所以这是一个长周期的代理循环，而不是一次性的编码提示。大致同一个模型家族的五种配置，压缩方案和文件体积各不相同，成绩落在 20 分里的 7 到 16 分之间，而其中最好的本地量化版本，正好追平了官方托管 API。最后这个等价关系是个有用的参照点；而文件体积几乎一样、压缩方案不同却拉开这么大差距这件事，应该让所有只按体积挑量化版本的人警惕起来。
https://x.com/Oluwaphilemon1/status/2101462798031061362
同一个人早一点的那次实验值得对照着看，因为任务设计才是让数字有意义的地方：二十个多步骤修 bug 任务，每个平均约 55 轮交互，所以这是一个长周期的代理循环，而不是一次性的编码提示。大致同一个模型家族的五种配置，压缩方案和文件体积各不相同，成绩落在 20 分里的 7 到 16 分之间，而其中最好的本地量化版本，正好追平了官方托管 API。最后这个等价关系是个有用的参照点；而文件体积几乎一样、压缩方案不同却拉开这么大差距这件事，应该让所有只按体积挑量化版本的人警惕起来。
#7
@Oluwaphilemon1
https://x.com/Oluwaphilemon1/status/2101619782642500091
同一套环境产出了本轮最具体的本地代理数据点，而作者明确表示，那个抢眼的吞吐数字并不是重点。一个 27B 压缩模型在 12GB 消费级显卡上跑到大约每秒 40 个 token——而且不是空上下文的速度测试，而是把完整的 262K 上下文窗口常驻在显存里，上面还跑着真实的代理循环、加载了 25 个工具，完成了一次 77 分钟的构建，最后产出了一个能用的文件。他的表述是对的：一个模型在新鲜上下文的基准上可以好看得很，等到对话记录变长就崩掉，而无人值守的循环恰恰全程活在后面那个状态里。
https://x.com/Oluwaphilemon1/status/2101619782642500091
同一套环境产出了本轮最具体的本地代理数据点，而作者明确表示，那个抢眼的吞吐数字并不是重点。一个 27B 压缩模型在 12GB 消费级显卡上跑到大约每秒 40 个 token——而且不是空上下文的速度测试，而是把完整的 262K 上下文窗口常驻在显存里，上面还跑着真实的代理循环、加载了 25 个工具，完成了一次 77 分钟的构建，最后产出了一个能用的文件。他的表述是对的：一个模型在新鲜上下文的基准上可以好看得很，等到对话记录变长就崩掉，而无人值守的循环恰恰全程活在后面那个状态里。
#8
@GiulioRebuffo
https://x.com/GiulioRebuffo/status/2101507400540758244
一段很短的对话，但它准确反映了自动研究在编译器和证明系统领域是怎么被真正提出来的。建议是把一个自动研究循环对准某个有潜力达到 C 语言速度的语言实现，但附带的那个限定条件才是有意思的地方：你得同时盯住好几个变量，既不能让证明时间爆炸，又要保持良好的证明覆盖率。这是一个真正多变量的目标，也是自动研究叙事里比较诚实的版本——循环的上限取决于你交给它的那组约束，而在这里，只盯一个数字的评分会直接把它优化进一个毫无用处的结果里。
https://x.com/GiulioRebuffo/status/2101507400540758244
一段很短的对话，但它准确反映了自动研究在编译器和证明系统领域是怎么被真正提出来的。建议是把一个自动研究循环对准某个有潜力达到 C 语言速度的语言实现，但附带的那个限定条件才是有意思的地方：你得同时盯住好几个变量，既不能让证明时间爆炸，又要保持良好的证明覆盖率。这是一个真正多变量的目标，也是自动研究叙事里比较诚实的版本——循环的上限取决于你交给它的那组约束，而在这里，只盯一个数字的评分会直接把它优化进一个毫无用处的结果里。
#9
@StarkWareLtd
https://x.com/StarkWareLtd/status/2102004618997944360
自动研究以一种具名的、有赞助的竞赛形式出现，而不是作为一项研究技术。一家密码学公司联合两个伙伴发起了一项挑战赛，整个目标就是把某种抗量子交易的成本压到尽可能低。这个设定本身就值得记一笔：它是一个需要最小化的标量，外加一个可验证的检查器，而这恰恰是自动研究循环最爱吃的问题形状。这类东西会越来越多——只要一个领域已经有了便宜且可信的验证器，加上一个大家都认的数字，竞赛形式和自动化循环就会收敛到同一件事上。
https://x.com/StarkWareLtd/status/2102004618997944360
自动研究以一种具名的、有赞助的竞赛形式出现，而不是作为一项研究技术。一家密码学公司联合两个伙伴发起了一项挑战赛，整个目标就是把某种抗量子交易的成本压到尽可能低。这个设定本身就值得记一笔：它是一个需要最小化的标量，外加一个可验证的检查器，而这恰恰是自动研究循环最爱吃的问题形状。这类东西会越来越多——只要一个领域已经有了便宜且可信的验证器，加上一个大家都认的数字，竞赛形式和自动化循环就会收敛到同一件事上。
#10
@stretchcloud
https://x.com/stretchcloud/status/2102049713000534115
一篇论文主张 harness 应该像它内部的模型一样进化，而其中的防过拟合机制才是最值得留住的部分。它没有拿评分用的那个基准去调 harness——那只会教会它钻这个基准的空子——而是专门整理了两千个与评测集刻意不相交的进化任务。然后它在同一个任务上对比成功和失败的轨迹，从中分离出真正的行为缺陷而不是一次性失误，再把 harness 拆成五个模块：代理循环、工具使用、观测管理、上下文管理、任务完成检测，各自独立进化之后再整合回一个。在测试过的每一个基座模型上，进化后的 harness 都打赢了静态的。
https://x.com/stretchcloud/status/2102049713000534115
一篇论文主张 harness 应该像它内部的模型一样进化，而其中的防过拟合机制才是最值得留住的部分。它没有拿评分用的那个基准去调 harness——那只会教会它钻这个基准的空子——而是专门整理了两千个与评测集刻意不相交的进化任务。然后它在同一个任务上对比成功和失败的轨迹，从中分离出真正的行为缺陷而不是一次性失误，再把 harness 拆成五个模块：代理循环、工具使用、观测管理、上下文管理、任务完成检测，各自独立进化之后再整合回一个。在测试过的每一个基座模型上，进化后的 harness 都打赢了静态的。
#11
@ayyazdev
https://x.com/ayyazdev/status/2102186647961964579
一个很小的管道改动，但对任何用订阅制跑长循环的人来说都有实际后果。一个官方插件把某个代理框架的每一轮请求转发给另一家厂商的 CLI，这样 Pro 或 Max 订阅就能给这个循环供能，不需要单独的 API key。代理循环、工具、审批和上下文压缩仍然归这个框架自己管，借用的只有模型调用那一步。有两个运维细节很关键也很容易忽略：计费是按程序化代理的费率算的，不是更便宜的交互式费率；而且你必须把 API key 的环境变量清掉，否则它会悄无声息地把你切到按 token 付费。
https://x.com/ayyazdev/status/2102186647961964579
一个很小的管道改动，但对任何用订阅制跑长循环的人来说都有实际后果。一个官方插件把某个代理框架的每一轮请求转发给另一家厂商的 CLI，这样 Pro 或 Max 订阅就能给这个循环供能，不需要单独的 API key。代理循环、工具、审批和上下文压缩仍然归这个框架自己管，借用的只有模型调用那一步。有两个运维细节很关键也很容易忽略：计费是按程序化代理的费率算的，不是更便宜的交互式费率；而且你必须把 API key 的环境变量清掉，否则它会悄无声息地把你切到按 token 付费。
#12
@ayyazdev
https://x.com/ayyazdev/status/2102127463337754808
一家云厂商把代理循环开源成了一个库，而它瞄准的痛点非常准。一次 import 就给你 shell 和文件工具、网页访问、提示缓存、会把超大工具结果自动挪走的上下文管理、落盘的会话、长期记忆、一个通用子代理和一个待办追踪器，还有一个 TypeScript 孪生版本，换模型只要改一个字符串，托管和本地供应商都通吃。帖子里的定位很准确：大多数团队本来就有自己的代理循环。真正又无聊又难的部分，是那些「不把 token 烧光、不在任务中途丢上下文」的默认值，而把这些做成可覆盖的库交付出来，比再来一套要自己拼装的脚手架有用得多。
https://x.com/ayyazdev/status/2102127463337754808
一家云厂商把代理循环开源成了一个库，而它瞄准的痛点非常准。一次 import 就给你 shell 和文件工具、网页访问、提示缓存、会把超大工具结果自动挪走的上下文管理、落盘的会话、长期记忆、一个通用子代理和一个待办追踪器，还有一个 TypeScript 孪生版本，换模型只要改一个字符串，托管和本地供应商都通吃。帖子里的定位很准确：大多数团队本来就有自己的代理循环。真正又无聊又难的部分，是那些「不把 token 烧光、不在任务中途丢上下文」的默认值，而把这些做成可覆盖的库交付出来，比再来一套要自己拼装的脚手架有用得多。
#13
@ayyazdev
https://x.com/ayyazdev/status/2101700818692927631
某个实验室把自家的编码 harness 放到了 API 后面，而这篇帖子的定位是理解它的正确角度：代理循环过去是每个人各自重新发明的定制胶水，现在正在变成一个你直接调用的基础设施，就像模型早就是的那样。这个托管服务负责会话、编排、上下文压缩和故障恢复，会话是持久的、能跨轮延续，你可以接入自己的工具和协议服务器，沙箱用它的还是你自己的都行。值得注意的是它没有单独的 harness 费——模型 token 和工具按常规费率计费，沙箱按容器费率计费。任何还在自己维护压缩和重试栈的人，至少该把这笔账算一遍。
https://x.com/ayyazdev/status/2101700818692927631
某个实验室把自家的编码 harness 放到了 API 后面，而这篇帖子的定位是理解它的正确角度：代理循环过去是每个人各自重新发明的定制胶水，现在正在变成一个你直接调用的基础设施，就像模型早就是的那样。这个托管服务负责会话、编排、上下文压缩和故障恢复，会话是持久的、能跨轮延续，你可以接入自己的工具和协议服务器，沙箱用它的还是你自己的都行。值得注意的是它没有单独的 harness 费——模型 token 和工具按常规费率计费，沙箱按容器费率计费。任何还在自己维护压缩和重试栈的人，至少该把这笔账算一遍。
#14
@TonyJZhou
https://x.com/TonyJZhou/status/2101697122886418637
一条很犀利的诊断式回复，讲的是怎么读一个正在运行的循环里的故障。面对一堆反复失败的截图，他的观察是：同一台机器、多个会话、同样形状的失败，这不是采样噪声，而是共享状态——模型、harness、工具缓存，或者代理循环底下某个别的共享层——而正确的问题是，这些失败的会话除了权重之外还有什么是共同的。这正是代理工作最需要、目前又最缺的调试直觉：多次独立运行出现完全一样的失败形状，是共同依赖的证据，而不是关于模型本身的证据。
https://x.com/TonyJZhou/status/2101697122886418637
一条很犀利的诊断式回复，讲的是怎么读一个正在运行的循环里的故障。面对一堆反复失败的截图，他的观察是：同一台机器、多个会话、同样形状的失败，这不是采样噪声，而是共享状态——模型、harness、工具缓存，或者代理循环底下某个别的共享层——而正确的问题是，这些失败的会话除了权重之外还有什么是共同的。这正是代理工作最需要、目前又最缺的调试直觉：多次独立运行出现完全一样的失败形状，是共同依赖的证据，而不是关于模型本身的证据。
#15
@TonyJZhou
https://x.com/TonyJZhou/status/2101533796327670072
一句话说清了为什么代理的经济账不同于聊天的经济账。机制在于 token 体量：一个代理循环在单个任务上烧掉的 token 比一次聊天轮次高出几个数量级，于是在总账里，每 token 的价格开始压过质量的权重。结论直接跟着出来，而且比大多数路由建议更可操作——顶级能力只在小模型顶不住的那条尾巴上才有意义，所以把那部分路由走，其余的跳过。这跟决策模型这波浪潮讲的是同一个道理，只不过是从账单那一侧、而不是从延迟那一侧推出来的。
https://x.com/TonyJZhou/status/2101533796327670072
一句话说清了为什么代理的经济账不同于聊天的经济账。机制在于 token 体量：一个代理循环在单个任务上烧掉的 token 比一次聊天轮次高出几个数量级，于是在总账里，每 token 的价格开始压过质量的权重。结论直接跟着出来，而且比大多数路由建议更可操作——顶级能力只在小模型顶不住的那条尾巴上才有意义，所以把那部分路由走，其余的跳过。这跟决策模型这波浪潮讲的是同一个道理，只不过是从账单那一侧、而不是从延迟那一侧推出来的。
#16
@TonyJZhou
https://x.com/TonyJZhou/status/2102330168765489377
本轮里最必要的一个区分，而且它直接顶撞了嗓门最大的那些说法。把训练循环自动化，买到的是实验吞吐量，不是递归自我改进。发起训练、盯着作业、修复失败、跑评测，这些在「每次试验消耗的研究员工时」上都变便宜了，这是真实且有价值的。但假设仍然来自人，目前还没有任何评测循环能写出假设。任何把吞吐提升读成自我改进曲线起点的人，都是把「验证一个想法的成本」和「想法的来源」混为一谈了。
https://x.com/TonyJZhou/status/2102330168765489377
本轮里最必要的一个区分，而且它直接顶撞了嗓门最大的那些说法。把训练循环自动化，买到的是实验吞吐量，不是递归自我改进。发起训练、盯着作业、修复失败、跑评测，这些在「每次试验消耗的研究员工时」上都变便宜了，这是真实且有价值的。但假设仍然来自人，目前还没有任何评测循环能写出假设。任何把吞吐提升读成自我改进曲线起点的人，都是把「验证一个想法的成本」和「想法的来源」混为一谈了。
#17
@ayyazdev
https://x.com/ayyazdev/status/2102275046198690205
一个面向类型化决策的排行榜在修掉一处统计泄漏之后修订了数字，而诚实的读法是：排名前两位在统计上根本分不开——差距极小，置信区间包含零。真正扎眼的数字在榜单别处：回答模型自报的置信度正好是 0.5，也就是抛硬币。这一个数字就构成了「需要外部决策闸门」的全部论据。它给出的机制是读取最后一层隐藏状态、不输出任何 token，以一个很小的文件形式挂在模型旁边；对代理循环来说，这意味着你可以在工具调用真正执行之前就把它拦下来，而不是事后去评估损失。
https://x.com/ayyazdev/status/2102275046198690205
一个面向类型化决策的排行榜在修掉一处统计泄漏之后修订了数字，而诚实的读法是：排名前两位在统计上根本分不开——差距极小，置信区间包含零。真正扎眼的数字在榜单别处：回答模型自报的置信度正好是 0.5，也就是抛硬币。这一个数字就构成了「需要外部决策闸门」的全部论据。它给出的机制是读取最后一层隐藏状态、不输出任何 token，以一个很小的文件形式挂在模型旁边；对代理循环来说，这意味着你可以在工具调用真正执行之前就把它拦下来，而不是事后去评估损失。
#18
@SlimAssiliX
https://x.com/SlimAssiliX/status/2101989047983911309
对整个领域反复踩进去的一个度量陷阱，这是最干净的一句表述。模型变便宜时，每百万 token 的成本会下降，但当一个问题需要更多轮次才能解决时，每个已解决任务的成本会持平甚至上升——而这两个指标恰恰就在「代理循环靠拉长轮次来弥补能力差距」的地方开始脱钩。换句话说，你最需要那个便宜价格的场景，恰恰就是标价不再能预测你账单的场景。任何用「每百万 token 多少钱」来汇报代理省了多少钱的人，用的正是对代理最不成立的那个指标。
https://x.com/SlimAssiliX/status/2101989047983911309
对整个领域反复踩进去的一个度量陷阱，这是最干净的一句表述。模型变便宜时，每百万 token 的成本会下降，但当一个问题需要更多轮次才能解决时，每个已解决任务的成本会持平甚至上升——而这两个指标恰恰就在「代理循环靠拉长轮次来弥补能力差距」的地方开始脱钩。换句话说，你最需要那个便宜价格的场景，恰恰就是标价不再能预测你账单的场景。任何用「每百万 token 多少钱」来汇报代理省了多少钱的人，用的正是对代理最不成立的那个指标。
#19
@SlimAssiliX
https://x.com/SlimAssiliX/status/2102438999490953716
某厂商给更新的一档模型降价之后，这条一句话的运维提醒带出了一个更普遍的教训。任何把模型名硬编码成旧版本的代理循环，现在每一步都在多花明显的钱，因为模型字符串不会自己去重新谈判——供应商改了经济账，你的配置没改。对那些持续运行的无人值守循环来说，这是一次不会有任何报错浮现出来的静默成本回退，这也让硬编码模型标识从一个代码风格偏好，变成了一项长期存在的运维负债。
https://x.com/SlimAssiliX/status/2102438999490953716
某厂商给更新的一档模型降价之后，这条一句话的运维提醒带出了一个更普遍的教训。任何把模型名硬编码成旧版本的代理循环，现在每一步都在多花明显的钱，因为模型字符串不会自己去重新谈判——供应商改了经济账，你的配置没改。对那些持续运行的无人值守循环来说，这是一次不会有任何报错浮现出来的静默成本回退，这也让硬编码模型标识从一个代码风格偏好，变成了一项长期存在的运维负债。
#20
@TonyJZhou
https://x.com/TonyJZhou/status/2101965400393080935
一天的网关数据就把开源与闭源之争重新组织了一遍。某个开源模型占了大约 70% 的 token，却只对应约 5% 的支出；而某家闭源厂商占了约 5% 的 token，却吃掉约 48% 的支出。给出的解读是对的：token 并不等价。走量的代理循环跑在开源模型上，昂贵的那条尾巴留给闭源，钱跟着能力走而不是跟着用量走。任何拿 token 份额当市场份额来引用的人，不管往哪个方向引，引的都是错的那一列。
https://x.com/TonyJZhou/status/2101965400393080935
一天的网关数据就把开源与闭源之争重新组织了一遍。某个开源模型占了大约 70% 的 token，却只对应约 5% 的支出；而某家闭源厂商占了约 5% 的 token，却吃掉约 48% 的支出。给出的解读是对的：token 并不等价。走量的代理循环跑在开源模型上，昂贵的那条尾巴留给闭源，钱跟着能力走而不是跟着用量走。任何拿 token 份额当市场份额来引用的人，不管往哪个方向引，引的都是错的那一列。
#21
@stretchcloud
https://x.com/stretchcloud/status/2101536835415753106
一个在设计循环时值得记住的延迟数字：中位数 154 毫秒，而评测榜上排第二的模型是 860 毫秒。附带的那个论证才是有用的部分——代理循环里的延迟税大部分不是计算，而是决策开销：一次完整的模型调用被花在挑下一个执行者、做路由、或者给相关性打分上。把这部分砍掉大约五倍，外加输出 token 免费，这不是同一套架构里的改进，而是另一套架构。具体数字站不站得住另说，但把「决策开销」单列成一条预算，是给循环做性能剖析的正确姿势。
https://x.com/stretchcloud/status/2101536835415753106
一个在设计循环时值得记住的延迟数字：中位数 154 毫秒，而评测榜上排第二的模型是 860 毫秒。附带的那个论证才是有用的部分——代理循环里的延迟税大部分不是计算，而是决策开销：一次完整的模型调用被花在挑下一个执行者、做路由、或者给相关性打分上。把这部分砍掉大约五倍，外加输出 token 免费，这不是同一套架构里的改进，而是另一套架构。具体数字站不站得住另说，但把「决策开销」单列成一条预算，是给循环做性能剖析的正确姿势。
📡 生态产品雷达
生态产品雷达
类型化决策模型 —— 本轮被引用最多的单一原语，出现在路由、工具闸门、完成度判断和降延迟等场景里，还附带一份关于它在哪里失效的诚实报告。
把代理 harness 当成产品 —— 一家云厂商的开源库、某实验室的托管 harness API，以及一篇主张 harness 应该像其内部模型一样进化的论文。
消费级硬件上的本地推理栈 —— 两比特量化的 27B 模型，在 12GB 显卡上常驻 262K 上下文并跑完整的代理循环。
每个已解决任务的成本 —— 这不是产品，而是整条信息流收敛到的那个指标，并且明确是在反对"每百万 token 多少钱"。
类型化决策模型 —— 本轮被引用最多的单一原语，出现在路由、工具闸门、完成度判断和降延迟等场景里，还附带一份关于它在哪里失效的诚实报告。
把代理 harness 当成产品 —— 一家云厂商的开源库、某实验室的托管 harness API，以及一篇主张 harness 应该像其内部模型一样进化的论文。
消费级硬件上的本地推理栈 —— 两比特量化的 27B 模型，在 12GB 显卡上常驻 262K 上下文并跑完整的代理循环。
每个已解决任务的成本 —— 这不是产品，而是整条信息流收敛到的那个指标，并且明确是在反对"每百万 token 多少钱"。
评论