Semantic Kernel dotnet 1.0 beta4 发布了！
这个版本带来了一些重要的变化和改进：
破坏性变更：移除了 IPlan 接口！
由于 IPlan 接口没有任何定义，而所有 Plan 实现实际上都直接实现了 ISKFunction 成员，因此目前没有必要将其作为一个标志接口。所以，我们要去除 IPlan 接口，并直接将其所有依赖项指向 ISKFunction。
移除 Kernel.Builder 用 new KernelBuilder() 替代。
原因是 Kernel.Builder 的定义是：public static KernelBuilder Builder => new();，这会使得人们在不看内部实现时认为这是一个单实例，实际上，每次访问都是一个不同的实例，这很容易引发问题。
引入 IAIServiceSelector 接口，允许在语义函数执行期间选择 AI 服务和请求设置
在之前的版本中，语义函数在创建时就已经设置了 AI 服务，这导致一个语义函数实例不能与多个不同的内核实例一起使用。此外，请求设置也是在函数创建时设置的，这意味着在执行函数时无法选择不同的请求设置。
该接口的默认实现大致如下：
- 如果语义函数仅关联一个没有服务id的模型请求设置实例，则使用默认的AI服务和模型请求设置，这与以前的行为一致。
- 如果语义函数仅关联一个带有服务id的模型请求设置实例，则使用指定的AI服务和模型请求设置。如果指定的AI服务不可用，则会抛出异常，这与以前的行为一致。
- 如果语义函数关联了多个模型请求设置实例，则按照以下规则处理：
- 按照顺序考虑模型请求设置实例
- 第一个没有服务id的模型请求设置实例将被视为默认请求设置
- 对于每一个带有服务id的模型请求设置实例，如果该服务存在，则会使用该服务和关联的模型请求设置
- 如果找不到匹配的服务但提供了默认的请求设置，则会使用默认服务
- 如果找不到匹配的服务且没有提供默认的请求设置，则会抛出异常
增加使用自定义本机函数的示例
示例中内容包括：
- 一个本机函数调用另一个本机函数（函数链）
- 两个原生函数在内核（函数管线）中按顺序调用
- 将上下文变量自动转换为本机函数参数中的基元类型
增加了关于多 LLM 支持用例的 ADR (架构决策记录) 提案
- 描述支持多 LLM 设计的 ADR。将来会进行扩展，以允许增加额外的使用案例，如通过 LLM 模型 ID 选择 AI 服务。
- 调整 IAIServiceSelector 以便将其添加到 IKernel 实例中，查看示例 62 可找到自定义 IAIServiceSelector 实现的例子。
增加 Completion service 类型选择的 ADR
有时候我们需要根据需求选择不同的 Completion service 类型，这个 ADR 可以告诉我们如何实现
增加了 chat completion 角色的 SK 提示语法的 ADR
目前，SK 还不能在提示中标记出一段具有特定角色（如助手、系统或用户）的文本作为消息。因此，SK 不能将提示划分为 chat completion 连接器的所需的消息列表。
此外，可以使用诸如 Handlebars、Jinja 等各种模板引擎支持的一系列模板语法来定义提示。每种语法可能以独特的方式代表聊天消息或角色。因此，如果没有适当的抽象做隔离，模板引擎的语法可能会侵入 SK 的领域，使得 SK 与模板引擎紧密耦合，这将导致 Semantic Kernel 无法支持新的模板引擎。
删除 SKCancelEventArgs 不需要的终结器
因为 GC 可以正常处理这种情况
升级了一些依赖包
- 将 Azure.Identity 从 1.10.2 升级到 1.10.3
- 将 Microsoft.Azure.Functions.Worker.Sdk 从 1.15.0 提升到 1.15.1
Semantic Kernel .NET 1.0 正式版已经越来越接近了，目前看到 .NET 小组成员正在在积极更新维护 ADR，已将所有合并的 ADR 状态为已接受，并添加一个联系人，目的是为了使 Python 和 Java 小组更清楚哪些决策已被接受以及如何联系以获取更多信息以便帮助，这将很有利于指引后续其他语言版本的设计开发不偏离 Semantic Kernel 的架构设计理念。