azure-functions-agents

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Azure Functions Agents

Use this skill to build event-driven AI agents on Azure Functions with the Azure Functions serverless agents runtime. This programming model is new, so prefer these patterns over older package README examples.

使用本Skill在Azure Functions上借助Azure Functions无服务器Agent运行时构建事件驱动型AI Agent。该编程模型为全新模型，因此相比旧版包的README示例，建议优先采用这些模式。

Current Defaults

当前默认配置

Scaffold with Microsoft Foundry as the model provider.
Scaffold files may keep
```
gpt-4.1
```
as the safe Bicep fallback, but before provisioning or deploying, check the user's subscription/region for the best deployable GPT model and quota.
Prefer the newest deployable GPT reasoning model with remaining quota when available, such as
```
gpt-5.4
```
or newer. Only configure reasoning settings for models known to support them. Older models can fail if
```
AZURE_FUNCTIONS_AGENTS_REASONING_*
```
settings are present.
For
```
gpt-5.x
```
and other reasoning-capable models, use reasoning effort
```
high
```
by default,
```
xhigh
```
only when the selected model supports it, and reasoning summary
```
concise
```
.
If an agent needs web browsing, current public data, browser automation, data analysis, or code execution, use Azure Container Apps dynamic sessions. Do not write custom web-fetch tools for those cases.
Use remote MCP servers and connection MCP servers from
```
mcp.json
```
.
Use Connector Namespaces, represented as
```
Microsoft.Web/connectorGateways
```
resources in Bicep.
Generated apps should include a ready-to-edit
```
src/local.settings.json
```
, not only a template.

Generated

requirements.txt

must use the official PyPI package:

azurefunctions-agents-runtime

以Microsoft Foundry作为模型提供商搭建框架。
框架文件可能保留
```
gpt-4.1
```
作为安全的Bicep回退选项，但在配置或部署前，请检查用户的订阅/区域，选择最适合部署的GPT模型及配额。
若有可用配额，优先选择最新的可部署GPT推理模型，例如
```
gpt-5.4
```
或更新版本。仅为已知支持推理设置的模型配置推理参数。若存在
```
AZURE_FUNCTIONS_AGENTS_REASONING_*
```
设置，旧版模型可能运行失败。
对于
```
gpt-5.x
```
及其他支持推理的模型，默认使用推理强度
```
high
```
，仅当所选模型支持时才使用
```
xhigh
```
，推理摘要默认设为
```
concise
```
。
若Agent需要网页浏览、当前公开数据、浏览器自动化、数据分析或代码执行功能，请使用Azure Container Apps动态会话。此类场景下请勿编写自定义网页抓取工具。
使用
```
mcp.json
```
中的远程MCP服务器和连接MCP服务器。
使用Connector Namespaces，在Bicep中表示为
```
Microsoft.Web/connectorGateways
```
资源。
生成的应用应包含可直接编辑的
```
src/local.settings.json
```
，而非仅提供模板。

生成的

requirements.txt

必须使用官方PyPI包：

azurefunctions-agents-runtime

。

Progressive References

递进式参考文档

Load only the files needed for the task:

Need	Reference
Required files and scaffold contents	project-files.md
Agent frontmatter, triggers, built-in endpoints	agent-files.md
Trigger schemas, connector triggers, built-in endpoint routes	triggers.md
Built-in chat APIs, session IDs, built-in MCP tools	built-in-endpoints.md
Local/deployed testing recipes by trigger type	testing.md
Foundry model defaults, upgrades, reasoning settings	models.md
Dynamic sessions for code execution and web browsing	sessions.md
Connector Namespace overview, naming, and safety boundaries	connectors.md
Connector MCP server configs, authorization, `mcp.json` , and inspection	connector-mcp.md
Connector operation IDs, schemas, dynamic parameters, and Teams target IDs	connector-schemas.md
Connector-triggered agents and trigger config deployment	connector-triggers.md
Custom Python tools and Agent Skills	tools-and-skills.md
Writing robust agent instructions	agent-authoring.md
Bicep, azd, deployment, local development	infra-and-deployment.md
Diagnostics and common failures	troubleshooting.md
Full quickstart app copied into this skill	quickstart-reference.md

仅加载任务所需的文件：

需求	参考文档
必需文件与框架搭建内容	project-files.md
Agent前置元数据、触发器、内置端点	agent-files.md
触发器模式、连接器触发器、内置端点路由	triggers.md
内置聊天API、会话ID、内置MCP工具	built-in-endpoints.md
按触发器类型分类的本地/部署后测试方案	testing.md
Foundry模型默认配置、升级、推理设置	models.md
用于代码执行和网页浏览的动态会话	sessions.md
Connector Namespaces概述、命名及安全边界	connectors.md
连接器MCP服务器配置、授权、 `mcp.json` 及检查	connector-mcp.md
连接器操作ID、模式、动态参数及Teams目标ID	connector-schemas.md
连接器触发的Agent及触发器配置部署	connector-triggers.md
自定义Python工具与Agent Skills	tools-and-skills.md
编写可靠的Agent指令	agent-authoring.md
Bicep、azd、部署、本地开发	infra-and-deployment.md
诊断与常见故障	troubleshooting.md
完整的快速入门应用示例	quickstart-reference.md

Assess the Workspace

工作区评估

Before editing, inspect the app. Look for:

src/function_app.py

importing

create_function_app()

```
src/*.agent.md
```
```
src/agents.config.yaml
```
```
src/mcp.json
```
```
src/tools/
```
and
```
src/skills/
```
```
src/local.settings.json
```

infra/main.bicep

infra/app/*.bicep

infra/main.parameters.json

```
azure.yaml
```
```
.azure/*/config.json
```
for existing
```
azd
```
environments

For existing apps, read the current files and preserve the app's structure. Current apps should use explicit

builtin_endpoints

trigger.args

, Foundry provider settings,

agents.config.yaml

for shared runtime defaults, and Connector Namespace MCP entries in

mcp.json

When inspecting deployed connectors, remember that Connector Namespace resources live under

Microsoft.Web/connectorGateways

. Connections are

connectorGateways/<gateway>/connections

, MCP server configs are

connectorGateways/<gateway>/mcpserverconfigs

, and trigger configs are

connectorGateways/<gateway>/triggerconfigs

. Do not search for legacy top-level

Microsoft.Web/connections

to find Connector Namespace connections.

编辑前，请检查应用内容，确认是否存在以下文件：

src/function_app.py

中是否导入

create_function_app()

```
src/*.agent.md
```
```
src/agents.config.yaml
```
```
src/mcp.json
```
```
src/tools/
```
和
```
src/skills/
```
目录
```
src/local.settings.json
```

infra/main.bicep

、

infra/app/*.bicep

、

infra/main.parameters.json

```
azure.yaml
```
```
.azure/*/config.json
```
（用于现有
```
azd
```
环境）

对于现有应用，请读取当前文件并保留应用结构。现有应用应使用显式的

builtin_endpoints

、

trigger.args

、Foundry提供商设置、用于共享运行时默认值的

agents.config.yaml

，以及

mcp.json

中的Connector Namespace MCP条目。

检查已部署的连接器时，请记住Connector Namespace资源位于

Microsoft.Web/connectorGateways

下。连接信息存储在

connectorGateways/<gateway>/connections

，MCP服务器配置存储在

connectorGateways/<gateway>/mcpserverconfigs

，触发器配置存储在

connectorGateways/<gateway>/triggerconfigs

。请勿搜索旧版顶级

Microsoft.Web/connections

来查找Connector Namespace的连接信息。

Discuss and Plan the Agent

Agent需求沟通与规划

When the user says they want to create an agent, do not jump straight to files unless the request already contains enough detail. First learn enough to shape the app and discuss a short plan.

Ask only the questions needed to move forward, usually covering:

Goal: What should the agent accomplish, and what should a successful run produce?
Invocation: Should it be chat/API-driven, scheduled, event-triggered, connector-triggered, or some combination?
Inputs and outputs: What data starts the run, and should the result be returned, logged, emailed, posted, drafted, stored, or sent somewhere else?
Interactive surfaces: Does the user want to chat with the agent, expose a chat/API surface, stream responses, or expose the agent as a built-in MCP tool? Enable built-in endpoints only for those interactive scenarios.
Tools and services: Does it need web/code execution, Microsoft Learn, Office 365, Teams, Azure Resource Manager, storage, queues, databases, or custom APIs?
Teams targets: If the agent needs a Teams team, channel, or chat target, ask the user to paste a Teams link and parse IDs from it on their behalf. Do not ask them to manually find raw team IDs, channel IDs, or chat IDs.
Safety boundaries: For actions like email, Teams posts, ticket creation, or resource changes, should the agent draft, ask for confirmation, or act automatically?
Model selection: Which Azure subscription and region should be checked for GPT model access and quota? If the user has not specified them, use the current Azure CLI subscription and the planned
```
AZURE_LOCATION
```
.
Deployment preference: Default to building and deploying to Azure with
```
azd up
```
, but offer to run locally first if the user wants a local iteration loop.

Do not ask the user to estimate runtime duration unless the workflow is obviously unusual or may run longer than the standard background-agent defaults. Set practical timeouts yourself: keep simple chat/API agents at the runtime default, set timer, connector-triggered, queue, and other background agents to 30 minutes, and align

host.json

functionTimeout

to the longest agent timeout. For synchronous HTTP work that may take longer than about 230 seconds, choose a background/deferred pattern instead of relying on a longer HTTP response.

Do not add

builtin_endpoints

or a

main.agent.md

debug/chat agent just to test a scheduled, timer, connector-triggered, queue, or other background workflow. If the user asks for a chat bot, debug chat UI, chat API, streaming API, or says they want to talk to the agent, enable the appropriate built-in endpoints for that agent or add a separate interactive agent. Otherwise, verify background agents with the admin invoke endpoint and Application Insights.

After the discovery, summarize the plan before editing. Include the agent files, trigger or built-in endpoints, model choice, tools/MCP/connectors, infrastructure changes, and how it will be tested. If the user has already provided enough detail, make reasonable choices and proceed.

当用户表示想要创建Agent时，除非请求已包含足够细节，否则请勿直接开始编写文件。首先需了解足够信息来规划应用并讨论简短方案。

仅询问推进工作所需的问题，通常包括：

目标：Agent需要完成什么任务？成功运行后应生成什么结果？
触发方式：是聊天/API驱动、定时触发、事件触发、连接器触发，还是多种方式组合？
输入输出：运行的起始数据是什么？结果应返回、记录、发送邮件、发布、草拟、存储还是发送至其他位置？
交互界面：用户是否需要与Agent聊天、暴露聊天/API界面、流式返回响应，还是将Agent作为内置MCP工具？仅在这些交互场景下启用内置端点。
工具与服务：是否需要网页/代码执行、Microsoft Learn、Office 365、Teams、Azure Resource Manager、存储、队列、数据库或自定义API？
Teams目标：若Agent需要Teams团队、频道或聊天目标，请让用户粘贴Teams链接并代为解析ID。请勿要求用户手动查找原始团队ID、频道ID或聊天ID。
安全边界：对于发送邮件、发布Teams消息、创建工单或修改资源等操作，Agent应草拟内容、请求确认还是直接执行？
模型选择：应检查哪个Azure订阅和区域的GPT模型访问权限及配额？若用户未指定，则使用当前Azure CLI订阅和计划的
```
AZURE_LOCATION
```
。
部署偏好：默认使用
```
azd up
```
构建并部署到Azure，但如果用户希望先进行本地迭代，可提供本地运行选项。

除非工作流明显特殊或可能超过标准后台Agent的默认运行时长，否则请勿要求用户估算运行时长。自行设置合理的超时时间：简单的聊天/API Agent保留运行时默认值，定时、连接器触发、队列及其他后台Agent设为30分钟，并将

host.json

中的

functionTimeout

与最长的Agent超时时间保持一致。对于可能超过约230秒的同步HTTP任务，请选择后台/延迟模式，而非依赖更长的HTTP响应超时。

对于定时、计时器、连接器触发、队列或其他后台工作流，请勿仅为测试目的添加

builtin_endpoints

或

main.agent.md

调试/聊天Agent。若用户要求聊天机器人、调试聊天UI、聊天API、流式API，或表示想要与Agent对话，则为该Agent启用相应的内置端点或添加单独的交互式Agent。否则，使用管理调用端点和Application Insights验证后台Agent。

完成需求调研后，在编辑前总结方案，包括Agent文件、触发器或内置端点、模型选择、工具/MCP/连接器、基础设施变更及测试方式。若用户已提供足够细节，则做出合理选择并推进工作。

Scaffold a New App

搭建新应用框架

Use the complete reference sample at assets/quickstart-sample as the safest starting point. Copy it into the target project, then tailor it to the user's agent instead of inventing a project structure from memory.

Baseline structure:

text

<project-root>/
  azure.yaml
  infra/
    abbreviations.json
    main.bicep
    main.parameters.json
    app/
      api.bicep
      connector-gateway.bicep
      trigger-config.bicep        # if using connector triggers
      foundry.bicep
      rbac.bicep
      session-pool.bicep
      session-pool-rbac.bicep
  src/
    function_app.py
    host.json
    local.settings.json
    requirements.txt
    .funcignore
    agents.config.yaml
    main.agent.md              # only when the user wants chat/API/MCP endpoints
    <agent-name>.agent.md
    mcp.json

Default scaffold choices:

Python 3.13 in Bicep.
Foundry provider. Keep
```
gpt-4.1
```
in template defaults only as a safe fallback.
Before running
```
azd provision
```
or
```
azd up
```
, run the model and quota checks in models.md, recommend the best deployable GPT model, and set the
```
FOUNDRY_MODEL
```
,
```
FOUNDRY_MODEL_NAME
```
,
```
FOUNDRY_MODEL_VERSION
```
,
```
FOUNDRY_DEPLOYMENT_CAPACITY
```
, and reasoning env vars when a better reasoning-capable model is selected.
No reasoning app settings unless the app is explicitly upgraded to a reasoning-capable model.
ACA dynamic session pool when any agent needs code execution or web browsing.
Optional Office 365 Outlook connection MCP server when
```
TO_EMAIL
```
is set.
Built-in endpoints only when the scenario is interactive. Do not add debug chat UI, chat API, streaming API, built-in MCP, or a general
```
main.agent.md
```
to a scheduled-only/background-only app unless the user asked for that surface.
Explicit timeout settings: use
```
functionTimeout: "00:30:00"
```
in
```
host.json
```
for background-capable apps, keep simple chat/API agents at
```
timeout: 900
```
, and set timer, connector-triggered, queue, or other long-running background agents to
```
timeout: 1800
```
unless the task clearly needs more.
Connector-triggered apps use the preview extension bundle and a second-step trigger config deployment after the
```
connector_extension
```
system key exists.
```
local.settings.json
```
includes local storage and Foundry/MCP placeholders.

After copying, remove or adjust sample-specific agents and instructions. Keep infrastructure modules only when the app needs them.

以assets/quickstart-sample中的完整参考示例作为最安全的起点。将其复制到目标项目中，然后根据用户的Agent需求进行调整，而非凭空创建项目结构。

基准结构：

text

<project-root>/
  azure.yaml
  infra/
    abbreviations.json
    main.bicep
    main.parameters.json
    app/
      api.bicep
      connector-gateway.bicep
      trigger-config.bicep        # 使用连接器触发器时需包含
      foundry.bicep
      rbac.bicep
      session-pool.bicep
      session-pool-rbac.bicep
  src/
    function_app.py
    host.json
    local.settings.json
    requirements.txt
    .funcignore
    agents.config.yaml
    main.agent.md              # 仅当用户需要聊天/API/MCP端点时包含
    <agent-name>.agent.md
    mcp.json

默认框架选择：

Bicep中使用Python 3.13。
Foundry作为模型提供商。仅将
```
gpt-4.1
```
作为模板默认的安全回退选项。
在运行
```
azd provision
```
或
```
azd up
```
前，执行models.md中的模型和配额检查，推荐最佳可部署GPT模型，并在选择更优的支持推理的模型时设置
```
FOUNDRY_MODEL
```
、
```
FOUNDRY_MODEL_NAME
```
、
```
FOUNDRY_MODEL_VERSION
```
、
```
FOUNDRY_DEPLOYMENT_CAPACITY
```
及推理环境变量。
除非应用明确升级到支持推理的模型，否则不添加推理应用设置。
当任何Agent需要代码执行或网页浏览功能时，使用ACA动态会话池。
设置
```
TO_EMAIL
```
时，可选添加Office 365 Outlook连接MCP服务器。
仅在交互式场景下启用内置端点。除非用户明确要求，否则请勿为仅定时/仅后台应用添加调试聊天UI、聊天API、流式API、内置MCP或通用
```
main.agent.md
```
。
显式超时设置：适用于后台任务的应用在
```
host.json
```
中设置
```
functionTimeout: "00:30:00"
```
，简单聊天/API Agent保留
```
timeout: 900
```
，定时、连接器触发、队列或其他长时间运行的后台Agent设为
```
timeout: 1800
```
（除非任务明确需要更长时间）。
连接器触发的应用使用预览扩展包，并在
```
connector_extension
```
系统密钥存在后进行第二步触发器配置部署。
```
local.settings.json
```
包含本地存储和Foundry/MCP占位符。

复制完成后，移除或调整示例特定的Agent和指令。仅保留应用所需的基础设施模块。

Local Development First Rule

本地开发优先规则

Default to deploying new apps to Azure with

azd up

; these agents are designed for managed identity, Foundry, dynamic sessions, Connector Namespaces, Application Insights, and Functions hosting. Offer to run locally first when the user wants to iterate before deploying, and explain the local tools required.

Local prerequisites:

Azure Developer CLI (
```
azd
```
)
Azure Functions Core Tools v4
Python 3.13+

Azurite, when using

AzureWebJobsStorage=UseDevelopmentStorage=true

Azure CLI login for local managed-identity-equivalent access

When an app uses Foundry, dynamic sessions, or connector MCP servers, run

azd provision

before local development. Local

func start

still calls real Azure resources for model, session pool, and connector operations.

Local loop:

```
azd init
```
```
azd provision
```

Copy outputs from

azd env get-values

into

src/local.settings.json

Start Azurite with
```
azurite --skipApiVersionCheck
```
.
From
```
src
```
, create a venv, install requirements, and run
```
func start
```
.

The scaffolded Bicep grants the deployer/local user access to Foundry and the session pool, and connection access policies when optional connectors are enabled.

默认将新应用部署到Azure（使用

azd up

）；这些Agent专为托管标识、Foundry、动态会话、Connector Namespaces、Application Insights和Functions托管设计。当用户希望在部署前进行迭代时，提供本地运行选项并说明所需的本地工具。

本地开发 prerequisites：

Azure Developer CLI (
```
azd
```
)
Azure Functions Core Tools v4
Python 3.13+

Azurite（当使用

AzureWebJobsStorage=UseDevelopmentStorage=true

时）

Azure CLI登录（用于本地等效托管标识访问）

当应用使用Foundry、动态会话或连接器MCP服务器时，在本地开发前需运行

azd provision

。本地

func start

仍会调用真实的Azure资源来处理模型、会话池和连接器操作。

本地开发流程：

```
azd init
```
```
azd provision
```

将

azd env get-values

的输出复制到

src/local.settings.json

中。

使用
```
azurite --skipApiVersionCheck
```
启动Azurite。
在
```
src
```
目录下创建虚拟环境，安装依赖，然后运行
```
func start
```
。

搭建的Bicep会为部署者/本地用户授予Foundry和会话池的访问权限，以及启用可选连接器时的连接访问策略。

Build or Modify Agents

构建或修改Agent

Each

.agent.md

file defines one agent. Use YAML frontmatter for runtime configuration and markdown for behavior. The file stem becomes the function name and built-in endpoint route segment.

Choose endpoints from the scenario, not from testing convenience. Scheduled-only, timer, connector-triggered, queue, and other background agents should omit

builtin_endpoints

unless the user asks to talk to that agent, expose it as an API, or expose it as a built-in MCP tool. Use the admin endpoint and Application Insights to test background agents.

Current trigger example:

yaml

---
name: Daily Report
description: Sends a daily report.

trigger:
  type: timer_trigger
  args:
    schedule: "0 0 15 * * *"

mcp: true
---

Current built-in endpoint example:

yaml

---
name: Chat Agent
description: Interactive agent for testing.

builtin_endpoints:
  debug_chat_ui: true
  chat_api: true
  mcp: true

mcp: false
---

Load agent-files.md before adding less common frontmatter fields.

每个

.agent.md

文件定义一个Agent。使用YAML前置元数据进行运行时配置，使用Markdown定义行为。文件名前缀将成为函数名称和内置端点路由段。

根据场景选择端点，而非出于测试便利。仅定时、计时器、连接器触发、队列及其他后台Agent应省略

builtin_endpoints

，除非用户要求与该Agent对话、将其暴露为API或内置MCP工具。使用管理端点和Application Insights测试后台Agent。

当前触发器示例：

yaml

---
name: Daily Report
description: Sends a daily report.

trigger:
  type: timer_trigger
  args:
    schedule: "0 0 15 * * *"

mcp: true
---

当前内置端点示例：

yaml

---
name: Chat Agent
description: Interactive agent for testing.

builtin_endpoints:
  debug_chat_ui: true
  chat_api: true
  mcp: true

mcp: false
---

添加不太常见的前置元数据字段前，请先查阅agent-files.md。

Model Selection Guidance

模型选择指南

For new scaffolds, keep

gpt-4.1

as the safe Bicep default, but actively try to select the best deployable GPT model before provisioning. Use

az cognitiveservices model list

and

az cognitiveservices usage list

to check the user's subscription, target region, model version, deployment SKU, and quota. See models.md for copyable commands.

Do not silently deploy

gpt-4.1

just because it is the template default. Either run the model and quota checks and choose/recommend a better deployable model, or state why the checks could not be run and then use

gpt-4.1

without reasoning settings.

Recommend the newest deployable GPT reasoning model with remaining quota. Ask the user to choose when there are meaningful tradeoffs, such as newer/slower/costlier reasoning models versus smaller mini/nano models. If no reasoning-capable model has quota, or if availability/quota discovery cannot determine what the user can deploy, use

gpt-4.1

without reasoning settings.

When selecting a reasoning-capable model, confirm reasoning support from the Azure OpenAI reasoning models documentation, then set model and reasoning values together. Use reasoning effort

high

by default,

xhigh

only when the selected model supports it and the user wants maximum reasoning with possible latency/cost tradeoffs, and reasoning summary

concise

对于新框架，将

gpt-4.1

作为安全的Bicep默认选项，但在配置前需主动选择最佳可部署GPT模型。使用

az cognitiveservices model list

和

az cognitiveservices usage list

检查用户的订阅、目标区域、模型版本、部署SKU和配额。可参考models.md中的可复制命令。

请勿仅因

gpt-4.1

是模板默认选项就静默部署。要么执行模型和配额检查并选择/推荐更优的可部署模型，要么说明无法执行检查的原因，然后使用不带推理设置的

gpt-4.1

。

推荐有剩余配额的最新可部署GPT推理模型。当存在有意义的权衡时（例如更新/更慢/成本更高的推理模型与更小的mini/nano模型），请让用户选择。若没有支持推理的模型有可用配额，或无法确定用户可部署的模型，则使用不带推理设置的

gpt-4.1

。

选择支持推理的模型时，请先确认Azure OpenAI推理模型文档中的推理支持情况，然后同时设置模型和推理参数。默认使用推理强度

high

，仅当所选模型支持且用户希望最大化推理能力（可能存在延迟/成本权衡）时才使用

xhigh

，推理摘要默认设为

concise

。

Deploy and Verify

部署与验证

For new apps, use

azd up

from the project root. If the user has agreed to deploy, run the deployment commands yourself instead of stopping after printing them. Set required

azd

env vars, run

azd init

when needed, run model/quota checks before provisioning, confirm the active Azure subscription, then run

azd up

with a generous timeout. Pause only for information you genuinely need from the user, such as a missing recipient email, region choice, subscription confirmation, or portal-only connector authorization. Do not route secrets through chat.

Before

azd provision

azd up

, run

az account show --query "{name:name,id:id,tenantId:tenantId}"

and show the selected subscription to the user unless they already explicitly named the subscription for this deployment. If it is not the intended subscription, have the user choose or run

az account set --subscription <subscription-id>

before provisioning. Do not deploy to whichever Azure CLI subscription happens to be active without making that choice visible.

Unless the user explicitly asks for continuous deployment, deploy from the local workspace with

azd up

. Do not create GitHub Actions workflows, CI/CD pipeline files, repository secrets, or run

azd pipeline config

for a normal app deployment request.

After deployment, verify outputs with

azd env get-values

, open or provide the relevant app URL, show the user how to get the default function key only when built-in chat UI/API endpoints are present, open Connector Namespace authorization links when connectors are present, check connection status, and run a smoke test when practical. For timer or other non-HTTP agents, manually trigger the function with the admin endpoint after deployment, then query Application Insights requests, traces, and exceptions for that run. For built-in chat agents, open or provide the

/agents/<slug>/

URL and call the chat API if useful. Do not rely on

az functionapp log tail

for Flex Consumption agent diagnostics.

Be hands-on after scaffolding. Do not stop at a command list when the next command is safe and the user already approved the direction. Run

azd up

, open authorization URLs, run

azd env get-values

, test deployed endpoints, and report the results. Stop only for user-only actions such as signing in to authorize a connector, selecting an ambiguous option, or entering secrets.

When creating backing Azure resources beyond this skill's bundled Bicep, use Azure docs. If the agent needs searchable docs context, ask the user to connect the Microsoft Learn MCP server at

https://learn.microsoft.com/api/mcp

Useful endpoints:

Chat UI, when enabled:
```
/agents/<agent-file-stem>/
```
Chat API, when enabled:
```
POST /agents/<agent-file-stem>/chat
```

Streaming chat API, when enabled:

POST /agents/<agent-file-stem>/chatstream

MCP endpoint, when enabled:
```
/runtime/webhooks/mcp
```
Manual non-HTTP trigger:
```
POST /admin/functions/<agent-file-stem>
```

对于新应用，从项目根目录运行

azd up

。若用户同意部署，请自行运行部署命令，而非仅打印命令后停止。设置必需的

azd

环境变量，必要时运行

azd init

，配置前执行模型/配额检查，确认活动Azure订阅，然后使用足够长的超时时间运行

azd up

。仅在确实需要用户提供信息时暂停，例如缺少收件人邮箱、区域选择、订阅确认或仅能通过门户完成的连接器授权。请勿通过聊天传递密钥。

在

azd provision

或

azd up

前，运行

az account show --query "{name:name,id:id,tenantId:tenantId}"

并向用户显示所选订阅（除非用户已明确指定本次部署的订阅）。若不是预期订阅，请让用户选择或运行

az account set --subscription <subscription-id>

后再进行配置。请勿在未告知用户的情况下部署到当前Azure CLI的活动订阅。

除非用户明确要求持续部署，否则从本地工作区使用

azd up

进行部署。对于常规应用部署请求，请勿创建GitHub Actions工作流、CI/CD管道文件、仓库密钥或运行

azd pipeline config

。

部署完成后，使用

azd env get-values

验证输出，打开或提供相关应用URL，仅当存在内置聊天UI/API端点时向用户展示如何获取默认函数密钥，当存在连接器时打开Connector Namespace授权链接，检查连接状态，并在可行时运行冒烟测试。对于计时器或其他非HTTP Agent，部署后使用管理端点手动触发函数，然后查询Application Insights中该次运行的请求、跟踪和异常信息。对于内置聊天Agent，打开或提供

/agents/<slug>/

URL，必要时调用聊天API。请勿依赖

az functionapp log tail

进行Flex Consumption Agent诊断。

搭建框架后需亲自动手操作。当下一个命令安全且用户已批准方向时，请勿仅停留在命令列表阶段。运行

azd up

、打开授权URL、运行

azd env get-values

、测试已部署的端点并报告结果。仅在需要用户执行操作时停止，例如登录授权连接器、选择模糊选项或输入密钥。

当需要创建本Skill捆绑Bicep之外的Azure基础资源时，请参考Azure文档。若Agent需要可搜索的文档上下文，请让用户连接Microsoft Learn MCP服务器：

https://learn.microsoft.com/api/mcp

。

常用端点：

启用后的聊天UI：
```
/agents/<agent-file-stem>/
```
启用后的聊天API：
```
POST /agents/<agent-file-stem>/chat
```

启用后的流式聊天API：

POST /agents/<agent-file-stem>/chatstream

启用后的MCP端点：
```
/runtime/webhooks/mcp
```
手动触发非HTTP函数：
```
POST /admin/functions/<agent-file-stem>
```