goose 接入 Azure AI Foundry三种端点类型、协议路由与部署元数据解析实战【免费下载链接】goosean open source, extensible AI agent that goes beyond code suggestions - install, execute, edit, and test with any LLM项目地址: https://gitcode.com/GitHub_Trending/goose3/goose本文以 goose 的azure_foundry提供商为核心完整讲解如何把 goose 会话接入 Azure AI Foundry 的 Project / Resource / MaaS 三类端点包括全部配置环境变量与取值前提、认证优先级Entra 令牌 → API Key → Azure CLI、基于modelPublisher的协议路由机制、部署元数据对上下文窗口的解析以及常见 401/403 与列不出部署问题的排查方法。读完后你可以直接在自己的 Foundry 项目中配置 goose 会话并理解每次请求在底层被路由到哪条推理协议、能力参数从哪里来。一、三种端点类型与对应的推理接口azure_foundry提供商把 goose 连接到 Azure AI Foundry 的模型部署。它区分三种端点形态每种形态的推理接口inference surface不同端点类型端点形态推理接口Foundry 项目Projecthttps://resource.services.ai.azure.com/api/projects/project通过部署发现 按发布者publisher感知路由Foundry 资源Resourcehttps://resource.services.ai.azure.comOpenAI 模型走 ResponsesClaude 走 Anthropic Messages伙伴模型走 Chat CompletionsMaaS / Serverlesshttps://deployment.region.models.ai.azure.com对该端点绑定的模型使用 Chat Completions端点类型的识别并不依赖任何额外配置而是由 goose 在解析AZURE_FOUNDRY_ENDPOINT时自动完成。实现位于 endpoint_kindURL 中包含/api/projects/子串 →Project端点否则主机名以.services.ai.azure.com结尾 →Resource端点其余情况 →MaaS端点。这一点在测试endpoint_type_is_detected中有直接验证crates/goose-providers/src/azure_foundry.rs#L791-L809三类 URL 各归其位。对 Project 端点goose 会用GET /deployments发现项目内的全部模型部署部署名可以被自定义goose 依据返回的modelPublisher字段选择协议并依据modelName解析上下文窗口等模型元数据。Resource 端点不提供项目级部署发现接口goose 只能按模型名/部署名前缀识别模型族gpt-5*和支持的 o 系列走 Responses、claude-*走 Anthropic Messages、其余走 Chat Completions。如果你的部署是自定义别名且无法从名字判断模型族建议使用 Project 端点。二、配置环境变量与 goose configure变量是否必填说明AZURE_FOUNDRY_ENDPOINT是完整的 Foundry 项目或 MaaS 端点AZURE_FOUNDRY_API_KEY否API Key省略时使用 Azure CLI 凭证AZURE_FOUNDRY_MODEL仅 MaaS 必填绑定到所配置 MaaS 端点的模型名AZURE_FOUNDRY_AD_TOKEN否预取的 Microsoft Entra 访问令牌优先级高于 API KeyAZURE_FOUNDRY_API_VERSION否部署发现 API 版本Project 端点默认v1运行goose configure选择Configure Providers再选择Azure AI Foundry即可交互式配置也可以在启动 goose 之前直接设置环境变量export AZURE_FOUNDRY_ENDPOINThttps://my-resource.services.ai.azure.com/api/projects/my-project export AZURE_FOUNDRY_API_KEYkey goose session对于 MaaS 端点export AZURE_FOUNDRY_ENDPOINThttps://my-deployment.eastus.models.ai.azure.com export AZURE_FOUNDRY_API_KEYkey export AZURE_FOUNDRY_MODELmodel-bound-to-this-endpoint goose sessionMaaS 端点只暴露一个已部署模型因此AZURE_FOUNDRY_MODEL对这类端点是硬性要求。这一点在构造阶段就会强制校验AzureFoundryProvider::create 中当端点被识别为 MaaS 而maas_model为空时直接返回错误AZURE_FOUNDRY_MODEL is required for MaaS endpoints。配置项在源码中的定义这些变量在 ProviderDescriptor::metadata 中注册为ConfigKey默认模型为Phi-4并内置一份AZURE_FOUNDRY_KNOWN_MODELS已知模型清单Phi-4、Meta-Llama-3.3-70B-Instruct、Mistral-large-2411、Cohere-command-r-plus、DeepSeek-R1/V3、glm-4.7、Kimi-K2-Instruct、claude-sonnet-4-6、gpt-5、o3 等。当端点不是 Project 端点时即 Resource 或 MaaS 未显式配置模型fetch_supported_models返回的正是这份清单crates/goose-providers/src/azure_foundry.rs#L458-L478。已配置的判定逻辑在 azure_foundry_configured_values端点非空且非 MaaS 端点或 MaaS 端点同时提供了模型名才视为该提供商可用。三、认证优先级与资源标识认证按如下顺序选择AZURE_FOUNDRY_AD_TOKEN预取的 Entra 令牌AZURE_FOUNDRY_API_KEYAzure CLI 默认凭证链当两者都未配置时先执行az login再启动 goose 即可az login这条优先级链直接对应 AzureAuth::new_with_resource 中的模式匹配(Some(token), _) BearerToken(None, Some(key)) ApiKey(None, None) DefaultCredential。Project 与 Resource 端点为https://ai.azure.com申请令牌MaaS 端点则申请https://ml.azure.com的令牌。两个资源标识符定义在 azure_foundry_def.rsAZURE_PROJECT_ENTRA_RESOURCE/AZURE_MAAS_ENTRA_RESOURCE并在from_env中按端点类型选择。认证头的实现细节不同端点/凭证组合使用不同的请求头策略见 from_envAPI Key 用于 Project/Resource以api-key头发送并启用同源重定向限制API Key 用于 MaaS改用标准Authorization: Bearer头API Key 用于 Anthropic 面/anthropic使用x-api-key头Entra 令牌以Authorization: Bearer token发送。关于重定向限制值得单独说明当认证方式是 API Key 时客户端会限制重定向只在同源内跟随configured_client 中的with_same_origin_redirects。测试 foundry_api_keys_do_not_follow_cross_origin_redirects 验证了这一点若源服务器把带api-key/x-api-key头的请求 307 重定向到其他域客户端会直接报错且目标域不会收到任何请求——这是为了防止 API Key 通过跨域重定向泄漏。同域重定向则正常跟随foundry_api_keys_follow_same_origin_redirects测试。四、协议路由publisher 感知与降级策略Project 端点的三路分发对 Project 端点goose 依据 Azure 返回的部署元数据为每个部署选择协议发布者OpenAI且为 Responses 兼容模型gpt-5*与支持的 o 系列→POST /openai/v1/responses发布者Anthropic→POST /anthropic/v1/messages更老的 OpenAI 模型与其他所有发布者 →POST /openai/v1/chat/completions核心路由函数是 inference_route。测试 routing_matrix_uses_endpoint_publisher_and_underlying_model 给出了完整的判定矩阵端点发布者底层模型路由结果MaaSOpenAIgpt-5MaasChatCompletionsMaaSAnthropicclaude-sonnet-4-6MaasChatCompletionsProjectOpenAIgpt-5ProjectResponsesProjectOpenAIo3-miniProjectResponsesProjectOpenAIgpt-4oProjectChatCompletionsProjectPartnergpt-5ProjectChatCompletionsProjectAnthropic任意AnthropicMessages其中Responses 兼容模型的判定来自 is_openai_responses_model正则(?i)(?:^|[-/])(?:o\d(?:$|-)|gpt-5(?:$|[-.]))同时匹配gpt-5、gpt-5.x如gpt-5.6-sol以及o1/o3-mini这类 o 系列命名。注意路由的语义路由由发布者和底层模型共同决定与部署的显示名无关。比如 Partner 发布者的gpt-5部署仍然走 Chat Completions因为协议选择以 publisher 为准而 Anthropic 发布者下的任何部署都走 Messages 面。三个推理客户端的构建Provider 构造时会同时准备最多四个 HTTP 客户端AzureFoundryProvider::createChat 客户端OpenAI 兼容协议。Project/Resource 端点的路径前缀是openai/v1/MaaS 端点是v1/——这与文档中MaaS 端点始终走/v1/chat/completions一致Responses 客户端仅非 MaaS 端点构建base path 为openai/v1/responses并跳过规范化过滤skip_canonical_filteringAnthropic 客户端仅非 MaaS 端点构建请求发往https://resource.services.ai.azure.com/anthropic代码中取端点的/api/projects/之前的部分作为 hub并附加anthropic-version头Deployments 客户端用于调用GET /deployments做部署发现。部署发现不可用时的降级当部署发现暂时不可用时gpt-5*/o 系列这类可识别的 Responses 兼容名与claude-*名仍会落到各自的 native 协议其余名字走 Chat Completions。从源码结构看这套降级由两层缓存机制支撑DeploymentCache 与 deployment_for部署元数据带 60 秒 TTLDEPLOYMENT_METADATA_TTL_SECS单次拉取有 5 秒超时DEPLOYMENT_METADATA_TIMEOUT_SECS避免元数据接口抖动阻塞推理请求缓存区分两种用途上下文发现ContextDiscovery和推理路由InferenceRouting。即使上次拉取失败空缓存也允许用于上下文发现避免每次推理都重试拖慢响应但推理路由会在 TTL 内重试拉取测试 routing_retries_cached_deployment_failures 精确验证了这个不对称行为。部署列表拉取分页与 api-versionfetch_deployments 实现了一个标准的 OData 风格分页循环首次请求deployments?api-versionversion其中 version 取AZURE_FOUNDRY_API_VERSIONProject 端点缺省为v1响应体的value数组中每项含name部署名、modelName底层模型、modelPublisher发布者缺失modelName时回退为部署名缺失modelPublisher时用模型名前缀推断ModelPublisher::from_model_name跟随nextLink翻页并用 with_api_version 保证分页链接上携带同一api-version若链接已带该参数则不覆盖。测试pagination_link_keeps_api_version覆盖了两种情形。测试 deployment_discovery_is_paginated_and_preserves_underlying_model 用 wiremock 模拟了两页部署数据验证翻页与name → modelName/publisher映射的完整性。五、模型元数据上下文窗口、能力与定价部署 API 返回name、modelName、modelVersion、modelPublisher。goose 用底层模型名modelName在内置模型目录中查找上下文窗口部署显示名只作为ModelInfo.name保留。核心逻辑在 model_info_for_deployment先按原始名、小写名、以及剥离-high/-low等推理强度后缀后的基名三次尝试在 canonical 目录中查找配合extract_reasoning_effort解析 effort 后缀查到后取其limit.context作为context_limitreasoning取目录值、否则按模型名启发式判定显式的GOOSE_CONTEXT_LIMIT或会话级覆盖始终优先。测试给出的具体数值可以作为验证依据deployment_metadata_enriches_context_without_pricing部署名production-chat、底层gpt-5解析出上下文窗口400_000且input_token_cost/output_token_cost均为Nonegpt_5_6_sol_uses_its_full_context_windowgpt-5.6-sol的上下文窗口为1_050_000且标记为推理模型custom_deployment_context_uses_underlying_model通过get_context_limit(production-chat)得到的 400K 窗口完全来自底层modelName的目录查表caller_override_precedes_deployment_metadata调用方显式传入Some(64_000)时直接返回 64K且完全不会发起部署发现请求——即覆盖值优先于元数据。关于定价Azure 的计费取决于区域、SKU、合同与部署类型deployments API 不提供可靠的每 token 价格因此该提供商不会为发现的部署附加任何价格信息对应上面input_token_cost: None等字段。六、关键实战细节自定义部署名的别名保留这是该提供商最有价值的行为之一你在会话中使用的模型名始终是你的部署名别名goose 不会把它重写成底层模型名底层模型名仅用于内部的能力判断上下文窗口、max_tokens、是否推理模型等。以 Project 端点的stream实现为例crates/goose-providers/src/azure_foundry.rs#L534-L609wire_model发往 Azure 的请求体中的model字段即部署别名capability_model取自部署元数据的modelName用于套用 canonical 能力上限三个路由分支都同时携带两者stream_for_model(capability_config, wire_model, capability_model, ...)。测试 custom_openai_deployment_uses_alias_and_underlying_capabilities 验证了部署名production-chat底层gpt-5请求确实命中/openai/v1/responses且请求体model production-chat。suffixed_deployment_without_metadata_is_preserved_on_the_wire 则验证了另一种边缘场景部署发现返回空列表时名为gpt-5-high的别名既保留在线上报文中又通过名字前缀解析出 400K 上下文——即无元数据时按可识别名字前缀降级的完整闭环。对 Anthropic 面anthropic_alias_uses_underlying_output_limit_and_preserves_override 展示了 max_tokens 的解析部署claude-prod底层claude-sonnet-4-6默认输出上限取底层模型的 canonical 值128_000而用户显式设置max_tokens: 12_345时则原样透传。此外在会话恢复session resume路径上deserialize_session_model_config 对azure_foundry做了特殊处理恢复model_name与request_params例如thinking_effort确保带后缀的部署别名如gpt-5-high在跨会话恢复后不被规范化改写crates/goose/src/model_config.rs#L42-L48 也对该提供商跳过了常规的 canonical 上限套用以保持部署别名原样。七、排障手册401 / 403确认 API Key 属于你所配置的端点使用 Entra 认证时重新执行az login并确认你的身份对该 Foundry 项目有访问权限不要混用Project 端点的 Key 不能用于 MaaS 端点反之亦然两者的资源标识与认证头策略都不同见上文第三节的api-key/Bearer差异。另外401 也可能出在部署发现接口上fetch_supported_models对 Project 端点会把发现接口的认证失败原样向上抛出测试 project_inventory_failure_is_propagated表现为模型列表拉取直接失败——此时先检查端点 Key 是否有效。列不出部署确认端点 URL 中包含/api/projects/project后缀缺少它会让你落到 Resource 端点分支从而返回内置的已知模型清单而非项目部署列表确认项目中确实存在模型部署如果项目使用了非默认部署发现 API 版本设置AZURE_FOUNDRY_API_VERSION注意该参数只影响GET /deployments的查询不影响推理请求。自定义部署名路由到了错误的协议刷新提供商的模型列表让 goose 重新拉取部署元数据元数据缓存 60 秒过期且推理路由用途在拉取失败后 TTL 内会重试。没有部署元数据时路由只能依据可识别的模型名前缀——所以给部署起gpt-5*/o\d/claude-*之外的自定义名字时务必确保发现接口可用。八、小结一张表看清请求走向把上面各节的规则合并任一goose session请求的实际走向如下场景请求路径相对端点请求体model字段协议选择依据Project OpenAI 发布者 gpt-5*/o 系列endpoint/openai/v1/responses部署别名modelPublisher 底层模型名Project Anthropic 发布者hub/anthropic/v1/messages部署别名modelPublisherProject 其他含老版 OpenAI、伙伴模型endpoint/openai/v1/chat/completions部署别名modelPublisherResource无部署发现与 Project 相同的三个接口模型/部署名仅模型名前缀MaaSendpoint/v1/chat/completionsAZURE_FOUNDRY_MODEL绑定的模型固定 Chat Completions理解这套别名保留、能力按底层模型解析、协议按发布者路由的设计后你可以在 Foundry 中随意重命名部署例如按环境区分的production-chat、gpt-5-high而不必改动 goose 侧的任何模型声明上下文窗口、输出上限等能力仍会正确解析。相关实现集中在 crates/goose-providers/src/azure_foundry.rs端点识别、路由、部署缓存与全套测试、crates/goose/src/providers/azure_foundry_def.rs环境变量装配与认证头策略和 crates/goose/src/providers/azureauth.rs凭证优先级与令牌获取。【免费下载链接】goosean open source, extensible AI agent that goes beyond code suggestions - install, execute, edit, and test with any LLM项目地址: https://gitcode.com/GitHub_Trending/goose3/goose创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 goose 接入 Azure AI Foundry：三种端点类型、协议路由与部署元数据解析实战
goose 接入 Azure AI Foundry三种端点类型、协议路由与部署元数据解析实战【免费下载链接】goosean open source, extensible AI agent that goes beyond code suggestions - install, execute, edit, and test with any LLM项目地址: https://gitcode.com/GitHub_Trending/goose3/goose本文以 goose 的azure_foundry提供商为核心完整讲解如何把 goose 会话接入 Azure AI Foundry 的 Project / Resource / MaaS 三类端点包括全部配置环境变量与取值前提、认证优先级Entra 令牌 → API Key → Azure CLI、基于modelPublisher的协议路由机制、部署元数据对上下文窗口的解析以及常见 401/403 与列不出部署问题的排查方法。读完后你可以直接在自己的 Foundry 项目中配置 goose 会话并理解每次请求在底层被路由到哪条推理协议、能力参数从哪里来。一、三种端点类型与对应的推理接口azure_foundry提供商把 goose 连接到 Azure AI Foundry 的模型部署。它区分三种端点形态每种形态的推理接口inference surface不同端点类型端点形态推理接口Foundry 项目Projecthttps://resource.services.ai.azure.com/api/projects/project通过部署发现 按发布者publisher感知路由Foundry 资源Resourcehttps://resource.services.ai.azure.comOpenAI 模型走 ResponsesClaude 走 Anthropic Messages伙伴模型走 Chat CompletionsMaaS / Serverlesshttps://deployment.region.models.ai.azure.com对该端点绑定的模型使用 Chat Completions端点类型的识别并不依赖任何额外配置而是由 goose 在解析AZURE_FOUNDRY_ENDPOINT时自动完成。实现位于 endpoint_kindURL 中包含/api/projects/子串 →Project端点否则主机名以.services.ai.azure.com结尾 →Resource端点其余情况 →MaaS端点。这一点在测试endpoint_type_is_detected中有直接验证crates/goose-providers/src/azure_foundry.rs#L791-L809三类 URL 各归其位。对 Project 端点goose 会用GET /deployments发现项目内的全部模型部署部署名可以被自定义goose 依据返回的modelPublisher字段选择协议并依据modelName解析上下文窗口等模型元数据。Resource 端点不提供项目级部署发现接口goose 只能按模型名/部署名前缀识别模型族gpt-5*和支持的 o 系列走 Responses、claude-*走 Anthropic Messages、其余走 Chat Completions。如果你的部署是自定义别名且无法从名字判断模型族建议使用 Project 端点。二、配置环境变量与 goose configure变量是否必填说明AZURE_FOUNDRY_ENDPOINT是完整的 Foundry 项目或 MaaS 端点AZURE_FOUNDRY_API_KEY否API Key省略时使用 Azure CLI 凭证AZURE_FOUNDRY_MODEL仅 MaaS 必填绑定到所配置 MaaS 端点的模型名AZURE_FOUNDRY_AD_TOKEN否预取的 Microsoft Entra 访问令牌优先级高于 API KeyAZURE_FOUNDRY_API_VERSION否部署发现 API 版本Project 端点默认v1运行goose configure选择Configure Providers再选择Azure AI Foundry即可交互式配置也可以在启动 goose 之前直接设置环境变量export AZURE_FOUNDRY_ENDPOINThttps://my-resource.services.ai.azure.com/api/projects/my-project export AZURE_FOUNDRY_API_KEYkey goose session对于 MaaS 端点export AZURE_FOUNDRY_ENDPOINThttps://my-deployment.eastus.models.ai.azure.com export AZURE_FOUNDRY_API_KEYkey export AZURE_FOUNDRY_MODELmodel-bound-to-this-endpoint goose sessionMaaS 端点只暴露一个已部署模型因此AZURE_FOUNDRY_MODEL对这类端点是硬性要求。这一点在构造阶段就会强制校验AzureFoundryProvider::create 中当端点被识别为 MaaS 而maas_model为空时直接返回错误AZURE_FOUNDRY_MODEL is required for MaaS endpoints。配置项在源码中的定义这些变量在 ProviderDescriptor::metadata 中注册为ConfigKey默认模型为Phi-4并内置一份AZURE_FOUNDRY_KNOWN_MODELS已知模型清单Phi-4、Meta-Llama-3.3-70B-Instruct、Mistral-large-2411、Cohere-command-r-plus、DeepSeek-R1/V3、glm-4.7、Kimi-K2-Instruct、claude-sonnet-4-6、gpt-5、o3 等。当端点不是 Project 端点时即 Resource 或 MaaS 未显式配置模型fetch_supported_models返回的正是这份清单crates/goose-providers/src/azure_foundry.rs#L458-L478。已配置的判定逻辑在 azure_foundry_configured_values端点非空且非 MaaS 端点或 MaaS 端点同时提供了模型名才视为该提供商可用。三、认证优先级与资源标识认证按如下顺序选择AZURE_FOUNDRY_AD_TOKEN预取的 Entra 令牌AZURE_FOUNDRY_API_KEYAzure CLI 默认凭证链当两者都未配置时先执行az login再启动 goose 即可az login这条优先级链直接对应 AzureAuth::new_with_resource 中的模式匹配(Some(token), _) BearerToken(None, Some(key)) ApiKey(None, None) DefaultCredential。Project 与 Resource 端点为https://ai.azure.com申请令牌MaaS 端点则申请https://ml.azure.com的令牌。两个资源标识符定义在 azure_foundry_def.rsAZURE_PROJECT_ENTRA_RESOURCE/AZURE_MAAS_ENTRA_RESOURCE并在from_env中按端点类型选择。认证头的实现细节不同端点/凭证组合使用不同的请求头策略见 from_envAPI Key 用于 Project/Resource以api-key头发送并启用同源重定向限制API Key 用于 MaaS改用标准Authorization: Bearer头API Key 用于 Anthropic 面/anthropic使用x-api-key头Entra 令牌以Authorization: Bearer token发送。关于重定向限制值得单独说明当认证方式是 API Key 时客户端会限制重定向只在同源内跟随configured_client 中的with_same_origin_redirects。测试 foundry_api_keys_do_not_follow_cross_origin_redirects 验证了这一点若源服务器把带api-key/x-api-key头的请求 307 重定向到其他域客户端会直接报错且目标域不会收到任何请求——这是为了防止 API Key 通过跨域重定向泄漏。同域重定向则正常跟随foundry_api_keys_follow_same_origin_redirects测试。四、协议路由publisher 感知与降级策略Project 端点的三路分发对 Project 端点goose 依据 Azure 返回的部署元数据为每个部署选择协议发布者OpenAI且为 Responses 兼容模型gpt-5*与支持的 o 系列→POST /openai/v1/responses发布者Anthropic→POST /anthropic/v1/messages更老的 OpenAI 模型与其他所有发布者 →POST /openai/v1/chat/completions核心路由函数是 inference_route。测试 routing_matrix_uses_endpoint_publisher_and_underlying_model 给出了完整的判定矩阵端点发布者底层模型路由结果MaaSOpenAIgpt-5MaasChatCompletionsMaaSAnthropicclaude-sonnet-4-6MaasChatCompletionsProjectOpenAIgpt-5ProjectResponsesProjectOpenAIo3-miniProjectResponsesProjectOpenAIgpt-4oProjectChatCompletionsProjectPartnergpt-5ProjectChatCompletionsProjectAnthropic任意AnthropicMessages其中Responses 兼容模型的判定来自 is_openai_responses_model正则(?i)(?:^|[-/])(?:o\d(?:$|-)|gpt-5(?:$|[-.]))同时匹配gpt-5、gpt-5.x如gpt-5.6-sol以及o1/o3-mini这类 o 系列命名。注意路由的语义路由由发布者和底层模型共同决定与部署的显示名无关。比如 Partner 发布者的gpt-5部署仍然走 Chat Completions因为协议选择以 publisher 为准而 Anthropic 发布者下的任何部署都走 Messages 面。三个推理客户端的构建Provider 构造时会同时准备最多四个 HTTP 客户端AzureFoundryProvider::createChat 客户端OpenAI 兼容协议。Project/Resource 端点的路径前缀是openai/v1/MaaS 端点是v1/——这与文档中MaaS 端点始终走/v1/chat/completions一致Responses 客户端仅非 MaaS 端点构建base path 为openai/v1/responses并跳过规范化过滤skip_canonical_filteringAnthropic 客户端仅非 MaaS 端点构建请求发往https://resource.services.ai.azure.com/anthropic代码中取端点的/api/projects/之前的部分作为 hub并附加anthropic-version头Deployments 客户端用于调用GET /deployments做部署发现。部署发现不可用时的降级当部署发现暂时不可用时gpt-5*/o 系列这类可识别的 Responses 兼容名与claude-*名仍会落到各自的 native 协议其余名字走 Chat Completions。从源码结构看这套降级由两层缓存机制支撑DeploymentCache 与 deployment_for部署元数据带 60 秒 TTLDEPLOYMENT_METADATA_TTL_SECS单次拉取有 5 秒超时DEPLOYMENT_METADATA_TIMEOUT_SECS避免元数据接口抖动阻塞推理请求缓存区分两种用途上下文发现ContextDiscovery和推理路由InferenceRouting。即使上次拉取失败空缓存也允许用于上下文发现避免每次推理都重试拖慢响应但推理路由会在 TTL 内重试拉取测试 routing_retries_cached_deployment_failures 精确验证了这个不对称行为。部署列表拉取分页与 api-versionfetch_deployments 实现了一个标准的 OData 风格分页循环首次请求deployments?api-versionversion其中 version 取AZURE_FOUNDRY_API_VERSIONProject 端点缺省为v1响应体的value数组中每项含name部署名、modelName底层模型、modelPublisher发布者缺失modelName时回退为部署名缺失modelPublisher时用模型名前缀推断ModelPublisher::from_model_name跟随nextLink翻页并用 with_api_version 保证分页链接上携带同一api-version若链接已带该参数则不覆盖。测试pagination_link_keeps_api_version覆盖了两种情形。测试 deployment_discovery_is_paginated_and_preserves_underlying_model 用 wiremock 模拟了两页部署数据验证翻页与name → modelName/publisher映射的完整性。五、模型元数据上下文窗口、能力与定价部署 API 返回name、modelName、modelVersion、modelPublisher。goose 用底层模型名modelName在内置模型目录中查找上下文窗口部署显示名只作为ModelInfo.name保留。核心逻辑在 model_info_for_deployment先按原始名、小写名、以及剥离-high/-low等推理强度后缀后的基名三次尝试在 canonical 目录中查找配合extract_reasoning_effort解析 effort 后缀查到后取其limit.context作为context_limitreasoning取目录值、否则按模型名启发式判定显式的GOOSE_CONTEXT_LIMIT或会话级覆盖始终优先。测试给出的具体数值可以作为验证依据deployment_metadata_enriches_context_without_pricing部署名production-chat、底层gpt-5解析出上下文窗口400_000且input_token_cost/output_token_cost均为Nonegpt_5_6_sol_uses_its_full_context_windowgpt-5.6-sol的上下文窗口为1_050_000且标记为推理模型custom_deployment_context_uses_underlying_model通过get_context_limit(production-chat)得到的 400K 窗口完全来自底层modelName的目录查表caller_override_precedes_deployment_metadata调用方显式传入Some(64_000)时直接返回 64K且完全不会发起部署发现请求——即覆盖值优先于元数据。关于定价Azure 的计费取决于区域、SKU、合同与部署类型deployments API 不提供可靠的每 token 价格因此该提供商不会为发现的部署附加任何价格信息对应上面input_token_cost: None等字段。六、关键实战细节自定义部署名的别名保留这是该提供商最有价值的行为之一你在会话中使用的模型名始终是你的部署名别名goose 不会把它重写成底层模型名底层模型名仅用于内部的能力判断上下文窗口、max_tokens、是否推理模型等。以 Project 端点的stream实现为例crates/goose-providers/src/azure_foundry.rs#L534-L609wire_model发往 Azure 的请求体中的model字段即部署别名capability_model取自部署元数据的modelName用于套用 canonical 能力上限三个路由分支都同时携带两者stream_for_model(capability_config, wire_model, capability_model, ...)。测试 custom_openai_deployment_uses_alias_and_underlying_capabilities 验证了部署名production-chat底层gpt-5请求确实命中/openai/v1/responses且请求体model production-chat。suffixed_deployment_without_metadata_is_preserved_on_the_wire 则验证了另一种边缘场景部署发现返回空列表时名为gpt-5-high的别名既保留在线上报文中又通过名字前缀解析出 400K 上下文——即无元数据时按可识别名字前缀降级的完整闭环。对 Anthropic 面anthropic_alias_uses_underlying_output_limit_and_preserves_override 展示了 max_tokens 的解析部署claude-prod底层claude-sonnet-4-6默认输出上限取底层模型的 canonical 值128_000而用户显式设置max_tokens: 12_345时则原样透传。此外在会话恢复session resume路径上deserialize_session_model_config 对azure_foundry做了特殊处理恢复model_name与request_params例如thinking_effort确保带后缀的部署别名如gpt-5-high在跨会话恢复后不被规范化改写crates/goose/src/model_config.rs#L42-L48 也对该提供商跳过了常规的 canonical 上限套用以保持部署别名原样。七、排障手册401 / 403确认 API Key 属于你所配置的端点使用 Entra 认证时重新执行az login并确认你的身份对该 Foundry 项目有访问权限不要混用Project 端点的 Key 不能用于 MaaS 端点反之亦然两者的资源标识与认证头策略都不同见上文第三节的api-key/Bearer差异。另外401 也可能出在部署发现接口上fetch_supported_models对 Project 端点会把发现接口的认证失败原样向上抛出测试 project_inventory_failure_is_propagated表现为模型列表拉取直接失败——此时先检查端点 Key 是否有效。列不出部署确认端点 URL 中包含/api/projects/project后缀缺少它会让你落到 Resource 端点分支从而返回内置的已知模型清单而非项目部署列表确认项目中确实存在模型部署如果项目使用了非默认部署发现 API 版本设置AZURE_FOUNDRY_API_VERSION注意该参数只影响GET /deployments的查询不影响推理请求。自定义部署名路由到了错误的协议刷新提供商的模型列表让 goose 重新拉取部署元数据元数据缓存 60 秒过期且推理路由用途在拉取失败后 TTL 内会重试。没有部署元数据时路由只能依据可识别的模型名前缀——所以给部署起gpt-5*/o\d/claude-*之外的自定义名字时务必确保发现接口可用。八、小结一张表看清请求走向把上面各节的规则合并任一goose session请求的实际走向如下场景请求路径相对端点请求体model字段协议选择依据Project OpenAI 发布者 gpt-5*/o 系列endpoint/openai/v1/responses部署别名modelPublisher 底层模型名Project Anthropic 发布者hub/anthropic/v1/messages部署别名modelPublisherProject 其他含老版 OpenAI、伙伴模型endpoint/openai/v1/chat/completions部署别名modelPublisherResource无部署发现与 Project 相同的三个接口模型/部署名仅模型名前缀MaaSendpoint/v1/chat/completionsAZURE_FOUNDRY_MODEL绑定的模型固定 Chat Completions理解这套别名保留、能力按底层模型解析、协议按发布者路由的设计后你可以在 Foundry 中随意重命名部署例如按环境区分的production-chat、gpt-5-high而不必改动 goose 侧的任何模型声明上下文窗口、输出上限等能力仍会正确解析。相关实现集中在 crates/goose-providers/src/azure_foundry.rs端点识别、路由、部署缓存与全套测试、crates/goose/src/providers/azure_foundry_def.rs环境变量装配与认证头策略和 crates/goose/src/providers/azureauth.rs凭证优先级与令牌获取。【免费下载链接】goosean open source, extensible AI agent that goes beyond code suggestions - install, execute, edit, and test with any LLM项目地址: https://gitcode.com/GitHub_Trending/goose3/goose创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考