我如何使用一个 AI 开发团队六篇文章之后的实践与反思过去六篇文章我分别写了 AI 团队的角色、模型分配、MCP 召回、并行协作、交付验收和指标面板。单独看每篇都在解释一种机制放在一起却容易漏掉最重要的问题这个团队实际怎么用为什么值得这样组织对我来说Codex Team Runtime 首先是一个工作实验。我希望几个持续存在的 Agent 能承接不同职责让我既能委托工作也能随时进入具体任务而不是把所有需求、实现和验收塞进一个越来越长的对话。在目前相对稳定的使用模式下团队已经带来了实际价值。分工、讨论和验收有协商成本但对我的日常工作来说这部分成本可以接受。更值得研究的是怎样保留有价值的协作让不同任务得到合适的模型能力而不是承担同样复杂的流程。这篇文章既是使用方式的回顾也是研究方向的一次调整我开始把评估对象从一次模型调用转向一次完整交付。1. 我的使用入口仍然是一项工作实际开发版本中的团队任务入口。用户可以进入不同角色的工作过程。我不会先要求 Agent 演一场“多角色讨论”。入口仍然是工作本身实现一个功能、准备一个交付包或者调查一个问题。区别在于这项工作会进入一个有持续职责的团队Manager 负责澄清范围、拆分任务、协调接口以及最后的验收判断。Worker 在各自独立的任务中执行工作提交产物和证据。Liaison 提供讨论和进度入口帮助我理解团队状态但不代替 Manager 派发或验收。这些不是藏在一次模型调用里的角色标签而是我能打开、查看和参与的 Codex 任务。如果我只是想知道进展可以从 Liaison 进入如果想讨论某个实现可以打开对应 Worker。直接交流产生了范围变化仍然需要回到 Manager 的协调过程避免一个局部决定悄悄改变整项交付。对于第一次尝试的人我建议先从一个 Manager 和一个 Worker 开始在所用版本的安装说明下完成 Skill、运行组件和 MCP 配置确认成员登记及角色召回可用再交给它一项边界清楚的工作。下面是一种任务表达示例不是保证自动完成团队初始化的特殊命令完成这个模块的修改只处理约定范围。实现后提交变更说明、产物位置、验证结果和未完成项由 Manager 独立检查后再向我交付。第一轮值得观察的不是启动了多少 Agent而是任务能否从派发走到提交、检查和交付如果中途停下来下次还能不能接上。2. 并行的价值来自责任边界按项目划分责任的实际方案。截图记录的是拆分建议当时登记与派工尚未完成不是并行开发完成的证明。一个实际使用场景是跨项目的固件升级开发。这里同时涉及下游能力、平台服务和前端界面。拆分方案不是让两个 Worker 分别完成“在线升级”和“离线升级”而是按项目划分责任一个处理下游文件准备和指令相关能力一个处理平台公共任务及进度接口一个处理前端页面、上传和状态展示。这样拆分的意义在于在线和离线场景可能共享同一项目里的代码。按场景各做一遍很容易让不同 Worker 同时改变公共逻辑。按项目划分后团队需要先对齐接口再推进各自的实现。我在这次使用中观察到了这样的协作过程。这里仍然有两种不同的依赖接口约定有时可以先谈清楚随后并行真实产物依赖则不能靠一条“请并行执行”的指令消除。因此我更在意团队是否减少了反复解释和相互覆盖而不是 Agent 数量本身。独立工作区可以隔离文件修改却不会自动解决接口理解不一致。3. 长期团队需要恢复的不只是角色一次请求中的角色召回行为这里没有展示完整的上下文压缩与恢复过程。团队持续使用以后对话会变长也会中断。仅仅在提示词里写“你是 Manager”不足以描述恢复之后应该发生什么。我的做法是把角色关系放到持久记录中通过 Team Context MCP 提供查询入口。MCP 在这里不是记忆本身重要的是背后有可以重新读取的团队、成员和职责记录。恢复时至少要分清三件事我属于哪个团队、承担什么职责团队现在有什么工作当前用户是否希望我继续处理这些工作。角色召回解决第一件事但不能替代后两件事。一个 Agent 找到了自己的 Manager 身份不意味着某个旧任务仍然获得授权也不意味着它知道哪些提交还等着审查。这也是最近优化中很重要的认识恢复角色的入口应当接到恢复工作的入口。待审事项应该从任务和提交状态中找回而不是再复制一份到长期记忆里维护另一套容易过期的待办。在此前一段超过两周的实际使用中我的三个团队、十几个 Agent 没有出现我观察到的团队记忆丢失。这是有价值的使用体验但不是系统性的成功率测量也不能保证每次恢复后的行为都正确。真正需要检查的是它是否带着正确身份找到了正确版本的工作并在当前边界内继续行动。4. 协作如何把诊断变成下一轮行动第一轮对话Worker 报告诊断发现及操作边界。这是诊断回报不是修复完成的证明。同一任务的后续对话用户确认继续Manager 明确第二轮修复范围并保留后续验收职责。另一个实际案例更能说明这个团队如何工作。一项部署任务停在文件校验阶段大量文件通过只有一个运行时数据库没有通过固定哈希检查。第一轮Manager 把问题交给 Worker 诊断。Worker 的回报把视野从“这个文件为什么不一致”扩展到“发布包是否混入了不应作为固定基线的运行态数据”除了数据库还涉及运行过程中产生的身份文件。它同时说明这轮没有访问现场也没有替换现场数据库。我在 Manager 对话中提出了两个可能的方向取消这个数据库的检查或者恢复成之前的基线版本。讨论没有直接进入执行而是进一步区分了两类对象应该验证完整性的交付内容以及运行后本来就会变化的现场数据。恢复旧数据库可能覆盖已有变化并不能解决校验范围本身的问题。在收到 Worker 回报之后Manager 进一步明确了方案保留现场数据调整运行态目录的安装校验范围同时继续校验镜像、脚本和静态配置后续交付包也不应继续携带旧运行态数据。我确认继续后第二轮任务才转向修复。Worker 接到的不是一句宽泛的“把问题解决”而是带有边界的行动处理交付目录与校验逻辑不接触现场数据也不重新构建没有必要变更的镜像。这组记录截至截图时只展示到修复开始还没有最终提交和 Manager 验收结果。但它已经让协作方式变得具体Worker 提供诊断依据Manager 结合我的讨论明确取舍再把确认后的方向组织成下一轮任务。团队协作的价值不只是把任务分给另一个 Agent而是让诊断证据经过讨论与判断变成下一轮边界清楚的行动。这里的人工参与也不只发生在最后的批准按钮上。我可以在过程中提出方向团队再用证据完善它。Manager 的职责则不应停留在转发消息它需要保持问题背景、明确下一轮范围并在后续检查实际交付。这些职责有没有做到仍然需要从行为和产物中检验不能仅凭角色名称或一条“已完成”消息判断。5. 协作有成本但并非所有成本都应该消除一次复杂个案的复盘不代表稳定模式下的日常耗时也不是优化前后对比。约 56 分钟覆盖完整交付约 8 分钟只覆盖其中的构建操作两者的差值不能全部视为协作浪费。图中事件按顺序排列并非按时间比例绘制。接口对齐、诊断讨论和交付验收都会占用时间。我把这部分开销理解为协商税。只要它帮助团队减少误解、明确责任、避免错误交付就不应该一概当成浪费。在目前稳定的使用模式下我认为这部分成本是可以接受的这是实际使用感受还不是系统统计结论。此前有一次情况比较复杂的打包任务完整交付接近 56 分钟而其中的构建工具内部耗时约 8 分钟。这个案例让我注意到协调成本可能被放大但它不是日常表现的代表。两项数字也不是优化前后对比一个覆盖完整交付一个只覆盖其中的构建操作不能把差值全算成多 Agent 的额外成本。复盘里能看到上下文压缩、Manager 动作之间的间隔以及提交后重复组织通知的步骤。现有记录不足以把所有时间空白精确归因但有一个具体的设计问题值得处理防重复、保存回执和处理未知结果有必要让 LLM 每次亲手组织其中每一个机械步骤未必有必要。这改变了我优化流程的目标。我不是想把所有协商都删掉而是区分两类事情需要结合上下文作判断的讨论以及可以由 Runtime 稳定完成的状态处理。真正值得减少的不是协作本身而是不产生新判断、却反复占用模型轮次的协调。6. 指标不是给 Agent 打分而是帮助修改系统最初我关注模型分配和 Token 消耗哪些工作需要更强的判断能力哪些可以交给成本更合适的 Worker。但只有用量数据解释不了某次复杂交付为什么变慢也不能判断一次模型分配是否合适。某一天消耗了多少 Token、完成了多少任务也不能直接相除就当成一项工作的交付成本。任务难度、跨日执行和统计覆盖范围都可能不同。所以下一步正在开发的是任务级耗时记录让一次工作从需求进入、派发、执行、提交、审查到最终交付有可以关联的时间信息。这个方向已经有部分实现包括时间线整理和明确选择的构建耗时证据导入整体仍在开发。由于时间和 Token 预算有限目前还没有完成同类任务的优化后对照验证因此不能把日常使用体验写成已经测得的改进幅度。我想用这些记录回答更具体的问题工作迟迟没有开始是在澄清需求、等待依赖还是反复恢复状态Worker 已经提交之后时间花在必要审查还是重复通知和整理回执调整模型、指令或 Runtime 接口后同类任务的交付是否改善证据完整性有没有下降时间指标本身也需要边界。并行任务的时长不能直接相加当作用户等待工具内部耗时不能再和包含它的外层调用重复累计日志没有覆盖的时间需要保留为未知而不是填成零或猜一个原因。对我来说Trace 的意义是留下可追溯的过程Eval 的意义是围绕一个明确问题判断变化是否有益。Dashboard 只是观察入口真正的价值在于它是否改变了下一次设计决定。7. 从改进 Skill到重新划分 Skill 与 Runtime经历这些使用过程我对这个项目的理解也变了。最初很容易把问题理解为 Skill 写得不够详细恢复错了就补一条恢复规则通知重复了就再强调一次不要重复交付慢了就要求更快。但规则越多并不意味着执行成本越低。有些可靠性要求反而被展开成了更多轮对话。我现在倾向于让 Skill 表达需要判断的事情例如如何拆任务、何时补充证据、什么情况下应该停止推进把可重复、可验证的状态处理放进 Runtime例如提交版本、重复识别和待审查询。实际启动任务、发送消息和唤醒 Agent则仍然受宿主能力约束。研究角色、任务、提交和审查轮次之间的关系也让我第一次更深入地尝试图式建模。不过关系被记录下来并不等于已经有了可靠的自动调度器。它首先帮助我把“谁负责什么、正在审查哪次提交”从聊天叙述变成可查询的结构。这与我的企业级 AI Runtime 主线是一致的长期协作需要的不只是记住更多内容还需要把知识、当前工作状态和执行边界区分清楚。如果借用 RSI 的视角这里正在形成的是一个由人参与的改进过程真实使用暴露问题过程记录帮助定位问题再调整 Skill 或 Runtime最后回到实际任务中验证。它还不是一个已经证明有效的自动自我改进系统。尤其在没有后测的时候“做了修改”和“系统变好了”必须分开说。8. 下一步让 Manager 按任务选择 Worker最近一个很具体的体验给了我调整模型分工的动机。我单独调用 Luna 执行镜像打包速度和效果都符合预期两次任务界面显示的耗时分别为 5 分 51 秒和 4 分 44 秒。这里没有 Manager 参与也不是与 Sol 的受控对照。它说明的是对于我已有明确执行流程的打包任务Luna 是值得继续使用的选择并不是所有执行都需要同样的模型能力。下一步我希望把这个认识放回团队内部默认提供三种 Worker 配置由 Manager 根据任务选择而不是由我每次手动指定模型。初始分配可以是Luna Worker承接流程固定、结果容易核验的任务例如按既定脚本打包镜像、整理产物清单。Terra Worker承接范围较清晰、仍需要一定实现或排查判断的任务。Sol Worker承接不确定性较高、涉及跨模块权衡或复杂根因分析的任务。这是一项待实现和验证的路由设计不是已经生效的自动调度能力。三个默认档位也不意味着每项任务都启动三个 Worker更不是对模型能力划定永久边界。Manager 需要判断的不只是任务被称为“简单”还是“困难”还包括流程是否成熟、证据是否充分以及失败后影响多大。同样叫打包正常执行可以交给 Luna一旦出现未知构建故障就可能需要 Terra如果问题涉及跨服务依赖或发布架构再考虑 Sol。必要的验收要求不应随模型档位降低。路由还需要允许修正。Worker 遇到超出原范围的不确定性时应把已有产物、错误和诊断一起交回由 Manager 决定是否升级而不是无限重试或从头重做。问题解决、流程重新稳定后后续同类任务又可以回到 Luna。角色让责任持续存在路由让能力分配随任务变化。我希望用交付时间、Token 消耗、验收结果和升级情况一起判断这套分配是否合适而不是只追求某一次模型调用更便宜。这也是下一阶段更具体的研究问题一个持续工作的团队能否在保留协商与验收价值的同时把判断能力放到真正需要它的地方前六篇从具体问题进入01 | 从一个 Codex 对话到一个可参与的 AI 开发团队02 | 模型分层与成本Manager 和 Worker 怎样分配模型如何把协调、审查与返工计入比较。03 | 长期角色记忆与 MCP 召回身份怎样持久化遗忘后怎样恢复如何验证自然召回。04 | Worker 并行的时间与 Token 取舍哪些工作适合拆怎样同时观察交付时间和总用量。05 | 汇报、验收与返工闭环怎样区分提交、送达、接收与通过异常情况下怎样继续。06 | 任务面板与指标面板怎样从同一个工作台理解交付状态、数据覆盖和资源使用。