Twitter AI Agent - 2026-06-03¶
1. 大家在讨论什么¶
1.1 Harness 工程仍是核心，但讨论开始更偏向“怎么做” 🡒¶
最强的一波讨论依然把模型视为更大系统中的一层。与 6 月 2 日相比，变化主要在语气：构建者不再只是介绍上下文、记忆和 harness 这套词汇，而是开始据此告诉大家，哪些东西不必再学、应该改学什么，以及复杂性到底该放在哪里。共有五条入选内容支撑这一主题。
@DataChaz 指出 (272 个赞，25 条回复，36,443 次浏览，415 次收藏) 认为，真正可能产生复利的部分是上下文工程、工具设计、编排器—子代理模式、评测纪律、MCP，以及“harness > model”的思维方式。回复则把门槛说得更具体：构建者表示，评测纪律是那个不声不响却能拉开差距的因素；在技术栈其他部分变得重要之前，harness 先得具备崩溃恢复、会话恢复和审计轨迹。
@sairahul1 提出了相同的观点 (155 个赞，18 条回复，37,968 次浏览，254 次收藏) 的表态更激进：他把 AutoGen、CrewAI、智能体市场、基准榜单，以及横向的“构建任意智能体”平台都列入“淘汰名单”，同时反复强调，能穿越框架更迭留下来的，是上下文工程、工具设计、评测纪律、MCP 和 harness 思维。最有价值的一条回复指出，脆弱的恰恰就是这种通用的“构建任意智能体”层，而品味和评测会活得更久。
@_avichawla 重新表述了 (34 个赞，6 条回复，2,749 次浏览，37 次收藏) 把同一观点表述成一个架构问题：模型故意保持轻薄，而 harness 把记忆、技能、协议，以及可观测性、审批回路、评估等中介层外置出去。一条回复把这个推论又往前推了一步：光看提示日志还不够，团队需要能重放完整的组合运行时，才能真正调试故障。
@joaomdmoura 总结了 (21 个赞，1 条回复，2,611 次浏览) 给出了这套论点的运维版本：不存在什么“简单的智能体系统”，只有“复杂性放在哪里”的选择。他的建议是让编排尽量简单，把复杂性压到工具、可观测性和测试里，因为持续迭代在这些地方带来的伤害更小。
@adxtyahq 汇总了 (152 个赞，4 条回复，3,785 次浏览，268 次收藏) 给出了一条学习路径，涵盖 RAG、智能体式 RAG、Anthropic 的 构建高效智能体、LangGraph、MCP、记忆系统和评测，并明确建议读者跳过那些“10 分钟搭建 AI 智能体”的视频。这份资源清单之所以重要，是因为它把当天的反炒作氛围，落成了一套具体的学习正典。
讨论洞察： 回复里，人们对模型选型的兴趣低于对 harness 可检查性的关注：评测、可重放的运行时状态、恢复机制，以及可核验留痕。
与前一天对比： 6 月 2 日确立了上下文、记忆和 harness 这套共同词汇。到了 6 月 3 日，这套词汇已经被视为既定共识，讨论开始转向设计规则、阅读清单，以及不要把过多复杂性塞进编排层的警告。
1.2 技能不再像静态提示词，而开始变成可训练、可治理、可安装的资产 🡕¶
围绕技能的讨论，已经从“写一个可复用提示词”转向三个更难的问题：技能能否基于证据被优化、它在改变未来行为前能否先被审查，以及它能否通过真实的产品界面来分发。共有五条入选内容支撑这一主题。
@omarsar0 报道称 (130 个赞，22 条回复，9,487 次浏览，223 次收藏) 认为，在把微软的 SkillOpt 论文接入自己的编排器并看到效果提升后，这篇论文显得更可信了。附带的预告和公开论文都把创新点说得很具体：把技能视为冻结智能体的外部状态，用一个独立的优化器模型提出有边界的增删改建议，只有在留出集验证结果变好时才接受改动。
@openclaw 介绍了 (60 个赞，9 条回复，5,051 次浏览，37 次收藏) 介绍了 Skill Workshop：它把重复性工作转化为可审查的提案，而不是悄悄改写未来的运行结果。链接中的 博客文章 和 文档 展示了一条“提案优先”的工作流：生成出来的技能会先保持为 PROPOSAL.md 草稿，直到人类对其进行修改、应用、拒绝或隔离。
@grabbou 展示了 (11 个赞，1 条回复，1,181 次浏览，8 次收藏) 指出，Codex 现在可以直接从 GitHub 仓库添加外部市场，并在界面里加载 Callstack 的 React Native 技能。截图把分发入口说得很清楚：一个弹窗可从 callstackincubator/agent-skills 添加市场，另一个则展示了产品内可浏览、可运行的 React Native 审查与 QA 技能。
@VaibhavSisinty 强调了 (28 个赞，3 条回复，2,112 次浏览，38 次收藏) 介绍了 Everything Claude Code 这一可安装栈：其中包含 38 个专用智能体、156 项技能、72 条命令，以及一个带有 1,282 项测试的安全扫描器。截图之所以重要，是因为它同时展示了选择性安装命令，以及这个包内部的角色分工：规划器、安全审查员、TypeScript 审查员、代码审查员和调试器。
讨论洞察： 分歧不在于技能有没有用，而在于人类检查点之前到底该允许多少自主学习，以及技能质量能否被测量，而不是被想当然地假定。
与前一天对比： 6 月 2 日强调的是技能仓库、安装命令和递归式技能改进。到了 6 月 3 日，讨论新增了基于基准的优化、提案闸门、基于仓库的市场，以及可选择安装的完整栈。
1.3 智能体运行时正从单一终端窗口走向持久化操作界面 🡕¶
另一组帖子不再把智能体当作聊天框，而是把它视为能跨界面、跨机器、跨日程持续存在的工作界面。共有四条入选内容支撑这一主题。
@akshay_pachaar 描述了 (58 个赞，9 条回复，8,291 次浏览，77 次收藏) 介绍了 Hermes Desktop：它与 CLI 共享同一套核心智能体、会话、记忆和技能，同时提供工具调用的流式可见性、并排预览、工件面板和远程网关模式，因此重任务可以在 VPS 上运行，而操作者仍留在本地。它的关键主张不是“现在有 GUI 了”，而是连续性：任务可以在终端开始，在应用里结束，中间无需重置状态。
@codyplof 给出了 (38 个赞，11 条回复，3,072 次浏览，44 次收藏) 是当天最接地气的实践者报告。他表示，在 Mac Mini 上，Hermes 值得付出部署成本；它与 Claude 和 Codex 配合良好，在 Slack 里适合作为幕僚长式助手，而且正在扩展成一个可访问仓库、工作区和分析系统的共享团队智能体。同一条讨论还暴露出一个真实的运维约束：他最初使用 Anthropic API，但因为对自己的场景来说太贵，后来转用了 Codex 套餐。
@Daniel_Farinax 展示了 (44 个赞，5 条回复，1,509 次浏览，19 次收藏) 介绍了一层语音界面：它可在桌面上编排 Grok Build，并借助记忆、调度和通知处理“同时运行几十个智能体”。一条回复点出了它为什么显眼：语音开始充当路由器，而不再只是输入方式。
@Tanaypawar27 发布了 (41 个赞，13 条回复，7 次收藏) 展示了一张 Claude Code 路线图，把整个栈压缩成一条 12 步路径，从 CLI 和项目一路延伸到记忆、技能、hooks、MCP、插件、子智能体、智能体团队和例程。这张信息图之所以重要，是因为它把“从安装到自动驾驶”包装成了一条标准进阶路径，而不再只是圈内人才知道的经验。
讨论洞察： 回复主要聚焦这些界面的运维边缘问题：远程网关怎么搭、子智能体并行工作时记忆如何做版本控制，以及语音是否应该成为主要调度器。
与前一天对比： 6 月 2 日通过 ACP 让桌面互操作性进入视野。到了 6 月 3 日，讨论进一步延伸到了持久会话、Slack 频道、VPS 控制、工件，以及语音驱动的编排。
1.4 上下文和记忆开始成为显式运行时原语，而不是隐藏在提示词里的填充内容 🡕¶
6 月 2 日大家提“更好的记忆”时，这个诉求大多还停留在抽象层面。到了 6 月 3 日，帖子开始点名他们真正想要的原语：推送式上下文、固定外部状态、响应式规则，以及分层记忆。共有四条入选内容支撑这一主题。
@tylbar 宣布了 (29 个赞，9 条回复，5,848 次浏览，21 次收藏) 介绍了 Mastra 的 Agent Signals：包括面向外部事件的通知信号、把最新外部状态重新锚定进上下文的状态信号，以及根据智能体当前循环调整行为的响应式信号。这让“上下文工程”看起来不再像写提示词，而更像是一套上下文操作系统。
@josevalim 指出 (13 个赞，6 条回复，744 次浏览) 认为，MCP 需要一种让服务器向客户端推送提示词上下文的机制。他举的具体例子是 Figma 的选中状态：现在他还得多做一步手动操作，才能告诉智能体自己选中了什么。回复把这个问题扩展到了 CI 失败、异常页面和工具变更通知，同时坚持认为，推送进来的状态必须保持可检查、且受权限控制。
@OpenCovenant 声称 (26 个赞，11 条回复) 认为，身份、权限、记忆、审计和结算，应该作为机器上的共享服务，位于所有框架和模型之下。同一账号后来又用 可视化展示了 (30 个赞，15 条回复) 把记忆分成三层：工作记忆、情景记忆和长期记忆。
讨论洞察： 讨论串层面的共识不是“给我更多上下文”，而是“给我事件驱动的上下文、可见的状态，以及有明确保留规则的记忆分层”。
与前一天对比： 6 月 2 日把记忆视为一项方法论和反复出现的痛点。到了 6 月 3 日，这个问题被进一步具体化为状态信号、推送式上下文，以及明确的工作记忆／情景记忆／长期记忆分层。
2. 什么让人感到沮丧¶
手动传递上下文和陈旧状态，仍在打断本来已经相当能干的智能体¶
严重程度：高。@josevalim 表示 (13 个赞，6 条回复，744 次浏览) 表示，MCP 仍然要求他额外做一步，才能把 Figma 里当前选中的内容告诉智能体。回复也很直白地描述了现在的应急办法：还不存在的状态钩子、工具变更通知，或者把截图再贴回提示词里。@tylbar 已推出 (29 个赞，9 条回复，5,848 次浏览，21 次收藏) 之所以要做 Agent Signals，正是因为团队需要让 CI 失败、收到的新邮件和不断变化的外部状态，在无需手动重新提示的前提下送达智能体。即便在 @codyplof 描述 (38 个赞，11 条回复，3,072 次浏览，44 次收藏) 描述的那个已经跑起来的 Hermes 配置下，回复里最先出现的问题之一仍是：他到底是怎么避免长会话里的上下文串扰的。大家现在靠截图、固定状态、Slack 频道、Obsidian 笔记和旁路记忆层硬扛。这值得投入建设，因为摩擦出现在智能体开始做有用工作之前。
当团队把过多智能塞进编排层时，复杂性会迅速爆炸¶
严重程度：高。@joaomdmoura 写道 (21 个赞，1 条回复，2,611 次浏览) 认为，复杂的多智能体编排层会拖慢团队，因为每一次改动都会沿着路由和交接逻辑层层扩散。@_avichawla 指出 (34 个赞，6 条回复，2,749 次浏览，37 次收藏) 认为，正确做法是把记忆、技能、协议、可观测性、审批回路和评估外置，而不是都藏进一个不透明的循环里；一条回复还补充说，光有提示日志不够，团队需要能重放完整的组合运行时。@DataChaz 认为 (272 个赞，25 条回复，36,443 次浏览，415 次收藏) 关于 harness 优先思维的讨论下，回复则表示，崩溃恢复、会话恢复和审计轨迹，才是耐用系统与教程级演示之间的分界线。大家的应对模式非常一致：更简单的编排、更强的工具、更明确的计划，以及更多运行时留痕。这值得投入建设，因为迭代速度正是在这里被拖死的。
静默学习与不安全执行，仍让团队对自主性保持警惕¶
严重程度：高。@openclaw 表示 (60 个赞，9 条回复，5,051 次浏览，37 次收藏) 认为，智能体应该学会处理重复工作，但不该靠悄悄改写未来运行来做到这一点。Skill Workshop 的那套流程之所以存在，正是因为生成出来的技能在变成线上行为前，需要可审查的提案、支持文件扫描，以及明确的应用或拒绝动作。@Dagnum_PI 将其定位为 (65 个赞，5 条回复，1,244 次浏览) 介绍了 Gate AI：它作为智能体与模型之间的一层，筛查每一个请求、拦截提示词注入，并建立防篡改的审计轨迹。即便在 @Tanaypawar27 提到了 (41 个赞，13 条回复，7 次收藏) 那条整体氛围相当正面的 Claude Code 路线图讨论里，回复也立刻抛出了一个现实的运维疑问：多个子智能体并行运行时，记忆文件该怎么做版本控制？大家现在靠审批闸门、安全扫描器和人工审核回路来应对。这值得投入建设，因为真正的阻碍是对执行过程的不信任，而不是没有需求。
前沿模型的成本仍是一项显眼税负¶
严重程度：中高。@codyplof 表示 (38 个赞，11 条回复，3,072 次浏览，44 次收藏) 表示，他最初使用 Anthropic API，但后来因为对自己的配置来说太贵，转用了 Codex 套餐。@SeanZCai 放大了 (155 个赞，6 条回复，24,816 次浏览，137 次收藏) 转述了 Harvey 的说法：以 GLM 5.1 为主工作模型、Opus 4.7 为顾问的混合法律智能体，在质量和成本上都优于 Opus；而一个经过后训练的 Kimi 2.6 法律智能体，在同一组 100 个任务切片上也以大约 11 倍的成本优势击败了 Opus。@CommandCodeAI 宣传为 (93 个赞，3 条回复，111,603 次浏览，59 次收藏) 则推出了每月 1 美元的入门套餐，提供约 15K 次请求和额度，主打 DeepSeek V4 Pro、Qwen 3.7 Max 和 MiniMax M3；这本身就说明，定价压力已经成为产品卖点的一部分。
大家的应对方式包括混合路由、后训练、更便宜的开放模型，以及激进的模型套餐打包。这值得投入建设，因为经济性决定了智能体究竟会停留在实验阶段，还是成为默认工具。
3. 人们希望存在什么¶
带有用户可见权限控制的事件驱动式上下文注入¶
最明确的诉求不是更大的上下文窗口，而是状态一变，更合适的状态就能自动送达。@josevalim 描述了 (13 个赞，6 条回复，744 次浏览) 用一个简单的 Figma 例子说明了眼下的缺口：选中某个对象后，他仍然得再做一步，才能告诉智能体到底变了什么。@tylbar 提供了 (29 个赞，9 条回复，5,848 次浏览，21 次收藏) 通过通知、状态和响应式信号给出了一部分答案，但这两个讨论串下的回复都坚持认为，推送进来的状态必须保持可检查，并且受权限控制。这是现实需求，不是愿景，因为当前的变通方案仍然是截图、粘贴提示词和手动刷新状态。机会：直接。
在不悄悄改变行为的前提下改进技能的受治理学习¶
@openclaw 指出 (60 个赞，9 条回复，5,051 次浏览，37 次收藏) 认为，智能体应把重复工作转成可以修改、应用或拒绝的提案，而不是直接变成线上行为。@omarsar0 指出 (130 个赞，22 条回复，9,487 次浏览，223 次收藏) 则把 SkillOpt 指向一种更正式的同类直觉：不是靠一次性重写提示词，而是通过有边界的修改和留出集验证来优化技能。两者合在一起，说明大家想要的是可测量、可回滚、可跨智能体和 harness 导出的技能学习。今天已经有零散组件，但它们分散在不同产品和研究成果里。机会：直接且竞争激烈。
能在 CLI、桌面、Slack 和语音之间保留会话的共享智能体工作区¶
@akshay_pachaar 表示 (58 个赞，9 条回复，8,291 次浏览，77 次收藏) 指出，Hermes Desktop 真正重要的地方，是同一套会话、记忆和技能能从 CLI 延续过来，而不会在新界面里重置。@codyplof 展示了 (38 个赞，11 条回复，3,072 次浏览，44 次收藏) 进一步说明了这在实践中的意义：他已经在 Slack、cron 和 Mac Mini 配置中使用 Hermes，并正准备做一个拥有完整组织上下文的共享团队智能体。@Daniel_Farinax 补充说 (44 个赞，5 条回复，1,509 次浏览，19 次收藏) 则把语音展示为另一种用来调度和生成智能体的控制界面。这一需求既紧迫又务实，因为团队已经想要一个持久存在的工作界面，而不是彼此互不记忆的聊天框、机器人和桌面应用。机会：直接且竞争激烈。
面向垂直领域智能体、更便宜也更安全的 harness 层¶
另一个明确诉求并不是再来一个通用模型发布，而是一个能让垂直领域智能体足够便宜、足够安全、因而值得长期保留的 harness 层。@SeanZCai 转述了 (155 个赞，6 条回复，24,816 次浏览，137 次收藏) 转述了 Harvey 的结果：混合法律智能体和后训练开放模型，能够实质性地推动成本—质量前沿。@CommandCodeAI 将其变成了 (93 个赞，3 条回复，111,603 次浏览，59 次收藏) 把定价压力直接做成了可见的产品卖点，而 @Dagnum_PI 将其表述为 (65 个赞，5 条回复，1,244 次浏览) 则把安全性和可审计性做成了位于智能体与模型之间的独立中间件层。这个需求很现实，而且已经被部分满足，但解决方案仍分散在定价方案、路由技巧和早期安全层之间。机会：直接且竞争激烈。
4. 正在使用的工具和方法¶
| 工具 | 类别 | 情绪 | 优势 | 局限 |
|---|---|---|---|---|
| Harness engineering | 方法 | (+) | 将记忆、技能、协议、评测和可观测性从底层模型中分离出来 | 如果运行时不能重放，就很容易把过多逻辑埋进编排层 |
| 构建高效智能体 | 参考 / 工作流 | (+) | 是工作流、智能体、工具和 MCP 的严肃起点 | 只提供指导；团队仍需自行搭建运行时、评测和策略层 |
| SkillOpt | 技能优化 | (+) | 有边界的修改、留出集验证，以及可在 Codex 与 Claude Code 之间迁移 | 集成工作仍处于研究阶段；依赖有评分的 rollout 和验证配置 |
| Skill Workshop | 技能治理 | (+) | 提案优先的技能创建、修订/应用/拒绝流程，以及支持文件扫描 | 增加了人工审核摩擦，目前主要聚焦工作区范围内的技能 |
| Agent Signals | 上下文 / 记忆原语 | (+) | 通知、状态和响应式信号让智能体能看到不断变化的外部状态 | 目前仍处于 Alpha 阶段，且暂时仅适用于 Mastra |
| Hermes Desktop | 智能体运行时 / UI | (+) | 共享会话、工件、远程网关、语音，以及可视化的工具调用可见性 | 部署和远程模式相关问题在回复里仍然很快就会出现 |
| Claude Code workflow stack | 工作流 / IDE | (+/-) | 项目、CLAUDE.md、记忆、技能、命令、hooks、MCP、子智能体和例程构成了清晰的操作模型 | 记忆版本控制和并发语义仍不清楚 |
| Codex external marketplaces | 技能市场 | (+) | 可导入基于仓库的技能，并在产品 UI 中呈现出来 | 强依赖特定生态，效果也取决于仓库目录质量 |
| Hybrid open-model legal agents | 模型路由 / 后训练 | (+) | GLM/Kimi 加前沿顾问，改善了真实垂直领域里的成本—质量前沿 | 回复质疑其护城河究竟来自微调，还是工作流数据 |
| Command Code Go plan | 定价 / 编码智能体服务 | (+/-) | 低价入门档，以及多模型支出路由 | 宣传口径超过了已公开披露的技术细节 |
| Gate AI | 安全中间件 | (+/-) | 提示词注入筛查和防篡改审计轨迹 | 仍处于早期访问阶段，公开实现细节较少 |
| Covenant | 智能体底座 / 记忆 | (+/-) | 共享身份、权限、记忆、审计、结算和分层记忆 | 在这组数据里，信号仍主要停留在示意图层面 |
总体来看，大家更偏好把能力外置到技能、信号、记忆层和安全中间件中的工具，而不是把一切藏进一个提示词大杂烩里。迁移路径也很清晰：从只依赖前沿模型的配置，转向混合路由；从临时技能文件，转向经过审核和优化的技能资产；从只在终端里使用，转向跨桌面、Slack 和语音的共享界面。竞争分化同样明显：研究项目在推进可测量的技能提升，产品团队在打包操作界面和市场，而安全或上下文供应商则试图成为智能体与模型之间的必经中间件。
5. 人们正在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| Skill Workshop | OpenClaw | 把智能体从重复工作中学到的经验，变成可审查的技能提案，再决定是否转为线上行为 | 静默自我修改的技能风险高，且难以审计 | PROPOSAL.md / SKILL.md workflow、Control UI、CLI、Gateway、支持文件扫描 |
已发布 | 博客, 文档 |
| Agent Signals | @tylbar / Mastra | 为智能体增加通知、状态和响应式信号 | 外部状态、提醒和行为引导仍然过于依赖手动传递 | @mastra/core@1.39.0、Studio、Code、浏览器集成、Working Memory |
Alpha | 推文 (29 个赞，9 条回复，5,848 次浏览) |
| Everything Claude Code | affaan-m | 可选择安装的 Claude Code 超级栈，包含 38 个智能体、156 项技能、72 条命令和 AgentShield 测试 | 一个通用编码智能体对规划、审查、调试和安全来说过于粗糙 | 专家型智能体、技能包、命令、安全扫描器、选择性安装配置 | 已发布 | 仓库, 推文 (28 个赞，3 条回复，2,112 次浏览，38 次收藏) |
| Codex 的 React Native 技能市场 | Callstack | 将基于仓库的移动开发技能导入 Codex，并在可浏览的 UI 中提供 | 通用编码智能体会遗漏移动开发特有的审查、升级和 QA 工作流 | callstackincubator/agent-skills、GitHub 市场导入、Codex UI |
已发布 | 仓库, 推文 (11 个赞，1 条回复，1,181 次浏览，8 次收藏) |
| Hermes Desktop | Hermes 团队 | 为与 CLI 相同的智能体核心、会话、记忆、技能和工件提供桌面界面 | 仅限终端的智能体隐藏了状态，持续操作也很笨重 | 共享智能体核心、远程网关、工件面板、cron、语音、拖放文件 | Beta | 推文 (58 个赞，9 条回复，8,291 次浏览，77 次收藏) |
| Grok Voice 桌面编排器 | @Daniel_Farinax | 可生成并管理大量桌面智能体的定制语音层 | 桌面多任务处理和编排仍过于手动 | 定制 macOS 应用、400+ 工具、Grok Build、记忆、调度、通知 | Alpha | 推文 (44 个赞，5 条回复，1,509 次浏览，19 次收藏) |
| Gate AI | @Dagnum_PI | 位于编码智能体与模型端点之间的安全层 | 提示词注入和缺失审计日志仍阻碍智能体部署 | 请求筛查、提示词注入检测、防篡改审计轨迹 | Beta | 推文 (65 个赞，5 条回复，1,244 次浏览) |
| Command Code Go plan | @CommandCodeAI | 面向多模型编码智能体使用场景的低成本入门档 | 前沿模型使用成本阻碍更广泛的日常采用 | DeepSeek V4 Pro、Qwen 3.7 Max、MiniMax M3、用量路由、工具调用修复 | 已发布 | 推文 (93 个赞，3 条回复，111,603 次浏览，59 次收藏) |
| Harvey 混合法律智能体 | Harvey + FireworksAI | 将开放模型路由到前沿顾问，并对法律专业模型做后训练 | 只依赖前沿模型的法律智能体，在重复性专家工作流上成本仍然过高 | GLM 5.1 worker、Opus 4.7 advisor、Kimi 2.6 SFT、Legal Agent Benchmark | Beta | 讨论推文 (155 个赞，6 条回复，24,816 次浏览，137 次收藏) |
| Covenant | @OpenCovenant | 面向身份、权限、记忆、审计、结算和分层记忆的本地底座 | 各种框架都在重复造相同的共享智能体服务 | 本地共享服务，以及工作记忆、情景记忆和长期记忆分层 | Alpha | 基础 (26 个赞，11 条回复), 记忆 (30 个赞，15 条回复) |
SkillOpt、Skill Workshop、Callstack 的市场流程，以及 Everything Claude Code，都指向同一种构建模式：技能不再只是提示词，而是带有优化、审核、分发和选择性安装界面的全生命周期资产。它们的关键差异在于介入时点不同：SkillOpt 介入训练阶段，Skill Workshop 介入审批阶段，Callstack 介入分发阶段，ECC 则介入打包组合阶段。
Hermes Desktop 和 Grok Voice 的演示则展示了第二种模式：操作界面本身正在变成产品范围的一部分。@codyplof 补充说 (38 个赞，11 条回复，3,072 次浏览，44 次收藏) 表示，他已经在 Mac Mini 上、Slack 里使用 Hermes，并把它当作共享团队幕僚长智能体的雏形，这说明界面问题已经不再是假设性问题。
Harvey、Gate AI、Command Code 和 Covenant 则展示了接下来差异化会往哪里走：路由、安全、定价，以及共享基础设施。@SeanZCai 转述了 (155 个赞，6 条回复，24,816 次浏览，137 次收藏) 通过 Harvey 更低成本的混合法律智能体结果，给出了当天最清晰的垂直领域数据点；而 Gate AI 和 Covenant 则把审计轨迹、共享记忆或权限层本身做成了产品。
6. 新近且值得关注¶
SkillOpt 让围绕技能的讨论从纯理念层面变得可测量¶
@omarsar0 提到了 (130 个赞，22 条回复，9,487 次浏览，223 次收藏) 是这组数据里最清晰的硬数据成果之一：一篇论文和公开项目页面提出，技能可以通过有边界的文本修改和留出集验证来优化，然后迁移到直接聊天、Codex 和 Claude Code 中。这一点值得关注，因为这组数据中大多数关于技能的讨论都集中在打包和分发上；SkillOpt 则加入了基准语言、由失败驱动的迭代，以及明确的验证闸门。
Harvey 给出了当天关于混合智能体经济性的最强垂直验证¶
@SeanZCai 强调了 (155 个赞，6 条回复，24,816 次浏览，137 次收藏) 转述 Harvey 的说法：以 GLM 5.1 为 worker、Opus 4.7 为 advisor 的混合法律智能体，在质量和成本上都优于 Opus；而一个经过后训练的 Kimi 2.6 法律专家模型在成本上也表现更优。这一点值得关注，因为它把“harness 比模型更重要”这一论点，推进到了特定领域基准，而不只是通用构建者讨论。
Everything Claude Code 展示了完整智能体栈正以多快的速度被产品化成可安装套件¶
@VaibhavSisinty 强调了 (28 个赞，3 条回复，2,112 次浏览，38 次收藏) 介绍了一个公开的 Claude Code 栈：它打包了 38 个智能体、156 项技能、72 条命令，以及一个带有 1,282 项测试的安全扫描器，同时仍建议用户按需选择安装。这一点值得关注，因为它把规划、审查、调试和安全的专业化能力打包进了一个可安装界面，而不是让用户自己拼装整套栈。
7. 机会在哪里¶
[+++] 事件驱动上下文与持久记忆编排 — Jose Valim 对 MCP 推送式上下文的请求、Mastra 的 Agent Signals、codyplof 关于上下文串扰的讨论，以及 Covenant 对分层记忆的框架，都指向同一个缺口：智能体仍缺少一种标准、可检查的方式，在正确时间接收正确状态。
[+++] 技能全生命周期工具链 — SkillOpt、Skill Workshop、Callstack 的 Codex 市场流程，以及 Everything Claude Code 表明，如今技能需要的已不只是创作，还包括优化、治理、打包和选择性安装路径。市场上已经有若干组件，但还没有占据主导地位的端到端全流程。
[+++] 面向编码智能体的安全与审计中间件 — Gate AI、Skill Workshop 的审批流，以及讨论串层面反复出现的审计轨迹、可重放运行时和提示词注入防护需求，都说明在智能体与模型端点之间存在明确的产品楔子。
[++] 跨界面操作层 — Hermes Desktop、基于 Slack 的共享智能体，以及语音驱动的桌面编排，都表明市场需要一个持久存在的工作界面，能跨终端、GUI、聊天、远程服务器和日程运行，而不必重置状态。
[++] 面向垂直领域智能体的混合路由与后训练 — Harvey 的法律智能体结果、Command Code 的定价姿态，以及 codyplof 因成本而切换模型的做法，都表明通过路由、专业化和更紧的评测闭环，仍有机会在经济性上超越只依赖前沿模型的方案。
8. 要点¶
- 讨论仍在收敛到 harness，而不是裸模型；真正耐久的层是 harness。 @DataChaz 指出 (272 个赞，25 条回复，36,443 次浏览，415 次收藏) 认为，能产生复利的是上下文工程、工具设计、评测、MCP 和 harness 思维，而回复随即把这件事落到了恢复机制和审计轨迹等具体要求上。
- 技能正在变成带有优化、审核和分发步骤的受管资产。 @omarsar0 提到了 (130 个赞，22 条回复，9,487 次浏览，223 次收藏) 展示了基于基准的技能优化，而 @openclaw 展示了 (60 个赞，9 条回复，5,051 次浏览，37 次收藏) 则表明，团队也希望在这些技能上线前先经过提案和审批闸门。
- 智能体运行正从单一终端扩展到共享、持久的操作界面。 @akshay_pachaar 描述了 (58 个赞，9 条回复，8,291 次浏览，77 次收藏) 展示了一个能在 CLI 与 VPS 执行之间共享状态的桌面界面，而 @codyplof 补充说 (38 个赞，11 条回复，3,072 次浏览，44 次收藏) 则表明，团队已经在 Slack 和共享 Mac Mini 配置中用上了这一模式。
- 上下文工程正在变成运行时设计，而不只是提示词技巧。 @josevalim 指出 (13 个赞，6 条回复，744 次浏览) 提出了推送式提示词上下文，而 @tylbar 已推出 (29 个赞，9 条回复，5,848 次浏览，21 次收藏) 则把状态、通知和响应式信号展示为一条具体的实现路径。
- 成本竞争正在转向路由、后训练和 harness 效率。 @SeanZCai 强调了 (155 个赞，6 条回复，24,816 次浏览，137 次收藏) 展示了 Harvey 的混合法律智能体结果，而 @CommandCodeAI 宣传为 (93 个赞，3 条回复，111,603 次浏览，59 次收藏) 则把廉价的多模型使用档位做成了核心产品特性。
- 安全与审批层正在成为围绕编码智能体的一类基础产品。 @Dagnum_PI 将其定位为 (65 个赞，5 条回复，1,244 次浏览) 把 Gate AI 作为抵御提示词注入并提供审计轨迹的中间件，这也呼应了更广泛的讨论串诉求：在赋予自主系统更多权限之前，必须先给出可见、可核验的执行留痕。