You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I read your pseudocode about workflow, and I found that after receiving a task (AgentMsg), the workflow has two processing methods:
Find a corresponding role to handle the task
All roles process the task separately and combine the results
In reality, many complex tasks need to be completed through division of labor and cooperation, that is, there will be a leader who splits tasks into smaller subtasks and performs them synchronously. This working mode is not found directly in workflow.
After thinking about it, there are roughly two scenarios where tasks need to be split:
Tasks require characters with different skills to complete
Based on the current design, these roles can be constructed in the workflow, and this task can be assigned to all the roles in the workflow to handle it separately. These roles understand and decompose the task, and only deal with the part within their own responsibilities. Finally, each The processing results of roles are combined to become the final result.
A single role has limited capabilities (for LLM, mainly context length?), tasks require many characters with the same skills to complete
Based on the current design, a two-level workflow can be designed. The first level constructs a role and assigns the task to the role. The role understands and splits it into a task list, and delivers the task list to the sub-workflow. The sub-workflow receives the task list. Finally, only the first subtask that has not been completed is processed, and then the status of the subtasks in the task list is modified, and a new sub-workflow is started again until all subtasks in the task list are completed.
For the second scenario, it is a bit like a recursive structure, which is more difficult to understand. If you can directly provide a general split mode, it will be more friendly to developers. If you want to achieve this, you may need to introduce a special role (leader ). The general process is as follows:
if self. leader is not None:
result = await _process_msg(msg, self. leader)
task_list = split_tasks(result);
task_result_list = []
for task in task_list:
msg = result + ". please execute this task:" + task
role = self.input_filter.select(msg)
task_result = await _process_msg(msg, role)
task_result_list += task_result
result = self._merge_msg_result(task_result_list)
chatsession.append_post(result)
In addition, is the process of merging results also an intelligent process of summarization, and does this also require a role to handle?
The text was updated successfully, but these errors were encountered:
I believe we're on the same page. The essence of constructing a team (workflow) composed of AI Agents to decompose complex problems is to confront and solve the enduring fact of the LLM Token Limit. You can see in the current design (src/aios_kernel/workflow.py) that it already includes the process of roles breaking down tasks into sub-workflows and merging them.
I consider this a fundamental requirement, so there's no need to define a role called "Leader" at the base level. However, I also predict that within workflows built on OpenDAN, there will undoubtedly be a frequently used role named "Leader" equipped with a set of sophisticated prompts.
As always, I appreciate your thoughts and feedback on this matter. Let's continue to collaborate to make our project a success.
I read your pseudocode about workflow, and I found that after receiving a task (AgentMsg), the workflow has two processing methods:
In reality, many complex tasks need to be completed through division of labor and cooperation, that is, there will be a leader who splits tasks into smaller subtasks and performs them synchronously. This working mode is not found directly in workflow.
After thinking about it, there are roughly two scenarios where tasks need to be split:
Based on the current design, these roles can be constructed in the workflow, and this task can be assigned to all the roles in the workflow to handle it separately. These roles understand and decompose the task, and only deal with the part within their own responsibilities. Finally, each The processing results of roles are combined to become the final result.
Based on the current design, a two-level workflow can be designed. The first level constructs a role and assigns the task to the role. The role understands and splits it into a task list, and delivers the task list to the sub-workflow. The sub-workflow receives the task list. Finally, only the first subtask that has not been completed is processed, and then the status of the subtasks in the task list is modified, and a new sub-workflow is started again until all subtasks in the task list are completed.
flow chart:
For the second scenario, it is a bit like a recursive structure, which is more difficult to understand. If you can directly provide a general split mode, it will be more friendly to developers. If you want to achieve this, you may need to introduce a special role (leader ). The general process is as follows:
In addition, is the process of merging results also an intelligent process of summarization, and does this also require a role to handle?
The text was updated successfully, but these errors were encountered: