上一篇聊了 Agent 是什么。这篇拆引擎盖——三款产品底层到底怎么跑的。
我不贴源码，但会把架构画清楚。我自己是这三款产品的日常用户，所以很多判断来自真实体感，不是看文档脑补的。产品经理看架构差异能做更好的决策，开发者看设计思路可以直接抄作业。
一、Agent 的通用架构：先画一张底图
不管哪款 Agent 产品，底层都跑同一个模式——Agent Loop（智能体循环）。我第一次真正理解这个循环，是在用 Claude Code 调试一个跨文件的 bug 时：它读代码、猜原因、改一行、跑测试、发现不对、再读、再改……来回转了十几圈才搞定。那一刻我意识到，这个"循环"不是概念，是 Agent 的心脏。
三款产品的区别就在于：这个循环怎么实现、循环里塞了什么东西、循环跑在哪里。Claude Code 跑在你的终端里，一次一个循环；Codex 在云端开 N 个沙盒并行跑；OpenClaw 在一个常驻进程里跑，还能定时自己启动循环。同一个心脏，三种跳法。
二、Claude Code：极致专注的单线程架构
2.1 整体架构
Claude Code 的架构哲学四个字：简单直接。
一个终端进程，一个 Agent Loop，一个上下文窗口。没有后台服务，没有云端调度，所有事情都在这一个进程里完成。你在终端敲 claude，启动一个 Node.js 进程，它接收你的输入、调 Claude API 推理、执行工具、把结果喂回模型、继续下一轮。
整个过程是同步阻塞的——模型在想的时候你等着，工具在跑的时候模型等着。一次只做一件事，但做得很深。
我觉得这个设计很聪明。可预测性是 Agent 产品最稀缺的品质，你能清楚地知道它在干什么、干到哪一步了。代价是不能并行，一个会话同时只能处理一个任务——但对终端编程场景来说，这个代价完全可以接受。
2.2 Agent Loop 的三阶段
Claude Code 的 Agent Loop 分三个阶段。说"阶段"其实不太准确，它们更像是交织在一起反复运转的齿轮。
加载配置 / CLAUDE.md / Skills
思考 → 工具调用 → 观察结果 → 循环
生成回复 / 总结变更
Init 阶段：搞清楚"我是谁、我在哪"
每次你输入一条指令，Agent 先做一轮上下文收集：读取 CLAUDE.md（项目级配置，相当于项目的"使用说明书"）、加载已启用的 Skills 描述、加载 MCP 工具定义、回顾对话历史。
举个例子：我在一个 Next.js 项目里让 Claude Code "把首页的加载速度优化一下"。Init 阶段它会读 CLAUDE.md 里写的"本项目用 App Router，CSS 用 Tailwind，测试用 Vitest"，这些信息决定了它后面怎么干活。没有这一步，它可能会给你写 Pages Router 的代码。
Agentic Loop：核心战斗循环
上下文打包发给 Claude API，模型返回下一步操作——可能是调用工具（读文件、执行命令、搜索代码），可能是直接回答，也可能是追问你要更多信息。
如果是工具调用，执行完把结果塞回上下文，进入下一轮。这个循环可能转几十圈。我亲眼看过一次 Claude Code 修一个跨三个文件的类型错误：读文件 → 分析依赖 → 改第一个文件 → 跑 tsc → 发现另一个报错 → 读那个文件 → 改 → 再跑 → 过了。前后转了 8 圈，全程没问我一句话。
Shutdown：收工汇报
循环结束后，模型生成最终回复，总结做了什么改动。如果改了代码，会列出改了哪些文件、改了什么。这一步看起来简单，但对用户信任很重要——你得知道 Agent 到底动了什么。
2.3 工具系统：三层设计
Claude Code 的工具分三层，这个分层我觉得很值得抄：
第一层：内置工具——开箱即用的核心操作。文件读写（Read/Edit/Write）、搜索（Grep/Glob）、命令执行（Bash）、网络请求（WebFetch/WebSearch）、代码智能（跳转定义、查找引用）。覆盖了 80% 的编程场景，不需要任何配置。
第二层：Skills——用户自定义的工作流模板。每个 Skill 是一个目录，里面有个 SKILL.md 描述这个技能能做什么、怎么做。聪明的地方在于按需加载：系统提示词里只放 Skills 的名字和一句话描述，模型判断需要用某个 Skill 时才去读完整内容。你装了 50 个 Skills 也不会撑爆上下文。
第三层：MCP 服务器——通过 MCP 协议连接的外部工具。每个 MCP Server 暴露一组工具，Claude Code 把工具定义合并到系统提示词中。但这里有个坑我踩过：每个 MCP Server 的工具定义都占上下文空间，即使你没在用它。装太多 MCP Server 会导致上下文浪费。Claude Code 的应对是当工具定义超过上下文的 10% 时启动"工具搜索"机制，延迟加载。
2.4 权限控制
Claude Code 的权限设计分两道防线，我觉得这个思路对所有 Agent 产品都适用。
第一道：权限模式。四档可选——default（每次敏感操作都问你）、acceptEdits（自动接受文件编辑，命令还是要确认）、plan（只读模式，只分析不动手）、bypassPermissions（完全跳过检查，别用）。我日常用 acceptEdits，让它自由改代码但不能乱跑命令，平衡了效率和安全。
第二道：沙盒。操作系统层面限制 Agent 能访问的文件和网络。权限控制的是"Agent 想做什么"，沙盒控制的是"Agent 实际能碰什么"。两层叠加，内外夹击。
权限规则还能精确到具体命令和路径——允许 npm run test 但禁止 rm -rf，允许读 .env 但禁止读 .env.production。规则按 deny → ask → allow 顺序匹配，第一个命中的生效。
Agent 产品的安全不能只靠一层。用户信任是 Agent 产品的生命线，丢了就回不来。
2.5 上下文管理
大模型有上下文窗口限制（Claude 目前 200K token）。长时间干活，对话历史越来越长，最终会撑满。Claude Code 有三招应对：
自动压缩（Compact）：上下文接近上限时，自动总结之前的对话，用精简版替换原始内容。像人的记忆——你不会记住每句话的原文，但记得关键信息。我在长会话里用过几次，压缩后偶尔会丢一些细节（比如忘了之前约定的变量命名），但整体还是流畅的。
子代理：把子任务派给独立的 Agent 会话。子代理有自己的上下文窗口，不污染主会话，做完只把结果返回。处理大文件重构时特别好用——主会话负责规划，子代理负责执行单个文件的改动。
CLAUDE.md 项目记忆：项目级持久化配置，不管开多少次新会话都会被加载。适合存项目约定、代码规范、常用命令。相当于给 Agent 一本永远带在身上的笔记本。
2.6 小结
Claude Code 像一个专注的手艺人——一次只做一件事，但做得精细。简单架构带来了可预测性和可靠性，代价是不能并行、不能后台运行。对于"坐在终端前写代码"这个场景，这是一个很正确的取舍。
三、OpenAI Codex：云端并行的工厂模式
3.1 整体架构
Codex 的架构思路跟 Claude Code 完全相反。Claude Code 是一个手艺人，Codex 是一座工厂。
核心设计：每个任务跑在独立的云端沙盒里，预加载了你的代码仓库副本。任务之间完全隔离，互不影响。你可以同时丢 5 个任务给 Codex，它在 5 个独立环境里并行处理，一个挂了不影响其他的。
为什么这么设计？我觉得原因很实际——OpenAI 有 ChatGPT 这个巨大的流量入口，用户量级决定了它必须用云端架构来承载。本地跑进程的方案在这个量级下行不通。而且云端沙盒天然解决了安全问题：Agent 的所有操作都在隔离环境里，搞不坏你的本地机器。
3.2 codex-1 模型
Codex 底层不是通用的 GPT，而是专门为编程优化的 codex-1。
codex-1 基于 o3，通过强化学习在真实编程任务上训练。它生成的代码风格接近人类（不是那种一看就是 AI 写的模板代码），能理解项目的 PR 偏好和代码规范，遇到测试失败会自己迭代修改直到通过。SWE-Bench Verified 上拿了 75.6% 的通过率。
说实话，专门训一个编程模型这件事，只有 OpenAI 这种体量的公司才做得起。但效果确实好——同样的任务，codex-1 生成的代码比通用模型更"像人写的"，review 的时候心理负担小很多。
3.3 三种使用形态
Codex 不是一个产品，是一个产品家族：
Web 版（chatgpt.com/codex）：在 ChatGPT 侧边栏里直接用，连接 GitHub 仓库，给任务就行。最方便，适合日常使用。
CLI 版：npm install -g @openai/codex，终端里用。开源的（Apache-2.0），代码在 GitHub 上。适合喜欢终端的开发者。
IDE 插件：VS Code、Cursor、Windsurf 都能装。编辑器里直接交互，还能把任务委托到云端执行。
三种形态共享同一个后端。我个人最常用 Web 版，因为可以开着 ChatGPT 一边聊天一边给 Codex 派任务，不用切窗口。
3.4 GitHub 深度集成
Codex 跟 GitHub 的集成是它最大的差异化卖点。
你可以在 GitHub 的 Issue 或 PR 里 @codex，它自动创建云端任务去处理。比如有人提了一个 bug issue，你在评论里写 @codex 请修复这个 bug，它就会克隆仓库到沙盒、分析 issue、定位问题、修复、跑测试、创建 PR 给你审查。整个过程你不需要打开编辑器。
这个工作流对开源项目维护者来说是杀手级的。想象一下，你的仓库每天收到 20 个 issue，以前要一个个看、一个个修。现在可以批量 @codex，让它并行处理，你只需要 review PR。从"自己修 bug"变成"审查别人（AI）修的 bug"，角色完全变了。
但也有局限——Codex 只能处理代码仓库里的事情。你让它帮你写个邮件、查个天气，它做不了。这是架构决定的：沙盒里只有代码环境，没有其他能力。
3.5 AGENTS.md 配置
跟 Claude Code 的 CLAUDE.md 类似，Codex 用 AGENTS.md 来配置项目级指令——目录结构说明、测试怎么跑、代码规范、哪些文件不要动。每次执行任务前都会读这个文件，相当于新员工入职先看公司手册。
有意思的是，这两个文件的命名暴露了两家公司的产品思路：Anthropic 用自家产品名（CLAUDE.md），OpenAI 用通用概念（AGENTS.md）。一个在建品牌壁垒，一个在推行业标准。
3.6 安全：沙盒隔离
每个任务跑在独立的云端沙盒里，默认断网。Agent 不能把你的代码发到外面，不能下载恶意依赖，任务之间完全隔离。需要网络访问（比如装依赖）可以手动开启。
这个安全模型比 Claude Code 的更简单粗暴，但也更可靠——不需要配置复杂的权限规则，物理隔离就是最好的安全。代价是灵活性差一些，有些需要网络的操作会比较麻烦。
3.7 小结
Codex 像一座现代化工厂——标准化、可并行、有隔离。它把"编程 Agent"做到了产品化的极致，GitHub 集成是真正的护城河。但也因此被锁死在编程场景里，你不能拿它当通用助手用。这是一个有意识的产品选择，不是技术限制。
四、OpenClaw：全场景的瑞士军刀架构
4.1 整体架构
OpenClaw 的架构是三者中最复杂的，因为它要解决的问题也最复杂——不只是编程，而是"成为一个全能 AI 助手"。我自己每天都在用 OpenClaw，所以这部分会讲得更细。
最大的架构特点是 Gateway + Client 分离。Gateway 是一个常驻后台的守护进程（daemon），7×24 小时运行，负责接收各渠道消息、管理会话、调度模型。
这跟 Claude Code 和 Codex 都不一样——它们是"用的时候启动，用完就关"，OpenClaw 是"一直在线，随时待命"。这个区别看起来只是技术细节，但它从根本上改变了 Agent 的能力边界：一个永远在线的 Agent 才能做定时任务、主动提醒、后台监控这些事情。
4.2 多渠道路由
OpenClaw 能同时连接十几个聊天渠道：飞书、QQ Bot、钉钉、企业微信、Telegram、Discord、Signal、WhatsApp……
Gateway 里有一个路由层，把不同渠道来的消息分发到正确的会话。你在飞书上跟它说的话和在 QQ 上说的话，可以是同一个会话（共享上下文），也可以是独立的。
我自己飞书和 QQ 两个渠道都在用。工作时间在飞书上让它帮我处理文档和日程，下班后在 QQ 上让它帮我查资料、写东西。不管在哪个 App 里，都能找到它，上下文还是连续的。这种"跨平台无缝"的体验，是单渠道产品做不到的。
4.3 Skill 插件系统
OpenClaw 的工具扩展机制叫 Skill，跟 Claude Code 的 Skills 思路类似，但生态更开放。
每个 Skill 是一个独立目录，包含 SKILL.md（说明文件）和可能的脚本、配置。社区有个 Skill 市场（clawhub.com），一键安装。我装了不少：天气查询、股票分析、YouTube 字幕提取、图片生成、PDF 处理、去 AI 味的文本润色……
举个真实例子：我写完一篇博客初稿后，会让 OpenClaw 用 humanizer 这个 Skill 做一轮审查——它会逐条检查 AI 写作的常见特征（三连排比、假大空总结、"值得注意的是"之类的废话），然后给出修改建议。这个 Skill 是我自己写的，花了半小时，但每篇文章都能省我 20 分钟的人工审查时间。
Skill 的加载也是按需的，系统提示词里只放描述，用到时才读完整内容。这个设计跟 Claude Code 一样，是 Agent 产品处理"工具太多"问题的标准解法。
4.4 记忆系统：三层架构
这是 OpenClaw 最让我惊喜的设计。
第一层：会话内记忆（短期）——当前对话的上下文，有窗口限制，会自动压缩。跟所有 Agent 一样。
第二层：日志记忆（中期）——每天的工作记录存在 memory/YYYY-MM-DD.md 文件里。Agent 每次启动会读最近两天的日志，了解近期发生了什么。比如昨天我让它帮我调研了一个竞品，今天我说"继续昨天的调研"，它能接上，因为昨天的日志里有记录。
第三层：长期记忆（MEMORY.md）——Agent 自己维护的"人生经验"。它会定期回顾日志，把重要的事情提炼进去：用户的偏好、项目状态、踩过的坑、学到的教训。我用了两个月，它已经知道我喜欢简洁的写作风格、知道我的项目用什么技术栈、知道我周三晚上通常有空做深度工作。
还有个 SOUL.md 文件，定义 Agent 的"性格"——说话风格、行为准则、价值观。你可以让它幽默、严肃、或者像某个特定角色。这个文件的存在让 OpenClaw 从"工具"变成了"角色"，用起来的感觉完全不一样。
坦白说，这套记忆系统也有问题。MEMORY.md 会越写越长，长到影响上下文空间；日志文件如果不定期清理也会堆积。我现在的做法是每周手动检查一次 MEMORY.md，删掉过时的内容。这个维护成本不算高，但确实存在。
4.5 心跳机制
大部分 Agent 是被动的——你找它，它才响应。OpenClaw 不一样，它有心跳（Heartbeat）。
Gateway 每隔 30 分钟给 Agent 发一个心跳信号。Agent 收到后，按 HEARTBEAT.md 里的清单做检查：有没有新的 GitHub 通知？有没有即将到来的日程？记忆文件需不需要整理？如果有事，主动给你发消息；没事就安静待着。
我配了一条规则：如果发现我的 GitHub 仓库有新的 issue 或 PR，就通过 QQ 通知我。上周有人给我的开源项目提了个 PR，我正在外面吃饭，QQ 弹了条消息告诉我。这种"Agent 主动找你"的体验，用过就回不去了。
当然，这个机制也有翻车的时候。有一次我配错了心跳规则，它每 30 分钟给我发一条"一切正常"的消息，半夜被吵醒。后来我加了个时间段限制：23:00-08:00 之间不要主动发消息。
4.6 Cron 定时任务
OpenClaw 内置了 Cron 引擎，可以设置定时任务。每个 Cron 任务跑在独立会话里，不影响主会话。
我在用的几个：每天早上 9 点检查邮件摘要推送给我；每周一和周四自动整理 AI 领域热文到飞书文档；每周三晚上 9 点做一次产品竞品动态扫描。
Cron 和心跳的区别：心跳是"定期巡逻，有事汇报"，Cron 是"到点执行特定任务"。心跳适合不确定什么时候会发生的事情，Cron 适合有固定时间表的工作。两个机制配合用，覆盖了大部分"主动性"需求。
4.7 模型无关
OpenClaw 不绑定任何模型厂商。你可以配置多个模型提供商，设置故障转移链：主力模型挂了自动切备用，备用也挂了切第三个。
我的配置是 Claude Opus → Kimi K2.5 → Gemini。日常用 Opus，Anthropic API 偶尔抽风时自动切到 Kimi，用户端完全无感知。子代理用便宜的 Flash 模型省钱，主会话用贵的模型保质量。
这个设计在产品层面很重要——不把鸡蛋放一个篮子里。2025 年各家 API 的稳定性都不算好，有故障转移才能保证 7×24 可用。
4.8 子代理系统
跟 Claude Code 的子代理类似，但更灵活：可以指定不同模型（主会话用 Opus，子代理用 Flash 省钱）、可以设超时、完成后自动汇报回主会话、可以贴标签方便管理。
我写这篇文章的时候就在用子代理——主会话负责规划大纲和审查质量，子代理负责执行具体章节的写作和优化。主会话的上下文不会被大量写作内容撑爆，子代理做完就释放。这个模式处理长文写作特别顺手。
4.9 小结
OpenClaw 的架构像一个操作系统——有进程管理（会话）、有文件系统（记忆）、有定时器（Cron）、有网络（多渠道）、有插件（Skills）。它不是为某个场景优化的工具，而是一个通用的 Agent 运行平台。
代价是复杂度高。部署需要自己搞服务器，配置项多，学习曲线陡。如果你只是想要一个编程助手，OpenClaw 有点过度设计了。但如果你想要一个"什么都能干的 AI 伙伴"，目前没有比它更合适的选择。
五、架构对比：一张表看清差异
把三款产品放在一起看，架构差异背后是产品定位的差异。
| 维度 | Claude Code | OpenAI Codex | OpenClaw |
|---|---|---|---|
| 架构模式 | 单进程单会话 | 云端多沙盒 | Gateway 守护进程 |
| 运行位置 | 本地终端 | 云端 | 自部署服务器 |
| 并发能力 | 单任务 | 多任务并行 | 子代理并行 |
| 工具扩展 | Skills + MCP | AGENTS.md + 内置 | Skills + MCP + 社区市场 |
| 记忆系统 | CLAUDE.md + 上下文压缩 | AGENTS.md | 三层记忆 + SOUL.md |
| 主动性 | 被动响应 | GitHub 事件触发 | 心跳 + Cron 主动推送 |
| 模型绑定 | Claude 系列 | codex-1 / OpenAI | 任意模型，可故障转移 |
| 多渠道 | 仅终端 | Web/CLI/IDE | 10+ 聊天渠道 |
| 安全模型 | 权限规则 + 沙盒 | 云端沙盒隔离 | 权限 + 沙盒 |
| 开源 | 否 | CLI 开源 | 完全开源 |
| 持久运行 | 否 | 任务期间 | 7×24 常驻 |
我的看法：没有"最好"的架构，只有最适合场景的。
Claude Code 适合"我就想安静写代码"的开发者。架构简单，心智负担低，打开终端就能用。它的局限在这个场景下反而是优点——少即是多。
Codex 适合团队协作和 GitHub 重度用户。并行处理多个 issue、自动创建 PR、跟 CI/CD 打通——这些是团队场景的刚需。但它被锁在 OpenAI 生态和编程场景里。
OpenClaw 适合想要一个"全能 AI 伙伴"的人。多渠道、多模型、记忆系统、定时任务——能力边界最宽。代价是部署和维护成本高，不适合只想开箱即用的人。
一个有趣的观察：三款产品的架构复杂度跟目标场景宽度成正比。场景越窄，架构越简单；场景越宽，架构越复杂。这不是巧合。
六、MCP 协议：Agent 的"USB-C 接口"
三款产品都面对同一个问题：Agent 怎么连接外部工具？
以前的做法是每个工具写一套定制代码。接 GitHub 写一套，接数据库写一套，接邮件写一套。换个 AI 平台，全部重写。这跟手机充电线的混乱年代一模一样。
MCP（Model Context Protocol）就是 Agent 世界的 USB-C。Anthropic 2024 年 11 月发布，到 2026 年已经成了事实标准。核心思路：统一 Agent 连接工具的接口。写一个 MCP Server，所有支持 MCP 的 Agent 都能用，不用为每个平台单独适配。
MCP 有三个角色：Client（Agent 这边，Claude Code 和 OpenClaw 都是 Client）、Server（工具那边，每个 MCP Server 封装一组工具）、Protocol（两边对话的规矩，基于 JSON-RPC 2.0）。
Claude Code 和 OpenClaw 都原生支持 MCP。Codex 目前主要靠内置工具和 AGENTS.md 扩展能力，MCP 支持在逐步完善中。
我个人的判断：MCP 会成为 Agent 生态的基础设施，就像 HTTP 之于 Web。现在写 MCP Server 的投入，未来会有很好的复用回报。
七、写在最后
拆完三款产品的架构，我最大的感受是：架构选择就是产品哲学的外化。
Claude Code 说"我帮你写好代码就行"，所以它的架构极简——一个进程、一个循环、一个窗口。Codex 说"我帮整个团队处理代码任务"，所以它搞了云端沙盒和并行调度。OpenClaw 说"我想成为你的 AI 伙伴"，所以它搭了一个小型操作系统。
作为产品经理，我从中学到的最重要的一课是：先想清楚你要解决什么问题，再决定架构。不是架构越复杂越好，也不是越简单越好。Claude Code 的简单不是偷懒，OpenClaw 的复杂不是炫技。它们都是在自己的场景下做了正确的取舍。
下一篇，我们从架构跳到产品设计层面。作为产品经理，能从这三款产品的交互设计、用户体验、商业模式中学到什么？怎么把这些思路用到自己的产品里？
Allen | AI 产品经理 | allen00.top