Multi-Agent Systems की Testing और Observability

पहले contracts, फिर यात्राएँ

परतों में परखें। (1) हर MCP server (tool सूची, schemas, error codes) और हर Agent Card/endpoint के लिए contract tests, scripted clients और ऐसे stub remote agents से जो तैयार task क्रम लौटाएँ, input-required, विफलता और timeout समेत। (2) fake cards और fake tool calls के साथ routing और नीति tests, allow-lists, अनुमोदन द्वार और "कोई agent नहीं मिला" रास्ता कवर करते हुए। (3) वास्तविक परिदृश्यों पर असली मॉडलों के साथ end-to-end मूल्यांकन, परिणाम, tool/delegation trajectory, लागत और सुरक्षा scored। Observability के लिए MCP और A2A calls के पार trace id आगे भेजें, delegations और tool calls redaction के साथ log करें, और विफलता दर, loop या hop गिनती, latency, प्रति अनुरोध लागत और अनुमोदन backlog मॉनिटर करें। Tracing के बिना तीन hops दूर की विफलता का निदान लगभग असंभव है।

Tests के लिए stub remote agent (उदाहरण)

यह scripted task क्रम चलाता है ताकि client की input-required और विफलता की सँभाल ऑफ़लाइन परखी जा सके। यहाँ चलाया नहीं गया।

class StubRemoteAgent:
    """Plays back scripted task states so client logic can be tested offline."""
    def __init__(self, script):
        self.script = list(script)
    def next_status(self):
        return self.script.pop(0)

def test_client_asks_user_when_input_required():
    agent = StubRemoteAgent(["working", "input-required", "working", "completed"])
    seen = [agent.next_status() for _ in range(4)]
    assert "input-required" in seen            # the client under test must surface a question

def test_client_gives_up_after_failure():
    agent = StubRemoteAgent(["working", "failed"])
    assert [agent.next_status() for _ in range(2)][-1] == "failed"

त्वरित जाँच: MCP और A2A calls के पार trace id क्यों आगे भेजें?

• Tokens encrypt करने के लिए
• Network तेज़ करने के लिए
• Logging से बचने के लिए
• विफलताओं का निदान करते समय एक अनुरोध का हर hop में पीछा करने के लिए