ಪ್ರತಿಯೊಂದು ಏಜೆಂಟ್ ಸಿಸ್ಟಮ್ ಕೂಡ ಒಂದೇ ರೀತಿಯ ಅಹಿತಕರ ಸಮತೋಲನ ಕಾಯ್ದುಕೊಳ್ಳುವ ಸವಾಲನ್ನು (trade-off) ಎದುರಿಸುತ್ತದೆ. ಕೋಡ್ ರಿವ್ಯೂಗಳು ಮತ್ತು ಗಿಟ್ (git) ಇತಿಹಾಸದಲ್ಲಿ ಉಳಿಯುವಂತಹ ಆಳವಾದ, ಸುಸಜ್ಜಿತ ಜ್ಞಾನದ ತಳಪಾಯವನ್ನು (knowledge base) ನೀವು ಬಯಸುತ್ತೀರಿ. ಆದರೆ ರನ್ಟೈಮ್ (runtime) ವೇಗವಾಗಿ ಮತ್ತು ಕೇಂದ್ರೀಕೃತವಾಗಿರಬೇಕೆಂದು ನೀವು ಬಯಸುತ್ತೀರಿ. ಈ ಎರಡು ಅಗತ್ಯಗಳು ಪರಸ್ಪರ ವಿರುದ್ಧವಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತವೆ. ನೀವು ಎಷ್ಟು ಹೆಚ್ಚು ಸೂಚನೆಗಳನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತೀರೋ, ಅಷ್ಟೇ ಹೆಚ್ಚು ಅವುಗಳನ್ನೆಲ್ಲಾ ಪ್ರಾಂಪ್ಟ್ನಲ್ಲಿ (prompt) ಹಾಕಿ ಉತ್ತಮ ಫಲಿತಾಂಶದ ನಿರೀಕ್ಷೆ ಮಾಡುವುದು ಆಕರ್ಷಕವಾಗಿ ಕಾಣುತ್ತದೆ. ಆದರೆ ಆ ನಿರೀಕ್ಷೆಯ ಬೆಲೆ ಹೆಚ್ಚು.
Agent Project Context ಪರಿಸರ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ (ecosystem), ಈ ಉದ್ವಿಗ್ನತೆಯು ಎರಡು ಪದರಗಳಾಗಿ ಸ್ಪಷ್ಟವಾಗಿ ವಿಭಜಿಸಲ್ಪಟ್ಟಿದೆ. APC ಬಾಳಿಕೆಯನ್ನು (durability) ನಿರ್ವಹಿಸುತ್ತದೆ. APX ವೇಗವನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ. ಅವು ಹೇಗೆ ಪರಸ್ಪರ ಸಂವಹನ ನಡೆಸುತ್ತವೆ—ಮತ್ತು APX ಏಕೆ ಪ್ರತಿಯೊಂದು ಸ್ಕಿಲ್ ವ್ಯಾಖ್ಯಾನವನ್ನು (skill definition) ಮೊದಲೇ ಲೋಡ್ ಮಾಡಲು ನಿರಾಕರಿಸುತ್ತದೆ—ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು, ಹೆಚ್ಚಿನ ಆಪ್ಟಿಮೈಸೇಶನ್ ಗೈಡ್ಗಳಿಗಿಂತ ಹೆಚ್ಚು ಪ್ರಾಂಪ್ಟ್ ಇಂಜಿನಿಯರಿಂಗ್ ಬಗ್ಗೆ ತಿಳಿಸುತ್ತದೆ.
ಆರ್ಕೈವ್ ಮತ್ತು ಇಂಜಿನ್
APC ನ ಕೆಲಸವು ಶಾಶ್ವತತೆ (permanence). ಇದು ಮರುಬಳಕೆ ಮಾಡಬಹುದಾದ ಸ್ಕಿಲ್ ಫೈಲ್ಗಳನ್ನು .apc/skills/ ಅಡಿಯಲ್ಲಿ ಸಾಮಾನ್ಯ ಮಾರ್ಕ್ಡೌನ್ (Markdown) ದಾಖಲೆಗಳಾಗಿ ಸಂಗ್ರಹಿಸುತ್ತದೆ. ಈ ಫೈಲ್ಗಳು ನಿಮ್ಮ ರೆಪೊಸಿಟರಿ (repository) ಒಳಗಿರುವುದರಿಂದ, ಅವು ವರ್ಷನ್ ಕಂಟ್ರೋಲ್ನೊಂದಿಗೆ (version control) ಸಾಗುತ್ತವೆ. ನೀವು ಡಿಪ್ಲಾಯ್ಮೆಂಟ್ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಬದಲಾಯಿಸುವ ಪಲ್ ರಿಕ್ವೆಸ್ಟ್ (pull request) ಅನ್ನು ತೆರೆಯಬಹುದು. ಆರು ವಾರಗಳ ಹಿಂದಿನ ಸೆಕ್ಯೂರಿಟಿ ಪಾಲಿಸಿ ರೋಲ್ಬ್ಯಾಕ್ ಅನ್ನು ಡಿಫ್ (diff) ಮಾಡಬಹುದು. ಏಜೆಂಟ್ ಏನನ್ನು ತಿಳಿಯಬೇಕಿತ್ತು ಮತ್ತು ಯಾವಾಗ ಎಂಬುದನ್ನು ನೀವು ನಿಖರವಾಗಿ ಆಡಿಟ್ ಮಾಡಬಹುದು. ಒಂದು ಕೆಟ್ಟ ಡಿಪ್ಲಾಯ್ಮೆಂಟ್ ಲೈವ್ ಆದಾಗ ಅಥವಾ ಕಂಪ್ಲೈಯನ್ಸ್ ಆಡಿಟರ್ ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳಲು ಪ್ರಾರಂಭಿಸಿದಾಗ ಈ ರಿವ್ಯೂಯಬಿಲಿಟಿ (reviewability) ಬಹಳ ಮುಖ್ಯವಾಗುತ್ತದೆ.
ಇನ್ನೊಂದೆಡೆ, APX ವರ್ತಮಾನದಲ್ಲಿ ಬದುಕುತ್ತದೆ. ಇದು ನೀವು ಮತ್ತು ಮಾಡೆಲ್ ನಡುವಿನ ನಿಜವಾದ ಸಂಭಾಷಣೆಯನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ. ಇದರ ಗುರಿ ಜ್ಞಾನವನ್ನು ಆರ್ಕೈವ್ ಮಾಡುವುದಲ್ಲ, ಬದಲಾಗಿ ಅದನ್ನು ನಿಖರವಾಗಿ ಬಳಸುವುದು. APX ಸ್ಕಿಲ್ಗಳನ್ನು ಶಾಶ್ವತ ಹೊರೆಯಾಗಿ ಪರಿಗಣಿಸಿದಾಗ, ಇಡೀ ಸಿಸ್ಟಮ್ ನಿಧಾನವಾಗುತ್ತದೆ. ಕಾಂಟೆಕ್ಸ್ಟ್ ವಿಂಡೋ (context window) ತುಂಬಿಹೋಗುತ್ತದೆ. ಟೋಕನ್ ವೆಚ್ಚಗಳು ಏರುತ್ತವೆ. ಅದಕ್ಕಿಂತ ಕೆಟ್ಟದಾಗಿ, ಪ್ರಸ್ತುತ ವಿನಂತಿಗೆ ಸಂಬಂಧವಿಲ್ಲದ ಸೂಚನೆಗಳ ಮೇಲೆ ಮಾಡೆಲ್ನ ಗಮನ ಚದುರುತ್ತದೆ.
ಅದಕ್ಕಾಗಿಯೇ ಸ್ಕಿಲ್ ಬಾಡಿಗಳು (skill bodies) ಬೇಡಿಕೆಯ ಮೇರೆಗೆ (on demand) ಲೋಡ್ ಆಗುತ್ತವೆ.
ಅತಿಯಾದ ಪ್ರಾಂಪ್ಟ್ನ ನಿಜವಾದ ವೆಚ್ಚ
ಹೆಚ್ಚಿನ ತಂಡಗಳಿಗೆ ಟೋಕನ್ಗಳಿಗೆ ಹಣ ಬೇಕಾಗುತ್ತದೆ ಎಂಬುದು ತಿಳಿದಿದೆ. ಆದರೆ ಅಪ್ರಸ್ತುತ ಟೋಕನ್ಗಳು ನಿಖರತೆಯನ್ನು (accuracy) ಕುಂದಿಸುತ್ತವೆ ಎಂಬುದು ಕಡಿಮೆ ತಂಡಗಳಿಗೆ ತಿಳಿದಿದೆ.
APX ಪ್ರತಿಯೊಂದು ಹಂತದಲ್ಲೂ ಲಭ್ಯವಿರುವ ಪ್ರತಿಯೊಂದು ಸ್ಕಿಲ್ ಅನ್ನು ಸೇರಿಸಿದಾಗ, ಪ್ರಾಂಪ್ಟ್ ಗೊಂದಲಮಯವಾಗುತ್ತದೆ (noisy). ಮಾಡೆಲ್ ಒಂದೇ ಬಾರಿಗೆ ಡಿಪ್ಲಾಯ್ಮೆಂಟ್ ರನ್ಬುಕ್, ಸೆಕ್ಯೂರಿಟಿ ಗೈಡ್, API ಸ್ಟೈಲ್ ರೆಫರೆನ್ಸ್, ಟೆಸ್ಟಿಂಗ್ ಚೆಕ್ಲಿಸ್ಟ್ ಮತ್ತು ಆನ್ಬೋರ್ಡಿಂಗ್ FAQ ಎಲ್ಲವನ್ನೂ ಪಡೆಯುತ್ತದೆ. ದೊಡ್ಡ ಕಾಂಟೆಕ್ಸ್ಟ್ ವಿಂಡೋ ಇದ್ದರೂ ಸಹ, ಮಾಡೆಲ್ ಸಿಗ್ನಲ್ ಅನ್ನು ಹುಡುಕಲು ಮೊದಲು ಗೊಂದಲದ ನಡುವೆ ಹುಡುಕಬೇಕಾದಾಗ ತರ್ಕದ ಗುಣಮಟ್ಟವು (reasoning quality) ಕುಸಿಯುತ್ತದೆ. ಲೋಕಲ್ ಟೆಸ್ಟ್ ಸೆಟಪ್ ಬಗ್ಗೆ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುವಾಗ, ಅದು ಪ್ರೊಡಕ್ಷನ್ ಡಿಪ್ಲಾಯ್ಮೆಂಟ್ಗೆ ಸಂಬಂಧಿಸಿದ ಸೆಕ್ಯೂರಿಟಿ ಅಗತ್ಯವನ್ನು ಹಿಡಿದುಕೊಳ್ಳಬಹುದು. ಒಂದು ಸರಳ ಬಗ್ ಫಿಕ್ಸ್ ಮಾಡುವಾಗ ಅದು ರಿಲೀಸ್ ಚೆಕ್ಲಿಸ್ಟ್ನ ಹಂತಗಳನ್ನು ಭ್ರಮೆಯಾಗಿ (hallucinate) ತೋರಿಸಬಹುದು. ಸಂಬಂಧವಿಲ್ಲದ ಪ್ರತಿಯೊಂದು ಹೆಚ್ಚುವರಿ ಪ್ಯಾರಾಗ್ರಾಫ್ ಕೂಡ ಗಮನವನ್ನು ಬೇರೆಡೆಗೆ ಸೆಳೆಯುವ ಅಡ್ಡಿಯಾಗುತ್ತದೆ.
ಇದರ ಲೆಕ್ಕಾಚಾರ ಸರಳವಾಗಿದೆ. ಹೆಚ್ಚಿನ ಹಂತಗಳಿಗೆ ಹೆಚ್ಚಿನ ಸ್ಕಿಲ್ಗಳ ಅಗತ್ಯವಿರುವುದಿಲ್ಲ. ನೀವು ಎರರ್ ಲಾಗ್ನ (error log) ಕ್ವಿಕ್ ಫಿಕ್ಸ್ ಕೇಳುತ್ತಿದ್ದರೆ, ನಿಮಗೆ ಡಿಪ್ಲಾಯ್ಮೆಂಟ್ ರನ್ಬುಕ್ ಅಥವಾ ಸೆಕ್ಯೂರಿಟಿ ಹಾರ್ಡನಿಂಗ್ ಗೈಡ್ನ ಪೂರ್ಣ ಪಠ್ಯದ ಅಗತ್ಯವಿಲ್ಲ. ಮಾಡೆಲ್ ತಪ್ಪನ್ನು ಗುರುತಿಸಬೇಕು, ನಿಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್ ನಿಯಮಗಳನ್ನು (conventions) ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು ಮತ್ತು ಸರಿಯಾದ ಫೈಲ್ ಅನ್ನು ಎಡಿಟ್ ಮಾಡಬೇಕು ಅಷ್ಟೆ. ಅಪ್ರಸ್ತುತ ಸ್ಕಿಲ್ ಬಾಡಿಗಳನ್ನು ಲೋಡ್ ಮಾಡುವುದು ಮಾಡೆಲ್ಗೆ ಈ ಕೆಲಸ ಮಾಡಲು ಸಹಾಯ ಮಾಡುವುದಿಲ್ಲ. ಬದಲಾಗಿ, ನಿಮ್ಮ ನಿಜವಾದ ಸಮಸ್ಯೆಯ ಮೇಲೆ ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸುವ ಮೊದಲೇ ಅನಗತ್ಯ ಡೇಟಾವನ್ನು ಫಿಲ್ಟರ್ ಮಾಡಲು ಇದು ಮಾಡೆಲ್ ಅನ್ನು ಒತ್ತಾಯಿಸುತ್ತದೆ.
ಆನ್-ಡಿಮ್ಯಾಂಡ್ ಲೋಡಿಂಗ್ ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ
ಈ ಕಾರ್ಯವಿಧಾನವು ಸರಳವಾಗಿದೆ ಆದರೆ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿದೆ. APC ಮೂಲ ಸತ್ಯವನ್ನು (ground truth) ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುತ್ತದೆ. ನಿಮ್ಮ ಸ್ಕಿಲ್ ವ್ಯಾಖ್ಯಾನಗಳು ಅವುಗಳ ಸರಿಯಾದ ಸ್ಥಳದಲ್ಲಿಯೇ ಇರುತ್ತವೆ: .apc/skills/<name>.md ನಲ್ಲಿ.
APX ಆ ಫೈಲ್ಗಳನ್ನು ಆಕ್ಟಿವ್ ಮೆಮೊರಿಗೆ (active memory) ಪ್ರತಿಬಿಂಬಿಸುವುದಿಲ್ಲ. ಬದಲಾಗಿ, ಅದು ಸ್ಕಿಲ್ ಹೆಸರುಗಳ ಸಂಕ್ಷಿಪ್ತ ನೋಂದಣಿಯನ್ನು (compact registry) ಸಿದ್ಧಪಡಿಸುತ್ತದೆ. ಮಾಡೆಲ್ ಈ ಪಟ್ಟಿಯನ್ನು ನೋಡಿ ಅಲ್ಲಿ ಒಂದು ಕ್ಯಾಟಲಾಗ್ ಇದೆ ಎಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತದೆ. ಲಭ್ಯವಿರುವ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಹುಡುಕಲು ಅಥವಾ ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಅಗತ್ಯವಿದ್ದರೆ, ಅದು list_skills ಕರೆಯನ್ನು ಬಳಸಬಹುದು. ಇದು ಹೆಚ್ಚಿನ ಡೇಟಾ ಹೊರೆಯನ್ನು ನೀಡದೆ ಮಾಹಿತಿಯ ಸ್ಪಷ್ಟತೆಯನ್ನು ನೀಡುತ್ತದೆ.
ಕೆಲಸಕ್ಕೆ ನಿಖರವಾದ ಸಿಂಟ್ಯಾಕ್ಸ್ (syntax), ವಿವರವಾದ ಹಂತಗಳು ಅಥವಾ ಸ್ಕಿಲ್ ಫೈಲ್ನಲ್ಲಿ ಎನ್ಕೋಡ್ ಮಾಡಲಾದ ನಿರ್ದಿಷ್ಟ ನಿರ್ಬಂಧಗಳು ಅಗತ್ಯವಿದ್ದಾಗ, ಮಾಡೆಲ್ load_skill ಅನ್ನು ಕರೆಯುತ್ತದೆ. ಆ ಸಮಯದಲ್ಲಿ ಮಾತ್ರ, APX ಪೂರ್ಣ ಮಾರ್ಕ್ಡೌನ್ ಬಾಡಿಯನ್ನು APC ಯಿಂದ ಪಡೆದು ಕಾಂಟೆಕ್ಸ್ಟ್ಗೆ ಸೇರಿಸುತ್ತದೆ. ಸೂಚನೆಯು ತಕ್ಷಣದ ಅಗತ್ಯಕ್ಕೆ ತಕ್ಕಂತೆ ಬರುತ್ತದೆ, ಅದರ ಉದ್ದೇಶಕ್ಕಾಗಿ ಒಮ್ಮೆ ಬಳಕೆಯಾಗುತ್ತದೆ ಮತ್ತು ಸಿಸ್ಟಮ್ ಅದನ್ನು ಅನಗತ್ಯ ಹೊರೆಯಾಗಿ ಹೊತ್ತುಕೊಳ್ಳುವುದನ್ನು ತಪ್ಪಿಸುತ್ತದೆ.
ಒಂದು ಲೈಬ್ರರಿಯನ್ನು ಇಂಪೋರ್ಟ್ ಮಾಡುವುದು ಮತ್ತು ಪ್ರತಿಯೊಂದು ಫಂಕ್ಷನ್ ವ್ಯಾಖ್ಯಾನವನ್ನು ನಿಮ್ಮ ಮೇನ್ ಫೈಲ್ಗೆ ಪೇಸ್ಟ್ ಮಾಡುವುದರ ನಡುವಿನ ವ್ಯತ್ಯಾಸವನ್ನು ಯೋಚಿಸಿ. ಒಂದು ವಿಧಾನವು ನಿಮ್ಮ ಕೋಡ್ಬೇಸ್ ಅನ್ನು ಸುಲಭವಾಗಿ ಬಳಸಲು (navigable) ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ. ಇನ್ನೊಂದು ವಿಧಾನವು ಅಸ್ತವ್ಯಸ್ತತೆಯನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ, ಅದು ಕೇವಲ ಆಕಸ್ಮಿಕವಾಗಿ ಕಂ编译 (compile) ಆಗಬಹುದು.
ಸ್ಕಿಲ್ಗಳು ಸಂಘರ್ಷಕ್ಕೊಳಗಾದಾಗ ಯಾರು ಗೆಲ್ಲುತ್ತಾರೆ
APX ಸ್ಕಿಲ್ಗಳನ್ನು ಲೋಡ್ ಮಾಡುವಾಗ ಸ್ಪಷ್ಟವಾದ ಆದ್ಯತೆಯ ಕ್ರಮವನ್ನು (priority order) ಕೂಡ ಜಾರಿಗೊಳಿಸುತ್ತದೆ. ಪ್ರತಿಯೊಂದು ಪರಿಸರವೂ ಒಂದೇ ಆಗಿರುವುದಿಲ್ಲ ಮತ್ತು ಸಾಮಾನ್ಯ ಸಲಹೆಗಳು ಎಂದಿಗೂ ಸ್ಥಳೀಯ ಜ್ಞಾನವನ್ನು (local knowledge) ಮೀರಿಸಬಾರದು.
ಪ್ರಾಜೆಕ್ಟ್ ಕೌಶಲಗಳು (Project skills) ಮೊದಲ ಆದ್ಯತೆಯನ್ನು ಪಡೆಯುತ್ತವೆ. ಈ ಫೈಲ್ಗಳು ನಿಮ್ಮ ಪ್ರಸ್ತುತ ರಿಪೊಸಿಟರಿಯಲ್ಲಿ .apc/skills/ ಅಡಿಯಲ್ಲಿ ಇರುತ್ತವೆ. ಅವು ನಿಮ್ಮ ತಂಡದ ನಿರ್ದಿಷ್ಟ ನಿಯಮಗಳು, ನಿಮ್ಮ ಕಸ್ಟಮ್ ವ್ಯಾಪರ್ಗಳು, ನಿಮ್ಮ ಹಳೆಯ ಹೆಸರಿಸುವ ಮಾನದಂಡಗಳು ಮತ್ತು ನಿಮ್ಮ ವಿಶಿಷ್ಟ ಟೂಲ್ಚೈನ್ ಅನ್ನು ಒಳಗೊಂಡಿರುತ್ತವೆ. ನಿಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್ ಡೇಟಾಬೇಸ್ ಮೈಗ್ರೇಷನ್ಗಳನ್ನು ನಿರ್ವಹಿಸಲು ತನ್ನದೇ ಆದ ರೀತಿಯನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಿದ್ದರೆ, ಆ ವ್ಯಾಖ್ಯಾನವೇ ಅಂತಿಮವಾಗಿರುತ್ತದೆ.
ನಂತರ ಗ್ಲೋಬಲ್ ಕೌಶಲಗಳು (Global skills) ಬರುತ್ತವೆ. ಪ್ರಾಜೆಕ್ಟ್ ತನ್ನದೇ ಆದ ನಿಯಮಗಳನ್ನು ಹೇಳದಿದ್ದಾಗ ಅನ್ವಯವಾಗುವ ಸಂಸ್ಥೆಯಾದ್ಯಂತದ ಮಾದರಿಗಳನ್ನು ಇವು ಒಳಗೊಂಡಿರುತ್ತವೆ. ಇವು ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಲೈಬ್ರರಿಯಂತೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ.
ಬಿಲ್ಟ್-ಇನ್ ರನ್ಟೈಮ್ ಕೌಶಲಗಳು (Built-in runtime skills) ಅಂತಿಮ ಪರ್ಯಾಯವಾಗಿ (fallback) ಕೆಳಮಟ್ಟದಲ್ಲಿರುತ್ತವೆ. ಪ್ರತಿಯೊಬ್ಬ ಏಜೆಂಟ್ ಕೂಡ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕಾದ ಸಾಮಾನ್ಯ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಇವು ನಿರ್ವಹಿಸುತ್ತವೆ, ಆದರೆ ಯಾವುದೇ ನಿರ್ದಿಷ್ಟ ಪ್ರಾಜೆಕ್ಟ್ ಇವುಗಳನ್ನು ಮರು ವ್ಯಾಖ್ಯಾನಿಸಲು ಪ್ರಯತ್ನಿಸುವುದಿಲ್ಲ.
ಈ ಪದರಗಳ ವಿಧಾನವು ನಿಮ್ಮ ರಿಪೊಸಿಟರಿಯು ತನ್ನ ಸ್ವಂತ ನಡವಳಿಕೆಯ ಮೇಲೆ ನಿಯಂತ್ರಣವನ್ನು ಕಾಯ್ದುಕೊಳ್ಳುತ್ತದೆ ಎಂದರ್ಥ. ಗ್ಲೋಬಲ್ ಅಥವಾ ಬಿಲ್ಟ್-ಇನ್ ಕೌಶಲವು ನಿಮ್ಮ ತಂಡವು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಕಸ್ಟಮೈಸ್ ಮಾಡಿದ ವರ್ಕ್ಫ್ಲೋ ಅನ್ನು ಅಕಸ್ಮಾತ್ ಹೈಜಾಕ್ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ.
ಇದು ಪ್ರಾಯೋಗಿಕವಾಗಿ ಹೇಗಿರುತ್ತದೆ
ಒಂದು ಸಾಮಾನ್ಯ ನಿರ್ವಹಣಾ ಕಾರ್ಯವನ್ನು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ. ನಿಮ್ಮ ತಂಡದ ಸದಸ್ಯರು ಚಾಟ್ನಲ್ಲಿ ಒಂದು ಎರರ್ ಲಾಗ್ ಅನ್ನು ಪೇಸ್ಟ್ ಮಾಡುತ್ತಾರೆ. ಟ್ರೇಸ್ಬ್ಯಾಕ್ ಒಂದು ಯುಟಿಲಿಟಿ ಮಾಡ್ಯೂಲ್ನಲ್ಲಿರುವ ಏಕೈಕ ನಲ್ ರೆಫರೆನ್ಸ್ ಅನ್ನು ತೋರಿಸುತ್ತದೆ. ಇದಕ್ಕೆ ಪರಿಹಾರವು ಬಹುಶಃ ಎರಡು ಸಾಲುಗಳ ಡಿಫೆನ್ಸಿವ್ ಕೋಡಿಂಗ್ ಆಗಿರುತ್ತದೆ.
ಆನ್-ಡಿಮ್ಯಾಂಡ್ ಲೋಡಿಂಗ್ ಇಲ್ಲದ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ, APX ತನಗೆ ತಿಳಿದಿರುವ ಪ್ರತಿಯೊಂದು ಕೌಶಲದೊಂದಿಗೆ ಕಾನ್ಟೆಕ್ಸ್ ಅನ್ನು ತುಂಬಿಸುತ್ತದೆ. ಆ ಎರಡು ಸಾಲುಗಳನ್ನು ಸ್ಪರ್ಶಿಸುವ ಮೊದಲು ಮಾಡೆಲ್ ಈಗ ನಲವತ್ತು ಪುಟಗಳ ಪಠ್ಯವನ್ನು ಪರಿಗಣಿಸಬೇಕಾಗುತ್ತದೆ. ಅದು ರಿಲೀಸ್ ಚೆಕ್ಲಿಸ್ಟ್ ಅನ್ನು ನೋಡಿ ವರ್ಷನ್ ಅನ್ನು ಹೆಚ್ಚಿಸಬೇಕೇ ಎಂದು ಯೋಚಿಸುತ್ತದೆ. ಅದು ಸೆಕ್ಯೂರಿಟಿ ಗೈಡ್ ಅನ್ನು ನೋಡಿ, ಕೇವಲ ನಲ್ ಚೆಕ್ ಅಗತ್ಯವಿರುವ ಫಂಕ್ಷನ್ಗೆ ಇನ್ಪುಟ್ ವ್ಯಾಲಿಡೇಶನ್ ಮಾಡಬೇಕೇ ಎಂದು ಯೋಚಿಸುತ್ತದೆ. ಅದು ಡಿಪ್ಲಾಯ್ಮೆಂಟ್ ರನ್ಬುಕ್ ಅನ್ನು ನೋಡಿ ಸ್ಟೇಜಿಂಗ್ ಎನ್ವಿರಾನ್ಮೆಂಟ್ಗಳ ಬಗ್ಗೆ ಯೋಚಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಇದರಿಂದ ಮಾಡೆಲ್ ದಾರಿ ತಪ್ಪುತ್ತದೆ. ಪ್ರತಿಕ್ರಿಯೆ ನೀಡಲು ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಟೋಕನ್ ಮೀಟರ್ ವೇಗವಾಗಿ ಚಲಿಸುತ್ತದೆ.
APX ನ ಆನ್-ಡಿಮ್ಯಾಂಡ್ ವಿನ್ಯಾಸದೊಂದಿಗೆ, ಮಾಡೆಲ್ ಕೇವಲ ಹೆಸರುಗಳನ್ನು ಮಾತ್ರ ನೋಡುತ್ತದೆ. [release-checklist], [security-guide], [deployment-runbook], ಮತ್ತು [error-handling] ಅಸ್ತಿತ್ವದಲ್ಲಿವೆ ಎಂದು ಅದಕ್ಕೆ ತಿಳಿದಿದೆ. ಅದು ಮೊದಲ ಮೂರನ್ನು ನಿರ್ಲಕ್ಷಿಸುತ್ತದೆ. ನಿಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್ನ ನಲ್ ಸೇಫ್ಟಿ ನಿಯಮಗಳು ನಿರ್ದಿಷ್ಟವಾಗಿದ್ದರೆ, ಅದು [error-handling] ಅನ್ನು ಲೋಡ್ ಮಾಡಬಹುದು. ಅದು ಬಗ್ ಅನ್ನು ಸರಿಪಡಿಸುತ್ತದೆ. ಸಂಬಂಧವಿಲ್ಲದ ಕೌಶಲಗಳು ಎಂದಿಗೂ ಕಾನ್ಟೆಕ್ಸ್ ವಿಂಡೋಗೆ ಪ್ರವೇಶಿಸುವುದಿಲ್ಲ. ಪ್ರಾಂಪ್ಟ್ ಸ್ವಚ್ಛವಾಗಿರುವುದರಿಂದ ಮಾಡೆಲ್ ಗಮನ ಕೇಂದ್ರೀಕರಿಸುತ್ತದೆ.
ಕಾರ್ಯವು ನಿಜವಾಗಿಯೂ ಸಂಕೀರ್ಣವಾಗಿದ್ದಾಗಲೂ ಇದೇ ತರ್ಕ ಅನ್ವಯಿಸುತ್ತದೆ. ನೀವು ನಂತರ ಏಜೆಂಟ್ಗೆ ಪ್ರೊಡಕ್ಷನ್ ಡಿಪ್ಲಾಯ್ಮೆಂಟ್ ಸಿದ್ಧಪಡಿಸಲು ಕೇಳಿದರೆ, ಆ ಹಂತಗಳು ಅಗತ್ಯವಾದಾಗ ಅದು ಡಿಪ್ಲಾಯ್ಮೆಂಟ್ ರನ್ಬುಕ್ ಅನ್ನು ಲೋಡ್ ಮಾಡಬಹುದು, ಸೆಕ್ಯೂರಿಟಿ ಗೈಡ್ ಅನ್ನು ಪರಿಶೀಲಿಸಬಹುದು ಮತ್ತು ರಿಲೀಸ್ ಚೆಕ್ಲಿಸ್ಟ್ ಅನ್ನು ನಿಖರವಾಗಿ ಅನುಸರಿಸಬಹುದು. ಜ್ಞಾನವು ಯಾವಾಗಲೂ ಅಲ್ಲೇ ಇರುತ್ತದೆ. ಅದು ಕೇವಲ ಸರಿಯಾದ ಕ್ಷಣಕ್ಕಾಗಿ ಕಾಯುತ್ತಿರುತ್ತದೆ.
ಆರ್ಕಿಟೆಕ್ಚರ್ ಆಗಿ ಪ್ರಾಂಪ್ಟ್ ಡಿಸಿಪ್ಲಿನ್
APC ಮತ್ತು APX ನಡುವಿನ ಬೇರ್ಪಡಿಕೆಯು ಕೇವಲ ಅನುಷ್ಠಾನದ ವಿವರವಲ್ಲ. ಇದು ಪ್ರಾಂಪ್ಟ್ ಡಿಸಿಪ್ಲಿನ್ನ ತತ್ವಶಾಸ್ತ್ರವಾಗಿದೆ. APC ಜ್ಞಾನವನ್ನು ಶಾಶ್ವತವಾಗಿ ಸಂರಕ್ಷಿಸುತ್ತದೆ, ಅದನ್ನು ಪರಿಶೀಲಿಸಬಹುದಾದ, ವರ್ಷನ್ ಮಾಡಲಾದ ಮತ್ತು ಸುರಕ್ಷಿತವಾದದನ್ನಾಗಿ ಮಾಡುತ್ತದೆ. ಆ ಜ್ಞಾನದ ಎಷ್ಟು ಭಾಗವು ಈಗಿನ ಸಕ್ರಿಯ