Twitter AI 编程 - 2026-07-04¶
1. 人们在讨论什么¶
1.1 官方多智能体工作流正从“技巧”走向第一方产品（🡕）¶
最强的一组讨论聚焦于：把智能体协作变成产品层能力，而不再只是私下搭建的配置。至少有四条保留内容从不同角度体现了同一转变：由仓库定义的自定义智能体、官方的 Claude 内嵌 Codex 插件、明确的模型角色分工手册，以及围绕 ChatGPT 和 Codex 的统一应用讨论。相比 7 月 3 日关于 harness 和 handoff 的讨论，7 月 4 日更加具体：出现了具名命令、安装步骤和可复用的工作流文件。
@github 宣布（109 个赞、15 条回复、18,420 次浏览、29 次收藏）讨论 GitHub Copilot CLI 中的自定义智能体；关联的 GitHub 博客称，这些智能体配置文件位于 .github/agents，采用 Markdown 加 YAML frontmatter，可为可重复的终端工作流定义角色、工具和防护规则。
@HeyAnjula 展示了（28 个赞、10 条回复、508 次浏览、4 次收藏）讨论 OpenAI 的 codex-plugin-cc 在 Claude Code 中运行。公开 README 印证了关键说法：/codex:review、/codex:adversarial-review、/codex:rescue、/codex:status 和 /codex:result 都是已提供的命令；该插件使用本地 Codex CLI，并通过 ChatGPT 或 API 密钥认证，而不是依赖单独托管的运行时。
@Hyde_ai3 发布了（30 个赞、2 条回复、277 次浏览）给出了一套具体的编排方案：由 Fable 5 负责编排，Opus 担任深度推理子智能体，Sonnet 作为快速执行者，Codex 则作为独立的对等工程师。附图是关键证据，因为其中包含实际的 /agents、/plugin 和 /codex:setup 步骤，并建议让每个模型各司其职，而不是让一个模型包办所有工作。
@thsottiaux 调侃道（656 个赞、89 条回复、24,628 次浏览、27 次收藏）称 OpenAI 正在把“ChatGPT 带到 Codex 中，让 Codex 可以出现在 ChatGPT 里的 Codex 里的 ChatGPT 中”，但回复让这件事回到了实用层面：有人希望实现无需切换标签页的工作流；有人提出大约 500 个 thinking token 被截断的问题；还有一条较长的回复要求目标驱动工作流一旦开始循环时，能显示计划、里程碑和执行状态。
讨论洞察： 有价值的回复集中在责任归属、上下文窗口和执行可见性上。人们认可这种集成方向，但仍希望看到清晰的工作单元、分离的记忆，以及一个智能体向另一个智能体委派任务时更好的可追踪性。
与前一天的比较： 7 月 3 日将编排视为 harness 问题；7 月 4 日则把它推进到了第一方产品界面，并配套了文档化命令和可版本控制的智能体文件。
1.2 配额、重置和成本路由仍是核心，但讨论变得更偏运营（🡕）¶
成本压力仍然是重要的决策因素，但讨论已经超越了泛泛的价格抱怨。当日更有分量的内容聚焦于绕开限制、查看重置到期时间，以及构建能够承受速率限制的技术栈。与 7 月 3 日公开比价的氛围相比，7 月 4 日更关注运营控制。
@CrypSaf 表示（119 个赞、73 条回复、4,039 次浏览）称，将 Safio 升级为由 Claude、GPT/Codex、Gemini、Kimi 和 GLM 组成的混合方案后，平均月成本约为 $180，同时改进了故障回退并减轻了速率限制带来的痛点。引用的上下文很重要：他描述的是一个在本地运行、连接 Discord 数据、表格、机器人和代码的操作型智能体，而不是单一聊天助手。
@Mr_Salio 发帖称（126 个赞、21 条回复、8,739 次浏览、10 次收藏）展示了 Codex 中出现 GPT-5.6 Sol、Terra、Luna 以及新的速度控制选项。回复并未确认 Terra 和 Luna 的具体含义，但表明人们已经开始把模型命名、发布状态和速度档位视为工作流规划的输入。
@Ananth7e 分享了（36 个赞、2,456 次浏览）展示了带有明确到期时间的 Codex 重置面板，随后引用一名 OpenAI 员工称该功能“即将推出”。这很重要，因为重置时间不透明是 7 月 3 日的一个突出抱怨；这是信息流中首个较有力的证据，表明产品正在把到期窗口显示在界面中。
@israfill 声称（3 个赞、4 条回复、291 次浏览、3 次收藏）称，通过 Microsoft Foundry 和 Azure credits 路由 Claude Code，可以避开常见的五小时 Claude 限制。即使经济性仍只是用户报告，截图依然是有用的公开证据：其中显示 Azure 成本面板已产生 $32.93 费用，并有 $1,977.07 可用 credits，正是用户如今正在传播的那类路由变通方案。
讨论洞察： 读者关注的重点不再是原始基准性能谁更强，而是重置机制、到期倒计时、价格通道，以及工作流能否在没有意外中断的情况下持续运行。
与前一天的比较： 7 月 3 日主要讨论价格版图和对重置的焦虑；7 月 4 日增加了关于重置的具体界面证据，以及更明确的 credits 路由技巧。
1.3 围绕 AI 编程的安全加固开始成为独立的检查清单类别（🡕）¶
安全不再被视为未来才需要考虑的问题。三条保留内容都将其视为即时的工作流层：部署检查清单、技能供应链扫描，以及针对某个智能体产品的具体攻击链。这延续了 7 月 3 日的信任主题，但形式更加流程化。
@dashboardlim 警告称（8 个赞、776 次浏览、14 次收藏）称，Cursor、Claude Code、Lovable、Antigravity 和 Codex 发布迅速，但默认并不安全。附带的检查清单是核心证据，其中列出了七项具体检查：Supabase RLS 策略、服务端 API 密钥处理、身份验证边界情况、安全专家审查提示、后端验证、速率限制，以及错误信息泄露。
@DanKornas 强调了（7 个赞、5 条回复、1,116 次浏览、5 次收藏）介绍了 Skill Scanner，一款面向 AI Agent Skills 的尽力而为型安全扫描器。截图明确展示了其独特之处：它结合静态分析、YAML 和 YARA 模式、LLM 语义判断、行为数据流分析、SARIF 输出以及 GitHub Code Scanning 集成，用于在安装或团队推广前审查智能体资产。
@TakSec 总结道（6 个赞、791 次浏览、3 次收藏）介绍了 ODIN 的研究，显示 Google Antigravity 可通过隐藏的 <title> 标签和渲染后的图片 URL，被诱导外泄机密。ODIN 研究报告的截图将这一攻击类别从假设变成了具体案例。
讨论洞察： 值得注意的变化在于形式。信息流中不再是笼统的“AI 安全”论断，而是出现了实际的部署前检查、扫描器功能和攻击机制。
与前一天的比较： 7 月 3 日聚焦信任工具和漏洞研究报告；7 月 4 日则增加了更具运营性的“部署前先执行这些检查”的姿态。
1.4 工作流封装和面向特定角色的能力建设持续扩展（🡒）¶
另一个规模较小但仍有意义的讨论簇，关注如何将 AI 编程封装成面向特定角色、可教学的系统。证据不只是更多模型宣传，而是学习路线、拆解框架和基于角色的工具栈。
@ameliahazelai 分享了（21 个赞、16 条回复、198 次浏览、10 次收藏）列出了 18 门 Anthropic 免费课程。公开的 Skilljar 课程体系确认，该路线涵盖 Claude 桌面端工作流、Claude Code、MCP、智能体技能和子智能体，说明围绕这些工具形成的结构化培训发展得有多快。
@tom_doerr 分享了（4 个赞、1 条回复、2,255 次浏览、10 次收藏）介绍了 Plan Cascade，其 README 将其描述为一套 AI 驱动的级联开发框架，用于将复杂项目转化为可并行执行的任务批次。该仓库值得关注，因为它呈现了许多工作流帖子正在趋于采用的确切产品形态：拆解层、质量门、插件命令和多供应商执行。
@parmardarshil07 列出了（23 个赞、2 条回复、1,321 次浏览、19 次收藏）展示了一套日常数据工程技术栈，涵盖 GitHub Copilot、Claude、ChatGPT、Cursor、Amazon Q、Snowflake Cortex、Databricks Genie、dbt assistants 和 k8sgpt。它的价值在于说明，人们正在按任务进行专业化选择，而不是效忠于某一个助手。
讨论洞察： 这些面向角色的帖子表明，采用策略已经不再是“选出最好的模型”，而是“组装一套适合具体工作的工作流、课程体系和工具清单”。
与前一天的比较： 7 月 3 日已经出现了工作流规范化工具包；7 月 4 日则将其扩展为正式的学习路线和更多基于角色的技术栈披露。
2. 人们感到困扰的问题¶
不透明的限制、重置和会话状态仍在打断实际工作¶
严重程度：高。成本讨论本质上是控制权讨论。@CrypSaf 表示（119 个赞、73 条回复、4,039 次浏览）他围绕多个模型系列重构 Safio，正是为了获得更强的故障回退能力并减少速率限制瓶颈；@Ananth7e 分享了（36 个赞、2,456 次浏览）则展示了 Codex 重置面板，因为到期时间本身已经成为规划工作的关键因素。@israfill 推介了（3 个赞、4 条回复、291 次浏览、3 次收藏）把 Azure Foundry credits 作为绕过 Claude Code 时间上限的办法；@thsottiaux 的 ChatGPT-in-Codex 帖子（656 个赞、89 条回复、24,628 次浏览、27 次收藏）下还有回复抱怨，目标驱动型工作可能在不显示计划或进度的情况下陷入循环。应对方式已经很明确：用户堆叠多个模型、查看重置额度、通过其他计费通道进行路由，或手动监督长时间运行的目标。这值得投入建设，因为这些变通方案已经在实际运行，而不是停留在理论层面。
AI 编程工具默认仍然不够安全¶
严重程度：高。@dashboardlim 认为（8 个赞、776 次浏览、14 次收藏）称，主流 AI 编程工具经常跳过 RLS、将 API 密钥泄露到客户端代码中、遗漏身份验证边界情况，并且除非用户明确要求，否则不会配置速率限制。@TakSec 附上了链接（6 个赞、791 次浏览、3 次收藏）介绍了一条 Antigravity 提示注入攻击链，可转储环境变量并外泄机密；@DanKornas 回应道（7 个赞、5 条回复、1,116 次浏览、5 次收藏）则介绍了 Skill Scanner，将智能体技能安装视为供应链攻击面。人们通过增加明确的部署前检查清单和独立扫描工具来应对。这值得投入建设，因为问题具体、反复出现，并且直接关联生产风险。
多智能体链路和本地运行时仍有不少粗糙之处¶
严重程度：中。当天多次出现的迹象表明，在实践中将多个智能体串联起来仍然很脆弱。在 @HeyAnjula 的 插件帖子（28 个赞、10 条回复、508 次浏览、4 次收藏）下，有人说没有共享记忆层的两个智能体简直是“调试噩梦”；另一个人则询问智能体是否共享 token，以及是否会过早触及限制。@diegomarino 报道称（1 个赞、1 条回复、460 次浏览、3 次收藏）称，LM Studio 冷加载模型时 OpenCode 会卡住，因此他构建了一个预热插件；@BrightOginni 使用了（2 个赞、66 次浏览、2 次收藏）介绍了 Gitterm，用于更顺畅地共享 OpenCode 会话和开放端口。这些问题值得投入建设，因为它们是具体的运行时和协作问题，而不是抽象地要求“更好的 AI”。
3. 人们希望出现什么¶
透明的使用状态和更智能的成本路由¶
最明确的实际需求，是让工具解释自身的运行边界。@Ananth7e 分享了（36 个赞、2,456 次浏览）展示了重置面板，正是因为到期时间很重要；@israfill 建议（3 个赞、4 条回复、291 次浏览、3 次收藏）展示了通过 Azure credits 路由以避开 Claude 限制；@CrypSaf 将其定义为（119 个赞、73 条回复、4,039 次浏览）则展示了多模型故障回退，作为应对速率限制的直接方案。这是一项紧迫的实际需求：用户希望产品无需外部技巧，就能显示重置时间、当前通道、回退行为和剩余可运行时长。机会：直接。
具备可见工作单元、记忆边界和进度的任务委派¶
最明确的工作流诉求，是让多智能体委派变得可检查。在 @HeyAnjula 的 插件帖子（28 个赞、10 条回复、508 次浏览、4 次收藏）下，有人表示，真正需要管理的对象是被委派的工作单元：负责人、范围、工具、日志、审查者、成本画像和停止条件。@thsottiaux 的 Codex 帖子（656 个赞、89 条回复、24,628 次浏览、27 次收藏）下有回复要求提供任务计划、里程碑和可见进度，因为当前的目标模式可能陷入循环。这不是一个理想化想法，而是明确的产品缺口。机会：直接。
为生成式应用和已安装的智能体技能提供更安全的默认设置¶
人们要的不是更多泛泛的“AI 安全”，而是能够停止生成高风险默认配置的产品。@dashboardlim 列出了（8 个赞、776 次浏览、14 次收藏）列出了用户如今必须手动记住的具体检查；@DanKornas 推广了（7 个赞、5 条回复、1,116 次浏览、5 次收藏）则介绍了一款独立扫描器，仅用于在安装前审查智能体技能。这是一项已有检查清单和扫描器参与竞争的实际需求，但用户需要在编程工具之上额外叠加这些工具，说明核心工具仍有机会提供原生方案。机会：竞争性。
规格和文档变更能够自动同步到代码¶
这是一个较弱但已经显现的需求。@belindmo 询问（3 个赞、1 条回复、27 次浏览、3 次收藏）希望有一个智能体监控产品文档，并在文档发生变化时更新代码库。当前证据仍然有限，但这符合当天更广泛的规范优先、工作流优先编程趋势。机会：新兴。
4. 正在使用的工具和方法¶
| 工具 | 类别 | 评价 | 优势 | 局限 |
|---|---|---|---|---|
| GitHub Copilot | IDE 助手 | (+) | 用于 SQL、Python、PySpark 和 dbt；广泛适配日常工程技术栈 | 重复性工作流仍促使用户增加额外封装层，而不是只依赖原始自动补全 |
| GitHub Copilot CLI 自定义智能体 | CLI 工作流层 | (+) | 通过仓库定义角色、工具和防护规则，支持可重复的终端工作 | 回复显示，在高风险工作流中，人们怀疑仅靠 Markdown 防护规则是否足够 |
| Claude Code | 编程智能体 | (+/-) | 强大的主要工作界面，常被用作编排器或主要编程智能体 | 会话限制、上下文循环问题，以及提示不够明确时容易出现的安全隐患 |
| Codex | 编程智能体 | (+/-) | 在更大的工作流中承担后台救援、审查和第二意见角色 | 重置管理、发布状态不明确，以及关于截断或隐藏状态的部分抱怨 |
| OpenCode | 编程智能体 / 工作区 | (+/-) | 适用于云工作区和基于共享的工作流 | 本地模型冷启动和协作仍需要预热插件或 Gitterm 等附加工具 |
| Azure Foundry | 托管 / 计费通道 | (+/-) | 允许用户通过 credits 和企业计费界面路由 Claude 系列的使用量 | 配置开销高、credits 会过期，而且目前仍是变通方案，而非第一方产品答案 |
| Plan Cascade | 编排框架 | (+) | 将大型项目拆分为并行任务，并提供明确的质量门和多供应商执行能力 | 产品成熟度不一：插件稳定，桌面端处于 alpha，CLI 仍在开发 |
| Skill Scanner | 安全工具 | (+) | 支持多引擎检测智能体技能，并集成 SARIF 和 GitHub Code Scanning | README 明确说明它仅是尽力而为，仍需人工审查 |
| Anthropic Skilljar 课程 | 培训 | (+) | 为 Claude 桌面端、Claude Code、MCP 和子智能体提供结构化学习内容 | 适合入门，但无法消除运行时协调和治理问题 |
总体模式是组合，而非替代。@parmardarshil07 描述道（23 个赞、2 条回复、1,321 次浏览、19 次收藏）展示了一套基于角色的数据工程技术栈：Copilot 编写常规代码，Claude 负责架构和调试，Cursor 或 Codex 则按需使用。@Hyde_ai3 将其视为（30 个赞、2 条回复、277 次浏览）将 Claude、Opus、Sonnet 和 Codex 分配为同一工作流中的不同角色；@HeyAnjula 展示了（28 个赞、10 条回复、508 次浏览、4 次收藏）则显示，同样的角色划分正在成为官方插件能力。常见的变通方式，是围绕模型增加结构：用自定义智能体处理重复性终端工作，用 Foundry 处理计费和配额，用预热插件解决本地运行时问题，并在部署前执行安全检查。
5. 人们正在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| GitHub Copilot CLI 中的自定义智能体 | @github | 使用带有明确工具和防护规则的 Markdown 定义可复用终端智能体 | 重复执行相同的 CLI 工作流，以及反复解释团队上下文 | Markdown 智能体配置文件、YAML frontmatter、GitHub Copilot CLI、现有团队工具 | 已发布 | 推文, 博客 |
| Claude Code 的 Codex 插件 | @HeyAnjula 转发了 OpenAI 的插件 | 在 Claude Code 中运行 Codex，用于审查、救援、对抗性审查、查看状态和获取结果 | 在编程智能体之间切换标签页并手动交接 | Node.js 18.18+、Codex CLI、Codex app server、Claude Code、ChatGPT 或 API 密钥认证 | 已发布 | 推文, 仓库 |
| Plan Cascade | @tom_doerr 分享了 Taoidle 的项目 | 将复杂软件项目拆分为带质量门的并行可执行任务批次 | 大型项目中的上下文丢失，以及单个智能体的顺序执行 | Python 核心、Claude Code 插件、React/Rust 桌面应用、MCP server、多供应商 LLM 后端 | Beta | 推文, 仓库 |
| Skill Scanner | @DanKornas | 扫描 AI Agent Skills，检测提示注入、数据外泄和恶意代码模式 | 不安全的智能体技能安装，以及团队工作流中的供应链风险 | Python 3.10+、YAML 和 YARA 模式、LLM 语义检查、行为数据流、SARIF、GitHub Actions | Beta | 推文 |
| lmstudio-warm | @diegomarino | 在 OpenCode 发起请求前保持本地 LM Studio 模型处于加载状态 | LM Studio 冷加载或会话中途卸载模型导致 OpenCode 卡住 | OpenCode 插件、LM Studio | Alpha | 推文 |
| GangPrompt / Gitterm | @BrightOginni | 通过云工作区更安全地共享 OpenCode 会话和暴露的开发端口 | 难以共享本地智能体会话和实时开发应用 | OpenCode、Gitterm 云工作区和共享端口转发 | Beta | 推文, 网站 |
@tom_doerr 分享了（4 个赞、1 条回复、2,255 次浏览、10 次收藏）将 Plan Cascade 视为一个框架，而不是单智能体封装器；其 README 对此给出了少见的明确解释：拆解层、质量门和多个产品界面都是一等对象。
反复出现的构建模式并不是“做一个更聪明的聊天机器人”，而是“在智能体周围增加一层”：编排框架、安全扫描器、运行时预热工具和协作界面。即使项目很小，例如 lmstudio-warm，触发它的痛点也具体且偏运营；而当项目更大，例如 Plan Cascade 或 GitHub 自定义智能体时，构建者则会将工作拆解、防护规则和质量检查正式化，让工作流不再依赖某一次漫长对话。
6. 新动态与值得关注的内容¶
由仓库定义的自定义智能体进入主流 CLI 技术栈¶
@github 宣布（109 个赞、15 条回复、18,420 次浏览、29 次收藏）介绍了 GitHub Copilot CLI 的自定义智能体；关联博客称，它们位于 .github/agents 中，以可审查的 Markdown 文件形式存在，并包含明确的工具和防护规则。值得注意的是，这让智能体行为本身成为仓库状态，而不再是隐藏的个人配置。
Codex 重置可见性终于以产品界面形式出现¶
@Ananth7e 分享了（36 个赞、2,456 次浏览）展示了一个带有到期日期的重置面板，随后引用一名 OpenAI 员工称该功能即将推出。在连续数日公开讨论重置计算和配额困惑之后，出现实际的到期时间面板，是一次有意义的产品界面变化。
围绕 Claude Code、MCP 和子智能体的免费结构化培训不断扩展¶
@ameliahazelai 发帖称（21 个赞、16 条回复、198 次浏览、10 次收藏）列出了 18 门 Anthropic 免费课程；公开课程体系确认，其中包含 Claude 桌面端工作流、Claude Code、MCP 和子智能体模块。这很重要，因为生态规模已经足够大，入门培训本身正在成为一个产品类别。
7. 机会所在¶
[+++] 面向编程智能体的使用状态与路由控制平面 —— 第 1、2、3 节提供了相关证据：重置面板、Azure credits 路由、多模型故障回退技术栈，以及反复出现的限制不透明问题。一款能够显示当前通道、重置时间、回退行为和剩余可运行时长，同时无需用户依赖变通方案的产品，看起来尤其有潜力。
[++] 默认安全的交付流程与智能体技能溯源 —— dashboardlim 检查清单、Skill Scanner 和 ODIN 攻击链都指向同一个缺口：生成式应用和导入的智能体资产仍需要单独进行安全检查。这一机会的潜力中等偏强，因为检查清单和扫描器已经存在，但原生集成仍然缺失。
[++] 具备明确记忆和进度边界的工作单元编排 —— 官方 Codex 插件、GitHub 自定义智能体，以及要求提供负责人/范围/日志/审查者元数据的回复，都显示出对更好委派界面的明确需求。机会程度中等，因为许多团队已经在自行拼装这类方案，但工作流对象本身仍未得到充分建设。
[+] 围绕本地或云端智能体工作区的协作与运行时衔接层 —— Gitterm、lmstudio-warm 和 OpenCode 工作流帖子表明，围绕会话共享、端口暴露和本地模型就绪状态，正在出现一层新的需求。这一方向仍处于早期，但痛点已经具体到值得持续关注。
8. 要点总结¶
- 智能体编排正在成为可版本控制的工作流层，而不再只是高级用户的私下技巧。 GitHub 发布了由仓库定义的自定义智能体，OpenAI 的 Codex 插件则将 Claude 到 Codex 的委派变成了具名命令，而不是临时复制粘贴。（来源）
- 配额和重置可见性对用户行为的影响，仍然不亚于模型质量。 当天最强的成本信号不是基准测试图表，而是重置界面、Azure credits 路由，以及为防止工作在会话中途停止而设计的多模型故障回退。（来源）
- 安全已经成为日常 AI 编程工作流的一部分。 信息流中出现了具体的部署前安全检查、技能供应链扫描器和 Antigravity 攻击研究报告，全部指向运营层面的加固，而不是抽象的安全讨论。（来源）
- 构建者正在为智能体增加基础设施，而不是等待一个完美模型出现。 Plan Cascade、Skill Scanner、
lmstudio-warm和 Gitterm 的存在，都是因为拆解、审查、预热和共享仍然是彼此独立的产品问题。（来源） - 面向角色的技术栈正在成为常态。 一名数据工程师公开展示的技术栈，以及 Hyde 明确划分的 Fable/Opus/Sonnet/Codex 角色，都表明人们正越来越多地将不同助手分配给工作的不同阶段。（来源）