耗费3亿token 让Astra总结我过往项目给出的codex子代理编排方案

原帖作者在高强度使用 GPT-6 Astra 后，让模型结合其多个项目的历史对话，整理出一套以 Astra 为主代理的 Codex 子代理编排方案。下面按原帖公开配置整理其结构、参数、工作流与使用边界。

全局调度规则

全局 AGENTS.md 中的核心约束包括：

• 简单任务由主代理直接完成；只有子任务能够独立交付，且并行可以减少等待或隔离大量探索上下文时才派发。
• 默认同时使用 1–3 个子代理；增加并发前先判断任务独立性、工具共享状态、整合成本及实际工具上限。
• 主代理负责计划、复杂实现、范围决策和最终整合；子代理不自行扩大范围，也不继续派生子代理。
• 默认使用 fork_turns="none"，在任务说明中明确目标、路径、已知事实、限制和完成条件。只有连续上下文确有必要时才传入有限历史。
• 多个代理不重复检索同一个问题；已有代理适合后续同类任务时优先复用。
• 子代理默认只读。机械修改必须明确文件范围、转换规则、排除项和验收方法，并避免回滚其他协作者的改动。
• 子代理通常只回传最终结论、证据和限制；阻塞、重大反证或能解除主代理依赖的中间结论应及时发送。
• 派发后主代理继续自己的独立工作，只有下一步确实依赖子代理结果时才等待。
• 主代理不默认重读全部文件或重跑全部检查，仅复核冲突、高风险结论和修改后的最终行为。

六类子代理配置

配置文件放在 .codex/agents 目录。原帖给出的角色与关键参数如下：

每个角色配置末尾都设置：

[agents]
enabled = false

其作用是禁止子代理继续派生子代理，把并发与范围控制保留在主代理。

各角色的完成协议

default

处理目标明确、需要少量综合判断的只读问题。基于实际文件或可靠来源返回结论、关键证据和未覆盖内容；证据充分即停止。最终首行使用 complete、partial 或 blocked。

quick_scan

只做给定范围内的事实抽取、定位和分类，不分析全仓库架构，也不修改文件或外部数据。若遇到事实冲突、复杂因果或范围不足，返回 partial 和具体证据缺口。

code_explorer

从指定入口追踪复杂调用链与共享契约，区分已验证关系、推断和未覆盖分支。不提出无关重构，也不实施代码修改。

mechanical_editor

仅修改主代理明确分配的文件，遵守转换规则、排除项与验收条件。优先使用 apply_patch；只有命中范围已经核对时才做批量替换。出现歧义、意外命中或影响范围扩大时停止。

reviewer

独立检查复杂变更中的正确性、安全、并发和契约问题。每项发现需要给出触发条件、影响和精确位置；没有发现时也要说明审查范围与限制。

verifier

只运行主代理指定、前提明确的本地验证。不修改业务代码、测试断言或依赖配置来让检查通过；必要检查通过后停止，失败时区分复现证据与推测。

作者的实际使用方式

作者表示，主模型日常主要使用 high 推理强度；较大需求在头脑风暴阶段使用 max，形成计划后再开启新的 high 对话，并通过 create_thread 拆分并行任务。主代理承担计划、思考与设计，子代理被视为减少上下文腐化和幻觉的工具。

作者在一次额度重置后的观察中，同时运行约 2–4 个对话并让各对话派发子任务，报告当时消耗约 10%，而按此前方式估计约为 15%。这是作者的单次使用记录，不是受控基准。回复中也有人指出，节省幅度可能不足 25%，同时需要承担任务偏移、协调时间和认知负担；不同模型的成本与效果也可能改变角色分配。

原作者：CodesMonkey
原帖：https://linux.do/t/topic/2894461