基于 Microsoft Foundry 的智能体式 AI——多智能体编排与工作流

在本章中，我们将探索如何使用 Agentic AI，并基于 Large Language Models（LLMs）或 Small Language Models（SLMs），构建 multi-agent-based applications。这是一种新的软件工程范式：我们不再主要进行 logic-based programming，而是转向 AI decision-driven programming，也就是通过 instructions 告诉 language models 要执行什么任务，以及在什么时候执行。

在某些场景中，单个 agent 执行受限任务并不足够，因此我们需要构建 multi-agent scenario。例如，如果我们想处理 customer order，可能会有专注 customer account 的 agents、product-based agents，以及 order management agents。这三类 agents 组合在一起，才能完成处理 order 的 business workflow。

传统上，drag-and-drop tools 可以帮助编排小型 functional steps。Agentic AI 采用不同方式：它提供构建智能、自适应系统的 building blocks，包括 Agents、Memory、Knowledge 和 Tools，从而显著简化开发。

Agentic AI 的核心 components 已在第 7 章中详细讨论。

本章将通过一个实用的真实世界场景探索这些概念。你还将学习如何使用 Microsoft Foundry 实现 multi-agent systems。本章将覆盖以下主题：

• Multi-agent orchestration using workflow
• Multi-agent system using the Microsoft agent framework

Technical requirements

本章需要根据文档链接完成 standard agent setup 的 Microsoft Foundry resources，文档地址如下： learn.microsoft.com/en-us/azure…

随着产品成熟，setup steps 可能会演进。在本书写作时，Standard Agent 提供完整的 enterprise-ready features。它可以部署在 private network 中以增强保护，并包含 built-in security capabilities，例如 managed identities 和 native role-based access control（RBAC）。

我们还会使用 Visual Studio Code 创建 local setup。如果你有 Visual Studio Code 和 GitHub Copilot chat，就可以使用 vibe coding。

Vibe coding 是一种现代软件开发方法，核心围绕 prompt engineering，也就是通过 instructions 让 models 生成期望功能。通过关注如何构造问题并提供清晰指令，developers 可以利用 AI 加速 code generation 和 prototyping。虽然这种方法可以显著提升生产力，但也必须警惕 model outputs 中潜在的 hallucinations。所有生成代码都应仔细 review、validate 和 refine，以确保它满足 requirements，并且只包含 solution 所必需的内容。

在本书写作时，agents 支持 GPT-4.1 和 GPT-4o 等 models。对 newer models 的支持会随着时间演进，未来版本，例如 GPT-5、GPT-5.5 或 GPT-6，可能会在可用后被纳入。

Multi-agent orchestration using workflows

现代 enterprise applications 往往需要多个 agents 协同工作，以完成复杂任务。这通常通过 workflows 实现，用于 orchestrate agent interactions、system integrations，并且在某些情况下还包括 human approvals。

在本节中，你将学习如何编排多个 agents，创建 business flow，以完成一个 business use case。许多真实世界 business processes 本质上都是 multi-step，并且需要协调不同 systems、decision points 和 validations。这些 processes 可以完全自动化，也可以包含 human-in-the-loop steps，用于 approval 和 verification。

一个常见示例是 expense report processing。当通过 email 收到 expense report 时，可以触发一个 workflow 来处理该流程。典型 workflow 可能包含以下步骤：

• 等待 incoming email
• 提取 expense attachment
• 将数据传递给多个 agents 做 information extraction
• 验证 user 和 expense details
• 更新 expense management system

在这个场景中，多个 agents 协作完成整体目标，每个 agent 负责 workflow 中的一个特定部分。

Microsoft Foundry 的 user interface 中提供 workflow capability，我们可以登录 Microsoft Foundry user interface 并构建 applications。本节假设 individual agents 已经创建完成。关于如何构建和配置 agents，请参考第 7 章中的详细指导，因为这些 agents 会在 workflow 中被复用。

Creating a workflow using the user interface

我们可以从 blank workflow 开始，也可以使用现有 templates：

• Sequential Workflow
• Human in the Loop
• Group Chat

如果你想从零开始构建自己的 orchestration，请参考下面步骤：

进入 Microsoft Foundry user interface，然后在左侧菜单中选择 Agents。

点击 Workflow tab。

图 9.1：Blank workflow

一个 blank canvas 会打开。屏幕上有一些内容需要先了解。屏幕左上角有几个 tabs，如下：

Build：Build 是我们创建 orchestration flow 的地方，用于根据 requirements 构建完整 business use case 或 business flow。

Traces：这里可以查看 orchestration 如何执行、它的 latency，以及 conversation logs。

Monitor：这里可以看到 workflow 使用的 tokens，以及 model consumption。

Evaluation：这里用于根据 responsible AI KPIs 评估 model。

在左下角，你会看到 zoom in 和 zoom out canvas 的选项。

在右上角，会有 canvas orientation 选项，例如 vertical 或 horizontal，也可以选择 YAML 或 code 进行 visualization。

图 9.2：Right-top menu

在图 9.2 中，我选择让 orchestration 从左到右展示。但我们也可以选择 top down，因为有些 users 可能个人更喜欢自上而下的 flow，以便理解和构建 workflows。我个人更喜欢从左到右的 flow。

Building a simple multi-agent workflow

现在让我们创建一个 workflow。例如，我将构建一个 Request for Proposal application。对于这个 application，我构建了两个 agents：一个叫 intent，另一个是 request for proposal（RFP）agent。

创建新的 blank workflow 后，你会看到默认 workflow screen：

图 9.3：Blank workflow

我们来看 canvas 中有哪些内容。可以看到，默认出现一个 start node。接下来你会看到 “Add a workflow node”，这些是可以添加到 workflow 中的选项。一个 node 可以是一个 single agent，或者一个 single operation。这些 nodes 被分类为：

Invoke：这里用于调用 single agent，并提供在 orchestration 中配置 agent 的选项。

Data Transformation：这里有几个选项，例如 Set、reset variable、parse value。例如，Parse value 可以将一种 data type 转换为另一种；set 和 reset variable 可以创建一个 variable，用于在 orchestration flow 中跨流程使用，也可以改变 values 或赋新值。

Flow：这里提供 control options，例如 if / else、for each、go to node。这些是 conditional options，用于做 decisions、处理多个 items，或基于某个 decision 通过 go to node 走不同 flow。

Basics：Deliver a message、Ask a question、End the workflow。这些是基础节点，用于启动 conversation、以 chat style 与 user 交互获取 input，也用于标记 workflow 结束。

现在我们通过调用两个 agents 构建一个简单 workflow：

点击 canvas 中的 + 号，并从 invoke section 中选择 agent。

图 9.4：Node selection

现在选择 Agent。右侧会出现一个显示 agent configuration information 的面板。

图 9.5：Agent configuration

这里可以选择想使用的 agent，并进行其他配置。还有 Details 和 node settings。

Details section 会显示 agent 正在使用什么 model，以及为 agent 提供的 prompt instruction。它也会显示该 agent 配置的 tools、knowledge 和 memory。

Node Settings 用于 orchestration workflow，它提供指定 multi-turn conversation storage 的选项，也提供 variables，用于存储 agent output 或 extracted output，以便在 conditional 或 flow node type 中处理。也可以从已创建的 variables 中分配 input message 和 output messages。如果 use case 需要以某种格式提取信息进行处理，也可以将 output 保存为 JSON schema。

这里也有一个选项，用于指定下一个要选择处理的 agent 或 node。

接下来，我们将调用 request for proposal agent。

图 9.6：Complete workflow

图 9.6 展示了使用 blank workflow 构建的端到端简单 workflow。这里的目的是展示如何使用 user interface 构建 multi-agent orchestration。最后，点击 save button，并为 workflow 提供一个名称。

现在我们将与刚才讨论的 orchestration 进行 chat。

图 9.7：Preview option

从上面的菜单中，当 workflow 保存后，选择 Preview，右侧会打开 chat interface。这里就是我们输入信息并等待 workflow 完成的地方。Chat 完成后，可以在 canvas 上看到 status。

图 9.8：Workflow status

你可以看到 nodes 上的绿色 icon，表示 successful status；如果有 error，则会看到红色 icon。

图 9.9：Workflow trace

如上图所示，你可以在左侧看到 orchestration flow 如何进行的 lineage；右侧则可以看到 conversation details。我们也把这称为 agent lineage 和 traceability。

现在，我们也可以选择将 agent 发布到 Agent 365，或发布到 Teams 和 Copilot。

图 9.10：Publish options

现在我们可以查看 traces。

图 9.11：Traces

Monitor 是查看 model 和 agent 所使用 tokens 的地方。

图 9.12：Monitor

我们还可以看到 agents run、token usage 和 model cost。也可以看到针对 workflow 运行的 evaluations。还可以查看 tool calls 和 agent runs，以及 error rate。

Evaluations 本质上是在有 input 映射到 output，并带有 ground truth，有时还提供 context 的情况下，用来验证 model 对问题的 response 是否适当，是否给出了 relevant answer。

Error rate 是指 models 或 agents 在执行当前 task 时失败的比例。

这里也有选择时间范围的选项，例如 last day、7 days、1 month；也有 extended option，可以在 Azure Monitor 中打开并查看 logs。

在右上角菜单中，有查看 YAML 和 Python code 的选项，用于展示如何利用 workflow 并将其集成到自己的 applications 中。

下面是 YAML code block：

kind: workflow
trigger:
  kind: OnConversationStart
  id: trigger_wf
  actions:
    - kind: InvokeAzureAgent
      id: node-1775580920476
      agent:
        name: IntentAgent
      conversationId: =System.ConversationId
      input:
        messages: ""
      output:
        autoSend: true
    - kind: InvokeAzureAgent
      id: node-1775581643656
      agent:
        name: constructionRFPAgent
      conversationId: =System.ConversationId
      input:
        messages: ""
      output:
        autoSend: true
    - kind: EndConversation
      id: node-1775581660282
id: ""
name: workflow1
description: ""

如果你想使用 Microsoft Foundry Python SDK 并将其集成到自己的 application 中，visualizer 旁边的 Code 选项也提供了代码。

# Before running the sample:
#    pip install --pre azure-ai-projects>=2.0.0b4

import os
from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import ResponseStreamEventType


project_client = AIProjectClient(
    endpoint="https://msfoundryresource.services.ai.azure.com/api/projects/agentproject",
    credential=DefaultAzureCredential(),
)

这里是 project client 的实现，通过调用 workflow 并提供 version，然后调用 responses client 来启动 chat。

with project_client:

    workflow = {
        "name": "workflow1",
        "version": "1",
    }

    openai_client = project_client.get_openai_client()

    conversation = openai_client.conversations.create()
    print(f"Created conversation (id: {conversation.id})")

    stream = openai_client.responses.create(
        conversation=conversation.id,
        extra_body={"agent_reference": {"name": workflow["name"], "type": "agent_reference"}},
        input="Hi workflow1",
        stream=True,
        metadata={"x-ms-debug-mode-enabled": "1"},
    )

下面的代码会解析 streaming output 并展示它：

    for event in stream:
        if event.type == ResponseStreamEventType.RESPONSE_OUTPUT_TEXT_DONE:
            print("\t", event.text)
        elif event.type == ResponseStreamEventType.RESPONSE_OUTPUT_ITEM_ADDED and event.item.type == "workflow_action":
            print(f"********************************\nActor - '{event.item.action_id}' :")
        elif event.type == ResponseStreamEventType.RESPONSE_OUTPUT_ITEM_ADDED and event.item.type == "workflow_action":
            print(f"Workflow Item '{event.item.action_id}' is '{event.item.status}' - (previous item was : '{event.item.previous_action_id}')")
        elif event.type == ResponseStreamEventType.RESPONSE_OUTPUT_ITEM_DONE and event.item.type == "workflow_action":
            print(f"Workflow Item '{event.item.action_id}' is '{event.item.status}' - (previous item was: '{event.item.previous_action_id}')")
        elif event.type == ResponseStreamEventType.RESPONSE_OUTPUT_TEXT_DELTA:
            print(event.delta)
        else:
            print(f"Unknown event: {event}")

    openai_client.conversations.delete(conversation_id=conversation.id)
    print("Conversation deleted")

这段 code block 展示了如何消费在 Microsoft Foundry user interface 中构建的 workflow，并将其集成到其他 applications 中。这非常有影响力，因为当你构建 Agentic AI application 时，可以构建 reusable workflows，并由多个不同 applications 消费它们。我见到的大多数情况是，在与现有 applications 集成时，我们可以使用 Microsoft Foundry Python SDK 扩展和修改 application。

现在让我们看看 Microsoft Foundry workflow 中还可用的其他 templates。

Sequential：用于 step-by-step process implementation。在这种方式中，每一步会交给下一步继续完成。

Human in a loop：当 workflow 需要 human approval，并且 human 和 machine 之间要发生交互时使用。Agents 会等待 user approval，然后再继续处理 workflow。

Group Chat：这里 flow 会根据 escalations、fallback 和 expert handoff 动态变化。

来看一个 Sequential Multi-agent workflow 示例。在这个示例中，你可以看到每个 agent 如何按步骤顺序连接。要让整个 workflow 成功，每个 node 都必须无 error 执行。这是最简单的 agent orchestration 之一。

图 9.13：Sequential workflow

再看一个 Human in the loop multi-agent workflow 示例。这些是空 workflows，仅用于展示。在这种 workflow 中，需要保持 user in the loop，让其提供 feedback、approval 或 validation，从而满足条件后继续 workflow。例如，如果金额超过某个 dollar value，你希望获得 human 或 manager approval。对于这类 use cases，可以利用 human in the loop template workflow。

图 9.14：Human in the loop

现在，让我们探索 group chat workflow 示例。Group chat 适合复杂 multi-agent，其中 agent 会决定进入哪个 flow，跳过其他 agents，并只使用满足条件所需的 agents。例如，如果你想为网站构建 customer service chatbot，基于 user inputs，可能需要从 order management system 或 product system 检索信息。对于这类复杂场景，group chat 更合适。

图 9.15：Group Chat

现在，你已经看到如何使用 Microsoft Foundry Workflow user interface 构建一个简单的 two-agent system，也就是 multi-agent system。

在上一节中，你学习了什么是 multi-agent workflow，以及 Microsoft Foundry user interface 如何作为工具，用于构建 blank、sequential、human-in-the-loop 和 group chat 类型的 workflows。我们学习了如何从零构建 multi-agent orchestration workflow。我们也学习了 workflow canvas，以及 metrics、monitor、nodes 和其他 canvas features，例如 code options 和 workflow orientation。我们还学习了不同 workflow templates，例如 sequential、human-in-the-loop 和 group chat，以及它们适合的使用场景。

现在我们已经看到如何使用 user interface workflows，接下来进入基于 Microsoft agent framework 的 workflow，也就是面向 code-first approach 和 advanced scenarios 的方法。

Multi-agent system using the Microsoft agent framework

上一节中，我们看到如何使用 Microsoft Foundry user interface 构建 multi-agent orchestration。在本节中，我们将进一步介绍如何使用 Microsoft Agent Framework 进行 orchestration。

Microsoft Agent Framework 是一个 open source SDK，支持 Python、.NET 和其他语言，用于构建 agentic AI applications。这个 framework 是开源的，Microsoft 是主要贡献者。由于 AI 领域的 open source ecosystem 非常庞大，并且存在许多用于 agent creation 的 open source SDK，该 framework 的突出点在于它与 Autogen closely follows，而 Autogen 是最早的 agent building frameworks 之一。

Microsoft 的建议是：如果你完全在 Microsoft stack 中，应优先使用 Microsoft Foundry 的 first-party native SDK。如果你使用 open source 和其他工具，那么 Microsoft Agent Framework 会是更好的工具选择。Microsoft Agent Framework 是纯 code-first approach，并与 Microsoft Foundry 有紧密集成。关于 Foundry integration 的更多详情，可以参考： learn.microsoft.com/en-us/agent…

因此，我们可以使用 Microsoft Agent Framework，并复用 Microsoft Foundry 中构建的 agents，来构建 multi-agent orchestration。

本书重点放在 Magnetic Orchestrator 上，它是 Autogen 的一部分，现在也已在 Microsoft Agent Framework 中可用。Magnetic Orchestrator 很独特。本质上，它有一个 ledger 来管理它创建的 tasks。它也是根据 prompt instructions 选择合适 agents 的最佳 orchestrator。因此，我们可以通过提供 prompt instructions 来构建 dynamic orchestration，以达成期望 outcome。关于 MagneticOne orchestration 的文档详情： learn.microsoft.com/en-us/agent…

Orchestration types in Microsoft agent framework

在详细探索每种 orchestration type 之前，需要理解不同 patterns 适合不同 use cases。Orchestration 的选择取决于 task complexity、agents 之间的 dependency、是否需要 parallel execution，以及所需 flexibility level。以下 sections 描述 Microsoft Agent Framework 中可用的关键 orchestration types，以及何时使用它们。

Sequential

在 sequential orchestrations 中，每个 agent 作为一个 step 运行，并按顺序交给下一个 agent。如果其中一个失败，整个 workflow 就会失败。但当我们需要确保来自各种 disparate systems 的所有数据都已可用后，再进行处理时，这种方式非常合适。

例如，如果我想获取 customer insights，内容关于其最新 orders，而数据位于两个不同 systems 中，并且每个 system 都有 agent，那么为了获得完整 picture，最好从两个 systems 都获取数据，最后再处理 insights。这种场景适合 sequential orchestration。

Concurrent

在这种 workflow 中，agents 会以 asynchronous parallel 方式运行来处理信息。例如，如果我想构建一个 company research application，可能会有 6 到 10 个 agents 从各种 web 和 enterprise data sources 拉取信息。在这个场景中，不需要 sequential execution；相反，所有 agents 会并行执行，并将 output 提供给一个 collector，由 collector 整合并输出结果。请注意，这种方式没有上面那种 sequence 来保证顺序。

Handoff

这种 multi-agent pattern 用于 agents 将 tasks hand off 给其他 agents，以确保任务完成。Internal handoffs 使用 mesh topology 实现，其中每个 agent 都连接到其他 agents，而不需要 orchestrator agent。例如，customer support 或 expert systems 就是这种模式的几个例子：基于 user input，一个 agent 可以处理任务并提供 outcomes。Agent handoffs 基于提供给 agent 的清晰 instructions。

Group chat

这种方式更偏 collaborative，多个 agents 会来回交互。内部使用 star topology，中间有 orchestrator。Orchestrator 会选择如何使用 agents，例如 Round Robin、prompt-based selection，或应用 custom logic 来选择 agents。这些 agents 更适合 research 和 brainstorm 类型 use cases，用多个 ideas 进行分析，然后将它们汇总在一起。

Magnetic

Magnetic 专为 open-ended use cases 构建，支持 dynamic orchestration。它很 flexible，是一个 general purpose multi-agent application 模式。在 magnetic orchestration 中，magnetic manager 会协调一个 agent team 来完成任务。

当我们不知道 workflow 时，Magnetic 很有价值。路径没有预定义，magnetic manager 会自行找出路径并执行 tasks。例如，包含多轮 chain-of-thought 的 research-type use cases 非常适合这种模式。另一个例子是，如果我要研究特定 materials 和新 materials，magnetic 可以在后台通过 multiple turns 运行并产出 ideas。不过，这种 multi-agent pattern 的执行也确实需要时间。

Building a multi-agent application using magnetic orchestration

对于下面的代码，以下是为 brainstorming agentic application 创建的 individual agents。在我们的 brainstorming multi-agent 示例中，使用了以下 individual agents：

• Ideation agent
• Inquiry agent
• Business analyst agent
• Technical advisor agent
• Strategic analyst agent
• Resource planning agent
• Success metrics agent
• Technical architecture agent

这些 agents 代表不同 personas，并通过协作来生成、分析和 refine ideas，用于构建 solution。

由于这是 code-first implementation，因此需要 Python development environment。下面的设置使用 Visual Studio Code：

1. 打开 Visual Studio Code。
2. 打开 Terminal → New Terminal，在 Visual Studio Code 中启动 integrated terminal。运行 python version 验证 Python 已安装。
3. 使用 Command Palette 创建 virtual environment，选择 Python: Create Environment，并选择 .venv with Python 3.12。确保安装了正确版本的 azure-ai-projects 和 azure-ai-agents。我们之前已经做过介绍——这里需要重新构想现有 application functionality。首先安装。
4. 等待 environment 创建完成。创建完成后，你应该会在 Visual Studio Code 左侧 file explorer 中看到 .venv folder。
5. 接下来进入 View -> Command Palette -> Python: Select Interpreter，并选择刚才创建的解释器。上述步骤是任何 Python-based development 都常见的步骤。
6. 接下来使用 pip install 安装上面提到的 azure-ai-projects 和 azure-ai-agents SDK。
7. 安装其他必要 libraries：

pip install python-dotenv
pip install agent-framework
pip install azure-ai-projects

8. 现在创建一个新的 Python file 来编写代码。

Environment 准备好后，我们来看代码片段，了解如何使用 Microsoft Foundry 中已有 agents。

现在先设置 agent provider，用于复用 Microsoft Foundry 中的 agents。

client = AzureOpenAIResponsesClient(
        project_endpoint`load_dotenv()`

接下来，初始化 project client：

= os.environ["AZURE_AI_PROJECT_ENDPOINT"],
        deployment_name = os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"],

我们使用 DefaultAzureCredential，这是推荐的安全方式。随着代码 promoted 到更高 environments，例如 UAT、Testing、Production，DefaultAzureCredential 会自动使用 managed identity。

Credential = DefaultAzureCredential(),

为了最安全的实现，我们遵循 zero-trust principles，并使用 user-assigned managed identity。代码很直接：创建一个 agent。关键部分是 instructions field，它描述 agent 做什么。instructions field 充当 prompt，定义 orchestrator 应如何行为。tools parameter 包含 multi-agent orchestrator 使用的所有 individual agent definitions。这里仍然使用 brainstorming use case。所有 individual agents 的完整代码可在本书 GitHub repository 中找到。这正是帮助 orchestrator 做出决策的部分。运行一次 Python file，即可在 Azure AI Foundry 中创建并注册 agent。

    provider = AzureAIProjectAgentProvider(
        credential=DefaultAzureCredential(),
        project_endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
    )

上述代码本质上设置了 responses object，用于调用 Microsoft Foundry agent。请确保使用合适的 Microsoft Foundry project endpoint 配置 environment variables。Authentication 使用 azure.identity 中的 logged-in user。相比 key-based authentication，这更安全。而且在多数 enterprise 中，key-based authentication 可能已被禁用。

现在是调用已有 agent 的代码。在我的例子中，我使用这些 agents：

    ideaagent = await provider.get_agent(name="ideaagent")
    business_owner_agent = await provider.get_agent(name="BusinessOwnerAgent")

也可以列出所有 agents，并按名称查找，而不是 hardcoding asset ID。

接下来，我们创建一个 thread 用于 execution。实际 execution 在 Azure 中运行，而触发它的代码可以在本地或任何能运行 Python 的地方运行。跟踪 token usage 对理解 agentic AI applications 的成本非常重要。

    business_architect_agent = await provider.get_agent(name="BusinessArchitectAgent")
    solution_architect_agent = await provider.get_agent(name="SolutionArchitectAgent")
    raia_agent = await provider.get_agent(name="RAIAgent")
    architecture_summarizer_agent = await      provider.get_agent(name="ArchitectureSummarizerAgent")

这些 agents 都是 persona-based agents，用于帮助 software architect 基于 business requirements 设计新的 application。这些 agents 会从不同视角提供 ideas，以形成最终 response。

现在我们创建 magnetic manager，并通过 instructions 说明如何为 task 选择 agents：

manager_agent = Agent(
        name="MagenticManager",
        description="Orchestrator that coordinates the idea agent, business owner agent, business architect agent, solution architect agent, RAIAgent, and architecture summarizer agent to complete the task efficiently.",
        instructions="""You coordinate a team to complete complex tasks efficiently.
        - You have access to the following agents: ideaagent, business owner agent, business architect agent, solution architect agent, RAIAgent.
        - Pick the right agent(s) for each step of the task, and coordinate handoffs between agents.
        - At the end use the architecture summarizer agent to summarize the final architecture and reasoning in a clear and concise manner.
        You are a routing manager.
        You must invoke each participant exactly once, in the given order.
        Do not re-invoke any agent.
        Do not request revisions or follow-ups.
        Terminate immediately after the final agent completes.
        """,
        client=client,
    )

Magnetic manager 需要 agent name，然后提供 description，说明如何协调这些 agents。Instruction 是真正基于 task 的 prompt，用于向 manager 提供指令，说明我们有哪些不同 agents，并指定如何选择 agents 和 guardrails。下一项是使用的 client，也就是 OpenAI responses client。我也提供了本书展示用的 sample prompt。请仅将其用于信息和教育目的。

现在该构建 magnetic workflow 了。下面的代码本质上接收 magnetic manager 和其他 individual agents，并创建一个 workflow，将 magnetic manager 作为 router，并指定使用其他 agents 来完成任务。

    workflow = MagenticBuilder(
        participants=[
            ideaagent, business_owner_agent,
            business_architect_agent,
            solution_architect_agent, raia_agent,
            architecture_summarizer_agent,
        ],
        intermediate_outputs=True,
        manager_agent=manager_agent,
        max_round_count=6,
        max_stall_count=0,
        max_reset_count=6,
    ).build()

如果你注意上面的语法，会看到要消费的 agents 位于 participants list 中，它们是 Microsoft Foundry agents。请注意，manager_agent 正是我们刚才指定的 agent，其中有 instructions，说明如何最好地使用 agents，以及要执行什么 router task。还有其他参数，例如 intermediate_outputs，在我的例子中设置为 true，用于查看 individual agents 的输出。我用它来理解和 troubleshoot agents 的 behavior。对于 production use cases，不一定需要保存。

为了有效管理和控制 orchestration 的行为，Manager Agent 提供多个 configuration parameters。这些 settings 对治理 agents 如何协作、防止 infinite loops、处理 stalled execution，以及确保 workflow 在 cost 和 performance 的定义限制内完成非常重要。通过调优这些参数，可以让 workflow 更 predictable、efficient 和 resilient。

下面是 Manager Agent 使用的参数：

Max round count：在 workflow 停止之前允许的最大 total coordination rounds，即使任务尚未完成，也会返回 partial result。每个 “round” 通常是一项 agent action + manager decision。可用它防止 infinite loops 或控制 cost / latency。例如，max_round_count = 6 会将整个 collaboration 限制在 6 个 rounds 内。

max_stall_count：在 manager 触发 replan，也就是更新 task ledger / plan 之前，允许的连续无 detectable progress 的最大 rounds。Progress 通常通过 progress ledger 或 fact updates 衡量。设置为 0 可禁用 stall detection。这可以防止 team 陷入无产出的 loops。

Max_reset_count：在 workflow fail 之前，允许 complete plan resets 的最大次数。Reset 是比 replan 更强的动作，例如当当前 plan 根本上已经 broken 时。这是 major recoveries 的 safety limit。

在本节中，我们探索了如何使用 code-first approach 构建 multi-agent orchestration。我们配置了 Python environment，复用了 Foundry 中的 agents，并实现了基于 Magentic 的 orchestration pattern，其中 manager agent 会协调多个 specialized agents。

这种方法支持创建 flexible、reusable 和 scalable 的 multi-agent systems，并可以集成到 enterprise applications 中。

Summary

本章中，我们以 presales、solution architecture、forward engineering 和 professional services 等真实场景中的 brainstorming-based digital team 为 use case，探索了如何构建 multi-agent application。我们考察了多个 specialized agents 如何协作，以处理复杂 tasks 和 workflows。

我们首先使用 Microsoft Foundry workflows 和 Microsoft Agent Framework 实现了 multi-agent orchestration。这包括定义 orchestration logic、配置 agents，并指定 instructions 来引导 agent behavior。我们也探索了有效创建和执行 agent workflows 所需的关键 properties 和 configurations。

此外，我们回顾了 Foundry 中可用的不同 workflow templates，例如 Sequential、Human-in-the-Loop 和 Group Chat，并讨论了它们各自的 use cases。随后，我们转向 code-first approach，使用 Magentic builder 实现了一个 Magentic manager，用于动态协调多个 agents，并基于 user input 进行智能 agent selection。

总体而言，本章展示了如何为真实世界场景设计和实现 multi-agent、agentic AI applications。

第 10 章中，你将学习如何使用各种 metrics 评估 models 和 agents，以确保 agentic applications 对 end users 来说安全可靠。这包括评估 bias、harmful content 和 jailbreak behavior 等方面。你还将探索使用 red teaming agents 的 threat analysis techniques，使 cybersecurity teams 能够识别潜在 risks，并制定合适 mitigation strategies。

在本章中，我们以 presales brainstorming digital team 为 use case，构建了一个 multi-agent application。我们学习了如何创建 individual agents，将它们包装为 connected agent tools，并构建 orchestrator agent 来协调它们。我们还覆盖了如何执行 agents、捕获 token usage，并解析 orchestrator 和 individual agents 的 outputs。这为你使用 Azure AI Foundry 构建真实世界 multi-agent applications 奠定了基础。