用 goose Subrecipes 编排复杂 AI 工作流多模型任务编排、并行执行与可复用配方实战【免费下载链接】goosean open source, extensible AI agent that goes beyond code suggestions - install, execute, edit, and test with any LLM项目地址: https://gitcode.com/GitHub_Trending/goose3/gooseSubrecipes子配方是 goose 中「让配方调用配方」的机制主配方main recipe在sub_recipes字段中注册若干子配方由 AI 智能体按需调度每个子配方可以在独立会话中用各自最优的模型与指令完成专项任务。本文基于 goose 仓库中 2025-09-15-subrecipes-in-goose 博客、Subrecipes 官方指南与并行执行教程结合仓库源码与测试脚本完整讲解子配方的 YAML 结构、参数传递、并行/顺序调度策略与调试方法。读完你将能够把一个复杂任务拆解为多个专项配方再用一个父配方把它们编排成可复用的自动化流水线。Subrecipes 是什么从单一配方到配方编排如果你刚开始下厨多半从炒蛋、烤面包这类单一配方起步想做出整顿大餐时就需要同时协调多道菜。goose 的 Subrecipes 就是这个逻辑每个配方既可以独立运行完成专项任务也可以被另一个配方在运行时调用、组成更复杂的流水线。官方文档给出的价值很明确多步骤工作流Multi-step workflows把复杂任务拆成多个不同阶段每个阶段注入对应的专家提示词与模型可复用组件Reusable components把高频出现的通用任务做成可跨工作流复用的独立配方。在源码层面sub_recipes是主配方结构体上一个可选的字段。以 crates/goose/src/recipe/mod.rs 为例Recipe中pub sub_recipes: OptionVecSubRecipe每个SubRecipe至少携带name子配方的唯一标识用于生成可被主配方调用的工具名path指向子配方 YAML 文件的路径相对或绝对路径均可description描述该子配方的职责供模型理解何时调用values可选预置的参数值运行时总会传给子配方sequential_when_repeated可选布尔置为true时强制同一子配方的多次实例串行执行。一个值得注意的实现细节是凡是声明了sub_recipes的配方解析时都会自动注入summon平台扩展见 recipe/mod.rs 中的 ensure_summon_for_subrecipes因此在extensions里无需手动罗列主配方就天然拥有delegate工具来调度子配方。真正执行调用的核心位于 crates/goose/src/agents/platform_extensions/summon.rs该文件实现了SummonClient以及delegate(source: 子配方名, ...)的调用入口。每个子配方运行在独立且相互隔离的会话中它不共享主配方或其他子配方的对话历史、记忆与状态同时子配方不能再声明自己的子配方不支持嵌套。这种隔离一方面保证并行时的安全边界另一方面也提醒我们子配方必须自包含——所有必要信息都要通过参数显式传入。一个完整实战自动搭建完整项目博客作者以一个「项目初始化自动化系统」为例一次性创建带文档、Logo 与初始代码库的完整项目。关键设计是——不写一个臃肿的「万能」大配方而是拆成专项小配方再统一编排。父配方编排三个子配方version: 1.0.0 title: Complete Project Setup description: Creates a full project with README, image, and code using specialized models instructions: | You are a project orchestrator. Execute the subrecipes to create a complete project setup. Each subrecipe is specialized for its task and uses the optimal model and instructions for that work. EXECUTION ORDER: - Run image-creator and code-writer first, in parallel - When they both succeed and finish, then run readme-generator; dont make the readme until we have a logo and finished code project to reference prompt: | Create a complete project setup for: {{ project_name }} within ./project Execute these tasks: - Create a project logo/image - Write the initial codebase - Generate project documentation Project details: - Name: {{ project_name }} - Language: {{ language }} - Description: {{ description }} parameters: - key: project_name input_type: string requirement: required description: Name of the project to create - key: language input_type: string requirement: optional description: Programming language to use default: python - key: description input_type: string requirement: required description: Project description sub_recipes: - name: image-creator path: {{ recipe_dir }}/2-image.yaml description: Create project logo using GPT values: project_name: {{ project_name }} description: {{ description }} - name: code-writer path: {{ recipe_dir }}/3-code.yaml description: Write initial code using Claude values: project_name: {{ project_name }} language: {{ language }} description: {{ description }} - name: readme-generator path: {{ recipe_dir }}/1-readme.yaml description: Generate comprehensive README using Gemini sequential_when_repeated: true values: project_name: {{ project_name }} description: {{ description }} language: {{ language }} extensions: - type: builtin name: developer这个父配方值得留意几个细节参数按需分发每个子配方在values中只拿到自己需要的参数。父配方的{{ project_name }}、{{ language }}、{{ description }}会通过模板语法注入到子配方的values中。执行顺序写在提示词里默认情况下不同子配方是串行执行的除非你在提示词里明确要求并行。这里的instructions明确声明 image-creator 与 code-writer 先并行、两者都成功后 readme-generator 才运行从而让 README 能引用已生成好的 Logo 与代码。sequential_when_repeated: true对 readme-generator 做了一重保险——即使它被重复触发也强制按顺序执行避免 README 覆盖竞争。三个专项子配方让每种模型做最擅长的事子配方的核心价值是「把任务交给最合适的模型」。下面三个子配方分别用 OpenAI DALL-E 画 Logo、用 Claude 写代码、用 Gemini 写文档且各自的temperature与指令风格都针对任务做了调优。子配方 1图像生成OpenAI DALL-Etemperature 0.1version: 1.0.0 title: Project Image Creator description: Generate project logos and images settings: goose_provider: databricks goose_model: goose-claude-4-sonnet temperature: 0.1 instructions: | You are a creative designer specializing in logo and image creation. Create visually appealing, professional images that represent the projects purpose. Generate images using OpenAIs DALL-E API activities: - Generate images using DALL-E API - Save images to specified locations - Handle API errors gracefully prompt: | Create a project logo/image for {{ project_name }} - {{ description }}. Your working folder is {{recipe_dir}}/project/ Task: Generate an image using OpenAIs DALL-E API directly via Python script. Image specifications: - Size: 1024x1024 - Quality: standard - Output file: logo.png - Modern, professional design suitable for a tech API - Include themed elements based on project description: {{ description}} - Professional color scheme - High quality and suitable for documentation Steps: 1. First, verify the OPENAI_API_KEY environment variable is set 2. Create a Python script: - the filename should be ./project/logo_generator.py, create that file and edit it in place - it should calls OpenAIs DALL-E API directly to generate an image - the output folder to store the image is the same folder in which the logo_generator.py script exists - for example, the final image should be ./project/logo.png but not have the ./project path hard-coded in the script 3. Execute the script to generate the image with the specified parameters 4. Verify the image was created successfully and report the file location 5. If there are any errors, provide clear troubleshooting guidance Implementation approach: - Use the developer extension to create and run a Python script - The script should use only standard library modules (urllib, json, base64) to avoid dependency issues - Call OpenAIs DALL-E 3 API directly with proper authentication - Handle API responses and save the base64-encoded image to the specified location - Provide detailed error messages for troubleshooting Requirements: - The OPENAI_API_KEY environment variable must be set - Handle any API errors gracefully and provide helpful error messages retry: max_retries: 3 checks: - type: shell command: test -f {{recipe_dir}}/project/logo_generator.py - type: shell command: test -f {{recipe_dir}}/project/logo.png on_failure: rm -f {{recipe_dir}}/project/logo.png rm -rf {{recipe_dir}}/project/logo_generator.py timeout_seconds: 60 extensions: - type: builtin name: developer parameters: - key: project_name input_type: string requirement: required description: Project name for the logo - key: description input_type: string requirement: required description: What the project is about这个子配方演示了几类进阶能力settings覆盖模型选择子配方可以自行指定goose_provider、goose_model与temperature这是「多模型编排」的实现基础activities用自然语言显式声明本配方要完成的活动清单帮助模型聚焦任务边界retry为容易失败的 API/文件操作增加重试与清理逻辑——checks用 shell 命令验证产出物是否真实存在on_failure在失败时清理半成品文件timeout_seconds: 60限定单次超时。如果想换成「更有创造力的图像生成」只需替换settings为图像 MCP 服务器 创意调优过的模型即可例如settings: goose_provider: openai goose_model: gpt-4o temperature: 0.8子配方 2代码生成Claude Sonnettemperature 0.1version: 1.0.0 title: Code Generator description: Write initial project codebase settings: goose_provider: anthropic goose_model: claude-sonnet-4 temperature: 0.1 instructions: | You are a senior software engineer who writes clean, well-documented, and maintainable code. Follow best practices and include comprehensive error handling and documentation. prompt: | Write the initial codebase for {{ project_name }}. Your project folder will be ./project/ Requirements: - Language: {{ language }} - Description: {{ description }} - Include proper project structure - Include error handling - Follow language-specific best practices - Add unit tests where appropriate Documentation: - Add comprehensive documentation in a file called USAGE.md - do not create a README.md file extensions: - type: builtin name: developer parameters: - key: project_name input_type: string requirement: required description: Project name - key: language input_type: string requirement: required default: python description: Programming language - key: description input_type: string requirement: required description: Project description写代码追求的是「可靠与规范」所以这里把 temperature 压到 0.1减少随机性同时在 prompt 中明确要求单元测试、错误处理并且约定「只写 USAGE.md、不要创建 README.md」——把文档职责明确剥离给第三个子配方避免多配方之间争抢同一文件。子配方 3README 生成Geminitemperature 0.5version: 1.0.0 title: README Generator description: Generate comprehensive project documentation settings: goose_provider: google goose_model: gemini-2.5-flash temperature: 0.5 instructions: | You are a technical documentation specialist. Create comprehensive, well-structured README files that are informative, professional, and follow best practices. prompt: | Create a comprehensive README.md file for the project {{ project_name }}. Project details: - Name: {{ project_name }} - Language: {{ language }} - Description: {{ description }} Include sections for: - Project overview and features with lots of excitement over the capabilities of the project - Installation instructions - Usage examples the code and logo for this project will be in ./project; include the logo.png at the top of the readme, and instructions on running the code in the readme. the readme file should be placed in ./project/ extensions: - type: builtin name: developer parameters: - key: project_name input_type: string requirement: required description: Project name - key: language input_type: string requirement: required description: Programming language - key: description input_type: string requirement: required description: Project description由于 readme-generator 会在前两个子配方完成后才运行其 prompt 直接约定「把 logo.png 放在 README 顶部、包含运行说明」充分利用了上游产物。三个子配方与父配方的模型分配可以汇总为下表均来自上方 YAML 的settings实际模型名以你配置的 provider 为准配方专项职责provider / 模型示例temperature执行阶段image-creator生成 Logo/图片databricks goose-claude-4-sonnet调 DALL-E API0.1第一批与 code-writer 并行code-writer编写初始代码库anthropic claude-sonnet-40.1第一批与 image-creator 并行readme-generator生成完整 READMEgoogle gemini-2.5-flash0.5第二批前两者成功后并行与顺序Subrecipes 的执行模式选择在上述例子里我们靠提示词控制顺序。事实上 goose 对执行模式有一套明确的默认规则详见仓库文档 Running Subrecipes In Parallel。需要注意并行执行是官方标注的实验性特性行为与配置在后续版本中可能变化。官方文档给出的决策表如下场景默认行为覆盖方式不同子配方顺序执行在 prompt 中写「in parallel」同一子配方、不同参数并行执行设置sequential_when_repeated: true或在 prompt 中写「sequentially」对应到内部机制并行子配方执行使用隔离的 worker 系统自动管理并发任务——goose 为每个子配方实例创建独立 task并把它们分发到最多 10 个并发 worker上执行。当你运行多个并行任务时CLI 会实时显示进度看板包含已完成/运行中/失败/待处理的任务计数以及任务 ID、参数集、耗时、输出预览和错误信息任务状态从 Pending → Running → Completed/Failed 全程可视。不同子配方并行在 prompt 中直接声明同一父配方想并行调用两个不同子配方时在 prompt 里写清楚即可以下为旅行规划示例的父配方节选自并行教程# plan_trip.yaml version: 1.0.0 title: Plan Your Trip description: Get weather forecast and find things to do for your destination instructions: You are a travel planning assistant that helps users prepare for their trips. prompt: | run the following subrecipes in parallel to plan my trip: - use weather subrecipe to get the weather forecast for Sydney - use things-to-do subrecipe to find activities and attractions in Sydney sub_recipes: - name: weather path: ./subrecipes/weather.yaml values: city: Sydney - name: things-to-do path: ./subrecipes/things-to-do.yaml values: city: Sydney duration: 3 days extensions: - type: builtin name: developer timeout: 300 bundled: true同一子配方多次并行参数由上下文推断如果 prompt 暗示要对同一个子配方执行多次goose 会自动为每次创建并行实例。例如下例只声明一次weather子配方但 prompt 里的「澳洲三大城市」会让模型自动生成三个并行任务# multi_city_weather.yaml version: 1.0.0 title: Multi-City Weather Comparison description: Compare weather across multiple cities for trip planning instructions: You are a travel weather specialist helping users compare conditions across cities. prompt: | get the weather forecast for the three biggest cities in Australia to help me decide where to visit sub_recipes: - name: weather path: ./subrecipes/weather.yaml extensions: - type: builtin name: developer timeout: 300 bundled: true底层的weather子配方只需要声明自己所需的city参数即可# subrecipes/weather.yaml version: 1.0.0 title: Find weather description: Get weather data for a city instructions: You are a weather expert. You will be given a city and you will need to return the weather data for that city. prompt: | Get the weather forecast for {{ city }} for today and the next few days. parameters: - key: city input_type: string requirement: required description: city name extensions: - type: stdio name: weather cmd: uvx args: - mcp_weatherlatest timeout: 300如果你希望它串行执行直接告诉 goose 即可prompt: | get the weather for three biggest cities in Australia one at a time什么时候该顺序、什么时候该并行并行并不总是更好官方文档给出了清晰的取舍建议适合顺序执行的情况多个任务会修改共享资源如写同一个文件避免覆盖竞争执行顺序本身有意义后一步依赖前一步的输出例如上文 README 必须等 Logo 与代码就绪存在内存或 CPU 资源约束并行模式下排障复杂需要缩小范围逐步定位。适合并行执行的情况任务之间互相独立、无数据依赖期望更快的整体完成时间系统资源足以支撑并发最多约 10 个 worker需要批量处理大数据集或多个文件。对于绝不允许并行的子配方请在配方级配置sequential_when_repeated: true一票否决即使模型在 prompt 中暗示多次执行也强制顺序sub_recipes: - name: database-migration path: ./subrecipes/migrate.yaml sequential_when_repeated: true # Always sequential这正是项目搭建示例中对 readme-generator 使用该标记的原因——文档生成写入的是共享的./project目录串行可以避免与其它任务产生写冲突。仓库中的自动化测试 test_subrecipes.sh 正是针对同一份父配方的串行与并行两个变体project_analyzer.yaml 与 project_analyzer_parallel.yaml做回归验证通过检查输出中是否出现delegate工具调用及两个子配方file_stats、code_patterns的source标记来确认调度正确可作为你本地验证子配方行为的参考模板。参数传递values 预置与上下文推断子配方收到的参数可以来自两个渠道官方文档 Subrecipes 指南 中明确了两者的优先级与行为预置值values父配方在sub_recipes条目中固定的参数值运行时自动提供且不能被运行时覆盖上下文推断参数AI 从对话上下文包括之前子配方的输出中提取参数值。关键规则预置值的优先级高于上下文推断。若对话上下文与values同时提供了同一参数最终以values为准。看一个上下文传递的经典例子——旅行规划器。第一个子配方weather_data只声明参数location而父配方 prompt 只是笼统地说 Plan activities for Sydney...模型会从自然语言中抽出 Sydney 作为location# travel-planner.yaml节选完整版见 Subrecipes 指南 version: 1.0.0 title: Travel Activity Planner description: Get weather data and suggest appropriate activities instructions: | Plan activities by first getting weather data, then suggesting activities based on conditions. prompt: | Plan activities for Sydney by first getting weather data, then suggesting activities based on the weather conditions we receive. sub_recipes: - name: weather_data path: ./subrecipes/weather-data.yaml # No values - location parameter comes from prompt context - name: activity_suggestions path: ./subrecipes/activity-suggestions.yaml # weather_conditions parameter comes from conversation context而第二个子配方activity_suggestions声明的weather_conditions来自上一子配方的结果——模型会把weather_data返回的天气写进对话上下文再据此推断第二个子配方需要填入的天气参数实现子配方之间的结果接力。注意parameters中input_type: string的字段值都可以用{{ parameter_name }}模板语法注入到 prompt 与 instructions 中。若需要把多行文本参数传给子配方请使用indent()过滤器保持 YAML 格式合法例如{{ content | indent(2) }}。三个高频编排模式除了上面展示的「并行 结果接力」官方指南还给出了两种值得借鉴的模式顺序处理的流水线模式Code Review Pipeline父配方声明security_scan与quality_check两个子配方并在 instructions 中明确「先安全分析、再质量分析」同时用values把scan_level预置为comprehensivegoose run --recipe code-review-pipeline.yaml --params repository_path/path/to/repo条件分发的决策模式Smart Project Analyzer父配方先自行勘察仓库、判断项目类型再只调用其中一个子配方Web 应用走web_security_auditCLI/库走api_documentation。子配方的 prompt 中还可以用 Jinja 条件语法做细粒度开关例如{% if check_cors true %}Check CORS configuration...{% endif %}——适合把可选检查项做成布尔参数由values预置或运行时传入。控制子配方的执行上限每个子配方可以通过自己的settings.max_turns限制执行轮数未指定时继承父配方的max_turns# subrecipes/quick-scan.yaml version: 1.0.0 title: Quick Security Scan settings: max_turns: 10 # Limit this subrecipe to 10 turns instructions: Perform a quick security scan prompt: Scan for common vulnerabilities调试 Subrecipes 的五个实用建议结合博客原文与官方指南调试子配方工作流最有效的方法如下1. 先保证每个子配方能独立运行这是最关键的纪律。每个子配方必须单独跑通再谈组合。若一个子配方单独运行就失败放进更大的工作流只会更糟。调试时用goose run --recipe逐个验证# Test each subrecipe individually first goose run --recipe 1-readme.yaml --params project_nametest languagepython descriptiontest project goose run --recipe 2-image.yaml --params project_nametest descriptiontest project goose run --recipe 3-code.yaml --params project_nametest languagepython descriptiontest project2. 相对路径一律使用{{ recipe_dir }}在配方内引用文件路径时始终使用{{ recipe_dir }}它指向配方文件所在目录这样配方才能被复制到任意位置运行而不会因当前工作目录不同而失效。上面所有示例中path: {{ recipe_dir }}/2-image.yaml、{{recipe_dir}}/project/logo.png的做法都遵循此原则。3. 参数校验要做好为每个参数写清晰准确的description并把必填参数标记为requirement: required。这样即便调用方漏传某个值模型也能依据描述自行判断或尽早报错而不是在流程深处出现莫名其妙的失败。4. 为不稳定操作添加重试与清理网络调用、文件操作、第三方 API 都可能闪断。官方推荐的模板是为它们加上retry并用 shellchecks验证真实产物、用on_failure清理残留retry: max_retries: 3 checks: - type: shell command: test -f expected_output.txt on_failure: rm -f partial_output.txt timeout_seconds: 605. 关注资源与限流并行运行多个子配方时要注意 API 速率限制与系统资源占用。对资源密集型的任务必要时改用顺序执行或调低并行实例数量系统上限约 10 个并发 worker。官方推荐的子配方最佳实践还包括每个子配方只承担单一职责参数命名清晰并附描述把不变的值用values预置而非每次都让模型推断。设计你自己的子配方工作流从哪里开始开始不必复杂。挑一个你经常做的复杂任务拆成 2–3 个小块为每块单独写配方、单独测试最后用一个父配方编排。可参考的方向内容创作流水线调研、写作、编辑、排版各成一个配方开发工作流代码生成、测试、文档、部署分阶段推进数据处理管线采集、清洗、分析、可视化项目初始化目录结构、配置、初始文件、文档。更深一层看Subrecipes 代表着一种 AI 协作范式的转变不再是「一个万能单体模型包办一切」而是一批各司其职的专项智能体围绕共同目标协同。每个配方都成为可混搭复用的组件——先构建自己的专项配方库再针对不同项目自由组合。仓库内还保留了可直接翻阅的真实参考官方示例子配方位于 scripts/test-subrecipes-examples含 project_analyzer 与 subrecipes 目录端到端验证脚本是 scripts/test_subrecipes.sh此外 workflow_recipes/release_risk_check/recipe.yaml 是仓库中随附的完整业务配方示例。Subrecipes 目前是实验性特性运行前建议确认当前 goose 版本的对应说明此外该博客作为历史资料被保留社区 Recipe Cookbook 已停止接收新的配方投稿但你仍然可以浏览其中沉淀的配方作为设计参考。【免费下载链接】goosean open source, extensible AI agent that goes beyond code suggestions - install, execute, edit, and test with any LLM项目地址: https://gitcode.com/GitHub_Trending/goose3/goose创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考