AWS 开源 Codex Agent Team：多 Agent 如何真正协作

我通读了 AWS Samples 最近开源的sample-codex-agent-team原本以为会看到一个 Agent 调度服务任务队列、状态数据库、并发控制器再加一个可视化界面。代码里什么都没有。整个项目只有 53 个受 Git 管理的文件核心资产是五份 Agent 配置、九个工作流 Skill、三条命令、三个生命周期 Hook、一套高风险命令规则以及若干 Markdown 模板。它不运行 API不保存任务状态也不提供 Agent 之间的文件隔离。但这恰恰是它最值得研究的地方。这个项目没有试图再造一个“AI 版 Jira”而是先回答了一个更基础的问题当多个 Codex Agent 共享同一个代码仓库时怎样让它们像一支工程团队而不是一群同时修改文件的模型我读完配置、提示词、Hook、规则和测试后得到的结论是多 Agent 软件工程真正的门槛不是同时调用多少个模型而是能否把任务边界、共享状态、接口契约、独立评审和失败收口写成一套可持续执行的协作协议。这套样例已经把协议写得相当完整但它仍然不是生产级控制平面。它展示了“团队应该怎样协作”却没有从运行时强制“团队只能这样协作”。这两者之间的差距正是理解这个项目的关键。项目地址github.com/aws-samples/sample-codex-agent-team本文分析基于main分支提交ea5bf54仓库状态截至 2026 年 7 月 19 日。先建立心智模型这不是框架而是工程协议包如果只看项目里的fullstack-agent、coding-agent和review-agent很容易把它理解成“给不同模型写了几份角色提示词”。但真正把这些角色连起来的是一条 Spec 驱动的控制链。读这张图时要注意三点。第一默认协调者仍然是 Codex 主线程。fullstack-agent不是每个任务都必须启动的“老板 Agent”只有用户明确要求 Lead Profile 或 Spawn Plan 时才适合使用。第二Agent 之间没有共享任务数据库。它们通过.codex/specs/slug/下的 Markdown 文件交换长期状态通过主线程的显式 Spawn、Wait、Steer 和 Close 操作完成调度。第三Review 不是写完代码后随手执行的一条命令而是一道有独立所有者、有次数上限、有终止条件的工程门禁。从组件上看这个仓库可以分成四层层级主要文件解决的问题角色层.codex/agents/*.toml谁负责规划、编码、运维、评审和 AWS 架构流程层plugins/codex-agent-team/skills/怎样形成需求、拆任务、并行、评审和收尾状态层.codex/specs/slug/如何把需求、接口、任务、决策和评审留在对话之外护栏层.codex/hooks.json、.codex/rules/如何记录生命周期并对部分高风险命令加审批这种结构说明项目的设计中心不是“更聪明的单个 Agent”而是把软件团队原本隐性的合作习惯显式化。五个 Agent不是五种人格而是五种工程责任项目为五个角色明确指定了模型和推理强度toml.codex/config.tomlmodel “openai.gpt-5.6-sol”model_reasoning_effort “xhigh”[agents]max_threads 14max_depth 2角色矩阵如下Agent模型推理强度主要责任建议并发上限fullstack-agentopenai.gpt-5.6-solxhigh规格、接口、任务波次、委派和结果整合1coding-agentopenai.gpt-5.6-terraxhigh限定范围内的产品代码、测试和修复6devops-agentopenai.gpt-5.6-terrahighCI/CD、容器、IaC、环境和 Runbook2review-agentopenai.gpt-5.6-solmax独立审查正确性、安全性和验证证据4sa-agentopenai.gpt-5.6-terramaxAWS 架构、安全、可靠性、成本和运营1表面上看最醒目的数字是max_threads 14。但项目在 README 和 Agent 指令里反复强调这些数字是上限不是配额。真正决定并发数的不是“最多能启动几个 Agent”而是当前任务波次里有多少个互不重叠的文件所有权范围。只有两个可以独立写入的模块就只应该启动两个实现 Agent一个顺序任务启动一个 Worker 即可。反直觉的是这个样例虽然以“Agent Team”为卖点却一直在克制使用 Agent。因为多启动一个 Worker 不只增加 Token 成本也会增加过期交接、接口漂移和同文件竞争的概率。fullstack-agent的指令甚至明确禁止 Lead 直接接管大规模实现toml.codex/agents/fullstack-agent.tomlDo not implement non-trivial production code, production-touching tests,IaC, deployment scripts, or broad refactors.The implementation-phase entry gate is delegation:the first build action is to spawn or direct the worker pool.这条边界很重要。Lead 的工作是确定需求、接口和文件所有权Worker 的工作才是实现Reviewer 的工作则是独立判断实现能否被接受。如果 Lead 一边规划、一边编码、最后再给自己 PASS所谓多 Agent 团队只是在一个上下文里换了三顶帽子。想先跑起来15 分钟完成第一轮安全试用读到这里如果你想先看它到底能不能工作最稳妥的方式不是立即把整套配置复制进主力项目而是在样例仓库里跑一轮无云资源、无部署动作的小任务。先确认四个前置条件前置条件为什么需要Codex 已安装并完成认证自定义 Agent、插件和 Hook 都由 Codex 加载Python 3.11 在PATH完整提示词回归测试依赖tomllib当前目录是 Git 仓库根目录Hook 用git rev-parse定位脚本你准备信任这个项目.codex下的配置、Agent、Hook 和 Rules 只有信任后才加载还有一个最容易忽略的条件公开仓库没有包含私有model_provider、凭据、区域和信任配置。配置里的openai.gpt-5.6-sol与openai.gpt-5.6-terra必须由你的 Provider 提供如果当前环境没有这些模型Agent 会在真正开始工作前报404 Not Found: Engine not found。路径一在样例仓库中试跑第一步克隆并进入仓库bashgit clone https://github.com/aws-samples/sample-codex-agent-team.gitcd sample-codex-agent-teampython3 --versioncodex --version第二步不要急着信任。先检查.codex/config.toml、.codex/hooks.json、.codex/rules/和五份 Agent 配置。项目默认启用了 AWS IaC MCP、Context7、DeepWiki 和三个伴随插件其中部分工具会启动uvx、npx进程、下载包或访问远程服务。不需要 AWS 和外部知识库时先把相关enabled设为false。第三步从仓库根目录打开 Codex确认项目可信后注册仓库 Marketplacebashcodex plugin marketplace add “$PWD”然后在 Codex 中打开/plugins切换到Sample Codex Agent TeamMarketplace安装Codex Agent Team。AWS 优化路径还建议安装三个伴随插件但它们不是验证本地协作闭环的必要条件textaws-coreagent-toolkit-for-awsaws-data-analyticsagent-toolkit-for-awssuperpowersopenai-curated第四步启动一个新的 Codex 线程。插件是在会话启动时发现的安装完成后继续使用旧线程常常会表现为 Skill 和命令“已经在磁盘上却找不到”。新开线程前可以先跑一轮本地预检bashpython3 scripts/test_prompt_invariants.py -vpython3 .codex/hooks/test_subagent_lifecycle.py -vcodex debug prompt-input “validate repo config”前两条检查角色、Prompt 和 Hook最后一条确认 Codex 能加载当前项目上下文。它们不会证明多 Agent 团队已经端到端可用但可以提前暴露 Python 版本、配置解析和项目信任问题。第五步用一个只要求规划、不要求部署的 Prompt 验证整条链textUse the Codex hybrid team to plan a small local CLI feature.Create a .codex/specs plan, define exact interfaces,split implementation into file-disjoint scopes,spawn role agents only where useful,and run one independent review wave.Do not deploy or access cloud resources.如果只是一个粗略想法可以从需求访谈开始textUse $team-brainstorm for:一个只读取本地 Git 状态并生成 Markdown 摘要的 CLI。如果已经有 Spec则直接让工作流构建下一波任务textUse $team-spec-workflow for .codex/specs/.Build the next file-disjoint wave, then run review.插件还提供三条快捷命令/brainstorm用于从想法生成需求/launch-codex-team用于启动完整团队工作流/optimize-my-codex用于审计当前 Codex 配置。快捷命令只是入口底层仍然调用对应 Skill。第一次试跑时不要以“启动了几个 Agent”为成功标准。真正要检查的是.codex/specs/slug/是否生成需求、规格和任务每个 Worker 是否拥有明确且不重叠的文件返回结果是否包含真实验证命令和输出review.md是否由独立 Reviewer 写出任务结束后是否没有遗留 AgentGit Diff 中是否只有预期文件。路径二迁移到已有项目这里必须分清两种资产。plugins/codex-agent-team提供可复用的 Skill 和命令.codex/agents/*.toml、Hook、Rules 与项目配置则属于项目级或用户级 Codex 配置。只安装插件不会自动把五个项目级 Agent 安装到任意代码库。如果希望插件进入个人 Marketplace可以在样例仓库中运行bashpython3 scripts/install_personal_plugin.py --dry-runpython3 scripts/install_personal_plugin.py --refresh-cache第一条先展示将要修改的 Marketplace 文件和符号链接确认无误后再执行第二条。脚本会更新~/.agents/plugins/marketplace.json并创建~/plugins/codex-agent-team指向当前仓库插件目录的符号链接。然后再把真正需要的.codex/agents、Hook、Rules 和 Spec 模板合并进目标仓库。注意是“审查后合并”不是直接覆盖现有项目可能已经有自己的AGENTS.md、模型 Provider、线程上限、MCP、审批策略和安全规则。四个最常见的开箱问题症状优先检查Skill 或命令看不到安装后是否启动了新线程插件是否启用自定义 Agent 看不到项目是否可信Codex 是否从仓库根目录启动Engine not foundProvider 是否提供配置中的精确模型 IDHook 没有运行/hooks是否已信任当前目录是否存在 Git 根如果个人 Marketplace 中出现重复 Skill通常是因为既安装了插件又把同一批 Skill 直接软链接到了~/.agents/skills。保留~/plugins/codex-agent-team这一条标准插件来源删除重复直链再刷新插件缓存并新开线程。仓库没有提供专门的test-suite-runnerAgent。实现 Worker 应使用目标项目原生的测试、Lint、类型检查和 CI 命令Reviewer 再判断这些验证是否真的覆盖验收条件。不要为了凑齐角色额外制造一个没有项目上下文的“万能测试 Agent”。至此读者已经能跑通一轮。但“能启动”不等于“能长期协作”。接下来才进入这套系统真正承重的部分它如何把跨 Agent 状态放进.codex/specs。.codex/specs才是团队的共享记忆多 Agent 最容易制造的一种错觉是把聊天记录当成团队状态。一个 Worker 在消息里说“测试通过”另一个 Worker 说“接口已经对齐”Lead 再把两段结果总结成一句“本轮完成”。只要中间发生一次上下文压缩、会话中断或消息延迟团队对当前状态的理解就可能分叉。这个样例给出的解法很朴素对话负责沟通仓库文件负责记忆。每个非平凡任务都可以在.codex/specs/slug/下维护一组文档文件职责关键问题requirements.md已确认的产品意图用户真正需要什么什么不做spec.md可执行规格接口、错误、边界和验收标准是什么design.md架构与取舍组件怎样连接为什么选择这个方案tasks.md波次、所有权和进度谁能写哪些文件用什么命令验证decisions.md追加式决策日志中途改了什么谁批准怎样回滚review.md独立评审历史当前第几轮有哪些发现是否 PASSsa-review.mdAWS 架构意见安全、可靠性、成本和残余风险是什么这些文档不是为了“多写几份 Markdown”而是为了建立明确的事实优先级。仓库里的AGENTS.md规定当前文件与 Diff 是实现状态的事实来源.codex/specs是需求、所有权、决策、阻塞和评审的事实来源新鲜的命令输出是验证结论的事实来源。Agent 的返回消息只是证据之一旧摘要和沉默都不能覆盖当前磁盘状态。这条链路最大的价值是恢复能力。一次会话中断后Lead 不应该重新播放旧的 Spawn Plan而是重新读取tasks.md、decisions.md、review.md、当前文件和 Agent 状态再判断哪些工作已经完成、仍在运行、明确失败或状态未知。Agent 会遗忘聊天会被压缩但仓库可以被重新读取。多 Agent 系统要想可恢复就必须把关键状态放在模型上下文之外。并行不是“同时开始”而是文件所有权互不重叠有了共享记忆还要解决共享工作区的问题。这些 Agent 默认操作同一个仓库文件系统没有容器级或操作系统级隔离。如果两个 Worker 同时改同一个文件提示词里的角色名称并不能阻止覆盖。项目因此把“文件互斥”提升成整个工作流最核心的规则mdWave 1:Spec refs:spec.md#interfaces,requirements.md#FR-1[coding] Implement order validation |src/orders/validate.ts,src/orders/validate.test.ts|MatchOrderInputand error contracts.Run:npm test -- orders/validate一个合格任务至少要写明唯一实例名例如coding-2对应的 Spec、任务和波次精确可写文件与禁止编辑的边界验收条件和生产、消费的接口契约验证命令或必须提交的证据预期返回内容是否必须等待全部同波次 Agent其他 Agent 正在附近并行编辑的提醒。项目给出的交接示例很具体text.codex/agents/fullstack-agent.tomlUsecoding-agentascoding-2.Context:.codex/specs/orders-api/, Wave 2.Scope: onlysrc/orders/handler.tsandsrc/orders/handler.test.ts.Acceptance: matchspec.md#interfaces.Run:npm test -- orders/handler.Do not edit outside scope; peers are working concurrently.这其实是在用自然语言模拟一个轻量级的所有权系统。每个 Worker 获得一块写入租约任务波次则是一组可以同时持有、又不会重叠的租约。天真的做法是按“前端、后端、测试、文档”分四个 Agent。但真实仓库里前端 Agent 和测试 Agent 往往都要改同一份测试夹具后端 Agent 和文档 Agent 可能同时修改 OpenAPI 文件。按角色拆分不等于按文件拆分。更可靠的顺序是先锁定共享接口由一个明确所有者完成再根据当前磁盘上的文件边界向外扇出如果两个任务必须写同一个文件就串行执行或者指定唯一 Merge Owner。这也解释了为什么tasks.md使用“波次”而不是一张平铺清单。波次边界必须对应真实依赖接口、数据、代码生成或顺序约束而不是为了让计划看起来整齐。主线程真正要管理的是不确定性Worker 启动之后主线程并不是坐等几条“完成”消息。它要持续维护四类事实谁拥有哪些文件、哪些结果已经返回、哪些证据足以关闭任务、哪些 Agent 仍然活跃。项目将这个循环概括为 Spawn、Wait、Steer、ClosetextSpawn 启动当前波次真正需要的 WorkerWait 等待所有已请求 Agent不用沉默推断失败Steer 对不完整结果做最小范围纠正Close 收割结果后关闭已完成或不再需要的 Agent这里有一个很成熟的判断沉默不是失败。Agent 可能正在跑未缓存测试、构建容器、执行terraform plan或做大范围评审。仅凭时间流逝、没有新消息或看不到某个进程不能复制任务或重新分配相同文件。只有出现积极证据——明确的终止错误、确认进程已结束、输出损坏或有持久证据证明验收无法完成——才允许恢复或重派。而且恢复时只重派未完成的最小范围不能由 Lead 顺手接管全部实现。这条规则解决的是 Agent 系统中一个常见灾难因为看起来“卡住”而启动第二个 Worker两个实例随后同时写回同一批文件。很多多 Agent 冲突并不是并发设计错误而是错误恢复制造的重复所有权。独立评审不是角色扮演而是一道权限边界当实现完成项目没有让 Lead 汇总一下测试结果就宣布成功。它要求review-agent独立给出 PASS 或 FAIL。这不是措辞上的严格而是职责上的隔离Lead 不能在review.md里写权威 PASS实现 Agent 的自我检查只能算 TODO 标记分析 Reviewer 只能提交局部证据每一轮只能有一个综合 Reviewer 写最终结论综合 Reviewer 必须等待所有被请求的分析结果或明确记录缺失证据。大范围变更最多可以启用四个 Reviewer但它们不是四次独立投票review-1是唯一综合者review-2到review-4是按文件切片的分析员。分析员不写review.md避免多人覆盖同一份权威记录。评审关注的不只是“代码看起来对不对”还要求验证验证器本身textplugins/codex-agent-team/skills/team-review-cycle/SKILL.mdA green command is not enough if it:checks the wrong scopeomits a CI-pinned linter/type checker/testnever exercises the acceptance criterionuses a broken assertion or inadequate scriptsubstitutes static validation for required runtime behavior因此一条绿色命令不能自动关闭任务。terraform validate证明不了真实账户和区域静态检查证明不了部署脚本保留了真实退出码Mock 测试也不能替代验收标准要求的服务行为。对于 IaC、部署脚本、CI/CD、容器和 Shell 工具项目明确区分“静态已验证”和“运行时已验证”。如果没有凭据、Docker 或安全环境必须留下开放的 Live Validation Gate而不能把静态 PASS 写成运行时 PASS。三轮评审预算防止系统无限自转更反直觉的是这套工作流为整个用户目标只提供三次综合评审机会。一次评审不是 Reviewer 返回结论时才计数而是综合 Reviewer 被启动时就消耗预算。初次评审、定向复查、替换 Reviewer 和中断后的重试都算。预算不会因为换了文件、波次、会话或 Reviewer 而重置。第一轮和第二轮 FAIL 可以各产生一个范围明确的修复波次第三轮是终局。如果第三轮失败、中断或无法完成系统必须停止继续 Spawn 修复和评审 Agent关闭仍在运行的实例保存发现和验证证据然后把决定权交还给用户。这种设计牺牲了一部分自动修复能力换来资源上界和清晰的停止条件。它防止一个“Reviewer 总能找到新问题”的系统无限消耗 Token也避免 Agent 在没人监督时不断修改已经接近稳定的代码。但三轮预算也有副作用模型路由故障、基础设施抖动或 Reviewer 意外中断同样会消耗稀缺次数。它适合作为安全样例的保守默认值真实团队则应该把“工程失败”和“平台失败”分开计量同时仍保留总成本上限。Hook 和 Rules 是护栏不是控制平面项目还提供三类生命周期 HookSessionStart、SubagentStart和SubagentStop。json// .codex/hooks.json{“SubagentStart”: “subagent_lifecycle.py start”,“SubagentStop”: “subagent_lifecycle.py stop”}Hook 会过滤输入字段把事件写入~/.codex/team-logs日志达到 1 MiB 后轮转并保留三个备份。Subagent 日志在轮转和追加时使用fcntl.flock避免多个 Agent 同时启动或停止造成写入竞争。它还采用 Fail-open 策略日志目录不可写、输入 JSON 损坏或轮转失败都返回成功不让观测功能困住正常会话。这是一种合理的可用性取舍但也要看清边界。Hook 只是记录“Agent 开始或停止”不会阻止两个 Worker 修改同一个文件不会验证tasks.md是否更新也不会强制关闭遗留 Agent。前面所有团队纪律仍然依赖主线程和角色提示词执行。命令规则也一样。仓库对以下操作设置了确认或禁止git push、gh pr creategit push --force、git reset --hardterraform apply/destroy、cdk deploy/destroysam deploy/delete、CloudFormation 部署和删除aws s3 rm/rb、kubectl deletedocker system prune。我用 Codex 自带的 Execpolicy 检查器测试了代表性命令。直接执行git push会要求确认git push --force和git reset --hard会被禁止Terraform、S3、Kubernetes 和 Docker 的目标命令也能正确匹配。但前缀规则不是完整安全策略。git -C /path push、bash -lc git push、aws s3api delete-object和helm uninstall并不匹配现有规则。仓库文档也承认Rules 只能减少部分误操作不能取代 Sandbox、最小权限凭据和人工审批。提示词是组织制度Hook 是审计日志Rules 是局部门禁。三者都很有用但没有一个等于强制调度控制平面。我实际跑了一遍验证语法是绿的行为仍有空白为了区分“文档设计得很好”和“仓库当前真的可用”我按 README 跑了自带验证并补了几项结构检查。检查结果它实际证明了什么提示词不变量测试9/9 通过五角色模型矩阵和关键概念仍存在Subagent Hook 测试5/5 通过非对象 JSON、坏 JSON、字段过滤、Fail-open 和锁文件行为JSON/TOML/YAML 解析通过配置和元数据语法有效Python 编译通过Hook、安装器和测试脚本可被 Python 3.13 编译插件校验逻辑通过Manifest、Skill Front Matter 和 Agent YAML 满足当前结构契约Execpolicy 代表命令通过文档列出的直接命令前缀可以正确确认或禁止安装器 Dry-run通过能计算个人 Marketplace 和符号链接目标不进行写入这里有一个环境细节当前 macOS 的/usr/bin/python3是 Python 3.9没有tomllib因此完整提示词测试用系统python3会失败切换到已安装的 Python 3.13 后 9 项全部通过。README 已要求 Python 3.11所以这不是代码回归但它说明采用者不能只看“机器上有 Python”。更重要的是这些测试大部分验证“配置存在”和“关键词没有消失”而不是验证真实的多 Agent 行为。仓库已经删除早期的临时 Smoke Project也明确要求采用者在自己的沙箱里重新验证 GPT-5.6 路由、并行池和 Hook 锁。因此当前能给出的准确结论是静态配置和局部脚本测试是绿的完整团队闭环尚未被端到端证明。六个投入真实项目之前必须补的缺口1..gitignore与 README 自相矛盾这是我在仓库里发现的最具体、也最应该优先修的问题。README 明确写着运行时生成的.codex/specs已被.gitignore排除不属于这个可复用样例安全章节也要求把运行时 Specs、日志、本地状态和凭据留在 Git 之外。但仓库根目录没有.gitignore。我用git check-ignore检查.codex/specs/example/spec.md结果是NOT_IGNORED。这意味着一次普通的git add .可能把需求、架构决策、评审发现、被接受的安全风险甚至内部环境信息一起提交。对于一个把.codex/specs作为长期记忆的系统这不是文档瑕疵而是数据治理缺口。最低限度应该加入gitignore.codex/specs/.codex/team-logs/*.sqlite.env.env.*真实项目还应区分哪些规格需要版本控制、哪些只允许保留在本地不能简单把所有 Spec 一刀切忽略。2. 协作约束没有运行时强制文件互斥、等待全部 Worker、三轮预算和关闭 Agent 都写得很细但它们本质上仍是提示词协议。没有调度器验证两个 Spawn Prompt 是否包含重复文件没有租约服务拒绝第二个 Writer也没有状态机自动阻止第四轮 Reviewer。主线程遵守时系统工作良好主线程漏读、上下文被压缩或提示词被覆盖时规则可能静默失效。如果用于高价值仓库至少应该增加机器可读的任务清单、文件所有权冲突检查和评审计数器而不是只依赖 Markdown 自由文本。3. MCP 使用latest可复现性不足项目默认启用了三个外部能力入口AWS IaC MCP、Context7 和 DeepWiki。其中两个本地进程直接引用浮动版本toml.codex/config.tomlargs [“awslabs.aws-iac-mcp-serverlatest”]args [“-y”, “upstash/context7-mcplatest”]这让同一份仓库在不同日期启动时可能下载不同代码。对于能读取仓库、访问文档甚至接触 AWS 环境的工具浮动依赖会同时扩大供应链风险和调试难度。更稳妥的做法是固定版本、记录校验信息并把网络工具设为显式启用而不是在项目配置里默认打开。4. 默认 AWS Profile 和远程数据出口需要组织级审查AWS IaC MCP 写死AWS_PROFILEdefaultContext7 配置了默认工具批准DeepWiki 则是远程 HTTP MCP。这三个设置对个人样例很方便对企业仓库却意味着三类问题默认凭据可能指向未知账户仓库片段可能发送给第三方工具调用的批准边界可能比组织策略更宽。采用前应该明确账户、区域、Profile、数据分类和允许外发的内容并对云端工具使用最小权限、只读凭据和单独的启用开关。5. Hook 的跨平台能力有限Hook 命令硬编码/usr/bin/python3用$(git rev-parse ...)解析仓库根目录Subagent Logger 又直接导入 Unix 专有的fcntl。这套实现适合当前 macOS/Linux 环境但不能直接视为跨平台样例。Windows 缺少fcntlShell 命令替换语法也不同。即使在 Unix 上Python 的实际版本和安装位置也可能不一致。如果目标团队包含 Windows应该改成平台无关的启动入口和锁实现并在 CI 中建立 macOS、Linux、Windows 三平台测试矩阵。6. 回归测试保护的是提示词词面不是系统行为scripts/test_prompt_invariants.py的方法主要是检查模型与推理强度、统计最低单词数、确认提示词包含指定概念。这能防止一次“精简提示词”误删安全条款却也会产生两个副作用一是包含关键词不等于 Agent 会正确执行二是最低字数门槛会鼓励提示词不断增长。当前五个 Agent 的提示词合计约 7,380 个英文单词九个 Skill 再增加约 12,022 个单词。虽然 Skill 会按需加载但 AGENTS、角色 Prompt 和 Skill 之间已经有大量重复。未来每修复一个失败案例都继续追加一段警告最终会形成提示词债务。更好的测试组合应该包括结构化 Schema、少量关键 Prompt Snapshot、临时仓库中的多 Agent Smoke Test、规则匹配矩阵、真实并发日志压力测试以及中断恢复演练。如果我要把它用于真实团队会分三步落地第一步不是启动 14 个线程而是建立一个最小可信闭环。只选一个边界清楚的功能用一个 Coding Agent 和一个独立 Reviewer。要求任务有明确文件范围、接口和验证命令中断后必须能仅靠.codex/specs和 Git 状态恢复。只要这条链路还不能稳定重复就不应该扩大并发。第二步补强机器护栏。加入.gitignore和数据分类固定 MCP 版本关闭默认远程集成将任务范围写成可解析结构Spawn 前做文件重叠检查用 CI 测试 Execpolicy、Hook、安装器和中断恢复给 Token、时间、重试与外部调用设置预算。第三步才扩大角色池。从 24 个 Worker 开始根据真实的文件互斥宽度增加并发。AWS 工作一旦涉及 IAM、KMS、网络暴露、EKS、状态后端或分类数据再引入sa-agent。Reviewer 数量也按变更切片增加而不是为了“更独立”就让四个 Reviewer 重复阅读同一批文件。这套顺序的核心是先证明闭环再扩展吞吐先增加可验证性再增加自治。真正值得抄走的不是五个 Agent 的名字sample-codex-agent-team目前仍是一个年轻样例创建时间只有一个月左右没有正式 Tag 或 Release模型 Provider、凭据和信任配置也刻意没有提交。它离生产级多 Agent 控制平面还有明显距离。但它已经抓住了一个经常被忽略的方向。很多多 Agent Demo 把注意力放在角色数量、并发动画和“几个模型一起讨论”。这个项目反过来把最多篇幅花在文件所有权、事实来源、验证证据、恢复条件、独立评审和停止规则上。这些内容看起来没有那么炫却更接近真实软件团队每天赖以生存的东西。Agent 能不能成为工程同事不取决于它有没有一个像人的名字而取决于它是否拥有清晰责任、可检查交接、有限权限、独立验收和可恢复状态。没有这些所谓团队只是并发调用有了这些即使底层仍然是 Markdown 和提示词也已经开始形成工程组织。所以这个仓库最值得借鉴的不是fullstack-agent、coding-agent或review-agent的具体 Prompt也不是max_threads 14的参数。真正值得抄走的是它背后的判断不要只提示 Agent 去完成任务。把一支工程团队如何分工、如何共享事实、如何证明完成、如何拒绝错误、又如何在失败后停下来写成 Agent 可以反复读取的系统。当这些协议逐渐从提示词走向机器可验证的状态、租约和门禁多 Agent 软件工程才会真正从“几个模型一起工作”走向“一个可以被信任的生产系统”。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】