# Claude Code 动态工作流与 GitHub Copilot 桌面应用发布 - 来源：ginobefun (@hongming731) - 发布时间：2026-06-03 07:08 - AIHOT 分数：70 - AIHOT 链接：https://aihot.virxact.com/items/cmpxastn1026uslckvkbw6al6 - 原文链接：https://x.com/hongming731/status/2061948002672287785 ## AI 摘要 Anthropic 为 Claude Code 推出动态工作流，允许模型为每个任务自主生成 JavaScript 编排脚本，动态选择模型并启动多个子智能体在独立环境中并行执行，以解决单一上下文窗口处理复杂任务的限制。同时，GitHub 在 Microsoft Build 上发布了以智能体为核心的 Copilot 桌面应用，提供统一视图、协作面板和自动化流程，旨在管理并行 Agent 开发。文章披露，GitHub 平台每月提交量已突破 14 亿次。 ## 正文 http://x.com/i/article/2061947122350751744 # BestBlogs 早报 · 06-03|动态工作流、Copilot 桌面、AI 工程范式 在线阅读和收听：https://www.bestblogs.dev/explore/brief/2026-06-03 > EP76 · 2026-06-03 - AI 工程的范式正在被重写：Claude Code 突破单一上下文窗口、为每个任务动态生成编排脚本，GitHub Copilot 以智能体为核心推出桌面控制中心，提交量已突破 14 亿次/月。与此同时，腾讯云工程师从控制论视角论证，大模型是史上首个「认知引擎」，软件工程师的核心职责正在从「写代码」升级为「设计能自我纠偏的 AI 系统」。本期还涵盖任务保真度缩放定律、MiniMax M3 开源模型、NVIDIA Cosmos 3 及机器人供应链深度拆解，一并呈现这场变革的全貌。 ## 导语 今天是 2026 年 6 月 3 日，AI 工具链的底层逻辑正在发生一次结构性升级。 Anthropic 正式推出 Claude Code 动态工作流：Claude 不再只能在单一上下文窗口里规划并执行，而是能即时为每个任务生成一套专属的 JavaScript 编排脚本，自主决定要启动多少个子智能体、使用哪种模型、是否在独立的 worktree 里隔离运行。触发词只需一个：ultracode。 与此同时，GitHub 在 Microsoft Build 上发布了 Copilot 桌面应用--一个为并行 Agent 开发打造的统一控制中心。My Work 视图让你同时监管多条进行中的 Issue 和 PR，Canvas 面板实时显示 Agent 的工作进度，Agent Merge 全程处理 CI 和代码审查。在所有这些工具铺开的背景下，GitHub 的每月提交量已经突破 14 亿次，同比翻倍。 本期精讲之外还有 7 篇速览，覆盖任务保真度缩放定律、AI 原生工程组织打造、MiniMax M3 开源模型、NVIDIA Cosmos 3、机器人供应链深度拆解、Agent 存算分离架构，以及贴吧 AI CR 落地 10 周后 bug 密度下降 66.87% 的完整实践。 本期精讲三篇： - 精讲一：Anthropic 详解 Claude Code 动态工作流的工作原理与最佳实践 - 精讲二：GitHub 在 Microsoft Build 上推出以智能体为核心的 Copilot 桌面应用 - 精讲三：腾讯云工程师以控制论框架重新审视软件工程五十年与 AI 范式革命 ## 精讲一：为每项任务量身打造：Claude Code 中的动态工作流 | Claude Claude Code 面向的任务场景越来越复杂，但默认 harness 有一个固有限制：规划和执行必须在同一个上下文窗口里完成。随着任务变长、结构变复杂，这个窗口会越来越拥挤，开始出现「智能体懒惰」--Claude 开始抄近路；「目标漂移」--Claude 偏离了最初的任务目标。上周，Anthropic 发布了动态工作流（Dynamic Workflows），为这个问题提供了根本性的解法。 动态工作流的工作原理 动态工作流的核心是让 Claude 自己写一个 JavaScript 编排脚本，然后执行这个脚本来完成任务。这个脚本可以使用几个特殊函数来生成和协调子智能体（subagents），同时也可以调用标准的 JavaScript 工具：JSON、Math、Array 等。 与静态工作流的关键区别在于两点。首先，动态工作流可以自主决定给每个子智能体使用哪个模型--这意味着 Claude 会把复杂的推理任务分配给更强的模型，把简单的信息采集交给更快的模型，在成本与质量之间动态权衡。其次，子智能体可以在独立的 worktree 里运行，实现真正的环境隔离，避免多个子任务互相污染工作状态。 如果工作流被用户中断（比如关掉了终端），恢复会话后工作流可以从中断点继续，不需要从头再来。 它解决了哪些具体的失败模式 Anthropic 在文章里明确列出了动态工作流针对的几类失败场景： - 长任务的上下文污染：单一窗口处理长任务时，早期的规划信息和后期的执行信息混在一起，Claude 开始迷失方向。 - 大规模并行任务：比如同时处理 80 份简历评级、同时从多个 Slack 频道抓取数据--这类任务天然适合多路并发，但默认 harness 无法原生支持。 - 高度结构化任务：比如让多个 Agent 分别扮演投资人、用户、竞争对手，从不同角度撕碎一份商业计划书。 - 对抗性任务：让两个子智能体互相挑战，形成一种反馈机制来提升结果质量。 文章给出的几个示例 prompt 很有启发性：「这个测试大约每 50 次运行就会失败一次，用工作流来复现它，提出竞争性假设，不到找到能存活于证据的那个假设不要停」；「拿我最近 50 个会话挖出我反复在纠正的错误，把那些反复出现的写进 CLAUDE.md 规则」。这两个例子都展示了动态工作流的典型场景：需要反复迭代、需要并行比较、或者需要结构化协作的复杂多步任务。 常见的工作流模式 Anthropic 总结了 Claude 在构建工作流时会组合使用的几种基本模式： - 分类执行（Classify-and-act）：先用一个 Agent 对输入进行分类，再把不同类别的任务分配给专门的下游 Agent。 - 排序（Sorting）：把大批量列表（比如 1000 条支持工单）按定性标准排序--单次 prompt 质量会随列表变大而退化，工作流可以分批处理再汇总。 - 竞争性验证（Adversarial check）：让一个 Agent 生成，另一个 Agent 专门找漏洞，循环直到结论站得住脚。 使用建议 动态工作流会消耗更多 token，不适合日常简单任务。最适合的场景是：任务足够复杂（单一上下文处理时质量会退化）、任务足够高价值（额外的 token 成本值得付出）、任务有结构化并行需求（多个角度、多个数据源、多个竞争性假设）。触发方式是在 prompt 里使用关键词 ultracode，或者明确要求「用工作流来完成这件事」。Anthropic 提醒，最佳实践仍在演进，建议首次使用时从相对简单的并行任务开始积累直觉，再逐步应用到更复杂的高价值场景。动态工作流与默认 harness 完全兼容，不需要时可以无缝回退，无需额外配置。 对于正在用 Claude Code 处理复杂多步骤任务的工程师，这篇官方介绍值得仔细阅读：查看原文 ## 精讲二：GitHub Copilot 应用：以智能体为核心的桌面体验 当 Agent 变成开发工作流的常态，管理多个并行 Agent 本身就成了一个新问题。你早上打开电脑，三件工作已经在推进中：一个 Agent 在排查生产 bug，一个 Agent 在实现积压需求，第三个 Agent 在处理代码审查反馈。你需要一个地方能同时看到这三个进度，能介入、能重定向、能测试、能合并。原有的开发工具并不是为这种工作方式设计的。 在 Microsoft Build 2026 上，GitHub 发布了 Copilot 桌面应用，正是要填补这个空缺。 My Work：统一管理所有进行中的工作 Copilot 桌面应用的核心入口是 My Work 视图。这个视图汇聚了所有关联仓库里当前进行中的工作：活跃的 Agent 会话、Issue、PR、后台自动化任务。开发者不再需要在多个标签页之间切换来追踪不同 Agent 的状态，一个视图看全局。 worktree 隔离：Agent 会话互不干扰 每一个 Agent 会话都在独立的 git worktree 环境里运行。这与 Claude Code 动态工作流的设计理念高度一致：隔离是并行 Agent 开发的基础--不同 Agent 的工作状态不会互相污染，合并时也有清晰的边界。 Canvas：双向协作面板 Canvas 是一个可视化的双向协作区域。Agent 工作时，你可以在 Canvas 里实时看到它的工作进度，也可以在任何节点插入反馈、调整方向。这种「异步介入」的交互模式与传统的「等待 Agent 完成再审查」不同，更像是一个真实存在的协作伙伴，只是它在你后台异步跑，你随时可以看进度并给意见。 Agent Merge：全程自动化 CI 和代码审查 Agent Merge 功能负责管理从 Agent 提交代码到合并的整个流程，包括触发 CI 检查、处理代码审查反馈、最终完成合并。开发者的精力可以更多集中在方向判断和质量审核，而不是流程管理。 Copilot 代码审查的定制化扩展 与此同时，GitHub 还扩展了 Copilot 代码审查的能力：开发者现在可以通过自定义 Agent skills、MCP 服务器连接和可配置的 Actions 工作流，让每次代码审查都反映自己团队的标准、内部系统和工程上下文。代码审查还新增了「中等层级审查」（medium tier review）选项，在快速审查和深度审查之间提供了更细粒度的控制。 规模背景：14 亿次提交/月 GitHub 在发布中披露了一组数据：当前平台的每月提交量已经突破 14 亿次，同比近乎翻倍；GitHub Actions 每周运行时间超过 20 亿分钟。这个增速直接说明了为什么 GitHub 要在这个时间点推出 Agent 原生的控制中心--现有工具的设计假设已经跟不上实际工作流的演进节奏。 对于正在将多个 Copilot Agent 整合进开发工作流的团队，这篇发布文章是了解 GitHub Agent 原生方向的第一手资料。Copilot 桌面应用目前已向现有 Copilot Pro、Pro+、Business 和 Enterprise 用户开放技术预览，感兴趣的团队可以直接申请加入：查看原文 ## 精讲三：AI 软件工程范式革命的思考 这篇来自腾讯云开发者的长文，是近期读到的关于 AI 与软件工程关系最系统、最有历史纵深的一篇思考。作者不是在讨论某个工具或某个技巧，而是从工程史的视角，对软件工程过去五十年的本质做出了一次重新定性。 软件工程是过去五十年最不彻底的工程 作者从控制论的视角，梳理了经典工程门类的成功路径：机械、化工、电力、自动化，这些领域都靠同一个范式完成了工程化--「消耗能源，把人脑参与的低阶认知回路固化成物理装置」。蒸汽机的离心调速器、化工厂的恒温器、电网的调度装置，本质上都是同一件事：让原本需要人来盯着、调整、判断的事情，由一台烧煤或通电的设备自己完成。不确定性被大规模消除，同样的输入产出稳定可预期的结果。 软件工程卡在了这条路上。软件开发要处理的是抽象、分解、推理、创造--这些是高阶认知，没法像调速器那样固化成物理回路。五十年来，敏捷、Scrum、DevOps 解决的都是同一个问题，用的是同一种方式：优化堆人力的方式，但没有改变「必须靠人力堆」这个事实。 这就是作者对「软件工程是最不彻底的工程」的定义：它在工程的形而上学层面是个残缺品--所有兄弟门类都完成了「能源替代低阶智能」这个动作，唯独软件没有。 大模型是史上第一个「认知引擎」 大语言模型做到了经典工程从来没做到的事：输入算力，输出能理解需求、生成代码、做逻辑推理的高阶认知产物。 放到工程史的坐标里： - 经典工程：能源 → 低阶智能（机械调节、自动控制） - 大模型：能源 → 高阶智能（理解、推理、生成、决策） 作者的判断是：大模型和蒸汽机的工程史地位是平行的。蒸汽机让「做功」第一次能源化，大模型让「认知」第一次能源化。软件工程「真正降临」的时刻，不是 Scrum 流行的时候，不是 DevOps 普及的时候，而是大模型让「能源换高阶智能」成为可能的这个时刻。在此之前所有的「软件工程」，严格说都是软件作坊的优化版。 但这只是入场券，不是终局 大模型带来了新的不确定性：幻觉（输出看起来合理，悄悄就错了）、漂移（同样的输入，今天和明天给出不一样的结果）、不可解释（没法看进它的决策过程）。 这意味着大模型并没有消除不确定性，只是把「人的不确定性」换成了「模型的不确定性」。真正需要的是一整套新的工程原则--不再是「亲手消除每个微小的偏差」，而是「设计一个能自我纠偏的系统，并处理系统自己纠不回来的剩余偏差」。 作者引入了冯·福斯特 1970 年代提出的二阶控制论：一阶控制论是「观察并控制被控对象」，二阶控制论是「观察并控制『观察并控制』这件事本身」。投射到 AI 软件工程： - 经典软件工程：人在写代码 - AI 软件工程：人在设计「AI 写代码的系统」 这是身份的转变，不只是工具的转变。 自动化越彻底，工业相关人口反而越多 作者用一组跨越 150 年的数据指出：自动化越彻底，工业相关人口反而越多。1850 年代蒸汽机普及后，制造业整体爆炸式增长；1950 年代自动化后，工程师、设计师、工艺员数量暴增。每一次系统能力扩张，都会暴露出新的边界，而边界就是新的「偏差地带」，需要新一波人守在那里。 结论：人不是被淘汰，而是迁移。边界在扩大，需要守的人反而更多了。但能在这种边界上工作的人会越来越少，因为形式化吃掉的都是低阶认知，剩下的都是越来越高阶的部分。 与今日其他精讲的关系 这篇文章与精讲一、精讲二形成了很好的理论基础互补。Claude Code 动态工作流和 GitHub Copilot 桌面应用，都是「设计能自我纠偏的 AI 系统」这个新工程原则在工具层的具体体现--worktree 隔离、子智能体协作、Canvas 双向介入，都在解决「如何设计系统来处理 AI 自身的不确定性」这个核心问题。 对工程师意味着什么 作者给出了一个相对乐观但也相当严峻的判断：AI 时代，人的统一职能是「处理系统暂时还无法处理的偏差」。这条铁律在所有工程门类里都成立--机械故障靠人拉回、电网负载偏差靠人仲裁，现在是认知偏差靠人纠正。 不同的是，AI 工程里，偏差类型不再可枚举，偏差信号不再可观测，拉回手段也没有 SOP 可循。这意味着守边界的人，需要更强的判断力，而不只是更多的知识。 作者在文章末尾讨论了组织形态和落地路线，以及他认为这场变革「最难的那道坎」在哪里，这部分值得有 AI 落地任务的工程师和技术管理者仔细阅读：查看原文 ## 速览 1. 任务保真度缩放定律：为什么数据质量决定 Agent 性能（AI Engineer） Snorkel 的实验证明：在相同算力和任务数量下，仅改变训练数据质量，高保真任务带来 6% 的性能提升，低质量任务只有 1%，差距高达 5 倍。高质量任务须满足四项标准：容器化（隔离干净的回滚和并行化）、可达性（目标非平凡但可实现）、功能正确性（逻辑可预期）、环境稳定性（执行基础设施稳定）。满足这四项才能产生干净的失败信号，让模型在 RL 训练中有效爬坡。低质量任务的常见缺陷是「退化失败态」：环境本身就不稳定，模型无法从失败中提取有意义的学习信号，额外的计算预算全部浪费在噪声上。对正在做 Agent 微调数据集的工程师，这组数据有直接的策略指导价值。查看原文 2. 打造 AI 原生工程组织 | Claude（Claude Blog） Claude Code 团队分享了他们如何重新设计工程流程以适应 AI 原生工作方式。代码生成、测试编写和重构已经不再是瓶颈，真正的瓶颈变成了验证、代码审查和安全评估。他们重写了规划方式（从长期路线图改为即时制订）、代码审查流程、上下文收集方式，以及团队的构成逻辑。这不是工具使用指南，而是一个已经完全转型的工程组织对「如何重新设计流程」的第一手记录，适合正在思考 AI 原生团队转型的工程 Leader 阅读。查看原文 3. MiniMax M3：首个融合三大前沿能力的开源权重模型（MiniMax 官方） MiniMax 正式发布 M3，声称是首个同时融合三大前沿能力的开源权重模型：编码与智能体性能（SWE-Bench Pro 59.0%、Terminal Bench 2.1 66.0%）、由 MiniMax 稀疏注意力（MSA）实现的 100 万 token 上下文窗口、从零构建的原生多模态能力。同期推出 MiniMax Code 产品和新的 token 计划。权重和技术报告将在约 10 天内发布。值得注意的是，M3 是国内团队在开源大模型赛道上迄今为止对标 GPT 4o 级编码能力的最完整尝试之一，对关注开源模型生态的开发者值得持续跟进。查看原文 4. NVIDIA 推出 Cosmos 3：用于物理 AI 的完全开放全能模型（NVIDIA AI） NVIDIA 发布 Cosmos 3，定位为世界上首个完全开放的、用于物理 AI 的「全能模型」（omnimodel），原生支持视觉推理、世界生成和动作生成三种能力。本次发布了两个版本：Super（32B）和 Nano（8B），面向机器人和自主系统领域。结合精讲三和速览第五条的机器人供应链分析，物理 AI 的基础模型层正在加速成熟。查看原文 5. 拆解机器人「肉身」、量产与供应链：空翻之后，它还要学会接住一片落叶（硅谷 101） 硅谷 101 深度拆解人形机器人的硬件架构：骨架材料（从钢材到铝合金、镁合金、钛合金的演进与轻量化权衡）、关节执行器（从液压到电机转变的背后技术进步）、传感器体系、电气与计算系统，以及整条供应链的成本结构与量产门槛。文章还引用了智元、宇树等头部企业一线负责人的具体判断。宇树科技科创板 IPO 刚刚通过上交所审议，这篇系统性拆解正当其时，适合想深入了解机器人硬件护城河的读者。查看原文 6. 深度解析 Agent 存算分离架构设计（idoubi） 作者以 FastClaw 为例，系统拆解云端 Agent 的存算分离架构：三种运行模式（本地裸机、本地带沙盒、云端多副本）的优缺点对比，存储层的四种方案（热状态用 Redis、对话记录用 Postgres、长期记忆用 pgvector/Milvus、工作产物用 S3/OSS），以及基于存算分离架构的完整运行流程，同时指出了分布式数据一致性的挑战。对比今日精讲一中 Claude Code 动态工作流的 worktree 隔离机制，两篇在「计算与状态分离」这个方向上有一定共鸣，对正在设计云端 Agent 基础设施的工程师有直接参考价值。查看原文 7. 用数据说话：贴吧 AI CR（小码哥）落地 10 周，bug 密度下降 66.87%（百度 Geek 说） 贴吧 Server 团队的 AI Code Review 落地实践：通过规则定制、自动化评测和三层反馈闭环（高/中/低优先级评论处理流程），将 AI CR 评审占比从 33% 提升至 84%，bug 密度从 0.332 降至 0.11，降幅 66.87%。文章完整记录了 10 周的推进节奏、踩坑经验和方法论，代码库多、提交频率高、人工评审质量参差的团队可直接参考迁移。这份实践与精讲三的理论框架形成印证--AI CR 本身就是一个能自我纠偏的代码质量系统。查看原文 ## 今日阅读路径 时间有限，建议先读这三篇： 1. 为每项任务量身打造：Claude Code 中的动态工作流（精讲一）- 如果你在用 Claude Code，这是今天最直接有用的一篇，10 分钟读完，了解动态工作流的工作原理和触发方式，以及哪类任务最值得启用。 1. AI 软件工程范式革命的思考（精讲三）- 今天内容最有长期价值的一篇。控制论框架下的软件工程史重构，以及「设计能自我纠偏的 AI 系统」这个新工程师身份定位，是理解当前所有 AI 工具演进方向的底层框架。 1. GitHub Copilot 应用：以智能体为核心的桌面体验（精讲二）- 并行 Agent 开发控制中心的完整介绍，了解 GitHub 在 Agent 原生方向的系统性布局，以及 worktree 隔离、Canvas 协作、Agent Merge 这几个核心机制的实际用法。 还有时间？ 推荐任务保真度缩放定律（做 Agent 微调数据集的工程师必读，5 倍质量差距有直接策略价值）和机器人供应链深度拆解（宇树 IPO 时机下的硬件架构系统梳理，适合关注具身智能落地的读者）。