注：AI 发展很快，我们现在看到的文章，可能过几个月就过时了。
所以这篇文章不是为了下一个永恒结论，而是想看两套 Agent背后的工程设计理念。文中的判断，更多是基于公开文档、可观察行为和使用体验做的一次整理，不保证每个内部实现细节都完全准确。
有些时候，我会在群里看到一些观点：
Claude 发散思维强，GPT 收敛能力强。
Claude 有创意，Codex是牛马。
这些说法对不对，其实没那么重要。
更重要的是：我们感受到的“模型性格”，不一定全来自模型本身，也可能来自模型外面那层Agent工程骨架。
Claude Code不是单纯的 Claude 模型。
Codex也不是单纯的 GPT 模型。
它们都是模型 + 工具 + 权限 + 上下文 + 状态管理 + 执行环境之后，组合出来的 Agent 系统。
所以我们看到的差异，可能不是“谁更聪明”，而是两套系统给AI立规矩的方式不同。
Claude Code更像一个能随着现场不断调整的执行系统。
Codex 更像一个先把制度写清楚，再按流程执行的工程系统。
这不是说谁更严谨、谁更随意，而是说它们把规矩放在了不同位置。
做系统的人，不过是把必然会来的摧残，提前写进控制流，省得它反过来支配你。
为了不把问题讲虚，我们先看一个真实场景。
假设我有一个公众号排版工具，用户点“导出”或者“复制到公众号”以后，发现图片样式丢了，或者间距乱了。
我把这个问题交给 Agent：
“帮我定位一下，为什么导出以后图片样式丢失，修好并验证。”
看起来是一个小 Bug。
但如果你真让 Agent接手，它马上会遇到一堆工程问题：
它不能把整个项目一股脑塞进上下文，要先读入口文件、导出逻辑、图片处理逻辑。
它可以读文件，但不能随便删文件。
它可以修改代码，但发布到线上必须问我。
它修了一次没好，要看日志、缩小范围、重新验证。
它连续三次修不好，就该停下来，不要继续瞎改。
如果我中途打断，它要说清楚：改了哪些文件，哪些测试跑过，哪些验证没做。
改完以后，它不能自己说“好了”，最好跑测试、看截图，或者让另一个验证 Agent 复核。
如果再往公众号生产链路里看，这个问题会更具体。
一篇文章从原文到公众号草稿，不是一条“转换一下就完事”的直线。
PS : 基于此，我做了一个公众号排版skills全流程。(本文的排版，以及图片生成都由该skills完成。)
它至少会经过：路由、结构清洗、智能转换、插图计划、图片验收、标题确认、图片上传、公众号 HTML 排版、发布前检查、最终交付。
每一层都不能越权。
路由只决定走哪条链路。
计划只决定生成什么。
脚本负责执行和记录。
验收决定能不能进入文章。
标准文件固化判断边界。
这才是一个 Skill 真正像工程系统的地方。
你看，一个小小的“图片样式丢失”，背后其实已经包含了上下文治理、权限系统、状态管理、错误恢复、熔断、中断处理、验证独立和隔离机制。
这就是 Agent 工程设计真正有意思的地方。
不是让模型更会说话。
是让模型在真实任务里，知道边界，知道进度，知道什么时候停，知道怎么交付。
这篇文章，围绕四个问题展开：
Claude Code 和 Codex 的 Agent 设计倾向，差异在哪里？
它们怎么通过一次次请求跟模型交互？
心跳循环、中断、熔断、权限、上下文这些机制，在 Agent 里到底对应什么？
这些设计理念，对我们做 Agent 和写 Skill 有什么启发？
01 两套骨架，两种灵魂
Claude Code 和 Codex 最大的区别，不在于功能多少，而在于它们把“秩序”放在架构的哪一层。
注意，这不是绝对二分。
Claude Code 也有权限、hooks、subagents、上下文压缩。
Codex 也有运行时判断、动态工具、人工审批、上下文恢复。
真实差异不是“有没有”，而是“重心放在哪”。
Claude Code：秩序住在运行时
Claude Code 给人的感觉，是一个很强的现场执行系统。
它的核心像一个持续转动的循环：
拿到用户输入 → 拼上下文 → 调模型 → 模型返回 → 判断要不要用工具 → 检查权限 → 执行工具 → 把结果塞回历史 → 如果上下文太长就压缩 → 继续下一轮。
它像一个发动机。
只要任务没结束，它就继续转。
下面是我用CC模型在Calude的agent的提问，也验证了它在架构层次的设计模式，核心是一个单主循环+工具的结构。(当然它是闭源的，具体如何设计的，我们也不得而知。)
这套系统的秩序，更多藏在运行时的装配和执行里。
每一轮请求前，它会重新决定带什么上下文、给什么工具、遵守什么本地规矩。
每一轮请求后，它再根据模型返回，决定下一步怎么走。
所以 Claude Code 的味道是：
现场调度很强，循环很强，应变很强。
它更相信“边跑边治理”。
Codex：秩序住在控制层
Codex 的感觉不一样。
它更像是先把任务放进一个明确的工程框架里：
有 thread，有权限策略，有沙箱，有工具 schema，有 hook，有审批，有状态记录。
模型当然也在里面思考。
但模型不是想干什么就干什么。
它发出的工具调用，要经过结构化工具定义、权限判断、沙箱边界、用户审批这些控制层。
所以 Codex 的味道是：
流程感更强，边界更明确，审计和恢复意识更重。
它更相信“先立规矩，再让模型跑”。
一句话概括
Claude Code 把纪律活成了本能。
Codex 把纪律写成了制度。
一个偏现场调度。一个偏显式控制。
这就是两套 Agent 骨架给人的根本差异。
02 Agent 跟模型交互，本质上是在发请求
要理解 Agent，先得把神秘感拿掉。
Agent 每一次“动脑子”，本质上都是发一次请求。
它把当前任务、系统指令、对话历史、工具结果、本地规矩、可用工具，打包给模型。
模型返回一段内容，或者返回一个工具调用。
Agent 再根据返回结果，决定下一步怎么做。
模型本身没有真正的长期状态。
状态、记忆、规矩、权限，都是 Agent 这个壳在请求之间帮它维护的。
所以一个 Agent 靠不靠谱，不只看模型回答得好不好，还要看请求前后发生了什么。
请求前：
它怎么装上下文？怎么筛工具？怎么注入规则？怎么控制信息边界？
请求后：
它怎么执行工具？怎么查权限？怎么恢复错误？怎么记录状态？怎么决定停不停？
Claude Code 和 Codex 的差异，就藏在这些地方。
Claude Code：动态装配线
Claude Code 更像每次都在现场调配。
请求前，它会把系统提示、项目规则、当前目录信息、工具列表、历史消息、压缩摘要等东西拼起来。
请求后，如果模型要用工具，就在执行流里判断这个工具能不能用、要不要问用户、是否继续下一轮。
这不是说它没有模块。
而是说，它的控制感更多来自“运行时不断装配”。
它像一个熟练的急诊医生。
流程当然有，但很多判断发生在现场。
Codex：制度化流水线
Codex 更像每次请求都在走一套制度化流水线。
任务有 thread。
工具有 schema。
权限有 policy。
执行有 sandbox。
关键节点可以挂 hook。
用户审批会影响下一步执行。
状态可以恢复、续跑、回放。
请求前，它不是简单把所有东西塞进去，而是按结构把上下文、工具、权限、任务状态组织起来。
请求后，工具调用也不是一句“模型说了算”，而是要经过系统边界。
它像银行柜台。
不是不能变通，而是每一步都要过系统。
核心差异
Claude Code 更像“现场调度”。
Codex 更像“流程治理”。
Claude Code 的优势是灵活、连续、能扛长任务。
Codex 的优势是边界清楚、可审计、适合工程化协作。
两者不是谁先进谁落后。
它们只是把秩序放在了不同位置。
03 九个工程机制，其实都在回答一个问题
做 Agent，不是给模型接几个工具。
做 Agent，本质上是在回答：
模型不可靠的时候，系统怎么仍然可靠？
九个机制，可以分成三组。
第一组，解决“怎么持续运转”。
心跳循环，让 Agent 不会一轮就停。Claude Code 的循环感更强，像现场发动机；Codex 也有循环，但更像 thread 生命周期里的执行器。循环只保证系统能跑，不保证跑对，所以它必须配方向盘和刹车。
错误恢复，解决模型断了、工具挂了、上下文爆了怎么办。真正靠谱的 Agent，不是顺的时候多聪明，而是错的时候能不能收场。恢复机制不是异常补丁，它就是主流程的一部分。
熔断机制，解决连续失败时什么时候停。Agent 最可怕的不是失败，而是失败了还一直自信重试。连续三次改不对，就停；连续两次验证失败，就交给人。熔断不是回退，熔断是止损。
第二组，解决“怎么守住边界”。
权限系统，把“模型想做什么”和“系统允许它做什么”分开。模型可以建议删文件，但删不删，不能由模型决定。
Agent 的安全起点应该是：模型默认什么都不能干，再按任务逐步授权。
工具 Schema，是模型和系统之间的合同。没有 schema，模型就是凭感觉填表；合同越清楚，错误越早暴露，系统越稳。
隔离机制，防止一个 Agent 的误判污染全局。上下文要隔离，权限要隔离，中间产物要隔离，文件系统和网络访问也要隔离。隔离不是高级功能，是多 Agent 能正常工作的前提。
第三组，解决“怎么协作和交付”。
上下文治理，决定什么该带给模型，什么不该带。上下文不是垃圾桶，是工作台。回到公众号排版工具的 Bug，Agent 不应该一上来读完整个项目，而应该先读导出入口、图片处理逻辑、样式转换逻辑。需要什么，拿什么。
中断处理，决定用户打断后系统能不能说清现场。协议层通常会保证工具调用和工具结果配对，不让对话停在半截；但业务层账本不会自动补齐。改了哪些文件、跑了哪些测试、哪些验证没做，仍然需要 Agent 或 Skill 主动记录。
验证独立，解决“写代码的人不能给自己打分”。实现和审查要分开，执行和验证要分开，探索和总结要分开。多 Agent 的第一性原理不是并行加速，而是职责隔离。
04 回到那个 Bug：为什么这些机制不是玄学
我们再回到开头的例子。
公众号排版工具导出以后，图片样式丢了。
一个没有工程约束的 Agent，可能会这样做：
先读一堆文件。
猜一个原因。
改三个地方。
跑不起来，再改。
还不行，再改。
最后告诉你：“我已经修复了。”
但它到底改了什么？
有没有影响别的样式？
图片、代码块、引用块、封面图有没有一起测？
能不能复制到公众号后台？
不知道。
这就不是工程。这是赌博。
一个靠谱的 Agent，应该这样工作：
第一步，限定上下文。
先找导出入口、HTML 转换逻辑、图片样式处理逻辑，而不是把整个项目都塞进来。
如果是公众号流水线，还要先确认 route。
是只做本地预览？
是修复插图？
是只做排版？
还是要进入发布准备？
不同 route 对应不同权限，不同产物，也对应不同验收标准。
第二步，限定权限。
读文件可以自动做。
改代码要记账。
删除文件、发布文章、上传到微信服务器，必须问人。
本地预览可以保留本地图片路径。
但发布准备就不行。
进入最终 HTML 前，本地图片必须先上传到微信公众号服务器，再替换成微信图片 URL。
如果上传失败，不能偷偷换成外部图床，也不能假装成功。
应该重试，写报告，标记需要人工上传，然后停在发布前。
第三步，记录状态。
读了哪些文件，判断是什么，改了哪些地方，验证跑到哪一步，都要留下痕迹。
公众号链路里，这些状态应该落成具体产物：
运行记录、图片上传报告、主题验收报告、预发布检查报告、最终交付清单。
没有报告，就没有现场。
第四步，设置熔断。
连续三次没有通过验证，就停。
别再继续“玄学修复”。
比如图片上传重试后仍失败，就不要继续生成可发布 HTML。
比如 formatter 找不到图片，就不要继续往后排版。
比如主题验收不通过，就不要进入发布或更新草稿。
第五步，独立验证。
改完不能只看代码。
要跑导出，要看样式，要最好用截图或另一个验证视角复核。
对于公众号排版来说，验证不是一句“HTML 生成成功”。
还要看首图是不是第一张图，比例是不是对，正文图有没有连续挤在一起，本地图片路径有没有残留，标题是不是用户确认过，主题色是不是一致。
第六步，交付结果。
告诉用户：
改了什么。
为什么这么改。
验证了什么。
还剩什么风险。
这才是 Agent 工程设计。
不是让 AI 看起来更聪明。而是让它做事更像一个能交付的人。
05 这些机制放在一起，说明了什么？
它们说明一件事：
Agent 不是聊天机器人加工具。
Agent 是一个控制系统。
模型只是里面最聪明、也最不稳定的部件。
所以做 Agent 的核心，不是哄模型。
skills编排设计也同样如此。
是给模型修轨道、设护栏、留刹车、做记录。
权限，是护栏。
上下文，是工作台。
状态，是账本。
熔断，是止损。
验证，是复核。
隔离，是防火墙。
工具 schema，是合同。
可观测性，是黑匣子。
这些东西不是装修。
这些东西是地基。
还有一件事，也很重要：
这些机制不只是为了“活下来”，也是为了“别烧钱”。
上下文压缩、按需披露、任务隔离、验证前置，本质上都是在减少无效 token、无效轮次和无效工具调用。
工程优化的不是模型原始出字速度。
工程优化的是系统整体的无效消耗。
跑得快不一定省。少走弯路，才是真省。
06 对 Agent 设计的五个启发
1. 控制面要看得见
你可以像 Claude Code 一样，把控制面更多放进运行时动态装配。
也可以像 Codex 一样，把控制面写成更显式的制度层。
但你必须知道：你的控制面在哪里？
最差的架构，是控制面和执行面糊成一团。既没有清晰模块，也没有清楚流程。出了问题以后，没人知道是哪一层失控了。
2. 状态是系统的账本
状态不是顺手记一下。
状态是 Agent 的脊梁骨。
它决定系统能不能恢复，能不能回放，中断后能不能续跑，多人协作时能不能接手。
没有状态管理的 Agent，就是一次性玩具。
有状态管理的 Agent，才可能变成可持续工作的系统。
3. 安全边界要从一开始收紧
不要默认模型什么都能干。要默认模型什么都不能干。
然后按任务需求，一点一点放权。
能读，不一定能写。能写，不一定能删。能改草稿，不一定能发布。
安全不是出问题以后再补。安全应该是初始状态。
4. 循环必须有方向盘和刹车
循环很重要。
但循环本身不等于智能。
一个只会循环的 Agent，可能只是更有耐心地犯错。
所以每个循环都要配三件事：
进度评估：现在完成了多少？
终止条件：什么叫做完成？
熔断机制：失败多少次必须停？
没有这三件事，循环就是失控的发动机。
5. 先按失败模式设计，再谈自动化
正常流程谁都会画。
真正难的是：上下文满了怎么办，工具失败怎么办，用户打断怎么办，连续三次修不好怎么办。
设计 Agent，应该先列死法，再设计活法。
多 Agent 也是一样。
不要一上来就堆角色。先问清楚：谁执行，谁验证，谁汇总，谁拥有最终决策权，中间状态能不能共享。
沉默的 Agent 是黑箱。
有状态输出、有历史追溯、有异常记录的 Agent，才是可控流程。
07 对 Skill 设计的十条落地法则
全局 Agent 的设计原则，可以下放到 Skill。
Skill 不是长 Prompt。
Skill 是一个微型约束系统。
如果把这个思路放到公众号文章生产流程里，就很清楚。
排版是一个 Skill。配图是一个 Skill。微信图片上传是一个 Skill。发布前检查是一个 Skill。
它们不是几段提示词。
它们都应该有边界、有状态、有验证、有熔断。
公众号排版流水线的设计特别像 Skills 设计的骨架：
route 决定走哪条链路。
plan 决定生成什么。
scripts 负责执行和记录。
acceptance 决定能不能进入文章。
references 固化标准。
这些思考就是让 Skill 从 Prompt 变成工程系统的分界线。
1. 先分类，再设计
动手前先问：
这个任务搞砸了会怎样？
它是提醒型任务，还是执行型任务？
只是改文案、提建议，风险低。
涉及写文件、删文件、发请求、调接口，风险就高。
判断标准很简单：
如果执行出了相反结果，能不能一分钟内修好？
不能，就必须加边界。
2. 每个 Skill 都要有红绿灯
绿灯：什么可以做。
红灯：什么绝对不能做。
黄灯：什么必须问用户。
比如公众号发布链路里：
本地排版预览，可以自动做。
上传图片到微信服务器，可以在明确授权后做。
正式发布文章，必须人工确认。
本地预览和发布准备，必须是两种模式。
本地预览允许保留本地图片路径。
发布准备必须使用微信图片 URL。
只要还有本地图片路径残留，就不能进入发布。
不要把边界藏在心里。要写在 Skill 最前面。
3. 状态检查是第一步
Skill 不能假设自己从零开始。
启动第一步应该是检查现场：
上次做到哪了？有没有遗留文件？有没有中断记录？这次应该从哪继续？
状态检查，比后面执行步骤更重要。
公众号流水线里，这一步可以很具体：
有没有 selected_title.json？
标题是不是用户确认过？
图片有没有上传报告？主题验收有没有通过？
最终 HTML 里还有没有本地图片路径？
这些不是“细节洁癖”。
这是发布前的安全闸门。
4. 熔断必须自己写
有代价的操作，必须设重试上限。
三次改不对，就停。
两次验证失败，就停。
连续出现同一个异常，就停。
停不是失败。停是保护现场。
比如图片上传失败，重试之后仍然失败，就写入人工处理清单。
比如验收失败，就只重生成失败图片。
如果仍然失败，就等待人工确认。
不要用外部图床兜底，不要静默跳过，不要假装成功。
5. 关键节点要抛进度
沉默的 Skill 是黑箱。
用户不怕你慢。用户怕你不知道自己在干什么。
所以关键节点要说清：
现在在哪。已经完成什么。接下来做什么。为什么要这么做。
6. 验证要独立
重要任务尽量拆成两段：
先执行。再验证。
执行的时候不要顺手给自己打满分。
至少切换成验证模式，用另一个视角重新看。
排版导出修好了，不是看代码觉得对了就算。
要真的导出一次，看图片、样式、间距、复制结果。
7. 中间产物要隔离
Skill A 的半成品，不要随便传给 Skill B。
只有最终结论、稳定产物、明确摘要，才适合流转。
半成品共享，是污染的根源。
这也是为什么候选计划不能直接变成最终计划。
智能转换层可以产出候选。
但最终能不能进入文章，要经过筛选、验收和合成。
多 Agent 也一样。
Agent 可以给 suggestions，但不要直接改最终 Markdown。
8. 渐进披露，入口要瘦
Skill 文件不要写成百科全书。
入口只写流程、边界、触发条件。细节放到资源文件里，按需读取。能加载，不等于应该加载。
上下文也是成本。
9. 先想断了怎么办
写 Skill 的顺序，不只是：
第一步做什么，第二步做什么，第三步做什么。
而还要先问：
断了怎么办？失败怎么办？用户中断怎么办？
权限不够怎么办？结果不确定怎么办？
正常流程谁都会写。
断了之后的行为，才决定 Skill 靠不靠谱。
所以失败分支要写得像产品说明一样清楚。
配置缺失，就跳过发布，只产出 HTML。
图片找不到，就停止生成最终 HTML。
主题不一致，就标记需要复核。
失败不可怕。静默失败才可怕。
10. 把线性流程升级成小循环
好的 Skill 不应该是一条僵硬流水线。
它应该是一个小循环：
状态检查 → 核心执行 → 独立验证 → 写进度 → 判断下一步。
通过了，就停。
没通过，但没到上限，就调整后再来。
到上限了，就熔断，保留现场，等人决策。
这样 Skill 才不是一段长 Prompt。
而是一个会判断、会调整、会记录的微型自动化系统。
08 最后的话
Claude Code 教我一件事：
把纪律活成本能。
信循环，信现场，信应变能力。
宁可结构轻一点，也要让 Agent 在长任务里活下来。
Codex 教我另一件事：
把纪律写成制度。
信边界，信契约，信提前设计好的控制层。
宁可流程重一点，也要让系统在组织里长久可靠。
它们殊途同归。
同归的是：模型不可靠，秩序要靠模型外面的工程结构来提供。
不同的是：一个更像现场调度。一个更像制度流水线。
而我现在越来越觉得，一个好 Skill，其实就是把这套工程结构缩小到一个具体任务里。
它不是一段更长的 Prompt。
它是一条小型生产线：路由、计划、执行、验收、交付。
哪一步能自动，哪一步要确认，哪一步必须停，都要提前写清楚。
所以，不是哄模型。是搭结构。
权限、恢复、熔断、验证独立、记忆分层、默认隔离、状态记录、工具合同。
这些是地基，不是装修。
正常流程谁都会写。断了之后的行为，才决定一个系统靠不靠谱。
比如 Codex 的模块化，不一定是“模型自己记住了一切”。
我们新开一个任务的时候，系统外面通常
会有一个会话级的容器，负责装这次任务里的上下文、工具调用、执行结果和状态摘要。
工具也不是模型想怎么调就怎么调。Tool schema 会先规定工具能收什么参数、参数长什么样，至少能把“参数传歪了”这类问题挡在前面。Policy 或执行策略层，则负责看这个动作能不能做：读文件可以直接做，写文件要不要确认，联网、删除、发布这种高风险动作要不要拦下来。
Claude Code 更像是一个主循环。每一轮循环里，它都会把当前上下文、可用工具、工具结果、用户目标重新带上，再让模型判断下一步要做什么。
