Mga Artikulo
Huwag Nang Basta Isubo ang SOP sa AI Agent: Gamitin ang RFC 2119 (MUST/SHOULD/MAY) Para sa Eksaktong Kontrol sa Gawi ng Agent
Kapag basta na lang isinaksak ang SOP ng tao sa LLM, madalas na isang beses lang tatama ang Agent at tatlong beses sasablay. Ipinapakita ng article na ito kung paano gamitin ang MUST, SHOULD, at MAY ng RFC 2119 para i-rewrite ang System Prompt at Agent Skill—malinaw na hinihiwalay ang hard constraints, strong recommendations, at sariling discretion—kasama ang tatlong prinsipyo para sa implementation.
· 4 minutong basa
Maraming team na nagpapatupad ng Agent sa production ang madalas na sumasabit sa parehong pagkakamali: basta na lang isinusubo sa LLM ang buong "human SOP" galing Word o Notion, umaasang automatic itong mareresolba ng AI. Ang resulta, madalas parang tumataya sa lotto: isang beses tatama, tatlong beses sasablay.
Ang problema ay wala sa kakayahan ng modelo, kundi dahil ang SOP ng tao ay naglalaman ng sandamakmak na "Tacit Knowledge". Awtomatikong alam ng utak ng tao na "kapag ang halaga ay mas mababa sa 500 pesos, hindi na kailangan ng approval" o "kapag may error sa step na ito, puwede munang laktawan". Pero para sa LLM, ang unstructured text ay walang malinaw na boundaries sa bigat ng bawat instruction, kaya nagiging malaya itong mag-hallucinate o mag-assume.
Para maging deterministic ang gawi ng iyong Agent, ang unang hakbang ay hindi ang lumipat sa mas malaking modelo, kundi ang paggamit ng classic standard sa network protocol specs: ang RFC 2119 semantic levels.
Diretsahang konklusyon: I-tag lang bilang MUST ang compliance, security, at core Schema; ipaubaya ang iba pang boundaries sa SHOULD at MAY; at para sa mga high-risk nodes, idaan ito sa human review.
Bakit RFC 2119?#
Kapag sumusulat ng System Prompt, Agent Skill, o Workflow Rule, ang mga malabong salita tulad ng "pakitandaan", "mas maganda kung", o "hangga't maaari" ay walang anumang boundary enforcement sa modelo. Ang paggamit ng malinaw na verb levels ay pumupuwersa sa pagtatakda ng mga limitasyon sa pagdedesisyon.
MUST / REQUIRED: Hard constraint, zero compromise#
- Semantics: Hinding-hindi puwedeng laktawan, walang exception.
- Use cases: Data validation, security checks, Schema output rules, high-risk guardrails.
- Halimbawa: "Bago i-call ang invoice API,
MUST munang i-validate kung umiiral ang employee ID; kapag walang ibinalik na data, MUST agad ihinto ang execution."
SHOULD / RECOMMENDED: Matinding rekomendasyon, pero bukas sa makatuwirang deviation#
- Semantics: Dapat sundin maliban na lang kung may napakabigat at valid na dahilan base sa context; kapag lumihis, kailangang ipaliwanag ng Agent ang reasoning nito.
- Use cases: Pagpili ng algorithm strategy, classification preferences, retry logic.
- Halimbawa: "Para sa customer inquiry Tickets,
SHOULD unahing i-assign sa Tier 1 support; pero kung may kinalaman sa payment dispute, pinapayagang i-route sa finance audit team."
MAY / OPTIONAL: Sariling discretion, ganap na optional#
- Semantics: Ang modelo ang magpapasya kung isasagawa ito o hindi, base sa available context resources o token budget.
- Use cases: Karagdagang paliwanag, extended thinking suggestions, optional log formats.
- Halimbawa: "Kapag gumagawa ng summary ng resolution,
MAY maglakip ng 1～2 kaugnay na historical reference Ticket IDs."
Tatlong Prinsipyo sa Implementation#
1. Huwag gawing puro MUST ang lahat, mag-iwan ng espasyo para sa Reasoning#
Kapag ginawa mong MUST ang bawat rule, tinatrato mo ang LLM na parang isang Deterministic Compiler, na madaling magdulot ng rule conflicts o logic deadlocks kapag lumobo na ang Context. I-mark lang bilang MUST ang "compliance, security, at core Schema", at ipaubaya ang natitirang boundaries sa SHOULD.
2. Samahan ng structured Markdown blocks#
Hatiin ang Prompt sa apat na blocks sa ibaba, para maging malinaw sa isang tingin ang Scope ng semantic strength:
## Parameters
## Constraints (RFC 2119)
## Execution Steps
## Error Handling
3. I-bind ang high-risk nodes sa Human-in-the-loop#
Kapag na-trigger ang isang kritikal na MUST boundary (tulad ng single transaction > $5,000 o pagbabago sa Admin permissions), ang nag-iisang MUST action ng Agent ay "i-pause ang pipeline at maghintay ng manual approval mula sa tao bago magpatuloy", sa halip na ito ang magdesisyon para sa tao.
Konklusyon: Mula sa pagiging Demo Toy tungo sa Production-Ready#
Ituring ang Agent bilang isang industrial assembly line, hindi bilang isang all-around na "sidekick superhero". Sa pamamagitan ng pagbuo ng behavioral contract gamit ang RFC 2119, doon pa lang tunay na aangat ang iyong Agent mula sa simpleng demo toy patungo sa pagiging maaasahang Production-Ready system.