agent-orchestrator

核心用法

Agent Orchestrator 是一个元代理编排技能，专为复杂任务的多智能体协作而设计。其核心工作流程分为六个阶段：

任务分解阶段：将宏观任务拆解为可独立执行的子任务，建立依赖关系图，确保子任务之间最小化耦合。编排器会分析最终目标、识别关键交付物、确定组件依赖，并将独立工作分组为可并行处理的子任务。

代理生成阶段：为每个子任务动态创建专属工作空间，包含 SKILL.md 技能文件、inbox 输入目录、outbox 输出目录、workspace 工作区和 status.json 状态追踪文件。通过 create_agent.py 脚本自动化完成代理环境搭建。

代理分派阶段：向每个代理的 inbox 写入任务指令和输入文件，设置状态为 pending，并使用 Task 工具启动子代理执行。子代理读取自身 SKILL.md 技能定义后自主运行。

监控与整合阶段：通过轮询 status.json 检查代理完成状态，收集各代理 outbox 中的输出结果，验证交付物是否符合成功标准，合并整合输出内容，解决潜在的冲突问题。

解散阶段：归档代理工作空间，清理临时文件，生成最终执行摘要，包括各代理完成内容、遇到的问题、交付物位置和资源消耗指标。

显著优点

高度模块化设计：采用文件系统作为代理间通信媒介（inbox/outbox 模式），实现了代理间的松耦合，单个代理的失败不会影响整体系统稳定性。

动态能力生成：能够根据任务需求实时生成定制化的子代理技能定义，无需预先编写大量固定模板，具备极强的任务适应性。

并行执行效率：通过依赖图识别可并行执行的子任务，显著缩短复杂任务的总执行时间，特别适合数据收集、分析、写作等可分解的研究和创作工作流。

清晰的职责边界：每个子代理拥有明确的所有权范围和成功标准，避免了多代理系统中的责任模糊问题，便于调试和优化。

完善的生态支持：提供六种预构建代理模板（Research、Code、Analysis、Writer、Review、Integration），覆盖常见的任务类型，降低上手门槛。

潜在缺点与局限性

文件 I/O 开销：基于文件的通信协议在代理数量庞大或通信频繁时可能产生显著的性能瓶颈，状态文件的轮询机制也存在一定的延迟。

无内置容错机制：文档中未明确描述子代理失败时的自动重试、回滚或替代执行策略，需要使用者自行实现故障恢复逻辑。

依赖管理复杂度：虽然编排器能识别任务依赖，但在实际执行中，复杂的依赖链可能导致某个关键路径代理阻塞整个流程，缺乏动态资源调度能力。

状态一致性风险：多代理同时操作 status.json 可能引发竞态条件，尽管文档建议使用原子操作，但未提供具体的实现保障。

资源消耗不可控：子代理的创建数量理论上无硬性限制，在资源受限环境中可能导致系统过载，需要外部监控机制介入。

适合的目标群体

AI 应用开发者：需要构建复杂多步骤工作流的工程师，特别是涉及研究、分析、内容生成等需要多角色协作的场景。

数据科学与研究团队：需要自动化执行数据收集、清洗、分析、报告生成全流程的研究人员，可显著减少重复性协调工作。

内容创作团队：需要并行处理素材收集、初稿撰写、编辑审校、最终整合的媒体、出版或营销团队。

自动化运维工程师：希望将复杂的运维任务分解为可并行执行的检查、修复、验证子任务的技术团队。

产品管理与项目经理：需要自动化跟踪多维度项目信息、生成综合报告的产品和项目管理人员。

使用风险

子代理配置风险：编排器本身安全，但实际风险高度依赖于子代理的 SKILL.md 配置。若子代理被授予过度权限（如无限制的网络访问、系统命令执行），可能导致安全漏洞或意外操作。

资源耗尽风险：缺乏内置的子代理数量上限和超时控制，在复杂任务中可能创建过多代理实例，导致计算资源耗尽或 API 调用配额超限。

数据隔离风险：虽然使用文件系统隔离，但所有代理共享底层存储，配置不当可能导致代理间数据意外覆盖或敏感信息泄露。

调试复杂度：分布式执行模式使得问题定位困难，某个子代理的失败可能需要深入多个工作空间才能诊断根本原因。

版本兼容性：动态生成的 SKILL.md 可能依赖特定版本的工具或 API，若底层环境升级，可能导致子代理行为不一致。