Загвараас агент руу: Responses API-г компьютерийн орчноор хангах нь

Бид одоогоор тодорхой даалгаварт онцгой сайн ажилладаг загварыг ашиглахаас эхлээд төвөгтэй ажлын урсгалыг гүйцэтгэх чадвартай агентуудыг ашиглах руу шилжиж байна. Загварт өгөгдөл өгөхөд та зөвхөн сургасан оюуныг нь ашиглаж чадна. Харин загварт компьютерийн орчин олговол үйлчилгээ ажиллуулах, API-уудаас өгөгдөл хүсэх, эсвэл хүснэгт, тайлан зэрэг илүү хэрэгцээтэй артефакт үүсгэх зэрэг 훨씬 өргөн хэрэглээний тохиолдлыг хэрэгжүүлж чадна.

Агент бүтээхээр оролдоход хэд хэдэн бодит асуудал гарч ирдэг: завсрын файлуудаа хаана байрлуулах, том хүснэгтүүдийг өгөгдөлд наахаас хэрхэн зайлсхийх, аюулгүй байдлын төвөг үүсгэхгүйгээр ажлын урсгалд сүлжээний хандалт хэрхэн олгох, мөн timeout ба retry-г өөрөө ажлын урсгалын систем бүтээлгүйгээр хэрхэн зохицуулах вэ гэдэг.

Хөгжүүлэгчдээр өөрсдийн гүйцэтгэх орчныг өөрсдөөр нь бүтээлгэхийн оронд бид Responses API⁠(шинэ цонхонд нээгдэнэ)-г бодит ертөнцийн даалгаврыг найдвартай гүйцэтгэх компьютерийн орчноор хангахад шаардлагатай бүрэлдэхүүнүүдийг бүтээсэн.

OpenAI-ийн Responses API нь shell хэрэгсэл болон хостлогдсон контейнер ажлын талбартай хамт эдгээр бодит асуудлуудыг шийдэхээр бүтээгдсэн. Загвар алхам, командуудыг санал болгоно; платформ тэдгээрийг оролт, гаралтад зориулсан файлын систем, нэмэлт бүтэцлэгдсэн хадгалалт (жишээ нь SQLite), мөн хязгаарласан сүлжээний хандалт бүхий тусгаарлагдсан орчинд ажиллуулна.

Энэ нийтлэлээр бид агентуудад зориулсан компьютерийн орчныг хэрхэн бүтээснээ задлан тайлбарлаж, үүнийг илүү хурдан, илүү давтагдахуйц, илүү аюулгүй продакшн ажлын урсгалд хэрхэн ашиглах тухай эхний сургамжуудаасаа хуваалцана.

Сайн агент ажлын урсгал нягт гүйцэтгэлийн давталтаас эхэлдэг: загвар файл унших эсвэл API-аар өгөгдөл татах гэх мэт үйлдэл санал болгоно, платформ түүнийг ажиллуулна, дараа нь үр дүн нь дараагийн алхамд орно. Бид энэ давталтыг ажил дээр нь харах хамгийн энгийн арга болох shell хэрэгслээс эхлээд, дараа нь контейнер ажлын талбар, сүлжээ, дахин ашиглах ур чадварууд, контекстийн шахалтыг авч үзнэ.

Shell хэрэгслийг ойлгохын тулд эхлээд хэлний загвар ер нь хэрэгслүүдийг хэрхэн ашигладгийг ойлгох нь тустай: жишээлбэл функц дуудах эсвэл компьютертэй харилцах гэх мэт. Сургалтын явцад загварт хэрэгслүүдийг хэрхэн ашигладаг, үр дүн нь ямар гардаг талаар алхам алхмаар жишээ үзүүлдэг. Энэ нь загварт хэрэгслийг хэзээ, яаж ашиглахаа шийдэж сурахад тусалдаг. Бид “хэрэгсэл ашиглах” гэж хэлэхдээ загвар бодитоороо зөвхөн хэрэгсэл дуудах саналыг гаргадаг гэсэн үг. Тэр дуудагдлыг өөрөө гүйцэтгэж чаддаггүй.

Shell хэрэгсэл нь загварыг эрс илүү хүчирхэг болгодог: командын мөрөөр дамжуулан компьютертэй харилцаж, текст хайхаас эхлээд таны компьютерээс API хүсэлт илгээх хүртэл өргөн хүрээний ажлыг гүйцэтгэнэ. Танил Unix хэрэгслүүд дээр суурилсан манай shell хэрэгсэл нь grep, curl, awk зэрэг хэрэгслүүд бэлнээрээ байж, таны хүлээх бүхнийг хийж чадна.

Зөвхөн Python ажиллуулдаг одоогийн code interpreter-тэй харьцуулахад shell хэрэгсэл нь Go эсвэл Java програм ажиллуулах, NodeJS сервер эхлүүлэх зэрэг 훨씬 өргөн хэрэглээний тохиолдлыг боломжтой болгодог. Энэ уян хатан байдал нь загварт төвөгтэй агентлаг даалгавруудыг биелүүлэх боломж олгодог.

Загвар дангаараа зөвхөн shell команд санал болгож чадна, гэхдээ эдгээр команд яг яаж гүйцэтгэгддэг вэ? Бидэнд загварын гаралтыг авах, хэрэгслүүдийг дуудах, хэрэгслийн хариуг даалгавар дуусах хүртэл загварт давталтаар буцаан дамжуулах зохицуулагч хэрэгтэй.

Responses API нь хөгжүүлэгчид OpenAI-ийн загваруудтай харилцах арга юм. Тусгай хэрэгслүүдтэй ашиглахад Responses API нь удирдлагыг клиент рүү буцаадаг бөгөөд клиент нь хэрэгслүүдийг ажиллуулах өөрийн harness-тай байх шаардлагатай. Гэхдээ энэ API нь загвар болон хостлогдсон хэрэгслүүдийн хооронд мөн шууд зохион байгуулалт хийж чадна.

Responses API өгөгдөл хүлээн авахдаа загварын контекстийг бүрдүүлдэг: хэрэглэгчийн өгөгдөл, өмнөх ярианы төлөв, хэрэгслийн заавар. Shell гүйцэтгэл ажиллахын тулд өгөгдөлд shell хэрэгслийг ашиглах тухай дурдах ёстой мөн сонгосон загвар shell команд санал болгохоор сургагдсан байх ёстой—GPT‑5.2 ба түүнээс хойших загварууд үүнд сургагдсан. Энэ бүх контексттэйгээр загвар дараагийн үйлдлээ шийднэ. Хэрэв shell гүйцэтгэлийг сонговол Responses API үйлчилгээнд нэг эсвэл хэд хэдэн shell командыг буцаана. API үйлчилгээ тэдгээр командыг контейнер runtime руу дамжуулж, shell-ийн гаралтыг стриймээр буцаан, дараагийн хүсэлтийн контекстэд загварт өгнө. Дараа нь загвар үр дүнг шалгаж, нэмэлт команд гаргах эсвэл эцсийн хариу өгөх боломжтой. Responses API загвар нэмэлт shell командгүй дууссан хариу буцаах хүртэл энэ давталтыг үргэлжлүүлнэ.

Responses API shell командыг гүйцэтгэхдээ контейнер үйлчилгээтэй стрийминг холболтыг хадгалдаг. Гаралт үүсэх бүрд API үүнийг бараг бодит цагт загварт дамжуулдаг тул загвар илүү гаралт хүлээх, өөр команд ажиллуулах эсвэл эцсийн хариу руу шилжихээ шийдэж чадна.

Загвар нэг алхамд олон shell команд санал болгож болох бөгөөд Responses API тэдгээрийг тус тусдаа контейнер сешнүүд ашиглан зэрэг ажиллуулж чадна. Сешн бүр гаралтаа тусад нь стриймлэнэ, API эдгээр урсгалуудыг бүтэцтэй хэрэгслийн гаралт болгон нэгтгээд контекстэд буцаана. Өөрөөр хэлбэл, агентын давталт файл хайх, өгөгдөл татах, завсрын үр дүнг баталгаажуулах зэрэг ажлыг зэрэгцүүлэн ажиллуулж чадна.

Команд файлтай ажиллах эсвэл өгөгдөл боловсруулахтай холбоотой үед shell-ийн гаралт маш том болж, хэрэгтэй дохио нэмэхгүйгээр контекстийн төсвийг идэж болдог. Үүнийг хянахын тулд загвар команд бүрт гаралтын дээд хязгаар заадаг. Responses API тэр хязгаарыг мөрдүүлж, эхлэл ба төгсгөлийг нь хадгалсан, алгассан агуулгыг тэмдэглэсэн хязгаарлагдсан үр дүн буцаана. Жишээлбэл, та гаралтыг 1,000 тэмдэгтээр хязгаарлаж, эхлэл ба төгсгөлийг хадгалж болно:

эхэндэх текст ... 1000 тэмдэгт таслагдсан ... төгсгөлийн текст

Зэрэгцээ гүйцэтгэл болон хязгаарласан гаралт хамтдаа агентын давталтыг хурдан бөгөөд контекстийн хувьд үр ашигтай болгодог тул загвар түүхий терминалын логоор дарагдах биш, хамааралтай үр дүн дээр сэтгэн бодсоор байж чадна.

Агентын давталтын нэг боломжит асуудал нь даалгавар урт хугацаанд ажиллаж болдог явдал юм. Урт хугацааны даалгавар контекстийн цонхыг дүүргэдэг бөгөөд энэ нь turn-уудын хооронд болон агентуудын хооронд контекст хадгалахад чухал. Агент ур чадвар дуудаж, хариу авч, хэрэгслийн дуудлага ба сэтгэн бодох хураангуй нэмж байна гэж төсөөлөөд үзье—хязгаартай контекстийн цонх маш хурдан дүүрнэ. Агент үргэлжлэн ажиллах явцад чухал контекстээ алдахгүй байхын тулд гол мэдээллийг хадгалж, илүүдэл бүхнийг арилгах арга хэрэгтэй. Хөгжүүлэгчдээр тусгай хураангуйлалт эсвэл төлөв дамжуулах систем зохиож, арчлуулахын оронд бид Responses API-д загвар хэрхэн ажилладаг болон яаж сургагдсантай нийцүүлэн төрөлх шахалтыг нэмсэн.

Манай хамгийн сүүлийн загварууд өмнөх ярианы төлөвийг шинжилж, гол өмнөх төлөвийг шифрлэсэн, токен-хэмнэлттэй дүрслэлд хадгалдаг шахалтын зүйлийг үүсгэхээр сургагдсан. Шахалтын дараа дараагийн контекстийн цонх нь энэ шахалтын зүйл болон өмнөх цонхны өндөр үнэ цэнтэй хэсгүүдээс бүрдэнэ. Ингэснээр ажлын урсгалууд уртассан олон алхамт, хэрэгсэлд тулгуурласан сешнүүдийн үеэр ч цонхны заагийг даван уялдаатай үргэлжилж чадна. Codex энэ механизмыг ашигладаг тул чанар алдагдуулахгүйгээр урт хугацааны кодчиллын даалгавар болон давтагдсан хэрэгслийн гүйцэтгэлийг тогтвортой явуулж чаддаг.

Шахалт нь серверт суурилсан байдлаар эсвэл тусдаа /compact эцсийн цэгээр ашиглах боломжтой. Сервер талын шахалт нь босго тохируулах боломж олгож, систем шахалтын цагийг автоматаар зохицуулдаг тул клиент талын төвөгтэй логикийн хэрэгцээг арилгана. Мөн шахалтын өмнөхөн гарсан багахан хэтрэлтийг тэсвэрлэхийн тулд илүү том үр дүнтэй оролтын контекстийн цонх олгодог учраас хязгаарт ойр хүсэлтүүдийг шууд татгалзахын оронд боловсруулж, шахаж чадна. Загварын сургалт хөгжихийн хэрээр төрөлх шахалтын шийдэл ч OpenAI-ийн загварын шинэ хувилбар бүртэй хамт хөгжсөөр байдаг.

Codex шахалтын системийг бүтээхэд бидэнд тусалсан бөгөөд өөрөө түүний эрт хэрэглэгч болсон. Codex-ийн нэг instance шахалтын алдаа гаргахад бид шалгахын тулд хоёр дахь instance-ийг ажиллуулдаг байсан. Үр дүнд нь Codex асуудал дээр ажилласныхаа ачаар төрөлх, үр дүнтэй шахалтын системтэй болсон. Codex өөрийгөө шалгаж, сайжруулах энэ чадвар OpenAI-д ажиллахын хамгийн сонирхолтой хэсгүүдийн нэг болсон. Ихэнх хэрэгсэл хэрэглэгчээрээ л хэрхэн ашиглахаа сургуулдаг; харин Codex бидэнтэй хамт суралцдаг.

Одоо төлөв ба нөөцийг авч үзье. Контейнер нь зөвхөн команд ажиллуулах газар биш, мөн загварын ажлын контекст юм. Контейнер дотор загвар файл унших, өгөгдлийн сан асуух, сүлжээний бодлогын хяналтын дор гадаад системүүдэд хандах боломжтой.

Контейнер контекстийн эхний хэсэг нь нөөцийг байршуулах, зохион байгуулах, удирдах файлын систем юм. Бид загварт байгаа өгөгдлийн зураглалыг өгөх, өргөн хүрээний шуугиантай хайлт хийхийн оронд чиглэсэн файлын үйлдлийг сонгоход нь туслахын тулд контейнер ба файл⁠(шинэ цонхонд нээгдэнэ) API-уудыг бүтээсэн.

Түгээмэл anti-pattern бол бүх оролтыг шууд өгөгдлийн контекстэд чихэх явдал юм. Оролт өсөх тусам өгөгдөл хэт дүүрэх нь зардалтай болж, загварт түүнийг чиглэн ойлгоход хэцүү болдог. Илүү сайн арга бол нөөцүүдийг контейнерийн файлын системд шатлуулан байршуулж, загвараар shell команд ашиглан юу нээх, задлах, хувиргахаа шийдүүлэх явдал юм. Хүмүүстэй адил загварууд зохион байгуулалттай мэдээлэлтэй үед илүү сайн ажилладаг.

Контейнер контекстийн хоёр дахь хэсэг нь өгөгдлийн сангууд юм. Олон тохиолдолд бид хөгжүүлэгчдэд бүтэцлэгдсэн өгөгдлийг SQLite зэрэг өгөгдлийн санд хадгалж, түүнийг query хийхийг зөвлөдөг. Жишээлбэл бүх хүснэгтийг өгөгдөл рүү хуулж оруулахын оронд хүснэгтүүдийн тайлбарыг—ямар багана байгааг, юу гэсэн утгатайг—загварт өгч, хэрэгтэй мөрүүдээ өөрөөр нь татуулах боломжтой.

Жишээ нь, та “Энэ улиралд ямар бүтээгдэхүүний борлуулалт буурсан бэ?” гэж асуувал загвар бүх хүснэгтийг бүхэлд нь уншихын оронд зөвхөн хамааралтай мөрүүдийг query хийж чадна. Энэ нь илүү хурдан, хямд бөгөөд том өгөгдлийн багцад илүү сайн өргөтгөгдөнө.

Контейнерийн контекстийн гурав дахь хэсэг нь сүлжээний хандалт бөгөөд агентын ачааллын чухал хэсэг юм. Агентийн ажлын урсгалд амьд өгөгдөл татах, гадаад API дуудах, эсвэл package суулгах шаардлага гарч болно. Үүний зэрэгцээ контейнеруудад хязгааргүй интернет хандалт өгөх нь эрсдэлтэй: энэ нь мэдээллийг гаднын вэбсайтуудад ил болгож, эмзэг дотоод эсвэл гуравдагч талын системд санамсаргүй хүрч, нууц мэдээлэл алдагдах болон өгөгдөл гадагшлуулахыг хамгаалахад илүү хэцүү болгодог.

Эдгээр асуудлыг агентуудын ашигтай байдлыг хязгаарлахгүйгээр шийдэхийн тулд бид хостлосон контейнеруудыг sidecar egress proxy ашиглахаар бүтээсэн. Бүх гадагш чиглэсэн сүлжээний хүсэлтүүд төвлөрсөн бодлогын давхаргаар урсаж, allowlist болон хандалтын хяналтыг хэрэгжүүлэхийн зэрэгцээ траффикийг ажиглагдахуйц байлгана. Нууц мэдээллийн хувьд бид egress дээр домэйнээр хязгаарласан secret injection ашигладаг. Загвар болон контейнер зөвхөн placeholder-уудыг л хардаг, харин нууцын түүхий утгууд нь загварт харагдах контекстоос гадуур үлдэж, зөвхөн зөвшөөрөгдсөн чиглэлд хэрэглэгддэг. Ингэснээр authenticated гадаад дуудлага хийх боломжийг хадгалсаар байж алдагдлын эрсдэлийг бууруулна.

Shell командууд хүчирхэг боловч олон даалгавар ижил олон алхамт хэв маягийг давтдаг. Агентууд ажлын урсгалыг ажиллуулах бүртээ дахин нээх шаардлагатай болдог — дахин төлөвлөж, командуудыг дахин илгээж, хэвшмэл дүрмүүдийг дахин сурах хэрэг гардаг — ингэснээр үр дүн жигд бус болж, гүйцэтгэл дэмий үрэгддэг. Агентийн skills⁠(шинэ цонхонд нээгдэнэ) нь эдгээр хэв маягийг дахин ашиглах, хослуулах боломжтой барилгын блокууд болгон багцалдаг. Тодруулбал skill гэдэг нь ‘SKILL.md⁠(шинэ цонхонд нээгдэнэ)’ (мета өгөгдөл болон заавруудыг агуулсан) болон API тодорхойлолт, UI asset зэрэг аливаа туслах нөөцийг багтаасан хавтасны багц юм.

Энэ бүтэц нь бидний өмнө тайлбарласан runtime архитектуртай байгалийн жамаар таардаг. Контейнер нь тогтвортой файл болон гүйцэтгэлийн контекст өгдөг, харин shell хэрэгсэл нь гүйцэтгэлийн интерфейсийг өгдөг. Энэ хоёр байхад загвар шаардлагатай үед shell командууд (`ls`, `cat` гэх мэт)-аар skill файлуудыг олж, заавруудыг тайлбарлаж, skill скриптүүдийг нэг агентын давталт дотор ажиллуулж чадна.

Бид OpenAI платформ дээр skills-ийг удирдах API-ууд⁠(шинэ цонхонд нээгдэнэ)-ыг өгдөг. Хөгжүүлэгчид skill хавтаснуудыг хувилбаржуулсан багц хэлбэрээр байршуулж хадгалдаг бөгөөд дараа нь skill ID-гаар татаж авч болно. Загварт өгөгдлийг илгээхээс өмнө Responses API нь skill-ийг ачаалж, загварын контекстэд оруулдаг. Энэ дараалал нь детерминистик:

1. Нэр, тайлбар зэрэг skill-ийн мета өгөгдлийг татаж авна.
2. Skill багцыг татаж авч, контейнерт хуулж, задлана.
3. Skill мета өгөгдөл болон контейнерийн замаар загварын контекстыг шинэчилнэ.

Skill хамааралтай эсэхийг шийдэхдээ загвар нь түүний заавруудыг үе шаттайгаар судалж, контейнер дотор shell командуудаар скриптүүдийг нь ажиллуулдаг.

Бүх хэсгүүдийг нэгтгэн хэлбэл: Responses API нь зохицуулалтыг, shell хэрэгсэл нь гүйцэтгэж болох үйлдлүүдийг, хостлосон контейнер нь тогтвортой runtime контекстыг, skills нь дахин ашиглах ажлын урсгалын логикийг, харин compaction нь агент шаардлагатай контексттэйгээр удаан хугацаанд ажиллах боломжийг олгодог.

Эдгээр суурь элементүүдээр нэг өгөгдөл төгсгөлөөс төгсгөл хүртэлх ажлын урсгал болж тэлж чадна: зөв skill-ийг олох, өгөгдөл татах, түүнийг локал бүтэцлэгдсэн төлөв болгон хөрвүүлэх, үр ашигтайгаар асуух, мөн тогтвортой артефакт үүсгэх.

Доорх диаграм нь амьд өгөгдлөөс хүснэгт үүсгэхэд энэ систем хэрхэн ажилладгийг харуулна.

Shell хэрэгсэл болон компьютерийн орчныг ашиглан төгсгөлөөс төгсгөл хүртэлх ажлын урсгалыг нэгтгэсэн гүнзгий жишээ үзэхийг хүсвэл skill-ийг хэрхэн багцалж Responses API-гаар гүйцэтгэхийг алхам алхмаар үзүүлсэн манай хөгжүүлэгчийн блог нийтлэл⁠(шинэ цонхонд нээгдэнэ) болон cookbook⁠(шинэ цонхонд нээгдэнэ)-ийг үзнэ үү.

Энэ суурь элементүүдийн цуглуулгаар хөгжүүлэгчид юу бүтээхийг харахдаа бид догдолж байна. Хэлний загварууд нь зөвхөн текст, зураг, аудио үүсгэхээс илүүг хийх зориулалттай — бид бодит ертөнцийн нарийн төвөгтэй даалгавруудыг өргөн хэмжээнд боловсруулах чадварыг нь нэмэгдүүлэхээр платформоо үргэлжлүүлэн хөгжүүлсээр байх болно.