-
Notifications
You must be signed in to change notification settings - Fork 2.6k
feat: created sub recipe tools #2982
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
| } | ||
| } | ||
|
|
||
| fn parse_recipe_content(content: &str) -> Result<Recipe> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
moved to goose package to be reusable
| pub struct Agent { | ||
| pub(super) provider: Mutex<Option<Arc<dyn Provider>>>, | ||
| pub(super) extension_manager: Mutex<ExtensionManager>, | ||
| pub(super) sub_recipe_manager: Mutex<SubRecipeManager>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I created a sub_recipe_manager to manage sub recipe tools and trigger the sub recipe tool call.
I could also use the extension manager to add these tool, but the extension manager is mainly for MCP. So I create a sub_recipe_manager, maybe later it could evolve to sub_agent_manager
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems great. They are distinct from extensions so I think that makes sense. It also leaves the door open to agents treating sub-recipes differently: instead of shelling out to a new goose, a future version may use the same agent or a new in-process instance
…ram is defined in the main recipe
jamadeo
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very nice! I'll test this out and report back with any findings
| read_only_hint: true, | ||
| destructive_hint: false, | ||
| idempotent_hint: false, | ||
| open_world_hint: false, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we know that open_world is false? should we just leave it out?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good catch! I just used the default, will modify that
| pub struct Agent { | ||
| pub(super) provider: Mutex<Option<Arc<dyn Provider>>>, | ||
| pub(super) extension_manager: Mutex<ExtensionManager>, | ||
| pub(super) sub_recipe_manager: Mutex<SubRecipeManager>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems great. They are distinct from extensions so I think that makes sense. It also leaves the door open to agents treating sub-recipes differently: instead of shelling out to a new goose, a future version may use the same agent or a new in-process instance
|
|
||
| use crate::recipe::{Recipe, RecipeParameter, RecipeParameterRequirement, SubRecipe}; | ||
|
|
||
| pub const SUB_RECIPE_TOOL_NAME_PREFIX: &str = "subrecipe__run_sub_recipe"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure how much it matters, but since the models themselves don't really know what a recipe is, you could probably just use run__{recipe name} or something like that to name the tools
| let stderr_output = stderr_task.await.unwrap(); | ||
|
|
||
| if status.success() { | ||
| Ok(stdout_output) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we should probably also return stderr to the model, right?
| } | ||
|
|
||
| pub fn is_sub_recipe_tool(&self, tool_name: &str) -> bool { | ||
| tool_name.starts_with(SUB_RECIPE_TOOL_NAME_PREFIX) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
here you might as well just test for membership in the map, rather than the prefix
| for sub_recipe in sub_recipes_to_add { | ||
| let sub_recipe_name = sub_recipe.name.clone(); | ||
| let tool = create_sub_recipe_tool(&sub_recipe); | ||
| self.sub_recipe_tools.insert(sub_recipe_name.clone(), tool); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if you instead store them in the map using their prefixed names, it will make them easier to look up in call_sub_recipe_tool() and is_sup_recipe_tool()
* main: Blog: Add video to container use blog (#3008) Use official logo in Goose web (#3012) fix shims for extensions on windows (#3009) fix powershell executions (#3006) Docs linux desktop (#3007) Platform Tool for Scheduler: Allow Goose to Manage Its Own Schedule (#2944) docs: container use blog and guide (#2962) Fix: Workflow syntax (#3002) Added just lint-ui for linting front end code (#2997) fix typo in secret name (#2994) feat(ui): add chain-of-thought panel above assistant messages (#2899) feat(cli): Add `--quiet /-q` flag to goose run (#2939) Feat: Recipe Library (#2946) Docs: Goose on Windows Installation (#2990) Fixes : Workflow error on issue comment (#2958) Add a setting for the quit confirmation dialog (#2901) Update bundle-desktop-windows.yml (#2988) feat: optional fast edit models (#2580) feat: Add lead-worker model selection and real-time model display in GUI (#2964)
* main: fix: Improves reliability of flaky log tests (#3029) Add xAI Test Coverage (#3020) Reorganizing tutorials (#3028) feat(providers): update Google Gemini models to latest available models (#2989) fix(docker): install protoc to fix lance-encoding build (#2995) fix: updated openrouter known models (#3021) Mnovich/temporal foreground tasks (#2895) add 'install in goose' asset (#3016) Added useDarkMode hook for detecting dark mode setting dynamically (#3019) docs: add sagemaker provider (#2980) Docs: Add Goose Recipes Cookbook Page (#2998) feat (cli): add an alias --id for --name param for goose session --resume command (#3018) fix: disable extension (#3000) Add xAI Provider Support for Grok Models (#2976) removing dlls from core bin (#3014) docs: Update Leaderboard in New Community Landing Page (#2954) Douwe/fix include for recipes (#2914)
| } | ||
|
|
||
| #[cfg(test)] | ||
| mod tests { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tests are moved to a separate files
* origin/main: Session file security updates (#3071) feat(ui): Add drag and drop support for opening sessions from finder. (#3070) Mnovich/fix cli permisisons (#3074) copy permission fix for cli (#3073) Update download_cli.sh to support arbitrary Goose versions (#3060) fix(temporal-service): makes the search for possible temporal paths parallel. (#3062) added MCPs menu item (#3066) fix missing dependencies for cli (#3065) feat: created sub recipe tools (#2982) attempt to build CLI native for Windows (#3058) docs: typo - wrong extension id (#3063) fix(docs): teach Goose how to spell “autonomous” 🪿📚 (#3061) feat (cli): list Groq-supported models (#3048) Fix session corruption issues (#3052) feat: update to get vector db path from env var for vector tool strategy (#3042) Fix Linux desktop download links to point to actual desktop versions (#3051) fix temporal build for windows (#3045) fix cron parsing for windows (#3044)
Signed-off-by: Soroosh <soroosh.sarabadani@gmail.com>
What
when running recipe
goose run --recipe...when explaining recipe
goose run --recipe ... --explain1 parse the recipe content with the inheritance, and extract recipe parameters and template variables.
2. validate the params
3. render the recipe with params and inheritance (if not all params are provided, it won't fail)
when validating or creating deep link for recipe
goose recipe deeplink ...,goose receipe validate ...1 . parse the recipe content with the inheritance, and extract recipe parameters and template variables.
2. validate the params
3. ender the recipe with inheritance but without any params