Microsoft Foundry Agent Service ਲਈ quickstart Python ਲਈ ਲਿਖਿਆ ਗਿਆ ਹੈ। ਇਹ Azure ਦੇ ਅੰਦਰੂਨੀ ਕੰਮਾਂ (plumbing) ਨੂੰ ਇੰਨੀ ਸੰਘਣੀ scaffolding ਦੇ ਅੰਦਰ ਲੁਕਾ ਦਿੰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਇਹ ਜਾਣੇ ਬਿਨਾਂ ਕਿ ਕਿਹੜੇ resources ਅਸਲ ਵਿੱਚ ਬਣਾਏ ਗਏ ਸਨ, ਟਿਊਟੋਰਿਅਲ ਖਤਮ ਕਰ ਸਕਦੇ ਹੋ। ਜੇਕਰ ਤੁਸੀਂ .NET 'ਤੇ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਇੱਕ ਮੁਸ਼ਕਲ ਨਾਲ ਸ਼ੁਰੂਆਤ ਕਰਦੇ ਹੋ: ਸੈਂਪਲ ਗਲਤ ਦਿਸ਼ਾ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੇ ਹਨ, ਪੈਕੇਜ ਦੇ ਨਾਮ ਬਿਨਾਂ ਕਿਸੇ ਚੇਤਾਵਨੀ ਦੇ ਬਦਲ ਜਾਂਦੇ ਹਨ, ਅਤੇ Azure AI Foundry ਤੋਂ Microsoft Foundry ਵਿੱਚ ਹਾਲੀਆ rebrand ਨੇ ਸਰਚ ਰਿਜ਼ਲਟਾਂ ਵਿੱਚ ਦਸਤਾਵੇਜ਼ਾਂ ਦੇ ਦੋ ਸੈੱਟਾਂ ਨੂੰ ਆਪਸ ਵਿੱਚ ਲੜਨ ਲਈ ਛੱਡ ਦਿੱਤਾ ਹੈ।

ਮੈਂ ਹਾਲ ਹੀ ਵਿੱਚ C# ਵਿੱਚ ਆਪਣਾ ਪਹਿਲਾ agent ਬਣਾਇਆ ਹੈ। ਇੱਕ ਵਾਰ ਜਦੋਂ ਤੁਸੀਂ ਫਾਲਤੂ ਦੀਆਂ ਚੀਜ਼ਾਂ (noise) ਨੂੰ ਹਟਾ ਦਿੰਦੇ ਹੋ ਅਤੇ ਜ਼ਰੂਰੀ ਕਦਮਾਂ ਨੂੰ preview-version ਦੀ ਉਲਝਣ ਤੋਂ ਵੱਖ ਕਰ ਲੈਂਦੇ ਹੋ, ਤਾਂ ਇਹ ਸੇਵਾ ਵਧੀਆ ਕੰਮ ਕਰਦੀ ਹੈ। ਇੱਥੇ ਉਹ ਨਕਸ਼ਾ ਹੈ ਜੋ ਮੈਂ ਚਾਹੁੰਦਾ ਸੀ ਕਿ ਮੇਰੇ ਕੋਲ ਪਹਿਲੇ ਦਿਨ ਹੀ ਹੁੰਦਾ।

ਉਹ ਚਾਰ Resources ਜਿਨ੍ਹਾਂ ਦੀ ਤੁਹਾਨੂੰ ਅਸਲ ਵਿੱਚ ਲੋੜ ਹੈ

ਇੱਕ ਬੇਸਿਕ Prompt Agent ਚਲਾਉਣ ਲਈ ਤੁਹਾਨੂੰ ਦਰਜਨਾਂ Azure services ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਤੁਹਾਨੂੰ ਸਿਰਫ਼ ਚਾਰ ਚੀਜ਼ਾਂ ਦੀ ਲੋੜ ਹੈ, ਅਤੇ CLI ਇਹਨਾਂ ਨੂੰ ਇਸ ਤਰੀਕੇ ਨਾਲ ਦਿਖਾਉਂਦਾ ਹੈ ਜਿਸ ਤਰ੍ਹਾਂ Python notebooks ਨਹੀਂ ਕਰਦੇ।

ਪਹਿਲਾਂ, AIServices ਕਿਸਮ ਵਾਲਾ ਇੱਕ Foundry resource। ਇਹ ਉਹਨਾਂ models ਲਈ parent capacity ਵਜੋਂ ਕੰਮ ਕਰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ ਕਾਲ ਕਰੋਗੇ। ਦੂਜਾ, ਉਸ resource ਦੇ ਅੰਦਰ ਇੱਕ project। project ਉਹ scope ਹੈ ਜਿੱਥੇ ਤੁਹਾਡੀਆਂ agent definitions, conversation threads, ਅਤੇ deployment settings ਰਹਿੰਦੀਆਂ ਹਨ। ਤੀਜਾ, ਇੱਕ deployed model। ਇੱਕ ਐਕਟਿਵ deployment ਤੋਂ ਬਿਨਾਂ, agent ਕੋਲ invoke ਕਰਨ ਲਈ ਕੋਈ endpoint ਨਹੀਂ ਹੁੰਦਾ। ਚੌਥਾ, ਆਪਣੀ identity ਲਈ ਇੱਕ role assignment ਤਾਂ ਜੋ SDK project ਦੇ ਵਿਰੁੱਧ authenticate ਕਰ ਸਕੇ।

ਬੱਸ ਇੰਨਾ ਹੀ। ਕੋਈ Kubernetes cluster ਨਹੀਂ, ਕੋਈ custom compute ਨਹੀਂ, conversation history ਲਈ ਕੋਈ manually managed Redis cache ਨਹੀਂ।

Prompt Agents ਬਨਾਮ Hosted Agents

Foundry ਤੁਹਾਨੂੰ agents ਚਲਾਉਣ ਦੇ ਦੋ ਤਰੀਕੇ ਦਿੰਦਾ ਹੈ। ਵਧੇਰੇ ਗੁੰਝਲਦਾਰ ਵਿਕਲਪ ਨੂੰ ਆਪਣਾ ਡਿਫੌਲਟ ਨਾ ਬਣਾਓ।

Prompt Agents ਸੌਖਾ ਰਸਤਾ ਹਨ। ਤੁਸੀਂ ਇੱਕ model ਚੁਣਦੇ ਹੋ, system instructions ਲਿਖਦੇ ਹੋ, ਅਤੇ Foundry ਤੁਹਾਡੇ ਲਈ agent ਚਲਾਉਂਦਾ ਹੈ। ਤੁਸੀਂ compute, containers, ਜਾਂ routing logic ਨੂੰ ਮੈਨੇਜ ਨਹੀਂ ਕਰਦੇ। ਇਹ internal tools, helpdesk bots, ਅਤੇ ਦਸਤਾਵੇਜ਼ਾਂ 'ਤੇ ਸਿੱਧੇ ਸਵਾਲ-ਜਵਾਬ ਲਈ ਢੁਕਵਾਂ ਹੈ।

Hosted Agents ਲਈ ਤੁਹਾਨੂੰ application code ਲਿਖਣ, ਇਸਨੂੰ ਇੱਕ container ਵਜੋਂ package ਕਰਨ, ਅਤੇ ਉਸਨੂੰ Foundry ਨਾਲ ਜੋੜਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਤੁਸੀਂ ਇਸ ਰਸਤੇ ਨੂੰ ਉਦੋਂ ਹੀ ਚੁਣਦੇ ਹੋ ਜਦੋਂ ਤੁਹਾਨੂੰ ਅਜਿਹੀ custom business logic ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਜੋ Foundry prompts ਅਤੇ built-in tools ਰਾਹੀਂ ਪ੍ਰਗਟ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਜਿਵੇਂ ਕਿ non-standard authentication ਦੇ ਨਾਲ ਇੱਕ internal API ਨੂੰ ਕਾਲ ਕਰਨਾ।

ਇਹ ਗਾਈਡ Prompt Agents 'ਤੇ ਕੇਂਦਰਿਤ ਹੈ ਕਿਉਂਕਿ Docker files ਅਤੇ orchestration ਵਿੱਚ ਨਿਵੇਸ਼ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਪੁਸ਼ਟੀ ਕਰਨ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਹੈ ਕਿ ਤੁਹਾਡਾ .NET setup ਸਹੀ ਹੈ।

Command Line ਤੋਂ ਸੈੱਟਅੱਪ ਕਰਨਾ

CLI ਦੀ ਵਰਤੋਂ ਕਰਨ ਨਾਲ ਤੁਸੀਂ ਹਰੇਕ resource ਨੂੰ ਦੇਖਣ ਲਈ ਮਜਬੂਰ ਹੋ ਜਾਂਦੇ ਹੋ, ਜੋ ਕਿ ਬਿਲਕੁਲ ਉਹੀ ਹੈ ਜੋ Python quickstart ਲੁਕਾ ਦਿੰਦਾ ਹੈ। East US 2 ਵਿੱਚ ਇੱਕ resource group ਬਣਾਓ। ਇੱਥੇ region ਦੀ ਚੋਣ ਮਹੱਤਵਪੂਰਨ ਹੈ। Foundry ਟੂਲ ਸਪੋਰਟ ਨੂੰ ਅਸਮਾਨ ਰੂਪ ਵਿੱਚ ਰੋਲ ਆਊਟ ਕਰਦਾ ਹੈ, ਅਤੇ East US 2 ਵਿੱਚ ਵਰਤਮਾਨ ਵਿੱਚ ਸਭ ਤੋਂ ਵਿਸ਼ਾਲ ਸੈੱਟ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਅਜਿਹਾ region ਚੁਣਦੇ ਹੋ ਜਿਸ ਵਿੱਚ code interpreter ਜਾਂ file search tools ਦੀ ਕਮੀ ਹੈ, ਤਾਂ ਤੁਹਾਡੀ agent creation call ਅਸਮਰੱਥ ਸਮਰੱਥਾਵਾਂ (unsupported capabilities) ਬਾਰੇ ਇੱਕ ਅਸਪਸ਼ਟ error ਨਾਲ ਫੇਲ ਹੋ ਜਾਵੇਗੀ।

--allow-project-management ਫਲੈਗ ਦੇ ਨਾਲ Foundry resource ਬਣਾਓ। ਉਸ ਫਲੈਗ ਤੋਂ ਬਿਨਾਂ, resource ਇੱਕ standalone cognitive services endpoint ਬਣਿਆ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਉਹ project-scoped deployments ਨੂੰ ਸਵੀਕਾਰ ਨਹੀਂ ਕਰੇਗਾ ਜਿਨ੍ਹਾਂ ਦੀ agents ਨੂੰ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਫਿਰ project ਬਣਾਓ, ਆਪਣਾ model deploy ਕਰੋ, ਅਤੇ ਆਪਣੇ ਆਪ ਨੂੰ Foundry User ਰੋਲ ਅਸਾਈਨ ਕਰੋ।

Display name ਦੀ ਬਜਾਏ stable role GUID ਦੀ ਵਰਤੋਂ ਕਰੋ:

53ca6127-db72-4b80-b1b0-d745d6d5456d

Tenant 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹੋਏ, role names Azure Active Directory ਵਿੱਚ ਵੱਖ-ਵੱਖ ਗਤੀਆਂ ਨਾਲ ਫੈਲਦੇ ਹਨ। ਇੱਕ ਸੰਸਥਾ ਅੱਜ ਪੋਰਟਲ ਵਿੱਚ Foundry User ਦੇਖਦੀ ਹੈ; ਦੂਜੀ ਨੂੰ ਇਹ ਕਈ ਦਿਨਾਂ ਤੱਕ ਨਹੀਂ ਦਿਖਾਈ ਦੇਵੇਗਾ। GUID ਸਿੱਧਾ definition ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ ਅਤੇ rollout ਦੌਰਾਨ ਫੇਲ ਨਹੀਂ ਹੋਵੇਗਾ। ਇਹ ਇੱਕ ਇਕੱਲੀ ਜਾਣਕਾਰੀ ਤੁਹਾਨੂੰ permission-denied errors ਨੂੰ debug ਕਰਨ ਵਿੱਚ ਇੱਕ ਘੰਟਾ ਬਚਾ ਸਕਦੀ ਹੈ ਜੋ policy ਸਮੱਸਿਆਵਾਂ ਵਾਂਗ ਲੱਗਦੀਆਂ ਹਨ ਪਰ ਅਸਲ ਵਿੱਚ label-resolution ਸਮੱਸਿਆਵਾਂ ਹੁੰਦੀਆਂ ਹਨ।

ਗਲਤ NuGet Package ਤੋਂ ਬਚੋ

ਇੱਥੇ .NET developers ਅਕਸਰ ਫਸ ਜਾਂਦੇ ਹਨ। ਤੁਹਾਨੂੰ ਪੁਰਾਣੇ snippets ਵਿੱਚ Azure.AI.Projects.OpenAI ਦੇ ਹਵਾਲੇ ਦਿਖਾਈ ਦੇਣਗੇ। ਉਹ ਪੈਕੇਜ ਸਿਰਫ preview-only ਹੈ, ਅਤੇ ਇਹ Azure.AI.Extensions.OpenAI ਦੇ ਨਾਲ ਓਵਰਲੈਪ ਹੁੰਦਾ ਹੈ। ਦੋਵੇਂ ਸਮਾਨ namespaces ਵਿੱਚ extension methods ਅਤੇ types ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੇ ਹਨ। ਜੇਕਰ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਨਾਲ-ਨਾਲ ਇੰਸਟਾਲ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਡਾ build ambiguous reference errors ਨਾਲ ਟੁੱਟ ਜਾਂਦਾ ਹੈ ਜੋ