![]()
Předchozí lekce škálovala agenty nahoru do cloudu. Tato je přenáší dolů na jeden stroj. Na konci budete mít funkčního inženýrského asistenta, který uvažuje, volá nástroje, čte vaše soubory a vyhledává ve vaší dokumentaci — aniž by vykonal jediný inference call v cloudu.
Proč byste to chtěli? Tři důvody, které se neustále objevují v reálné inženýrské práci:
Háček je, že vyměňujete špičkový cloudový model za Malý jazykový model (SLM), který běží na vašem CPU, GPU nebo NPU. Tato lekce se týká budování agentů, kteří jsou v rámci tohoto omezení dobří, místo předstírání, že omezení neexistuje.
Tato lekce zahrnuje:
Po dokončení této lekce budete vědět, jak:
Předpokládá se, že jste absolvovali předchozí lekce a jste obeznámeni s:
Také budete potřebovat:
requirements.txt, navíc foundry-local-sdk, openai a chromadb pro tuto lekci.Špičkový cloudový model má stovky miliard parametrů a za sebou datacentrum. SLM má pár miliard parametrů a musí se vejít do paměti RAM vašeho notebooku. Tento rozdíl nastavuje jasná očekávání.
SLM jsou dobré v:
SLM jsou slabší v:
Vítězná strategie pro lokální agenty je tedy: nechte SLM orchestraci a nechte nástroje dělat těžkou práci. Model nemusí znát váš kód — musí vědět, kdy zavolat read_file a search_docs. To přesně odpovídá silným stránkám SLM.
flowchart LR
U[Vývojář] --> A[Lokální SLM agent]
A -->|rozhoduje, který nástroj| T1[přečíst_soubor]
A -->|rozhoduje, který nástroj| T2[hledat_dokumenty RAG]
A -->|rozhoduje, který nástroj| T3[analyzovat_kód]
T1 --> A
T2 --> A
T3 --> A
A --> R[Odpověď, plně na zařízení]
Microsoft Foundry Local je lehký runtime, který stahuje, spravuje a poskytuje modely kompletně na vašem stroji. Jeho nejdůležitější vlastností pro nás je, že vystavuje OpenAI-kompatibilní HTTP endpoint — což znamená, že OpenAI SDK a OpenAI klient v Microsoft Agent Framework fungují proti němu pouze změnou base_url. Vše, co jste se naučili o budování agentů, lze použít přímo; pouze endpoint se přesouvá z cloudu na localhost.
Foundry Local také automaticky vybere nejlepší verzi modelu pro váš hardware — verzi na CPU, CUDA/GPU nebo NPU — takže nemusíte ručně optimalizovat pro každý stroj.
Nainstalujte Foundry Local (viz dokumentaci pro váš OS) a ověřte, že funguje:
# Nainstalujte (například; postupujte podle dokumentace pro vaši platformu)
winget install Microsoft.FoundryLocal # Windows
# brew install microsoft/foundrylocal/foundrylocal # macOS
# Stáhněte a spusťte model Qwen, poté spusťte lokální službu
foundry model run qwen2.5-7b-instruct
foundry service status
Jakmile služba běží, máte lokální OpenAI-kompatibilní endpoint (obvykle http://localhost:PORT/v1). Notebook používá foundry-local-sdk k automatickému nalezení endpointu, takže nemusíte pevně zakódovat port.
Agent je agentem jen pokud může volat nástroje. Mnoho SLM může chatovat, ale vytváří nespolehlivé, nesprávně formátované volání nástrojů. Qwen modely jsou trénovány pro volání funkcí a konzistentně vytvářejí správně formátované volání nástrojů — což přesně mění lokální chat model na lokální agenta.
Průběh je standardní smyčka volání nástrojů, kterou už znáte, jen běží přímo na zařízení:
sequenceDiagram
participant U as Uživatel
participant A as Qwen Agent (místní)
participant T as Místní nástroj
U->>A: "Co dělá auth.py?"
A->>A: Rozhodnout: zavolat read_file
A->>T: read_file("auth.py")
T-->>A: obsah souboru
A->>A: Uvažovat nad obsahem
A-->>U: Vysvětlení
Vyhledávání v dokumentaci je místo, kde si lokální agenti vydělají. Místo toho, abyste doufali, že SLM zapamatoval dokumentaci vašeho frameworku, vložíte tyto dokumenty do lokální vektorové databáze a necháte agenta, aby podle potřeby načítal relevantní úryvky.
Používáme Chromu, vestavěný vektorový obchod, který běží v procesu bez nutnosti správy serveru. Pipeline je kompletně lokální: lokální embedding model → lokální vektory → lokální vyhledávání → lokální SLM.
flowchart TB
D[Vaše dokumenty / kód] --> E[Lokální embedding model]
E --> V[(Chroma vektorová databáze - na disku)]
Q[Dotaz agenta] --> QE[Lokálně vložit dotaz]
QE --> V
V -->|top-k částí| A[Agent Qwen]
A --> Ans[Podložená odpověď]
Toto je stejný Agentic RAG vzor z Lekce 5 — jediná změna je, že všechny komponenty běží na vašem stroji.
MCP je transport, ne cloudová služba. MCP server může běžet jako lokální proces na stdio, poskytující nástroje agentovi přes standardní protokol. To umožňuje znovupoužití rostoucího ekosystému MCP serverů — přístup k souborovému systému, git operace, dotazy do databáze — kompletně offline.
Bezpečnostní postoj je odlišný od cloudu, ale není nulový: lokální MCP server běží s oprávněními vašeho uživatele, proto omeďte, k čemu může přistupovat (adresář projektu, ne celý domovský adresář) a výstupy považujte za vstupy určené ke kontrole.
Lokální-first neznamená pouze lokální. Dospělé systémy směrují dle citlivosti a obtížnosti:
| Situace | Kde běží |
|---|---|
| Citlivý kód / data, nebo offline | Lokální SLM |
| Jednoduchý, ohraničený úkol | Lokální SLM (lacné, rychlé) |
| Těžké vícenásobné uvažování nad necitlivými daty | Cloudový model |
| Vše během výpadku | Lokální SLM (přiměřená degradace) |
To odráží myšlenku model routing z Lekce 16 — až na to, že jeden „model“ je nyní váš vlastní stroj. Robustní design se vrací k lokálnímu modelu, když cloud není dostupný, takže agent klesá v kvalitě, místo aby úplně selhal.
flowchart LR
Q[Požadavek] --> S{Citlivé nebo offline?}
S -->|ano| L[Lokální SLM]
S -->|ne| C{Vyžaduje hluboké uvažování?}
C -->|ne| L
C -->|ano| Cloud[Model v cloudu]
L --> Out[Odpověď]
Cloud --> Out
Otevřete code_samples/17-local-agent-foundry-local.ipynb a projděte jej. Vytvoříte lokálního inženýrského asistenta, který běží kompletně na vašem pracovním stanovišti a umí:
Nikdy se nepoužívá inference z cloudu.
Asistent se připojuje k Foundry Local přes OpenAI-kompatibilní endpoint, takže kód agenta vypadá téměř stejně jako v cloudových lekcích — mění se jen klient:
from foundry_local import FoundryLocalManager
from openai import OpenAI
# Foundry Local objeví/stáhne model a poskytne nám lokální endpoint.
manager = FoundryLocalManager(\"qwen2.5-7b-instruct\")
client = OpenAI(base_url=manager.endpoint, api_key=manager.api_key) # api_key je lokální zástupný symbol
Nástroje jsou obyčejné Python funkce omezené na adresář projektu:
def read_file(path: str) -> str:
\"\"\"Read a file, but only inside the sandboxed project directory.\"\"\"
full = (PROJECT_ROOT / path).resolve()
if PROJECT_ROOT not in full.parents and full != PROJECT_ROOT:
return \"Access denied: path is outside the project directory.\"
return full.read_text(encoding=\"utf-8\")
Všimněte si kontroly sandboxu — i lokálně je nástroj, který čte libovolné cesty, riziko. Notebook omezuje každý nástroj na jednu kořenovou složku projektu.
Otestujte své chápání před přechodem k úkolu.
1. Uveďte dva konkrétní důvody pro spuštění agenta lokálně místo v cloudu.
2. Jaké je doporučené rozdělení práce mezi SLM a jeho nástroji v lokálním agentovi a proč?
3. Co umožňuje znovupoužití cloudového kódu agenta s Foundry Local?
4. Proč konkrétně používáme Qwen model pro volání funkcí místo jakéhokoli SLM?
5. Které komponenty běží v lokální RAG pipeline na stroji?
6. Lokální MCP server běží na vašem stroji. Znamená to automaticky bezpečnost? Jaká opatření byste měli stále přijmout?
7. Popište rozumné hybridní pravidlo směrování, které zahrnuje lokální model.
8. Jaké je realistické minimum RAM pro spuštění lokálního agenta v této lekci a co vám přináší více RAM?
Rozšiřte lokální inženýrského asistenta na lokálního recenzenta dokumentace pro malý projekt podle vašeho výběru (použijte některou z lekčních složek tohoto repozitáře, pokud chcete).
Vaše řešení by mělo:
Přidat nástroj find_todos, který prohledá projekt na komentáře TODO/FIXME a vrátí je s názvem souboru a číslem řádku — při dodržení téže kontroly sandboxu jako read_file.
Poté napište krátký odstavec o tom, co byste přesunuli do cloudu a co byste nechali lokálně pro tohoto recenzenta a proč. Hodnotí se, zda jsou lokální komponenty správně propojené a zda je vaše hybridní uvažování správné — ne kvalita modelu.
V této lekci jste postavili agenta, který běží zcela na vašem vlastním zařízení:
Tím je dokončena fáze nasazení: Lekce 16 škálovala agenty do Microsoft Foundry a tato lekce je škáluje dolů na jednu pracovní stanici. Následující lekce se věnuje zabezpečení nasazených agentů.
Nasazení škálovatelných agentů
Prohlášení o omezení odpovědnosti: Tento dokument byl přeložen pomocí AI překladatelské služby Co-op Translator. Přestože usilujeme o co největší přesnost, mějte prosím na paměti, že automatizované překlady mohou obsahovat chyby nebo nepřesnosti. Originální dokument v jeho mateřském jazyce by měl být považován za autoritativní zdroj. Pro kritické informace se doporučuje profesionální lidský překlad. Nejsme odpovědní za jakékoli nedorozumění nebo nesprávné interpretace vzniklé použitím tohoto překladu.