AI编程助手四大工程范式深度解读：Codex、Claude Code、Antigravity与OpenCode路线比较

最近不少工程师朋友在讨论：OpenAI Codex、Claude Code、Google Antigravity、OpenCode，这些工具到底有什么本质区别？做工程、做产品的团队，或者初创企业，又该优先掌握哪一个？

如果只是把它们当作四个独立的软件来比较，很可能会陷入“哪个更强”的表层争论。更准确地说，它们代表了AI编码代理（AI Coding Agent）正在成型的四种工程路线：

  1. OpenAI Codex：平台化工程Agent路线
  2. Claude Code：代码库深度理解与多文件执行路线
  3. Antigravity：以Agent为中心的IDE路线
  4. OpenCode：开源可控、模型灵活选配路线

本文并不打算做一份“最强排行榜”，而是想从真实工程实践出发，解释清楚：当我们着手构建一个像 Project Velocity 这样的AIoT系统时，如何理解这四种Agent工作方式的差异，以及它们各自适合什么样的场景。

一、为什么不能只问“哪个Agent写代码最快”

很多人刚开始接触AI编码代理时，最容易关注这些问题：哪个生成代码速度最快？哪个模型最聪明？哪个最接近人类程序员的思维习惯？

这些问题当然有价值，但它们还远远不够。因为真实的工程开发从来不只是写一个函数。

以 Project Velocity 为例，我们正在做的是一个端到端的 MCU–Edge–Cloud AIoT 系统，涉及：

  • STM32F103 节点运行 Zephyr RTOS；
  • 节点上连接着传感器、继电器、红外、LCD、按键、CAN 总线；
  • Edge 侧用 RK3588 / Linux 作网关；
  • 上层通过 MQTT、OPC UA、ThingsBoard 实现遥测、控制与可视化；
  • 还需要考虑硬件映射、协议转换、日志、测试、远程维护和版本管理。

在这种复杂系统里，AI Agent的工作远不止“帮我写代码”。它必须理解：

  • 硬件资源在哪里，哪些 GPIO、I2C、UART、CAN 已被占用；
  • Zephyr 的 device tree overlay、prj.conf、main.c 之间如何保持一致；
  • Edge gateway 的数据模型与云端如何对应；
  • 修改了一处代码，会不会影响协议、测试、部署以及后续的维护。

所以，真正应该问的问题不是“哪个Agent最出色”，而是**“哪一种Agent的工作方式，最贴合你当前工程场景的需求？”**

二、Codex 路线：从代码补全走向工程任务委派

Codex 代表的是一种十分清晰的平台化路线。它并不仅仅停留在一个聊天窗口里，也不是简单的IDE插件，而是逐渐渗透到多个开发环境：本地终端、IDE、Web、GitHub、云端执行环境、PR review，甚至支持多任务并行。

这条路线的核心不再是“补全下一行代码”，而是：你可以把一个工程任务整体交给 Agent，它在自己的上下文中阅读代码、修改文件、运行命令、检查输出，然后把结果交给你来审核和合并。

在 Project Velocity 这类项目中，我们可以把许多任务委派给 Codex：

  • 通读整个 Zephyr 工程目录，解释当前节点的代码结构；
  • 根据新增传感器需求，同步修改 overlay、prj.conf 和 main.c；
  • 为 CANopen telemetry 添加新的对象映射；
  • 为 Edge gateway 增加 MQTT topic；
  • 对 PR 做代码审查，检查是否会破坏现有的 telemetry path；
  • 在云端并行执行多个修复任务，最后由工程师统一审核合并。

Codex 路线的突出优势是：它更像一个已经融入工程流程的 Agent，而不仅仅是一个孤立的代码助手。 这特别适合已经有 Git/GitHub 工作流的团队，需要对 PR、测试、分支进行管理的项目，以及希望把 AI Agent 嵌入日常软件工程流程的场景。

但这也带来一个重要的提醒：Agent 越接近工程流程，人类越需要清晰定义边界。 尤其在嵌入式和AIoT系统中，Agent绝不能随意改动与硬件强相关的代码。它可以建议修改 main.c，但不能在缺乏硬件连接信息的情况下擅自改动 overlay；它可以生成 MQTT topic，但必须和云端 ThingsBoard 的数据模型保持一致。因此，Codex 很适合实现“工程任务委派”，但前提是你已经建立了清晰的工程结构、仓库规范和严格的 review 机制。

三、Claude Code 路线：先深度理解整个代码库，再跨文件执行

Claude Code 的鲜明特点可以概括为：它不满足于给你补全一行语句，而是试图理解整个代码库，然后跨文件、跨模块地完成复杂任务。

这一路线尤其适合已经具备一定规模的存量项目。因为真实工程中很多问题根本不是单个文件能解决的。例如，在 Project Velocity 里要增加一个温湿度传感器，可能牵涉到：

  • device tree overlay；
  • Zephyr Kconfig；
  • 传感器驱动接口；
  • main.c 中数据采集逻辑；
  • CANopen TPDO 映射；
  • Edge gateway 数据解析；
  • MQTT topic；
  • ThingsBoard dashboard 数据字段。

如果一个 Agent 只能看到当前文件，就很容易生成“局部正确、系统错误”的代码。Claude Code 路线的重点，就是尽可能理解代码库的结构、模块依赖以及执行路径，然后再去改代码、跑命令、修复错误。它更像一个“坐在终端里的工程搭档”。

你可以直接问它：这个项目的启动流程是什么？数据从 STM32 到 ThingsBoard 是怎样流动的？哪些文件定义了 CANopen 对象？如果要增加一个 RPC 控制命令，需要改动哪些地方？接着可以让它先解释清楚，再执行修改；修改后自动运行测试；如果失败，继续迭代修复。这类询问的价值不仅是生成代码，更在于帮助工程师迅速建立一张“系统地图”。

Claude Code 路线特别适合需要阅读陌生代码库、进行多文件重构、定位复杂 bug、测试失败后自动分析与修复，以及在大项目中持续协作的团队。但它同样不能替代工程判断。在AIoT领域，Agent只能看到代码，未必了解真实硬件连接、信号完整性、时序约束、传感器误差、生产测试条件。因此，Claude Code 非常适合“深度代码库理解 + 执行”，但人类工程师仍然必须对硬件约束、系统架构、测试策略和最终验收负全责。

四、Antigravity 路线：IDE 不再是编辑器，而是 Agent 调度中心

Google Antigravity 代表了一种思路截然不同的方向：把 IDE 从“写代码的地方”重新定义为“管理 Agent 的地方”。

传统 IDE 是以编辑器为中心的。你打开文件、写代码、编译运行、调试。而 Antigravity 的理念更像是：用户提出任务；Agent 进行计划；Agent 使用编辑器、终端、浏览器等多种工具；Agent 产出计划、截图、执行记录、验证结果等 artifact；用户像项目负责人一样进行审查、反馈、批准或调整。

这是一种“以Agent为中心的IDE”模式。其重点不是把 AI 硬塞进旧式 IDE，而是重新设计整个开发界面：未来开发者或许不再是持续手敲代码，而是在一个任务控制台里同时调度和管理多个 Agent。

放到 Project Velocity 里，我们可以这样理解 Antigravity 路线。假设要实现一个功能：从 ThingsBoard 发起 RPC 请求，控制 STM32 节点上的继电器，并将执行结果回传云端。这个任务可以拆解成多个子任务：

  1. 分析当前云端的 RPC 格式；
  2. 检查 Edge gateway 中 MQTT 到 CANopen 的转换逻辑；
  3. 修改 STM32 端接收逻辑；
  4. 加入执行结果的 telemetry；
  5. 运行本地测试；
  6. 生成验证截图或日志；
  7. 为工程师提供一个可审查的 artifact。

Antigravity 这类 Agent-first IDE 的想象空间正在于此：它不再只问“代码写完了没有”，而是追问“任务有没有被计划、执行、验证和记录”。 这对工程团队而言至关重要，因为工程管理最怕的就是：Agent 到底改了什么？为什么这样改？有没有验证？验证证据在哪？出错后怎样回滚？如果一个 Agent-first IDE 能够把这些过程可视化，那么工程团队就更容易将 AI Agent 引入真实项目。

这条路线特别适合复杂任务的拆解、前后端联调、多 Agent 并行、带浏览器验证的 Web/Cloud 开发，以及需要过程记录和可审查 artifact 的团队。但对于嵌入式硬件工程，它还需要与真实设备、串口、J-Link、CAN 分析仪、HIL 测试台等工具做到更深度的打通。所以，Antigravity 路线最值得学习的，不单是某个产品本身，而是它背后的思想：IDE 正在从代码编辑器演变成 Agent 的任务管理和验证平台。

五、OpenCode 路线：开源、终端优先、模型可选、可控性更强

OpenCode 代表的是另一条极为重要的路线：Agent 不必锁死在某一家的平台上，它可以是开源、终端优先、模型灵活选配、可私有化部署的工具链。

对很多工程团队，尤其是嵌入式、工业、IoT 以及企业内部项目来说，这一点意义重大。因为真实工程项目常常涉及：未发布的产品、客户资料、硬件原理图、BOM 成本、私有协议、工厂测试流程、商业合同与交付计划。这些内容未必适合全部上传到外部云服务中。

OpenCode 这类开源 Agent 的价值在于：可以在终端中运行；可以自由接入不同模型；更容易对接本地或企业私有模型；能够与 GitHub workflow、CI、Issue、PR 紧密配合；对于团队来说，可控性和透明度都明显更高。在 Project Velocity 里，OpenCode 路线特别适合完成这些任务：

  • 在本地 Ubuntu 环境中分析 Zephyr 工程；
  • 使用本地模型进行代码阅读与文档整理；
  • 结合 Git workflow 处理 issue；
  • 在不暴露全部项目资料的前提下，让 Agent 参与部分工作；
  • 为团队逐步建立自己的 AI 辅助工程流程。

当然，开源路线也意味着团队需要承担更多的工程配置工作：模型怎么选？API key 怎么管理？本地模型的能力是否足够？权限边界如何设定？CI runner 怎样隔离？Agent 失败后如何回滚？因此，OpenCode 并不是“最省事”的路线，但它很可能是许多工程团队最愿意长期掌握的一条路。因为它给团队提供了一项重要能力：不是单纯使用 Agent，而是把 Agent 真正纳入自己的工程体系。

六、四种路线的对比列表

下面的表格可以帮助快速梳理四条路线的差异：

工具/路线 核心入口 最强特点 适合场景
Codex ChatGPT / CLI / IDE / Web / GitHub 平台型工程Agent，多环境协同 PR、任务委派、代码审查、多任务并行
Claude Code Terminal / IDE / Desktop / Web 深度理解代码库，跨文件执行 大型代码库阅读、重构、bug修复、测试失败分析
Antigravity Agent-first IDE 任务计划、执行、验证、artifact管理 复杂任务拆解、多Agent管理、带浏览器验证的开发
OpenCode Terminal / Desktop / IDE / GitHub workflow 开源、模型可选、可控性强 本地工程、私有项目、企业流程、可定制Agent

但这张表的目的并不是让我们站队选边。更重要的认知是：未来的工程团队很可能同时使用多种 Agent。 比如，用 Claude Code 快速理解一个陌生的代码库；用 Codex 在 GitHub 上处理 issue 和 PR review；用 Antigravity 管理复杂任务和验证过程；用 OpenCode 接入本地模型，处理更敏感的工程资料。Agent 并不是“一个工具包打天下”，真正成熟的团队会逐渐形成自己的 Agent 工程组合。

七、回到 Project Velocity：AI Agent 如何真正进入真实 AIoT 工程闭环

在 Project Velocity 这个项目里，最令我关心的并不是 Agent 是否能写出一段漂亮的代码，而是它能不能进入一个真实的工程闭环。

这个闭环至少包括：

  1. 资料输入：datasheet、schematic、pinout、Excel、PDF、Markdown；
  2. 架构约束：MCU、Edge、Cloud、协议、数据模型；
  3. 代码生成：overlay、prj.conf、main.c、gateway、dashboard；
  4. 编译运行：Zephyr build、Linux service、MQTT broker、ThingsBoard；
  5. 测试验证：串口日志、CAN 报文、MQTT message、云端 telemetry；
  6. 文档沉淀：Obsidian、Markdown、NotebookLM、项目知识库；
  7. 工程治理：Git、review、CI、版本、OTA、回滚。

这也是我一直强调的观点：AI 辅助工程（AI-Assisted Engineering）不等于“Vibe Coding”。 Vibe Coding 更像是：我说一个想法，AI 帮我生成一段代码。而 AI-Assisted Engineering 应该是：人类定义架构、约束、验证标准和交付目标，AI Agent 参与资料处理、代码生成、测试、审查、文档和维护，但整个过程依然严格受到工程体系的约束。

这就是 Codex、Claude Code、Antigravity、OpenCode 真正值得研究的地方。它们并不是简单的“代码生成器”，而是在一步步把软件开发从“人写代码，AI 补全”推向**“人定义目标与约束，Agent 执行、验证、反馈，人类审查与决策”**的全新模式。

八、给工程师和学习者的建议

如果你刚开始学习 AI Coding Agent，建议不要一上来就追求“哪个最强”。可以按照下面的顺序逐步深入：

第一步：先理解 Agent 的基本工作方式

包括：如何读取上下文、制定计划、使用工具、修改文件、运行命令，并根据错误反馈持续迭代。

第二步：选择一个有真实约束的小项目进行练习

不要只让 Agent 写贪吃蛇或待办列表。最好选择一个贴近真实约束的小项目，比如：一个 Zephyr 传感器节点、一个 MQTT gateway、一个本地数据采集脚本、一个 ThingsBoard dashboard demo，或者一个 Android driver 测试程序。约束越真实，你越能看清 Agent 的能力边界。

第三步：不要只看生成结果，更要关注过程

重点观察：它是否先尝试理解项目结构？是否知道该修改哪些文件？会不会自动运行测试？会不会解释失败的原因？是否留下可审查的修改记录？是否遵守你设定的硬件和协议约束？

第四步：建立自己的 Agent 使用规范

比如在 Project Velocity 里，我会要求 AI 生成 Zephyr 代码时，始终围绕“三文件策略”：

  1. overlay / .dts：硬件映射；
  2. prj.conf：系统配置；
  3. main.c：应用逻辑。

这样就能避免 AI 只写应用逻辑，却忘记了硬件映射和 Kconfig 配置。这正是从“会用 AI”跃迁到“用 AI 做工程”的关键一步。

九、结语：重构的不是程序员，而是工程组织方式

Codex、Claude Code、Antigravity、OpenCode 的相继出现，意味着 AI Coding Agent 已经进入了一个新的阶段。过去，我们习惯问：“AI 能不能写代码？”现在，更关键的问题变成了：“AI Agent 能不能进入真实的工程流程？能不能理解上下文、执行任务、验证结果、接受 review？能不能被团队管理、约束并持续改进？”

对于学生，这是一个全新的学习入口；对于工程师，这是一种新的生产力工具；对于创业团队，这是一种新的研发组织方式。对于 AIoT 和嵌入式系统来说，这更是一次重要的机会：因为我们的项目天然具备跨硬件、固件、边缘、云端、协议和运维的复杂性，越复杂的工程越需要 Agent，同时也越需要工程约束。

所以，我的看法很明确：不要只学习某一个 Agent。 更重要的是学习如何把 Agent 放进真实的工程体系里。这才是 AI-Assisted Engineering 的内核所在。