AI专家团队调度器：用YAML和自然语言实现多智能体协作

1. 项目概述：当AI专家们开始“开会”

如果你和我一样，是个喜欢折腾的程序员，那你肯定经历过这种场景：想做一个新项目，比如用AI搞个副业，或者评估一个技术方案的可行性。你打开ChatGPT或者Claude，开始和它“聊天”。你问它市场怎么样，它给你分析一通；你再问它技术怎么实现，它又给你讲一遍。整个过程就像是你一个人在跟一个“全能但泛泛”的顾问对话，你得自己把市场、技术、产品、运营这些碎片拼起来，最后还得自己拍板。

这效率太低了，而且视角单一。真正的决策，尤其是商业或技术决策，需要的是一个团队，而不是一个通才。你需要市场专家告诉你趋势，需要产品经理梳理需求，需要架构师评估技术，需要财务算清账目。如果能让这些“专家”同时上线，各司其职，最后给你一份整合好的报告，那该多好？

这就是agency-orchestrator要解决的问题。它不是一个聊天机器人，而是一个AI专家团队的调度中心。你不需要写Python代码去调用LangChain或者CrewAI，也不需要为每个专家角色写复杂的prompt。你只需要用一句人话描述你的需求，或者写一个简单的YAML配置文件，它就能自动从211个预设的专业AI角色库里，挑选出最合适的“专家”，按照任务依赖关系（DAG）并行或串行地工作，最后给你一个完整的、多视角的方案。

我花了几天时间深度体验了这个工具，从安装、配置到跑通各种工作流，甚至把它集成到了我的日常开发环境里。这篇文章，我就以一个一线开发者的视角，带你彻底搞懂这个“AI团队调度器”到底怎么用，它的核心设计巧在哪里，以及在实际操作中会遇到哪些坑、怎么避开。

2. 核心设计思路：为什么是YAML和“一句话”？

在深入代码和命令之前，我们得先理解agency-orchestrator的设计哲学。市面上已经有不少多智能体框架，比如CrewAI、LangGraph，它们功能强大，但门槛也高。你需要懂Python，需要理解它们的API，需要自己定义Agent、Task、Tool，整个过程更像是在“编程”。

agency-orchestrator走了另一条路：配置即代码，自然语言即接口。它的目标用户，是那些想快速获得高质量、结构化结果的实践者，而不是AI框架的研究者。

2.1 YAML工作流：把复杂协作可视化

它的核心是一个工作流引擎，用YAML文件来定义。为什么是YAML？因为足够简单、可读性强、易于版本管理。一个典型的工作流文件，看起来就像一份项目计划书：

name: “产品需求评审” agents_dir: “agency-agents-zh” llm: provider: “deepseek” model: “deepseek-chat” concurrency: 2 inputs: - name: prd_content required: true steps: - id: analyze role: “product/product-manager” task: “分析以下PRD，提取核心需求：\n\n{{prd_content}}” output: requirements - id: tech_review role: “engineering/engineering-software-architect” task: “评估技术可行性：\n\n{{requirements}}” output: tech_report depends_on: [analyze] - id: design_review role: “design/design-ux-researcher” task: “评估用户体验风险：\n\n{{requirements}}” output: design_report depends_on: [analyze] - id: summary role: “product/product-manager” task: “综合反馈输出结论：\n\n{{tech_report}}\n\n{{design_report}}” depends_on: [tech_review, design_review]

这个YAML定义了一个四步工作流：

1. 产品经理分析PRD，输出需求要点。
2. 软件架构师和UX研究员基于上一步的需求，并行地进行技术评审和设计评审。
3. 最后，产品经理（可以是同一个角色，也可以是另一个）汇总两份报告，给出最终结论。

depends_on字段清晰地定义了步骤间的依赖关系，引擎会自动构建DAG（有向无环图），并让没有依赖关系的步骤并发执行（concurrency: 2控制了最大并发数）。这种设计让复杂的多角色协作变得一目了然，修改流程就像调整项目甘特图一样直观。

2.2 “一句话”编排：把选择权交给AI

但写YAML对新手来说还是有点门槛。agency-orchestrator更厉害的一招是ao compose命令。你只需要用自然语言描述你的需求，AI会帮你完成剩下的所有事：

ao compose “PR代码审查，要覆盖安全和性能” --run

执行这个命令后，引擎内部会：

1. 理解意图：解析你的自然语言描述，识别出核心任务是“代码审查”，并特别强调了“安全”和“性能”。
2. 角色匹配：从211个中文角色库（agency-agents-zh）中，智能匹配出最相关的专家，比如“代码审查员”、“安全工程师”、“性能基准师”。
3. 设计流程：自动设计一个合理的DAG。通常会让三个专家并行审查代码的不同方面，然后由一个“汇总者”角色（可能是“技术负责人”或“架构师”）整合报告。
4. 生成并执行：自动生成一个完整的、可执行的YAML工作流文件，并立即运行它。

这个过程完全自动化，你不需要知道角色库里有谁，也不需要懂DAG怎么画。对于快速验证一个想法、完成一次性的分析任务，这个功能简直是“神器”。它把从“想法”到“结果”的路径压缩到了最短。

2.3 角色库：即插即用的专家系统

项目的强大，一半功劳要归于其背后的角色库。agency-agents-zh这个仓库提供了211个精心设计的中文AI角色。每个角色都是一个独立的YAML文件，定义了该角色的“人设”、专业领域、思考方式和系统提示词（system prompt）。

例如，一个“小红书专家”的角色定义，会包含对小红书平台算法、用户偏好、内容格式、热门话题的深刻理解。当这个角色被调用时，它给出的建议会非常“接地气”，直接符合小红书生态的玩法，而不是泛泛而谈的“社交媒体运营”。

这种设计带来了巨大的灵活性。你可以直接使用这些现成的专家，也可以基于它们进行微调，甚至创建自己的专属角色库。这相当于拥有了一个覆盖产品、技术、市场、运营、财务、法务等各个领域的“虚拟专家团队”，随时待命。

3. 环境准备与快速上手

理论讲完了，我们动手实操。我的环境是macOS，Windows和Linux用户操作类似。

3.1 安装与初始化

安装非常简单，因为它是一个Node.js的CLI工具：

npm install -g agency-orchestrator

安装完成后，你可以先体验一下“零配置”的演示：

ao demo

这个命令会运行一个内置的简单工作流，让你感受一下多角色协作的过程和输出格式。

接下来，我建议初始化本地角色库。虽然运行时会自动从GitHub拉取，但本地有一份副本更方便查看和自定义：

# 初始化中文角色库（默认） ao init # 或者初始化英文角色库 ao init --lang en

执行后，会在当前目录下创建一个agency-agents-zh（或agency-agents）的文件夹，里面就是那211个角色的定义文件。你可以打开看看，理解一下角色是如何被定义的。

3.2 选择你的“算力”：LLM提供商配置

这是最关键的一步。agency-orchestrator支持多达10种大语言模型，其中7种可以完全不用API Key，直接利用你已经付费的AI服务。这是它相比其他框架一个巨大的优势。

场景一：你已经是某家AI服务的付费用户

• 你有Claude Pro/Max会员：这是体验最好的方式之一。

  # 首先安装Claude Code CLI工具 npm install -g @anthropic-ai/claude-code # 然后在工作流YAML中配置或命令行指定 ao compose “你的需求” --run --provider claude-code

  Claude Code模型能力很强，上下文长，适合复杂任务。
• 你有GitHub Copilot订阅：

  npm install -g @github/copilot # 使用 copilot-cli 作为 provider

• 你有ChatGPT Plus/Pro：

  npm install -g @openai/codex # 使用 codex-cli 作为 provider

• 你有Google账号（可用Gemini）：

  npm install -g @google/gemini-cli # 使用 gemini-cli 作为 provider，免费额度很高。

场景二：你想用免费的API

• DeepSeek：目前性价比极高的选择。去官网注册，获取API Key。

  export DEEPSEEK_API_KEY=“你的key” ao compose “你的需求” --run --provider deepseek --model deepseek-chat

• Ollama：在本地运行开源模型，完全免费，但需要本地算力。

  # 首先安装并启动Ollama，拉取模型如qwen2.5:7b ollama run qwen2.5:7b # 在工作流中配置 provider: ollama, model: qwen2.5:7b

场景三：使用国内兼容OpenAI的API比如火山引擎、智谱、月之暗面等。这些需要配置为provider: openai，并指定自定义的base_url。

# 方法一：使用ao init命令快速配置 ao init --provider openai --model glm-4 --base-url https://open.bigmodel.cn/api/paas/v4 --api-key 你的key # 方法二：手动创建或编辑 .env 文件 echo ‘AO_PROVIDER=openai’ > .env echo ‘AO_MODEL=glm-4’ >> .env echo ‘OPENAI_BASE_URL=https://open.bigmodel.cn/api/paas/v4’ >> .env echo ‘OPENAI_API_KEY=你的key’ >> .env

实操心得一：模型选择策略根据任务类型选模型：

• 复杂分析、长文本生成（如商业计划、技术方案）：优先claude-code或deepseek-chat。它们逻辑能力强，上下文窗口大。
• 代码审查、技术设计：claude-code、copilot-cli或codex-cli是首选，它们在代码理解上更专业。
• 快速验证、简单任务：gemini-cli或ollama（如果本地模型足够强）是不花钱的好选择。
• 谨慎使用完全免费的CLI模式：如gemini-cli可能有速率限制，复杂工作流可能中途失败。对于重要任务，建议使用有稳定保障的API模式（如DeepSeek）。

3.3 你的第一个“一句话”工作流

环境准备好了，我们来跑一个最简单的例子，验证整个流程：

ao compose “帮我用Python写一个简单的网页爬虫，获取豆瓣电影Top250的电影名称和评分” --run --provider deepseek

等待1-3分钟，你会在终端看到类似下面的输出：

工作流: Python网页爬虫实现 步骤数: 3 | 并发: 2 | 模型: deepseek-chat 参与者: 💻 后端开发工程师 | 🕸️ 爬虫工程师 | 📋 代码审查员 ────────────────────────────────────────────────── ✅ 💻 后端开发工程师 25.1s → 分析需求，确定技术栈（requests, BeautifulSoup） ✅ 🕸️ 爬虫工程师 45.3s → 编写爬虫代码，处理反爬策略（User-Agent， 延迟） ✅ 📋 代码审查员 38.7s → 审查代码结构、异常处理和效率 ================================================== 完成: 3/3 步 | 109.1s | 4, 221 tokens ==================================================

运行完成后，所有输出文件会保存在ao-output/Python网页爬虫实现-<时间戳>/目录下。打开里面的summary.md，你就能看到完整的、可运行的Python爬虫代码，以及代码审查意见。

至此，你已经成功运行了第一个多智能体协作任务。整个过程，你只输入了一句话。

4. 核心功能深度解析与实战

掌握了基础操作，我们深入看看agency-orchestrator那些真正提升效率的高级特性和实战技巧。

4.1 工作流模板：开箱即用的最佳实践

项目内置了32个工作流模板，覆盖了开发、营销、数据、设计、运维、战略等常见场景。直接使用这些模板，可以跳过设计工作流的环节，快速获得专业输出。

查看所有模板：

# 进入工作流目录查看 ls workflows/ # 或者按类别查看 find workflows -name “*.yaml” | head -20

实战案例一：用内置模板做技术方案评审假设你写了一份新功能的技术方案文档tech-design.md，想请“架构师”、“安全工程师”和“代码审查员”帮你把关。

# 直接运行内置的“技术设计评审”模板 ao run workflows/dev/tech-design-review.yaml --input design_doc=@tech-design.md

这个模板的工作流是：先由“架构师”进行整体评审，然后“安全工程师”和“代码审查员”并行进行专项评审，最后再由“架构师”汇总给出结论。你不需要关心流程细节，只需要提供输入文档。

实战案例二：生成周报每周写周报很烦？可以用这个：

ao run workflows/ops/weekly-report.yaml --input raw_notes=@本周工作记录.txt --input week_number=18

它会调用“会议助手”整理你的零散记录，“内容创作者”润色成文，最后“高管摘要师”提炼亮点。一分钟，一份结构清晰、重点突出的周报就生成了。

实操心得二：活用--input参数--input参数非常灵活：

• key=value：直接传入字符串。
• key=@file_path：从文件读取内容，适合长文本输入。
• 可以在一个命令中组合多个--input。
• 如果YAML中定义了required: true的输入项，你必须通过--input提供，否则会报错。

4.2 智能编排（Compose）与迭代优化（Resume）

ao compose的智能程度很高，但第一次生成的结果可能不完全符合你的预期。这时，--resume和--from参数就派上大用场了。

完整流程示例：为一个AI工具创业想法制定商业计划

1. 首次运行，生成初步方案：

   ao compose “我想做一个帮助中小商家用AI生成短视频脚本的工具，请帮我制定商业计划” --run --provider claude-code --output bp-v1

   运行后，输出保存在ao-output/bp-v1/。你看了觉得市场分析部分不够深入，财务预测太乐观。
2. 只重做市场分析和财务部分： 首先，查看生成的工作流YAML文件（通常在ao-output/bp-v1/workflow.yaml），找到对应步骤的ID，比如market_analysis和financial_forecast。

   # 从上次运行的结果恢复，并从 market_analysis 步骤开始重跑 ao compose “我想做一个帮助中小商家用AI生成短视频脚本的工具，请帮我制定商业计划” --run --provider claude-code --resume ao-output/bp-v1/ --from market_analysis

   引擎会加载bp-v1中已完成步骤的输出（如“产品定义”、“技术架构”），然后从market_analysis步骤开始重新执行，并自动执行其后续的所有步骤（如financial_forecast,summary）。这样，你无需为已经满意的部分重复付费（消耗token）。
3. 多次迭代，精益求精： 你可以反复使用--resume和--from，针对不同的步骤进行微调。所有历史版本都保存在ao-output/下，方便回溯对比。

注意事项：Resume的工作原理--resume本质上是读取指定输出目录下的metadata.json和各个步骤的中间输出文件（.md），将这些输出作为后续步骤的输入变量。因此，不要手动删除或修改ao-output/里子目录的内容，除非你确定不再需要断点续跑了。建议为重要的运行使用--output指定一个有意义的目录名，便于管理。

4.3 集成到AI编程工具（MCP Server模式）

如果你日常使用 Claude Code、Cursor、Windsurf 等AI编程工具，那么MCP Server模式会让你效率飞升。它允许你直接在IDE里，通过自然语言命令来操控工作流。

配置步骤（以Claude Code为例）：

1. 启动MCP Server（可以放在后台运行）：

   ao serve

2. 打开Claude Code的设置（通常是Cmd + ,然后搜索MCP）。
3. 在MCP Servers配置中添加：

   { “mcpServers”: { “agency-orchestrator”: { “command”: “npx”, “args”: [“agency-orchestrator”, “serve”] } } }

4. 重启Claude Code。

配置成功后，你在Claude Code的聊天框中就可以直接说：

• “帮我运行一个PR代码审查工作流，代码在src/utils.ts文件里。”
• “列出所有可用的AI角色。”
• “为‘设计一个用户登录系统’这个需求智能编排一个工作流。”

AI助手会调用agency-orchestrator的MCP工具，执行相应操作并将结果返回给你。这意味着你可以在编码的同时，无缝地进行需求分析、设计评审、文档生成等协作任务，无需切换终端或上下文。

4.4 自定义与扩展：打造你的专属AI团队

内置的211个角色很强大，但总有覆盖不到的场景。这时就需要自定义。

1. 自定义角色角色定义在agency-agents-zh/目录下，按领域分类。例如，你想创建一个“跨境电商物流专家”角色。

• 在agency-agents-zh/下找到合适的分类，比如business/。
• 新建文件business-cross-border-logistics-expert.yaml。
• 参考其他角色的格式编写，核心是system字段下的提示词，要详细定义该专家的背景、专业知识、说话风格和输出格式。

name: “跨境电商物流专家” description: “精通亚马逊FBA、独立站物流、关税计算、海外仓优化，熟悉中美欧物流政策。” system: > 你是一名拥有10年经验的跨境电商物流解决方案专家。你擅长... （此处详细描述专业知识、思考框架、输出要求）

保存后，在你的工作流YAML中，就可以通过role: “business/business-cross-border-logistics-expert”来调用这个新角色了。

2. 自定义工作流模板将你经常使用的、调试好的工作流YAML文件保存到workflows/目录下的自定义文件夹中，例如workflows/my-company/。以后就可以通过ao run workflows/my-company/xxx.yaml快速调用。

3. 使用条件分支和循环工作流支持简单的条件逻辑和循环，适合更复杂的场景。

• 条件分支 (condition): 某个步骤可以根据之前步骤的输出决定是否执行。

  - id: check_feasibility role: “engineering/engineering-software-architect” task: “评估技术可行性：{{requirements}}” output: feasibility_report - id: proceed_development role: “engineering/engineering-backend-architect” task: “基于可行方案进行详细设计” depends_on: [check_feasibility] condition: “{{feasibility_report}} contains ‘可行’“ # 只有报告里包含“可行”才执行

• 循环 (loop): 用于需要迭代优化的场景，比如多次评审直到通过。

  - id: code_review role: “engineering/engineering-code-reviewer” task: “审查代码：{{code}}” output: review_comments - id: revise_code role: “engineering/engineering-backend-developer” task: “根据反馈修改代码：\n原代码：{{code}}\n反馈：{{review_comments}}” output: revised_code depends_on: [code_review] loop: back_to: code_review # 修改后跳回评审步骤 max_iterations: 3 # 最多循环3次 exit_condition: “{{review_comments}} contains ‘LGTM’ or ‘通过’” # 评审意见包含LGTM则退出循环

5. 常见问题、排查技巧与性能优化

在实际使用中，你肯定会遇到一些问题。下面是我踩过坑后总结的排查指南。

5.1 执行失败与错误排查

问题1：步骤执行超时或LLM无响应

• 现象：某个步骤卡住很久，最后报错Timeout或LLM call failed。
• 原因：网络问题、LLM服务不稳定、或任务过于复杂导致模型“思考”时间过长。
• 解决：
  1. 检查网络和API Key：确保你的网络能正常访问对应的LLM服务，API Key有效且额度充足。
  2. 调整超时设置：在工作流YAML的llm部分增加timeout参数（单位毫秒），例如timeout: 300000（5分钟）。
  3. 简化任务：如果某个task描述过于复杂，尝试拆分成更小的子任务，或优化提示词使其更清晰。
  4. 切换模型：某些模型对复杂逻辑处理可能较慢，可以换一个更快的模型（如从claude-code切换到deepseek-chat）试试。

问题2：depends_on循环依赖错误

• 现象：运行ao validate或ao plan时，报错提示循环依赖。
• 原因：在YAML中，步骤A依赖步骤B，步骤B又直接或间接依赖步骤A，形成了死循环。
• 解决：仔细检查工作流中所有步骤的depends_on字段，确保依赖关系是一个有向无环图（DAG）。可以使用ao plan workflow.yaml命令可视化查看依赖图，帮助定位问题。

问题3：变量渲染错误Variable ‘xxx’ not found

• 现象：运行时报错，提示找不到变量。
• 原因：在task或condition中使用了{{variable_name}}，但这个变量没有被定义。可能的原因有：
  • 拼写错误。
  • 该变量所在的步骤output名称与引用名称不一致。
  • 该变量所在的步骤执行失败，没有产生输出。
  • 在depends_on中未正确声明依赖关系。
• 解决：
  1. 使用ao validate workflow.yaml进行静态校验，它会检查基本的变量引用。
  2. 运行ao plan workflow.yaml，确认步骤依赖关系是否正确。
  3. 检查每个步骤的output字段名，确保引用时完全一致。

5.2 输出质量优化技巧

技巧1：给角色更具体的上下文角色的systemprompt 是通用的。在task描述中，提供越具体的背景信息，输出质量越高。

• 差：task: “写一份产品需求文档。”
• 好：task: “为我们计划开发的‘AI短视频脚本工具’撰写PRD。目标用户是中小餐饮店老板，核心功能是通过输入菜品照片和优惠信息，自动生成15秒抖音口播脚本。请包含用户故事、功能列表和成功指标。”

技巧2：利用“人工审批”节点进行质量控制对于关键输出，可以插入type: approval的步骤。

- id: final_review type: approval prompt: “请仔细审阅以下商业计划书摘要，确认无误后输入‘批准’继续，或输入修改意见：\n\n{{summary_report}}” depends_on: [summary]

运行到这一步时，工作流会暂停，在终端等待你输入“批准”或反馈意见。这给了你介入关键决策的机会。

技巧3：控制输出格式在角色的systemprompt 或步骤的task中，明确要求输出格式，如“请用Markdown格式输出”、“请分点列出”、“请包含以下章节：1. 概述 2. 分析 3. 建议”。这能让最终汇总更规整。

5.3 成本与性能优化

1. Token消耗监控每次运行结束后，查看ao-output/xxx/metadata.json文件，里面有详细的totalTokens统计（输入和输出）。这有助于你了解不同任务、不同模型的成本。

• 发现某个步骤消耗巨大：检查其task是否输入了过长的文本，或模型输出了冗余内容。尝试优化提示词，要求回答更简洁。
• 对比模型成本：用同样的工作流跑不同的provider，对比token消耗和结果质量，找到性价比最高的组合。

2. 并发数 (concurrency) 调整默认并发数是2。如果你的机器性能好、网络稳定，且LLM提供商允许较高并发，可以适当调高concurrency来加速整体流程。但要注意：

• 过高的并发可能导致LLM提供商速率限制（Rate Limit），引发大量错误。
• 某些免费CLI工具（如gemini-cli）并发能力很弱，建议保持为1。
• 对于有严格顺序依赖的步骤，提高并发数无益。

3. 模型混合使用你可以在不同步骤指定不同的模型，实现性价比最优。

steps: - id: brainstorm role: “product/product-manager” task: “进行头脑风暴，列出10个功能点子” output: ideas llm: # 步骤级覆盖全局LLM设置 provider: “gemini-cli” # 用免费的Gemini做发散思考 model: “gemini-2.0-flash” - id: feasibility_check role: “engineering/engineering-software-architect” task: “评估这些点子的技术可行性：{{ideas}}” output: tech_assessment depends_on: [brainstorm] # 不指定llm，则使用全局的claude-code进行严谨评估

通过YAML的步骤级llm配置，可以让创意阶段用便宜/快速的模型，关键评审阶段用能力强但贵的模型。

6. 真实场景应用案例拆解

让我们看几个更复杂的、贴近真实工作场景的例子，感受一下agency-orchestrator如何改变工作流。

6.1 案例：从零开始策划一个AI产品发布会

需求：你要为一款新的AI编程助手举办线上发布会，需要策划全流程。传统方式：自己写策划案，或者跟一个AI反复沟通修改，耗时耗力。用 agency-orchestrator：

ao compose “为一款名为‘CodePilot AI’的新一代AI编程助手策划一场线上产品发布会，目标受众是开发者，预算5万元，时间在下季度初” --run --provider claude-code --output launch-plan

AI团队自动组建与执行：

1. 趋势研究员：分析当前AI编程工具市场趋势和开发者关注点。
2. 产品经理：提炼CodePilot AI的核心卖点和差异化优势。
3. 营销主管与内容创作者：并行工作。营销主管制定整体传播策略、渠道选择和预算分配；内容创作者撰写发布会演讲稿、新闻稿、社交媒体预热文案。
4. 活动策划师：设计发布会具体流程、环节、互动设计。
5. 项目经理：汇总以上所有输出，制定详细的时间线、任务分工和风险预案。

最终产出：在ao-output/launch-plan/summary.md中，你会得到一份完整的发布会策划案，包含市场分析、核心信息、传播计划、活动流程、预算细化和执行时间表。你从一个模糊的想法，到获得一份可执行的方案，只用了不到10分钟和一句命令。

6.2 案例：技术选型与架构评审

需求：新项目需要在AWS的Lambda和App Runner之间做选型。传统方式：查阅文档，自己对比，可能还会发帖询问。用 agency-orchestrator：

# 你可以手动编写这样一个工作流，或者用 compose 生成类似结构 name: “Serverless 服务选型评审” agents_dir: “agency-agents-zh” llm: provider: “claude-code” model: “claude-3-5-sonnet” inputs: - name: project_desc required: true description: “项目描述，包括预期流量、技术栈、成本敏感度等” steps: - id: aws_expert role: “engineering/engineering-cloud-architect” task: “基于以下项目需求，详细对比AWS Lambda和AWS App Runner的优缺点：\n\n{{project_desc}}” output: comparison - id: cost_analyst role: “finance/financial-analyst” task: “根据以下技术对比，估算两种方案在月活10万、100万、1000万场景下的月度成本：\n\n{{comparison}}” output: cost_analysis depends_on: [aws_expert] - id: decision role: “engineering/engineering-engineering-manager” task: “综合技术对比和成本分析，给出明确的选型建议和理由：\n\n{{comparison}}\n\n{{cost_analysis}}” depends_on: [cost_analyst]

运行它，并提供你的项目描述。你会先后得到一份深入的技术对比报告、一份详细的成本测算，以及一份带有明确建议的决策报告。这个过程模拟了一个真实的技术决策会议，汇集了架构师和财务的视角。

6.3 案例：内容创作流水线

需求：运营一个技术博客，每周需要产出一篇高质量长文。用 agency-orchestrator：你可以创建一个自动化流水线。

# 使用内置的 content-pipeline 模板 ao run workflows/content-pipeline.yaml --input topic=“深入理解Node.js事件循环” --input target_audience=“中级JavaScript开发者” --output weekly-blog

这个模板的工作流可能是：

1. 策略师：根据主题和目标受众，确定文章的核心论点、结构和关键词。
2. 创作者：根据策略师的大纲，撰写详细的文章草稿。
3. 技术审查员：审查文章的技术准确性。
4. 编辑：对文章进行润色、优化可读性。
5. 增长黑客：为文章生成社交媒体推广文案和SEO元描述。

整个过程自动化，你只需要提供一个主题，就能获得一篇经过多轮“打磨”的、准备发布的文章草稿。你可以将这个过程设置为每周定时任务，实现内容生产的半自动化。

7. 总结与个人体会

用了agency-orchestrator一段时间后，我最大的感受是：它把多智能体协作从一个“编程框架”变成了一个“生产力工具”。它的设计处处体现着对开发者体验的优化：

• 降低门槛：YAML和“一句话”编排，让没有AI工程背景的人也能立刻用起来。
• 贴近现有工作流：CLI工具、MCP集成，让它能无缝嵌入到开发、写作、策划的现有流程中，而不是要求你改变习惯去适应它。
• 务实的经济模型：支持多种LLM，尤其是7种免API Key的方式，极大地降低了尝试和使用成本。你可以用已有的订阅开始玩，用免费的额度做实验，用低成本的API处理生产任务。
• 结果导向：所有的设计都指向一个目标——快速产出高质量、结构化的结果。--resume、内置模板、丰富的角色库，都是为了缩短从想法到成果的路径。

当然，它也不是银弹。复杂的业务逻辑、需要深度交互和工具调用的场景，可能还是需要LangChain、CrewAI这样的重型框架。但对于占日常工作中80%的那些分析、规划、创作、评审类任务，agency-orchestrator提供了一个极其高效的解决方案。

我个人最常用的场景有三个：一是快速进行技术方案的可行性分析和初版设计；二是撰写需要多角度思考的文档，比如项目提案、复盘报告；三是作为“第二意见”，在我做出某个决策（比如技术选型、产品功能优先级）后，用不同的AI角色组合再跑一次，查漏补缺。

最后一个小建议：开始用时，多尝试ao compose，感受AI自动编排的智能；熟练后，多研究内置模板和自定义工作流，把它固化到你重复性最高的工作中去。这个工具的价值，会随着你使用深度的增加而指数级增长。