Twitter AI 编程动态 - 2026-07-15¶
1. 人们在讨论什么¶
1.1 Google 的编程叙事正从单个泄露模型扩展成整个平台版图（🡕）¶
互动量最高的内容都与 Google 相关，但证据层次不一，既有传闻，也有生态营销，甚至还有明显的产品混淆。两篇高互动泄露帖都把 Gemini 3.5 Pro 描绘成即将发布；与此同时，一些互动量较低但更具体的帖子则试图把 Gemini CLI、Antigravity、Jules、ADK 和 A2A 组织成一套彼此关联的开发栈。
@LuminaXspace 发帖称（321 个赞、24 条回复、25,732 次浏览、45 次收藏）列出了一份未经证实的 Gemini 3.5 Pro 传闻清单：7 月 17 日为目标日期、新一轮预训练、200 万 token 上下文窗口，以及更强的编程和推理能力。今天真正有价值的信号，不是其中任何一条已经被证实，而是：在没有官方基准测试或产品页面的情况下，一则编程模型发布传闻主导了关注度。
@ottleyai 认为（21 个赞、14 条回复、1,290 次浏览、11 次收藏）认为，Google 正在构建的是一个全栈 AI 生态，而不是只追求某一个模型的胜利。帖中附带的那张图，是整个讨论里最清晰的实物证据：它把 Gemini、Gemma、Stitch、Whisk、NotebookLM、Veo、Flow、Google Vids、Antigravity、Gemini CLI、Jules、ADK、A2A 和 FileSearch API 归入同一个开发版图。
@ishivgaur 分享了（8 个赞、4 条回复、175 次浏览）发出了一张 Linus Torvalds 的 AudioNoise 仓库截图，截图里的提交信息写道：在将内置矩形选择器替换为自定义版本后，Google Antigravity 帮助修复了一个可视化工具。这张图之所以重要，在于它是具体的使用证据，而不是又一条生态口号。
@pigeon__s 引用并回应（43 个赞、1,982 次浏览）在一则 Jules V2 预告下追问：Jules 到底是否还作为独立于 Antigravity 的产品存在。这是当天最尖锐的反向信号：即便是高度关注此类话题的用户，也已经很难判断 Google 现在哪些编程产品入口才是当前主线。
讨论洞察： Gemini 泄露帖下的回复，大多是在要证据，或者表示希望再出现一个真正有分量的前沿竞争者。更强烈的矛盾信号来自 Jules 讨论串：问题不是性能怀疑，而是产品版图本身让人摸不清。
与前一天的比较： 2026-07-14，围绕 Google 的讨论还主要聚焦于 Antigravity 这一智能体入口。到了 2026-07-15，话题扩展成更广义的 Google 技术栈叙事，但随之而来的也是命名和产品边界上的混乱。
1.2 智能体状态正在逃离编辑器，进入 Jira、手机和硬件（🡕）¶
第二个主题，是如何控制那些已经在运行中的工作。最有力的产品证据来自 GitHub 的 Jira 集成和 Visual Studio 的使用量功能；与此同时，开发者和配件厂商也在探索手机与硬件这类界面，用于监控和引导智能体。
@github 宣布（80 个赞、9 条回复、22,787 次浏览、28 次收藏）称 GitHub Copilot for Jira 已正式可用。GitHub 的 GA 更新日志 表示，这次发布新增了：在 Jira issue 中流式显示智能体进度、在同一草稿 pull request 上通过 Jira 聊天面板进行会话后的后续引导，以及更简化的上手流程；帖文还提到此前预览版加入的模型选择、通过 MCP 获取 Confluence 上下文、自定义智能体和自定义字段。值得注意的是，回复明显没有公告本身那样乐观，很多人警告 AI 生成工单泛滥以及嘈杂的自动评论。
@GHchangelog 发布了（19 个赞、1 条回复、2,046 次浏览、4 次收藏）介绍了一项 Visual Studio 更新，其中的 官方更新日志 加入了实时 Copilot 使用量跟踪与提醒、MCP 服务器指纹的信任校验、将 pull request 上下文导入聊天，以及 C++ 现代化功能正式可用。这意味着关注点正从“IDE 里有智能体”转向“IDE 里能看到智能体的成本和工具信任边界”。
@ridark_eth 推广了（23 个赞、12 条回复、347 次浏览、13 次收藏）介绍了 Orca，把它作为一种并行运行 Claude Code、Codex、Copilot 及其他 CLI 智能体的方式。Orca 仓库 及其 移动端文档 支撑了核心说法：隔离的 git worktree、手机通知与回复，以及账号级的使用状态跟踪。
@testingcatalog 重点介绍了（20 个赞、2 条回复、2,089 次浏览）介绍了 Work Louder 的 Codex Micro。产品页面 表示，它的 RGB 按键会反映智能体状态，而命令键、摇杆和旋钮则让用户能够触发工作流并调节推理深度。虽然该帖互动量不高，但它是一个值得注意的信号：智能体监督正在演变成一个硬件品类。
讨论洞察： Jira 讨论串清楚地发出了一个警告：“工作流中的 AI”很容易变成“AI 生成的工作流噪声”。Orca 和 Codex Micro 讨论串则指向相反方向：当智能体需要关注时，人们想要更明确的状态、更快的干预，以及更少的上下文切换。
与前一天的比较： 昨天最典型的监督形态还是 GitHub Mobile 展示一个需要用户输入的远程会话。今天，同样的监督逻辑已经出现在 Jira、Visual Studio 的使用量窗口、移动伴侣应用，甚至专用硬件中。
1.3 团队开始把智能体闭环流程制度化，而不只是把提示词写得更狠（🡕）¶
第三个主题，是流程硬化。与其庆祝纯粹的生成速度，今天更有价值的帖子都在试图：在执行前消除歧义、明确暴露工具、减少 token 浪费，或者限制被委派智能体的能力范围。
@RituWithAI 认为（11 个赞、4 条回复、164 次浏览、6 次收藏）称 GitHub 的 Spec Kit 存在的意义，就是防止智能体高效地把错误的东西写出来。Spec Kit 仓库 和 GitHub 的 关于规范驱动开发的帖子 支撑了这一核心流程：constitution、specify、plan、tasks，然后 implement，并把 spec 视为持续更新的事实来源。
@TheCodeMan__ 分享了（10 个赞、3 条回复、296 次浏览、3 次收藏）给出了一个具体的 .NET MCP server 示例。他的 starter-kit 页面 和 深度解析 描述了一个性能实验室：Copilot agent mode 可以根据聊天提示触发负载测试、比较端点、报告 p95/p99 延迟，并标记线程池饥饿问题。
@RetroChainer 声称（37 个赞、12 条回复、1,158 次浏览、20 次收藏）称，RTK 在不改代码的情况下，能将由 shell 驱动的 token 消耗降低约 80%。RTK 仓库 记录了同样形态的基准测试，并表示该代理会在命令输出送达模型前先行压缩；但讨论串里最有价值的回复，提出了一个显而易见的问题：激进过滤会不会把智能体真正需要的堆栈跟踪也一并藏掉。
@thdxr 表示（19 个赞、3 条回复、978 次浏览）称，OpenCode 的子智能体很快将需要额外配置，才能继续调用更多子智能体。这条看似很小的更新之所以重要，是因为它把“委派”重新定义成一个权限设计问题，而不只是能力问题。
讨论洞察： 这些内容的共同动作，都是在执行前或执行周围为智能体工作加结构：先定义规格、明确暴露真实工具、压缩 shell 噪声，或让递归委派变成显式选择。RTK 讨论串给出的最有价值质疑则是：输出被压缩得太狠时，到底会丢掉什么。
与前一天的比较： 2026-07-14，人们主要还在不同模型与智能体之间分发工作。到了 2026-07-15，更强的信号已经变成工作流纪律：明确的规格、明确的工具、明确的预算，以及明确的委派规则。
2. 什么让人感到沮丧¶
重叠的产品入口让人难以判断工作该放在哪一层¶
严重程度：中。Google 相关讨论表明，生态广度如今正在制造导航问题。@pigeon__s 提问（43 个赞、1,982 次浏览）在看到 Jules V2 预告后，追问 Jules 是否还独立于 Antigravity 存在；与此同时，@ottleyai 推广了（21 个赞、14 条回复、1,290 次浏览、11 次收藏）则给出了一张横跨 Gemini、Antigravity、Jules、ADK、A2A、FileSearch API 等产品的地图。让人沮丧的并不是对 Google 工具本身的反对，而是不知道该学哪一层、该采用哪一层，或者该把哪一层当作长期可持续的选择。之所以值得围绕这一点构建，是因为最直观的失败模式发生在写代码之前：注意力已经先被浪费掉了。
智能体操作周围的信任边界看起来依旧脆弱¶
严重程度：高。@Hamaaadite 指出（2 条回复、113 次浏览）介绍了 GhostApproval，公开的 Wiz 报告 以及 CSA 说明 则描述了一个影响六款编程助手的、基于符号链接的审批漏洞，其中包括 Claude Code 和 Google Antigravity。问题并不是抽象的安全理论：提示里描述的可以是一个看起来无害的文件，但实际写入却会落到 ~/.ssh/authorized_keys 或其他敏感目标上。
@xyz3va 抱怨（77 个赞、5 条回复、4,658 次浏览）称，此前披露的 OpenCode 安全问题仍未获确认，与此同时产品却在推广移动应用。这是一种单方面指控，但依然是信任侵蚀的有用证据。@thdxr 补充说（19 个赞、3 条回复、978 次浏览）则提出了一个更小但相关的点：嵌套子智能体将需要额外配置，这反映出委派规则在生产环境里仍然敏感到需要继续收紧。之所以值得围绕这一点构建，是因为用户显然想要智能体能力，但前提是审批界面与委派规则必须让人真正能理解。
团队更容易看到花费，却不容易看到价值¶
严重程度：高。多篇帖子都汇聚到同一个运营层面的抱怨：成本和使用量正在比工程回报更早变得可衡量。@Herald_Dev 认为（3 个赞、1 条回复、62 次浏览）称，团队已经在为 Claude Code 或 Cursor 付费，却没有可靠办法区分一个高纪律、高产出的用户，和一个高花费的“tokenmaxxer”。附带图表让这一抱怨变得更直观，尽管它并未给出公开方法论。
@GHchangelog 发布了（19 个赞、1 条回复、2,046 次浏览、4 次收藏）介绍了一项带使用量提醒的 Visual Studio 更新；@burkeholland 展示了（43 个赞、3 条回复、2,837 次浏览、27 次收藏）介绍了一个能暴露隐藏模型切换成本的 cache-miss 扩展；@ludvigrask_ 分享了（6 个赞、1 条回复、70 次浏览）则展示了 OpenCode Console 的计费页面，包括席位、发票和自动充值阈值。
@RetroChainer 声称（37 个赞、12 条回复、1,158 次浏览、20 次收藏）称，RTK 可以压缩 shell 输出，从而显著降低 token 消耗，但即便如此，讨论最后仍回到了一个问题：这些节省会不会以丢失调试细节为代价。Orca 的 使用情况跟踪文档 则从另一个角度体现了同样的需求：人们希望在会话卡住之前，就能看到剩余额度和重置时间。之所以值得围绕这一点构建，是因为当下的应对方式仍然是人工盯盘、反复查看仪表板，以及临时做压缩处理，而不是拥有一个值得信赖的 ROI 视图。
工作流原生智能体，同样会制造工作流原生噪声¶
严重程度：中。对 GitHub Copilot for Jira 最明确的反对意见，并不是它不该存在，而是它可能会把本来就很嘈杂的项目管理习惯进一步放大。在 @github 宣布（80 个赞、9 条回复、22,787 次浏览、28 次收藏）这条 Jira GA 帖子的回复中，多位用户预测会出现幻觉式验收标准、自动生成工单泛滥，以及让纸面生产力看起来更高、但团队真实信号质量更差的自动评论。产品本身确实加入了流式进度和会话后引导等控制点，但显而易见的担忧在于：管理界面往往比真正改善流程更容易被塞满。若能在不放大审查噪声的前提下，对智能体活动进行汇总和分流，这一点就值得围绕它构建。
3. 人们希望存在什么¶
从聊天到智能体再到产品家族的一张统一地图¶
Google 相关讨论显示，用户实际需要的是更少的重叠标签，以及不同入口之间更清晰的连续性。@pigeon__s 提问（43 个赞、1,982 次浏览）追问 Jules 是否实际上已经并入 Antigravity；与此同时，@ottleyai 展示了（21 个赞、14 条回复、1,290 次浏览、11 次收藏）则展示了一张横跨 Google 模型、编程工具和智能体基础设施的地图。这种需求是务实的，而不是理想化的：用户想知道哪一层负责哪类工作，以及资产或技能如何在不同入口之间迁移。机会：直接。
能展示真实风险的审批与委派控制¶
GhostApproval 说明，当路径本身就可能误导人时，用户不能依赖笼统的“批准这次编辑”提示。@Hamaaadite 提到（2 条回复、113 次浏览）提到了这个问题，@thdxr 指出（19 个赞、3 条回复、978 次浏览）则表示，嵌套子智能体的生成将被放到额外配置之后。隐含的要求是：在工作开始执行或发生委派之前，系统就应展示规范化目标、继承权限和升级规则。机会：直接。
面向输出的 ROI 跟踪，而不是原始 token 遥测¶
多篇帖子都指向一个缺失的管理层，它位于简单使用量计数器之上。@Herald_Dev 认为（3 个赞、1 条回复、62 次浏览）称，没有输出上下文的花费几乎毫无意义；@GHchangelog 宣布（19 个赞、1 条回复、2,046 次浏览、4 次收藏）提到 Visual Studio 里的实时使用量提醒，而 Orca 的 文档 则描述了带有重置感知的使用量显示。实际需求，是把配额、延迟和成本，与真正交付的工作、审查负担和缺陷率联系起来。机会：竞争性。
在执行前强制澄清的规格与工具契约¶
Spec Kit 是当天最清晰的供给侧回应，对应着一个贯穿全天的需求：人们希望智能体在动手构建前先把问题问清楚。@RituWithAI 描述了（11 个赞、4 条回复、164 次浏览、6 次收藏）点出了错误规格问题；@TheCodeMan__ 展示了（10 个赞、3 条回复、296 次浏览、3 次收藏）则展示了当智能体拥有明确 MCP 工具、而不是模糊指令时，会是什么样子。用户需要的是这样一种工作流：在模型开始自由发挥之前，需求、可调用工具和验证标准都已经被明确下来。机会：直接。
4. 正在使用的工具与方法¶
| 工具 | 类别 | 情绪 | 优势 | 局限 |
|---|---|---|---|---|
| Google Antigravity + Jules + Gemini CLI | 智能体平台家族 | (+/-) | 被呈现为 Google 大型开发栈的一部分，覆盖模型、CLI、IDE、异步编程和智能体基础设施 | 产品边界模糊到用户仍在追问 Jules 和 Antigravity 是否是两个独立产品 |
| GitHub Copilot for Jira | 项目管理集成 | (+/-) | 将编程智能体进度流式送入 Jira，支持在同一 PR 上继续引导，并简化上手流程 | 回复普遍担心工单泛滥、自动评论和幻觉式工作流噪声 |
| GitHub Copilot in Visual Studio | IDE 遥测与信任 | (+) | 实时使用量提醒、MCP 指纹校验、PR 上下文导入、C++ 现代化正式可用 | 提高了可见性，但单靠它仍无法回答 ROI 或代码质量问题 |
| Cache-miss Copilot extension | Copilot 扩展 | (+) | 在实时会话中直接显示缓存失效和模型切换惩罚 | 属于个人扩展示例，而不是标准产品功能 |
| Spec Kit | 工作流工具包 | (+) | 在实施前先把需求转成规格、计划和任务；可适配多种编程智能体 | 增加流程开销，且依赖人在各阶段认真审查 |
| AI in .NET Starter Kit / MCP Server | MCP 开发工具 | (+) | 为 Copilot agent mode 提供明确的性能测试工具、p95/p99 分析和实用编排示例 | 是教学示例，且明确未定位为生产可用 |
| RTK | CLI 代理 / token 优化 | (+/-) | 压缩嘈杂的 shell 输出、减少 token 消耗、开销低、适用面广 | 只对 shell 驱动的输出链路有效；过度压缩可能隐藏调试细节 |
| Orca | 多智能体 ADE | (+) | 并行 worktree、手机控制、使用量跟踪、SSH worktree，以及 GitHub/Linear 集成 | 智能体和账号越多，编排复杂度越高 |
| OpenCode | 编程智能体 | (+/-) | 真实用户报告了成功排障；内置构建/规划智能体和桌面应用也扩大了可达性 | 公开的未解决安全问题投诉削弱了产品叙事 |
| Codex Micro | 智能体控制硬件 | (+/-) | 实时状态按键、命令按钮、摇杆和旋钮为 Codex 提供了可触摸的控制界面 | 设备只服务于特定产品，也增加了一个额外需要管理的入口 |
整体满意度从务实的工作流辅助工具，一直延伸到明确的信任担忧。人们并没有放弃前沿智能体，而是在它们周围叠加新的控制层：Visual Studio 里的使用量窗口、Copilot 里的缓存洞察、OpenCode 里的计费视图，以及 Orca 的手机监督。迁移模式也依旧是多元并存，而不是赢家通吃。Orca 的价值主张是让 Codex、Claude Code、Copilot 等工具并行运行；TheCodeMan 的 MCP 示例则默认任何兼容客户端都应该能调用同一套工具。主流的应对方式仍然是显式结构：先规格后实施、明确暴露 MCP 工具、压缩 shell 输出，以及本地使用量监控，而不是寄望于某一个模型或某一个 UI 一次性解决整个闭环。
5. 人们正在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| Spec Kit | GitHub | 将需求提示转化为规格、计划、任务和实施工作流 | 减少因提示含糊而导致智能体朝错误方向编码的问题 | specify CLI、Markdown 工件、跨智能体斜杠命令 |
已发布 | 仓库 |
| AI in .NET Starter Kit / MCP Server | @TheCodeMan__ | 为智能体提供可调用的 .NET 工具，用于 API 性能测试与分析 | 让 MCP 在真实开发者工作流中落地，而不只是玩具演示 | ASP.NET Core、MCP、Blazor、自定义负载测试引擎、GitHub Copilot agent mode | 已发布 | 入门套件 |
| RTK | rtk-ai | 在 shell 输出到达编程智能体前先进行过滤和压缩 | 减少重复命令输出造成的 token 浪费 | Rust、CLI 代理、shell hooks | 已发布 | 仓库 |
| Orca | StablyAI | 在并行 worktree 中运行多个 CLI 编程智能体，并通过手机进行监督 | 让单个开发者能同时比较和引导多个智能体 | 桌面应用、移动伴侣应用、git worktrees、SSH、GitHub/Linear 集成 | 已发布 | 仓库 |
| GitHub Copilot for Jira | GitHub | 将编程智能体的执行、进度和后续引导带入 Jira | 在规划工作流中保留工单上下文和智能体进度 | GitHub Copilot、Jira、通过 MCP 获取 Confluence 上下文 | 已发布 | 更新日志 |
| Codex Micro | Work Louder | 用于监控和引导 Codex 智能体的实体控制器 | 用触觉状态与命令控制，替代又一个悬浮窗口 | RGB 状态按键、命令键、摇杆、旋钮、直接 Codex 集成 | Beta | 产品页面 |
最强的构建模式并不是“新模型击败旧模型”，而是“给现有智能体套上一层更好的工作操作系统”。@RituWithAI 描述了（11 个赞、4 条回复、164 次浏览、6 次收藏）把 Spec Kit 描述为一种在编码前强制澄清的办法；@TheCodeMan__ 分享了（10 个赞、3 条回复、296 次浏览、3 次收藏）则展示了一个性能测试 MCP server，让 Copilot 能调用真实工具并解释结果。@RetroChainer 重点介绍了（37 个赞、12 条回复、1,158 次浏览、20 次收藏）则从成本侧展示了同一种模式：不要改智能体本身，而要改送进它上下文的内容。
第二个模式，是围绕实时运行中的智能体工作构建监督与恢复能力。@ridark_eth 推广了（23 个赞、12 条回复、347 次浏览、13 次收藏）把 Orca 描述为并行智能体的舰队控制器；@testingcatalog 展示了（20 个赞、2 条回复、2,089 次浏览）则把 Codex Micro 展示为同一理念的实体化版本。在支持场景里，@cocktailpeanut 分享了（8 个赞、809 次浏览、4 次收藏）展示了一张用户截图：OpenCode 发现 Pinokio 安装器抓取了错误的软件包名称，并通过更新配置修复了冲突。
这张截图之所以重要，是因为它展现了当天智能体工具最实用的一面：不是基准测试，而是在工作流中把一个真实损坏的安装过程调试并修正。
6. 新鲜且值得关注的内容¶
GhostApproval 把老式符号链接漏洞变成了 AI 智能体的信任问题¶
@Hamaaadite 提到（2 条回复、113 次浏览）把 GhostApproval 描述为一个跨品类缺陷，而公开的 Wiz 文章 以及 CSA 说明 则清楚地说明了它的新意：问题不只是会跟随符号链接，而是审批 UI 隐藏了真实目标文件。这很重要，因为很多智能体安全承诺都建立在一个前提上——人的审批是知情审批。
仓库攻击演练正在成为智能体时代的一项运营技能¶
@BradGroux 报道称（10 个赞、1 条回复、20,203 次浏览）介绍了赢下 GitHub “Repository Under Attack” 红队工作坊的经历，附图也说明了它为何值得关注：事件路径同时涉及 PAT 泄露、部署密钥、恶意 npm 发布、GitHub Actions secrets，以及跨仓库凭证。讨论串里最有价值的细节是，只有当团队把证据、决策、遏制步骤和验证过程紧密串联起来时，Codex、OpenClaw 和 Copilot app 才真正发挥了帮助作用。
触觉界面和计费界面，开始被算作智能体功能的一部分¶
当天的讨论也清楚表明，“智能体 UX”如今已经包括硬件旋钮和财务页面。@testingcatalog 展示了（20 个赞、2 条回复、2,089 次浏览）介绍了一款面向 Codex 的控制器；@ludvigrask_ 分享了（6 个赞、1 条回复、70 次浏览）则展示了一个包含席位、发票时间和自动充值阈值的计费页面。这一组合之所以值得注意，是因为它暗示下一层竞争已经不再只是模型质量，而是工具能否清楚展示状态、支出和干预入口。
7. 机会在哪里¶
[+++] 保持信任的智能体权限与审批体验 — GhostApproval 表明，如果工具隐藏规范化目标，用户就无法安全地批准操作；而 OpenCode 对嵌套子智能体的调整，以及公开的安全投诉，也显示委派规则仍未稳定。若有产品能在执行前展示真实文件目标、继承权限和升级边界，就能回应这组数据中最强烈的信任痛点。
[+++] 面向输出的 ROI 与预算控制 — Visual Studio 的使用量提醒、Orca 的使用量跟踪、OpenCode 的计费页面、RTK 的 token 压缩方案，以及 Herald 的输出与支出图表，都指向同一个尚未满足的层：团队能看到成本和限制，却看不到持久的工程回报。最强机会，在于构建一个把配额、延迟、审查负担和实际交付关联起来的控制平面。
[++] 不制造工作流噪声的工作流原生监督 — Jira GA、Orca mobile、Codex Micro，以及 GitHub 更广泛的监督入口，都显示出人们希望在智能体运行时持续监控并引导它们。反向信号则是对工单泛滥和嘈杂自动评论的担忧。能够汇总工作、只在高价值时刻请求干预，并在不增加项目管理噪声的前提下保留可追溯性的产品，仍有明显空间。
[+] 以规格为先、由 MCP 支撑的执行工具包 — Spec Kit 和 TheCodeMan 的 .NET MCP 示例展示了一条摆脱模糊提示的务实路径：明确意图、暴露显式工具，并用具体输出做验证。正在浮现的机会，是面向特定领域的入门工具包，把需求结构、工具契约和验证闭环打包，服务真实工程任务。
8. 要点¶
- Google 占据了当天的大部分注意力，但主要靠的是生态叙事和传闻，而不是经过验证的产品证据。 互动量最高的 Gemini 3.5 Pro 帖子明确未经证实，而最有力的具体证据，则是一张把 Gemini、Antigravity、Jules 和智能体基础设施串成同一叙事的技术栈地图。（来源）
- 可见的前沿已不再只是更快地写代码，而是监督和引导那些已经开始运行的工作。 Jira GA、Visual Studio 使用量提醒、Orca mobile 和 Codex Micro，都在把智能体状态带到用户可以中途介入的位置。（来源）
- 信任与安全如今已成为编程智能体的一等产品要求。 GhostApproval 把经典符号链接漏洞变成了知情审批失效问题，而围绕未解决问题的公开投诉，以及对子智能体权限的收紧，也都说明用户正在密切关注这些边界。（来源）
- 最强的构建者活力集中在智能体外围的结构层，而不是替换模型本身。 Spec Kit、MCP server 示例、RTK，以及真实世界的排障帖子，都在聚焦于明确意图、暴露工具、减少噪声，或让恢复更容易。（来源）