Twitter AI Agent - 2026-07-10¶
1. 人们在讨论什么¶
1.1 Codex 发布后的余波，让模型选择变成了路由与 UX 问题 🡕¶
7 月 10 日声量最大的一组讨论，来自 OpenAI 将 Codex 并入 ChatGPT 后的次日反馈。讨论的焦点不只是 GPT-5.6 Sol 好不好，而是默认设置、滑块、用量配额，以及用户是否应该自己知道何时该把任务路由到 Sol、Terra、Luna 或其他厂商。以下 4 条内容从不同角度提供了证据。
@danshipper 认为（737 个赞、46 条回复、121,730 次浏览、464 次收藏）表示，GPT-5.6 Sol 速度快、成本低，能力也足以跑完整个知识工作闭环，但在他的 Senior Engineer 基准测试中只拿到 56/100，而 Claude Fable 5 为 91/100。其独特之处不在意识形态，而在操作层面：他建议把 Sol 作为 Fable 的子代理，把合并后的 ChatGPT Codex 应用视为一个工作流界面，并将真正的选择表述为：哪些任务交给 Sol，哪些任务留给更强但也更挑剔的模型。
@thsottiaux 表示（1,672 个赞、356 条回复、32,372 次浏览、112 次收藏）表示，OpenAI 让用户太容易触发最高算力设置，在桌面布局里把熟悉的聊天和项目藏得太深，还让一些多代理工作流出现了回归问题。他承诺会在当天重置用量，给模型选择器加入更便宜的默认项，修复插件问题，并在下一周带来更熟悉的侧边栏和更清晰的用量可见性。
@btibor91 总结（153 个赞、12 条回复、12,881 次浏览、89 次收藏）总结了公开的 Codex AMA：大多数工作用 Sol Medium，快速的非编码任务用 Terra，子代理用 Luna，目前还没有真正的 “Auto” 模型。他的帖子还记录了团队对困难任务的建议：面对模糊 bug 和迁移任务时提高推理强度；对于高度依赖 MCP 的工作流，降低推理强度或使用 CLI 封装；同时把目标设定得更有边界，避免 Codex 过早放弃。
@nikesharora 认为（132 个赞、29 条回复、11,058 次浏览、164 次收藏）认为，企业最终仍会被卡在单一模型栈上，因为 harness 调优、评测、程序性记忆以及缓存定价都无法在不同提供方之间平滑迁移。他的独特观点是，真正的切换成本不是数据迁移，而是重新验证；这让浅层路由层适合简单任务，却很难支撑长链路代理。
讨论洞察： 回复基本都很务实：重置时间、Windows 资源占用、命名混乱，以及路由是否应该自动学会，而不是推给操作员自己处理。
与前一天的对比： 7 月 9 日讨论的是 harness 经济学。到 7 月 10 日，同一场争论已经变成了围绕默认设置、模型选择器，以及产品究竟该替用户吸收多少路由工作量的拉锯。
1.2 Harness 与循环工程开始成为一种可教授的操作模型 🡕¶
发帖者不再把 harness 工程当作圈内黑话，而是把它变成图示、循环分类、公开课程和具体的仓库模式。共同做法是，把可持续的知识从一次性提示词里拿出来，沉淀进文件、停止条件和可复用脚手架中。
@David_TornAI 梳理了（71 个赞、24 条回复、768 次浏览）梳理了从提示词工程到上下文工程，再到 harness 工程的演进，并把 harness 描述为一台负责收集、执行、验证和重试的机器。配图之所以重要，是因为它把边界讲清楚了：提示词工程是在调一个组装好的输入，上下文工程是在管理什么内容能装进上下文窗口，而 harness 工程则是用工具、记忆和验证把整个循环包起来。
@mikenevermiss 总结（32 个赞、15 条回复、1,482 次浏览、25 次收藏）介绍了官方 Claude Code 指南中的四类循环：轮次驱动、目标驱动、时间驱动和主动式。这里真正有用的证据是图片本身，因为它明确写出了每类循环何时启动、如何停止、适合什么工作，让“循环工程”从一句口号变成了一份工作流菜单。
@Divyyanshishrma 提到（72 个赞、6 条回复、1,549 次浏览）介绍了 Learn Harness Engineering；公开的 课程网站 和截图显示，这套课程围绕环境设计、状态管理、验证和控制系统，通过讲座、项目和资源库来提高 Codex 与 Claude Code 的可靠性。
@mattpocockuk 分享了（83 个赞、11 条回复、8,306 次浏览、64 次收藏）介绍了一项面向 TypeScript 代码库深层模块的技能：src/packages 下的包、通过 index.ts 建立的导入边界、隔离测试、禁止循环依赖，以及作为上下文指针的 AGENTS.md。这很好地体现了当天更广泛的趋势：人们正在把“对代理友好的结构”做成可重复使用的技能，而不是每次会话都重新解释一遍。
另一个规模较小但很具体的例子来自 @LearnWithBrij 概述（6 个赞、101 次浏览）：一个 Claude Code 项目树，其中 CLAUDE.md、钩子、技能、文档和本地规则都放在高风险模块附近。
讨论洞察： 大家的共同假设是：提示词是临时的，结构才是持久的。技能、钩子、本地规则、模块边界和显式评估器，正成为仓库的一部分，而不只是对话的一部分。
与前一天的对比： 7 月 9 日把技能当作可复用基础设施来讨论。到了 7 月 10 日，围绕这些技能文件的教学体系、循环设计和仓库布局也变得同样重要。
1.3 围绕代理的控制界面仍在持续产品化 🡕¶
最强烈的构建者动能，不是再做一个更自主的演示，而是打造那些能让代理安全地部署、发布、观测或消费结构化数据的界面。反复出现的语言包括安装块、信任门、分阶段发布、仪表盘，以及 API 或 MCP 部署。
@GithubProjects 强调了（34 个赞、1 条回复、5,609 次浏览、36 次收藏）介绍了 Langflow，151,593 星标仓库 描述的是一个带交互式 playground、多代理编排以及内置 API 和 MCP 服务器部署能力的可视化构建器。其独特之处在于，每个工作流都可以被转成其他界面可调用的工具，而不是被困在某个单一聊天产品里。
@gitlawb 发布了（123 个赞、12 条回复、3,917 次浏览）介绍了 Zero v0.3.0：一个原生终端编码代理，支持语音听写、OAuth 配置、工作区信任门和模型记忆。它的定位非常明确，是任务所有权：“You say what. It plans, edits, runs, verifies,” 这与当天更广泛的兴趣点一致——大家关注的是受治理的执行，而不是抽象的自主性。
@istdrc 开源了（9 个赞、3 条回复、1,042 次浏览、9 次收藏）介绍了 Hands；公开的 README 表示，它能在 Cloudflare Workers、D1 和 R2 上端到端跑完整个发布循环，包括草稿优先发布、分阶段 rollout、分享页，以及应用内反馈或崩溃工单。与泛泛的代理发布相比，这更能说明问题，因为它瞄准的是一个具体的运营边界：交付客户端应用。
@nyk_builderz 指向（9 个赞、120 次浏览、8 次收藏）介绍了 Mission Control，这是一个面向任务、代理集群、支出、治理和质量门的 5,704 星标的自托管编排仪表盘，并采用 SQLite 优先部署。当天这条推文的互动量不大，但仓库细节本身已足以构成一个有意义的构建者信号。
@CoinMarketCap 推出了（45 个赞、31 条回复、42,160 次浏览）介绍了 Agent Hub；公开的 产品页面 及配图才是实质内容：一站式覆盖 CEX、衍生品、链上、新闻、社交、KOL 和钱包的加密信息；预计算信号；紧凑的 Markdown 或 YAML 输出；以及可直接复制粘贴到 Claude Code、Cursor、VS Code、OpenClaw、Codex 和 Gemini CLI 中的 MCP 安装块。
讨论洞察： 共同的产品语言都围绕“受治理的行动路径”。构建者卖的是安装块、信任门、分阶段暴露和操作员仪表盘，而不是抽象的自主性。
与前一天的对比： 7 月 9 日已经抬高了操作员工作区的重要性。到 7 月 10 日，则又增加了更具体的发布、安装和治理界面，代理可以马上接入。
1.4 可审计、面向领域的评测离生产更近了一步 🡕¶
关于验证的讨论，已经从泛泛的“用评测”建议，转向了具体领域和契约层。基准测试越来越像生产验收测试：有领域任务、明确的答案契约，以及公开的通过/失败分布。
@kenbwork 介绍了（28 个赞、3 条回复、3,736 次浏览、16 次收藏）介绍了 BioSecBench-Surveillance：一个覆盖 7 类任务、6 种样本类型，并同时包含短读长与长读长测序的基准，共 100 个评估。配图之所以重要，是因为它把能力上限直接摆了出来：最佳 endpoint 通过率约 50%，大多数前沿配置都低于这一水平，异常检测只有 20% 左右，长读长数据集也比短读长更难。
@SciFi 分享了（1 个赞、110 次浏览、3 次收藏）介绍了论文 From Prompts to Contracts 及其 配套仓库。摘要异常具体：主张源边界、实体路由、答案契约和可复现轨迹，并报告了 3 个托管模型上的 270 次组合边界运行；消融实验还显示，由代码内建的约束机制保住了 120/120 的效用，而外部 guardrail 则把效用降到了 88/120。
@tom_doerr 分享了（8 个赞、1 条回复、2,609 次浏览、13 次收藏）介绍了 UCSB-AI/GEA 仓库，它把自我改进代理描述为一种带有显式经验共享的群体进化，而不是单个代理在隔离状态下自我修改。这一信号不如 Codex 讨论那么大，但与当天对学习循环可审计结构的更广泛兴趣一致。
@goose_oss 转发了（5 个赞、1 条回复、504 次浏览）介绍了一篇 AAIF 文章：一台笔记本上的 4B 本地 Gemma 模型成功驱动了本地 MCP 服务器，而同一配置下 7B 的 Hermes 函数调用模型却失败了。这里的重要启示不只是模型排名本身，而是工具调用行为和本地运行时适配性，可能比参数规模更关键。
讨论洞察： 共同模式是把可靠性推入可检查的产物：通过率表、答案契约、来源清单和工具调用证据。
与前一天的对比： 7 月 9 日聚焦外部验证器和重写循环。到 7 月 10 日，这些想法已经被推进到基因组监测、企业答案契约和本地 MCP 工具调用实验中。
2. 人们因为什么而感到挫败¶
用户仍然得自己充当模型与推理路由器¶
高严重度。@thsottiaux 承认（1,672 个赞、356 条回复、32,372 次浏览、112 次收藏）表示，OpenAI 让最高算力设置过于容易被触发，却又弱化了其对用量限制的影响；与此同时，@btibor91 记录了（153 个赞、12 条回复、12,881 次浏览、89 次收藏）提到的一场 AMA 中，仍然没有真正的 Auto 模型，用户必须根据任务在 Sol、Terra、Luna 和不同推理等级之间自行选择。@danshipper 展示了（737 个赞、46 条回复、121,730 次浏览、464 次收藏）说明了这为什么重要：Sol 足以胜任很多循环，但在他的基准测试里，Fable 在最难的编码工作上仍然明显领先。人们目前的应对方式，是用子代理模式、面向 MCP 密集型流程的低推理封装，以及大量手动试验。之所以值得围绕这一点构建产品，是因为同样的路由痛点，同时出现在厂商道歉、公开 AMA 和独立实践者测试里。
Harness 可移植性与切换成本依旧脆弱¶
高严重度。@nikesharora 认为（132 个赞、29 条回复、11,058 次浏览、164 次收藏）认为，真正形成锁定的不是模型权重，而是 harness、评测、程序性记忆，以及不同提供方各自的缓存定价。@dr_cintas 展示了（337 个赞、30 条回复、30,943 次浏览、495 次收藏）提供了一个折中办法：把规划和审查放在 Claude Fable 5 上，把实现量压给 Grok 4.5。@KBlueleaf 声称（8 个赞、1 条回复、531 次浏览）则表示，在相近 token 总量下，他自己的框架只消耗了 Codex 周额度的大约二分之一到三分之一，这再次说明底层基座开销很重要。团队现在的应对方式包括自定义路由、按模型定制技能，以及手动重新验证。之所以值得围绕这一点构建产品，是因为切换成本在表现为模型质量问题之前，首先已经表现为 harness 问题。
高判断负载的领域工作仍会让代理失灵¶
高严重度。@kenbwork 报道（28 个赞、3 条回复、3,736 次浏览、16 次收藏）指出，在不同模型—harness 组合中，BioSecBench-Surveillance 的通过率大约在 14% 到 50% 之间；异常检测约为 20%，长读长数据集为 26%，而短读长为 41%。失败模式不只是找不到工具，而是卡在对阈值、参考、归一化和结果解释的科学判断上。@goose_oss 转发了（5 个赞、1 条回复、504 次浏览）还提到一项本地测试：一个 7B 函数调用模型没能执行一个 MCP 工作流，而 4B 模型却完成了。人们目前的应对方式，是缩小范围、加强验证器，以及采用工具优先架构。之所以值得围绕这一点构建产品，是因为“能调用工具”和“能做出正确判断”之间，依然有很大鸿沟。
仓库原生结构仍主要靠手工搭建¶
中等严重度，且在上升。@mattpocockuk 分享了（83 个赞、11 条回复、8,306 次浏览、64 次收藏）介绍了一项深层模块技能，专门用于在 TypeScript 仓库中强制维持清晰边界；@Divyyanshishrma 指出（72 个赞、6 条回复、1,549 次浏览）则指向一整套公开的 harness 工程课程；@LearnWithBrij 认为（6 个赞、101 次浏览）说明，编码代理仓库需要在高风险模块附近配好 CLAUDE.md、技能、钩子、文档和本地规则。今天的应对策略，仍是手工围绕模型搭项目记忆和护栏。之所以值得围绕这一点构建产品，是因为需求是真实的，但现在的搭建方式依然像定制化的仓库木工活。
3. 人们希望有什么¶
自动路由与感知用量的默认设置¶
这一需求非常明确。@btibor91 总结（153 个赞、12 条回复、12,881 次浏览、89 次收藏）提到一场 Codex AMA，其中仍没有 Auto 模型；@thsottiaux 表示（1,672 个赞、356 条回复、32,372 次浏览、112 次收藏）指出，默认设置把用户推向了不必要的高成本选项；@nikesharora 认为（132 个赞、29 条回复、11,058 次浏览、164 次收藏）则认为，路由必须结合真实流量和验证成本来学习。人们显然想要的是一个策略层：自动决定模型档位、推理深度和停止条件，而不是把每个操作员都逼成路由专家。机会评级：[+++] 直接。
面向编码代理的仓库原生脚手架¶
反复出现的愿望不是更聪明的提示词，而是一种可重复的项目形状。@mattpocockuk 提出（83 个赞、11 条回复、8,306 次浏览、64 次收藏）介绍了可复用的深层模块技能；@LearnWithBrij 概述了（6 个赞、101 次浏览）展示了一个包含 CLAUDE.md、钩子、技能、文档和本地规则的仓库布局；@Divyyanshishrma 指出（72 个赞、6 条回复、1,549 次浏览）则指向一整套教授如何把这些 harness 搭好的课程。实际需求，是一套覆盖记忆、钩子、边界和可复用工作流的起步系统，让团队无需从零发明。机会评级：[++] 直接。
面向企业与受监管工作流的契约驱动审计层¶
这一需求同时出现在研究与生产语境中。@SciFi 分享了（1 个赞、110 次浏览、3 次收藏）介绍了一篇主张源边界、实体路由、答案契约和可复现轨迹的论文；@kenbwork 发布了（28 个赞、3 条回复、3,736 次浏览、16 次收藏）给出了基因组监测这一领域的具体通过率证据；gokulrajaram/ProductSpec 则在产品意图控制文件之上加入了 Decision Trace。人们想要的似乎不只是“更好的评测”，而是由代码持有的契约，能够跨模型替换、领域复杂性和审计要求继续成立。机会评级：[+++] 直接。
面向代理的发布、数据与资金底座¶
有几条帖子，本质上都在呼唤代理行动周边的可靠轨道。@istdrc 开源了（9 个赞、3 条回复、1,042 次浏览、9 次收藏）提到了用于发布运营的 Hands；@CoinMarketCap 推出了（45 个赞、31 条回复、42,160 次浏览）提到了一个支持 MCP 的市场数据中心；@jerallaire 将其定义为（504 个赞、69 条回复、27,403 次浏览）则提到 Circle 获得 OCC 批准，作为 AI 代理彼此支付的基础设施。大家希望的是代理能直接使用的发布、数据和支付轨道，不必靠定制胶水代码，也不丢失操作员控制。机会评级：[++] 直接。
优先工具可靠性而非模型规模的本地优先 MCP 技术栈¶
最清晰的信号，并不来自一条大爆款帖子，而是来自一位实践者的结果。@goose_oss 分享了（5 个赞、1 条回复、504 次浏览）介绍了一篇文章：一个 4B 本地模型成功完成本地 MCP 任务，而一个 7B 函数调用模型却失败了；与此同时，ai4s-research/open-science 将 Open Science Desktop 定位为本地优先、模型无关的研究工作台。实际需求，是一套本地栈，在这里工具调用、来源可追溯性和隐私，比追求设备能塞下的最大模型更重要。机会评级：[+] 新兴。
4. 正在使用的工具与方法¶
| 工具 | 类别 | 情绪 | 优势 | 局限 |
|---|---|---|---|---|
| GPT-5.6 Sol + ChatGPT Codex | 模型与代理工作区 | (+/-) | 速度快；比 Fable 更便宜；写作能力强；适合完整知识工作闭环；UI 持续改进 | 用户仍需自己选择档位和推理等级；限制与重置可见性造成困惑；较难的编码任务仍落后于 Fable |
| Claude Fable 5 | 前沿模型 | (+/-) | 高端代码质量更干净；适合承担规划者/审查者角色；适配混合工作流 | 更贵；更难用好；常与更便宜的执行模型搭配 |
| 通过 Fable Advisor 使用 Grok 4.5 | 混合编码工作流 | (+) | 在 Fable 审查下适合承担大规模实现；可打开文件做路由微调；支持并行执行 spec | 需要插件和 CLI 配置；跨厂商交接仍可能脆弱 |
| Learn Harness Engineering | 课程与参考资料 | (+) | 提供围绕可靠 Codex 与 Claude Code harness 的公开讲座、项目和资源库 | 更像参考资料，不是交钥匙产品；早期术语仍需向新人翻译 |
| ProductSpec | 意图规范标准 | (+) | 在代理交接中保留问题、范围、验收标准与 Decision Trace；已有验证器和 GitHub Action | 仍处于早期采用阶段；团队需要改变写 spec 的习惯才能获得价值 |
| Langflow | 工作流构建器 | (+) | 可视化编排；交互式 playground；可将流程部署为 API 或 MCP 服务器；支持多代理编排 | 平台面比轻量库更大；并非每个团队都需要构建器 UI |
| Mission Control | 编排仪表盘 | (+) | 自托管任务、支出、治理、质量门和技能管理；采用 SQLite 优先部署 | Alpha 软件；新增一个需要运行和保护的控制平面 |
| Hands | 发布平台 | (+) | 草稿优先发布、分阶段 rollout、分享页，以及已发布应用的反馈/崩溃闭环 | 范围比通用代理平台更窄；聚焦客户端应用发布运营 |
| KohakuTerrarium | 代理框架 | (+) | 提供可复用底座，涵盖工具、子代理、持久会话、TUI 与 Web UI | 又是一套需要学习的框架；更适合需要新代理形态的团队，而不是已有产品已够用的场景 |
| Goose 本地推理 + MCP | 本地栈 | (+/-) | 模型、工具和 MCP 服务器都放在同一台笔记本上；隐私姿态强；适合工具优先工作流 | 工具调用质量对模型很敏感；更大的模型不会自动表现更好 |
| CoinMarketCap Agent Hub | 数据与信号中心 | (+/-) | 统一加密市场覆盖；预计算信号；紧凑、面向代理的输出；支持 MCP 的安装路径 | 只适用于加密领域；价值取决于操作员对市场数据的需求以及对供应商的依赖程度 |
总体来看，满意度跨度最大的，不是单个工具，而是模型与 harness 的组合。GPT-5.6 Sol 因速度和价格收获好评，但 Fable 依旧占据最难编码工作的“声望位”，这也是为什么混合式规划者—执行者配置不断出现。同样的模式也出现在本地栈讨论中：当工具调用更匹配时，较小的本地模型也能胜过较大的模型。
最常见的变通办法，是把逻辑从提示词挪进结构。技能、钩子、本地规则、Decision Trace、API 或 MCP 部署，以及分阶段发布控制，本质上都在做同一件事：降低系统对某一次完美补全的依赖。因此，迁移压力流动的方向，也不再主要是从一个模型厂商切到另一个厂商，而是从临时拼凑的聊天式工作流，转向把路由、验证、治理和可复用上下文做成一等能力的产品。
5. 人们正在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| Zero v0.3.0 | @gitlawb | 原生终端自主编码代理，可规划、编辑、运行并验证任务 | 为独立开发者提供一个带信任门、真正接管任务的代理界面，而不是又一个聊天框 | Grok 4.5；语音听写；OAuth 配置；工作区信任门；模型记忆 | Beta | 推文 |
| Langflow | langflow-ai | 可部署为 API 或 MCP 服务器的 AI 工作流可视化构建器 | 将代理工作流转成可复用服务与供其他客户端调用的工具 | Python；可视化构建器；交互式 playground；API 部署；MCP 服务器部署 | Shipped | 推文, 仓库 |
| ProductSpec | gokulrajaram | 面向实现前软件意图的开放标准，支持 Decision Trace 和代理技能 | 在人与代理交接过程中保留意图，避免 spec 消失在聊天或工单里 | Markdown；验证器；GitHub Action；可安装的代理技能 | Beta | 推文, 仓库 |
| Hands | botiverse | 面向客户端应用的代理原生发布平台 | 打通从草稿构建、上线到反馈/崩溃分诊的完整闭环 | Cloudflare Workers；D1；R2；Android/iOS/HarmonyOS/Electron SDK | Beta | 推文, 仓库, 网站 |
| Mission Control | builderz-labs | 面向代理集群的自托管编排仪表盘 | 集中管理任务、支出、治理、质量门和可观测性 | Next.js；SQLite；WebSocket/SSE；技能注册表 | Alpha | 推文, 仓库 |
| KohakuTerrarium | Kohaku-Lab | 用于构建与组合代理的通用框架和应用 | 避免团队为每个新代理重复搭建控制器、工具、子代理和会话底座 | Python；工具；子代理；持久会话；TUI；Web UI | Beta | 推文, 仓库 |
| Open Science Desktop | ai4s-research | 本地优先的 AI 研究工作台，在一个可审计流程里完成探索、实验与写作 | 给研究代理提供来源可追溯性、可复现性和本地控制，而不是松散的聊天输出 | Tauri；React；MCP；代理技能；OpenCode runtime | Beta | 推文, 仓库 |
| CoinMarketCap Agent Hub | @CoinMarketCap | 面向代理的加密数据与信号中心，支持 MCP 就绪接入 | 去掉定制化数据管道，让代理能快速消费结构化市场信号 | 实时 API；事件触发器；200+ 个实时技能；Markdown/YAML 输出；MCP 就绪安装块 | Shipped | 推文, 页面 |
| BioSecBench-Surveillance | @kenbwork | 面向基因组监测代理的可验证基准 | 衡量代理是否能做出影响工作流的科学决策，而不只是会调用工具 | 100 个评测；测序数据任务；16 种模型—harness 配置 | Alpha | 推文 |
主导性的构建模式，是在现有模型外再加一层控制层。Langflow 把工作流变成可部署的 API 和 MCP 工具，Mission Control 增加仪表盘和质量门，Hands 增加 rollout 与发布后闭环，ProductSpec 则在代码上游加入意图契约。共同点不是“更多自主性”，而是围绕自主性建立更耐久的结构。
第二种模式，是提供可复用底座，而不是一次性代理。Zero 封装的是一个接管任务的终端代理；KohakuTerrarium 封装的则是构建 creature、子代理和会话所需的底层机制。Open Science Desktop 则把同样的思路用于研究场景，在本地把运行、产物、笔记本和来源串联起来。
第三种模式，是数据与评测轨道。CoinMarketCap Agent Hub 提供可直接接入代理的市场数据和可复制粘贴的 MCP onboarding；BioSecBench-Surveillance 则把真实科学工作流转成一个基准，明确暴露出当前代理仍会失败的地方。
6. 新内容与值得关注的事项¶
BioSecBench-Surveillance 让科学代理的能力上限变得可见¶
它之所以值得关注，不只是因为又多了一个基准，而是因为它揭示了失败的形状。@kenbwork 发布了（28 个赞、3 条回复、3,736 次浏览、16 次收藏）介绍了一个监测基准：当前模型—harness 组合的 endpoint 通过率上限约为 50%，尤其在异常检测和长读长数据上吃力。这为代理讨论提供了一项特定领域的压力测试，而不是又一个通用编码分数。
“从提示词到契约”的论文把可审计性落成了具体架构¶
@SciFi 提到（1 个赞、110 次浏览、3 次收藏）介绍了 From Prompts to Contracts。它之所以重要，在于它把 harness 这套主张变成了可测量的内容：源边界、实体路由、答案契约、可复现轨迹、270 次组合边界运行，以及 harness 与外部 guardrail 之间明确的效用对比。这是本数据集中最清晰的公开尝试之一：把可审计性从愿景，落到有名字的产物和验收测试上。
本地优先研究与 MCP 工作台拿出了具体的公开证据¶
本地优先这条支线的生态，比平时更强。Open Science Desktop 的 README 表示，它在 ResearchClawBench 上排名第 1，同时把探索、实验、来源和写作打包进一个桌面闭环；@goose_oss 转发了（5 个赞、1 条回复、504 次浏览）则提到一项测试：较小的本地模型在一个真实 MCP 任务上胜过了更大的模型。这里值得注意的信号是，本地优先构建者现在拿出来的是基准排名和具体工具调用结果，而不只是隐私口号。
7. 机会在哪里¶
**+++］ 自动路由与使用治理层** — ［@thsottiaux、@btibor91、@danshipper 和 @nikesharora 都指向同一个缺失层：自动决定模型档位、推理深度和停止条件，同时把支出展示得足够清楚，让用户愿意信任默认设置。这是一个强机会，因为同一天里，厂商沟通、实践者基准和用户回复都出现了同样的痛点。
**+++］ 基于契约的审计与评估 harness** — ［@kenbwork、@SciFi 和 ProductSpec 都把可靠性视为必须编码进契约、验证产物或持久轨迹中的东西。这是一个强机会，因为这种需求同时横跨受监管的企业答案场景与高判断负载的科学工作流。
**++］ 仓库脚手架与持久化项目记忆** — ［@mattpocockuk、@LearnWithBrij 和 @Divyyanshishrma 展现出对起步系统的现实需求：把技能、钩子、本地规则、模块边界和项目记忆打包成团队可以快速采用的东西。这是一个中等机会，因为会有很多变体竞争，但需求已经明确浮现。
**++］ 面向发布、数据与支付的 agent 运行底座** — ［Hands、CoinMarketCap Agent Hub 和 @jerallaire 都暴露出同一条鸿沟：推理与行动之间的断层。这是一个中等机会，因为需求很具体，但每一条轨道都带着合规、厂商和信任约束，限制了可进入的空间。
**+］ 本地优先的工具调用栈** — ［@goose_oss、KohakuTerrarium 和 Open Science Desktop 表明，一个新兴机会正在形成：构建更看重来源、隐私和工具可靠性，而不是纯粹模型规模的系统。这仍是新兴机会，因为公开证据虽有希望，但还早、也仍属小众。
8. 要点¶
- 发布日的 UX 问题，如今是路由问题，而不是原始智能问题。 OpenAI 自己的后续说明也承认，默认设置和用量可见性把用户推向了昂贵选项，而公开 AMA 仍要求用户按任务自己选择模型档位和推理等级。（来源）
- Harness 工程正借助图示、循环设计和课程，变成一门正式学科。 当天最有力的教育材料，不是泛泛的提示词技巧，而是明确的“收集—执行—验证—重试”图、循环分类和公开 harness 课程。（来源）
- 真正吸引注意力的产品，是围绕代理构建的控制界面，而不只是代理本身。 Langflow、Hands、Mission Control、Zero 和 CoinMarketCap Agent Hub 所卖的，更多是受治理的执行、部署或数据接入，而不是抽象的自主性。（来源）
- 面向具体领域的评测，仍在暴露巨大的判断鸿沟。 在 BioSecBench-Surveillance 中，前沿代理栈的 endpoint 通过率往往低于 50%，在开放式科学判断上尤其吃力。（来源）
- 可审计契约与本地优先栈，是目前建立信任最清晰的两种回答。 一条讨论把答案契约、轨迹和模型替换验证推进为代码持有的产物，另一条则显示：因为工具调用更匹配，一个较小模型也能成功跑通完整的本地 MCP 闭环。（来源）