Twitter AI 编程 - 2026-09-23¶
1. 大家在讨论什么¶
1.1 本地与混合式智能体运行时成为当天最明确的产品转向 (🡕)¶
当天最大的变化，是讨论重点从单纯的发布声量转向了更具体的本地执行。至少有五条内容支撑了这一主题：Google 推出用于离线运行 Gemma 4 的 Antigravity SDK，Gemma 自身列出后端支持列表，Taylor Mullen 随后补充了 SDK 示例，Potluck CLI 对本地运行时进行封装，此外还有一些相关的沙箱帖子也开始把本地控制视为产品能力本身，而不只是附带收益。
@antigravity 宣布（2,134 次点赞、79 条回复、110,326 次浏览、1,017 次收藏）表示，Gemma 4 现在可以在 Antigravity SDK 中完全离线运行。其链接的 Google 博文 称，LiteRT 路径已针对 Gemma 4 26B A4B 做过调优，建议配备超过 24GB 的 VRAM 或统一内存，并展示了一次混合式审计运行：Gemini 3.8 Flash 根据文件名进行规划，而 97.2% 的 token 在本地运行。回复区很快就超出了发布文案本身：有人问工具调用循环是否仍然能保持本地，有人追问演示到底是完全离线还是混合模式，也有人关心这套流程实际需要多少硬件。
@googlegemma 新增（212 次点赞、11 条回复、9,097 次浏览、128 次收藏）表示，同样的本地流程也适用于兼容 OpenAI 的端点，比如 Ollama、llama.cpp 和 vLLM。这一点之所以重要，是因为它把“本地智能体”界定为一个可以叠加在多种服务栈之上的编排层，而不只是一次性的 Gemma 演示。
@strakedev 已发布（7 次点赞、2 条回复、51 次浏览）提到 Potluck CLI，这也从另一个侧面证明，本地运行时管理正在成为独立的产品层。公开的 README 称，它可以搭建本地运行时、将模型权重固定在 potluck.lock 中、启用本地网关，并在项目内保存或恢复智能体会话。
讨论洞察： 回复内容关注的是实际操作，而不是愿景。大家关心的是 VRAM 下限、函数调用循环在离线状态下是否仍可运行，以及在不放弃更强云端模型的前提下，有多少任务能够留在设备端完成。
与前一天对比： 9 月 22 日最受关注的帖子主要围绕定价、重置和发布触点；到了 9 月 23 日，更强的信号则是本地与混合式运行时已经真正开始上线。
1.2 智能体控制平面继续向代码生成之外扩展 (🡕)¶
第二个强烈主题是，团队持续围绕智能体构建能力，而不只是在智能体内部做文章。至少有六条内容支撑了这一主题：GitHub 发布本地沙箱能力、深入讲解其超大 PR 渲染方案、OpenChamber 发布无需重启的新版本、OpenCode 为其协议辩护、CoCo 的编排层，以及带有 Jev 风格的决策路由。
@pierceboggan 宣布（42 次点赞、2 条回复、2,167 次浏览、13 次收藏）提到 GitHub Copilot 应用中的本地沙箱能力。其链接的 更新日志 称，该沙箱可按项目限制文件系统访问、外发网络使用，以及 Git 或 GitHub 凭证；如果操作系统无法执行所请求的策略，shell 会直接失败，而不是在未启用沙箱的情况下继续运行。
@gimenete 撰文（16 次点赞、6 条回复、1,050 次浏览、8 次收藏）称，GitHub 重建了 Copilot 应用的 pull request 视图，使其能够处理 2,200 个文件、超过 100 万行变更，以及 400 多条行内评论。公开的 工程博客文章 表示，关键在于把确定性的代码几何布局与动态的评论几何布局拆分开来，这样评论测量就不会再拖垮滚动性能；这是一项评审界面创新，而不是又一个生成基准。
@openchamber_dev 已发布（57 次点赞、4 条回复、8,956 次浏览、22 次收藏）提到 OpenChamber 2.0，使技能、智能体、MCP 服务器和插件都能在保存后立即生效、无需重启；配套的 博文 还表示，Code Mode 可以把许多工具调用压缩成一段简短脚本。@thdxr 认为（121 次点赞、11 条回复、6,791 次浏览、20 次收藏）则表示，正是 OpenCode 的服务器协议，才让 OpenChamber 这类更丰富的前端成为可能；不过回复中也暴露出新的摩擦点，包括 MCP 认证问题和端点变更带来的破坏性兼容变更。
一些规模较小的开发者帖子，也把同样的控制平面逻辑继续向外延展。@DanKornas 分享（5 次点赞、6 条回复、585 次浏览）认为，CoCo 是一个安装在 Claude Code、Cursor 或 Codex 之上的编排层，而不是用来取代它们；与此同时，@PrajwalTomar_ 声称（3 次点赞、1 条回复、379 次浏览、3 个书签）认为，Jev 最适合作为 Claude Code 前的一层快速“是/否”决策层，用于高破坏性命令、分诊和路由。
讨论洞察： 值得关注的问题集中在策略作用面和状态转换上：哪些凭证会保留下来、评论如何在不引发滚动跳动的情况下计量、前端能否实时重载，以及究竟允许哪一层作出决定。
与前一天的对比： 9 月 22 日，“控制”这一主题主要围绕测试回执和对破坏性命令的拦截展开。到 9 月 23 日，同样的倾向进一步深入到第一方沙箱、审查界面架构，以及把 harness 本身视为基础设施的编排层。
1.3 工作流状态带来的摩擦，仍在决定哪些 harness 让人觉得好用（🡒）¶
第三个主题是，那些不可见的状态仍在决定人们是否信任一个工具。至少有七条内容支撑了这一点：反复要求 Antigravity 接入更新的 Anthropic 模型、直接提出多账号支持的需求、OpenChamber 主打“无需重启”、Claude Code 关于 AGENTS.md 的注意事项，以及一些实操案例——代理之所以成功或失败，正是因为表单或配置里存在隐藏状态。
@HarshithLucky3 询问（553 次点赞、27 条回复、78,286 次浏览、20 个书签）要求在 Antigravity 中提供 Opus 5.5；@Soso_fun_yt 表示（328 次点赞、19 条回复、18,874 次浏览、21 个书签）表示，Opus 4.6 对复杂编程任务来说还不够好用；以及 @ash_twtz 展示（213 次点赞、63 条回复、9,945 次浏览、6 个书签）展示了一个仍在列出 Claude Opus 4.6 的模型选择器。这张截图之所以重要，是因为它把一种泛泛的抱怨变成了一个可见的产品状态问题，而不只是凭感觉争论基准表现。
@HarshithLucky3 另行询问（23 次点赞、786 次浏览）呼吁 Antigravity、Claude desktop 和 ChatGPT desktop 支持多账号，这个需求很窄，但非常具体。与此同时，@steipete 指出（24 次点赞、4 条回复、4,007 次浏览、10 个书签）指出，当遥测或非必要流量被禁用时，Claude Code 对 AGENTS.md 的支持可能会悄然消失；他链接的 文章 则表示，变通办法是一行 CLAUDE.md import。
@thdxr 展示（104 次点赞、16 条回复、7,469 次浏览、5 个书签）展示了 OpenCode 在一个出故障的航班值机表单中发现了一个隐藏的必填字段，然后在提交前先询问缺失的值。这张图片之所以重要，是因为它展示了代理识别出的那种精确而不可见的 UI 状态；而回复中有人表示，在经历过类似的静默失败后，一些团队现在会在真实提交前先检查隐藏字段。
讨论洞察： 今天最具体的赞赏或挫败感，很少直接指向模型的原始智能，而更多在于模型菜单是否是最新的、指令文件是否真的加载了、账户能否保持分离，以及工具能否看见损坏表象背后的隐藏状态。
与前一天相比： 9 月 22 日已经显示，能保留既有工作流的插件更受青睐。到 9 月 23 日，这种较宽泛的偏好进一步收敛为更明确的诉求：模型是否足够新、能否切换账户、指令是否加载成功，以及能否调试隐藏表单问题。
2. 什么让人感到挫败¶
模型更新和账户状态仍然跟不上模型发布节奏¶
最强烈的挫败感并不是人们讨厌现有工具，而是这些承载层的状态落后于模型市场。@HarshithLucky3 询问（553 次点赞，27 条回复，78,286 次浏览，20 次收藏）要求在 Antigravity 中提供 Opus 5.5，@Soso_fun_yt 表示（328 次点赞，19 条回复，18,874 次浏览，21 次收藏）认为 Opus 4.6 还不足以胜任复杂编码任务，而 @ash_twtz 展示（213 次点赞，63 条回复，9,945 次浏览，6 次收藏）指出选择器仍然停留在 Opus 4.6，回复中也有人抱怨缺少 Gemini 3.1 Pro High。@HarshithLucky3 另行询问（23 次点赞，786 次浏览）则呼吁 Antigravity、Claude desktop 和 ChatGPT desktop 支持多账户。
用户的应对方式很务实，而非出于意识形态：哪个界面先更新就用哪个；如果偏好的模型缺席，就先用更便宜的内置模型；或者为像 OpenChamber 这样的工具叫好，因为它发布时传递的核心信息不过是“无需重启”。这些抱怨都集中在选择器过时、账户缺失，以及需要用户花太多精力盯着会话状态。严重程度：高。值得构建：高。
安全执行仍然依赖额外的策略层¶
第二类挫败感在于，安全执行依然像是后加上去的。@pierceboggan 宣布（42 次点赞，2 条回复，2,167 次浏览，13 次收藏）提到 GitHub Copilot app sandboxing，具备按项目划分的文件系统、网络和凭证控制；但同一批数据里也有 @tweetpraveen 列表（2 次点赞，15 条回复，297 次浏览）提出另外七项生产级要求，例如使用 gVisor 或 microVM、将密钥放在盒子外、阻止 MCP 出站，以及外部审计日志。@KitPloit 重点提到（271 次浏览，1 次收藏）提到 cplt 作为内核级沙箱，并带有 git 和 gh 防护；而 @beyourloverboy 发现（1 次点赞，2 条回复，74 次浏览）提到 MAW，其 仓库 说明支付请求仍然要经过策略、审批和签名收据，而不是直接由代理执行。
这里的共性是，团队并不希望模型掌握最终决定权。他们希望密钥、允许列表、审批、预算和日志都外置，由聊天界面之外的系统掌控。严重程度：高。值得构建：高。
不可见的产品状态仍会绊倒原本能力很强的代理¶
第三类挫败感是，那些本来能力很强的代理，仍会被用户看不见的状态绊住。@thdxr 展示（104 次点赞，16 条回复，7,469 次浏览，5 次收藏）提到 OpenCode 在调试一个损坏的航班值机页面时，发现了 UI 根本没有渲染出来的隐藏必填字段；一条回复还说，另一支团队现在会在真实提交前先检查隐藏字段，因为他们一周内已经无声无息地丢掉了四次提交。@steipete 指出（24 个赞，4 条回复，4,007 次浏览，10 次收藏）指出，当禁用遥测或非必要流量时，Claude Code 可能会静默跳过 AGENTS.md。对 @thdxr 和 @openchamber_dev 的回复又补充了一个较小但很说明问题的痛点：MCP 认证和协议变更依然很容易出问题。
人们的应对方式包括加垫片和检查：保留一个备用的 CLAUDE.md，要求智能体在提交前先暴露隐藏的表单状态，或者改用那些能够原地重载而不是重启的前端。这些办法确实有效，但仍然需要操作人员额外投入。严重性：中高。值得构建程度：高。
3. 人们希望出现什么¶
受控的本地智能体：把成本和代码都留在设备端¶
最明确、最现实的需求，是在不牺牲智能体工作流质量的前提下实现本地执行。@antigravity 宣布（2,134 个赞，79 条回复，110,326 次浏览，1,017 次收藏）提到 Antigravity SDK 对离线 Gemma 4 的支持，@googlegemma 新增（212 个赞，11 条回复，9,097 次浏览，128 次收藏）指出，Ollama、llama.cpp 和 vLLM 等本地 OpenAI 兼容端点也适配这一流程，而 @strakedev 已发布（7 个赞，2 条回复，51 次浏览）则展示了带有本地运行时设置、模型锁定和会话恢复功能的 Potluck CLI。其紧迫性非常现实：隐私受限代码、token 成本控制，以及可预期的可用性，都在相关帖子和回复中反复出现。
当下的替代方案仍然较为割裂。Antigravity 的官方方案最完整，Potluck 将本地运行时管理单独打包，而 cplt 则是在现有智能体外围增加沙箱能力，并没有真正解决运行时编排本身的问题。这个需求显然真实存在，但目前仍需由多个层次拼装而成。机会：直接。
智能体控制平面：不是只记录不可逆操作，而是先审批再执行¶
人们并不是在抽象层面要求更大的自主性。他们要的是权限边界。@pierceboggan 推出（42 个赞，2 条回复，2,167 次浏览，13 次收藏）提到 GitHub Copilot 应用中的项目级沙箱，@tweetpraveen 列出（2 个赞，15 条回复，297 次浏览）提到应当置于智能体之外的七项生产控制，@PrajwalTomar_ 描述（3 个赞，1 条回复，379 次浏览，3 次收藏）提到作为 Claude Code 前置“是/否”决策层的 Jev，而由 @beyourloverboy 引出的 MAW 仓库，则为智能体驱动的支付增加了策略、审批和签名回执。
其中一些能力今天已经可以实现，但用户仍然需要自己在沙箱、封装层、钱包和策略引擎之间手动拼接。这使得这一需求显得现实且紧迫，而不是停留在愿景层面。机会：直接。
经得起重启、账号切换和设备变更的 Harness 体验¶
第三个需求，是工具的状态要有持久感，而不是脆弱易失。@HarshithLucky3 询问（23 个赞，786 次浏览）提到多账号支持，@openchamber_dev 发布（57 个赞，4 条回复，8,956 次浏览，22 次收藏）则是一项围绕“当 skills、agents、MCP servers 或 plugins 发生变化时无需重启”而构建的发布，以及 @emanueledpt 推广（16 个赞、4 条回复、436 次浏览、1 次收藏）：一次 Remodex 更新，让 OpenCode 会话能持续在你自己的机器上运行，同时你还可以在手机上继续操作。@steipete 展示（24 个赞、4 条回复、4,007 次浏览、10 次收藏）则展示了相反的情况：某个功能看似存在，却被一项遥测设置悄悄禁用。
这是一种竞争性需求，而不是填补空白式的需求。已经有多款产品在尝试解决它，但当天的证据表明，状态可靠性和会话连续性，仍决定了哪个界面更值得信任。机会：竞争型。
4. 正在使用的工具与方法¶
| 工具 | 类别 | 情绪 | 优势 | 局限 |
|---|---|---|---|---|
| Antigravity SDK | Agent 框架 / 运行时 | (+) | 支持离线 Gemma 4、混合路由、多个本地后端 | 旗舰级本地方案需要超过 24GB VRAM；Antigravity 相邻产品界面仍不断收到关于模型新鲜度的抱怨 |
| Gemma 4 26B + LiteRT | 本地模型 / 运行时 | (+) | 零 token 成本、隐私性强、本地 GPU 上离线运行可靠 | 硬件要求高，而且本地工具循环延迟仍令人存疑 |
| Potluck CLI | 本地运行时管理器 | (+) | 运行时安装、模型锁定、本地网关、会话保存与恢复 | 仍属非常早期版本，平台覆盖有限，今天能看到的采用证据也不多 |
| GitHub Copilot app | Agent IDE / 审查应用 | (+/-) | 官方已推出 Opus 5.5、本地沙箱，以及面向大型 PR 审查的工程能力 | 回复中仍提到速率限制、刷新 bug，以及模型自动选择带来的困惑 |
| Claude Opus 5.5 | 前沿编程模型 | (+) | Copilot 报告称，相比 Opus 5，它能以更少步骤和 token 达到相近的解决效果；在其他 harness 中也被大量点名希望接入 | 在不同客户端和选择器中的可用性仍不均衡 |
| OpenCode | 开放式 agent harness | (+/-) | 服务器协议丰富、前端可定制、具备调试损坏表单的真实场景经验 | MCP 认证和协议变更仍在带来可用性摩擦 |
| OpenChamber 2.0 | Agent 前端 / 工作区 | (+) | 可实时重载 skills、agents、MCP servers 和 plugins；Code Mode 支持批量工具调用 | 依赖 OpenCode 的行为，并继承了其不断变化的接口 |
| cplt | 沙箱 | (+) | 内核级策略、git 和 gh 防护、出站过滤、按仓库配置 | 额外的策略调优和平台注意事项增加了配置开销 |
| CoCo Super Intelligence | 编排层 | (+/-) | 持久状态、顾问委员会式工作流、可跨现有 harness 使用的大型 skills 与 commands 库 | 覆盖面很大，再加上 open-core 拆分，可能增加复杂度 |
| Jev | 决策 / 路由层 | (+) | 快速的是/否路由、命令门控、低成本分类工作流 | 今天的证据主要来自构建者和运营者的发帖，而不是广泛的社区基准测试 |
| GPT-Live-1 + GPT-5.6 Luna | 语音 / 委派研究分工 | (+) | 在研究和渲染异步进行时，仍能保持对话持续进行 | 目前只在一个展示型构建中观察到，而且需要管理更多架构 |
| MAW | 支付 / 策略控制平面 | (+/-) | 基于策略的支出、审批、签名回执、可供 Copilot 使用的 actions | 社交媒体层面的证据仍很早期，实际部署规模也不清楚 |
总体满意度最高的情况，是工具在不要求操作者改投某个新模型阵营的前提下减轻了负担：让工作留在本地、修改后无需重启即可重载，或为执行划出清晰的安全边界。评价转为复杂，往往是因为某个界面隐藏了状态，或跟不上最快的模型发布节奏。这也解释了为什么 Antigravity 一方面激起了最强烈的本地运行时热情，另一方面也招致了最响亮的模型菜单抱怨。
常见的变通办法是显式拆分与包裹：在 Antigravity 中用云端规划器搭配本地构建器，让 GPT-Live-1 负责对话、Luna 负责研究，让 Jev 决策、Claude 执笔，以及用 OpenChamber、CoCo、cplt 或 Potluck 去包裹现有 harness，而不是直接替换它。竞争态势的核心，不再是谁独占某一个模型，而是谁能把连续性、安全性和审查体验打包得最好。
5. 人们正在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| Antigravity SDK 中的本地 AI 支持 | Google Antigravity via @antigravity | 增加离线以及本地/云混合的 agent 工作流 | 让团队在将源代码保留在本地的同时，仍能使用 agent 工作流 | Python, Gemma 4 26B A4B, LiteRT, Gemini 3.8 Flash, local OpenAI-compatible backends | 已发布 | 博客, 仓库, 推文 |
| 语音控制的 LED 墙助手 | Sid Rampally via @OpenAIDevs | 将 Raspberry Pi 和 LED 墙变成一个语音助手，可显示天气、列车信息和场景 | 展示 Codex 如何把硬件、研究和渲染串联成一个可用的副项目 | Raspberry Pi, GPT-Live-1, GPT-5.6 Luna, Responses API, WLED-MM, HUB75 panel | Alpha | 博客, 推文 |
| OpenChamber 2.0 | @openchamber_dev | 通过实时重载 skills、agents、MCP、plugins 和 Code Mode 来运行并审查 agent 工作 | 消除多工具 agent 工作流中频繁重启带来的摩擦 | OpenCode v2, TypeScript, plugins, MCP, web search | 已发布 | 博客, 仓库, 推文 |
| Potluck CLI 0.1.1 | @strakedev via newtorob | 安装本地运行时、管理模型，并运行或恢复终端编码会话 | 将本地推理和会话持久化打包进一个 CLI | Node.js, bundled Python runtime, local gateway, model locks | Beta | 仓库, 推文 |
| cplt | navikt via @KitPloit | 在具备仓库策略以及 git 或 gh 防护的内核级沙箱中运行编码 agents | 缩小提示词注入、错误命令和密钥访问的影响范围 | Rust, Seatbelt or Landlock, repo policy, command guards | 已发布 | 仓库, 推文 |
| MAW | rupeshexe via @beyourloverboy | 为代理触发的交易加入可编程支付策略、审批、收据和审计日志 | 防止 AI 代理直接掌握原始支出权限 | TypeScript、Next.js 14、PostgreSQL 16、Azure Bicep、Entra ID、稳定币适配器 | Alpha | 仓库, 推文 |
| Remodex OpenCode mobile control | @emanueledpt | 让 OpenCode 或 Codex 会话持续在你自己的机器上运行，同时你可以通过 iPhone 继续操作 | 将长时间运行的本地代理会话扩展到第二个控制界面 | iOS 应用、OpenCode 提供方、Codex 配对 | Beta | 推文 |
Antigravity 和 OpenAI 的例子，正好代表了当天构建者光谱的两端。Antigravity 把本地、私有执行变成了一条可复用的 SDK 路径；而那篇 LED 墙帖子展示的则是一个一次性的、但描述完整的副项目：只靠 GPT-Live-1、GPT-5.6 Luna、Raspberry Pi 和一个渲染器，就足以做出一个挂在墙上、而不是待在浏览器里的东西。
不过，反复出现的构建模式是“包裹 harness”，而不是“替换 harness”。OpenChamber、Potluck、cplt、CoCo 和 Remodex 都默认代理已经存在，重点放在重载、运行时打包、隔离、编排或第二控制界面上。@0xMorlex 绘制了（7 次点赞、2 条回复、55 次浏览、6 次收藏）则把这种模式做成了组织架构图版本：规划→编码→审查→测试→修复→合并的循环；他说这套流程上个月处理了 2,500 个 PR。与此同时，@PrajwalTomar_ 制作了（3 次点赞、1 条回复、379 次浏览、3 次收藏）提出了 Jev 的互补观点：让 Claude 负责读写，但把路由和不可逆决策交给一个便宜得多、只做“是或否”判断的层。
MAW 把这种控制平面逻辑推进得最远。仓库 表示，每个支付意图都会先通过 Entra ID 完成认证，再根据可编程支出策略接受检查，必要时进入人工审批，最后以签名收据完成结算。这一点之所以值得注意，是因为它把金融视为另一种需要治理的代理副作用，而不是必须完全放在整个技术栈之外处理的事情。
这组数据里，几乎每个真正有意义的构建，都是由明确的运营缺口触发的：让代码留在本地、跨重启存活、隔离危险操作、协调多个代理步骤，或把会话延伸到手机或墙面上。多个构建者都在独立地把这些缺口打包成现有工具外围的一层，而不是试图发明一个全新的单体式一体化代理 shell。
6. 新近且值得关注的内容¶
Home MCP 把代理式控制推进到了真实的家用设备¶
@heyorvian 发布了（5 次点赞、3 条回复、400 次浏览、2 次收藏）表示，Google 的早期访问版 Home MCP server 可以让兼容 MCP 的代理读取 Google Home 设备状态、查看事件历史，并控制受支持的设备。截图展示了 Google Developer Center 中 OAuth client 的设置；这条推文之所以重要，还在于它同时保留了相关警告：解锁门锁等敏感操作仍被屏蔽，而且仍可能出现意外行为。
Claude Code 对 AGENTS.md 的支持仍埋着一个带有遥测隐患的坑¶
@steipete 标记（24 次点赞、4 条回复、4,007 次浏览、10 次收藏）表示，Claude Code 新增的 AGENTS.md 支持里有个问题。链接中的 分析 表示，内置加载器依赖远程功能开关；一旦禁用遥测或非必要流量，它就可能在没有提示的情况下停止读取 AGENTS.md，而当前的变通方案是加入一行 CLAUDE.md import。对试图在不同 agent 之间统一共享指令的团队来说，这比发布说明里常见的 bug 更值得重视。
7. 机会在哪里¶
[+++] 受治理的本地 agent 运行时栈 —— 这一判断同时来自多个部分的证据：Antigravity 的离线 Gemma 4 路径、Potluck 的模型锁定和会话恢复、cplt 的内核沙箱、GitHub Copilot app 的沙箱化，以及 MAW 通过策略控制副作用。之所以机会很大，是因为第一方团队和独立开发者都在向同一组需求收敛：本地执行、可预测的成本、凭证隔离，以及显式审批。
[++] 跨界面的有状态 harness 体验 —— 对 Antigravity 中 Opus 5.5 的呼声、多账号支持、OpenChamber 的免重启发布、Remodex 的手机控制，以及 AGENTS.md 的遥测注意事项，都指向同一个缺口：会话状态仍然显得很脆弱。这是一个中等强度的机会，因为痛点明显、也便于着手解决，但来自第一方客户端的竞争会非常激烈。
[++] 围绕 agent 工作的审查与编排基础设施 —— GitHub 针对超大 PR 的渲染工作、OpenChamber 的 Code Mode、CoCo 的编排层、Jev 的决策路由，以及 0xMorlex 的 planner→review→test 循环，都表明开发者正把审查与协调本身当作独立产品来打造。这个信号已足够强，值得重视，但最终胜出的方案可能更像无形基础设施，而不是炫目的终端应用。
[+] 面向支付和物理设备的 agent 权限扩展 —— MAW 和 Home MCP 都在把 agent 推向后果更重的环境，同时用审批、策略或拦截操作来加以约束。这个信号仍在形成中，因为社会层面的证据比编码 harness 工具要薄弱一些，但相关要求已经非常明确，而且异常具体。
8. 要点¶
- 本地化和私有化执行，已取代单纯的价格讨论，成为最清晰的新动向。 Antigravity 和 Gemma 不只是承诺让 agent 工作更便宜；它们还交付了离线 Gemma 4 路径，以及规划器与构建器混合分工的方案，而 Potluck 则单独封装了本地运行时管理。 (来源)
- harness 正越来越成为产品本身。 GitHub 的沙箱化和超大 PR 渲染工作，再加上 OpenChamber 的免重启发布，说明竞争正转向审查界面、策略和会话体验，而不再只是比拼基础模型质量。 (来源)
- 不可见的状态，仍是最容易破坏信任的因素之一。 对 Antigravity 中 Opus 5.5 的抱怨、多账号需求、AGENTS.md 的遥测注意事项，以及隐藏表单字段的调试示例，都源于用户难以直接看见的状态。 (来源)
- 大多数开发者是在包裹现有 agent，而不是替代它们。 Potluck、cplt、CoCo、OpenChamber 和 Remodex 都构建在现有 harness 外围，而 0xMorlex 和 PrajwalTomar 则把规划、审查或决策一侧的层级视为真正的杠杆点。 (来源) 5.后果更严重的智能体操作正随着政策闸门一同到来。 MAW 的审批驱动支付，以及 Home MCP 对敏感设备操作的拦截，都表明下一个前沿不只是更强的自主性，而是治理更完善的自主性。（来源）