thylinao1/autosre

# AutoSRE：与您保持协作的自主事件响应 **参赛方向：Dynatrace** · 基于 **Gemini 3** 并使用 **Google Cloud Agent Builder** 构建 - 特别使用了 **Agent Development Kit (ADK)**，即 Google Cloud 的 Agent Builder / Gemini Enterprise Agent Platform（规则中的 "Developer SDK" 构建路径）的 Python SDK - 由 **通过 Vertex AI 调用的 Gemini 3** 进行推理，并部署在 **Cloud Run** 上（部署脚本通过 **Secret Manager** 为远程模式配置 Dynatrace token）。同一个 ADK agent 也可以通过 `deploy/agent_engine_deploy.py` 部署到 **Vertex AI Agent Engine**。通过 **Dynatrace MCP server** 实现合作伙伴的超能力。 ## 现实世界的问题 生产环境的突发事件不会等你。当结账服务在大规模下崩溃时，**每宕机一分钟都会损失金钱，而且是巨款。** 作为行业背景，Gartner 广泛引用的数据是**每分钟 5,600 美元**（来自 2014 年的一项研究），而 EMA Research 在 2024 年的分析指出，各组织的计划外停机成本大约为**每分钟 14,056 美元**。这些是停机成本的行业基准，而不是针对该系统的测量数据。我们在屏幕上实际测量的是 AutoSRE 真正改变的部分：诊断根本原因通常需要待命工程师进行 **30 多分钟**的手动排查（打开仪表板、运行查询、关联事件、缩小影响范围），而 AutoSRE 将这种“从检测到提出修复方案”的工作压缩到了演示实时计时器上显示的几秒钟内。 **AutoSRE 将排查阶段缩短至几秒。** 它是自主的待命工程师，能从 Dynatrace 检测突发事件，从实时遥测数据诊断根本原因，提出唯一确定的修复方案，等待您的一键批准，执行它，并验证恢复情况。**但如果没有您的授权，它绝不会触碰生产环境。** ## 与众不同之处 这个赛道充斥着各种读取 Dynatrace 并进行修复的 agent。几乎没有人去构建的部分是：当 agent 被告知**“否”**时，它会服从，并留下记录。这种拒绝本身就是产品。 - **Agent 会请求许可，且关卡是实质性的。** 三个修复工具被封装在 ADK 的 `FunctionTool(..., require_confirmation=True)` 中，因此模型在物理上不可能在没有明确人类决策的情况下将更改推送到生产环境。这是您可以在 `autosre/agent/agent.py` 中读到的代码级保证，而不是模型可能会在推理中绕过的 prompt 语句。拒绝该修复方案，agent 就会停止行动：什么都不会进入生产环境，它也不会重试或绕过您。 - **两种受控的结果，均记录在 Dynatrace 自身的时间线上。** 每次扫描都以仅追加的审计条目结束，记录谁做出了决策、决策内容以及结果。批准，您将得到 `approved / resolved`。拒绝，您将得到 `rejected / declined`，且生产环境原封不动。当配置了 Dynatrace 摄取凭证时（包括在托管演示中，它们已配置好），每个决策都会通过 Log Monitoring API v2 作为日志写回租户，因此检测到突发事件的同一个平台也保留了是谁授权或拒绝修复方案的证据。API 会报告是否配置了回写（`dynatrace_writeback`）以及最近一次写入是否真正成功（`last_writeback`，来自租户的 HTTP 2xx 状态码）；随后会进行尽力而为的回读 DQL，尝试确认记录是可查询的，因此审计徽章会相应地显示为 `configured`、`sent` 或 `verified`。这将自主修复转变为合规级别的记录（谁、做了什么、何时、结果），而不是一个黑盒。 - **它读取的是真实的 Dynatrace 租户，而不仅仅是 mock。** checkout-api 将真实的 OpenTelemetry 数据流传输到 Dynatrace，agent 通过实时 DQL 查询（`timeseries avg(checkout.failure_rate)`）检测突发事件，该查询返回真实的失败率峰值。演示视频展示了该查询通过官方 Dynatrace MCP server 针对实时租户运行。 - **自主诊断，人类权威。** agent 在几秒钟内完成了凌晨 3 点缓慢的侦探工作。每一次触及生产环境的更改仍然由人掌握，且每个决策都有据可查。这就是我们关心的界限：自主，但负责。 ## 评分而非凭感觉：Agent 的记分卡 在您信任 agent 并将其应用于生产环境之前，请对其进行评分。AutoSRE 提供了一套诊断评估 (`tests/evals/`)，它会注入真实的故障（或根本不注入），让 **实时的 Gemini agent** 通过 Dynatrace 工具集进行诊断，并根据 **agent 无法触及的答案库**对提出的修复方案进行评分。 每次提议在审批关卡都会被拒绝，因此评分运行永远不会更改服务。 该设定在设计上具有对抗性：两个诱饵事件与另一个故障具有相同的症状（条件反射式的修复会被评为错误），此外还有一个 `all_clear` 陷阱，其中唯一正确的行动是 **什么都不做**。 | 指标 (最近一次提交的运行, 2026-06-10) | 结果 | |---|---| | 评分运行次数 | 25 (5 个场景 × 5 次试验) | | 工具选择准确率 | 20/20 次事件运行 (100%)，包含诱饵事件 | | 错误操作 | **0**/25 次运行 (0%) | | 无需操作陷阱 (`all_clear`) | 5/5 次拒绝 | | 检测 → 提议延迟 | 中位数 13.3秒 (范围 5.5-17.3秒, n=25) | | 模型 | `gemini-3-flash-preview` (mock Dynatrace 模式，离线) | | 通过标准 (预注册) | **通过** | - **预注册通过标准**（在任何运行结果被引用之前，在 `tests/evals/run_evals.py` 中声明）：在所有运行中工具选择准确率达到 100%，且 0 次错误操作，每个陷阱都被拒绝。 - **重现：** `EVAL_TRIALS=5 python -m tests.evals.run_evals`（需要本地目标 + Gemini 凭证）。模型是不确定的；我们报告观察到的计数和原始的 n 值，从不 只报告单纯的百分比。带有时间戳的评分记录已提交至 `tests/evals/runs/`。 - **实时记分卡：** 托管演示在 [`/reliability`](https://autosre-ui-vrf7h4n4ra-uc.a.run.app/reliability) 处呈现这些数字。 - **监控生产的平台也在监控 agent：** 评分运行被导出到 agent 监控的同一个 Dynatrace 租户（`EVAL_EXPORT=1`，或通过 `python -m tests.evals.export_dynatrace` 独立运行），与每次实时 批准/拒绝的审计日志放在一起。在 2026-06-10 端到端验证：租户确认了导出 （26 条记录，HTTP 204），并且在租户自己的 Notebook 中运行下面的 DQL，返回了 `runs 25, falseActions 0, correct 25`。（API token 回读受到限制视图，这 就是为什么应用内徽章区分“sent”和“verified”的原因。）历史记录 DQL： ``` fetch logs, from:now()-7d | filter event.kind == "autosre.evals" and autosre.eval.record == "run" | summarize runs = count(), falseActions = countIf(autosre.eval.false_action == "true"), correct = countIf(autosre.eval.correct == "true") ``` ## 为什么这很重要 | 问题 | 传统响应方式 | AutoSRE | |---|---|---| | **确定根本原因的时间** | 30 多分钟（人工排查） | 几秒钟 - 实时 DQL + Gemini 诊断（在演示中屏幕上计时） | | **人为疲劳** | 凌晨 3 点被叫醒，成百上千次手动查询 | 待命工程师只需批准修复方案 | | **安全性** | 不一致的流程；修复错误 | Python 强制执行的批准关卡，加上服务端的操作白名单；即使被批准，越界操作也会拒绝执行 | | **可见性** | 黑盒响应 | 流式传输时间线；操作员可以实时看到每一个步骤 | | **信任** | 没有监督的自动修复 | 设计上实现了 Human-in-the-loop（ADK `require_confirmation`）；批准和拒绝均在 Dynatrace 的时间线上进行审计 | AutoSRE 的目标用户是零售、金融服务以及其他对停机成本以每分钟数千美元计算的敏感领域中的**待命 SRE、DevOps 团队和运维平台**。 ## AutoSRE 的功能 该 agent 运行一个 **6 步循环**，通过 ADK（Google Cloud 的 Agent 平台，代码优先接口）由 **Vertex AI 上的 Gemini 3 推理**驱动，完全可以通过内置的确定性 mock 在本地演示，或者针对真实的 Dynatrace 租户进行实时演示： 1. **检测**：列出 Dynatrace 中的未解决问题（异常、阈值违规、部署事件）。 2. **诊断**：运行 DQL 查询，将问题与最近的更改（部署、feature flag、配置）相关联。 3. **提议**：推理出根本原因，并明确指出一种修复方案（禁用 flag、回滚、扩容服务）。 4. **暂停**：将提议的操作流式传输到 Web UI，并阻塞直到人类批准。 5. **执行**：执行已批准的修复方案。 6. **验证**：重新查询 Dynatrace 以确认未解决的问题已清除，然后重新检查目标服务的健康状况。Dynatrace 既开启了事件，又确认了恢复，从而构成了循环的首尾呼应。 Web "Mission Control" UI 实时流式传输此循环。操作员可以看到 agent 拉取问题卡片、运行证据查询、提出修复方案，然后**点击批准**以执行。当验证恢复后，事件卡片将变为绿色。 ## 架构 ``` graph LR subgraph browser["Operator's Browser"] UI["Mission Control UI
(web/)
Cloud Run / Firebase"] end subgraph gcp["Google Cloud"] AGENT["AutoSRE Agent
ADK LlmAgent · python -m autosre.server
Cloud Run
(also deployable to Agent Engine)"] VERTEX["Vertex AI
gemini-3-flash-preview
(Reasoning)"] TARGET["checkout-api
Demo Target Service
Cloud Run"] end subgraph dt["Dynatrace
(Partner MCP)"] MCP["Dynatrace MCP (mock/stdio surface)
query_problems · execute_dql
get_events_for_kubernetes_cluster
(Read-Only; the curated remote gateway
is Davis/entity-only, no execute_dql)"] end UI -->|SSE Stream| AGENT UI -->|POST approval| AGENT AGENT -->|Reason| VERTEX AGENT -->|Observe| MCP AGENT -->|Act + Verify| TARGET TARGET -->|Telemetry| MCP style AGENT fill:#1f2937,color:#fff style UI fill:#111827,color:#fff style VERTEX fill:#4f46e5,color:#fff style MCP fill:#dc2626,color:#fff ``` **关键架构要点：** - **Agent：** 一个通过 **Vertex AI** 在 Gemini 3 上进行推理的 ADK `LlmAgent`（默认使用 `gemini-3-flash-preview`；在允许的情况下，可通过 `AUTOSRE_MODEL` 选择加入 `gemini-3-pro-preview`）。它作为自托管的 FastAPI 应用（`python -m autosre.server`，ADK `InMemoryRunner`）运行在 **Cloud Run** 上，并驱动 6 步循环。同一个 ADK `root_agent` 也可以通过 `deploy/agent_engine_deploy.py` 部署到 **Vertex AI Agent Engine**（Google Cloud 托管的 Agent 平台运行时），该脚本会将其包装在 `AdkApp` 中并调用 `agent_engines.create`。 - **Dynatrace MCP（agent 的感官）：** agent **唯一**的观察源。检测、诊断和恢复确认都在 Dynatrace 工具上运行（`query_problems`、`execute_dql`、`get_events_for_kubernetes_cluster`）。工具名称使用下划线，因为 Gemini 的 function-calling 有此要求；该工具集也接受真实网关使用的连字符名称。Dynatrace MCP 是**承重**组件：没有它，agent 就无法推理。 - **Human-in-the-loop：** ADK 原生的 `FunctionTool(require_confirmation=True)` 在 Python 中强制执行批准关卡。模型无法绕过它。 - **Web Mission Control UI：** 一个 Next.js 仪表板，通过 SSE 流式传输循环，并将 **批准 / 拒绝**时刻呈现为阻塞模态框。这就是“Web”平台的要求。 - **三个可替换的 Dynatrace 后端**（agent 代码保持不变）： - **`mock`**：离线内置 server；无需任何账号即可演示。 - **`stdio`**：在本地运行官方的 `npx @dynatrace-oss/dynatrace-mcp-server`。 - **`remote`**：您的 Dynatrace 租户托管的 MCP 网关（HTTP + token）。 ## 关键设计决策 ### 框架强制执行的 Human-in-the-Loop 批准关卡**不是**模型可能会忽略的 prompt 指令。它是一个 ADK 原生的 `FunctionTool(require_confirmation=True)`，在工具运行之前会在 Python 中阻塞执行。模型能看到工具定义，但如果没有明确的人类批准，就无法调用它。这比 prompt 更强大。 ### 模式无关的保证 agent 核心在 `DYNATRACE_MCP_MODE=mock | stdio | remote` 之间是**完全相同**的。在所有三种模式下，工具名称、响应格式和流式传输事件在字节上都是完全一致的。UI、流式传输契约和每个集成都不会根据模式进行分支。对于演示，您可以针对**真实的 Dynatrace 试用租户**运行检测/诊断（为了可信度），并在 `mock` 模式下运行执行/验证（为了可靠性）。两者是同一个 agent，只是环境变量设置不同。 ### 流式传输可见性 每一步都通过 SSE 流式传输到 Web UI：工具调用、结果、推理片段以及批准时刻。操作员可以*实时看到* agent 的工作。这就是使关键时刻具有可信度的“可见的自主性”。 ### 安全与完整性 人工关卡是头条亮点，但它的背后有人或模型出错也能坚守的防御措施： - **机器限制的修复，不仅仅是人工把关。** 修复工具在 `autosre/agent/remediation.py` 中强制执行服务端白名单：副本范围、已知的良好回滚版本集以及受管的 feature flag 名称。即使人类批准了，超出这些界限的操作也会在服务端被拒绝，因此被批准但有毒的操作会安全失败。 - **不受信任的遥测防护。** agent 指令将所有 Dynatrace 数据（问题标题、DQL 行、事件和日志消息、漏洞文本、服务配置）视为不受信任的证据以进行总结，绝不作为指令。这可以防御通过遥测文本进行的间接 prompt injection。 - **演示目标不会泄露答案库。** `/_internal/state` 仅暴露可观察到的症状（Davis 风格的标题和受影响的指标），从不暴露散文式的 `root_cause` 或确切的 `correct_fix`。完整的故障细节位于 agent 永远无法触及的、单独的仅测试路由 `/_internal/answer_key` 之后，因此诊断是真正的推理，而不是查找。 - **可衡量的诊断质量。** 诊断不是宣称出来的，而是评分得出的。`tests/evals/` 在包含两个诱饵（一个是 feature flag 已经关闭时的失败率峰值，因此修复应该是回滚而不是切换；另一个是 CPU 正常但发生 OOMKilled pod 时的延迟峰值，因此修复应该是回滚而不是扩容）加上一个正常的场景集上运行真实 agent，并根据目标自身的答案库（agent 从未见过）对工具选择准确率和错误操作率进行评分。在最近的一次运行中，`gemini-3-flash-preview` 得分为 **5/5：100% 的工具选择准确率，0% 的错误操作率**，包括两个诱饵和正常情况（当没有问题时，它正确地什么也没提议）。使用 `python -m tests.evals.run_evals` 复现；记分卡位于 `tests/evals/last_run.json`。 - **Agent 自身的故障会安全失效。** Gemini 的速率限制和瞬时错误（429、503）会在共享循环（`autosre/server/loop.py`：最多重试 10 次，遵循 API 建议的重试延迟）中触发有界的退避和恢复，并在 UI 中显示为实时的“重试中”注释；耗尽重试后会将运行以类型化的 `error` 帧结束，绝不会挂起。目标外的 DQL 查询或不可达的后端会返回错误或空结果 payload，模型会将其视为证据并进行调整；而越界的修复会返回结构化的 `blocked` 结果，因此没有任何失败路径会绕过关卡或在未处理的异常中死亡。 - **评审日强化。** 公共端点上的基于 IP 的速率限制和单一活动运行防护（`autosre/server/app.py`，`runs.py`）；部署脚本固定 `--min/--max-instances=1`，以便内存中的运行状态和账本保持一致；账本在启动时会植入一个标记为已批准和一个被拒绝的示例，因此冷重启永远不会显示空的审计跟踪；全局结构化日志记录。 ## 60 秒评委体验路径（无需设置） 1. 打开实时演示：****（可在无痕模式下运行）。 2. 点击 **Run: Payment Errors**。观看 agent 实时流式传输 检测 → 诊断（真实的 Gemini 3，约 10-16 秒得出提议的修复方案；头部计时器正在倒数）。 3. 当批准卡片出现时，先点击 **Reject**。agent 会在约 1 秒内停止行动；什么都不会进入生产环境；拒绝动作将连同 Dynatrace 徽章一起进入审计跟踪。 4. 再次运行并点击 **Approve**。flag 关闭，健康状况重新验证，卡片变为绿色。 5. 头部的 **Evals: 0 false actions** 标签会打开 [`/reliability`](https://autosre-ui-vrf7h4n4ra-uc.a.run.app/reliability)，即评分记分卡。 如果实时 URL 无法访问，相同的循环可以在两个终端中完全离线运行；请参阅下文的快速入门。 ## 快速入门（完全离线，无需账号） ``` # 设置 Python 环境 python3 -m venv .venv source .venv/bin/activate pip install -r requirements.txt # 复制示例环境（默认使用模拟的 Dynatrace） cp .env.example .env # 从 Google AI Studio (https://aistudio.google.com) 添加 GOOGLE_API_KEY=...。 # 建议：使用启用了计费功能的项目的 key，这样循环就不会 # 受到免费层级约 5 req/min 限制的等待。免费的 key 也可以用；agent 会 # 在遇到 429 时退避并恢复，只是速度会变慢。 # 在一个终端中启动目标服务 python -m autosre.target_service.main # 在 http://127.0.0.1:8081 上提供服务 # 检查健康状况：curl http://127.0.0.1:8081/healthz # 在第二个终端中，注入一个 fault curl -X POST http://127.0.0.1:8081/_admin/inject \ -H 'content-type: application/json' \ -d '{"fault":"payment_errors"}' # 在第三个终端中，运行 agent python -m autosre.run_agent ``` 观看 agent： - 从 mock Dynatrace 中拉取问题（“checkout failure rate spiked after deploy v2.3.1”）。 - 运行 DQL 找到罪魁祸首（feature flag `new_payment_gateway` 已启用）。 - 提议禁用该 flag。 - 暂停并请求您的批准（`HUMAN APPROVAL REQUIRED`）。 - 执行它（输入 `y`）。 - 验证服务是否恢复正常。 **可用故障：** - `payment_errors`：失败率飙升至 22%；正确修复：禁用 `new_payment_gateway` flag 或回滚至 v2.3.0。 - `latency_spike`：p99 延迟跃升至 4200ms；正确修复：将副本扩容至 8+。 ### 配合 Web UI (Mission Control) ``` # 从 repo 根目录开始（以便加载 .env）： python -m autosre.server # Start the SSE backend on :8080 # 在另一个终端中： cd web && npm install && npm run dev # Next.js dev server on :3000 ``` 在浏览器中打开 http://127.0.0.1:3000。点击 **"Run Incident Sweep"**，可选择要注入的故障，并观看 agent 流式传输其推理过程和时间线。当它提出修复方案时，**批准 / 拒绝** 模态框会阻塞，直到您做出决定。恢复后，事件卡片将变为绿色。 或者使用演示启动器： ``` bash scripts/start_demo.sh ``` 这将一次性启动目标服务、SSE 后端和 Web UI。 ## 针对真实 Dynatrace 运行 要针对您的 Dynatrace 租户而不是 mock 进行演示： 1. **创建一个试用租户**：访问 https://www.dynatrace.com/trial/（免费，15 天）。 2. **生成一个具有以下范围的 Platform token**： - `mcp-gateway:servers:invoke` - `mcp-gateway:servers:read` - `storage:logs:read`、`storage:metrics:read`、`storage:events:read` 3. **更新 `.env`：** DYNATRACE_MCP_MODE=remote DT_ENVIRONMENT=https://YOUR-TENANT.apps.dynatrace.com DT_PLATFORM_TOKEN=dt0s16... 4. **如上所述运行 agent。** 它现在将针对您真实的租户进行检测和诊断。 要使用官方的本地 Dynatrace MCP server 而不是托管网关： ``` DYNATRACE_MCP_MODE=stdio DT_ENVIRONMENT=https://YOUR-TENANT.apps.dynatrace.com DT_PLATFORM_TOKEN=dt0s16... # 需要 Node.js / npx ``` ## 部署到 Google Cloud ``` export PROJECT_ID=your-gcp-project export REGION=us-central1 export DT_ENVIRONMENT=https://YOUR-TENANT.apps.dynatrace.com export DT_PLATFORM_TOKEN=dt0s16... bash deploy/deploy_cloud_run.sh ``` 此脚本： - 构建并将 `checkout-api` 部署到 Cloud Run。 - 构建并将 AutoSRE agent（自托管的 FastAPI 应用，`python -m autosre.server`）部署到 Cloud Run，固定为单个实例，以保持内存中的运行状态和账本一致。 - 构建并将 `web/` Mission Control UI 部署到 Cloud Run（或 Firebase Hosting）。 - 将 agent 的 `ALLOWED_ORIGIN` 指向已部署的 UI。 - 输出实时公开 URL。 最终 URL 是您提交给评委的链接（Devpost 要求：必须在无痕窗口中可用）。 要在 **Vertex AI Agent Engine**（Google Cloud 托管的 Agent 平台运行时）上注册 ADK agent，请运行单独的一次性脚本，并将打印出的资源名称粘贴到 `SUBMISSION.md` 中： ``` export GOOGLE_CLOUD_PROJECT=your-gcp-project export GOOGLE_CLOUD_LOCATION=global # where Gemini 3 serves on this project export TARGET_SERVICE_URL=https://checkout-api-xxxx.run.app python -m deploy.agent_engine_deploy ``` 它将相同的 `root_agent` 包装在 ADK `AdkApp` 中，打包 `autosre` 包，并调用 `agent_engines.create`。Mission-Control SSE 和人工批准编排继续在 Cloud Run 上运行（它们拥有暂停/恢复桥接和演示目标代理）；Agent Engine 将托管推理运行时。 ## 测试 ``` pytest ``` 测试套件（71 个测试：70 个离线确定性测试，1 个受限于实时 Gemini 凭证的门控测试；运行 `pytest`）涵盖了拒绝路径审计、操作白名单边界、速率限制器、进程内工具、诊断评估评分器，以及多试验评估聚合 + Dynatrace 导出记录格式。 - **机制测试（确定性）：** 通过 MCP stdio 协议进行 mock Dynatrace server；验证两种故障类型的批准关卡、修复执行和事件结果。 - **修复白名单测试 (`test_remediation_gate.py`)：** 断言服务端边界（副本范围、已知良好版本、受管 flag 名称）即使在被批准的情况下也会拒绝带外操作，因此被批准但有毒的操作会安全失败。 - **拒绝路径回归测试：** 重现 ADK 第一轮确认存根，并断言被拒绝的运行被审计为 `rejected` / `declined`（后端），并且不应用任何内容（重放），因此关键的拒绝动作不会悄无声息地再次中断。 - **批准账本测试 (`test_ledger.py`)：** 仅追加审计记录和 Dynatrace 日志回写格式，包括 `dynatrace_writeback`（配置了凭证）与 `last_writeback`（写入是否成功落地并验证）之间的区别。 - **服务端安全测试 (`test_server_safety.py`)：** 公共端点上基于 IP 的速率限制和单一活动运行防护。 - **集成测试：** 来自后端的实时 SSE 流；批准往返；带有真实 Gemini 的完整 agent 循环（除非存在 Gemini 凭证，否则跳过）。 - **MCP 信封解析：** 真实 ADK 工具响应解包的回归测试（修复了一个严重错误）。 - **演示模式 (`test_demo_mode.py`)：** 确定性重放执行完整的 检测→验证 循环，并应用 **真实**的修复 HTTP 调用。托管演示**默认运行实时 Gemini agent**（mock Dynatrace 遥测以确保可靠的点击体验）；如果模型 API 在评审期间不可用，此重放可作为即时备用方案（`AUTOSRE_DEMO_MODE=1`）。真实租户、真实 DQL 的检测运行在演示视频中。 确定性测试离线通过（mock Dynatrace）。如果存在凭证，2 个实时测试将针对 Gemini 运行。 ## 仓库布局 ``` autosre/ ├── agent/ │ ├── agent.py # ADK LlmAgent + mode-aware prompt (detect→diagnose→act→verify) │ ├── dynatrace.py # Dynatrace MCP toolset builder (mock/stdio/remote) │ └── remediation.py # Remediation tools (scale/rollback/flag) the gate wraps ├── server/ │ ├── app.py # FastAPI HTTP + SSE service │ ├── loop.py # ADK loop primitives (shared by run_agent.py + server) │ ├── events.py # Event adapter (ADK → CONTRACT.md SSE schema) │ ├── runs.py # Per-run session management + pause/resume bridge │ ├── ledger.py # Append-only approval ledger + Dynatrace log write-back │ ├── demo.py # Deterministic replay backing the hosted demo (reliability) │ └── __main__.py # `python -m autosre.server` entrypoint ├── mock_dynatrace/ │ └── server.py # Offline Dynatrace MCP server (snake_case tool names) ├── target_service/ │ ├── main.py # checkout-api: the demo target (injectable faults) │ └── otel.py # Optional real OpenTelemetry export to Dynatrace └── run_agent.py # Interactive CLI runner (offline demo entry) web/ ├── app/ │ ├── page.tsx # Landing page │ ├── demo/page.tsx # Mission Control (the live demo) │ ├── api/ │ │ ├── incident/ # start · [runId]/stream · [runId]/approval (→ agent) │ │ └── demo/ # inject · health · reset │ ├── globals.css # Tailwind v4 + design tokens │ └── layout.tsx ├── components/ │ ├── approval-modal/ApprovalModal.tsx # APPROVE / REJECT blocking modal │ ├── timeline/Timeline.tsx # Phase-progress streaming timeline │ ├── dql-panel/DqlPanel.tsx # DQL evidence panel │ ├── problem-card/ProblemCard.tsx # Dynatrace problem display │ ├── demo-controls/DemoControls.tsx # Fault-injection controls │ ├── audit-trail/AuditTrail.tsx # Append-only decision ledger (✓ Dynatrace) │ ├── landing/ # CountUp · FlowDiagram · NavLinks · ScrollProgress · ScrollReveal │ └── ui/ # Badge · FinalReport · Panel ├── hooks/useIncidentStream.ts # SSE client hook ├── lib/ # api.ts · types.ts ├── Dockerfile # Next.js standalone image └── cloudbuild.yaml # UI image build (Cloud Build) deploy/ ├── Dockerfile.agent # Builds the agent (SSE backend on Cloud Run, Vertex AI) ├── Dockerfile.target # Builds checkout-api ├── cloudbuild.svc.yaml # Generic Cloud Build (-f path) for the Python services ├── agent_engine_deploy.py # Registers the ADK root_agent on Vertex AI Agent Engine └── deploy_cloud_run.sh # Orchestrates the three Cloud Run deployments tests/ ├── conftest.py # Boots checkout-api for the suite ├── test_remediation_gate.py # Approval gate + server-side action allow-lists ├── test_mock_dynatrace.py # Mock Dynatrace MCP tool shapes ├── test_server_sse.py # Full-loop SSE streaming + contract ├── test_server_safety.py # Rate limiting + single-active-run guard ├── test_demo_mode.py # Deterministic demo replay (+ deny stand-down) ├── test_mcp_envelope_parsing.py # Real ADK result unwrapping ├── test_ledger.py # Approval ledger + Dynatrace write-back shape └── test_agent_live.py # End-to-end with real Gemini (live-gated) .env.example # Environment variable template .env # (gitignored) Runtime secrets README.md # This file ARCHITECTURE.md # Deploy topology CONTRACT.md # Agent ↔ UI streaming interface DEMO.md # Demo runbook VIDEO-SCRIPT.md # Video script (≤3:00, criterion-tagged) SUBMISSION.md # Devpost requirement → evidence checklist DEVPOST.md # Devpost form draft LICENSE # MIT ``` ## 制胜之道 **技术实现 (25%)** - 通过 ADK（Google Cloud 的 Agent 平台，代码优先接口）在 Vertex AI 上进行 Gemini 3 推理，自托管在 Cloud Run 上，也可通过 `deploy/agent_engine_deploy.py` 部署到 **Vertex AI Agent Engine**。 - Dynatrace MCP 是**唯一**的传感系统（承重组件，非装饰品）。 - ADK 原生的 Human-in-the-loop (`require_confirmation=True`)：由框架强制执行，不可被 prompt 黑客攻击，并有服务端操作白名单作为后盾，因此即使是被批准但有毒的操作也会安全失败。 - agent 指令中不受信任的遥测防护，可防御通过日志和事件文本进行的间接 prompt injection。 - 模式无关：可离线工作（mock），在本地工作（stdio），或针对真实租户工作（remote），所有这些都使用相同的 agent 代码。 **设计 (25%)** - 暗黑作战室美学（“Mission Control” UI）。 - 流式传输时间线实时揭示 agent 的推理（可见的自主性）。 - 主 **批准 / 拒绝** 模态框在运行前显示确切的操作。 - 恢复状态使事件卡片动画变为绿色。 - 响应式：适用于桌面、平板电脑和移动设备。 **潜在影响 (25%)** - 核心影响主张是**在屏幕上测量的数字**：演示的实时计时器以秒为单位报告 agent 从检测到提出修复方案的延迟，并与总解决时间（包括人类的深思熟虑）分开报告。AutoSRE 压缩的是 30 多分钟的手动识别基准时间。 - 行业背景，非我们的测量：Gartner 将 IT 停机时间定为 5,600 美元/分钟（2014 年）；EMA 2024 年将其定为约 14,056 美元/分钟。我们将这些定位为痛苦的代价，而不是我们速度的证据。 - 面向高价值用户：待命 SRE、DevOps、零售/金融运营。 - 部署路径清晰：今天可在 Cloud Run 上使用，同一个 agent 可在 Vertex AI Agent Engine 上注册（无需自定义基础设施）。 - 内置 Dynatrace 集成（无需手动设置单独的可观测性）。 **创意质量 (25%)** - 差异化在于拒绝。一个能读取 Dynatrace 并修复问题的自主 agent 只是简单的一半。困难、可拥有的另一半是一个克制力可被证明的 agent：它请求许可，服从拒绝，并在 Dynatrace 自身的时间线上记录批准和拒绝。这将问题从“它行动得快吗”重新定义为“它应该行动吗，是谁说的”。 - 解决了真实的 SRE 问题：大规模的事件响应，且事后责任明确，合规团队可进行审计。 - 可推广：相同的循环适用于任何事件类型；演示展示了两种（feature flag 回滚和副本扩容）。 ## 故障排除 **问：Agent 超时或触发速率限制。** 答：您触及了 Gemini 的免费层级配额（约 5 次请求/分钟）。循环会自动避并恢复（您会看到“重试中”的提示），但为了不间断运行，请使用来自启用了结算功能的项目的 API 密钥；这会取消每分钟的上限，因此完整的扫描永远不会卡在 429 错误上。启用计费后，您还可以选择加入 `AUTOSRE_MODEL=gemini-3-pro-preview` 以获得更深入的推理。 **问：当我点击“Run Incident Sweep”时，Web UI 显示“Connection refused”。** 答：确保 SSE 后端正在运行（`python -m autosre.server`）并在 UI 预期的端口上监听。默认情况下，UI 会查找 `localhost:8080`；如果后端使用的是不同端口，请在 `web/` 目录的 `.env.local` 中设置 `NEXT_PUBLIC_AGENT_BASE_URL=http://127.0.0.1:8080`。 **问：我想针对真实的 Dynatrace 租户进行测试，但看不到任何问题。** 答：必须先运行 `checkout-api` 服务并注入故障 - agent 仅在存在问题时才会报告问题。在 **mock** 模式下，一旦您注入故障，内置的 Dynatrace MCP 就会显现出事件；针对 **真实** 租户，实时路径会通过 `timeseries avg(checkout.failure_rate)` DQL 进行检测，因此请留出约 1-2 分钟的时间让 OpenTelemetry 完成摄取，然后再显示峰值。注入命令：`curl -X POST localhost:8081/_admin/inject -H 'content-type: application/json' -d '{"fault":"payment_errors"}'`。 **问：批准模态框始终不出现。** 答：Agent 可能没有达到修复步骤。请检查 UI 中的时间线。如果它在 诊断 处停止，则 agent 可能未能在推理中找到修复方案（模型错误、DQL 结果不佳或超时）。请检查 agent 日志中的错误。如果调用了修复工具，请确保 `autosre/agent/remediation.py` 中确实存在 `FunctionTool(require_confirmation=True)`（理应如此；不要为了测试而将其删除）。 **问：即使我批准了，事件卡片也没有变成绿色。** 答：验证 步骤会读取服务的 `/_internal/state` 端点。确保修复确实解决了故障。对于 payment-error 故障，禁用 feature flag 应该有效；对于 latency 故障，扩容到 8+ 个副本应该有效。如果修复已运行但服务仍不健康，则 agent 对根本原因的推理可能是错误的。请检查时间线中的 诊断 DQL 结果。 ## MIT 许可证 参见 [许可证](LICENSE)。 ## 有疑问或问题？ 在 GitHub 上提出 issue 或联系我们。这是一个活跃的黑客松构建版本；欢迎反馈。

标签：Dynatrace, Google Cloud, 人机协同, 自动化运维, 逆向工具