企业官网建设流程全解析

• 前端
• 开发工具

本文基于 Dillinger（Next.js Markdown 编辑器）仓库中 .agent/agents/orchestrator.md 的完整定义，解析该多智能体体系"总调度器"的工作机制：如何在调用任何专家 Agent 之前执行 PLAN.md 预检与项目类型路由，如何通过文件归属表强制领域边界，以及如何完成从任务分解到统一报告的合成。读完后你可以完整掌握一套可复制的 Claude Code 原生 Agent Tool 编排协议，并将其迁移到自己的项目中。

一、Orchestrator 在 Dillinger 开发工具链中的位置

Dillinger 仓库的 .agent/ 目录内置了一套名为Antigravity Kit的 AI 智能体能力工具包。根据 ARCHITECTURE.md 的统计，该体系由三部分组成：

orchestrator本身是 16 个专家 Agent 中的元智能体（meta agent）：它不直接写业务代码，而是通过 Claude Code 的原生Agent Tool调用其他 15 个领域专家，完成并行分析与结果合成。ARCHITECTURE.md 中给出的快速参考表明确了这一分工——"Plan" 需求路由到project-planner+brainstorming/plan-writing技能，而orchestrator自身依赖parallel-agents与behavioral-modes两个技能。

1.1 Agent 定义文件的 frontmatter 格式

每个 Agent 都是一个带 YAML frontmatter 的 Markdown 文件。以 orchestrator.md 文件头部为例：

name: orchestrator description: Multi-agent coordination and task orchestration. Use when a task requires multiple perspectives, parallel analysis, or coordinated execution across different domains. Invoke this agent for complex tasks that benefit from security, backend, frontend, testing, and DevOps expertise combined. tools: Read, Grep, Glob, Bash, Write, Edit, Agent model: inherit skills: clean-code, parallel-agents, behavioral-modes, plan-writing, brainstorming, architecture, lint-and-validate, powershell-windows, bash-linux

各字段的设计意图值得逐项拆解：

对照 project-planner.md 的定义可以看到同一套模式的另一面：它的tools是Read, Grep, Glob, Bash（没有Agent工具），即它是被调度者而非调度者；其正文甚至明确写道 "You are likely invoked by Orchestrator"，要求首先检查 PROMPT 中的上下文区块。这印证了体系的层级关系：orchestrator（可再调用）→ 领域专家（只执行）→ 技能脚本（可执行工具）。

二、第一步永远是运行时能力检查（RUNTIME CAPABILITY CHECK）

orchestrator 定义文档规定了一个先于一切规划的强制第一步：验证当前运行时可用哪些工具。这体现了该体系的一条核心原则——不要只读代码，要执行脚本：

1. 读取 ARCHITECTURE.md，获取 Scripts & Skills 的完整清单；
2. 识别与任务相关的脚本，例如 Web 测试用playwright_runner.py，安全审计用security_scan.py；
3. 在任务执行计划中安排实际执行这些脚本，而非仅静态阅读代码。

这些脚本在仓库中真实存在，可直接定位到：

• playwright_runner.py —— E2E 测试执行器；
• security_scan.py —— 安全漏洞扫描；
• lint_runner.py —— Lint 与类型校验。

紧接着是PHASE 0：快速上下文检查，规则非常克制：

• 若已有计划文件则先读取；
• 请求清晰 → 直接开始；
• 存在重大歧义 → 最多问 1-2 个问题，然后继续。

文档用警示框强调了"不要过度追问"（Don't over-ask）：只要请求基本清晰就立即动手。这与后文的"先澄清再编排"并不矛盾——前者针对项目现状的快速核对，后者针对需求本身的模糊性（见第四节澄清矩阵）。

三、Orchestrator 的五项职责

文档将调度器的角色浓缩为五个动词：

1. Decompose（分解）：把复杂任务拆分为领域特定的子任务；
2. Select（选择）：为每个子任务挑选合适的专家 Agent；
3. Invoke（调用）：通过原生 Agent Tool 发起调用；
4. Synthesize（合成）：把各 Agent 的发现合并为一致的整体输出；
5. Report（报告）：给出可执行的行动建议。

注意第五点：合成产物不是各 Agent 输出的简单拼接，而是带优先级排序的统一报告（模板见第八节）。parallel-agents技能中同样强调 "Single synthesis - One unified report, not separate outputs"。

四、编排前的双检查点与澄清矩阵

这是整个协议中"最不可跳过"的部分。文档设置了两个CRITICAL级检查点（Checkpoint），任何一项失败都意味着编排失败（FAILED orchestration）。

4.1 Checkpoint 1：计划验证（MANDATORY）

在调用任何专家 Agent 之前必须逐项核对：

文档用红字标注了违反条款：没有 PLAN.md 就调用专家 Agent = 编排失败。

4.2 Checkpoint 2：项目类型路由

Agent 指派必须与项目类型严格匹配，错配即为违规：

这条路由表防止了"用 Web 前端专家去改 React Native 代码"这类跨栈越界，与第六节的文件归属边界共同构成两层防错：路由层（选谁）+ 文件层（能写什么）。

4.3 澄清矩阵：先问清再编排

当用户请求模糊或开放时，文档的要求是"DO NOT assume. ASK FIRST."（不要假设，先问）。澄清聚焦五个维度：

标准的澄清话术模板为：

Before I coordinate the agents, I need to understand your requirements better: 1. [Specific question about scope] 2. [Specific question about priority] 3. [Specific question about any unclear aspect]

文档末尾的红线是：绝不基于假设进行编排——先澄清，后执行（Clarify first, execute after）。

4.4 检查点汇总

文档在正文末尾又给出了一个可打印的核对表，确保任何一次 Agent 调用前都能被机器化核验：

五、16 个可用专家 Agent 与选择策略

5.1 完整 Agent 目录

文档给出了调度器可直接调用的全部专家清单及其触发场景：

两点值得注意：

• documentation-writer被标注了特殊限制——只在用户明确要求写文档时才调用，防止 Agent 自作主张生成文档污染代码库；
• 从 agents/ 目录 的文件列表看，api-designer在清单中被列出，但目录下暂无对应的api-designer.md定义文件。可以推断该角色可能依赖运行时临时注入的通用能力或其他定义兜底，属于体系演进中的边缘案例。

5.2 Agent 选择规则（Step 2）

编排工作流的第二步给出量化选择策略：选 2-5 个 Agent，并遵循三条硬规则：

1. 只要修改代码，必须包含test-engineer；
2. 只要触碰认证逻辑，必须包含security-auditor；
3. 其余按受影响的架构层选择。

配合 parallel-agents 技能中的触发词映射表（如 "security"/"auth" →security-auditor，"bug"/"not working" →debugger），调度器可以从用户的一句话里机械地推出 Agent 组合。而 /orchestrate 工作流 进一步把下限抬高：编排 = 至少 3 个不同 Agent，少于 3 个"不算编排，只是委派"，并给出了任务类型与最少 Agent 组合的矩阵（如 API 类任务 = backend-specialist + security-auditor + test-engineer）。

5.3 Agent 状态机

每个被调度的 Agent 有四个状态，供调度器跟踪与报告：

六、领域边界强制（Agent Boundary Enforcement）

这是文档篇幅最重的核心机制：每个 Agent 必须待在自己的领域内，跨域作业即为违规（VIOLATION）。

6.1 能力边界表（CAN / CANNOT）

6.2 文件类型归属表

能力边界之外，还有第二层按文件模式的属主表——这是可被工具机械化执行的规则：

这套 glob 规则与 Dillinger 自身的目录约定天然契合：仓库中 components/ 目录存放MonacoEditor.tsx、DocumentList.tsx等 UI 组件，app/api/ 目录存放 GitHub/Dropbox/Google Drive 等 API 路由处理器——若用该协议改造本仓库，frontend-specialist只能写components/，backend-specialist只能写app/api/，测试工程师独占 tests/ 下的*.test.ts与 tests/e2e/ 下的 Playwright 规格。

6.3 强制执行协议与违规示例

执行协议是一段伪代码，定义了"写文件前的拦截逻辑"：

WHEN agent is about to write a file: IF file.path MATCHES another agent's domain: → STOP → INVOKE correct agent for that file → DO NOT write it yourself

文档给出的正误对照示例：

❌ WRONG: frontend-specialist writes: __tests__/TaskCard.test.tsx → VIOLATION: Test files belong to test-engineer ✅ CORRECT: frontend-specialist writes: components/TaskCard.tsx → THEN invokes test-engineer test-engineer writes: __tests__/TaskCard.test.tsx

收尾红线：一旦看到 Agent 在写自己领域外的文件，立即停止并重新路由（STOP and re-route）。

七、原生 Agent 调用协议（Native Agent Invocation Protocol）

文档定义了四种调用语法，全部通过 Claude Code 的原生 Agent Tool 完成，而非外部脚本：

单 Agent 调用：

Use the security-auditor agent to review authentication implementation

多 Agent 顺序调用：

First, use the explorer-agent to map the codebase structure. Then, use the backend-specialist to review API endpoints. Finally, use the test-engineer to identify missing test coverage.

带上下文的链式调用：

Use the frontend-specialist to analyze React components, then have the test-engineer generate tests for the identified components.

恢复先前 Agent：

Resume agent [agentId] and continue with the updated requirements.

/orchestrate 工作流 在此基础上补充了一条MANDATORY 上下文传递规则：调用任何子 Agent 时必须携带四要素——

1. Original User Request：用户原始请求全文；
2. Decisions Made：用户对澄清问题的全部回答；
3. Previous Agent Work：先前 Agent 的工作摘要；
4. Current Plan State：当前计划状态（如存在计划文件）。

工作流中给出的完整上下文示例长这样：

Use the project-planner agent to create PLAN.md: **CONTEXT:** - User Request: "原始需求原文" - Decisions: Tech=..., Layout=..., Auth=..., Design=... - Previous Work: Orchestrator asked N questions, user chose all options - Current Plan: 计划文件路径 + 现有结构摘要 **TASK:** Create detailed PLAN.md based on ABOVE decisions. Do NOT infer from folder name.

违反条款的说明同样直接：不带完整上下文调用子 Agent = 子 Agent 将做出错误假设。project-planner.md 的正文与之一一对应：它要求被调用后先找 PROMPT 中的 CONTEXT 区块，优先级为"对话历史 > 计划文件 > 项目文件 > 文件夹名"，且严禁从文件夹名推断项目类型。

八、编排工作流：四步法与合成报告模板

8.1 STEP 0：预检（任何 Agent 调用之前，强制）

# 1. Check for PLAN.md Read docs/PLAN.md # 2. If missing → Use project-planner agent first # "No PLAN.md found. Use project-planner to create plan." # 3. Verify agent routing # Mobile project → Only mobile-developer # Web project → frontend-specialist + backend-specialist

跳过 Step 0 = 编排失败。

8.2 STEP 1：任务分析（领域勾选）

What domains does this task touch? - [ ] Security - [ ] Backend - [ ] Frontend - [ ] Database - [ ] Testing - [ ] DevOps - [ ] Mobile

8.3 STEP 3：顺序调用（逻辑顺序）

1. explorer-agent → Map affected areas 2. [domain-agents] → Analyze/implement 3. test-engineer → Verify changes 4. security-auditor → Final security check (if applicable)

这个"探索 → 领域实现 → 测试 → 安全收尾"的管道与 parallel-agents 技能中的三种编排模式（Comprehensive Analysis / Feature Review / Security Audit）完全同构，属于跨文件互相印证的一致设计。

8.4 STEP 4：合成报告模板

所有 Agent 完成后，调度器按统一模板输出（注意是单一报告，不是 N 份输出）：

## Orchestration Report ### Task: [Original Task] ### Agents Invoked 1. agent-name: [brief finding] 2. agent-name: [brief finding] ### Key Findings - Finding 1 (from agent X) - Finding 2 (from agent Y) ### Recommendations 1. Priority recommendation 2. Secondary recommendation ### Next Steps - [ ] Action item 1 - [ ] Action item 2

/orchestrate 工作流 还给出了更严格的两阶段变体，可作为进阶形态理解：

• PHASE 1（规划，串行）：只允许project-planner创建 PLAN.md，可选explorer-agent勘察代码库——此阶段禁止任何其他 Agent；
• CHECKPOINT（用户审批）：计划完成后必须停下来请求用户显式批准，未获批准不得进入 Phase 2；
• PHASE 2（实施，并行）：批准后才并行调用，按并行分组组织——Foundation 组（database-architect+security-auditor）、Core 组（backend-specialist+frontend-specialist）、Polish 组（test-engineer+devops-engineer）；
• EXIT GATE（出口门禁）：完成前必须核验三项——被调用 Agent 数 ≥ 3、至少执行过security_scan.py等验证脚本、报告已生成。任何一项不满足都不得宣布编排完成。

其中引用的验证脚本在仓库中均可定位：security_scan.py、lint_runner.py、playwright_runner.py。

九、冲突解决机制

多 Agent 并行必然产生意见分歧，文档给出了两类冲突的处理规程：

同类文件编辑冲突（多个 Agent 建议修改同一文件）：

1. 收集全部建议；
2. 给出合并后的推荐方案；
3. 若仍有冲突，交由用户裁决偏好。

Agent 间结论不一致：

1. 如实记录两种立场；
2. 解释各自的取舍（trade-offs）；
3. 按固定优先级推荐——security（安全）> performance（性能）> convenience（便利）。

这个优先级与第六节"安全审计放在流程最后"的编排顺序互为表里：安全既是硬约束（一票否决式路由），又是软排序（冲突时的仲裁基准）。

十、最佳实践、内置 Agent 协同与完整示例

10.1 五条最佳实践

1. Start small：从 2-3 个 Agent 起步，按需加码；
2. Context sharing：把相关发现传递给后续 Agent；
3. Verify before commit：凡改代码必含test-engineer；
4. Security last：安全审计作为最终检查；
5. Synthesize clearly：一份统一报告，而非分散输出。

10.2 与 Claude Code 内置 Agent 的协同

体系不排斥 Claude Code 自带 Agent，而是明确分工——"用内置 Agent 图快，用自定义 Agent 图专长"：

parallel-agents 技能 中给出了同一张表并补充了模型列（Explore=Haiku，Plan/General-purpose=Sonnet），建议"快速搜索用 Explore，领域专长用自定义 Agent"。

10.3 完整示例：认证系统评审

文档给出的正确编排示例，用户输入只有一句："Review and improve the authentication system"。调度器的标准响应流程：

🔴 STEP 0: Pre-flight Check → Checking for PLAN.md... → PLAN.md found. Project type: WEB. Agent assignments: Valid. → Proceeding with orchestration. I'll coordinate multiple agents for a comprehensive review: 1. First, using explorer-agent to map auth-related code... 2. Now using security-auditor to review security posture... 3. Having backend-specialist review implementation... 4. Finally, test-engineer to check test coverage... ## Synthesis Report [Combined findings and recommendations]

对应的反例同样被写进文档，作为训练 LLM 行为边界的负样本。用户说 "Build me an e-commerce site" 时：

❌ 错误响应： ❌ 跳过 Step 0 检查 ❌ 直接调用 frontend-specialist ❌ 直接调用 backend-specialist ❌ 未验证 PLAN.md → VIOLATION: 违反编排协议 ✅ 正确响应： 🔴 STEP 0: Pre-flight Check → Checking for PLAN.md... → PLAN.md NOT FOUND. → STOPPING specialist agent invocation. → "No PLAN.md found. Creating plan first..." → 调用 project-planner agent → PLAN.md 创建完成 → 恢复编排

10.4 协议要点回顾

把整份 orchestrator.md 压缩成可执行清单，就是调度器的行为契约：

十一、如何把这套协议用于 Dillinger 仓库

如果你想在 Dillinger 这类 Next.js 项目上应用该协议，可直接按文档给出的路径操作（只读参考，无需修改仓库）：

1. 先读 .agent/ARCHITECTURE.md 建立 16 Agent / 40 Skill / 11 Workflow 的全景图，确认当前需求命中的 Agent 与脚本；
2. 用 plan-writing 与 brainstorming 技能先产出docs/PLAN.md（Dillinger 仓库的 docs/plans/ 目录已有 Next.js 迁移系列的真实计划文件，可作为 PLAN.md 的格式参照）；
3. 按"explorer → 领域专家 → test-engineer → security-auditor"的固定管道调用，且每步携带四要素上下文；
4. 结束前用 lint_runner.py 与 security_scan.py 做出口验证，对照 tests/routes/ 与 tests/e2e/ 中现有的 Vitest/Playwright 用例确认覆盖。

这套 orchestrator 定义的真正价值不在于"调用了多少 Agent"，而在于它把多智能体协作中最容易失控的三个环节——规划前置（PLAN.md 门禁）、职责隔离（文件属主表）、结论收敛（单一合成报告 + 安全优先仲裁）——全部变成了可检查、可验证的显式规则，从而让 LLM 驱动的并行开发从"随机委派"变成有协议的工程流程。

• 前端
• 开发工具