如何用 Codex 管理 50 个 Agent

我试过同时盯几个 Codex 会话。两三个的时候，感觉自己很能干。到了第五个窗口，问题开始排队：一个要我回忆上周为什么改了算法，一个等我解释代码边界，还有一个做完实验，问下一步听谁的。Agent 在并行，我在窗口之间来回交过路费。

十个会话已经很难照看。每开一个 Agent，既多了一份执行力，也多了一条通向我的求助热线。如果目标是二十个、五十个 Agent，我得先改变谁来接这些电话。我想只和少数几个长期负责人说话，让他们管理下面的工作。五十是设计目标，不是我已经验证过的产能。

为什么先要 Chief of Staff

先说 Chief of Staff，因为新项目一多，光是建立负责人就会消耗我的注意力。客户项目、内部研发、技术学习，每条长期工作线都要定职责、沟通方式、权限和记录位置。我把自己的偏好告诉 Chief of Staff，让它起草新 Director 的岗位说明，再由我决定是否启用。

它像团队里负责招聘和培养 Director 的人。新 Director 的角色设定、决定和历史放在 Git 里；会话出了问题，Chief of Staff 可以根据记录重建。它也检查各岗位的定时任务有没有正常运行，按轮值查看负责人的直接交流，发现有证据的问题才辅导。某位 Director 沟通出了错，不等于所有 Director 都该改同一条规则。

Chief of Staff 不接具体项目。健康检查也只看排程、运行状态和阻碍，不顺手审业务报告或代码。它把这一层维护好，我才不用每增加一个项目就亲自训练一遍负责人。

为什么每个长期项目要有 Director

这里要把两个名字分清。以前我开一个完整的 Codex session，交给它一个任务。它可以自己读文件、改代码、跑检查，也可以再叫别的 Agent 帮忙。我把这种既能干活、又能带人的 session 叫 Manager。

Director 也是完整的 Codex session，但我不给它具体执行任务。它长期负责一条项目线，保存目标、偏好和决定；有活时，它启动 Manager。这个 Manager 是 Director 的 sub-agent。Manager 接到任务以后，可以自己做，也可以再开 sub-agent。Director 负责给背景、接住问题、审查结果，再向我汇报。这就是我用 Director 这个新名字的原因：它与原来那个会亲自做事的 Manager 不是同一层。

一个 Director 对应一个长期项目或清楚的工作领域。同一客户的两条工作线，如果目标和决策节奏不同，也可以分别交给两个 Director。我主要和少数几个熟悉项目的 Director 交谈，不用给每个新 Manager 重新讲一遍历史。

Director 留在主会话里，几个 Manager 可以同时工作。我继续交代下一件事时，它仍然能回应。这样才有机会从管理几个会话走向管理几十个 Agent；到底能并行多少，还要看任务依赖、审查能力和成本。

团队架构：Director 管 Manager

图中的数量只是示意。关键是两级父子关系：Manager 是 Director 的 sub-agent；Manager 也可以再开自己的 sub-agent。

如果岗位只画在图上，实际出了问题却都来找我，这张图没有意义。每一层必须知道自己该接住什么、什么时候往上交。我仍然决定目标、优先级和需要人判断的取舍。其他角色的边界可以压缩成一张表：

问题先在这一条线上解决：sub-agent 问 Manager，Manager 问 Director；需要我取舍或授予新权限时，Director 再来找我。

Manager 的权限由 Director 给的具体任务决定。一个代码质量 Manager 可以自己修复范围清楚的问题；另一个 Manager 可能只负责指挥下层 Agent。岗位名称本身不会扩大权限。

一个实验怎样跑起来

我在会上举过一个实验的例子：先清理数据，再改算法，最后验证模型。过去，我可能开三个会话，自己记住谁在等谁。现在我把实验交给项目 Director。它给数据清理和算法改动分别开一个 Manager；验证要用到清理后的数据，就等数据准备好再启动。

每个 Manager 都是 Director 开出的 sub-agent，也都是完整的 Codex session。数据清理的 Manager 可以自己读文件、写脚本、跑检查；如果任务值得再拆，它也可以开自己的 sub-agent。算法 Manager 也一样。需要 Claude Code 时，Manager 可以在自己的任务范围内调用它，或让下层 Agent 调用。Director 不替他们写代码，它检查交回来的结果能否拼成一个完整实验。

平时 Manager 在后台安静做事：自己执行，或指挥下层 Agent。下层 Agent 有问题先问 Manager；Manager 解决不了才问 Director。Director 留在主会话里，我可以继续和它谈下一件事。只有涉及新的权限、目标变化或必须由我决定的取舍，它才把问题推到我面前。

重要任务可以把 Manager 带到前台

有的任务需要我看见推理过程，光听 Director 转述结论不够。比如算法方向有争议，我想直接问执行者为什么舍弃另一种做法。Director 可以把负责这件事的 Manager 带到 Codex 里一个可见的独立会话，我直接进去和它讨论。讨论完，Manager 把新决定、剩余问题和工作结果总结给 Director；Director 也能读这段对话，更新项目记录，继续跟进。这样的会话只在需要我判断时打开，平时 Manager 继续安静干活。

Codex 怎样与 Claude Code 协作

会议中有人问：如果编码任务更适合 Claude Code，是否还要在两个应用里分别维护对话？我不想为了换一个编码工具，就重新向另一个窗口解释项目。所以项目入口仍在 Codex：我和 Director 说话，Director 把任务交给 Manager；获授权的 Manager 可以自己用 Codex 做，也可以在独立工作目录中调用 Claude Code CLI，或者让自己的 sub-agent 调用。

Claude Code 的非交互模式支持 claude -p，也可以用 --output-format json 返回机器可读的结果。一个示意调用是：

claude -p "在当前工作目录完成指定的局部代码修改，运行相关检查，返回修改文件、检查结果和未解决问题。不要提交。" --output-format json

Manager 要补上文件范围、验收条件和已授权的操作。CLI 是否能编辑或运行命令，取决于它自己的认证和工具权限配置。多个编码执行者同时工作时，给它们独立工作目录，或分配互不重叠的文件。Claude Code CLI 参考和非交互模式说明列出了这些调用方式。

Claude Code 的输出先回到调用它的 Manager 或下层 Agent，再沿 Manager → Director 的路径上报。Director 看变更和测试结果，再给我项目层面的结论。我不用在两个应用里分别维护一份项目对话。

多个项目怎样交换信息

项目之间会遇到相似的问题。如果每个 Director 都从零研究一遍，前一个项目的经验就白费了；如果直接复制整段聊天，接收方又要在大量细节里找结论。我只用两种办法交换信息。

需要长期保留的结论，就写进 Git 中的项目记录，附上相关决定、结果和来源。另一个 Director 按需读取，不必加载整个项目历史。

需要看原始讨论时，复制那段 Codex 对话的 deep link，交给有权限的 Director。它可以沿链接直接读取对话，抓取与自己项目有关的部分；如果要长期复用，再把提炼后的结论写进自己的 Git 记录。例如，项目 B 想借用项目 A 的数据校验方法，可以先读 A 的记录；若摘要不够，再用 deep link 查看当时的讨论，确认适用条件。

项目结束时，原 Director 也可以把记录或对话链接交给接手者，让对方浓缩并保存需要延续的经验。

定时检查让系统运转，但不淹没人的注意力

Director 是长期负责人，但它不会因为会话还开着，就自动知道什么时候该回头看任务。我按岗位设定检查频率和时段：有的 Director 在工作时段每小时看一次，有的每天一次就够。每次触发只做一次检查；上一轮没结束，不启动重叠的一轮。

检查的目的也不是每小时给我发一封「一切正常」。没有实质变化就保持安静；有重要进展、阻碍、风险或需要我决定的事，再来找我。

上面是组织的骨架。真要让它长期运转，还有三件小事：怎样记住做过的决定，怎样在开工前问清目标，怎样把一句话准确地交给下一层。

Tip 1：把项目记忆放在 Git

Director 要长期负责项目，聊天记录却会越积越长。每次开工都把完整历史读一遍，成本高，也会把当前任务淹没；只靠聊天窗口记事，换一次会话又可能丢掉岗位设定和旧决定。我把需要延续的东西放进 Git。

每个 Director 有名字、职责说明和一个指定的 Git 文件夹，用来保存角色设定、工作偏好、当前状态、重要决定以及按时间整理的历史。一个可用的目录可以长这样：

projects/forecasting/
  role.md         # 这个岗位负责什么、可做什么
  current.md      # 当前目标、任务、阻碍
  decisions.md    # 已做的关键决定和理由
  history/        # 较早的交接与工作记录

文件名可以不同。Director 平时读岗位职责、当前状态和这次任务需要的记录；旧历史留在文件里，碰到相关问题再查。某天它走偏或会话需要更换，Chief of Staff 也有资料把这个岗位重新建起来。

Tip 2：用苏格拉底式提问检查任务理解

苏格拉底式提问，原本是一种通过连续追问来检验想法的方法：你说的概念到底是什么？依据是什么？有没有未经检查的假设？如果照这个想法做，会有什么后果？提问的人不是急着给答案，而是让对方把自己脑中的前提说出来。康涅狄格大学对苏格拉底式提问的介绍把澄清、假设、证据、后果和其他视角列为常见的提问方向。

我借用的是这个动作，不是让 Agent 每接一个任务就展开一场哲学辩论。Agent 很容易听到「把预测模型做好」就开始跑实验，最后把误差降了，却发现我真正担心的是线上运行时间。第一条实质回复里，它先用一句话复述自己理解的目标，再问一个能暴露取舍的问题，比如：「如果更低的误差需要把运行时间翻倍，这次实验应优先守住哪一个指标？」这样的问题比「我可以开始吗」有用得多。前者能发现目标里的空白，后者只会多一次确认。

这个问题不该卡住已经授权的工作。Manager 可以先清理数据、检查现有基线；只有实验方向真的取决于我的选择，才把问题沿着 Manager → Director 的路径送上来。定时检查也不需要每次重新问一遍。它的价值在任务入口：让错误的假设尽早浮出水面，而不是等三个 Agent 忙完才发现大家跑向了不同的终点。

Tip 3：借用 ASD-STE100 让表达更清楚

ASD-STE100 是 Simplified Technical English，一套为技术文档制定的受控英语标准，源于航空航天领域的维护文档。它由写作规则和受控词典两部分组成，目的是让不同背景的读者对同一句操作说明尽量得到同一个意思。ASD-STE100 官方标准可以查到完整规则和词典。

五十个 Agent 的问题，除了谁向谁汇报，还有一句话经过几层转述后会不会变形。「把数据处理一下，跑一下看看，有问题及时同步」听着很自然，交给 Manager 却有太多空白：处理到什么程度？跑哪个实验？什么情况算有问题？我会把它改成：「Manager A 删除重复记录，并记录删除数量。Manager B 使用清理后的数据运行基线实验。如果输入缺少必需字段，先报告 Director，不自行猜测补值。」执行者、动作、交付物和升级条件都写在句子里。

中文对话里，我借用它的原则：用具体的词和短句，同一个概念始终用同一个名字，尽量说清谁做什么。英文技术交接则可以进一步按 ASD-STE100 的规则和受控词典写。这里的中文例子只是在借鉴清晰写法，不是宣称中文符合这套英语标准。消息越要跨层传递，我越愿意多花几秒钟把它写准。

五十个 Agent 不是成绩单。要是我仍在五十个窗口间巡逻，这套架构只是把忙乱画成了一张组织图。真正有用的时刻，是任务在 Director 和 Manager 那里自己往前走，而重要的判断穿过这些层级，仍能准确地回到我手里。