संरचित प्रक्रियाएँ

परिचय

संरचित प्रक्रिया एक प्रक्रिया है, जो चरणों का निश्चित क्रम चलाती है। मुक्त-रूप प्रक्रिया प्राकृतिक भाषा में दिया गया मार्गदर्शन है, जिसे एजेंट समझकर स्थिति के अनुसार ढालता है। संरचित प्रक्रिया टाइप किए गए चरणों की क्रमबद्ध सूची है, जिसे प्रक्रिया लागू होने पर एजेंट हर बार क्रम से चलाता है।

संरचित प्रक्रिया का उपयोग तब करें, जब हर कॉल पर खास चरणों का एक ही तरह से होना ज़रूरी हो: कॉलर की पहचान सत्यापित करना, टिकट एस्केलेट करना या भुगतान लेना। इसे आप सरल भाषा में लिखे छोटे चरणों की सूची के रूप में तैयार करते हैं।

हर प्रक्रिया की तरह, संरचित प्रक्रिया में भी एक ट्रिगर होता है जो बताता है कि वह कब लागू होती है। जब कोई बातचीत ट्रिगर से मेल खाती है, तो एजेंट प्रक्रिया के चरणों को क्रम से चलाता है और फिर बाकी बातचीत पर लौट आता है।

संरचित प्रक्रिया का उपयोग कब करें

संरचित प्रक्रिया का उपयोग तब करें, जब खास चरणों का हर बार एक ही तरह से चलना ज़रूरी हो, लेकिन आप उसे फिर भी सरल चरणों में जल्दी तैयार करना चाहते हों। संरचित प्रक्रियाएँ वर्कफ़्लो की तुलना में लिखने में आसान हैं, लेकिन कम अभिव्यक्तिपूर्ण हैं। वे मुक्त-रूप प्रक्रियाओं, वर्कफ़्लो और सिस्टम प्रॉम्प्ट से कैसे अलग हैं, जानने के लिए प्रक्रियाओं का उपयोग कब करें देखें।

स्ट्रक्चर्ड प्रोसीजर की संरचना

एक स्ट्रक्चर्ड प्रोसीजर के तीन हिस्से होते हैं: एक नाम, एक ट्रिगर और चरणों की क्रमबद्ध सूची।

नाम

एक छोटा लेबल जो डैशबोर्ड में प्रोसीजर की पहचान करता है। नाम कभी भी LLM को नहीं भेजा जाता, इसलिए इससे एजेंट के व्यवहार पर असर नहीं पड़ता।

ट्रिगर

यह सामान्य भाषा में बताया गया विवरण है कि एजेंट को यह प्रोसीजर कब चलाना चाहिए, उदाहरण के लिए जब यूज़र किसी ऑर्डर का रिफ़ंड मांगे। एजेंट यूज़र के इरादे की तुलना हर प्रोसीजर के ट्रिगर से करता है और मेल खाने वाला प्रोसीजर चलाता है, इसलिए ट्रिगर ठोस और अलग-अलग होने चाहिए। एजेंट को सिर्फ़ ट्रिगर टेक्स्ट दिखता है, प्रोसीजर का नाम या ID नहीं। ट्रिगर किसी भी प्रोसीजर की तरह ही काम करता है; ट्रिगर लिखना देखें।

ट्रिगर खाली छोड़ने पर प्रोसीजर एक सब-प्रोसीजर बन जाता है, जो केवल तब चलता है जब कोई दूसरा प्रोसीजर उसे कॉल करता है।

चरण

प्रोसीजर का मुख्य भाग टाइप किए गए चरणों की क्रमबद्ध सूची होता है। चरणों के कई प्रकार होते हैं और आप टास्क का वर्णन करने के लिए इन्हें मिलाकर इस्तेमाल करते हैं।

हर चरण हर जगह इस्तेमाल नहीं किया जा सकता। If आर्म के अंदर आप दूसरे If या Retry को छोड़कर कोई भी चरण इस्तेमाल कर सकते हैं। Tool चरण के विफलता हैंडलर के अंदर आप If या दूसरे Tool को छोड़कर कोई भी चरण इस्तेमाल कर सकते हैं।

API चरण रेफरेंस

स्ट्रक्चर्ड प्रोसीजर का content, steps ऐरे वाले JSON-एन्कोडेड दस्तावेज़ होता है। हर चरण एक ऑब्जेक्ट है, जिसकी पहचान उसके type से होती है। ट्रिगर प्रोसीजर का अलग टॉप-लेवल फ़ील्ड है, content का हिस्सा नहीं। API और SDK पेलोड प्रोसीजर के लिए type: "deterministic" इस्तेमाल करते हैं।

Ask

Ask चरण एजेंट को जानकारी मांगने और यूज़र के उपयुक्त जवाब देने तक इंतज़ार करने का निर्देश देता है।

• API प्रकार: ask
• instruction: ज़रूरी, खाली न होने वाली स्ट्रिंग।

{
  "type": "ask",
  "instruction": "Ask the user for their order ID."
}

Tell

Tell चरण एजेंट को अपने शब्दों में एक संदेश जनरेट करने का निर्देश देता है। आगे बढ़ने से पहले यह यूज़र के जवाब का इंतज़ार नहीं करता।

• API प्रकार: tell
• instruction: ज़रूरी, खाली न होने वाली स्ट्रिंग।

{
  "type": "tell",
  "instruction": "Explain that the refund normally takes five to ten business days."
}

Say

Say चरण दिए गए टेक्स्ट को जैसा लिखा है वैसा ही बोलता है, फिर आगे बढ़ता है। एजेंट की हर अतिरिक्त समर्थित भाषा के लिए भाषा कोड के आधार पर एक सटीक संदेश देने के लिए message_translations दें।

• API प्रकार: say
• message: ज़रूरी, खाली न होने वाली स्ट्रिंग।
• message_translations: भाषा कोड को { "value": "..." } से मैप करने वाला वैकल्पिक ऑब्जेक्ट।

{
  "type": "say",
  "message": "Your refund has been submitted.",
  "message_translations": {
    "es": { "value": "Su reembolso ha sido enviado." }
  }
}

If, else if और else

If चरण में एक या अधिक क्रमबद्ध कंडीशनल आर्म होते हैं। पहला मेल खाने वाला आर्म चलता है। वैकल्पिक fallback ऐरे Else आर्म है।

• API प्रकार: branch
• branches: ज़रूरी, कंडीशनल आर्म की खाली न होने वाली सूची।
• fallback: Else चरणों की वैकल्पिक सूची।
• हर आर्म के लिए condition और खाली न होने वाली steps सूची ज़रूरी है।

{
  "type": "branch",
  "branches": [
    {
      "condition": {
        "type": "llm",
        "condition": "The user is on an annual plan."
      },
      "steps": [
        {
          "type": "say",
          "message": "Your annual plan is eligible for a prorated refund."
        }
      ]
    }
  ],
  "fallback": [
    {
      "type": "tell",
      "instruction": "Explain that the account's plan could not be determined."
    }
  ]
}

यह if/else-if/else की तरह काम करता है:

1. शर्तों का क्रम से मूल्यांकन होता है।
2. पहला मेल खाने वाला आर्म चलता है।
3. कोई शर्त मेल न खाने पर fallback चलता है।
4. आर्म पूरा होने के बाद प्रोसीजर फिर से मुख्य क्रम में जुड़ जाता है।

ऊपर का उदाहरण टेक्स्ट कंडीशन इस्तेमाल करता है, जिसका मॉडल सामान्य भाषा में मूल्यांकन करता है। कंडीशन डायनामिक वेरिएबल के एक्सप्रेशन भी हो सकती हैं:

{
  "type": "expression",
  "expression": {
    "type": "eq_operator",
    "left": {
      "type": "dynamic_variable",
      "name": "plan_tier"
    },
    "right": {
      "type": "string_literal",
      "value": "annual"
    }
  }
}

एक एक्सप्रेशन कंडीशन डायनामिक वेरिएबल की जांच करती है, जिन्हें टूल रिज़ल्ट से भरा जाता है या बातचीत शुरू होने पर सेट किया जाता है। यह यूज़र का सबसे हालिया जवाब नहीं पढ़ सकती। यूज़र की बात के आधार पर ब्रांच करने के लिए टेक्स्ट कंडीशन इस्तेमाल करें।

एक If चरण के सभी आर्म में एक ही कंडीशन प्रकार होना चाहिए: llm या expression।

Tool

Tool चरण किसी खास टूल को कॉल करता है।

• API प्रकार: tool_call
• tool_id: ज़रूरी, खाली न होने वाली टूल ID। टूल एजेंट से अटैच होना चाहिए।
• tool_name: टूल से मेल खाने वाला ज़रूरी टूल नाम।
• instruction: टूल को कॉल करने का तरीका बताने वाला वैकल्पिक निर्देश।
• schema_overrides: टूल के पैरामीटर के लिए वैकल्पिक तय वैल्यू।
• on_failure: वैकल्पिक विफलता हैंडलर।

{
  "type": "tool_call",
  "tool_id": "tool_abc123",
  "tool_name": "lookup_order",
  "instruction": "Look up the order using the order ID provided by the user."
}

तय पैरामीटर वैल्यू

जब किसी पैरामीटर की वैल्यू हमेशा एक खास होनी चाहिए, तब schema_overrides इस्तेमाल करें। मॉडल ओवरराइड किए गए पैरामीटर को नहीं देखता और न ही चुनता है। की टूल के स्कीमा में पैरामीटर पाथ होती हैं; हर वैल्यू एक स्रोत बताती है:

{
  "type": "tool_call",
  "tool_id": "tool_abc123",
  "tool_name": "update_ticket",
  "schema_overrides": {
    "request_body.status": { "source": "constant", "constant_value": "pending" },
    "request_body.ticket_id": { "source": "dynamic_variable", "dynamic_variable": "ticket_id" }
  }
}

विफलता हैंडलिंग

on_failure के बिना, विफल टूल कॉल बातचीत समाप्त कर देता है। इसके बजाय रिकवरी चरण चलाने के लिए on_failure जोड़ें।

• fallback: टूल विफल होने पर चलने वाले चरणों की ज़रूरी, खाली न होने वाली सूची।
• branches: कंडीशनल विफलता हैंडलिंग के लिए आरक्षित। इसे खाली छोड़ें।

{
  "type": "tool_call",
  "tool_id": "tool_abc123",
  "tool_name": "lookup_order",
  "on_failure": {
    "branches": [],
    "fallback": [
      {
        "type": "tell",
        "instruction": "Explain that the order could not be retrieved and offer to connect the user with support."
      }
    ]
  }
}

विफलता हैंडलर में Ask, Tell, Say, Sub-procedure, System tool और Retry चरण हो सकते हैं। इसमें Tool या If चरण नहीं हो सकते। हैंडलर चलने के बाद प्रोसीजर Tool चरण के बाद वाले चरण के साथ जारी रहता है।

Retry

Retry चरण उस विफलता हैंडलर को फिर से चलाता है जिसमें वह मौजूद है, जिसमें टूल कॉल भी शामिल है। हर प्रयास टूल को फिर से कॉल करता है और, अगर वह फिर विफल हो जाता है, तो हैंडलर के हर चरण को फिर से चलाता है। प्रयास समाप्त होने पर बातचीत खत्म हो जाती है।

• API प्रकार: retry
• max_retries: 1 से 3 तक का वैकल्पिक पूर्णांक। डिफ़ॉल्ट 1 है।
• वैल्यू मूल टूल कॉल के बाद के प्रयासों की गिनती करती है।
• Retry सिर्फ़ on_failure के अंदर मान्य है।
• Retry अपने विफलता हैंडलर का अंतिम चरण होना चाहिए, क्योंकि बाद के चरण पहुंच से बाहर होंगे।

{
  "type": "retry",
  "max_retries": 2
}

Sub-procedure

Sub-procedure चरण दूसरा स्ट्रक्चर्ड प्रोसीजर चलाता है। उस प्रोसीजर के चरण पूरे होने पर निष्पादन Sub-procedure चरण के बाद वाले चरण पर लौटता है।

• API प्रकार: sub_procedure
• procedure_id: ज़रूरी, खाली न होने वाली प्रोसीजर ID।
• टारगेट उसी एजेंट पर मौजूद होना चाहिए।
• टारगेट स्ट्रक्चर्ड प्रोसीजर होना चाहिए।
• कोई प्रोसीजर खुद को कॉल नहीं कर सकता।

{
  "type": "sub_procedure",
  "procedure_id": "agtprc_6qbpwdq8n01bxhk44bgjy6f10ck3"
}

System tool

System tool चरण बिल्ट-इन सिस्टम कार्रवाई करता है।

• API प्रकार: system_tool
• system_tool_name: ज़रूरी सिस्टम-टूल नाम।
• फ़िलहाल सिर्फ़ end_call समर्थित है। बाद में और सिस्टम टूल जोड़े जा सकते हैं।
• क्योंकि end_call अंतिम है, यह अपने कंटेनिंग क्रम, आर्म या विफलता हैंडलर का अंतिम चरण होना चाहिए।

{
  "type": "system_tool",
  "system_tool_name": "end_call"
}

वैलिडेशन नियम

एजेंट को पब्लिश करने या एजेंट ड्राफ़्ट सेव करने पर, इनमें से किसी भी नियम को तोड़ने वाला स्ट्रक्चर्ड प्रोसीजर अस्वीकार हो जाता है। त्रुटि उसके पाथ से समस्या वाले चरण का नाम बताती है।

• दो If चरण एक के बाद एक नहीं रखे जा सकते।
• If चरण नेस्ट नहीं किए जा सकते।
• एक्सप्रेशन कंडीशन वाला If चरण सीधे Ask चरण के बाद नहीं हो सकता।
• एक If चरण की सभी कंडीशन एक ही प्रकार की होनी चाहिए: llm या expression।
• Retry सिर्फ़ on_failure के अंदर हो सकता है और वहीं का आखिरी चरण होना चाहिए।
• end_call जिस भी सूची में हो, उसका आखिरी चरण होना चाहिए।
• विफलता हैंडलर के fallback में कम से कम एक चरण होना चाहिए।
• Sub-procedure को उसी एजेंट के किसी मौजूदा स्ट्रक्चर्ड प्रोसीजर की ओर पॉइंट करना चाहिए, खुद की ओर नहीं।
• tool_id एजेंट का टूल होना चाहिए, tool_name मेल खाना चाहिए और schema_overrides टूल के स्कीमा से मेल खाना चाहिए।
• steps सूची, हर instruction और हर message खाली नहीं होने चाहिए।

इनमें से कोई नियम लागू होने पर प्रोसीजर को फिर से व्यवस्थित करने का तरीका जानने के लिए सर्वोत्तम तरीके देखें।

पूरा API उदाहरण

यह उदाहरण शिपमेंट स्टेटस के आधार पर ऑर्डर रद्द करना संभालता है। यह एक टूल पैरामीटर तय करता है, विफल टूल कॉल से रिकवर करता है, दूसरे स्ट्रक्चर्ड प्रोसीजर को कॉल करता है और फिर कॉल समाप्त करता है।

{
  "steps": [
    {
      "type": "ask",
      "instruction": "Ask the user for their order ID."
    },
    {
      "type": "branch",
      "branches": [
        {
          "condition": {
            "type": "llm",
            "condition": "The user says the order has already shipped."
          },
          "steps": [
            {
              "type": "tell",
              "instruction": "Explain that shipped orders must be returned before they can be refunded."
            }
          ]
        },
        {
          "condition": {
            "type": "llm",
            "condition": "The user says the order has not shipped."
          },
          "steps": [
            {
              "type": "tool_call",
              "tool_id": "tool_abc123",
              "tool_name": "cancel_order",
              "instruction": "Cancel the order using the order ID provided by the user.",
              "schema_overrides": {
                "request_body.notify_customer": { "source": "constant", "constant_value": true }
              },
              "on_failure": {
                "branches": [],
                "fallback": [
                  {
                    "type": "tell",
                    "instruction": "Apologize that the cancellation did not go through and say you will try once more."
                  },
                  {
                    "type": "retry",
                    "max_retries": 1
                  }
                ]
              }
            }
          ]
        }
      ],
      "fallback": [
        {
          "type": "ask",
          "instruction": "Ask whether the order has already shipped."
        }
      ]
    },
    {
      "type": "sub_procedure",
      "procedure_id": "agtprc_6qbpwdq8n01bxhk44bgjy6f10ck3"
    },
    {
      "type": "say",
      "message": "Thank you for contacting us. Goodbye.",
      "message_translations": {
        "es": { "value": "Gracias por contactarnos. Adiós." }
      }
    },
    {
      "type": "system_tool",
      "system_tool_name": "end_call"
    }
  ]
}

स्ट्रक्चर्ड प्रोसीजर कैसे चलता है

स्ट्रक्चर्ड प्रोसीजर के चरणों को एजेंट द्वारा निष्पादित किए जाने वाले रूप में बदलने को कंपाइल करना कहते हैं। जब आप पब्लिश करते हैं, तो प्लेटफ़ॉर्म हर स्ट्रक्चर्ड प्रोसीजर को कंपाइल करता है; आपको खुद कुछ कंपाइल नहीं करना होता। कंपाइल किया गया परिणाम फ़िलहाल Workflow टैब में सिर्फ़ पढ़ने योग्य नोड्स के रूप में दिखता है।

जब यूज़र का अनुरोध किसी प्रोसीजर के ट्रिगर से मेल खाता है, तो एजेंट उस प्रोसीजर में प्रवेश करता है और उसके चरण क्रम से चलाता है। स्ट्रक्चर्ड प्रोसीजर के अंदर एजेंट हर चरण पर अलग से ध्यान देता है। अंत तक पहुंचने पर यह बाकी बातचीत में लौट आता है।

नीचे दिए गए नियम बताते हैं कि रनटाइम पर चरण कैसे काम करते हैं।

स्ट्रक्चर्ड प्रोसीजर मैनेज करें

सर्वोत्तम तरीके

हर स्टेप टाइप पहले से अपना व्यवहार लागू करता है, इसलिए आपको शायद ही इसे अलग से बताने की ज़रूरत पड़ती है। हर स्टेप का उद्देश्य लिखें और बाकी काम स्टेप टाइप पर छोड़ दें। नीचे दिए गए निर्देश उन मामलों के लिए हैं जिन्हें सही रखना ज़रूरी है।

किसी स्ट्रक्चर्ड प्रोसिजर को टेस्ट करने के लिए, प्रोसिजर को बेहतर बनाना देखें।

स्टेप टाइप चुनना

प्रोसिजर की संरचना बनाना

टूल्स के साथ काम करना

निर्देश लिखना

प्रोसिजर को संयोजित करना

प्रोसिजर को संयोजित करने के सामान्य निर्देश स्ट्रक्चर्ड प्रोसिजर पर भी लागू होते हैं; फ्री-फॉर्म प्रोसिजर पेज पर प्रोसिजर को संयोजित करना देखें।

एक पैटर्न खास तौर पर टाइप्स को मिलाने के लिए है: फ्री-फॉर्म प्रोसिजर किसी स्ट्रक्चर्ड प्रोसिजर को रेफ़र कर सकता है। खुले तौर पर संभालने वाले काम फ्री-फॉर्म प्रोसिजर में रखें और वे हिस्से जिन्हें हर बार एक ही तरीके से चलना चाहिए, जैसे पहचान की पुष्टि या एस्केलेशन, स्ट्रक्चर्ड प्रोसिजर को सौंपें।

सीमाएं

• If स्टेप्स को नेस्ट नहीं किया जा सकता और दो If स्टेप्स को एक के बाद एक नहीं रखा जा सकता।
• केवल end_call सिस्टम टूल समर्थित है।
• स्ट्रक्चर्ड प्रोसिजर नॉलेज बेस डॉक्यूमेंट्स को रेफ़र नहीं कर सकते।
• प्रोसिजर पूरा होने पर मौजूदा टर्न खत्म करने का कोई तरीका नहीं है; एजेंट टर्न खुला रखता है और बोलना जारी रख सकता है।
• डैशबोर्ड में किसी खास वर्कफ़्लो नोड से स्ट्रक्चर्ड प्रोसिजर शुरू नहीं किया जा सकता।
• प्रोसिजर शुरू करने से लेटेंसी बढ़ती है: एजेंट इसमें प्रवेश करने के लिए टूल कॉल करता है और फिर जनरेटेड वर्कफ़्लो से आगे बढ़ता है।

मॉडल प्रोवाइडर सपोर्ट

स्ट्रक्चर्ड प्रोसिजर सब-प्रोसिजर में प्रवेश करते समय और प्रोसिजर पूरा करते समय इंटरनल टूल कॉल्स को फ़ोर्स करते हैं। प्रमुख OpenAI, Anthropic, Gemini और Grok मॉडल फैमिलीज़ फ़ोर्स्ड टूल चॉइस को सपोर्ट करती हैं। अन्य मॉडल या कस्टम प्रोवाइडर इसकी गारंटी नहीं दे सकते, जिससे सब-प्रोसिजर ट्रांज़िशन या प्रोसिजर पूरा होना कम भरोसेमंद हो सकता है। किसी दूसरे मॉडल प्रोवाइडर का इस्तेमाल करते समय फ़ोर्स्ड टूल-चॉइस सपोर्ट की पुष्टि करें।

कंटेंट साइज़ सीमा और स्ट्रक्चर्ड प्रोसिजर फ्री-फॉर्म प्रोसिजर से कैसे अलग हैं, सहित सभी प्रोसिजर पर लागू सीमाओं के लिए प्रोसिजर देखें।