SKILLS
Skill är ett paket — tool är en körbar gräns
Det finns ingen universell standarddefinition av ”skill”. På en plattform kan det betyda instruktioner och resurser; på en annan kod, ett workflow eller en verktygssamling. Beskriv därför alltid innehållet i stället för att lita på etiketten.
Ett tool är mer precist: en anropbar funktion med namn, beskrivning, indataschema, resultat, felbeteende och faktiska behörigheter.
Håll isär instruktion, kontext och handling
- Instruktion/prompt: beskriver arbetssättet.
- Resource eller RAG-källa: tillför kontext som dokument eller databasposter.
- Minne/tillstånd: sparar vad som hänt i eller mellan körningar.
- Tool/function: läser eller förändrar ett externt system.
- Workflow: binder ihop förutbestämda steg och felvägar.
- Skill-paket: kan kombinera flera av ovanstående, beroende på plattform.
MCP:s serverprimitiver tools, resources och prompts hjälper till att hålla tre av dessa roller tydliga, men implementeringen måste fortfarande styra åtkomst och dataflöde.
Dela upp mötesförberedelsen i smala verktyg
En bred ”kalender-skill” med läsning, bokning, ändring och radering gör ett misstag onödigt dyrt. Dela hellre upp den:
- calendar.list_upcoming: läs en begränsad tidsperiod.
- notes.read_by_meeting_id: läs endast behöriga anteckningar.
- agenda.create_draft: skriv ett utkast i sandbox.
- calendar.update_event: separat skrivverktyg som alltid kräver godkännande.
Då kan de tre första användas i test utan att agenten får ändra kalendern.
Läs manifestet, inte marknadsnamnet
Oavsett om en tjänst säger connector, action, plugin, function, tool eller skill behöver du kontrollera samma saker: kodens ursprung, vilka data som skickas, exakta scopes, hemlighetshantering, nätverksåtkomst, loggning, uppdateringar, felbeteende och om verktyget kan ändra något.
En uppladdad fil är kontext. En sparad prompt är en instruktion. En appkoppling är en integration. De blir inte automatiskt en agent eller en säker skill.
Specificera varje tool innan modellen får se det
- Entydigt namn och beskrivning utan överlappande verktyg.
- Strikt indataschema, längdgränser och allowlist för värden.
- Strukturerad output med tydliga felkoder, inte fri text som döljer fel.
- Timeout, rate limit, maxstorlek och idempotens för muterande anrop.
- Separata läs- och skrivfunktioner samt minsta OAuth-scope eller tjänsteroll.
- Godkännandekrav som kodregel, inte bara som en mening i prompten.
- Loggning med redaktion av token, hemligheter och känsliga payloads.
Fler verktyg ger större attackyta
Varje verktyg ökar antalet möjliga fel, prompt-injection-vägar och dataflöden. Börja med en allowlist, läsrättighet och en testidentitet. Lägg till skrivning först när verktyget har egna valideringar, evals och ett fungerande godkännandesteg.
Ta bort verktyg som inte används. Rotera och avgränsa token. Ett verktyg ska neka en otillåten handling även om modellen uttryckligen ber om den.
Skribent, källkontroll och begränsning
Skribent och teknisk källgranskare: Christopher Leijon. Funktioner, protokoll och säkerhetsråd har kontrollerats mot länkade primärkällor .
Extern sakgranskning: Ingen extern systemarkitekt, AI-säkerhetsspecialist eller dataskyddsspecialist har granskat sidan. Materialet är ett praktiskt orienteringsstöd och ersätter inte säkerhetsgranskning, hotmodellering, juridisk bedömning eller organisationens förändringsprocess.
Nästa: Din första agent
Bygg ett minsta säkert agentsystem med tre konkreta exempel.