系列文章（3/4）| 作者：Allen | allen00.top
前两篇拆完了 Agent 的概念和三款产品的架构，这篇聊点我自己的东西——作为一个同时用着 Claude Code、Codex 和 OpenClaw 的产品经理，我在设计自己产品的过程中踩了哪些坑，又从这三款产品里偷师了哪些设计思路。
不讲代码，讲选择。每个产品决策背后都有取舍，我想把这些取舍掰开了说。
一、Agent 产品的五个核心设计决策
做 Agent 产品绕不开五个选择题。没有标准答案，但有明确的取舍逻辑。我把自己踩过的坑和从三款产品里学到的经验放在一起说。
| 决策维度 | Claude Code | Codex | OpenClaw | 我的倾向 |
|---|---|---|---|---|
| 运行环境 | 本地终端 | 云端沙盒 | 自部署服务器 | 看场景 ↓ |
| 任务模式 | 单任务深度 | 多任务并行 | 单线程 + 子代理 | 单任务为主 |
| 工具系统 | 内置 + MCP | 内置 + AGENTS.md | Skill 插件生态 | MCP 优先 |
| 记忆深度 | 项目级 | 任务级 | 三层体系 | 越深越好 |
| 安全策略 | 多层权限 | 沙盒 + 断网 | 信任模型 | 渐进信任 |
决策一：本地运行还是云端运行？
这个决策我纠结了很久。Claude Code 跑在本地终端，Codex 跑在云端沙盒，OpenClaw 跑在自己的服务器上。三条路，我都走过。
说个真实体验：我用 Claude Code 重构一个项目，整个过程代码不出本机，改完直接 git push，心里很踏实。但有一次我想让它帮我同时处理三个独立模块的 bug，做不到——它是单线程的，关了终端就停了。
Codex 的云端模式解决了并行问题，五个任务同时跑，爽是爽。但说实话，我觉得 Codex 的云端模式其实是一种妥协——OpenAI 的模型推理本身就在云端，与其让用户本地跑一个壳子远程调 API，不如干脆把整个执行环境都搬到云上，顺便解决了环境一致性的问题。这不是"云端更好"的技术判断，而是"既然都要联网，不如做彻底"的产品判断。代价是你的代码得上传到别人的服务器——对个人项目无所谓，对企业客户是硬伤。
OpenClaw 走了第三条路：你自己搞台服务器，Agent 7×24 在线。我现在就是这么用的，体验确实好——随时能找它，不用开电脑。但运维成本是真实的，服务器配置、网络调试、进程管理，这些对非技术用户是劝退项。
我的判断框架：
- 用户是开发者、数据敏感 → 本地优先（Claude Code 路线）
- 用户要并行、要省心 → 云端优先（Codex 路线）
- 用户要全天候在线、要完全可控 → 自部署（OpenClaw 路线）
没有最优解，只有最适合你用户的解。
决策二：单任务还是多任务并行？
这个问题我一开始想错了。看到 Codex 能同时跑五个任务，我第一反应是"这才是未来"。后来实际用下来，发现没那么简单。
Claude Code 一次只做一件事，听起来落后，但用起来有个巨大的好处：你能完整地看到 Agent 的思考过程和每一步操作。它改了哪个文件、为什么改、改完跑了什么测试——全在你眼前。出了问题，三秒定位。这种透明感在处理复杂重构时特别重要，你不会想让一个你看不懂在干嘛的 Agent 去动核心模块。
Codex 的并行确实快。五个独立 bug 同时修，效率是 Claude Code 的五倍。但 Codex 为了实现并行付出了很大代价——每个任务一个完整的沙盒环境，每个沙盒都要克隆一份代码仓库。资源消耗是实打实的，这也是为什么它必须跑在云端。
我在设计 OpenClaw 的使用方式时选了一个折中方案：主线程单任务，但可以派子代理（subagent）去处理独立的子任务。主 Agent 像项目经理一样分活、收结果，子代理各干各的。这样既保留了主线程的可控性，又能在需要时并行。实际用下来，大部分时候单线程够用，偶尔派个子代理处理耗时任务（比如读一堆文档做汇总），体验比全并行更顺手。
我的结论：并行是锦上添花，不是刚需。先把单任务体验做到极致，再考虑并行。如果你的用户场景里任务天然是串行的（"先分析数据，再写报告，最后发邮件"），强行做并行反而增加理解成本。
决策三：工具系统怎么设计？
Agent 能做什么，取决于它手里有什么工具。这个决策直接决定了产品的天花板。
三款产品走了三条不同的路，我都体验过，感受很不一样：
Claude Code 是"内置 + MCP"的组合。核心操作（读写文件、跑命令、搜索代码）内置搞定，外部服务通过 MCP 协议接入。我给它接过 GitHub MCP、Sentry MCP，配置完就能用，不用写一行胶水代码。这个体验很丝滑。
Codex 更封闭一些，主要靠内置工具加上 AGENTS.md 里的项目配置。它和 GitHub 的集成做得很深——直接从 issue 接任务、自动开 PR、跑 CI。但如果你想接一个 GitHub 之外的服务，就没那么方便了。
OpenClaw 走的是插件生态路线。内置工具不多，大量能力通过 Skill 插件提供，社区（clawhub.com）里有各种现成的 Skill 可以装。好处是灵活，什么都能接；坏处是质量参差不齐，有些 Skill 文档写得一言难尽。
我在这个问题上的观点很明确：MCP 是当前最值得押注的方向。
道理很简单——MCP 做的事情就像 USB-C 统一了充电接口。以前每个 AI 产品接外部工具都要写一套定制适配，现在有了统一协议，写一次适配所有 Agent。Claude Code 已经全面支持 MCP，OpenClaw 也在跟进，连 Cursor 这样的编辑器都接了 MCP。如果你现在开始做 Agent 产品，工具系统不支持 MCP 就是给自己挖坑——等生态起来了再补，迁移成本会很高。
决策四：记忆怎么做？
这是我踩坑最多的一个决策。
一开始我觉得记忆没那么重要——Agent 不就是个工具吗，用完就走，记什么记？直到我用 OpenClaw 用了两个月，才真正理解记忆系统的价值。
先说三款产品的差异。Claude Code 的记忆是项目级的：一个 CLAUDE.md 文件存项目约定（代码风格、技术栈、常用命令），对话过程中有上下文压缩。但跨会话？不好意思，每次重新开聊都是陌生人。我经常要重复告诉它"这个项目用 pnpm 不用 npm""测试用 vitest 不用 jest"，烦。
Codex 更极端——每个任务完全独立，任务之间零记忆。它把 GitHub 的 issue 和 PR 当"外部记忆"用，某种程度上也算一种巧妙的设计：不是我记不住，是我把记忆外包给了 GitHub。
OpenClaw 的记忆体系是我见过最完整的。三层：会话内上下文（短期）、每日工作日志 memory/YYYY-MM-DD.md（中期）、MEMORY.md 长期记忆（长期）。还有个 SOUL.md 定义 Agent 的"性格"。我现在的 OpenClaw 记得我的技术栈偏好、写作风格、常用工具链，甚至知道我周末不喜欢被打扰。这种"越用越懂你"的感觉，是没有记忆的 Agent 给不了的。
我在设计自己的产品时借鉴了 OpenClaw 的记忆模型，但做了简化：只做两层——项目配置文件（类似 CLAUDE.md）加一个用户偏好文件（跨项目持久化）。三层记忆对个人助手场景是合理的，但对专注某个垂直领域的工具型 Agent 来说，两层够用，多了反而增加维护负担。
记忆深度要匹配产品定位。一次性工具不需要记忆，长期助手必须有记忆，垂直工具取中间值。别照搬，想清楚你的 Agent 和用户是什么关系。
决策五：安全边界在哪？
Agent 能自主行动，这是它的价值，也是用户最大的恐惧来源。"它会不会删我的文件？""它会不会把代码发到外面？"——这些担心不是多余的，是你必须正面回答的产品问题。
我在设计自己的产品时，研究了三款产品的安全策略，学到的最重要一课是：安全感比安全本身更重要。
Claude Code 的权限模型是我见过设计得最细致的。它有三档权限模式：默认每次敏感操作都弹确认框（烦但踏实），中间档可以设白名单（常用命令自动放行），最高档全自动（老手专用）。更厉害的是权限规则可以精确到具体命令和文件路径——"允许运行 npm test，但不允许运行 rm -rf"。我在设计自己产品的权限系统时，直接借鉴了这个分级思路：新用户默认保守，用出信任了再逐步放开。
Codex 的安全策略更简单粗暴：沙盒隔离 + 默认断网。每个任务跑在独立容器里，默认不能访问互联网，所有代码改动必须人工审查后才能合并到主分支。这招对企业用户特别有效——CTO 最怕的就是 AI 偷偷把代码传出去，Codex 直接把网断了，釜底抽薪。
OpenClaw 走的是"信任模型"路线：内部操作（读文件、写代码、搜索）默认允许，外部操作（发消息、发邮件、调外部 API）需要确认。这个设计很符合直觉——Agent 在自己的工作空间里折腾随便，但要往外发东西就得经过我同意。
三种策略各有适用场景，但底层逻辑是一样的：给用户控制权和可见性。让用户能看到 Agent 在做什么、能随时叫停、能自己设边界。做到这三点，信任自然就建立起来了。
二、懂业务比懂技术更重要
这是我从三款产品里提炼出的最核心的一条认知。
技术人做 Agent 产品，特别容易掉进一个坑：堆功能。"我们支持 100 个工具！""我们用最强的模型！""我们的 Agent Loop 比别人快 3 倍！"——这些在技术博客里很酷，但用户根本不关心。用户只关心一件事：这东西能帮我解决什么问题？
讲个我自己的故事。我之前想做一个"AI 写作助手"，一开始的思路是：接最好的模型、支持最多的输出格式、做最灵活的 prompt 模板系统。功能列表写了两页纸，觉得很完美。后来我把原型给几个做内容的朋友试用，反馈让我清醒了——他们说："我不需要这么多选项，我就想把一篇初稿丢进去，它帮我改得像人写的就行。"
两页纸的功能列表，用户真正需要的就一个功能。剩下的都是我自己的技术幻想。
回头看三款产品，最打动我的设计往往不是技术最复杂的，而是对用户场景理解最准的：
OpenClaw 的心跳机制。技术实现就是个定时器，没什么花头。但它精准地击中了一个需求：用户希望 Agent 不只是被动等指令，而是能主动关心我。我现在的 OpenClaw 会自己检查邮件、看日历提醒、甚至在我该休息的时候提醒我。这不是技术创新，是对"AI 助手应该像什么"的产品洞察。
Codex 和 GitHub 的深度集成。不是为了炫耀"我们能接 GitHub API"，而是因为开发者的工作流本来就长在 GitHub 上——issue 是任务入口，PR 是交付出口，CI 是质量关卡。Codex 把 Agent 嵌进了这个已有的工作流里，而不是要求用户学一套新流程。这个设计决策背后是对开发者日常工作的深度理解。
Claude Code 的"先问再做"默认模式。技术上完全可以做成全自动。但 Anthropic 选择了默认每次都问——因为他们理解，对于一个能读写你全部代码的 AI，信任不是一开始就有的，需要一次一次确认来慢慢建立。等用户熟悉了，再自己去调成更自动的模式。这个"默认保守、渐进放开"的设计，不是技术决策，是对人性的理解。
产品经理在 Agent 时代的价值恰恰在这里。你可能写不了 Agent Loop，但你知道用户在什么场景下会骂娘、什么功能看起来酷但没人用、什么体验细节决定了用户会不会留下来。这些判断力，在 Agent 时代不是被削弱了，而是更稀缺了。
三、Agent 的用户场景分层
不是所有场景都需要 Agent。这句话我想说两遍，因为太多人在不需要 Agent 的地方硬塞 Agent。
我把 AI 的使用场景分成三层，每层对应不同的产品形态：
轻量场景：问答、翻译、总结。用户需求明确，一问一答搞定。Chatbot 完全够用。你不需要启动一个 Agent Loop 来翻译一句话——那叫过度设计。ChatGPT、Kimi 这类对话产品在这个层级已经做得很好了。
中等场景：辅助编码、文档协作。用户需要 AI 在旁边实时帮忙，但主导权在用户手里。Copilot 模式最合适——写代码时自动补全、写文档时给润色建议。GitHub Copilot、Cursor 的 Tab 补全都是这个层级的产品。用户不需要 Agent 自己做决策，需要的是一个反应快的副驾驶。
重度场景：自主完成复杂任务。任务复杂、步骤多、中间需要灵活判断。这才是 Agent 的主场。"帮我重构这个模块并确保测试通过""每天帮我整理行业新闻发到飞书群""分析这三个竞品的定价策略写一份报告"——这些任务有明确目标但执行路径不确定，需要 Agent 自己规划、自己执行、遇到问题自己调整。
我见过不少团队犯的错误是：产品场景 80% 是轻量问答，却花大力气做了一个 Agent 架构。结果用户觉得"这东西回个问题怎么这么慢"——因为每次回答都要走一遍 Agent Loop，杀鸡用了牛刀。
做产品决策之前先问自己：我的用户真的需要 Agent 吗？如果答案是"大部分时候不需要"，那就做一个好的 Chatbot，比做一个半吊子 Agent 强十倍。Agent 的价值只在重度场景里才能体现。
四、Agent 的进化路径
Agent 产品不是一步到位的。从 2023 年初的 AutoGPT 热潮到现在，我观察到 Agent 产品沿着四条路径在进化。每条路径都有清晰的"从哪来、到哪去"，也都能在三款产品里找到对应的设计痕迹。
从被动到主动
2023 年的 Agent 几乎都是被动的——你说话，它响应。ChatGPT、早期的 Claude，都是这个模式。用户不开口，AI 就安静待着。
2024 年开始出现变化。Codex 在 2025 年初上线后，支持从 GitHub issue 自动触发任务——有人提了 bug，Codex 自动去修，不需要人手动分配。这是"事件驱动"的主动性。OpenClaw 的心跳机制走得更远：Agent 定期自己醒来，检查邮件、看日历、扫描待办事项，有重要的事主动通知你。这是"自驱动"的主动性。
主动性是 Agent 从"工具"变成"助手"的分水岭。工具等你来用，助手会主动找你。但主动性也有边界——我的 OpenClaw 曾经在凌晨两点给我发消息说"你有一封新邮件"，后来我在配置里加了安静时间段。主动不等于打扰，这个度要拿捏好。
从健忘到记忆
2023 年的 AI 对话产品基本都是"金鱼记忆"——上下文窗口用完就忘，下次聊天从头开始。ChatGPT 后来加了 Memory 功能，算是迈出了第一步，但那个记忆很粗糙，经常记错或者记了一堆没用的。
Claude Code 在 2024 年底推出时，用 CLAUDE.md 做项目级记忆——把项目的技术栈、代码规范、常用命令写在一个文件里，每次启动自动加载。这个设计很聪明：不靠 AI 自己记，靠一个人类可读可编辑的配置文件。简单、可控、不会出幻觉。
OpenClaw 在 2025 年把记忆做到了三层：短期的对话上下文、中期的每日工作日志、长期的 MEMORY.md。更有意思的是它会在空闲时自己整理记忆——把每日日志里的重要信息提炼到长期记忆里，过时的信息清理掉。这个"记忆维护"机制让 Agent 的记忆不是越积越乱，而是越用越精准。
我的判断是，记忆系统会成为 Agent 产品的核心竞争力。模型能力大家都能调 API，工具大家都能接 MCP，但记忆是跟着用户走的——用了三个月的 Agent 比新装的 Agent 更懂你，这个迁移成本就是护城河。
从单一到协作
2023-2024 年的 Agent 基本都是单兵作战——一个 Agent 从头干到尾。AutoGPT 试过让 Agent 自己拆任务自己执行，但效果很差，经常在子任务之间迷路。
2025 年开始出现真正可用的多 Agent 协作。Codex 的并行任务本质上就是多 Agent——每个沙盒里跑一个独立的 Agent 实例，各干各的，最后结果汇总到 GitHub PR。OpenClaw 的子代理（subagent）机制更灵活：主 Agent 可以随时派一个子代理去处理特定任务，子代理完成后把结果交回来，主 Agent 继续。我经常用这个功能——比如让主 Agent 帮我写文章，同时派一个子代理去搜索参考资料，另一个子代理去生成配图。
Claude Code 在 2025 年中推出了 SDK，允许开发者自己编排多 Agent 工作流。这说明 Anthropic 也认可了多 Agent 的方向，只是选择让开发者自己组合，而不是内置一套固定的协作模式。
多 Agent 协作的难点不在技术，在协调。谁负责什么、结果怎么合并、冲突怎么解决——这些问题和管理一个真实团队没什么区别。做过项目管理的产品经理在这个问题上反而有优势。
从封闭到开放
2024 年之前，Agent 能用什么工具基本是开发时写死的。LangChain 里定义了哪些 Tool，Agent 就只能用哪些，想加新的得改代码重新部署。
2024 年底 Anthropic 发布 MCP 协议，游戏规则变了。MCP 让 Agent 可以动态接入新工具，不需要改一行代码。今天接一个 GitHub MCP Server，明天接一个 Notion MCP Server，后天接一个公司内部的 CRM API——全是运行时热插拔。Claude Code 是最早全面支持 MCP 的产品，OpenClaw 也在跟进，现在连 VS Code、Cursor 这些编辑器都支持了。
这个趋势对产品设计的启示是：不要试图自己做所有工具，而是做好工具接入的标准化接口。把精力花在核心体验上，长尾需求交给生态。OpenClaw 的 Skill 市场（clawhub.com）就是这个思路——官方做平台和标准，社区贡献具体的工具和能力。
五、如果我来设计一个 Agent 产品
说了这么多别人的产品，最后聊聊我自己的思考。如果让我从零开始做一个 Agent 产品，我会怎么做？
我不会做一个"什么都能干"的通用 Agent。通用意味着什么都做不精，而且市场上已经有 Claude Code、ChatGPT 这些巨头占位了，没必要硬碰硬。
我会选一个垂直场景切入。具体来说，我最想做的是一个"产品经理的 AI 工作伙伴"——因为这是我自己最痛的场景，我知道痛点在哪。
核心场景：竞品分析、PRD 撰写、数据看板解读、用户反馈归类、周报月报生成。这些任务占了我日常工作的 40%，重复性高但又需要一定判断力，正好是 Agent 的甜区。
架构选择：云端优先 + 本地可选。产品经理不是开发者，不能指望他们配环境装依赖。默认云端开箱即用，对数据敏感的企业客户提供私有化部署选项。这个思路参考了 Codex 的云端模式，但不做沙盒隔离（产品经理的任务不需要那么重的隔离）。
记忆设计：两层就够。第一层是"项目上下文"——每个产品线一个配置文件，存竞品列表、核心指标、团队术语、历史决策。第二层是"用户偏好"——写作风格、汇报格式、常用数据源。不做 OpenClaw 那样的三层体系，因为工具型产品不需要 Agent 有"性格"。
工具系统：内置 5 个核心工具（网页抓取、文档生成、数据查询、图表绘制、消息推送），外部扩展全走 MCP。第一批接飞书、Notion、Jira 的 MCP Server，覆盖产品经理最常用的三个平台。
安全策略：借鉴 Claude Code 的渐进信任模型。新用户默认每次外部操作都确认（发飞书消息、写 Notion 文档），用了一周后提示用户可以设置白名单。数据层面，用户的项目数据加密存储，不用于模型训练——这个承诺要写在产品首页最显眼的位置。
差异化：不和 Claude Code、Codex 比技术深度，比场景理解。一个通用 Agent 写竞品分析报告，你得花 20 分钟写 prompt 告诉它格式、维度、数据源；我的产品里，你说"帮我分析一下 XX 产品最近的动态"，它就知道该去哪找数据、用什么框架分析、输出什么格式——因为这些都在项目上下文里配好了。
这个产品不一定能做成，但思考过程本身就是有价值的：从场景出发、选最合适的架构、把记忆和工具做到刚好够用、安全策略匹配用户心理。这套方法论适用于任何 Agent 产品的设计。
写完这篇回头看，我觉得 Agent 产品设计的核心其实就一句话：技术决定能做什么，产品决定该做什么。
模型越来越强、工具越来越多、架构越来越成熟——这些是技术趋势，挡不住。但"给什么用户、在什么场景下、用什么方式提供价值"，这些问题永远需要人来回答。Claude Code、Codex、OpenClaw 三款产品给出了三种不同的答案，没有谁对谁错，只有适不适合自己的用户。
如果你也在做 Agent 相关的产品，希望这篇文章里的五个设计决策和四条进化路径能帮你少走一些弯路。如果你觉得我哪里说得不对，欢迎来找我聊——产品设计这事儿，越辩越清楚。
下一篇是这个系列的最后一篇——实战操作指南。手把手带你上手 Claude Code、Codex 和 OpenClaw，从安装配置到日常使用的进阶技巧。
Allen | 产品经理 | allen00.top