Support SKContext as one of the optimal input parameter of Planner constructor.

[tim-nju]

It would be so great if we could choose to pass a self-created SKContext when constructing a Planner, for example:

    public SequentialPlanner(
        IKernel kernel,
        SequentialPlannerConfig? config = null,
        string? prompt = null,
        SKContext? context = null
    )

In this case, the SKContext can be much more flexible in its usage and not only restricted inside function calls. Besides, this change is two lines thing and will not require any other changes to the existing framework or any applications. While it provides more flexibility and free room to the developers.

[evchaki]

@shawncal - can you add details to this one.

[shawncal]

Hi @tim-nju, thanks for the suggestion!

SKContext is really meant as the "currently running context" for a function or, in this case, a Plan. The context will evolve from one function call to the next, and is a way for the Kernel to map ContextVariables and other details to the function's parameters, and to capture return values and exceptions.

Ideally, a developer should never need to construct an SKContext of their own, as the Kernel does this in RunAsync()... instead, the developer can use higher-level abstractions to pass in the args and values they need. In fact, with an upcoming change, we plan to make SKContext an abstract base class, meaning there will be no public constructor available. Instead, we'll show how to call functions and allow the Context to come from the Kernel that's calling it.

In the case of SequentialPlanner, what did you have in mind, that you'd need the SKContext for? This would be good to know, as we continue to refine the SDK, and make sure you have all the customization and extensibility hooks you need.

[tim-nju]

@shawncal Thank you for your informative reply. Here is our scenario: in our kernel app (let's call it A), there are no real functions. All the real functions are executed in another place (let's call it B). So we need to run the fake function in A to get all the input parameter values from SKContext and then pass those input parameter values via network call from A to B. And then B returns the real execution result. And then we would like to update the context with the result manually. And repeat the process.

[tim-nju]

BTW, I do say we can play context when calling public async Task<Plan> InvokeNextStepAsync (SKContext context). The missing part is the constructor.

[tim-nju]

Oops, sorry, looks like manually updating the values in SKContext doesn't change anything. Sorry to bother.

[nacharya1]

@tim-nju, seems like you have a resolution to your question. I will close this for now. If you have questions please let us know.