乐于分享
好东西不私藏

同样叫"智能体" 豆包、OpenClaw、Codex 的架构差多远?

同样叫"智能体" 豆包、OpenClaw、Codex 的架构差多远?

都叫 Agent,但一个像”会聊天的知识库”,一个像”住在微信里的管家”,一个像”关在沙箱里的程序员”。这篇讲清楚它们内部到底怎么搭的。

三种截然不同的智能体设计取向人设豆包智能体提示词 + 知识库配置式 · 低代码面向:C端场景助手OpenClaw网关 + 多渠道 + 技能常驻式 · 主动触发面向:个人全能管家Codex沙箱 + 多智能体分工工程式 · 审批把关面向:软件工程任务

图 1 三种智能体,三种设计哲学:配置式、常驻式、工程式

上一篇我们讲了 Agent 的通用工作循环——”感知—思考—行动”。但这只是骨架,真正决定一个 Agent 好不好用、敢不敢放权的,是骨架之外具体怎么搭的架构。今天用豆包智能体、OpenClaw、Codex 这三个真实产品,看看同一个”Agent”概念,能长出多不一样的身体。

📌 时效说明:豆包官方已发布公告,其”智能体”自定义功能将于 2026 年 7 月 15 日下线,后续相关能力迁移至字节跳动旗下的”猫箱”App。本文写作于功能下线前,借它来讲解这一类”配置式智能体”的设计思路,架构逻辑本身在猫箱等产品上仍然适用。

01 豆包智能体:配置式,”给模型换个人设”

在豆包里创建一个智能体,本质上你在做三件事:给它取个人设(法律顾问、编程导师……)、写一段系统提示词限定语气和能力边界、再上传一份知识库作为专属参考资料。之后每个智能体拥有独立的对话记忆,切换角色不会串戏。

系统提示词人设 / 语气 / 边界知识库上传文档 / 检索增强大语言模型豆包 Pro 系列对话回复独立记忆 · 不串角色

图 2 豆包智能体的架构:提示词 + 知识库 → 模型 → 带记忆的对话

这种架构的关键词是“配置”而不是”编程”:普通用户不用写一行代码,靠填表单和上传文档就能拥有一个专属 AI 角色。它擅长的是知识问答、角色扮演、垂直领域陪聊,但它默认没有浏览器、没有命令行,不会自己去帮你点外卖、发邮件——它的能力边界基本就是”模型 + 知识库”划出来的那个圈。值得一提的是,豆包专业版也在往”能办事”的方向探索,比如一句话生成一份完整调研报告或课件 PPT,这背后其实是在这套配置式架构上叠加了任务拆解和工具调用能力,只是目前还没有下放到普通”智能体”这个轻量功能里。

02 OpenClaw:常驻式,”住在你聊天软件里的管家”

OpenClaw 是一个开源项目,思路完全不同:它不追求”一个网页里的对话框”,而是把自己变成一个常驻后台的网关(Gateway),接入你已经在用的微信、Telegram、Discord、Slack 等几十种聊天软件,你在哪个软件里给它发消息,它就在哪回你。

微信 / TelegramDiscord / SlackWhatsApp / 更多Gateway网关 · 自托管心跳定时唤醒大脑:可换任意模型技能 Skills(社区市场)本地记忆(Markdown 文件)每隔一段时间自动”心跳”检查待办,无需你先开口

图 3 OpenClaw:多渠道网关 + 可换大脑 + 技能市场 + 本地记忆

它的几个设计特点很有意思:

大脑可替换

它自己不训练模型,而是把 Claude、GPT、DeepSeek 等模型当”外接大脑”接入,你可以随时切换,甚至混用便宜模型和贵模型。

技能可扩展

每个”技能”是一个带说明文档的功能包(比如”帮我查日历””同步备份”),来自社区市场,装上就能用,类似手机 App Store。

会”主动”找你

靠一个定时”心跳”机制,它会隔一段时间自己醒来检查有没有该做的事,而不是永远等你先说话——这也是它和普通聊天机器人最大的不同。

⚠️ 硬币的另一面:因为它需要读邮件、控制浏览器、操作日历等大量权限,安全研究者也指出过风险——比如被恶意”技能”注入指令、误读消息做出不该做的操作。用它,本质是在用便利性换取一部分风险,需要谨慎配置权限。

03 Codex:工程式,”关在沙箱里、按规矩办事的程序员”

OpenAI 的 Codex 瞄准的是一个更严肃的场景:写代码。它的架构明显是”工程师视角”搭出来的——追求的不是好玩、好聊,而是可控、可审查、可并行

主 Agent拆解任务子任务 A独立沙箱执行子任务 B独立沙箱执行子任务 C独立沙箱执行自动审查 → 人工审批 → 合并 PR测试 / 代码检查 / diff 展示

图 4 Codex:主 Agent 拆解任务 → 子 Agent 并行沙箱执行 → 自动审查 → 人工确认

拆开来看,Codex 有几个”工程化”的关键机制:

  • 沙箱隔离
    :每个任务都在独立的、限制了系统权限甚至断网的沙箱里跑,写坏了也不影响真实环境。
  • 审批分级
    :从”每一步都要你点头”到”全自动跑但仍产出 PR 供审查”,权限粒度可以按团队信任程度调整。
  • 多智能体并行
    :一个复杂任务会被拆成互不干扰的子任务,分别在各自沙箱里同时推进,效率更接近一个小型虚拟团队,而不是一个人埋头苦干。
  • AGENTS.md 上下文
    :项目里放一份说明文件,告诉 Codex 这个代码库的规范、如何跑测试,相当于给新人程序员的”入职文档”。
  • 结果不直接落地
    :Codex 默认只生成 Pull Request,而不是直接改动主分支,人依然是代码合入的最终把关人。

可以看到,Codex 的架构选择处处透露着”这是要用在真实生产系统上的”这种谨慎——它的”自由度”不是体现在权限有多大,而是体现在任务拆解和并行执行的效率上。

04 放在一起看:三种架构怎么选

维度
豆包智能体
OpenClaw
Codex
设计取向
配置式知识助手
常驻式个人管家
工程式编程队友
核心组成
提示词 + 知识库
网关 + 渠道 + 技能 + 记忆
沙箱 + 多智能体 + 审批
触发方式
用户主动提问
被动响应 + 定时”心跳”主动触发
接到任务后自动拆解执行
模型绑定
豆包自家模型
任意模型可插拔
OpenAI 系模型为主,支持接入其他模型
典型用户
普通消费者
技术爱好者 / 效率党
软件开发者 / 工程团队
主要风险点
能力边界有限,出圈的事做不了
权限开放大,需防误操作与提示注入
使用与算力成本较高

三者没有谁更”高级”,只是解决的问题不同:豆包智能体把复杂度留给平台、把简单留给用户,适合快速拥有一个懂行的聊天角色;OpenClaw 把控制权留给用户自己,代价是要承担更多配置和安全责任;Codex 把可靠性放在第一位,用沙箱和审批换取”能放心用在真实代码库上”的信任。

一句话理解:智能体的架构差异,本质是在”好用”与”可控”之间做的不同取舍。