Google Cloud 闡述 Gemini 平台上的受治理自我演進 AI 智能體架構

OCT. 22, 2026

The Emergence of Self-Evolving AI

As enterprise cloud platforms scale to serve millions of concurrent users, tightly coupled microservices introduce cascading failure modes that no static runbook or threshold alert can anticipate. During high-velocity events like a Black Friday flash sale, Site Reliability Engineers (SREs) face an unforgiving reality: diagnose noisy distributed telemetry in seconds, or suffer cascading outages costing millions of dollars per minute.

While generative AI copilots have accelerated code authoring and log summarization, AI agents struggle to reliably remediate live production outages. An on-call engineer battling connection pool starvation does not need an AI agent offering troubleshooting tips or unverified pull requests that might not fix the root cause; they need a governed, self-evolving AI system that can:

Diagnose distributed root causes across cache and database tiers in real time,
Self-patch by synthesizing, verifying, and mounting executable mitigation tools into live server middleware on the fly,
Self-critique by computing the marginal credit of every action to separate effective fixes from harmful reflexes,
Remember by distilling cryptographically signed operational invariants into semantic memory to reduce the chance of identical failures recurring, and
Re-architect by dynamically rewiring its own multi-agent hierarchy in memory with human sign-off to absorb future surges.

This paradigm is Self-Evolving AI.

In this Google Cloud research reference architecture, codenamed Project Chrysalis, we demonstrate how three foundational research breakthroughs combine into a unified, production-grade architecture that can run on Gemini platform and the Agent Development Kit (ADK). Across simulated Black Friday cache-stampede outages, this governed architecture cut time-to-first-mitigation from 15 to 45 minutes down to 1.8 seconds, reduced HTTP 5xx error rates from 72.7% to 80.0% down to 0.0%, dropped P99 latency from 519.8 ms to 18.2 ms, and evaluated 400 counterfactual traffic policies in BigQuery in ~0.5 ms.

Crucially, this self-evolving architecture does not operate as an unconstrained "black box". To ensure the agent remains secure, reliable, aligned, and contained against rogue behavior, every autonomous action is cryptographically bounded by Google Cloud's defense-in-depth security stack: Model Armor to sanitize incoming telemetry against prompt injections and data leaks; Google Cloud Key Management Service (Cloud KMS) and Binary Authorization middleware to cryptographically sign synthesized patches and block unverified code from mounting; Open Policy Agent (OPA) Policy Controller to enforce strict SLA guardrails that prevent self-inflicted outages; and Dual-Custody Human-in-the-Loop (HITL) governance to require explicit SRE sign-off before any permanent changes are made to the agent hierarchy.

1. The Incident: The Black Friday Cache Stampede & Why Agents Must Self-Evolve

To see why static playbooks and advisory copilots fail under pressure, consider a classic distributed failure cascade:

The Ingress Surge: A flash promotion drives a sudden burst of concurrent checkout requests across cold inventory keys.
The Cache Eviction: Google Cloud Memorystore (Redis) evicts cold keys under strict Least Recently Used (LRU) memory limits, collapsing the cache hit ratio to zero.
Connection Pool Starvation: Uncached traffic cascades directly into Google Cloud SQL. Once the PostgreSQL connection pool saturates, incoming queries queue past timeout thresholds and the service begins failing with widespread HTTP 500 errors.
The Fatal "3:00 AM Panic Reflex": Under operational stress, both human responders and naive LLMs instinctively try to restart the database connection pool. In a live stampede, dropping connections locks the database kernel, spikes tail latency nearly tenfold, and drives error rates toward total outage.

How a Self-Evolving Agent Adapts Over Time

Conventional AI agents are frozen at deployment with fixed system prompts and pre-registered tools. When a novel infrastructure bottleneck strikes, a self-evolving AI architecture extends those baseline capabilities by synthesizing situation-specific mitigation tools at runtime, scoring the telemetry impact of every intervention, and codifying verified guardrails for future incidents.

For true autonomous resilience, the agent itself must evolve based on empirical evidence of what worked and what failed:

Autonomous Self-Patching (Tool Synthesis): When the agent diagnoses that database starvation is driven by an unthrottled ingress surge and realizes it lacks a built-in traffic-shaping tool, it writes its own middleware patch on the fly (an in-memory token-bucket rate limiter), validates its Abstract Syntax Tree (AST), signs it with Cloud KMS, and hot-mounts it directly into the API Gateway.
Causal Self-Critique (Evaluating What Worked vs. What Failed): After stabilizing the outage, the agent evaluates the telemetry delta of every action taken during the incident. It mathematically penalizes the database restart reflex because it worsened latency, while rewarding its synthesized rate limiter for eliminating server errors.
Cognitive Memory & Organizational Self-Rewiring: To reduce the likelihood of a repeat outage, the agent writes a signed operational principle into vector memory that blocks database restarts during cache stampedes. It then modifies its own multi-agent topology in RAM, commissioning a permanent Traffic Shaping Specialist Agent under the supervisor agent so future surges are shaped before they reach the database.

2. The Three Research Pillars of Self-Evolving AI

Self-evolving cloud agents are an active area of applied research focused on resolving the SRE Trilemma (balancing exploration safety, structural adaptability, and multi-step credit assignment) by unifying three research pillars on Google Cloud:

1.Serverless Counterfactual Simulation (Dream-RSI):
Challenge: Testing unvetted rate-limiting parameters in live production risks throttling legitimate revenue or re-triggering outages.
Mechanism: Production request traces are exported to Google BigQuery, where the engine replays hundreds of candidate token-bucket configurations in sub-millisecond vectorized memory sweeps to identify Pareto-optimal policies offline.

2. Tri-Level Co-Evolution (APEX):
Challenge: Single-layer prompt tuning provides fragile band-aids, while unconstrained code self-modification risks system instability.
Mechanism: Agent evolution is separated into three governed timescales:

Layer 1 (Ephemeral Hotpatching): Synthesizes and mounts in-memory middleware tools to halt active outages in seconds.
Layer 2 (Principle Distillation): Encodes Cloud KMS-signed lessons into Agent Platform Vector Search so contraindicated actions are blocked on future alerts.
Layer 3 (Topology Rewiring): Commissions permanent specialist sub-agents into the active multi-agent Directed Acyclic Graph (DAG).

3. Step-Level Shapley Attribution (AgentEvolver):
Challenge: During chaotic incidents, multiple interventions occur in sequence; coarse outcome rewards cannot isolate which step healed the service and which caused collateral damage.
Mechanism: AgentEvolver computes marginal Shapley credit across each execution span using pre- and post-intervention telemetry deltas (P99 latency, HTTP 5xx rate, and database pool saturation), isolating beneficial patches from erroneous ones.

3. The 4-Phase Reference Walkthrough: Self-Evolution in Action

Architecture_diagram

We implemented this architecture as an interactive application on Gemini platform. The diagram above illustrates the closed-loop workflow across the Production Target Service, Agent Development Kit (ADK) Multi-Agent Plane, Self-Evolution Engine, and Defense-in-Depth Governance Pipeline.

Each phase of the interactive demonstration showcases a distinct stage of the agent's self-evolution:

Phase 1: Ingress Outage & SRE Baseline

What Happens: Following a 5-request warm baseline, a 50-request concurrent flash-sale surge hits 15 cold inventory keys.
System Impact: Memorystore hit ratio drops from 100% to 0.0%, the Cloud SQL connection pool hits 100% saturation (2/2 active connections locked), P99 latency spikes to 312.8 to 519.8 ms, and HTTP 500 errors jump to 72.7% to 80.0% (40 failed checkouts).

Phase 2: ADK Fast-Loop Triage & Governed APEX Layer 1 Hotpatch

What Happens: Telemetry alerts wake the Agent Development Kit (ADK) Supervisor Router Agent powered by Gemini 4 Argon, after Model Armor inspects the incoming alert payload to block prompt injections.
Autonomous Self-Patching: Diagnosing pool exhaustion, the APEX Layer 1 Hotpatch Synthesizer generates an in-memory token-bucket rate limiter (10-token capacity, 40.0 req/s replenishment). Before mounting into the API Gateway middleware, the patch passes three automated governance gates:
1. AST Sandbox Visitor verifies that forbidden system modules and dynamic execution sinks are absent.
2. OPA Policy Controller confirms the replenishment rate meets the enterprise minimum SLA (>= 10.0 req/s).
3. Cloud KMS & Binary Authorization signs the artifact digest (EC_SIGN_P256_SHA256) and verifies key provenance at the middleware boundary.

System Impact: Across a second 50-request surge, HTTP 500 errors drop to 0.0%, Cloud SQL pool saturation drops from 100% to 0%, P99 latency recovers to 18.2 ms, and excess burst traffic is cleanly shed via HTTP 429 (40 requests throttled, 10 served from warm cache).

Phase 3: AgentEvolver Attribution & Tier-2 HITL In-Memory Topology Rewiring

What Happens: The AgentEvolver Credit Attribution Engine audits the incident execution spans, penalizing the database restart reflex ( after spiking latency to 3,800 ms) and rewarding the token-bucket middleware patch (+0.97 credit).
Principle Distillation: The APEX Layer 2 Principle Distiller signs and indexes an immutable operational rule into Gemini Platform Vector Search: "Cache eviction stampede: database restart contraindicated; apply token-bucket load shedding."
Tier-2 Dual-Custody Approval: Rather than relying on temporary hotpatches, the system proposes a Tier-2 structural update: commissioning a permanent Traffic Shaping Specialist Agent. Execution pauses in the UI and presents a Dual-Custody SRE Approval Modal requiring explicit sign-off from the on-call SRE.
In-Memory ADK Graph Rewiring:
In production cloud runtimes (Google Kubernetes Engine, Cloud Run), container images are immutable; rewriting source files on disk during a live outage violates container integrity and requires disruptive restarts. Instead, once issued a cryptographic human-approval token, the APEX Layer 3 Cloud Topology Adapter executes an in-memory Directed Acyclic Graph (DAG) update:

Instantiates the Traffic Shaping Specialist Agent in RAM with dedicated rate-limiting, queue-depth inspection, and token-replenishment tools.
Appends the specialist agent directly to the Supervisor Router Agent's active sub-agent graph as a parallel peer alongside the Diagnostic Agent (leaving the diagnostic node unmodified).
Updates the supervisor's routing instructions and re-binds the live Google ADK Runner in memory with zero downtime and zero container restarts.

Phase 4: Google BigQuery Counterfactual Replay & Curiosity Chaos Verification

What Happens: Incident request traces flow into Google BigQuery, where the BigQuery Counterfactual Replay Engine executes 400 counterfactual policy simulations across token capacities and replenishment rates.
Sub-Millisecond Discovery & Chaos Proof: Vectorized in-memory trace replay completes all 400 sweeps in ~0.5 milliseconds, identifying the Pareto-optimal policy (5-token capacity, 5.0 req/s rate, zero 5xx errors). Finally, the Curiosity Chaos Red-Team Agent stress-tests the evolved system in an isolated shadow sandbox by purging 100% of the cache and firing 200 concurrent requests. The newly wired Traffic Shaping Specialist Agent absorbs the surge with 0 HTTP 500 errors and 13% max DB load, certifying the architecture as resilient.

4. Enterprise Cloud Governance: Defense-in-Depth

^{The Governing Principle:} ^{An AI agent may autonomously evolve its operational tactics to defend system health, but its authority to execute is cryptographically bounded by immutable enterprise policies, hardware key provenance, and explicit human custody.}

To deploy self-evolving agents safely in production, our architecture enforces an unbroken four-gate defense-in-depth chain of custody. Every synthesized patch, distilled memory, and topology update must clear four sequential verification boundaries:

Ingress & AST Sandbox Sanitization: Before any telemetry alert enters the agent reasoning loop, Model Armor screens payloads for adversarial prompt injections and redacts sensitive data. When the agent synthesizes mitigation code, an AST Sandbox Visitor parses the syntax tree before compilation to block unauthorized system calls and arbitrary execution sinks.
Cryptographic Provenance & Binary Authorization: Validated code artifacts and distilled principles are signed using Google Cloud KMS asymmetric keys. API Gateway middleware enforces a strict Binary Authorization check, refusing to mount any in-memory rate limiter unless its cryptographic signature verifies against the enterprise key ring.
Policy-as-Code & Dual-Custody HITL Escalation: An Open Policy Agent (OPA) Policy Controller enforces rigid SLA guardrails (such as requiring replenishment rates >= 10.0 req/s so an agent cannot accidentally self-inflict a denial of service). Higher-risk Tier-2 structural updates, such as rewiring the ADK agent graph, trigger a Dual-Custody Human-in-the-Loop Gate, pausing execution until an authorized SRE approves the change with a cryptographic token.
Tamper-Evident Auditability: Every alert sanitization, AST check, KMS signature, policy verdict, and HITL approval emits structured records to Google Cloud Logging, guaranteeing end-to-end compliance and forensic traceability.

5. Empirical Results in the demo simulation

Across automated evaluations of Black Friday cache-stampede workloads, the self-evolving architecture delivered decisive operational gains over both manual triage and static advisory copilots:

Demo results

6. Explore the Reference Architecture on GitHub & Google Cloud

Explore the reference implementation and Google Cloud documentation below:

Github Code for the Reference Architecture & Demo.
Build and productionize on Gemini Platform.
Governance & Data: Cloud KMS • Model Armor • Google BigQuery • Cloud Logging