ಸಂಭಾಷಣಾ AI ಏಜೆಂಟ್ ಒಳಗಿನಿಂದ ಹೇಗೆ ಕಾರ್ಯ ಮಾಡುತ್ತದೆ

ಸಂವಾದಾತ್ಮಕ AI ಏಜೆಂಟ್ ಒಳಗಿನಿಂದ ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ (OpenClaw ಆರ್ಕಿಟೆಕ್ಚರ್)

ಸಂವಾದಾತ್ಮಕ AI ಏಜೆಂಟ್ ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಪ್ರಾಯೋಗಿಕವಾಗಿ, ಟರ್ನ್‌ನಿಂದ ಟರ್ನ್‌ಗೆ? ಈ ಪೋಸ್ಟ್ OpenClaw ನ ಬ್ಲ್ಯಾಕ್ ಬಾಕ್ಸ್ ಅನ್ನು ತೆರೆಯುತ್ತದೆ: ಗ್ರಾಹಕರ ಸಂದೇಶ WhatsApp ನಲ್ಲಿ ಬಂದ ಕ್ಷಣದಿಂದ ಏಜೆಂಟ್ ಹಿಂದೆ ಬರೆಯುವ ಪಠ್ಯದವರೆಗೆ. ಇದು ತಾಂತ್ರಿಕವಾಗಿರುತ್ತದೆ. ನೀವು ಉತ್ಪನ್ನ ಆರ್ಕಿಟೆಕ್ಚರ್ ನಿರ್ಧರಿಸುತ್ತಿದ್ದರೆ, ಪರಿಹಾರವನ್ನು ಖರೀದಿಸಲು ಹೋಗುತ್ತಿದ್ದು ಆಳವಾಗಿ ಮೌಲ್ಯಮಾಪನ ಮಾಡಲು ಬಯಸಿದರೆ, ಅಥವಾ ಸಂಭಾಷಣೆಯ ಹಿಂದೆ ಏನು ನಡೆಯುತ್ತಿದೆ ಎಂದು ತಿಳಿಯಲು ಆಸಕ್ತಿ ಹೊಂದಿದ್ದರೆ ಇದು ಯೋಗ್ಯವಾಗಿದೆ.

TL;DR: ಪ್ರತಿ ಟರ್ನ್ 6 ಹಂತಗಳ ಮೂಲಕ ಹಾದುಹೋಗುತ್ತದೆ — ingest, ಸಂದರ್ಭ ಪರಿಹಾರ, skills ಆಯ್ಕೆ, ಮುಂದಿನ ಕ್ರಿಯೆ ನಿರ್ಧಾರ, guard-rails ನೊಂದಿಗೆ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆ, ಮೆಮೊರಿ ಸಂರಕ್ಷಣೆ. ಸಂಪೂರ್ಣ ಚಕ್ರ Cloudflare ನ edge ನಲ್ಲಿ <2 ಸೆಕೆಂಡುಗಳಲ್ಲಿ ಚಲಿಸುತ್ತದೆ, ಸ್ಥಿರ ಸರ್ವರ್ ಇಲ್ಲದೆ.

---

ಆರ್ಕಿಟೆಕ್ಚರ್ ಏಕೆ ಮುಖ್ಯ

ಡೆಮೊದಲ್ಲಿ ಕೆಲಸ ಮಾಡುವಂತೆ ಕಾಣುವ ಆದರೆ ಪ್ರೊಡಕ್ಷನ್‌ನಲ್ಲಿ ಮುರಿಯುವ ಸಂವಾದಾತ್ಮಕ ಏಜೆಂಟ್ ಸಾಮಾನ್ಯವಾಗಿ ಈ 4 ಸಮಸ್ಯೆಗಳಲ್ಲಿ ಒಂದನ್ನು ಹೊಂದಿರುತ್ತದೆ:

1. ಹೆಚ್ಚಿನ ಲೇಟೆನ್ಸಿ — ಗ್ರಾಹಕ ಪ್ರತಿಕ್ರಿಯೆಗಾಗಿ 8 ಸೆಕೆಂಡು ಕಾಯುತ್ತಾರೆ, ಸಂಭಾಷಣೆ ಸಾಯುತ್ತದೆ.
2. ನಿಯಂತ್ರಿಸದ ಭ್ರಮೆ — ಏಜೆಂಟ್ ಬೆಲೆ, ಸಮಯ, ನೀತಿಯನ್ನು ಕಲ್ಪಿಸಿಕೊಳ್ಳುತ್ತದೆ.
3. ಕಳೆದುಹೋದ ಸಂದರ್ಭ — ಗ್ರಾಹಕ 2 ದಿನಗಳ ನಂತರ ಹಿಂತಿರುಗುತ್ತಾರೆ ಮತ್ತು ಏಜೆಂಟ್ ಎಲ್ಲವನ್ನೂ "ಮರೆತುಬಿಡುತ್ತದೆ".
4. ನಿಯಂತ್ರಣವಿಲ್ಲದ ವೆಚ್ಚ — ಪ್ರತಿ ದೀರ್ಘ ಸಂಭಾಷಣೆ ಪ್ರಾಂಪ್ಟ್ ಅನ್ನು ತುಂಬುತ್ತದೆ ಮತ್ತು ನೀವು ಟೋಕನ್‌ಗಳಿಗೆ ಭಾರಿ ಹಣ ಕೊಡುತ್ತೀರಿ.

4 ಸಮಸ್ಯೆಗಳೂ ಆರ್ಕಿಟೆಕ್ಚರ್ ಆಯ್ಕೆಗಳು, ಮಾಡೆಲ್‌ನ ಮಿತಿಗಳಲ್ಲ. OpenClaw ಈ 4 ಅನ್ನು ತಪ್ಪಿಸಲು ನಿರ್ಮಿಸಲಾಗಿದೆ — ಮತ್ತು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವ ಮಾರ್ಗವೆಂದರೆ ಒಂದು ಟರ್ನ್‌ನ ಚಕ್ರವನ್ನು ನೋಡುವುದು.

---

ಒಂದು ಟರ್ನ್‌ನ ಚಕ್ರ (6 ಹಂತಗಳು)

ಗ್

• ಇತ್ತೀಚಿನ ಇತಿಹಾಸ ಸಂಭಾಷಣೆಯ (ಕೊನೆಯ N ಸಂಬಂಧಿತ ಟರ್ನ್‌ಗಳು).
• ದೀರ್ಘಾವಧಿ ಮೆಮೊರಿ ಗ್ರಾಹಕರ (ಆದ್ಯತೆಗಳು, ಖರೀದಿ ಇತಿಹಾಸ, ಟಿಪ್ಪಣಿಗಳು).
• ಏಜೆಂಟ್ ಸ್ಥಿತಿ (ಪರ್ಸೋನಾ, ಸಕ್ರಿಯಗೊಳಿಸಿದ skills, ನಿಯಮಗಳು).

ಎಲ್ಲವೂ D1 ನಿಂದ ಬರುತ್ತವೆ (Cloudflare ನ ವಿತರಿತ SQLite). D1 ಸಾಂಪ್ರದಾಯಿಕ Postgres/Mongo ಅನ್ನು ಬದಲಿಸುತ್ತದೆ — ನಿರ್ವಹಿಸಲು ಡೇಟಾಬೇಸ್ ಸರ್ವರ್ ಇಲ್ಲ, worker ನಿಂದ ಕೆಲವು ms ನಲ್ಲಿ ಪ್ರವೇಶ, tenant_id ಮೂಲಕ multi-tenant.

ಪ್ರಮುಖ ಅಂಶ: ನಾವು ಸಂಪೂರ್ಣ ಸಂಭಾಷಣೆಯನ್ನು prompt ನಲ್ಲಿ ಲೋಡ್ ಮಾಡುವುದಿಲ್ಲ. OpenClaw ನ Memory Manager v2 (ನಮ್ಮ ಆಂತರಿಕ ದಾಖಲೆಗಳಲ್ಲಿ ವಿವರಿಸಲಾಗಿದೆ) ಪ್ರಸ್ತುತ ಟರ್ನ್‌ಗೆ ಸಂಬಂಧಿತ ಟರ್ನ್‌ಗಳನ್ನು ಮಾತ್ರ ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ (ಕೊನೆಯ N + ಹೆಚ್ಚಿನ ಶಬ್ದಾರ್ಥ ಸಂಬಂಧವಿರುವ N). ಇದು 100+ ಟರ್ನ್‌ಗಳ ಸಂಭಾಷಣೆಗಳಲ್ಲಿಯೂ ಟೋಕನ್ ವೆಚ್ಚವನ್ನು ಊಹಿಸಬಹುದಾದಂತೆ ಇಡುತ್ತದೆ.

ಹಂತ 3 — Skills ಆಯ್ಕೆ (policy engine, ~20ms)

ಪ್ರತಿ ಏಜೆಂಟ್‌ಗೆ ಲಭ್ಯವಿರುವ skills ಗಳ ಒಂದು ಗುಂಪಿದೆ — ಅವನು ಕರೆಯಬಹುದಾದ ಕಾರ್ಯಗಳು. ಉದಾಹರಣೆಗಳು: consultar_calendario, criar_evento, gerar_link_pagamento, consultar_pedido, chamar_humano.

"ನಾನು ಶನಿವಾರ ಬೆಳಿಗ್ಗೆ ಬುಕ್ ಮಾಡಲು ಬಯಸುತ್ತೇನೆ" ಎಂಬ ಸಂದೇಶವನ್ನು ನೀಡಿದಾಗ, policy engine ಫಿಲ್ಟರ್ ಮಾಡುತ್ತದೆ:

• ಪತ್ತೆಯಾದ ಉದ್ದೇಶಕ್ಕೆ (ಶೆಡ್ಯೂಲಿಂಗ್) ಹೊಂದಿಕೆಯಾಗುವ Skills.
• ಸಂಭಾಷಣೆಯ ಈ ಹಂತಕ್ಕೆ ಅನುಮತಿಸಲಾದ Skills (ಪ್ರತಿ skill ಎಲ್ಲಾ ಸಮಯದಲ್ಲೂ ಲಭ್ಯವಿರುವುದಿಲ್ಲ).
• ಈ tenant ಸಕ್ರಿಯಗೊಳಿಸಿದ Skills (tenant ಸಂಯೋಜಿಸಿದ್ದರೆ ಮಾತ್ರ calendar ಕಾಣಿಸುತ್ತದೆ).

ಕೊನೆಯಲ್ಲಿ ನಿಮಗೆ ಮಾಡೆಲ್‌ಗೆ ರವಾನಿಸಲಾದ skills ನ ಒಂದು ಸಣ್ಣ ಉಪಗುಂಪು ಸಿಗುತ್ತದೆ — ಸಾಧ್ಯವಿರುವ 50 ಅಲ್ಲ, ಇಲ್ಲಿ ಅರ್ಥವಾಗುವ 4 ಮಾತ್ರ. ಇದು ಮಾಡೆಲ್ ತಪ್ಪು skill ಅನ್ನು ಕರೆಯುವ ಸಾಧ್ಯತೆಯನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.

ಹಂತ 4 — ನಿರ್ಧಾರ (LLM call, 400-1200ms)

ಈಗ ಮಾಡೆಲ್ ಪ್ರವೇಶಿಸುತ್ತದೆ. OpenClaw ಒಂದು ಫ್ರಾಂಟಿಯರ್ LLM ಗೆ (Anthropic Claude, OpenAI GPT, Google Gemini — tenant ಪ್ರಕಾರ ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು) ಒಂದೇ ಕರೆ ಮಾಡುತ್ತದೆ:

• System prompt = ಏಜೆಂಟ್‌ನ ಪರ್ಸೋನಾ + ನಿಯಮಗಳು + ಲಭ್ಯವಿರುವ skills.
• History = ಹಂತ 2 ರಲ್ಲಿ ಆಯ್ಕೆ ಮಾಡಿದ ಟರ್ನ್‌ಗಳು.
• User message = ಪ್ರಸ್ತುತ ಟರ್ನ್‌

1. ಪ್ಯಾರಾಮೀಟರ್‌ಗಳನ್ನು ಮಾನ್ಯೀಕರಿಸುತ್ತದೆ (date_range ಸರಿಯಾದ ಫಾರ್ಮ್ಯಾಟ್‌ನಲ್ಲಿದೆಯೇ? ಟೆನೆಂಟ್‌ನ ನಿಯಮಗಳ ಒಳಗಿದೆಯೇ?).
2. ಅನುಮತಿಯನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ (ಈ ಏಜೆಂಟ್‌ಗೆ ಈ ಕ್ಯಾಲೆಂಡರ್ ಅನ್ನು ಪ್ರಶ್ನಿಸುವ ಹಕ್ಕಿದೆಯೇ?).
3. ಕರೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ (ಈ ಸಂದರ್ಭದಲ್ಲಿ Google Calendar API).
4. ರಚನಾತ್ಮಕ ಫಲಿತಾಂಶವನ್ನು ಮಾಡೆಲ್‌ಗೆ ಹಿಂತಿರುಗಿಸುತ್ತದೆ.

ಇದು ಏಕೆ ಮುಖ್ಯ? ಏಕೆಂದರೆ ಮಾಡೆಲ್ ಎಂದಿಗೂ ಫಲಿತಾಂಶವನ್ನು ಕಲ್ಪಿಸುವುದಿಲ್ಲ. ಕ್ಯಾಲೆಂಡರ್ [10h, 11h] ಹಿಂತಿರುಗಿಸಿದರೆ, ಅದು ನಿಖರವಾಗಿ ಮುಂದಿನ ಕರೆಗೆ ಹೋಗುತ್ತದೆ. ಸ್ಕಿಲ್ ವಿಫಲವಾದರೆ, ಮಾಡೆಲ್‌ಗೆ ಅದು ವಿಫಲವಾಯಿತೆಂದು ತಿಳಿಯುತ್ತದೆ. ಏಜೆಂಟ್ 9 ಗಂಟೆಗೆ ಸಮಯವಿದೆ ಎಂದು "ಕಲ್ಪಿಸಿಕೊಳ್ಳುವ" ಅಪಾಯ ಶೂನ್ಯ, ಆದರೆ ನಿಜವಾಗಿ ಇಲ್ಲದಿರುವಾಗ.

ಸೂಕ್ಷ್ಮ ಮಾಹಿತಿಯನ್ನು ಒಳಗೊಂಡ ಸಂದರ್ಭಗಳಲ್ಲಿ (ಬೆಲೆ, ಗಡುವು, ಗ್ರಾಹಕರ ಹೆಸರು), ಪೈಪ್‌ಲೈನ್ tool call ಅನ್ನು ಒತ್ತಾಯಿಸುತ್ತದೆ — ಮಾಡೆಲ್ ತನ್ನ ಸ್ವಂತ "ಜ್ಞಾನ"ದಿಂದ ಉತ್ತರಿಸಲು ಬಿಡುವುದಿಲ್ಲ. ಇದು ವಾಣಿಜ್ಯ ಏಜೆಂಟ್‌ಗಳಲ್ಲಿ ಅತ್ಯಂತ ಸಾಮಾನ್ಯವಾದ ಭ್ರಮೆಯ ವರ್ಗವನ್ನು ನಿವಾರಿಸುತ್ತದೆ.

ಹಂತ 6 — ಪ್ರತಿಕ್ರಿಯೆ ಮತ್ತು ಶಾಶ್ವತ ಸಂಗ್ರಹಣೆ (~50ms)

ಸ್ಕಿಲ್‌ನ ಫಲಿತಾಂಶ ಕೈಯಲ್ಲಿರುವಾಗ, ಮಾಡೆಲ್ ಎರಡನೇ ಕರೆಯನ್ನು ಮಾಡುತ್ತದೆ — ಈಗ ಗ್ರಾಹಕರಿಗೆ ಅಂತಿಮ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ರೂಪಿಸಲು. ಉದಾ:

"ಶನಿವಾರ 10 ಗಂಟೆ ಮತ್ತು 11 ಗಂಟೆಗೆ ಲಭ್ಯವಿದೆ. ಯಾವುದನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತೀರಿ?"

ಸಮಾನಾಂತರವಾಗಿ, ವರ್ಕರ್:

1. WhatsApp API ಮೂಲಕ ಸಂದೇಶವನ್ನು ಹಿಂದಕ್ಕೆ ಕಳುಹಿಸುತ್ತದೆ.
2. ಸಂಪೂರ್ಣ ಟರ್ನ್ ಅನ್ನು (user + assistant + tool calls + ಅವಧಿ) D1 ನಲ್ಲಿ ಶಾಶ್ವತವಾಗಿ ಸಂಗ್ರಹಿಸುತ್ತದೆ.
3. ಟರ್ನ್ ಹೊಸ ಸಂಗತಿಯನ್ನು ಉತ್ಪಾದಿಸಿದರೆ ದೀರ್ಘಾವಧಿ ಸ್ಮರಣೆಯನ್ನು ನವೀಕರಿಸುತ್ತದೆ (ಉದಾ: "ಗ್ರಾಹಕರು ಶನಿವಾರವನ್ನು ಆದ್ಯತೆ ನೀಡುತ್ತಾರೆ").
4. ಅವಲೋಕನ ಈವೆಂಟ್ ಅನ್ನು ಹೊರಸೂಸುತ್ತದೆ (ವಿಳಂಬ ಮೆಟ್ರಿಕ್, ಟೋಕನ್ ವೆಚ್ಚ, ಎಸ್ಕಲೇಶನ್ ದರ).

ಇವೆಲ್ಲವೂ ಸಮಾನಾಂತರವಾಗಿ ಚಲಿಸುತ್ತವೆ. ಶಾಶ್ವತ ಸಂಗ್ರಹಣೆಯು ಸಂದೇಶ

ಉತ್ತಮ ಆರ್ಕಿಟೆಕ್ಚರ್ ನೀವು ಬಿಲ್ ನೋಡುವವರೆಗೆ ಅದೃಶ್ಯವಾಗಿರುತ್ತದೆ. ಪ್ರತಿ ಟರ್ನ್ 1-2 LLM ಕರೆಗಳು + D1 ಲುಕಪ್‌ಗಳನ್ನು ಮಾಡುತ್ತದೆ ಎಂದು ಪರಿಗಣಿಸಿದರೆ, ಸಂಪೂರ್ಣ ಸಂಭಾಷಣೆಗೆ (10-15 ಟರ್ನ್‌ಗಳು) ವಿಶಿಷ್ಟ ವೆಚ್ಚ ಇಷ್ಟಿರುತ್ತದೆ: