mirror of
https://github.com/microsoft/agent-framework.git
synced 2026-06-16 21:04:09 +08:00
d5c07f2623
* feat(foundry): add experimental to_prompt_agent converter Adds `to_prompt_agent(agent)`, an experimental converter (`ExperimentalFeature.TO_PROMPT_AGENT`) that turns an Agent Framework `Agent` into a Foundry `PromptAgentDefinition` ready to publish via `AIProjectClient.agents.create_version(...)`. Behaviour: * `agent.client` must be a `FoundryChatClient` (or subclass); otherwise `TypeError` is raised. The model deployment name is lifted from the bound client so the same Agent definition used for local runs can be published as a hosted prompt agent without restating the model. * Foundry SDK tool instances (from `FoundryChatClient.get_*_tool()`) are passed through unchanged. AF `FunctionTool`s (and `@tool`-decorated callables) are emitted as Foundry `FunctionTool` declarations. * Local AF MCP tools cannot be expressed in a `PromptAgentDefinition`; the converter raises `ValueError` and points at `FoundryChatClient.get_mcp_tool()` for hosted MCP servers. * The converter walks both `agent.default_options["tools"]` and `agent.mcp_tools` because `normalize_tools()` splits local MCP off into its own list. Re-exported through the `agent_framework.foundry` lazy-loading namespace (updates both `__init__.py` and the `__init__.pyi` type stub). Adds a portable-agent sample showing the same `Agent` driven through both `agent.run(...)` and `to_prompt_agent(agent)`, and a README section covering the new converter. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * chore(samples): remove snippet tags from portable agent sample Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * chore(samples): inline FoundryChatClient and enable prompt-agent publish Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * chore(samples): drop async credential context manager Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * docs(foundry): trim README to_prompt_agent example to publish-only flow Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * docs(foundry): note FoundryAgent runs @tool callables for deployed prompt agents Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * fix(foundry): address review comments on to_prompt_agent converter * Construct `PromptAgentDefinition` `Tool` from a dict via `**tool_item` unpacking rather than the positional Mapping constructor \u2014 cleaner and matches the typical Pydantic / Azure SDK pattern. * Drop the redundant `isinstance(mcp_tool, MCPTool)` guard in `_convert_tools`; the parameter is already typed `Iterable[MCPTool]` so the second `raise` was unreachable. The remaining single `raise` fires for every entry as intended. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * fix(foundry): match Agent.__init__ model resolution in to_prompt_agent * Read the model from `agent.default_options.get("model")` first, falling back to `agent.client.model`. This mirrors the order `Agent.__init__` uses (`_agents.py:740`) when assembling default_options, so the model the agent runs with is the same model the converter publishes \u2014 e.g. when the caller passes `default_options={"model": "..."}` to override the bound client. * Updated the missing-model error message to point at both the client and the default_options paths. * Added tests: * tool-only agent with no `instructions` produces a definition where `instructions` is `None` and is omitted from the dict payload (`Agent.__init__` strips None values from default_options before storing them). * `default_options['model']` wins over the bound client's model. * Fallback to client.model when default_options has no model. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * feat(foundry): add deploy_as_prompt_agent helper + samples Adds `deploy_as_prompt_agent(agent)`, a convenience wrapper around `to_prompt_agent` that reuses the bound FoundryChatClient's project client to call `project_client.agents.create_version(...)`. Defaults `agent_name` / `description` from `agent.name` / `agent.description` so the Agent stays the single source of truth. * Exposed from `agent_framework_foundry` and the lazy-loading `agent_framework.foundry` namespace (including the .pyi stub). * Marked experimental with the existing `ExperimentalFeature.TO_PROMPT_AGENT` tag. * Tests cover the happy path, name/description defaulting, explicit override, no-name error, metadata + description forwarding, extra kwargs passthrough, and the experimental metadata. Samples: * Renamed the existing sample to `creating_prompt_agents.py`, drops 'portable' wording, presents `deploy_as_prompt_agent` first as the recommended path and `to_prompt_agent` + `AIProjectClient` as the two-step alternative, and adds a cleanup step that deletes the published agent so re-runs stay idempotent. * New `using_prompt_agents.py` shows the end-to-end loop: deploy the agent, connect to it with `FoundryAgent` passing the same local `@tool` callable, run a query against the deployed prompt agent, then clean up. README updated to introduce `deploy_as_prompt_agent` as the recommended path and link to both runnable samples. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * fix(foundry): restore missing-model ValueError in to_prompt_agent The check was accidentally dropped while reworking docstrings in the previous commit. Test `test_to_prompt_agent_rejects_missing_model` exercises this path and was failing on CI as a result. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * refactor(foundry): rename deploy_as_prompt_agent -> create_prompt_agent Renames the helper across the foundry package, core lazy-loader stubs, tests, README and samples. The new name better matches the action performed (a prompt-agent definition is created in Foundry) and is consistent with the surrounding ''create_*'' API surface. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * refactor(foundry): drop create_prompt_agent, enrich to_prompt_agent params Remove the create_prompt_agent helper and consolidate on to_prompt_agent. Expose every PromptAgentDefinition parameter that has either an Agent Framework equivalent (sourced from default_options) or no equivalent (accepted as a keyword argument). * default_options-sourced (with kwarg overrides): temperature, top_p, string tool_choice * kwarg-only Foundry knobs: reasoning, text, structured_inputs, rai_config, ToolChoiceParam tool_choice Precedence is always: explicit keyword > default_options entry > unset. Tests cover every path (defaults, default_options, kwargs, kwarg override). Samples and README rewritten around the enriched to_prompt_agent. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * refactor(foundry): single source of truth for prompt-agent options Stop duplicating the generation-parameter surface between FoundryChatOptions and to_prompt_agent. Translate every field with an Agent Framework equivalent (temperature, top_p, tool_choice, reasoning, response_format/text/verbosity) from agent.default_options via a new RawFoundryChatClient helper _prepare_prompt_agent_options. Only Foundry-specific fields with no AF equivalent — structured_inputs and rai_config — remain as keyword arguments on to_prompt_agent. - tool_choice is dropped when there are no tools (mirrors _prepare_options semantics and avoids polluting tool-less prompt agents with Agent.__init__'s 'auto' default). - response_format Pydantic models route through openai.lib._parsing._responses.type_to_text_format_param; dict shapes go through the existing _prepare_response_and_text_format helper. - default_options is not mutated; text dict is defensively copied. Tests, README, and creating_prompt_agents.py sample updated to reflect the new single-source model. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * docs(foundry): consolidate prompt-agent sample Drop creating_prompt_agents.py (the publish-only variant) and rename using_prompt_agents.py to foundry_prompt_agents.py so the single sample covers the full convert -> publish -> connect -> run loop. Update the README link list accordingly. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * docs(foundry): run local Agent + deployed agent in same sample Add an agent.run() call against the local Agent before publishing, then run the deployed prompt agent on the same query. Expand the docstring with a compare-and-contrast covering runtime/latency, configurability, and persistence/sharing differences between the two execution paths. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * test(foundry): cover conflicting response_format + text.format in to_prompt_agent Exercises the ValueError path when a Pydantic response_format would overwrite an explicit text.format mapping with a different shape. Lifts _chat_client.py coverage from 89% to 90%. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * refactor(foundry): move _prepare_prompt_agent_options into _to_prompt_agent Lift the translation helper off RawFoundryChatClient and into the _to_prompt_agent module as a module-private function that takes the client as its first argument. The chat client no longer needs to carry a method whose only consumer is the prompt-agent converter, while still serving as the source of the request-path helper (_prepare_response_and_text_format) that the converter reuses for dict-shaped response_format values. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * docs(python): codify GA terminology + post-run docs review Add two pieces of guidance to python/AGENTS.md: * Terminology - reserve 'GA' for hosted services; use 'released' or 'stable' for Agent Framework code/features to match the feature-lifecycle stages. * Maintaining Documentation - review AGENTS.md and skills at the end of every run and update any guidance the conversation made stale; before adding a new principle, ask the user to confirm it should be captured. Also pulls in a docstring fix in foundry_prompt_agents.py that swaps the stray 'GA' for 'released', applying the new terminology rule. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * address PR review: strict=True default, Tool._deserialize dispatch, sample cleanup safety - FunctionTool published as strict=True so the server-side schema validation matches what the local FoundryAgent(tools=[same_callable]) dispatcher enforces. AF FunctionTool has no 'strict' attribute, so the safer default is used uniformly instead of silently downgrading to a permissive contract. - _validate_mapping_tool now dispatches through ProjectsTool._deserialize so dict-shaped tools rehydrate to the concrete subclass (FunctionTool, WebSearchTool, ...) via the 'type' discriminator instead of returning a generic Tool. Added a test that asserts isinstance(WebSearchTool) and a new test for the function-typed dict path. - foundry_prompt_agents.py sample now wraps credential + project client in async with and the create_version / run flow in try/finally so a failure on connect or run still deletes the published prompt agent rather than leaving an orphaned, billable resource in the user's Foundry project. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * fix(ci): correct linkspector ignorePattern typo (./pulls -> ./pull) GitHub PR URLs use the singular segment /pull/N (compare to /issues/N for issues). The existing './pulls' ignore pattern never matched anything as a result, so legitimately stale PR links (e.g. PRs deleted from forks) surface as linkspector failures on unrelated PRs. This is the same convention the './issues' rule above already follows. Fixes the markdown-link-check failure on a dangling link in dotnet/src/Microsoft.Agents.AI.DurableTask/CHANGELOG.md. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
235 lines
10 KiB
Markdown
235 lines
10 KiB
Markdown
# Agent Framework Foundry
|
|
|
|
This package contains the Microsoft Foundry integrations for Microsoft Agent Framework, including Foundry chat clients, preconfigured Foundry agents, Foundry embedding clients, and Foundry memory providers.
|
|
|
|
## Toolboxes
|
|
|
|
A *toolbox* is a named, versioned bundle of hosted tool configurations — code interpreter, file search, image generation, MCP, web search, and so on — stored inside a Microsoft Foundry project. Toolboxes let you manage tool configuration once and reuse it across agents.
|
|
|
|
### Authoring a toolbox
|
|
|
|
Toolboxes can be authored two ways:
|
|
|
|
- **Foundry portal** — create and version toolboxes through the UI without touching code.
|
|
- **Programmatically** — use the [`azure-ai-projects`](https://pypi.org/project/azure-ai-projects/) SDK to create, update, and version toolboxes from Python.
|
|
|
|
> Toolbox authoring APIs (`ToolboxVersionObject`, `ToolboxObject`, `project_client.beta.toolboxes.*`) require `azure-ai-projects>=2.1.0`. Earlier versions can only consume toolboxes that already exist.
|
|
|
|
### Using toolboxes with `FoundryAgent`
|
|
|
|
For hosted `FoundryAgent`, the toolbox must already be attached to the agent in the Microsoft Foundry project. Once attached, the agent invokes its toolbox tools transparently — no client-side wiring required — and you interact with the agent the same way you would with any other tool-equipped Foundry agent.
|
|
|
|
### Using toolboxes with `FoundryChatClient`
|
|
|
|
Each toolbox is reachable as an MCP server. Connect to the toolbox's MCP endpoint with `MCPStreamableHTTPTool` — the agent then discovers and calls its tools over MCP at runtime:
|
|
|
|
```python
|
|
from agent_framework import Agent, MCPStreamableHTTPTool
|
|
from agent_framework.foundry import FoundryChatClient
|
|
|
|
async with Agent(
|
|
client=FoundryChatClient(...),
|
|
instructions="You are a helpful assistant. Use the toolbox tools when useful.",
|
|
tools=MCPStreamableHTTPTool(
|
|
name="my_toolbox",
|
|
description="Tools served by my Foundry toolbox",
|
|
url="https://<your-toolbox-mcp-endpoint>",
|
|
),
|
|
) as agent:
|
|
result = await agent.run("What tools are available?")
|
|
print(result.text)
|
|
```
|
|
|
|
## Hosted tool factories
|
|
|
|
`FoundryChatClient` exposes static factory methods that return Foundry SDK tool
|
|
configurations ready to pass to an `Agent`'s `tools=[...]` argument. These
|
|
factories don't require a `FoundryChatClient` instance — you can call them
|
|
statically and reuse the same tool configuration across agents.
|
|
|
|
```python
|
|
from agent_framework import Agent
|
|
from agent_framework.foundry import FoundryChatClient
|
|
|
|
agent = Agent(
|
|
client=FoundryChatClient(...),
|
|
instructions="...",
|
|
tools=[
|
|
FoundryChatClient.get_web_search_tool(),
|
|
FoundryChatClient.get_code_interpreter_tool(),
|
|
],
|
|
)
|
|
```
|
|
|
|
Generally available factories: `get_code_interpreter_tool`,
|
|
`get_file_search_tool`, `get_web_search_tool`,
|
|
`get_image_generation_tool`, `get_mcp_tool`.
|
|
|
|
> **Choosing a web grounding tool.** `get_web_search_tool` is the recommended
|
|
> default — it requires no separate Bing resource and works with Azure OpenAI
|
|
> models out of the box. Reach for `get_bing_grounding_tool` (experimental,
|
|
> see below) when you need finer Bing parameters (`count`, `freshness`,
|
|
> `market`, `set_lang`), are grounding non-OpenAI Foundry models, or are
|
|
> migrating from Grounding with Bing Search on the classic platform — it
|
|
> requires a Grounding with Bing Search Azure resource that you manage.
|
|
> `get_bing_custom_search_tool` (also experimental) is for grounding
|
|
> restricted to a curated list of domains via a Bing Custom Search instance.
|
|
> See the
|
|
> [web grounding overview](https://learn.microsoft.com/azure/foundry/agents/how-to/tools/web-overview)
|
|
> for the full comparison.
|
|
|
|
> **Experimental — `ExperimentalFeature.FOUNDRY_TOOLS`.** The following
|
|
> factories wrap GA Foundry tool SDK classes but are new wrappers in
|
|
> `agent-framework-foundry` and may change before the wrappers themselves
|
|
> reach GA. Calls emit an `ExperimentalWarning` the first time the
|
|
> `FOUNDRY_TOOLS` feature is exercised in a process (then deduplicated).
|
|
|
|
| Factory | Foundry SDK tool |
|
|
|---------|-----------------|
|
|
| `get_azure_ai_search_tool(index_connection_id, index_name, ...)` | `AzureAISearchTool` |
|
|
| `get_bing_grounding_tool(connection_id, ...)` | `BingGroundingTool` |
|
|
|
|
> **Experimental — `ExperimentalFeature.FOUNDRY_PREVIEW_TOOLS`.** The
|
|
> following factories wrap **preview** Foundry tool SDK types — the underlying
|
|
> Foundry capability itself is in preview and may change or be removed before
|
|
> reaching GA. Calls emit a separate `ExperimentalWarning` the first time the
|
|
> `FOUNDRY_PREVIEW_TOOLS` feature is exercised in a process (then
|
|
> deduplicated). Use `FOUNDRY_TOOLS` for "wrapper is new" and
|
|
> `FOUNDRY_PREVIEW_TOOLS` for "underlying Foundry feature is preview".
|
|
|
|
| Factory | Foundry SDK tool |
|
|
|---------|-----------------|
|
|
| `get_sharepoint_tool(connection_id)` | `SharepointPreviewTool` |
|
|
| `get_fabric_tool(connection_id)` | `MicrosoftFabricPreviewTool` |
|
|
| `get_memory_search_tool(memory_store_name, scope, ...)` | `MemorySearchPreviewTool` |
|
|
| `get_computer_use_tool(environment, display_width, display_height)` | `ComputerUsePreviewTool` |
|
|
| `get_browser_automation_tool(connection_id)` | `BrowserAutomationPreviewTool` |
|
|
| `get_bing_custom_search_tool(connection_id, instance_name, ...)` | `BingCustomSearchPreviewTool` |
|
|
| `get_a2a_tool(base_url=..., project_connection_id=..., ...)` | `A2APreviewTool` |
|
|
## Publishing an agent as a Foundry prompt agent
|
|
|
|
> **Experimental — `ExperimentalFeature.TO_PROMPT_AGENT`.** `to_prompt_agent`
|
|
> is a preview API and may change before reaching GA. The warning fires the
|
|
> first time the `TO_PROMPT_AGENT` feature is exercised in a process and is
|
|
> then deduplicated.
|
|
|
|
`to_prompt_agent(agent)` converts an `Agent` whose chat client is a
|
|
`FoundryChatClient` into a Foundry `PromptAgentDefinition` that can be
|
|
published with `AIProjectClient.agents.create_version(...)`. The model is read
|
|
from `default_options["model"]` first and falls back to the bound
|
|
`FoundryChatClient.model` (matching `Agent.__init__`'s resolution order), so
|
|
the same agent definition you run locally can be published as a hosted prompt
|
|
agent without restating the model deployment name.
|
|
|
|
Every generation parameter that has an Agent Framework equivalent is sourced
|
|
from `agent.default_options` and translated into the matching Foundry shape by
|
|
`_prepare_prompt_agent_options` (a module-private helper in
|
|
`agent_framework_foundry._to_prompt_agent` that reuses the chat client's own
|
|
request-path helpers):
|
|
|
|
| `default_options` key | `PromptAgentDefinition` field |
|
|
|---|---|
|
|
| `temperature` | `temperature` |
|
|
| `top_p` | `top_p` |
|
|
| `tool_choice` (dropped when no tools) | `tool_choice` (`str` / `ToolChoiceFunction` / `ToolChoiceAllowed`) |
|
|
| `reasoning` (dict or `Reasoning`) | `reasoning` |
|
|
| `response_format` (dict or `BaseModel`) | `text.format` |
|
|
| `verbosity` | `text.verbosity` |
|
|
| `text` | merged into `text` |
|
|
|
|
This keeps the `Agent` as the single source of truth for everything it can
|
|
already express. Only Foundry-specific fields with no Agent Framework
|
|
equivalent are accepted as keyword arguments on `to_prompt_agent`:
|
|
|
|
- `structured_inputs` — `dict[str, StructuredInputDefinition]`
|
|
- `rai_config` — `RaiConfig`
|
|
|
|
```python
|
|
import asyncio
|
|
import os
|
|
|
|
from agent_framework import Agent
|
|
from agent_framework.foundry import FoundryChatClient, to_prompt_agent
|
|
from azure.ai.projects.aio import AIProjectClient
|
|
from azure.identity.aio import AzureCliCredential
|
|
|
|
|
|
async def main() -> None:
|
|
credential = AzureCliCredential()
|
|
project_endpoint = os.environ["FOUNDRY_PROJECT_ENDPOINT"]
|
|
|
|
agent = Agent(
|
|
client=FoundryChatClient(
|
|
project_endpoint=project_endpoint,
|
|
model="gpt-4o",
|
|
credential=credential,
|
|
),
|
|
name="travel-agent",
|
|
description="Helps Contoso employees book travel.",
|
|
instructions="You are a helpful travel assistant.",
|
|
tools=[
|
|
FoundryChatClient.get_web_search_tool(),
|
|
FoundryChatClient.get_code_interpreter_tool(),
|
|
],
|
|
# Generation parameters set on the Agent flow through automatically.
|
|
default_options={
|
|
"temperature": 0.3,
|
|
"top_p": 0.95,
|
|
"reasoning": {"effort": "medium"},
|
|
},
|
|
)
|
|
|
|
definition = to_prompt_agent(agent)
|
|
|
|
project_client = AIProjectClient(endpoint=project_endpoint, credential=credential)
|
|
created = await project_client.agents.create_version(
|
|
agent_name=agent.name,
|
|
definition=definition,
|
|
description=agent.description,
|
|
)
|
|
print(f"Published {created.name} v{created.version}")
|
|
|
|
|
|
asyncio.run(main())
|
|
```
|
|
|
|
Behaviour:
|
|
|
|
- `agent.client` must be a `FoundryChatClient` (or subclass) — otherwise the
|
|
converter raises `TypeError`.
|
|
- The bound client must have a `model` set — otherwise the converter raises
|
|
`ValueError`.
|
|
- Foundry SDK tool instances returned by `FoundryChatClient.get_*_tool()` are
|
|
passed through unchanged.
|
|
- AF `FunctionTool` instances (and `@tool`-decorated callables) are emitted as
|
|
Foundry `FunctionTool` **declarations** — the prompt agent receives the
|
|
schema only, not the Python implementation. To execute the function when
|
|
invoking the deployed prompt agent, connect with `FoundryAgent` and pass the
|
|
same callable via `tools=`:
|
|
|
|
```python
|
|
from agent_framework.foundry import FoundryAgent
|
|
|
|
deployed = FoundryAgent(
|
|
project_endpoint=project_endpoint,
|
|
agent_name="travel-agent",
|
|
credential=credential,
|
|
tools=[book_hotel], # same @tool-decorated callable used at publish time
|
|
)
|
|
result = await deployed.run("Book me a hotel in Seattle for 3 nights.")
|
|
```
|
|
|
|
`FoundryAgent` runs the function locally when the prompt agent calls it, so
|
|
the declaration on the server and the implementation on the client stay in
|
|
sync via the shared `@tool` definition.
|
|
- Local Agent Framework MCP tools cannot be published as prompt-agent tools —
|
|
the converter raises `ValueError` and points at
|
|
`FoundryChatClient.get_mcp_tool(...)` for hosted MCP servers.
|
|
|
|
See the runnable example under `samples/02-agents/providers/foundry/`:
|
|
|
|
- [`foundry_prompt_agents.py`](../../samples/02-agents/providers/foundry/foundry_prompt_agents.py)
|
|
— publish with `to_prompt_agent`, then connect back with `FoundryAgent` and
|
|
execute the same local `@tool` callable that the deployed prompt agent
|
|
invokes by name.
|