fix proplem in tool call

[liunux4odoo]

• BaseTool.result_as_answer is not applied in agent executor (result_as_answer  #931)
• some platforms raise prompt error as the tool output was append to the assistant message

origin messages in the agent executor._invoke_loop seem like:

System: You are a ... . Your personal goal is ...
User: Current Task ...
Assistant: Action: .... Action Input: ... Observation: {tool's output}

some platforms cannot process these three messages because they limit the last message to be an user or tool message.

So this pr split them to:

System: You are a ... . Your personal goal is ...
User: Current Task ...
Assistant: Action: ...
Tool: Action: .... Action Input: ... Observation: {tool's output}

[joaomdmoura]

This is a review from a crew. I'm testing a crew for PRs, so if it sounds weird that is the reason, you are one of the first ones to see this. :) I'll try to personally look into it as well

Positive Changes

1. Proper Tool Handling: The addition of logic to manage the tool.return_direct flag improves how tool outputs are managed.
2. Fuzzy Matching: The implementation of tool name matching via fuzzy logic bolsters the flexibility of tool selection.
3. Message Role Improvement: The formatting of tool messages has been refined, enhancing clarity in communication.

Specific Code Improvements

1. Optimize Tool Selection Logic:
   The _select_tool method employs string similarity, which can be streamlined. A more efficient fuzzy matching implementation or caching recent results would enhance performance.

   similarity_threshold = 0.85

2. Robust Error Handling:
   While error handling has been introduced, it would benefit from more granularity to capture various failure modes while executing tools.

   except Exception as e:
       self.messages.append({"role": "system", "content": f"Tool execution error: {str(e)}"})

3. Structured Message Formatting:
   The _format_tool_message method could better encapsulate actions and inputs, providing a clearer output structure.

   return {
       "role": "tool",
       "name": formatted_answer.tool,
       "content": {
           "action": formatted_answer.tool,
           "input": formatted_answer.tool_input,
           "observation": formatted_answer.result
       }
   }

4. Type Safety:
   Ensure type hints are added for the result_as_answer property to maintain type safety and clarity.

   @property
   def result_as_answer(self) -> bool:

Links to Historical Context

Given the PR's focus on tool handling, recent changes in adjacent PRs (e.g., PR #1615 and PR #1618) discuss related improvements in error handling and logging. Reviewing those may provide additional context for what can be further improved in tool interactions.

General Recommendations

• Documentation: Enhance inline comments and document the implications of return_direct in the context of tool execution.
• Testing: Implement unit tests specific to the newly introduced fuzzy matching and error handling paths.
• Code Organization: Consider refactoring the _select_tool method into a dedicated ToolSelector class for improved separation of concerns.
• Performance: Evaluate more efficient algorithms for string comparison if tool sets are large.
• Logging: Introduce debug logging, especially around the tool selection process to ease troubleshooting.

Conclusion

These changes will not only elevate the maintainability and reliability of the code but also align with best practices, ensuring smoother future enhancements. Let's keep iterating on these suggestions to further strengthen the CrewAI framework.

[liunux4odoo]

The crew seems to be smart.

[bhancockio]

Hey @liunux4odoo!

I am not fully understanding the issue and solution offered in this PR. Could you please expand upon the original issue and your solution.

For example, I am not sure why you're using the tool role. Do any models support the tool role?

It would also be awesome if you could show a simple demo crew that is working with your PR.

Here's how ChatGPT handles tool calling:
https://platform.openai.com/docs/guides/function-calling

[liunux4odoo]

Hey @liunux4odoo!

I am not fully understanding the issue and solution offered in this PR. Could you please expand upon the original issue and your solution.

For example, I am not sure why you're using the tool role. Do any models support the tool role?

It would also be awesome if you could show a simple demo crew that is working with your PR.

Here's how ChatGPT handles tool calling: https://platform.openai.com/docs/guides/function-calling

The first problem is described in #931
I use crewai with open source LLMs. The conversation must following this format:

[
  ("system", "xxx"), # could be committed
  ("user", "xxx"), # React template with tools
  ("assistant", "xxx"), # Tool call message
  ("user" | "tool", "xxx") # result of tool call
]

The last message could not have role of assistant.

BTW: CrewAI use React template for tool call, if it is better to use tools parameter of litellm.chat.completions.create directly?