Twitter AI Agent - 2026-08-02¶
1. 人们在讨论什么¶
1.1 循环、图结构、运行框架与评估工作变得更偏运营化了 (🡕)¶
最强的技术主题，是大家不再只给智能体系统的各层起名字，而开始明确说明这些层在生产环境里应该怎么运作。相比 8 月 1 日强调上下文、图结构和运行框架这些词汇，8 月 2 日给出了更具体的控制点：触发器、检查器、停止规则、世界状态验证，以及轨迹评判。整场讨论听起来不再像提示词建议，而更像操作者在定义一次智能体运行该如何开始、如何停止、如何恢复，以及如何被评分。
@milesdeutscher 分享了（34 点赞，23 回复，16,963 浏览，53 收藏）一个由 6 个部分组成的 Claude Code 循环：触发器、执行器、检查器、停止规则、记忆和技能。配图之所以重要，是因为它让循环工程变得可以检查，而不再像某种玄学：检查器是一个独立的评分步骤，停止规则会给重试次数和预算加上上限，而记忆则会跨运行持久存在。最有用的回复进一步强化了这一点：大家最容易跳过的，恰恰就是检查器和停止规则，然后才会疑惑为什么循环开始漂移，或者为什么它会一直跑个没完。
@Vtrivedy10 认为（27 点赞，1 回复，3,045 浏览，39 收藏），智能体评估可以分成两桶：先验证环境的最终状态，再评判轨迹里有没有作弊、浪费、成本过高或延迟过大。配图把这个区分讲得很清楚：上面是 before-state / after-state verifier，下面是对更省还是更浪费的轨迹对比。这比一句泛泛的“评估很难”强得多，因为它点明了容器化世界、验证器的盲点，以及这样一个事实——终态在技术上正确，并不等于这次运行本身就是一次好运行。
@elune0x 写道（53 点赞，9 回复，3,418 浏览，36 收藏），提示词只是“提出一个动作”，真正决定这个动作能不能活下来的，是控制栈。那条帖子把失败拆成了循环问题（重复、重试策略、预算）、图结构问题（路由、汇合、检查点、记忆切换）和运行框架问题（权限、副作用、回滚）。这个分类和数据集中其他更实操的图示很契合，所以它最后落地成了一个有用框架，而不是另一句口号。
@Priyannkaaaa 表示（583 点赞，26 回复，20,277 浏览，61 收藏），DeepSeek 正在基于自家的 Harness 框架准备一款专门的编程智能体 DeepSeek Code，具备规划、工具使用、代码执行、记忆、仓库感知，以及长时程工作流。即便讨论串里还没有公开仓库，这条推文依然重要，因为它显示“运行框架”这套语言已经从讨论里溢出，开始变成一个直接和 Claude Code、Codex 竞争的产品类别。
讨论要点： 循环和评估类帖子下的回复，异常具体。大家讨论的不是怎么写更好的提示词，而是检查了什么、什么才算有效终态、怎样在循环浪费算力前把它停下来，以及为什么复盘时默认该先怪控制栈，而不是先怪模型。
与前日对比： 8 月 1 日建立了上下文、循环、图结构和运行框架工程的词汇表。到了 8 月 2 日，这套词汇被进一步推进成运行规则、图示和发布计划。
1.2 计算机使用型智能体进一步靠近安全桌面与本地 / 云混合配置 (🡕)¶
第二个主要主题，是执行环境。构建者讨论的已经不只是浏览器智能体或抽象的自主性，而是远程桌面、审批流程、本地 GPU 配置，以及可共享、已注册的计算节点。这比 8 月 1 日那种宽泛的“智能体将走出聊天和 IDE”更往前走了一步，落到了具体的工作站与基础设施选择上。
@zentalksai 表示（65 点赞，17 回复，2 次引用，3,572 浏览），把 AI 智能体放到你电脑上的真正问题是信任；随后它把 Sai 的私有远程桌面、审批闸门，以及在笔记本合上后仍能继续运行的能力，当成对这个问题的回应。配图把差异点写得很直白：持续在线执行、BYOD 或专用远程桌面、完整 GUI 能力，以及不依赖 API 集成的跨工具工作。Simular 的公开产品页重复了这 4 个点，而底层的 Agent-S 仓库则写明，Agent S3 是首个在 OSWorld 上以 72.60% 超越人类表现的系统，这也让这条推文的分量高过一般产品宣传。
@alecqfong 展示了（89 点赞，16 回复，1 次引用，6,107 浏览，22 收藏）一套本地栈：用 DGX Sparks 负责具体执行和子智能体，用 DGX Stations 做规划和顾问，再用 Brev 负责联网、编排以及一个持续在线的云端智能体。最有信息量的图片，不是那张硬件“摆拍”，而是 Brev 仪表盘——它展示了本地已注册计算节点，与云端 head 节点和 observability 节点一起出现在同一个网状环境里。NVIDIA 公开的 DGX Station to Brev 指南也确认，这条 registered-compute 流程本来就是为了让本地硬件能够被远程访问、共享，并作为受管的 Brev 容量出现。
@VKazulkin 点出了（6 点赞，845 浏览，14 收藏）AWS MCP Server 新增的 OAuth 支持。配套的 AWS 安全文章之所以重要，是因为它补上了浏览器登录、IAM 联邦与 Identity Center 支持、token 内省与撤销、动态客户端注册，以及无头 OAuth 路径。这还不是完整的安全方案，但它是一个非常具体的信号：智能体工具访问正在被拉回标准身份与治理控制中。
讨论要点： 质疑并不是反智能体。大家在意的是工作到底跑在哪里、用户不在时审批会怎样排队、远程机器到底是不是真的可以随时销毁，以及在“本地栈”变成真实运行环境之前，还要粘多少胶水代码。
与前日对比： 8 月 1 日拓宽的是智能体作用面，涉及文档、媒体和小部件。8 月 2 日则把执行层讲得更具体：远程桌面、已注册 GPU 机器，以及受治理的工具访问。
1.3 技能与角色化方法开始成为智能体能力的可复用单元 (🡕)¶
第三个主题是，大家越来越倾向于把智能体描述成“角色上下文 + 可复用方法”的组合，而不是裸模型。昨天的报告已经提到可移植技能和迁移工具；今天则更进一步，走向技能目录、按部门组织的技能库，以及决定该由哪个智能体接手任务的路由层。
@milesdeutscher 重点提到了（65 点赞，22 回复，17,850 浏览，124 收藏）Nous Research 的 Hermes Skills Hub——一个覆盖 200+ 类别、9 万项社区技能的目录。现在的 Skills Hub 页面写的是“正在从所有注册表抓取 88k+ 项技能”，而 Hermes Agent README则把这个目录接到一套更大的系统里：内置技能创建、记忆、子智能体，以及跨平台运行。最好的回复，也是最尖锐的提醒：如果策展做不好，9 万个技能大部分都只是噪音。
@coreyganim 认为（41 点赞，7 回复，2,278 浏览，37 收藏），当一个智能体同时拥有业务职能和这项职能的一组可重复方法时，它的价值会高得多。真正有用的部分，是他给出的组合公式：业务上下文 + 可复用方法 + 工具 + 边界 + 验证。回复又补上了一个限定：如果把组织架构照搬得过于字面化，就会错过跨职能工作流，而这恰恰是多智能体系统最容易藏住所有权问题的地方。
@startupideaspod 描述了（118 点赞，14 回复，12,568 浏览，143 收藏）Buzz——一个轻量的多智能体表层，实际价值在于把每个智能体固定到一个模型上，再由一个 chief routing agent 决定任务分给谁。这条帖子之所以更有价值，是因为它很坦率地承认了当前限制：重复性工作流仍然跑不稳，中继会增加延迟，而对于严肃的软件工作来说，产品仍处于 alpha。正因为它把技能、角色与路由捆在一起打包，又明确暴露局限，这反而成了观察这条产品线的一份很好公开样本。
讨论要点： 回复把策展和所有权当成真正的瓶颈。大家没那么担心智能体能不能“做成一次”，而是在担心一个技能库能不能在多个智能体之间始终保持有序、可限定作用域，而且可验证。
与前日对比： 8 月 1 日强调的是迁移和共享记忆。8 月 2 日则把重点转向技能目录、部门级方法库，以及路由器式的所有权分配。
1.4 “软件丰裕”的乐观情绪浮现，同时人类角色的定义也更清晰了 (🡕)¶
宏观层面最宽的一条线索，并不是悲观论，而是一种更具体的说法：智能体正在加速软件产出，同时把人的价值往判断、优先级和产品品味这些更高层的位置上推。这一点之所以重要，是因为它把那些关于循环和运行框架的战术性帖子，连到了一个更大的信念上——工作不会直接消失，而是在改变形状。
@dabit3 写道（253 点赞，33 回复，7 次引用，16,471 浏览，178 收藏），“软件丰裕”正在变成现实：公司交付的 PR 数量增长了 10-20 倍，迁移和依赖升级这类可重复任务正是智能体擅长的，而真正越来越稀缺的差异化能力，则是判断、好奇心、上下文和品味。回复没有只是鼓掌，而是给这个论点补充了更多纹理：有操作者指出，下一个瓶颈很可能会落到 QA 和产品规划上；也有人认为，当所有人都能多交付 20 倍代码时，同质化也会随之上升。
讨论要点： 这条讨论串比架构类帖子争议更大，但分歧点并不是智能体是否已经改变工程工作，而是新的瓶颈到底会落在哪里。
与前日对比： 8 月 1 日的重心主要落在系统设计和企业控制平面上。8 月 2 日虽然仍有这些内容，但同时也带出了更明确的“劳动与手艺”论点：人最终还要负责什么。
2. 令人困扰的问题¶
对计算机使用型智能体来说，信任与隔离仍然是第一道反对理由¶
严重程度：高。最清晰的恐惧信号，并不是模型质量，而是智能体跑在哪里、能碰到什么。@zentalksai 说，把智能体放在你自己的机器上，问题在于它就在你的文件、登录状态和日常桌面环境旁边；随后它把 Sai 的远程工作区和审批流当成修复方案。回复立刻去验证这个说法，而不是为它叫好：大家追问审批是不是只会在用户离开时不断堆积，以及远程工作区到底能不能在每个任务后真正销毁。@VKazulkin 则从更具体的治理层面给出了一个回应：AWS MCP Server 的 OAuth、token revocation 和 token introspection，说明信任问题正从产品叙事继续往真实的认证基础设施里推进。这值得围绕它构建产品，因为这种反对意见往往在任务还没开始前就出现了。
长时程工作流仍然会漂移、重复劳动并浪费 token¶
严重程度：高。Buzz 那条讨论串把最实际的失败模式说得非常直白：@startupideaspod 说，搭起来很容易，但重复性工作流“还远远谈不上跑得很好”；而一条来自正在运行 400+ 个智能体的回复则指出，难点都在 setup 之后：漂移、重复做昨天做过的事，以及完全记不住之前失败了什么。@milesdeutscher 从循环侧描述的是同一个问题：如果缺少 checker 或 stop rule，智能体要么会误以为自己已经做完，要么就会无限失败却不升级。@elune0x 对重复行为的抱怨也落在这里：如果结果已经不再改善，运行却还在继续，那就是循环失败了。这非常值得围绕它构建产品，因为多条帖子从不同角度会合到了同一个诊断上。
智能体评估仍然比人们想象中更难¶
严重程度：中。@Vtrivedy10 非常具体地指出，一次成功的智能体运行必须被评判两次：一次看世界最终变成了什么状态，一次看它是沿着怎样的轨迹走到那里的。难点在于，有效终态可能比验证器预期的更宽；而糟糕轨迹即便靠作弊、循环或浪费成本，也有可能抵达一个表面上正确的结果。这和 @elune0x 的说法是对齐的：评估器、预算、审批和回滚路径，本来就住在模型之外。这种痛点是真实的，但它更像工具和测量能力的缺口，而不是一个彻底走不通的死局。
3. 人们期望的功能¶
面向计算机使用型智能体的安全、可销毁工作区¶
实际需求。Sai 的帖子、底下的回复，以及 AWS OAuth 的发布，都指向同一个缺口：用户想要一个能横跨桌面软件行动的智能体，但不想把自己的日常机器和无管控凭据直接交给它。人们显然想要的是一个可销毁的远程工作区，带审批、可审计访问，以及标准身份控制。机会：直接。
面向长时程工作的更好 checker 与 evaluator 基础设施¶
实际需求。@milesdeutscher 的循环图，以及 @Vtrivedy10 的评估图，都暗示了同一个缺失层：团队需要更容易定义成功、捕获循环行为，并容纳“不同但依然有效”的终态。Buzz 在重复性工作流上的问题，则让这种需求显得不是学术讨论，而是迫在眉睫。机会：直接。
具有更清晰所有权边界的策展型技能系统¶
实际需求。Hermes Skills Hub 说明供给侧正在爆炸式增长，但那条讨论里最好的回复也点出了问题：没有策展的 9 万个技能，大多只是噪音。@coreyganim 则从组织层面补上了同样的约束：技能必须有职能所有权、边界和验证，否则就会退化成即兴发挥。机会：竞争型。
把私有硬件当成一等容量的本地 / 云混合编排¶
新兴需求。本地栈那条帖子并不是在索要新模型，而是在展示一种愿望：把本地 GPU 机器、云节点、可观测性和编排放进同一个控制平面。证据仍然偏早期，但 Brev 的 registered-compute 模式说明，一部分构建者确实想要一种跨家庭、办公室和云端的智能体基础设施，而不想把这件事做成一次性的系统工程。机会：新兴。
4. 使用中的工具与方法¶
| 工具 | 类别 | 评价 | 优势 | 局限 |
|---|---|---|---|---|
| DeepSeek Code / Harness | 编程智能体 | (+/-) | 承诺提供仓库感知、记忆、规划、工具使用和长时程工作流 | 在这份数据里仍只是已宣布的封闭测试版；讨论串里还没有公开产物 |
| Buzz | 多智能体工作区 | (+/-) | 模型固定角色、路由器式 chief agent，以及可复用现有 Claude Code skills | alpha 成熟度、来回中继带来的延迟，以及重复性工作流偏弱 |
| Hermes Skills Hub | 技能注册表 | (+) | 覆盖多家厂商的大型目录；还能接到一个可创建技能并生成 subagents 的运行时 | 当目录规模非常大时，策展质量仍是个公开问题 |
| Sai | 计算机使用工作区 | (+/-) | 安全远程桌面、审批、持续在线执行，以及无需 API 的跨工具 GUI 操作 | 信任最终取决于远程机器和销毁保证，而不只是营销文案 |
| Brev registered compute | GPU / 编排基础设施 | (+) | 让本地 DGX 类硬件能够和云节点一起，作为受管、可共享容量出现 | 需要真实硬件、注册成本，以及不少基础设施胶水 |
| AWS MCP Server OAuth | 身份验证 / 治理 | (+) | 标准登录、IAM federation、撤销、内省，以及动态客户端注册 | 它解决的是访问控制，而不是更高层的记忆、审批或工作流策略 |
| Claude Code 循环模式 | 方法 | (+) | 通过 trigger、checker、stop rules、memory 和 skills，让长时程自动化变得可读可检 | 如果 checker 或停止条件设计得弱，依然很容易配错 |
| 循环 / 图结构 / 运行框架工程 | 方法 | (+) | 把时间、状态和副作用失败拆进可调试的不同层里 | 如果没有图示、评估器和工具配套，它仍可能停留在抽象层 |
| 环境状态 + 轨迹评估 | 评估方法 | (+) | 同时衡量最终结果，以及智能体是如何抵达结果的，包括作弊与成本 | 跑起来成本高，而且很难定义得足够宽，去覆盖那些同样有效的替代结果 |
当一个工具增加了明确的控制表层——审批、路由、已注册基础设施、checker 或撤销——整体满意度就会更高。最常见的权宜方案，是做分层：用更便宜或更轻的模型处理窄任务，把更重的模型留给难任务，再配一个单独的路由器或验证器来保持系统诚实。最清晰的迁移动态，并不是为了切换供应商而切换，而是从“单智能体即兴发挥”，转向技能目录、明确所有权角色，以及受治理的执行环境。
5. 人们在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| DeepSeek Code | DeepSeek | 一款专门的编程智能体，提供规划、工具使用、代码执行、记忆，以及带仓库感知的工作流 | 试图把 DeepSeek 的模型线直接变成编程智能体竞品，而不只是原始模型 | Harness framework、V4-Flash 评估栈、仓库感知记忆 / 工作流 | 测试版 | 推文 |
| Buzz | Jack Lipstone and team | 一个多智能体工作区，带模型固定角色和 chief routing agent | 让小团队无需自建基础设施，也能快速协调专门化智能体 | Claude Code harness、global skills、Fable / Sonnet 角色固定、server relay | Alpha | 推文 |
| Hermes Skills Hub | Nous Research | 挂接在 Hermes 智能体运行时上的大型技能目录 | 让技能能在多种智能体配置间可移植、可搜索、可复用 | Hermes Agent runtime、skills registry、subagents、memory、cross-platform gateway | 已发布 | 文档，推文 |
| Sai | Simular | 一款在远程工作区里运行的安全计算机使用智能体，带审批与完整 GUI 访问 | 试图在不直接暴露用户日常机器的前提下，让桌面自动化变得可用 | 安全远程工作区、GUI 自动化、审批闸门、持续在线执行、Agent S 底座 | 测试版 | 站点，推文 |
| KrillinAI | Krillin AI team | 一条端到端的视频翻译、配音与渲染流水线，可由人或智能体来编排 | 把原本杂乱的本地化工作流打包成分阶段 CLI 和适合技能编排的自动化表层 | Go、Whisper、LLM translation、TTS、分阶段 CLI、JSON manifest、按阶段划分的技能 | 已发布 | 仓库，推文 |
最强的构建模式，不再是“又一个聊天机器人”，而是把执行环境、可复用技能和多步骤工作流打包起来，让智能体在第一条提示词之后也能继续干活。DeepSeek Code 和 Buzz 解决的是编程工作区这一侧的问题，而 Hermes Skills Hub 和 KrillinAI 则把可复用技能与稳定契约本身做成了产品表层。Sai 之所以特别突出，是因为它给电脑操作包了一层信任叙事：独立工作区、审批闸门，以及后台持续运行，而不是直接常驻在用户的笔记本上。
这些构建在整份数据里反复被触发的原因很清楚：人们希望智能体是可复用的、作用域明确的、可持续运行的。与此同时，他们并不想一直盯着循环，不想每次都从头重建技能，也不想为了自动化就把自己的主力机器和凭据暴露出去。
6. 新动态与亮点¶
DeepSeek 让运行框架工程看起来像一场产品竞赛，而不只是话语潮流¶
最值得注意的竞争信号，是 DeepSeek Code 的预览，因为它把仓库感知、记忆、规划和长时程工作流定义成一款一流编程智能体的基本配置，而不是围绕强模型加上的附属功能。(来源)
Hermes 把技能推到了接近“市场规模”的层面¶
Hermes Skills Hub 之所以重要，是因为公开页面和仓库都把技能描述成一个跨注册表、可搜索、可复用的层，而不只是个人提示词文件夹。回复里最强的反驳，也恰恰是最关键的提醒：现在策展的重要性，已经和库存数量一样高了。(来源)
AWS 把标准 OAuth 治理带进了 MCP 访问¶
AWS MCP Server 的 OAuth 支持之所以突出，是因为它给智能体工具访问补上了常规身份基础设施——浏览器登录、federation、撤销、内省，以及无头认证——这是一个具体的治理进展，而不是模糊的安全愿景。(来源)
KrillinAI 展示了非编程工作流如何被做成智能体就绪流水线¶
KrillinAI 值得注意，是因为配套仓库并不只是个 demo 应用。它暴露出了分阶段 CLI、manifest 输出，以及按阶段划分的技能，服务的是一个真实的本地化工作流，横跨转录、翻译、配音和渲染。(来源)
7. 机会在哪里¶
[+++] 安全的计算机使用工作区 —— Sai、AWS MCP OAuth，以及那些高度围绕信任展开的回复，都指向同一个缺口：用户想要能操作桌面的智能体，但只愿意把它们放进带审批、可撤销、凭据边界清晰的可销毁工作区里。
[+++] 面向长时程智能体的 checker 与 evaluator 基础设施 —— 循环与评估类帖子都指向缺失的原语：成功测试、停止规则、轨迹评分，以及对“不同但有效”结果的处理。这种需求也在 Buzz 的重复性工作流失败里直接暴露出来。
[++] 技能策展、路由与所有权层 —— Hermes Skills Hub、Corey Ganim 把“职能 + 方法”捆起来的说法，以及 Buzz 的总路由智能体，都说明下一层产品机会不在于再堆原始能力，而在于更好地组织可复用技能，并更清晰地指定谁负责什么。
[+] 本地 / 云混合的智能体运维 —— Brev 注册本地算力这条路线仍然偏早期，但它指向了一个逐渐扩大的细分市场：人们想要一种智能体基础设施，能把私有 GPU 硬件和云节点视作同一个可控资源池。
8. 要点总结¶
- 智能体工程话语继续从提示词转向控制表层。 最有用的帖子都在点名那些具体杠杆：checker、stop rules、环境状态验证，以及轨迹评分，而不是再去追问更好的提示词措辞。(来源)
- 对计算机使用型智能体来说，信任正在变成真正的门槛约束。 关于桌面智能体最强的一组讨论，不在于原始自主性，而在于远程工作区、审批队列，以及可销毁会话。(来源)
- 可复用技能正被当成基础设施来对待，但策展仍落后于库存扩张。 Hermes Skills Hub 展示了目录规模，而回复立刻指出，真正的价值如今落在挑选和组织正确技能上。(来源)
- 本地 / 云混合智能体栈已经具体到能晒出架构截图，而不只是空泛愿景。 本地 DGX 加 Brev 的配置，是最清楚的信号之一：一部分构建者希望智能体容量能够横跨私有硬件与云控制平面。(来源)
- 在这份数据里，人类角色被重新抬高定义，而不是被直接抹掉。 最高信号的宏观讨论认为，智能体会吃掉可重复的工程杂务，而判断、优先级和品味会变得更有价值。(来源)