在 Gemini 平台上构建受治理的自我进化 AI 智能体

自我进化型人工智能的兴起The Emergence of Self-Evolving AI

随着企业云平台扩展以服务数百万并发用户，紧耦合的微服务会引发连锁故障模式，而静态运行手册或阈值告警都无法预见这些故障。在黑色星期五闪购这类高强度事件期间，站点可靠性工程师（SRE）面临着严峻的现实：必须在几秒内诊断出嘈杂的分布式遥测数据，否则就要承受级联宕机造成的损失，每分钟高达数百万美元。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.

尽管生成式 AI 副驾加快了代码编写和日志摘要的生成，但 AI 智能体仍难以可靠地修复线上生产故障。正在应对连接池资源耗尽的值班工程师，不需要一个只会提供故障排查建议或提交未经验证、可能无法解决根本原因的拉取请求的 AI 智能体；他们需要的是一个受治理、能够自我演进的 AI 系统，能够：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:

1. 实时诊断缓存层和数据库层之间的分布式根本原因，
   Diagnose distributed root causes across cache and database tiers in real time,
2. 通过综合生成、验证并即时将可执行的缓解工具挂载到实时服务器中间件中，实现自我修补，
   Self-patch by synthesizing, verifying, and mounting executable mitigation tools into live server middleware on the fly,
3. 通过计算每项行动的边际贡献进行自我批判，以区分有效的修复措施与有害的条件反射，
   Self-critique by computing the marginal credit of every action to separate effective fixes from harmful reflexes,
4. 通过将经密码学签名的操作不变量提炼到语义记忆中来加以记忆，从而降低相同故障再次发生的可能性，并
   Remember by distilling cryptographically signed operational invariants into semantic memory to reduce the chance of identical failures recurring, and
5. 通过在内存中动态重构自身的多智能体层级结构，并经人工审批，以应对未来的激增。
   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.

在这个 Google Cloud 研究参考架构中（代号 Project Chrysalis），我们展示了三项基础性研究突破如何结合为统一的生产级架构，并可在 Gemini 平台和 Agent Development Kit (ADK) 上运行。在模拟的黑色星期五缓存击穿故障中，这一受治理的架构将首次缓解所需时间从 15 至 45 分钟缩短至 1.8 秒，将 HTTP 5xx 错误率从 72.7% 至 80.0% 降至 0.0%，将 P99 延迟从 519.8 毫秒降至 18.2 毫秒，并在 BigQuery 中以约 0.5 毫秒评估了 400 种反事实流量策略。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.

至关重要的是，这种自我演进架构并非不受约束的“黑箱”。为确保智能体安全、可靠、保持一致并能遏制异常行为，其每项自主操作都受到 Google Cloud 深度防御安全体系的加密约束：Model Armor 用于净化传入的遥测数据，防范提示注入和数据泄露；Google Cloud Key Management Service (Cloud KMS) 与 Binary Authorization 中间件用于对合成补丁进行加密签名，并阻止未经验证的代码被加载；Open Policy Agent (OPA) Policy Controller 用于执行严格的 SLA 防护规则，防止智能体自身引发服务中断；双人托管的人机协同 (HITL) 治理机制则要求在对智能体层级作出任何永久性变更前，必须获得 SRE 的明确批准。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. 事件：黑色星期五缓存惊群，以及智能体为何必须自我进化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:

1. 入口流量激增：限时促销导致针对冷库存键的并发结账请求骤然增加。
   The Ingress Surge: A flash promotion drives a sudden burst of concurrent checkout requests across cold inventory keys.
2. 缓存驱逐：Google Cloud Memorystore（Redis）在严格的最近最少使用（LRU）内存限制下驱逐冷键，导致缓存命中率降至零。
   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.
3. 连接池耗尽：未缓存的流量会直接涌向 Google Cloud SQL。一旦 PostgreSQL 连接池达到容量上限，传入的查询就会排队等待，直至超过超时阈值，导致服务开始大范围返回 HTTP 500 错误。
   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.
4. 致命的“凌晨 3 点恐慌反射”：在运维压力下，人类响应人员和未经训练的 LLM 都会本能地尝试重启数据库连接池。在真实流量惊群期间，断开连接会锁住数据库内核，使尾延迟飙升至近十倍，并令错误率逼近全面宕机。
   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

传统 AI 代理在部署时便已定型，使用固定的系统提示和预先注册的工具。当出现新型基础设施瓶颈时，自我进化的 AI 架构会在运行时合成针对具体情况的缓解工具，以评估每项干预对遥测数据的影响，并将经过验证的防护措施编纂成规程，供未来事件参考。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:

• 自主自我修补（工具合成）：当智能体诊断出数据库资源匮乏是由未限流的入口流量激增所致，并意识到自己缺少内置的流量整形工具时，它会即时编写自己的中间件补丁（基于内存的令牌桶限流器），验证其抽象语法树（AST），使用 Cloud KMS 对其签名，并将其直接热挂载到 API 网关中。
  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.
• 认知记忆与组织自我重构：为降低再次发生服务中断的可能性，该智能体将一条带签名的运维原则写入向量记忆，禁止在缓存惊群期间重启数据库。随后，它在 RAM 中修改自身的多智能体拓扑，在主管智能体之下设立一个常驻的流量整形专家智能体，以便在未来流量激增时，先对流量进行整形，再让其抵达数据库。
  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. 自我进化 AI 的三大研究支柱2. The Three Research Pillars of Self-Evolving AI

自我进化型云代理是应用研究的一个活跃领域，旨在通过整合 Google Cloud 上的三大研究支柱，解决 SRE 三难困境（平衡探索安全性、结构适应性和多步信用分配）：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. 无服务器反事实模拟（Dream-RSI）：挑战：在生产环境中测试未经验证的限流参数，可能会限制合法收入，或再次引发故障。机制：将生产请求跟踪数据导出到 Google BigQuery，随后引擎以亚毫秒级的向量化内存扫描方式，重放数百种候选令牌桶配置，从而离线识别帕累托最优策略。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. 三层协同进化（APEX）：挑战：单层提示调优只能提供脆弱的临时补丁，而不受约束的代码自我修改则可能导致系统不稳定。机制：智能体进化被划分为三个受治理的时间尺度：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:

• 第 1 层（临时热修补）：生成并挂载驻留内存的中间件工具，在几秒钟内止住正在发生的故障。
  Layer 1 (Ephemeral Hotpatching): Synthesizes and mounts in-memory middleware tools to halt active outages in seconds.
• 第 2 层（原则提炼）：将经 Cloud KMS 签名的经验编码到 Agent Platform Vector Search 中，从而在未来的告警中阻止禁忌操作。
  Layer 2 (Principle Distillation): Encodes Cloud KMS-signed lessons into Agent Platform Vector Search so contraindicated actions are blocked on future alerts.
• 第 3 层（拓扑重构）：将永久性专业子代理纳入当前运行的多代理有向无环图（DAG）。
  Layer 3 (Topology Rewiring): Commissions permanent specialist sub-agents into the active multi-agent Directed Acyclic Graph (DAG).

3. 步骤级 Shapley 归因（AgentEvolver）：挑战：在混乱的故障事件中，多个干预措施会依次发生；粗粒度的结果奖励无法区分哪一步修复了服务、哪一步造成了附带损害。机制：AgentEvolver 根据干预前后的遥测数据变化（P99 延迟、HTTP 5xx 率和数据库连接池饱和度），计算每个执行阶段的边际 Shapley 贡献，从而将有效补丁与错误补丁区分开来。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. 四阶段参考演练：自我进化实战演示3. The 4-Phase Reference Walkthrough: Self-Evolution in Action

我们在 Gemini 平台上将这一架构实现为交互式应用。上图展示了生产目标服务、Agent 开发套件（ADK）多智能体平面、自我演进引擎和纵深防御治理流水线之间的闭环工作流。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:

阶段 1：入口流量故障与 SRE 基线Phase 1: Ingress Outage & SRE Baseline

• 发生情况：在完成 5 个请求的预热基线后，50 个请求并发的闪购流量激增，冲击了 15 个冷门库存键。
  What Happens: Following a 5-request warm baseline, a 50-request concurrent flash-sale surge hits 15 cold inventory keys.
• 系统影响：Memorystore 命中率从 100% 降至 0.0%，Cloud SQL 连接池达到 100% 饱和（2/2 个活动连接均被锁定），P99 延迟飙升至 312.8 至 519.8 毫秒，HTTP 500 错误率升至 72.7% 至 80.0%（40 次检出失败）。
  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).

阶段 2：ADK 快速循环分诊与治理型 APEX 第 1 层热补丁Phase 2: ADK Fast-Loop Triage & Governed APEX Layer 1 Hotpatch

• 发生情况：Model Armor 检查传入的告警负载并拦截提示注入后，遥测告警会唤醒由 Gemini 4 Argon 提供支持的 Agent Development Kit (ADK) Supervisor Router Agent。
  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.

• 系统影响：在第二轮 50 个请求的流量激增期间，HTTP 500 错误率从 100% 降至 0.0%，Cloud SQL 连接池饱和率从 100% 降至 0%，P99 延迟恢复至 18.2 毫秒，多余的突发流量通过 HTTP 429 干净地限流（40 个请求被限流，10 个由预热缓存提供服务）。
  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).

阶段 3：AgentEvolver 归因与二级 HITL 内存中拓扑重构Phase 3: AgentEvolver Attribution & Tier-2 HITL In-Memory Topology Rewiring

• 发生情况：AgentEvolver 信用归因引擎审计了事故处理过程中的执行跨度，对数据库重启这一惯性反应进行惩罚（该操作导致延迟飙升至 3,800 毫秒），并奖励令牌桶中间件补丁（+0.97 信用值）。
  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).
• 原则蒸馏：APEX 第 2 层原则蒸馏器将一条不可变操作规则签名并编入索引，存入 Gemini Platform Vector Search：“缓存淘汰惊群：禁止重启数据库；采用令牌桶负载削减。”
  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 双人托管审批：系统不再依赖临时热补丁，而是提议进行 Tier-2 结构性更新：启用一名常驻的流量整形专家智能体。执行将在 UI 中暂停，并显示双人托管 SRE 审批弹窗，要求值班 SRE 明确签字批准。
  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.
• 内存中的 ADK 图重连：在生产级云运行时环境（Google Kubernetes Engine、Cloud Run）中，容器映像不可变；在故障期间实时改写磁盘上的源文件会破坏容器完整性，并需要进行影响服务的重启。相反，在签发加密的人类审批令牌后，APEX Layer 3 云拓扑适配器会执行内存中的有向无环图（DAG）更新：
  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:

1. 在 RAM 中实例化流量整形专家代理，并为其配备专用的速率限制、队列深度检查和令牌补充工具。
   Instantiates the Traffic Shaping Specialist Agent in RAM with dedicated rate-limiting, queue-depth inspection, and token-replenishment tools.
2. 将专业代理直接添加到 Supervisor Router Agent 的活动子代理图中，作为与 Diagnostic Agent 并行的同级节点（不修改诊断节点）。
   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).
3. 更新 supervisor 的路由指令，并在内存中重新绑定正在运行的 Google ADK Runner，实现零停机、零容器重启。
   Updates the supervisor's routing instructions and re-binds the live Google ADK Runner in memory with zero downtime and zero container restarts.

第四阶段：Google BigQuery 反事实重放与好奇心混沌验证Phase 4: Google BigQuery Counterfactual Replay & Curiosity Chaos Verification

• 发生的情况：事件请求轨迹流入 Google BigQuery，BigQuery 反事实回放引擎会针对不同的令牌容量和补充速率执行 400 次反事实策略模拟。
  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.
• 亚毫秒级发现与混沌验证：向量化的内存中轨迹重放在约 0.5 毫秒内完成全部 400 轮扫描，并找出帕累托最优策略（容量为 5 个 token、速率为 5.0 req/s、5xx 错误为零）。最后，Curiosity 混沌红队智能体在隔离的影子沙箱中对演进后的系统进行压力测试：清空 100% 的缓存，并发起 200 个并发请求。新接入的流量整形专家智能体成功承受了流量激增，HTTP 500 错误为零，数据库负载峰值仅为 13%，证明了该架构具备韧性。
  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. 企业云治理：纵深防御4. Enterprise Cloud Governance: Defense-in-Depth

治理原则：AI 代理可以自主调整其运维策略以维护系统健康，但其执行权限受到不可篡改的企业策略、硬件密钥溯源机制以及明确的人类监管的密码学约束。

^{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:

1. 入口与 AST 沙箱净化：在任何遥测告警进入智能体推理循环之前，Model Armor 会筛查载荷中的对抗性提示注入，并对敏感数据进行脱敏。当智能体生成缓解代码时，AST 沙箱访问器会在编译前解析语法树，以阻止未经授权的系统调用和任意执行入口。
   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.
2. 加密溯源与二进制授权：经过验证的代码制品和提炼出的原则均使用 Google Cloud KMS 非对称密钥签名。API Gateway 中间件会强制执行严格的 Binary Authorization 检查；除非内存中的速率限制器通过企业密钥环验证其加密签名，否则拒绝挂载该限制器。
   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.
3. 策略即代码与双人监管的 HITL 升级机制：开放策略代理（OPA）策略控制器会强制执行严格的 SLA 防护规则（例如要求补充速率 >= 10.0 req/s，防止代理意外导致自身拒绝服务）。对于风险较高的 Tier-2 结构性更新（例如重新连接 ADK 代理图），系统会触发双人监管的人工介入（HITL）关卡，暂停执行，直至获授权的 SRE 使用加密令牌批准变更。
   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.
4. 防篡改审计能力：每次告警净化、AST 检查、KMS 签名、策略裁决和 HITL 审批都会向 Google Cloud Logging 写入结构化记录，确保端到端合规性和取证可追溯性。
   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. 演示模拟中的实证结果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:

6. 在 GitHub 和 Google Cloud 上探索参考架构6. Explore the Reference Architecture on GitHub & Google Cloud

请查看以下参考实现和 Google Cloud 文档：Explore the reference implementation and Google Cloud documentation below:

• 参考架构与演示的 GitHub 代码。
  Github Code for the Reference Architecture & Demo.
• 在 Gemini Platform 上构建并投入生产。
  Build and productionize on Gemini Platform.
• Governance & Data: Cloud KMS • Model Armor • Google BigQuery • Cloud Logging