Twitter AI 编程 - 2026-06-16¶
1. 人们在讨论什么¶
1.1 Codex 和 Copilot 持续把智能体功能做成可见的产品界面 🡕¶
6 月 16 日最清晰的讨论簇，并不是某个新模型发布，而是产品界面变得更具体了：Codex 的浏览器控制、更广区域的 Codex 功能铺开，以及 GitHub Copilot App 面向编排和可视化的多项 UI 更新。共有 5 条保留条目支撑这一主题。
@testingcatalog 报道（740 个点赞、27 条回复、44,368 次浏览、331 次收藏），Codex 现在支持借助 Chrome DevTools Protocol 使用浏览器。这条帖子把它描述成一种让 Codex 检查并修改网站的方式，而回复区立刻把讨论推向了操作控制而非噱头：有人要求提供被触达标签页日志，也有人说，浏览器使用让 Web 应用也能像代码一样进入同一个检查、编辑、测试循环。
@RoundtableSpace 表示（151 个点赞、12 条回复、51,500 次浏览、139 次收藏），OpenAI 正向符合条件的用户提供最多 1,200 美元积分、6 个月 ChatGPT Pro，以及 Codex 访问权限，交换条件是一个公开 GitHub 仓库。这里真正重要的是回复区：人们把这项提议视作重启那些被搁置或做了一半项目的方式，同时也仍在质疑 Codex 是否能稳定到足够实用。
@testingcatalog 补充（58 个点赞、4 条回复、3,521 次浏览），OpenAI 正把 Codex 的计算机使用功能、Chrome 扩展、个性化记忆和 Chronicle 扩展到 EEA、英国和瑞士用户，并引用了底层的 OpenAIDevs 帖子。这让浏览器使用这条线更像一次更大范围的铺开，而不是单点实验。
@_Evan_Boyle 展示 了 GitHub Copilot App 里的一个新的 /orchestrate 技能（32 个点赞、4 条回复、1,997 次浏览、16 次收藏），用于在多个会话和仓库之间协调工作。他在回复里还说，会话之间现在可以互相收发消息——这比泛泛的“多智能体”营销说法具体得多。
@mariorod1 展示 了在 GitHub Copilot App 内渲染 Mermaid 图表（49 个点赞、3 条回复、1,409 次浏览）；@_Evan_Boyle 则强调 了一个更小但彼此呼应的控制项：可按时间或最近活动排序会话（37 个点赞、2,065 次浏览）。这两条帖子放在一起，说明 Copilot App 的工作正在从核心智能体执行，继续扩展到组织管理和可视化解释。
讨论要点： 最有价值的回复，集中在护栏和可读性上。人们要的不只是“计算机使用”，而是智能体碰了哪些标签页、哪个会话在做什么，以及多个会话是如何被协调起来的证据。
与前日对比： 6 月 15 日已经把编排看作运行框架问题。到了 6 月 16 日，同样的故事进一步落在了可见产品 UI 上：浏览器控制、/orchestrate、Mermaid 渲染，以及会话管理打磨。
1.2 一线实践者分享了更明确的多智能体监督手册 🡕¶
第二个主要主题偏向运营层面。讨论已经不再是多智能体编程是否可行，而是怎样真正把它跑起来：先讨论、再拆分工作、保留上下文、监督多个会话，甚至让多个真人共享同一个会话。共有 4 条保留条目支撑这一主题。
@KingBootoshi 概述 了一套长链路的 Claude Code/Codex 工作流（27 个点赞、7 条回复、1,413 次浏览、40 次收藏）：从最初的讨论串、主 PRD、基础分支，到从缓存上下文分叉出来的并行 worktree。这里最有辨识度的主张，不只是“多用几个智能体”，而是 APFS 的 copy-on-write 克隆加上分叉聊天，能让文件上下文保持足够热，从而让并行工作既更便宜也更快。
@aakashadesara 发布 了 CTOP（2 个点赞、2 条回复、75 次浏览），把它作为一个终端视图，用来总览 Claude、Codex、OpenCode 和 Devin 会话。配图截图之所以重要，是因为它把实时上下文占比和成本放进了同一个面板；一旦人们不再一次只跑一个智能体，这正是他们需要的监督界面。
@tdinh_me 分享 了一个既好笑又很说明问题的例子（1 个点赞、2 条回复、428 次浏览）：一个借 Telegram 对外开放的 Claude Code 会话，在共享工作流里主动 ping 错了人。这个笑点本身就是重点。一个有状态的单一会话，已经开始被当成两位用户共享的基础设施。
@oliviscusAI 提到 ECC，把它称作“AI 编程智能体的操作系统”（12 个点赞、2 条回复、340 次浏览、9 次收藏），支持 Claude Code、Cursor、Codex、OpenCode、Gemini CLI、Zed 和 GitHub Copilot，拥有 271 项技能、67 个智能体和 92 条命令。即使这条帖子带有明显宣传性质，它仍强化了同一种模式：人们越来越期待模型外面有一层可复用的环境层。
讨论要点： 最强的一线细节，在于状态和监督，而不是模型 IQ。真正难的问题，是如何跨分支保留上下文、弄清每个智能体在做什么，以及避免共享会话变得一团糟。
与前日对比： 6 月 15 日把编排更多当成基准和 plugin API 话题。6 月 16 日则补上了更明确的操作流程、监控界面，以及共享会话行为。
1.3 配额计算和可靠性，仍决定着人们是否信任这套工作流 🡕¶
第三个大主题是，即便是热情用户，评判 AI 编程工具时仍会看配额清晰度、价格可预测性，以及应用本身是否稳定。共有 5 条保留条目支撑这一主题。
@rxhit05 报道（17 个点赞、14 条回复、469 次浏览），Google Antigravity 刚刚获得 3 倍配额提升。截图本身很有信息量，因为它把“更多配额”变成了一次可见的产品变更；但回复区态度不一：有人说这已经够拿来做一个 SaaS，也有人说，限制仍然大致会在同一个节点出现。
@manu_varru 表示（2 条回复、104 次浏览），在用 Google AI Studio 生成图片之后，Antigravity 的倒计时从几小时跳成了几天，而面板里又缺少可信的用量追踪器。这张截图之所以重要，是因为它把一个模糊抱怨变成了明确诉求：用户要的是一个他们能信的计数器。
@_mauriciorubio 报告（2 个点赞、197 次浏览），Codex 即使更新后仍不稳定，会出现循环、空白聊天、重复报错，以及 token 继续消耗。配套截图直接展示了这种矛盾：一个界面说应用已经是最新版本，另一个界面却仍然显示会阻塞使用的错误状态。
@slicknet 链接 到一篇详细的 定价分析（2 个点赞、260 次浏览），认为 GitHub Copilot 从 6 月 1 日起转向按 AI credits 计费后，后台智能体、代码审查、云端智能体和多智能体流程在心理定价上都变得更难估算。这篇文章之所以有用，是因为它把当天零散的小抱怨，连接成了一个更大的产品设计问题：一旦智能体开始异步运行，成本就变得难以预测。
@alexcovo_eth 补充（24 个点赞、2,174 次浏览、6 次收藏），更重度的 Codex 加 Hermes 使用，正在烧掉足够多的 token，让给客户报固定价变得更难；而那张用量热力图截图，则用具体的日活跃度而不是泛泛的“AI 很贵”抱怨，为这一点提供了支撑。
讨论要点： 只要计量器讲得清楚、应用又保持响应，人们愿意花钱，也愿意盯配额。最棘手的抱怨，集中在隐性消耗、互相矛盾的倒计时，以及更新损坏后 token 还在继续流失。
与前日对比： 6 月 15 日已经把限制和计量器看成产品的一部分。6 月 16 日则继续加压，但抱怨更明确地指向了追踪器准确性、后台消耗，以及生产环境级的不稳定性。
2. 令人困扰的问题¶
配额记账对长时智能体工作来说仍然过于模糊¶
严重程度：高。@manu_varru 表示（2 条回复、104 次浏览），Antigravity 在做一些小型站点更新时还显示剩余数小时，但在用 Google AI Studio 生成图片后就跳成了几天，并明确要求提供一个像样的用量追踪器。@rxhit05 庆祝 3 倍配额提升（17 个点赞、14 条回复、469 次浏览），但仍有回复说产品大致还是会在同一个点撞上限制。@alexcovo_eth 补充（24 个点赞、2,174 次浏览、6 次收藏），重度使用 Codex 加 Hermes，让他们很难给客户报固定价格。人们现在的应对方式，是盯着面板、更加挑拣地分配工作，并试着发明自己的成本估算启发式。这件事值得投入，因为智能体工作流现在已经长到，糟糕的计量器会直接打断规划和客户交付。
稳定性故障摧毁信任的速度，仍比新功能建立信任更快¶
严重程度：高。@_mauriciorubio 报告（2 个点赞、197 次浏览），Codex 在更新后依然无法使用，会出现循环、空白聊天，以及为恢复状态不断烧 token。即便是当天互动量最高的 Codex 浏览器使用讨论串里，也有 @SlykePhoxenix 在 @testingcatalog 的 发布串 下回复说，桌面应用在自己机器上仍然无法正确保存设置（740 个点赞、27 条回复、44,368 次浏览、331 次收藏）。眼下的绕行方式主要还是重试、刷新，或者直接放弃这条流程。这件事值得投入，因为后台智能体、浏览器控制和多会话工作只有在客户端足够稳定、能被持续监督时才有价值。
在很多用户眼里，Google 的编程产品栈仍然显得支离破碎¶
严重程度：中。@haider1 发问（73 个点赞、12 条回复、4,618 次浏览），Google 到底在“做什么大菜”，因为 AI Studio、Antigravity、IDE 界面和 Jules 在战略上仍让人摸不着头脑。回复区对这些产品究竟彼此重叠，还是各有明确分工，看法并不一致——而这本身就是问题所在：用户很难清楚判断一条工作流究竟在哪个产品里开始，又在哪个产品里结束。眼下最实际的应对方式，是不断试错，再靠其他用户的口口相传来做“翻译”。这件事值得投入，因为即便是感兴趣的用户，也会在平台地图难以解释时失去信心。
3. 人们期望的功能¶
值得信赖的配额与预算控制¶
6 月 16 日最直接的诉求，不是更聪明的模型，而是人们真正能信的计量体系。@manu_varru 明确要求（2 条回复、104 次浏览），在 Antigravity 倒计时意外跳变之后，需要一个像样的用量追踪器；@slicknet 链接 到一篇更长的论证（2 个点赞、260 次浏览），指出一旦智能体开始在后台运行，按用量计费的 Copilot credits 就很难再让人直觉理解；@alexcovo_eth 则从咨询侧 把同样需求说得更具体（24 个点赞、2,174 次浏览、6 次收藏）：token 消耗已经越来越难报价。这是一个带着直接收入影响的实际需求。机会：直接。
更好的多智能体与共享智能体监督层¶
当天也清楚显示出，人们希望在单个会话之上再有一层控制层。@_Evan_Boyle 推出 了用于跨会话和仓库协调工作的 /orchestrate（32 个点赞、4 条回复、1,997 次浏览、16 次收藏）；@aakashadesara 展示 了作为多智能体会话仪表板的 CTOP（2 个点赞、2 条回复、75 次浏览）；@tdinh_me 则暴露 出共享会话有多容易失控：一个 bot 开始叫错用户（1 个点赞、2 条回复、428 次浏览）。隐含的愿望，是让多智能体工作变得可检查、可归因，而且能安全共享。机会：直接。
更低配置税的本地优先与移动端智能体工作空间¶
构建者的帖子说明，人们对能把配置摩擦压缩掉的工作空间兴趣很强。@RFzinc 发布 了 Shelly（3 个点赞、3 条回复、55 次浏览）：让 Codex CLI 在 Android 上原生运行，不需要 PC、Termux 或 proot；@kalyan_kpl 则把 Colab CLI 描述成一座从本地终端通向远程加速器的零摩擦桥梁（27 个点赞、2 条回复、2,243 次浏览、19 次收藏）。反复出现的诉求，不只是“让 AI 跑在更多设备上”，而是“在真正开始高效工作前，少做点接线活”。机会：竞争型。
4. 使用中的工具与方法¶
| 工具 | 类别 | 评价 | 优势 | 局限 |
|---|---|---|---|---|
| OpenAI Codex | 编程智能体 | (+/-) | 借助 Chrome DevTools Protocol 使用浏览器、区域覆盖持续扩大、真实使用热度高、向公开仓库构建者提供资助/访问 | 更新器失败、循环/空白聊天、桌面端不稳定，以及 token 消耗难以定价 |
| GitHub Copilot App | 智能体工作空间 | (+) | 可在会话/仓库间使用 /orchestrate、支持 Mermaid 图表、会话排序，以及围绕长工作流的可见 UI 打磨 |
回复区仍不断出现对定价、BYOK 和平台支持的疑问 |
| Google Antigravity | 规划/编排工具 | (+/-) | 架构/规划、作为第二意见的审查角色、配额增加，以及与 Claude Code 配合工作 | 用户仍报告配额困惑，以及它相对 AI Studio 和 Jules 的定位不清 |
| Claude Code | 偏执行的编程智能体 | (+/-) | 擅长里程碑式执行、文件编辑、测试，以及与规划工具配对使用 | cache/worktree 行为仍需要手工处理，共享会话流程也可能变乱 |
| Google Colab CLI | 远程执行 CLI | (+) | 从终端申请 GPU/TPU、远程执行、下载产物/日志，适合智能体驱动的 ML 工作流 | 当天证据主要来自一条解释性讨论串，尚未看到广泛用户验证 |
| Shelly | 移动端编程工作空间 | (+) | 在 Android 上原生运行 Codex CLI，带 Agent Chat 和配额/成本组件，避开 Termux/proot 配置 | 当天仍是早期使用信号，证据主要来自单个构建者 |
| 9Router / Hermes / UsePod-style routing | 成本/路由层 | (+/-) | 低价备份/免费层路由、替代性提供商定价，以及接入现有工具的 localhost 桥 | 证据多半是宣传性内容，而且要求用户自己理解提供商/路由复杂度 |
| CopilotKit MCP server | 上下文 server / 文档层 | (+) | 主打免费、无限制；索引仓库、聊天、文档、PDF，并随产品变化更新 | 当天证据主要来自厂商自述，缺少独立验证 |
整体满意度非常实际。人们称赞那些能让智能体工作更可见、更便宜或更容易起步的工具；而当配额计算、更新行为或产品边界仍然不透明时，他们就会抱怨。
最清晰的方法分层，是在 Antigravity 或其他编排层里做规划，再到 Claude Code 或 Codex 里执行。最明显的市场分层，则是完整智能体工作空间与其周边支撑工具之间的分化：路由、MCP/上下文 server、输出过滤、移动端封装，以及监督仪表板。
5. 人们在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| BugHunter / Claude Bug Bounty | @tom_doerr / shuvonsec | 在 Claude Code 内部或作为独立 CLI，自动化漏洞赏金工作的侦察、挖掘、验证和报告 | 安全研究人员希望获得端到端的智能体工作流，而不是手动把提示词和扫描器缝在一起 | Python CLI、shell 扫描器、Claude Code plugin、独立模式、Ollama/Groq/DeepSeek/Claude/OpenAI 提供商 | 已发布 | 仓库, 推文 |
| Postrboard | @burkeholland | 一个带实时文档与组件的个人 CSS 框架和设计语言 | 想快速塑造一套自定义设计系统，而不必每次都从零开始 | design tokens、CSS 组件库、实时文档站点、基于 skills 的安装流程 | 已发布 | 网站, 推文 |
| mfertown / mferland | @HeresMyEth | 一个面向人类和智能体的开放 MMO，带 quests、fights、skills 和实时世界状态 | 把智能体变成持久环境中的一等用户，而不只是代码生成器 | 实时 Web 游戏、钱包认证智能体、skill router、只读 world/player APIs | 已发布 | 游戏, 技能, 推文 |
| Shelly | @RFzinc / RYOITABASHI | 在 Android 上原生运行真正的 Codex CLI，带实时 Agent Chat 和配额组件 | 去掉移动端 AI 编程所需的桌面/Termux/proot 配置税 | 原生 Android 应用、应用自有 PTY、Codex CLI、打包 Git/Bash/Python、Expo、TypeScript | 已发布 | Product Hunt, 仓库, 推文 |
BugHunter 之所以突出，是因为公开 README 把技术栈和范围写得格外明确。它不只是一个提示词包；它把侦察、验证闸门、报告模板和提供商选择打包进了一条智能体工作流，这正是这一天信息流里反复出现的“把工作流做成产品”的模式。
Postrboard 规模更小，但它揭示了另一种构建者模式：用 Copilot 生产个人基础设施，而不是面向客户的 SaaS。实时文档页里能看到真实的 tokens 和组件，所以结果不只是一个 logo 或落地页 mockup。
mfertown 和 Shelly 指向两个不同、但彼此呼应的方向。mfertown 把智能体当成世界内的行动者，拥有公开状态和任务；Shelly 则把手机当成完整的本地 AI 编程工作站，在打包终端里直接运行 Codex。两者共同点在于，构建者扩展的是智能体可以栖身的地方，而不只是它们能回答什么提示词。
反复出现的构建模式已经很清楚：人们正用领域工作流、自定义界面或替代运行时去封装编程智能体，而不是等待基础工具自己无所不能。
6. 新动态与亮点¶
输出过滤变成了一门节省 token 的产品¶
@carsonthedev 发布 了 opencode-smartsnip（4 个点赞、4 条回复、87 次浏览），这个工具会在 shell 输出送进模型之前先做过滤。对于一次小发布来说，它的说法异常具体：git 输出减少 72%、pnpm 输出减少 48%，并在一个真实工作日里减少了约 100 万 token 的上下文流量。它之所以重要，是因为它正面击中了其他讨论串反复抱怨的一个实际成本中心。
MCP 基础设施开始以“新鲜度”和“零限制”来销售¶
@CopilotKit 认为（24 个点赞、1 条回复、1,032 次浏览、16 次收藏），它的 MCP server 之所以能保持免费且不限量，是因为它只维护一个生态系统，同时又能索引仓库、Discord 讨论串、Slack 对话、Notion 页面和 PDF。这里真正有趣的转向，不是常见的“我们有文档”，而是承诺上下文 server 的更新速度应该和产品变化一样快。
围绕前沿模型的价格发现正在变成独立的一层¶
@0xgilbert 发布 了一张定价面板（61 个点赞、7 条回复、3,605 次浏览），显示 GPT-5.5 通过 marketplace routing 提供时，价格远低于 OpenAI 官方直供。回复区明确把这称作“推理资本市场”，意思已经很清楚：提供商套利正在成为编程智能体工具包的一部分，而不只是后台问题。
7. 机会在哪里¶
[+++] 智能体配额控制平面 —— 证据同时来自第 1 节和第 2 节：Antigravity 的配额提升、对更好追踪器的明确请求、Copilot 按用量计费引发的争论，以及咨询侧对高 token 工作难以定价的真实困扰。最强的切入口不是再做一个模型封装层，而是提供支出可见性、任务级记账，以及后台智能体更清晰的失败边界。
[++] 多智能体监督与共享会话安全 —— /orchestrate、CTOP、KingBootoshi 的 worktree 加缓存手册，以及共享的 Telegram/Claude 会话，都指向同一种需求：一旦多个智能体或多人同时碰一条工作流，归因和监控就变得关键。市场上仍有空间做出这样的产品：清楚展示哪个会话改了什么、正在对哪个用户说话，以及整支智能体队伍的成本和上下文是如何流动的。
[+] 低配置成本的本地与移动端工作空间 —— Shelly 和 Colab CLI 展示了人们对在受限或非常规设备上更快起步的兴趣，而 Google 产品栈的混乱也说明，过多入口仍会拖慢人们上手。这是一个正在浮现的机会，不过当前最强的证据仍主要来自个体构建者，而不是更广泛的人群。
8. 要点总结¶
- AI 编程产品继续从“写代码”向外扩展到浏览器控制、编排和可视化。 Codex 的浏览器使用，以及计算机使用/Chrome 扩展功能的区域铺开，与 Copilot App 中关于
/orchestrate、Mermaid 图表和会话排序的帖子并列出现。(来源) - 社区对“运营很多个智能体”这件事，已经比“提示一个智能体”认真得多。 关于工作树与缓存的详细指导、CTOP 监控，以及共享会话实验，都表明围绕智能体队列的真实操作模型正在成形。(来源)
- 配额清晰度和可靠性仍是最大的信任杀手。 用户抱怨追踪器精度、不可预测的消耗、不稳定的更新，以及一旦智能体转到后台就变得难以理解的定价模型。(来源)
- 构建者正在围绕智能体发布封装层、运行时和领域工作流，而不是等核心工具成熟。 BugHunter、Postrboard、mfertown 和 Shelly 都在扩展智能体的工作场景或它们能够接管的流程。(来源)