本文介绍代理框架体系结构中的关键概念，包括基本原则、设计目标和战略目标。
目标
开发 Agent Framework 时考虑了以下关键优先级：
- 语义内核代理框架充当实现代理功能的核心基础。
- 不同类型的多个代理可以在单个对话中协作，每个代理都贡献其独特的功能，同时集成人工输入。
- 代理可以同时参与和管理多个并发对话。
代理
抽象 Agent 类充当所有类型的代理的核心抽象，提供一个基础结构，可以扩展以创建更专用的代理。 此基类构成了更具体的代理实现的基础，所有这些实现都利用内核的功能来执行各自的函数。 请参阅 “代理类型” 部分中的所有可用代理类型。
可以直接调用代理来执行任务，也可以由不同的模式进行协调。 这种灵活的结构允许代理适应各种聊天或任务驱动方案，为开发人员提供强大的工具来构建智能多代理系统。
语义内核中的代理类型
代理线程
抽象 AgentThread 类充当线程或聊天状态的核心抽象。 它抽象化了可为不同代理管理聊天状态的不同方式。
有状态代理服务通常将会话状态存储在服务中，并且可以通过 ID 与之交互。其他代理可能需要在每个调用中将整个聊天历史记录传递到代理，在这种情况下，会话状态在本地在应用程序中进行管理。
有状态代理通常仅与匹配的AgentThread实现一起工作，而其他类型的代理可以使用多个AgentThread类型。 例如， AzureAIAgent 需要匹配 AzureAIAgentThread。 这是因为 Azure AI 代理服务将对话存储在服务中，并且需要特定的服务调用来创建线程并对其进行更新。 如果使用不同的代理线程类型，我们会因线程类型AzureAIAgent意外而快速失败，并引发异常来通知调用方。
代理协调管理
重要
代理框架中的代理编排功能处于实验阶段。 它们处于积极开发阶段，在升级到预览版或候选发布阶段之前可能会发生重大变化。
注释
如果一直在使用 AgentGroupChat 编排模式，请注意它不再维护。 建议开发人员使用新 GroupChatOrchestration 模式。
此处提供了迁移指南。
语义内核中的 代理业务流程 框架使多个代理能够协作解决复杂的任务。 它提供了一个灵活的结构，用于定义代理如何交互、共享信息和委托责任。 核心组件和概念包括：
- 业务流程模式： 预构建的模式（如并发、顺序、交接、群聊和 Magentic）允许开发人员为其方案选择最合适的协作模型。 每个模式为代理定义不同的通信和处理任务的方式（有关详细信息，请参阅 业务流程模式 表）。
- 数据转换逻辑： 输入和输出转换允许业务流程在代理和外部系统之间调整数据，同时支持简单和复杂的数据类型。
- 人工介入： 某些模式支持人工介入，使人工代理能够参与编排过程。 这对于需要人工判断或专业知识的方案特别有用。
此体系结构使开发人员能够构建智能的多代理系统，这些系统可以通过协作、专业化和动态协调来解决实际问题。
代理与语义内核特性之间的对齐
基于许多开发人员在语义内核生态系统中所熟知的基础概念和功能，Agent Framework 已构建而成。 这些核心原则充当代理框架设计的构建基块。 通过利用语义内核的熟悉结构和功能，代理框架扩展其功能，以实现更高级、更自主的代理行为，同时保持与更广泛的语义内核体系结构的一致性。 这可确保开发人员顺利过渡，使他们能够应用其现有知识，以在框架中创建智能、可适应的代理。
插件和函数调用
插件 是语义内核的基本方面，使开发人员能够集成自定义功能并扩展 AI 应用程序的功能。 这些插件提供了一种灵活的方法，可将专用功能或业务特定的逻辑合并到核心 AI 工作流中。 此外，通过利用 插件 和 利用函数调用，可以显著增强框架中的代理功能。 这样，代理就可以动态与外部服务交互或执行复杂的任务，进一步扩展了各种应用程序中 AI 系统的范围和多功能性。
了解如何在 此处 配置代理以使用插件。
代理消息
代理消息传送（包括输入和响应）基于语义内核的核心内容类型构建，为通信提供统一的结构。 此设计选择简化了从传统聊天完成模式过渡到应用程序开发中更高级的代理驱动模式的过程。 通过利用熟悉的语义内核内容类型，开发人员可以无缝地将代理功能集成到其应用程序中，而无需彻底改革现有系统。 这种简化可确保从基本对话 AI 发展到更自主、面向任务的代理时，基础框架保持一致，使开发更快、更高效。
模板化
代理的角色主要由它收到的指令决定其行为和操作。 与调用Kernel提示类似，代理的说明可以包括模板化参数（值和函数），这些参数在执行期间动态替换。 这可实现灵活的上下文感知响应，使代理能够基于实时输入调整其输出。
此外，可以使用提示模板配置直接配置代理，为开发人员提供一种结构化且可重用的方式来定义其行为。 此方法提供了一个功能强大的工具，用于标准化和自定义代理指令，确保各种用例的一致性，同时仍保持动态适应性。
在此处详细了解如何使用语义 内核模板创建代理。
声明性规范
即将推出有关使用声明式规格的文档。
重要
此功能处于实验阶段。 此阶段的功能正在开发中，在升级到预览阶段或候选发布阶段之前可能会更改。
注册自定义代理类型
若要将自定义代理用于声明性 YAML 规范系统，必须先将代理类注册到代理注册表。 这是必需的，以便 AgentRegistry 在解析 YAML 规范中的 type: 字段时识别和构造代理程序。
若要注册自定义代理类型，请使用 @register_agent_type 修饰器：
from semantic_kernel.agents import register_agent_type, Agent, DeclarativeSpecMixin
@register_agent_type("custom_agent")
class CustomAgent(DeclarativeSpecMixin, Agent):
...
提供给修饰器（例如） "custom_agent"的字符串必须与 YAML 规范中的类型：字段匹配。
注册后，可以使用声明性模式实例化自定义代理，例如通过 AgentRegistry.create_from_yaml(...)。
DeclarativeSpecMixin 添加了对以下方法的支持，例如 from_yaml、from_dict 和 resolve_placeholders，这些方法允许从 YAML 或字典格式构造代理。
@classmethod
async def from_yaml(cls, yaml_str: str, *, kernel=None, plugins=None, prompt_template_config=None, settings=None, extras=None, **kwargs):
# Resolves placeholders and loads YAML, then delegates to from_dict.
...
@classmethod
async def from_dict(cls, data: dict, *, kernel=None, plugins=None, prompt_template_config=None, settings=None, **kwargs):
# Normalizes and passes spec fields to _from_dict.
...
@classmethod
@abstractmethod
async def _from_dict(cls, data: dict, *, kernel, prompt_template_config=None, **kwargs):
# Subclasses implement this to create the agent from a dict.
...
@classmethod
def resolve_placeholders(cls, yaml_str: str, settings=None, extras=None) -> str:
# Optional: override this to customize how environment or runtime placeholders are resolved in YAML.
return yaml_str
小窍门
任何自定义代理都必须继承自 DeclarativeSpecMixin 以启用基于 YAML 的构造，并且必须使用注册表 @register_agent_type注册。
此功能不可用。