Twitter AI Agent - 2026-06-04¶
1. 大家在讨论什么¶
1.1 Harness 工程从“相信如此”走向可测量的基准表现 🡕¶
6 月 4 日最大的变化，是“harness 胜过模型”不再只是口号，而开始以可测量的证据出现。多条高信号内容都支持这一主题，涵盖 Microsoft 的技能优化论文、Harvey 的法律基准，以及一些规模较小但诊断价值很高、专门隔离 harness 本身影响的基准测试讨论。
@omarsar0 报道 (241 个赞、28 条回复、15,116 次浏览、376 次收藏) 表示，Microsoft 的 SkillOpt 论文在他接入自己的编排器后显得更可信了：一个多模态论文图表提取技能的表现从 0.73 提升到了 0.93。公开的 SkillOpt 论文 则把机制说得很清楚：一个独立的优化器模型会对单个技能文档提出受限修改，只有当这些改动在 direct chat、Codex 和 Claude Code 上的留出验证里都带来提升时，才会被保留。
@SeanZCai 认为 (291 个赞、8 条回复、55,401 次浏览、283 次收藏) 表示，随着后训练成本下降，应用层公司开始与前沿模型提供商解耦，并以 Harvey 的法律基准为例。公开的 Fireworks 文章 给出了被引用的 Harvey 说法背后的具体数字：一个只在必要时调用 Opus 4.7 的 GLM 5.1 worker，以 368 美元完成了 18 个 all-pass 任务；Opus 端到端完成了 14 个，成本为 954 美元；一个经过后训练的 Kimi K2.6 变体则以 84 美元完成了 15 个。
@sairahul1 写道 (209 个赞、22 条回复、52,378 次浏览、331 次收藏) 表示，AutoGen、CrewAI、通用 agent 市场，以及横向的“构建任意 agent”平台，正在成为技术栈里衰减最快的部分；而上下文工程、工具设计、评测纪律、MCP 和 harness 思维则会不断复利。互动较少、但诊断价值更高的基准测试讨论中，@wenkafka 展示了 (3 个赞、224 次浏览) 展示了一张 Terminal-Bench 2.0 图表：同一个模型在不同 harness 下的得分大约相差 20 分；@chengyongru 总结了 (4 个赞、2 条回复、666 次浏览) 则把 Harness-Bench 作为证据，说明仅仅更换执行层，完成率、过程得分和 token 使用量都会发生实质变化。
讨论洞察： 回复不断把瓶颈说得更具体：评测纪律、轨迹采集、工具报错后的恢复能力，以及与实际验证器或文件系统保持一致的运行时状态，比再刷一次排行榜更重要。
与前一天对比： 6 月 3 日还只是把 harness 视为值得学习的一层；到了 6 月 4 日，讨论里已经出现了图表、垂直领域基准结果，以及一篇试图直接优化 harness 构件本身的论文。
1.2 Agent 工作更接近共享团队工作区 🡕¶
第二个讨论集群不再把 agent 看成一个聊天窗口，而更像是团队上下文、后台工作和人工审核的汇合界面。多条高信号内容都支持这一主题，既有明确的愿望清单，也有已经发布的产品界面。
@gregisenberg 写道 (188 个赞、55 条回复、14,242 次浏览、129 次收藏) 表示，他希望 Slack 变成 agent-first、支持语音、减少打扰，能够显示谁在做什么，并允许一个人的 agent 与另一个人的 agent 协同，而不必把两个人都拉进流程里。Nebula 一条带竞争意味的回复声称，它已经覆盖了这份清单“50% 以上”的需求，这让这种需求看起来不再只是愿景，而是相当具体。
@cansar 表示 (316 个赞、48 条回复、36,686 次浏览、31 次收藏) 表示，在加入 OpenAI 做 Codex 之前，Block 就已经构建了内部多 harness ADE 和基于 Slack 的云端 agent；他还把 Codex 形容为业内最好的 agent 应用。他的核心判断是：prompt、标签页、工具、文件和交接，开始收敛成一个更平静的工作界面，而不是继续碎片化地分散在不同应用里。
@cognition 展示了 (91 个赞、11 条回复、12,764 次浏览、22 次收藏) 介绍了 Harvey 的后台 agent Spectre 已集成进 Devin Desktop，使组织上下文可以跟着工程师走到笔记本电脑上，并在他们偏好的 agent 之间流转。最有价值的回复并没有泛泛赞美自动化，而是指出，真正的收益在于结束“设置考古”，并让交接质量变得可检查。
@thomasgauvin 宣布 (55 个赞、3 条回复、4,087 次浏览、36 次收藏) 提到了新的 Cloudflare agent 文档，而这些公开的 Cloudflare Agents 文档 也解释了这条动态为什么重要：现在有一个平台能在持久化运行时上覆盖聊天、Slack、电子邮件、语音和 webhook，并提供本地 SQL 状态、调度、fibers、浏览器自动化、沙箱代码执行、MCP 工具、支付和可观测性。
@CodexReleases 宣布 (70 个赞、11,971 次浏览) 介绍了 Codex CLI 0.137.0，包含 Multi-agent v2、按线程选择运行时、远程控制配对和企业配置包；@danshipper 推出了 (92 个赞、11 条回复、11,525 次浏览、116 次收藏) 则介绍了 Spiral 4.0，把它定位为 agent 可通过 MCP 和 CLI 使用的写作伙伴。两者结合后，“agent 工作区”的讨论从编码界面扩展到了团队写作和品牌运营。
讨论洞察： 回复把对界面的兴奋进一步落实成了运营要求：共享上下文、可追溯的交接、紧急程度路由，以及能带着足够凭据返回、从而值得信任的后台 agent。
与前一天对比： 6 月 3 日强调的是 CLI、桌面端、Slack 和语音之间的持久性；到了 6 月 4 日，这一讨论被明确成了工作场景里的具体需求，以及已经上线的团队向控制界面。
1.3 技能和 harness 继续变成可安装的运行资产 🡕¶
关于技能的讨论继续远离“把 prompt 存在某个地方”，转向代码仓库、看板、加载策略和公开的运营工具。共有七条入选内容支撑这一主题。
@_avichawla 认为 (39 个赞、4 条回复、5,711 次浏览、71 次收藏) 表示，Claude 类 agent 产品周围的 UI 和产物层现在实际上已经接近开源，而 CopilotKit 是最清晰的例子。公开的 CopilotKit README 用一套具体技术栈支撑了这一说法：agent-native 应用、生成式 UI、共享状态、人在回路中的暂停，以及被多个框架采纳的 AG-UI 协议。
@openclaw 宣布 (23 个赞、1 条回复、3,259 次浏览、14 次收藏) 介绍了 Workboard 中更好的多 agent 协作；链接里的公开 Workboard 文档 展示了一套 CLI 加 Gateway 的流程：通过共享 SQLite 状态，而不是松散的聊天协调，来列出卡片、创建卡片、派发就绪工作，并跟踪 worker 的运行。@wadefoster 表示 (20 个赞、914 次浏览、16 次收藏) 表示 Zapier 已开源其 GTM agents；公开的 GTM Cheat Codes 仓库 则确认，其中包含面向市场、销售、营收运营、支持、内容和法务运营的技能包，以及审批关卡和安全回写规则。
互动较少的构建者产物让这种封装转向更加具体。@nummanali 分享了 (1 条回复、148 次浏览) 展示了一个 16-agent Claude Code 运行的工作流遥测；@onepagecode 概述了 (1 个赞、6 条回复、91 次浏览) 把 Claude Code 描述为一个由工具、记忆、权限、subagents 和 hooks 构成的循环；@dani_avila7 认为 (9 个赞、422 次浏览、9 次收藏) 则指出，渐进式披露是杠杆最高的技能模式之一，因为参考资料和脚本应该只在工作流真正走到对应阶段时才加载。
@goose_oss 发布了 (27 个赞、2 条回复、1,519 次浏览) 介绍了 Goose v1.37.0；公开的 Goose README 和 发布说明 显示，这个运行时正在开源生态中逐渐成熟：项目已并入 Linux Foundation 旗下的 Agentic AI Foundation，同时新增了 /model、/goal、hooks、本地代码审查，以及更广泛的 ACP/MCP 支持。
讨论洞察： 一个明显变化是，人们如今关心的不只是技能怎么写，还关心它们如何加载、路由、版本化、审查和可视化。
与前一天对比： 6 月 3 日聚焦优化和市场；6 月 4 日则把这套逻辑推进到了公开仓库、运营看板、业务工作流包和成本感知的加载模式。
1.4 记忆、上下文压缩与安全委派成为具体故障域 🡕¶
第四个讨论集群不再只是说“agent 需要更好的记忆”，而是点名了长时间运行的 agent 具体会怎样失败：上下文衰减、空白状态重启、隐藏的恶意内容，以及缺少验证的委派。共有五条入选内容支撑这一主题。
@Aurimas_Gr 认为 (30 个赞、4 条回复、1,292 次浏览、26 次收藏) 表示，更大的上下文窗口并不能解决长时间运行 agent 的漂移问题，因为累积了足够多的工具输出、重试和历史记录后，注意力质量仍会下降。他附带的图示比那句口号更有用，因为它比较了三种具体压缩选项：丢弃、总结或卸载上下文；而回复则指出，真正需要的是检查点和版本化存储。
@iam_chonchol 写道 (13 个赞、2 条回复、2,296 次浏览) 表示，他构建的每个 agent 都是前 20 分钟看起来很聪明，随后就会重置成一张白纸，迫使他重新交代项目、决策和用户上下文。一条回复说这种模式“太真实了”，把对记忆的抱怨从小众实现问题变成了共同经历。
@Nafees_Ai 警告 (10 个赞、4 条回复、59 次浏览) 提到了 “Agents of Chaos” 论文；@rohanpaul_ai 总结了 (11 个赞、3 条回复、499 次浏览、10 次收藏) 则介绍了一套类似 DeepMind 风格的 “AI Agent Traps” 分类法：网站可以识别 agent，并向它展示人类从未看到的恶意内容，包括隐藏的 HTML 指令、隐写图像和被投毒的文档。另一篇帖子里，同一位作者 分享了 (12 个赞、798 次浏览、13 次收藏) 提出了一套 “Intelligent AI Delegation” 框架，把委派视为一连串选择：是否交出任务、如何指定任务，以及事后如何验证结果。
讨论洞察： 回复不断回到检查点、版本化状态、可见的权限边界，以及交接后的验证。问题并不是抽象意义上的“记忆”，而是谁能改变状态、agent 看到了什么，以及操作者如何证明整个运行过程始终没有跑偏。
与前一天对比： 6 月 3 日让记忆层和事件化上下文变得可见；到了 6 月 4 日，讨论进一步转向压缩策略、攻击分类法和明确的委派政策。
2. 什么让人感到沮丧¶
基准测试讨论仍在掩盖执行层¶
严重程度：高。@chengyongru 认为 (4 个赞、2 条回复、666 次浏览) 表示，如果任务和模型不变、只改变 harness，综合得分仍可能变动约 23.8 分；他还强调了几类从业者看了会格外熟悉的失败：36.4% 是契约或格式失败，24.6% 是工具或恢复失败。@wenkafka 展示了 (3 个赞、224 次浏览) 展示了一张 Terminal-Bench 2.0 图表：同一个模型在不同 harness 下大约相差 20 分；@omarsar0 表示 (241 个赞、28 条回复、15,116 次浏览、376 次收藏) 则表示，SkillOpt 终于给他的技能带来了“正规的测试框架”。人们正通过留出验证、把模型与运行时分开的基准讨论，以及更明确的技能评估来应对这个问题。之所以值得投入建设，是因为团队仍缺少比较不同运行时的标准方法，无法在不混淆模型选择与执行质量的前提下进行对比。
团队上下文仍会在交接边界断裂¶
严重程度：高。@gregisenberg 列出了 (188 个赞、55 条回复、14,242 次浏览、129 次收藏) 列出了一整套缺失的工作区能力：紧急程度感知、agent 间协同、深度工作保护、明确的责任归属，以及面向新员工的共享上下文。在 @cognition 展示 (91 个赞、11 条回复、12,764 次浏览、22 次收藏) 所说的 Devin Desktop 内 Spectre 讨论下，一条回复提到，当组织记忆能够顺畅流动时，审核就不再是“设置考古”，而会变成一个交接质量问题。@cansar 补充道 (316 个赞、48 条回复、36,686 次浏览、31 次收藏) 表示，Block 很早就在构建基于 Slack 的云端 agent 和多 harness ADE，这凸显出团队为了获得一个可用的共享界面，至今仍要做大量定制集成。人们正借助 Slack agent、桌面封装，以及 Cloudflare Agents 这类多渠道运行时来应对，但底层痛点仍是上下文碎片化和交接薄弱。之所以值得投入建设，是因为数据集中每个新的界面，本质上都只是围绕同一个协作缺口打补丁。
长时间运行的 agent 仍会丢失主线¶
严重程度：高。@Aurimas_Gr 表示 (30 个赞、4 条回复、1,292 次浏览、26 次收藏) 表示，即使上下文窗口更大，长时间运行的 agent 最终仍会耗尽有用上下文；回复也立刻要求检查点和版本化存储，而不只是更多 token。@iam_chonchol 描述了 (13 个赞、2 条回复、2,296 次浏览) 则从用户侧描述了同一种失败模式：agent 前 20 分钟表现惊艳，随后重置成一张白纸，迫使操作者重新交代项目和过往决策。互动较少的构建者帖子里，@onepagecode 将其定义为 (1 个赞、6 条回复、91 次浏览) 把自动压缩和语义搜索视为 Claude Code 循环里的结构性组成部分；@nummanali 分享了 (1 条回复、148 次浏览) 则给出了一个 16-agent、310 万 token 工作流的遥测，让协调问题的规模变得可见。人们正通过压缩策略、分阶段技能加载和明确的记忆分类法来应对。之所以值得投入建设，是因为这种浪费出现在每一次长时间运行中，而不只是边缘案例。
自主 agent 仍然太容易被误导，或被错误委派¶
严重程度：高。@Nafees_Ai 警告 (10 个赞、4 条回复、59 次浏览) 表示，“Agents of Chaos” 论文把自主 agent 放进带有电子邮件、文件、记忆和 shell 访问权限的真实环境里，再对其进行红队测试。@rohanpaul_ai 总结了 (11 个赞、3 条回复、499 次浏览、10 次收藏) 提出了一套由六部分组成的 “AI Agent Traps” 分类法：恶意网站可以把指令藏在 HTML 注释、白底白字文本、图像、PDF、元数据或被投毒的记忆里；一条回复说，仅一个隐藏的 HTML 注释，就可能让原本对齐的运行时偏离轨道。他另发的 delegation 帖子 (12 个赞、798 次浏览、13 次收藏) 进一步点明了相邻的挫败感：团队仍没有可靠的政策来决定何时委派、如何界定任务范围，以及之后如何验证交接结果。人们正通过更严格的权限边界和更明确的验证闭环来应对。之所以值得投入建设，是因为这种失败模式带来的不是“不方便”，而是“不可信的执行”。
3. 人们希望存在什么¶
一个理解紧急程度、责任归属和 agent 间协同的 agent-first 团队工作区¶
最明确、也最实际的需求，是一个让 agents 成为原生协作者而不是外挂工具的工作区。@gregisenberg 描述了 (188 个赞、55 条回复、14,242 次浏览、129 次收藏) 描述了这样一个地方：他的 agent 可以“拍一拍别人的 agent”，系统能区分“现在就要”和“什么时候都行”，决策会变成一等对象，而不是聊天残渣。@cansar 表示 (316 个赞、48 条回复、36,686 次浏览、31 次收藏) 表示，Codex app 正开始把 prompt、工具、文件和交接收拢到同一个界面；@cognition 展示了 (91 个赞、11 条回复、12,764 次浏览、22 次收藏) 则展示了一个组织上下文能够跨 agent 和设备流转的后台 agent。这是实际需求，不是情绪诉求：当前的替代方案仍是一堆 Slack bots、桌面封装和定制集成。机会：直接且竞争激烈。
具备明确压缩、检查点和恢复规则的持久记忆¶
人们要的不是抽象意义上的“更多记忆”，而是能撑过长时间运行、又不会变成垃圾的记忆层。@Aurimas_Gr 认为 (30 个赞、4 条回复、1,292 次浏览、26 次收藏) 提出了明确的压缩选项：丢弃、总结和卸载；而回复立刻进一步要求检查点和版本化检索。@iam_chonchol 描述了 (13 个赞、2 条回复、2,296 次浏览) 则展示了缺少这一层的代价：每次新会话都要重新解释同一个项目和同一批决策。互动较少的构建者产物 @onepagecode 和 @nummanali 说明，操作者已经在用压缩、工作流遥测和多 agent 轨迹围绕这个问题做设计。这个需求既紧迫又务实，因为今天的兜底方案仍然是手动重新写 prompt，或临时记些笔记。机会：直接。
可移植、可渐进加载且可审查的技能与 harness 资产¶
关于技能的讨论表达出的愿望，比“更好的 prompt”要具体得多。构建者想要的是能跨运行时迁移、成本可见、并且在修改真实系统前保持可审查的资产。@wadefoster 分享了 (20 个赞、914 次浏览、16 次收藏) 开源了带审批关卡的 GTM agent 技能和自动化；@openclaw 发布了 (23 个赞、1 条回复、3,259 次浏览、14 次收藏) 展示了一个以任务为底座的多 agent 协调界面；@_avichawla 指出 (39 个赞、4 条回复、5,711 次浏览、71 次收藏) 则指向 CopilotKit，把它视为 agent-native 应用和共享状态的开放基础设施。@dani_avila7 补充道 (9 个赞、422 次浏览、9 次收藏) 表示，渐进式披露之所以重要，是因为技能参考资料和脚本应该只在需要时才加载。现在一些组件已经存在，但仍分散在代码仓库、CLI、仪表盘和各自为政的运行时生态里。机会：直接且竞争激烈。
保持可审查的委派政策与对抗防御中间件¶
最强烈的治理诉求并不是“让 agents 自主”，而是“让委派清晰可见”。@rohanpaul_ai 分享了 (12 个赞、798 次浏览、13 次收藏) 提出了一套公开框架，把委派视为一系列选择：是否把工作交出去、如何指定任务，以及如何检查结果。他另发的 AI Agent Traps 帖子 (11 个赞、3 条回复、499 次浏览、10 次收藏) 和 @Nafees_Ai 重点介绍 (10 个赞、4 条回复、59 次浏览) “Agents of Chaos” 说明了这一需求为什么务实：网站、文件和真实环境都可能让 agent 接触到人类根本看不到的恶意内容。现有答案大多仍停留在论文、图示或本地规则层面，而不是一个标准化控制层。机会：直接。
4. 正在使用的工具和方法¶
| 工具 | 类别 | 评价 | 优势 | 局限 |
|---|---|---|---|---|
| Harness 工程 | 方法 | (+) | 将模型选择与工具、评测、状态和恢复机制分离 | 由于许多运行时选择会同时变化，难以进行干净测量 |
| SkillOpt | 技能优化 | (+) | 受限修改、留出验证和可迁移的技能资产 | 需要有评分的 rollout 和验证 harness |
| Harvey 混合 harness | 模型路由 / 后训练 | (+) | 通过稀疏的顾问调用，以更低成本获得接近前沿模型的法律质量 | 证据仍主要集中在单一垂直基准上 |
| Cloudflare Agents | Agent 运行时平台 | (+) | 持久状态、调度、工具、可观测性和多渠道覆盖 | 依赖特定平台栈和工作流假设 |
| Codex CLI 0.137.0 | 编码 agent 运行时 | (+) | Multi-agent v2、按线程选择运行时，以及远程控制配对 | 数据集中只有版本发布层面的细节，缺少长时间使用者反馈 |
| CopilotKit | Agent UI / SDK | (+) | 生成式 UI、共享状态、人在回路中的流程，以及 AG-UI 生态支持 | 应用构建者仍需自行搭建工作流和策略层 |
| OpenClaw Workboard | 协调 / 编排看板 | (+) | 任务驱动的派发、共享 worker 状态和可见的失败 | 比纯聊天工具需要更大的操作者界面 |
| GTM Cheat Codes | 技能包 / 业务自动化 | (+) | 带审批关卡、可审查的 GTM 工作流和安全回写 | 垂直领域较强，且依赖接入 Zapier 的系统 |
| 技能中的渐进式披露 | 文档 / 加载方法 | (+) | 减少 token 负载，让长流程保持分阶段推进 | 要求作者谨慎管理各阶段 |
| 上下文压缩 | 记忆管理方法 | (+/-) | 丢弃、总结和卸载策略为操作者提供明确权衡 | 若没有版本化检索，关键状态很容易丢失或陈旧 |
| AI Agent Traps / Agents of Chaos | 安全评测 | (+/-) | 让隐藏内容攻击和真实环境中的失效模式具体可见 | 目前主要是诊断用途；团队仍需要生产级控制层 |
| Goose | 开源 agent 运行时 | (+) | 桌面端、CLI、API、hooks、模型切换，以及广泛的 ACP/MCP 支持 | 功能面快速扩张，增加了运维复杂度 |
| Spiral 4.0 | 兼容 agent 的写作工具 | (+/-) | 把风格一致的写作能力带入 MCP 和 CLI 工作流 | 数据集里目前主要还是发布方说法，缺少独立操作者报告 |
总体来看，人们更认可那些把运行时行为外化为技能、轨迹、看板和可见状态的工具，而不是把一切藏进一个不透明的 prompt 里。满意度最高的工具，要么让改进变得可测量，比如 SkillOpt 和 Harvey；要么让操作者界面变得清晰可见，比如 Cloudflare Agents、Workboard、CopilotKit 和 Goose。最常见的应对方式包括渐进式加载、人工审批关卡、混合路由和上下文压缩。迁移趋势则指向：从 prompt 打包转向仓库支撑的技能包，从纯聊天使用转向多渠道工作界面，以及从只用前沿模型转向开放模型 worker 加选择性前沿建议的组合。
5. 人们正在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| SkillOpt | Microsoft Research / @omarsar0 | 通过受限修改和留出验证优化 agent 技能文档 | 一次性写出的技能难以可靠改进 | 优化器模型、冻结的目标 agent、验证循环 | Alpha | 论文, 推文 |
| Harvey 混合法律 agent | Harvey / Fireworks / @SeanZCai | 将开放 worker 模型路由给前沿顾问，并对法律专用模型做后训练 | 只用前沿模型的法律 agent 在重复性领域工作中成本过高 | GLM 5.1、Opus 4.7、Kimi K2.6、LAB benchmark | Beta | 博客, 推文 |
| Cloudflare Agents | Cloudflare / @thomasgauvin | 在聊天、Slack、电子邮件、语音和 webhook 之间运行持久化 agents | 团队想要一个同时具备状态、调度、工具和可观测性的统一运行时 | Agents SDK、Project Think、SQL 状态、fibers、browser、sandbox、MCP | Shipped | 文档, 推文 |
| Spiral 4.0 | Every / @danshipper | 为人和 agents 提供带风格引擎和 MCP/CLI 访问能力的写作伙伴 | 团队希望在 agent 工作流中实现符合品牌风格的写作 | 风格引擎、MCP、CLI | Shipped | 推文 |
| Devin Desktop 中的 Spectre | Cognition / Harvey | 把 Harvey 的后台 agent 和组织上下文带入 Devin Desktop | 当后台工作彼此隔离时，上下文和交接质量会断裂 | Spectre、Devin Desktop、ACP 风格的 agent 互操作性 | Beta | 推文 |
| OpenClaw Workboard | OpenClaw | 为多 agent worker 执行增加基于任务的看板运行和派发 | 聊天线程不是长时间运行的多 agent 工作的良好协调界面 | CLI、Gateway、SQLite 状态、worker claims、dispatch loop | Shipped | 文档, 推文 |
| GTM Cheat Codes | Zapier / @wadefoster | 发布带审批关卡的 GTM agent 技能和预构建自动化 | 业务团队想要有来源依据的自动化，而不是盲目运行的 agents | Zapier SDK、MCP、技能包、自动化、审批关卡 | Shipped | 仓库, 推文 |
| CopilotKit | CopilotKit / @_avichawla | 用于构建带生成式 UI 和共享状态的 agent-native 应用的 SDK | 从零搭建 agent UI 和共享工作流难度很高 | AG-UI Protocol、React、共享状态、工具渲染、HITL | Shipped | 仓库, 推文 |
| Goose v1.37.0 | Agentic AI Foundation / @goose_oss | 具备不断扩展工作流控制能力的开源桌面端、CLI 和 API agent 运行时 | 开发者想要一个可跨模型和界面使用的便携式开放运行时 | Rust、ACP、MCP、hooks、多提供商支持 | Shipped | 仓库, 发布, 推文 |
SkillOpt、OpenClaw Workboard、GTM Cheat Codes 和 CopilotKit 指向同一种构建模式：技能和 harness 正在成为周围配有评测、派发、UI 和审批界面的受管理资产。@dani_avila7 展示了 (9 个赞、422 次浏览、9 次收藏) 表示，甚至连文档如今也被当作分阶段的运行时基础设施，通过渐进式披露来加载；@nummanali 分享了 (1 条回复、148 次浏览) 则用一个 16-agent 工作流的遥测让这类基础设施变得可见。
Cloudflare Agents、Devin Desktop 中的 Spectre、Spiral 4.0 和 Goose 又展示出第二种反复出现的模式：操作者界面本身正在成为产品范围的一部分。一类团队追求跨渠道、跨界面的广度，另一类把专业化后台 agent 拉进桌面端，还有一类则把 agent 工作流延伸到写作和品牌运营。多个团队都在独立围绕同一个痛点构建：上下文应该能流动，而界面应该让长时间运行的工作可检查。
Harvey 的混合法律 agent 是数据集中最强的垂直案例，因为它同时结合了这两种模式：一个围绕开放 worker 调优的 harness，加上选择性调用的前沿顾问，并且绑定在一个披露了成本数字的领域基准上。这说明路由、后训练和评测循环正在成为产品差异化本身，而不再只是藏在模型选择背后的实现细节。
6. 新动态与值得关注的内容¶
LEAP 给出了当天最清晰的“结构优于模型”结果¶
@DanKornas 认为 (9 个赞、1 条回复、512 次浏览、8 次收藏) 表示，Google 的 LEAP 论文之所以重要，是因为直接使用 Gemini-3.1-Pro 的基线在 Putnam 2025 的 12 道形式化问题中 0 题解出，而套上 LEAP 后则解出了全部 12 题。这一点之所以值得关注，是因为它把当天“harness-first”的逻辑从编码或 agent 基准，扩展到了形式推理中的一套清晰循环：规划、分解、验证、复用。
Slack 开始明确补贴 agent-first 的工作场所应用¶
@0x_beni_ 强调了 (89 个赞、9 条回复、5,988 次浏览、111 次收藏) 提到了一项总额 42,000 美元的 Slack Agent Builder Challenge，奖励包括 Dreamforce 差旅、Slack Marketplace 分发和新闻简报展示位；被引用的 @devpost 公告则确认，这项活动被明确包装为围绕 Slack 内工作流自动化、实时洞察和互联系统的竞赛。这一点值得关注，因为工作场所 agent 界面已经从创始人的愿望清单，进入了有赞助的生态建设阶段。
Goose 的基金会归属让开放 agent 运行时更具制度化色彩¶
@goose_oss 发布了 (27 个赞、2 条回复、1,519 次浏览) 提到了 Goose v1.37.0，包含 /model、/goal、hooks、本地代码审查和更广泛的 ACP 支持；公开的 Goose README 现在则表示，该项目已并入 Linux Foundation 旗下的 Agentic AI Foundation。这一点之所以值得关注，是因为开放运行时生态不再只是持续发新功能，也开始积累治理结构和制度连续性。
7. 机会在哪里¶
**+++］ 通过压缩、检查点和验证实现持久上下文管理** — ［@Aurimas_Gr、@iam_chonchol、Spectre-in-Devin 讨论，以及 Cloudflare 和 OpenClaw 的多渠道运行时，都指向同一个缺失层：状态必须能以紧凑、可检查、易恢复的形式撑过长时间运行。
**+++］ 面向智能体优先的团队工作空间** — ［@gregisenberg、@cansar、@cognition、Cloudflare Agents，以及 Slack 的 Agent Builder Challenge，都表明市场强烈需要一个能协调人、agents、渠道、紧急程度和交接的统一界面。
[+++] 技能与 harness 生命周期工具 —— SkillOpt、GTM Cheat Codes、OpenClaw Workboard、CopilotKit、渐进式披露模式和 Goose 都表明，团队现在需要围绕技能提供评测、封装、加载、路由、审批和遥测，而不只是写 prompt。
[++] 委派与对抗防御中间件 —— “AI Agent Traps”、“Agents of Chaos” 和 “Intelligent AI Delegation” 共同定义了 agent 与开放网络或文件系统之间一个清晰的产品楔口：在自主运行接触真实环境之前，操作者需要策略、检查与验证。
[++] 垂直领域混合 harness —— Harvey 的法律基准有力说明，经过调优的开放模型 worker 加选择性的前沿建议，在真实领域里可以打败“只用前沿模型”的经济性。这为特定领域的 agent 技术栈留下了空间：它们不必靠模型名气取胜，而可以在成本、控制力和时延上建立优势。
[+] 衡量运行时而不只是模型的基准基础设施 —— Terminal-Bench、Harness-Bench 和 LEAP 都指向一个正在浮现的需求：基准需要把执行层明确报告出来，但这一方向的公开工具仍然早期且分散。
8. 要点¶
- Harness 效应如今已经开始被基准测试，而不再只是停留在口头断言。 @omarsar0 展示了 (241 个赞、28 条回复、15,116 次浏览、376 次收藏) 表示，SkillOpt 可以在验证条件下改进真实的 agent 技能；Harvey 公开的基准数字则把同一结论推进成了一张成本与质量对照图。（来源）
- 界面之争正转向 agent-native 团队工作区。 @gregisenberg 描述了 (188 个赞、55 条回复、14,242 次浏览、129 次收藏) 描述了一个能理解紧急程度、责任归属和 agent 间协同的协作界面；@cansar 将其定义为 (316 个赞、48 条回复、36,686 次浏览、31 次收藏) 则把 Codex 视为零散工具和交接开始汇流的地方。（来源）
- 技能正在变成受管理的运行资产。 Zapier 的 GTM Cheat Codes、OpenClaw 的 Workboard 文档，以及 @dani_avila7 认为 (9 个赞、422 次浏览、9 次收藏) 都把渐进式披露视为控制成本、加载和上下文纪律的一种方式。（来源）
- 长时间运行 agent 的可靠性问题，本质上仍主要是状态管理问题。 @Aurimas_Gr 认为 (30 个赞、4 条回复、1,292 次浏览、26 次收藏) 提出明确的压缩策略；@iam_chonchol 描述了 (13 个赞、2 条回复、2,296 次浏览) 则从操作者一侧展示了“白纸重置”问题。（来源）
- 没有对抗防御和验证闭环，委派就不会被信任。 @rohanpaul_ai 总结了 (11 个赞、3 条回复、499 次浏览、10 次收藏) 展示了 agents 能看到、人却看不到的隐藏内容攻击；他的委派框架，再加上 @Nafees_Ai 强调了 (10 个赞、4 条回复、59 次浏览) “Agents of Chaos”，说明为什么策略和交接后检查必须成为一等能力。（来源）
- 开放 agent 运行时正在同时扩大功能面，也增强制度基础。 @goose_oss 发布了 (27 个赞、2 条回复、1,519 次浏览) 提到了 Goose v1.37.0，而其公开仓库也已并入 Agentic AI Foundation，这比又一条一次性发布动态更能说明问题。（来源）