Ο πρώτος agent που δουλεύει πραγματικά σε αυτή τη σειρά είναι περίπου 260 γραμμές Python: ένας Strands Agent, δύο read-only εργαλεία που αναλαμβάνουν έναν cross-account ρόλο IAM πριν καλέσουν το boto3, και ένα system prompt του οποίου η αποκλειστική δουλειά είναι να εμποδίσει το μοντέλο να ακούγεται σίγουρο για κάτι που στην πραγματικότητα δεν έχει ελέγξει. Ακόμα χωρίς AgentCore Gateway, χωρίς supervisor, χωρίς multi-agent handoff: αυτά έρχονται σε επόμενα μέρη. Αυτό το μέρος αφορά το να κάνει ένας agent σωστά μία δουλειά, αναπτυγμένος στο AgentCore Runtime, πριν προστεθεί οτιδήποτε κάνει το debugging του πιο δύσκολο.

Το Μέρος 1 έστησε το σενάριο (μια SaaS εταιρεία 50 μηχανικών, 40 ειδοποιήσεις την εβδομάδα, με το read-only επιβεβλημένο από το IAM ως τον μη διαπραγματεύσιμο περιορισμό) και επέλεξε AgentCore συν Strands αντί για κλασικούς Bedrock Agents ή έναν αυτοφτιαγμένο βρόχο. Το Μέρος 2 έχτισε το όριο λογαριασμού μέσα στο οποίο ζουν αυτοί οι agents: τους ρόλους spoke ops-readonly και ops-mutate, και ένα application inference profile ανά agent που τυλίγει το cross-region routing του Bedrock. Αυτό το μέρος χρησιμοποιεί και τα δύο απευθείας. Τίποτα εδώ δεν δημιουργείται από το μηδέν· καταναλώνει ό,τι έχτισε ήδη το Μέρος 2. Ο συνοδευτικός κώδικας βρίσκεται στο github.com/flightlesstux/agents-on-call, στα agents/triage/agent.py και terraform/10-agent-runtime/, και κάθε απόσπασμα παρακάτω είναι αντιγραμμένο από αυτά τα αρχεία, όχι απλοποιημένο για το άρθρο.

Ανατομία ενός Strands agent

Το Strands Agents είναι ένα model-driven SDK για Python, open source από την AWS τον Μάιο του 2025 υπό άδεια Apache 2.0, και χρησιμοποιούνταν εσωτερικά για το Amazon Q Developer, το AWS Glue και το VPC Reachability Analyzer πριν καν βγει έξω από την εταιρεία. Το επιχείρημά του δεν είναι μια νέα γλώσσα orchestration: είναι ένας λεπτός βρόχος γύρω από ένα μοντέλο που ήδη ξέρει πώς να καλεί εργαλεία, συνδεδεμένος με το Bedrock, απευθείας Anthropic, Ollama, ή έναν provider πίσω από LiteLLM proxy, χωρίς να αλλάζει ο τρόπος που γράφεται ο agent. Όλο το σχήμα ενός agent χωράει σε πέντε βήματα.

1. Η ρύθμιση προέρχεται από το περιβάλλον, όχι από literals μέσα στο αρχείο. Οτιδήποτε χρειάζεται να γνωρίζει το runtime ορίζεται ως μεταβλητή περιβάλλοντος από το Terraform module παρακάτω, οπότε τίποτα ειδικό για λογαριασμό ή μυστικό δεν είναι hardcoded στον κώδικα:

AWS_REGION = os.environ.get("AWS_REGION", "eu-west-1")
INFERENCE_PROFILE_ARN = os.environ["AGENT_INFERENCE_PROFILE_ARN"]
OPS_READONLY_ROLE_NAME = os.environ.get("OPS_READONLY_ROLE_NAME", "ops-readonly")
SPOKE_EXTERNAL_ID = os.environ["SPOKE_EXTERNAL_ID"]

2. Τα εργαλεία είναι απλές συναρτήσεις Python με έναν decorator. Το Strands διαβάζει τα type hints και το docstring μιας συνάρτησης για να χτίσει το tool spec που βλέπει στην πραγματικότητα το μοντέλο, οπότε το docstring δεν είναι σχόλιο για ανθρώπους, είναι το συμβόλαιο του interface:

@tool
def cloudwatch_read(
    spoke_account_id: str,
    namespace: str,
    metric_name: str,
    dimensions: dict[str, str],
    lookback_minutes: int = 60,
    stat: str = "Average",
    period_seconds: int = 60,
) -> str:
    """Read a CloudWatch metric's recent datapoints from a spoke account.
    ...
    """

3. Το μοντέλο συνδέεται μέσω του inference profile του Μέρους 2, όχι μέσω ενός ακατέργαστου model ID. Το temperature παραμένει χαμηλό σκόπιμα: αυτός ο agent προτείνει μια διάγνωση από στοιχεία, δεν χρειάζεται δημιουργική ποικιλία στη διατύπωσή του.

model = BedrockModel(
    model_id=INFERENCE_PROFILE_ARN,
    region_name=AWS_REGION,
    temperature=0.1,
    max_tokens=2048,
)

4. Ο ίδιος ο agent είναι μία μόνο κλήση constructor: ένα μοντέλο, ένα system prompt, και μια λίστα εργαλείων. Δεν υπάρχει orchestration graph να γραφτεί, γιατί το Strands συμπεραίνει τον βρόχο κλήσης εργαλείων από την ίδια την έξοδο tool-use του μοντέλου:

agent = Agent(
    model=model,
    system_prompt=SYSTEM_PROMPT,
    tools=[cloudwatch_read, logs_read],
    name="incident-triage",
    description=(
        "First-pass responder for CloudWatch alarms: reads metrics and logs, proposes a "
        "root cause candidate, defers all remediation to a human or the runbook agent."
    ),
)

5. Ένα entrypoint του AgentCore Runtime τον τυλίγει. Το BedrockAgentCoreApp προέρχεται από το ξεχωριστό πακέτο bedrock-agentcore, όχι από το ίδιο το Strands: το Strands είναι το framework του agent, το AgentCore είναι το επίπεδο φιλοξενίας, και ο decorator @app.entrypoint είναι η ραφή ανάμεσα στα δύο.

app = BedrockAgentCoreApp()

@app.entrypoint
def invoke(payload: dict) -> dict:
    """AgentCore Runtime entrypoint.
    ...
    """
    prompt = payload.get("prompt")
    if not prompt:
        return {"error": "payload.prompt is required"}

    result = agent(prompt)
    return {"result": str(result)}

if __name__ == "__main__":
    app.run()

Η κλήση agent(prompt) είναι ολόκληρος ο βρόχος του agent από έξω: το Strands στέλνει το prompt και τα tool specs στο Bedrock, παίρνει πίσω είτε μια τελική απάντηση είτε ένα αίτημα tool-use, εκτελεί το ζητούμενο εργαλείο, τροφοδοτεί το αποτέλεσμα πίσω, και επαναλαμβάνει μέχρι το μοντέλο να σταματήσει να ζητά εργαλεία. Τίποτα από αυτόν τον βρόχο δεν είναι κώδικας που κατέχει αυτό το project· είναι κώδικας που αυτό το project θα έπρεπε να είχε γράψει με το χέρι κάτω από την αυτοφτιαγμένη επιλογή που απέρριψε το Μέρος 1.

Σχεδιασμός του system prompt: στοιχεία πριν τα συμπεράσματα

Ένας triage agent που ακούγεται σίγουρος είναι πιο επικίνδυνος από έναν που λέει «δεν ξέρω ακόμα», γιατί ένας άνθρωπος που διαβάζει την έξοδό του στις τρεις τα ξημερώματα ενεργεί εξίσου βάσει του τόνου όσο και του περιεχομένου. Το system prompt υπάρχει σχεδόν αποκλειστικά για να αποτρέψει αυτόν τον τρόπο αποτυχίας, όχι για να κάνει τον agent πιο έξυπνο:

1. Στοιχεία πριν τα συμπεράσματα. Κάλεσε cloudwatch_read και logs_read πριν δηλώσεις
   οποιονδήποτε υποψήφιο root cause. Μια υπόθεση που σχηματίζεται πριν κάνεις query σε
   τουλάχιστον ένα metric και ένα log group είναι μαντεψιά, όχι διάγνωση, και δεν πρέπει
   να την παρουσιάσεις ως τέτοια.
2. Ανάφερε το όνομα του metric και το namespace για κάθε ισχυρισμό: πες «το AWS/ApplicationELB
   TargetResponseTime ανέβηκε από 120ms σε 4.8s στα τελευταία 15 λεπτά», όχι «το latency
   ανέβηκε». Ένας αναγνώστης χωρίς πρόσβαση στις κλήσεις εργαλείων σου πρέπει να μπορεί να
   επαληθεύσει κάθε αριθμό που δηλώνεις ξανατρέχοντας το ίδιο query.
3. Δήλωσε ρητά την αβεβαιότητα. ...
4. Καμία εικασία για αιτίες που τα εργαλεία σου δεν μπορούν να δουν. ...
5. Τα άδεια αποτελέσματα είναι ευρήματα. Ένα metric χωρίς datapoints στο query window, ή ένα
   log query που επιστρέφει μηδέν γραμμές, είναι στοιχείο (η αποτυχία είναι σιωπηλή, ή
   ανάντη αυτού του log group), όχι λόγος να ξαναδοκιμάσεις με ευρύτερο παράθυρο μέχρι να
   εμφανιστεί κάτι.
6. Έκλεισε με μια δομημένη περίληψη: την ειδοποίηση, τον/τους υποψήφιο(ους) root cause με
   confidence, τα ακριβή metrics και log queries που έτρεξες, και τι θα έλεγχες στη συνέχεια
   αν είχες μία ακόμα κλήση εργαλείου.

Ο κανόνας δύο κάνει τη μεγαλύτερη δουλειά. Το «ανάφερε το όνομα του metric» ακούγεται σαν στιλιστική προτίμηση, αλλά είναι αυτό που μετατρέπει την έξοδο του agent από έναν ισχυρισμό που ένας άνθρωπος πρέπει να εμπιστευτεί σε έναν ισχυρισμό που ένας άνθρωπος μπορεί να επαληθεύσει σε δεκαπέντε δευτερόλεπτα επικολλώντας το ίδιο CloudWatch query. Ο κανόνας πέντε υπάρχει επειδή η φυσική αποτυχία ενός agent με προϋπολογισμό επαναλήψεων είναι να συνεχίζει να διευρύνει το χρονικό παράθυρο ή να αλλάζει το query μέχρι να βρει κάτι, οπότε αυτό το «κάτι» αναφέρεται ως η αιτία ακόμα κι όταν είναι άσχετο. Ένα άδειο αποτέλεσμα είναι δεδομένο. Το να το αντιμετωπίζει κανείς ως αδιέξοδο προς αναφορά, αντί ως έναυσμα για να συνεχίσει το ψάρεμα, είναι αυτό που εμποδίζει τον agent από το να κατασκευάζει μια διάγνωση από θόρυβο.

Δύο εργαλεία, απλή Python, χωρίς Gateway ακόμα

Η αρχιτεκτονική στόχος από το Μέρος 1 βάζει κάθε εργαλείο πίσω από το AgentCore Gateway: συμβατό με MCP, με κεντρικό scoping IAM, μία allowlist για τέσσερα εργαλεία σε ολόκληρη την πλατφόρμα. Αυτό είναι το Μέρος 4. Εδώ, με ακριβώς έναν agent και δύο εργαλεία, το Gateway θα ήταν έμμεση κατεύθυνση χωρίς ακόμα τίποτα να δρομολογήσει ανάμεσα. Και τα δύο εργαλεία είναι απλές συναρτήσεις Python με τον decorator @tool που καλεί απευθείας ο agent, και κάνουν και τα δύο το ίδιο πράγμα πριν αγγίξουν την AWS: αναλαμβάνουν τον ρόλο ops-readonly στον στοχευμένο λογαριασμό spoke.

def _assume_ops_readonly(spoke_account_id: str) -> boto3.Session:
    sts = boto3.client("sts", region_name=AWS_REGION, config=_boto_config)
    role_arn = f"arn:aws:iam::{spoke_account_id}:role/{OPS_READONLY_ROLE_NAME}"
    creds = sts.assume_role(
        RoleArn=role_arn,
        RoleSessionName="triage-agent-read",
        ExternalId=SPOKE_EXTERNAL_ID,
        DurationSeconds=900,
    )["Credentials"]
    return boto3.Session(
        aws_access_key_id=creds["AccessKeyId"],
        aws_secret_access_key=creds["SecretAccessKey"],
        aws_session_token=creds["SessionToken"],
        region_name=AWS_REGION,
    )

Δεκαπέντε λεπτά, όχι το ανώτατο όριο της μίας ώρας που επιτρέπει η trust policy του ops-readonly: μια κλήση εργαλείου που ακόμα χρειάζεται credentials μετά από δεκαπέντε λεπτά έχει κολλήσει σε κάτι άλλο, και ένα credential με μικρότερη διάρκεια ζωής συρρικνώνει την ακτίνα έκρηξης αν ποτέ διαρρεύσει έξω από τη διεργασία. Το cloudwatch_read τυλίγει το get_metric_statistics και επιστρέφει datapoints ως JSON, με το παλαιότερο πρώτο. Το logs_read ξεκινά ένα query CloudWatch Logs Insights και κάνει polling για ολοκλήρωση, με ανώτατο όριο δεκαοκτώ δευτερόλεπτα σε είκοσι προσπάθειες, και εγείρει σφάλμα αντί να επιστρέφει άδειο αποτέλεσμα σε ένα κολλημένο query: ένα log query που κάνει σιωπηλό timeout και αναφέρει μηδέν αντίστοιχες γραμμές διαβάζεται ακριβώς όπως το «δεν βρέθηκαν σφάλματα», που είναι ο ένας τρόπος αποτυχίας που αυτό το εργαλείο δεν επιτρέπεται να έχει. Και τα δύο εργαλεία δέχονται ένα όρισμα spoke_account_id, που σημαίνει ότι το μοντέλο αποφασίζει ποιον λογαριασμό θα κάνει query βάσει του τι του λέει το alarm event, όχι μια τιμή ενσωματωμένη στο deployment.

Τι κερδίζεις από το AgentCore Runtime σε σχέση με Lambda ή ECS

Τίποτα εδώ δεν απαιτεί αυστηρά το AgentCore Runtime. Ένας Strands agent είναι απλή Python· θα μπορούσε να τρέξει σε μια συνάρτηση Lambda ή ένα ECS task με έναν client boto3 και έναν βρόχο. Το AgentCore Runtime, σε γενική διαθεσιμότητα από τις 13 Οκτωβρίου 2025, προσφέρει τρία πράγματα που διαφορετικά θα ήταν προσαρμοσμένη υποδομή:

  • Ένα παράθυρο εκτέλεσης οκτώ ωρών ανά session. Το σκληρό ανώτατο όριο των δεκαπέντε λεπτών του Lambda επιβάλλει είτε έναν πολύ βραχύβιο agent είτε έναν χειροφτιαγμένο μηχανισμό συνέχειας ανάμεσα σε invocations για οτιδήποτε τρέχει περισσότερο, κάτι που μπορεί να συμβεί σε έναν βρόχο διάγνωσης πολλαπλών εργαλείων με retries. Το μοντέλο session του AgentCore Runtime δεν χρειάζεται αυτό το τέχνασμα.
  • Πλήρη απομόνωση session ανάμεσα σε invocations, χωρίς να χτίζεις με το χέρι ένα sandbox ανά session από ξεχωριστά execution contexts Lambda ή ECS tasks.
  • Χρέωση ανά δευτερόλεπτο χωρίς χρέωση για αδρανές CPU. 0,0895 $ ανά vCPU-ώρα και 0,00945 $ ανά GB-ώρα, με χρέωση στο δευτερόλεπτο, με ελάχιστο μνήμης 128MB, και συγκεκριμένα χωρίς χρέωση για τον χρόνο που ένας agent περνά μπλοκαρισμένος περιμένοντας μια απάντηση LLM ή μια κλήση εργαλείου, κάτι που τυπικά είναι 30 έως 70 τοις εκατό του πραγματικού χρόνου ενός session. Ένα ECS task ή ένα provisioned Lambda θα χρέωνε αυτόν τον αδρανή χρόνο ανεξάρτητα από το αν το CPU κάνει κάτι.

Το trade-off είναι πραγματικός περιορισμός, όχι υποσημείωση: το AgentCore Runtime υποστηρίζει μόνο το σύνολο εντολών ARM64, οπότε κάθε dependency με compiled extensions πρέπει να επιλυθεί σε wheel ARM64 ή manylinux, αλλιώς το deployment αποτυγχάνει στην επικύρωση ELF-header κατά το upload. Τα δύο dependencies αυτού του agent, strands-agents και bedrock-agentcore, δεν διανέμουν compiled extensions σήμερα, οπότε δεν δημιουργεί πρόβλημα εδώ. Θα δημιουργήσει πρόβλημα στον πρώτο agent αυτής της σειράς που θα χρειαστεί κάτι σαν έναν native database driver, και η διόρθωση εκείνη τη στιγμή είναι να χτίσεις το deployment artifact με pip install --platform manylinux2014_aarch64 --only-binary=:all: αντί για ένα απλό pip install.

Terraform για το runtime

Το aws_bedrockagentcore_agent_runtime υποστηρίζει δύο αμοιβαία αποκλειόμενους τύπους artifact κάτω από το agent_runtime_artifact: το code_configuration, ένα S3 zip με μια έκδοση runtime και ένα entry point, ή το container_configuration, ένα ECR image URI. Αυτό το module χρησιμοποιεί το code_configuration. Το ίδιο το CLI του AgentCore ορίζει από προεπιλογή για νέους agents το ίδιο μονοπάτι απευθείας ανάπτυξης κώδικα (εσωτερικά ονομάζεται CodeZip) αντί για container build, και με ακριβώς δύο dependencies και κανένα system package για εγκατάσταση, ένα Dockerfile θα ήταν τελετουργία που αυτός ο agent δεν χρειάζεται ακόμα. Ένας μελλοντικός agent του οποίου τα dependencies χρειάζονται compiling, ή του οποίου το runtime δεν είναι Python, είναι το έναυσμα για να αλλάξεις σε container_configuration, όχι μια προεπιλεγμένη προτίμηση για τον έναν τύπο artifact έναντι του άλλου.

resource "aws_bedrockagentcore_agent_runtime" "triage" {
  agent_runtime_name = "${replace(var.platform_name, "-", "_")}_triage"
  description        = "Incident-triage agent: reads CloudWatch metrics and Logs Insights across spokes, diagnoses, never mutates."
  role_arn           = aws_iam_role.triage_runtime.arn

  agent_runtime_artifact {
    code_configuration {
      entry_point = ["agent.py"]
      runtime     = "PYTHON_3_12"

      code {
        s3 {
          bucket     = aws_s3_bucket.agent_artifacts.id
          prefix     = aws_s3_object.triage_agent_code.key
          version_id = aws_s3_object.triage_agent_code.version_id
        }
      }
    }
  }

  environment_variables = {
    AWS_REGION                  = var.aws_region
    AGENT_INFERENCE_PROFILE_ARN = var.agent_inference_profile_arn
    OPS_READONLY_ROLE_NAME      = var.ops_readonly_role_name
    SPOKE_EXTERNAL_ID           = var.spoke_external_id
  }

  network_configuration {
    network_mode = "PUBLIC"
  }

  protocol_configuration {
    server_protocol = "HTTP"
  }

  tags = merge(var.tags, {
    Agent = "triage"
  })
}

Το network_mode = "PUBLIC" αντί για ένα VPC attachment είναι σκόπιμη επιλογή: οι μόνες εξερχόμενες κλήσεις αυτού του agent είναι η κλήση μοντέλου Bedrock και το cross-account sts:AssumeRole, και τα δύο δημόσια endpoints υπηρεσιών AWS που προσπελαύνονται μέσω HTTPS με αυθεντικοποίηση IAM. Δεν υπάρχει κανένας ιδιωτικός πόρος δικτύου, μια βάση δεδομένων ή ένας εσωτερικός load balancer, με τον οποίο μιλάει απευθείας αυτός ο agent, οπότε ένα VPC attachment θα πρόσθετε κόστος NAT και endpoint για το τίποτα. Η permission policy του execution role έχει scoping σε τρεις κατευθύνσεις που αντικατοπτρίζουν τα τρία πράγματα που επιτρέπεται να αγγίξει στην πραγματικότητα αυτός ο agent: bedrock:InvokeModel στο ARN του inference profile και στα υποκείμενα ARNs foundation-model στα οποία μπορεί να δρομολογήσει (και τα δύο, επειδή το cross-region inference εξουσιοδοτεί τόσο στο επίπεδο profile όσο και στο επίπεδο destination-model, και η απουσία της δεύτερης άδειας αποτυγχάνει μόνο στις κλήσεις που τυχαίνει να δρομολογούνται σε μια περιοχή χωρίς αυτήν, ακριβώς η διαλείπουσα αποτυχία που επισήμανε το Μέρος 2 για την ίδια την πρόσβαση σε μοντέλα)· sts:AssumeRole με scoping στο ακριβές ARN του ops-readonly σε κάθε λογαριασμό spoke που επιτρέπεται να κάνει query αυτός ο agent, χτισμένο από μια λίστα, όχι από ένα wildcard· και s3:GetObject στο δικό του prefix code artifact, τίποτα ευρύτερο.

Μια πρώτη διάγνωση, από την ειδοποίηση στην περίληψη

Μια ειδοποίηση CloudWatch στο AWS/ApplicationELB TargetResponseTime ενεργοποιείται για την υπηρεσία checkout σε έναν λογαριασμό spoke. Ο supervisor agent δεν υπάρχει ακόμα (Μέρος 5), οπότε για αυτό το μέρος ένας άνθρωπος επικολλά το context της ειδοποίησης απευθείας στον agent. Αυτό που επιστρέφει, συμπυκνωμένο:

> cloudwatch_read(spoke_account_id="222222222222",
    namespace="AWS/ApplicationELB", metric_name="TargetResponseTime",
    dimensions={"LoadBalancer": "app/prod-checkout/50dc6c495c0c9188"},
    lookback_minutes=30)
< 30 datapoints, ο μέσος όρος ανεβαίνει από 0.14s σε 4.6s στα τελευταία 12 λεπτά

> cloudwatch_read(spoke_account_id="222222222222",
    namespace="AWS/ApplicationELB", metric_name="HTTPCode_Target_5XX_Count",
    dimensions={"LoadBalancer": "app/prod-checkout/50dc6c495c0c9188"},
    lookback_minutes=30)
< ο αριθμός 5XX σταθερός κοντά στο μηδέν για 18 λεπτά, μετά ανεβαίνει μαζί με το TargetResponseTime

> logs_read(spoke_account_id="222222222222",
    log_group_name="/aws/ecs/prod-checkout",
    query_string='fields @timestamp, @message | filter @message like /timeout|pool/ | sort @timestamp desc',
    lookback_minutes=15)
< 41 γραμμές, κυρίαρχο μήνυμα: "HikariPool-1 - Connection is not available,
  request timed out after 30000ms"

Η περίληψη του agent: το AWS/ApplicationELB TargetResponseTime στο app/prod-checkout ανέβηκε από 140ms σε 4.6s μέσα σε 12 λεπτά, με το HTTPCode_Target_5XX_Count να αρχίζει να ανεβαίνει περίπου έξι λεπτά αφότου ξεκίνησε η άνοδος του latency. Το CloudWatch Logs Insights πάνω στο /aws/ecs/prod-checkout στο ίδιο παράθυρο επιστρέφει 41 γραμμές που ταιριάζουν με timeout σε connection pool, πιθανότερη αιτία: το connection pool της βάσης δεδομένων της υπηρεσίας έχει εξαντληθεί, και τα requests μπαίνουν σε ουρά μέχρι να χτυπήσουν το timeout των 30 δευτερολέπτων του pool, κάτι που εμφανίζεται ως αυξημένο TargetResponseTime πριν γίνει ολοκληρωτικά 5XX. Confidence: μέτρια, όχι υψηλή, γιατί αυτός ο agent δεν έχει κανένα εργαλείο που να μπορεί να διαβάσει τον δικό της αριθμό συνδέσεων της βάσης δεδομένων ή το ρυθμισμένο μέγιστο του pool, οπότε δεν μπορεί να επιβεβαιώσει ότι το pool είναι πράγματι γεμάτο έναντι, για παράδειγμα, μιας downstream εξάρτησης που κρατά συνδέσεις ανοιχτές περισσότερο από το συνηθισμένο. Προτεινόμενος επόμενος έλεγχος: τα metrics σύνδεσης βάσης δεδομένων του runbook agent, μόλις υπάρξει αυτός ο agent, ή ένας άνθρωπος που ελέγχει απευθείας τον τρέχοντα αριθμό ενεργών συνδέσεων του pool.

Αυτή η τελευταία παράγραφος είναι οι κανόνες του system prompt να λειτουργούν όπως προβλέπεται, όχι μια επιφύλαξη που προστέθηκε για το άρθρο. Ο agent έχει πραγματικά στοιχεία για μια πραγματική υπόθεση, αναφέρει τα ακριβή metrics και query πίσω από αυτήν, και σταματά ακριβώς στο όριο του τι μπορούν πραγματικά να δουν τα δύο εργαλεία του, ονομάζοντας το κενό αντί να μαντεύει πάνω του.

Τρόποι αποτυχίας που πρέπει να προσέχεις

Τρία πράγματα αξίζει να γνωρίζεις πριν αυτός ο agent τρέξει ενάντια σε μια πραγματική ειδοποίηση. Πρώτον, μια αποτυχία AssumeRole ενάντια στο ops-readonly, λάθος account ID, ληγμένο external ID, ένα spoke που δεν έχει ακόμα onboarded, πρέπει να εμφανίζεται ως «δεν μπόρεσα να διαβάσω αυτόν τον λογαριασμό» στην τελική περίληψη, όχι ως μια σιωπηλά παραλειφθείσα κλήση εργαλείου που το μοντέλο παρακάμπτει συλλογιζόμενο από τη μία πηγή δεδομένων που πέτυχε· μια μερική διάγνωση που παρουσιάζεται με την ίδια βεβαιότητα όπως μια πλήρης είναι χειρότερη από καμία διάγνωση. Δεύτερον, το timeout των δεκαοκτώ δευτερολέπτων του Logs Insights είναι πραγματικό ανώτατο όριο: ένα query ενάντια σε ένα log group υψηλού όγκου με ευρύ φίλτρο μπορεί νόμιμα να πάρει περισσότερο χρόνο, και η διόρθωση είναι ένα πιο στενό query (στενότερο χρονικό παράθυρο, πιο συγκεκριμένο φίλτρο) από το μοντέλο, όχι ένα μεγαλύτερο timeout που μετατρέπει μια κολλημένη κλήση εργαλείου σε κολλημένη κλήση agent. Τρίτον, το χαμηλό temperature μειώνει την ποικιλία διατύπωσης αλλά δεν εγγυάται ότι το μοντέλο καλεί και τα δύο εργαλεία πριν απαντήσει· ο κανόνας ένα του system prompt είναι ο πραγματικός μηχανισμός επιβολής, και αξίζει να τον δοκιμάσεις ενάντια σε ειδοποιήσεις σκόπιμα σχεδιασμένες να δελεάσουν μια συντόμευση, μια ειδοποίηση της οποίας μόνο το όνομα υπονοεί έντονα μια αιτία, για να επιβεβαιώσεις ότι ο agent συνεχίζει να κάνει query πριν καταλήξει σε συμπέρασμα.

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

Το πλήρες agent.py και το πλήρες module terraform/10-agent-runtime/, συμπεριλαμβανομένων των εγγράφων πολιτικής IAM που κόπηκαν από τα αποσπάσματα παραπάνω, ζουν στο συνοδευτικό repository στο github.com/flightlesstux/agents-on-call. Για την πλευρά βάσεων δεδομένων και υποδομής της λειτουργίας πλατφορμών σαν αυτή σε κλίμακα, οι σημειώσεις πεδίου είναι στο ercan.cloud, και ο κόμβος είναι στο ercanermis.com.