ਇੱਕ ਸੰਵਾਦਾਤਮਕ AI ਏਜੰਟ ਅੰਦਰੋਂ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ

ਇੱਕ ਸੰਵਾਦਾਤਮਕ AI ਏਜੰਟ ਅੰਦਰੋਂ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ (OpenClaw ਆਰਕੀਟੈਕਚਰ)

ਇੱਕ ਸੰਵਾਦਾਤਮਕ AI ਏਜੰਟ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ ਅਮਲੀ ਤੌਰ 'ਤੇ, ਟਰਨ ਦਰ ਟਰਨ? ਇਹ ਪੋਸਟ OpenClaw ਦਾ ਬਲੈਕ ਬਾਕਸ ਖੋਲ੍ਹਦੀ ਹੈ: ਜਦੋਂ ਗਾਹਕ ਦਾ ਸੁਨੇਹਾ WhatsApp 'ਤੇ ਆਉਂਦਾ ਹੈ ਉਸ ਪਲ ਤੋਂ ਲੈ ਕੇ ਉਸ ਟੈਕਸਟ ਤੱਕ ਜੋ ਏਜੰਟ ਵਾਪਸ ਲਿਖਦਾ ਹੈ। ਇਹ ਤਕਨੀਕੀ ਹੋਵੇਗਾ। ਇਹ ਉਦੋਂ ਫਾਇਦੇਮੰਦ ਹੈ ਜੇਕਰ ਤੁਸੀਂ ਪ੍ਰੋਡਕਟ ਆਰਕੀਟੈਕਚਰ ਦੇ ਫੈਸਲੇ ਲੈਂਦੇ ਹੋ, ਜੇਕਰ ਤੁਸੀਂ ਕੋਈ ਹੱਲ ਖਰੀਦਣ ਜਾ ਰਹੇ ਹੋ ਅਤੇ ਡੂੰਘਾਈ ਨਾਲ ਮੁਲਾਂਕਣ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਜਾਂ ਜੇਕਰ ਤੁਹਾਨੂੰ ਗੱਲਬਾਤ ਦੇ ਪਿੱਛੇ ਕੀ ਹੋ ਰਿਹਾ ਹੈ ਇਹ ਜਾਣਨ ਦਾ ਸ਼ੌਕ ਹੈ।

TL;DR: ਹਰ ਟਰਨ 6 ਪੜਾਵਾਂ ਵਿੱਚੋਂ ਲੰਘਦਾ ਹੈ — ingest, ਸੰਦਰਭ ਹੱਲ ਕਰੋ, skills ਚੁਣੋ, ਅਗਲੀ ਕਾਰਵਾਈ ਦਾ ਫੈਸਲਾ ਕਰੋ, guard-rails ਨਾਲ ਚਲਾਓ, ਮੈਮੋਰੀ ਸੁਰੱਖਿਅਤ ਕਰੋ। ਪੂਰਾ ਚੱਕਰ Cloudflare ਦੀ edge 'ਤੇ <2 ਸਕਿੰਟਾਂ ਵਿੱਚ ਚੱਲਦਾ ਹੈ, ਬਿਨਾਂ ਕਿਸੇ ਸਥਿਰ ਸਰਵਰ ਦੇ।

---

ਆਰਕੀਟੈਕਚਰ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ

ਸੰਵਾਦਾਤਮਕ ਏਜੰਟ ਜੋ ਡੈਮੋ ਵਿੱਚ ਕੰਮ ਕਰਦਾ ਦਿਖਦਾ ਹੈ ਪਰ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਟੁੱਟ ਜਾਂਦਾ ਹੈ, ਆਮ ਤੌਰ 'ਤੇ ਇਹਨਾਂ 4 ਸਮੱਸਿਆਵਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੁੰਦੀ ਹੈ:

1. ਉੱਚ ਲੇਟੈਂਸੀ — ਗਾਹਕ ਜਵਾਬ ਲਈ 8 ਸਕਿੰਟ ਉਡੀਕਦਾ ਹੈ, ਗੱਲਬਾਤ ਮਰ ਜਾਂਦੀ ਹੈ।
2. ਬੇਕਾਬੂ ਹੈਲੂਸੀਨੇਸ਼ਨ — ਏਜੰਟ ਕੀਮਤ, ਸਮਾਂ, ਨੀਤੀ ਘੜ ਲੈਂਦਾ ਹੈ।
3. ਗੁਆਚਿਆ ਸੰਦਰਭ — ਗਾਹਕ 2 ਦਿਨਾਂ ਬਾਅਦ ਵਾਪਸ ਆਉਂਦਾ ਹੈ ਅਤੇ ਏਜੰਟ ਸਭ ਕੁਝ "ਭੁੱਲ" ਜਾਂਦਾ ਹੈ।
4. ਬੇਕਾਬੂ ਲਾਗਤ — ਹਰ ਲੰਬੀ ਗੱਲਬਾਤ ਪ੍ਰੌਂਪਟ ਭਰ ਦਿੰਦੀ ਹੈ ਅਤੇ ਤੁਸੀਂ ਟੋਕਨ 'ਤੇ ਬਹੁਤ ਖਰਚ ਕਰਦੇ ਹੋ।

ਇਹ ਚਾਰੇ ਆਰਕੀਟੈਕਚਰ ਦੀਆਂ ਚੋਣਾਂ ਹਨ, ਮਾਡਲ ਦੀਆਂ ਸੀਮਾਵਾਂ ਨਹੀਂ। OpenClaw ਇਹਨਾਂ ਚਾਰਾਂ ਤੋਂ ਬਚਣ ਲਈ ਬਣਾਇਆ ਗਿਆ ਸੀ — ਅਤੇ ਸਮਝਣ ਦਾ ਰਾਹ ਇੱਕ ਟਰਨ ਦੇ ਚੱਕਰ ਨੂੰ ਦੇਖਣਾ ਹੈ।

---

ਇੱਕ

• ਗੱਲਬਾਤ ਦਾ ਤਾਜ਼ਾ ਇਤਿਹਾਸ (ਆਖਰੀ 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।

ਸੁਨੇਹਾ "quero marcar pra sábado de manhã" ਮਿਲਣ 'ਤੇ, policy engine ਫਿਲਟਰ ਕਰਦਾ ਹੈ:

• ਪਛਾਣੇ ਗਏ ਇਰਾਦੇ (ਸਮਾਂ-ਸੂਚੀ) ਨਾਲ ਮੇਲ ਖਾਂਦੀਆਂ Skills।
• ਗੱਲਬਾਤ ਦੇ ਇਸ ਪੜਾਅ ਲਈ ਮਨਜ਼ੂਰ Skills (ਹਰ skill ਹਰ ਸਮੇਂ ਉਪਲਬਧ ਨਹੀਂ ਹੁੰਦੀ)।
• ਉਹ Skills ਜੋ ਇਸ tenant ਨੇ ਸਮਰੱਥ ਕੀਤੀਆਂ ਹਨ (calendar ਸਿਰਫ਼ ਉਦੋਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ ਜਦੋਂ tenant ਨੇ ਇੰਟੀਗ੍ਰੇਟ ਕੀਤਾ ਹੋਵੇ)।

ਅੰਤ ਵਿੱਚ ਤੁਹਾਡੇ ਕੋਲ skills ਦਾ ਇੱਕ ਛੋਟਾ ਉਪ-ਸਮੂਹ ਹੁੰਦਾ ਹੈ ਜੋ ਮਾਡਲ ਨੂੰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ — 50 ਸੰਭਾਵਿਤ ਨਹੀਂ, ਸਿਰਫ਼ ਉਹ 4 ਜੋ ਇੱਥੇ ਅਰਥ ਰੱਖਦੀਆਂ ਹਨ। ਇਹ ਮਾਡਲ ਵੱਲੋਂ ਗਲਤ skill ਚਲਾਉਣ ਦੀ ਸੰਭਾਵਨਾ ਨੂੰ ਬਹੁਤ ਘਟਾ ਦਿੰਦਾ ਹੈ।

ਪੜਾਅ 4 — ਫੈਸਲਾ (LLM call, 400-1200ms)

ਹੁਣ ਮਾਡਲ ਕੰਮ ਕਰਦਾ ਹੈ। OpenClaw ਇੱਕ ਫਰੰਟੀਅਰ LLM (Anthropic Claude, OpenAI GPT, Google Gemini — tenant ਅਨੁਸਾਰ ਸੰਰਚਨਾਯੋਗ) ਨੂੰ ਇੱਕ ਸਿੰਗਲ ਕਾਲ ਕਰਦਾ ਹੈ ਜਿਸ ਵਿੱਚ:

• System prompt = ਏਜੰਟ ਦੀ ਪਰਸੋਨਾ + ਨਿਯਮ + ਉਪਲਬਧ skills।
• History = ਪੜਾਅ 2 ਵਿੱਚ ਚੁਣੇ ਗਏ ਟ

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 ਵਿੱਚ lookups ਕਰਦਾ ਹੈ, ਇੱਕ ਪੂਰੀ ਗੱਲਬਾਤ (10-15 ਟਰਨ) ਦੀ ਆਮ ਲਾਗਤ ਇਹ ਹੁੰਦੀ ਹੈ: