ಫೆಬ್ರವರಿ 4, 2026

Codex ಹಾರ್ನೆಸ್ ಅನ್ಲಾಕ್: ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್ ಅನ್ನು ಹೇಗೆ ನಿರ್ಮಿಸಿದೆವು

ಸೆಲಿಯಾ ಚೆನ್, ತಾಂತ್ರಿಕ ಸಿಬ್ಬಂದಿಯ ಸದಸ್ಯರು

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

OpenAI ಯ ಕೋಡಿಂಗ್ ಏಜೆಂಟ್ Codex ಅನೇಕ ವಿಭಿನ್ನ ಮೇಲ್ಮೈಗಳಲ್ಲಿ ಲಭ್ಯವಿದೆ: ವೆಬ್ ಆ್ಯಪ್⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ), CLI⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ), IDE ಎಕ್ಸ್ಟೆನ್ಶನ್⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ), ಮತ್ತು ಹೊಸ Codex macOS ಆ್ಯಪ್. ಆಂತರಿಕವಾಗಿ, ಅವೆಲ್ಲವೂ ಒಂದೇ Codex ಹಾರ್ನೆಸ್‌ನಿಂದ ಶಕ್ತಿಯುತಗೊಳಿಸಲ್ಪಟ್ಟಿವೆ—the ಏಜೆಂಟ್ ಲೂಪ್ ಮತ್ತು ಲಾಜಿಕ್, ಇದು ಎಲ್ಲಾ Codex ಅನುಭವಗಳಿಗೆ ಆಧಾರವಾಗಿವೆ. ಅವರ ನಡುವಿನ ಪ್ರಮುಖ ಕೊಂಡಿ ಏನು? Codex ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ), ಗ್ರಾಹಕ-ಸ್ನೇಹಿ, ದ್ವಿದಿಶೀಯ JSON-RPC¹ API.

ಈ ಪೋಸ್ಟ್‌ನಲ್ಲಿ, ನಾವು Codex ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್ ಅನ್ನು ಪರಿಚಯಿಸುತ್ತೇವೆ; ನಿಮ್ಮ ಬಳಕೆದಾರರು ತಮ್ಮ ವರ್ಕ್‌ಫ್ಲೋಗಳನ್ನು ಸೂಪರ್‌ಚಾರ್ಜ್ ಮಾಡಲು ಸಹಾಯವಾಗುವಂತೆ Codex ನ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ನಿಮ್ಮ ಉತ್ಪನ್ನಕ್ಕೆ ತರುವ ಅತ್ಯುತ್ತಮ ಮಾರ್ಗಗಳ ಬಗ್ಗೆ ಇದುವರೆಗೆ ನಾವು ಕಲಿತದ್ದನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತೇವೆ. ನಾವು ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್ ನ ಆರ್ಕಿಟೆಕ್ಚರ್ ಮತ್ತು ಪ್ರೋಟೋಕಾಲ್ ಮತ್ತು ಅದು ವಿಭಿನ್ನ Codex ಸರ್ಫೇಸ್‌ಗಳೊಂದಿಗೆ ಹೇಗೆ ಏಕೀಕೃತಗೊಳ್ಳುತ್ತದೆ ಎಂಬುದನ್ನು, ಜೊತೆಗೆ Codex ಅನ್ನು ಹೇಗೆ ಬಳಸಿಕೊಳ್ಳಬೇಕು ಎಂಬ ಸಲಹೆಗಳನ್ನು ನೀಡುತ್ತೇವೆ—ನೀವು Codex ಅನ್ನು ಕೋಡ್ ರಿವ್ಯೂವರ್, SRE ಏಜೆಂಟ್ ಅಥವಾ ಕೋಡಿಂಗ್ ಸಹಾಯಕನಾಗಿ ಬಳಸಲು ಬಯಸಿದರೆ.

ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್‌ನ ಮೂಲ

ವಾಸ್ತುಶಿಲ್ಪಕ್ಕೆ ಮುನ್ನ, ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್ ನ ಹಿನ್ನೆಲೆಯನ್ನು ತಿಳಿದುಕೊಳ್ಳುವುದು ಸಹಾಯಕ. ಆರಂಭದಲ್ಲಿ, ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್ ಕ್ರಮೇಣ ನಮ್ಮ ಮಾನಕ ಪ್ರೋಟೋಕಾಲ್ ಆಗಿ ವಿಕಸನಗೊಂಡ ಉತ್ಪನ್ನಗಳಾದ್ಯಂತ Codex ಹಾರ್ನೆಸ್ ಅನ್ನು ಮರುಬಳಕೆ ಮಾಡಲು ಒಂದು ಪ್ರಾಯೋಗಿಕ ಮಾರ್ಗವಾಗಿತ್ತು.

Codex CLI ಅನ್ನು TUI (ಟರ್ಮಿನಲ್ ಬಳಕೆದಾರ ಇಂಟರ್ಫೇಸ್) ಆಗಿ ಪ್ರಾರಂಭಿಸಲಾಯಿತು, ಅಂದರೆ Codex ಅನ್ನು ಟರ್ಮಿನಲ್ ಮೂಲಕ ಪ್ರವೇಶಿಸಬಹುದು. ನಾವು VS Code ಎಕ್ಸ್ಟೆನ್ಷನ್ ಅನ್ನು ನಿರ್ಮಿಸಿದಾಗ (Codex ಏಜೆಂಟ್‌ಗಳೊಂದಿಗೆ ಸಂವಹನ ಮಾಡಲು ಹೆಚ್ಚು IDE-ಸ್ನೇಹಿ ವಿಧಾನ), IDE UI ಯಿಂದ ಅದೇ ಏಜೆಂಟ್ ಲೂಪ್ ಅನ್ನು ಮರು-ಅಮಲಿಗೊಳಿಸದೆ ಚಾಲನೆ ಮಾಡಲು ಅದೇ ಹಾರ್ನೆಸ್ ಅನ್ನು ಬಳಸುವ ವಿಧಾನ ನಮಗೆ ಬೇಕಾಯಿತು. ಅದರರ್ಥ ವಿನಂತಿ/ಪ್ರತಿಕ್ರಿಯೆ ಅನ್ನು ಮೀರಿ ಶ್ರೀಮಂತ ಸಂವಹನ ಮಾದರಿಗಳನ್ನು ಬೆಂಬಲಿಸುವುದು, ಉದಾಹರಣೆಗೆ ವರ್ಕ್‌ಸ್ಪೇಸ್ ಅನ್ನು ಅನ್ವೇಷಿಸುವುದು, ಏಜೆಂಟ್ ತರ್ಕಿಸುವಾಗ ಪ್ರಗತಿಯನ್ನು ಸ್ಟ್ರೀಮ್ ಮಾಡುವುದು ಮತ್ತು ವ್ಯತ್ಯಾಸಗಳನ್ನು ಹೊರಸೂಸುವುದು. ನಾವು ಮೊದಲು Codex ಅನ್ನು MCP ಸರ್ವರ್ ಆಗಿ⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) ಬಹಿರಂಗಪಡಿಸಲು ಪ್ರಯತ್ನಿಸಿದ್ದೇವೆ, ಆದರೆ VS Code ಗೆ ಅರ್ಥವಾಗುವ ರೀತಿಯಲ್ಲಿ MCP ಅರ್ಥವ್ಯವಸ್ಥೆಯನ್ನು ನಿರ್ವಹಿಸುವುದು ಕಷ್ಟಕರವೆಂದು ತೋರಿತು. ಬದಲಾಗಿ, ನಾವು TUI ಲೂಪ್ ಅನ್ನು ಪ್ರತಿಬಿಂಬಿಸುವ JSON-RPC ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಪರಿಚಯಿಸಿದ್ದೇವೆ, ಇದು ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್‌ನ ಅನೌಪಚಾರಿಕ ಮೊದಲ ಆವೃತ್ತಿ⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) ಆಯಿತು. ಆ ಸಮಯದಲ್ಲಿ, ಇತರ ಗ್ರಾಹಕರು ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್ ಮೇಲೆ ಅವಲಂಬಿಸಿರುತ್ತಾರೆ ಎಂದು ನಾವು ನಿರೀಕ್ಷಿಸಿರಲಿಲ್ಲ, ಆದ್ದರಿಂದ ಅದನ್ನು ಸ್ಥಿರ API ಆಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿರಲಿಲ್ಲ.

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

ಮುಂದೆ, ವಿಭಿನ್ನ ಗ್ರಾಹಕರು ಒಂದೇ ಹಾರ್ನೆಸ್ ಅನ್ನು ಬಳಸಲು ಸಾಧ್ಯವಾಗುವಂತೆ ನಾವು ಆರ್ಕಿಟೆಕ್ಚರ್ ಮತ್ತು ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಹೇಗೆ ವಿನ್ಯಾಸಗೊಳಿಸಿದ್ದೇವೆ ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತೇವೆ.

Codex ಹಾರ್ನೆಸ್‌ನ ಒಳಭಾಗದಲ್ಲಿ

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

1. ಥ್ರೆಡ್ ಜೀವನಚಕ್ರ ಮತ್ತು ಸ್ಥಿರತೆ. ಥ್ರೆಡ್ ಎಂದರೆ ಬಳಕೆದಾರ ಮತ್ತು ಏಜೆಂಟ್ ನಡುವಿನ Codex ಸಂಭಾಷಣೆ. Codex ಥ್ರೆಡ್‌ಗಳನ್ನು ರಚಿಸುತ್ತದೆ, ಪುನರಾರಂಭಿಸುತ್ತದೆ, ಫೋರ್ಕ್ ಮಾಡುತ್ತದೆ, ಆರ್ಕೈವ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಈವೆಂಟ್ ಇತಿಹಾಸವನ್ನು ಸ್ಥಿರವಾಗಿ ಉಳಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಕ್ಲೈಂಟ್‌ಗಳು ಮರುಸಂಪರ್ಕಿಸಿ ಸಮ್ಮತವಾದ ಟೈಮ್‌ಲೈನ್ ಅನ್ನು ರೆಂಡರ್ ಮಾಡಬಹುದು.

2. ಕಾನ್ಫಿಗ್ ಮತ್ತು ಆಥ್. Codex ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಲೋಡ್ ಮಾಡುತ್ತದೆ, ಡೀಫಾಲ್ಟ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಕ್ರೆಡೆನ್ಶಿಯಲ್ ಸ್ಥಿತಿಯನ್ನು ಒಳಗೊಂಡಂತೆ “ChatGPT ಯೊಂದಿಗೆ ಸೈನ್ ಇನ್ ಮಾಡಿ” ನಂತಹ ದೃಢೀಕರಣ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ.

3. ಸಾಧನ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆ ಮತ್ತು ವಿಸ್ತರಣೆಗಳು. Codex ಶೆಲ್/ಫೈಲ್ ಉಪಕರಣಗಳನ್ನು ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್‌ನಲ್ಲಿ ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ ಮತ್ತು MCP ಸರ್ವರ್‌ಗಳು ಮತ್ತು ಕೌಶಲ್ಯಗಳಂತಹ ಏಕೀಕರಣಗಳನ್ನು ಸಂಪರ್ಕಿಸುತ್ತದೆ, ಇದರಿಂದ ಅವುಗಳು ಸತತ ನೀತಿ ಮಾಡೆಲ್ ಅಡಿಯಲ್ಲಿ ಏಜೆಂಟ್ ಲೂಪ್‌ನಲ್ಲಿ ಭಾಗವಹಿಸಬಹುದು.

ನಾವು ಇಲ್ಲಿ ಉಲ್ಲೇಖಿಸಿದ ಎಲ್ಲಾ ಏಜೆಂಟ್ ಲಾಜಿಕ್, ಮೂಲ ಏಜೆಂಟ್ ಲೂಪ್ ಸೇರಿದಂತೆ, “Codex ಕೋರ್⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ)” ಎಂದು ಕರೆಯಲಾಗುವ Codex CLI ಕೋಡ್‌ಬೇಸ್‌ನ ಒಂದು ಭಾಗದಲ್ಲಿ ಇದೆ. Codex core ಒಂದು ಲೈಬ್ರರಿ ಆಗಿದ್ದು, ಎಲ್ಲ ಏಜೆಂಟ್ ಕೋಡ್ ಅಲ್ಲಿ ಇರುತ್ತದೆ ಮತ್ತು ಇದು ಏಜೆಂಟ್ ಲೂಪ್ ಅನ್ನು ಚಲಾಯಿಸಲು ಮತ್ತು ಒಂದು Codex ಥ್ರೆಡ್ (ಸಂಭಾಷಣೆ) ನ ಸ್ಥಿರತೆಯನ್ನು ನಿರ್ವಹಿಸಲು ರನ್‌ಟೈಮ್ ಆಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.

ಉಪಯುಕ್ತವಾಗಿರಲು, Codex ಹಾರ್ನೆಸ್ ಗ್ರಾಹಕರಿಗೆ ಸುಲಭವಾಗಿ ಲಭ್ಯವಾಗಿರಬೇಕು. ಅಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್ ತನ್ನ ಪಾತ್ರವನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ.

“ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್ ಪ್ರಕ್ರಿಯೆ ಹರಿವು” ಎಂಬ ಶೀರ್ಷಿಕೆಯ ರೇಖಾಚಿತ್ರ. ಒಂದು ಕ್ಲೈಂಟ್ JSON-RPC ಸಂದೇಶಗಳನ್ನು stdio ರೀಡರ್‌ಗೆ ಕಳುಹಿಸುತ್ತದೆ, ಅದು Codex ಸಂದೇಶ ಪ್ರೊಸೆಸರ್‌ಗೆ ವಿನಂತಿಗಳನ್ನು ಡಿಸ್ಪ್ಯಾಚ್ ಮಾಡುತ್ತದೆ. ಪ್ರೊಸೆಸರ್ ಲುಕ್‌ಅಪ್ ಥ್ರೆಡ್‌ಗಳು, ಥ್ರೆಡ್ ಹ್ಯಾಂಡಲ್‌ಗಳು, ಸಲ್ಲಿಸಿದ ವಿನಂತಿಗಳು ಮತ್ತು ಈವೆಂಟ್‌ಗಳು/ಅಪ್‌ಡೇಟ್‌ಗಳ ಮೂಲಕ ಥ್ರೆಡ್ ಮ್ಯಾನೇಜರ್ ಮತ್ತು ಕೋರ್ ಥ್ರೆಡ್‌ನೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುತ್ತದೆ, ನಂತರ ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಕ್ಲೈಂಟ್‌ಗೆ ಹಿಂದಿರುಗಿಸುತ್ತದೆ.

ಆಪ್ ಸರ್ವರ್ ಗ್ರಾಹಕ ಮತ್ತು ಸರ್ವರ್ ನಡುವಿನ JSON-RPC ಪ್ರೋಟೋಕಾಲ್ ಮತ್ತು Codex ಕೋರ್ ಥ್ರೆಡ್‌ಗಳನ್ನು ಹೋಸ್ಟ್ ಮಾಡುವ ದೀರ್ಘಕಾಲದ ಪ್ರಕ್ರಿಯೆಯಾಗಿದೆ. ಮೇಲಿನ ರೇಖಾಚಿತ್ರದಿಂದ ನಾವು ನೋಡಬಹುದಾದಂತೆ, ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್ ಪ್ರಕ್ರಿಯೆಗೆ ನಾಲ್ಕು ಮುಖ್ಯ ಘಟಕಗಳಿವೆ: stdio ರೀಡರ್, Codex ಸಂದೇಶ ಪ್ರೊಸೆಸರ್, ಥ್ರೆಡ್ ಮ್ಯಾನೇಜರ್ ಮತ್ತು ಕೋರ್ ಥ್ರೆಡ್‌ಗಳು. ಥ್ರೆಡ್ ಮ್ಯಾನೇಜರ್ ಪ್ರತಿ ಥ್ರೆಡ್‌ಗಾಗಿ ಒಂದು ಕೋರ್ ಸೆಷನ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ ಮತ್ತು ನಂತರ Codex ಸಂದೇಶ ಪ್ರೊಸೆಸರ್ ಪ್ರತಿ ಕೋರ್ ಸೆಷನ್ ಜೊತೆ ನೇರವಾಗಿ ಸಂವಹನ ಮಾಡಿ ಗ್ರಾಹಕ ವಿನಂತಿಗಳನ್ನು ಸಲ್ಲಿಸಲು ಮತ್ತು ನವೀಕರಣಗಳನ್ನು ಸ್ವೀಕರಿಸಲು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.

ಒಂದು ಗ್ರಾಹಕ ವಿನಂತಿ ಅನೇಕ ಈವೆಂಟ್ ಅಪ್‌ಡೇಟ್‌ಗಳಿಗೆ ಕಾರಣವಾಗಬಹುದು ಮತ್ತು ಈ ವಿವರವಾದ ಈವೆಂಟ್‌ಗಳು ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್ ಮೇಲ್ಭಾಗದಲ್ಲಿ ಸಮೃದ್ಧ UI ಅನ್ನು ನಿರ್ಮಿಸಲು ನಮಗೆ ಅವಕಾಶ ಮಾಡಿಕೊಡುತ್ತವೆ. ಇದಲ್ಲದೆ, stdio ರೀಡರ್ ಮತ್ತು Codex ಸಂದೇಶ ಪ್ರಾಸೆಸರ್ ಕ್ಲೈಂಟ್ ಮತ್ತು Codex ಕೋರ್ ಥ್ರೆಡ್ ನಡುವಿನ ಅನುವಾದ ಪದರವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. ಅವು ಕ್ಲೈಂಟ್ JSON-RPC ವಿನಂತಿಗಳನ್ನು Codex ಕೋರ್ ಕಾರ್ಯಾಚರಣೆಗಳಾಗಿ ಅನುವಾದಿಸುತ್ತವೆ, Codex ಕೋರ್ ನ ಆಂತರಿಕ ಈವೆಂಟ್ ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಕೇಳುತ್ತಾರೆ ಮತ್ತು ನಂತರ ಆ ಕಡಿಮೆ-ಮಟ್ಟದ ಈವೆಂಟ್‌ಗಳನ್ನು ಸಣ್ಣ ಸಮೂಹದ ಸ್ಥಿರ, UI-ಸಿದ್ಧ JSON-RPC ಅಧಿಸೂಚನೆಗಳಾಗಿ ಪರಿವರ್ತಿಸುತ್ತವೆ.

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

ಸಂಭಾಷಣೆ ಮೂಲಭೂತ ಅಂಶಗಳು

ಮುಂದೆ, ನಾವು ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್ ಪ್ರೋಟೋಕಾಲ್‌ನ ಬಿಲ್ಡಿಂಗ್ ಬ್ಲಾಕ್‌ಗಳಾದ ಸಂಭಾಷಣೆಯ ಪ್ರಿಮಿಟಿವ್‌ಗಳನ್ನು ಬ್ರೇಕ್ ಡೌನ್ ಮಾಡುತ್ತೇವೆ. ಏಜೆಂಟ್ ಲೂಪ್‌ಗಾಗಿ API ವಿನ್ಯಾಸಗೊಳಿಸುವುದು ಕಷ್ಟಕರವಾಗಿದೆ, ಏಕೆಂದರೆ ಬಳಕೆದಾರ/ಏಜೆಂಟ್ ಸಂವಹನವು ಸರಳ ವಿನಂತಿ/ಪ್ರತಿಕ್ರಿಯೆಯಲ್ಲ. ಒಂದು ಬಳಕೆದಾರರ ವಿನಂತಿ ನಿಷ್ಠೆಯಿಂದ ಪ್ರತಿನಿಧಿಸಬೇಕಾದ ಕ್ರಿಯೆಗಳ ಸಂರಚಿತ ಕ್ರಮವಾಗಿ ವಿಸ್ತರಿಸಬಹುದು: ಬಳಕೆದಾರರ ಇನ್‌ಪುಟ್, ಏಜೆಂಟ್‌ನ ಕ್ರಮೇಣ ಪ್ರಗತಿ ಮತ್ತು ಮಾರ್ಗಮಧ್ಯೆ ಉತ್ಪಾದಿಸಲಾದ ಆಭ್ಯಾಸಗಳು (ಉದಾ., ವ್ಯತ್ಯಾಸಗಳು). ಆ ಸಂವಹನ ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಸುಲಭವಾಗಿ ಏಕೀಕರಿಸಲು ಮತ್ತು UI ಗಳಾದ್ಯಂತ ಸ್ಥಿತಿಸ್ಥಾಪಕವಾಗಿರಿಸಲು, ನಾವು ಸ್ಪಷ್ಟ ಗಡಿಗಳು ಮತ್ತು ಜೀವಿತಚಕ್ರಗಳನ್ನು ಹೊಂದಿರುವ ಮೂರು ಮೂಲ ಪ್ರಿಮಿಟಿವ್‌ಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡಿದ್ದೇವೆ:

1. ಐಟಂ: Codex ನಲ್ಲಿ ಐಟಂ ಇನ್‌ಪುಟ್/ಔಟ್‌ಪುಟ್‌ನ ಅಣು ಘಟಕವಾಗಿದೆ. ಅಂಶಗಳನ್ನು ಟೈಪ್ ಮಾಡಲಾಗಿದೆ (ಉದಾ., ಬಳಕೆದಾರರ ಸಂದೇಶ, ಏಜೆಂಟ್ ಸಂದೇಶ, ಸಾಧನ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆ, ಅನುಮೋದನೆ ವಿನಂತಿ, ವ್ಯತ್ಯಾಸ) ಮತ್ತು ಪ್ರತಿಯೊಂದಕ್ಕೂ ಸ್ಪಷ್ಟವಾದ ಜೀವನಚಕ್ರವಿದೆ:

ಐಟಂ/ಪ್ರಾರಂಭಿಸಲಾಗಿದೆ ಐಟಂ ಪ್ರಾರಂಭವಾಗುವಾಗ
ಐಚ್ಛಿಕ ಐಟಂ/*/ಡೆಲ್ಟಾ ಈವೆಂಟ್‌ಗಳನ್ನು ವಿಷಯ ಸ್ಟ್ರೀಮ್‌ಗಳಾಗಿ (ಸ್ಟ್ರೀಮಿಂಗ್ ಐಟಂ ಪ್ರಕಾರಗಳಿಗಾಗಿ)
ಐಟಂ/ಪೂರ್ಣಗೊಂಡಿದೆ ಐಟಂ ತನ್ನ ಅಂತಿಮ ಪೇಲೋಡ್‌ನೊಂದಿಗೆ ಅಂತಿಮಗೊಳ್ಳುವಾಗ

ಈ ಲೈಫ್‌ಸೈಕಲ್ ಗ್ರಾಹಕರಿಗೆ started ನಲ್ಲಿ ತಕ್ಷಣವೇ ರೆಂಡರಿಂಗ್ ಪ್ರಾರಂಭಿಸಲು, ಡೆಲ್ಟಾ ನಲ್ಲಿ ಕ್ರಮೇಣ ನವೀಕರಣಗಳನ್ನು ಸ್ಟ್ರೀಮ್ ಮಾಡಲು ಮತ್ತು ಪೂರ್ಣಗೊಂಡಿದೆ ನಲ್ಲಿ ಅಂತಿಮಗೊಳಿಸಲು ಅವಕಾಶ ನೀಡುತ್ತದೆ.

2. ಟರ್ನ್: ಟರ್ನ್ ಎಂದರೆ ಬಳಕೆದಾರ ಇನ್‌ಪುಟ್‌ನಿಂದ ಪ್ರಾರಂಭವಾಗುವ ಏಜೆಂಟ್ ಕಾರ್ಯದ ಒಂದು ಘಟಕ. ಇದು ಗ್ರಾಹಕನು ಒಂದು ಇನ್‌ಪುಟ್ ಅನ್ನು ಸಲ್ಲಿಸಿದಾಗ (ಉದಾಹರಣೆಗೆ, “ಟೆಸ್ಟ್‌ಗಳನ್ನು ರನ್ ಮಾಡಿ ಮತ್ತು ವೈಫಲ್ಯಗಳನ್ನು ಸಾರಾಂಶಗೊಳಿಸಿ”) ಆರಂಭವಾಗಿ, ಆ ಇನ್‌ಪುಟ್‌ಗಾಗಿ ಏಜೆಂಟ್ ಔಟ್‌ಪುಟ್‌ಗಳನ್ನು ಉತ್ಪಾದಿಸುವುದನ್ನು ಮುಗಿಸಿದಾಗ ಅಂತ್ಯಗೊಳ್ಳುತ್ತದೆ. ಒಂದು ಟರ್ನ್ ನಲ್ಲಿ ಮಧ್ಯಂತರ ಹಂತಗಳು ಮತ್ತು ಮಾರ್ಗಮಧ್ಯೆ ಉತ್ಪಾದಿಸಲಾದ ಔಟ್‌ಪುಟ್‌ಗಳನ್ನು ಪ್ರತಿನಿಧಿಸುವ ಐಟಂ‌ಗಳ ಸರಣಿಯಿರುತ್ತದೆ.

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

ಈಗ, ಪ್ರಿಮಿಟಿವ್‌ಗಳ ಮೂಲಕ ಪ್ರತಿನಿಧಿಸಲಾದ ಸಂಭಾಷಣೆಯಲ್ಲಿ, ಗ್ರಾಹಕ ಮತ್ತು ಏಜೆಂಟ್ ನಡುವಿನ ಸರಳೀಕೃತ ಸಂಭಾಷಣೆಯನ್ನು ನಾವು ನೋಡುತ್ತೇವೆ:

‘ಕ್ಲೈಂಟ್-ಸರ್ವರ್ ಪ್ರೋಟೋಕಾಲ್ ಸಂದೇಶ ಹರಿವು: ಆರಂಭಿಕ ಹ್ಯಾಂಡ್‌ಶೇಕ್’ ಎಂದು ಲೇಬಲ್ ಮಾಡಲಾದ ಚಿತ್ರ. ಒಬ್ಬ ಗ್ರಾಹಕ ಗ್ರಾಹ್ಯಕಮಾಹಿತಿಯೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಿ ವಿನಂತಿಯನ್ನು ಸರ್ವರ್‌ಗೆ ಕಳುಹಿಸುತ್ತಾನೆ. ಸರ್ವರ್ “my_client/1.0” ಎಂಬ ಯೂಸರ್ ಏಜೆಂಟ್ ಸ್ಟ್ರಿಂಗ್ ಅನ್ನು ಒಳಗೊಂಡ ಫಲಿತಾಂಶ ಈವೆಂಟ್‌ನೊಂದಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತದೆ.

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

JSON

1{
2  "method": "initialize",
3  "id": 0,
4  "params": {
5    "clientInfo": {
6      "name": "codex_vscode",
7      "title": "Codex VS Code Extension",
8      "version": "0.1.0"
9    }
10  }
11}

ಇದು ಸರ್ವರ್ ಹಿಂತಿರುಗಿಸುವುದು:

JSON

1{
2  "id": 0,
3  "result": {
4    "userAgent": "codex_vscode/0.94.0-alpha.7 (Mac OS 26.2.0; arm64) vscode/2.4.22 (codex_vscode; 0.1.0)"
5  }
6}

“ಕ್ಲೈಂಟ್-ಸರ್ವರ್ ಪ್ರೋಟೋಕಾಲ್ ಸಂದೇಶ ಹರಿವು: ಥ್ರೆಡ್ ಮತ್ತು ಟರ್ನ್ ಲೈಫ್ ಸೈಕಲ್.” ಎಂಬ ಶೀರ್ಷಿಕೆಯ ಡಯಾಗ್ರಾಂ. ಗ್ರಾಹಕ ಥ್ರೆಡ್/ಪ್ರಾರಂಭ ಮತ್ತು ಟರ್ನ್/ಪ್ರಾರಂಭಿಸಿ ವಿನಂತಿಗಳನ್ನು ಸರ್ವರ್‌ಗೆ ಕಳುಹಿಸುತ್ತಾರೆ. ಸರ್ವರ್ ಥ್ರೆಡ್/ಪ್ರಾರಂಭಿಸಲಾಗಿದೆ, ಟರ್ನ್/ಪ್ರಾರಂಭಿಸಲಾಗಿದೆ, ಐಟಂ/ಪ್ರಾರಂಭಿಸಲಾಗಿದೆ ಮತ್ತು ಐಟಂ/ಪೂರ್ಣಗೊಂಡಿದೆ ಎಂಬ ಈವೆಂಟ್‌ಗಳನ್ನು ಹೊರಸೂಸುತ್ತದೆ, ಇದು ಬಳಕೆದಾರರ ಸಂದೇಶ “ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸಿ ಮತ್ತು ವೈಫಲ್ಯಗಳನ್ನು ಸಾರಾಂಶಗೊಳಿಸಿ.” ಅನ್ನು ತೋರಿಸುವ ಒಂದು ತಿರುವನ್ನು ಸೂಚಿಸುತ್ತದೆ.

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

‘ಕ್ಲೈಂಟ್-ಸರ್ವರ್ ಪ್ರೋಟೋಕಾಲ್ ಸಂದೇಶ ಹರಿವು: ಐಚ್ಛಿಕ ಅನುಮೋದನೆಯೊಂದಿಗೆ ಟೂಲ್ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆ’ ಎಂಬ ಶೀರ್ಷಿಕೆಯ ರೇಖಾಚಿತ್ರ. ಟೂಲ್ ಕಾಲ್ ಸಮಯದಲ್ಲಿ, ಸರ್ವರ್ ಐಟಂ/ಪ್ರಾರಂಭಿಸಲಾಗಿದೆ ಅನ್ನು ಎಮಿಟ್ ಮಾಡುತ್ತದೆ, ನಂತರ ಐಟಂ/ಕಮಾಂಡ್ ಎಕ್ಸಿಕ್ಯೂಶನ್/ಕೋರಿಕೆ ಅನುಮೋದನೆ ಅನ್ನು 'ಕಾರಣ' ('ಟೆಸ್ಟ್ಸ್ ನಡೆಸಿ') ಸಹಿತ ಎಮಿಟ್ ಮಾಡುತ್ತದೆ. ಗ್ರಾಹಕ ಅನುಮೋದನೆ ಈವೆಂಟ್ ಅನ್ನು (ಅನುಮತಿಸಿ/ನಿರಾಕರಿಸಿ) ಹಿಂತಿರುಗಿಸುತ್ತದೆ. ನಂತರ ಸರ್ವರ್ ಆಜ್ಞೆ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯನ್ನು ("pnpm ಪರೀಕ್ಷೆ") ತೋರಿಸುವ ಐಟಂ/ಪೂರ್ಣಗೊಂಡಿದೆ ಅನ್ನು ಹೊರಸೂಸುತ್ತದೆ.

ಟೂಲ್ ಕಾಲ್ ಗಳನ್ನು ಸಹ ಐಟಂಗಳಾಗಿ ಗ್ರಾಹಕರಿಗೆ ಹಿಂದಿರುಗಿಸಲಾಗುತ್ತದೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಸರ್ವರ್ ಒಂದು ಕ್ರಿಯೆಯನ್ನು ನಿರ್ವಹಿಸುವ ಮೊದಲು, ಸರ್ವರ್ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸುವ ಮೂಲಕ ಕ್ಲೈಂಟ್ ಅನುಮೋದನೆಯನ್ನು ಕೇಳಬಹುದು. ಅನುಮೋದನೆ ಕ್ಲೈಂಟ್ “ಅನುಮತಿಸಿ” ಅಥವಾ “ನಿರಾಕರಿಸಿ” ಎಂದು ಪ್ರತಿಕ್ರಿಯಿಸುವವರೆಗೆ ಟರ್ನ್ ಅನ್ನು ವಿರಾಮಗೊಳಿಸುತ್ತದೆ. VS ಕೋಡ್ ವಿಸ್ತರಣೆಯಲ್ಲಿ ಅನುಮೋದನೆ ಪ್ರಕ್ರಿಯೆಯು ಈ ರೀತಿಯಾಗಿದೆ:

ಡಾರ್ಕ್ ಥೀಮ್‌ನ ಇಂಟರ್ಫೇಸ್‌ನಲ್ಲಿರುವ ಅನುಮತಿ ಪ್ರಾಂಪ್ಟ್, “ಈ ವರ್ಕ್‌ಸ್ಪೇಸ್‌ಗಾಗಿ pnpm ಪರೀಕ್ಷೆಯನ್ನು ಚಲಾಯಿಸಲು ನೀವು ನನಗೆ ಅನುಮತಿಸಲು ಬಯಸುವಿರಾ?” ಎಂದು ಕೇಳುತ್ತದೆ. ಇದು ಆಯ್ಕೆಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ: 1) ಹೌದು, 2) pnpm test ನಿಂದ ಆರಂಭವಾಗುವ ಕಮಾಂಡ್‌ಗಳಿಗೆ ಹೌದು ಮತ್ತು ಮತ್ತೆ ಕೇಳಬೇಡಿ, 3) ಇಲ್ಲ, ಕೆಳಭಾಗದಲ್ಲಿ ಸಲ್ಲಿಸಿ ಬಟನ್‌ನೊಂದಿಗೆ.

“ಕ್ಲೈಂಟ್-ಸರ್ವರ್ ಪ್ರೋಟೋಕಾಲ್ ಸಂದೇಶ ಹರಿವು: ಸ್ಟ್ರೀಮಿಂಗ್ ಏಜೆಂಟ್ ಸಂದೇಶ ಹರಿವು.” ಎಂಬ ಶೀರ್ಷಿಕೆಯ ಡಯಾಗ್ರಾಂ. ಸರ್ವರ್ ಅಸಿಸ್ಟಂಟ್ ಸಂದೇಶವನ್ನು ಭಾಗಗಳಾಗಿ ಸ್ಟ್ರೀಮ್ ಮಾಡುತ್ತದೆ: ಐಟಂ/ಆರಂಭಿಸಲಾಗಿದೆ, ಎರಡು ಏಜೆಂಟ್‌ಮೆಸೇಜ್/ಡೆಲ್ಟಾ ಈವೆಂಟ್‌ಗಳು (“ಮೂರು ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸಿತು.”, “ಎಲ್ಲವೂ ಉತ್ತೀರ್ಣವಾಗಿದೆ”), ನಂತರ ಐಟಂ/ಪೂರ್ಣಗೊಂಡಿದೆ. ಟರ್ನ್ ಟರ್ನ್/ಪೂರ್ಣಗೊಂಡಿದೆ ನೊಂದಿಗೆ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ.

ಕೊನೆಯಲ್ಲಿ, ಸರ್ವರ್ ಏಜೆಂಟ್ ಸಂದೇಶವನ್ನು ಕಳುಹಿಸಿ ನಂತರ ಟರ್ನ್/ಪ್ರಾರಂಭಿಸಲಾಗಿದೆ ಮೂಲಕ ಟರ್ನ್ ಅನ್ನು ಅಂತ್ಯಗೊಳಿಸುತ್ತದೆ. ಏಜೆಂಟ್ ಸಂದೇಶ ಡೆಲ್ಟಾ ಈವೆಂಟ್‌ಗಳು ಸಂದೇಶದ ಭಾಗಗಳನ್ನು ಸ್ಟ್ರೀಮ್ ಮಾಡುತ್ತವೆ, ಐಟಂ/ಪೂರ್ಣಗೊಂಡಿದೆ ಮೂಲಕ ಸಂದೇಶವನ್ನು ಅಂತಿಮಗೊಳಿಸುವವರೆಗೆ.

ರೇಖಾಚಿತ್ರದಲ್ಲಿನ ಸಂದೇಶಗಳನ್ನು ಓದಲು ಸುಲಭವಾಗುವಂತೆ ಸರಳಗೊಳಿಸಲಾಗಿದೆ. ನೀವು ಸಂಪೂರ್ಣ ಟರ್ನ್ ಗಾಗಿ JSON ಅನ್ನು ನೋಡಲು ಬಯಸಿದರೆ, ನೀವು Codex CLI ರೆಪೋದಿಂದ ಟೆಸ್ಟ್ ಕ್ಲೈಂಟ್ ಅನ್ನು ರನ್ ಮಾಡಬಹುದು:

Bash

1codex debug app-server send-message-v2 "run tests and summarize failures"

ಗ್ರಾಹಕರೊಂದಿಗೆ ಏಕೀಕರಣ

ಈಗ, ವಿವಿಧ ಕ್ಲೈಂಟ್ ಸರ್ಫೇಸ್‌ಗಳು ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್ ಮೂಲಕ Codex ಅನ್ನು ಹೇಗೆ ಅಳವಡಿಸುತ್ತವೆ ಎಂಬುದನ್ನು ನೋಡೋಣ. ನಾವು ಮೂರು ಮಾದರಿಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತೇವೆ: ಸ್ಥಳೀಯ ಆಪ್‌ಗಳು ಮತ್ತು IDEಗಳು, Codex ವೆಬ್ ರನ್‌ಟೈಮ್, ಮತ್ತು TUI.

“ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್ ಮೂಲಕ Codex ಹಾರ್ನೆಸ್‌ಗೆ ಏಕೀಕೃತಗೊಂಡ Codex ಕ್ಲೈಂಟ್‌ಗಳು” ಎಂಬ ಶೀರ್ಷಿಕೆಯ ರೇಖಾಚಿತ್ರ. ಮೊದಲ-ಪಕ್ಷದ ಕ್ಲೈಂಟ್‌ಗಳು (ಕೋಡೆಕ್ಸ್ ಡೆಸ್ಕ್‌ಟಾಪ್ ಅಪ್ಲಿಕೇಶನ್, TUI/CLI, ವೆಬ್ ರನ್‌ಟೈಮ್) ಮತ್ತು ತೃತೀಯ-ಪಕ್ಷದ ಇಂಟಿಗ್ರೇಷನ್‌ಗಳು (JetBrains IDEs, VS ಕೋಡ್, Xcode) JSON-RPC ಕರೆಗಳ ಮೂಲಕ Codex ಹಾರ್ನೆಸ್ ಮೂಲಕ ಸಂವಹನ ಮಾಡುತ್ತವೆ.

ಮೂರರಲ್ಲಿಯೂ, ಸಾರಿಗೆ stdio (JSONL) ಮೇಲೆ JSON-RPC ಆಗಿದೆ. JSON-RPC ನಿಮ್ಮ ಆಯ್ಕೆಯ ಭಾಷೆಯಲ್ಲಿ ಕ್ಲೈಂಟ್ ಬೈಂಡಿಂಗ್‌ಗಳನ್ನು ನಿರ್ಮಿಸಲು ಸುಲಭವಾಗಿಸುತ್ತದೆ. Codex ಸರ್ಫೇಸ್‌ಗಳು ಮತ್ತು ಪಾಲುದಾರ ಏಕೀಕರಣಗಳು Go, Python, TypeScript, Swift ಮತ್ತು Kotlin ಸೇರಿದಂತೆ ಭಾಷೆಗಳಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್ ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಅನುಷ್ಠಾನಗೊಳಿಸಿವೆ. TypeScript ಗಾಗಿ, ನೀವು ಈ ಕೆಳಗಿನುದನ್ನು ರನ್ ಮಾಡುವ ಮೂಲಕ Rust ಪ್ರೋಟೋಕಾಲ್‌ನಿಂದ ನೇರವಾಗಿ ವ್ಯಾಖ್ಯಾನಗಳನ್ನು ರಚಿಸಬಹುದು:

Bash

1codex app-server generate-ts

ಇತರೆ ಭಾಷೆಗಳಿಗಾಗಿ, ನೀವು JSON ಸ್ಕೀಮಾ ಬಂಡಲ್ ಅನ್ನು ರಚಿಸಿ ಮತ್ತು ಅದನ್ನು ನಿಮ್ಮ ಇಷ್ಟದ ಕೋಡ್ ಜನರೇಟರ್‌ಗೆ ಫೀಡ್ ಮಾಡಲು ರನ್ ಮಾಡಬಹುದು:

Bash

1codex app-server generate-json-schema

ಸ್ಥಳೀಯ ಆ್ಯಪ್‌ಗಳು ಮತ್ತು IDE ಗಳು

Codex ವಿಸ್ತರಣೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿರುವ VS ಕೋಡ್ ನ ಸ್ಕ್ರೀನ್‌ಶಾಟ್. ಒಂದು ರಸ್ಟ್ ಟೆಸ್ಟ್ ಫೈಲ್ ತೆರೆಯಲಾಗಿದೆ, ಮತ್ತು ಅದರ ಕೆಳಗೆ Codex ಪ್ಯಾನೆಲ್ ಕೇವಲ fmt ಮತ್ತು ಕಾರ್ಗೋ ಟೆಸ್ಟ್ -p codex-app-server ಅನ್ನು ರನ್ ಮಾಡುತ್ತಿರುವುದನ್ನು ವಿವರಿಸುತ್ತದೆ, ಫಾರ್ಮ್ಯಾಟಿಂಗ್ ಮತ್ತು ಟೆಸ್ಟ್‌ಗಳು ಪ್ರಗತಿಯಲ್ಲಿ ಇವೆ ಎಂದು ವರದಿ ಮಾಡುತ್ತಾ, ಅಂತಿಮ ಪಾಸ್/ಫೇಲ್ ಫಲಿತಾಂಶಕ್ಕಾಗಿ ಕಾಯುತ್ತಿದೆ.

ಸ್ಥಳೀಯ ಕ್ಲೈಂಟ್‌ಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್-ನಿರ್ದಿಷ್ಟ ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್ ಬೈನರಿ ಅನ್ನು ಬಂಡಲ್ ಮಾಡುತ್ತವೆ ಅಥವಾ ಫೆಚ್ ಮಾಡುತ್ತವೆ, ಅದನ್ನು ದೀರ್ಘಕಾಲ ಚಾಲನೆಯಲ್ಲಿರುವ ಚೈಲ್ಡ್ ಪ್ರೊಸೆಸ್ ಆಗಿ ಪ್ರಾರಂಭಿಸುತ್ತವೆ, ಮತ್ತು JSON-RPCಗಾಗಿ ದ್ವಿದಿಶ stdio ಚಾನೆಲ್ ಅನ್ನು ತೆರೆಯೇ ಇಡುತ್ತಾರೆ. ಉದಾಹರಣೆಗೆ, ನಮ್ಮ VS ಕೋಡ್ ಎಕ್ಸ್‌ಟೆನ್ಶನ್ ಮತ್ತು ಡೆಸ್ಕ್‌ಟಾಪ್ ಆ್ಯಪ್‌ನಲ್ಲಿ, ರವಾನಿಸಲಾದ ಆರ್ಟಿಫ್ಯಾಕ್ಟ್‌ನಲ್ಲಿ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್-ನಿರ್ದಿಷ್ಟ Codex ಬೈನರಿ ಸೇರಿರುತ್ತದೆ ಮತ್ತು ಪರೀಕ್ಷಿತ ಆವೃತ್ತಿಗೆ ಪಿನ್ ಮಾಡಲಾಗಿದೆ, ಆದ್ದರಿಂದ ಗ್ರಾಹಕರು ನಾವು ಮಾನ್ಯಗೊಳಿಸಿದ ನಿಖರವಾದ ಬಿಟ್‌ಗಳನ್ನೇ ಯಾವಾಗಲೂ ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತಾರೆ.

ಪ್ರತಿ ಏಕೀಕರಣವು ಕ್ಲೈಂಟ್ ನವೀಕರಣಗಳನ್ನು ಆಗಾಗ್ಗೆ ರವಾನಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. Xcode ನಂತಹ ಕೆಲವು ಪಾಲುದಾರರು ಬಿಡುಗಡೆ ಚಕ್ರಗಳನ್ನು ಬೇರ್ಪಡಿಸಲು, ಕ್ಲೈಂಟ್ ಅನ್ನು ಸ್ಥಿರವಾಗಿರಿಸಿ, ಅಗತ್ಯವಿದ್ದಾಗ ಅದನ್ನು ಹೊಸ ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್ ಬೈನರಿ ಕಡೆಗೆ ಸೂಚಿಸಲು ಅವಕಾಶ ನೀಡುತ್ತಾರೆ. ಆ ರೀತಿಯಲ್ಲಿ ಅವರು ಸರ್ವರ್-ಸೈಡ್ ಸುಧಾರಣೆಗಳನ್ನು (ಉದಾಹರಣೆಗೆ, Codex ಕೋರ್‌ನಲ್ಲಿ ಉತ್ತಮ ಸ್ವಯಂ-ಸಂಕುಚನ ಅಥವಾ ಹೊಸದಾಗಿ ಬೆಂಬಲಿತ ಕಾನ್ಫಿಗ್ ಕೀಗಳು) ಅಳವಡಿಸಿಕೊಳ್ಳಬಹುದು ಮತ್ತು ಕ್ಲೈಂಟ್ ಬಿಡುಗಡೆಯನ್ನು ಕಾಯದೆ ದೋಷ ತಿದ್ದುಪಡಿಗಳನ್ನು ಬಿಡುಗಡೆ ಮಾಡಬಹುದು. ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್‌ನ JSON-RPC ಸರ್ಫೇಸ್ ಅನ್ನು ಹಿಂದಿನ ಆವೃತ್ತಿಗಳೊಂದಿಗೆ ಹೊಂದಾಣಿಕೆಯಾಗುವಂತೆ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ, ಆದ್ದರಿಂದ ಹಳೆಯ ಕ್ಲೈಂಟ್‌ಗಳು ಹೊಸ ಸರ್ವರ್‌ಗಳೊಂದಿಗೆ ಸುರಕ್ಷಿತವಾಗಿ ಸಂವಹನ ಮಾಡಬಹುದು.

Codex ವೆಬ್

Codex ವೆಬ್ Codex ಹಾರ್ನೆಸ್ ಅನ್ನು ಬಳಸುತ್ತದೆ, ಆದರೆ ಅದನ್ನು ಕಂಟೈನರ್ ಪರಿಸರದಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಒಬ್ಬ ಕಾರ್ಮಿಕನು ಚೆಕ್‌ಔಟ್ ಮಾಡಿದ ವರ್ಕ್‌ಸ್ಪೇಸ್‌ನೊಂದಿಗೆ ಒಂದು ಕಂಟೇನರ್ ಅನ್ನು ಒದಗಿಸುತ್ತಾನೆ, ಅದರೊಳಗೆ ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್ ಬೈನರಿ ಅನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತಾನೆ ಮತ್ತು stdio² ಚಾನೆಲ್ ಮೂಲಕ ದೀರ್ಘಕಾಲ JSON-RPC ಅನ್ನು ನಿರ್ವಹಿಸುತ್ತಾನೆ. ವೆಬ್ ಆಪ್ (ಬಳಕೆದಾರರ ಬ್ರೌಸರ್ ಟ್ಯಾಬ್‌ನಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿರುವುದು) HTTP ಮತ್ತು SSE ಮೂಲಕ Codex ಬ್ಯಾಕ್‌ಎಂಡ್‌ ಜೊತೆ ಸಂವಹನ ಮಾಡುತ್ತದೆ, ಇದು ಕಾರ್ಮಿಕ ಉತ್ಪಾದಿಸುವ ಕಾರ್ಯ ಈವೆಂಟ್‌ಗಳನ್ನು ಸ್ಟ್ರೀಮ್ ಮಾಡುತ್ತದೆ. ಇದು ಬ್ರೌಸರ್-ಬದಿಯ UI ಅನ್ನು ಹಗುರವಾಗಿರಿಸುತ್ತದೆ, ಆದರೆ ಡೆಸ್ಕ್‌ಟಾಪ್ ಮತ್ತು ವೆಬ್‌ನಲ್ಲಿ ನಮಗೆ ಸ್ಥಿರವಾದ ರನ್‌ಟೈಮ್ ಅನ್ನು ಒದಗಿಸುತ್ತದೆ.

ವೆಬ್ ಸೆಷನ್‌ಗಳು ಕ್ಷಣಿಕವಾಗಿರುವುದರಿಂದ (ಟ್ಯಾಬ್‌ಗಳು ಮುಚ್ಚುತ್ತವೆ, ನೆಟ್‌ವರ್ಕ್‌ಗಳು ಕಡಿತಗೊಳ್ಳುತ್ತವೆ), ದೀರ್ಘಕಾಲೀನ ಕಾರ್ಯಗಳಿಗೆ ವೆಬ್ ಆ್ಯಪ್ ನಿಖರ ಮಾಹಿತಿಯ ಮೂಲವಾಗಲು ಸಾಧ್ಯವಿಲ್ಲ. ಸರ್ವರ್‌ನಲ್ಲಿ ಸ್ಥಿತಿ ಮತ್ತು ಪ್ರಗತಿಯನ್ನು ಉಳಿಸುವುದರಿಂದ ಟ್ಯಾಬ್ ಕಾಣೆಯಾಗಿದ್ದರೂ ಸಹ ಕೆಲಸ ಮುಂದುವರಿಯುತ್ತದೆ. ಸ್ಟ್ರೀಮಿಂಗ್ ಪ್ರೋಟೋಕಾಲ್ ಮತ್ತು ಉಳಿಸಿದ ಥ್ರೆಡ್ ಸೆಷನ್‌ಗಳು ಹೊಸ ಸೆಷನ್‌ಗೆ ಮರುಸಂಪರ್ಕಿಸಲು, ಬಿಟ್ಟುಹೋದ ಸ್ಥಳದಿಂದ ಮುಂದುವರಿಯಲು ಮತ್ತು ಕ್ಲೈಂಟ್‌ನಲ್ಲಿ ಸ್ಥಿತಿಯನ್ನು ಮರುನಿರ್ಮಿಸದೆ ತಕ್ಷಣವೇ ಹಿಡಿಯಲು ಸುಲಭವಾಗಿಸುತ್ತವೆ.

TUI/Codex CLI

Codex CLI ಅನ್ನು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿರುವ ಟರ್ಮಿನಲ್‌ನ ಸ್ಕ್ರೀನ್‌ಶಾಟ್. ಇದು OpenAI Codex ಬ್ಯಾನರ್ ಅನ್ನು gpt-5.2-codex ಮಾಡೆಲ್ ತೋರಿಸುತ್ತದೆ ಮಧ್ಯಮ, ಬಳಕೆದಾರ ಆಜ್ಞೆ “ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್ ಅನ್ನು ನನಗೆ ವಿವರಿಸಿ,” ಮತ್ತು “ಕೆಲಸದ” ಸ್ಥಿತಿ. ಕೆಳಗೆ, ಒಂದು ಸಲಹೆ ಕಾಣಿಸುತ್ತದೆ: “@filenameಗಾಗಿ ಪರೀಕ್ಷೆಗಳನ್ನು ಬರೆಯಿರಿ,” ಶಾರ್ಟ್‌ಕಟ್‌ಗಳ ಆಯ್ಕೆಗಳೊಂದಿಗೆ.

ಐತಿಹಾಸಿಕವಾಗಿ, TUI ಒಂದು “ನೇಟಿವ್” ಕ್ಲೈಂಟ್ ಆಗಿದ್ದು, ಅದು ಏಜೆಂಟ್ ಲೂಪ್‌ನೊಂದಿಗೆ ಅದೇ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿತ್ತು ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್ ಪ್ರೋಟೋಕಾಲ್‌ಗಿಂತಲೂ ರಸ್ಟ್ ಕೋರ್ ಪ್ರಕಾರಗಳೊಂದಿಗೆ ನೇರವಾಗಿ ಸಂವಹನ ಮಾಡುತ್ತಿತ್ತು. ಅದರಿಂದ ಆರಂಭಿಕ ಪುನರಾವರ್ತನೆ ವೇಗವಾಗಿತ್ತು, ಆದರೆ TUI ಅನ್ನು ವಿಶೇಷ-ಪ್ರಕರಣದ ಮೇಲ್ಮೈಯಾಗಿಯೂ ಮಾಡಿತು.

ಈಗ ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವುದರಿಂದ, ನಾವು TUI ಅನ್ನು ಪುನರ್‌ರಚಿಸಲು⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) ಯೋಜಿಸುತ್ತಿದ್ದೇವೆ, ಇದನ್ನು ಬಳಸಿಕೊಂಡು ಅದು ಯಾವುದೇ ಇತರ ಕ್ಲೈಂಟ್‌ನಂತೆ ವರ್ತಿಸುತ್ತದೆ: ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್ ಚೈಲ್ಡ್ ಪ್ರೊಸೆಸ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಿ, stdio ಮೂಲಕ JSON-RPC ಮಾತನಾಡಿ ಮತ್ತು ಅದೇ ಸ್ಟ್ರೀಮಿಂಗ್ ಈವೆಂಟ್‌ಗಳು ಮತ್ತು ಅನುಮೋದನೆಗಳನ್ನು ರೆಂಡರ್ ಮಾಡಿ. ಇದು TUI ಅನ್ನು ದೂರಸ್ಥ ಯಂತ್ರದಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿರುವ Codex ಸರ್ವರ್‌ಗೆ ಸಂಪರ್ಕಿಸಲು ಅನುಮತಿಸುತ್ತದೆ, ಏಜೆಂಟ್ ಅನ್ನು ಗಣನೆಗೆ ಹತ್ತಿರದಲ್ಲೇ ಇಟ್ಟುಕೊಂಡು, ಲ್ಯಾಪ್‌ಟಾಪ್ ನಿದ್ರಿಸುತ್ತಿದ್ದರೂ ಅಥವಾ ಸಂಪರ್ಕ ಕಡಿತಗೊಂಡರೂ ಕೆಲಸವನ್ನು ಮುಂದುವರಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ ಮತ್ತು ಸ್ಥಳೀಯವಾಗಿ ಲೈವ್ ಅಪ್‌ಡೇಟ್‌ಗಳು ಮತ್ತು ನಿಯಂತ್ರಣಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ.

ಸರಿಯಾದ ಪ್ರೋಟೋಕಾಲ್ ಆಯ್ಕೆ ಮಾಡುವುದು

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

JSON-RPC ಪ್ರೋಟೋಕಾಲ್‌ಗಳು

Codex MCP ಸರ್ವರ್ ಆಗಿ

Codex mcp-ಸರ್ವರ್⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) ಅನ್ನು ಚಾಲನೆ ಮಾಡಿ ಮತ್ತು stdio ಸರ್ವರ್‌ಗಳನ್ನು ಬೆಂಬಲಿಸುವ ಯಾವುದೇ MCP ಕ್ಲೈಂಟ್‌ನಿಂದ ಸಂಪರ್ಕಿಸಿ (ಉದಾಹರಣೆಗೆ, OpenAI ಏಜೆಂಟ್ಸ್ SDK⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ)). ನೀವು ಈಗಾಗಲೇ MCP-ಆಧಾರಿತ ವರ್ಕ್‌ಫ್ಲೋ ಹೊಂದಿದ್ದರೆ ಮತ್ತು Codex ಅನ್ನು ಕರೆಸಬಹುದಾದ ಸಾಧನವಾಗಿ ಕರೆಸಲು ಬಯಸಿದರೆ ಇದು ಉತ್ತಮ ಹೊಂದಾಣಿಕೆ. ಕಡಮೆ ಅಂದರೆ, ನೀವು MCP ಬಹಿರಂಗಪಡಿಸುವುದನ್ನೇ ಪಡೆಯುತ್ತೀರಿ, ಆದ್ದರಿಂದ ಹೆಚ್ಚು ಸಮೃದ್ಧ ಸೆಷನ್ ಅರ್ಥವ್ಯವಸ್ಥೆ (ಉದಾ., ಡಿಫ್ ಅಪ್‌ಡೇಟ್ಸ್) ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುವ Codex-ನಿರ್ದಿಷ್ಟ ಸಂವಹನಗಳು MCP ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಳ ಮೂಲಕ ಸರಿಯಾಗಿ ಮ್ಯಾಪ್ ಆಗದೇ ಇರಬಹುದು.

ವಿವಿಧ-ಪ್ರೊವೈಡರ್ ಏಜೆಂಟ್ ಹಾರ್ನೆಸ್ ಪ್ರೋಟೋಕಾಲ್‌ಗಳು

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

Codex ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್

ಸ್ಥಿರ, UI-ಸ್ನೇಹಿ ಈವೆಂಟ್ ಸ್ಟ್ರೀಮ್ ಆಗಿ ಸಂಪೂರ್ಣ Codex ಹಾರ್ನೆಸ್ ಅನ್ನು ಬಹಿರಂಗಪಡಿಸಲು ನೀವು ಬಯಸುವಾಗ ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್ ಅನ್ನು ಆಯ್ಕೆಮಾಡಿ. ನೀವು ಏಜೆಂಟ್ ಲೂಪ್‌ನ ಸಂಪೂರ್ಣ ಕಾರ್ಯಕ್ಷಮತೆ ಮತ್ತು ChatGPT ಮೂಲಕ ಸೈನ್ ಇನ್, ಮಾಡೆಲ್ ಅನ್ವೇಷಣೆ ಮತ್ತು ಸಂರಚನೆ ನಿರ್ವಹಣೆ ಮುಂತಾದ ಇತರ ಬೆಂಬಲ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಪಡೆಯುತ್ತೀರಿ. ಮುಖ್ಯ ವೆಚ್ಚವು ಸಂಯೋಜನೆ ಕೆಲಸವಾಗಿದೆ, ಏಕೆಂದರೆ ನಿಮ್ಮ ಭಾಷೆಯಲ್ಲಿ ಕ್ಲೈಂಟ್-ಸೈಡ್ JSON-RPC ಬೈಂಡಿಂಗ್ ಅನ್ನು ನೀವು ನಿರ್ಮಿಸಬೇಕಾಗುತ್ತದೆ. ಆದರೆ, ಪ್ರಾಯೋಗಿಕವಾಗಿ, ನೀವು JSON ಸ್ಕೀಮಾ ಮತ್ತು ಡಾಕ್ಯುಮೆಂಟೇಶನ್ ಅನ್ನು Codex ಗೆ ನೀಡಿದರೆ, ಅದು ಬಹಳಷ್ಟು ಕಷ್ಟದ ಕೆಲಸವನ್ನು ಮಾಡಬಲ್ಲದು. ನಾವು ಕೆಲಸ ಮಾಡಿದ ಅನೇಕ ತಂಡಗಳು Codex ಬಳಸಿ ಶೀಘ್ರವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಏಕೀಕರಣವನ್ನು ಮಾಡಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಾಯಿತು.

Codex ಅನ್ನು ಎಂಬೆಡ್ ಮಾಡಲು ಇತರ ಮಾರ್ಗಗಳು

Codex ಎಕ್ಸೆಕ್⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ)

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

ಕೋಡೆಕ್ಸ್ SDK⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ)

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

ಇದನ್ನು ಮುಂದಕ್ಕೆ ಸಾಗಿಸುವುದು

ಈ ಪೋಸ್ಟ್‌ನಲ್ಲಿ, ನಾವು ಏಜೆಂಟ್‌ಗಳೊಂದಿಗೆ ಸಂವಹನ ಮಾಡಲು ಹೊಸ ಮಾನದಂಡವನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸುವ ನಮ್ಮ ವಿಧಾನವನ್ನು ಮತ್ತು Codex ಹಾರ್ನೆಸ್ ಅನ್ನು ಸ್ಥಿರ, ಗ್ರಾಹಕ-ಸ್ನೇಹಿ ಪ್ರೋಟೋಕಾಲ್ ಆಗಿ ಪರಿವರ್ತಿಸುವ ವಿಧಾನವನ್ನು ಹಂಚಿಕೊಂಡಿದ್ದೇವೆ. ನಾವು ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್ ಹೇಗೆ Codex ಕೋರ್ ಅನ್ನು ಬಹಿರಂಗಪಡಿಸುತ್ತದೆ, ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಸಂಪೂರ್ಣ ಏಜೆಂಟ್ ಲೂಪ್ ಅನ್ನು ಚಾಲನೆ ಮಾಡಲು ಅವಕಾಶ ನೀಡುತ್ತದೆ ಮತ್ತು TUI, ಸ್ಥಳೀಯ IDE ಏಕೀಕರಣಗಳು ಹಾಗೂ ವೆಬ್ ರನ್‌ಟೈಮ್ ಸೇರಿದಂತೆ ವ್ಯಾಪಕ ಶ್ರೇಣಿಯ ಸರ್ಫೇಸ್‌ಗಳಿಗೆ ಶಕ್ತಿ ನೀಡುತ್ತದೆ ಎಂಬುದನ್ನು ವಿವರಿಸಿದ್ದೇವೆ.

ನಿಮ್ಮ ಸ್ವಂತ ಕಾರ್ಯಪ್ರವಾಹಗಳಲ್ಲಿ Codex ಅನ್ನು ಒಕ್ಕೂಟಗೊಳಿಸಲು ಈ ವಿಚಾರಗಳು ಪ್ರೇರೇಪಿಸಿದರೆ, ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್ ಅನ್ನು ಪ್ರಯತ್ನಿಸುವುದು ಮೌಲ್ಯಯುಕ್ತವಾಗಿದೆ. ಎಲ್ಲಾ ಮೂಲ ಕೋಡ್ Codex CLI ಓಪನ್-ಸೋರ್ಸ್ ರೆಪೋ⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ)ನಲ್ಲಿ ಇದೆ. ನಿಮ್ಮ ಪ್ರತಿಕ್ರಿಯೆ ಮತ್ತು ವೈಶಿಷ್ಟ್ಯ ವಿನಂತಿಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳಲು ಮುಕ್ತವಾಗಿರಿ. ನಿಮ್ಮಿಂದ ಕೇಳಲು ನಾವು ಉತ್ಸುಕರಾಗಿದ್ದೇವೆ ಮತ್ತು ಏಜೆಂಟ್‌ಗಳನ್ನು ಎಲ್ಲರಿಗೂ ಇನ್ನಷ್ಟು ಸುಲಭವಾಗಿ ಲಭ್ಯವಾಗುವಂತೆ ಮಾಡುತ್ತೇವೆ.

ಲೇಖಕ

Celia Chen

ಕೃತಜ್ಞತೆಗಳು

ಈ ಪೋಸ್ಟ್‌ಗೆ ಕೊಡುಗೆ ನೀಡಿದ ಮೈಕಲ್ ಬೋಲಿನ್, ಓವನ್ ಲಿನ್, ಎರಿಕ್ ಟ್ರೌಟ್ ಮತ್ತು ರಾಸ್ಮಸ್ ರೈಗಾರ್ಡ್ ಅವರಿಗೆ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್ ಮೇಲೆ ಕೆಲಸ ಮಾಡಿದ ಸಂಪೂರ್ಣ Codex ತಂಡಕ್ಕೆ ವಿಶೇಷ ಧನ್ಯವಾದಗಳು.

ಅಡಿಟಿಪ್ಪಣಿಗಳು

1
ನಾವು “JSON‑RPC lite” ರೂಪಾಂತರವನ್ನು ಬಳಸುತ್ತೇವೆ: ಇದು ವಿನಂತಿ/ಪ್ರತಿಕ್ರಿಯೆ/ಅಧಿಸೂಚನೆ ಆಕಾರವನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ, ಆದರೆ "jsonrpc": "2.0" ಹೆಡರ್ ಅನ್ನು ಅನ್ನು ಹೊರತುಪಡಿಸುತ್ತದೆ ಮತ್ತು stdio ಮೇಲೆ JSONL ರೂಪದಲ್ಲಿ ಫ್ರೇಮ್ ಮಾಡಲಾಗುತ್ತದೆ, ಕಠಿಣ JSON‑RPC 2.0 ಬದಲಿಗೆ.
2
“stdio” ಕಂಟೇನರ್‌ನೊಳಗಿನ ಆ್ಯಪ್-ಸರ್ವರ್‌ನ stdin/stdout ಅನ್ನು ಸೂಚಿಸುತ್ತದೆ ಹೋಸ್ಟ್ ಮಾಡಿದ ಸೆಟಪ್‌ಗಳಲ್ಲಿ, ಆ ಸ್ಟ್ರೀಮ್‌ಗಳನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಸ್ಥಿರವಾದ ನೆಟ್‌ವರ್ಕ್ ಸಂಪರ್ಕದ (ಉದಾ., WebSocket-ನಂತಹ) ಮೂಲಕ ಕಂಟೇನರ್ ರನ್‌ಟೈಮ್‌ಗೆ ಟನಲ್ ಮಾಡಲಾಗುತ್ತದೆ—ಆದ್ದರಿಂದ ಅದು ನಿಜವಾದ ಸ್ಥಳೀಯ ಪೈಪ್ ಅಲ್ಲದಿದ್ದರೂ stdio ಹಾಗೆ ವರ್ತಿಸುತ್ತದೆ.

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

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

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

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

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

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

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

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