Twitter AI 编程 - 2026-07-13¶
1. 人们在讨论什么¶
1.1 编排已经从“聊智能体”走向真正上线的控制界面 (🡕)¶
7 月 13 日声量最大的一簇讨论，不再是选哪个最喜欢的模型，而是怎么把多个智能体真正跑起来。Google 推出了 Antigravity 的新 Agent Teams，GitHub 公布了 Copilot CLI 里子智能体委派带来的量化可靠性提升，而一线使用者则展示了定时运行和远程接管，正在成为下一层工作方式。整场讨论的语气非常偏运营：怎样让智能体运行能持续活着、可审查，而且成本低到值得反复用。
@testingcatalog 指出（129 点赞、8 回复、10,229 浏览量、15 收藏），Antigravity 现在支持 /teamwork-preview，而被引用的官方 Antigravity 帖子称，这支被拉起的团队会并行地规划、构建并验证复杂任务。那张截图之所以重要，是因为它显示这已经是产品内的一等命令，而不只是概念演示。
@github 报告（125 点赞、29 回复、24,700 浏览量、22 收藏），Copilot CLI 里更智能的子智能体委派，让工具失败下降 23%、搜索失败下降 27%、编辑失败下降 18%，且质量没有回退。配套表格还称 P95 等待时间下降 5%，这让它成为少数公开给出运行框架前后对比精确指标的帖子之一。
@iiiichigo_chan 表示（25 点赞、7 回复、928 浏览量、17 收藏），GitHub Agentic Workflows 能把 markdown 工作流变成常驻的 GitHub Actions 任务，让 Claude Code、Codex 或 Copilot 去“上夜班”，处理 bug 分诊、不稳定测试、发布说明或依赖更新。随后，@jfversluis 展示（1 点赞、1 回复、248 浏览量），Copilot CLI 的 --remote 流程在需要审批或分支策略决策时，可以从网页和手机继续接管。
讨论要点： 回复区并没有否定编排本身，而是一再强调运营层约束。@spboyer 认为（10 点赞、549 浏览量、6 收藏），每一次交接都会增加协调成本、更多工具调用和更多漂移机会；而 Antigravity 与 gh-aw 帖子下的回复，则集中在限流以及定时运行之间如何保住持久状态。
与前日对比： 7 月 12 日主要还在谈可移植层和桥接插件。到 7 月 13 日，讨论已经转向真正运行多智能体工作的控制界面。
1.2 信任边界已经变成具体事故，而不再只是架构口号 (🡕)¶
最强的一轮安全讨论，来自那些点名具体失败模式的帖子：被隐藏的符号链接目标、静默整仓上传，以及由厂商控制的记忆层表面。整体语气更偏运营，而不是理论。人们关心的已经不是抽象的安全承诺，而是到底有哪些东西会被写入、上传或保留。
@mardehaym 认为（98 点赞、12 回复、28,846 浏览量、101 收藏），Satya Nadella 那篇《pay for AI twice》文章，确实说中了组织知识泄漏的问题，但给出的答案依然是把客户带回 Microsoft 自己的栈。那条讨论串里最锋利的一条回复说，修正应该落到团队自有、可版本化的文件里，因为“模型只是来访问我们的记忆。它不会替我们保存。” 这把信任边界之争，变成了一条具体的设计规则。
@cloudsa 概括 了 Wiz 的 《GhostApproval》披露（5 点赞、2 回复、386 浏览量、2 收藏）。其中提到，Amazon Q Developer、Claude Code、Augment、Cursor、Google Antigravity 和 Windsurf 都可能被符号链接欺骗，在审批提示把真实目标藏起来的情况下，把内容写到工作区之外。Wiz 表示，AWS、Cursor 和 Google 很快修复了问题，而其余厂商的回应则更弱，或者并不完整。
@mardehaym 警告（5 点赞、5 回复、4,110 浏览量），Grok Build 0.2.93 即便在用户关闭了 “Improve the model” 后，仍把完整的已跟踪仓库和 git 历史上传到一个 Google Cloud 存储桶。cereblab 的线级分析 记录了 POST /v1/storage、grok-code-session-traces 存储桶路径，以及一个 12 GB 测试仓库传输了 5.10 GiB 数据，而提示词里已经明确写着不要读取文件。
讨论要点： 大家的共识不是“别用智能体”，而是“先让它们经过你能控制的那一层”：版本化记忆文件、明确的审批分级，以及能够确认隐私开关或权限边界到底是不是真的代理层。
与前日对比： 7 月 12 日关于信任的争论，还主要围绕谁拥有记忆层。到 7 月 13 日，公开的利用与外传证据已经把边界问题钉成了具体事实。
1.3 token 消耗问题已经开始在运行框架层被逐项拆解 (🡕)¶
用量问题依然很热，但讨论变得更具体了。人们现在比较的是上下文上限、首轮载荷大小，以及不同运行框架各自的 issue 吞吐，而不再只是泛泛抱怨“限制太模糊”。讨论也从“我把额度用完了”转向“到底是这个运行框架里的哪一层把预算烧掉了？”
@hqmank 表示（67 点赞、3 回复、6,034 浏览量），OpenAI 已确认 GPT-5.6 Sol 的 372K 上下文发布导致用量高于预期，因此已回滚到 272K。@kunchenguid 把这变成了一条配置建议（28 点赞、6 回复、5,192 浏览量、17 收藏）：如果某个非 Codex 运行框架还把 GPT-5.6 设成 372K，就把它降到 272K，避免白白损失额度。
@TateBerenbaum 分享 了一张针对 22 个字符任务的校准图（5 点赞、1 回复、164 浏览量、2 收藏）。图中估算，Claude Code 首轮载荷大约是 32,800 tokens，而 OpenCode 大约是 6,900，差距大部分被归因于 system prompt、工具 schema 和首条消息脚手架。
@BradGroux 表示（2 点赞、3 回复、547 浏览量），通过 Foundry 使用 GitHub Copilot App 处理积压 issue，相比 Codex 的 /goal “像拔牙一样费劲”；而他附上的截图甚至显示，应用自己也承认存在过度编排、重复会话和陈旧状态。@Layton_Gott 认为（3 点赞、3 回复、109 浏览量），“零上限”的智能体配置依然需要 6 条明确硬限制：花费、时间、重试、工具访问、停止条件和升级规则。
讨论要点： 大家给出的权宜方案已经很具体：改上下文窗口、按会话封顶花费、给计划过审而不是逐条审批每一次安全读取，并裁掉工具面，让运行框架少背一点固定成本。
与前日对比： 7 月 12 日的重点还是共享用量池和意外账单。到 7 月 13 日，讨论已经补上了上下文回滚证据、首轮固定开销图，以及明确的控制策略。
1.4 技能包、规格工具和提示词语料库正在变成可复用产品 (🡕)¶
另一簇讨论，则把工作流层本身当成了产品。构建者不再只是再发一个裸智能体，而是发布技能包、规格工具、提示词语料库和集成指南，让现有智能体更可复用、更可重复。人们越来越像是在整理流程资产的运营者，而不只是挑模型的人。
@Granite0x 提到 Addy Osmani 的 agent-skills（11 点赞、2 回复、525 浏览量、12 收藏）。仓库和截图显示，它围绕 define → plan → build → verify → review → ship 这条生命周期，提供了 24 个生产级技能、8 个 slash 命令，以及 77,991 个 GitHub 星标。@crptAtlas 把 GitHub 的 spec-kit 视为对抗“氛围式编码”漂移的解药；在审查时，这个仓库已有 120,694 个星标，并把规格描述为可执行工件，而不是一次性脚手架。
@Chinazhidx 强调 了 awesome-deepseek-agent（14 点赞、2 回复、681 浏览量、7 收藏），这是一个拥有 4,677 个星标的指南包，用于把 DeepSeek 接进 Claude Code、Codex、GitHub Copilot、GitHub Copilot CLI 等多种工具。@Suryanshti777 表示（14 点赞、4 回复、1,118 浏览量、13 收藏），system_prompts_leaks 仅靠整理 GPT-5.6、Codex、Claude、Gemini、Copilot、Grok 等系统背后的隐藏指令文件，就已经突破了 57,000 个星标。
讨论要点： 这里的语气，已经没那么在乎模型阵营之争，而更在乎可复用的操作流程。人们想要的是那些装得上、看得见、下次还能继续带走的工件。
与前日对比： 7 月 12 日还更多是桥接层和市场式指南。到 7 月 13 日，这种倾向已经扩展成完整的技能套件、规格工具包和公开提示词语料库。
2. 令人困扰的问题¶
没有把真相说全的审批提示、隐私开关和默认启用策略¶
严重程度：高。最尖锐的挫败感，不是代码生成得差，而是你失去了对智能体到底在做什么的控制权。@cloudsa 指出 了 Wiz 的 《GhostApproval》披露（5 点赞、2 回复、386 浏览量、2 收藏）：6 个编程助手都可能被诱导写到工作区之外，而审批提示里却把真实文件目标藏了起来。随后，@mardehaym 进一步放大 了 Grok Build 的整仓上传问题（5 点赞、5 回复、4,110 浏览量、3 收藏），而 cereblab 的公开线级分析 还记录了存储上传路径和字节数。即便不看这些明确的安全事件，@QuinnyPig 也抱怨（26 点赞、2,588 浏览量、4 收藏），GitHub Copilot app 会在整个组织里被默认开启，而退出说明却深埋在厂商邮件里。应对模式很一致：让智能体先经过自己可控的代理，把记忆留在团队自有、可版本化的文件里，并把无害的读取审批与任何会触及外部世界的操作分开。这值得有人来做，因为这个需求既是安全关键问题，也已经有具体的公开失败案例支撑。
运行框架开销和上下文设置仍然会制造账单惊吓¶
严重程度：高。即便 OpenAI 已把 GPT-5.6 Sol 从 372K 回滚到 272K 上下文，用量痛点也没有消失。@hqmank 展示 了人们如何继续排查上下文窗口计费问题（67 点赞、3 回复、6,034 浏览量、4 收藏），而 @kunchenguid 则把它变成了一条配置修复建议（28 点赞、6 回复、5,192 浏览量、17 收藏）。@TateBerenbaum 给出 的开销图（5 点赞、1 回复、164 浏览量、2 收藏）则提示，任务甚至还没开始，运行框架本身就可能把首轮大部分预算烧掉。@BradGroux 把 Copilot App 的 issue 积压工作形容为“像拔牙一样费劲”（2 点赞、3 回复、547 浏览量、1 收藏），而 @Layton_Gott 认为（3 点赞、3 回复、109 浏览量、2 收藏），自主任务必须对花费、时间、重试、工具访问、停止条件和升级流程设下硬上限。当前的权宜方案，是缩小上下文、裁掉工具面、给计划过审而不是逐条审批安全读取，并对每个任务硬性设置预算上限。这值得有人来做，因为这个痛点高频、偏运营，而且可度量。
多智能体配置仍在用速度换状态漂移¶
严重程度：中。那些对智能体团队最兴奋的人，也最快指出了协调税。@spboyer 表示（10 点赞、549 浏览量、6 收藏），子智能体从来不是免费的，因为每一次交接都会增加工具调用和漂移风险；而 @iiiichigo_chan 帖子下的一条回复则 强调（25 点赞、7 回复、928 浏览量、17 收藏），定时运行真正难的不是 cron 触发，而是持久记忆，以及和上一次运行做 diff。@jfversluis 展示 了为什么远程监督会有帮助（1 点赞、1 回复、248 浏览量、1 收藏）：长时间运行的任务，依然会冒出分支策略、合并和审批决定，需要人类来拍板。这值得有人来做，因为编排显然有用，但用户想要的是状态连续性和更低的协调成本，而不只是更多智能体。
很多团队依然需要帮助来决定何时不要用智能体¶
严重程度：中。@AiswaryaVenkit1 转述 了 Microsoft Cloud Adoption Framework，并把它压缩成一套很直白的规则（27 点赞、5 回复、300 浏览量、8 收藏）：如果工作本身结构化、可预测，或者已有现成 copilot 能解决，就别上定制智能体，继续用更简单的工具；只有当安全边界、跨团队协作或严肃规模需求真正成立时，才值得上多智能体。那条讨论串里最锋利的一条回复更短：正确答案往往比人们愿意承认的更常是“不要”。这值得有人来做成决策支持或架构评审，因为现在的市场大多在卖“怎么加更多智能体行为”，而不是“怎么拒绝它”。
3. 人们期望的功能¶
一个可审计的花费、权限与数据外发控制平面¶
最清晰的实际诉求，是有一个地方能同时看清：智能体能花多少钱、能碰什么，以及它到底往外发了什么。@Layton_Gott 明确列出了 缺失的控制项（3 点赞、3 回复、109 浏览量、2 收藏）—— 最大花费、最大时长、最大重试次数、工具范围、停止条件和升级规则；而 @hqmank 展示 了这一点（67 点赞、3 回复、6,034 浏览量、4 收藏），@kunchenguid 也展示了 这一点（28 点赞、6 回复、5,192 浏览量、17 收藏），@TateBerenbaum 同样展示了 这一点（5 点赞、1 回复、164 浏览量、2 收藏）：不透明的设置和固定开销，依然会直接变成意外消耗。GhostApproval 和 Grok Build 上传事件，又从安全侧把同一个需求说得更尖锐：人们想要一个控制平面，能够确认到底有哪些文件、提示词和打包内容真正越过了边界。花费上限、代理和按工具审批都只是局部答案，但需求显然比任何单一功能都更宽。机会类型：直接型。
切换引擎和会话重置后依然能活下来的工作流套件¶
人们反复用不同说法表达同一个愿望：工作流保住，引擎有需要时再换。GitHub Agentic Workflows 把 markdown 变成常驻的 GitHub Actions 任务，agent-skills 把可复用的工程生命周期打包给 70+ 个智能体，awesome-deepseek-agent 提供跨多个宿主的接线指南，而 @sairahul1 描述 了如何使用官方的 Claude Code 官方 Codex 插件（11 点赞、1 回复、1,862 浏览量、11 收藏），在保留同一个界面的同时切换底层执行模型。这个需求是务实的，不是情绪化的：用户不想每次偏好的智能体一变，就把整套操作流程重建一遍。机会类型：竞争型。
审批说真话、记忆归自己所有的更安全运行时¶
今天的公开证据，让这类安全诉求变得格外具体。Wiz 的《GhostApproval》披露 描述了会把真实文件目标藏起来的审批对话框，而 cereblab 的 Grok Build 分析 则记录了即便隐私开关关闭、整仓上传仍在继续的情况。与此同时，@mardehaym 认为（98 点赞、12 回复、28,846 浏览量、101 收藏），那条讨论串中的回复也认为，修正、日志和可复用记忆应该留在团队自有、可版本化的资产里。人们想要的并不只是一个更准确的模型，而是一个文件边界、审批提示和记忆所有权都可检查、可强制执行的运行时。机会类型：直接型。
开销更低的运行框架与更聪明的模型路由¶
Claude Code 与 OpenCode 的开销对比、GPT-5.6 的上下文回滚，以及人们对让 Claude Code 走本地代理、或让 Codex 跑在开放模型上的兴趣，都指向同一个需求：用户想保留同一套工作流，但固定成本更低、路由也更灵活。@TateBerenbaum 量化了 提示词和工具开销（5 点赞、1 回复、164 浏览量、2 收藏），@RedHat_AI 展示 了对开放模型 vLLM Agentic API bridge 的兴趣（10 点赞、2 回复、493 浏览量、2 收藏），而 OpenAI Codex Claude Code Proxy 仓库则展示了人们已经在尝试如何把界面与提供商解耦。这既是成本诉求，也是控制诉求。机会类型：竞争型。
一种在开工前就告诉团队到底值不值得上智能体的检查¶
@AiswaryaVenkit1 点出 了一个多数智能体工具仍然忽略的需求（27 点赞、5 回复、300 浏览量、8 收藏）：明确告诉团队，什么时候应该继续用传统 SaaS 工具、脚本，或更简单的单智能体路径。现在的市场，把更多精力花在增加编排层上，而不是防止过度工程化。这让这个需求既对企业买家很务实，也对那些一旦选了更简单架构就会担心自己落伍的团队带有情绪层面的吸引力。机会类型：直接型。
4. 使用中的工具与方法¶
| 工具 | 类别 | 评价 | 优势 | 局限 |
|---|---|---|---|---|
| Google Antigravity | 编程智能体平台 | (+/-) | 新增 teamwork-preview 团队编排、产品势头强、智能体平台叙事完整 |
用户仍在要求更高的限流额度和更强的模型能力 |
| GitHub Copilot CLI | CLI 编程智能体 | (+) | 公开量化的可靠性提升、可从网页/手机远程接管的工作流、不断扩大的运营控制面 | 用户仍希望看到更清晰的采用/限额数据，以及更谨慎的预算控制 |
| GitHub Copilot app | 应用 / 扩展平台 | (+/-) | 能承载 JVM Pulse 这类垂直扩展，也能在应用内呈现 issue/PR 工作 | 有用户说积压 issue 工作“像拔牙一样费劲”，而组织级默认启用会让管理员措手不及 |
| GitHub Agentic Workflows | 定时编排 | (+/-) | 自然语言 markdown 工作流可在 GitHub Actions 中跨多个引擎运行 | 计费 bug 曾迫使版本退役，而跨运行之间的状态仍是难题 |
| Codex / GPT-5.6 Sol | 模型 / 编程智能体 | (+/-) | 执行口碑强、官方已开始做用量优化、也能通过插件轻松委派 | 372K 上下文发布曾让用户被多收费用，所以路由和上限仍需手动照看 |
| Claude Code | 运行框架 | (+/-) | 拥有大型技能/插件生态，以及方便的 shell 工作流 | 一张公开开销图把极高的首轮载荷归因于提示词和工具脚手架 |
| OpenCode | 开源编程智能体 | (+) | 在一项公开对比中固定开销更低，而且已经被用于 issue 分诊循环 | 公开 issue 讨论里，仍有人提到 OpenCode 2.0 的 compaction-loop bug |
| Spec Kit | 规格驱动方法 | (+) | 让规格变得可执行，减少模糊提示词，仓库采用度很强 | 增加了前置流程，也扩大了命令面 |
| agent-skills | 技能包 | (+) | 把资深工程师工作流打包成可复用技能和 slash 命令，覆盖 70+ 个智能体 | 仍需要人工策展，而且效果依赖宿主智能体行为 |
| Awesome DeepSeek Agent | 集成指南包 | (+) | 可在 Claude Code、Codex、GitHub Copilot 和 GitHub Copilot CLI 之间快速接入 | 证明的是集成更轻松，而不是单靠它就能带来更好输出质量 |
| JVM Pulse | Copilot 扩展 | (+) | 把 Java GC/JFR 工件转成仪表盘和 Copilot 建议 | 只适用于 Java，而且仍处在极早期阶段 |
整体来看，人们对编排和工作流打包的情绪是“谨慎偏正面”，而对默认设置、隐藏成本和信任边界则明显更怀疑。最强的赞赏，给了那些能让智能体行为更可见或更可重复的工具：委派指标、定时任务、规格工作流、技能包和指南集。
这些权宜方案是组合式的。先保留你喜欢的界面，再替换执行层或给外面加控制面：要做委派任务时，可以用 Claude Code 官方 Codex 插件；当计费来源很关键时，可以让 Claude Code 经过本地代理；如果优先级是开放模型，也可以关注 @RedHat_AI 那场 vLLM Agentic API 桥接演示（10 点赞、2 回复、493 浏览量、2 收藏）。用户也一直在缩减上下文、工具列表和审批范围，避免让运行框架本身变成最大的摩擦来源。
竞争态势看起来更像组合游戏，而不是赢家通吃。就在同一天里，市场上同时冒出了团队编排功能、远程接管功能、指南包、技能包、规格工具包、应用扩展、开放模型桥接层和定时工作流运行器。这是一个工作流层仍然非常悬而未决的市场。
5. 人们在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| GitHub Agentic Workflows | GitHub | 按计划在 GitHub Actions 中运行自然语言 markdown 工作流 | 每次都要重复做同样的仓库杂务，并在每次运行时重新交代上下文 | Go、GitHub Actions、markdown 工作流、多引擎支持 | 已发布 | repo, post |
| agent-skills | Addy Osmani | 面向 AI 编程智能体的生产级技能包，含 24 个技能和 8 个 slash 命令 | 团队需要可重复的工程流程，而不是临场拼凑的提示词 | JavaScript 仓库、markdown 技能、slash-command 配置、Claude Code plugin | 已发布 | repo, post |
| Spec Kit | GitHub | 把规格转成可执行落地工作流的规格驱动工具包 | 模糊需求和不可预测的“氛围式”改动 | Python、Specify CLI、智能体集成、可执行规格 | 已发布 | repo, post |
| Codex plugin for Claude Code | OpenAI | 在 Claude Code 内加入 /codex:review、/codex:rescue 和后台任务管理 |
想用 Codex 做审查或执行，又不想离开 Claude Code | JavaScript、Node.js、Claude Code plugin、Codex app server | 已发布 | repo, post |
| Awesome DeepSeek Agent | DeepSeek AI | 把 DeepSeek 接进多种助手的指南包 | 切换提供商时的接入配置摩擦 | Markdown 文档、DeepSeek-V4-Pro/V4-Flash 配置、多客户端指南 | 已发布 | repo, post |
| JVM Pulse | brunoborges | 能分析 GC + JFR 并给出 JVM 调优建议的 Copilot canvas 扩展 | Java 性能分析通常游离在编程智能体工作流之外 | JavaScript canvas 扩展、GCToolkit、JDK jfr CLI、jbang |
Alpha | repo, post |
| System Prompts Leaks | asgeirtj | 汇集主流助手系统提示词的公开语料库 | 构建者想检查助手为何会这样表现 | JavaScript 仓库、CC0 文档语料库 | 已发布 | repo, post |
| OpenAI Codex Claude Code Proxy | MikeChongCan | 本地代理启动器，让 Claude Code 通过 OpenAI/Codex OAuth 或 Azure OpenAI 与 GPT 模型对话 | 在保留 Claude Code 工作流的同时，切换模型提供商和计费来源 | Python、CLIProxyAPI、本地 Anthropic 兼容代理、GPT-5.6 路由 | Alpha | repo, post |
最强的构建模式，是把工作流打包本身做成产品。GitHub Agentic Workflows、agent-skills、Spec Kit、codex-plugin-cc 和 awesome-deepseek-agent 都默认了一件事：工作流的寿命，会比当前最受欢迎的模型或宿主更长。一个把重复工作变成定时 markdown 任务，一个把资深工程师习惯编码成流程，一个让规格变得可执行，一个把 Codex 留在 Claude Code 里，还有一个则降低了切换提供商时的接入摩擦。
第二个模式，是面向运营者的扩展与路由层。JVM Pulse 借助 GitHub Copilot 启动 Java 工作负载、收集 GC 和 JFR 工件，然后在仪表盘里总结吞吐、暂停、分配率和堆行为。而 OpenAI Codex Claude Code Proxy 走的是反方向：保留 Claude Code 界面，但通过 localhost 代理把它路由到 GPT-5.6 Sol，并决定计费记在 OpenAI/Codex OAuth 还是 Azure OpenAI 名下。
其他构建者信号，则集中在让智能体行为可检查。System Prompts Leaks 把系统指令当成公共参考层，而 @thdxr 展示 了一个 issue 通道（66 点赞、10 回复、3,600 浏览量）：OpenCode 会把高质量 GitHub issues 拉进来，再尝试复现并修复。@RedHat_AI 强调 了一场 vLLM Agentic API 演示（10 点赞、2 回复、493 浏览量），它让开放模型也能保留 Codex 风格的网页搜索和多轮状态，这说明路由与可观测性本身可能会长成一个独立产品类别。
6. 新动态与亮点¶
一家头部编程智能体厂商公开了真实的运行框架前后对比指标¶
@github 做了一件少见的事（125 点赞、29 回复、24,700 浏览量、22 收藏）：它在修改子智能体委派逻辑后，公布了 Copilot CLI 的精确失败率和等待时间变化。在一个通常靠演示和氛围说话的市场里，一张写着工具失败减少 23%、搜索失败减少 27%、编辑失败减少 18%，且没有质量回退的表，已经是真正的信号。
GhostApproval 让审批体验问题第一次有了名字¶
Wiz 的 《GhostApproval》报告 把一种模糊的不安，变成了具体的漏洞模式：跟随 symlink，再加上智能体审批提示里的 UI 误导。@cloudsa 把它带进了 AI 编程时间线（5 点赞、2 回复、386 浏览量），这很重要，因为它说明安全研究如今盯上的，已经不只是模型输出，还有审批模型本身。
Copilot 原生扩展正迅速走向垂直领域¶
@brunoborges 介绍 了 JVM Pulse（9 点赞、3 回复、501 浏览量），这是一个 Copilot canvas 扩展，会分析 Java GC 和 JFR 遥测，再让 Copilot 给出优化建议。它值得注意，是因为这里的编程智能体不再只是代码生成器，而成了工件与调优建议的交互界面。
系统提示词正在变成公共参考层¶
@Suryanshti777 表示（14 点赞、4 回复、1,118 浏览量、13 收藏），system_prompts_leaks 已经突破 57,000 个星标，而仓库截图显示，里面最近加入了 GPT-5.6、Codex、Claude 以及 GitHub Copilot for macOS 的提示词条目。这很值得注意，因为社区越来越把隐藏指令看作可检查的基础设施，而不是厂商的魔法。
7. 机会在哪里¶
[+++] 可审计的智能体治理平面 —— 证据来自 GhostApproval、Grok Build 上传事件、372K→272K 回滚、OpenCode 与 Claude Code 的开销对比图，以及对花费上限、工具范围和升级规则的明确呼吁。这个方向很强，因为痛点同时横跨安全、成本与运营者控制。
[+++] 工作流可移植套件与编排层 —— GitHub Agentic Workflows、agent-skills、Spec Kit、Claude Code 的 Codex 插件，以及 awesome-deepseek-agent，都在解决同一个问题：团队想要的是能跨引擎变化、会话重置和宿主切换继续活下来的工作流。这个方向很强，因为信号同时覆盖了官方厂商项目、独立构建者和指南包。
[++] 低开销路由与模型切换基础设施 —— TateBerenbaum 的固定开销图、Codex Claude Code Proxy 仓库，以及 vLLM Agentic API 桥接演示，都指向同一层：把界面与提供商拆开，同时压低固定成本。这个方向属于中等强度，因为需求很明确，但最终胜出的产品形态还在浮现。
[++] 垂直领域智能体扩展 —— JVM Pulse 展示了，当编程智能体不再只是纯代码生成器，而成为遥测、分析和建议的入口时，会发生什么。这个方向属于中等强度，因为模式很有前景，但公开证据仍然早期而且偏小众。
[+] 智能体 / 非智能体架构顾问 —— 那条 Microsoft 决策树讨论串说明，市场上确实存在一种真实需求：告诉团队什么时候不该再加更多智能体行为。这个方向属于新兴机会，因为需求可信，但几乎没有产品把“克制”当作自己的主卖点。
8. 要点总结¶
- 编排正在成为一层一等公民级别的产品界面。 Antigravity 的
/teamwork-preview、Copilot CLI 的委派指标、gh-aw 的常驻任务，以及 Copilot CLI 的远程控制，都指向了单智能体提示词之上的新一层。(source) - 对信任边界的担忧，如今已经有了具体的公开失败案例支撑。 这一天里出现了被点名的审批体验漏洞、整仓上传证据，以及一再要求代理层和自有记忆的呼声。(source)
- 用量痛点正在变成运行框架工程。 372K 回滚、272K 权宜配置建议，以及固定开销图，关注的都不是模型质量本身，而是 shell 到底怎么配置。(source)
- 工作流层如今已经成了一个独立产品类别。 技能包、规格工具包、集成指南，以及公开的系统提示词语料库，都在被当成可复用基础设施。(source)
- 构建者的精力，正在投向围绕智能体的外包装、扩展与路由层。 JVM Pulse、Claude Code 的 Codex 插件、Claude Code 到 GPT 的代理，以及 vLLM 桥接演示，都在延展或重定向现有智能体，而不是直接把它们替换掉。(source)
- 成熟团队在扩大自动化之前，正在重新引入架构判断。 今天最有分量的治理建议，是先判断一项任务到底该不该上智能体、尽量保留单智能体路径，并在正确的边界上审批计划。(source)