多 Agent 带来的关键变化，不是提示词应该更长，而是任务必须更清楚：哪些部分可以分头做，哪些结论需要等待，结果怎样合并，最后按什么标准验收。你需要改变的，是把“一句愿望”改写成一份可执行、可检查的任务说明。
本文以 2026 年 10 月 18 日为信息截点。以下使用方法均为建议，资料研究、代码审查与内容制作的例子都是待验证方案，并非本人实测。
先划清边界：这是 Chat 标签的产品更新
根据 OpenAI 2026 年 10 月 16 日的官方公告 ，ChatGPT 中的 GPT-6 Astra Pro 获得升级，包括响应提速，以及插件和工具使用的改善。与任务组织最相关的是：多个 Agent 可以并行处理一项任务的不同部分，用户能够跟踪各自进展，并打开已完成任务检查工作结果。
公告给出的开放范围是 Pro 用户的 Chat 标签。这是产品更新，不是新模型发布，也不代表全体用户开放。公告没有交代并发数量、用量限额或具体调度方式，不能据此补出操作细节。
另一个容易混淆的来源是 subagents 配置文档 。它属于 Work/Codex 背景，不能当作 Chat 标签的操作指南，更不能把 Codex CLI 的子 Agent 配置写成此次更新的入口。
这次更新明确提供了并行处理和进度查看能力，但“能够分头做”与“能够可靠交付”不是一回事。后者仍取决于任务边界、共享标准和验收过程。
委派：拆成交付物，而不是分配几个模糊角色
先写总目标，再为各部分定义交付物。与其只说“研究一下这个问题”，不如说明结果用于什么决定、允许使用哪些材料，以及最终需要证据表、问题清单还是建议稿。
一份可复核的委派说明，至少应回答四件事：
- 输入：可使用的材料、版本和时间范围是什么。
- 边界：负责回答什么，明确不处理什么。
- 产出：结果采用什么结构，怎样交给下一环节使用。
- 验收：什么算完成，证据不足或输入缺失时怎么办。
“负责分析”和“负责总结”看似分工，实际可能高度重叠。如果没有统一对象和标准，分头工作只是把模糊要求复制了几份，最后仍要由你重新梳理。
建议把共同约束放在任务说明前部，例如只依据给定材料、事实与推断分开、无法确认的内容标记为未知。各部分可以关注不同问题，但不能各用一套规则。
这里的“分工”是任务描述方法，不代表已经确认 Chat 支持手动创建、配置或指定某个 Agent。系统能否按指定职责拆分执行，仍需要在实际入口验证。
依赖：先决定谁必须等谁，再谈同时开工
以资料研究为例（以下为待验证方案）：假设你要根据一组已有材料，判断某项内部方案是否值得进入试点。先统一试点对象、判断标准和材料日期，再分别整理支持证据、反对证据与信息缺口。
这些整理工作可以在任务说明中被列为相对独立的部分，但最终判断应明确依赖证据整理完成。不要一边让某个分支寻找依据，一边要求另一个分支提前写出确定结论。
如果成本口径没有统一，一个分支关注采购费用，另一个关注使用时间，结果即使各自完整，也不能直接比较。并行之前需要统一的，不只是问题，还有词语的含义。
建议将依赖顺序写成：确认问题与口径 → 分别提取证据 → 检查冲突与缺口 → 形成判断。各部分交付时保留材料名称、日期、对应结论和不确定项，让后续合并能够回到原始依据，而不是只接收一段摘要。
验收时，重点检查结论是否超出材料覆盖范围。缺少关键证据时，可以交付“暂不足以判断”和待补材料清单，不必为了完成任务而补出一个答案。
合并：代码审查不能只把问题清单贴在一起
以代码审查为例（以下为待验证方案）：围绕同一个代码版本和同一组变更，按逻辑正确性、边界处理、测试遗漏等方向组织审查。先限定只提出发现，不修改文件，避免审查意见与代码改动混在一起。
每条发现都应包含定位信息、触发条件、可能影响，以及证据或验证方法。仅有“这里可能不安全”“建议优化”这样的表述，不足以成为可执行的审查结果。
多个方向可能重复指出同一个问题，也可能提出相反建议。因此，合并不是把清单顺次粘贴，而是重新判断发现之间的关系。
建议在总稿中区分三类情况：重复项合并，互相冲突的意见保留分歧与依据，尚未验证的问题单独列出。不能因为多个分支说法一致，就把它当成独立验证；它们可能依赖同一段材料或同一个错误前提。
验收还应检查证据等级。静态阅读得到的怀疑、可复现的问题和实际执行过的测试，不应写成同一种确定性。若没有执行测试，就不能把“建议这样验证”改写成“测试已通过”。
验收：内容制作要检查证据，也要检查整体
以内容制作为例（以下为待验证方案）：先固定读者、主题范围、可引用材料和篇幅，再将资料核对、结构草案、反例整理作为候选分工。正文定稿应等待关键材料确认，而不是让不同分支在背景不一致时直接各写一段，最后硬拼。
合并时，可以按“观点—证据—限制—行动”重新组织内容，不必保留各部分原来的段落顺序。某段文字即使单独成立，也可能与全文重复，或使用了另一套概念，需要删改。
建议将验收分成两层。局部检查关注事实能否找到来源、推断是否标明、缺口是否保留；整体检查关注术语是否一致、段落是否重复、前后结论是否冲突，以及文章是否真正回答了读者的问题。
公告所说的进度可见、完成任务可打开查看，为复核提供了条件，但不能据此推断结果已经正确。完成状态只能告诉你工作到了哪一步，不能代替内容验收。
建议在接收总稿前抽查关键结论及其来源，并检查合并过程中是否丢失了限制条件。对会影响最终判断的内容，不应只读摘要。
并行成本：别只计算生成答案的时间
并行可能缩短某些独立工作的等待时间，但不会自动消除总工作量。共享材料需要对齐，重复发现需要去重，冲突意见需要裁决，最终结果仍要复核。任务拆得越碎，协调工作也可能越多。
这里讨论的主要是组织与复核成本。公告没有给出此次并行能力的具体计费变化、资源消耗或限额，不能推断它更便宜，也不能自行估算单次任务费用。
建议优先尝试输入稳定、边界明确、结果容易比较的任务。如果后一环节必须等待前一环节判断，或者各部分需要反复协商同一个核心问题，就不宜为了“多 Agent”而强行拆分。
第一次尝试，建议选择范围较小、后果可控的任务，并记录总耗时、人工复核时间、重复结果和返工情况。若生成更快，却让你花更多时间理解和纠错，这次拆分就需要调整。
判断并行是否值得，建议看从提出任务到获得可用交付物的总成本，而不是只看各部分多快显示完成。必要时减少分支，先补清共同输入，再重新组织任务。
🧭 一份可以直接改写的任务说明
建议把下面这段作为起点，根据实际任务补齐括号内容。它是交付要求，不是已核实的产品操作流程。
目标：基于我提供的材料，形成供我复核的【交付物】，用于【用途】。
边界：只使用【材料范围】，遵守【约束】；缺少信息时明确标记，不自行补齐。
分工：先指出可独立处理的部分，以及必须等待上游结果的环节；在适用时分别处理独立部分。
输出：各部分采用统一格式，列出结论、依据、未知项与验证方法。
合并：去除重复项，保留冲突及其依据，不把未验证内容写成确定结论。
验收：按【标准】逐项检查，最后交付总稿、未解决问题和需要我判断的事项。
建议先检查这段说明里最空泛的词：“全面”指覆盖哪些范围，“准确”要求什么证据，“完成”意味着交出哪些内容。把这些词换成可检查的条件，比不断追加“请认真思考”更有操作性。
多 Agent 的意义，不在于让更多工作同时开始，而在于让独立工作能够汇成一个可靠结果。委派时说清边界，执行前写清依赖，合并时处理分歧，交付前保留验收——这才是需要改变的交任务方法。
延伸阅读：Agent Harness 。