假设你正在用 Codex 做一个功能：接口刚改完，前端还在等字段确认，构建又报了错。你在同一个对话里补充需求、让它排查错误，再追问上一项改动有没有验证。
对话越来越长。需求讨论、代码实现、执行结果和验收意见挤在一起。等你想确认“现在究竟卡在哪里”时，往往还要重新梳理一遍上下文。
这是一个示意场景，却能说明我做 codex-team-runtime 时想解决的问题：怎样把一个人和一个 AI 的长对话，组织成一个人可以参与、分工明确、能够长期协作的开发团队？
我的出发点很具体：让主窗口作为 Manager，负责需求确认、验收和协调；代码修改、构建等执行工作，尽量交给独立的 Codex 原生任务。需要了解细节时，我能打开对应 Worker，查看过程、追问并参与。后来又增加了 Liaison，作为日常沟通和进度解释窗口，减少对 Manager 的打扰。
这篇文章是工程实践系列的第一篇，先讲这套组织方式和实现边界。
版本说明：本文依据写作时的本地开发工作树核验，其中包含尚未全部提交发布的改动。下文的实现描述不等于公开仓库或读者已安装版本的能力清单，统一工作台尤其应按本地候选能力理解。
GitHub 项目：huajiexiewenfeng/codex-team-runtime
一、先把决策、执行和验收分开
实际任务列表：不同职责的成员拥有可打开的独立原生任务。无关任务已遮挡。开发版本实际界面，后续可能调整。
在一个对话里，AI 可以先讨论需求，再写代码，最后解释自己做了什么。任务简单时，这很直接。
任务变多之后，我更希望保留一个稳定的协调位置：有人负责判断目标有没有变化，有人负责具体实现，有人负责解释进展。一个 Worker 的执行过程不必塞进所有人的当前对话，但关键结论和证据必须能交回来。
于是，团队形成了三类角色。
| 角色 | 主要负责什么 | 交接时应留下什么 |
|---|---|---|
| Manager | 确认需求、拆分任务、协调依赖、安排返工、独立验收 | 明确的工作范围、验收标准和最终判断 |
| Worker | 在约定范围内实现、测试、构建等 | 实际改动、验证结果、阻塞与提交证据 |
| Liaison | 日常沟通、解释进度、讨论问题、转交已确认的决定 | 有来源的状态说明与需要 Manager 处理的问题 |
用户仍然决定目标、范围和重大取舍，也可以直接与 Manager 或 Worker 交流。Liaison 不派工、不指挥 Worker，也不代替 Manager 验收。
这种分工的意义，是让不同问题有清楚的承接位置：想知道项目进展，可以找 Liaison；需要改变目标，由 Manager 协调；要讨论一个具体实现，可以进入相应 Worker。
但多个窗口也会带来沟通成本。用户在 Worker 中提出的意见如果改变了范围或依赖，就需要回到 Manager 统一协调。否则，主窗口保留的是旧计划，执行窗口收到的却是新要求。
二、为什么坚持使用可见的原生任务
用户要求增加部署 Worker 后，Manager 确认成员创建、职责与就绪状态。此时尚未执行部署。团队与任务身份 ID 已遮挡。开发版本实际界面，后续可能调整。
这里的 Worker 是用户可以打开的独立 Codex 原生任务。
这使用户能够看到宿主展示的推理摘要、执行过程、工具结果与证据，并在需要时追问。例如，Worker 选择了一条与你预期不同的实现路径，你可以当场问清依据；发现它误解了一个字段含义，也可以及时补充。
这些可见内容不应被称为完整内部思维链。它们是宿主提供给用户的观察与交互界面。
人的参与位置因此从交付末尾，延伸到了执行过程中。 用户可以检查一个局部判断，也可以把真正影响全局的决定交回 Manager。
拆分窗口的目标是减少干扰，实际交互仍可能打断正在运行的工作。Liaison 的价值就在这里：一部分“现在到哪一步了”的问题，可以通过读取可信状态来回答，不必每次都让 Manager 或 Worker 停下来重新解释。
三、从角色提示词，到能恢复的协作状态
给三个窗口分别写上 Manager、Liaison、Worker，还不足以支撑长期协作。
上下文丢失或压缩之后，一个成员至少要重新弄清两件事：
- 我属于哪个团队，承担什么职责，向谁负责？
- 我当前负责哪项工作，做到哪一步，下一步获得了什么授权？
当前本地实现把这两类信息分开维护。
1. Skill 约定协作方式
manager-session Skill 及其 references 描述角色边界、委派方式、身份恢复、提交和验收规则。
Skill 是按需加载的规则。它能告诉成员何时应该恢复身份、如何交接，但它本身不是持久数据库，也不保证每个窗口都已经加载了最新规则。
2. MCP 提供身份恢复入口
Python Team Context MCP 通过 Team Registry 保存团队身份。成员使用经核对的当前任务身份调用 team_context.read，恢复自己、团队、精确的 Leader、角色职责及入队状态等信息。
它首先帮助回答“我是谁、向谁负责”。当前任务、实现证据和授权范围，还要从原业务状态及任务说明中恢复。
这个入口也有明确边界：MCP 不会自己调用自己。持久数据仍在，不代表 Agent 在遗忘之后一定会主动想起读取它。上下文压缩后的自然召回与职责执行，仍需要持续验证。
3. 运行层记录工作走到了哪里
Node.js 运行层保存轮次、任务、排队、提交、审查和验收状态，并校验已经编码的状态约束。
例如，某个 Worker 已经提交，但还没通过验收，不能仅因为它的原生任务显示空闲，就给它塞入另一项独立工作。当前设计会继续保留占用，新工作进入 Manager 侧的持久队列。
这让“窗口当前是否在运行”和“成员是否已经交清手上的工作”成为两个独立判断。
下面的图概括了职责和信息来源，连线表示交互或读取关系，不代表自动执行时序。
模型负责判断，代码负责校验已编码的约束，Codex 宿主负责真实任务和消息操作。它们各自能证明的事情也不同：状态记录不能代替实际消息送达，角色规则不能代替宿主权限。
四、用一个交付场景检查分工是否成立
下面用“给列表增加筛选功能”举例。这是依据当前协作契约编写的示意案例，不是真实项目复盘，也不代表本次执行过测试。
第一步：Manager 把需求变成可验收的工作
用户希望列表支持按状态筛选。Manager 先确认字段含义、默认行为和异常情况，再划定实现范围。例如，接口参数与前端交互分别由不同 Worker 处理，先明确接口契约和文件所有权。
如果前端必须等待后端的字段决定，就先解决这个依赖。只有输入清楚、范围可以分开的部分，才适合并行。
第二步：用户可以进入执行过程
一次实际的进度问答：Liaison 区分实现报告与验收，并说明估时前提。截图中的时间估计和性能目标不代表已完成验证。开发版本实际界面，后续可能调整。
前端 Worker 在实现中提出：“切换筛选后，是否保留当前页码？”用户可以在该任务里解释预期。
如果这个决定影响接口行为或原验收标准，就需要交回 Manager 更新协调依据。Worker 不应把一次局部讨论当作扩大整个任务范围的许可。
这时用户也可以向 Liaison 询问整体进度。Liaison 应依据状态来源说明哪些工作仍在执行、哪里有阻塞、哪些已提交待审查，并保留数据时间；它不能因为没有新消息就推断失败，也不能把旧记录讲成当前现场。
第三步：提交后仍有一次独立判断
Worker 完成实现与验证，提交改动说明和证据，再向准确的 Manager 回报。
Manager 检查需求是否满足、证据是否覆盖验收标准。假如筛选后的分页行为没有覆盖，就可以要求返工，补足相关验证后再审查。
主路径是 queued → executing → submitted → reviewing → approved；需要修改时，从 reviewing 进入 rework，随后再次提交。
这里有一个可以直接从本地源码核对的机制：运行层只允许处于 reviewing 的任务被批准，并要求提供验收证据；尚未验收的工作也会阻止轮次关闭。
这是状态约束的代码证据。它能防止跳过规定的状态步骤，证据是否充分、实现是否正确，仍依赖 Manager 的实际审查。
Worker 提交不等于 Manager 验收。 保存提交、发送通知、收到通知和验收通过，也需要分别核对。若把这些动作压缩成一句“已完成”，拆成多个窗口之后仍然很难判断交付到底走到了哪里。
五、一个 Team Dashboard，回答两类问题
窗口多了之后，用户不应该只能逐个打开任务，才能拼出团队全貌。
当前本地候选实现提供统一的 Team Dashboard，包含“任务进度”和“指标统计”两个入口。两者共享工作台，但保留各自的数据来源与更新时间。
任务进度：交付走到了哪里
开发版本工作台总览：展示轮次与交付状态，页面自动同步的是团队记录。开发版本实际界面，后续可能调整。
任务进度页依据任务状态和成员信息，展示任务、阶段、阻塞、提交及验收。
它帮助用户区分：某项工作还在实现，还是已经提交、等待审查？当前阻塞在哪个环节？一个轮次是否仍有未验收事项？
页面同步的是已记录的状态，不等于直接观测到了每个原生任务的实时执行。看板是只读视图，不能派工、唤醒 Agent 或代替验收。
指标统计：资源花在了哪些地方
指标统计页按需读取显式绑定的团队日报，内部保留 Token 和 MCP 视图。
Token 侧可以查看输入、缓存输入、输出，以及按角色、成员等维度组织的用量。缓存输入属于输入的一部分，不能再加一遍；Token 数也不能直接当作费用账单。
按角色查看每日已观测 Token；当前费用未配置、覆盖未核实，用量不等于费用账单。开发版本实际界面，后续可能调整。
MCP 侧可以查看观测到的调用、结果和可识别的触发情境。例如，入队、前台续接、已知压缩后的恢复、交付前检查等，当前契约允许在已有必要调用上声明 reason。
查看导入的 MCP 服务端调用计数；当前覆盖未核实，调用匹配不代表记忆有效或后续职责执行正确。开发版本实际界面，后续可能调整。
这类情境由 Agent 声明，服务端并没有独立验证其原因。未知应保留为未知。一次调用匹配到了身份，也没有证明成员随后正确执行了职责。
所以，调用次数不能当作记忆有效率。要评估记忆是否帮助了协作，还需要检查：该恢复时是否调用、是否找回正确身份、后续行为是否符合职责，以及是否需要人工纠偏。
当前工作台也不会因为任务页在刷新，就自动扫描日志或生成新的指标。未绑定报告、未导入 MCP 数据、成员覆盖不全，都需要明确显示，不能补成零。
六、团队化需要算清几笔账
把工作拆出去，也增加了任务说明、沟通、审查和返工。后续优化必须把这些开销一起算进去。
第一笔是模型配置。 让较强模型承担 Manager 的需求判断和验收，让成本较低且适合任务的模型承担 Worker，是一种资源配置策略。它不保证 Token 数减少，也不保证质量自动保持。便宜的单次执行如果带来更多返工，整体收益可能消失。
第二笔是并行。 独立工作并行可能缩短交付时间，同时提高单位时间用量。共享文件冲突、重复读取上下文和等待接口决定，都可能抵消收益。任务适不适合拆，比一次开多少个 Worker 更值得先判断。
第三笔是长期恢复。 持久身份和任务状态让恢复有了依据，但不会让 Agent 永久在线或永不遗忘。当前系统也不是一个保证无人值守推进的常驻调度器；消息失败或 Manager 没有被唤醒时，不能承诺自动恢复。
此外，Manager 的独立验收仍然是模型参与的判断，不是质量保证书。角色边界也不是文件系统权限隔离；运行层能校验的约束，有明确的实现范围。
项目知识可以作为补充。如果使用 PDC（Project Develop Copilot），它可以提供项目知识和范围，帮助 Manager 拆分任务；团队运行本身不要求先安装 PDC、初始化 Wiki 或建立项目图谱，已有需求、文档和源码也能作为依据。
七、接下来的五篇，逐个回答工程问题
这篇先建立全貌。后续五篇分别展开：
- 模型分层与成本：Manager 和 Worker 怎样分配模型，如何把协调、审查与返工计入比较。
- 长期角色记忆与 MCP 召回：身份怎样持久化，遗忘后怎样恢复，如何验证自然召回。
- Worker 并行的时间与 Token 取舍：哪些工作适合拆，怎样同时观察交付时间和总用量。
- 汇报、验收与返工闭环：怎样区分提交、送达、接收与通过，异常情况下怎样继续。
- 任务面板与指标面板：怎样从同一个工作台理解交付状态、数据覆盖和资源使用。
回到最初的需求：我希望主窗口能持续承担需求确认、协调和验收，执行工作有清楚的负责人，而用户随时能进入具体任务，理解发生了什么，参与必要的决定。
要让这样的团队持续可用，还需要回答一个现实问题：把更强的模型放在 Manager，把具体工作交给成本较低的 Worker，什么时候才划算？ 下一篇就从这笔账开始。
最后补充一点：codex-team-runtime 目前仍是开发版本，可能存在 Bug，功能和协作流程也会继续调整。 欢迎到 GitHub 项目 查看代码、交流想法和反馈问题；体验时，请以所用版本的实际能力为准。
扫一扫
365
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
