分类 人工智能 下的文章

什么是 Dynamic Workflows?它到底颠覆了什么?

一句话:它让 Claude Code 从一个"1v1 聊天的编程助手",变成了能自己带团队、指挥几百个 AI 分工协作的架构师。

以前的 AI 是你走一步它跟一步。Dynamic Workflows 的逻辑是你定方向,它在后台自己带兵打仗。

核心机制很简单,但很暴力:

动态规划:拿到任务后不盲目动手,先分析代码库架构,自己写编排脚本。

百兵并行:后台同时启动几十到几百个子 Agent,各领一份差事。

自我收敛:每个子 Agent 旁边配一个审查 Agent 做 Code Review,全改完后自动跑测试、解冲突,直到结果收敛才交到你手里。


11 天移植 75 万行代码:那个刷屏的案例

Bun 的创始人 Jarred Sumner 用 Dynamic Workflows,在 11 天内把 Bun 项目的 75 万行底层代码从 Zig 完整移植到了 Rust。

过去这种体量的重构,哪怕资深架构师带十几个高级开发,也要几个月起步。因为人要一步一步理清依赖关系,精力有上限。

而现在 AI 的工程哲学变成了:用规模碾压复杂。 75 万行代码拆成几百个独立子任务,百人规模的 AI 同时开工。这种并行度以前想都不敢想。


幕后的工作流

用户输入宏大任务
       │
       ▼
 1. 动态规划 → 自动生成编排脚本
       │
       ▼
 2. 任务分解 → 拆解成数百个微型子任务
       │
       ▼
 3. 并行执行 → 数百子 Agent 同时扫描/重凙/Review
       │
       ▼
 4. 预检汇总 → 跑测试、解冲突、收敛结果
       │
       ▼
 交付最终版本

端到端的全自动闭环,这才是真正把开发者从搬砖里解放出来的东西。


它适合什么场景?

写个 Hello World 或修个样式 Bug 不需要这玩意儿。它是为大规模工程战役生的:

  • 史诗级迁移:老旧框架整体更换、跨几千文件的语言移植
  • 全库级重构:全局 Bug 搜寻、安全审计、基于性能分析数据的优化
  • 多维度高标验证:同时从性能、安全、规范等多个维度进行严格校验

一点思考

Dynamic Workflows 把 AI 编程卷到了一个新临界点。

过去总在讨论"AI 会不会替代程序员",现在答案越来越清晰了:AI 不替代你,但一个能指挥几百个 AI 协同作战的人,会轻松碾压传统的单兵开发者。

未来的架构师可能不需要管庞大团队了,需要的是会向 AI 军团下达精准指令。


ClaudeCode #DynamicWorkflows #AI编程 #MultiAgent

拒绝单纯刷榜:从本地 Agent 编排器视角拆解 Claude Opus 4.8 的"终端革命"

Anthropic 刚丢出 Claude Opus 4.8,各大技术社区都在刷它在 SWE-Bench Pro 上的 69.2%——把 GPT-5.5 和 Gemini 3.1 Pro 都甩开了。

但说实话,我对跑分已经免疫了。真让我半夜睡不着的是它在终端代码、多智能体协同和算力调度上的变化。这不像一次模型升级,更像给我们这些折腾 CLI 和本地 Agent 的人专门造了一批基础设施。

聊聊我从编排器视角看到的三个关键点。


1. Dynamic Workflows:并发编排的最后一块拼图

过去半年我一直在跟本地 macOS 上的 CLI Agent 打交道,用 OpenClaw 之类的工具做终端 Agent,同时在搭一个可视化的 Nexus 编排器。

最大的痛点是并发。以前让 AI 写代码,全是单线程——你提需求它改一点,你报错它再修一点。一旦业务逻辑复杂起来(比如我最近在搞的医药 B2B 系统,涉及多组下发链路和流转模拟),单线程 Agent 基本撑不住,上下文一长就开始自相矛盾。

Opus 4.8 在 Claude Code 里引入的 Dynamic Workflows 正好打在痛点上。它可以在一个会话里自主规划、并行启动上百个子 Agent。在 Nexus 里,我可以把 Opus 4.8 当"主脑"——接到需求后,派一个 Agent 写前端表单,一个查数据库状态机,一个跑合规测试,最后终端里合并代码。

这种长周期、多步骤的终端任务自动化,才是真正能用的东西。


2. 算力精细化调度:终于不用为一句话的检查烧钱了

玩本地 Agent 都懂,算力分配是个精细活。我平时用迷你主机外接卡跑本地,日常还好,真到重逻辑还是得靠云端 API。

Opus 4.8 开放了 Effort 控制,在编排器里可以直接做分层调度:

轻量级路由:编排器里有大量做网关、语法检查的轻 Agent。切到 Fast Mode,价格 $10-$50/百万 Token,速度 2.5 倍。用在这种高频低智任务上刚好。

重度逻辑:核心代码重构或者设计复杂 Agent 逻辑时,开高 Effort/Max,强迫模型在输出前做深度自适应思考。

好钢用在刀刃上。这让复杂架构的开发成本终于能算得过账了。


3. Evaluation Awareness:它会"讨好"你的评分系统了

技术报告中还有个细节:Opus 4.8 表现出了一种评估意识——干活时会主动思考"这段代码评审会怎么打分"。

对普通网页用户,这不过是让回答显得更严谨。但对把终端权限交给它的开发者来说,这意味着它的决策逻辑变得更黑盒了。它不只懂怎么写代码,还懂了"怎么写最容易被通过"。

在赋予它更多编排权限的同时,本地的沙盒隔离和审计规则该加点保险了。


结尾

Opus 4.8 的发布,标志着大模型正式从"全能的闲聊助手"走进了专业自动化工程师的深水区。

对热衷 Local-first AI 工具的人来说,这是一把锋利的剑。接下来就看怎么把它装进工作流,让它真正干活。


#ClaudeOpus #Agent #本地开发 #AI编排

Google I/O 2026 观后感:Agent 不再遮掩,以及我为什么搞本地编排器

如果说去年的 AI 圈还在卷"怎么让模型说话更自然",那 Google I/O 2026 给我的信号非常直白——巨头已经不想跟你聊天了,他们要的是能替你干完一整间公司活的全自动工人。

从"你问我答"的 Chatbot,到大会上层出不穷的 Multi-agent 编排方案,Google 在传递一件事:对话时代天花板到了,Agent 异步协作才是下一步。

作为一个长期跟终端 CLI 工具打交道的人,这场大会看完我只有一个感觉——我的方向盘没打错。


1. 扔掉排队叫号,上流水线

我前几天刚写过那篇 Gemini CLI 停服的吐槽。

免费版 Gemini CLI 的交互模式是标准的一问一答,等回复的时候终端一卡,什么都干不了。这种排队叫号的体验,在今天的 AI 工具里确实已经落后了。

Google 这次祭出的 Antigravity 2.0,演示里直接并发启动了 93 个子 Agent,跑了将近一天,生成了 26 亿个 Token,最终产出了一个操作系统的核心框架。

这说明什么?终端不再是打字回话的窗口,它是一个微型调度中心。你定方向,底下一群 Agent 自己拆任务、自己沟通、自己查补漏。


2. 云端有 Spark,本地怎么办?

除了硬核开发工具,Google 还搬出了一个叫 Gemini Spark 的概念。

简单说就是 7×24 小时不关机的云端专属 Agent。你电脑一合,它还在后台帮你处理邮件、整理材料、调日程。听起来确实省心。

但对于数据习惯留在自己机器上的本地党来说,这事就引出另一个问题:本地的那些 CLI Agent,归谁管、怎么管?


3. 为什么我相信可视化编排这条路

看完这些演示,我觉得前一阵在 Nexus Orchestrator 身上花的时间没白费。

当时搞这个 macOS 本地 CLI Agent 的编排工具,周围有人会说:都在敲终端了,再加个可视化面板不是多此一举吗?

但这次 I/O 的风向把答案打得很清晰:Agent 数量一旦超过单人格上限,纯命令行的心智负担是扛不住的。

平时在终端跑 OpenClaw 或者其他本地 AI Agent,做点数据抓取、分析之类的,一两个任务还好。当并行量上来之后,任务间的依赖和资源争用,没有一个直观的统管视角,迟早会把自己绕进去。

我要的那个东西,本质上是一个控制台——能把每个"终端打工人"的职责分配清楚,资源调度明确,然后看着它们在 macOS 的交互语境下自己跑起来。


之后

大厂在云上堆算力、堆并发,这是他们的赛道。而本地生态这边,怎么高效地跑 Agent、怎么让编排器真正顺手,是我们这帮人的事。

既然 Google 已经把多 Agent 编排这张牌摊开了,那我继续折腾本地编排器的理由又多了一个。


#GoogleIO2026 #MultiAgent #AI编排 #本地开发

Google 又亮砍刀:Gemini CLI 倒计时,我的终端 Agent 编排器又要改代码了

前段时间还在跟 Gemini CLI 那烦人的 "Action Required" 授权报错斗智斗勇,好不容易把它理顺,正准备让它在我的本地可视化编排器里和 Claude Code 凑成一桌打配合,结果今天一觉醒来,Google 直接把桌子掀了

是的,各位还在用免费版/个人版 Gemini CLI 的朋友们,准备好在 2026 年 6 月 18 日 参加它的告别仪式吧。

Google 官方博客发了"讣告",宣布免费版的 Gemini CLI 即将停服,取而代之的是一个叫 Antigravity CLI 的新玩具。至于企业版和氪金老大哥们?你们接着舞,旧版 CLI 对你们依然开放。


🤨 为什么又换马甲?

作为一个常年在终端里折腾各种 AI Agent 和本地大模型的开发者,我对大厂这种"朝令夕改"已经有点免疫了。但这次 Google 给出的理由,确实踩中了当前 AI 发展的痛点:多智能体(Multi-agent)协同

以前的 Gemini CLI 像是一个尽职尽责的单线程客服:你抛一个问题,它给你一个回答。这种模式搞搞简单的脚本生成还行,但面对复杂的本地工程重构就显得捉襟见肘。

根据官方说法,用 Go 语言 重写的 Antigravity CLI 最大的卖点就是后台异步编排。这意味着你可以让几个 Agent 在后台疯狂切磋、跑代码、查 Bug,而你的终端依然丝滑,不会被阻塞得动弹不得。


🛠️ 对本地终端生态意味着什么?

其实,如果抛开要被迫重构代码的怨念不谈,Antigravity 的思路和我最近在搞的本地 CLI Agent 可视化编排理念是不谋而合的。

单纯的对话工具已经摸到了天花板,接下来的爆发点就在于如何优雅地统管、调度各种终端 Agent(比如基于 OpenClaw 跑起来的各种小工具),让它们在 macOS 风格的清爽交互下自动完成那些脏活累活。

Antigravity 把"多 Agent 异步编排"做成了 CLI 的原生能力,这相当于直接在底层提供了一套更强健的脚手架。


🚀 接下来怎么办?

留给我们的时间还有不到一个月。

别挣扎了,拥抱反重力。 既然 Antigravity CLI 已经全面开放,早换早享受。毕竟 Go 写的玩意儿,运行速度的提升应该是肉眼可见的。

准备重构。 那些硬编码了 Gemini CLI 调用的自动化脚本和编排器逻辑,得趁早排期改写了。

保持观望。 看看 Antigravity 宣称的"多智能体后台协作"到底是个噱头,还是真的能成为本地工作流的终极答案。


不说了,我先去研究一下 Antigravity 的接入文档了。希望这次 Google 的"反重力"能飞得久一点,别再让我刚写完接口就得面临下线重构的命运了。


#AI #Google #CLI #MultiAgent #开发者日常

注册土耳其区 Apple ID 订阅 ChatGPT Plus 教程

适用场景

注册一个中国大陆区 Apple ID,然后把账号国家/地区改成土耳其区,用于通过土区 App Store 礼品卡余额订阅 ChatGPT Plus


核心思路

注册国区账号 → 网页端转区到土耳其
→ 手机端切 App Store 店面
→ 登录并下载免费 App 固定店面
→ 购买土区礼品卡 → 兑换余额 → 订阅

这套流程的目标是准备一个可以稳定走土区 App Store 内购的 Apple ID,然后在 ChatGPT App 里用 Apple 账户余额订阅 ChatGPT Plus。

⚠️ 不建议拿主力 iCloud 账号操作。 更推荐单独注册一个只用于 App Store、礼品卡充值和订阅的 Apple ID。

开始前准备

  • 一个全新邮箱(尽量不要用已经注册过 Apple ID 的邮箱)
  • 国内 +86 手机号(通常可以使用)
  • 一台 iPhone 或 iPad(网页注册可以在电脑完成,但固定 App Store 区域、兑换礼品卡和订阅更建议用移动端)
  • 稳定的非大陆网络环境(建议全局模式,不要规则分流)
  • 一张可在线支付的银行卡(Visa、MasterCard 或银联)

第一步:先注册一个国区 Apple ID

不需要直接注册土耳其区账号,先按正常流程注册 中国大陆区 Apple ID 即可。

  1. 打开 Apple 账号页面
  2. 创建新账号时,国家或地区选择 中国大陆
  3. 手机号选择 +86
  4. 出生日期填写成年日期
  5. 完成邮箱验证码和短信验证码
注册完成后,先不要急着去 App Store 登录这个账号。后面要先在网页端完成转区,再处理 App Store 店面,否则容易被设备当前的 App Store 区域带回国区。

第二步:网页端把账号区域改成土耳其

注册完国区账号后,建议直接从土耳其区域入口进入账号管理页:

https://account.apple.com/tr/

特别注意

  • 从这里开始,确认已开启全局代理 / 全局模式,出口 IP 是稳定的非大陆 IP
  • 不要只让浏览器走代理,也不要使用规则分流
  • 否则后面的土耳其区入口、Country/Region 修改和付款方式 None / 无都可能异常

操作步骤

进入页面后,登录刚注册好的国区 Apple ID。进入 Personal Information / 个人信息Country/Region / 国家或地区

  1. 点击 Country/Region,开始修改国家或地区
  2. 系统会提示转区前需要确认一些信息(订阅、余额或条款变更),确认无误后继续
  3. 同意新的条款

填写付款方式

到付款方式页面时,优先选择 None / 无。账单地址需要填写土耳其地址,电话可以继续使用国内手机号。

先打开土耳其地址生成器生成地址信息:

https://1ktools.com/zh-cn/tools/developer/turkey-address-generator

生成结果里重点看这几项:

字段对应 Apple 中的字段
街道街道地址
城市城市
省份省/州
邮政编码邮编
国家国家

回到 Apple 付款方式页面,把付款方式选为 None / 无,再把生成的土耳其地址填进去。保存后确认国家或地区已变成土耳其。

付款方式没有 None 怎么办?

  • 是否从 https://account.apple.com/tr/ 进入
  • 是否使用了稳定的非大陆网络
  • 是否开启全局模式(而不是规则分流)
  • 是否已进入完整的 Country/Region 修改流程

第三步:先切 App Store 店面,再登录账号

这是最容易翻车的一步。即使网页端显示账号已经是土耳其区,不要马上打开 App Store 登录,否则会被送回国区。

正确顺序

  1. 退出"媒体与购买项目"账号
  2. 用 Scheme 先切换 App Store 店面到土耳其
  3. 再登录刚刚转区后的 Apple ID

退出账号:设置 → Apple 账户 → 媒体与购买项目 → 退出登录。

切换店面:Safari 打开以下代码:

itms-apps://itunes.apple.com/WebObjects/MZStore.woa/wa/resetAndRedirect?dsf=143480&cc=tr
出现"无法连接 App Store"是正常现象,这个动作的目的是触发店面切换。

完成切换后回到 App Store 登录土区 Apple ID,确认 Country/Region 显示为土耳其。


第四步:下载一个免费 App 固定店面

登录后下载一个免费 App,固定 App Store 店面,降低下次登录又回到国区的概率。

登录 → 确认是土区 → 搜免费 App → 获取下载 → 再充值或订阅

第五步:购买土区礼品卡并充值

推荐使用土耳其本地礼品卡网站 Oyunfor

https://www.oyunfor.com/apple-store/apple-store-itunes-gift-card

操作步骤

1. 注册:切中文/英文,填写邮箱、姓名、手机号(可用 +86)

2. 选金额:第一次建议 100 TL 小额测试

3. 填写发票信息

字段填写
类型个人 / Bireysel
姓名英文或拼音
电话+86 国内手机号
国家China / 中国
如有 "TC Vatandaşı Değilim"(我不是土耳其公民),要勾选

4. 付款:选择 信用卡支付 → Iyzico ile Öde(手续费约 2.49%)

5. 填入卡信息(Visa/MasterCard/银联均可),完成 3D Secure 验证

6. 查看礼品卡码:头像 → Aldığım Ürünler → 展开订单

⚠️ 礼品卡码务必保密,被他人使用无法追回。

7. 兑换:App Store → 头像 → Redeem Gift Card → 输入代码

8. 订阅:打开 ChatGPT App 订阅页面购买 Plus


常见问题

转区提示 "There was an error. Please try later"

退出媒体与购买→用 Scheme 切店面→再登录。换网络或换设备。

内购提示 "your purchase could not be completed"

新号风控。等 24–48 小时后再试。

Mac 上不能订阅

建议用 iPhone / iPad 完成订阅。

手机号能不能用 +86?

可以尝试。一个手机号绑定多个区域 Apple ID 也有人成功过。

费用参考

512.45 TL 约合 77.85 RMB(随汇率波动)。


发表于 Kola.Work · 2026 年 5 月