ਮਾਡਲ ਤੋਂ ਏਜੰਟ ਤੱਕ: Responses API ਨੂੰ ਇੱਕ ਕੰਪਿਊਟਰ environment ਨਾਲ ਸੱਜਿਤ ਕਰਨਾ

ਅਸੀਂ ਇਸ ਵੇਲੇ ਅਜਿਹੇ ਬਦਲਾਅ ਦੇ ਦੌਰ ਵਿੱਚ ਹਾਂ ਜਿੱਥੇ ਖ਼ਾਸ ਕੰਮਾਂ ਵਿੱਚ ਨਿਪੁੰਨ ਮਾਡਲਾਂ ਤੋਂ ਜਟਿਲ workflows ਸੰਭਾਲਣ ਯੋਗ ਏਜੰਟਾਂ ਵੱਲ ਜਾਇਆ ਜਾ ਰਿਹਾ ਹੈ। ਮਾਡਲਾਂ ਨੂੰ ਪ੍ਰੌੰਪਟ ਕਰਕੇ, ਤੁਸੀਂ ਸਿਰਫ਼ ਟ੍ਰੇਨ ਕੀਤੀ ਬੁੱਧੀ ਤੱਕ ਪਹੁੰਚ ਕਰ ਸਕਦੇ ਹੋ। ਪਰ ਮਾਡਲ ਨੂੰ ਇੱਕ ਕੰਪਿਊਟਰ environment ਦੇਣ ਨਾਲ ਬਹੁਤ ਵੱਡੀ ਵਰਤੋਂ-ਸ਼੍ਰੇਣੀ ਸੰਭਵ ਹੋ ਸਕਦੀ ਹੈ, ਜਿਵੇਂ services ਚਲਾਉਣਾ, APIs ਤੋਂ data ਮੰਗਣਾ, ਜਾਂ spreadsheets ਜਾਂ reports ਵਰਗੇ ਹੋਰ ਲਾਭਦਾਇਕ artifacts ਬਣਾਉਣਾ.

ਜਦੋਂ ਤੁਸੀਂ ਏਜੰਟ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹੋ ਤਾਂ ਕੁਝ ਵਿਹਾਰਕ ਸਮੱਸਿਆਵਾਂ ਸਾਹਮਣੇ ਆਉਂਦੀਆਂ ਹਨ: ਵਿਚਕਾਰਲੇ files ਕਿੱਥੇ ਰੱਖਣੇ ਹਨ, ਵੱਡੀਆਂ tables ਨੂੰ ਪ੍ਰੌੰਪਟ ਵਿੱਚ paste ਕਰਨ ਤੋਂ ਕਿਵੇਂ ਬਚਣਾ ਹੈ, workflow ਨੂੰ ਸੁਰੱਖਿਆ ਸੰਬੰਧੀ ਸਿਰਦਰਦ ਪੈਦਾ ਕੀਤੇ ਬਿਨਾ network access ਕਿਵੇਂ ਦੇਣੀ ਹੈ, ਅਤੇ timeouts ਅਤੇ retries ਨੂੰ ਆਪ workflow system ਬਣਾਏ ਬਿਨਾ ਕਿਵੇਂ ਸੰਭਾਲਣਾ ਹੈ.

ਇਸ ਦੀ ਬਜਾਇ ਕਿ developers ਨੂੰ ਆਪਣੇ execution environments ਆਪ ਬਣਾਉਣੇ ਪੈਣ, ਅਸੀਂ ਲੋੜੀਂਦੇ ਹਿੱਸੇ ਬਣਾਏ ਤਾਂ ਜੋ Responses API⁠(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ) ਨੂੰ ਅਸਲੀ ਦੁਨੀਆ ਦੇ ਕੰਮਾਂ ਨੂੰ ਭਰੋਸੇਯੋਗ ਢੰਗ ਨਾਲ ਚਲਾਉਣ ਲਈ ਇੱਕ ਕੰਪਿਊਟਰ environment ਨਾਲ ਸੱਜਿਤ ਕੀਤਾ ਜਾ ਸਕੇ.

OpenAI ਦੀ Responses API, shell tool ਅਤੇ hosted container workspace ਦੇ ਨਾਲ ਮਿਲਕੇ, ਇਹਨਾਂ ਵਿਹਾਰਕ ਸਮੱਸਿਆਵਾਂ ਦਾ ਹੱਲ ਕਰਨ ਲਈ ਬਣਾਈ ਗਈ ਹੈ। ਮਾਡਲ ਕਦਮ ਅਤੇ commands ਸੁਝਾਉਂਦਾ ਹੈ; platform ਉਹਨਾਂ ਨੂੰ inputs ਅਤੇ outputs ਲਈ filesystem, ਵਿਕਲਪਿਕ structured storage (ਜਿਵੇਂ SQLite), ਅਤੇ ਸੀਮਿਤ network access ਵਾਲੇ isolated environment ਵਿੱਚ ਚਲਾਉਂਦਾ ਹੈ. 

ਇਸ ਪੋਸਟ ਵਿੱਚ, ਅਸੀਂ ਵੇਖਾਂਗੇ ਕਿ ਅਸੀਂ ਏਜੰਟਾਂ ਲਈ ਕੰਪਿਊਟਰ environment ਕਿਵੇਂ ਬਣਾਇਆ ਅਤੇ ਇਸਨੂੰ ਹੋਰ ਤੇਜ਼, ਹੋਰ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ, ਅਤੇ ਹੋਰ ਸੁਰੱਖਿਅਤ production workflows ਲਈ ਕਿਵੇਂ ਵਰਤਣਾ ਹੈ ਇਸ ਬਾਰੇ ਕੁਝ ਸ਼ੁਰੂਆਤੀ ਸਿੱਖਿਆਵਾਂ ਸਾਂਝੀਆਂ ਕਰਾਂਗੇ.

ਇੱਕ ਵਧੀਆ ਏਜੰਟ workflow ਇੱਕ ਟਾਈਟ execution loop ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ: ਮਾਡਲ files ਪੜ੍ਹਨ ਜਾਂ API ਨਾਲ data ਲਿਆਉਣ ਵਰਗੀ action ਸੁਝਾਉਂਦਾ ਹੈ, platform ਇਸਨੂੰ ਚਲਾਉਂਦਾ ਹੈ, ਅਤੇ ਨਤੀਜਾ ਅਗਲੇ ਕਦਮ ਵਿੱਚ ਵਾਪਸ ਜਾਂਦਾ ਹੈ। ਅਸੀਂ ਸ਼ੈੱਲ ਟੂਲ ਨਾਲ ਸ਼ੁਰੂ ਕਰਾਂਗੇ—ਇਸ ਲੂਪ ਨੂੰ ਕੰਮ ਕਰਦਿਆਂ ਦੇਖਣ ਦਾ ਸਭ ਤੋਂ ਸੌਖਾ ਤਰੀਕਾ—ਅਤੇ ਫਿਰ container workspace, networking, reusable skills, ਅਤੇ context compaction ਨੂੰ cover ਕਰਾਂਗੇ.

ਸ਼ੈੱਲ ਟੂਲ ਨੂੰ ਸਮਝਣ ਲਈ, ਪਹਿਲਾਂ ਇਹ ਸਮਝਣਾ ਲਾਭਦਾਇਕ ਹੈ ਕਿ language model ਆਮ ਤੌਰ ‘ਤੇ tools ਕਿਵੇਂ ਵਰਤਦਾ ਹੈ: ਜਿਵੇਂ function call ਕਰਨਾ ਜਾਂ ਕੰਪਿਊਟਰ ਨਾਲ ਇੰਟਰੈਕਟ ਕਰਨਾ। training ਦੌਰਾਨ, ਮਾਡਲ ਨੂੰ ਕਦਮ-ਦਰ-ਕਦਮ ਉਹ ਉਦਾਹਰਨਾਂ ਦਿਖਾਈਆਂ ਜਾਂਦੀਆਂ ਹਨ ਜਿਨ੍ਹਾਂ ਵਿੱਚ tools ਦੀ ਵਰਤੋਂ ਅਤੇ ਉਹਨਾਂ ਦੇ ਨਤੀਜੇ ਹੁੰਦੇ ਹਨ। ਇਸ ਨਾਲ ਮਾਡਲ ਸਿੱਖਦਾ ਹੈ ਕਿ tool ਕਦੋਂ ਵਰਤਣਾ ਹੈ ਅਤੇ ਕਿਵੇਂ ਵਰਤਣਾ ਹੈ। ਜਦੋਂ ਅਸੀਂ ਕਹਿੰਦੇ ਹਾਂ “tool ਵਰਤਣਾ”, ਤਾਂ ਅਸਲ ਵਿੱਚ ਮਾਡਲ ਸਿਰਫ਼ ਇੱਕ tool call ਸੁਝਾਉਂਦਾ ਹੈ। ਇਹ ਖੁਦ call execute ਨਹੀਂ ਕਰ ਸਕਦਾ.

ਸ਼ੈੱਲ ਟੂਲ ਮਾਡਲ ਨੂੰ ਨਾਟਕੀ ਢੰਗ ਨਾਲ ਹੋਰ ਸ਼ਕਤੀਸ਼ਾਲੀ ਬਣਾਉਂਦਾ ਹੈ: ਇਹ command line ਰਾਹੀਂ ਕੰਪਿਊਟਰ ਨਾਲ ਇੰਟਰੈਕਟ ਕਰਦਾ ਹੈ ਤਾਂ ਜੋ text ਖੋਜਣ ਤੋਂ ਲੈ ਕੇ ਤੁਹਾਡੇ ਕੰਪਿਊਟਰ ‘ਤੇ API requests ਭੇਜਣ ਤੱਕ ਕਈ ਕਿਸਮਾਂ ਦੇ ਕੰਮ ਕੀਤੇ ਜਾ ਸਕਣ। ਜਾਣ-ਪਹਿਚਾਣ ਵਾਲੇ Unix tooling ‘ਤੇ ਬਣਿਆ ਸਾਡਾ shell tool ਉਹ ਸਭ ਕਰ ਸਕਦਾ ਹੈ ਜਿਸਦੀ ਤੁਸੀਂ ਉਮੀਦ ਕਰਦੇ ਹੋ, ਅਤੇ grep, curl, ਅਤੇ awk ਵਰਗੀਆਂ utilities out of the box ਉਪਲਬਧ ਹਨ.

ਸਾਡੇ ਮੌਜੂਦਾ code interpreter ਨਾਲ ਤੁਲਨਾ ਕਰਨ ‘ਤੇ, ਜੋ ਸਿਰਫ਼ Python execute ਕਰਦਾ ਹੈ, shell tool ਕਾਫ਼ੀ ਵੱਡੀ ਵਰਤੋਂ-ਸ਼੍ਰੇਣੀ ਯੋਗ ਬਣਾਉਂਦਾ ਹੈ, ਜਿਵੇਂ Go ਜਾਂ Java programs ਚਲਾਉਣਾ ਜਾਂ NodeJS server ਸ਼ੁਰੂ ਕਰਨਾ। ਇਹ ਲਚਕ ਮਾਡਲ ਨੂੰ ਜਟਿਲ ਏਜੰਟਿਕ ਕੰਮ ਪੂਰੇ ਕਰਨ ਦੇ ਯੋਗ ਬਣਾਉਂਦੀ ਹੈ.

ਆਪਣੇ ਆਪ, ਮਾਡਲ ਸਿਰਫ਼ shell commands ਸੁਝਾ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ commands execute ਕਿਵੇਂ ਹੁੰਦੀਆਂ ਹਨ? ਸਾਨੂੰ ਇੱਕ orchestrator ਦੀ ਲੋੜ ਹੈ ਜੋ ਮਾਡਲ ਆਉਟਪੁੱਟ ਲਵੇ, tools invoke ਕਰੇ, ਅਤੇ tool response ਨੂੰ ਮੁੜ ਮਾਡਲ ਤੱਕ ਲੂਪ ਵਿੱਚ ਪਹੁੰਚਾਏ, ਜਦ ਤੱਕ ਕੰਮ ਪੂਰਾ ਨਾ ਹੋ ਜਾਵੇ.

Responses API ਉਹ ਤਰੀਕਾ ਹੈ ਜਿਸ ਰਾਹੀਂ developers OpenAI ਮਾਡਲਾਂ ਨਾਲ ਇੰਟਰੈਕਟ ਕਰਦੇ ਹਨ। ਜਦੋਂ custom tools ਨਾਲ ਵਰਤੀ ਜਾਂਦੀ ਹੈ, Responses API ਕੰਟਰੋਲ client ਨੂੰ ਵਾਪਸ ਦੇ ਦਿੰਦੀ ਹੈ, ਅਤੇ client ਨੂੰ tools ਚਲਾਉਣ ਲਈ ਆਪਣਾ harness ਚਾਹੀਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਇਹ API ਮਾਡਲ ਅਤੇ hosted tools ਦੇ ਵਿਚਕਾਰ out of the box ਵੀ orchestration ਕਰ ਸਕਦੀ ਹੈ. 

ਜਦੋਂ Responses API ਨੂੰ ਪ੍ਰੌੰਪਟ ਮਿਲਦਾ ਹੈ, ਇਹ model context ਇਕੱਠਾ ਕਰਦੀ ਹੈ: user prompt, ਪਹਿਲਾਂ ਦੀ conversation state, ਅਤੇ tool instructions। shell execution ਦੇ ਕੰਮ ਕਰਨ ਲਈ, ਪ੍ਰੌੰਪਟ ਵਿੱਚ shell tool ਦੀ ਵਰਤੋਂ ਦਾ ਜ਼ਿਕਰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਚੁਣਿਆ ਗਿਆ ਮਾਡਲ shell commands ਸੁਝਾਉਣ ਲਈ trained ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ—GPT‑5.2 ਅਤੇ ਇਸ ਤੋਂ ਬਾਅਦ ਦੇ ਮਾਡਲ ਇਸ ਲਈ trained ਹਨ। ਇਸ ਸਾਰੇ context ਨਾਲ, ਮਾਡਲ ਫਿਰ ਅਗਲੀ action ਦਾ ਫ਼ੈਸਲਾ ਕਰਦਾ ਹੈ। ਜੇ ਇਹ shell execution ਚੁਣਦਾ ਹੈ, ਤਾਂ ਇਹ Responses API service ਨੂੰ ਇੱਕ ਜਾਂ ਵੱਧ shell commands ਵਾਪਸ ਕਰਦਾ ਹੈ। API service ਉਹ commands container runtime ਨੂੰ ਭੇਜਦੀ ਹੈ, shell output ਨੂੰ stream back ਕਰਦੀ ਹੈ, ਅਤੇ ਇਸਨੂੰ ਅਗਲੀ request ਦੇ context ਵਿੱਚ ਮਾਡਲ ਨੂੰ ਭੇਜਦੀ ਹੈ। ਫਿਰ ਮਾਡਲ ਨਤੀਜਿਆਂ ਦੀ ਜਾਂਚ ਕਰ ਸਕਦਾ ਹੈ, follow-up commands ਜਾਰੀ ਕਰ ਸਕਦਾ ਹੈ, ਜਾਂ ਅੰਤਿਮ ਜਵਾਬ ਦੇ ਸਕਦਾ ਹੈ। Responses API ਇਸ ਲੂਪ ਨੂੰ ਤਦ ਤੱਕ ਦੁਹਰਾਂਦੀ ਹੈ ਜਦ ਤੱਕ ਮਾਡਲ ਵਾਧੂ shell commands ਤੋਂ ਬਿਨਾ completion ਵਾਪਸ ਨਹੀਂ ਕਰਦਾ.

ਜਦੋਂ Responses API ਇੱਕ shell command execute ਕਰਦੀ ਹੈ, ਇਹ container service ਨਾਲ ਇੱਕ streaming connection ਬਣਾਈ ਰੱਖਦੀ ਹੈ। ਜਿਵੇਂ ਹੀ output ਬਣਦਾ ਹੈ, API ਇਸਨੂੰ ਲਗਭਗ real time ਵਿੱਚ ਮਾਡਲ ਤੱਕ ਪਹੁੰਚਾਉਂਦੀ ਹੈ ਤਾਂ ਜੋ ਮਾਡਲ ਫ਼ੈਸਲਾ ਕਰ ਸਕੇ ਕਿ ਹੋਰ output ਦੀ ਉਡੀਕ ਕਰਨੀ ਹੈ, ਹੋਰ command ਚਲਾਉਣੀ ਹੈ, ਜਾਂ ਅੰਤਿਮ response ਵੱਲ ਵਧਣਾ ਹੈ.

ਮਾਡਲ ਇੱਕ ਕਦਮ ਵਿੱਚ ਕਈ shell commands ਸੁਝਾ ਸਕਦਾ ਹੈ, ਅਤੇ Responses API ਉਹਨਾਂ ਨੂੰ ਵੱਖ-ਵੱਖ container sessions ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇਕੱਠੇ execute ਕਰ ਸਕਦੀ ਹੈ। ਹਰ session output ਨੂੰ ਸੁਤੰਤਰ ਤੌਰ ‘ਤੇ stream ਕਰਦਾ ਹੈ, ਅਤੇ API ਉਹਨਾਂ streams ਨੂੰ structured tool outputs ਵਜੋਂ context ਵਿੱਚ multiplex ਕਰਦੀ ਹੈ। ਹੋਰ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਏਜੰਟ ਲੂਪ ਕੰਮ ਨੂੰ parallelize ਕਰ ਸਕਦਾ ਹੈ, ਜਿਵੇਂ files ਖੋਜਣਾ, data ਲਿਆਉਣਾ, ਅਤੇ ਵਿਚਕਾਰਲੇ ਨਤੀਜਿਆਂ ਨੂੰ validate ਕਰਨਾ.

ਜਦੋਂ command ਵਿੱਚ file operations ਜਾਂ data processing ਸ਼ਾਮਲ ਹੋਵੇ, shell output ਬਹੁਤ ਵੱਡਾ ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ ਬਿਨਾ ਲਾਭਦਾਇਕ ਸੰਕੇਤ ਜੋੜੇ context budget ਖਾ ਸਕਦਾ ਹੈ। ਇਸਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਨ ਲਈ, ਮਾਡਲ ਹਰ command ਲਈ output cap ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ। Responses API ਉਸ cap ਨੂੰ ਲਾਗੂ ਕਰਦੀ ਹੈ ਅਤੇ ਇੱਕ ਸੀਮਿਤ ਨਤੀਜਾ ਵਾਪਸ ਕਰਦੀ ਹੈ ਜੋ output ਦੇ ਸ਼ੁਰੂ ਅਤੇ ਅੰਤ ਦੋਵੇਂ ਨੂੰ ਸੰਭਾਲ ਕੇ ਰੱਖਦਾ ਹੈ, ਨਾਲ ਹੀ ਹਟਾਈ ਗਈ content ਨੂੰ ਨਿਸ਼ਾਨਿਤ ਕਰਦਾ ਹੈ। ਉਦਾਹਰਨ ਵਜੋਂ, ਤੁਸੀਂ output ਨੂੰ 1,000 characters ਤੱਕ ਸੀਮਿਤ ਕਰ ਸਕਦੇ ਹੋ, ਜਿਸ ਵਿੱਚ ਸ਼ੁਰੂ ਅਤੇ ਅੰਤ ਬਚੇ ਰਹਿਣ:

text at the beginning ... 1000 chars truncated ... text at the end

ਇਕੱਠੇ ਮਿਲਕੇ, concurrent execution ਅਤੇ bounded output ਏਜੰਟ ਲੂਪ ਨੂੰ ਤੇਜ਼ ਅਤੇ context-efficient ਬਣਾਉਂਦੇ ਹਨ ਤਾਂ ਜੋ ਮਾਡਲ raw terminal logs ਨਾਲ ਘਿਰਣ ਦੀ ਬਜਾਇ ਸੰਬੰਧਿਤ ਨਤੀਜਿਆਂ ‘ਤੇ ਰੀਜ਼ਨਿੰਗ ਜਾਰੀ ਰੱਖ ਸਕੇ.

ਏਜੰਟ ਲੂਪਾਂ ਦੀ ਇੱਕ ਸੰਭਾਵਿਤ ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਕੰਮ ਲੰਮੇ ਸਮੇਂ ਤੱਕ ਚੱਲ ਸਕਦੇ ਹਨ। ਲੰਬੇ ਸਮੇਂ ਚੱਲਣ ਵਾਲੇ ਕੰਮ context window ਨੂੰ ਭਰ ਦਿੰਦੇ ਹਨ, ਜੋ turns ਅਤੇ ਏਜੰਟਾਂ ਵਿਚਕਾਰ context ਦੇਣ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਸੋਚੋ ਕਿ ਇੱਕ ਏਜੰਟ skill ਨੂੰ call ਕਰ ਰਿਹਾ ਹੈ, ਜਵਾਬ ਲੈ ਰਿਹਾ ਹੈ, tool calls ਅਤੇ reasoning summaries ਜੋੜ ਰਿਹਾ ਹੈ—ਸੀਮਿਤ context window ਬਹੁਤ ਜਲਦੀ ਭਰ ਜਾਂਦੀ ਹੈ। ਜਿਵੇਂ-ਜਿਵੇਂ ਏਜੰਟ ਚੱਲਦਾ ਰਹਿੰਦਾ ਹੈ, ਮਹੱਤਵਪੂਰਨ context ਖੋਣ ਤੋਂ ਬਚਣ ਲਈ ਸਾਨੂੰ ਇੱਕ ਤਰੀਕੇ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਜਿਸ ਨਾਲ ਮੁੱਖ ਵੇਰਵੇ ਰੱਖੇ ਜਾਣ ਅਤੇ ਗੈਰ-ਜ਼ਰੂਰੀ ਚੀਜ਼ਾਂ ਹਟਾਈਆਂ ਜਾਣ। developers ਤੋਂ custom summarization ਜਾਂ state-carrying systems ਡਿਜ਼ਾਇਨ ਅਤੇ ਸੰਭਾਲਣ ਦੀ ਮੰਗ ਕਰਨ ਦੀ ਬਜਾਇ, ਅਸੀਂ Responses API ਵਿੱਚ native compaction ਜੋੜੀ, ਜੋ ਮਾਡਲ ਦੇ ਵਿਹਾਰ ਅਤੇ ਇਸ ਦੀ training ਨਾਲ ਅਨੁਕੂਲ ਹੋਣ ਲਈ ਬਣਾਈ ਗਈ ਹੈ.

ਸਾਡੇ ਨਵੇਂ ਮਾਡਲ ਪਹਿਲਾਂ ਦੀ conversation state ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨ ਅਤੇ ਇੱਕ compaction item ਬਣਾਉਣ ਲਈ trained ਹਨ ਜੋ encrypted token-efficient representation ਵਿੱਚ ਮੁੱਖ ਪਹਿਲਾਂ ਦੀ state ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ। compaction ਤੋਂ ਬਾਅਦ, ਅਗਲੀ context window ਇਸ compaction item ਅਤੇ ਪਹਿਲਾਂ ਵਾਲੀ window ਦੇ high-value ਹਿੱਸਿਆਂ ਤੋਂ ਬਣਦੀ ਹੈ। ਇਸ ਨਾਲ workflows ਨੂੰ window boundaries ਪਾਰ ਵੀ ਇੱਕਸਾਰ ਤਰੀਕੇ ਨਾਲ ਜਾਰੀ ਰੱਖਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਭਾਵੇਂ session ਲੰਬੀ multi-step ਅਤੇ tool-driven ਹੀ ਕਿਉਂ ਨਾ ਹੋਵੇ। Codex ਇਸ mechanism ‘ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਤਾਂ ਜੋ ਲੰਬੇ ਸਮੇਂ ਚੱਲਣ ਵਾਲੇ coding tasks ਅਤੇ iterative tool execution ਦੀ ਗੁਣਵੱਤਾ ਘਟੇ ਬਿਨਾ ਚੱਲ ਸਕਣ.

Compaction server ਵਿੱਚ built-in ਤੌਰ ‘ਤੇ ਜਾਂ ਇੱਕ standalone /compact ਐਂਡਪੌਇੰਟ ਰਾਹੀਂ ਉਪਲਬਧ ਹੈ। Server-side compaction ਤੁਹਾਨੂੰ threshold configure ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ, ਅਤੇ system compaction ਦੇ ਸਮੇਂ ਨੂੰ ਆਪ ਸੰਭਾਲਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਜਟਿਲ client-side logic ਦੀ ਲੋੜ ਖਤਮ ਹੁੰਦੀ ਹੈ। ਇਹ ਛੋਟੇ overages ਨੂੰ compaction ਤੋਂ ਠੀਕ ਪਹਿਲਾਂ ਬਰਦਾਸ਼ਤ ਕਰਨ ਲਈ ਕੁਝ ਵੱਡੀ effective input context window ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਜੋ limit ਦੇ ਨੇੜੇ requests reject ਹੋਣ ਦੀ ਬਜਾਇ process ਅਤੇ compact ਕੀਤੀਆਂ ਜਾ ਸਕਣ। ਜਿਵੇਂ-ਜਿਵੇਂ model training ਵਿਕਸਿਤ ਹੁੰਦੀ ਹੈ, native compaction solution ਵੀ ਹਰ OpenAI model release ਨਾਲ ਵਿਕਸਿਤ ਹੁੰਦੀ ਰਹਿੰਦੀ ਹੈ.

Codex ਨੇ compaction system ਬਣਾਉਣ ਵਿੱਚ ਸਾਡੀ ਮਦਦ ਕੀਤੀ ਅਤੇ ਨਾਲ ਹੀ ਇਸਦਾ ਇੱਕ ਸ਼ੁਰੂਆਤੀ ਯੂਜ਼ਰ ਵੀ ਰਿਹਾ। ਜਦੋਂ ਇੱਕ Codex instance ਨੂੰ compaction error ਆਉਂਦੀ ਸੀ, ਅਸੀਂ ਜਾਂਚ ਲਈ ਦੂਜੀ instance ਚਲਾ ਦਿੰਦੇ ਸੀ। ਨਤੀਜਾ ਇਹ ਨਿਕਲਿਆ ਕਿ Codex ਨੂੰ ਸਮੱਸਿਆ ‘ਤੇ ਕੰਮ ਕਰਕੇ ਹੀ ਇੱਕ native, ਪ੍ਰਭਾਵਸ਼ਾਲੀ compaction system ਮਿਲ ਗਿਆ। Codex ਦੀ ਇਹ ਸਮਰੱਥਾ ਕਿ ਇਹ ਖੁਦ ਨੂੰ ਜਾਂਚ ਅਤੇ ਸੁਧਾਰ ਸਕਦਾ ਹੈ, OpenAI ਵਿੱਚ ਕੰਮ ਕਰਨ ਦਾ ਖਾਸ ਦਿਲਚਸਪ ਹਿੱਸਾ ਬਣ ਗਈ ਹੈ। ਜ਼ਿਆਦਾਤਰ tools ਸਿਰਫ਼ ਇਹ ਮੰਗਦੇ ਹਨ ਕਿ ਯੂਜ਼ਰ ਉਹਨਾਂ ਨੂੰ ਵਰਤਣਾ ਸਿੱਖੇ; Codex ਸਾਡੇ ਨਾਲ-ਨਾਲ ਸਿੱਖਦਾ ਹੈ.

ਹੁਣ ਆਓ state ਅਤੇ resources ਦੀ ਗੱਲ ਕਰੀਏ। ਕੰਟੇਨਰ ਸਿਰਫ਼ commands ਚਲਾਉਣ ਦੀ ਜਗ੍ਹਾ ਨਹੀਂ, ਸਗੋਂ ਮਾਡਲ ਲਈ working context ਵੀ ਹੈ। ਕੰਟੇਨਰ ਦੇ ਅੰਦਰ, ਮਾਡਲ files ਪੜ੍ਹ ਸਕਦਾ ਹੈ, databases query ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ network policy controls ਹੇਠਾਂ ਬਾਹਰੀ systems ਤੱਕ ਪਹੁੰਚ ਕਰ ਸਕਦਾ ਹੈ.

ਕੰਟੇਨਰ context ਦਾ ਪਹਿਲਾ ਹਿੱਸਾ file system ਹੈ, ਜੋ resources upload, organize, ਅਤੇ manage ਕਰਨ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। ਅਸੀਂ ਮਾਡਲ ਨੂੰ ਉਪਲਬਧ data ਦਾ ਨਕਸ਼ਾ ਦੇਣ ਅਤੇ ਇਸਨੂੰ ਵੱਡੀਆਂ, ਸ਼ੋਰ ਵਾਲੀਆਂ scans ਕਰਨ ਦੀ ਬਜਾਇ target ਕੀਤੀਆਂ file operations ਚੁਣਨ ਵਿੱਚ ਮਦਦ ਦੇਣ ਲਈ container ਅਤੇ file⁠(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ) APIs ਬਣਾਈਆਂ ਹਨ.

ਇੱਕ ਆਮ anti-pattern ਇਹ ਹੈ ਕਿ ਸਾਰਾ ਇਨਪੁੱਟ ਸਿੱਧਾ ਪ੍ਰੌੰਪਟ context ਵਿੱਚ ਭਰ ਦਿੱਤਾ ਜਾਵੇ। ਜਿਵੇਂ-ਜਿਵੇਂ inputs ਵਧਦੇ ਹਨ, ਪ੍ਰੌੰਪਟ ਨੂੰ ਅਤਿ-ਭਰਨਾ ਮਹਿੰਗਾ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਮਾਡਲ ਲਈ ਇਸ ਵਿੱਚ ਰਾਹ ਲੱਭਣਾ ਔਖਾ ਹੋ ਜਾਂਦਾ ਹੈ। ਇੱਕ ਵਧੀਆ pattern ਇਹ ਹੈ ਕਿ resources ਨੂੰ container file system ਵਿੱਚ stage ਕੀਤਾ ਜਾਵੇ ਅਤੇ ਮਾਡਲ ਨੂੰ ਇਹ ਫ਼ੈਸਲਾ ਕਰਨ ਦਿੱਤਾ ਜਾਵੇ ਕਿ shell commands ਨਾਲ ਕੀ ਖੋਲ੍ਹਣਾ, parse ਕਰਨਾ ਜਾਂ transform ਕਰਨਾ ਹੈ। ਬਿਲਕੁਲ ਮਨੁੱਖਾਂ ਵਾਂਗ, ਮਾਡਲ ਵੀ ਸੁਧਰੇ ਹੋਏ ਜਾਣਕਾਰੀ ਨਾਲ ਵਧੀਆ ਕੰਮ ਕਰਦੇ ਹਨ.

ਕੰਟੇਨਰ context ਦਾ ਦੂਜਾ ਹਿੱਸਾ databases ਹਨ। ਕਈ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਅਸੀਂ developers ਨੂੰ ਸੁਝਾਅ ਦਿੰਦੇ ਹਾਂ ਕਿ structured data ਨੂੰ SQLite ਵਰਗੀਆਂ databases ਵਿੱਚ store ਕੀਤਾ ਜਾਵੇ ਅਤੇ ਉਹਨਾਂ ਨੂੰ query ਕੀਤਾ ਜਾਵੇ। ਉਦਾਹਰਨ ਵਜੋਂ, ਪੂਰੀ spreadsheet ਨੂੰ ਪ੍ਰੌੰਪਟ ਵਿੱਚ ਕਾਪੀ ਕਰਨ ਦੀ ਬਜਾਇ, ਤੁਸੀਂ ਮਾਡਲ ਨੂੰ tables ਦਾ ਵੇਰਵਾ ਦੇ ਸਕਦੇ ਹੋ—ਕਿਹੜੇ columns ਮੌਜੂਦ ਹਨ ਅਤੇ ਉਹਨਾਂ ਦਾ ਕੀ ਅਰਥ ਹੈ—ਅਤੇ ਇਸਨੂੰ ਆਪਣੀ ਲੋੜ ਵਾਲੀਆਂ rows ਖਿੱਚਣ ਦਿਓ.

ਉਦਾਹਰਨ ਲਈ, ਜੇ ਤੁਸੀਂ ਪੁੱਛਦੇ ਹੋ, “ਇਸ quarter ਵਿੱਚ ਕਿਹੜੇ products ਦੀ sales ਘਟੀ?” ਤਾਂ ਮਾਡਲ ਪੂਰੀ spreadsheet ਸਕੈਨ ਕਰਨ ਦੀ ਬਜਾਇ ਕੇਵਲ ਸੰਬੰਧਿਤ rows query ਕਰ ਸਕਦਾ ਹੈ। ਇਹ ਵੱਡੇ datasets ਲਈ ਹੋਰ ਤੇਜ਼, ਸਸਤਾ ਅਤੇ ਵਧੇਰੇ scalable ਹੈ.

ਕੰਟੇਨਰ context ਦਾ ਤੀਜਾ ਹਿੱਸਾ ਨੈੱਟਵਰਕ ਪਹੁੰਚ ਹੈ, ਜੋ ਏਜੰਟ workloads ਦਾ ਇੱਕ ਲਾਜ਼ਮੀ ਹਿੱਸਾ ਹੈ। ਏਜੰਟ workflow ਨੂੰ live data ਲਿਆਉਣ, ਬਾਹਰੀ APIs ਨੂੰ call ਕਰਨ ਜਾਂ packages install ਕਰਨ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ। ਇਸੇ ਸਮੇਂ, ਕੰਟੇਨਰਾਂ ਨੂੰ ਬਿਨਾ ਰੋਕ-ਟੋਕ internet access ਦੇਣਾ ਖ਼ਤਰਨਾਕ ਹੋ ਸਕਦਾ ਹੈ: ਇਹ ਜਾਣਕਾਰੀ ਨੂੰ ਬਾਹਰੀ websites ਤੱਕ ਪਹੁੰਚਾ ਸਕਦਾ ਹੈ, ਅਣਜਾਣੇ ਵਿੱਚ ਸੰਵੇਦਨਸ਼ੀਲ internal ਜਾਂ third-party systems ਨੂੰ ਛੂਹ ਸਕਦਾ ਹੈ, ਜਾਂ credentials leak ਅਤੇ data exfiltration ਤੋਂ ਬਚਾਅ ਕਰਨਾ ਔਖਾ ਬਣਾ ਸਕਦਾ ਹੈ.

ਇਨ੍ਹਾਂ ਚਿੰਤਾਵਾਂ ਦਾ ਹੱਲ ਕਰਨ ਲਈ ਬਿਨਾ ਏਜੰਟਾਂ ਦੀ ਵਰਤੋਂਯੋਗਤਾ ਘਟਾਏ, ਅਸੀਂ hosted containers ਇਸ ਤਰ੍ਹਾਂ ਬਣਾਏ ਕਿ ਉਹ sidecar egress proxy ਵਰਤਣ। ਸਾਰੀਆਂ outbound network requests ਇੱਕ ਕੇਂਦਰੀ policy layer ਰਾਹੀਂ ਲੰਘਦੀਆਂ ਹਨ ਜੋ allowlists ਅਤੇ access controls ਲਾਗੂ ਕਰਦੀ ਹੈ ਅਤੇ ਨਾਲ ਹੀ traffic ਨੂੰ observable ਰੱਖਦੀ ਹੈ। credentials ਲਈ, ਅਸੀਂ egress ‘ਤੇ domain-scoped secret injection ਵਰਤਦੇ ਹਾਂ। ਮਾਡਲ ਅਤੇ ਕੰਟੇਨਰ ਸਿਰਫ਼ placeholders ਵੇਖਦੇ ਹਨ, ਜਦਕਿ raw secret values ਮਾਡਲ-ਵਿਖਾਈ ਦੇਣ ਵਾਲੇ context ਤੋਂ ਬਾਹਰ ਰਹਿੰਦੀਆਂ ਹਨ ਅਤੇ ਸਿਰਫ਼ ਮਨਜ਼ੂਰਸ਼ੁਦਾ destinations ਲਈ ਹੀ ਲਾਗੂ ਹੁੰਦੀਆਂ ਹਨ। ਇਸ ਨਾਲ leakage ਦਾ ਖ਼ਤਰਾ ਘਟਦਾ ਹੈ, ਜਦਕਿ authenticated external calls ਫਿਰ ਵੀ ਸੰਭਵ ਰਹਿੰਦੀਆਂ ਹਨ.

ਸ਼ੈੱਲ commands ਸ਼ਕਤੀਸ਼ਾਲੀ ਹਨ, ਪਰ ਕਈ ਕੰਮ ਇੱਕੋ ਜਿਹੇ multi-step patterns ਨੂੰ ਦੁਹਰਾਉਂਦੇ ਹਨ। ਏਜੰਟਾਂ ਨੂੰ ਹਰ run ਵਿੱਚ workflow ਮੁੜ ਖੋਜਣਾ ਪੈਂਦਾ ਹੈ—ਮੁੜ ਯੋਜਨਾ ਬਣਾਉਣੀ, ਮੁੜ commands ਜਾਰੀ ਕਰਨੀ, ਅਤੇ conventions ਮੁੜ ਸਿੱਖਣੀਆਂ—ਜਿਸ ਨਾਲ ਨਤੀਜੇ ਅਸੰਗਤ ਬਣਦੇ ਹਨ ਅਤੇ execution ਵਿਅਰਥ ਜਾਂਦੀ ਹੈ। Agent skills⁠(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ) ਉਹਨਾਂ patterns ਨੂੰ ਮੁੜ-ਵਰਤਣਯੋਗ, composable building blocks ਵਿੱਚ ਪੈਕ ਕਰਦੀਆਂ ਹਨ। ਠੋਸ ਤੌਰ ‘ਤੇ, ਇੱਕ skill ਇੱਕ folder bundle ਹੁੰਦੀ ਹੈ ਜਿਸ ਵਿੱਚ ‘SKILL.md⁠(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ)’ (ਜਿਸ ਵਿੱਚ metadata ਅਤੇ instructions ਹੁੰਦੀਆਂ ਹਨ) ਨਾਲ ਨਾਲ ਹੋਰ supporting resources ਹੁੰਦੇ ਹਨ, ਜਿਵੇਂ API specs ਅਤੇ UI assets.

ਇਹ structure ਸਾਡੇ ਪਹਿਲਾਂ ਵਰਣਨ ਕੀਤੇ runtime architecture ਨਾਲ ਕੁਦਰਤੀ ਤੌਰ ‘ਤੇ ਮੇਲ ਖਾਂਦਾ ਹੈ। ਕੰਟੇਨਰ persistent files ਅਤੇ execution context ਦਿੰਦਾ ਹੈ, ਅਤੇ shell tool execution interface ਦਿੰਦਾ ਹੈ। ਜਦੋਂ ਇਹ ਦੋਵੇਂ ਮੌਜੂਦ ਹੁੰਦੇ ਹਨ, ਮਾਡਲ ਲੋੜ ਪੈਣ ‘ਤੇ shell commands (`ls`, `cat`, ਆਦਿ) ਵਰਤ ਕੇ skill files ਖੋਜ ਸਕਦਾ ਹੈ, instructions ਨੂੰ ਸਮਝ ਸਕਦਾ ਹੈ ਅਤੇ skill scripts ਨੂੰ ਇਕੋ agent loop ਵਿੱਚ ਚਲਾ ਸਕਦਾ ਹੈ.

ਅਸੀਂ OpenAI platform ਵਿੱਚ skills ਨੂੰ manage ਕਰਨ ਲਈ APIs⁠(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ) ਦਿੰਦੇ ਹਾਂ। Developers skill folders ਨੂੰ versioned bundles ਵਜੋਂ upload ਅਤੇ store ਕਰਦੇ ਹਨ, ਜਿਨ੍ਹਾਂ ਨੂੰ ਬਾਅਦ ਵਿੱਚ skill ID ਰਾਹੀਂ ਪ੍ਰਾਪਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਮਾਡਲ ਨੂੰ ਪ੍ਰੌੰਪਟ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ, Responses API skill ਨੂੰ load ਕਰਦੀ ਹੈ ਅਤੇ ਇਸਨੂੰ model context ਵਿੱਚ ਸ਼ਾਮਲ ਕਰਦੀ ਹੈ। ਇਹ ਕ੍ਰਮ deterministic ਹੈ:

1. skill metadata ਲਿਆਓ, ਜਿਸ ਵਿੱਚ ਨਾਮ ਅਤੇ ਵਰਣਨ ਸ਼ਾਮਲ ਹਨ.
2. skill bundle ਲਿਆਓ, ਇਸਨੂੰ ਕੰਟੇਨਰ ਵਿੱਚ ਕਾਪੀ ਕਰੋ, ਅਤੇ unpack ਕਰੋ.
3. skill metadata ਅਤੇ container path ਨਾਲ model context ਅਪਡੇਟ ਕਰੋ.

ਜਦੋਂ ਇਹ ਫ਼ੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਕੋਈ skill ਸੰਬੰਧਿਤ ਹੈ ਜਾਂ ਨਹੀਂ, ਮਾਡਲ ਹੌਲੀ-ਹੌਲੀ ਇਸ ਦੀਆਂ instructions ਦੀ ਪੜਚੋਲ ਕਰਦਾ ਹੈ ਅਤੇ ਕੰਟੇਨਰ ਵਿੱਚ shell commands ਰਾਹੀਂ ਇਸ ਦੀਆਂ scripts ਚਲਾਂਦਾ ਹੈ.

ਸਾਰੇ ਹਿੱਸੇ ਇਕੱਠੇ ਕਰਕੇ: Responses API orchestration ਦਿੰਦੀ ਹੈ, shell tool ਚਲਣਯੋਗ actions ਦਿੰਦਾ ਹੈ, hosted container persistent runtime context ਦਿੰਦਾ ਹੈ, skills ਮੁੜ-ਵਰਤਣਯੋਗ workflow logic ਦੀ layer ਦਿੰਦੀਆਂ ਹਨ, ਅਤੇ compaction ਏਜੰਟ ਨੂੰ ਲੋੜੀਂਦੇ context ਨਾਲ ਲੰਮੇ ਸਮੇਂ ਤੱਕ ਚੱਲਣ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ.

ਇਨ੍ਹਾਂ primitives ਨਾਲ, ਇੱਕੋ ਪ੍ਰੌੰਪਟ end-to-end workflow ਵਿੱਚ ਫੈਲ ਸਕਦਾ ਹੈ: ਸਹੀ skill ਖੋਜੋ, data ਲਿਆਓ, ਇਸਨੂੰ ਲੋਕਲ structured state ਵਿੱਚ ਬਦਲੋ, ਇਸਨੂੰ ਕੁਸ਼ਲਤਾ ਨਾਲ query ਕਰੋ, ਅਤੇ ਟਿਕਾਊ artifacts ਬਣਾਓ. 

ਹੇਠਾਂ ਦਿੱਤਾ ਡਾਇਗ੍ਰਾਮ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ live data ਤੋਂ spreadsheet ਬਣਾਉਣ ਲਈ ਇਹ ਸਿਸਟਮ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ.

end-to-end workflows ਲਈ shell tool ਅਤੇ computer environment ਨੂੰ ਜੋੜਨ ਦਾ ਵਿਸਥਾਰਪੂਰਣ ਉਦਾਹਰਨ ਵੇਖਣ ਲਈ, ਸਾਡੀ developer blog post⁠(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ) ਅਤੇ cookbook⁠(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ) ਵੇਖੋ, ਜੋ skill ਨੂੰ package ਕਰਨ ਅਤੇ ਇਸਨੂੰ Responses API ਰਾਹੀਂ ਚਲਾਉਣ ਦੀ ਵਿਵਰਣਾ ਦਿੰਦੀਆਂ ਹਨ.

ਅਸੀਂ ਇਹ ਦੇਖਣ ਲਈ ਉਤਸ਼ਾਹਿਤ ਹਾਂ ਕਿ developers ਇਨ੍ਹਾਂ primitives ਦੇ ਸੈੱਟ ਨਾਲ ਕੀ ਬਣਾਉਂਦੇ ਹਨ। Language models ਸਿਰਫ਼ text, images, ਅਤੇ audio ਬਣਾਉਣ ਲਈ ਨਹੀਂ ਹਨ–ਅਸੀਂ ਆਪਣੇ platform ਨੂੰ ਅੱਗੇ ਵੀ ਵਿਕਸਿਤ ਕਰਦੇ ਰਹਾਂਗੇ ਤਾਂ ਜੋ ਇਹ ਵੱਡੇ ਪੱਧਰ ‘ਤੇ ਜਟਿਲ, ਅਸਲੀ ਦੁਨੀਆ ਦੇ ਕੰਮ ਸੰਭਾਲਣ ਵਿੱਚ ਹੋਰ ਸਮਰੱਥ ਬਣੇ.