Twitter AI 编程 - 2026-08-28¶
1. 人们在讨论什么¶
1.1 AI 编程工具持续从个人助手转向面向特定领域、多智能体的工作台（🡕）¶
样本中最明显的变化，是重心从单智能体编程辅助转向了面向更复杂、更长期或更专业任务的结构化工作台。最清晰的证据来自 Antigravity 对 Teamwork 的推进，以及 OpenAI 面向生命科学推出的新产品 Rosalind Workbench。两者都将编排与共享上下文视为产品核心，而不只是模型能力。
@antigravity 表示（707 个赞、22 条回复、31,564 次浏览、283 个书签）称，Google Research 和 Google DeepMind 团队正在 Antigravity 中使用 Teamwork，开展理论计算机科学、数学研究和系统工程工作。相关 Teamwork 帖子 介绍了一个能够选择专业模式的框架，包括迭代编程、分布式编程、长证明、自我验证和文档审查。该公司称，这套框架已经取得了从解决开放问题到构建可启动操作系统的 RISC-V 模拟器等成果。同样重要的是，这条推文对产品定位保持了克制：它明确称该功能消耗大量 token，对日常任务而言有些“大材小用”。（帖子链接）
@ChrisHayduk 宣布（139 个赞、8 条回复、10,732 次浏览、55 个书签）将 Rosalind Workbench 描述为面向生命科学研究人员的 Codex 式体验。公开的 Rosalind Workbench 博文 补充了几个关键细节：GPT-Rosalind、专业科学查看器、插件/工具编排，以及 ChatGPT 应用研究预览版中对计划、中间结果和支持证据的连贯记录。回复进一步凸显了其领域适配性，提到了协作式插件、科学家与模型之间的共享上下文，以及工作台内置的生物原生文件查看器。（帖子链接）
讨论洞察： 围绕这两款产品的回复，关注点较少是“智能体能不能帮忙”，更多是证据处理：Teamwork 连续运行数天后能否保留推理记录，以及 Rosalind 的插件和查看器能否让科学家与模型始终处于同一上下文中。讨论的核心是共享工作状态，而不是一次性提示。
与前一天对比： 2026-08-27，Teamwork 已经把讨论推向编排方向。到 2026-08-28，这一模式进一步扩展为面向特定领域的研究基础设施，生命科学与软件工程一道，成为智能体工作台的重要目标场景。
1.2 GitHub Copilot 越来越像协作控制平面，而不只是单一界面（🡕）¶
GitHub 释放出的最强信号已不再是孤立功能，而是在描述一个可以定制、在团队聊天中共享，并能提供多种模型选择的平台，同时让工作在不同界面之间持续推进。
@github 总结（142 个赞、11 条回复、41,222 次浏览、35 个书签）介绍了“GitHub Copilot 最近上线的 5 项功能”，而回复则让这一组合显得格外具体：Slack 和 Teams 集成，用于共享智能体会话；新的 Customize 标签页；正式可用的模型，包括 Gemini 3.7 Flash、MAI-Code-1.1-Flash 和 Kimi K3；以及 Copilot CLI 中的 Sessions 侧边栏。其意义在于，这次发布的重点不再是单一提示界面，而是一个不断扩展的控制平面，横跨聊天、可安装扩展、模型供给和多会话管理。（帖子链接）
@github 宣布（11 个赞、2 条回复、2,557 次浏览、1 个书签）介绍了 Copilot 应用中的 Customize 标签页。相关 GitHub 更新日志 和截图准确展示了 GitHub 希望这一控制平面呈现的样子：MCP 服务器、插件、技能和画布被集中到一个安装/发现界面中，并列出了 Figma、Impeccable Design 和 Microsoft Foundry 等推荐条目。其独特之处不只是可扩展性，而是连“发现”本身也正在被产品化。（帖子链接）
@github 展示了（14 个赞、3 条回复、2,675 次浏览、2 个书签）展示了 Copilot 直接在 Slack 和 Microsoft Teams 对话中工作。公开的 Slack 更新日志 和 Teams 更新日志 进一步明确了操作细节：共享云智能体会话、可见的产物和差异、在安全沙箱中异步继续执行，以及对 Copilot 创建的拉取请求启用额外审批。截图提供了最具体的证据：@GitHub 打开了一个代码频道，并将图表返回到对话线程中。（帖子链接）
讨论洞察： GitHub 自己的文档始终把人工审批和预算边界摆在前台。共享会话与云智能体计费、沙箱预算和可选的额外 PR 审批配套出现，说明 GitHub 预计协作与治理会一并交付。
与前一天对比： 本周早些时候，GitHub 的势头主要来自 Azure DevOps、WSL 以及移动端构建/测试。到 2026-08-28，重点已经上移到更高层：多人会话、可安装的定制界面、模型选择和会话管理。
1.3 智能体工作的经济性和隐藏配置，已成为产品体验的一部分（🡕）¶
第三个主题是，人们不再把模型名称当作体验的完整解释。公开讨论转向了工作负载经济性、隐藏路由、上下文窗口差异和备用用量池。
@opencode 宣布（220 个赞、12 条回复、7,719 次浏览、9 个书签）介绍了 OpenCode Go 中的 Qwen3.8-Flash，包括 125B/6B 版本、1M 上下文和多模态支持。与此同时，@thdxr 表示（212 个赞、18 条回复、5,490 次浏览、7 个书签）称，OpenCode Go 正在被打造为“让所有人都能使用智能体的最大尝试”，其经济性已经接近盈亏平衡，以至于该公司正努力避免在这款产品上亏钱。回复明确了其工作负载范围：它针对编程智能体场景进行了优化，而不是通用推理。两条帖子共同表明，工具链经济性和工作负载定位都是产品的核心属性。（Qwen 帖子；economics 帖子）
@TokenGremlin 认为（44 个赞、3 条回复、5,732 次浏览、11 个书签）称，Codex 和 ChatGPT Work 可能正在以模型名称无法体现的方式在底层发生变化。图片序列提供了最有力的证据：Three.js 输出的前后对比；一条问题记录显示，在选择 Sol 的情况下，Luna 产生了 232 轮，而 Sol 只有 124 轮；另一条显示，根据客户端/发起端不同，上下文窗口可能为 272K 或 872K；最后一张卡片指出，OpenAI 公开发布的 8 月 6 日 Sol 更新，并未完全解释 Work/Codex 的行为。作者谨慎地将其称为强烈怀疑，而非确认，但更大的问题已经很明确：即使模型名称不变，产品体验也可能发生变化。（帖子链接）
@alexgetmancom 报道称（27 个赞、7 条回复、1,296 次浏览、1 个书签）称，OpenAI 文档现在提到，部分 Plus 和 Pro 账户在常规 Codex 和 ChatGPT Work 用量耗尽后，可以使用 Luna Reserve。截图让这一限制变得直观：备用用量独立存在，受模型限制，且并非所有人都能使用。这很重要，因为账户权益规则正日益成为人们体验“模型”的一部分。（帖子链接）
讨论洞察： 这一组讨论中的回复都很务实，而非意识形态化。人们询问 1M 上下文推理在较长序列长度下能维持多快、OpenCode Go 是否能用于编程之外的工作负载，以及 Sol 的改进究竟来自模型变化，还是工具链/编排变化。共同关注点是可观测性。
与前一天对比： 上周已经出现了大量围绕价格和路由的讨论。到 2026-08-28，讨论已从“哪个工具更便宜”进一步转向“实际为我提供服务的究竟是什么系统、使用多大的窗口、受什么配额限制，又属于哪个备用用量池”。
1.4 开发者持续将智能体系统拆解为明确的规划器、提取器和评估器（🡕）¶
最有信息量的开发者帖子并不是泛泛而谈的“我做了一个智能体”，而是描述了具体的循环结构、可量化的基准和精确的失败模式。
@undefinedKi 总结（16 个赞、7 条回复、587 次浏览、9 个书签）将 PRAXIST 描述为一个研究系统：在相同的 75 项任务上击败了 Claude Code 加 Opus 4.8 的基线，同时成本约为 3,054 美元，而不是 38,370 美元。配图清晰展示了其架构：并行 peer、任务专属评估器、写入共享内存的发现，以及由领头 peer 选定的下一轮议程。引用的 @Sapient_Int 发布文案还提供了更多跨领域证据，包括 100% 的火箭安全着陆率，以及在合作方环境中降低 SLAM 误差。（帖子链接）
@shivam74689 报道称（12 个赞、7 条回复、318 次浏览、6 个书签）介绍了一个基于浏览器的定价提取工作流，将目标规划、浏览器执行、确定性提取和经过验证的结构化输出分开。配图才是其真正价值所在：一张图展示了 Planner、PlanRunner、BrowserAgent、Playwright 和 PricingExtractor 之间的工作流；另一张展示了一个具体的选择器定位失败案例——概念上正确的 a[href='/copilot/pricing'] 目标，仍然无法匹配实时 DOM。该推文还称，确定性提取层的 11/11 单元测试全部通过，使这篇帖子从“氛围编程”转变为一份可靠性案例研究。（帖子链接）
讨论洞察： 这里获得认可的是明确的结构。回复特别提到了 PRAXIST 的成本数据，以及浏览器智能体帖子中的选择器定位经验。这表明，当评估器、预算和失败模式都清晰可见时，人们更愿意信任智能体系统。
与前一天对比： 本周早些时候的报告已经在跟踪技能、规范和工具链。到 2026-08-28，讨论从“你应该有一个工作流”转向了“这是循环、这是评估器、这是基准，也是失败模式”。
2. 什么让人感到沮丧¶
模型标签和用量条仍无法解释究竟是什么系统在处理任务¶
这属于高严重性问题，因为证据来自试图理解真实编程工作流的人，而不是抽象推测。@TokenGremlin 认为（44 个赞、3 条回复、5,732 次浏览、11 个书签）称，即使 Codex 会话选择了 Sol，仍可能显示大量 Luna 用量，并且上下文窗口会根据客户端发起端而变化。与此同时，@alexgetmancom 报道称（27 个赞、7 条回复、1,296 次浏览）提到，部分账户在正常 Work/Codex 用量耗尽后会获得独立的 Luna Reserve 备用池。@TonyKorologos 表示（2 个赞、2 条回复、246 次浏览）则提出了一个更小但更尖锐的抱怨：两段简短的应用商店描述，就耗尽了五小时配额的最后 7%。用户只能通过逆向分析截图、问题单和仪表盘来应对，因为公开界面仍未清楚说明实际服务、备用用量和计费状态。
浏览器智能体即使概念上正确，也可能在真实页面上失败¶
这同样属于高严重性问题，证据也异常具体。@shivam74689 展示了（12 个赞、7 条回复、318 次浏览、6 个书签）介绍了一个浏览器智能体：它正确推导出了 a[href='/copilot/pricing']，却因为该选择器不存在于渲染后的 DOM 中而超时。同一篇帖子称，确定性提取加验证让 11/11 单元测试全部通过，这反而使剩下的定位失败更具启发性：难点不只是规划，还要证明当前页面状态与计划相符。这个问题值得直接投入解决，因为失败模式明确、反复出现且成本高昂。
访问权限和可负担性仍是现实的产品约束，而不是默认已解决的问题¶
这属于中高严重性问题。@thdxr 表示（212 个赞、18 条回复、5,490 次浏览、7 个书签）称，OpenCode Go 的运营经济性非常紧张，团队甚至在努力避免亏损；@opencode 补充了（220 个赞、12 条回复、7,719 次浏览、9 个书签）则将另一个 1M 上下文模型加入同一工具链。@undefinedKi 推出了 介绍了 PRAXIST 如何部分依靠成本控制取胜，强调其基准表现击败了成本高得多的 Claude 基线。显而易见的应对策略是专门化工作负载：针对编程智能体流量进行优化，限制工具链，并公开预算和评估器，而不是假装访问成本为零。
3. 人们希望拥有的东西¶
透明的模型来源、上下文窗口和配额界面¶
最明确的实际需求，是当编程智能体声称使用某个模型时，用户能够知道背后究竟运行着什么系统。@TokenGremlin 指出 提供了由问题单支持的证据，显示 Sol 与 Luna 之间存在路由差异，且上下文窗口取决于客户端；@alexgetmancom 披露了 则显示，Luna Reserve 是部分账户可用的独立备用池。@TonyKorologos 补充了 展示了同一需求的终端用户版本：在一项简单的写作任务耗尽剩余配额之前，配额行为就应该是可理解的。机会：直接。
面向专业研究领域的共享上下文工作台¶
人们需要的不只是更好的通用模型。他们也在认可将模型与领域原生工具、文件查看器和持久化证据结合起来的工作台。@ChrisHayduk 推出了 介绍了面向生命科学的 Rosalind Workbench；OpenAI 的博客则描述了专业查看器、插件/工具编排，以及对计划和中间结果的连贯记录。@antigravity 实现了 从编程一侧提出了同样的结构性主张，介绍了 Teamwork 面向研究规模任务的专业模式。机会：直接。
始终留在团队实际沟通渠道中的协作式智能体界面¶
GitHub 的线程明确表达了这一需求：用户希望能够从团队已经进行协调的地方，持续引导智能体工作。@github 展示了 介绍了 Slack 和 Teams 协作；公开更新日志则描述了共享云智能体会话、可见产物、可选的额外 PR 审批，以及从聊天继续进入应用、终端或 IDE 的能力。相关的 Customize 选项卡帖子 从另一个角度表达了同一需求：团队希望在一个地方发现集成、插件和画布，而不是在文档和独立安装器之间来回寻找。机会：直接。
具备确定性提取和验证能力的分层浏览器自动化¶
@shivam74689 显示 所介绍的浏览器智能体，将规划器、执行器、提取器和验证器分层，这让未满足的需求变得格外清晰。用户希望智能体能够浏览和执行操作，同时也希望拥有确定性提取、模式验证和有依据的选择器，避免一个看似合理的计划在 DOM 边界处崩溃。这是一个实际需求，而不是愿景，因为开发者已经不得不加入 Pydantic 验证和明确的提取器逻辑，才能让工作流可靠运行。机会：竞争性。
4. 正在使用的工具与方法¶
| 工具 | 类别 | 评价 | 优势 | 局限 |
|---|---|---|---|---|
| Antigravity 中的 Teamwork | 多智能体编排 | (+/-) | 为编程、证明、验证和文档审查提供明确模式；面向长期任务构建 | 消耗大量 token，且公开承认对日常任务来说属于过度配置 |
| Rosalind Workbench | 领域工作台 | (+) | 为生命科学提供共享科学上下文、专业查看器和插件/工具编排 | 目前仍处于研究预览阶段，且领域访问限制了受众 |
| GitHub Copilot 应用 | 智能体工作区 / 控制平面 | (+) | 在一个界面中结合模型选择、定制、会话管理和周边工具 | 价值越来越取决于预算、策略以及启用的集成 |
| Slack/Teams 中的 GitHub Copilot | 协作聊天界面 | (+) | 共享会话、可见产物、异步云执行，以及可选的额外 PR 审批 | 需要云智能体策略、预算控制，以及团队采用相应沟通工具 |
| OpenCode Go | 智能体工具链 / 推理产品 | (+/-) | 试图让智能体广泛可用，并针对编程智能体工作负载进行优化 | 经济性仍然紧张，且并未定位为通用廉价推理服务 |
| Qwen3.8-Flash | 开放模型 | (+) | 1M 上下文、多模态支持，并可直接在编程智能体工具链中使用 | 长上下文速度，以及相较其他模型的性价比仍存在疑问 |
| Work/Codex 中的 GPT-5.6 Sol/Luna | 托管模型界面 | (+/-) | 部分工作流中被认为有明显提升，并提供可见的回退/备用行为 | 仅凭模型标签可能无法说明路由、上下文长度或备用状态行为 |
| PRAXIST | 自主研究系统 | (+) | 并行 peer、由评估器主导的循环、持久化发现，以及非常明确的成本/性能主张 | 需要可量化目标、可运行项目和严格的预算控制 |
| Playwright + 确定性提取器 + Pydantic | 浏览器智能体方法 | (+) | 将浏览器操作与结构化数据提取、验证分开 | 即使计划在概念上正确，实时 DOM 定位仍然脆弱 |
| Appshots | 桌面上下文捕获 | (+) | 以极少的用户操作，将最前端应用窗口和可用文本带入 Work/Codex | 仅支持 macOS 桌面，部分应用只能提供可见截图或有限文本 |
当工具让上下文和编排变得更加明确时，满意度最高。@ChrisHayduk 带来了 将生命科学插件和共享证据引入专用工作台；@github 捆绑了 将协作、定制和模型选择集中到一个 Copilot 线程中；@undefinedKi 展示了 则将 PRAXIST 呈现为由评估器驱动的研究循环，而不是提示词包装器。
当系统状态保持不透明时，满意度就会下降。@TokenGremlin 质疑了 质疑可见的模型标签是否足以完整描述 Work/Codex 的行为；@TonyKorologos 达到 提到在一项简短写作任务中遭遇配额墙；@shivam74689 记录了 则展示了一个概念上合理、却在实际页面上失败的选择器。因此，最主要的应对模式是分层工程：共享上下文、明确的评估器、确定性提取器、可见的审批，以及考虑预算的编排。
5. 人们正在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| Rosalind Workbench | OpenAI / Chris Hayduk | 为生命科学研究人员提供带有专业查看器和插件的共享科学工作台 | 研究数据、工具和实验记录通常分散在彼此割裂的系统中 | GPT-Rosalind、科学插件、分子/序列/切片查看器、ChatGPT 应用 | Beta | 推文, 博客 |
| GitHub Copilot Customize 标签页 | @github | 为 MCP 服务器、插件、技能和画布提供集中式安装/发现界面 | 团队需要在 Copilot 内发现周边工具和工作流，而不是在各处文档中寻找 | GitHub Copilot 应用、MCP、插件、技能、画布 | 已发布 | 推文, 更新日志 |
| Slack 和 Teams 中的 GitHub Copilot | @github | 从团队已经用于协调工作的对话中发起共享云智能体会话 | 将聊天线程转化为可见、可引导的智能体工作流，并支持创建 PR 和审查产物 | Slack、Teams、GitHub Copilot 云智能体、云沙箱 | Beta | 推文, Slack, Teams |
| PRAXIST | Sapient Intelligence | 通过并行 peer、评估器和共享发现，运行自主且可量化的研发循环 | 处理目标可衡量、但最佳路径仍未知的问题 | Praxist runtime、Codex 或 Claude Code 接管技能、评估器驱动的研究工具链 | Beta | 代码仓库, 推文 |
| 基于浏览器的定价提取工作流 | @shivam74689 | 使用分层浏览器智能体规划、浏览、提取定价数据，并验证最终模式 | 仅依赖 LLM 的浏览器自动化过于脆弱，无法可靠提取结构化数据 | Planner、PlanRunner、BrowserAgent、Playwright、确定性提取器、Pydantic | Alpha | 推文 |
| OpenCode Go + 新模型供给 | @opencode | 持续将 Qwen3.8-Flash 等开放模型加入编程智能体产品 | 编程智能体能否广泛普及，取决于可负担的工具链经济性和足够的模型选择 | OpenCode Go、Qwen3.8-Flash、面向编程工作负载的多模态模型路由 | Beta | Qwen 推文, economics 推文 |
构建方式明显呈现出结构化特征。Rosalind Workbench、PRAXIST 和浏览器定价工作流都描述了一串专业组件，而不是一个无所不能的模型。GitHub 已发布的功能则将同一方向带入日常开发工作：插件、聊天界面和模型菜单正被打包成更大操作层的一部分。
PRAXIST 和浏览器定价工作流尤其有价值，因为它们公开了内部循环。PRAXIST 的图片展示了 peer、评估器、发现和对预算敏感的迭代；定价提取图则将规划、浏览、提取和验证分开，并明确暴露了选择器定位失败。这使两者都比泛泛的“我做了一个智能体”演示更能证明开发者真正走向成熟。
6. 新鲜且值得关注的动态¶
Appshots 将桌面应用状态变成 Work/Codex 的一等输入¶
@OpenAIDevs 表示（50 个赞、6,212 次浏览、8 个书签）称，Appshots 能将当前前台应用中的上下文提供给 ChatGPT Work 和 Codex，让它们理解用户正在查看的内容并据此采取行动。公开的 Appshots 文档 让这一功能比单纯的推文描述更加具体：它会同时捕获最前端 macOS 应用窗口的图像和可用文本，将 appshot 作为附件保存在本地；在 Work/Codex 中，还可以配合匹配的插件，获得更深入的应用感知帮助。其值得关注之处在于，它将实时应用上下文变成智能体的常规输入，而不再是特殊演示。
关于 AI 生成代码检测的公开讨论变得具体得多¶
@thisguyknowsai 报道称（20 个赞、5 条回复、1,270 次浏览、6 个书签）介绍了一篇论文。论文声称，利用 41 个行为特征，在涵盖 Codex、Copilot、Devin、Cursor 和 Claude Code 的 33,580 个拉取请求上取得了 97.2% 的 F1 分数。有趣之处不只是准确率主张；回复很快提出质疑：该分类器究竟证明了代码作者身份，还是主要识别提交信息和 PR 结构习惯。这让这篇帖子比典型的基准截图更有价值，因为它同时暴露了合规和解读问题。
Luna Reserve 让回退容量成为可见的产品层¶
@alexgetmancom 展示了（27 个赞、7 条回复、1,296 次浏览）称，OpenAI 现在为部分账户在常规用量耗尽后，于 Codex 和 ChatGPT Work 中提供 Luna Reserve。截图之所以重要，是因为它让备用用量池变得可见且独立，而不再只是内部权益规则。值得关注的是，配额、回退模型和备用用量池正日益成为开发者体验本身的一部分。
7. 机会在哪里¶
**+++］ 透明的编排与使用情况可观测性** — TokenGremlin 基于 issue 的 Sol/Luna 截图、Luna Reserve，以及关于配额的投诉，都指向同一个缺口：用户需要知道，究竟是哪条模型路径、上下文窗口和使用池在实际支撑这些工作。这是一个很强的机会点，因为这种混乱已经开始影响信任。(［来源, 1, 2)
**+++］ 面向特定领域的多代理工作台** — Antigravity Teamwork 和 Rosalind Workbench 都展现出同一种模式：将模型与专用工具、共享证据以及针对更窄问题空间的显式编排结合起来。这个信号很强，因为两家不同厂商在同一天推出了相同的结构。(［来源, 1)
**++］ 跨聊天、应用与 CLI 的协作控制平面** — GitHub 的已发布功能串、Customize 选项卡以及 Slack/Teams 工作流表明，这类工具存在持久机会：既能让共享工作保持可见，又能保留策略、预算和审批边界。(［来源, 1, 2)
**++］ 稳健的浏览器落地提取层** — 价格提取工作流表明，当规划、浏览、提取和验证被拆分开来时，代理的可靠性会提升。这个机会中等偏强，因为构建者已经在摸索解决方案的形态，但失败模式仍然存在。(［来源)
8. 要点¶
- AI 编程技术栈持续扩展为结构化工作台，而不只是更聪明的聊天。 Teamwork 和 Rosalind Workbench 都将编排、工具和共享证据视为真正的产品界面。（来源）
- GitHub Copilot 越来越像围绕智能体工作的协作与定制层。 已发布功能线程、Customize 标签页以及 Slack/Teams 流程，都指向一个横跨聊天、应用和 CLI 界面的控制平面。（来源）
- 模型标签已无法完整描述开发者体验。 Sol 与 Luna 的路由疑问、取决于客户端的上下文窗口，以及 Luna Reserve 都表明，服务配置和配额状态已经成为工作流中可见的一部分。（来源）
- 可靠的智能体系统正被构建为带有明确评估器和验证器的分层流水线。 PRAXIST 和浏览器定价工作流都通过公开循环、指标和失败模式建立了可信度，而不是将一切隐藏在结果演示之后。（来源）
- 跨应用上下文捕获正成为常规基础设施。 Appshots 的意义在于，Work/Codex 可以从最前端应用窗口及其可用文本开始工作，而不必要求用户手动重写描述。（来源）