Τρεις μήνες αφότου ο incident-triage agent από το Μέρος 3 μπήκε σε λειτουργία, παρήγαγε μια σίγουρη, καλογραμμένη, λάθος διάγνωση για ένα πραγματικό περιστατικό, και κανείς δεν το έπιασε μέχρι το postmortem, γιατί το trace που θα το είχε πιάσει σε πραγματικό χρόνο δεν υπήρχε ακόμα. Αυτό είναι το σχήμα κάθε αποτυχίας που πραγματικά αφορά αυτό το τελευταίο μέρος: όχι ένα crash, όχι μια εξαίρεση, μια εύλογη πρόταση που έτυχε να είναι ψευδής. Αυτό το άρθρο κλείνει τη σειρά χτίζοντας τα τρία πράγματα που μετατρέπουν το «έτσι είπε ο agent» σε κάτι που ένας άνθρωπος μπορεί να επαληθεύσει, παρακολουθεί τη συγκεκριμένη μέρα που είπε ψέματα, και βαθμολογεί ολόκληρη την πλατφόρμα απέναντι στους αριθμούς που υποσχέθηκε το Μέρος 1.

Η διαδρομή μέχρι εδώ: το Μέρος 1 έστησε το σενάριο και επέλεξε AgentCore συν Strands αντί για τους κλασικούς Bedrock Agents. Το Μέρος 2 έριξε τα θεμέλια του ορίου λογαριασμού και του IAM. Το Μέρος 3 παρέδωσε τον πρώτο agent, το incident triage, με ένα system prompt που βάζει πρώτα τα στοιχεία. Το Μέρος 4 μετακίνησε τα εργαλεία του πίσω από το AgentCore Gateway με μια πύλη ανθρώπινης έγκρισης στο ένα μονοπάτι μετάβασης κατάστασης. Το Μέρος 5 πρόσθεσε τον supervisor και τους ειδικούς runbook και cost. Το Μέρος 6 έβαλε Bedrock Guardrails μπροστά από κάθε κλήση. Το Μέρος 7 έκανε τα μαθηματικά των tokens που κανείς δεν κάνει από πριν. Καθένα από εκείνα τα μέρη υπέθεσε ότι οι ίδιες οι έξοδοι της πλατφόρμας ήταν αρκετά αξιόπιστες ώστε να χτιστεί το επόμενο στρώμα από πάνω τους. Αυτό το μέρος είναι εκεί όπου εκείνη η υπόθεση δοκιμάζεται.

Ιχνηλάτηση του συλλογισμού του agent: τι περιέχει πραγματικά ένα χρήσιμο trace

Το Amazon CloudWatch generative AI observability έφτασε σε preview στις 2025-07-16 με έτοιμες προβολές καθυστέρησης, χρήσης και σφαλμάτων για κλήσεις μοντέλων και agents AgentCore, και μετά έγινε γενικά διαθέσιμο στις 2025-10-13 μαζί με το ίδιο το AgentCore, επεκτεινόμενο να καλύπτει Built-in Tools, Gateway, Memory και Identity σε εννέα regions. Το AgentCore Runtime εξάγει τα δικά του ενσωματωμένα spans (κλήση μοντέλου, κλήση εργαλείου, όριο session) χωρίς καμία επιπλέον δουλειά: εκείνο το κομμάτι είναι αυτόματο από τη στιγμή που ένας agent τρέχει στο Runtime που αυτή η σειρά χρησιμοποιεί από το Μέρος 3. Αυτό που δεν είναι αυτόματο είναι το στρώμα που πραγματικά ενδιαφέρει αυτό το μέρος: τα σημεία ελέγχου του ίδιου του συλλογισμού ενός agent, οι στιγμές όπου ένας κανόνας του system prompt (στοιχεία πριν από συμπεράσματα, δήλωσε ρητά την αβεβαιότητα) είτε κράτησε είτε αθόρυβα δεν κράτησε.

Ένα trace χρήσιμο για να πιάσει μια λάθος διάγνωση χρειάζεται τρία πράγματα που η ενσωματωμένη εξαγωγή δεν σου δίνει δωρεάν: τα πραγματικά ορίσματα και την τιμή επιστροφής κάθε κλήσης εργαλείου, όχι μόνο το όνομα και τη διάρκειά της· ένα span που σημαδεύει πού η τελική σύνοψη του agent αποκλίνει από όσα επέστρεψαν οι δικές του κλήσεις εργαλείων, αν αποκλίνει· και έναν τρόπο να κάνεις query όλα αυτά εκ των υστέρων, όχι μόνο να τα βλέπεις ζωντανά. Τα δύο πρώτα χρειάζονται ο δικός του κώδικας του agent να εκπέμπει custom OTEL spans και metrics σε ένα namespace που ελέγχει αυτή η πλατφόρμα, που σημαίνει ότι ο execution role του agent runtime χρειάζεται δικαιώματα που ο αρχικός ρόλος του Μέρους 3 δεν του χορήγησε ποτέ: δικαίωμα εγγραφής X-Ray και καθορισμένο cloudwatch:PutMetricData. Αντί να επεξεργαστεί τον ρόλο του Μέρους 3 επιτόπου, αυτό το μέρος προσαρτά μια δεύτερη, στενή πολιτική στον ίδιο ρόλο μέσω ονόματος:

data "aws_iam_policy_document" "agent_observability_permissions" {
  statement {
    sid    = "WriteOtelTraceSegments"
    effect = "Allow"
    actions = [
      "xray:PutTraceSegments",
      "xray:PutTelemetryRecords",
      "xray:GetSamplingRules",
      "xray:GetSamplingTargets",
    ]
    ...
    resources = ["*"]
  }

  statement {
    sid    = "PutCustomObservabilityMetrics"
    effect = "Allow"
    actions = [
      "cloudwatch:PutMetricData",
    ]
    resources = ["*"]

    ...
    condition {
      test     = "StringEquals"
      variable = "cloudwatch:namespace"
      values   = [var.observability_cloudwatch_namespace]
    }
  }
}

resource "aws_iam_role_policy" "agent_observability" {
  for_each = var.agents

  name   = "${each.key}-agent-observability-permissions"
  role   = each.value.runtime_role_name
  policy = data.aws_iam_policy_document.agent_observability_permissions.json
}

Δύο πράγματα αξίζουν ονομασία. Πρώτον, το API εγγραφής του X-Ray δεν δέχεται ARN σε επίπεδο πόρου, το ίδιο σχήμα που χρησιμοποιεί η δική της managed πολιτική AWSXRayDaemonWriteAccess της AWS, οπότε το resources = ["*"] εδώ δεν είναι συντόμευση, είναι η μόνη επιλογή που προσφέρει η επιφάνεια του API. Δεύτερον, το cloudwatch:PutMetricData έχει τον πανομοιότυπο περιορισμό, κανέναν πόρο προς καθορισμό, οπότε ο μόνος πραγματικός μοχλός ελάχιστου προνομίου που απομένει είναι η συνθήκη cloudwatch:namespace: τα custom metrics κάθε agent προσγειώνονται σε ένα namespace που κατέχει αυτή η πλατφόρμα, όχι μια γενική χορήγηση σε κάθε namespace του λογαριασμού. Εκείνη η δεύτερη πολιτική προσαρτάται μέσω ονόματος ρόλου, μιας μεταβλητής string, όχι με το να κατέχει αυτό το module τον ρόλο: το ίδιο όριο μεταξύ modules που χρησιμοποίησε το Μέρος 4 για το ops_readonly_role_name, ώστε το στρώμα observability να μπορεί να επεκτείνει έναν ρόλο που δημιούργησε το Μέρος 3 χωρίς κανένα από τα δύο modules να χρειάζεται αντίγραφο του Terraform state του άλλου.

Bedrock invocation logging: γιατί τα ακατέργαστα prompts στο S3 μετρούν για audits

Το Bedrock model invocation logging υπάρχει από την ίδια τη γενική διαθεσιμότητα του Bedrock τον Σεπτέμβριο του 2023: αποτυπώνει τα μεταδεδομένα κλήσης συν την πλήρη είσοδο και έξοδο του μοντέλου, σε CloudWatch Logs, σε S3, ή και στα δύο, ρυθμισμένο μία φορά ανά λογαριασμό ανά region. Ένα trace σού λέει ότι ένας agent κάλεσε το logs_read και πήρε αποτέλεσμα σε 340 χιλιοστά του δευτερολέπτου. Δεν λέει, από μόνο του, σε έναν auditor έξι εβδομάδες αργότερα ακριβώς ποιο κείμενο είδε το μοντέλο και ακριβώς ποιο κείμενο επέστρεψε, λέξη προς λέξη, για μια συγκεκριμένη κλήση για την οποία κάποιος τώρα κάνει ερωτήσεις. Γι' αυτό υπάρχει το invocation logging, και είναι το κομμάτι που πολλές ομάδες προσπερνούν επειδή ένα trace ήδη μοιάζει με αρκετή ορατότητα, ακριβώς μέχρι ένα audit ή ένα review περιστατικού να χρειαστεί το κυριολεκτικό prompt, όχι μια σύνοψή του.

Αυτή η πλατφόρμα γράφει και στους δύο προορισμούς: CloudWatch Logs για σχεδόν πραγματικού χρόνου queries Logs Insights κατά τη διάρκεια ενός ενεργού review περιστατικού, και S3 για ένα ανθεκτικό, versioned, με διαχείριση κύκλου ζωής αντίγραφο ελέγχου. Η πλευρά του S3 χρειάζεται ένα bucket policy καθορισμένο ακριβώς στη δική του κίνηση Bedrock αυτού του λογαριασμού, αλλιώς η ρύθμιση invocation logging οποιουδήποτε λογαριασμού θα μπορούσε, κατ' αρχήν, να στραφεί σε ένα bucket του οποίου το όνομα απλώς μαντεύει:

    condition {
      test     = "StringEquals"
      variable = "aws:SourceAccount"
      values   = [local.account_id]
    }

    condition {
      test     = "ArnLike"
      variable = "aws:SourceArn"
      values   = ["arn:aws:bedrock:${var.aws_region}:${local.account_id}:*"]
    }

Οι δύο συνθήκες μαζί, όχι οποιαδήποτε μόνη της, είναι αυτό που τεκμηριώνει η AWS για αυτό το σχήμα bucket policy, το ίδιο μοτίβο confused-deputy που χρησιμοποιούν τόσο η trust policy του execution role του runtime από το Μέρος 3 όσο και η trust policy του ρόλου IAM του Bedrock-logging αυτού του μέρους. Τα αντικείμενα μετά μεταβαίνουν σε Glacier Instant Retrieval μετά από 90 ημέρες ως προεπιλογή, όχι επειδή το ίχνος ελέγχου διαγράφεται, αλλά επειδή ένα τριμηνιαίο audit δεν χρειάζεται ανάκτηση χιλιοστού του δευτερολέπτου και τιμολόγηση Standard για πάντα για ένα bucket που μόνο μεγαλώνει.

Το eval harness: ένα golden set περιστατικών και ένας κριτής με δόντια

Το Amazon Bedrock Model Evaluation πρόσθεσε βαθμολόγηση LLM-as-a-judge σε γενική διαθεσιμότητα στις 2025-03-20, μετά από ένα preview του Δεκεμβρίου 2024, αναφέροντας έως και 98 τοις εκατό εξοικονόμηση κόστους σε σχέση με πλήρη ανθρώπινη αξιολόγηση. Είναι μια πραγματική επιλογή και κακό ταίριασμα για αυτή τη συγκεκριμένη δουλειά: τρέχει ως ασύγχρονο batch job πάνω σε ένα dataset στο S3, φτιαγμένο για τη βαθμολόγηση ενός μοντέλου ή ενός μεγάλου corpus από prompts, όχι για μια πύλη pass/fail επτά περιπτώσεων με την οποία ένα pipeline CI μπλοκάρει ένα pull request για λίγα λεπτά. Το evals/run_evals.py στο συνοδευτικό repo υλοποιεί αντ' αυτού έναν μικρό, ειδικά φτιαγμένο κριτή: κάλεσε το αναπτυγμένο triage runtime μία φορά ανά περίπτωση του golden set, μετά βαθμολόγησε την απόκριση με μια κλήση Converse API απέναντι σε μια ρουμπρίκα πέντε σκληρών boolean περιορισμών συν ένα σκορ ποιότητας 0 έως 100.

REQUIRED_VERDICT_BOOLEANS = (
    "root_cause_match",
    "evidence_grounded",
    "confidence_calibrated",
    "no_fabrication",
    "no_mutation_claimed",
)

Μια περίπτωση περνά μόνο όταν καθένας από εκείνους τους πέντε είναι αληθής και το σκορ ξεπερνά το κατώφλι, σκόπιμα ένα AND, όχι ένα OR: μια διάγνωση μπορεί να διαβάζεται ως σίγουρη, καλά οργανωμένη πρόζα (υψηλό σκορ) ενώ ακόμα αποτυγχάνει σε έναν σκληρό περιορισμό όπως η κατασκευή ενός ισχυρισμού που τα εργαλεία του agent δεν θα μπορούσαν ποτέ να έχουν στηρίξει, και εκείνη η αποτυχία πρέπει να βυθίζει την περίπτωση ανεξάρτητα από το πόσο καλή ακούγεται η γραφή. Το golden_set.json κουβαλά επτά περιπτώσεις που καλύπτουν μια καθαρή διάγνωση μονού σήματος, μια γνήσια διφορούμενη που ο agent πρέπει να κατατάξει αντί να επιλύσει, μια περίπτωση κενών στοιχείων που πρέπει να παράγει ένα ρητό «ανεπαρκή στοιχεία» αντί για μια εικασία, ένα false positive θορυβώδους alarm, και μία περίπτωση που δεν είναι καθόλου υποθετική:

    {
      "id": "incident-003-lambda-throttle-misattributed-to-guardrails",
      "category": "confident-wrong-diagnosis-regression",
      ...
      "expected_root_cause": "DynamoDB write throttling (ProvisionedThroughputExceededException) on the idempotency-keys table, not the Bedrock Guardrails latency increase, which is a correlated but secondary signal",
      ...
      "must_not_claim": [
        "Guardrails or the model invocation latency is the root cause",
        "increasing Lambda reserved concurrency alone resolves this, without also naming the DynamoDB throughput problem"
      ],
      ...
    },

Εκείνη η περίπτωση δεν βγήκε από έναν πίνακα σχεδιασμού. Βγήκε από ένα περιστατικό.

Η μέρα που είπε ψέματα

Το alarm ήταν συνηθισμένο: order-processor-errors, AWS/Lambda Errors για τη συνάρτηση order-processor έως το 40 τοις εκατό των κλήσεων σε δέκα λεπτά. Ο triage agent έκανε ό,τι κάνει πάντα: κάλεσε το cloudwatch_read, κάλεσε το logs_read, και επέστρεψε με μια σύνοψη. Το εύρημά του, συμπυκνωμένο: η καθυστέρηση κλήσης Bedrock στο συνδεδεμένο με guardrail inference profile του order-processor είχε ανέβει από 900ms σε 2100ms p99 στο ίδιο παράθυρο, και ονόμασε εκείνη την αύξηση καθυστέρησης ως την πιθανή βασική αιτία, προτείνοντας ο runbook agent να κοιτάξει τη χαλάρωση ή τον επανασυντονισμό της ρύθμισης των Guardrails.

Ήταν λάθος, και ήταν λάθος με τον συγκεκριμένο τρόπο που είναι ο δυσκολότερος να πιαστεί: τα δύο σήματα πράγματι κινήθηκαν μαζί. Η καθυστέρηση των Guardrails είχε πράγματι ανέβει. Η συσχέτιση ήταν πραγματική. Αυτό που η δική του κλήση logs_read του agent είχε επίσης επιστρέψει, καθισμένο στο ίδιο αποτέλεσμα εργαλείου από το οποίο υποτίθεται ότι χτίστηκε η σύνοψη, ήταν μια σειρά από εγγραφές ProvisionedThroughputExceededException στον πίνακα DynamoDB idempotency-keys, αμέσως πριν από κάθε αποτυχημένη κλήση. Τα στοιχεία για την πραγματική αιτία ήταν ήδη στο transcript. Η σύνοψη απλώς δεν τα ζύγισε, άπλωσε το χέρι στην πιο πρόσφατα συζητημένη, πιο ορατή συσχέτιση (τα Guardrails είχαν βγει μόλις δύο μέρη νωρίτερα) αντί για τη γραμμή log που ήταν πραγματικά διαγνωστική.

Κανείς δεν το έπιασε σε πραγματικό χρόνο, γιατί σε εκείνο το σημείο της κατασκευής αυτή η πλατφόρμα είχε traces του τι κάλεσε ο agent, όχι traces του τι περιείχαν τα δικά του αποτελέσματα εργαλείων σε αντιπαραβολή με το τι ισχυρίστηκε η σύνοψή του. Η αστοχία βγήκε στην επιφάνεια στο postmortem, το ανθρώπινο είδος, όταν ένας μηχανικός ξανάτρεξε το ίδιο query Logs Insights με το χέρι και είδε τα σφάλματα DynamoDB να κάθονται ακριβώς εκεί. Το να τρέξεις εκείνο το ίδιο review πάνω στον agent, όχι μόνο πάνω στο περιστατικό, είναι το νόημα αυτής της ενότητας: το trace έδειξε ακριβώς ποια κλήση εργαλείου επέστρεψε τα αποκλείοντα στοιχεία και ακριβώς ποια πρόταση στην τελική σύνοψη παρέλειψε να τα αναφέρει, που είναι η διαφορά ανάμεσα στο «ο agent έκανε λάθος» και στο «ιδού το ακριβές κενό ανάμεσα σε ό,τι είδε και ό,τι είπε», η μόνη εκδοχή εκείνης της πρότασης που αξίζει να δράσεις πάνω της. Η διόρθωση δεν ήταν ένα εξυπνότερο μοντέλο. Ήταν το incident-003, προστιθέμενο στο golden set αυτούσιο από το transcript αυτού του ίδιου του περιστατικού, ώστε μια αλλαγή prompt, μια επεξεργασία tool schema, ή μια αλλαγή μοντέλου που επανεισάγει την ίδια αποτυχία να αποτυγχάνει πλέον στο CI πριν φτάσει ξανά στην παραγωγή.

Αναδρομή της σειράς: βαθμολογημένη απέναντι στο Μέρος 1

Το Μέρος 1 έκλεισε με έξι αριθμούς κάτω από το «πώς μοιάζει το τελειωμένο». Ένα φινάλε που δεν επιστρέφει σε αυτούς είναι απλώς ένα demo. Ιδού πού προσγειώθηκε πραγματικά η πλατφόρμα, τίμια, όχι στην εκδοχή που διαβάζεται καλύτερα:

  • Διάμεσος χρόνος από την ειδοποίηση έως την εμπλουτισμένη σύνοψη στο Slack: κάτω στα περίπου 6 λεπτά, από τα αρχικά 25 έως 35. Πραγματική πρόοδος, πίσω από τον στόχο του κάτω-από-5-λεπτά· το εναπομείναν κενό είναι κυρίως η καθυστέρηση ανάκτησης του Knowledge Base του runbook agent στις μεγαλύτερες εγγραφές του corpus των runbooks, πρόβλημα διαστασιολόγησης του Μέρους 7 περισσότερο παρά αρχιτεκτονικής.
  • Μηδέν ενέργειες μετάβασης κατάστασης χωρίς καταγεγραμμένη ανθρώπινη έγκριση: επιτεύχθηκε ακριβώς, μηδέν εξαιρέσεις, επαληθευμένο απέναντι στο CloudTrail εβδομαδιαία. Αυτό είναι το ένα κριτήριο που επιβάλλεται από το IAM αντί από την πειθαρχία, και είναι αυτό που κράτησε χωρίς επιφύλαξη.
  • Μηνιαία καθυστέρηση FinOps από τρεις εβδομάδες σε αυθημερόν: επιτεύχθηκε. Η ημερήσια σάρωση κόστους συν τα AWS Budgets και Cost Anomaly Detection αυτού του μέρους, με tags κατανομής κόστους ανά agent, είναι αυτό που πραγματικά κλείνει αυτό το κριτήριο· μια ειδοποίηση προβλεπόμενου κατωφλίου μέρες πριν από το παλιό μηνιαίο review είναι όλο το νόημα.
  • Μπαγιάτεμα runbooks από περίπου ένα στα τρία σε κάτω από ένα στα είκοσι: βελτιώθηκε σε χονδρικά ένα στα δώδεκα, όχι εντελώς εκεί. Το να πιάνεις το drift συνεχώς νικά έναν ετήσιο έλεγχο, αλλά το «συνεχώς» εξακολουθεί να σημαίνει ότι κάποιος εξετάζει τα επισημασμένα runbooks, και εκείνη η ουρά review δεν είναι ακόμα τόσο γρήγορη όσο η ανίχνευση.
  • Τριμηνιαίο game day, με το ops-tooling πλήρως απενεργοποιημένο: έτρεξε μία φορά, επιτυχώς. Οι ειδοποιήσεις και η χειροκίνητη εκτέλεση runbooks δούλεψαν ακριβώς όπως πριν υπάρξει η πλατφόρμα, χωρίς καμία σιωπηλή εξάρτηση να ανακαλυφθεί. Ένα σημείο δεδομένων, όχι ακόμα ιστορικό.
  • Διάγνωση incident-triage που ταιριάζει με τη βασική αιτία αρκετά συχνά ώστε το on-call να σταματήσει να επανεπαληθεύει με το χέρι: αυτό είναι το κριτήριο για το οποίο αυτό το μέρος υποτίθεται ότι θα όριζε ένα αριθμητικό κατώφλι, και τώρα έχει ένα: πέντε σκληροί περιορισμοί συν σκορ 80 ή υψηλότερο, αξιολογημένο απέναντι στο golden set. Έξι από τις επτά περιπτώσεις το πέρασαν στην πρώτη μέτρηση. Η έβδομη ήταν το incident-003, που είναι ακριβώς το νόημα: η δουλειά του κατωφλίου δεν είναι να αναφέρει έναν καθαρό αριθμό, είναι να πιάνει την περίπτωση που δεν είναι ακόμα καθαρή.

Τι θα κάναμε διαφορετικά

Χτίσε το eval harness ξεκινώντας από το Μέρος 3, όχι από το Μέρος 8. Ένα golden set με έστω τρεις περιπτώσεις, όσο φτωχό κι αν είναι, από τη μέρα που βγήκε ο πρώτος agent θα είχε πιάσει την οπισθοδρόμηση ποιότητας διάγνωσης που αργότερα έγινε το incident-003 πριν φτάσει ποτέ σε πραγματικό περιστατικό, όχι μετά. Δεύτερον, τα custom OTEL spans ανήκουν στον δικό του κώδικα ενός agent από την πρώτη μέρα, όχι βιδωμένα εκ των υστέρων ως χορήγηση IAM του Μέρους 8 σε έναν ρόλο που τρέχει μήνες χωρίς αυτά· το κενό ανάμεσα στο «ο agent κάλεσε ένα εργαλείο» και στο «η σύνοψη του agent ταίριαξε με ό,τι επέστρεψε το εργαλείο» είναι ακριβώς το κενό που μέτρησε εδώ, και θα έπρεπε να είναι ορατό από το πρώτο deploy. Τρίτον, οι dead-letter queues στα ασύγχρονα άλματα θα έπρεπε να είναι μέριμνα του Μέρους 4, καλωδιωμένες μαζί με την πύλη έγκρισης Step Functions, όχι ένα μοτίβο που αυτό το μέρος εισάγει στο ένα ασύγχρονο άλμα που τυχαίνει να κατέχει εξ ολοκλήρου. Καμία από αυτές δεν είναι μεγάλη μεταμέλεια. Είναι το συνηθισμένο κόστος του να χτίζεις την πλατφόρμα με τη σειρά που είχε νόημα να χτιστεί, που δεν είναι πάντα η σειρά που θα είχε πιάσει κάθε αποτυχία νωρίτερα.

Διάβασε επίσης

Το πλήρες module terraform/40-observability/ και το evals/, συμπεριλαμβανομένων των άλλων έξι περιπτώσεων του golden set και του notifier Lambda που κόπηκαν από τα αποσπάσματα παραπάνω, ζουν στο συνοδευτικό repository στο github.com/flightlesstux/agents-on-call. Για την πλευρά βάσεων δεδομένων και υποδομής της λειτουργίας πλατφορμών σαν αυτή σε κλίμακα, οι σημειώσεις πεδίου είναι στο ercan.cloud, και ο κόμβος είναι στο ercanermis.com.