谷歌给 Antigravity 加了个叫 Dynamic Workflows 的功能。按官方文档的说法，入口是一条斜杠命令 /run-workflow，后面跟一句你自己描述的任务。智能体会读取内置的 run-workflow 技能，为这个任务写一段简短的 Python 脚本。Antigravity 随后把脚本展示给你，在你批准之前什么都不跑——除非你的权限预设已经放行。

顺序是关键：先用代码写计划，再批准，最后执行。批准之后，脚本替你协调其他智能体，可以用 parallel() 并发跑，也可以用 pipeline() 串行跑，还能分组到有名字的阶段里实时观察。

每个工作流智能体在自己的会话里干活，返回的结果必须匹配一份 JSON Schema，于是文件读取、搜索、测试日志都不会涌进你的主对话。一个工作流还能跨轮次保留同一个智能体——找出 bug 的那位评审，之后可以回来确认 bug 已修。跑通的脚本可以存成文件，以后再跑。

谷歌自己给的例子刻意平常：并行审查每个改动过的文件，一个文件一位评审；先写一个失败的测试，再修代码；或者铺开一批并行修复者，让最初的评审来验收。功能在 Antigravity 的应用和命令行里都能用，面向 Google AI Pro 和 Google AI Ultra 套餐，除套餐原有的模型额度外不另收费。

为什么 Python 这一段才是重点？把编排藏进聊天里本来很容易。长对话确实能协调智能体，但对话没法 diff，没法下周二原样重跑，也没法指着第 12 行说“只改这个阶段”。

Python 脚本不一样：运行前可检查，写错时可编辑，写对后可复用。原语刻意做小——phase() 命名阶段，log() 记录发生了什么，agent() 启动工作，parallel() 和 pipeline() 控制时序。控制流不再是模型一轮一轮即兴发挥的东西，而是人事先批准过的东西。

这套思路和靠踩坑换来的经验很接近。新闻批次只有在步骤不再住在某个人脑子里之后才稳定下来：先找一手来源，发布前所有关卡必须全过，计数固定为实测值，检查失败就先修检查器再谈文章。这周就有一个例子：一个以“1.”开头的表格单元格让搜索提交管线瘫了一天，因为某个检查器悄悄把它当列表标记剥掉了。修法不是更好的提示词，而是一条更小、可测试的规则，外加一个回归测试。

同一天还有一组更安静的数字。RiceStudioLab 第一次通过仪表盘的数据通路拉取真实统计，而不是靠猜：26 篇已发布笔记，52 次总浏览，5 个赞，0 条评论，0 日元销售，均为 11 月 15 日 note 的计数。阅读量最高的一篇有 17 次浏览。数字很小，还是照发——因为一个无法度量的工作流，只是一种仪式。

把 Antigravity 的发布和这个周日串起来的，是同一条线：让看不见的部分变得可见，智能体跑之前的计划，跑完之后的结果。想做的测试也不大：挑一件已经在做的重复活——对一份固定清单做并行检查，每项给出结构化结论——先按 Antigravity 的方式写成可审查的脚本，不管最后是否真的在 Antigravity 里跑。

如果一份计划经不起用 Python 写下来，它从来就不是计划，只是排版漂亮的希望。把计划写成你愿意批准、愿意运行、也愿意再运行一次的代码——这就是全部功课，哪怕你从没打开过 Antigravity。