Semantic Kernel 内容格式化完全指南把 AI 响应收敛成可解析的稳定结构【免费下载链接】semantic-kernelIntegrate cutting-edge LLM technology quickly and easily into your apps项目地址: https://gitcode.com/GitHub_Trending/se/semantic-kernel让 LLM 输出 JSON结果它给你回了json 好的这是你要的 JSON……后面接着一段解释。下游程序直接解析失败。把 LLM 的自由文本收敛成稳定结构是生产环境里绕不开的问题而这正是 Semantic Kernel 内容格式化要解决的事它不靠事后清洗而是从提示模板、工具调用行为到结构化输出在生成环节就把格式约束住。响应不可控格式化 AI 响应的真实痛点两个高频翻车现场你要一份结构化数据模型用 Markdown 代码块包了一层还顺手加了开场白和总结正则写得再宽也拦不住自由发挥。你希望模型先查订单再回答它跳过工具直接一本正经地编。这两种情况的共同点是你只在提示词里请求了格式系统层面没有任何约束。这张图展示的是框架里 Agent 的继承体系KernelAgent继承自Agent而AgentChannel负责把消息在 Agent 之间传递。换句话说所有 Agent 都是挂在 Kernel 上的Kernel 才是真正持有能力、分发调用的核心。核心机制拆解Kernel、插件、函数与模板Semantic Kernel 可以理解为一个协调器它收到请求Ask然后调动手上注册的能力去满足它。能力以插件Plugin为单位分组插件里是一个个函数Function——分两种用 C# / Python 写的原生函数和用自然语言写在提示模板里的语义函数。响应格式由三层共同决定提示模板决定模型看到什么Prompt Execution Settings 决定模型用什么规矩说工具调用行为决定模型先做哪件事。把这三层配好AI 响应管理才算真正落地。模板工厂怎么选模板工厂负责把带变量的提示渲染成最终文本。默认的 Basic 工厂用{{var}}占位简单直接Handlebars 工厂则支持条件判断、循环和自定义 helper适合逻辑复杂的提示。工厂在创建 Kernel 时通过AddTemplateEngineHandlebars之类的扩展注册之后所有语义函数共用它。图中BasicPromptTemplate与HandlebarsPromptTemplate各自对应一个 Factory都实现同一个IPromptTemplateFactory接口——选型只需要换工厂不改上层调用代码。工具调用行为如何配置想让模型先查资料再回答就要配工具调用行为。SK 里统一用FunctionChoiceBehavior来声明Auto表示模型自己决定调不调、调哪个Required强制必须调用None则只挂上工具、由你手动驱动。这个行为对象放进PromptExecutionSettings随请求下发连接器再翻译成各家模型的具体参数。时序图里能看到完整回路choiceBehavior在每轮响应时决定暴露哪些函数AI Service 据此请求 LLM拿到结果后逐个Invoke functions再回传。工具描述写得越清楚这一环就越稳。用结构化输出给响应套上结构前两步管输入侧最后一步管输出侧。PromptExecutionSettings里可以直接指定响应格式——比如按某个类生成 JSON Schema、要求严格 JSON 输出——模型返回的内容天然对齐你的字段定义不需要再从文本里抠 JSON。这一步和工具行为不冲突可以同时启用。常见坑与调优建议只靠提示词求格式写一百遍请只输出 JSON都不如开一次结构化输出格式约束要落到设置层。工具描述含糊参数说明写得潦草模型就瞎猜。给每个函数写清用途和参数含义调用质量立竿见影。模板越写越长提示里塞了太多分支逻辑时考虑换成 Handlebars把条件判断从自然语言里挪出来模型少理解一层。Semantic Kernel 把格式化拆成模板、工具行为、输出结构三道闸每道都能单独调。概念不熟先翻 docs/GLOSSARY.md架构取舍的来龙去脉在 docs/decisions/完整代码在仓库https://gitcode.com/GitHub_Trending/se/semantic-kernel【免费下载链接】semantic-kernelIntegrate cutting-edge LLM technology quickly and easily into your apps项目地址: https://gitcode.com/GitHub_Trending/se/semantic-kernel创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考