Hierarchical Multi Agents rfc #29
Conversation
|
@xuechendi OPEA Agent RFC was created: #26. Suggest taking that as the base and add your improvements. @ftian1 |
Signed-off-by: Chendi Xue <chendi.xue@intel.com>
|
@ftian1 @minmin-intel @XuhuiRen, I have move all content from 'WORD' version RFC to this PR. |
|
|
||
| configuration: | ||
| ``` | ||
| strategy: choices([react, planexec, humanInLoopPlanExec]) |
There was a problem hiding this comment.
what is the difference between these stratety choices?
There was a problem hiding this comment.
options here are common strategies for Agent, and we will add more strategies in future.
here are some high-level explaination for each strategy
react: https://react-lm.github.io/
plan_exec: https://langchain-ai.github.io/langgraph/tutorials/plan-and-execute/plan-and-execute/
human_in_the_loop: https://langchain-ai.github.io/langgraph/how-tos/human_in_the_loop/breakpoints/
| llm_endpoint_url: str | ||
| llm_engine: choices([tgi, vllm, openai]) | ||
| llm_model_id: str | ||
| recursion_limit: int |
There was a problem hiding this comment.
any description for these fields? Better we have some schema definition for the configurations.
There was a problem hiding this comment.
Good suggestion, I think we can add term explaination in actual codes readme / template configuration yaml.
'recursion_limit' is not a must_to_provide argument, default will be 5. This keyword is used to ask agent to break after several tests. For example:
If we asked agent to get today's intel stock price but not providing right tools, agent will not get the exact answer and fall into a dead loop, in which the Agent will try to fix its prompt and plan back and forth). By adding 'recursion_limit', if one agent can't get answer after 'recursion_limit' times of tests, agent will direct return to user with no answer.
|
|
||
| #### Part3.1 Hierarchical Multi Agents | ||
| __Example 1__: ‘Single Agent megaservice’ | ||
| Only 1 agent is presented in this configuration. |
There was a problem hiding this comment.
Is this Agent configuration written by developer or auto-generated? Can it be adjusted on the fly?
There was a problem hiding this comment.
The 'opea_micro_service' and 'opea_mega_service' configuration should be prepared by enterprise devops team. For docker-based side, ip and port should be provided. For GMC/k8s side, we should leverage a python script to obtain domain_name:port from k8s.
The 'tool' yaml should be generated by enterprise developer according to their company tools/available APIs, and then end_user should be able to cherry-pick some tools from the tool store.
There was a problem hiding this comment.
Is this Agent configuration written by developer or auto-generated? Can it be adjusted on the fly?
Yes, tools will also be adjusted on the fly. There is keyword -> 'tools' in ChatCompletion or Assistants to call out which tools will be used
No description provided.