-
Notifications
You must be signed in to change notification settings - Fork 3.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
Some issues related to support for an Agent declarative format #10237
Comments
For the initial question (#1), I believe the original thinking was to avoid infinite chat when a developer failed to provide parser. One option is that the default implementation could be In response to your question: Why doesn't the default implementation change the function result? The termination function could provide any result and isn't bound to forcing the model to respond in any particular fashion. (For example, I personally like using structured output and then parsing the JSON result.) Since there is insufficient visibility for the base implementation to evaluate the result, the default posture is currently to avoid a non-terminating chat (with the most conservative approach - always terminate). As we're having this discussion, I do kind've like the approach of not having any default implemenation and raising an actionable error when no-result parser is defined. Thoughts? |
Going back a little. So if I am creating a
It is option #2 which I am looking at. Note: We should consider changing the |
KernelFunctionTerminationStrategy was originally designed for use with a prompt function only. The |
1. Use KernelFunction return value
The default
KernelFunctionTerminationStrategy.ResultParser
is:public Func<FunctionResult, bool> ResultParser { get; init; } = (_) => true;
If the
KernelFunction
returns false then this will override this return value and cause termination.Why doesn't the default implementation change the function result?
2. Pass
Agent
andChatHistory
inKernelArguments
Consider this code
It would be more convenient to:
Agent
instance rather than the name or idChatHistory
rather than a string (which cannot be parsed back into a ChatHistoryKernelFunctions
which has a signature which takes typedAgent
andChatHistory
parameters3. Should we have a standard way to Invoke an
Agent
When we support declarative agents the follow will look something like this
Agent
instance from a file which contains a declarative definition of anAgent
Agent
instance optionally using a provided input and other argumentsAgent
instance again and maintain contextHere's some psuedo code:
At the moment the code to "Invoke" a
ChatCompletionAgent
versus aOpenAIAssistantAgent
is different. Should we have an abstraction in the Agent framework that allows us to standardise?The text was updated successfully, but these errors were encountered: