Twitter AI 智能体 - 2026-06-18¶
1. 人们在讨论什么¶
1.1 应用层 AI 的价值重心，从模型封装器转向集成与控制路径（🡕）¶
6 月 18 日最强的战略讨论串认为，价值正在积累在模型能力与真实工作之间的那一层。至少有 4 条高强度内容支撑了这个框架：Levie 的应用型 AI 方法论、xAI 把 Grok 接入 Databricks Agent Bricks、DigitalOcean 的一键式 Grok Build 部署界面，以及 DeepMind 公开发布的系统级安全控制论文。
@levie 认为（174 次点赞、25 条回复、15,522 次浏览、258 次收藏），应用型 AI 公司之所以能赢，在于它们构建了面向特定工作流的界面、能在前沿模型与更便宜模型之间路由任务、能在现场推进变更管理，并形成垂直领域的市场进入打法。这条讨论最有辨识度的地方，在于它用很具体的方式否定了过去“薄层”那套批评：护城河不在模型调用本身，而在围绕它展开的实施界面。
@XFreeze 表示（87 次点赞、18 条回复、4,208 次浏览），Grok 现在已经可在 Databricks Agent Bricks 内使用，由 Databricks 提供数据与治理层，Grok 提供推理层。@digitalocean 补充 了一个更偏部署的变体（84 次点赞、11 条回复、68,563 次浏览）：它把 Grok Build 放进了 DigitalOcean Marketplace，作为一个预配置好的编程智能体入口，并且可以通过 SSH 访问。
@sebkrier 分享 了 Google DeepMind 的两篇新论文（26 次点赞、2 条回复、1,199 次浏览、18 次收藏），聚焦智能体控制。附带的路线图截图列出了威胁建模、控制不变式、基于能力的缓解阶梯，以及由 15 项实用防御组成的组合，而 Google 公开的安全智能体概览则明确指出，安全智能体需要定义清晰的人类控制者、受限能力以及可观测的动作与规划。
讨论要点： 当天最有用的一条回复来自 Levie 的讨论串，其中一位读者说，企业智能体本质上是一串“权限转移栈：读取、推断、调用工具、修改记录、通知人类”。这和控制路线图所释放的信号完全对上了：讨论焦点已经不是模型更聪明，而是谁在监督整个运行过程。
与前日对比： 6 月 17 日的核心是前沿模型带来的兴奋，尤其围绕 Fable 5。到了 6 月 18 日，重心明显转向让这些模型能够在受治理工作流中真正落地的运营层。
1.2 技能、记忆与测试框架被当成可安装的基础设施（🡕）¶
第二个主题是，开发者开始把智能体能力视作打包好的基础设施：记忆原语、技能中心、元测试框架，以及其他团队可以安装或学习的课程材料。至少有 5 条内容支撑了这个主题，其中 2 条给出了异常具体的落地细节。
@Teknium 报告（313 次点赞、25 条回复、12,670 次浏览、124 次收藏），Hermes Agent 的记忆管理工具现在支持 save / edit / remove 流程的批量操作。附带卡片不是装饰，而是信息密度很高的证据：它解释了旧故障模式、新的原子化 operations[] 流程，以及实测结果——调用次数减少 52%，并且在 32 次真实智能体运行中得到验证，501 个单元测试全部通过。
@zeuuss_01 整理 了一套 Hermes 技能栈（102 次点赞、15 条回复、10,434 次浏览、122 次收藏），其中包括一个含 753+ 条目的网络安全技能包、Chainlink 官方链上技能、一个能继续生成更多技能的技能工厂、面向 300+ 付费 API 的 AgentCash、一个 X/Twitter 抓取器，以及 HermesHub 的 65+ 规则安全扫描器。@zhanghaili0610 开源 了 Deep Agents in Action（63 次点赞、3 条回复、5,009 次浏览、89 次收藏），而公开的 repo 和截图则展示了 8 个已上线章节，内容覆盖规划、上下文工程、子智能体、异步子智能体、技能和长期记忆。
@tom_doerr 链接 了 ctf-skills（14 次点赞、1,428 次浏览、14 次收藏），README 把它定义成一个 Agent Skills 技能包，覆盖 web 漏洞利用、二进制利用、密码学、逆向工程、取证和 OSINT；在抓取时，这个仓库有 2,446 个 GitHub stars。@Dinosn 提到 了 Omnigent（3 次点赞、630 次浏览、6 次收藏），这是一个拥有 3,818 星的早期元测试框架，公开宣称能在 Claude Code、Codex、Cursor、Pi 和自定义智能体之间做编排，并带有策略与沙箱能力。
讨论要点： 这种打包模式在完全不同类型的工件上都高度一致。无论界面是记忆原语、技能中心、CTF 技能包还是元测试框架，核心卖点都一样：不要再一条提示词一条提示词地重复搭智能体行为。
与前日对比： 6 月 17 日已经出现了自演化技能和技能市场。6 月 18 日则把同一趋势进一步运营化，带来了可量化的运行时收益、带扫描能力的技能注册表，以及可复用的课程材料。
1.3 实践者开始按任务、effort 档位和提供商来优化技术栈（🡕）¶
第三个主题是，模型选择变得更细颗粒。人们不再问“哪个单一模型最好”，而是开始明确描述规划、执行、审查、隐私和预算各自的路由规则。
@morganlinton 分享 了一张公开的技术栈卡片（26 次点赞、7 条回复、1,058 次浏览、13 次收藏），它把不同模型分配给常规工作、更难的工作以及“疯狂困难的架构构建”。这张图之所以重要，是因为它已经是一份真实操作者手册：Opus 或 Fable 负责规划，GPT-5.5 和 Composer 负责执行，而审查则根据任务难度再做不同选择。
@levie 在自己的应用型 AI 方法论里明确纳入了模型路由，认为最好的平台会根据任务性质，在前沿智能与更便宜的模型之间做平衡。@TheMaran 分享 了一份通过 Zenmux 使用 GLM 5.2 且无需信用卡的指南（56 次点赞、6 条回复、1,885 次浏览、53 次收藏），同时也提醒“限流来得很快”。@ErikVoorhees 展示 了通过 Venice 接入 GLM 5.2 的 Hermes（63 次点赞、8 条回复、5,963 次浏览、24 次收藏），而 Venice 公开的 API 文档则把它描述为一个 OpenAI 兼容端点，支持私密推理和编程智能体集成。
讨论要点： 回复整体都很务实。Morgan 的讨论串认为，当中等 effort 已经够用时，xHigh 往往只是在浪费时间和 token；而 Erik 那条 Venice 讨论的回复则立刻追问，私有代码是否仍可能被推理提供商指纹化。
与前日对比： 6 月 17 日关于模型的讨论仍被前沿能力和访问资格主导。到了 6 月 18 日，团队已经开始主动把模型塞进规划、执行和审查这些不同角色里，开放模型网关也进入了组合之中。
1.4 智能体开始拥有自己的语音与邮件渠道（🡕）¶
最后一个清晰主题是，沟通界面正在原生化为智能体表面。和测试框架、模型路由这些簇相比，证据量更小，但足够具体：智能体现在开始拥有自己的收件箱与语音层，而不再完全依赖文本聊天。
@AndrewYNg 推出 了一门课程（71 次点赞、13 条回复、10,855 次浏览、43 次收藏），讲的是如何在不重写提示词、工具或 RAG 管线的前提下，为智能体加入语音能力。这条推文点名了 3 种具体模式，而不是含糊的“语音 AI”：一个语音交互游戏、一个只需约 10 行代码就能获得语音能力的现有智能体，以及一个能主动外呼并实时回传转录的智能体。
@testingcatalog 报道（83 次点赞、4 条回复、11,028 次浏览、57 次收藏），Atomic Mail 会给智能体分配自己的收件箱，并允许它们通过 MCP 或 Agent Skill 处理注册、发送、接收和回复。公开的 Atomic Mail agents 页面 则把这件事做成了可执行界面：它直接暴露出注册和 JMAP 请求用到的 CLI 命令。
讨论要点： 回复把缺失的控制项暴露得很明显。Andrew Ng 的讨论串里，有人追问审批是在音频回路里走完，还是要等转录确认后才执行；另一条回复则指出，barge-in 处理会是下一个故障点。Atomic Mail 的后续回复则强调，真正的工作流价值在于注册、验证邮件和线程回复这些具体任务。
与前日对比： 6 月 17 日重点还是本地桌面、终端和端侧界面。6 月 18 日则把边界进一步推向电话、收件箱以及智能体拥有的沟通渠道。
2. 令人困扰的问题¶
企业级智能体部署，仍然主要是集成与治理工作¶
严重程度：高。@levie 表示（174 次点赞、25 条回复、15,522 次浏览、258 次收藏），在应用型 AI 里，真正的工作是围绕特定工作流的界面、模型路由、现场实施和垂直领域市场进入策略，而不只是模型层本身。有条回复把这点进一步说透成操作者抱怨：企业智能体不是一次聪明的模型调用，而是一整串权限转移。接着，@sebkrier（26 次点赞、2 条回复、1,199 次浏览、18 次收藏）又补上了 DeepMind 的公开控制路线图，截图列出了威胁建模、控制不变式、缓解阶梯和 15 项具体防御。@XFreeze（87 次点赞、18 条回复、4,208 次浏览）也把 Databricks Agent Bricks 上的 Grok 定位为数据与治理集成，而不是单纯的原始模型故事。团队现在的应对方式，是把智能体放进受治理的数据栈中，并在工具使用周围加上更多监督。这值得投入构建，因为这种抱怨同时出现在战略讨论和控制系统工作里。
长程、重记忆系统仍然脆弱或低效¶
严重程度：高。@Teknium（313 次点赞、25 条回复、12,670 次浏览、124 次收藏）之所以发布批量记忆操作，是因为旧的一次一操作流程会在接近满容量时拒绝写入，迫使用户多轮删除并重试。附带卡片把痛点和修复都量化了：采用原子化更新路径后，调用次数减少了 52%。@jianxie_（201 次点赞、11 条回复、800,902 次浏览）则把 QUEST 的长程 RL 管线描述成一条依赖链：judge、search、retrieval 或 cache 中任何一个微小 bug，都可能毁掉几天训练；团队表示，他们光是把技术栈稳定下来，就花了将近两个月。其权宜方案也说得很明确：到处加 fallback 机制、把会话级训练限制在 32K token，并最终把 cache 命中率做到约 40%，以减少重复 API 支出。这值得投入构建，因为问题同时出现在运行时 UX 和训练基础设施里。
语音与沟通回路仍然暴露出审批与可靠性缺口¶
严重程度：中。@AndrewYNg（71 次点赞、13 条回复、10,855 次浏览、43 次收藏）把语音智能体描述成今天就能构建的东西，但回复立刻追问：动作审批是在音频回路里走完，还是要等转录确认后？另一条回复则点出 barge-in 处理会成为下一个故障点。@testingcatalog（83 次点赞、4 条回复、11,028 次浏览、57 次收藏）展示了智能体拥有自己的收件箱，但它的价值主张仍然围绕验证邮件、线程回复和注册这类运营杂务。人们当前的应对方式，是在高风险步骤继续保留人工在环，并把第一批工作流限定在边界清晰的沟通任务里。这值得适度投入构建，因为需求很具体，但信任模型还不完整。
廉价且私密的模型访问正在改善，但开发者仍要面对限流与信任取舍¶
严重程度：中。@TheMaran（56 次点赞、6 条回复、1,885 次浏览、53 次收藏）主推了无需信用卡的 GLM 5.2 访问方式，紧接着又提醒限流可能很快就会触发。@ErikVoorhees（63 次点赞、8 条回复、5,963 次浏览、24 次收藏）展示了通过 Venice 私密运行 GLM 5.2 的 Hermes，但回复里有人追问，推理提供商是否仍能通过上下文对私有代码做指纹识别。Venice 公开的 API 文档 把面向编程智能体的私密、OpenAI 兼容访问当成卖点，说明隐私与兼容性如今已经从小众要求变成销售要点。开发者当前的应对方式，是把免费或更便宜的模型塞进更窄的执行槽位，同时把更高信任或更强能力的提供商留给规划与审查。这值得适度投入构建，因为约束是真实存在的，但市场上的网关已经很拥挤。
3. 人们期望的功能¶
能跨工具变动而存活的可移植技能与记忆工件¶
信息流反复指向的是可复用能力包，而不是一次性提示词。@zhanghaili0610（63 次点赞、3 条回复、5,009 次浏览、89 次收藏）围绕规划、上下文工程、子智能体、技能和记忆组织了一个开源课程；@tom_doerr（14 次点赞、1,428 次浏览、14 次收藏）指向了 ctf-skills，这是一个拥有 2,446 星的专业技能包；@Dinosn（3 次点赞、630 次浏览、6 次收藏）则提到了 Omnigent，它承诺在多种编程测试框架之间提供统一编排层。@Teknium（313 次点赞、25 条回复、12,670 次浏览、124 次收藏）又从运行时角度补了一笔：他把记忆更新做成了原子化，成本更低。这是一个现实需求，已有活跃开发者和公开工件在持续发货。机会：直接。
原生面向智能体的沟通基础设施¶
两条完全不同的讨论串，在不同渠道里提出了同一个需求：给智能体一块它自己的沟通界面。@testingcatalog（83 次点赞、4 条回复、11,028 次浏览、57 次收藏）描述了一个属于智能体自己的收件箱，可跑注册、验证、发送、接收和回复工作流；@AndrewYNg（71 次点赞、13 条回复、10,855 次浏览、43 次收藏）则描述了具备语音能力的智能体，可以主动拨号、流式回传转录，并在部署前做评估。现实需求已经非常明确，但周边回复也表明，可靠性、审批和时延仍需要更强的默认能力。机会：直接。
更好的模型路由、成本控制与隐私操作者工具¶
@levie（174 次点赞、25 条回复、15,522 次浏览、258 次收藏）把模型路由定义为应用型 AI 方法论的核心组成部分，@morganlinton（26 次点赞、7 条回复、1,058 次浏览、13 次收藏）则给出了按难度分层的规划、执行和审查技术栈卡片。@TheMaran（56 次点赞、6 条回复、1,885 次浏览、53 次收藏）说明开发者仍在追逐免费或廉价访问，而 @ErikVoorhees（63 次点赞、8 条回复、5,963 次浏览、24 次收藏）则通过 Venice 暴露了同一需求的隐私版本。这是一个现实需求，但解决空间在网关、仪表盘和多模型运行时之间已经相当竞争。机会：竞争型。
面向真实系统内部智能体的更强控制与审计界面¶
最明确的治理诉求，来自那些同时描述风险的地方。@sebkrier（26 次点赞、2 条回复、1,199 次浏览、18 次收藏）分享了 DeepMind 的路线图和政策制定者指南，而 Levie 的讨论串则把产品定义成围绕模型的控制路径，而不是模型本身。这里的实际请求不是抽象的“安全”，而是受限能力、可观测计划，以及能与真实智能体能力增长相匹配的防御层。这对企业部署既紧迫又现实，即使不同买家想要的控制层并不一样。机会：直接。
4. 使用中的工具与方法¶
| 工具 | 类别 | 评价 | 优势 | 局限 |
|---|---|---|---|---|
| Claude Opus 4.8 / Fable | 模型 | (+) | 在公开操作者技术栈里被用作更难任务的规划层；Levie 也把前沿能力视为选择性投入，而非全部产品 | 对许多常规任务来说过于昂贵或火力过剩；操作者越来越少默认使用最高 effort 档位 |
| GPT-5.5 | 模型 | (+/-) | 在模型路由方法论里被公开用于执行与审查；Levie 也把它列为值得留给真正需要前沿智能的任务 | Morgan 的讨论串认为 xHigh effort 往往会耗费更多时间和 token，却不提升答案质量 |
| GLM 5.2 | 模型 | (+/-) | 开发者通过 Zenmux 和 Venice 把它当作更便宜的编程模型使用；Erik Voorhees 讨论串中的回复称它能稳定处理类似 Claude Code 的测试框架工作 | 免费访问很快就可能被限流，而对隐私敏感的用户仍会质疑推理提供商究竟能从上下文里推断出什么 |
| Venice API | 网关 | (+) | 公开文档把它定位为 OpenAI 兼容的私密 API，支持 250+ 模型，并明确集成编程智能体 | 仍然要求用户把敏感上下文和 API 密钥管理交给外部网关 |
| Hermes Agent | 运行时 | (+) | 内建学习循环、技能生态、持久记忆，并且现在有了原子化批量记忆更新和可测量的调用下降 | 变化很快的产品表面意味着频繁更新，而更大的技能栈也需要扫描与信任控制 |
| Omnigent | 元测试框架 | (+) | 在 Claude Code、Codex、Cursor、Pi 和自定义智能体之间提供统一编排层，并带有策略与沙箱能力 | 公开标记为 Alpha，因此就现有证据看，可移植性走在成熟度前面 |
| Atomic Mail | 沟通基础设施 | (+) | 给智能体分配自己的收件箱，并提供 JMAP 操作来处理注册、验证、发送和回复 | 仍处于开放 Alpha，且现有证据最强的仍是边界清晰的邮件工作流，而非更广义的沟通场景 |
| VocalBridge voice stack | 语音层 | (+/-) | 让开发者无需重写提示词或工具，就能加入语音、外呼和评估能力 | 回复凸显出时延、barge-in 和审批回路之间的取舍仍未解决 |
| Databricks Agent Bricks + Grok | 企业技术栈 | (+/-) | 把数据 / 治理层留在企业已有的数据栈里，同时替换进一个推理模型 | 信息流主要还是发布式表述，关于团队如何在实践中运行它的细节很少 |
总体情绪仍然偏向那些能在模型周围补上结构、可视化或本地性的工具；而对单独的模型升级或支付自治本身，则更为复杂。最明显的迁移路径，是从“一个托管聊天加一条提示词”转向带有检查点、权限、子智能体和记忆的测试框架。第二条迁移路径，是从纯云默认假设转向混合或完全本地栈；第三条迁移路径，则是从看不见的支出走向明确的 ROI、回滚和治理界面。
5. 人们在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| Deep Agents in Action | @zhanghaili0610 | 面向 planning、context engineering、sub-agents、skills 和 memory 的开源课程与文档站点 | 开发者需要面向生产级智能体系统的具体、当下的示例 | LangChain、LangGraph、Astro、GitHub Pages | 已发布 | tweet, repo |
| Atomic Mail | @testingcatalog | 以 API 为先的邮件系统，智能体可以注册收件箱，并在邮件之上运行工作流 | 智能体需要可持续存在的沟通渠道来处理注册、验证、发送和线程回复 | MCP、Agent Skills、JMAP | 早期阶段 | tweet, agents page |
| Omnigent | @Dinosn | 在 Claude Code、Codex、Cursor、Pi 和自定义智能体之间做编排的元测试框架 | 团队想要跨测试框架可移植性、策略控制和沙箱能力，而不想重写工作流 | Python、YAML 智能体、托管沙箱 | 早期阶段 | tweet, repo |
| ctf-skills | @tom_doerr | 面向 web、crypto、reverse engineering、forensics 和 OSINT 任务的专业 Agent Skills 技能包 | 通用编程智能体往往缺少进攻安全工作所需的领域流程 | Agent Skills 规范、Python、Friday Studio 集成 | 已发布 | tweet, repo |
| QUEST | @jianxie_ | 使用 Mid-Training → SFT → RL，并带会话级训练和缓存的深度研究训练系统 | 长程研究智能体既昂贵又脆弱，难以在运营上维持 | Search / retrieval 服务、judge 模型、缓存、会话级训练 | 早期阶段 | tweet |
| Loop Engineering Orange Book | @AlchainHust | 一本位于测试框架层之上的 loop engineering 免费实战指南 | 实践者需要可复用的外环设计模式，而不只是更好的提示词 | PDF 指南、公开案例研究、流程模式 | 已发布 | tweet, repo |
Atomic Mail 之所以突出，是因为它把沟通变成了智能体的一等界面，而不只是通知渠道。公开的 agents 页面直接暴露了注册和 JMAP 请求命令，因此“智能体收件箱”这个说法背后有可见界面支撑，而不只是发布文案。
Omnigent 和 ctf-skills 则在不同抽象层级上体现了同一种打包直觉。Omnigent 把编排、策略和可移植性打包进一个运行时，而 ctf-skills 则把领域流程打包成可安装的专业工件。再加上 Deep Agents in Action，它们共同说明：当前相当一部分构建活动，都在围绕“如何分发可复用的智能体能力”，而不是构建单一用途聊天机器人。
QUEST 代表了另一种开发者模式：让长程智能体在经济上还能活下去的基础设施。公开说明没有先庆祝基准测试胜利，而是强调管线稳定性、fallback 设计、上下文限制和缓存复用；这正是当底层痛点偏运营、而不是概念层面时，会出现的构建模式。
6. 新动态与亮点¶
DeepMind 用公开、系统级术语重新定义智能体控制¶
@sebkrier 提到 的一对 Google DeepMind 论文（26 次点赞、2 条回复、1,199 次浏览、18 次收藏），把对抗性智能体视为系统设计问题，而不只是模型对齐问题。路线图截图之所以信息量很高，是因为它点出了具体控制原语——威胁建模、控制不变式、基于能力的缓解阶梯，以及 15 项防御——而 Google 公开的安全智能体概览又给出了三条核心原则：人类控制者、受限能力，以及可观测的动作 / 规划。这种组合让 6 月 18 日的安全讨论比抽象口号更偏运营层。
公开操作者方法论开始越来越像真正的运行手册¶
@morganlinton 发布 的不是一句模糊的“用最强模型”，而是一张具体的模型路由卡片（26 次点赞、7 条回复、1,058 次浏览、13 次收藏）；@levie 描述 的战略层需求，也同样指向显式模型路由。这件事之所以重要，是因为它说明市场开始产出足够稳定的操作者启发式，可以被公开发布、讨论和迭代。
7. 机会在哪里¶
[+++] 智能体治理与控制界面 —— Levie 的应用型 AI 方法论、DeepMind 的控制路线图，以及 Grok 被放进 Databricks Agent Bricks 这件事，都在指向同一个缺口：团队需要围绕那些会触及真实工作流和真实数据的智能体，建立监督、审计和受限能力边界。
[+++] 有状态、可移植的技能与记忆 —— Teknium 那次调用减少 52% 的记忆更新、Hermes 技能包分发、Deep Agents in Action、ctf-skills 和 Omnigent，都说明市场对那种可以被打包、复用，并在会话或测试框架之间迁移的智能体能力有明确需求。
[++] 原生面向智能体的沟通基础设施 —— Atomic Mail 和 Andrew Ng 的语音智能体课程都说明，收件箱和电话正在变成智能体界面，但审批逻辑、可靠性和工作流边界仍不成熟。
[+] 兼顾成本的模型路由与私有开放模型部署 —— Morgan Linton 的技术栈卡片、Levie 的模型路由观点、GLM 5.2 访问讨论，以及 Venice 的私有网关，都在指向对工具的需求：它既要能选出“足够便宜但也足够可靠”的模型，又不能牺牲信任或速度。
8. 要点总结¶
- 6 月 18 日，市场讨论的重点是智能体周围的控制层，而不只是内部模型。 Levie 的讨论把工作流集成与治理定义成护城河，DeepMind 的公开控制路线图则提供了与之匹配的系统级词汇。(source)
- 有状态能力如今已经开始用运行时指标来衡量，而不是只停留在产品文案里。 Hermes 的记忆批量更新附上了一张具体的前后对比卡片，明确展示了调用次数下降和验证数量。(source)
- 模型路由正在变成正常的运营实践。 Morgan Linton 的公开技术栈卡片、Levie 的路由论点，以及 GLM 5.2 访问讨论，都表明规划者、执行者和审查者正在被越来越多地分配到不同模型和网关上。(source)
- 可复用的技能与测试框架工件，是信息流里最清晰的构建模式之一。 Deep Agents in Action、ctf-skills、Omnigent、HermesHub 和 Loop Engineering Orange Book，都在把智能体经验与方法打包起来，让它可以被复用，而不是每次重写提示词。(source)
- 智能体开始拥有沟通渠道，但控制问题也随之进入这些渠道。 Atomic Mail 的智能体收件箱和 Andrew Ng 的语音智能体课程，都把渠道迁移变成了具体事实，而回复则立刻追问审批、时延和可靠性。(source)