Twitter AI 智能体 - 2026-08-22¶
1. 人们在讨论什么¶
1.1 生产级智能体工作由运行框架、队列和审查闭环来定义 (🡕)¶
最强的一簇帖子，把构建智能体看成操作系统问题，而不是写提示词的小技巧。多条高信号帖子都收敛到同一组要素：能检查轨迹的评估、能穿过慢 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 轮 plan/review 闭环、72 小时的 Claude Code /ultracode、5 到 10 个窄职责审查智能体、密集的集成与 E2E 测试，以及内部自用验证才能合并。回复把这个操作层面的教训说得更尖锐：这种工作流按 API 目录价算可能要花数千美元，因此每一轮都需要紧凑、可核对的留痕，而不是靠感觉。
讨论要点： 回复区一再要求的是机制，不是神秘感：轨迹质量、持久状态、防重复的重试、审查留痕，以及明确的审批责任人。
与前日对比： 8 月 21 日更关注技能、上下文层和可移植经验知识。到了 8 月 22 日，这个框架依然成立，但隐藏的基础设施被摆到了台前：队列、审查闭环、退避、验证，以及让操作员能看见的控制项。
1.2 技能、记忆和运行框架可移植性正在成为独立基础设施 (🡕)¶
第二簇帖子把可复用技能和共享记忆看成了自己的产品类别。与其让一个智能体每次会话都重新学习同一个仓库、同一套策略或同一条工作流，构建者们更愿意持续发布可安装的技能库、持久记忆服务器，以及能让上下文跨运行时迁移的运行框架路由器。这个主题，把 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 介绍了 SkillNet（5 点赞、5 条回复、807 次浏览），把它定位成发现、评估、组合和编排可复用智能体技能的开放基础设施。公开仓库表示，搜索和公开 GitHub 下载都不需要凭据，而且这个库现在已经索引了 50 万+ 技能，这让“技能”更像一个包生态，而不只是一个提示词文件夹。
@DanKornas 还 分享了 mem9（1 点赞、3 条回复、400 次浏览），把它作为 AI 智能体的持久共享记忆层。仓库把它定位成 OpenClaw、Hermes Agent、Claude Code、Codex、DeepSeek Harness、Dify 和自定义客户端共用的一块记忆平面，提供混合召回和仪表盘，而不是每个智能体各自维护一本笔记。
@Shruti_0810 指向了（8 点赞、2 条回复、935 次浏览）DevOps & Security Agent Skills 仓库，它公开宣称自己提供 160+ 个面向基础设施、安全、合规和 AI 工程的生产级技能。这一点很有用，因为它说明运营知识正在被分发成智能体可加载的资产，而不只是静态文档。
讨论要点： 共同的动作是把经验知识外置出来。技能变成了可搜索的工件，记忆变成了共享服务，运行框架兼容性也变成了构建者期望可以路由、而不是每次重写的东西。
与前日对比： 8 月 21 日展示了为什么团队想要可移植技能；8 月 22 日则展示了围绕这种欲望正在成形的基础设施层：路由器、记忆服务器、技能索引，以及跨运行时的安装界面。
1.3 研究者把智能体推进了训练闭环、本地推理、语音基准和物理执行 (🡕)¶
第三个主题是，真正有意义的进展来自改变模型周围的运行框架、环境或执行表面。最强的例子覆盖了基准测试运行框架、RL 框架、本地投机解码、语音任务完成，甚至最终把工作流落到了实体打印物上。相比 8 月 21 日更聚焦领域型闭环，8 月 22 日更强调这些闭环是如何被训练、衡量、在本地加速，或推向语音和物理执行世界的。
@daniel_mac8 认为（168 点赞、21 条回复、8,719 次浏览、77 次收藏），NVIDIA 的 AVO 运行框架配上 Opus 5，把 ARC-AGI-3 公共基准上的表现从大约 30% 推到了 100%。配图很好地解释了这条帖子为什么重要：持久记忆、inspect → plan → implement → evaluate 的步骤、执行反馈，以及把失败轨迹重新分流的监督器，全都属于运行框架，而不是基础模型。
@Sumanth_077 分享了（65 点赞、6 条回复、4,163 次浏览、48 次收藏）NVIDIA 开源的 Molt 框架，把它描述为一套“智能体优先”的 RL 栈：reward 可以是任意 Python 函数，同一份脚本也能从 8B 扩展到 1T 级 MoE actor。仓库用一个小巧的 Ray + vLLM + AutoModel/FSDP2 栈来支撑这个定位，而且从头到尾都尽量保持可读。
@rohanpaul_ai 概括了 Harness Continual Learning（45 点赞、5 条回复、2,523 次浏览、41 次收藏），认为它能对提示词、记忆、技能和路由变更进行把关，因为不断演化的运行框架即使没有重训模型，也会“遗忘”。与此同时，@rohanpaul_ai 还 报告 了 ClawGym II（30 点赞、5 条回复、2,918 次浏览），说明它能穿过 Claude Code 或 OpenClaw 这样的黑盒运行框架做 RL 训练，并且仍然提升通过率。
@0xkydo 报告（190 点赞、11 条回复、10,325 次浏览、129 次收藏），一次社区挑战在 7 天里把 Apple Silicon 上 Qwen 3.8 27B 的中位解码速度从 26 tok/s 推到了 87.9 tok/s，依靠的是自定义 MTP heads、更紧的 verify/rollback 路径和 Metal kernel 工作。@XFreeze 则 补充（117 点赞、15 条回复、438,991 次浏览），Artificial Analysis 新出的 Speech Agent Arena 把 Grok Voice Think Fast 2.0 排在任务成功率第一，但回复也立刻质疑它在限流、噪声音频和基准测试到现实迁移上的表现。
讨论要点： 新进展很少是“模型变得更聪明了”，更常见的是“闭环变得更快了”“运行框架可以训练了”“环境变得更难了”，或者“智能体终于能完成一个真实任务表面了”。
与前日对比： 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 和冗长表达，消耗的 token 可能是提示词措辞本身的 10 到 50 倍。@iasg1004 测得（1 点赞、2 条回复、18 次浏览），一个子智能体在打开第一个文件之前，仅启动就先吞掉了 436,000 个 token；同样一项审查，3 个智能体要花 2,150,310 个 token，而 1 个智能体只要 809,070。@momo5502 的审计 又补上了更硬的数据（29 点赞、4 条回复、1,179 次浏览、16 次收藏）：按目录价折算大约要花 85,207 美元，89% 都是缓存读取，而且子智能体之间有 54.7% 的大文件读取是重复的。严重程度：高。值得构建：高。
不可逆操作仍需要存在于智能体之外的授权¶
最清晰的信任抱怨，是智能体不该靠自己绕过控制边界。@nabu_lines 警告（36 点赞、23 条回复、1,751 次浏览），智能体最危险的一句话，不是“我搞错了”，而是“我找到别的办法了”；随后他主张密钥应该留在智能体之外，授权必须在签名时由硬件完成。@AiCamila_ 也从操作层面 表达了 同一个观点（6 点赞、271 次浏览）：删除、支付、发送和覆盖等动作，都应该停在显式确认闸门之前。更早的 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 次浏览）。这是一个直接需求，因为这些人描述的失败，都是重复副作用、卡死的链路，以及无法审查的不可逆操作。机会：直接。
可跨运行框架迁移的共享技能与记忆¶
人们也希望智能体别再每个会话都重新学习同一套运营知识。@DanKornas 把 SkillNet 定位在可复用技能的发现、评估、组合与编排上（5 点赞、5 条回复、807 次浏览），而他的 mem9 讨论串（1 点赞、3 条回复、400 次浏览）则把持久共享记忆定义成一个服务器层，而不是提示词变通办法。@GithubProjects 展示了 Letta 的有状态记忆方案（26 点赞、1 条回复、4,743 次浏览、14 次收藏），@Shruti_0810 则 指向 一个面向基础设施和安全工作的 160+ 技能库（8 点赞、2 条回复、935 次浏览）。这件事一半是直接需求，一半是竞争型机会：需求已经非常明显，但多个项目也已经在争夺这层共享底座。机会：竞争型。
检查轨迹而不只看输出的评估¶
第三个需求，是更好地检查智能体到底做了什么。最强的措辞来自 @AndrewYNg 这条分享 的回复区（3,873 点赞、85 条回复、217,069 次浏览、6,473 次收藏），实践者在里面要求推理质量评估、轨迹阅读能力，以及一种能识别“自信地总结了其实并没发生的工作”的机制。@momo5502 展示了 为什么这很重要：他挖了 2 GB 真实会话日志（29 点赞、4 条回复、1,179 次浏览、16 次收藏）；而 @XFreeze 的回复区也以另一种形式 暴露了 同样的缺口（117 点赞、15 条回复、438,991 次浏览），大家追问的是：这些基准测试胜利，能不能穿过嘈杂的真实音频和被限流的 API 继续成立。这是一个直接需求，因为社区已经有结果和排行榜了；它真正缺的，是能可靠检查路径本身的仪器。机会：直接。
4. 使用中的工具与方法¶
| 工具 | 类别 | 评价 | 优势 | 局限 |
|---|---|---|---|---|
| AVO | 智能体运行框架架构 | (+) | 持久记忆、监督器闭环、执行反馈，以及 inspect → plan → implement → evaluate 流程 | 今天的证据主要来自基准测试，且集中在 ARC-AGI-3，而不是广泛部署 |
| HarnessRouter / UHP | 运行框架运行时 / API | (+) | 自托管、一套 API 连接多个运行框架、私有密钥 / 数据、入门套件 | 回复指出，权限仍需要为不同智能体仔细处理 |
| Letta Code | 有状态运行框架 | (+) | 记忆、身份、MemFS、技能、日程安排、多环境路由 | 功能丰富也带来比无状态 CLI 更高的运维复杂度 |
| Molt | RL 框架 | (+) | 任意 Python reward、最小化的 Ray + vLLM + AutoModel/FSDP2 栈、从头到尾可读 | 更偏研究定位；今天公开显示的生产采用信号有限 |
| SkillNet | 技能基础设施 | (+) | 无凭据发现、创建、评估、组合与编排，以及非常大的公开技能库 | 编排依赖兼容的网关 / API 配置 |
| mem9 | 记忆层 | (+) | 跨运行时共享持久记忆、混合召回、仪表盘、可托管或自托管 | 引入了额外的服务 / API 依赖，以及记忆治理界面 |
| OpenHands Agent Canvas | 自托管控制中心 | (+) | 常驻智能体、多个后端、自动化触发、本地 / 远程 / 云端灵活切换 | 如果不做加固，非沙箱安装会让智能体拥有完整文件系统访问权 |
| RTK / Context Mode / Token Savior (来源讨论串) | 上下文优化 | (+/-) | 剥离嘈杂终端输出、外置大响应、收窄代码检索范围 | 包装栈较为碎片化；一些回复认为这只是给自我制造的工具膨胀擦屁股 |
| Speech Agent Arena | 基准测试 | (+/-) | 衡量的是任务成功率，而不只是语音顺滑度 | 回复质疑真实音频噪声、限流，以及能否迁移出基准集 |
总体满意度更偏向自托管控制平面、记忆层和技能基础设施，因为这些工具能直接减少重复设置，并让长时间运行的智能体工作变得可读。最常见的权宜方案，是把角色拆开：一个模型或运行框架负责规划和审查，另一个在 tmux、CLI 或路由后的后端里负责执行。竞争正在从“谁的原始模型最好”转向“谁的栈能给出更好的状态、权限、留痕和上下文经济性”。
5. 人们在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| HarnessRouter Community Edition | HarnessRouter | 通过一个自托管 API 路由 Codex、Claude Code、Hermes 和 DeepSeek Harness | 去掉围绕会话、权限、上下文和工件做的各产品运行框架接入重复劳动 | Docker、UHP、提供商集成 | 已发布 | 推文 仓库 规格 |
| Molt | NVIDIA NeMo | 面向训练工具使用型智能体的“智能体优先” RL 框架，reward 由 Python 定义 | 为研究者提供一套穿过真实环境与工具闭环训练智能体的最小栈 | Ray、vLLM、AutoModel、FSDP2、PyTorch | 测试版 | 推文 仓库 论文 |
| Letta Code | Letta | 带持久记忆、技能、多智能体支持和多机器路由的有状态智能体运行框架 | 避免长时间运行的智能体每换一次会话或设备就从零开始 | TypeScript CLI、MemFS、Letta Cloud、技能、日程安排 | 已发布 | 推文 仓库 文档 |
| SkillNet | ZJUNLP | 搜索、下载、创建、评估和编排可复用的智能体技能 | 避免智能体为每一项任务都从头重建同一类能力 | Python SDK、CLI、可视化浏览器 | 已发布 | 推文 仓库 论文 |
| mem9 | mem9-ai | 面向 OpenClaw、Hermes、Claude Code、Codex、Dify 和自定义客户端的共享记忆层 | 在会话、机器和协作智能体之间保留并共享上下文 | Go 服务、API、基于 TiDB 的托管选项、仪表盘 | 已发布 | 推文 仓库 站点 |
| OpenHands Agent Canvas | OpenHands | 面向本地、远程和云端后端的自托管编程智能体与自动化控制中心 | 让智能体在笔记本合上后仍能继续运行，并集中管理多后端控制 | Node、Docker、Agent Server、Automation Server | 已发布 | 推文 仓库 |
| DevOps & Security Agent Skills | BagelHole | 面向基础设施、安全、合规和 AI 工程任务的 160+ 可安装技能 | 降低运维密集型工作里反复加载上下文的成本，避免智能体每次都从零犯错 | Skills format、脚本、参考文档、配置 | 已发布 | 推文 仓库 |
HarnessRouter、Letta、SkillNet 和 mem9 都指向同一种构建模式：运行框架、记忆层和技能底座，如今都已经成了独立产品表面。Molt 则把这套逻辑推进到训练层，用一个小而可修改的 RL 闭环来缩小栈规模；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 heads、自适应 draft 数量、kernel 优化，以及 verify 路径清理。回复立刻把下一个问题摆上了台面：要把这些增益合回上游，让真正的本地用户也能享受到。
一次 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 都在攻击同一种反复浪费：智能体不断重复学习同一套策略、仓库和工作流。这个方向已经开始竞争，但需求非常清晰，因为跨运行框架、跨会话的可移植性依旧让人痛苦。
[+] 感知轨迹的评估与审计工具 — Andrew Ng 回复区里的人们要的是推理质量评估，MW2 审计展示的是时间和花费到底流向哪里，而语音智能体讨论区则在质疑基准测试胜利能否穿过混乱现实。这个方向还有空间，留给那些检查“路径”而不只是检查“答案”的工具。
8. 要点总结¶
- 运行框架质量，是今天最主要的分化因素。 最清楚的证据来自 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 仓库，都把这些层当作能够托在多个智能体和模型之下的可复用产品。(来源)