把 GPT-5.4 的 1M 上下文真正跑起来、给 Codex 打开联网搜索、再搭一套多 Agents 协作流程，这三件事单独拎出来都不算难，但放在一起配置的时候，坑是真的多。我前后折腾了一周多，踩过"上下文看似开了实际没开"、搜索不触发、Agent 互相覆盖文件之类的各种坑，总算把整套方案稳定跑了起来。这篇文章就把完整的配置流程、参数选择和排错思路一次讲清楚。
适合谁来读？如果你是做 AI 应用开发的人，或者重度使用这类工具做代码生成、长文档分析、自动化任务编排的人，这篇文章可以直接抄作业。我会把每一步为什么这么配、参数为什么这么填、以及我实测下来的数据都写出来，而不是只给一份"照着点按钮"的清单。下面的内容按配置顺序展开，从整体思路到具体参数，最后是排错经验，你既可以从头读，也可以直接跳到遇到问题的章节。
1. 三个能力拆开看，才知道为什么要一起配
1.1 1M 上下文解决的是"读得全"的问题
在我拿到 1M 上下文对应的模型入口之后，第一反应是往里塞一份几十万行的项目代码试试。以前用较小的上下文窗口，模型目光如豆，看一个文件还要翻页分段喂；用 128K 能看一个中型仓库，但稍微大一点就得靠检索兜底。1M token 折算下来大约相当于 60 到 100 万汉字的体量，差不多是一本很厚的长篇小说的全部文字量。也就是说，你可以把一个项目的核心代码、文档、需求说明一次全部喂进去，不用切块，不用先做召回再拼装。
这个能力的价值不在于"窗口大"这个数字本身，而在于你终于可以换掉传统 RAG 流程里的那套切片、向量化、召回策略，直接让模型在完整上下文里定位信息。我实际测下来，当模型确实能看到全量内容时，回答的一致性比我之前用 RAG 拼出来的方案高了不少。检索策略做得再精细，本质上还是"盲人摸象"，而 1M 上下文给了模型一次"把大象完整看一遍"的机会。如果信息本身就在上下文里，模型就不太需要靠知识库去猜。
1.2 联网搜索解决的是"看得新"的问题
模型的知识是有截止时间的，这一点用过的人都有体会。你问它半个月前发布的一个库的新版本改了哪些接口，它大概率会一本正经地编一个不存在的 API 签名，因为它训练时根本没见过这些内容。Codex 的联网搜索解决的正是这个问题。在配置里把 web search 打开之后，Codex 在需要的时候会自己去检索网页、读文档、看 issue 讨论，然后把搜索到的最新信息缝合进回答和代码里。
实测里最典型的场景是：我让它写一段调用某个常用图表库的代码，它先搜索了一下这个库当前的最新版本和文档，然后给出的代码签名就是对的。不开搜索的时候，同样的提问，它给出的接口参数往往停留在旧版本上，甚至把已经废弃的写法当成最佳实践。开了搜索之后，模型对"时效性信息"的判断会主动转变：不懂就去查，而不是硬编。
1.3 多 Agents 解决的是"做得开"的问题
单个模型再配上再大的上下文，本质上还是一个"单线程"的大脑。你让它处理一个涉及规划、调研、编码、质检的复合任务，它容易做着做着就绕晕，前面定下的方案后面自己就推翻了。多 Agents 的思路是把任务拆开，让不同角色各管一摊，每个 Agent 只处理自己范围内的子任务，最后再汇总。
我把这套配置里的 Agent 分了四类：规划者、研究者、写码者、评审者。规划者负责拆任务，研究者负责查资料，写码者负责出实现，评审者负责质量把关。每个 Agent 的上下文是独立的，但它们共享一个任务状态区，这个状态区放在 1M 的共享上下文里。这个配合是整套方案的骨架，也是后面所有配置的意义所在。单 Agent 是一条流水线，多 Agent 是一张协作网络，能扛的任务复杂度完全不是一个等级。
1.4 配置顺序建议：先基础、后扩展
我的建议很直接：不要一上来就开 Agent 编排。先把模型切到 GPT-5.4，确认 1M 上下文真的生效，再验证 Codex 的搜索可靠性，最后才上多 Agents。前两步是地基，地基不稳，Agent 越多越乱。我一开始就是顺序反了，先在 Agents 配置里折腾了半天，结果发现有些问题根本不是编排逻辑的问题，而是模型入口没选对、上下文没真正开起来。后来乖乖按顺序来，排查成本直接降了一个量级。后面各章我也就按这个顺序展开，你可以边看边跟着配。
2. 开启 GPT-5.4 和 1M 上下文，其实是两件事
2.1 先确认入口和账号权限
很多人以为把客户端升级到最新版就有 1M 上下文了，其实不是。模型能力和上下文窗口是两套配置，入口决定你拿到的到底是不是支持长上下文的版本。我在配置前会先做一次简单的探测：发一个最小的请求进去，在返回的元信息里看模型标识是不是带长上下文权限的版本。如果走的是 API 方式，可以去查一下模型列表接口，看看当前账号下到底挂载了哪些模型变体。有的入口只有标准版，没有长上下文版；有的入口虽然显示支持，但实际请求到了服务端就被降级了。
这个探测成本很低，但能省掉后面一大堆"为什么塞不进长文"的排查。之前我遇到过一种情况：配置写得好好的，一上传大文档就报长度超限，后来才发现问题根本不是参数没写对，而是那个入口压根没有挂长上下文模型。先在入口层面确认好，比什么都重要。
2.2 关键参数：上下文窗口和单次回复上限要分清
先弄清一个概念：上下文窗口和单次回复长度是两回事。1M 指的是请求里最多能放 1,048,576 个 token 的输入，不是让模型一次性吐 100 万 token 的输出。实际配置里，我比较稳妥的组合是输入窗口给满 1M，单次回复上限设成 16,384，也就是 16K。这样即使任务需要多轮逐步输出，也预留了足够的空间，又不会因为一次生成太长而导致超时和成本失控。
在 API 请求里，关键的参数是这几个：
| 参数名 | 我使用的值 | 作用 |
|---|---|---|
| model | gpt-5.4-1m | 指定支持 1M 上下文的模型变体 |
| context_window | 1048576 | 设置上下文窗口上限 |
| max_tokens | 16384 | 设置单次回复的最大 token 数 |
| stream | true | 开启流式输出，避免长任务等待时表现像卡死 |
如果你用的是客户端而不是 API，通常在设置里也能找到上下文长度选项，直接拉到最大即可。但要注意，客户端显示出来的设置和实际生效的值不一定是同一个，界面勾选了一个"长上下文模式"，有的版本并不会真正切换成对应模型，只是把界面上的数值改大了。所以后面那个"写入再回读"的验证步骤绝对不要跳过。
2.3 用"写入再回读"验证 1M 是否真正生效
我第一次配置完就想当然觉得生效了，结果喂了一篇长文档进去，模型回答的内容明显只基于了开头和结尾，典型的中间截断。后来我学乖了，写了一个简单的验证脚本：在上下文的中间位置插入一段只有这段才有的特殊内容，比如一行随机字符串，然后问模型"中间那段特殊内容是什么"。如果上下文真的全量加载，模型应该准确回读出那行字符串；如果它答不上来，说明存在截断、压缩或入口不对三种可能。
# 仅作示意：把超长文本写入上下文，再回读中间区域的标记内容 client = llm_client(endpoint="你的服务入口", api_key="你的密钥") marker = "中间标记:verify_7f3a9c21" content = "A" * 500000 + marker + "B" * 500000 resp = client.completions.create( model="gpt-5.4-1m", messages=[ {"role": "user", "content": content}, {"role": "user", "content": "请回答整个上下文中出现的标记字符串是什么？"}, ], max_tokens=64, ) print(resp.text)如果输出里完整出现了 verify_7f3a9c21，说明 1M 是真的生效了；如果答不上来或者说"找不到"，就要检查入口权限和中间层是否截断了请求。这一步非常便宜，几分钟就能测完，但它能直接告诉你前面所有配置有没有白做。我强烈建议任何开了 1M 上下文的人都先跑一遍这个验证，再开始干正事，否则后面所有结论都是建在沙子上。
2.4 成本、延迟和精度的三角权衡
1M 上下文不是免费的。每次请求的 token 用量会直接体现在账单里，尤其当你把几十万字的资料整个塞进去的时候，光输入就是几十万 token 的量级。我实测下来的经验是：没必要所有请求都开满 1M。可以根据任务类型分级，分析大型代码库或者整本文档时才切换长上下文模式，平时的小任务用标准上下文窗口就够，成本能差出一个数量级。
另一个被低估的问题是首 token 延迟。输入越长，模型处理和预填充的时间就越长。我拿 1M 上下文跑一次长文档分析，首 token 出来的时间比 128K 模式慢了 5 到 8 倍。如果是交互式场景还勉强能接受，但如果你想拿它做实时在线服务，一定要提前做性能测试，别让用户对着空白页面干等。总结下来就是：1M 是把双刃剑，用对场景是利器，不分场景滥用就是烧钱加拖慢。
3. Codex 联网搜索：从开关到调参
3.1 Codex 在这套体系里到底是干嘛的
在这个配置里，Codex 不单纯是另一个大模型，它更像是一层"执行引擎"。它的职责包括：根据你给的意图拆解操作步骤、生成代码、在当前环境里执行命令、调用外部工具，以及在需要的时候去网上搜资料。你可以把它理解成模型的"手和脚"：模型负责思考，Codex 负责把事情落地。
所以"Codex 联网搜索"这个功能，本质上是给执行引擎接上了一双"眼睛"。之前它只能凭训练时的知识做推断，现在它可以先搜、再读、最后再执行，整个链条的可靠性提升非常明显。我见过不少朋友只关注模型本身的参数，却忽略了这个执行层的配置，结果模型再强，落地的时候还是抓瞎。Codex 这一层配置好了，模型的思考才能真正转成可运行的成果。
3.2 打开联网搜索的完整步骤
不同环境下的开关位置可能不一样，但我用的这套流程在 API 和客户端配置里都能复用，分四步走：
第一步，在能力开关里把 Codex 功能置为启用状态，这一步通常在全局配置里。第二步，专门打开 web_search 选项，很多人只开了 Codex，忘了单独打开搜索，导致 Codex 有权限工具但一直没有"眼睛"。第三步，配置搜索参数，包括搜索深度、单次最大返回结果数、搜索超时时间，具体取值下一节展开。第四步，在系统提示里加上一句"当信息可能超出知识截止日期时，主动使用搜索工具"，这句话能显著提高搜索的触发频率。
配置完以后同样要验证。我用的测试很直接：问它"某个知名开源工具昨天的版本更新内容"，如果它给出的回答具体到日期、与事实吻合、并且能给出信息来源，就说明搜索链路是通的。如果它含糊其辞或者编造日期，那就是搜索根本没触发，或者触发后被模型忽略掉了。
3.3 搜索参数调优实测
搜索参数里最容易影响效果的是搜索深度和最大结果数。深度拉满意味着每次搜索会抓更多的网页、读更长的页面正文，准确性通常会高一点，但延迟和 token 消耗也会涨。最大结果数决定单次搜索拿多少条结果回填到上下文，数量太少可能漏掉关键信息，数量太多又会引入噪声。
| 参数 | 低频场景 | 高频场景 | 我的建议 |
|---|---|---|---|
| search_depth | low | high | 默认 high，敏感任务可调 low |
| max_search_results | 3 | 8 | 5 兼顾速度和覆盖面 |
| timeout | 20 秒 | 60 秒 | 30 秒足够，再长影响整体体验 |
我实测下来，max_search_results 设成 5 是性价比比较高的档位。少于 3 的时候，如果第一页结果本身质量差，就没有退路了；超过 8 以后，多出来的那些结果基本是干扰项，反而会干扰模型判断。如果你当前任务对时效性要求不高，把深度降到 low，延迟能砍掉差不多一半。这个结论是我跑了十几组对比才定下来的，不是拍脑袋给的。
3.4 实测：先查文档再写代码
拿一个我实际跑过的场景举例。某次项目里要给一个老系统对接某个新发布的图表库，但我完全不清楚这个库最新版本的接口长什么样。如果不开搜索，我硬写出来的代码大概率用的是旧版签名，能运行但和新版本生态对不上，后续升级会很痛苦。
开搜索之后，Codex 先发起一轮检索，读了该库的官方文档首页和发布说明，找到了新的初始化接口和参数结构，然后把信息写进了任务上下文。接着它才动手写代码。整个过程中，我能从运行日志里看到搜索子任务的执行记录：请求什么时候发出的、结果什么时候回写、哪些网页内容被采纳了。这种"先看后做"的链路，才是 Codex 联网搜索最有价值的打开方式。如果跳过搜索直接写，等于让一个隔了很久没更新知识的人凭记忆写代码。
4. 多 Agents 配置：角色、通信和编排
4.1 角色先定义清楚，别让 Agent 互相打架
多 Agents 系统最怕的不是某个 Agent 变笨，而是职责边界不清楚。两个 Agent 同时改一块内容，最后互相覆盖，甚至为了一个问题来回踢皮球，整体效率比单 Agent 还低。我的做法很直接：在配置之前先把角色清单写死，每个 Agent 只负责自己的那部分工作，不允许越权处理。
我目前固定使用的四个角色如下，各位可以参考并根据自己的场景调整：
| 角色名 | 核心职责 | 使用工具 |
|---|---|---|
| orchestrator | 拆解任务、分配子任务、汇总结果 | 上下文管理、任务调度 |
| researcher | 查资料、读文档、整理信息 | 联网搜索、文档阅读 |
| coder | 按方案写代码、执行本地脚本 | 代码生成、本地执行 |
| reviewer | 审查产物、跑测试、给修改意见 | 代码审查、测试执行 |
这套划分的经验是：角色数量控制在 3 到 5 个之间最舒服。少了，每个 Agent 负载太重，遇到复合任务容易顾此失彼；多了，通信成本会指数级上升，明明是协作，最后大量的时间都花在等别的 Agent 传结果上。4 个对我来说是当前方案下的平衡点。
4.2 一份可落地的配置结构
我用的配置以 YAML 形式维护，每次调整环境可以直接改文件再重新加载，不需要动业务代码。核心结构大致如下，你可以直接抄走改一改：
model: gpt-5.4-1m context_window: 1048576 max_tokens: 16384 capabilities: codex: enabled: true web_search: true search_depth: high max_search_results: 5 timeout: 30 agents: - name: orchestrator role: planner model: gpt-5.4-1m memory: full_context tools: [context_management, task_dispatch] - name: researcher role: informer model: gpt-5.4-standard max_tokens: 8192 memory: subtask_context tools: [web_search, doc_reader] - name: coder role: implementer model: gpt-5.4-standard max_tokens: 8192 memory: subtask_context tools: [code_generation, local_execution] - name: reviewer role: quality_gate model: gpt-5.4-standard max_tokens: 8192 memory: subtask_context tools: [code_review, test_runner]这里有个关键设计：orchestrator 的 memory 是 full_context，也就是它能访问完整的 1M 共享上下文；其他执行角色只访问自己收到的子任务片段。这样做的原因很简单：避免每个 Agent 都把全部历史加载一遍，既省 token，也减少相互干扰。共享上下文是全局状态，子任务上下文是每个 Agent 的工作台，两者通过调度接口同步。这个"全局看板 + 独立工作台"的结构，是我来回调了好几版才定下来的。
4.3 三种协作模式怎么选
多 Agents 编排模式不是万能的，不同任务适合不同的协作方式。我总结下来有三种常用形态，实际使用时要在配置阶段就选好。
第一种是串行流水线。先由 researcher 查资料，再由 coder 写代码，最后由 reviewer 审查。这种模式适合任务链条清晰、前后依赖关系强的场景。优点是整体逻辑简单，每个环节的输入输出都好控制；缺点是任何一个环节卡住，后面所有步骤都得等着，整体吞吐量被最慢的那个 Agent 决定。我一般把这种模式用在链路稳定、不需要反复横跳的任务上。
第二种是并行扇出。orchestrator 把任务切成多个互相独立的子任务，同时派给多个 coder，最后统一汇总。适合模块化强、子任务之间几乎没有依赖的开发任务。优点是吞吐量高，多个模块可以同步推进；缺点是需要保证子任务真的互不依赖，否则合并的时候冲突会非常明显。而且并行越多，token 消耗越快，预算控制要同步收紧。
第三种是主从模式。orchestrator 始终掌握全局，其余 Agent 都是执行者，每隔一段时间把进展回报给 orchestrator，由它决定下一步怎么走。适合长周期、需要频繁修正方向的任务。优点是方向把控好，不会跑偏；缺点是 orchestrator 容易成为瓶颈，调度逻辑写得不够稳的话，整体都会卡在它身上。
我日常跑最多的还是第一种。虽然并行扇出看起来效率高，但现实里的任务很难做到完全无依赖，硬拆并行往往得不偿失。主从模式对大任务友好，但对调度器的要求高，前期投入比较大。先把串行流水线跑稳，再逐步往并行和主从演进，是比较稳妥的路线。
4.4 一个完整流程演示
举一个我实际跑过的例子，目标是给一个内部项目增加一个新的数据处理模块。
orchestrator 先读取 1M 上下文里的项目全貌，把任务拆成三块：调研现有数据格式、编写处理模块、补充单元测试。随后它把调研子任务派给 researcher，researcher 搜索了相关领域的最佳实践，结合项目文档整理出一份格式说明。orchestrator 拿到说明后，把它作为子任务上下文交给 coder，coder 开始写实现。写完后，reviewer 拿到代码和测试用例，跑了一遍测试，发现一个边界条件下会出错的问题，把问题反馈给 coder。最后 coder 修复完，reviewer 确认通过，orchestrator 把最终结果写回共享上下文，整条任务的产物就完整落在项目里了。
整个过程里，四个 Agent 没有直接对话，所有信息都通过 orchestrator 中转。这个设计是我踩过坑之后学到的：Agent 之间直接通信看似省了一步，但一旦信息版本不同步，后面排查起来非常痛苦。统一走调度器，日志和状态都集中在一个地方，出了问题能很快定位是哪个环节的锅。多 Agent 不是把一堆模型扔在一起就行，关键要把数据和消息的流转结构设计好。
5. 常见问题排查实录
5.1 上下文"假开启"了怎么办
这个坑我印象特别深，你以为你已经开启了 1M，实际上模型根本没有拿到全量输入。常见原因有三个：一是入口本身不支持长上下文版本；二是客户端或中间层限制了请求长度；三是模型在处理超长输入时触发了自动压缩策略，把中间内容做了摘要而不是原文匹配。
排查方法从简单到复杂排序：先确认模型标识没问题，再打印实际请求的 token 数看有没有达到预期，最后跑一遍"中间内容回读"测试。如果三条都排除了还是有问题，去看服务端日志里有没有上下文被裁剪的记录。我的经验是八成以上的"假开启"都出在第二层，也就是中间层把请求长度截断了，学会看日志之后，这类问题基本一抓一个准。
5.2 Codex 搜索不触发或结果太旧
搜索不触发，最典型的原因就是系统提示里没有声明"可以用搜索"。模型默认情况下不会拿自己的自由度去调用外部工具，它更倾向于直接基于训练知识回答。解决办法是在提示词里显式声明：当问题可能涉及时效性信息时，必须使用搜索工具，并在回答中标注信息来源。加了这句话之后，搜索触发率会直线上升。
另一个常见问题是搜索确实触发了，但结果出来还是旧的。这种情况多半是 max_search_results 设太低，或者结果排序权重偏向低质量来源。我建议先把这个值提到 8 重新跑一次，如果结果变好了，说明是覆盖面不够；如果还是不变，那大概率是搜索服务本身的索引就有延迟，等一段时间再测。别一上来就怀疑模型能力，先看搜索返回的原始内容到底新不新。
5.3 Agent 互相覆盖工作内容
多 Agent 协作里最让人头疼的，就是两个 Agent 改了同一个文件，后写的人把先写的人覆盖了。我处理这个问题的办法分两层。第一层是任务所有权：每个文件在同一时间只允许一个 Agent 持有写权限，orchestrator 调度时会登记当前持有者；第二层是变更版本管理：每个 Agent 写回内容之前先对比基线，如果发现基线已经被别的 Agent 改过，就强制这个 Agent 重新拉取最新版再合并。
这套防护加进去之后，覆盖问题基本没有再出现过。核心思路其实不是"防止覆盖"，而是"提前暴露冲突"：宁可让 Agent 停下来重新同步，也不要让静默覆盖把别人改的东西丢进历史里。代码托管工具里的冲突标记就是干这个的，多 Agent 系统里也一样，早冲突早处理，比晚发现好得多。
5.4 成本失控怎么办
同时开 1M 上下文和多个 Agent 时，token 消耗会以让人心疼的速度增长。我见过一次跑一个中等复杂度任务，光 orchestrator 读全量上下文就烧掉十几万 token。要控制成本，给每个 Agent 限定独立的 max_tokens 和 memory 策略是最有效的手段。另外，把共享上下文设计成"按需分页加载"，而不是每个 Agent 启动就全量读取，也能省下不少 token。
我顺手做了个预算开关：每次任务开始前先估算 token 上限，超过预算直接拒绝执行，比事后看账单后悔强得多。成本问题不是功能问题的时候，它就是设计问题。在配置结构里把预算控制预留出来，后面运营会轻松很多。
5.5 排查顺序建议
最后整理一个排查顺序，遇到问题按顺序查，而不是东一榔头西一棒子。第一层查入口和权限，有权限问题先解决权限；第二层查配置参数，把 context_window、max_tokens、web_search 开关逐项核对；第三层查运行时日志，看请求是否真的带上了预期参数、搜索子任务有没有下发；第四层才查业务代码和提示词设计。绝大多数配置类问题到第三层之前就能定位。
把排查顺序固化下来之后，我这边处理异常案例的时间基本从小时级降到了分钟级。这套方法论比任何单个参数的配置技巧都值钱，因为它能让你在面对陌生问题时，快速缩小怀疑范围。
把这些功能全部配完再跑顺之后，我最大的体会是：单独开任何一个能力都只是锦上添花，真正让整套方案产生质变的，是 1M 上下文、Codex 联网搜索和多 Agents 这三者之间的咬合关系。上下文给了模型深度，搜索给了模型时效，多 Agent 给了整个流程并行度和可维护性。三者各干各的活，又通过共享上下文和调度器捏在一起，这个结构是整套方案的核心。
最后分享一个小技巧：把你调好的整套配置保存成一个版本化的配置文件，放到代码仓库里管理。每次参数调整都留个提交记录，这样一旦新版本模型或某个新配置导致行为变化，你可以快速回滚到上一版稳定状态。这套配置我已经迭代了好几十个版本，每次改动都有据可查，返工成本比之前凭记忆改配置低了很多。希望这篇文章能帮你绕开我踩过的那些坑，少花点时间在配置上，多花点时间在真正该做的事上。
