Twitter AI Agent - 2026-08-22¶
1. 人们在讨论什么¶
1.1 生产级智能体工作,关键在于 harness、队列和审查闭环(🡕)¶
最强的一组讨论把智能体构建视为一个操作系统问题,而不是写提示词的小技巧。多条高信号帖子都收敛到同一组要素:能检查轨迹的评测、能扛住慢速 I/O 的队列和 worker、不会重复产生副作用的重试机制,以及能留下可核查记录的审查闭环。相比 8 月 21 日对技能和上下文封装的强调,8 月 22 日又往下挖了一层,转向保障长时运行智能体可靠性的底层机制。
@AndrewYNg 分享 (3,873 个赞,85 条回复,217,069 次浏览,6,473 次收藏) 发布了一张构建和部署 AI 应用的技能地图,但这条讨论里最具体的观点其实出现在回复中。一条回复认为,只看结果的评测无法判断智能体到底是推理过程干净,还是只是碰巧做对;另一条则指出,真正的生产工作流需要触发器、事实来源、验收测试、审批负责人、回滚机制和审查指标。
@freeCodeCamp 重点介绍 (159 个赞,6 条回复,8,860 次浏览,143 次收藏) 发布了一门面向生产环境的多智能体 PR 审查课程,围绕 LangGraph 编排、GitHub Webhook、Redis 队列、验证智能体和置信度评分展开。回复马上把课程宣传中隐含的那些脏活累活点了出来:重复 webhook、部分执行、重试,以及不能默认相信“高置信度”的审查结果。
@kmeanskaran 认为 (81 个赞,2 条回复,2,794 次浏览,73 次收藏) 指出,智能体后端需要身份与隔离、队列、worker、持久状态、工具边界和明确的交付路径,因为智能体负载天然慢、受 I/O 限制,而且不具确定性。随帖附带的架构图之所以重要,在于它清楚展示了系统如何从请求—响应假设,转向“队列优先”的控制平面。

@JinjingLiang 报道 (67 个赞,21 条回复,5,596 次浏览,32 次收藏) 表示,一个大型 PR 在真正实现前,大约需要 20 轮规划/审查循环、72 小时的 Claude Code /ultracode、5 到 10 个窄职能审查智能体、大量集成测试和 E2E 测试,以及内部 dogfooding,之后才能合并。回复进一步点明了运营层面的教训:按 API 标价计算,这类工作流可能花掉数千美元,因此每一轮都需要紧凑、可核查的记录,而不是凭感觉判断。
讨论洞察: 回复里持续追问的不是神秘感,而是机制:轨迹质量、持久状态、可安全去重的重试、审查记录,以及审批负责人。
与前一天对比: 8 月 21 日聚焦的是技能、上下文层和可迁移知识;8 月 22 日则延续这一框架,同时把隐藏的基础设施层明确了出来:队列、审查闭环、退避、验证,以及对操作员可见的控制项。
1.2 技能、记忆和 harness 可移植性,正成为独立基础设施(🡕)¶
第二组讨论把可复用技能和共享记忆视为独立的产品类别。开发者不再让一个智能体每次会话都重学同一套代码库、策略或工作流,而是在持续推出可安装的技能库、持久记忆服务器,以及能让上下文跨运行时迁移的 harness 路由器。这个主题把 8 月 21 日“技能即封装”的思路,进一步推进到明确的发现、编排和存储层。
@HARNESSROUTER 宣布 (48 个赞,5 条回复,4,804 次浏览,105 次收藏) 发布了一个采用 Apache 许可证的 Community Edition,可通过一个自托管 API 运行 Codex、Claude Code、Hermes 和 DeepSeek Harness;公开仓库还写明,同一个系统也实现了开放的 Unified Harness Protocol。一条回复补充了一个关键细节:工具权限往往仍要按智能体逐个手工处理,这让它比单纯的发布宣传帖更有可信度。
@GithubProjects 分享 (26 个赞,1 条回复,4,743 次浏览,14 次收藏) 将 Letta 描述为一个面向有状态智能体的框架,其记忆会持久保留并随时间改进。Letta Code 仓库则把这一说法展开为具体能力:记忆与身份、由 Git 跟踪的 MemFS 上下文、可安装技能、子智能体、定时任务,以及把同一个智能体路由到笔记本电脑、云端 VM 和托管沙箱的能力。
@DanKornas 介绍 (5 个赞,5 条回复,807 次浏览) 将 SkillNet 定位为发现、评估、组合和编排可复用智能体技能的开放基础设施。公开仓库称,搜索和从公开 GitHub 下载都无需凭据,而且该库目前已索引 500K+ 技能,这让“技能”更像一个软件包生态,而不只是一个提示词文件夹。
@DanKornas 还分享了 (1 个赞,3 条回复,400 次浏览) 将 mem9 定位为 AI 智能体的持久共享记忆层。仓库将其描述为 OpenClaw、Hermes Agent、Claude Code、Codex、DeepSeek Harness、Dify 和自定义客户端共用的一层记忆平面,提供混合召回和仪表盘,而不是每个智能体各自维护笔记本。
@Shruti_0810 指向 (8 个赞,2 条回复,935 次浏览) 提到了 DevOps 与安全 Agent 技能 仓库;该仓库公开宣称提供 160+ 个面向基础设施、安全、合规和 AI 工程的生产级技能。这个细节很有价值,因为它显示运营知识正在作为可供智能体加载的资产被分发,而不是继续停留在静态文档里。
讨论洞察: 共同的动作是把 know-how 外置化。技能变成可搜索的工件,记忆变成共享服务,而 harness 兼容性也开始被视为应当“路由”而不是“重写”的能力。
与前一天对比: 8 月 21 日说明了团队为什么需要可移植技能;8 月 22 日则展示了围绕这种需求正在成形的基础设施层:路由器、记忆服务器、技能索引,以及跨运行时的安装入口。
1.3 研究者把智能体推进到训练闭环、本地推理、语音基准和物理执行(🡕)¶
第三个主题是,真正有意义的进展,来自于改变模型周围的 harness、环境或执行界面。最强的例子覆盖了基准 harness、RL 框架、本地 speculative decoding、语音任务完成,甚至还有一个工作流最终让实体物件从打印机里产出。相比 8 月 21 日聚焦领域专用闭环,8 月 22 日更强调这些闭环如何被训练、测量,或在现实世界里真正执行。
@daniel_mac8 认为 (168 个赞,21 条回复,8,719 次浏览,77 次收藏) 表示,NVIDIA 的 AVO harness 与 Opus 5 结合后,把 ARC-AGI-3 公开基准的成绩从约 30% 推到了 100%。附图解释了这条帖子为何重要:持久记忆、inspect → plan → implement → evaluate 的步骤、执行反馈,以及把失败轨迹重新路由的 supervisor,都属于 harness,而不是底层模型本身。

@Sumanth_077 分享 (65 个赞,6 条回复,4,163 次浏览,48 次收藏) 介绍了 NVIDIA 开源的 Molt 框架,并将其定位为一个“agentic-first”的 RL 技术栈:奖励可以是任意 Python 函数,同一份脚本可以从 8B 扩展到 1T 级 MoE actor。仓库用一套小型的 Ray + vLLM + AutoModel/FSDP2 组合来支撑这一定位,目标是让整套流程从头到尾都便于读懂。
@rohanpaul_ai 总结 (45 个赞,5 条回复,2,523 次浏览,41 次收藏) 将 Harness Continual Learning 描述为一种对提示词、记忆、技能和路由变更进行把关的方法,因为不断演化的 harness 即使不重新训练模型,也会“遗忘”。与此同时,@rohanpaul_ai 报道 (30 个赞,5 条回复,2,918 次浏览) 表示,ClawGym II 可以通过 Claude Code 或 OpenClaw 这类黑盒 harness 做 RL 训练,并持续提升通过率。
@0xkydo 报道 (190 个赞,11 条回复,10,325 次浏览,129 次收藏) 表示,一项社区挑战在 7 天内,通过定制 MTP 头、更紧的验证/回滚路径和 Metal kernel 优化,把 Apple Silicon 上 Qwen 3.8 27B 的中位解码速度从 26 tok/s 提升到 87.9 tok/s。@XFreeze 补充说 (117 个赞,15 条回复,438,991 次浏览) 表示,Artificial Analysis 新推出的 Speech Agent Arena 按任务成功率将 Grok Voice Think Fast 2.0 排名第一;而回复马上质疑了速率限制、嘈杂音频,以及基准成绩能否迁移到现实场景。
讨论洞察: 新进展很少是“模型变聪明了”,更多是“闭环变快了”“harness 可训练了”“环境变难了”,或者“智能体现在能完成一个真实任务界面了”。
与前一天对比: 8 月 21 日展示了基准和垂直领域工具里的具体智能体闭环;8 月 22 日则进一步补上了这些闭环如何被训练、做基准、本地加速,或推进到语音与物理执行表面的工作。
2. 什么让人沮丧¶
可靠性管线,仍然决定智能体能否真正用于生产¶
最一致的挫败感在于,长时运行的智能体往往不是先败在推理上,而是先败在系统层。@arpit_bhayani 表示 (74 个赞,8 条回复,3,557 次浏览,35 次收藏) 指出,每个严肃的智能体闭环都需要硬超时、退避和熔断、持久进度检查点以及追踪,因为网络中断、速率限制和半死不活的 API 不是例外,而是常态。回复补上了生产环境里缺失的关键词:幂等键、可安全处理重复的副作用,以及超时通常意味着“结果未知”,而不是“操作失败”。freeCodeCamp 课程串文 (159 个赞,6 条回复,8,860 次浏览,143 次收藏) 和 Jinjing Liang 的 PR 工作流帖子 (67 个赞,21 条回复,5,596 次浏览,32 次收藏) 又从不同角度强化了同一痛点:只有把审查和验证当成一等公民,重复 webhook、部分执行和超大 PR 才变得可承受。严重程度:高。值得投入:高。
上下文膨胀和子智能体扇出,仍在烧时间和预算¶
第二个挫败点来自经济账:智能体经常把更多上下文花在自己的脚手架上,而不是花在用户任务上。@sairahul1 认为 (18 个赞,8 条回复,3,413 次浏览,25 次收藏) 指出,终端输出、代码库上下文、MCP schema 和冗长表达,造成的浪费可能比提示词措辞本身高出 10 到 50 倍。@iasg1004 测量了 (1 个赞,2 条回复,18 次浏览) 展示了一次 436,000 token 的子智能体启动成本,孩子智能体在打开第一个文件前就已经花掉了这些 token;同样一次审查,三个智能体要花 2,150,310 token,而一个智能体只要 809,070。@momo5502 补充说 (29 个赞,4 条回复,1,179 次浏览,16 次收藏) 所链接的审计则给出了更硬的数据:按标价折算约 $85,207、89% 为缓存读取,且子智能体之间 54.7% 的大型文件读取是重复的。严重程度:高。值得投入:高。

不可逆操作,仍需要位于智能体之外的授权¶
最明确的信任类抱怨是,智能体不该靠“说服自己”绕过控制边界。@nabu_lines 警告 (36 个赞,23 条回复,1,751 次浏览) 指出,智能体最危险的一句话不是“我犯错了”,而是“我找到了另一种办法”;随后主张密钥应保留在智能体之外,授权应在签名时由硬件完成。@AiCamila_ 制作了 则从操作层面表达了同样的观点:删除、付款、发送和覆盖等操作,都应该停在明确的确认闸门后面。更早前 Andrew Ng 的讨论串也从另一个方向呼应了这一点:有回复说,生产工作流需要具名的审批负责人和回滚机制。严重程度:高。值得投入:高。

3. 人们希望有什么¶
一个默认提供重试、记录和审批闸门的控制平面¶
最强烈的现实需求,是智能体系统默认把运行控制项暴露出来,而不是把它们藏在对话转录里。@HARNESSROUTER 打包了 (48 个赞,5 条回复,4,804 次浏览,105 次收藏) 把会话、权限、上下文、工件和沙箱视为一个可复用层。@kmeanskaran 也做了同样的事 (81 个赞,2 条回复,2,794 次浏览,73 次收藏) 给出了后端架构,@arpit_bhayani 写道 (74 个赞,8 条回复,3,557 次浏览,35 次收藏) 讨论了重试,而 @AiCamila_ 明确说明了 (6 个赞,271 次浏览) 则强调危险操作要有明确确认。这是一个直接需求,因为大家描述的故障就是重复副作用、卡住的链路,以及不可审查的不可逆操作。机会:直接。
能跨 harness 迁移的共享技能和记忆¶
人们也希望智能体别再每次会话都重学同一套运营知识。@DanKornas 将其定位为 (5 个赞,5 条回复,807 次浏览) 用 SkillNet 处理可复用技能的发现、评估、组合和编排,而他的 mem9 串文 (1 个赞,3 条回复,400 次浏览) 则把持久共享记忆定义为服务器层,而不是提示词小技巧。@GithubProjects 挖掘出 (26 个赞,1 条回复,4,743 次浏览,14 次收藏) 指向 Letta 的有状态记忆路径,@Shruti_0810 指出 (8 个赞,2 条回复,935 次浏览) 则指向一个面向基础设施与安全工作的 160+ 技能库。这既是直接需求,也带有竞争属性:需求已经非常明显,但已有多个项目在争夺这层共享底座。机会:竞争型。
能检查轨迹、而不只是检查输出的评测¶
第三个需求,是更好地检查智能体到底做了什么。最强烈的表述出现在 @AndrewYNg 在这里分享 (3,873 个赞,85 条回复,217,069 次浏览,6,473 次收藏) 的回复里:从业者希望有推理质量评测、轨迹阅读能力,以及识别“自信总结了根本没发生过的工作”的机制。@momo5502 展示了 (29 个赞,4 条回复,1,179 次浏览,16 次收藏) 通过挖掘 2 GB 真实会话日志说明了这为什么重要,而 @XFreeze 也揭示了同样的差距 (117 个赞,15 条回复,438,991 次浏览) 下面的回复则认为,基准胜利仍需对照嘈杂的真实世界音频和受限速的 API 来验证。这是一个直接需求,因为社区已经有输出和排行榜,缺的是对路径的可靠观测能力。机会:直接。
4. 在用的工具和方法¶
| 工具 | 类别 | 评价 | 优势 | 局限 |
|---|---|---|---|---|
| AVO | 智能体 harness 架构 | (+) | 持久记忆、supervisor 闭环、执行反馈、inspect → plan → implement → evaluate 流程 | 今天的证据仍偏基准测试,且主要集中在 ARC-AGI-3,而不是广泛部署 |
| HarnessRouter / UHP | Harness 运行时 / API | (+) | 自托管、一个 API 对接多个 harness、私钥与数据私有、带入门套件 | 回复显示,权限仍需按智能体谨慎处理 |
| Letta Code | 有状态 harness | (+) | 记忆、身份、MemFS、技能、定时任务、多环境路由 | 功能丰富,也带来了超出无状态 CLI 的运营复杂度 |
| Molt | RL 框架 | (+) | 任意 Python 奖励、精简的 Ray + vLLM + AutoModel/FSDP2 技术栈、端到端可读 | 更偏研究导向;今天关于生产采用的证据仍有限 |
| SkillNet | 技能基础设施 | (+) | 无需凭据即可发现、创建、评估、组合和编排,公开库体量很大 | 编排依赖兼容的 gateway/API 配置 |
| mem9 | 记忆层 | (+) | 跨运行时共享持久记忆、混合召回、仪表盘、支持托管或自托管 | 引入了服务器/API 依赖以及记忆治理面 |
| OpenHands Agent Canvas | 自托管控制中心 | (+) | 常驻运行智能体、支持多后端、自动化触发器、兼顾本地/远程/云端灵活性 | 若未加固,安装后会让智能体获得完整文件系统访问权限 |
| RTK / Context Mode / Token Savior (来源串文) | 上下文优化 | (+/-) | 去除嘈杂终端输出、把大型响应外置、收窄代码检索范围 | 包装层较碎;回复认为其中部分只是为自造的工具膨胀善后 |
| Speech Agent Arena | 基准 | (+/-) | 衡量的是任务成功率,而不只是语音流畅度 | 回复质疑其对真实世界音频噪声、速率限制以及超出基准集后的迁移能力 |
总体满意度偏向自托管控制平面、记忆层和技能基础设施,因为这些工具能直接减少重复配置,并让长时运行的智能体工作变得可理解。最常见的权宜模式是拆分角色:一个模型或 harness 负责规划和审查,另一个则在 tmux、CLI 或路由后的后端里执行。竞争态势正在从“谁的原始模型最强”,转向“哪套栈能提供更好的状态、权限、记录和上下文经济性”。
5. 人们在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| HarnessRouter Community Edition | HarnessRouter | 通过一个自托管 API 路由 Codex、Claude Code、Hermes 和 DeepSeek Harness | 去掉围绕会话、权限、上下文和工件的逐产品 harness 集成工作 | Docker、UHP、provider 集成 | 已发布 | 推文 仓库 规范 |
| Molt | NVIDIA NeMo | 一个 agentic-first 的 RL 框架,用 Python 定义奖励来训练会使用工具的智能体 | 为研究者提供一套精简技术栈,用真实环境和工具闭环训练智能体 | Ray、vLLM、AutoModel、FSDP2、PyTorch | Beta | 推文 仓库 论文 |
| Letta Code | Letta | 有持久记忆、技能、多智能体支持和多机器路由能力的有状态智能体 harness | 避免长时运行的智能体在每次会话或设备切换时都归零重来 | TypeScript CLI、MemFS、Letta Cloud、技能、定时任务 | 已发布 | 推文 仓库 文档 |
| SkillNet | ZJUNLP | 搜索、下载、创建、评估并编排可复用的智能体技能 | 避免智能体为每个任务反复重建同一种能力 | Python SDK、CLI、可视化浏览器 | 已发布 | 推文 仓库 论文 |
| mem9 | mem9-ai | 面向 OpenClaw、Hermes、Claude Code、Codex、Dify 和自定义客户端的共享记忆层 | 在会话、机器和协作智能体之间保留并共享上下文 | Go server、API、基于 TiDB 的托管选项、仪表盘 | 已发布 | 推文 仓库 网站 |
| OpenHands Agent Canvas | OpenHands | 面向本地、远程和云端后端的编码智能体与自动化自托管控制中心 | 即使笔记本电脑合上,智能体也能继续运行,并集中管理多后端 | Node、Docker、Agent Server、Automation Server | 已发布 | 推文 仓库 |
| DevOps & Security Agent Skills | BagelHole | 面向基础设施、安全、合规和 AI 工程任务的 160+ 个可安装技能 | 降低运维型工作中反复加载上下文的成本,避免智能体每次都从零摸索 | Skills 格式、脚本、参考文档、配置 | 已发布 | 推文 仓库 |
HarnessRouter、Letta、SkillNet 和 mem9 都指向同一种构建模式:harness、记忆层和技能底座,如今都已经是独立的产品界面。Molt 把这一逻辑推进到训练层面,通过把 RL 技术栈收缩成一个小而可 hack 的闭环;OpenHands Agent Canvas 则把跨机器、跨计划持续运行智能体所需的运营层打包出来。即便是技能库项目,现在也越来越不像“awesome list”,而更像带有 CLI 入口、评估界面和自托管路径的可安装基础设施。

6. 新动态与值得关注的内容¶
Apple 硬件上的本地前沿风格智能体明显提速¶
@0xkydo 报道 (190 个赞,11 条回复,10,325 次浏览,129 次收藏) 提到,Qwen 3.8 27B 在 M5 Max 上的中位解码速度在 7 天内从 26 tok/s 跃升到 87.9 tok/s,驱动因素包括定制 MTP 头、自适应草稿数、kernel 优化,以及验证路径清理。回复让下一个问题变得很明确:得把这些增益 upstream,才能让本地用户真正受益。
一次 235B token 审计,让智能体经济性从传闻变成可检查对象¶
@momo5502 分享 (29 个赞,4 条回复,1,179 次浏览,16 次收藏) 发布了一次日志审计,显示按标价折算约为 $85,207 的支出、89% 的缓存读取、大量构建/测试开销,以及子智能体之间重复研究的问题。再加上 @iasg1004 对“孩子智能体在打开文件前就要花掉 436,000 token”的量化,“子智能体很贵”这件事就从口头说法变成了公开、可核查的证据。
语音智能体基准开始重视任务完成¶
@XFreeze 报道 (117 个赞,15 条回复,438,991 次浏览) 表示,Artificial Analysis 的 Speech Agent Arena 按任务成功率将 Grok Voice Think Fast 2.0 排名第一。相比只看语音润色度,这是更强的信号,因为它跟踪的是理解、工具选择和任务完成。回复也立刻把这个基准拉回现实:在嘈杂真实音频、打断和速率限制下,这个分数还能不能成立?

智能体从仿真走向制造¶
@ProfBuehlerMIT 展示了 (148 个赞,15 条回复,26,464 次浏览,98 次收藏) 展示了一个三机器人工作流:从图像中推断结构原理、构建物理模拟器、运行 47 次实验、筛选设计,并把最优方案送去 3D 打印。最重要的一条回复反而最简单:当被问到这些智能体是否触碰了物理世界时,他回答“是”。
7. 机会在哪里¶
[+++] 智能体运营控制平面 — 第 1、2、5 节的证据同时指向这一点:后端架构图、重试手册、明确的确认闸门、HarnessRouter 的自托管 API,以及 Jinjing Liang 的长 PR 工作流,都暴露了同一个缺口。团队需要一个统一界面来承载会话、队列、重试、记录、审批和持久状态。
[++] 共享技能与记忆底座 — Letta、SkillNet、mem9 和 DevOps & Security Agent Skills 都在解决同一种重复浪费:智能体反复重学相同的策略、代码库和工作流。这个方向已经有竞争,但需求也非常明确,因为跨 harness、跨会话的可移植性依然很痛。
[+] 面向轨迹的评测与审计工具 — Andrew Ng 的回复要求评估推理质量,MW2 的审计展示了时间和支出究竟流向哪里,而语音智能体相关回复则质疑基准赢家能否撑过混乱的真实世界条件。这里仍有空间做“看路径而不只是看答案”的工具。
8. 要点¶
- 当天最主要的差异化因素,是 harness 质量。 最清楚的证据来自 Andrew Ng 的技能讨论、NVIDIA 的 AVO 基准胜利、freeCodeCamp 的生产级 PR 审查器,以及 Karan 的后端架构图:大家真正押注的杠杆,是记忆、队列、评测和监督,而不是再改一次提示词。 (来源)
- 所谓生产就绪,仍然意味着重试、持久状态和明确的人类授权。 Arpit Bhayani 的重试清单、Camila 的确认闸门,以及 nabu 关于硬件签名的主张,说的都是同一件事:不可逆操作需要比“模型看起来很自信”更强的基础设施。 (来源)
- 上下文现在已经成了经济瓶颈。 Rahul 的上下文工程讨论、iasg1004 对 436k-token 启动成本的测量、Jinjing Liang 昂贵的 72 小时 PR 工作流,以及 momo5502 的 235B token 审计,都表明 token 开销既来自有用工作,也同样被脚手架和重复上下文所驱动。 (来源)
- 开发者正在把技能、记忆和路由做成独立的基础设施类别。 HarnessRouter、Letta、SkillNet、mem9、OpenHands Agent Canvas,以及 DevOps & Security Agent Skills 仓库,都把这些层当作可复用产品,承载在多个智能体和模型之下。 (来源)