Tool Calling, मानव अनुमोदन और Execution Limits के साथ LangGraph Customer Support Agent बनाएं

Design decision: agent को खोजने दें, लेकिन refund को अंतिम रूप देने नहीं

एक support agent को purchase details जुटाने और matching records खोजने की अनुमति होनी चाहिए, लेकिन उसे अपने-आप refund जारी करने की अनुमति नहीं होनी चाहिए। LangGraph में इस अंतर को workflow में व्यक्त किया जा सकता है: अनुरोध को route करें, आवश्यकता होने पर read-only lookup tools कॉल करें, फिर refund operation से पहले pause करें ताकि कोई व्यक्ति उसे approve या reject कर सके।

यह tutorial customer-support triage के आधार पर इस pattern को बनाता है। इसमें orchestration के लिए LangGraph, lookup के लिए tool-calling chat model, consequential node से पहले human checkpoint और graph execution को सीमित करने के लिए recursion limit का उपयोग किया गया है। यह code अपनाने के लिए एक pattern है, tested OneMux integration नहीं।

इस article के लिए उपलब्ध कराए गए LangSmith tutorial में अलग-अलग lookup और refund subgraphs वाला digital music-store support bot बनाया गया है। इसमें customer और purchase details निकालने, missing information पूछने और final responses, tool trajectories तथा individual steps का evaluation करने का वर्णन है। इसके refund example में database deletion का उपयोग किया गया है और authentication तथा अन्य production security measures को स्पष्ट रूप से छोड़ दिया गया है। उस demo के destructive behavior को live support system में copy न करें। LangSmith का complex-agent evaluation tutorial पढ़ें।

Prerequisites और सीमाएं

LangGraph और अपने चुने हुए model provider के लिए संबंधित LangChain integration install करें। Source tutorial में langgraph और langchain[openai] का उपयोग किया गया है, लेकिन नीचे दिया गया example जानबूझकर model initialization को provider-specific छोड़ता है। आपको read-only purchase lookup और ऐसा refund operation देने वाले database या service की भी आवश्यकता है, जिसे आपका application नियंत्रित करता हो।

Model कनेक्ट करने से पहले तय करें कि प्रत्येक tool क्या कर सकता है:

• Lookup: केवल वे records लौटाए, जिन्हें authenticated customer देखने के लिए अधिकृत है।
• Refund preparation: exact transaction और amount की पहचान करे; records में बदलाव न करे।
• Refund execution: authorization और audit logging के साथ approved action को application code में execute करे।

Customer authentication, authorization, idempotency और refund policy को model के discretion से बाहर रखें। Model द्वारा बनाया गया customer name या invoice ID identity का प्रमाण नहीं है।

Human checkpoint के साथ graph बनाएं

इस example में tool-calling support वाला model, एक lookup tool और अलग refund node का उपयोग किया गया है। चिन्हित application functions को अपने authorized service calls से बदलें। Model और tool schema आपके configure किए गए endpoint द्वारा समर्थित होने चाहिए; compatibility documented endpoint और parameter support पर निर्भर है। यह snippet यह प्रमाणित नहीं करता कि किसी विशेष model या OneMux configuration का परीक्षण किया गया है।

from typing import Annotated, Literal

from langchain.tools import tool
from langchain_core.messages import AnyMessage
from langgraph.graph import END, START, StateGraph
from langgraph.graph.message import add_messages
from langgraph.prebuilt import ToolNode, tools_condition
from langgraph.checkpoint.memory import MemorySaver
from langgraph.types import interrupt
from typing_extensions import TypedDict

# Replace with your provider's documented LangChain model setup.
# Confirm that the chosen endpoint supports tool calling and the parameters used.
model = make_your_chat_model().bind_tools([])  # bind the tools below in your application

class State(TypedDict):
    messages: Annotated[list[AnyMessage], add_messages]
    refund_request: dict | None
    approval: str | None

@tool
def find_purchases(customer_reference: str) -> list[dict]:
    """Find purchases for an already authenticated customer."""
    return authorized_purchase_lookup(customer_reference)

tools = [find_purchases]
model = make_your_chat_model().bind_tools(tools)

def assistant(state: State):
    return {"messages": [model.invoke(state["messages"])]}

def prepare_refund(state: State):
    # Build this from validated application data, not model-invented values.
    request = build_validated_refund_request(state["messages"])
    decision = interrupt({
        "type": "refund_approval",
        "request": request,
        "instruction": "Approve or reject this exact refund request.",
    })
    if decision != "approve":
        return {"approval": "rejected", "refund_request": request}
    return {"approval": "approved", "refund_request": request}

def execute_refund(state: State):
    if state.get("approval") != "approved":
        return {"messages": [{"role": "assistant", "content": "The refund was not approved."}]}
    result = issue_refund_safely(state["refund_request"])
    return {"messages": [{"role": "assistant", "content": format_refund_result(result)}]}

builder = StateGraph(State)
builder.add_node("assistant", assistant)
builder.add_node("tools", ToolNode(tools))
builder.add_node("prepare_refund", prepare_refund)
builder.add_node("execute_refund", execute_refund)
builder.add_edge(START, "assistant")
builder.add_conditional_edges("assistant", tools_condition)
builder.add_edge("tools", "assistant")
builder.add_edge("prepare_refund", "execute_refund")
builder.add_edge("execute_refund", END)

graph = builder.compile(checkpointer=MemorySaver())

यह एक structural example है, complete routing graph नहीं: आपके application को verified refund intent को prepare_refund पर और सामान्य questions को assistant/lookup path पर route करना होगा। interrupt() call graph को pause करती है और approval payload caller को लौटाती है। Human review interface में decision भेजने से पहले customer, transaction, amount और policy context दिखना चाहिए। LangGraph के Command(resume=...) mechanism और उसी thread identifier के साथ उसी thread को resume करें। Checkpoints को उचित रूप से persist करें; in-memory checkpointing development के लिए है, durable production workflows के लिए नहीं।

Control flow का एक महत्वपूर्ण विवरण: interrupt एक pause है, permission system नहीं। Refund execution node में approval value को दोबारा enforce करें और सुनिश्चित करें कि refund service स्वयं authorization, transaction eligibility और duplicate requests की जांच करे।

Execution को सीमित करें और failures को स्पष्ट बनाएं

Graph invoke करते समय recursion limit पास करें। यह graph supersteps को सीमित करता है; model tokens, tool runtime, database query cost या user requests की संख्या को सीमित नहीं करता। Model calls और tools के लिए अलग timeouts और resource limits सेट करें।

from langgraph.errors import GraphRecursionError

config = {
    "configurable": {"thread_id": "support-case-123"},
    "recursion_limit": 12,
}

try:
    result = graph.invoke(
        {"messages": [{"role": "user", "content": "I need help with a purchase."}]},
        config=config,
    )
except GraphRecursionError:
    # Return a safe handoff or ask for clarification; log the trace for review.
    result = {"status": "needs_human_review"}

Expected workflow के आधार पर limit चुनें, फिर normal completion और loop-prone inputs दोनों का परीक्षण करें। Exhausted graph को चुपचाप retry करने से बचें: यदि आपके tools idempotent नहीं हैं, तो retries tool calls दोहरा सकती हैं। Read-only lookup tools को side-effecting operations की तुलना में retry करना अधिक सुरक्षित है।

केवल answer नहीं, path का भी evaluation करें

दिए गए LangSmith tutorial में तीन उपयोगी evaluation targets बताए गए हैं: final response (क्या customer को उचित उत्तर मिला?), trajectory (क्या agent ने expected tool-call path अपनाया?) और single step (क्या उसने किसी खास decision के लिए सही tool चुना?)। Refund triage के लिए missing identity details, multiple matching purchases, बिना परिणाम वाला lookup, rejected approval और approved refund के cases बनाएं।

जांचें कि agent जानकारी गढ़ने के बजाय आवश्यक information मांगता है; lookup से refund trigger नहीं होता; और approval के बिना execution नहीं हो सकता। Evaluation के लिए mock या test services का उपयोग करें, ताकि tests वास्तविक customer records में बदलाव न करें। Source tutorial अपने database operations के लिए mock mode का उपयोग करता है, लेकिन वह अपने demo setup का वर्णन करता है—production safety guarantee का नहीं।

Model access के लिए OneMux का उपयोग

OneMux एक OpenAI-compatible API के माध्यम से leading AI models तक access देता है। यदि आप model access के लिए single API surface चाहते हैं, तो OneMux quickstart, API documentation और available models देखें। इस workflow की compatibility चुने गए model endpoint के documented tool-calling support और accepted parameters पर निर्भर करती है। Deployment से पहले इन विवरणों की पुष्टि करें; यह article यह दावा नहीं करता कि LangGraph example का OneMux के साथ परीक्षण किया गया है।

सीमाएं और troubleshooting

• Model tool कॉल नहीं करता: जांचें कि selected endpoint tool calling को support करता है और tool schema उसके documented format में पास किया गया है।
• Graph loop करता है: assistant और tools के बीच transitions की जांच करें, graph steps को सीमित करें और सुनिश्चित करें कि completed tool result अगला decision बदलता है।
• Approval से गलत case resume होता है: support case से जुड़ा stable thread identifier उपयोग करें और resume करने से पहले checkpoint verify करें।
• Refund दो बार चलता है: service boundary पर idempotency जोड़ें और approved request तथा outcome record करें।
• Agent किसी अन्य customer के records दिखाता है: lookup service में authorization ठीक करें; prompt instruction access control नहीं है।

निष्कर्ष

LangGraph support triage को explicit workflow steps के रूप में व्यक्त करना संभव बनाता है, बजाय इसके कि निर्णय लेने और action करने के लिए single model response पर भरोसा किया जाए। Lookup को read-only रखें, refunds से पहले pause करें, execution के समय approval validate करें और graph steps को सीमित करें। इसके बाद agent के answer और उसके अपनाए गए path—दोनों का evaluation करें। ये controls workflow को inspect करना आसान बनाते हैं—लेकिन production security और policy enforcement की जिम्मेदारी application की ही रहती है।

Sources

• LangSmith: Evaluate a complex agent — music-store support example, उसकी lookup/refund structure, mock mode और तीन evaluation targets का source।