跳转至

Twitter AI - 2026-06-20

1. 人们在讨论什么

1.1 智能体工作被定义为编排能力和操盘技能,而不只是更会写提示词 (🡕)

当天最强的高信号帖子,把 AI 进展视为一个协调问题。讨论重点放在:谁能搭好智能体、让经验在多次运行之间留存、把工作拆成可靠的子系统,而不是谁能写出最炫的提示词。这个转向由 3 类不同内容共同支撑:一条劳动力市场帖子、一个研究成果,以及一个关于检索架构的论点。

@gregisenberg 写道(230 点赞、44 回复、7,905 浏览、174 收藏),当下最有价值的技能,是搭建智能体、运行本地模型、做分发,以及把机器人和 AI 结合起来。@dair_ai 介绍了 Skill-MAS(17 点赞、3 回复、1,243 浏览、18 收藏)——一个论文和代码同时发布的项目:它保持前沿模型冻结,同时演化一种可复用、基于文本的元技能,用于任务拆解、智能体工程和工作流编排(paperrepo)。@pauliusztin_ 则认为(15 点赞、3 回复、791 浏览、14 收藏),递归语言模型可以把大型文件、代码库和深度研究任务拆成更小的调查单元,从而让部分检索基础设施变得不再必要。

Skill-MAS 的项目截图,展示论文标题及其三阶段多智能体工作流设计

对比传统 6 段式 RAG 流水线与单段式 RLM 方法的示意图

讨论要点: 回复用更直白的话表达了同一个判断。Greg Isenberg 那条帖子的回复说,真正的分野在于:谁能搭建并运行本地 AI、谁能做机器人、谁能建立受众;而 Skill-MAS 讨论串里则有人追问,它的反思循环在分布漂移下是否还能成立,这说明大家既感兴趣,也在质疑这类编排能力的真实可靠性。

与前日对比: 6 月 19 日的重点是运行时信任、治理和智能体的生产控制。到 6 月 20 日,讨论又往技术栈更前一层移动,变成谁能协调智能体工作,以及编排本身如何学习。

1.2 经济性和模型市场压力变得更难忽视 (🡕)

当天最有力的经济类帖子,谈的不是模型 IQ,而是 AI 需求是否足以支撑当前 capex、更便宜的中国模型会不会挤压高价方案,以及本地硬件是否已经好到可以替代持续性的订阅支出。

@FoamOnTheRunway 认为(100 点赞、17 回复、17,468 浏览、50 收藏),AI 泡沫其实已经破了,只是半导体股票还没重新定价;他给出的依据包括 GPU 租赁价格下跌、超大规模云厂商从债务融资转向股权融资,以及补贴结束后的需求转弱。@C_Barraud 写道(47 点赞、3 回复、3,399 浏览、13 收藏),中国模型正在 OpenRouter 上赢下使用量、成本和采用率之争,同时也提醒说,token 份额并不代表整个市场。另有 3 条关于本地算力的帖子,从开发者角度讲了同一个成本故事:@gippp69 总结了一个 400 美元二手 GPU 家用方案(30 点赞、17 回复、1,360 浏览、19 收藏),目标是替代每月 110 至 260 美元的托管栈;@starmexxx 声称(38 点赞、13 回复、2,660 浏览、17 收藏),一台 M4 Mac mini 在被引用的本地基准测试里跑赢了 RTX 5060 Ti;@0xRicker 则表示(25 点赞、3 回复、534 浏览、21 收藏),一台 Minisforum 迷你 PC 就能把 70B 和 120B 的本地模型放进内存。

对比费城半导体指数与大盘走势的股价图,用来支撑看空 AI capex 的观点

图表显示 2026 年上半年中国模型在 OpenRouter 上的使用量超过美国模型

讨论要点: 回复大致分成两派:一派对低成本本地方案很兴奋,另一派则怀疑 OpenRouter token 份额到底能说明多少整体市场情况。OpenRouter 那条讨论里有人回复说,这只是总 token 使用量里很小的一块;而 Mac mini 那条下面,大家更多在谈功耗和立刻下单的意愿。

与前日对比: 6 月 19 日已经能看到开发者在寻找更便宜的测试环境和本地执行路径。到 6 月 20 日,这一趋势上升成了更宏观的定价与变现叙事,横跨半导体估值、API token 份额和家用方案替代账单的计算。

1.3 严肃的 AI 部署讨论持续进入行业和机构基础设施 (🡕)

模型层之下最有说服力的开发者帖子,来自那些在谈具体部署环境的团队:非洲语言语音系统,以及军事规划。这些并不是泛泛的“AI 会改变一切”,而是绑定明确运行场景的技术栈描述。

@Abba_kakaa 写道(45 点赞、8 回复、403 浏览),可靠的语音 AI 需要的不只是语音模型,还要有数据集、转录流水线、标注系统、基准测试、方言评估、检索、工具执行、监控和反馈回路。Dialectra 的公开网站给出了更具体的基础设施和基准数字,包括 1,240 小时已验证的 Hausa 数据、680 小时 Fulfulde 数据、420 小时 Kanuri 数据,以及训练后的 WER 分别为 8.2%、11.4% 和 13.1%(Dialectra)。@shashj 引用了一位 9 Deep Recce Strike Brigade 指挥官的话(22 点赞、4,842 浏览),称 HIVEMIND 大语言模型能把原本需要数天制定的计划缩短到数小时,而链接中的 British Army Review 还提到,Project Asgard 让 Strategic Reserve Corps 能以前所未有的速度和规模,对从开源到 Above Secret 的海量数据进行分流处理(CHACR PDF)。

讨论要点: 共同模式是全栈思维。Dialectra 的讨论串明确认为,未来赢家会理解从语音采集到部署的整条价值链;而 Army 这个案例,则把 LLM 的价值定义为现有机构内部的规划提速和数据分流,而不是一个消费级助手。

与前日对比: 6 月 19 日的讨论已经下沉到方言数据、基准测试和算力。到 6 月 20 日,这一趋势进一步延伸到可见的已部署系统:面向非洲语言的语音基础设施,以及服务军方总部的 AI 辅助规划系统。


2. 令人困扰的问题

编排能力依然比模型接入更稀缺

严重程度:高。@gregisenberg 表示(230 点赞、44 回复、7,905 浏览、174 收藏),搭建智能体、运维本地模型和做分发,已经属于顶级技能,这意味着模型接入本身已不再是主要瓶颈。@dair_ai 介绍了一个完整的研究方向(17 点赞、3 回复、1,243 浏览、18 收藏),专门研究如何在不重新训练权重的情况下改进编排;@pauliusztin_ 则明确表示(15 点赞、3 回复、791 浏览、14 收藏),对某些工作负载来说,检索栈太复杂了。当前的应对模式,是写规格、拆子任务,以及搭建可复用的编排层。这值得做,因为这种痛点同时出现在研究、招聘和实际的检索架构工作里。

托管 AI 的经济模型看起来越来越脆弱

严重程度:高。@FoamOnTheRunway 认为(100 点赞、17 回复、17,468 浏览、50 收藏),超大规模云厂商的 capex 经济性正在恶化;与此同时,@C_Barraud 认为(47 点赞、3 回复、3,399 浏览、13 收藏),足够好且更便宜的中国模型正在抬高定价压力。从开发者侧看,@gippp69 声称(30 点赞、17 回复、1,360 浏览、19 收藏),二手 GPU 家用方案可以替代按月付费的托管栈;@starmexxx 则声称(38 点赞、13 回复、2,660 浏览、17 收藏),一台低成本 Mac mini 在一项被引用的本地测试里就能跑赢独立 GPU。当前的权宜方案,是本地推理、更小的开源模型,以及“够用就行”的路由策略,而不是每次都为高端闭源模型付费。这值得做,因为市场评论者和一线用户正在对同一个价格问题形成共识。

行业部署仍然需要过多定制化基础设施

严重程度:中。@Abba_kakaa 列出了语音智能体背后缺失的部件(45 点赞、8 回复、403 浏览):高质量数据集、转录、标注、基准测试、方言评估、检索、工具执行和监控。@shashj 分享了一个军事案例(22 点赞、4,842 浏览),其中规划速度之所以提升,是因为 LLM 支持被嵌入了现有指挥工作流。当前的绕行方案,是围绕具体机构搭建专属技术栈。这值得做,因为最强的部署案例依然要求团队先把许多层自己拼起来,终端用户才能看到价值。


3. 人们期望的功能

能够积累经验的可复用编排层

大家想要的似乎不只是更强的基础模型,而是能让工作流知识跨多次运行保留下来的机制。@dair_ai 分享了一个系统(17 点赞、3 回复、1,243 浏览、18 收藏),它明确就是为了在不更新模型权重的情况下演化编排技能;而 @gregisenberg 则认为(230 点赞、44 回复、7,905 浏览、174 收藏),当下稀缺的劳动,已经变成如何搭好并正确管理智能体。这是一个有直接需求的现实问题,因为人们已经在手工为这个缺失层投入时间。机会:直接。

价格可承受、同时性能也过得去的私有算力

当天反复出现的需求,是既足够私密、又足够便宜,能脱离高价订阅独立运行的 AI。@gippp69 描述了一个为了替代月度 AI 账单而搭建的家用方案(30 点赞、17 回复、1,360 浏览、19 收藏);@starmexxx 分享了一套低功耗 Mac mini 的基准测试叙事(38 点赞、13 回复、2,660 浏览、17 收藏);@0xRicker 则表示(25 点赞、3 回复、534 浏览、21 收藏),一台迷你 PC 能装下比用户预期大得多的本地模型。这是一个有直接需求的现实问题,但竞争会非常激烈,因为硬件厂商、路由层和开源模型栈都在往这里收敛。机会:竞争激烈。

面向行业场景的数据与部署栈

@Abba_kakaa 论证了非洲语音生态仍然需要从采集、标注一直到部署的整条路径(45 点赞、8 回复、403 浏览),而 Dialectra 的公开网站则用具体的数据集和基准基础设施解释了原因。@shashj 分享的 Asgard 案例,也为机构场景 指向了相同方向(22 点赞、4,842 浏览):只有当模型被嵌入能分流数据并加速规划的工作流时,它才真正有意义。这是一个现实需求,但它更偏行业、也更依赖关系,不是单一通用产品类别。机会:直接。

面向长上下文工作的更简单混合知识系统

@pauliusztin_ 认为(15 点赞、3 回复、791 浏览、14 收藏),RLM 可以去掉大型文件和代码库工作中经典检索栈的一部分;与此同时,@DanKornas 分享了一条仍然活跃的工具链(39 点赞、1 回复、1,219 浏览、36 收藏),涵盖向量数据库、Typesense、LangGraph、MongoDB Vector Search 和 RAG 评估。这种组合说明,人们仍想要一种更简单的架构:既保留 RAG 的精确性,又减少它的运维开销。机会:竞争激烈。


4. 使用中的工具与方法

工具 类别 评价 优势 局限
ChatGPT LLM 助手 (+/-) 在一张对比矩阵里被描述为适合创意工作、编程和日常效率任务 用户会明确拿它和更专门的工具比较,而不是把它当成默认赢家
Gemini LLM 助手 (+/-) 被定位为适合 Google Workspace 集成和更新更快的网页数据;同时也是低成本竞争压力叙事的一部分 指导类帖子说明,很多用户依然把它当 ChatGPT 那样去提示,从而错过了工具特有的行为
Claude LLM 助手 / 编码 (+) 经常和深度阅读、编程以及规格密集型工作流联系在一起 它更多出现在更大的工作流系统中,而不是单独作为完整架构出现
Perplexity 研究助手 (+) 在对比图中因带引用的研究和事实核查能力而被看重 它被视为碎片化栈中的一个工具,而不是通用接口
OpenRouter API 路由器 / 市场代理 (+/-) 能让人看到快速变化的模型使用情况,并降低跨厂商切换摩擦 token 份额不代表整个市场,也无法直接映射到收入
RAG stack (Typesense, LangGraph, MongoDB Vector Search) 检索流水线 (+/-) 仍被积极用于教学,覆盖摄取、向量搜索、高级检索和评估 组件太多、基础设施额外负担重,让它在某些工作负载下显得笨重
Recursive Language Models 推理方法 (+/-) 能把大型文件、代码库、法律和研究任务拆开处理,而不必把所有内容塞进一个上下文窗口 不能完整替代 RAG;对更简单的查询来说,仍可能更慢或更复杂
Skill-MAS 多智能体编排框架 (+) 把任务拆解、智能体工程和工作流编排演化成一层可复用技能 仍处于研究阶段,生产环境中的稳健性和迁移能力还有疑问
Dialectra 语音数据 / 基准平台 (+) 为非洲语言提供经过验证、带方言标签的数据集、基准套件、分析能力和 API 按设计就是聚焦一个特定地区的语音 AI 问题集
Project Asgard / HIVEMIND 规划决策支持系统 (+) 公开证据显示,它能在军事工作流里分流大规模数据并加快规划 偏机构、偏专用,并不是面向公众的通用产品

对比矩阵,将 ChatGPT、Grok、Gemini、Claude 和 Perplexity 映射到各自最适合的使用场景

整体满意度分布更偏务实,而不是意识形态站队。用户并没有选一个通吃的万能模型,而是在按任务拆分工具,把闭源助手、路由层、本地硬件、检索栈和编排方法混着用。

共同的权宜模式,是做技术栈分层。RAG 仍被积极用于精确检索,但 RLM 式拆解正在受到更多关注,因为它可以在长上下文工作中减少基础设施负担。在成本侧,OpenRouter 式路由和本地硬件方案,其实都指向同样的迁移压力:只要更便宜或本地的路径“够用”,越来越少的人愿意为每个请求都支付高价。


5. 人们在构建什么

项目 构建者 功能 解决的问题 技术栈 阶段 链接
Skill-MAS Hehai Lin et al. 演化一种可复用的元技能,用于在 3 个阶段中设计并编排多智能体系统 团队希望编排知识能够持续积累,而不是每次都要重新训练基础模型 Frontier LLMs、多轨迹 rollout、对比式反思、生成的 MAS 代码 Alpha paper, repo, tweet
Dialectra @Abba_kakaa 为非洲语言构建具备方言感知的语音数据集、基准套件、分析和 API 语音团队在可靠产品上线前,需要经过验证的本地语言数据和评估体系 数据采集、母语者验证、标注、基准引擎、API 已发布 tweet, site
Project Asgard / HIVEMIND British Army / CHACR 用于分流数据并加速军事规划工作流的 AI 辅助决策支持与规划工具 指挥机构需要处理大体量数据,并更快产出规划方案 基于 LLM 的规划支持、跨密级数据分流、总部工作流集成 Beta tweet, PDF

@dair_ai 带出了当天技术表达最明确的构建成果(17 点赞、3 回复、1,243 浏览、18 收藏)。公开 repo 显示,Skill-MAS 会演化一个单独的 SKILL.md 文件,用它来处理任务拆解、智能体工程和工作流编排,再通过多轮 rollout 与对比式反思去重写这项技能。这很重要,因为它把“智能体 know-how”变成了团队可以版本化、可以优化的东西,而不是每次从零重新摸索。

@Abba_kakaa 分享了另一种构建模式(45 点赞、8 回复、403 浏览):为通用模型领导者覆盖不足的行业场景搭基础设施。Dialectra 的网站非常明确地展示了它的产品面,从带方言标签的语料、母语者验证,到基准套件、API 和部署就绪度报告。

@shashj 引用了一个少见的公开机构案例,而不是创业公司发布(22 点赞、4,842 浏览)。链接中的 British Army Review 把 Project Asgard 描述成一个决策支持层,帮助一个军团级规划机构对从开源到 Above Secret 的数据进行分流,这使它成了公开材料里最清晰的 LLM 被嵌入现有指挥工作流的案例之一。

反复出现的构建模式,是做基础设施,而不是做套壳。最强的项目不是通用助手外壳,而是围绕具体瓶颈构建的编排系统、行业数据集和机构专用决策层。


6. 新动态与亮点

OpenAI 的人才争夺被描述成一场架构竞赛

@MTSlive 写道(60 点赞、3 回复、6,815 浏览、9 收藏),Noam Shazeer 在 Google 和 Character AI 参与了核心 transformer、scaling、mixture-of-experts、Gemini、Flash 与 Gemma 等工作后,现已加入 OpenAI。这条讨论之所以值得注意,不是因为名人八卦,而是因为它采用了这样一个框架:这类招聘之所以重要,是因为架构研究依然被视为递归式自我改进和前沿模型竞争中的决定性杠杆。

军事规划成为最清晰的机构级 LLM 案例之一

@shashj 分享了一个公开的军事规划案例(22 点赞、4,842 浏览),它冲破了企业 AI 常见的模糊说法。推文和链接中的 CHACR 评论,把价值主张直接对应到明确结果:从按天计的规划缩短到按小时计,以及更快分流大规模涉密和开源数据流。


7. 机会在哪里

[+++] 智能体编排与经验留存层 —— Greg Isenberg 的技能市场帖子、Skill-MAS,以及 RLM/RAG 的讨论,都指向同一个缺口:模型接入已经不难,但可靠的任务拆解、编排和可复用的工作流知识依然稀缺。

[+++] 具备成本意识的私有化与本地 AI 基础设施 —— 对半导体的怀疑、OpenRouter 带来的定价压力,以及多条本地硬件基准测试讨论,都说明市场需要更低的持续成本、更强的隐私,以及更少依赖高价托管推理。

[++] 面向行业场景的数据与部署栈 —— Dialectra 和 Project Asgard 表明,真正的价值往往只会在团队解决了行业数据质量、评估、工作流集成和机构约束之后才出现。

[+] 混合检索与长上下文推理系统 —— 活跃的 RAG 工具链与 RLM 式简化之间的张力,说明市场有空间做出既保留检索精度、又降低流水线复杂度的产品。


8. 要点总结

  1. 讨论已经从“哪个模型最聪明?”转向“谁真的能把这套栈跑起来?” 当天互动最强的帖子,谈的是智能体搭建、本地模型、机器人和分发能力,而不只是模型品牌本身。(source)
  2. AI 经济性看起来比 AI 能力更有争议。 看空市场的人、OpenRouter 的使用图表,以及本地算力基准测试讨论,都在追问同一个问题:一旦更便宜或本地的替代方案“够用”,高价方案还能保住多少定价权。(source)
  3. 严肃的开发者仍在聊天机器人这一层之下持续投入。 Skill-MAS、Dialectra 和 Project Asgard 的重点,都是编排、数据和工作流集成,而不是再做一个通用助手套壳。(source)
  4. RAG 没有消失,但正在被两边同时挑战。 一部分 Twitter 仍在教学向量数据库、LangGraph 和评估,另一部分则认为,递归式、智能体风格的推理可以替代长上下文工作里的一部分栈。(source)