ਕਨਵਰਸੇਸ਼ਨਲ AI ਏਜੰਟ ਅੰਦਰ ਤੋਂ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ
OpenClaw ਵਿੱਚ ਗੱਲਬਾਤ ਦੇ 6 ਪੜਾਅ — ਅਸਲ ਲੇਟੈਂਸੀ, ਗੱਲਬਾਤ ਪ্ਰਤੀ ਲਾਗਤ ਅਤੇ ਭ੍ਰਮ ਦੇ ਵਿਰੁੱਧ 4 ਰੱਖਿਆ ਲਾਈਨਾਂ।
Equipe OpenClaw · Time de Engenharia & Produto
A Equipe OpenClaw é formada por engenheiros, designers e especialistas em IA dedicados a construir a melhor plataforma de agentes conversacionais para negócios brasileiros. Combinamos expertise…
ਇੱਕ ਕਥਾਤਮਕ AI ਏਜੰਟ ਅੰਦਰ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ (OpenClaw ਆਰਕੀਟੈਕਚਰ)
ਇੱਕ ਕਥਾਤਮਕ AI ਏਜੰਟ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ ਅਮਲ ਵਿੱਚ, ਮੋੜ ਦਰ ਮੋੜ? ਇਹ ਪੋਸਟ OpenClaw ਦੇ ਕਾਲੇ ਡੱਬੇ ਨੂੰ ਖੋਲ੍ਹਦੀ ਹੈ: ਜਿਸ ਪਲ ਗ੍ਰਾਹਕ ਦਾ ਸੁਨੇਹਾ WhatsApp 'ਤੇ ਆਉਂਦਾ ਹੈ ਤੋਂ ਲੈ ਕੇ ਜਿਸ ਪਾਠ ਨੂੰ ਏਜੰਟ ਵਾਪਸ ਲਿਖਦਾ ਹੈ। ਇਹ ਤਕਨੀਕੀ ਹੋਵੇਗਾ। ਇਹ ਕੀਮਤੀ ਹੈ ਜੇ ਤੁਸੀਂ ਉਤਪਾਦ ਆਰਕੀਟੈਕਚਰ ਦਾ ਫੈਸਲਾ ਕਰਦੇ ਹੋ, ਜੇ ਤੁਸੀਂ ਇੱਕ ਹੱਲ ਖਰੀਦਣ ਜਾ ਰਹੇ ਹੋ ਅਤੇ ਡੂੰਘਾਈ ਦਾ ਮੁਲਾਂਕਣ ਕਰਨਾ ਚਾਹਦੇ ਹੋ, ਜਾਂ ਜੇ ਤੁਸੀਂ ਜਾਣਨਾ ਪਸੰਦ ਕਰਦੇ ਹੋ ਕਿ ਗੱਲਬਾਤ ਦੇ ਪਿੱਛੇ ਕੀ ਹੋ ਰਿਹਾ ਹੈ।
TL;DR: ਹਰ ਮੋੜ 6 ਪੜਾਵਾਂ ਵਿੱਚੋਂ ਲੰਘਦਾ ਹੈ — ingest, ਸੰਦਰਭ ਹੱਲ ਕਰੋ, skills ਚੁਣੋ, ਅਗਲੀ ਕਾਰਵਾਈ ਦਾ ਫੈਸਲਾ ਕਰੋ, guard-rails ਨਾਲ ਚਲਾਓ, ਮੈਮੋਰੀ ਨੂੰ ਸਥਿਰ ਕਰੋ। ਪੂਰਾ ਚੱਕਰ Cloudflare ਦੇ edge 'ਤੇ <2 ਸਕਿੰਟਾਂ ਵਿੱਚ ਚਲਦਾ ਹੈ, ਕੋਈ ਸਥਿਰ ਸਰਵਰ ਨਹੀਂ।
ਆਰਕੀਟੈਕਚਰ ਕਿਉਂ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ
ਕਥਾਤਮਕ ਏਜੰਟ ਜੋ ਡੈਮੋ ਵਿੱਚ ਕੰਮ ਕਰਦਾ ਜਾਪਦਾ ਹੈ ਪਰ ਉਤਪਾਦਨ ਵਿੱਚ ਟੁੱਟ ਜਾਂਦਾ ਹੈ ਆਮ ਤੌਰ 'ਤੇ ਇਹਨਾਂ 4 ਸਮੱਸਿਆਵਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ:
- ਉੱਚ ਲੇਟੈਂਸੀ — ਗ੍ਰਾਹਕ ਜਵਾਬ ਲਈ 8 ਸਕਿੰਟ ਉਡੀਕ ਕਰਦਾ ਹੈ, ਗੱਲਬਾਤ ਮਰ ਜਾਂਦੀ ਹੈ।
- ਅਨਿਯੰਤ੍ਰਿਤ ਭ੍ਰਮ — ਏਜੰਟ ਕੀਮਤ, ਸਮਾਂ, ਨੀਤੀ ਦਾ ਆਭਾਸ ਕਰਦਾ ਹੈ।
- ਸੰਦਰਭ ਗੁਆ ਗਿਆ — ਗ੍ਰਾਹਕ 2 ਦਿਨ ਬਾਅਦ ਵਾਪਸ ਆਉਂਦਾ ਹੈ ਅਤੇ ਏਜੰਟ "ਭੁੱਲ" ਜਾਂਦਾ ਹੈ।
- ਅਨਿਯੰਤ੍ਰਿਤ ਲਾਗਤ — ਹਰ ਲੰਬੀ ਗੱਲਬਾਤ prompt ਨੂੰ ਭਰਦੀ ਹੈ ਅਤੇ ਤੁਸੀਂ token 'ਤੇ ਭਾਗ ਦਾ ਭੁਗਤਾਨ ਕਰਦੇ ਹੋ।
ਇਹ 4 ਆਰਕੀਟੈਕਚਰ ਦੀਆਂ ਚੋਣਾਂ ਹਨ, ਮਾਡਲ ਦੀਆਂ ਸੀਮਾਵਾਂ ਨਹੀਂ। OpenClaw ਨੂੰ ਇਹਨਾਂ 4 ਨੂੰ ਰੋਕਣ ਲਈ ਬਣਾਇਆ ਗਿਆ ਸੀ — ਅਤੇ ਸਮਝਣ ਦਾ ਰਸਤਾ ਇੱਕ ਮੋੜ ਦੇ ਚੱਕਰ ਨੂੰ ਦੇਖਣਾ ਹੈ।
ਇੱਕ ਮੋੜ ਦਾ ਚੱਕਰ (6 ਪੜਾਅ)
ਕਲਪਨਾ ਕਰੋ ਕਿ ਗ੍ਰਾਹਕ ਨੇ ਹੁਣੇ ਸੁਨੇਹਾ ਭੇਜਿਆ "ਮੈਂ ਸ਼ਨਿਵਾਰ ਸਵੇਰੇ ਲਈ ਬੁੱਕ ਕਰਨਾ ਚਾਹਦਾ ਹਾਂ". "received" ਅਤੇ ਏਜੰਟ ਦੇ ਜਵਾਬ ਦੇ ਵਿਚਕਾਰ ਕੀ ਹੁੰਦਾ ਹੈ?
ਪੜਾਅ 1 — Ingest (edge worker, <50ms)
WhatsApp ਦਾ ਸੁਨੇਹਾ Meta ਦੇ webhook ਰਾਹੀਂ ਸਿੱਧਾ ਇੱਕ Cloudflare Worker ਵਿੱਚ ਆਉਂਦਾ ਹੈ ਭੌਗੋਲਿਕ ਤੌਰ 'ਤੇ ਸਭ ਤੋਂ ਨਜ਼ਦੀਕੀ ਮੌਜੂਦਗੀ ਬਿੰਦੂ (PoP) ਵਿੱਚ। ਭਾਰਤ ਵਿੱਚ, ਇਸਦਾ ਮਤਲਬ ਦਿੱਲੀ ਜਾਂ ਮੁੰਬਈ, ਨੈਟਵਰਕ ਲੇਟੈਂਸੀ < 20ms।
worker ਤਿੰਨ ਚੀਜ਼ਾਂ ਕਰਦਾ ਹੈ:
- webhook ਦੇ ਹਸਤਾਖਰ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ (HMAC WABA ਸਕ੍ਰੀਟ ਦੇ ਵਿਰੁੱਧ)।
- tenant ਦੀ ਪਛਾਣ ਕਰੋ ਰਿਸੀਵਰ ਦੇ ਫੋਨ ਨੰਬਰ ਦੁਆਰਾ (multi-tenant
to_numberਦੁਆਰਾ)। - normalize ਕਰੋ payload — ਆਡੀਓ ਟ੍ਰਾਂਸਕ੍ਰਿਪਸ਼ਨ ਬਣ ਜਾਂਦਾ ਹੈ, ਚਿੱਤਰ ਵਰਣਨ ਬਣ ਜਾਂਦਾ ਹੈ, ਸਥਾਨ
{lat,lng}ਬਣ ਜਾਂਦਾ ਹੈ, ਪਾਠ ਜਿਵੇਂ ਹੈ।
ਪੜਾਅ 1 ਦੇ ਅੰਤ ਵਿੱਚ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਆਬਜੈਕਟ {tenant_id, conversation_id, user_message} ਹੈ ਅਗਲੇ ਪੜਾਅ ਲਈ ਤਿਆਰ।
ਪੜਾਅ 2 — ਸੰਦਰਭ ਹੱਲ ਕਰੋ (D1 + KV, ~80ms)
ਏਜੰਟ ਨੂੰ ਫੈਸਲਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ 3 ਸੰਦਰਭ ਦੇ ਟੁਕੜਿਆਂ ਦੀ ਲੋੜ ਹੈ:
- ਤਾਜ਼ਾ ਇਤਿਹਾਸ ਗੱਲਬਾਤ ਦਾ (ਆਖਰੀ N ਪ্রাসঙ্গিক ਮੋੜ)।
- ਲੰਬੇ ਸਮੇਂ ਦੀ ਯਾਦ ਗ੍ਰਾਹਕ ਦੀ (ਪਸੰਦਾਂ, ਖਰੀਦ ਦਾ ਇਤਿਹਾਸ, ਨੋਟਸ)।
- ਏਜੰਟ ਦੀ ਸਥਿਤੀ (ਪਰਸੋਨਾ, ਸਮਰੱਥ ਹੋਈਆਂ ਸਕਿਲਾਂ, ਨਿਯਮ)।
ਸਭ D1 ਤੋਂ ਆਉਂਦੇ ਹਨ (Cloudflare ਦਾ ਵਿਤਰਿਤ SQLite)। D1 ਰਵਾਇਤੀ Postgres/Mongo ਨੂੰ ਬਦਲਦਾ ਹੈ — ਕੋਈ ਡਾਟਾਬੇਸ ਸਰਵਰ ਨਹੀਂ ਰੱਖਣਾ, ਵਰਕਰ ਤੋਂ ਕੁਝ ms ਵਿੱਚ ਪਹੁੰਚ, tenant_id ਦੁਆਰਾ ਮਲਟੀ-ਟੈਨੈਂਟ।
ਮੁੱਖ ਨੁਕਤਾ: ਅਸੀਂ ਪੂਰੀ ਗੱਲਬਾਤ ਪ੍ਰੋਂਪਟ ਵਿੱਚ ਲੋਡ ਨਹੀਂ ਕਰਦੇ। OpenClaw ਦਾ Memory Manager v2 (ਸਾਡੇ ਅੰਦਰੂਨੀ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਵਰਣਿਤ) ਸਿਰਫ ਮੌਜੂਦਾ ਮੋੜ ਲਈ ਪ੍ਰਾਸਙ্গਿਕ ਮੋੜ ਚੁਣਦਾ ਹੈ (ਆਖਰੀ N + ਉੱਚ ਸਿਮੈਂਟਿਕ ਪ੍ਰਾਸਙ্ਗਿਕਤਾ ਦੇ N)। ਇਹ 100+ ਮੋੜਾਂ ਦੀ ਗੱਲਬਾਤ ਵਿੱਚ ਵੀ ਟੋਕਨ ਲਾਗਤ ਨੂੰ ਅਨੁਮਾਨਯੋਗ ਰੱਖਦਾ ਹੈ।
ਪੜਾਅ 3 — ਸਕਿਲਾਂ ਦੀ ਚੋਣ (ਨੀਤੀ ਇੰਜਣ, ~20ms)
ਹਰੇਕ ਏਜੰਟ ਕੋਲ ਸਕਿਲਾਂ ਦਾ ਇੱਕ ਸੈੱਟ ਹੈ — ਫੰਕਸ਼ਨ ਜੋ ਉਹ ਸੱਦ ਸਕਦਾ ਹੈ। ਉਦਾਹਰਣਾਂ: consultar_calendario, criar_evento, gerar_link_pagamento, consultar_pedido, chamar_humano।
ਸੁਨੇਹੇ "quero marcar pra sábado de manhã" ਦਿੱਤਾ, ਨੀਤੀ ਇੰਜਣ ਫਿਲਟਰ ਕਰਦਾ ਹੈ:
- ਖੋਜੇ ਗਏ ਇਰਾਦੇ ਨਾਲ ਅਨੁਕੂਲ ਸਕਿਲਾਂ (ਸਮਾਰੋਹ)।
- ਗੱਲਬਾਤ ਦੇ ਇਸ ਪੜਾਅ ਲਈ ਅਨੁਮਤ ਸਕਿਲਾਂ (ਹਰ ਸਕਿਲ ਹਮੇਸ਼ਾ ਉਪਲਬਧ ਨਹੀਂ)।
- ਸਕਿਲਾਂ ਜੋ ਇਸ ਟੈਨੈਂਟ ਨੇ ਸਮਰੱਥ ਕੀਤੀਆਂ (ਕੈਲੰਡਰ ਸਿਰਫ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ ਜੇ ਟੈਨੈਂਟ ਨੇ ਏਕੀਕ੍ਰਿਤ ਕੀਤਾ)।
ਅੰਤ ਵਿੱਚ ਤੁਹਾਡੇ ਕੋਲ ਮਾਡਲ ਨੂੰ ਪਾਸ ਕੀਤੀਆਂ ਸਕਿਲਾਂ ਦਾ ਇੱਕ ਛੋਟਾ ਸਬਸੈੱਟ ਹੈ — 50 ਸੰਭਾਵਿਤ ਵਿੱਚੋਂ ਨਹੀਂ, ਸਿਰਫ 4 ਜੋ ਇੱਥੇ ਅਰਥ ਰੱਖਦੇ ਹਨ। ਇਹ ਮਾਡਲ ਦੁਆਰਾ ਗਲਤ ਸਕਿਲ ਸੱਦਣ ਦੀ ਸੰਭਾਵਨਾ ਨੂੰ ਬਹੁਤ ਘਟਾਉਂਦਾ ਹੈ।
ਪੜਾਅ 4 — ਫੈਸਲਾ (LLM ਕਾਲ, 400-1200ms)
ਹੁਣ ਮਾਡਲ ਦਾਖਲ ਹੁੰਦਾ ਹੈ। OpenClaw ਇੱਕ ਸੀਮਾ LLM ਨੂੰ ਇੱਕ ਸਿੰਗਲ ਕਾਲ ਕਰਦਾ ਹੈ (Anthropic Claude, OpenAI GPT, Google Gemini — ਟੈਨੈਂਟ ਦੁਆਰਾ ਕੌਨਫਿਗਰਯੋਗ) ਨਾਲ:
- ਸਿਸਟਮ ਪ੍ਰੋਂਪਟ = ਏਜੰਟ ਦਾ ਪਰਸੋਨਾ + ਨਿਯਮ + ਉਪਲਬਧ ਸਕਿਲਾਂ।
- ਇਤਿਹਾਸ = ਪੜਾਅ 2 ਵਿੱਚ ਚੁਣੇ ਮੋੜ।
- ਯੂਜ਼ਰ ਸੁਨੇਹਾ = ਮੌਜੂਦਾ ਮੋੜ ਦਾ ਸੁਨੇਹਾ।
ਮਾਡਲ ਦੋ ਚੀਜ਼ਾਂ ਵਿੱਚੋਂ ਇੱਕ ਜਵਾਬ ਦਿੰਦਾ ਹੈ:
- ਅੰਤਿਮ ਜਵਾਬ (ਗ੍ਰਾਹਕ ਨੂੰ ਸਿੱਧਾ ਟੈਕਸਟ)।
- ਟੂਲ ਕਾਲ (ਇੱਕ ਖਾਸ ਸਕਿਲ ਨੂੰ ਪੈਰਾਮੀਟਰਾਂ ਨਾਲ ਚਲਾਉਣ ਦੀ ਬੇਨਤੀ)।
ਉਦਾਹਰਣ "quero marcar pra sábado de manhã" ਵਿੱਚ, ਮਾਡਲ ਆਮ ਤੌਰ ਤੇ ਵਾਪਸ ਕਰਦਾ ਹੈ:
{
"tool": "consultar_calendario",
"args": { "date_range": "2026-04-19 06:00 to 12:00" }
}
ਪੜਾਅ 5 — ਗਾਰਡ-ਰੇਲਾਂ ਨਾਲ ਐਕਸੀਕਿਊਸ਼ਨ (ਵੇਰੀਏਬਲ, ~100-500ms)
ਸਕਿਲ ਮਾਡਲ ਵਿੱਚ ਨਹੀਂ ਚਲਦੀ। ਇਹ ਸਾਡੇ ਕੋਡ ਵਿੱਚ ਚਲਦੀ ਹੈ, ਜੋ:
- ਪੈਰਾਮੀਟਰਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ (ਕੀ date_range ਦਾ ਫਾਰਮੈਟ ਸਹੀ ਹੈ? ਕੀ ਇਹ ਟੇਨੈਂਟ ਦੇ ਨਿਯਮਾਂ ਦੇ ਅੰਦਰ ਹੈ?).
- ਅਨੁਮਤੀ ਦੀ ਜਾਂਚ ਕਰੋ (ਕੀ ਇਸ ਏਜੰਟ ਨੂੰ ਇਸ ਕੈਲੰਡਰ ਨੂੰ ਪੁੱਛਣ ਦਾ ਅਧਿਕਾਰ ਹੈ?).
- ਕਾਲ ਨੂੰ ਚਲਾਓ (ਇਸ ਸਥਿਤੀ ਵਿੱਚ Google Calendar API).
- ਸੰਰਚਿਤ ਨਤੀਜਾ ਵਾਪਸ ਕਰੋ ਮਾਡਲ ਨੂੰ।
ਇਹ ਕਿਉਂ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ? ਕਿਉਂਕਿ ਮਾਡਲ ਕਦੇ ਨਤੀਜਾ ਨਹੀਂ ਬਣਾਉਂਦਾ। ਜੇ ਕੈਲੰਡਰ [10h, 11h] ਵਾਪਸ ਕਰੇ, ਤਾਂ ਇਹ ਬਿਲਕੁਲ ਉਹੀ ਹੈ ਜੋ ਅਗਲੀ ਕਾਲ ਵਿੱਚ ਜਾਂਦਾ ਹੈ। ਜੇ ਸਕਿਲ ਅਸਫਲ ਹੋ ਜਾਵੇ, ਤਾਂ ਮਾਡਲ ਜਾਣਦਾ ਹੈ ਕਿ ਇਹ ਅਸਫਲ ਹੋ ਗਿਆ। ਏਜੰਟ ਦੇ "ਸੋਚਣ" ਦਾ ਜ਼ੀਰੋ ਜੋਖਮ ਕਿ 9 ਵਜੇ ਸਮਾਂ ਹੈ ਜਦੋਂ ਇਹ ਨਹੀਂ ਹੈ।
ਉਹ ਮਾਮਲਿਆਂ ਲਈ ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਸੰਵੇਦਨਸ਼ੀਲ ਜਾਣਕਾਰੀ ਸ਼ਾਮਲ ਹੈ (ਕੀਮਤ, ਸਮਾਂ ਸੀਮਾ, ਗ੍ਰਾਹਕ ਦਾ ਨਾਮ), ਪਾਈਪਲਾਈਨ tool call ਨੂੰ ਮਜਬੂਰ ਕਰਦੀ ਹੈ — ਮਾਡਲ ਨੂੰ ਆਪਣੀ "ਜਾਣਕਾਰੀ" ਤੋਂ ਜਵਾਬ ਦੇਣ ਨਹੀਂ ਦਿੰਦੀ। ਇਹ ਭ੍ਰਮ ਦੀ ਸਭ ਤੋਂ ਆਮ ਸ਼੍ਰੇਣੀ ਨੂੰ ਖਤਮ ਕਰਦਾ ਹੈ ਵਪਾਰਕ ਏਜੰਟਾਂ ਵਿੱਚ।
ਪੜਾਅ 6 — ਜਵਾਬ ਅਤੇ ਸਥਿਰਤਾ (~50ms)
ਸਕਿਲ ਦੇ ਨਤੀਜੇ ਦੇ ਨਾਲ, ਮਾਡਲ ਦੂਸਰੀ ਕਾਲ ਕਰਦਾ ਹੈ — ਹੁਣ ਗ੍ਰਾਹਕ ਲਈ ਅੰਤਿਮ ਜਵਾਬ ਬਣਾਉਣ ਲਈ। ਉਦਾ:
"ਮੇਰੇ ਕੋਲ ਸ਼ਨੀਵਾਰ ਨੂੰ 10 ਵਜੇ ਅਤੇ 11 ਵਜੇ ਹਨ। ਤੁਸੀਂ ਕਿਹੜਾ ਪਸੰਦ ਕਰਦੇ ਹੋ?"
ਸਮਾਨਾਂਤਰ ਵਿੱਚ, ਵਰਕਰ:
- ਭੇਜੋ ਸੁਨੇਹਾ WhatsApp API ਦੁਆਰਾ ਵਾਪਸ।
- ਸਥਿਰ ਕਰੋ ਪੂਰੀ ਵਾਰੀ (ਉਪਭੋਗਤਾ + ਸਹਾਇਕ + ਟੂਲ ਕਾਲ + ਮਿਆਦ) D1 ਵਿੱਚ।
- ਲੰਬੀ ਮਿਆਦ ਦੀ ਯਾਦ ਨੂੰ ਅਪਡੇਟ ਕਰੋ ਜੇ ਵਾਰੀ ਨਵੀਂ ਤੱਥ ਪੈਦਾ ਕਰੇ (ਉਦਾ: "ਗ੍ਰਾਹਕ ਸ਼ਨੀਵਾਰ ਨੂੰ ਪਸੰਦ ਕਰਦਾ ਹੈ").
- ਨਿਰੀਖਣ ਘਟਨਾ ਜਾਰੀ ਕਰੋ (ਲੇਟੈਂਸੀ ਮੈਟ੍ਰਿਕ, ਟੋਕਨ ਲਾਗਤ, ਸਕੇਲਿੰਗ ਦਰ)।
ਸਭ ਕੁਝ ਸਮਾਨਾਂਤਰ ਵਿੱਚ ਚਲਦਾ ਹੈ। ਸਥਿਰਤਾ ਸੁਨੇਹੇ ਦੀ ਭੇਜਣ ਨੂੰ ਰੋਕਦੀ ਨਹੀਂ — ਗ੍ਰਾਹਕ D1 ਦਾ ਇੰਤਜ਼ਾਰ ਨਹੀਂ ਕਰਦਾ।
ਭ੍ਰਮ ਦੇ ਵਿਰੁੱਧ ਰੱਖਿਆ ਕਿੱਥੇ ਹੈ
ਏਜੰਟ ਜੋ ਉਤਪਾਦਨ ਵਿੱਚ ਭ੍ਰਮ ਕਰਦਾ ਹੈ ਤੇਜ਼ੀ ਨਾਲ ਵਿਸ਼ਵਾਸ ਗੁਆ ਦਿੰਦਾ ਹੈ। OpenClaw ਕੋਲ 4 ਰੱਖਿਆ ਦੀਆਂ ਲਾਈਨਾਂ ਹਨ:
- ਸਰੋਤ-ਦੀ-ਸੱਚਾਈ ਮਜਬੂਰ। ਤੱਥਾਤਮਕ ਡੇਟਾ (ਕੀਮਤ, ਸਮਾਂ, ਨਾਮ) ਹਮੇਸ਼ਾ ਸਕਿਲ ਤੋਂ ਆਉਂਦਾ ਹੈ, ਕਦੇ ਮਾਡਲ ਤੋਂ ਇਕੱਲੇ ਨਹੀਂ।
- ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਵਿੱਚ ਦੁਹਰੀ ਜਾਂਚ। ਅਨੁਸੂਚੀ ਗ੍ਰਾਹਕ ਨਾਲ ਸਥਿਰ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪੁਸ਼ਟੀ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਭੁਗਤਾਨ ਪ੍ਰਵੇਸ਼ ਜਾਰੀ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪੁਸ਼ਟੀ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
- ਸਪਸ਼ਟ ਨਕਾਰਾਤਮਕ ਨਿਯਮ। ਹਰੇਕ ਏਜੰਟ ਦਾ ਪਰਸੋਨਾ "ਕਦੇ X, Y, Z ਨੂੰ ਸੋਚਣਾ ਨਹੀਂ" ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ — ਮਾਡਲ ਪਾਲਣਾ ਕਰਦਾ ਹੈ।
- ਮਨੁੱਖ ਲਈ ਫਾਲਬੈਕ। ਜਦੋਂ ਕੋਈ ਸਕਿਲ ਸਵਾਲ ਨੂੰ ਕਵਰ ਨਹੀਂ ਕਰਦਾ, ਏਜੰਟ
"ਮੈਨੂੰ ਟੀਮ ਨਾਲ ਚੈਕ ਕਰਨ ਦਿਓ"ਕਹਿੰਦਾ ਹੈ ਅਤੇ ਟਿਕਟ ਖੋਲ੍ਹਦਾ ਹੈ — ਅੰਦਾਜ਼ਾ ਨਹੀਂ ਲਗਾਉਂਦਾ।
ਆਡਿਟ ਵਿੱਚ ਜੋ ਅਸੀਂ ਪਿਛਲੇ 6 ਮਹੀਨਿਆਂ ਵਿੱਚ ਕੀਤੇ ਹਨ (ਅਸਲ ਗੱਲਬਾਤ ਹੱਥ ਨਾਲ ਦੁਬਾਰਾ ਦੇਖੀ ਗਈ), ਤੱਥਾਤਮਕ ਭ੍ਰਮ ਦੀ ਦਰ 0.3% ਵਾਰੀ ਤੋਂ ਘੱਟ ਰਹੀ — ਅਤੇ ਲਗਭਗ ਸਾਰੇ ਮਾਮਲੇ ਕੌਨਫਿਗ ਦੁਆਰਾ ਸਨ (ਟੇਨੈਂਟ ਪ੍ਰਾਸੰਗਿਕ ਸਕਿਲ ਨੂੰ ਸਮਰਥ ਕਰਨਾ ਭੁੱਲ ਗਿਆ), ਮਾਡਲ ਦੀ ਗਲਤੀ ਨਹੀਂ।
ਗੱਲਬਾਤ ਪ੍ਰਤੀ ਲਾਗਤ
ਚੰਗੀ ਆਰਕੀਟੈਕਚਰ ਅਦਿੱਖ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਬਿਲ ਨੂੰ ਨਹੀਂ ਦੇਖਦੇ। ਇਸ ਲਈ ਕਿ ਹਰੇਕ ਮੋੜ 1-2 LLM ਕਾਲ + D1 ਵਿੱਚ ਖੋਜ ਕਰਦਾ ਹੈ, ਪੂਰੀ ਗੱਲਬਾਤ (10-15 ਮੋੜ) ਲਈ ਆਮ ਖਰਚ ਇਸ ਵਿੱਚ ਆਉਂਦਾ ਹੈ:
Equipe OpenClaw
ਪ੍ਰਕਾਸ਼ਿਤ ਤਾਰੀਖ 2026 M06 3
