一、 从对话到执行：Coding Agent 诞生的必然性

2022 年末，ChatGPT 的发布让大语言模型第一次以“可对话”的形态进入大众视野，它并非首次提出大语言模型（LLM），却通过极低的使用门槛，将文本生成、问答与代码能力直接交付给普通用户，使 AI 从技术圈迅速扩散至更广泛的应用场景，由此开启了新一轮 AI 应用浪潮。

随着使用的深入，大家逐渐意识到，仅依赖对话并不足以完成复杂、长期的真实任务，围绕“目标驱动、持续执行”的 Agent 思路开始成形，一些产品（如 Manus）通过将任务拆解、工具调用和执行过程显性化，使这种范式首次以更直观的方式被用户感知，推动 AI 应用从一次性响应向持续执行演进。

在软件工程领域，这一问题尤为突出，开发者可以轻松让模型优化一段代码，但在真实工程环境中，代码往往分布在数百个文件中，伴随着复杂依赖、构建流程和测试约束，基于复制粘贴（例如：500+文件、复杂依赖）的交互方式很快失效。

正是在这一背景下，Coding Agent 成为最先在主流模型体系中落地的 Agent 形态。 以 Claude Code、OpenAI Codex 以及 Gemini 为代表的新一代模型，开始直接面向代码仓库和工程流程设计能力，使模型不再只是“写代码”，而是能够理解工程上下文、修改文件、运行测试并参与完整的软件开发过程，本文来聊聊。

说明：本文内容基于作者在实际使用与调研 Claude Code、OpenAI Codex 及 Gemini 等工具过程中的个人理解与经验总结，难免存在一定主观性，仅供技术交流与讨论参考。

二、 Coding Agent 的三大流派

围绕 Coding Agent 的实现路径，不同模型体系给出了不同的答案，以 Anthropics Claude Code、OpenAI Codex 和 Google Gemini 3 为代表，可以大致归纳出三种具有代表性的技术流派，它们在能力侧重点、工程假设以及 Agent 的工作方式上存在显著差异。

2.1 Claude Code：系统架构师

博主深度使用过 Claude Code 一段时间，并整理了 《3万字硬核拆解 Claude Code：从入门到工程化落地（建议收藏）》 相关笔记，有兴趣的同学可以阅读，地址：https://yanglinwei.blog.csdn.net/article/details/157426627

我给 CC 的定位是 “系统架构师”，一般复杂难以解决的问题我都会找它去定位，他会帮你想清楚“该怎么做”。

CC 是一种以代码上下文理解为核心的 Coding Agent 路线，其能力重点并不在于“写出多炫的代码”，而在于稳定地理解大规模代码库的结构、语义和意图，通过长上下文窗口和对代码语义一致性的强调，Claude Code 更擅长在已有工程中进行修改、重构和增量式演进。

在使用的过程中，从终端打印的执行日志我们会发现 CC 放弃代码索引的技术，而是使用50年前的grep 搜索技术，实际上是对 “无状态” 设计哲学的现代传承，体现了 “有时候遗忘比记忆更强大” 的智慧。

2.2 OpenAI Codex：全栈工程师

博主也整理 《Codex 全面实战教程：从安装到工程协作，一篇跑通》 相关笔记，有兴趣的同学可以阅读，地址：https://yanglinwei.blog.csdn.net/article/details/157428411

如果说 Claude Code 更像一位从全局出发、先想清楚 “ 该怎么改 ” 的系统架构师，那 OpenAI Codex 更接近 “长期浸泡在真实工程里的全栈开发工程师”，关注点始终是 “下一步该做什么，怎么验证是否做对，直至完成”。

Codex 的核心技术特征并不在于复杂的代码索引或结构建模，而在于一个围绕真实工程动作展开的执行循环（Agent Loop）：模型不断在 读文件 → 改代码 → 跑命令 → 看结果 的过程中迭代前进，用执行反馈而不是静态理解来驱动决策。

关于Agent loop，可以阅读文章：https://openai.com/index/unrolling-the-codex-agent-loop

与 Claude Code 使用 grep 这类“原始但可靠”的工具、强调无状态上下文理解不同，Codex 的设计更偏向 “动作即记忆” —— 状态并不来自长期代码建模，而来自刚刚发生过的执行结果，这使它在修 bug、补测试、跑通流程等工程任务中表现得极其自然，几乎复刻了一名人类工程师在终端里的工作节奏。

从某种意义上说，Codex 并不是在试图 “完全理解代码库”，而是在通过一轮轮可验证的执行，把工程一步步推进到完成。

2.3 Google Gemini 3：前端工程师

博主整理了相关的笔记 《【万字长文】Gemini 3 Pro 全面指南：从免费订阅到 CLI / Agent 实》，有兴趣的童鞋可以阅读下：https://yanglinwei.blog.csdn.net/article/details/157432319

虽然 Gemini 3 的能力覆盖面很广，博主在一段时间的实际使用后，会比较明显地感觉到 它在前端与 UI 相关任务上的表现尤为突出，同时支持在Web端使用 Google 的 AI studio可以实时生成并预览界面。

相比偏重系统结构理解的 Claude Code，或强调执行闭环的 Codex，Gemini 3 在页面结构拆解、组件组织、样式表达以及交互逻辑推理上更为自然，往往能直接给出更贴近真实前端工程习惯的实现方式。在涉及 UI 调整、页面重构或从设计意图出发生成前端代码的场景中，Gemini 3 更关注“界面是否成立”，而不仅仅是代码能否运行，这使它在偏产品导向、体验驱动的工程任务中使用成本更低。

从 Claude Code、OpenAI Codex 到 Gemini 3，可以看到 Coding Agent 并不存在统一的实现路径，而是围绕不同的工程假设，形成了多种侧重点各异的技术路线，可以根据自己的需要去选择。

三、 opencode：把模型变成工程 Agent 的基础设施

博主在前面介绍了三种主流的 Coding Agent，它们的典型使用方式往往是在 终端（Terminal） 或 IDE 插件 里运行，但如果要体验这些工具，大家通常需要先手动安装它们，这个过程对很多人来说比较繁琐，例如这是博主在 IDEA 里安装的三个插件：

有读者可能会问：那为什么不用 Cursor 客户端？

确实，大家可以用 Cursor 或其它外部客户端工具，但这样不可避免需要在 开发环境和客户端之间频繁切换，而大多数开发者已经习惯把工作流程集中在自己熟悉的开发工具中：

• 后端开发更习惯用 IDEA
• 前端开发喜欢用 VS Code

因此许多人更倾向于直接在当前 IDE/终端里使用插件，而不是切换到外部应用。

还有一个问题是无论是 Claude、Codex 还是 Cursor，我们都无法完全知道它们背后的提示词、推理流程，这些都被封装在云端闭源系统里，缺乏透明度。正是在这样的背景下，opencode 的诞生并迅速走红就显得很自然了，下面来详细聊聊它。

3.1 什么是 opencode？

Github 仓库：https://github.com/anomalyco/opencode
opencode 是一个开源的 AI 编程助手 / 编码代理（coding agent），由 anomalyco 社区维护，并以 MIT 协议 完全开源发布在 GitHub 上，截止至当前，已经有 90.4K 的 Star 了，而且还在不断地上涨。

opencode 传统的 AI 编码插件不一样，它不仅仅是一个补全插件，而是一个能 理解项目上下文、分析任务、规划步骤并执行实际改动的智能工具，并支持终端（Terminal）、桌面应用、IDE 扩展等多种界面，也可以通过 API 使用。它还支持使用 超过 75+ 种大型语言模型提供商（如 OpenAI、Anthropic、Google 或本地模型）。

opencode 并不是某一个“更强的模型”，而是一套 “把模型变成工程 Agent 的基础设施”。

3.2 opencode 的优势

opencode 和传统插件/客户端相比的一些显著优势：

• 【100% 开源、透明】：可以看到完整源码、配置和提示词设计，不会像 Copilot、Claude Code 那样是黑盒系统。
• 【多终端和 IDE 支持】：除了终端界面以外，opencode 也有桌面客户端和 IDE 扩展。
• 【支持多种 LLM 提供商】：不锁定单一厂商，你可以使用 Anthropic Claude、OpenAI GPT、Google Gemini 甚至本地模型。
• 【深度理解项目上下文】：通过集成 LSP（Language Server Protocol）等机制，opencode 能实时理解项目结构，而不是简单地基于一条提示生成代码。
• 【自定义配置和 Agents】：可以配置多个专用 agent，分别负责不同任务（如代码生成、调试或搜索），提升协作能力。
• 【客户端/服务端架构】：opencode 是一个 client/server 架构，这意味着你可以在服务器运行核心服务，然后用终端、桌面或其他客户端远程连接使用。

如果你追求 透明性、灵活性和真正与项目深度集成的 AI 编码体验，opencode 是目前生态里非常值得尝试的选择。

四、oh-my-opencode：走向多 Agent 协作的工程形态

Github 仓库：https://github.com/code-yeongyu/oh-my-opencode
oh-my-opencode 是一个基于 OpenCode 的高级插件/扩展，旨在将 OpenCode 从一个单体 Agent扩展成一个 多角色协作的智能 Agent 生态。

简单来说，oh-my-opencode 并不是另一个独立的 Coding Agent，它更像是 为 OpenCode 提供的一套 “全功能 Agent 管理和编排层”，通过预设的专用角色、工具集成与工作流，自带 “电池全装” 的 AI 开发体验。在 opencode 的基础之上，oh-my-opencode 提供：

• 【多角色智能 Agent 编排】：像 Oracle（设计与调试）、Librarian（文档和代码库探索）、Frontend Engineer（前端构建）等多个专用角色协同工作，而不是由单一 Agent 完成全部任务。
• 【后台与子任务执行】：支持后台 Agent 以及并行执行机制，让长任务和大上下文处理更高效。([Oh My OpenCode][2])
• 【深度代码智能工具集】：集成了 LSP、AST 等工具，以及自定义 MCP（Model Context Protocols），增强对项目结构、代码语义和重构操作的处理能力。([DeepWiki][3])
• 【生命周期钩子（Hooks） 与 自动化流程】：通过预设的钩子，你可以控制从分析、执行、验证到后处理等各个阶段，让 Agent 按照定义好的规则完整执行。([DeepWiki][3])

这个设计使得 oh-my-opencode 不只是 “增强版的 opencode”，而是 一个真正面向工程任务的多-Agent协作框架，让不同类型的智能角色能够互相配合，完成复杂、长流程的软件开发任务。

oh-my-opencode与 opencode 原生的区别

特性	OpenCode 原生	oh-my-opencode
Agent 模式	单一 Agent	多 Agent 协作
任务协调	模型自身判断	预设角色 + 编排机制
工具深度集成	基础	包含 LSP、AST、MCP 等
后台执行	否	支持
IDE/终端扩展	支持	进一步完善
用户可配置性	较简单	配置丰富、可定制

从这个对比可以看出，oh-my-opencode 更侧重于 工程级生产力与细粒度控制，适合大型项目和复杂任务。总的来说，oh-my-opencode 是对 OpenCode 的一次工程级扩展，让 AI Agent 的能力从 “一个助手” 进化到 “一个多角色、可编排的开发团队”。

五、 未来已来，Coding Agent 只是开始

在前面的内容中，我们主要讨论了 Coding Agent 如何走入真实的软件工程体系：从理解代码结构，到修改文件、执行命令、运行测试，逐步承担起原本由工程师完成的部分工作。但如果把视角稍微向外延伸，就会发现一个更有意思的趋势：Agent 的能力边界，正在快速溢出 Coding 领域本身。

moltbot（原名 Clawdbot） 并不是一个典型意义上的 Coding Agent，它几乎不关注大型代码库的结构建模，也不试图参与复杂的工程规划，但它所体现的，正是 同一代 Agent 思想在另一个方向上的自然延展。

与前文介绍的 Claude Code、Codex、opencode 运行在 IDE 或终端中的形态不同，moltbot 将交互入口放在了 人们最日常的工具 上：例如 Telegram、WhatsApp、Discord 等即时通讯软件。用户并不是“进入开发环境和 Agent 对话”，而是像发消息一样，向一个 长期在线的执行者下达指令。

在执行层面，moltbot 关注的也不再只是代码文件，而是更贴近真实世界的操作对象：
本地脚本、文件系统、日程、邮件以及各种可自动化的任务流程。它强调的不是“是否理解工程结构”，而是“是否能够在用户授权的环境中，把事情真正做完”。

从能力形态上看，moltbot 更接近一个 通用执行型 Agent：它同样具备目标驱动、工具调用和持续运行的特征，只是服务对象从“软件工程系统”转向了“个人数字环境”。

未来已来，而 Coding Agent 只是开始 ~

六、 一条正在展开的 Agent 演进路径

最后，博主使用 AI 生成了一张图，对全文内容做了一次整体性的抽象总结。

从 ChatGPT 的对话式智能 → 到 Manus 的任务显性化 → 再到 Claude Code / Codex / Gemini 面向真实工程的执行能力 → 继而演进出 OpenCode 这样的 Agent 基础设施、oh-my-opencode 的多 Agent 编排体系 → 直到 moltbot 这种通用执行型 Agent：

这更像是一条 按时间自然展开的技术演进路径，而非一条指向某个“终极形态”的必然路线。

任何 AI 形态的出现，本质上都源于当下工程条件、使用场景与现实需求的阶段性选择，而不是未来的唯一答案。面对层出不穷的 AI 概念与工具，与其被技术浪潮裹挟，不如保持清醒，建立自己的判断边界。

在不放弃独立思考能力的前提下，选择性地与 AI 共舞，才是我们真正可持续的进化方式 ~