企业官网建设流程全解析

在 Codex 里让多个 AI 子代理协作写代码，最怕的就是"越权"——子代理擅自改错文件、悄悄扩大范围、甚至替根代理做了架构决策。astra-orchestrator 技能 正是为解决这个问题而生：它用一套委托门禁决定"要不要拆子代理"，再用一份六要素契约给每个子代理划清权限边界。下面带你读懂这套 Codex Astra Luna Orchestrator 编排机制，看它如何从设计上防止子代理越权。

一句话读懂 astra-orchestrator 技能

astra-orchestrator 是一个 Codex 技能，角色定位是"编排者（orchestrator）"：让根代理（root agent）负责理解目标、拆解任务、集成与最终校验，再把有边界的执行工作委托给专门化的子代理。

它随 codex-astra-luna-orchestrator 项目提供，内置多个配置档位（profile）：默认档 pro、plus 以及 Sol 系列，统一使用Luna作为执行子代理、Astra/Sol作为审阅者。

核心原则：子代理只提供"证据和有边界的执行"，不掌握整体方向。根代理绝不下放架构所有权。

委托门禁：先判断"要不要拆"，再决定"谁来做"

委托门禁（Delegation gate）是防止子代理滥用的第一道闸。它要求根代理在做任何实质性仓库工作之前，先把任务分成两类：

• root-only（仅根代理）：任务确实很小、很局部，拆分没有收益
• delegated（委托）：任务命中任意一条触发规则

只要命中下列任一条件，就必须委托，并且必须先调用spawn_agent真正生成子代理，而不是只在脑内"模拟"委托：

门禁的防越权意义：它既防止根代理"揽活"（该拆不拆，导致上下文污染），也防止子代理"滥建"（无谓地为凑数而生成子代理）。

为什么不能"口头委托"

技能里反复强调：不能只是描述、模拟或在内部推理委托——实际的子代理必须被生成。如果spawn_agent不可用或失败，必须明确报告失败，而不是悄悄回退到根代理直接干。这条规则把"看起来用了子代理"和"真的用了子代理"区分开，从制度上杜绝虚假委托。

契约设计：给每个子代理套上"权限缰绳"

门禁决定"拆不拆"，契约（Delegation contract）决定"拆出去的子代理能做什么、不能做什么"。每个委托任务都应包含六个要素：

技能给了一个经典对照：坏例子是模糊的"修复后端"；好例子是精确的"追踪 POST /invoices 在哪里校验货币，返回相关文件、校验路径与已有测试，不要改任何文件"。前者给子代理留了无限发挥空间，后者把权限收敛到最小。

文件所有权：一个文件只有一个写者

契约里对实现类任务明确要求文件所有权；并行时技能坚持"每个文件或子系统偏好一个写者"。这样两个子代理就不会同时改同一个文件，从根源上避免"越权写"和写冲突。

只读沙箱：从权限层面锁死"改"的能力

技能不只是口头约束，还在配置文件里用沙箱把"读"和"写"物理分开：

• 探索者 explorer.toml 设为sandbox_mode = "read-only"，指令明确"不编辑文件"
• 审阅者 reviewer.toml 同样是read-only，要求"评审实际改动而非意图"，并写明"Do not edit files"

这意味着 explorer 和 reviewer即使想越权也改不了文件——权限边界写进了 config.toml 与角色配置，而不只是靠提示词。

根代理的权限边界：谁也不能替它做架构决策

根代理拥有十项职责：理解用户真实目标、选择架构方向、拆解任务、决定并行、生成子代理、发契约、裁决冲突、集成改动、审最终 diff、协调最终校验，以及向用户呈现结果。其中的红线是：

根代理不得把架构所有权下放给子代理。

升级机制：越界时"上报"而非"自作主张"

当子代理遇到下列情况，技能要求它上报给根代理，而不是自行扩大范围：架构决策、破坏性 API / 表结构变更、新增依赖、涉及安全的敏感设计、结果差异大的模糊需求、范围外的意外改动、影响其他子代理所有权，以及需要更宽推理范围的阻塞点。

同时，模型升级的决定权归根代理——Luna 子代理不能自己把自己换成更贵的模型。这从制度上堵死了子代理"擅自升级、擅自扩张"的通道。

完成门禁：根代理的"最后一道验收"

在给出最终答案前，技能要求根代理确认：每个必需子代理确实被生成；每个必需子代理要么完成、要么明确失败；重要发现已集成；冲突发现已裁决；必需校验已执行；没有必需子代理仍在运行。

配合"最终验证"（查 diff、确认行为、跑高价值测试、声明未能执行的校验），根代理不会放过任何"看起来完成、其实没完成"的委托。

快速上手：安装与调用 astra-orchestrator

1. 克隆仓库并进入：

   git clone https://gitcode.com/gh_mirrors/co/codex-astra-luna-orchestrator cd codex-astra-luna-orchestrator

2. 运行安装脚本（macOS/Linux 用 setup.sh，Windows 用 setup.ps1），按提示选择目标仓库与 profile。

3. 安装器会把配置写入.codex/、技能写入.agents/，并追加 AGENTS.md 项目指令。

4. 在目标仓库里启动 Codex，复杂任务可显式调用$astra-orchestrator。

各档位的模型与推理等级对照见 README 的 Profiles 表；手动配置细节可参考 完整编排指南。

小结：越权是如何被"设计"掉的

astra-orchestrator 技能防越权，不是靠一句"别越权"的提示词，而是层层设防：

• 委托门禁先判定任务性质，杜绝"该拆不拆"和"无谓乱拆"
• 六要素契约把目标、范围、约束、交付、验收钉死
• 文件所有权 + 只读沙箱从权限层面锁死写操作
• 升级机制让越界情况"上报"而非"自作主张"
• 完成门禁 + 最终验证由根代理兜底验收

这套机制把"子代理不越权"从一句愿望变成了可执行的制度，正是 Codex Astra Luna Orchestrator 编排可靠性的核心来源。