本文涵蓋代理程式架構架構中的重要概念，包括基本準則、設計目標和戰略目標。
目標
Agent Framework是以下列重要優先順序所開發：
- Semantic Kernel 代理程式架構可作為實作代理程式功能的核心基礎。
- 不同類型的多個代理程式可以在單一對話內共同作業，每個代理程式都會貢獻其獨特的功能，同時整合人類輸入。
- 代理程式可以同時參與和管理多個並行交談。
代理人
抽象 Agent 類可作為所有類型的代理程式的核心抽象概念，提供可擴充以建立更特製化代理程式的基礎結構。 這個基類會形成更特定代理程序實作的基礎，這些實作全都利用核心的功能來執行其各自的函式。 請參閱代理程式類型一節中的所有可用代理類型。
您可以直接叫用代理程式來執行工作，或由不同的模式協調。 此彈性結構可讓代理適應各種對話或任務驅動的情境，提供強大的工具給開發人員用來建置智慧型多代理系統。
語意核心中的代理程序類型
代理程式線程
抽象 AgentThread 類可作為線程或對話狀態的核心抽象概念。 它將交談狀態管理的不同方式抽象化，以便適用於不同的代理。
具狀態代理程式服務通常會將交談狀態儲存在服務中，而且您可以透過標識符與其互動。其他代理程式可能需要在每個調用上將整個聊天記錄傳遞至代理程式，在此情況下，交談狀態會在應用程式中本機管理。
具狀態代理程式通常只能搭配相符 AgentThread 的實作使用，而其他類型的代理程式可以使用一種 AgentThread 以上的類型。 例如，AzureAIAgent 需要一個相符的 AzureAIAgentThread。 這是因為 Azure AI 代理程式服務會將交談儲存在服務中，而且需要特定的服務呼叫來建立線程並加以更新。 如果使用不同的代理程式線程類型搭配 AzureAIAgent，我們會由於非預期的線程類型而快速失敗，並引發例外狀況來警示呼叫者。
代理人協作配置
這很重要
Agent Framework 中的代理程序協調流程功能處於實驗階段。 它們處於積極開發狀態，在晉級預覽或發行候選階段之前可能會大幅變更。
備註
如果您已經在使用 AgentGroupChat 編排模式，請注意它已經不再維護。 我們建議開發人員使用新的 GroupChatOrchestration 模式。
這裡提供移轉指南。
Semantic Kernel 中的 代理程式協調流程 架構可讓您協調多個代理程式，共同解決複雜的工作。 它提供彈性結構，可定義代理程式互動、共用資訊及委派責任的方式。 核心元件和概念包括：
- 協調流程模式： 預先建置的模式，例如 Concurrent、Sequential、Handoff、Group Chat 和 Magentic，可讓開發人員選擇最適合其案例的共同作業模型。 每個模式都會定義不同的方式讓代理程式進行通訊和處理工作（如需詳細資訊，請參閱 協調流程模式 數據表）。
- 數據轉換邏輯： 輸入和輸出轉換可讓協調流程調整代理程式和外部系統之間的數據，同時支援簡單和複雜的數據類型。
- Human-in-the-loop： 某些模式支援人類參與的迴圈，讓人類操作員參與編排過程。 這對於需要人類判斷或專業知識的案例特別有用。
此架構可讓開發人員建置智慧型手機多代理程式系統，透過共同作業、特製化和動態協調來解決真實世界的問題。
代理程式與語意核心特性對齊
Agent Framework是以許多開發人員在語意核心生態系統中了解的基礎概念和功能為基礎。 這些核心原則可作為 Agent Framework 設計建置組塊。 藉由利用語意核心的熟悉結構和功能，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 向登錄處註冊。
此功能無法使用。