前端开发工具【免费下载链接】dillingerThe last Markdown editor, ever.项目地址https://gitcode.com/gh_mirrors/di/dillinger点击查看免费下载本文基于 DillingerNext.js Markdown 编辑器仓库中 .agent/agents/orchestrator.md 的完整定义解析该多智能体体系总调度器的工作机制如何在调用任何专家 Agent 之前执行 PLAN.md 预检与项目类型路由如何通过文件归属表强制领域边界以及如何完成从任务分解到统一报告的合成。读完后你可以完整掌握一套可复制的 Claude Code 原生 Agent Tool 编排协议并将其迁移到自己的项目中。一、Orchestrator 在 Dillinger 开发工具链中的位置Dillinger 仓库的 .agent/ 目录内置了一套名为Antigravity Kit的 AI 智能体能力工具包。根据 ARCHITECTURE.md 的统计该体系由三部分组成组成数量说明Specialist Agents16角色化的专家智能体定义.agent/agents/*.mdSkills40领域知识模块.agent/skills/*/SKILL.md按任务上下文按需加载Workflows11斜杠命令流程.agent/workflows/*.md如/orchestrate、/plan、/debugorchestrator本身是 16 个专家 Agent 中的元智能体meta agent它不直接写业务代码而是通过 Claude Code 的原生Agent Tool调用其他 15 个领域专家完成并行分析与结果合成。ARCHITECTURE.md 中给出的快速参考表明确了这一分工——Plan 需求路由到project-plannerbrainstorming/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各字段的设计意图值得逐项拆解字段取值设计要点nameorchestratorAgent 的唯一标识供 Agent Tool 按名调用description长文本同时写给 LLM判断何时路由与人类阅读明确触发条件多视角、并行分析、跨领域协作toolsRead, Grep, Glob, Bash, Write, Edit, Agent关键点是最末的Agent工具——只有拥有该工具的 Agent 才能再调用其他 Agent这是调度权的来源modelinherit继承调用方的模型配置避免为协调角色单独绑定模型skills8 个技能名声明按需加载的知识模块如parallel-agents编排模式库、plan-writing计划写作、bash-linux/powershell-windows跨平台命令能力对照 project-planner.md 的定义可以看到同一套模式的另一面它的tools是Read, Grep, Glob, Bash没有Agent工具即它是被调度者而非调度者其正文甚至明确写道 You are likely invoked by Orchestrator要求首先检查 PROMPT 中的上下文区块。这印证了体系的层级关系orchestrator可再调用→ 领域专家只执行→ 技能脚本可执行工具。二、第一步永远是运行时能力检查RUNTIME CAPABILITY CHECKorchestrator 定义文档规定了一个先于一切规划的强制第一步验证当前运行时可用哪些工具。这体现了该体系的一条核心原则——不要只读代码要执行脚本读取 ARCHITECTURE.md获取 Scripts Skills 的完整清单识别与任务相关的脚本例如 Web 测试用playwright_runner.py安全审计用security_scan.py在任务执行计划中安排实际执行这些脚本而非仅静态阅读代码。这些脚本在仓库中真实存在可直接定位到playwright_runner.py —— E2E 测试执行器security_scan.py —— 安全漏洞扫描lint_runner.py —— Lint 与类型校验。紧接着是PHASE 0快速上下文检查规则非常克制若已有计划文件则先读取请求清晰 → 直接开始存在重大歧义 → 最多问 1-2 个问题然后继续。文档用警示框强调了不要过度追问Dont over-ask只要请求基本清晰就立即动手。这与后文的先澄清再编排并不矛盾——前者针对项目现状的快速核对后者针对需求本身的模糊性见第四节澄清矩阵。三、Orchestrator 的五项职责文档将调度器的角色浓缩为五个动词Decompose分解把复杂任务拆分为领域特定的子任务Select选择为每个子任务挑选合适的专家 AgentInvoke调用通过原生 Agent Tool 发起调用Synthesize合成把各 Agent 的发现合并为一致的整体输出Report报告给出可执行的行动建议。注意第五点合成产物不是各 Agent 输出的简单拼接而是带优先级排序的统一报告模板见第八节。parallel-agents技能中同样强调 Single synthesis - One unified report, not separate outputs。四、编排前的双检查点与澄清矩阵这是整个协议中最不可跳过的部分。文档设置了两个CRITICAL级检查点Checkpoint任何一项失败都意味着编排失败FAILED orchestration。4.1 Checkpoint 1计划验证MANDATORY在调用任何专家 Agent 之前必须逐项核对检查项动作失败时的处理计划文件是否存在Read ./{task-slug}.mdSTOP → 先创建计划项目类型是否已识别在计划中查找 WEB/MOBILE/BACKENDSTOP → 交给 project-planner任务是否已定义在计划中查找任务分解STOP → 使用 project-planner文档用红字标注了违反条款没有 PLAN.md 就调用专家 Agent 编排失败。4.2 Checkpoint 2项目类型路由Agent 指派必须与项目类型严格匹配错配即为违规项目类型正确 Agent禁用 AgentMOBILEmobile-developer❌ frontend-specialist、backend-specialistWEBfrontend-specialist❌ mobile-developerBACKENDbackend-specialist—这条路由表防止了用 Web 前端专家去改 React Native 代码这类跨栈越界与第六节的文件归属边界共同构成两层防错路由层选谁 文件层能写什么。4.3 澄清矩阵先问清再编排当用户请求模糊或开放时文档的要求是DO NOT assume. ASK FIRST.不要假设先问。澄清聚焦五个维度不明确之处应先问的问题Scope范围范围是什么整个应用 / 特定模块 / 单个文件Priority优先级什么最重要安全 / 速度 / 功能Tech Stack技术栈有无偏好框架 / 数据库 / 托管平台Design设计视觉风格偏好极简 / 大胆 / 特定配色Constraints约束有哪些约束时间 / 预算 / 既有代码标准的澄清话术模板为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 调用前都能被机器化核验检查点验证方式失败动作PLAN.md 存在Read docs/PLAN.md先使用 project-planner项目类型有效已识别 WEB/MOBILE/BACKEND询问用户或分析请求Agent 路由正确Mobile → 仅 mobile-developer重新指派苏格拉底门通过3 个问题已问且已答先提问五、16 个可用专家 Agent 与选择策略5.1 完整 Agent 目录文档给出了调度器可直接调用的全部专家清单及其触发场景Agent领域使用时机security-auditor安全与认证认证、漏洞、OWASPpenetration-tester安全测试主动漏洞测试、红队backend-specialist后端与 APINode.js、Express、FastAPI、数据库frontend-specialist前端与 UIReact、Next.js、Tailwind、组件test-engineer测试与 QA单元测试、E2E、覆盖率、TDDdevops-engineerDevOps 与基础设施部署、CI/CD、PM2、监控database-architect数据库与 SchemaPrisma、迁移、优化mobile-developer移动应用React Native、Flutter、Expoapi-designerAPI 设计REST、GraphQL、OpenAPIdebugger调试根因分析、系统性排错explorer-agent探索发现代码库勘察、依赖梳理documentation-writer文档仅在用户显式要求文档时performance-optimizer性能剖析、优化、瓶颈project-planner规划任务分解、里程碑、路线图seo-specialistSEO 与增长SEO 优化、meta 标签、分析game-developer游戏开发Unity、Godot、Unreal、Phaser、多人两点值得注意documentation-writer被标注了特殊限制——只在用户明确要求写文档时才调用防止 Agent 自作主张生成文档污染代码库从 agents/ 目录 的文件列表看api-designer在清单中被列出但目录下暂无对应的api-designer.md定义文件。可以推断该角色可能依赖运行时临时注入的通用能力或其他定义兜底属于体系演进中的边缘案例。5.2 Agent 选择规则Step 2编排工作流的第二步给出量化选择策略选 2-5 个 Agent并遵循三条硬规则只要修改代码必须包含test-engineer只要触碰认证逻辑必须包含security-auditor其余按受影响的架构层选择。配合 parallel-agents 技能中的触发词映射表如 security/auth →security-auditorbug/not working →debugger调度器可以从用户的一句话里机械地推出 Agent 组合。而 /orchestrate 工作流 进一步把下限抬高编排 至少 3 个不同 Agent少于 3 个不算编排只是委派并给出了任务类型与最少 Agent 组合的矩阵如 API 类任务 backend-specialist security-auditor test-engineer。5.3 Agent 状态机每个被调度的 Agent 有四个状态供调度器跟踪与报告状态图标含义PENDING⏳等待被调用RUNNING正在执行COMPLETED✅成功完成FAILED❌遇到错误六、领域边界强制Agent Boundary Enforcement这是文档篇幅最重的核心机制每个 Agent 必须待在自己的领域内跨域作业即为违规VIOLATION。6.1 能力边界表CAN / CANNOTAgent可以做不能做frontend-specialist组件、UI、样式、hooks❌ 测试文件、API 路由、DBbackend-specialistAPI、服务端逻辑、DB 查询❌ UI 组件、样式test-engineer测试文件、mock、覆盖率❌ 生产代码mobile-developerRN/Flutter 组件、移动端 UX❌ Web 组件database-architectSchema、迁移、查询❌ UI、API 逻辑security-auditor审计、漏洞、认证审查❌ 功能代码、UIdevops-engineerCI/CD、部署、基础设施配置❌ 应用代码api-designerAPI 规范、OpenAPI、GraphQL schema❌ UI 代码performance-optimizer剖析、优化、缓存❌ 新功能seo-specialistmeta 标签、SEO 配置、分析❌ 业务逻辑documentation-writer文档、README、注释❌ 代码逻辑❌ 未经显式请求的自动调用project-plannerPLAN.md、任务分解❌ 代码文件debugger修 Bug、根因❌ 新功能explorer-agent代码库发现❌ 写操作penetration-tester安全测试❌ 功能代码game-developer游戏逻辑、场景、资源❌ Web/移动端组件6.2 文件类型归属表能力边界之外还有第二层按文件模式的属主表——这是可被工具机械化执行的规则文件模式属主 Agent其他 Agent**/*.test.{ts,tsx,js}test-engineer❌ 全部拦截**/__tests__/**test-engineer❌ 全部拦截**/components/**frontend-specialist❌ backend、test 拦截**/api/**、**/server/**backend-specialist❌ frontend 拦截**/prisma/**、**/drizzle/**database-architect❌ frontend 拦截这套 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 agents 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.恢复先前 AgentResume agent [agentId] and continue with the updated requirements./orchestrate 工作流 在此基础上补充了一条MANDATORY 上下文传递规则调用任何子 Agent 时必须携带四要素——Original User Request用户原始请求全文Decisions Made用户对澄清问题的全部回答Previous Agent Work先前 Agent 的工作摘要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 - [ ] Mobile8.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勘察代码库——此阶段禁止任何其他 AgentCHECKPOINT用户审批计划完成后必须停下来请求用户显式批准未获批准不得进入 Phase 2PHASE 2实施并行批准后才并行调用按并行分组组织——Foundation 组database-architectsecurity-auditor、Core 组backend-specialistfrontend-specialist、Polish 组test-engineerdevops-engineerEXIT GATE出口门禁完成前必须核验三项——被调用 Agent 数 ≥ 3、至少执行过security_scan.py等验证脚本、报告已生成。任何一项不满足都不得宣布编排完成。其中引用的验证脚本在仓库中均可定位security_scan.py、lint_runner.py、playwright_runner.py。九、冲突解决机制多 Agent 并行必然产生意见分歧文档给出了两类冲突的处理规程同类文件编辑冲突多个 Agent 建议修改同一文件收集全部建议给出合并后的推荐方案若仍有冲突交由用户裁决偏好。Agent 间结论不一致如实记录两种立场解释各自的取舍trade-offs按固定优先级推荐——security安全 performance性能 convenience便利。这个优先级与第六节安全审计放在流程最后的编排顺序互为表里安全既是硬约束一票否决式路由又是软排序冲突时的仲裁基准。十、最佳实践、内置 Agent 协同与完整示例10.1 五条最佳实践Start small从 2-3 个 Agent 起步按需加码Context sharing把相关发现传递给后续 AgentVerify before commit凡改代码必含test-engineerSecurity last安全审计作为最终检查Synthesize clearly一份统一报告而非分散输出。10.2 与 Claude Code 内置 Agent 的协同体系不排斥 Claude Code 自带 Agent而是明确分工——用内置 Agent 图快用自定义 Agent 图专长内置 Agent用途使用时机Explore快速代码库搜索Haiku 级小模型快速文件发现Plan规划期研究Sonnet 级计划模式研究General-purpose复杂多步任务Sonnet 级重活parallel-agents 技能 中给出了同一张表并补充了模型列ExploreHaikuPlan/General-purposeSonnet建议快速搜索用 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. Ill 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 压缩成可执行清单就是调度器的行为契约阶段动作失败条件运行时检查读 ARCHITECTURE.md锁定要执行的脚本只读不执行Phase 0快速核对现有计划/上下文过度追问Checkpoint 1PLAN.md 存在、类型已识别、任务已分解无计划就调专家Checkpoint 2项目类型 → Agent 路由匹配跨栈错配澄清矩阵范围/优先级/技术栈/设计/约束基于假设编排调用顺序管道 全量上下文传递缺上下文边界能力表 文件属主表双重拦截跨域写文件合成单一统一报告 冲突仲裁安全性能便利多份碎片输出十一、如何把这套协议用于 Dillinger 仓库如果你想在 Dillinger 这类 Next.js 项目上应用该协议可直接按文档给出的路径操作只读参考无需修改仓库先读 .agent/ARCHITECTURE.md 建立 16 Agent / 40 Skill / 11 Workflow 的全景图确认当前需求命中的 Agent 与脚本用 plan-writing 与 brainstorming 技能先产出docs/PLAN.mdDillinger 仓库的 docs/plans/ 目录已有 Next.js 迁移系列的真实计划文件可作为 PLAN.md 的格式参照按explorer → 领域专家 → test-engineer → security-auditor的固定管道调用且每步携带四要素上下文结束前用 lint_runner.py 与 security_scan.py 做出口验证对照 tests/routes/ 与 tests/e2e/ 中现有的 Vitest/Playwright 用例确认覆盖。这套 orchestrator 定义的真正价值不在于调用了多少 Agent而在于它把多智能体协作中最容易失控的三个环节——规划前置PLAN.md 门禁、职责隔离文件属主表、结论收敛单一合成报告 安全优先仲裁——全部变成了可检查、可验证的显式规则从而让 LLM 驱动的并行开发从随机委派变成有协议的工程流程。赞分享前端开发工具【免费下载链接】dillingerThe last Markdown editor, ever.项目地址https://gitcode.com/gh_mirrors/di/dillinger点击查看免费下载相关推荐openinterpreter codex-rs Orchestrator 提示模板多智能体编码 Agent 的编排行为协议openinterpreter codex rs Orchestrator 提示模板多智能体编码 Agent 的编排行为协议 在 openinterprete人工智能大模型AI Agent代码智能体AI 应用CLI多智能体编排实战基于 ToolLoopAgent 的 Orchestrator Agent 设计与实现Agent-Skills-for-Context-Engineering多智能体编排实战基于 ToolLoopAgent 的 Orchestrator Agent 设计与实现Agent Skills for Context En人工智能AI 技能提示工程AI 评测V8 多智能体编排实战Orchestrator 技能中的任务调度、DAG 管理与子代理协调V8 多智能体编排实战Orchestrator 技能中的任务调度、DAG 管理与子代理协调 导读 本文以 agents/skills/orchestrator语言运行时编译器JIT编译解释器内存管理上一篇MusicFree播放被打断时音量调节功能的优化思路下一篇Pace主题选择指南15款内置加载动画主题与10种配色如何挑选最合适的一款创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考