Google Antigravity /teamwork 对工业工程 Agent 的参考价值，集中在如何把复杂问题组织成一个可分工、可验证、可持续推进的工程过程。
工业工程任务通常跨越多个环节：理解设备与工艺、分析运行数据、构建模型、提出方案、调用仿真工具、检查约束，再形成可以交付的成果。一个环节的错误，还可能沿着后续流程不断放大。因此，架构既要支持探索，也要有识别错误、阻止错误传播和保留工程证据的机制。
Google Research 于 2026 年 11 月 13 日发布的文章，介绍了 Antigravity /teamwork 在数学、化学和系统工程中的应用。其共同特点是：人类专家定义问题与约束，智能体承担探索、实现和检查工作，结果接受相应工具与实验依据的检验。research.google
下面先分析公开机制，再讨论工业工程中的实现方式。文中的工业架构与泵组示例，属于据此提出的设计建议。
一、/teamwork 的核心：把工程职责落实到协作流程中
在 /teamwork 中，任务被组织成具有不同职责的智能体团队。官方文档将其划分为协调、执行和验证几个层次：
| 职责层次 | 官方角色 | 主要作用 |
|---|---|---|
| 总体协调 | Sentinel | 路由任务、报告进度、启动最终审计 |
| 项目编排 | Project Orchestrator | 拆分里程碑，组织具有依赖关系的工作 |
| 探索与实施 | Explorers、Workers | 分别承担只读研究和具体实现 |
| 审查与挑战 | Critic、Challenger | 检查方案，寻找边界条件与失败路径 |
| 审计与验收 | Auditor、Success Auditor | 核对执行证据，完成最终端到端检查 |
这些角色构成了一套明确的交付流程：生成结果之后，还要通过相应检查才能推进。Google Antigravity Docs
对工业工程而言，这种职责划分很有意义。方案设计、计算校核、试验验证和最终验收，本来就是不同的工作。把它们映射到 Agent 系统中，可以使每个环节都有明确输入、输出与责任。
不过，角色数量只是组织方式，验收条件才决定工程质量。 即使设置了很多“审查者”，如果它们只阅读同一段说明、重复同一种判断，系统仍可能一起漏掉错误。
工业平台需要进一步把角色职责落实为工具权限、产物格式和可执行的检查规则。
二、任务分配：根据问题的依赖关系选择协作方式
/teamwork 使用不同的 pattern，即协作模式，处理不同类型的问题。官方介绍的模式包括分布式编码、迭代编码、长证明和文档审查等。模式描述参与角色、协作规则与推进条件，框架据此组织执行，并能根据任务调整团队结构。Google Antigravity Blog
由此可以提炼出工业工程 Agent 的第一条设计原则：
先判断任务如何耦合，再决定如何分配。
1. 能独立交付的工作，适合并行推进
以泵组运行优化为例，可以同时安排不同 Agent：
- 审查历史运行数据的缺失、异常和时间对齐情况；
- 整理泵特性曲线、设备参数及运行边界；
- 分析现有控制程序和启停逻辑；
- 归纳不同负荷下的典型运行工况。
这些工作具有相对独立的产物，可以并行执行。但它们必须引用统一的设备编号、测点定义和数据版本，否则后续集成会出现语义冲突。
与此同时，任务之间仍存在先后关系。例如，候选控制策略的正式评估，应使用已经确认的数据和模型；模型存在重大问题时，相关优化结果只能标记为探索性结果。
2. 强耦合问题，适合顺序迭代与独立复核
假设正在修改一段控制逻辑，其中采样周期、滤波参数、状态切换和报警条件相互影响。将它们交给几个 Agent 同时修改，可能增加接口冲突，也可能让每个局部修改都看似合理，组合后却出现异常。
此时，更适合先形成一个完整候选，再交由后续 Agent 检查、挑战和修正。
Google 对 /boost 的描述正体现了这一点：初始执行者提出实现或调查结果，后续执行者重新审视要求、寻找漏洞并复测，协调者再独立检查。其定位包括复杂调试、并发问题和紧耦合重构。Google Antigravity Docs
因此，多 Agent 的价值既包括并行探索，也包括让不同执行者在不同阶段承担相互制约的职责。
3. 每个子任务都应有“工程任务单”
工业系统中，任务分配最好形成结构化记录，至少说明：
- 使用哪些输入，以及对应版本；
- 哪些工程约束必须满足；
- 允许调用哪些工具、修改哪些对象；
- 应交付什么产物，以什么方式验收；
- 遇到什么情况需要停止、补充信息或升级处理。
例如，“分析泵组节能潜力”仍然过于宽泛；“基于指定运行数据与泵曲线，在供水服务水平不降低的前提下，比较三种调度策略，并提交约束检查记录和可复现计算结果”，才足以支持可靠分工。
三、上下文隔离：让每个 Agent 专注，同时保持工程事实一致
上下文隔离是 /teamwork 值得研究的一项机制。
Antigravity 的子 Agent 文档明确指出，新子 Agent 默认不继承父 Agent 的完整会话历史；工作空间则另行配置，可以共享，也可以使用独立工作副本。文档同时允许 Agent 之间通信及查阅相关记录。Google Antigravity Docs
这意味着，上下文隔离主要是在控制“当前求解需要看到什么”，不能直接理解为信息绝对不可见或文件天然隔离。
Google Research 还强调，审查者可以从干净上下文出发，不携带原始生成者的推理过程来检查结果。这样设计，有助于减少审查者被前一位 Agent 的解释带偏的机会。research.google
迁移到工业工程时，可以把信息分成三类。
第一类是公共工程事实。 包括设备身份、测点含义、单位体系、工艺边界、适用工况、输入版本和验收要求。所有相关 Agent 都应基于同一套已确认信息工作。
第二类是局部探索记录。 包括某个 Agent 的假设、试验代码、中间推导和失败尝试。这些信息按需要共享，并保留“尚未验证”的状态。
第三类是交付证据。 包括候选配置、模型文件、测试输入、真实运行日志、验证结论以及对应版本。这些内容应能够被其他执行者重新检查。
这里有一个关键尺度：验证者可以不阅读生成者的完整思考过程，但必须掌握完整需求、工程边界和必要前提。
例如，验证泵组策略时，如果不知道最低供水压力要求，独立上下文反而会让验证失去意义。
此外，文件写入、数据库访问和工具调用还需要独立管理。工业实现中，应按项目、设备和操作种类约束权限，并管理并发修改；上下文管理承担不了这些职责。
四、候选方案生成：把探索组织成可比较的工程搜索
在 Long Proof 模式中，Google 描述了一种竞争式搜索过程：并行产生多个策略，为候选安排专门寻找反例的角色，再综合候选及其批评意见。失败路线会连同问题记录保留，其中有用的部分仍可能被后续尝试利用。Google Antigravity Blog
这种机制可以迁移到工业设计与优化中。
以泵组为例，候选探索可以覆盖不同方向：
- 根据需求变化调整压力设定策略；
- 优化多台泵的组合运行方式；
- 改进启停逻辑，减少低效运行与频繁切换。
这些候选的价值，在于它们探索了不同的工程假设和方法。仅仅复制相同任务、让多个模型生成相似答案，未必能有效扩大搜索范围。
要让候选具有可比性，还需要统一评价条件：相同的需求曲线、设备配置、约束边界和评价口径。
尤其需要区分两个步骤：
先判断可行性，再比较收益。
供水不足、压力越界或启停次数超过允许范围的方案，应先被判定为不满足要求。对于已经满足约束的方案，再比较能耗、维护负担、实现复杂度和工况适应性。
如果把所有因素混入一个可以任意权衡的总分，系统可能用某项收益“抵消”本来不可突破的工程约束。
候选方案的交付内容也应超出文字说明，至少包含配置或代码、依赖条件、评价结果以及已知失败工况。失败记录则可以继续转化为回归测试，使下一轮搜索拥有更明确的边界。
五、独立验证：把“有人认为正确”变成“有证据支持成立”
工业工程 Agent 中，独立验证应同时落实在流程、信息和工具三个层面。
流程上，生成者与验证者承担不同职责；信息上，验证者独立对照原始要求；工具上，验证结论需要来自可检查的计算、测试或测量结果。
Google 的工程案例体现了这种安排。例如，Rust 重写工作流依据依赖关系安排模块，并使用原有、未修改的测试套件检查结果；分子结构探索则引入了物理约束下的光谱模拟器。research.google
在 FarArray 案例中，Google 还明确说明，人类工程师负责接口、内存布局和验收机制，Agent 承担实现、调试及性能优化，工作接受分阶段检查。Google Antigravity Blog
对工业系统，可以按任务需要建立以下验证层次：
| 验证层次 | 检查内容 | 可以支持的结论 |
|---|---|---|
| 数据与接口检查 | 单位、字段、时间基准、接口和编译结果 | 输入与实现满足规定的基础条件 |
| 功能与回归检查 | 功能测试、历史数据回放、异常路径 | 在已测试范围内符合功能要求 |
| 工程模型验证 | 仿真、参数扰动、边界工况分析 | 在指定模型及假设下满足工程约束 |
| 实物与现场验证 | 按需开展台架、硬件在环或受控现场试验 | 在实际测试范围内观察到预期行为 |
这些层次支持的结论不同。仿真通过，说明方案在相应模型与条件下成立；现场效果仍需要相应证据。
验证基准需要独立管理
候选生成者可以编写开发测试，但正式验收基准应有独立的管理边界，防止通过修改指标、删减工况或跳过失败项获得“通过”。
新增测试和修订基准当然可以发生，只是应记录版本与理由，并重新确认受影响的结论。
同样，审计者应能够看到真实输出和失败记录，而不只接受执行者写下的“测试全部通过”。
独立上下文不能消除共同盲点
如果多个 Agent 使用相同的错误设备参数、同一份有偏数据或同一个失真的物理模型，它们仍然可能得到一致的错误结论。
因此，验证架构还要考虑证据来源的差异：计算结果能否与现场测量比较？仿真结论能否通过另一种方法复核？最终评估是否使用了未反复参与调优的数据？
对工程系统来说，明确“证据支持到什么范围”，是验证报告的一部分。
六、长期任务执行：让项目状态持续，使执行者可以更换
/teamwork 的长期执行设计包含两个值得借鉴的安排：通过需求、计划和进度等工作产物保存项目状态；在里程碑之间由新的协调者接手。Google Antigravity Docs
Antigravity 还提供相邻的上下文管理能力：将较早会话压缩为检查点摘要，以及恢复历史会话。这些能力分别解决上下文增长和会话续接问题。Google Antigravity Docs
工业平台在此基础上，还需要补足外部工具与工程状态的恢复机制。
1. 把任务状态保存在持久化系统中
跨天任务应保存：
- 当前目标、约束及其版本；
- 子任务依赖关系和实际完成状态；
- 数据、模型、代码与配置版本；
- 已提交的外部作业及其运行标识；
- 验证结果、失败原因和下一步条件。
接任者应能从这些记录恢复工作。自然语言摘要可以帮助理解，但关键状态应能与真实文件、日志和外部作业对应起来。
2. 长时间计算交给外部作业系统
如果一次仿真需要数小时，可以由 Agent 提交任务，保存作业标识，再由作业系统负责排队、执行和记录。
计算完成后，Agent 读取结果继续处理。项目可以长期存在，而某个模型会话不需要持续占用全部执行过程。
系统恢复时，也应先查询原作业状态，再决定是否重试，避免重复提交昂贵计算或重复执行外部操作。
3. 输入变化后，使旧结果明确失效
假设优化期间更换了泵型，或者最低压力要求发生变化，旧方案的验证结论就需要重新评估。
因此，每份验证报告都应绑定输入数据、设备配置、模型和约束版本。发生变化时，系统应找出受影响的任务，标记旧证据失效并安排重验。
长期任务的连续性，包含这种版本一致性。
4. 为停止与升级设置明确条件
长期执行应有预算、重试次数和进展判断。工具反复失败、数据不足、约束无法同时满足或候选长期没有改善，都应触发明确处理方式。
有时最有价值的交付物，是一份证据充分的“不成立”或“仍需补充这些数据”的报告。持续迭代需要以信息增量和工程进展为依据。
七、另一个重要启示：工业 Agent 也需要优化验证成本
工业任务中，产生候选方案可能很快，评价候选却很昂贵。一次高精度仿真、完整硬件测试或现场试验，往往限制了可探索的方案数量。
Google 引用的 DuoDiscover 专门研究这一瓶颈：Agent 同时寻找优化方向和快速代理评价方法，使用代理评价推进搜索，再持续对照真实评价检查其排序是否可靠；失真的代理评价会被淘汰。arxiv.org
这一机制很适合延伸到工业工程：
先用简化模型或快速计算筛选大量候选，再将少量有希望的方案送入高精度仿真和实物试验。
不过，代理评价本身也应成为被验证的对象。例如，某个简化泵站模型可能在常见负荷下排序正确，在低流量或切泵过程中却失效。系统需要记录其适用范围，并定期用更高可信度的评价校准。
尤其对于关键约束，快速筛选的通过结果需要由相应的正式检查确认。
这使架构多了一项能力：根据评价成本和可信度，安排不同深度的验证。
八、落到工业平台：以泵组运行优化为例
可以把任务设定为：
基于历史运行数据，提出降低泵组能耗的控制策略，同时满足供水服务、设备运行边界和启停限制，交付可复核的方案及验证报告。
首先要明确能源评价口径，并固定服务要求，避免通过减少供水量制造“节能”。随后依次推进数据审查、模型确认、候选探索、独立验证和工程交付。
一套可实现的架构，可以包含以下组件：
| 组件 | 在工业任务中的职责 |
|---|---|
| 工程项目服务 | 保存目标、约束、任务依赖、预算与验收状态 |
| 专业 Agent 执行层 | 组织数据分析、设备建模、策略生成、审查等角色 |
| 工业工具接口 | 连接资产资料、历史数据库、仿真工具、编译器与计算程序 |
| 版本与证据存储 | 管理输入快照、候选产物、运行日志及失败案例 |
| 独立验证服务 | 执行固定基准、回归测试、边界工况和证据检查 |
| 工程变更接口 | 将验证后的方案交给既有变更、试验和发布流程 |
对于已有 IoT 或 AIoT 平台，资产模型、时序数据、规则和任务系统，都可以成为这套架构的基础。新增的核心能力，是把工程问题转换为可执行任务，并把任务产物与验证证据关联起来。
工具连接可以采用 API 或 MCP；服务端应按企业、项目、设备和操作类型实施鉴权。读取数据、执行离线仿真、提交控制变更和实际下发，应分别管理。
在这一架构下，工程 Agent 负责搜索、分析和形成方案，实时控制环节继续由相应控制系统承担。经过验证的策略，则通过已有工程流程进入试验与部署。
最终交付也应足够具体：候选配置、相对基线的比较、约束检查、失败工况、适用边界、复现实验材料，以及必要的实施和回退安排。
九、如何判断这种架构是否值得采用
/teamwork 所体现的组织方式，尤其适合目标能够明确、候选可以比较、结果拥有外部检查手段，而且值得投入多轮探索的任务。
设备诊断、控制软件开发、仿真优化和设计校核，都可能满足这些条件。但不同任务的验证能力差异很大。例如，软件功能可以反复运行测试，设备根因判断却可能需要新增测量才能区分竞争性解释。架构应允许输出不确定性，并把下一步取证要求交代清楚。
实际建设时，可以先采用“协调者、方案生成者、独立验证者”这一较小配置，建立完整闭环，再根据瓶颈增加专业角色。
评价时，建议比较以下结果：
- 每个验收合格交付物的总成本；
- 工程师复核与返工所需时间；
- 最终遗漏的错误和约束违规情况；
- 结果能否复现、能否在中断后继续；
- 相对于单 Agent 加工具的基线，是否取得稳定收益。
Google 所说的工作流自我改进，也主要体现为利用过往运行过程调整编排与迭代方法；不能据此理解为基础模型权重自动完成了再训练。research.google 工业平台若引入这种能力，仍应对工作流变更进行版本管理和回归评估。
对工业工程 Agent 而言，优先建设的能力应当是：把工程目标转成约束明确的任务，把候选方案转成可复核的产物，把试验结果转成可追踪的证据，并让这些证据在跨天执行、输入变化和执行者交接之后仍然保持有效。
参考资料
- Advancing science & engineering with Antigravity’s /teamwork
https://www.research.google/blog/advancing-science-engineering-with-antigravitys-teamwork-feature/ - Teamwork: when AI becomes a research partner
https://antigravity.google/blog/teamwork-when-ai-becomes-a-research-partner/ - Teamwork agent teams (/teamwork)
https://antigravity.google/docs/teamwork - Boost deep reasoning (/boost)
https://antigravity.google/docs/boost - Custom subagents
https://antigravity.google/docs/subagents - DuoDiscover: Scaling Autonomous Discovery Beyond the Evaluation Bottleneck
https://arxiv.org/abs/2610.17184 - Context command (/context)
https://antigravity.google/docs/cli/commands/context/ - Resume command (/resume)
https://antigravity.google/docs/cli/commands/resume/ - How Gemini 4 Argon Upleveled Agents on Antigravity: Trillion-Edge Graphs and Custom TPU Kernels
https://antigravity.google/blog/gemini-4-argon-trillion-edge-graphs-and-tpu-kernels/