微软 Semantic Kernel 规划器驱动代理工作流

解决什么问题

把 LLM 直接塞进一个 chat() 调用里，很快就会遇到三个麻烦：一是复杂任务没有拆解，模型要么一步到位幻想出一堆不存在的中间结果，要么在长上下文里迷路；二是 prompt、工具调用和记忆散落在各处，换一门语言或换一个运行时就要重写一遍；三是团队很难对同一个流程做回归测试，因为每一次运行都依赖模型的即兴发挥。

这个技能针对的是「把规划（planner）作为工作流中枢」的构建方式，让代理在执行前先产出一份可检查的计划，再逐步落实，而不是把所有判断都押在单次生成上。

技能如何工作

核心思路是把代理拆成可组合的几层：

• 提示词（Prompts）：承载具体意图与约束，是流程里唯一需要频繁迭代的部分
• 插件（Plugins）：封装可被模型调用的工具与函数，把「能不能做」变成一组明确接口
• 内存（Memory）：维持跨步骤的上下文，避免每轮都从头解释现状
• 规划器（Planners）：先生成结构化计划，再按计划驱动执行——这是与裸调用 LLM 的关键区别
• 连接器（Connectors）：对接具体的 LLM 提供商，把运行时差异隔离在一层后面

典型的落地路径是：先定义插件边界，再编写提示词，然后用规划器把「目标」编译成一组有序步骤，执行过程中通过内存做状态回填，最终形成可重复运行的代理工作流。

它同时覆盖三种主流运行时：Python、.NET 和 Java。同一套规划器驱动的思路，可以在不同语言栈里复用，不必为每种技术栈重写工作流逻辑。

适用边界与注意点

• 运行环境要求较新：Python 需要 3.10+，.NET 需要 10.0+，Java 需要 17+，老项目迁移前要先确认工具链
• 依赖具体的 LLM 提供商凭证：连接器指向哪家模型，就需要对应平台的 API 密钥或配置，本地跑通不代表线上稳定
• 规划器不是万能的：它增加的是一个可检查的中间产物，但计划本身的质量仍然取决于提示词与插件接口设计得是否清晰
• 本地部署是可行选项：可以通过 Ollama、LMStudio 或 ONNX 在本地跑推理，适合对数据外发敏感的场景，但通常需要接受更慢的推理速度
• 多步流程的调试成本会转移：单步调用容易打日志，规划器驱动的流程需要额外关注每一步计划与实际执行的偏差

这个技能适合已经明确要构建多步骤代理、并且希望流程可复现的工程师，而不是只想做一次单轮问答的场景。