跳转至

Twitter AI 编程 - 2026-07-05

1. 人们在讨论什么

1.1 工作流层和编排套件持续增多 (🡕)

最强的一簇讨论,并不是新的旗舰模型发布,而是继续围绕现有编程智能体,把上下文、记忆、协调和审查封装成产品层。至少有 7 条保留样本支撑这个主题:GitHub 自定义智能体、AI Workflow 技能包、multi-agent-shogun、Maestro、Happier、Orca,以及一个设计技能注册表。相比 7 月 4 日偏第一方的多智能体推进,7 月 5 日把方向扩展到了第三方工作流套件和操作员界面。

@github 宣布 (171 点赞,18 条回复,28,102 浏览量,54 收藏数) GitHub Copilot CLI 推出自定义智能体;关联的 GitHub 博客写明,这些智能体以 Markdown 配置文件的形式放在 .github/agents 中,带有 YAML frontmatter、明确的工具访问权限,以及可审查的安全护栏,用来复用终端工作流。

@DanKornas 重点提到 (20 点赞,5 条回复,1,737 浏览量,25 收藏数) AI Workflow,它的公开 README 证实,这个项目提供 170+ 个可安装技能、面向特定领域的工作流包、npx add-skill,并支持 Claude Code、Cursor、Codex、OpenCode、GitHub Copilot 和 Gemini CLI。重要的变化,不是又一个提示词包,而是可复用的工作流上下文正在以跨工具的安装入口分发。

@DanKornas 分享了 (24 点赞,6 条回复,1,834 浏览量,18 收藏数) multi-agent-shogun,公开 README 佐证了它最特别的说法:一个统筹者加多个执行者,可以在可见的 tmux 窗格里并行运行;委派、报告和协调都通过 YAML 文件处理,而不是依赖隐藏状态。

README 截图,展示 multi-agent-shogun 如何在并行终端窗格中协调一个统筹者和多个执行智能体

@DanKornas 分享了 (9 点赞,6 条回复,1,143 浏览量,5 收藏数) Maestro,它的 README 写明有 25 条工作流命令、7 个参考文件、持久记忆、审计轨迹和一个 MCP 服务器。回复里,有读者立刻追问这些记忆单元能否保持新鲜,而不是最后变成过时的维基式摘要;这说明持久化本身已经成了现实的设计问题。

@DanKornas 提到了 (8 点赞,3 条回复,1,522 浏览量,7 收藏数) Happier,这是一款面向 Claude Code、Codex、OpenCode 等工具、支持端到端加密的跨设备客户端;与此同时,@YoussefHosni951 (3 点赞,3 条回复,97 浏览量) Orca 描述成一个可将单个任务分发到隔离的 git 工作树中并排比较结果的环境。两者合在一起,把主题从“安装一个工作流”推进到了“跨机器和设备监督多个工作流”。

讨论要点: 有价值的质疑,集中在记忆质量和安全性,而不是工作流层是否重要。GitHub 那条帖子下面的回复在质疑,单靠 Markdown 安全护栏是否足以应对高风险事件;Maestro 那条帖子下面最尖锐的回复,则在追问会话记忆能否保持结构化和时效性,而不是很快陈旧。

与前日对比: 7 月 4 日把第一方多智能体推进带入视野。到 7 月 5 日,同一方向又扩展成可复用技能库、记忆层、多智能体 shell,以及移动端监督界面。

1.2 绕开限制的路由开始变成产品层,而不再只是临时权宜方案 (🡕)

成本和配额压力仍然是核心,但讨论语气又变了。7 月 4 日重点是重置可见性和 Azure credits 绕行方案;7 月 5 日则更强调跨提供商路由的控制平面、预付费钱包,以及明确的本地/云端任务策略。最强的样本,都在讨论如何不重搭整个工作流,就让会话继续跑下去并切到更便宜的通道。

@VaibhavSisinty 表示 (71 点赞,10 条回复,7,614 浏览量,142 收藏数) 9Router 可以夹在 Claude Code 和 40+ 家提供商之间;当一条通道耗尽时,它会切到更便宜或免费的模型,还能压缩工具输出,并在实时面板里显示配额状态。附带的面板才是关键证据,因为它把已连接的 OAuth 提供商、免费提供商和 API-key 提供商都放进了同一个路由界面,而不是停留在理论功能清单上。

9Router 提供商面板,展示 Claude Code、Antigravity、Codex、Copilot、免费模型提供商和 API-key 提供商如何被接入到同一个控制平面

@StudentOffersHQ 表示 (61 点赞,3 条回复,3,330 浏览量,64 收藏数) Inference.net 通过一个兼容 OpenAI 的密钥提供 26 个前沿模型,并为新用户提供 26 美元 credits。钱包截图之所以重要,是因为它清楚展示了 25 美元支持额度、1 美元起始额度,以及立刻开始扣减的用量,让预付费 credits 这条路不再停留在抽象层面。

Inference.net 钱包界面,显示 25 美元支持额度、1 美元起始额度,以及预付费使用扣款

@elbruno 发布了 (7 点赞,2 条回复,505 浏览量,4 收藏数) 新的 CopilotHarness 系列,主张“为合适的任务选用合适的模型”;关联的 项目文档 则介绍了在 Aspire 编排下,如何按策略在 Ollama、Microsoft Foundry Local 和云端模型之间做路由。

@khanUmarCodes 表示 (3 条回复,58 浏览量),他用 OpenCode 搭配开放权重的 MiniMax 和 DeepSeek 模型,大约花 10 美元就能把日常工作跑起来;但前提是工作流要先澄清需求、再写 PRD、再拆成开发任务,最后切成可测试的切片。这让路由主题更落到实操层:只有任务结构更严格,便宜模型才真正可用。

讨论要点: 回复区主要不是在庆祝“免费 AI”。大家反复回到的还是连续性和调试问题。9Router 那条讨论串里,有人希望 Cursor 和 Antigravity 也能获得同样的控制能力;另一条不同立场的回复则认为,提供商抽象层很重要,因为无论底层正在跑哪个模型,工具的行为都应该保持一致。

与前日对比: 7 月 4 日把配额管理视为重置时机和计费通道的绕行问题。到 7 月 5 日,讨论又上移了一层,变成路由器、预付费多模型钱包,以及按策略切换本地/云端的选择机制。

1.3 智能体工作流扩散到了相邻领域:Web 应用、攻防安全和数学研究 (🡕)

第三簇讨论表明,编程智能体的模式正在走出惯常的“帮我改代码库”框架。保留下来的证据覆盖了浏览器原生智能体、进攻性安全多智能体框架,以及专家级数学工作流。共同点在于:让专家继续留在回路中,同时把更多结构化执行交给智能体系统。

@israfill 重点提到 (53 点赞,21 条回复,4,286 浏览量,59 收藏数) Alibaba 的 Page Agent,公开仓库证实了几个关键说法:只需一行页内 JavaScript 就能集成、用基于文本的 DOM 交互而不是截图来操作、支持自带模型,并可选用浏览器扩展或 MCP 路径来扩大控制范围。这很重要,因为它把浏览器自动化重新定义成可嵌入的产品功能,而不是单独的一套无头技术栈。

@IntCyberDigest (34 点赞,2 条回复,3,456 浏览量,25 收藏数) T3MP3ST 概括为面向 Claude Code 和 Codex 订阅的多智能体进攻性安全框架。附表才是关键证据,因为它把系统声称能覆盖的目标,以及每条能力线的成熟度都写得很清楚:Web 应用和 CTFs 已经稳定,机器人或 OT 工作流达到流水线稳定,源码分析只支持 Python 输入,而智能合约则偏向复现而不是发现新问题。

T3MP3ST 能力表,展示其声称覆盖的领域、稳定性状态,以及在 Web 应用、CTFs、源代码和智能合约上的注意事项

@nasqret 写道 (17 点赞,575 浏览量,9 收藏数),Claude Code 和 Codex 正在改变他在算术代数几何中的工作流:他现在可以按思考的速度生成并检查 CAS 代码,而不必手工敲下每一次验证。最有信息量的图,是那张已验证的更正表,因为它说明这个工作流被用在具体的数学核验和论文支撑上,而不只是一般性的笔记记录。

一张数学工作流中的核验表,对比修正前后结果,并展示一次围绕 Claude Code 和 Codex 的完整循环

讨论要点: 这些帖子并不是在说智能体会取代领域专家,恰恰相反。它们呈现出的模式是:专家保留判断权,而智能体接手 Web 界面、利用链流水线或符号计算工作流里那些重复但高度结构化的执行环节。

与前日对比: 7 月 4 日还有安全检查清单和培训路径。到 7 月 5 日,已经出现了更贴近实操、也更具领域特征的工作流:浏览器辅助助手、进攻性安全多智能体集群,以及研究型数学家用编程智能体做真实核验工作。

1.4 真正的优势,仍被归因于运行框架本身 (🡒)

这个主题在 7 月 3 日和 7 月 4 日就已经很强,到了 7 月 5 日仍在延续。新的细节是,人们越来越多地用流程图、基准差值和具体工作流模式来支撑这一判断,而不再只是靠直觉。反复出现的信息是:模型当然重要,但围绕它的闭环更重要。

@0x_kaize 认为 (29 点赞,13 条回复,1,094 浏览量,17 收藏数),提示工程正在被闭环工程取代。附图是最主要的证据,因为它把对比写得很直白:提示工程是一次性的提示—响应路径,而闭环工程则围绕目标、计划、行动、验证、反思和迭代组织起来,并把失败恢复与成功条件直接写进流程。

对比图,展示一次性提示工程与包含目标、计划、行动、验证、反思和迭代的闭环工程流程

@PhiloGroves 提到了 (2 条回复,109 浏览量) 腾讯的 《Xuanwu Atuin AI CyberGym》文章,其中报告 GLM-5.1 在 CyberGym Level 1 上取得 84.0% 的 pass@1,相比之下,文中引用的 Claude Code 环境下 GLM-5.1 成绩为 68.7%。腾讯把差距归因于管理者/子智能体编排、安全专项技能、SOP 遵循、TODO 跟踪,以及用于检测漂移的工作流钩子。

@khanUmarCodes 补充了 (3 条回复,58 浏览量) 同一个思路的实践者版本:他在更便宜的开放权重模型上拿到收益,是因为先改工作流,让智能体先澄清歧义、写 PRD、把工作拆成可测试切片,并避免过度工程化。

讨论要点: 真正的实操问题,已经不再是“哪个基础模型更强?”。而是“什么样的工作流,才能让智能体足够久地保持任务对齐、成本可控、且便于审查,直到把真实工作做完?”

与前日对比: 7 月 4 日把编排更多视为角色拆分和产品层问题。到 7 月 5 日,则补上了明确的闭环流程图、同模型基准差距,以及更细致的一线实践者说明:为什么流程层会改变结果。


2. 令人困扰的问题

限额、额度和提供商切换,仍会打断原本不错的工作流

严重程度:高。声量最大的成本帖子,本质上全是在讲绕行方案。@VaibhavSisinty 表示 (71 点赞,10 条回复,7,614 浏览量,142 收藏数),人们用 9Router,正是为了让 Claude Code 会话在一条通道用尽之后,能先切到更便宜、再切到免费的提供商而不停下;@StudentOffersHQ 则把 (61 点赞,3 条回复,3,330 浏览量,64 收藏数) 预付费额度和单密钥模型访问包装成继续工作的现实办法。@elbruno 的回应 (7 点赞,2 条回复,505 浏览量,4 收藏数),是给 Copilot 做一个本地/云端路由运行框架;@khanUmarCodes 则说 (3 条回复,58 浏览量),只有当工作流足够结构化、能减少无谓重试时,他才真正把便宜模型跑通。人们正在用代理层、预付费钱包、本地模型和路由策略来应对。这个方向值得做,因为绕行层本身已经开始长成独立产品。

只靠原始提示词,仍会导致漂移、过度工程化和会话失忆

严重程度:高。@0x_kaize 认为 (29 点赞,13 条回复,1,094 浏览量,17 收藏数),一次性提示对长时运行太脆弱,因为它缺少记忆、验证和恢复机制。@khanUmarCodes 从另一面描述了 (3 条回复,58 浏览量) 同样的失败模式:请求一旦含糊,智能体就会自信地替你消解歧义,最后在后续阶段表现成过度工程化或漂移。@DanKornas 分享了 (9 点赞,6 条回复,1,143 浏览量,5 收藏数) Maestro 这层记忆与工作流层,而最有价值的那条回复立刻追问:如果不跟踪结论、范围、状态和来源轨迹,记忆条目是不是很快就会过时。这个方向值得做,因为用户现在明确要的是工作流结构,而不只是更好的自动补全。

没有额外 shell 或配套应用时,同时监督多个智能体依然很别扭

严重程度:中。@DanKornas 分享 (24 点赞,6 条回复,1,834 浏览量,18 收藏数) multi-agent-shogun,正因为“难的是协调 8 个,不是跑 1 个”。@DanKornas 发布了 (8 点赞,3 条回复,1,522 浏览量,7 收藏数) Happier,让会话能在手机、Web、桌面和终端之间保持可访问;@YoussefHosni951 则把 (3 点赞,3 条回复,97 浏览量) Orca 展示成一个能在隔离工作树中比较多个智能体的环境。应对模式已经很清楚:tmux 层级、跨设备客户端,以及专门的智能体 IDE。这个方向看起来值得做,因为这种痛点往往要等团队开始持续运行多个智能体之后才会暴露出来。

具备浏览器能力的智能体,仍暴露出严重的安全攻击面

严重程度:高。@TakSec 警告 (11 点赞,1 条回复,1,274 浏览量,8 收藏数),Google Antigravity 可以被隐藏的 <title> 标签诱导,泄露 API 密钥;关联的 ODIN 文章写明,一旦用户批准了智能体口中无害的“可视化调试 token”,外传路径就会经过终端访问,再借一条渲染后的图片 URL 把数据带出去。@IntCyberDigest 也展示了 (34 点赞,2 条回复,3,456 浏览量,25 收藏数),像 T3MP3ST 这样的进攻性多智能体框架,也已经开始产品化,带有面向特定领域的 hunt 模式和成熟度声明。就连 Page Agent 的公开文档也强调,关键操作前要有人类确认,这说明构建者已经把它当成正在发生的风险。这个方向值得做,因为暴露面具体、可复现,而且直接绑定在浏览器 + 终端智能体上。


3. 人们期望的功能

原生的成本感知路由和可见的配额状态

最明确的现实需求,是让产品自己暴露出运行边界,而不是把用户逼到外部代理和表格里。@VaibhavSisinty 展示了 (71 点赞,10 条回复,7,614 浏览量,142 收藏数) 9Router 为什么能引发共鸣:回退规则、配额跟踪,以及跨多个提供商的统一入口。@StudentOffersHQ 则把 (61 点赞,3 条回复,3,330 浏览量,64 收藏数) 预付费额度和单密钥模型访问描述成现实替代方案;@elbruno 也用 (7 点赞,2 条回复,505 浏览量,4 收藏数) 一个策略驱动的本地/云端路由运行框架说明了同一点。这不是愿景式想法,而是迫切的现实需求。机会:直接切入。

能跨会话延续的持久工作流记忆和结构

人们要的不只是更大的上下文窗口,而是能保住正确状态单元的工作流。@DanKornas 推广 (9 点赞,6 条回复,1,143 浏览量,5 收藏数) Maestro,把它当成记忆、审计和工作流层,但最强的那条回复立刻追问:怎样才能不让记忆过时。@DanKornas 也分享了 (20 点赞,5 条回复,1,737 浏览量,25 收藏数) AI Workflow,正是因为新的会话否则就会从零开始;而 @khanUmarCodes 表示 (3 条回复,58 浏览量),真正的解锁点,是在动手前强制经过澄清、PRD、issues 和可测试切片。这是一个正在被积极尝试、但还没有定型默认方案的直接产品缺口。机会:直接切入。

跨设备和工作树的多智能体指挥中枢

最强的监督诉求,是在工作变成异步、多智能体之后,需要更好的操作员界面。@DanKornas 分享了 (24 点赞,6 条回复,1,834 浏览量,18 收藏数) multi-agent-shogun,因为难的是协调,不是调用。@DanKornas 展示了 (8 点赞,3 条回复,1,522 浏览量,7 收藏数) Happier 这种跨设备续接方案;@YoussefHosni951 则把 (3 点赞,3 条回复,97 浏览量) Orca 定位成一个能从单一界面比较多个隔离工作树智能体的办法。这是一个已经出现多种新答案、但还没有主导标准的现实需求。机会:竞争型。

更安全的浏览器智能体,以及人们真正敢信任的审批流程

围绕 Web 智能体的帖子,把缺失的需求讲得格外具体。Alibaba 的 Page Agent 已经在宣传关键操作前的人类确认;但 @TakSec 展示了 (11 点赞,1 条回复,1,274 浏览量,8 收藏数),如果智能体把操作误描述成无害的调试 token,用户批准这一步依然会失效。这是一个现实的安全需求,策略系统、扫描器和 UI 层缓解措施都在清楚竞争;但核心工具仍给更强的原生方案留出了空间。机会:竞争型。


4. 使用中的工具与方法

工具 类别 评价 优势 局限
GitHub Copilot CLI custom agents CLI 工作流层 (+) 仓库定义的角色、工具和安全护栏,适合可重复的终端工作 回复质疑,单靠 Markdown 安全护栏是否足以应对高风险的真实运行
9Router 路由代理 (+/-) 自动回退、配额跟踪、token 压缩、为多种编程客户端提供统一入口 又多了一层需要调试的控制平面,也可能把提供商切换隐藏在单一界面后面
Inference.net 多模型 API / credits (+/-) 一个密钥、预付起始额度、前沿模型访问、兼容 OpenAI 的客户端 需要支付卡,而且大模型会很快吃掉起始余额
AI Workflow 技能包 / 工作流包 (+) 170+ 个可安装技能、领域包、广泛的助手支持 属于外部策展层,而不是原生产品默认配置
multi-agent-shogun 智能体编排 (+) 可见的 tmux 窗格、并行执行者、YAML 协调、可版本化的交接 它试图驯服的,仍然主要是协调开销
Maestro 工作流和记忆层 (+) 命令、反模式指导、持久记忆、审计轨迹、MCP 服务器 读者立刻质疑记忆是否能保持新鲜,以及它是否和内置功能重叠
Happier 会话伴侣 / 控制界面 (+) 跨设备续接、回放与分叉、加密会话访问 它解决的是连续性和控制,不是模型本身的核心质量
Orca 并行智能体 ADE (+) 隔离的 git 工作树、移动端伴侣、设计模式、diff 标注 需要单独的环境,以及多个底层智能体订阅
Page Agent 浏览器智能体 (+/-) 一行集成、DOM 原生控制、可选的 MCP 和扩展支持 依赖 DOM 是否干净,而且会把页面上下文发给配置好的模型
CopilotHarness 路由方法 (+) 尽量本地优先的模型选择,可在 Ollama、Foundry Local 和云端模型之间切换 仍处于早期阶段,更像架构模式而不是主流默认方案
OpenCode + 开放权重模型 低成本编程栈 (+) 任务先澄清并细致切片时,适合快速、低成本地跑日常工作 一旦请求含糊,或工作流容许漂移,就容易失效

整体模式是叠加组合,而不是替换。@VaibhavSisinty 展示了 (71 点赞,10 条回复,7,614 浏览量,142 收藏数) 一层叠在现有编程工具之上的路由层;@StudentOffersHQ 推广了 (61 点赞,3 条回复,3,330 浏览量,64 收藏数) 用一个密钥访问多个模型家族;而 @khanUmarCodes 则认为 (3 条回复,58 浏览量),只有当工作流更严格时,便宜的开放权重模型才真正可靠。在工作流这一侧,@DanKornas (20 点赞,5 条回复,1,737 浏览量,25 收藏数) AI Workflow 来打包可复用技能,分享了 (9 点赞,6 条回复,1,143 浏览量,5 收藏数) 用于记忆和命令的 Maestro,又 提到了 (8 点赞,3 条回复,1,522 浏览量,7 收藏数) 用于会话连续性的 Happier。迁移压力朝两个方向都很明显:高价智能体仍在处理架构、审查和更难的推理,而路由层和更便宜的模型则被推向批量执行和长时间运行的工作。

@elbruno 发布了 (7 点赞,2 条回复,505 浏览量,4 收藏数) 一个展示同样逻辑的 CopilotHarness 示例:能本地就本地,必要时才上云,并且由策略而不是习惯决定路由。

示意图展示 GitHub Copilot 如何在 Aspire 的调度下,按任务路由到 Ollama、Microsoft Foundry Local 或 Microsoft Foundry cloud


5. 人们在构建什么

项目 构建者 功能 解决的问题 技术栈 阶段 链接
GitHub Copilot CLI 中的自定义智能体 @github 用 Markdown 定义带明确工具和安全护栏的可复用终端智能体 重复跑相同的 CLI 工作流,并反复解释团队上下文 Markdown 智能体配置、YAML frontmatter、GitHub Copilot CLI 已发布 推文, 博客
9Router @VaibhavSisinty 提到了 decolua 的项目 在多个提供商之间为编程工具做路由,并带有回退、配额跟踪和 token 压缩 会话上限、手动切换提供商,以及被浪费的配额 JavaScript 代理、兼容 OpenAI 的端点、OAuth/API-key 提供商 已发布 推文, 仓库
Page Agent @israfill 提到了 Alibaba 的项目 直接在网页内部嵌入一个自然语言 GUI 智能体 缺乏 API 的旧式或内部 Web UI,或只需要比无头技术栈更轻的自动化 TypeScript、页内 JavaScript、可选浏览器扩展、MCP 服务器 已发布 推文, 仓库
AI Workflow @DanKornas 提到了 nicepkg 的项目 在多个助手之间安装可复用的工作流和技能包 每次会话都从零开始,并反复重教领域规则 SKILL.md 工作流包、npx add-skill、跨工具技能目录 已发布 推文, 仓库
multi-agent-shogun @DanKornas 在可见的终端层级下并行运行多个编程智能体 协调多个智能体时容易丢失状态、任务或报告 Shell、tmux、YAML 协调文件、Memory MCP 测试版 推文, 仓库
Happier @DanKornas 在手机、Web、桌面和终端之间续接、控制并回放编程智能体会话 智能体会被困在启动它的那台机器上 TypeScript、移动端/Web/桌面客户端、端到端加密 测试版 推文, 仓库
Maestro @DanKornas 给 AI 编程工具增加工作流命令、参考资料、记忆和审计 会话失忆、流程不一致,以及重复犯工作流错误 TypeScript、技能、MCP 服务器、JSONL 审计与记忆文件 测试版 推文, 仓库
Orca @YoussefHosni951 提到了 StablyAI 的项目 把一个任务分发到隔离的工作树里,并让用户并排比较智能体输出 多个智能体同时运行时的合并混乱和上下文切换 TypeScript、git 工作树、移动端伴侣、嵌入式 Chromium 工具 已发布 推文, 仓库
ArcKit @DanKornas 把企业架构与保障流程封装成可复用的命令、智能体和模板 架构治理散落在彼此割裂的文档里,而不是可复用工作流中 JavaScript 工具包、命令、模板、钩子、治理叠加层 测试版 推文, 仓库

几个更大的项目,都指向同一种构建模式:新的产品层不再是“更聪明的模型”,而是“围绕模型搭得更好的一层”。@VaibhavSisinty (71 点赞,10 条回复,7,614 浏览量,142 收藏数) 9Router 当作回退和配额路由的控制平面;@YoussefHosni951 则把 (3 点赞,3 条回复,97 浏览量) Orca 定位成一个能让多个智能体在隔离工作树中运行、并集中审查的地方。@DanKornas 分享了 (9 点赞,6 条回复,1,143 浏览量,5 收藏数) 用于记忆和可复用命令的 Maestro,又 @DanKornas 分享了 (8 点赞,3 条回复,1,522 浏览量,7 收藏数) 用于跨设备控制的 Happier。

反复触发这些构建的,并不是原始模型智能不够。真正的问题是连续性丢失、路由不透明、监督薄弱,以及太多工作流被困在一段超长对话里。这个模式也解释了更专门的构建:面向内部 Web UI 的 Page Agent、面向架构治理的 ArcKit,以及面向领域技能包的 AI Workflow。


6. 新动态与亮点

同一模型下的运行框架增益,在公开网络安全基准中被量化

@PhiloGroves 提到 (2 条回复,109 浏览量) 腾讯 Xuanwu Atuin AI 在 CyberGym Level 1 上的结果:GLM-5.1 的 pass@1 达到 84.0%,而文中引用的 Claude Code 环境下 GLM-5.1 基线为 68.7%。文章写得很明确:这部分提升来自管理者/子智能体编排、SOP 遵循、可复用的网络安全技能、TODO 跟踪以及工作流钩子,而不是更换底层模型。

劳动力市场图表,让初级程序员的挤压更难被忽视

@OwenGregorian 认为 (13 点赞,4 条回复,2,996 浏览量,4 收藏数),AI 对初级编程岗位的冲击,比对资深群体更重,附带图表才是关键证据。一张图显示,美国软件开发者就业按年龄分布时,22–25 岁这一组较峰值下降 19%,而更年长的组别继续上升;另一张图则显示,程序员和 Web 开发者这些职位名称在下降,而软件开发者和数据科学家仍保持正增长。

美国软件开发者就业年龄分布图,显示 22 至 25 岁组较峰值下降 19%,而更年长组别继续上升

按职业划分的图表,显示程序员和 Web 开发者的跌幅大于更广义的软件开发者岗位

Skills 正从代码工作流扩散到设计系统打包

@tom_doerr 分享了 (3 点赞,2 条回复,2,172 浏览量,7 收藏数) awesome-design-skills,这是一个面向智能体工具、收录 67 个设计系统 skill 文件的注册表。它值得注意,不是因为互动量,而是因为它把当天“工作流打包”的趋势,从编码说明进一步扩展到了面向界面工作的成对 SKILL.mdDESIGN.md 产物。


7. 机会在哪里

[+++] 编程智能体的路由与配额控制平面 — 证据贯穿了第 1、2、3、4 节:9Router、Inference.net、CopilotHarness,以及基于开放权重模型的 OpenCode 工作流之所以存在,是因为用户仍然需要一种按配额、价格和任务来做可视化路由的方式。这个机会很强,因为人们已经在用独立路由器和预付费钱包,只为让工作连续跑下去。

[++] 工作流记忆 + 结构化任务拆解 — AI Workflow、Maestro、闭环工程讨论串,以及 Umar Khan 的澄清 -> PRD -> issues -> 可测试切片工作流,都指向同一个缺口。用户想要的是:智能体记住该记住的事、主动提出澄清问题,并且在不漂移、不走向过度工程化的前提下,让工作能够跨会话保持可审查性。

[++] 跨工作树和设备的多智能体指挥中枢 — multi-agent-shogun、Happier 和 Orca 都在解决监督问题,而不是模型问题。这个机会属于中等偏强,因为痛点非常具体,但现在已经出现了多个早期答案,分别在 shell、桌面和移动端界面上竞争。

[++] 浏览器与终端智能体的安全护栏 — ODIN 对 Antigravity 的利用,以及进攻性安全智能体框架的增长,都说明浏览器 + 终端智能体已经需要更强的审批、策略和审计层。这个机会属于中等,因为构建者已经意识到它,但核心产品仍留有很大缺口。

[+] 面向专家工作的领域专用工作流包 — ArcKit、awesome-design-skills,以及那套算术代数几何工作流,暗示出一层更新的机会:服务于架构、设计系统、数学核验和其他专家领域的专用打包方案。这个信号还在浮现,但这些例子已经比泛泛的“垂直 AI” 空谈具体得多。


8. 要点总结

  1. 工作流层扩张的速度,仍比模型叙事更快。 GitHub 自定义智能体、AI Workflow、multi-agent-shogun、Maestro、Happier 和 Orca 都把编程质量视为封装、记忆和监督问题,而不是原始模型选型问题。 (来源)
  2. 规避配额,如今已经自成一个产品类别。 9Router、Inference.net、CopilotHarness,以及更便宜的 OpenCode 工作流,都在帮助会话跨越限额、预付费额度和本地/云端分流继续运行。 (来源)
  3. 只有当工作流更严格时,人们才越来越愿意信任便宜模型。 当天最强的低成本成功案例,都把开放权重模型或混合模型队列,与澄清、PRD、issue 切分和显式验证循环绑在一起。 (来源)
  4. 具备浏览器能力的智能体,仍然同时强大又危险。 Page Agent 展示了轻量浏览器辅助助手正变得多容易接入;而 ODIN 对 Antigravity 的利用,则说明同一套浏览器 + 终端界面也能被用来外传密钥。 (来源)
  5. 围绕运行框架与模型的争论,拿到了更强的证据。 腾讯的 CyberGym 文章指出,同一个 GLM-5.1 模型在更专项的多智能体工作流下能取得明显更好的结果,这进一步强化了整个信息流正在从模型本身转向闭环设计与编排。 (来源)