ಜನವರಿ 23, 2026

Codex ಏಜೆಂಟ್ ಲೂಪ್ ಅನ್ನು ಅನ್‌ರೋಲ್ ಮಾಡುವುದು

ಮೈಕಲ್ ಬೋಲಿನ್, ತಾಂತ್ರಿಕ ಸಿಬ್ಬಂದಿಯ ಸದಸ್ಯ

ಲೋಡ್ ಆಗುತ್ತಿದೆ…

Codex CLI⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) ನಮ್ಮ ಅಂತರ-ವೇದಿಕೆ ಸ್ಥಳೀಯ ಸಾಫ್ಟ್‌ವೇರ್ ಏಜೆಂಟ್ ಆಗಿದ್ದು, ನಿಮ್ಮ ಯಂತ್ರದಲ್ಲಿ ಸುರಕ್ಷಿತವಾಗಿ ಮತ್ತು ದಕ್ಷವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಾ, ಉನ್ನತ-ಗುಣಮಟ್ಟದ, ನಂಬಿಕಸ್ಥ ಸಾಫ್ಟ್‌ವೇರ್ ಬದಲಾವಣೆಗಳನ್ನು ಉತ್ಪಾದಿಸಲು ಇದನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ. ನಾವು ಏಪ್ರಿಲ್‌ನಲ್ಲಿ ಮೊದಲ ಬಾರಿ CLI ಅನ್ನು ಬಿಡುಗಡೆ ಮಾಡಿದಾಗಿನಿಂದ⁠ ವಿಶ್ವದರ್ಜೆಯ ಸಾಫ್ಟ್‌ವೇರ್ ಏಜೆಂಟ್ ಅನ್ನು ಹೇಗೆ ನಿರ್ಮಿಸಬೇಕು ಎಂಬುದರ ಬಗ್ಗೆ ನಾವು ಅಪಾರವಾಗಿ ಕಲಿತಿದ್ದೇವೆ. ಆ ಒಳನೋಟಗಳನ್ನು ವಿವರಿಸಲು, Codex ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂಬುದರ ವಿವಿಧ ಅಂಶಗಳನ್ನು ಮತ್ತು ಕಷ್ಟಪಟ್ಟು ಕಲಿತ ಪಾಠಗಳನ್ನು ನಾವು ಅನ್ವೇಷಿಸುವ, ನಿರಂತರ ಸರಣಿಯ ಮೊದಲ ಪೋಸ್ಟ್ ಇದು. (Codex CLI ಹೇಗೆ ನಿರ್ಮಿಸಲಾಗಿದೆ ಎಂಬುದರ ಇನ್ನೂ ಹೆಚ್ಚು ಸೂಕ್ಷ್ಮ ದೃಶ್ಯಕ್ಕಾಗಿ, ನಮ್ಮ ಓಪನ್ ಸೋರ್ಸ್ ರಿಪೊಸಿಟರಿ https://github.com/openai/codex⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) ನಲ್ಲಿ ಪರಿಶೀಲಿಸಿ. ನೀವು ಇನ್ನಷ್ಟು ತಿಳಿಯಲು ಬಯಸಿದರೆ, ನಮ್ಮ ವಿನ್ಯಾಸ ನಿರ್ಧಾರಗಳ ಅನೇಕ ಸೂಕ್ಷ್ಮ ವಿವರಗಳನ್ನು GitHub ಇಶ್ಯೂಗಳು ಮತ್ತು ಪುಲ್ ರಿಕ್ವೆಸ್ಟ್‌ಗಳಲ್ಲಿ ದಾಖಲಿಸಲಾಗಿದೆ.)

ಆರಂಭಿಸಲು, ನಾವು ಏಜೆಂಟ್ ಲೂಪ್ ಮೇಲೆ ಗಮನಹರಿಸುತ್ತೇವೆ, ಇದು Codex CLI ಯಲ್ಲಿನ ಪ್ರಮುಖ ಲಾಜಿಕ್ ಆಗಿದ್ದು, ಬಳಕೆದಾರ, ಮಾಡೆಲ್, ಮತ್ತು ಮಾಡೆಲ್ ಕರೆಯುವ ಸಾಧನಗಳ ನಡುವಿನ ಸಂವಹನವನ್ನು ಸಮನ್ವಯಗೊಳಿಸುವ ಜವಾಬ್ದಾರಿಯನ್ನು ಹೊಂದಿದೆ, ಅರ್ಥಪೂರ್ಣ ಸಾಫ್ಟ್‌ವೇರ್ ಕೆಲಸವನ್ನು ಮಾಡಲು. ನಾವು ಈ ಪೋಸ್ಟ್ ನಿಮಗೆ LLM ಅನ್ನು ಬಳಸುವಲ್ಲಿ ನಮ್ಮ ಏಜೆಂಟ್ (ಅಥವಾ “ಹಾರ್ನೆಸ್”) ವಹಿಸುವ ಪಾತ್ರದ ಉತ್ತಮ ದೃಷ್ಟಿಕೋನವನ್ನು ನೀಡುತ್ತದೆ ಎಂದು ಭಾವಿಸುತ್ತೇವೆ.

ನಾವು ಆರಂಭಿಸುವ ಮೊದಲು, ಪದಪ್ರಯೋಗದ ಕುರಿತು ಒಂದು ಚಿಕ್ಕ ಟಿಪ್ಪಣಿ: OpenAI ನಲ್ಲಿ, “Codex” Codex CLI, Codex Cloud, ಮತ್ತು Codex VS Code ಎಕ್ಸ್‌ಟೆನ್ಶನ್ ಅನ್ನು ಒಳಗೊಂಡ ಸಾಫ್ಟ್‌ವೇರ್ ಏಜೆಂಟ್ ಆಫರ್‌ಗಳ ಸಮೂಹವಾಗಿದೆ. ಈ ಪೋಸ್ಟ್ Codex ಹಾರ್ನೆಸ್ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸಿದೆ, ಇದು ಎಲ್ಲಾ Codex ಅನುಭವಗಳಿಗೆ ಆಧಾರವಾಗಿರುವ ಮೂಲ ಏಜೆಂಟ್ ಲೂಪ್ ಮತ್ತು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಲಾಜಿಕ್ ಅನ್ನು ಒದಗಿಸುತ್ತದೆ ಮತ್ತು Codex CLI ಮೂಲಕ ಪ್ರದರ್ಶಿತವಾಗುತ್ತದೆ. ಇಲ್ಲಿ ಸುಲಭಕ್ಕಾಗಿ, ನಾವು “Codex” ಮತ್ತು “Codex CLI” ಎಂಬ ಪದಗಳನ್ನು ಪರಸ್ಪರ ಬದಲಾಯಿಸಿಕೊಂಡು ಬಳಸುತ್ತೀರಿ.

ಏಜೆಂಟ್ ಲೂಪ್

ಪ್ರತಿ AI ಏಜೆಂಟ್‌ನ ಹೃದಯದಲ್ಲಿ “ಏಜೆಂಟ್ ಲೂಪ್” ಎಂಬುದು ಇದೆ. ಏಜೆಂಟ್ ಲೂಪ್‌ನ ಸರಳೀಕೃತ ಚಿತ್ರಣ ಹೀಗಿದೆ:

“Agent loop” ಎಂಬ ಶೀರ್ಷಿಕೆಯ ರೇಖಾಚಿತ್ರವು AI ವ್ಯವಸ್ಥೆಯು ಬಳಕೆದಾರರ ವಿನಂತಿಯನ್ನು ಹೇಗೆ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ, ಉಪಕರಣಗಳನ್ನು ಕರೆಮಾಡುತ್ತದೆ, ಫಲಿತಾಂಶಗಳನ್ನು ಗಮನಿಸುತ್ತದೆ, ತನ್ನ ಯೋಜನೆಯನ್ನು ನವೀಕರಿಸುತ್ತದೆ, ಮತ್ತು ಔಟ್‌ಪುಟ್‌ಗಳನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ. ಬಾಣಗಳು ಬಳಕೆದಾರ ಇನ್‌ಪುಟ್, ಮಾಡೆಲ್ ರೀಜನಿಂಗ್, ಸಾಧನ ಕ್ರಮಗಳು ಮತ್ತು ಅಂತಿಮ ಪ್ರತಿಕ್ರಿಯೆ ಮುಂತಾದ ಹಂತಗಳನ್ನು ಸಂಪರ್ಕಿಸುತ್ತವೆ.

ಪ್ರಾರಂಭಿಸಲು, ಏಜೆಂಟ್ ಬಳಕೆದಾರರಿಂದ ಇನ್‌ಪುಟ್ ಅನ್ನು ಪಡೆದು, ಮಾಡೆಲ್‌ಗಾಗಿ ತಯಾರಿಸುವ ಪಠ್ಯ ಸೂಚನೆಗಳ ಸಮೂಹದಲ್ಲಿ ಸೇರಿಸುತ್ತದೆ, ಇದನ್ನು ಪ್ರಾಂಪ್ಟ್ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ.

ಮುಂದಿನ ಹಂತವೆಂದರೆ ನಮ್ಮ ಸೂಚನೆಗಳನ್ನು ಮಾಡೆಲ್‌ಗೆ ಕಳುಹಿಸಿ, ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ರಚಿಸಲು ಕೇಳುವುದು, ಇದನ್ನು ಇನ್‌ಫರೆನ್ಸ್ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ. ನಿರ್ಣಯದ ಸಮಯದಲ್ಲಿ, ಪಠ್ಯ ಪ್ರಾಂಪ್ಟ್ ಅನ್ನು ಮೊದಲು ಇನ್‌ಪುಟ್ ಟೋಕನ್‌ಗಳು⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ)ಗಳ ಸರಣಿಯಾಗಿ ಅನುವಾದಿಸಲಾಗುತ್ತದೆ—ಅಂದರೆ ಮಾಡೆಲ್‌ನ ಶಬ್ದಕೋಶಕ್ಕೆ ಸೂಚ್ಯಂಕಗೊಳಿಸುವ ಪೂರ್ಣಾಂಕಗಳು. ನಂತರ ಈ ಟೋಕನ್‌ಗಳನ್ನು ಮಾಡೆಲ್ ಅನ್ನು ಮಾದರಿಯಾಗಿಸಲು ಬಳಸಲಾಗುತ್ತದೆ, ಇದರಿಂದ ಔಟ್‌ಪುಟ್ ಟೋಕನ್‌ಗಳ ಹೊಸ ಕ್ರಮವನ್ನು ಉತ್ಪಾದಿಸಲಾಗುತ್ತದೆ.

ಔಟ್‌ಪುಟ್ ಟೋಕನ್‌ಗಳನ್ನು ಮತ್ತೆ ಪಠ್ಯಕ್ಕೆ ಅನುವಾದಿಸಲಾಗುತ್ತದೆ, ಇದು ಮಾಡೆಲ್‌ನ ಪ್ರತಿಕ್ರಿಯೆಯಾಗುತ್ತದೆ. ಟೋಕನ್‌ಗಳನ್ನು ಕ್ರಮೇಣವಾಗಿ ಉತ್ಪಾದಿಸುವುದರಿಂದ, ಮಾಡೆಲ್ ಕಾರ್ಯನಿರ್ವಹಿಸುವಾಗಲೇ ಈ ಅನುವಾದ ಸಂಭವಿಸಬಹುದು, ಇದರಿಂದ ಅನೇಕ LLM ಆಧಾರಿತ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಸ್ಟ್ರೀಮಿಂಗ್ ಔಟ್‌ಪುಟ್ ಅನ್ನು ತೋರಿಸುತ್ತವೆ. ಪ್ರಯೋಗದಲ್ಲಿ, ಇನ್‌ಫರೆನ್ಸ್ ಸಾಮಾನ್ಯವಾಗಿ ಪಠ್ಯದ ಮೇಲೆ ಕಾರ್ಯನಿರ್ವಹಿಸುವ API ಯ ಹಿಂದೆ ಸುತ್ತುವರಿಯಲ್ಪಟ್ಟಿರುತ್ತದೆ, ಟೋಕನೈಜೇಶನ್‌ನ ವಿವರಗಳನ್ನು ಅಮೂರ್ತಗೊಳಿಸುತ್ತದೆ.

ಇನ್‌ಫರೆನ್ಸ್ ಹಂತದ ಫಲಿತಾಂಶವಾಗಿ, ಮಾಡೆಲ್ (1) ಬಳಕೆದಾರರ ಮೂಲ ಇನ್‌ಪುಟ್‌ಗೆ ಅಂತಿಮ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ನೀಡುತ್ತದೆ, ಅಥವಾ (2) ಏಜೆಂಟ್ ನಿರ್ವಹಿಸಬೇಕೆಂದು ನಿರೀಕ್ಷಿಸಲಾದ ಟೂಲ್ ಕಾಲ್ ಅನ್ನು ವಿನಂತಿಸುತ್ತದೆ (ಉದಾ., “ls ಅನ್ನು ರನ್ ಮಾಡಿ ಮತ್ತು ಔಟ್‌ಪುಟ್ ಅನ್ನು ವರದಿ ಮಾಡಿ”). (2) ರ ಸಂದರ್ಭದಲ್ಲಿ, ಏಜೆಂಟ್ ಟೂಲ್ ಕಾಲ್ ಅನ್ನು ನಿರ್ವಹಿಸಿ, ಅದರ ಔಟ್‌ಪುಟ್ ಅನ್ನು ಮೂಲ ಪ್ರಾಂಪ್ಟ್‌ಗೆ ಸೇರಿಸುತ್ತದೆ. ಈ ಔಟ್‌ಪುಟ್ ಅನ್ನು ಹೊಸ ಇನ್‌ಪುಟ್ ರಚಿಸಲು ಬಳಸಲಾಗುತ್ತದೆ, ಇದು ಮಾಡೆಲ್ ಅನ್ನು ಮರು-ಕ್ವೆರಿ ಮಾಡಲು ಬಳಸಲಾಗುತ್ತದೆ; ನಂತರ ಏಜೆಂಟ್ ಈ ಹೊಸ ಮಾಹಿತಿಯನ್ನು ಪರಿಗಣಿಸಿ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸಬಹುದು.

ಈ ಪ್ರಕ್ರಿಯೆಯು ಮಾಡೆಲ್ ಟೂಲ್ ಕಾಲ್‌ಗಳನ್ನು ಹೊರಸೂಸುವುದನ್ನು ನಿಲ್ಲಿಸಿ, ಬದಲಾಗಿ ಬಳಕೆದಾರನಿಗಾಗಿ ಒಂದು ಸಂದೇಶವನ್ನು ಉತ್ಪಾದಿಸುವವರೆಗೆ (OpenAI ಮಾಡೆಲ್‌ಗಳಲ್ಲಿ ಇದನ್ನು ಅಸಿಸ್ಟೆಂಟ್ ಸಂದೇಶ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ) ಪುನರಾವರ್ತಿಸುತ್ತದೆ. ಅನೇಕ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಈ ಸಂದೇಶವು ಬಳಕೆದಾರರ ಮೂಲ ವಿನಂತಿಗೆ ನೇರವಾಗಿ ಉತ್ತರಿಸಬಹುದು, ಆದರೆ ಇದು ಬಳಕೆದಾರರಿಗೆ ಹಿಂಬಾಲಿಸುವ ಪ್ರಶ್ನೆಯಾಗಿಯೂ ಇರಬಹುದು.

ಏಜೆಂಟ್ ಸ್ಥಳೀಯ ಪರಿಸರವನ್ನು ಮಾರ್ಪಡಿಸುವ ಟೂಲ್ ಕಾಲ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸಬಹುದಾದ್ದರಿಂದ, ಅದರ “ಔಟ್‌ಪುಟ್” ಸಹಾಯಕ ಸಂದೇಶಕ್ಕೆ ಮಾತ್ರ ಸೀಮಿತವಾಗಿಲ್ಲ. ಅನೇಕ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಸಾಫ್ಟ್‌ವೇರ್ ಏಜೆಂಟ್‌ನ ಮುಖ್ಯ ಔಟ್‌ಪುಟ್ ಎಂದರೆ ಅದು ನಿಮ್ಮ ಯಂತ್ರದಲ್ಲಿ ಬರೆಯುವ ಅಥವಾ ಎಡಿಟ್ ಮಾಡುವ ಕೋಡ್. ಆದಾಗ್ಯೂ, ಪ್ರತಿ ತಿರುವು ಅಸಿಸ್ಟಂಟ್ ಸಂದೇಶದೊಂದಿಗೆ ಅಂತ್ಯಗೊಳ್ಳುತ್ತದೆ—ಉದಾಹರಣೆಗೆ “ನೀವು ಕೇಳಿದ architecture.md ಅನ್ನು ನಾನು ಸೇರಿಸಿದ್ದೇನೆ”—ಇದು ಏಜೆಂಟ್ ಲೂಪ್‌ನಲ್ಲಿ ಅಂತ್ಯ ಸ್ಥಿತಿಯನ್ನು ಸೂಚಿಸುತ್ತದೆ. ಏಜೆಂಟ್‌ನ ದೃಷ್ಟಿಕೋನದಿಂದ, ಅದರ ಕೆಲಸ ಪೂರ್ಣವಾಗಿದೆ ಮತ್ತು ನಿಯಂತ್ರಣವು ಬಳಕೆದಾರರಿಗೆ ಮರಳುತ್ತದೆ.

ರೇಖಾಚಿತ್ರದಲ್ಲಿ ತೋರಿಸಿರುವ ಬಳಕೆದಾರ ಇನ್‌ಪುಟ್ ನಿಂದ ಏಜೆಂಟ್ ಪ್ರತಿಕ್ರಿಯೆ ವರೆಗೆಗಿನ ಪ್ರಯಾಣವನ್ನು ಸಂಭಾಷಣೆಯ ಒಂದು ಟರ್ನ್ (Codex ನಲ್ಲಿ ಒಂದು ಥ್ರೆಡ್) ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ. ಈ ಸಂಭಾಷಣೆ ಟರ್ನ್ ಮಾಡೆಲ್ ಇನ್ಫರೆನ್ಸ್ ಮತ್ತು ಟೂಲ್ ಕಾಲ್‌ಗಳ ನಡುವೆ ಅನೇಕ ಪುನರಾವರ್ತನೆಗಳನ್ನು ಒಳಗೊಂಡಿರಬಹುದು. ನೀವು ಈಗಾಗಲೇ ಇರುವ ಸಂಭಾಷಣೆಗೆ ಪ್ರತೀ ಬಾರಿ ಹೊಸ ಸಂದೇಶವನ್ನು ಕಳುಹಿಸಿದಾಗ, ಸಂಭಾಷಣೆಯ ಇತಿಹಾಸವನ್ನು ಹೊಸ ಟರ್ನ್ ಪ್ರಾಂಪ್ಟ್‌ನ ಭಾಗವಾಗಿ ಸೇರಿಸಲಾಗುತ್ತದೆ, ಇದರಲ್ಲಿ ಹಿಂದಿನ ಟರ್ನ್ ಗಳ ಸಂದೇಶಗಳು ಮತ್ತು ಟೂಲ್ ಕಾಲ್‌ಗಳು ಒಳಗೊಂಡಿರುತ್ತವೆ:

“Multi-turn agent loop” ಎಂಬ ಶೀರ್ಷಿಕೆಯ ಡಯಾಗ್ರಾಂ, AI ಏಜೆಂಟ್‌ಗಳು ಪುನರಾವರ್ತಿತವಾಗಿ ಬಳಕೆದಾರರ ಇನ್‌ಪುಟ್ ಅನ್ನು ಸ್ವೀಕರಿಸುತ್ತವೆ, ಕ್ರಿಯೆಗಳನ್ನು ಸೃಷ್ಟಿಸುತ್ತವೆ, ಉಪಕರಣಗಳನ್ನು ಪರಾಮರ್ಶಿಸುತ್ತವೆ, ಸ್ಥಿತಿಯನ್ನು ನವೀಕರಿಸುತ್ತವೆ ಮತ್ತು ಫಲಿತಾಂಶಗಳನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತವೆ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ. ಏಜೆಂಟ್‌ನ ರೀಜನಿಂಗ್ ಚಕ್ರವನ್ನು ವಿವರಿಸುವ ಲೇಬಲ್ ಮಾಡಿದ ಹಂತಗಳು, ಬಾಣಗಳು ಮತ್ತು ಉದಾಹರಣೆಯ ಸಾಧನ ಔಟ್‌ಪುಟ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿದೆ.

ಇದರರ್ಥ ಸಂಭಾಷಣೆ ಬೆಳೆಯುತ್ತಿದ್ದಂತೆ, ಮಾಡೆಲ್ ಅನ್ನು ಮಾದರಿ ಮಾಡಲು ಬಳಸುವ ಪ್ರಾಂಪ್ಟ್‌ನ ಉದ್ದವೂ ಹೆಚ್ಚುತ್ತದೆ. ಈ ಉದ್ದವು ಮಹತ್ವದ್ದಾಗಿದೆ ಏಕೆಂದರೆ ಪ್ರತಿಯೊಂದು ಮಾಡೆಲ್‌ಗೆ ಸನ್ನಿವೇಶದ ವಿಂಡೋ ಇರುತ್ತದೆ, ಇದು ಒಂದು ಇನ್‌ಫರೆನ್ಸ್ ಕಾಲ್‌ಗೆ ಬಳಸಬಹುದಾದ ಗರಿಷ್ಠ ಟೋಕನ್‌ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಸೂಚಿಸುತ್ತದೆ. ಗಮನಿಸಿ ಈ ವಿಂಡೋದಲ್ಲಿ ಇನ್‌ಪುಟ್ ಮತ್ತು ಔಟ್‌ಪುಟ್ ಟೋಕನ್‌ಗಳು ಎರಡೂ ಸೇರಿವೆ. ನೀವು ಊಹಿಸಬಹುದಾದಂತೆ, ಒಂದು ಏಜೆಂಟ್ ಒಂದು ತಿರುವಿನಲ್ಲಿ ನೂರಾರು ಸಾಧನ ಕರೆಗಳನ್ನು ಮಾಡಲು ನಿರ್ಧರಿಸಬಹುದು, ಇದರಿಂದ ಸಂದರ್ಭ ವಿಂಡೋ ಖಾಲಿಯಾಗುವ ಸಾಧ್ಯತೆ ಇದೆ. ಈ ಕಾರಣಕ್ಕಾಗಿ, ಸನ್ನಿವೇಶದ ವಿಂಡೋ ನಿರ್ವಹಣೆ ಏಜೆಂಟ್‌ನ ಅನೇಕ ಜವಾಬ್ದಾರಿಗಳಲ್ಲೊಂದು. ಈಗ, Codex ಹೇಗೆ ಏಜೆಂಟ್ ಲೂಪ್ ಅನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನೋಡಲು ಮುಂದುವರಿಯೋಣ.

ಮಾಡೆಲ್ ಇನ್‌ಫರೆನ್ಸ್

Codex CLI Responses API⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) ಗೆ HTTP ವಿನಂತಿಗಳನ್ನು ಕಳುಹಿಸಿ ಮಾಡೆಲ್ ಇನ್ಫರೆನ್ಸ್ ಅನ್ನು ನಡೆಸುತ್ತದೆ. ನಾವು Codex ಮೂಲಕ ಮಾಹಿತಿ ಹೇಗೆ ಹರಿಯುತ್ತದೆ ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸುತ್ತೇವೆ, ಇದು ಏಜೆಂಟ್ ಲೂಪ್ ಅನ್ನು ಚಾಲನೆ ಮಾಡಲು Responses API ಅನ್ನು ಬಳಸುತ್ತದೆ.

Codex CLI ಬಳಸುವ Responses API ಎಂಡ್‌ಪಾಯಿಂಟ್ ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದಾಗಿದೆ⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ), ಆದ್ದರಿಂದ Responses API ಅನ್ನು ಅನುಷ್ಠಾನಗೊಳಿಸುವ⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) ಯಾವುದೇ ಎಂಡ್‌ಪಾಯಿಂಟ್‌ನೊಂದಿಗೆ ಇದನ್ನು ಬಳಸಬಹುದು:

ChatGPT ಲಾಗಿನ್ ಬಳಸುವಾಗ⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) Codex CLI ಜೊತೆಗೆ, ಇದು https://chatgpt.com/backend-api/codex/responses ಅನ್ನು ಎಂಡ್‌ಪಾಯಿಂಟ್ ಆಗಿ ಬಳಸುತ್ತದೆ
API-ಕೀ ಪ್ರಮಾಣೀಕರಣವನ್ನು ಬಳಸುವಾಗ⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) OpenAI ಹೋಸ್ಟ್ ಮಾಡಲಾದ ಮಾಡೆಲ್‌ಗಳೊಂದಿಗೆ, ಇದು https://api.openai.com/v1/responses ಅನ್ನು ಎಂಡ್‌ಪಾಯಿಂಟ್ ಆಗಿ ಬಳಸುತ್ತದೆ
Codex CLI ಅನ್ನು --oss ಸಹಿತ ರನ್ ಮಾಡುವಾಗ gpt-oss⁠ ಅನ್ನು ollama 0.13.4+⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) ಅಥವಾ LM Studio 0.3.39+⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) ಜೊತೆಗೆ ಬಳಸಲು, ಇದು ನಿಮ್ಮ ಕಂಪ್ಯೂಟರ್‌ನಲ್ಲಿ ಸ್ಥಳೀಯವಾಗಿ ಚಾಲನೆಯಲ್ಲಿರುವ http://localhost:11434/v1/responses ಗೆ ಡೀಫಾಲ್ಟ್ ಆಗುತ್ತದೆ
Codex CLI ಅನ್ನು Azure ಮುಂತಾದ ಕ್ಲೌಡ್ ಪೂರೈಕೆದಾರರಿಂದ ಹೋಸ್ಟ್ ಮಾಡಲಾದ Responses API ಜೊತೆ ಬಳಸಬಹುದು

ಸಂಭಾಷಣೆಯಲ್ಲಿನ ಮೊದಲ ನಿರ್ಣಯ ಕರೆಗಾಗಿ Codex ಪ್ರಾಂಪ್ಟ್ ಅನ್ನು ಹೇಗೆ ರಚಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನಾವು ಅನ್ವೇಷಿಸೋಣ.

ಆರಂಭಿಕ ಪ್ರಾಂಪ್ಟ್ ಅನ್ನು ನಿರ್ಮಾಣ ಮಾಡುವುದು

ಅಂತಿಮ ಬಳಕೆದಾರರಾಗಿ, ನೀವು Responses API ಅನ್ನು ಪ್ರಶ್ನಿಸಿದಾಗ ಮಾಡೆಲ್ ಅನ್ನು ಮಾದರಿಯಾಗಿಸಲು ಬಳಸಿದ ಪ್ರಾಂಪ್ಟ್ ಅನ್ನು ಪದಶಃ ನಿರ್ದಿಷ್ಟಪಡಿಸುವ ಅಗತ್ಯವಿಲ್ಲ. ಬದಲಾಗಿ, ನೀವು ನಿಮ್ಮ ಕ್ವೆರಿಯ ಭಾಗವಾಗಿ ವಿವಿಧ ಇನ್‌ಪುಟ್ ಪ್ರಕಾರಗಳನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತೀರಿ, ಮತ್ತು Responses API ಸರ್ವರ್ ಈ ಮಾಹಿತಿಯನ್ನು ಮಾಡೆಲ್ ಬಳಸಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾದ ಪ್ರಾಂಪ್ಟ್‌ಗೆ ಹೇಗೆ ರೂಪಿಸಬೇಕು ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ. ನೀವು ಪ್ರಾಂಪ್ಟ್ ಅನ್ನು “ಅಂಶಗಳ ಪಟ್ಟಿ” ಎಂದು ಪರಿಗಣಿಸಬಹುದು; ಈ ವಿಭಾಗವು ನಿಮ್ಮ ಪ್ರಶ್ನೆ ಹೇಗೆ ಆ ಪಟ್ಟಿಯಾಗಿ ಪರಿವರ್ತಿತವಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತದೆ.

ಆರಂಭಿಕ ಪ್ರಾಂಪ್ಟ್‌ಗಳಲ್ಲಿ, ಪಟ್ಟಿಯಲ್ಲಿನ ಪ್ರತಿಯೊಂದು ಅಂಶವು ಒಂದು ಪಾತ್ರದೊಂದಿಗೆ ಸಂಬಂಧಿತವಾಗಿದೆ. ಪಾತ್ರ ಸಂಬಂಧಿತ ವಿಷಯದ ತೂಕವನ್ನು ಸೂಚಿಸುತ್ತದೆ ಮತ್ತು ಇದು ಕೆಳಗಿನ ಮೌಲ್ಯಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ (ಪ್ರಾಮುಖ್ಯತೆಯ ಇಳಿಮುಖ ಕ್ರಮದಲ್ಲಿ): ಸಿಸ್ಟಂ, ಡೆವಲಪರ್, ಬಳಕೆದಾರ, ಅಸಿಸ್ಟಂಟ್.

Responses API⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) ಅನೇಕ ಪ್ಯಾರಾಮೀಟರ್‌ಗಳೊಂದಿಗೆ JSON ಪೇಲೋಡ್ ಅನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ. ನಾವು ಈ ಮೂರು ವಿಷಯಗಳ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸುತ್ತೇವೆ:

ಸೂಚನೆಗಳು⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ): ಮಾಡೆಲ್‌ನ ಸಂದರ್ಭಕ್ಕೆ ಸೇರಿಸಲಾದ ಸಿಸ್ಟಮ್ (ಅಥವಾ ಡೆವಲಪರ್) ಸಂದೇಶ
ಟೂಲ್‌ಗಳು⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ): ಮಾಡೆಲ್ ಪ್ರತಿಕ್ರಿಯೆ ರಚಿಸುವಾಗ ಕರೆ ಮಾಡಬಹುದಾದ ಸಾಧನಗಳ ಪಟ್ಟಿ
ಇನ್‌ಪುಟ್⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ): ಮಾಡೆಲ್‌ಗೆ ಪಠ್ಯ, ಚಿತ್ರ, ಅಥವಾ ಫೈಲ್ ಇನ್‌ಪುಟ್‌ಗಳ ಪಟ್ಟಿ

Codex ನಲ್ಲಿ, ಸೂಚನೆಗಳು ಕ್ಷೇತ್ರವನ್ನು model_instructions_file⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) ನಲ್ಲಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ್ದರೆ ~/.codex/config.toml ನಿಂದ ಓದಲಾಗುತ್ತದೆ; ಇಲ್ಲದಿದ್ದರೆ, ಮಾಡೆಲ್‌ಗೆ ಸಂಬಂಧಿಸಿದ base_instructions ಅನ್ನು⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) ಬಳಸಲಾಗುತ್ತದೆ. ಮಾಡೆಲ್-ನಿರ್ದಿಷ್ಟ ಸೂಚನೆಗಳು Codex repo ಯಲ್ಲಿ ಇರುತ್ತವೆ ಮತ್ತು CLI ಗೆ ಬಂಡಲ್ ಮಾಡಲಾಗುತ್ತವೆ (ಉದಾಹರಣೆಗೆ, gpt-5.2-codex_prompt.md⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ)).

ಟೂಲ್‌ಗಳು ಫೀಲ್ಡ್ ಒಂದು ಪಟ್ಟಿಯಾಗಿದೆ, ಇದು Responses API ಮೂಲಕ ವ್ಯಾಖ್ಯಾನಿಸಲಾದ ಸ್ಕೀಮಾ‌ಗೆ ಅನುಗುಣವಾಗಿರುವ ಟೂಲ್ ವ್ಯಾಖ್ಯಾನಗಳನ್ನು ಒಳಗೊಂಡಿದೆ. Codex ಗಾಗಿ, ಇದರಲ್ಲಿ Codex CLI ಒದಗಿಸುವ ಉಪಕರಣಗಳು, Codex ಗೆ ಲಭ್ಯವಾಗುವಂತೆ ಮಾಡಬೇಕಾದ Responses API ಒದಗಿಸುವ ಉಪಕರಣಗಳು, ಹಾಗೆಯೇ ಬಳಕೆದಾರರು MCP ಸರ್ವರ್‌ಗಳ ಮೂಲಕ ಸಾಮಾನ್ಯವಾಗಿ ಒದಗಿಸುವ ಉಪಕರಣಗಳು ಸೇರಿವೆ:

JavaScript

1[
2  // Codex's default shell tool for spawning new processes locally.
3  {
4    "type": "function",
5    "name": "shell",
6    "description": "Runs a shell command and returns its output...",
7    "strict": false,
8    "parameters": {
9      "type": "object",
10      "properties": {
11        "command": {"type": "array", "description": "The command to execute", ...},
12        "workdir": {"description": "The working directory...", ...},
13        "timeout_ms": {"description": "The timeout for the command...", ...},
14        ...
15      },
16      "required": ["command"],
17    }
18  }
19
20  // Codex's built-in plan tool.
21  {
22    "type": "function",
23    "name": "update_plan",
24    "description": "Updates the task plan...",
25    "strict": false,
26    "parameters": {
27      "type": "object",
28      "properties": {"plan":..., "explanation":...},
29      "required": ["plan"]
30    }
31  },
32
33  // Web search tool provided by the Responses API.
34  {
35    "type": "web_search",
36    "external_web_access": false
37  },
38
39  // MCP server for getting weather as configured in the
40  // user's ~/.codex/config.toml.
41  {
42    "type": "function",
43    "name": "mcp__weather__get-forecast",
44    "description": "Get weather alerts for a US state",
45    "strict": false,
46    "parameters": {
47      "type": "object",
48      "properties": {"latitude": {...}, "longitude": {...}},
49      "required": ["latitude", "longitude"]
50    }
51  }
52]

ಅಂತಿಮವಾಗಿ, JSON ಪೇಲೋಡ್‌ನ ಇನ್‌ಪುಟ್ ಕ್ಷೇತ್ರವು ಐಟಂಗಳ ಪಟ್ಟಿಯಾಗಿದೆ. ಬಳಕೆದಾರರ ಸಂದೇಶವನ್ನು ಸೇರಿಸುವ ಮೊದಲು Codex ಕೆಳಗಿನ ಅಂಶಗಳನ್ನು⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) ಇನ್ಫುಟ್ ಗೆ ಸೇರಿಸುತ್ತದೆ:

1. ಟೂಲ್‌ಗಳು ವಿಭಾಗದಲ್ಲಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾದ Codex ಒದಗಿಸಿದ shell ಟೂಲ್‌ಗೆ ಮಾತ್ರ ಅನ್ವಯಿಸುವ ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ ಅನ್ನು ವಿವರಿಸುವ role=developer ಹೊಂದಿರುವ ಸಂದೇಶ. ಅಂದರೆ, MCP ಸರ್ವರ್‌ಗಳಿಂದ ಒದಗಿಸಲಾದ ಇತರ ಸಾಧನಗಳು Codex ಮೂಲಕ ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ ಮಾಡಲಾಗುವುದಿಲ್ಲ ಮತ್ತು ತಮ್ಮದೇ ಗಾರ್ಡ್‌ರೆಲ್ಸ್ ಅನ್ನು ಜಾರಿಗೊಳಿಸುವ ಜವಾಬ್ದಾರಿ ಹೊಂದಿವೆ.

ಸಂದೇಶವನ್ನು ಒಂದು ಟೆಂಪ್ಲೇಟ್‌ನಿಂದ ನಿರ್ಮಿಸಲಾಗುತ್ತದೆ, ಅಲ್ಲಿ ವಿಷಯದ ಪ್ರಮುಖ ಭಾಗಗಳು Codex CLI ಗೆ ಸೇರಿಸಲಾದ ಮಾರ್ಕ್‌ಡೌನ್ ಸ್ನಿಪೆಟ್‌ಗಳಿಂದ ಬರುತ್ತವೆ, ಉದಾಹರಣೆಗೆ workspace_write.md⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) ಮತ್ತು on_request.md⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ):

ಸರಳ ಪಠ್ಯ

1<permissions instructions>
2  - description of the sandbox explaining file permissions and network access
3  - instructions for when to ask the user for permissions to run a shell command
4  - list of folders writable by Codex, if any
5</permissions instructions>

2. (ಐಚ್ಛಿಕ) ಬಳಕೆದಾರರ config.toml ಫೈಲ್‌ನಿಂದ ಓದಿದ developer_instructions ಮೌಲ್ಯವನ್ನು ಒಳಗೊಂಡಿರುವ role=developer ಹೊಂದಿರುವ ಒಂದು ಸಂದೇಶ.

3. (ಐಚ್ಛಿಕ) role=user ಹೊಂದಿರುವ ಸಂದೇಶ, ಇದರ ವಿಷಯವು “ಬಳಕೆದಾರರ ಸೂಚನೆಗಳು,” ಅವು ಒಂದೇ ಫೈಲ್‌ನಿಂದ ಪಡೆಯಲ್ಪಟ್ಟದ್ದಲ್ಲ, ಬದಲಾಗಿ ಬಹು ಮೂಲಗಳಿಂದ ಒಟ್ಟುಗೂಡಿಸಲ್ಪಟ್ಟಿವೆ⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ). ಸಾಮಾನ್ಯವಾಗಿ, ಹೆಚ್ಚಿನ ನಿರ್ದಿಷ್ಟ ಸೂಚನೆಗಳು ನಂತರದಲ್ಲಿ ಕಾಣಿಸುತ್ತವೆ:

$CODEX_HOME ನಲ್ಲಿ AGENTS.override.md ಮತ್ತು AGENTS.mdಫೈಲ್‌ಗಳ ವಿಷಯಗಳು
ಮಿತಿಗೆ ಒಳಪಟ್ಟು (ಡೀಫಾಲ್ಟ್ ಆಗಿ 32 KiB), cwd ನ Git/ಪ್ರಾಜೆಕ್ಟ್ ರೂಟ್‌ನಿಂದ (ಅದು ಅಸ್ತಿತ್ವದಲ್ಲಿದ್ದರೆ) cwd ತನಕ ಪ್ರತಿಯೊಂದು ಫೋಲ್ಡರ್‌ನಲ್ಲಿ ನೋಡಿ: AGENTS.override.md ಗಳಲ್ಲಿ ಯಾವುದಾದರೂ ಒಂದರ ವಿಷಯಗಳನ್ನು ಸೇರಿಸಿ, AGENTS.md, ಅಥವಾ config.tomlನಲ್ಲಿ project_doc_fallback_filenames ಮೂಲಕ ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಯಾವುದೇ ಫೈಲ್ ಹೆಸರು
ಯಾವುದೇ ಕೌಶಲ್ಯಗಳನ್ನು⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ್ದರೆ:
- ಕೌಶಲ್ಯಗಳ ಬಗ್ಗೆ ಒಂದು ಚಿಕ್ಕ ಪರಿಚಯ
- ಪ್ರತಿ ಕೌಶಲ್ಯಕ್ಕಾಗಿ ಕೌಶಲ್ಯ ಮೆಟಾಡೇಟಾ⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ)
- ಕೌಶಲ್ಯಗಳನ್ನು ಹೇಗೆ ಬಳಸುವುದು⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ)ಎಂಬುದರ ಕುರಿತು ಒಂದು ವಿಭಾಗ

4. role=user ಹೊಂದಿರುವ ಸಂದೇಶ, ಏಜೆಂಟ್ ಪ್ರಸ್ತುತ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿರುವ ಸ್ಥಳೀಯ ಪರಿಸರವನ್ನು ವಿವರಿಸುತ್ತದೆ. ಈ ಪ್ರಸ್ತುತ ಕಾರ್ಯನಿರ್ವಹಣಾ ಡೈರೆಕ್ಟರಿ ಮತ್ತು ಬಳಕೆದಾರರ ಶೆಲ್ ಅನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತದೆ⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ):

ಸರಳ ಪಠ್ಯ

1<environment_context>
2  <cwd>/Users/mbolin/code/codex5</cwd>
3  <shell>zsh</shell>
4</environment_context>

Codex ಎಲ್ಲಾ ಮೇಲ್ಕಂಡ ಲೆಕ್ಕಾಚಾರಗಳನ್ನು ಮಾಡಿ ಇನ್‌ಪುಟ್ ಅನ್ನು ಪ್ರಾರಂಭಗೊಳಿಸಿದ ನಂತರ, ಸಂಭಾಷಣೆಯನ್ನು ಪ್ರಾರಂಭಿಸಲು ಬಳಕೆದಾರರ ಸಂದೇಶವನ್ನು ಸೇರಿಸುತ್ತದೆ.

ಹಿಂದಿನ ಉದಾಹರಣೆಗಳು ಪ್ರತಿಯೊಂದು ಸಂದೇಶದ ವಿಷಯದ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸಿದ್ದವು, ಆದರೆ ಗಮನಿಸಿ, ಇನ್‌ಪುಟ್ ನ ಪ್ರತಿಯೊಂದು ಅಂಶವು ವಿಧ, ಪಾತ್ರ⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ), ಮತ್ತು ಕಂಟೆಂಟ್ ಹೊಂದಿರುವ JSON ಆಬ್ಜೆಕ್ಟ್ ಆಗಿದೆ, ಈ ಕೆಳಗಿನಂತೆ:

JSON

1{
2  "type": "message",
3  "role": "user",
4  "content": [
5    {
6      "type": "input_text",
7      "text": "Add an architecture diagram to the README.md"
8    }
9  ]
10}

Codex ಸಂಪೂರ್ಣ JSON ಪೇಲೋಡ್ ಅನ್ನು Responses API ಗೆ ಕಳುಹಿಸಲು ನಿರ್ಮಿಸಿದ ನಂತರ, ~/.codex/config.toml ನಲ್ಲಿ Responses API ಎಂಡ್‌ಪಾಯಿಂಟ್ ಅನ್ನು ಹೇಗೆ ಸಂರಚಿಸಲಾಗಿದೆ ಎಂಬುದರ ಮೇಲೆ ಅವಲಂಬಿಸಿ, ಅದು ಆಥರೈಜೇಷನ್ ಹೆಡರ್‌ನೊಂದಿಗೆ HTTP POST ವಿನಂತಿಯನ್ನು ಮಾಡುತ್ತದೆ (ನಿರ್ದಿಷ್ಟಪಡಿಸಿದರೆ ಹೆಚ್ಚುವರಿ HTTP ಹೆಡರ್‌ಗಳು ಮತ್ತು ಕ್ವೆರಿ ಪ್ಯಾರಾಮೀಟರ್‌ಗಳನ್ನು ಸೇರಿಸಲಾಗುತ್ತದೆ).

ಒಂದು OpenAI Responses API ಸರ್ವರ್ ವಿನಂತಿಯನ್ನು ಸ್ವೀಕರಿಸಿದಾಗ, ಅದು JSON ಅನ್ನು ಬಳಸಿ ಮಾಡೆಲ್‌ಗಾಗಿ ಪ್ರಾಂಪ್ಟ್ ಅನ್ನು ಈ ಕೆಳಗಿನಂತೆ ನಿರ್ಧರಿಸುತ್ತದೆ (ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು, Responses API ಯ ಕಸ್ಟಮ್ ಅನುಷ್ಠಾನವು ಬೇರೆ ಆಯ್ಕೆಯನ್ನು ಮಾಡಬಹುದು):

AI ಏಜೆಂಟ್ ಲೂಪ್‌ನ ಒಂದು ಹಂತವನ್ನು ತೋರಿಸುವ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್ ಚಿತ್ರ. ಒಬ್ಬ ಬಳಕೆದಾರರ ವಿನಂತಿ ಮಾಡೆಲ್‌ಗೆ ಪ್ರವೇಶಿಸುತ್ತದೆ, ಇದು ಒಂದು ಆಲೋಚನೆ, ಒಂದು ಸಾಧನದ ಹೆಸರಿನೊಂದಿಗೆ ಒಂದು ಕ್ರಿಯೆಯನ್ನು, ಮತ್ತು ಒಂದು ಸಾಧನದ ಇನ್‌ಪುಟ್ ಅನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ. ಟೂಲ್ ಅನ್ನು ಕರೆಸುವ ಮೊದಲು ಡಯಾಗ್ರಾಂ ಈ ಮಧ್ಯಂತರ ರೀಜನಿಂಗ್ ಹಂತವನ್ನು ಹೈಲೈಟ್ ಮಾಡುತ್ತದೆ.

ನೀವು ನೋಡಬಹುದಾದಂತೆ, ಪ್ರಾಂಪ್ಟ್‌ನಲ್ಲಿನ ಮೊದಲ ಮೂರು ಐಟಂ‌ಗಳ ಕ್ರಮವನ್ನು ಗ್ರಾಹಕನಲ್ಲ, ಸರ್ವರ್ ನಿರ್ಧರಿಸುತ್ತದೆ. ಆದರೂ, ಆ ಮೂರು ಅಂಶಗಳಲ್ಲಿ, ಟೂಲ್‌ಗಳು ಮತ್ತು ಸೂಚನೆಗಳು ಅನ್ನು ಗ್ರಾಹಕ ನಿರ್ಧರಿಸುವುದರಿಂದ, ಸಿಸ್ಟಂ ಸಂದೇಶದ ವಿಷಯ ಮಾತ್ರ ಸರ್ವರ್‌ನಿಂದ ನಿಯಂತ್ರಿಸಲಾಗುತ್ತದೆ. ಪ್ರಾಂಪ್ಟ್ ಅನ್ನು ಪೂರ್ಣಗೊಳಿಸಲು JSON ಪೇಲೋಡ್‌ನಿಂದ ಇನ್‌ಪುಟ್ ಅನ್ನು ಇವುಗಳು ಅನುಸರಿಸುತ್ತವೆ.

ಈಗ ನಮ್ಮ ಬಳಿ ಪ್ರಾಂಪ್ಟ್ ಇರುವುದರಿಂದ, ನಾವು ಮಾದರಿಯನ್ನು ಸ್ಯಾಂಪಲ್ ಮಾಡಲು ಸಿದ್ಧರಾಗಿದ್ದೇವೆ.

ಮೊದಲ ತಿರುವು

ಈ HTTP ವಿನಂತಿ ಪ್ರತಿಕ್ರಿಯೆಗಳ API ಗೆ Codex ನಲ್ಲಿ ಸಂಭಾಷಣೆಯ ಮೊದಲ “ತಿರುವು” ಅನ್ನು ಆರಂಭಿಸುತ್ತದೆ. ಸರ್ವರ್ Server-Sent Events (SSE⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ)) ಸ್ಟ್ರೀಮ್‌ಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತದೆ. ಪ್ರತಿ ಈವೆಂಟ್‌ನ ಡೇಟಾ ಒಂದು JSON ಪೇಲೋಡ್ ಆಗಿದ್ದು, "ವಿಧ" "ಪ್ರತಿಕ್ರಿಯೆ" ನಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ, ಇದು ಹೀಗಿರಬಹುದು (ಈವೆಂಟ್‌ಗಳ ಸಂಪೂರ್ಣ ಪಟ್ಟಿಯನ್ನು ನಮ್ಮ API ಡಾಕ್ಯುಮೆಂಟೇಶನ್⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) ನಲ್ಲಿ ಕಾಣಬಹುದು):

ಸರಳ ಪಠ್ಯ

1data: {"type":"response.reasoning_summary_text.delta","delta":"ah ", ...}
2data: {"type":"response.reasoning_summary_text.delta","delta":"ha!", ...}
3data: {"type":"response.reasoning_summary_text.done", "item_id":...}
4data: {"type":"response.output_item.added", "item":{...}}
5data: {"type":"response.output_text.delta", "delta":"forty-", ...}
6data: {"type":"response.output_text.delta", "delta":"two!", ...}
7data: {"type":"response.completed","response":{...}}

Codex ಈವೆಂಟ್‌ಗಳ ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಗ್ರಹಿಸುತ್ತದೆ⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) ಮತ್ತು ಅವುಗಳನ್ನು ಗ್ರಾಹಕ ಬಳಸಬಹುದಾದ ಆಂತರಿಕ ಈವೆಂಟ್ ಆಬ್ಜೆಕ್ಟ್‌ಗಳಾಗಿ ಮರುಪ್ರಕಟಿಸುತ್ತದೆ. response.output_text.delta ನಂತಹ ಈವೆಂಟ್‌ಗಳನ್ನು UI ಯಲ್ಲಿ ಸ್ಟ್ರೀಮಿಂಗ್ ಬೆಂಬಲಿಸಲು ಬಳಸಲಾಗುತ್ತದೆ, ಆದರೆ response.output_item.added ನಂತಹ ಇತರ ಈವೆಂಟ್‌ಗಳನ್ನು ಆಬ್ಜೆಕ್ಟ್‌ಗಳಾಗಿ ಪರಿವರ್ತಿಸಿ, ನಂತರದ Responses API ಕರೆಗಳಿಗಾಗಿ ಇನ್‌ಪುಟ್ ಗೆ ಸೇರಿಸಲಾಗುತ್ತದೆ.

Responses API ಗೆ ಮೊದಲ ವಿನಂತಿಯಲ್ಲಿ ಎರಡು response.output_item.done ಈವೆಂಟ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿದೆ ಎಂದು ಊಹಿಸಿ: ಒಂದು type=reasoning ಮತ್ತು ಒಂದು type=function_call. ನಾವು ಟೂಲ್ ಕಾಲ್‌ಗೆ ಪ್ರತಿಕ್ರಿಯೆಯೊಂದಿಗೆ ಮತ್ತೆ ಮಾಡೆಲ್ ಅನ್ನು ಕ್ವೆರಿ ಮಾಡುವಾಗ, ಈ ಈವೆಂಟ್‌ಗಳನ್ನು JSON‌ನ ಇನ್‌ಪುಟ್ ಫೀಲ್ಡ್‌ನಲ್ಲಿ ಪ್ರತಿನಿಧಿಸಬೇಕು:

JavaScript

1[
2  /* ... original 5 items from the input array ... */
3  {
4    "type": "reasoning",
5    "summary": [
6      "type": "summary_text",
7      "text": "**Adding an architecture diagram for README.md**\n\nI need to..."
8    ],
9    "encrypted_content": "gAAAAABpaDWNMxMeLw..."
10  },
11  {
12    "type": "function_call",
13    "name": "shell",
14    "arguments": "{\"command\":\"cat README.md\",\"workdir\":\"/Users/mbolin/code/codex5\"}",
15    "call_id": "call_8675309..."
16  },
17  {
18    "type": "function_call_output",
19    "call_id": "call_8675309...",
20    "output": "<p align=\"center\"><code>npm i -g @openai/codex</code>..."
21  }
22]

ನಂತರದ ಕ್ವೆರಿಯ ಭಾಗವಾಗಿ ಮಾಡೆಲ್ ಅನ್ನು ಮಾದರಿಯಾಗಿಸಲು ಬಳಸುವ ಫಲಿತಾಂಶದ ಪ್ರಾಂಪ್ಟ್ ಹೀಗಿರುತ್ತದೆ:

ಟೂಲ್ ಕರೆ ನಂತರದ AI ಏಜೆಂಟ್ ಅನ್ನು ತೋರಿಸುವ “Snapshot 2” ಎಂದು ಲೇಬಲ್ ಮಾಡಲಾದ ರೇಖಾಚಿತ್ರ. ಮಾಡೆಲ್ ಒಂದು ಸಾಧನದ ಪರಿವೀಕ್ಷಣೆಯನ್ನು ಸ್ವೀಕರಿಸಿ ಹೊಸ ಚಿಂತನೆ ಮತ್ತು ಕ್ರಿಯೆಯನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ. ಬಾಣಗಳು ಇನ್‌ಪುಟ್‌ಗಳು, ಪರಿವೀಕ್ಷಣೆಗಳು, ಮತ್ತು ಔಟ್‌ಪುಟ್‌ಗಳನ್ನು ಸಂಪರ್ಕಿಸುತ್ತವೆ, ಏಜೆಂಟ್ ತನ್ನ ರೀಜನಿಂಗ್ ಲೂಪ್ ಅನ್ನು ಹೇಗೆ ಪುನರಾವರ್ತಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಚಿತ್ರಿಸುತ್ತವೆ.

ವಿಶೇಷವಾಗಿ, ಹಳೆಯ ಪ್ರಾಂಪ್ಟ್ ಹೊಸ ಪ್ರಾಂಪ್ಟ್‌ನ ನಿಖರ ಪೂರ್ವಪ್ರತ್ಯಯ ಎಂಬುದನ್ನು ಗಮನಿಸಿ. ಇದು ಉದ್ದೇಶಿತವಾಗಿದೆ, ಏಕೆಂದರೆ ಇದು ನಂತರದ ವಿನಂತಿಗಳನ್ನು ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಇದು ನಮಗೆ ಪ್ರಾಂಪ್ಟ್ ಕ್ಯಾಶಿಂಗ್ ಅನ್ನು ಬಳಸಲು ಅನುಮತಿಸುತ್ತದೆ (ಕಾರ್ಯಕ್ಷಮತೆಯ ಕುರಿತು ಮುಂದಿನ ವಿಭಾಗದಲ್ಲಿ ನಾವು ಇದನ್ನು ಚರ್ಚಿಸುತ್ತೇವೆ).

ನಮ್ಮ ಏಜೆಂಟ್ ಲೂಪ್‌ನ ಮೊದಲ ಡಯಾಗ್ರಾಮ್ ಅನ್ನು ಹಿಂದಿರುಗಿ ನೋಡಿದಾಗ, ನಿರ್ಣಯ ಮತ್ತು ಸಾಧನ ಕರೆ ಮಾಡುವ ನಡುವಿನ ಅನೇಕ ಪುನರಾವೃತ್ತಿಗಳು ಇರಬಹುದು ಎಂದು ನಾವು ಗಮನಿಸುತ್ತೇವೆ. ಪ್ರಾಂಪ್ಟ್ ಕೊನೆಗೂ ನಾವು ಅಸಿಸ್ಟಂಟ್ ಸಂದೇಶವನ್ನು ಸ್ವೀಕರಿಸುವವರೆಗೆ ಬೆಳೆಯುತ್ತಿರಬಹುದು, ಇದು ಟರ್ನ್‌ನ ಅಂತ್ಯವನ್ನು ಸೂಚಿಸುತ್ತದೆ:

ಸರಳ ಪಠ್ಯ

1data: {"type":"response.output_text.done","text": "I added a diagram to explain...", ...}
2data: {"type":"response.completed","response":{...}}

Codex CLI ನಲ್ಲಿ, ನಾವು ಸಹಾಯಕನ ಸಂದೇಶವನ್ನು ಬಳಕೆದಾರರಿಗೆ ಪ್ರದರ್ಶಿಸುತ್ತೇವೆ ಮತ್ತು ಸಂಭಾಷಣೆಯನ್ನು ಮುಂದುವರಿಸಲು ಇದು ಅವರ 'ತುರ್ತು' ಎಂದು ಬಳಕೆದಾರರಿಗೆ ಸೂಚಿಸಲು ಕಂಪೋಸರ್ ಅನ್ನು ಗಮನಿಸುತ್ತೇವೆ. ಬಳಕೆದಾರರು ಪ್ರತಿಕ್ರಿಯಿಸಿದರೆ, Responses API ವಿನಂತಿಯಲ್ಲಿನ ಇನ್‌ಪುಟ್ ಗೆ ಹಿಂದಿನ ತಿರುವಿನ ಸಹಾಯಕ ಸಂದೇಶ ಮತ್ತು ಬಳಕೆದಾರರ ಹೊಸ ಸಂದೇಶವನ್ನು ಸೇರಿಸಿ ಹೊಸ ತಿರುವನ್ನು ಪ್ರಾರಂಭಿಸಬೇಕು:

JavaScript

1[
2  /* ... all items from the last Responses API request ... */
3  {
4    "type": "message",
5    "role": "assistant",
6    "content": [
7      {
8        "type": "output_text",
9        "text": "I added a diagram to explain the client/server architecture."
10      }
11    ]
12  },
13  {
14    "type": "message",
15    "role": "user",
16    "content": [
17      {
18        "type": "input_text",
19        "text": "That's not bad, but the diagram is missing the bike shed."
20      }
21    ]
22  }
23]

ಮತ್ತೊಮ್ಮೆ, ನಾವು ಸಂಭಾಷಣೆಯನ್ನು ಮುಂದುವರಿಸುತ್ತಿರುವುದರಿಂದ, ನಾವು Responses API ಗೆ ಕಳುಹಿಸುವ input ನ ಉದ್ದವು ನಿರಂತರವಾಗಿ ಹೆಚ್ಚುತ್ತಿದೆ:

“Snapshot 3” ಎಂದು ಲೇಬಲ್ ಮಾಡಲಾದ ಚಿತ್ರವು AI ಏಜೆಂಟ್ ಲೂಪ್‌ನ ಅಂತಿಮ ಹಂತವನ್ನು ತೋರಿಸುತ್ತದೆ. ಟೂಲ್ ಫಲಿತಾಂಶಗಳನ್ನು ಸ್ವೀಕರಿಸಿದ ನಂತರ, ಮಾಡೆಲ್ ಒಂದು ಸಮಾಪನ ಚಿಂತನೆ ಮತ್ತು ಬಳಕೆದಾರರಿಗೆ ಹಿಂತಿರುಗುವ ಅಂತಿಮ ಉತ್ತರವನ್ನು ರಚಿಸುತ್ತದೆ. ಬಾಣಗಳು ಉಪಕರಣದ ಔಟ್‌ಪುಟ್‌ನಿಂದ ಪೂರ್ಣಗೊಂಡ ಪ್ರತಿಕ್ರಿಯೆಯ ಪರಿವರ್ತನೆಯನ್ನು ಚಿತ್ರಿಸುತ್ತವೆ.

ಕಾರ್ಯಕ್ಷಮತೆಯ ಮೇಲೆ ಸದಾ ವೃದ್ಧಿಯಾಗುತ್ತಿರುವ ಈ ಪ್ರಾಂಪ್ಟ್ ಏನನ್ನು ಸೂಚಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸೋಣ.

ಕಾರ್ಯಕ್ಷಮತೆಯ ಪರಿಗಣನೆಗಳು

ನೀವು ನಿಮ್ಮನ್ನೇ ಕೇಳಿಕೊಳ್ಳಬಹುದು, “ನಿಲ್ಲಿ, ಸಂಭಾಷಣೆಯ ಅವಧಿಯಲ್ಲಿ Responses API ಗೆ ಕಳುಹಿಸಲಾದ JSON ಪ್ರಮಾಣದ ದೃಷ್ಟಿಯಿಂದ ಏಜೆಂಟ್ ಲೂಪ್ ಕ್ವಾಡ್ರಾಟಿಕ್ ಅಲ್ಲವೇ?” ಮತ್ತು ನಿಮ್ಮ ಪ್ರಶ್ನೆ ಸರಿಯಾಗಿರಬಹುದು. Responses API ಒಂದು ಐಚ್ಛಿಕ previous_response_id⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) ಪ್ಯಾರಾಮೀಟರ್ ಅನ್ನು ಈ ಸಮಸ್ಯೆಯನ್ನು ತಗ್ಗಿಸಲು ಬೆಂಬಲಿಸುತ್ತದಾದರೂ, Codex ಇಂದು ಅದನ್ನು ಬಳಸುವುದಿಲ್ಲ, ಮುಖ್ಯವಾಗಿ ವಿನಂತಿಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಸ್ಟೇಟ್‌ಲೆಸ್ ಆಗಿ ಇರಿಸಲು ಮತ್ತು ಜೀರೋ ಡೇಟಾ ರಿಟೆನ್ಷನ್ (ZDR) ಸಂರಚನೆಗಳನ್ನು ಬೆಂಬಲಿಸಲು.

previous_response_id ಅನ್ನು ತಪ್ಪಿಸುವುದು Responses API ಒದಗಿಸುವವರಿಗೆ ವಿಷಯಗಳನ್ನು ಸರಳಗೊಳಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಇದು ಪ್ರತಿಯೊಂದು ವಿನಂತಿಯೂ ಸ್ಟೇಟ್‌ಲೆಸ್ ಆಗಿರುವುದನ್ನು ಖಚಿತಪಡಿಸುತ್ತದೆ. ಇದು ಜೀರೋ ಡೇಟಾ ರಿಟೆನ್ಷನ್ (ZDR)⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಿಕೊಂಡಿರುವ ಗ್ರಾಹಕರಿಗೆ ಬೆಂಬಲವನ್ನು ಸರಳಗೊಳಿಸುತ್ತದೆ, ಏಕೆಂದರೆ previous_response_id ಅನ್ನು ಬೆಂಬಲಿಸಲು ಅಗತ್ಯವಿರುವ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುವುದು ZDR ಗೆ ವಿರುದ್ಧವಾಗುತ್ತದೆ. ZDR ಗ್ರಾಹಕರು ಹಿಂದಿನ ತಿರುವುಗಳಿಂದ ಸ್ವಂತ ರೀಜನಿಂಗ್ ಸಂದೇಶಗಳಿಂದ ಪ್ರಯೋಜನ ಪಡೆಯುವ ಸಾಮರ್ಥ್ಯವನ್ನು ತ್ಯಜಿಸುವ ಅಗತ್ಯವಿಲ್ಲ ಎಂಬುದನ್ನು ಗಮನಿಸಿ, ಏಕೆಂದರೆ ಸಂಬಂಧಿತ encrypted_content ಅನ್ನು ಸರ್ವರ್‌ನಲ್ಲಿ ಡೀಕ್ರಿಪ್ಟ್ ಮಾಡಬಹುದು. (OpenAI ZDR ಗ್ರಾಹಕರ ಡಿಕ್ರಿಪ್ಷನ್ ಕೀಯನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ, ಆದರೆ ಅವರ ಡೇಟಾವನ್ನು ಉಳಿಸಿಕೊಳ್ಳುವುದಿಲ್ಲ.) ZDR ಅನ್ನು ಬೆಂಬಲಿಸಲು Codex ಗೆ ಸಂಬಂಧಿಸಿದ ಬದಲಾವಣೆಗಳಿಗಾಗಿ PRs #642⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) ಮತ್ತು #1641⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) ನೋಡಿ.

ಸಾಮಾನ್ಯವಾಗಿ, ಮಾಡೆಲ್‌ನ ಸ್ಯಾಂಪ್ಲಿಂಗ್ ವೆಚ್ಚವು ನೆಟ್‌ವರ್ಕ್ ಟ್ರಾಫಿಕ್ ವೆಚ್ಚವನ್ನು ಮೀರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಸ್ಯಾಂಪ್ಲಿಂಗ್ ನಮ್ಮ ದಕ್ಷತಾ ಪ್ರಯತ್ನಗಳ ಪ್ರಮುಖ ಗುರಿಯಾಗುತ್ತದೆ. ಇದಕ್ಕಾಗಿಯೇ ಪ್ರಾಂಪ್ಟ್ ಕ್ಯಾಶಿಂಗ್ ಬಹಳ ಮುಖ್ಯವಾಗಿದೆ, ಏಕೆಂದರೆ ಇದು ಹಿಂದಿನ ಇನ್ಫರೆನ್ಸ್ ಕಾಲ್‌ನಿಂದ ಗಣನೆಗಳನ್ನು ಮರುಬಳಕೆ ಮಾಡಲು ನಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ನಮಗೆ ಕ್ಯಾಶ್ ಹಿಟ್‌ಗಳು ಬಂದಾಗ, ಮಾಡೆಲ್ ಅನ್ನು ಸ್ಯಾಂಪಲ್ ಮಾಡುವುದು ಚತುರ್ಭುಜೀಯಕ್ಕಿಂತ ರೇಖೀಯವಾಗಿರುತ್ತದೆ. ನಮ್ಮ ಪ್ರಾಂಪ್ಟ್ ಕ್ಯಾಶಿಂಗ್ ⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ)ಡಾಕ್ಯುಮೆಂಟೇಶನ್ ಇದನ್ನು ಹೆಚ್ಚಿನ ವಿವರಗಳಲ್ಲಿ ವಿವರಿಸುತ್ತದೆ:

ಕ್ಯಾಶ್ ಹಿಟ್‌ಗಳು ಪ್ರಾಂಪ್ಟ್‌ನೊಳಗೆ ನಿಖರವಾದ ಪ್ರಿಫಿಕ್ಸ್ ಹೊಂದಾಣಿಕೆಗಳಿಗೆ ಮಾತ್ರ ಸಾಧ್ಯವಾಗುತ್ತವೆ. ಕ್ಯಾಶಿಂಗ್ ಪ್ರಯೋಜನಗಳನ್ನು ಪಡೆಯಲು, ಸೂಚನೆಗಳು ಮತ್ತು ಉದಾಹರಣೆಗಳಂತಹ ಸ್ಥಿರ ವಿಷಯವನ್ನು ನಿಮ್ಮ ಪ್ರಾಂಪ್ಟ್‌ನ ಆರಂಭದಲ್ಲಿ ಇರಿಸಿ, ಮತ್ತು ಬಳಕೆದಾರ-ನಿರ್ದಿಷ್ಟ ಮಾಹಿತಿಯಂತಹ ಬದಲಾಗುವ ವಿಷಯವನ್ನು ಕೊನೆಯಲ್ಲಿ ಇರಿಸಿ. ಇದು ಚಿತ್ರಗಳು ಮತ್ತು ಉಪಕರಣಗಳಿಗೂ ಅನ್ವಯಿಸುತ್ತದೆ, ಅವು ವಿನಂತಿಗಳ ನಡುವೆ ಒಂದೇ ರೀತಿಯವಾಗಿರಬೇಕು.

ಇದನ್ನು ಮನಸ್ಸಿನಲ್ಲಿ ಇಟ್ಟುಕೊಂಡು, Codex ನಲ್ಲಿ “cache miss” ಗೆ ಕಾರಣವಾಗಬಹುದಾದ ಕಾರ್ಯಾಚರಣೆಗಳ ಬಗ್ಗೆ ಪರಿಗಣಿಸೋಣ:

ಸಂಭಾಷಣೆಯ ಮಧ್ಯದಲ್ಲಿ ಮಾಡೆಲ್‌ಗೆ ಲಭ್ಯವಿರುವ ಟೂಲ್‌ಗಳು ಅನ್ನು ಬದಲಾಯಿಸುವುದು.
Responses API ವಿನಂತಿಯ ಗುರಿಯಾಗಿರುವ ಮಾಡೆಲ್ ಅನ್ನು ಬದಲಿಸುವುದು (ಪ್ರಯೋಗದಲ್ಲಿ, ಇದು ಮೂಲ ಪ್ರಾಂಪ್ಟ್‌ನ ಮೂರನೇ ಅಂಶವನ್ನು ಬದಲಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಅದರಲ್ಲಿ ಮಾಡೆಲ್-ನಿರ್ದಿಷ್ಟ ಸೂಚನೆಗಳು ಒಳಗೊಂಡಿರುತ್ತವೆ).
ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ ಸಂರಚನೆ, ಅನುಮೋದನೆ ಮೋಡ್, ಅಥವಾ ಪ್ರಸ್ತುತ ಕಾರ್ಯನಿರ್ವಹಣಾ ಡೈರೆಕ್ಟರಿಯನ್ನು ಬದಲಾಯಿಸುವುದು.

Codex CLI ನಲ್ಲಿ ಪ್ರಾಂಪ್ಟ್ ಕ್ಯಾಶಿಂಗ್ ಅನ್ನು ಹಾನಿಗೊಳಿಸಬಹುದಾದ ಹೊಸ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಪರಿಚಯಿಸುವಾಗ Codex ತಂಡವು ಎಚ್ಚರಿಕೆಯಿಂದ ಇರಬೇಕು. ಉದಾಹರಣೆಗೆ, MCP ಪರಿಕರಗಳಿಗೆ ನಮ್ಮ ಆರಂಭಿಕ ಬೆಂಬಲವು ಪರಿಕರಗಳನ್ನು ಸತತ ಕ್ರಮದಲ್ಲಿ ಎಣಿಸಲು ವಿಫಲವಾದ ದೋಷವನ್ನು⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) ಪರಿಚಯಿಸಿತು, ಇದರಿಂದ ಕ್ಯಾಶ್ ಮಿಸ್‌ಗಳು ಉಂಟಾದವು. MCP ಟೂಲ್‌ಗಳು ವಿಶೇಷವಾಗಿ ಕಷ್ಟಕರವಾಗಿರಬಹುದು ಎಂಬುದನ್ನು ಗಮನಿಸಿ, ಏಕೆಂದರೆ MCP ಸರ್ವರ್‌ಗಳು notifications/tools/list_changed⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) ಅಧಿಸೂಚನೆಯ ಮೂಲಕ ತಾವು ಒದಗಿಸುವ ಟೂಲ್‌ಗಳ ಪಟ್ಟಿಯನ್ನು ತಕ್ಷಣದಲ್ಲೇ ಬದಲಾಯಿಸಬಹುದು. ದೀರ್ಘ ಸಂಭಾಷಣೆಯ ಮಧ್ಯದಲ್ಲಿ ಈ ಸೂಚನೆಯನ್ನು ಗೌರವಿಸುವುದು ದುಬಾರಿ ಕ್ಯಾಶ್ ಮಿಸ್‌ಗೆ ಕಾರಣವಾಗಬಹುದು.

ಸಾಧ್ಯವಾದಾಗ, ಸಂಭಾಷಣೆಯ ಮಧ್ಯದಲ್ಲಿ ಸಂಭವಿಸುವ ಸಂರಚನೆ ಬದಲಾವಣೆಗಳನ್ನು ನಾವು ಹಿಂದಿನ ಸಂದೇಶವನ್ನು ತಿದ್ದುಪಡಿ ಮಾಡುವ ಬದಲು ಬದಲಾವಣೆಯನ್ನು ಪ್ರತಿಬಿಂಬಿಸಲು ಇನ್‌ಪುಟ್ ಗೆ ಹೊಸ ಸಂದೇಶವನ್ನು ಸೇರಿಸುವ ಮೂಲಕ ನಿರ್ವಹಿಸುತ್ತೇವೆ:

ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ ಸಂರಚನೆ ಅಥವಾ ಅನುಮೋದನೆ ಮೋಡ್ ಬದಲಾಗಿದರೆ, ನಾವು ಹೊಸ⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) role=developer ಸಂದೇಶವನ್ನು ಮೂಲ <permissions instructions> ಐಟಂನಂತೆಯೇ ಅದೇ ಫಾರ್ಮ್ಯಾಟ್‌ನೊಂದಿಗೆ ಸೇರಿಸುತ್ತೇವೆ.
ಪ್ರಸ್ತುತ ಕಾರ್ಯನಿರ್ವಹಣಾ ಡೈರೆಕ್ಟರಿ ಬದಲಾಗಿದರೆ, ನಾವು ಸೇರಿಸುತ್ತೇವೆ⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) ಮೂಲ ನಂತೆಯೇ ಅದೇ ಫಾರ್ಮ್ಯಾಟ್‌ನೊಂದಿಗೆ ಹೊಸ role=user <environment_context> ಸಂದೇಶವನ್ನು ಸೇರಿಸುತ್ತೇವೆ.

ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಹೆಚ್ಚಿಸಲು ಕ್ಯಾಶ್ ಹಿಟ್‌ಗಳನ್ನು ಖಚಿತಪಡಿಸಲು ನಾವು ಬಹಳಷ್ಟು ಪ್ರಯತ್ನಿಸುತ್ತೇವೆ. ನಾವು ನಿರ್ವಹಿಸಬೇಕಾದ ಇನ್ನೊಂದು ಪ್ರಮುಖ ಸಂಪನ್ಮೂಲ ಇದೆ: ಸಂದರ್ಭ ವಿಂಡೋ.

ಸಂದರ್ಭ ವಿಂಡೋ ಮುಗಿದುಹೋಗುವುದನ್ನು ತಪ್ಪಿಸಲು ನಮ್ಮ ಸಾಮಾನ್ಯ ತಂತ್ರವೆಂದರೆ ಟೋಕನ್‌ಗಳ ಸಂಖ್ಯೆ ಕೆಲವು ಮಿತಿಯನ್ನು ಮೀರಿದಾಗ ಸಂಭಾಷಣೆಯನ್ನು ಸಂಕ್ಷಿಪ್ತಗೊಳಿಸುವುದು. ವಿಶೇಷವಾಗಿ, ನಾವು input ಅನ್ನು ಸಂಭಾಷಣೆಯನ್ನು ಪ್ರತಿನಿಧಿಸುವ ಹೊಸ, ಚಿಕ್ಕ ಅಂಶಗಳ ಪಟ್ಟಿಯಿಂದ ಬದಲಾಯಿಸುತ್ತೇವೆ, ಇದರಿಂದ ಏಜೆಂಟ್ ಇಲ್ಲಿಯವರೆಗೆ ಏನಾಗಿದೆ ಎಂಬುದರ ಅರಿವಿನೊಂದಿಗೆ ಮುಂದುವರಿಯಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ. ಕಾಂಪ್ಯಾಕ್ಷನ್‌ನ ಒಂದು ಆರಂಭಿಕ ಅನುಷ್ಠಾನ⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) ಬಳಕೆದಾರರು ಕೈಯಾರೆ /compact ಕಮಾಂಡ್ ಅನ್ನು ಇನ್‌ವೋಕ್ ಮಾಡಬೇಕಾಗಿತ್ತು, ಇದು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಸಂಭಾಷಣೆ ಜೊತೆಗೆ ಸಾರಾಂಶಗೊಳಿಸುವಿಕೆ⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ)ಗಾಗಿ ಕಸ್ಟಮ್ ಸೂಚನೆಗಳನ್ನು ಬಳಸಿ Responses API ಅನ್ನು ಕ್ವೆರಿ ಮಾಡುತ್ತಿತ್ತು. Codex ಫಲಿತಾಂಶವಾಗಿ ಬಂದ ಅಸಿಸ್ಟಂಟ್ ಸಂದೇಶವನ್ನು, ಸಾರಾಂಶವನ್ನು ಒಳಗೊಂಡ ಹೊಸ ಇನ್‌ಪುಟ್⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) ಆಗಿ ಮುಂದಿನ ಸಂಭಾಷಣಾ ತಿರುವುಗಳಿಗೆ ಬಳಸಿತು.

ಅಂದಿನಿಂದ, Responses API ಒಂದು ವಿಶೇಷ /responses/compact ಎಂಡ್‌ಪಾಯಿಂಟ್⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) ಅನ್ನು ಬೆಂಬಲಿಸಲು ಅಭಿವೃದ್ಧಿಯಾಗಿದೆ, ಇದು ಕಾಂಪ್ಯಾಕ್ಷನ್ ಅನ್ನು ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಮಾಡುತ್ತದೆ. ಇದು ಐಟಂಗಳ ಪಟ್ಟಿಯನ್ನು⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) ಹಿಂತಿರುಗಿಸುತ್ತದೆ, ಇದು ಹಿಂದಿನ ಇನ್‌ಪುಟ್ ಬದಲಿಗೆ ಬಳಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ ಮತ್ತು ಸಂದರ್ಭ ವಿಂಡೋವನ್ನು ಮುಕ್ತಗೊಳಿಸುತ್ತಾ ಸಂಭಾಷಣೆಯನ್ನು ಮುಂದುವರಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಈ ಪಟ್ಟಿ ಮೂಲ ಸಂಭಾಷಣೆಯ ಮಾಡೆಲ್‌ನ ಸುಪ್ತ ಅರ್ಥಗ್ರಹಿಕೆಯನ್ನು ಕಾಪಾಡುವ ಅಪಾರದರ್ಶಕ encrypted_content ಐಟಂ ಹೊಂದಿರುವ ವಿಶೇಷ type=compaction ಐಟಂ ಅನ್ನು ಒಳಗೊಂಡಿದೆ. ಈಗ, auto_compact_limit⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) ಮೀರಿದಾಗ ಸಂಭಾಷಣೆಯನ್ನು ಸಂಕ್ಷೇಪಿಸಲು Codex ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಈ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಅನ್ನು ಬಳಸುತ್ತದೆ.

ಮುಂದೆ ಬರಲಿದೆ

ನಾವು Codex ಏಜೆಂಟ್ ಲೂಪ್ ಅನ್ನು ಪರಿಚಯಿಸಿದ್ದೇವೆ ಮತ್ತು ಮಾಡೆಲ್ ಅನ್ನು ಪ್ರಶ್ನಿಸುವಾಗ Codex ತನ್ನ ಸಂದರ್ಭವನ್ನು ಹೇಗೆ ರೂಪಿಸುತ್ತದೆ ಮತ್ತು ನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ವಿವರಿಸಿದ್ದೇವೆ. ಮಾರ್ಗಮಧ್ಯದಲ್ಲಿ, ನಾವು Responses API ಮೇಲ್ಭಾಗದಲ್ಲಿ ಏಜೆಂಟ್ ಲೂಪ್ ಅನ್ನು ನಿರ್ಮಿಸುವ ಯಾರಿಗಾದರೂ ಅನ್ವಯಿಸುವ ಪ್ರಾಯೋಗಿಕ ಪರಿಗಣನೆಗಳು ಮತ್ತು ಉತ್ತಮ ಅಭ್ಯಾಸಗಳನ್ನು ಹೈಲೈಟ್ ಮಾಡಿದ್ದೇವೆ.

ಏಜೆಂಟ್ ಲೂಪ್ Codex ಗೆ ಅಡಿಪಾಯ ಒದಗಿಸಿದರೂ, ಇದು ಕೇವಲ ಆರಂಭ ಮಾತ್ರ. ಮುಂದಿನ ಪೋಸ್ಟ್‌ಗಳಲ್ಲಿ, ನಾವು CLI ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ಆಳವಾಗಿ ಪರಿಶೀಲಿಸುತ್ತೇವೆ, ಟೂಲ್ ಬಳಕೆಯನ್ನು ಹೇಗೆ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ಅನ್ವೇಷಿಸುತ್ತೇವೆ, ಮತ್ತು Codex ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸಿಂಗ್ ಮಾಡೆಲ್ ಅನ್ನು ಹೆಚ್ಚು ಸಮೀಪದಿಂದ ಪರಿಶೀಲಿಸುತ್ತೇವೆ.

ಲೇಖಕ

Michael Bolin

ಸ್ವೀಕೃತಿಗಳು

Codex CLI ಅನ್ನು ನಿರ್ಮಿಸಿದ ಸಂಪೂರ್ಣ ತಂಡಕ್ಕೆ ವಿಶೇಷ ಧನ್ಯವಾದಗಳು.

ಓದು ಮುಂದುವರಿಸಿ

ಎಲ್ಲವನ್ನೂ ನೋಡಿ

Codex ಜೊತೆಗೆ ಸ್ವಯಂ-ಸುಧಾರಿಸುವ ತೆರಿಗೆ ಏಜೆಂಟ್‌ಗಳ ನಿರ್ಮಾಣ

ಎಂಜಿನಿಯರಿಂಗ್ಮೇ 27, 2026

Windows ನಲ್ಲಿ Codex ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಲು ಸುರಕ್ಷಿತ, ಪರಿಣಾಮಕಾರಿ ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ ನಿರ್ಮಿಸುವುದು

ಎಂಜಿನಿಯರಿಂಗ್ಮೇ 13, 2026

ಗಾಬ್ಲಿನ್‌ಗಳು ಎಲ್ಲಿಂದ ಬಂದವು

ಎಂಜಿನಿಯರಿಂಗ್ಮೇ 5, 2026