🔧 Ano ang Skill?
Sa konteksto ng AI agents, isang skill (tinatawag din na tool or function) ay isang naka-package, muling magagamit na kakayahan na maaaring i-invoke ng LLM para makipag-ugnayan sa mundo sa labas ng kanyang context window. Binubuo ng skills ang agwat sa pagitan ng pag-unawa sa wika at aktwal na aksyon sa mundo.
May apat na bahagi ang bawat skill:
- Name — isang natatanging identifier na ginagamit ng model upang i-reference ang skill (hal.,
web_search) - Description — natural language na teksto na nagpapaliwanag kung ano ang ginagawa ng skill at kailan ito gagamitin; binabasa ito ng LLM para magpasya kung kailan tatawagin ang skill
- Input schema — isang istrukturadong definisyon ng mga argumento (JSON Schema); pinupunan ito ng model base sa gawain
- Implementation — ang aktwal na code na nagpapatakbo: isang API call, database query, shell command, o anumang iba pang operasyon
Halimbawa: A get_weather ang skill ay may paglalarawang "Fetches current weather for a city", tumatanggap ng { "city": "string" } bilang input, at tumatawag sa isang weather API. Hindi nakikita ng LLM ang API key o HTTP call — tumatanggap lang ito ng resulta pabalik bilang teksto.
⚙️ Paano Gumagana ang Pagtawag ng Tool
Kapag ang isang agent ay may access sa skills, hindi direktang tinatawagan ng LLM ang mga ito — requests isang tawag sa pamamagitan ng pagbuo ng isang istrukturadong output. Isinasagawa ng runtime (ang iyong application code) ang aktwal na tawag at ibinabalik ang resulta. Narito ang buong cycle:
- Tool registration — Ipinapadala ng iyong code sa model ang isang listahan ng magagamit na skills na may kanilang mga paglalarawan at schema
- Model reasoning — Binabasa ng LLM ang gawain at ang magagamit na tools, nagde-decide kung aling tool ang tatawagin at may anong mga argumento
- Tool call request — Naglalabas ang model ng isang istrukturadong "tool call" message (hal.,
{ "tool": "web_search", "args": { "query": "current Gemini models" } }) - Execution — Tinatawagan ng iyong runtime code ang aktwal na function, API, o serbisyo
- Result injection — Idinadagdag pabalik ang resulta sa conversation context
- Continued reasoning — Binabasa ng model ang resulta at tatawag muli ng isa pang tool, magtatanong ng follow-up, o gagawa ng panghuling sagot
Maaaring ulitin ng loop na ito nang maraming beses sa isang turn. Ang isang kumplikadong agentic na gawain ay maaaring tumawag ng 10–20 tool nang sunod-sunod bago magbigay ng panghuling tugon.
📊 Skills vs Plugins vs MCP Servers
Mabilis na nagbago ang terminolohiya. Ganito ang kaugnayan ng mga konsepto ayon sa kasaysayan:
| Era | Name | Paano ito gumana | Status |
|---|---|---|---|
| 2023 | ChatGPT Plugins | User-installable extensions na may OpenAPI spec; tinatawag ng ChatGPT ang mga ito via HTTP | Deprecated (pinalitan ng GPTs + tools) |
| 2023 | OpenAI Function Calling | API-level JSON Schema definitions; naglalabas ang model ng isang istrukturadong function call, ang iyong code ang nagpapatupad nito | Aktibo — pinalitan ang pangalan na "tool use" |
| 2023– | Tool Use / Skills | Pareho sa function calling; pinangalanan ng Anthropic ang "tool use", ginagamit ng iba ang "skills" o "functions" | Aktibo — kasalukuyang standard |
| 2024– | MCP Servers | Standardized protocol (Anthropic, Dec 2024) para sa pag-package at pamamahagi ng mga tool servers; anumang MCP client ay maaaring kumonekta sa anumang MCP server | Aktibo — lumalagong ecosystem |
Pangunahing pagkakaiba: Ang tradisyonal na tool use ay idinedefine inline sa iyong application code. Ang MCP servers ay standalone na proseso na nag-e-expose ng tools sa pamamagitan ng isang standardized protocol — ginagawa silang muling magagamit sa iba't ibang AI clients (Claude Desktop, Cursor, VS Code, custom agents). Magbasa pa: Ano ang MCP.
🗂️ Kategorya ng Tool & Antas ng Panganib
Hindi lahat ng tools ay may parehong panganib. Ang pag-grupo ayon sa antas ng panganib ay tumutulong magtakda ng iyong agent's action space at kung saan maglalagay ng human-in-the-loop checkpoints:
| Category | Examples | Risk | Recommendation |
|---|---|---|---|
| Read-only | web_search, read_file, get_weather, list_dir | Low | Payagang mag-autonomously; i-log ang lahat ng tawag |
| Write (local) | write_file, create_dir, edit_code | Medium | I-scope sa isang sandboxed workspace directory |
| Network / External | send_email, post_to_slack, call_api | Katamtaman–Mataas | HITL approval para sa irreversible sends |
| OS / Shell | run_command, execute_script, install_package | High | Limitahin sa containerized environment; kailangan ang HITL |
| Destructive | delete_file, drop_table, revoke_access | Critical | Laging mangailangan ng tahasang kumpirmasyon ng tao |
🏗️ Anatomiya ng Isang Magandang Skill
Ang pinakamahalagang desisyon sa disenyo para sa isang skill ay ang description. Binabasa ng LLM ang mga paglalarawan para magpasya kung aling tool ang tatawagin — ang isang hindi maayos na isinulat na paglalarawan ay nagreresulta sa maling pagpili ng tool, hindi natatawag na tool, o malabong mga argumento.
Ano ang nagpapabisa sa isang paglalarawan
- Maging malinaw kung kailan ito gagamitin — Mas mabuti ang "Gamitin ang tool na ito kapag nagtatanong ang user tungkol sa real-time na data o kasalukuyang mga kaganapan" kaysa sa "Searches the web"
- Sabihin kung ano ang HINDI nito ginagawa — "Hindi nagbabalik ng historical data na higit sa 30 araw"
- Ilarawan ang output format — "Nagbabalik ng JSON array ng search results na may title, url, at snippet fields"
- Panatilihin sa ilalim ng 200 salita — Ang mga paglalarawan na mas mahaba sa ~200 tokens ay maaaring bumigat sa attention ng model kapag maraming tools ang nakarehistro
Prinsipyo sa disenyo ng schema
- Kinakailangan vs opsyonal — Markahan lamang bilang required ang mga field kung talagang kinakailangan; ang mga opsyonal na field na may defaults ay nagpapababa ng error ng model
- Gumamit ng enums para sa mga constrained na halaga —
"format": {"enum": ["json", "markdown", "text"]}pinipigilan ang hallucinated values - Mas gusto ang idempotent na tools — Mas ligtas ang mga Tools na maaaring paulit-ulit na subukan (mga pagbabasa, lookup) kaysa sa mga one-shot na aksyon (mga pagpapadala, pagtanggal)
- Magbalik ng istrukturadong data — Mas madaling mag-reason ang model sa mga JSON responses kaysa sa unstructured text blobs
💡 Mga Halimbawa sa Tunay na Mundo
| Pangalan ng skill | Ano ang ginagawa nito | Mga pangunahing argumento | Risk |
|---|---|---|---|
web_search | Mag-query sa search engine at ibalik ang nangungunang mga resulta | query: string, num_results?: number | Low |
read_file | Basahin ang isang file mula sa workspace directory | path: string, offset?: number, limit?: number | Low |
write_file | Gumawa o i-overwrite ang isang file | path: string, content: string | Medium |
run_tests | Isagawa ang project test suite at ibalik ang mga resulta | filter?: string | Medium |
browser_screenshot | Mag-navigate sa isang URL at ibalik ang screenshot | url: string | Medium |
send_email | Magpadala ng email sa isa o higit pang mga recipient | to: string[], subject: string, body: string | Mataas — laging HITL |
run_shell | Isagawa ang anumang shell command | command: string, cwd?: string | Mataas — kinakailangan ang sandbox |
✅ Mga Pinakamahusay na Gawi
Minimal na permiso
Bigyan ang bawat agent lamang ng mga tools na kailangan nito para sa partikular nitong gawain. Ang isang agent na sumasagot ng mga FAQ ay hindi nangangailangan ng write_file or send_email. Mas maliit ang action space, mas maliit din ang blast radius kung ma-manipula ang agent. Tingnan: Sobrang Ahenhiya.
I-audit ang lahat ng tawag sa tool
I-log ang bawat tool call kasama ang mga argumento at resulta. Pinapayagan nito ang debugging, cost attribution, at pagtuklas ng anomalous na pag-uugali (hal., isang agent na nagbabasa ~/.ssh/ kapag dapat lumangoy lang ito sa project directory). Pinapayagan ng mga AgentOps platform tulad ng LangSmith itong gawing madali.
Human-in-the-loop para sa mga irreversible na aksyon
Anumang aksyon na mahirap o imposibleng i-undo — pagpapadala ng mga mensahe, pagtanggal ng data, paggawa ng mga pagbili — ay dapat mangailangan ng tahasang kumpirmasyon ng tao bago isakatuparan. Magtayo ng HITL checkpoints sa iyong agent runtime, hindi lang sa prompt. Maaaring ma-override ang mga prompt; ang code ay hindi.
Mag-ingat sa tool poisoning
Kung papayagan mong mag-install o mag-discover ng MCP servers ang mga agent nang dinamiko, ang isang malisyosong server ay maaaring magrehistro ng isang tool na may paglalarawang naglalaman ng mga nakatagong utos. Laging suriin ang mga paglalarawan ng tool bago idagdag ang mga ito sa registry ng iyong agent. Tingnan: Tool Poisoning.
Magsulat ng malinaw na error returns
Kapag nabigo ang isang tool, magbalik ng istrukturadong error na may sapat na konteksto para makarekober o mag-escalate ang model — hindi isang raw exception stack trace. Halimbawa: { "error": "rate_limited", "retry_after": 5 }. Ang isang mahusay na inilalarawang error ay nagpapahintulot sa agent na mag-retry, gumamit ng fallback tool, o magpaalam sa user nang maayos.