作者：Gwen Davis
排版：Alan Wang
AI 正在从 提示词-响应 的交互模式，转向可编程的执行能力。看看 GitHub Copilot SDK 如何让智能体式工作流直接嵌入到你的应用中。

在过去两年中，大多数团队与 AI 的交互方式基本相同：提供文本输入，接收文本输出，然后手动决定下一步该做什么。

但生产级软件并不是基于孤立的交互运行的。真实系统是“执行”的。它们会规划步骤、调用工具、修改文件、从错误中恢复，并在你定义的约束下进行调整。

作为开发者，你已经习惯在 IDE 中使用 GitHub Copilot 作为你信赖的 AI。但我敢打赌，你不止一次想过：“为什么我不能在自己的应用中也使用这种智能体式工作流？”

现在你可以了。

GitHub Copilot SDK 将这一执行层能力，以可编程的方式提供给你的软件。

你无需再维护自己的编排栈，而是可以直接将驱动 GitHub Copilot CLI 的、经过生产验证的规划与执行引擎嵌入到你的系统中。

如果你的应用可以触发逻辑，它现在就可以触发智能体式执行。这一转变正在改变 AI 驱动系统的架构。

那么它是如何工作的？以下是三个团队正在使用的、将智能体式执行嵌入真实应用的具体模式。

模式一：将多步骤工作委派给智能体

多年来，各个团队一直依赖脚本和粘合代码来自动化重复性任务。但一旦某个工作流开始依赖上下文、在执行过程中发生变化，或需要进行错误恢复，脚本就会变得脆弱。你要么将各种边界情况硬编码进去，要么开始构建一套自研的编排层。

使用 Copilot SDK，你的应用可以“委托意图”，而不是编码固定步骤。

例如：

你的应用提供了一个操作，例如“为该代码仓库准备发布”。

你无需手动定义每一个步骤，而是传递意图和约束条件。智能体会：

• 探索代码仓库

• 规划所需步骤

• 修改文件

• 运行命令

• 在出现失败时进行调整

同时始终在既定边界内运行。

为什么这很重要：随着系统规模的扩大，固定的工作流会逐渐失效。智能体式执行使软件能够在保持约束和可观测性的前提下进行自适应，而无需从零开始重建编排机制。

查看多步骤执行示例 →

模式二：在结构化的运行时上下文中进行执行

许多团队尝试将更多行为放入提示词中。但将系统逻辑编码在文本里，会使工作流更难测试、推理和演进。随着时间推移，提示词会变成结构化系统集成的一种脆弱替代。

借助 Copilot SDK，上下文变得结构化且可组合。

你可以：

• 定义特定领域的工具或智能体 skill

• 通过模型上下文协议（MCP）暴露工具

• 让执行引擎在运行时获取上下文

无需将归属数据、API 模式或依赖规则塞入提示词中，你的智能体可以在规划与执行过程中直接访问这些系统。

例如，一个内部智能体可能会：

• 查询服务归属

• 获取历史决策记录

• 检查依赖关系图

• 调用内部 API

• 在既定的安全约束下执行

为什么这很重要：可靠的 AI 工作流依赖于结构化且具备权限控制的上下文。MCP 提供了必要的基础连接，使智能体式执行能够基于真实工具和真实数据运行，而不是依赖提示词中的猜测。

模式三：在 IDE 之外嵌入执行

当今许多 AI 工具默认假设有价值的工作发生在 IDE 内。但现代软件生态远远超出了编辑器的范围。

团队希望在以下环境中拥有智能体能力：

• 桌面应用程序

• 内部运营工具

• 后台服务

• SaaS 平台

• 事件驱动系统

借助 Copilot SDK，执行能力成为应用层的一项功能。

你的系统可以监听某个事件——例如文件变更、部署触发或用户操作——并以编程方式调用 Copilot。

规划与执行循环在你的产品内部运行，而不是在独立界面或开发者工具中。

为什么这很重要：当执行能力嵌入到应用中时，AI 不再只是侧边窗口的助手，而成为基础设施。它可以在软件运行的任何地方使用，而不仅仅是在 IDE 或终端中。

构建你的第一个 Copilot 驱动的应用程序 →

执行是新的界面

从“AI 作为文本”到“AI 作为执行”的转变，本质上是架构层面的变化。智能体式工作流是可编程的规划与执行循环，它们在约束条件下运行，与真实系统集成，并在运行时自适应。

GitHub Copilot SDK 将这些执行能力以可编程层的形式提供出来。团队可以专注于定义软件需要完成的目标，而不必在每次引入 AI 时都重新构建编排机制。

如果你的应用可以触发逻辑，它就可以触发智能体式执行。

探索 GitHub Copilot SDK →