-
Notifications
You must be signed in to change notification settings - Fork 6.4k
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
Add code generation support to CodeExecutorAgent
#6098
base: main
Are you sure you want to change the base?
Add code generation support to CodeExecutorAgent
#6098
Conversation
Signed-off-by: Abhijeetsingh Meena <abhijeet040403@gmail.com>
Hi @ekzhu, I’ve pushed an initial draft PR with the basic LLM inference functionality implemented. The code is still in a rough state as I didn’t have much time to polish it today, but I’ll be refining it further in the coming iterations. |
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.
Thanks! it is in the right direction.
python/packages/autogen-agentchat/src/autogen_agentchat/agents/_code_executor_agent.py
Outdated
Show resolved
Hide resolved
python/packages/autogen-agentchat/src/autogen_agentchat/agents/_code_executor_agent.py
Outdated
Show resolved
Hide resolved
- `model_client` is now optional. When not provided, the code executor will execute other agent code from chat messages. - If `model_client` is provided, only the code suggested by the executor will be executed and the output will be returned right after the Code Generation. Signed-off-by: Abhijeetsingh Meena <abhijeet040403@gmail.com>
Changed the default system message from a generic AI assistant system message to one that explicitly defines the agent’s role in generating and executing python code with a focus on correctness and efficiency. Signed-off-by: Abhijeetsingh Meena <abhijeet040403@gmail.com>
python/packages/autogen-agentchat/src/autogen_agentchat/agents/_code_executor_agent.py
Outdated
Show resolved
Hide resolved
python/packages/autogen-agentchat/src/autogen_agentchat/agents/_code_executor_agent.py
Outdated
Show resolved
Hide resolved
python/packages/autogen-agentchat/src/autogen_agentchat/agents/_code_executor_agent.py
Outdated
Show resolved
Hide resolved
- Added default terminal and agent descriptions. - Updated description handling to assign dynamically if None. - Moved default system_message to a constant Signed-off-by: Abhijeetsingh Meena <abhijeet040403@gmail.com>
…` methods for `ChatMessage` objects Signed-off-by: Abhijeetsingh Meena <abhijeet040403@gmail.com>
Signed-off-by: Abhijeetsingh Meena <abhijeet040403@gmail.com>
…ck that tests `model_client` Signed-off-by: Abhijeetsingh Meena <abhijeet040403@gmail.com>
- Reflection is optional and works when `reflect_on_code_block_results=True`. - Modified `execute_code_block` to return a `TextMessage` for better control over the reflection workflow. - When reflection is disabled, the execution result will be wrapped in a `Response` object and yielded. - When reflection is enabled, the execution result is yielded as a `TextMessage`, followed by the code execution reflection, which ultimately returns a `Response` object, terminating the routine. Signed-off-by: Abhijeetsingh Meena <abhijeet040403@gmail.com>
Hi @ekzhu, I’ve implemented a prototype baseline for the reflection feature, completing the reasoning, execution, and reflection pipeline. Please let me know your thoughts — I’d appreciate any suggestions! |
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 think this looks pretty good.
Could you update the API docs with two usage examples to show different scenarios. One without model client and one with model client. Include the output for each in the doc as well.
python/packages/autogen-agentchat/src/autogen_agentchat/agents/_code_executor_agent.py
Outdated
Show resolved
Hide resolved
python/packages/autogen-agentchat/src/autogen_agentchat/agents/_code_executor_agent.py
Outdated
Show resolved
Hide resolved
Signed-off-by: Abhijeetsingh Meena <abhijeet040403@gmail.com>
Signed-off-by: Abhijeetsingh Meena <abhijeet040403@gmail.com>
- Expanded the docstrings in the `CodeExecutorAgent` class to cover new features, including configuration examples with and without a model client. - Updated class description and parameters to reflect recent additions. Signed-off-by: Abhijeetsingh Meena <abhijeet040403@gmail.com>
Done! Commit: 9fd093e Added API Docs for both the scenarios. |
python/packages/autogen-agentchat/src/autogen_agentchat/agents/_code_executor_agent.py
Outdated
Show resolved
Hide resolved
I rebased this PR to the latest changes in the main branch. I also made a small change to the default setting of |
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 think we can move this PR out of Draft stage now.
python/packages/autogen-agentchat/src/autogen_agentchat/agents/_code_executor_agent.py
Outdated
Show resolved
Hide resolved
Hi @ekzhu, Apologies for the oversight. I missed updating that section of the API documentation and forgot to account for the fact that with this approach, the system_message can never be None. |
…n result in model context Signed-off-by: Abhijeetsingh Meena <abhijeet040403@gmail.com>
…D_MESSAGE constant Signed-off-by: Abhijeetsingh Meena <abhijeet040403@gmail.com>
cb78371
to
2f874ef
Compare
CodeExecutorAgent
CodeExecutorAgent
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 have played with this setup for a number of tasks. I think there are some immediate next steps:
- New message types
CodeGenerationEvent
,CodeExecutionEvent
instead of theTextMessage
used for inner messages. Introduce additional fields likeCodeGenerationEvent.code_blocks
,CodeExecutionEvent.result
. Seeautogen_agentchat.messges
. - Automatic debugging loop until code result is not an error.
let me know if you want to work on these as separate PRs or keep iterating on this one for now.
I see the tests are still broken.
- Replaced the usage of `TextMessage` with new message types `CodeGenerationEvent` and `CodeExecutionEvent` for yielding code generation and execution results. - Updated `execute_code_block` method to return `CodeExecutionEvent` instead of `TextMessage`. - Adjusted message factory to register and support the new event types. Signed-off-by: Abhijeetsingh Meena <abhijeet040403@gmail.com>
Hi @ekzhu, Thanks for the suggestions! I’ve pushed a new commit that introduces Now, the inner messages are yielded as Regarding the automatic debugging loop to handle errors in code results, I find this feature really interesting and would love to work on it. I’m happy to create a separate PR for that one. As for the broken tests, I will prioritize fixing them as soon as I have some time. Let me know if you have any feedback on the recent commit! |
def to_model_text(self) -> str: | ||
return self.content | ||
|
||
def to_model_message(self) -> AssistantMessage: |
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.
Let's not include to_model_text
and to_model_message
in the CodeExecutionEvent
and CodeGenerationEvent
. As these are events for observability and termination purpose. Only BaseChatMessage
are going to other agents' model context.
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.
|
||
type: Literal["CodeGenerationEvent"] = "CodeGenerationEvent" | ||
|
||
def get_code_blocks(self) -> List[CodeBlock]: |
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.
get_code_blocks
and _extract_markdown_code_blocks
should stay in CodeExecutionAgent
.
Instead, it should include a field code_blocks: List[CodeBlock]
which gets assigned by the CodeExecutionAgent
.
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.
Done!
Removed get_code_blocks
and _extract_markdown_code_blocks
from CodeExecutorAgent
.
And code_blocks
attributes is filled from CodeExecutorAgent
.
class CodeExecutionEvent(BaseAgentEvent): | ||
type: Literal["CodeExecutionEvent"] = "CodeExecutionEvent" | ||
result: str | ||
|
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.
the result field should be CodeResult
type:
result: CodeResult
.
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.
Done!
I have a few doubts to confirm for this commit:
- I am utilizing
code_execution.result.output
attribute to add execution result to model_context, because it was not acceptingCodeExecutionEvent
. Is it correct? - Still yielding execution result as
TextMessage
. - Is returning
exit_code=-1
valid when there is not code blocks in generation.
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 am utilizing code_execution.result.output attribute to add execution result to model_context, because it was not accepting CodeExecutionEvent. Is it correct?
Yes.
Still yielding execution result as TextMessage.
The final Response
still contains the TextMessage
. Intermediate execution result should be yielded as CodeExecutionEvent
.
Is returning exit_code=-1 valid when there is not code blocks in generation.
No. If there is no code in the generation, there shouldn't be CodeGenerationEvent
or CodeExecutionEvent
-- it should go straight to final Response
.
Great, created a separate issue: #6207. You can comment on that issue. |
…ationEvent` and `CodeExecutionEvent` Signed-off-by: Abhijeetsingh Meena <abhijeet040403@gmail.com>
- Removed `get_code_blocks` and `_extract_markdown_code_blocks` methods from `CodeGenerationEvent`. - Added a new field `code_blocks: List[CodeBlock]` to CodeGenerationEvent. - Updated `CodeExecutionAgent` to assign `code_blocks` directly to the `CodeGenerationEvent`. Signed-off-by: Abhijeetsingh Meena <abhijeet040403@gmail.com>
- Refactored `CodeExecutionEvent` to use `CodeResult` instead of a string for the `result` field. - Updated handling of code execution results in `on_messages_stream` and `execute_code_block` to ensure proper usage of `CodeResult`. Signed-off-by: Abhijeetsingh Meena <abhijeet040403@gmail.com>
python/packages/autogen-agentchat/src/autogen_agentchat/agents/_code_executor_agent.py
Outdated
Show resolved
Hide resolved
) | ||
|
||
# execute generated code if present | ||
execution_result = await self.execute_code_block([inferred_text_message], cancellation_token) |
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.
Let's yield the CodeGenerationEvent before the code execution. This way the event is more realtime.
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.
Done!
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 there is no code in the generation, we shouldn't be emitting CodeGenerationEvent
, it should go straight to final response.
So we will need to sepearate code extraction from code execution.
…onEvent instead of TextMessage Signed-off-by: Abhijeetsingh Meena <abhijeet040403@gmail.com>
) | ||
|
||
# execute generated code if present | ||
execution_result = await self.execute_code_block([inferred_text_message], cancellation_token) |
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 there is no code in the generation, we shouldn't be emitting CodeGenerationEvent
, it should go straight to final response.
So we will need to sepearate code extraction from code execution.
class CodeExecutionEvent(BaseAgentEvent): | ||
type: Literal["CodeExecutionEvent"] = "CodeExecutionEvent" | ||
result: str | ||
|
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 am utilizing code_execution.result.output attribute to add execution result to model_context, because it was not accepting CodeExecutionEvent. Is it correct?
Yes.
Still yielding execution result as TextMessage.
The final Response
still contains the TextMessage
. Intermediate execution result should be yielded as CodeExecutionEvent
.
Is returning exit_code=-1 valid when there is not code blocks in generation.
No. If there is no code in the generation, there shouldn't be CodeGenerationEvent
or CodeExecutionEvent
-- it should go straight to final Response
.
Why are these changes needed?
CodeExecutorAgent
.Related issue number
Closes #5824
Checks