Twitter AI Agent - 2026-06-09¶
1. 大家在讨论什么¶
1.1 Harness engineering 从口号走向补齐失败闭环的基础设施 🡕¶
6 月 9 日最突出的主题，是 harness engineering 变得更具体了：讨论从泛泛而谈的“要循环，不要提示词”，转向了 verifier 设计、中断处理，以及可自我改进的 harness。4 条入选内容共同支撑了这一主题，而且都把 harness 视为可靠性的核心承载面，而不是包在模型外的一层薄壳。
@akshay_pachaar 认为（207 个赞，39 条回复，19,751 次浏览，263 次收藏）表示，无人值守的循环并不会消除调试；它只是把调试转移到了没人盯着的运行过程中。这意味着，只有在 checker 值得信任时，循环才有价值。配图把这一点说得更具体：它对比了手动阅读 trace 的工作流，与一种能自我闭环的循环——后者会把失败转化为根因分析、建议的 diff、重新运行，以及锁定后的回归测试。
@HowToAI_ 将其定义为（210 个赞，20 条回复，10,123 次浏览，211 次收藏）将 Illinois、Meta 和 Stanford 的最新综述概括为“Code as Agent Harness”，认为代码正在成为 agent 系统的记忆、环境与边界，而不再只是其最终输出。Code as Agent Harness 的论文仓库称，这个领域正围绕 harness interfaces、harness mechanisms 和 scaling the harness 逐步形成体系。这也呼应了当天的变化：讨论重点正从提示词措辞，转向可执行、可验证的脚手架。
@omarsar0 分享了（76 个赞，10 条回复，4,033 次浏览，107 次收藏）介绍了新的 Self-Harness 论文。这项工作把提示词、工具和控制流视为一种可学习的产物，而不是一套需要人工维护的脚手架。图片中的预印本页面写道，这个循环由 weakness mining、harness proposal 和 proposal validation 组成，并报告称在三类基础模型家族上，留出集通过率都有提升。
@threepointone 发布了（49 个赞，4 条回复，2,905 次浏览，37 次收藏）展示了一个“harness reliability engineering”状态机，映射了 RetryTurn、ParkForHuman、PreserveResult、RepairTranscript 和 ReattachChild 等中断结果。这张图之所以重要，是因为它把可靠性工作转化成了明确的运行时状态迁移，而不是停留在模糊建议上。
讨论洞察： 一个有价值的反驳是：循环依然会静默失败，除非循环之外有东西能发现问题并补上闭环。在 Akshay 那条帖子的回复里，大家强调调试从未消失；系统只是让“调试发生在哪里”这件事变得更复杂了。
与前一天对比： 6 月 8 日让“loop engineering”成了主流说法；而 6 月 9 日则通过 verifier、自我改进的 harness 和中断状态设计，让这个词有了更具体的内涵。
1.2 Claude Fable 5 把模型质量之争变成了路由与编排之争 🡕¶
第二个主要话题簇是 Anthropic 发布 Claude Fable 5，但真正有意思的并不只是对基准成绩的追捧。3 条入选内容共同支撑了这一主题，它们合在一起，把这次发布变成了一场关于何时使用前沿智能、何时下放任务，以及该由谁来路由工作的运营讨论。
@kimmonismus 总结了（628 个赞，35 条回复，63,043 次浏览，132 次收藏）称 Fable 5 在软件工程、知识工作、视觉和科学研究方面都达到了 state-of-the-art。配图中的 benchmark 表格则给出了发布日的 headline 数字：Claude Mythos 5 / Fable 5 在 SWE-Bench Pro 上为 80.3%，在 FrontierCode Diamond 上为 29.3%，在 Terminal-Bench 2.1 上为 88.0%。另一张图则按 effort level 对比了成本与准确率，让这种权衡本身也成为讨论的一部分。
@JJEnglert 评测了（161 个赞，17 条回复，28,936 次浏览，226 次收藏）从非工程师操作员的视角评价了这个模型——他已经在真实工作中消耗了大约 10 亿 token。他的帖子说，Fable 找到了 Claude 4.8 和 GPT-5.5 都漏掉的一个严重 bug；但同一篇内容也明确提出了控制问题：他希望有一个 auto-router，能在简单工作上自动降档，只把真正值得这笔成本的任务升级给 Fable。
@ClaudeDevs 展示了（107 个赞，1 条回复，33,449 次浏览，27 次收藏）显示，这次发布立刻被封装进了一种 manager-worker 模式：一个运行在 Claude Fable 5 上的协调 agent，把代码审查和测试编写委派给更小的 agent。这张截图之所以重要，是因为它把“底层使用更小模型”从模糊策略变成了具体代码。
讨论洞察： 最重要的细节来自 benchmark 帖和评测帖下的回复：一些实践者预计，最大的收益主要会出现在更长的任务和更大的代码库上；即便是看多的用户，也仍在描述手动路由，而不是相信一个模型就能包打天下。
与前一天对比： 6 月 8 日已经把模型选择框定为一个路由问题；6 月 9 日则补上了 benchmark 截图、操作员经济性，以及 coordinator 代码片段，把这个论点变成了发布日当天的实践。
1.3 工作流界面、技能和交付 harness 继续被封装成产品 🡕¶
第三个主题是封装。5 条入选内容共同支撑了这一点，而且都在把方向从独立聊天壳转向更持久的工作界面：桌面 runtime、可复用工作流模板、可移植技能，以及交付 harness。
@karrisaarinen 写道（121 个赞，15 条回复，8,585 次浏览，71 次收藏）表示，他想要一个 agent 工作流工具，能够描述工作项、分派任务、审查代码 diff、支持多人协作、收集客户上下文、定义共享技能和 MCP servers，并能从 Slack 运行。这条帖子是当天最清晰的一份第一人称产品需求清单，描述了一个 agent 控制平面应具备什么。
@ollama 宣布了（213 个赞，14 条回复，9,331 次浏览，99 次收藏）称 Hermes Desktop 现在只需一条命令就能通过 Ollama 运行。Hermes 文档 和 Hermes Agent 仓库 描述的是同一种封装动作：桌面安装器、20 多个消息入口、定时自动化、MCP 支持、隔离的 subagents，以及内置学习循环。
@tonbistudio 分享了（39 个赞，2 条回复，3,006 次浏览，49 次收藏）介绍了一个开源的 Hermes 多智能体工作流 模板，其 README 给出了一套固定结构：接收、去重、评分、并行研究、路由、一个人工关卡，以及履约。@Coo_Lxing 推出了（16 个赞，853 次浏览，15 次收藏）则把 Loom 描述为一个交付 harness，用于规划、验证、修复、预览和交接，并且能在中断和压缩后延续下去。
@twostraws 分享了（98 个赞，4 条回复，3,095 次浏览，20 次收藏）表示，Xcode 收录了他的一个 agent skill，而 Swift Testing Agent Skill 仓库 展示了它在 Xcode、Claude Code、Codex、Cursor 和 Gemini 上的安装路径。@LangChain 添加了（15 个赞，2 条回复，1,780 次浏览，12 次收藏）则通过 解释器技能 又加了一层：skill 可以附带一个 TypeScript module，由 runtime 导入并执行。
讨论洞察： 大家的共同诉求并不是“给我一个更聪明的聊天框”，而是“给我一个能持久保存计划、技能、工具、上下文、验证和交接的地方”。
与前一天对比： 6 月 8 日已经出现了 Slack、Xcode 和部署栈里的技能；而 6 月 9 日则把这种封装扩展到了桌面 runtime、可执行技能、可复用分流模板和交付 harness。
2. 什么让人沮丧¶
无人值守循环中的静默失败¶
严重程度：高。@akshay_pachaar 认为（207 个赞，39 条回复，19,751 次浏览，263 次收藏）表示，无人值守循环只有在 checker 值得信任时才有帮助，否则人还是得回去手工读 trace。@threepointone 发布了（49 个赞，4 条回复，2,905 次浏览，37 次收藏）展示了一个布满中断分支的状态机，说明大量失败处理都发生在 happy path 之外。Loom README 则直接点出了同样的问题：部分完成、目标漂移、自检偏差、token 浪费，以及交接缺口。人们的应对方式，是构建修复循环、人工停靠状态和回归锁。之所以值得围绕这一点构建产品，是因为信息流把静默失败视为基础设施债务，而不是用户操作失误。
长时运行的 agent 工作仍缺少持久的控制平面¶
严重程度：高。@karrisaarinen 写道（121 个赞，15 条回复，8,585 次浏览，71 次收藏）列出了一份工作流工具需求清单，覆盖计划、任务分派、diff 审查、多人协作、共享技能、共享 MCP servers，以及 Slack 原生运行。Hermes 多智能体工作流 模板和 Loom 都在填补这一缺口的部分内容，提供单人工关卡路由、持久化任务状态和交付证据，但两者都更像可改造的结构，而不是开箱即用的控制平面。当前的替代方案是模板、看板和自定义 harness。这个需求看起来很强，因为抱怨集中在连续性、可检查性和共享上下文，而不是模型本身的智能水平。
手动路由仍是前沿模型性能的“税”¶
严重程度：高。@JJEnglert 评测了（161 个赞，17 条回复，28,936 次浏览，226 次收藏）认为 Claude Fable 5 值得花在困难工作上，但也明确表示需要一个 auto-router，把前沿级推理留给真正值得的任务。@ClaudeDevs 展示了（107 个赞，1 条回复，33,449 次浏览，27 次收藏）展示了一种替代做法：把子任务委派给更小的 agent；而对 @kimmonismus 总结（628 个赞，35 条回复，63,043 次浏览，132 次收藏）Fable 5 的回复则说，这些提升可能在更大的代码库和更长时间运行中才最明显。当前的替代方案，是在前沿规划器和更便宜执行器之间手工搭 relay。之所以值得围绕这一点构建产品，是因为价值已经很明显，但路由逻辑仍主要存在于操作员的判断中。
MCP 和企业工具暴露范围默认仍显得过宽¶
严重程度：中。@saketsaurabh 发布了（98 个赞，10 条回复，3,357 次浏览，14 次收藏）讨论了 MCP Studio，并提出一个观点：每个应用一个 MCP server，会带来太多工具、太多 token，以及太多治理问题。他的帖子说，真实的企业任务通常横跨 Salesforce、Snowflake、NetSuite、ServiceNow、Workday 和内部系统，因此把每个应用都镜像进同一个工具堆，会给生产环境使用带来压力。当前的替代方案是手工筛选工具，或做任务级配置。之所以值得围绕这一点构建产品，是因为问题出在范围控制和治理，而不是功能不全。
3. 大家希望出现什么¶
一个用于计划、diff、上下文和团队协作的共享工作流层¶
这是 6 月 9 日最清晰、最直接的需求。@karrisaarinen 写道（121 个赞，15 条回复，8,585 次浏览，71 次收藏）表示，他想要一个工具，能描述工作项、给 agent 分派任务、审查 diff、支持多人协作、收集客户上下文、定义共享技能和 MCP servers，并从 Slack 运行。Hermes 多智能体工作流 和 Loom 这两个仓库如今提供的是部分答案，但它们都仍然假设用户会按自己的流程去改造结构。机会：直接。
在前沿规划器与低成本执行者之间自动路由¶
这是一个紧迫而偏运营的问题。@JJEnglert 评测了（161 个赞，17 条回复，28,936 次浏览，226 次收藏）对 Fable 5 评价积极，但仍要求有一个 auto-router，能在简单工作上自动降档，只有当任务值得前沿级成本时才升级。@ClaudeDevs 展示了（107 个赞，1 条回复，33,449 次浏览，27 次收藏）说明，手动版其实已经通过 coordinator-plus-subagent 编排在发生；而 @kimmonismus 总结了（628 个赞，35 条回复，63,043 次浏览，132 次收藏）则给出了足以让路由决策在经济上变得有意义的 benchmark 提升。机会：直接。
能扛住中断、压缩和交接的交付 harness¶
这是一种务实需求，而不是愿景式诉求。@Coo_Lxing 推出了（16 个赞，853 次浏览，15 次收藏）把 Loom 描述为一个用于规划、验证、修复、预览和交接的交付 harness，而其仓库则写明目标是保留项目上下文、测试结果、修复记录、预览证据和交付报告，让下一次会话或下一个 agent 无需从头开始即可继续。@akshay_pachaar 认为（207 个赞，39 条回复，19,751 次浏览，263 次收藏）表示，补齐失败闭环的逻辑必须被显式构建；而 @threepointone 发布了（49 个赞，4 条回复，2,905 次浏览，37 次收藏）则给出了同一问题的中断状态视角。机会：直接。
能携带可执行行为而不只是说明文字的可移植技能¶
这个需求看起来竞争会比较激烈，但确实存在。@twostraws 分享了（98 个赞，4 条回复，3,095 次浏览，20 次收藏）展示了一种 skill，可安装到 Xcode 和其他 coding agents 上，而 Swift Testing Agent Skill 仓库 则直接记录了这些跨界面的安装路径。@LangChain 添加了（15 个赞，2 条回复，1,780 次浏览，12 次收藏）讨论了 解释器技能，其中 SKILL.md 会随附一个 TypeScript module，供解释器导入并运行。这两个例子背后的诉求很明确：可复用的 skill packages 应该可执行、可移植、可版本化。机会：竞争型。
4. 正在使用的工具与方法¶
| 工具 | 类别 | 情绪 | 优势 | 局限 |
|---|---|---|---|---|
| Harness engineering / 自闭环循环 | 方法 | (+) | 能把 trace 转化为根因分析、重跑和回归锁 | 仍然依赖可信 checker 和显式失败处理 |
| Code as Agent Harness | 研究 / 设计模式 | (+) | 把代码视为可执行记忆、环境和验证底座 | 更偏研究框架，而非开箱即用产品 |
| Claude Fable 5 | 前沿 LLM | (+/-) | 在编码和长时程工作上 benchmark 表现强，能发现其他模型漏掉的问题 | token 成本依然高，路由仍需手工处理 |
| Claude Managed Agents pattern | 多 agent 编排 | (+) | 允许前沿 coordinator 把审查和测试编写委派给更小的 agent | 如何拆分 agent、如何路由任务仍依赖操作员判断 |
| Hermes Desktop + Ollama | 桌面 runtime | (+) | 对本地友好的 GUI、subagents、skills、消息集成、MCP 支持 | 产品复杂度高于单终端编码工作流 |
| Hermes multi-agent workflow | 编排模板 | (+) | 为团队提供可复用的“接收—研究—人工关卡”流水线 | 只是模板；仍需领域适配和运维配置 |
| Loom | 交付 harness | (+) | 持久化上下文、验证证据、修复记录、预览检查和交接状态 | 项目尚早，小型一次性修改会有额外流程开销 |
| LangChain interpreter skills | 技能封装 | (+) | 给 skill 增加可执行的 TypeScript module，以复用行为 | 需要解释器支持和有意识的暴露控制 |
| Swift Testing Agent Skill | Agent skill | (+) | 为 Xcode 和多个 coding agents 封装高信号的 Swift Testing 指导 | 领域较窄；价值取决于团队是否已经在使用 skills |
| MCP Studio | 工具网关 / MCP | (+/-) | 围绕任务收窄工具范围，而不是把每个 app 都镜像进一个 server | 仍需证明在复杂企业栈中的治理与可用性 |
| Cantrip | Agent runtime | (+/-) | 显式边界、可回放 looms、子组合和 ACP 支持 | 新的 runtime 概念可能很强，但也增加采用摩擦 |
整体满意度分布非常务实。大家更热衷于那些让 agent 更可检查、可恢复、可封装的方法和产品，而不只是“更自主”。主要迁移模式是：把前沿模型留在规划或审查层，把有边界的工作下推给更小的 worker 或可复用工作流，并把长时程连续性放进 harness、skills 或桌面 runtime 中（@JJEnglert 评测了（161 个赞，17 条回复，28,936 次浏览，226 次收藏）；@ClaudeDevs 展示了（107 个赞，1 条回复，33,449 次浏览，27 次收藏）；Hermes 文档；Loom；Hermes 多智能体工作流）。竞争态势正在转向：谁能围绕模型做出最好的控制层。
5. 大家在构建什么¶
| 项目 | 构建者 | 作用 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| Hermes multi-agent workflow | @tonbistudio | 可复用的自主分流流水线，包含接收、去重、评分、并行研究、路由、单人工关卡和履约 | 为团队提供一个具体的编排骨架，而不是从零发明工作流 | Python、YAML triage.yaml、Hermes Kanban |
已发布 | 仓库，推文 |
| Loom | @Coo_Lxing | 面向 coding agents 的开源交付 harness，包含规划、验证、修复、预览和交接状态 | 让长时运行的交付工作在中断、压缩和交接过程中仍能保持对齐 | agent-neutral CLI、动态工作流、持久化 .loom/ 状态 |
Alpha | 仓库，推文 |
| Hermes Desktop | Nous Research | Hermes Agent 的桌面界面，支持本地或云端模型、subagents、skills 和消息集成 | 把一个可自我改进的 agent runtime 封装进 GUI 和适合本地的安装流程 | 桌面应用、Hermes Agent runtime、Ollama、MCP、subagents | 已发布 | 文档，仓库，推文 |
| Swift Testing Agent Skill | @twostraws | 面向 Xcode 和 coding agents 的可移植 skill，用于编写和改进 Swift 测试 | 将领域专长封装成可安装的 skill，而不是每次重复写提示词说明 | Swift skill package、Xcode plug-ins、Claude Code/Codex/Cursor/Gemini 安装 | 已发布 | 仓库，推文 |
| Cantrip | deepfates | 一个 Elixir agent runtime，围绕 circles、media、gates、wards、looms 和 child composition 组织 | 为 agent 构建者提供显式边界、可回放能力、持久状态和 ACP 访问 | Elixir、OTP processes、JSONL/Mnesia loom storage、ACP | Alpha | 仓库，推文 |
| MCP Studio | @saketsaurabh | 面向任务的 MCP 层，目标是把跨系统完成一项工作所需的正确工具组合起来 | 减少每应用一个 server 的 MCP 方案带来的工具泛滥、token 开销和治理问题 | MCP、企业 SaaS 连接器、任务级工具路由 | Beta | 推文 |
共同的构建模式并不是“一个 agent 统治一切”，而是“把协调层外置”。Hermes multi-agent workflow 和 Loom 都把 agent 工作变成了带有显式关卡的分阶段交付流程；而 Hermes Desktop 和 Cantrip 则把记忆、委派和 runtime 边界封装成可复用界面。
Swift Testing Agent Skill 和 LangChain 的 interpreter-skills 方向则指向另一种反复出现的模式：专长正被打包成可移植模块。这一点很重要，因为信息流持续奖励那些让行为变得可安装、可审查、可复用的项目，而不是每次运行都重新解释一遍。
MCP Studio 从企业侧也符合这一趋势。它不主张暴露每个系统里的每个工具，而是主张围绕每项任务组合出合适的工具子集，这也是工作流封装的另一种形式。
6. 新内容与值得关注的动向¶
“代码即 harness”的研究，成了当天最清晰的概念锚点¶
@HowToAI_ 将其定义为（210 个赞，20 条回复，10,123 次浏览，211 次收藏）把 Illinois、Meta 和 Stanford 的综述解读为一种从自然语言推理转向“代码作为记忆、环境与边界”的变化。公开的 Code as Agent Harness 仓库称，这个领域现在正围绕 harness interfaces、harness mechanisms 和 scaling the harness 来组织。之所以重要，是因为它为信息流中已经逐渐成形的更广泛 harness 讨论提供了一个名字和一套结构。
发布日的 Fable benchmark 图片，让 coding-agent 竞赛更清晰¶
@kimmonismus 总结了（628 个赞，35 条回复，63,043 次浏览，132 次收藏）展示了 Claude Fable 5 的 benchmark 截图，用具体数字把模型讨论落到了实处：配图表格中，SWE-Bench Pro 为 80.3%，FrontierCode Diamond 为 29.3%，Terminal-Bench 2.1 为 88.0%。之所以重要，是因为当天关于模型的争论几乎立刻就不再抽象，而是转向了工作负载、effort setting 和路由决策。
Skill 开始携带可执行代码附件，而不只是 Markdown 说明¶
@LangChain 添加了（15 个赞，2 条回复，1,780 次浏览，12 次收藏）介绍了 interpreter skills，作为对 agent skills 的一种新扩展。公开的 解释器技能说明 解释了这种变化：skill 现在可以附带一个 TypeScript module，由解释器导入并执行，其中还包括在显式 runtime 暴露控制下对子 agent 和工具的调用。之所以重要，是因为这让 skill 同时成为了说明界面和 API 界面。
7. 机会在哪里¶
[+++] Agent delivery control planes — The strongest evidence came from multiple sections at once: @karrisaarinen 写道（121 个赞，15 条回复，8,585 次浏览，71 次收藏）给出了一份工作流工具的直接规格；@akshay_pachaar 认为（207 个赞，39 条回复，19,751 次浏览，263 次收藏）表示，循环需要可信的失败闭环逻辑；Loom 明确在为中断、验证、修复和交接而构建；而 Hermes 多智能体工作流 则封装了一个单人工关卡流水线。这个缺口很明显，因为零件已经存在，但共享控制平面看起来仍然碎片化。
[++] Frontier-model routing and delegated worker orchestration — @JJEnglert 评测了（161 个赞，17 条回复，28,936 次浏览，226 次收藏）认为 Fable 5 很有价值，但路由起来仍过于手工；@ClaudeDevs 展示了（107 个赞，1 条回复，33,449 次浏览，27 次收藏）展示了一种 coordinator-plus-subagent 模式；而 @kimmonismus 总结了（628 个赞，35 条回复，63,043 次浏览，132 次收藏）则给出了足以证明路由纪律在经济上有意义的 benchmark 提升。这属于中等机会，因为经济账已经很清楚，但策略仍主要存在于人的脑子里。
[++] Portable executable skills and workflow artifacts — @twostraws 分享了（98 个赞，4 条回复，3,095 次浏览，20 次收藏）展示了一种可安装到多个 agent 界面的 skill，@LangChain 添加了（15 个赞，2 条回复，1,780 次浏览，12 次收藏）展示了可执行的 interpreter skills，而 @tonbistudio 分享了（39 个赞，2 条回复，3,006 次浏览，49 次收藏）则展示了可复用的分流模板。这也属于中等机会，因为封装模式已经明确，但标准和分发仍处于早期。
[+] Task-scoped MCP and enterprise tool-governance layers — @saketsaurabh 发布了（98 个赞，10 条回复，3,357 次浏览，14 次收藏）通过 MCP Studio 提出：每个 app 一个 MCP server，会制造过多工具、token 和治理问题。这属于新兴机会，因为痛点已经很具体，但这个类别看起来仍然较新，而且带有较强的厂商色彩。
8. 要点¶
- 今天关于 harness 的讨论更偏运营层了。 @akshay_pachaar 认为（207 个赞，39 条回复，19,751 次浏览，263 次收藏）表示，只有 checker 可靠时，循环才有帮助；而 @threepointone 发布了（49 个赞，4 条回复，2,905 次浏览，37 次收藏）则展示了一个处理中断的状态机。（来源）
- 这一转向背后的研究框架，现在也更清晰了。 @HowToAI_ 将其定义为（210 个赞，20 条回复，10,123 次浏览，211 次收藏）把代码视作 harness，而公开的 Code as Agent Harness 仓库则将这一思路组织为接口、机制和扩展性问题。（来源）
- Fable 5 让路由纪律变得更重要，而不是更不重要。 @kimmonismus 总结了（628 个赞，35 条回复，63,043 次浏览，132 次收藏）展示了 benchmark 提升，但 @JJEnglert 评测了（161 个赞，17 条回复，28,936 次浏览，226 次收藏）在肯定同一发布的同时，仍然要求一个 auto-router。（来源）
- 缺失的产品，是一个持久的 agent 工作流层。 @karrisaarinen 写道（121 个赞，15 条回复，8,585 次浏览，71 次收藏）给出了当天最明确的一份需求清单，而 Loom 和 Hermes 多智能体工作流 都在试图填补这一缺口的一部分。（来源）
- Skills 正在变成可执行、可移植的资产。 @twostraws 分享了（98 个赞，4 条回复，3,095 次浏览，20 次收藏）展示了跨界面安装的 skill，而 @LangChain 添加了（15 个赞，2 条回复，1,780 次浏览，12 次收藏）则展示了把可运行代码与说明打包在一起的 interpreter skills。（来源）