最近很多朋友问我：OpenAI Codex、Claude Code、Google Antigravity、OpenCode，到底有什么区别？

作为工程师、产品经理、创业团队，到底应该学哪一个？

我的回答是：

不要先把它们看成四个软件。

更准确地说，它们代表了 AI Coding Agent 正在形成的四种路线：

1. OpenAI Codex：平台型工程 Agent 路线

2. Claude Code：代码库深度理解与执行路线

3. Antigravity：Agent-first IDE 路线

4. OpenCode：开源、可控、模型可选路线

这篇文章不是做“谁更强”的排行榜，而是从工程实践角度解释：

当我们真正做一个 AIoT 系统，比如 Project Velocity，应该如何理解这四种 Agent 路线？

---

一、为什么不能只问“哪个 Agent 最好用”？

很多人刚开始接触 AI Coding Agent 时，最容易问的问题是：

哪个写代码最快？

哪个模型最聪明？

哪个最像程序员？

这些问题当然重要，但还不够。

因为真实工程不是只写一个函数。

以 Project Velocity 为例，我们做的是一个完整的 MCU–Edge–Cloud AIoT 系统：

• STM32F103 节点运行 Zephyr RTOS；

• 节点连接传感器、继电器、IR、LCD、按键、CAN 总线；

• Edge 端使用 RK3588 / Linux 做网关；

• 上层通过 MQTT、OPC UA、ThingsBoard 完成遥测、控制和可视化；

• 还要考虑硬件映射、协议转换、日志、测试、远程维护和版本管理。

在这种系统里，AI Agent 不只是“帮我写代码”。

它要理解：

• 硬件资源在哪里；

• 哪个 GPIO、I2C、UART、CAN 被使用；

• Zephyr 的 overlay、prj.conf、main.c 如何一致；

• Edge gateway 如何和云端数据模型对应；

• 改一处代码，会不会影响协议、测试、部署和后续维护。

所以真正的问题不是：

哪个 Agent 最好？

而是：

哪一种 Agent 工作方式，最适合你的工程场景？

---

二、Codex 路线：从“写代码”走向“工程任务委派”

Codex 代表的是一种很明显的平台型路线。

它不是只停留在聊天窗口里，也不只是一个 IDE 插件，而是逐渐进入：

• 本地终端；

• IDE；

• Web；

• GitHub；

• 云端执行环境；

• PR review；

• 多任务并行。

这条路线的核心不是“补全下一行代码”，而是：

你把一个工程任务交给 Agent，它在自己的上下文里阅读代码、修改代码、运行命令、检查结果，并把结果交还给你 review。

比如在 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 路线的重点，就是让 Agent 尽可能理解代码库结构、模块依赖和执行路径，然后再改代码、跑命令、修复错误。

它更像一个“坐在终端里的工程搭档”。

你可以问它：

• 这个项目启动流程是什么？

• 数据从 STM32 到 ThingsBoard 是怎么走的？

• 哪些文件定义了 CANopen 对象？

• 如果我要增加一个 RPC 控制命令，需要改哪些地方？

• 请先解释，再修改；修改后跑测试；如果失败，继续修复。

这类问题的价值，不只是代码生成，而是帮助工程师快速建立“系统地图”。

Claude Code 路线特别适合：

• 需要阅读陌生代码库；

• 多文件重构；

• 复杂 bug 定位；

• 测试失败后的自动分析与修复；

• 大项目中的持续协作。

但它同样不能替代工程判断。

在 AIoT 里，Agent 看到的是代码，不一定知道真实硬件连接、信号完整性、时序约束、传感器误差、生产测试条件。

所以 Claude Code 很适合做“深度代码库理解 + 执行”，但人类工程师仍然要负责：

硬件约束、系统架构、测试策略和最终验收。

---

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

Google Antigravity 代表的是另一种很有意思的路线：

把 IDE 从“写代码的地方”，变成“管理 Agent 的地方”。

传统 IDE 的核心是编辑器。

你打开文件，写代码，运行，调试。

而 Antigravity 的思路更像是：

• 用户提出任务；

• Agent 进行计划；

• Agent 使用编辑器、终端、浏览器等工具；

• Agent 生成计划、截图、执行记录、验证结果等 artifacts；

• 用户像项目负责人一样审查、反馈、批准或调整。

这是一种更接近“Agent-first IDE”的模式。

它的重点不是把 AI 塞进旧 IDE，而是重新设计开发界面：

未来开发者可能不是一直手写代码，而是在一个任务控制台里管理多个 Agent。

放到 Project Velocity 里，Antigravity 路线可以这样理解：

假设我要实现一个功能：

从 ThingsBoard 发送 RPC，控制 STM32 节点上的继电器，并把执行结果回传到云端。

这个任务可以拆成多个子任务：

1. 分析当前云端 RPC 格式；

2. 检查 Edge gateway 中 MQTT 到 CANopen 的转换逻辑；

3. 修改 STM32 端接收逻辑；

4. 加入执行结果 telemetry；

5. 运行本地测试；

6. 生成验证截图或日志；

7. 给工程师一个 review artifact。

Antigravity 这类 Agent-first IDE 的想象空间，就在这里：

它不是只问“代码写完了吗”，而是问“任务有没有被计划、执行、验证、记录”。

这对于工程团队非常重要。

因为工程管理最怕的是：

• Agent 到底改了什么？

• 为什么这样改？

• 有没有验证？

• 验证证据在哪里？

• 出错以后怎么回滚？

如果一个 Agent-first IDE 能把这些过程可视化，工程团队就更容易把 AI Agent 放进真实项目。

这条路线特别适合：

• 复杂任务拆解；

• 前后端联调；

• 多 Agent 并行；

• 带浏览器验证的 Web / Cloud 工程；

• 需要过程记录和可审查 artifact 的团队。

但对于嵌入式硬件工程，它还需要和真实设备、串口、J-Link、CAN analyzer、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-Assisted Engineering 流程。

当然，开源路线也意味着团队要承担更多工程配置工作：

• 模型怎么选？

• 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-Assisted Engineering 不等于 Vibe Coding。

Vibe Coding 更像是：

我说一个想法，AI 帮我生成一段代码。

而 AI-Assisted Engineering 应该是：

人类定义架构、约束、验证标准和交付目标，AI Agent 参与资料处理、代码生成、测试、审查、文档和维护，但整个过程仍然受工程体系约束。

这就是 Codex、Claude Code、Antigravity、OpenCode 真正值得研究的地方。

它们不是简单的“代码生成器”。

它们正在把软件开发从：

人写代码，AI 补全

推向：

人定义目标和约束，Agent 执行、验证、反馈，人类审查和决策。

---

八、给工程师和学生的建议

如果你刚开始学习 AI Coding Agent，我建议不要一上来就追求“哪个最强”。

可以按照下面的顺序学习：

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

包括：

• 读取上下文；

• 制定计划；

• 使用工具；

• 修改文件；

• 运行命令；

• 根据错误反馈继续迭代。

第二步：选择一个真实小项目练习

不要只让 Agent 写贪吃蛇或者 Todo list。

最好选择一个有真实约束的小项目，比如：

• 一个 Zephyr 传感器节点；

• 一个 MQTT gateway；

• 一个本地数据采集脚本；

• 一个 ThingsBoard dashboard demo；

• 一个 Android driver 测试程序。

真实约束越多，你越能看出 Agent 的能力边界。

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

重点观察：

• 它是否先理解项目结构；

• 是否知道该改哪些文件；

• 是否会运行测试；

• 是否会解释失败原因；

• 是否会留下可 review 的修改；

• 是否尊重你定义的硬件和协议约束。

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

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

1. overlay / .dts：硬件映射；

2. prj.conf：系统配置；

3. main.c：应用逻辑。

这样可以避免 AI 只写 application logic，却忘记硬件映射和 Kconfig 配置。

这就是从“会用 AI”走向“用 AI 做工程”的关键一步。

---

九、结语：未来不是程序员被替代，而是工程组织方式被重构

Codex、Claude Code、Antigravity、OpenCode 的出现，说明 AI Coding Agent 已经进入一个新阶段。

过去我们讨论的是：

AI 能不能写代码？

现在更重要的问题是：

AI Agent 能不能进入真实工程流程？

能不能理解上下文、执行任务、验证结果、接受 review？

能不能被团队管理、约束和持续改进？

对于学生来说，这是新的学习入口。

对于工程师来说，这是新的生产力工具。

对于创业团队来说，这是新的研发组织方式。

对于 AIoT 和嵌入式系统来说，这更是一次重要机会：

因为我们的项目天然复杂，跨硬件、固件、边缘、云端、协议和运维。越复杂的工程，越需要 Agent；但也越需要工程约束。

所以我的观点是：

不要只学习某一个 Agent。

更重要的是学习：

如何把 Agent 放进真实工程体系里。

这才是 AI-Assisted Engineering 的核心。

---