把GPT-5.6装进Claude Code：子代理编排与系统提示词的最佳实践

一个反直觉的实验

如果几个月前有人告诉这位YouTube创作者，他会为Claude Code写一整期赞美视频——而且是在用它跑OpenAI的GPT-5.6（视频中称5.6 Sol）模型——他大概会觉得对方疯了。但现实就是如此魔幻：他没有在Codex里用5.6，而是把5.6作为实际执行模型接进了Claude Code。

这个组合听起来"很蠢"，但作者在早期体验窗口试用后被深深震撼，随着对Codex作为CLI和harness（模型运行框架）越来越失望，他决定深入探索这条路径。所谓harness，是指模型的运行时环境和编排层——它不是模型本身，而是决定模型如何被调用、如何接收指令、如何与外部工具交互的中间件。可以类比为：模型是引擎，harness是整辆车的底盘、变速箱和驾驶系统。同一个引擎装在不同底盘上，驾驶体验可以天差地别。

结论是：真正的收益并不只是Claude Code的UI更好，而是它在子代理（subagent）设计、系统提示词、集成能力等方面的根本性差异。

本文不是简单地推荐某个工具，而是要拆解一个更重要的问题：在新一代模型能力面前，harness到底做对了什么、做错了什么，直接决定了你能从模型里榨出多少价值。

Codex子代理的核心问题：从简单到失控

作者对Codex的第一大不满，集中在它处理子代理的方式上。子代理是AI编码工具中的一种架构设计，指主代理（top-level agent）将复杂任务分解后派发给专门的子任务执行者——这一概念借鉴了软件工程中的微服务架构和操作系统中的进程-线程模型。设计良好的子代理系统需要解决三个核心问题：任务分发的粒度控制、上下文信息的传递范围、以及结果聚合的协调机制。

V1稳定但简单，V2复杂到失控

Codex的子代理目前有两个版本。V1稳定且简单：顶层代理可以派生出一层子代理去执行具体任务，完成后返回结果。这类似于传统的主从架构，简单可控。V2是尚未完成、需要手动开启的新版本，默认会把整个上下文窗口复制过去（这很烦人），还允许子代理再派生自己命名的子子代理，层层嵌套并互相传递消息。

V2的多层嵌套类似于分布式系统中的递归分解，理论上更灵活但也引入了通信复杂度爆炸的风险。结果就是把一个简单的层级结构变得"荒谬地复杂"，为了让这些节点互相通信又塞进大量工具，整体显得混乱且明显还在调试中——这也是它默认关闭的原因。

Claude Code的工作流：用代码定义编排

相比之下，Claude Code的workflow（工作流）功能要好得多。它不是让子代理在模型"心血来潮"时随机派生，而是让模型预先定义一个程序化的工作流：不同阶段、不同提示词、每个阶段配不同的子代理，全部写在一个从上到下执行的JavaScript文件里。

这种设计理念源自软件工程中成熟的工作流引擎（如Apache Airflow、Temporal），核心优势在于确定性和可观测性。与让模型自由决定何时派生子代理的方式相比，程序化工作流将"何时做什么"的决策从运行时推理转移到了编译时定义。用JavaScript文件来描述工作流意味着开发者可以使用条件分支、循环、错误处理等标准编程结构，同时享受版本控制和代码审查的工程实践。

用代码来定义程序化流程本就是天经地义的事。更关键的是——工作流会结束。这一特性为模型设置了明确的停止信号，避免了大语言模型常见的"过度生成"倾向。作者发现这对5.6系列模型的token效率是巨大利好：

"同样的任务，Ultra模式可能一直跑下去，而工作流会停；输出质量相同甚至更好，token消耗却只有约四分之一。"

在API调用场景中，token（大语言模型处理文本的基本计量单位，大约相当于4个英文字符或1-2个中文字符）消耗直接影响使用成本。对于重度使用AI编码工具的开发者而言，单日token消耗可达数百万，月度成本可能高达数百至数千美元。因此，在完成同等质量任务的前提下成本降低75%，具有极其显著的实际价值。

换句话说，OpenAI在Codex里自己写编排代码、让模型正确调用；而Claude Code让模型自己编写工作流和子代理的代码，实践中效果反而更好。这正是作者最初尝试把5.6接入Claude Code的直接动机。

系统提示词的巨大鸿沟

真正让作者"破防"的，是两者系统提示词的对比。系统提示词是在每次对话开始前注入模型的指令集，它定义了模型的角色、行为边界、输出风格和工具使用规则。在token经济学中，系统提示词的每一个字都会持续消耗计算资源——因为它在每次推理调用时都会被完整传入模型的上下文窗口。

为什么5.6在Claude Code里设计质量更好？

作者注意到，同一个5.6模型在Claude Code里生成的页面，设计质量明显优于在Codex里生成的——前者一眼看去像是Claude（Opus/Fable）的手笔。他起初以为是Claude Code的系统提示词里藏着前端设计指引，于是通读整份提示词，想把这段指引搬到Codex。

结果令人意外：Claude Code的系统提示词里"front-end"这个词只出现了三次，其中两次还只是作为记忆功能的示例，真正的前端设计指导几乎为零。那问题到底出在哪？

罪魁祸首：Codex那份臃肿的系统提示词

答案是他一直在错的地方找。真正的问题不在Claude Code缺少什么，而在Codex的系统提示词塞得太多。过度详细的系统提示词不仅浪费token，还会产生"过度约束"问题：模型被迫在大量互相矛盾或过于具体的规则中寻找平衡，导致输出僵化。好的系统提示词设计遵循"最小必要"原则——只规定真正需要全局生效的行为准则，将场景特定的指令留给运行时动态注入。

作者展示了Codex此前官方系统提示词里的前端指引，内容细到令人咋舌：规定SaaS/CRM类工具必须"安静、实用、以工作为中心"；卡片圆角必须≤8像素；图标要用Lucide库；甚至禁止使用可见的说明性文字。他一针见血地指出：

"记得OpenAI模型那个特点吗——你让它做什么它就死板地做什么。这段提示直接告诉模型，只要是像SaaS的东西就必须做成实用风。永远如此，它也确实永远如此。"

OpenAI的模型以高度指令遵从（instruction following）著称，这本是优势，但在系统提示词过度约束的场景下反而成了劣势——模型不会"聪明地忽略"不合理的指令，而是严格执行每一条规则，即使这些规则在具体场景中并不适用。

这解释了为什么Codex生成的页面千篇一律，也解释了为什么它从不做好"空状态（empty states）"——因为提示词明确禁止用可见文字描述功能，而空状态、引导、校验提示恰恰是产品UI不可或缺的部分。空状态是用户界面设计中的重要概念，指应用程序中尚无数据或内容时呈现给用户的界面状态。好的空状态设计包含解释当前状态、提供行动建议、降低用户焦虑感三个要素，是用户首次体验的关键触点，直接影响新用户留存率。

更荒诞的细节还包括：提示词里"cards"出现6次、"card"出现12次，甚至"goblins（哥布林）"出现的次数比Claude Code提示词里"front-end"还多；那句"每30秒向用户更新一次进度"，正是许多重度用户抱怨Codex总爱设置30秒计时器的根源；而"autonomy and persistence（自主与坚持）"这段，则解释了为什么Codex在你还在规划阶段时就急着动手写代码。

作者透露，这段前端指引在他向Codex前端团队的朋友"crash out（激烈吐槽）"后已被移除，但他忍不住反问："为什么要靠一个YouTuber才能把垃圾从Codex里删掉？"

Claude Code系统提示词好在哪

作者同样通读了Claude Code的完整系统提示词，评价是"明显更好、更用心"。

它开头就说明用户会看到什么、工具在特定权限模式下执行；对探索性问题，要求模型用两三句话给出建议和主要权衡，呈现为"用户可以调整的方案"而非既定计划，且在用户同意前不实现——这与Codex那种"默认动手"的取向恰好相反，作者认为这种"先提问"的行为相当受用。

这种设计体现了人机协作中"确认优先（confirmation-first）"的交互范式：对于不可逆操作或涉及重大设计决策的场景，系统应先呈现选项并等待人类确认，而非自主执行。这在航空、医疗等高风险领域早已是标准实践，现在正被引入AI辅助编程领域。

其他细节也很克制：默认不写注释、只在"为什么"不明显时才加；执行操作前要考虑可逆性和影响范围，对难以撤销或影响共享系统的操作要先跟用户确认；语气简洁，除非用户要求否则不用emoji。

作者甚至让三个模型（Claude Code里的5.6 Sol、Fable 5，以及Codex里的5.6 Sol）分别给Codex的系统提示词打分。Claude Code里的5.6给出的评价是：作为Codex专用运行时提示是7/10，作为通用编码代理提示是4/10，作为面向现代模型的可移植提示只有3/10。它还指出关键一点：

"这些运行时指令应该由harness生成，而不是嵌入到可复用的agent里。"

这句话揭示了一个重要的架构原则：系统提示词应该分层——通用的行为准则属于agent层，而与特定运行环境（如文件系统权限、可用工具列表、输出格式要求）相关的指令应该由harness在运行时动态注入。将两者混为一谈会导致提示词既臃肿又缺乏可移植性。

上手的注意事项与常见问题

作者也如实列出了在Claude Code里跑Codex模型遇到的几个小问题：

• 偶尔会丢失任务追踪：他怀疑是上下文管理方式或系统提示词的小差异导致，但整体仍能较好地保持在任务上。这可能与不同harness的上下文窗口压缩策略有关——当对话超过模型的最大上下文长度时，harness需要决定丢弃哪些历史信息，不同的策略可能导致任务相关的关键信息被意外截断。
• 格式化能力欠佳：5.6对Claude Code里的Markdown编号列表处理不当，会出现"1、1、2、2、3、3"这样的重复编号；对某些链接的格式化也不熟悉。这类问题通常源于模型训练数据与目标harness期望格式之间的微妙不匹配——每个模型都有自己"习惯"的输出格式，跨harness使用时这些习惯可能与新环境的解析器产生冲突。

• token统计不实时：5.6系列在工作完成前不会报告token用量，而Fable会给出实时更新。这是因为不同模型提供商的API在流式输出（streaming）时返回的元数据字段不同，Claude Code原生适配的是Anthropic API的响应格式，对OpenAI API的某些字段可能未做完整解析。

要顺畅使用工作流，需要在系统提示词或全局agents.md里让Claude Code理解你所说的"Sol""Terra"等模型指代，或在指令中明确指定。

为什么不选Pi、OpenCode等其他harness？

针对评论区必然会问的问题，作者给出了明确回答：这些工具没有解决他最在意的子代理编排问题。

当前AI编码工具的开源生态中，存在大量轻量级CLI harness（如Aider、Continue、OpenCode等），它们通常聚焦于单模型交互体验的优化——更好的diff展示、更快的响应速度、更灵活的模型切换。但在多代理协作、阶段化任务分解这类复杂工程场景中，它们的能力边界就显现出来了。

它们的系统提示词确实不像Codex那么糟，但Pi需要你自己搭建全部工作流和编排工具；OpenCode内置了一批硬编码、质量一般的子代理，且都没有工作流机制（V2版本作者尚未评测）。

他给出的核心判断非常直接：

"对于需要拆分多个不同模型的代理去处理复杂工作、分阶段轮转、有明确终点的真实日常任务，工作流是我见过最好的方案，没有之一，其他都望尘莫及。"

他强调这并非什么别家实现不了的黑科技，Codex完全可以自己加上；但目前Claude Code已经把这件事做到位了——系统、终端UI、正确引导模型的提示词、以及一个"足够好"的harness，四者齐备。

结语：harness工程质量才是关键变量

作者最后坦言，他并不主张所有人都独占式地通过Claude Code来用Codex订阅，这只是一个结果远超预期的有趣实验。他还提到CLI Proxy API可以接入更多平台的订阅（比如用Twitter Premium账号接Grok，或在Claude Code里加上Opus 4.5）。CLI Proxy API是一种中间层服务，它将各平台的订阅权益（通常以Web界面形式提供）转化为标准API接口，使得命令行工具可以直接调用这些模型而无需每个平台单独的API密钥。

更值得深思的是他透露的下一步计划：手写一份全新的Codex系统提示词，不用任何AI生成。在他看来，提示词、skill这类东西——尤其是全局性的——就应该手工打磨，这样才能更好、更可控，并在使用中不断调整学习。这一观点与当前"用AI来写提示词"的流行趋势形成鲜明对比——手写提示词的优势在于作者对每一条规则的意图都了然于胸，能够精确预测其在边缘情况下的行为，而AI生成的提示词虽然表面完整，却往往缺乏这种深层意图的一致性。

这期内容的价值不在于"5.6+Claude Code"这个具体组合，而在于它揭示了一个常被忽视的真相：在模型能力趋同的今天，harness的工程质量（尤其是系统提示词和子代理编排）正在成为决定实际体验的关键变量。这一趋势类似于智能手机行业的演进——当芯片性能差距缩小后，操作系统优化、软硬件协同设计、应用生态等"软实力"成为了差异化竞争的核心。作为用户，读一读你天天在用的工具背后的系统提示词，或许比你想象的更有必要。

核心要点