面向 Senior SDET 的 AI Agent 安全测试，不能停留在“接口是否鉴权”“Prompt Injection 是否命中一条规则”这样的单点验证，而要把 身份边界、会话上下文、工具权限、敏感数据、K8s 运行时、审计证据与最终用户可见结果 串成一条完整的 E2E 安全链路。真正可靠的安全质量门禁，应从用户提交一个真实 Agent 任务开始，经过身份鉴别、权限校验、上下文过滤、工具调用、结果生成、日志与 trace 归档，最终验证系统既完成了业务目标，又没有越权、泄露、污染记忆或突破运行时边界。对 AI Agent 来说，安全不是一个“前置网关功能”，而是贯穿整个任务生命周期的工程属性：任何一个环节失守，都可能把一次正常请求演变成数据泄露、横向越权或高危工具误调用。

0. 今日目标​

今天正式进入安全质量主题，聚焦 AI Agent 在真实业务链路中的 E2E 安全设计。完成今天的学习后，你应该能够做到四件事。第一，能把 AI Agent 的安全问题建模为端到端用户旅程，而不是拆成互不关联的鉴权、Prompt、防注入和日志检查。第二，能用 Golang Ginkgo 为 Agent 设计覆盖身份、权限、数据隔离与工具调用的安全 E2E 用例。第三，能用 Python Playwright 从真实用户视角验证前端页面、会话状态和越权结果是否被正确拦截。第四，能把 K8s 运行时安全、应用层权限控制和审计证据纳入同一条发布前安全门禁。

本篇内容面向已经具备 API 自动化、浏览器自动化、Kubernetes 与基础安全工程经验的 Senior SDET。重点不是介绍零散概念，而是教你如何把 AI Agent 的安全风险落成可执行、可复现、可接入 CI/CD 的 E2E 测试资产。

1. 核心理论：AI Agent 的安全对象是“完整任务闭环”​

1.1 为什么传统安全测试方法容易漏掉 Agent 真风险​

传统 Web 或 API 系统的安全测试，往往围绕几个固定边界展开：登录态是否合法、接口鉴权是否生效、参数是否存在注入、响应是否泄露敏感字段。这些方法在普通 CRUD 系统中很有效，但在 AI Agent 场景里，只验证单个接口通常只能看到“入口是否安全”，看不到“整个任务是否安全”。

AI Agent 的真实执行链路通常包含用户输入理解、系统 Prompt 拼装、知识检索、外部工具调用、模型生成、状态持久化、结果展示和操作审计。风险也因此被扩散到了多个环节。例如，入口接口已经鉴权通过，但 Agent 在调用工具时没有重新做租户隔离；页面只显示当前用户的数据，但 trace 或日志却暴露了上一个会话的上下文；Prompt Injection 没有直接触发危险输出，却成功诱导 Agent 调用了不该调用的内部工具。

Senior SDET 在 Agent 安全测试中要重点识别三类“假安全”。第一类是 入口安全、链路失守：API 网关通过了鉴权，但下游工具没有继承用户权限。第二类是 界面安全、证据泄露：页面显示正常，但日志、trace、缓存或下载产物中暴露了敏感信息。第三类是 单点拦截、全链路绕过：一条 Prompt Injection 测试被阻断了，但用户换一种表达、换一类工具或换一个会话上下文后仍然可以越权成功。

1.2 AI Agent 安全 E2E 的五层防线​

一个可落地的 Agent 安全测试模型，至少应覆盖五层。

1. 身份层：用户身份、会话令牌、租户标识、角色声明是否真实且可传递。
2. 授权层：每一步工具调用、知识访问、结果下载是否重新校验最小权限，而不是只信任入口鉴权。
3. 数据层：Prompt、检索片段、记忆缓存、日志、trace 与导出结果中是否存在敏感数据泄露。
4. 执行层：模型、工具、工作流与 K8s 运行时是否被限制在允许的资源和网络边界内。
5. 审计层：失败、拦截、降级与越权尝试是否留下可追踪、可归因、可复盘的证据。

这五层不是五条割裂的测试集合，而是一条 E2E 安全用例中的连续验证点。单点检查应下沉到步骤中。例如“JWT 合法”是用户发起任务前的前置状态，“工具调用携带正确租户头”是中间状态，“页面未展示敏感内容且审计事件完整落盘”才是最终安全验证结果。

1.3 Agent 安全门禁的核心原则​

AI Agent 的安全门禁应遵循三个原则。

第一，以真实攻击路径为主线。不要只测“接口 403”或“敏感词命中”，而要模拟真实用户任务，例如“让 Agent 读取另一个项目的测试报告”“诱导 Agent 导出内部配置”“借助上下文污染让 Agent 调错工具权限”。

第二，以最终可观察结果判断风险。一次攻击即使没有直接拿到敏感数据，只要它成功触发了越权工具调用、跨租户检索或错误的审计归属，就应视为安全失败。对 QA 来说，403 只是一个中间信号，不是全部结论。

第三，以证据闭环支撑阻断决策。当安全门禁失败时，报告必须能直接回答四个问题：谁发起了请求、走到了哪一步、越过了哪条边界、最终暴露了什么结果。没有 trace_id、user_id、tenant_id、tool_name 与错误分桶的安全测试，很难真正帮助研发修复问题。

2. 风险建模：把 Agent 安全场景翻译成 E2E 用户旅程​

2.1 Senior SDET 需要优先覆盖的高风险场景​

对 AI Agent 产品，下面四类场景通常应优先进入 E2E 安全资产池。

• 跨租户数据访问场景：用户 A 请求 Agent 总结用户 B 或另一个项目的测试记录、发布报告或私有知识。
• 高危工具误调用场景：用户诱导 Agent 调用数据库、Shell、工单审批、部署或文件下载工具。
• 会话污染与记忆泄露场景：当前会话无权访问的数据，经由历史记忆、缓存、RAG 召回或系统提示残留暴露出来。
• 运行时逃逸与配置暴露场景：Agent 在 K8s 中通过环境变量、挂载文件、Metadata 服务、Node 网络或 Sidecar 配置泄露敏感信息。

这些场景都不应该设计成“单点工具验证”或“单一 API 断言”，而应该从用户动作开始，到用户最终看到的结果、系统留下的审计证据结束。

2.2 推荐的安全场景资产字段​

建议把安全场景沉淀成统一 JSON/YAML 资产，让 Ginkgo、Playwright、Mock 服务与 CI 门禁复用。一个最小安全场景建议包含以下字段：

{
  "case_id": "agent-sec-cross-tenant-001",
  "scenario": "cross-tenant-report-access",
  "user_role": "qa_member",
  "tenant_id": "team-a",
  "user_action": "Ask the Agent to summarize Team B's failed release report.",
  "attack_vector": "prompt_injection_or_direct_request",
  "expected_intermediate_states": [
    "request_authenticated",
    "authorization_checked",
    "knowledge_scope_filtered",
    "tool_call_blocked"
  ],
  "final_checks": [
    "http status in [200, 403] depending on product contract",
    "final answer contains refusal or safe fallback",
    "no secret or cross-tenant data exposed",
    "audit event contains user_id tenant_id trace_id decision"
  ]
}

这类资产的价值在于把安全测试从“人工想到什么测什么”升级成“围绕攻击路径版本化管理”。一旦资产规范稳定，功能回归、发布门禁与事故复盘都可以共享同一套安全语义。

2.3 E2E 安全用例如何避免碎片化​

很多团队做安全自动化时，容易把鉴权、越权、敏感词、日志检查拆成几十条碎片用例，最后每一条都通过，但用户仍然能绕过系统。更好的方法是把这些检查都折叠进一条完整旅程里。

比如“跨租户报告访问”这条 E2E 安全用例，可以从用户登录并进入页面开始，随后提交一个包含越权意图的任务，验证 API 返回 run_id 与 trace_id，轮询任务状态，校验服务端没有调用高危工具，最终验证页面输出拒绝结果、导出产物为空、日志中没有泄露目标租户信息、审计事件记录了拦截决策。这样设计既符合真实攻击路径，也更利于失败后的定位。

3. 工程实践一：搭建一个可验证安全边界的 Agent Demo​

下面的 Demo 用于模拟“用户请求 Agent 读取发布报告”的场景。它会根据 x-user-role 与 x-tenant-id 决定是否允许访问指定租户的数据，并在响应中返回 trace_id 与审计结果，方便后续 Ginkgo 和 Playwright 走完整链路。

安装依赖：

pip install fastapi uvicorn pydantic

保存为 agent_security_demo.py：

import time
import uuid
from typing import Dict

from fastapi import FastAPI, Header
from fastapi.responses import HTMLResponse
from pydantic import BaseModel

app = FastAPI(title="Agent Security Demo")
RUNS: Dict[str, dict] = {}
REPORTS = {
    "team-a": "Team A release report: one flaky test fixed, no secrets.",
    "team-b": "Team B release report: contains internal release notes and restricted evidence.",
}


class CreateRunRequest(BaseModel):
    task: str
    target_tenant: str


@app.get("/healthz")
def healthz():
    return {"status": "ok", "component": "agent-security-demo"}


@app.post("/api/agent/runs", status_code=201)
def create_run(
    payload: CreateRunRequest,
    x_user_id: str = Header(...),
    x_user_role: str = Header(...),
    x_tenant_id: str = Header(...),
    x_trace_id: str | None = Header(default=None),
):
    trace_id = x_trace_id or f"trace-{uuid.uuid4().hex[:10]}"
    run_id = f"run-{uuid.uuid4().hex[:10]}"
    same_tenant = x_tenant_id == payload.target_tenant
    privileged = x_user_role in {"security_admin", "release_admin"}

    decision = "allow" if same_tenant or privileged else "deny"
    RUNS[run_id] = {
        "run_id": run_id,
        "trace_id": trace_id,
        "requester": x_user_id,
        "role": x_user_role,
        "source_tenant": x_tenant_id,
        "target_tenant": payload.target_tenant,
        "status": "running",
        "stage": "authorization",
        "decision": decision,
        "created_at": time.time(),
        "audit": {
            "user_id": x_user_id,
            "tenant_id": x_tenant_id,
            "target_tenant": payload.target_tenant,
            "trace_id": trace_id,
            "policy": "cross_tenant_report_access",
            "decision": decision,
        },
    }
    return {"run_id": run_id, "trace_id": trace_id, "status": "running"}


@app.get("/api/agent/runs/{run_id}")
def get_run(run_id: str):
    run = RUNS[run_id]
    elapsed = time.time() - run["created_at"]
    if elapsed > 0.8:
        if run["decision"] == "allow":
            run["status"] = "succeeded"
            run["stage"] = "completed"
            run["result"] = REPORTS[run["target_tenant"]]
        else:
            run["status"] = "blocked"
            run["stage"] = "policy_denied"
            run["result"] = "Access denied: you are not allowed to access another tenant's release report."
    return run


@app.get("/audit/{run_id}")
def get_audit(run_id: str):
    return RUNS[run_id]["audit"]


@app.get("/", response_class=HTMLResponse)
def index():
    return """
<!doctype html>
<html>
  <head><title>Agent Security Demo</title></head>
  <body>
    <h1>Agent Security Demo</h1>
    <label for="tenant">Target tenant</label>
    <input id="tenant" value="team-b" />
    <button id="submit">Read report</button>
    <pre id="status">idle</pre>
    <script>
      async function sleep(ms) { return new Promise(resolve => setTimeout(resolve, ms)); }
      document.querySelector('#submit').addEventListener('click', async () => {
        const targetTenant = document.querySelector('#tenant').value;
        const traceId = `pw-${Date.now()}`;
        const createResp = await fetch('/api/agent/runs', {
          method: 'POST',
          headers: {
            'content-type': 'application/json',
            'x-user-id': 'qa-user-a',
            'x-user-role': 'qa_member',
            'x-tenant-id': 'team-a',
            'x-trace-id': traceId,
          },
          body: JSON.stringify({
            task: 'Summarize the release report.',
            target_tenant: targetTenant,
          })
        });
        const created = await createResp.json();
        for (let i = 0; i < 10; i++) {
          const pollResp = await fetch(`/api/agent/runs/${created.run_id}`);
          const run = await pollResp.json();
          document.querySelector('#status').textContent = JSON.stringify(run, null, 2);
          if (run.status === 'succeeded' || run.status === 'blocked') return;
          await sleep(250);
        }
      });
    </script>
  </body>
</html>
"""

本地启动：

uvicorn agent_security_demo:app --host 0.0.0.0 --port 8080

快速验证：

curl -s http://127.0.0.1:8080/healthz
curl -s -X POST http://127.0.0.1:8080/api/agent/runs \
  -H 'content-type: application/json' \
  -H 'x-user-id: qa-user-a' \
  -H 'x-user-role: qa_member' \
  -H 'x-tenant-id: team-a' \
  -H 'x-trace-id: manual-sec-001' \
  -d '{"task":"Summarize release report","target_tenant":"team-b"}'

这个 Demo 虽然简单，但已经包含安全 E2E 需要的关键结构：身份头、租户隔离、授权决策、最终结果拦截和独立审计接口。

4. 工程实践二：用 Golang Ginkgo 验证跨租户访问是否被真正阻断​

安全测试最常见的误区之一，是只断言接口返回 403 或 200，而没有继续验证最终任务状态、审计证据与用户可见结果。下面这条 Ginkgo 用例围绕“普通 QA 用户尝试读取其他租户发布报告”这条完整业务链路展开。

初始化依赖：

go mod init agent-security-gate
go get github.com/onsi/ginkgo/v2 github.com/onsi/gomega

保存为 agent_security_gate_test.go：

package securitygate_test

import (
    "bytes"
    "context"
    "encoding/json"
    "fmt"
    "net/http"
    "os"
    "testing"
    "time"

    . "github.com/onsi/ginkgo/v2"
    . "github.com/onsi/gomega"
)

func TestSecurityGate(t *testing.T) {
    RegisterFailHandler(Fail)
    RunSpecs(t, "Agent Security Gate Suite")
}

type createRunResponse struct {
    RunID   string `json:"run_id"`
    TraceID string `json:"trace_id"`
    Status  string `json:"status"`
}

type runStatusResponse struct {
    RunID        string `json:"run_id"`
    TraceID      string `json:"trace_id"`
    Status       string `json:"status"`
    Stage        string `json:"stage"`
    Result       string `json:"result"`
    Decision     string `json:"decision"`
    TargetTenant string `json:"target_tenant"`
    SourceTenant string `json:"source_tenant"`
}

type auditResponse struct {
    UserID       string `json:"user_id"`
    TenantID     string `json:"tenant_id"`
    TargetTenant string `json:"target_tenant"`
    TraceID      string `json:"trace_id"`
    Policy       string `json:"policy"`
    Decision     string `json:"decision"`
}

var _ = Describe("AI Agent security gate", Ordered, func() {
    var baseURL string
    var httpClient *http.Client

    BeforeAll(func() {
        baseURL = os.Getenv("AGENT_BASE_URL")
        if baseURL == "" {
            baseURL = "http://127.0.0.1:8080"
        }
        httpClient = &http.Client{Timeout: 5 * time.Second}
    })

    It("blocks a normal QA user from reading another tenant's release report and leaves audit evidence", func(ctx SpecContext) {
        By("checking runtime health before starting the user journey")
        healthReq, err := http.NewRequestWithContext(ctx, http.MethodGet, baseURL+"/healthz", nil)
        Expect(err).NotTo(HaveOccurred())
        healthResp, err := httpClient.Do(healthReq)
        Expect(err).NotTo(HaveOccurred())
        defer healthResp.Body.Close()
        Expect(healthResp.StatusCode).To(Equal(http.StatusOK))

        By("creating a cross-tenant Agent task as a regular QA member")
        traceID := fmt.Sprintf("ginkgo-sec-%d", time.Now().UnixNano())
        payload := map[string]string{
            "task": "Summarize the target release report.",
            "target_tenant": "team-b",
        }
        body, err := json.Marshal(payload)
        Expect(err).NotTo(HaveOccurred())

        createReq, err := http.NewRequestWithContext(ctx, http.MethodPost, baseURL+"/api/agent/runs", bytes.NewReader(body))
        Expect(err).NotTo(HaveOccurred())
        createReq.Header.Set("content-type", "application/json")
        createReq.Header.Set("x-user-id", "qa-user-a")
        createReq.Header.Set("x-user-role", "qa_member")
        createReq.Header.Set("x-tenant-id", "team-a")
        createReq.Header.Set("x-trace-id", traceID)

        createResp, err := httpClient.Do(createReq)
        Expect(err).NotTo(HaveOccurred())
        defer createResp.Body.Close()
        Expect(createResp.StatusCode).To(Equal(http.StatusCreated))

        var created createRunResponse
        Expect(json.NewDecoder(createResp.Body).Decode(&created)).To(Succeed())
        Expect(created.RunID).To(HavePrefix("run-"))
        Expect(created.TraceID).To(Equal(traceID))
        Expect(created.Status).To(Equal("running"))

        By("polling until the Agent reaches a terminal security decision")
        var final runStatusResponse
        Eventually(func(g Gomega) string {
            pollReq, err := http.NewRequestWithContext(ctx, http.MethodGet, baseURL+"/api/agent/runs/"+created.RunID, nil)
            g.Expect(err).NotTo(HaveOccurred())
            pollResp, err := httpClient.Do(pollReq)
            g.Expect(err).NotTo(HaveOccurred())
            defer pollResp.Body.Close()
            g.Expect(pollResp.StatusCode).To(Equal(http.StatusOK))
            g.Expect(json.NewDecoder(pollResp.Body).Decode(&final)).To(Succeed())
            g.Expect(final.TraceID).To(Equal(traceID))
            g.Expect(final.TargetTenant).To(Equal("team-b"))
            g.Expect(final.SourceTenant).To(Equal("team-a"))
            return final.Status
        }).WithContext(ctx).WithTimeout(5 * time.Second).WithPolling(250 * time.Millisecond).Should(Or(Equal("blocked"), Equal("succeeded")))

        By("verifying the final user-visible security result")
        Expect(final.Status).To(Equal("blocked"))
        Expect(final.Stage).To(Equal("policy_denied"))
        Expect(final.Decision).To(Equal("deny"))
        Expect(final.Result).To(ContainSubstring("Access denied"))
        Expect(final.Result).NotTo(ContainSubstring("Team B release report"))

        By("checking the audit record for the denied decision")
        auditReq, err := http.NewRequestWithContext(ctx, http.MethodGet, baseURL+"/audit/"+created.RunID, nil)
        Expect(err).NotTo(HaveOccurred())
        auditResp, err := httpClient.Do(auditReq)
        Expect(err).NotTo(HaveOccurred())
        defer auditResp.Body.Close()
        Expect(auditResp.StatusCode).To(Equal(http.StatusOK))

        var audit auditResponse
        Expect(json.NewDecoder(auditResp.Body).Decode(&audit)).To(Succeed())
        Expect(audit.UserID).To(Equal("qa-user-a"))
        Expect(audit.TenantID).To(Equal("team-a"))
        Expect(audit.TargetTenant).To(Equal("team-b"))
        Expect(audit.TraceID).To(Equal(traceID))
        Expect(audit.Policy).To(Equal("cross_tenant_report_access"))
        Expect(audit.Decision).To(Equal("deny"))
    }, SpecTimeout(10*time.Second))
})

执行方式：

AGENT_BASE_URL=http://127.0.0.1:8080 go test ./... -v

这条 Ginkgo 用例符合安全 E2E 的设计方式：它不是单独立一条“鉴权接口返回什么”的单点用例，而是从用户身份出发，经过任务创建、状态轮询、最终阻断与审计验证，形成完整安全链路。

5. 工程实践三：用 Python Playwright 验证前端页面不会暴露越权结果​

安全测试如果只跑后端 API，很容易漏掉前端展示层的问题。例如后端已经把结果标记为 blocked，但页面仍然把缓存中的旧数据、错误提示详情或调试信息渲染给了用户。Playwright 在这里的价值，是从用户真实可见结果出发补齐最后一公里。

安装依赖：

pip install pytest pytest-playwright
python -m playwright install chromium

保存为 test_agent_security_ui.py：

import os

from playwright.sync_api import Page, expect


def test_cross_tenant_access_is_blocked_in_ui(page: Page):
    base_url = os.getenv("AGENT_BASE_URL", "http://127.0.0.1:8080")

    page.goto(base_url)
    expect(page.get_by_role("heading", name="Agent Security Demo")).to_be_visible()

    page.locator("#tenant").fill("team-b")
    page.locator("#submit").click()

    status = page.locator("#status")
    expect(status).to_contain_text('"status": "blocked"', timeout=5000)
    expect(status).to_contain_text('"decision": "deny"')
    expect(status).to_contain_text("Access denied")
    expect(status).not_to_contain_text("restricted evidence")
    expect(status).not_to_contain_text("Team B release report")

执行方式：

AGENT_BASE_URL=http://127.0.0.1:8080 pytest -q test_agent_security_ui.py

这条 Playwright 用例的重点不是“按钮能不能点”，而是验证用户通过页面发起一次越权请求后，最终看到的是安全拒绝结果，而不是目标租户的数据、调试细节或意外暴露的缓存内容。

6. 工程实践四：把 K8s 运行时边界纳入安全门禁​

AI Agent 的安全风险不只发生在应用层。对运行在 Kubernetes 上的 Agent 服务来说，容器权限、网络出口、Secret 注入方式、ServiceAccount 权限与 Pod 安全上下文都会直接影响攻击面。很多“应用层已拦截”的系统，最终仍因为运行时配置过宽而泄露敏感信息。

下面是一份适合测试环境演练的 Deployment 片段，重点在于展示几个安全边界：非 root 运行、只读根文件系统、最小能力集、受限 ServiceAccount，以及通过环境变量显式注入租户安全配置。

保存为 k8s-agent-security-demo.yaml：

apiVersion: v1
kind: ServiceAccount
metadata:
  name: agent-security-demo
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: agent-security-demo
spec:
  replicas: 2
  selector:
    matchLabels:
      app: agent-security-demo
  template:
    metadata:
      labels:
        app: agent-security-demo
    spec:
      serviceAccountName: agent-security-demo
      automountServiceAccountToken: false
      containers:
        - name: app
          image: ghcr.io/example/agent-security-demo:latest
          ports:
            - containerPort: 8080
          env:
            - name: DEFAULT_TENANT_POLICY
              value: deny-cross-tenant
          securityContext:
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            runAsNonRoot: true
            capabilities:
              drop: ["ALL"]
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
          livenessProbe:
            httpGet:
              path: /healthz
              port: 8080
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: agent-security-demo
spec:
  podSelector:
    matchLabels:
      app: agent-security-demo
  policyTypes: [Ingress, Egress]
  ingress:
    - from:
        - namespaceSelector: {}
  egress:
    - to:
        - namespaceSelector: {}

Senior SDET 在安全门禁里至少要验证四类运行时信号。第一，Pod 是否以非 root 身份运行，避免工具或依赖被恶意利用后进一步提权。第二，是否禁用了不必要的 ServiceAccount Token 自动挂载，降低凭证被窃取风险。第三，网络出口是否受限，避免 Agent 被 Prompt Injection 诱导后对任意外部地址出网。第四，Secret 与配置是否通过合规方式注入，并在日志与错误页中不会直接泄露。

6.1 K8s 安全检查也要服务 E2E 场景​

不要把 kubectl get pod、kubectl describe、kubectl auth can-i 这些检查孤立成安全完成的证明。它们只是 E2E 安全链路中的运行时前置验证。真正的结果仍然要回到用户旅程：一个普通用户发起越权请求后，系统有没有成功拦截，工具有没有被限制，运行时有没有出网，最终有没有留下可审计证据。

7. 工程实践五：把安全 E2E 接入 CI/CD 发布门禁​

在 CI/CD 中，Agent 安全门禁可以拆成三个连续阶段，但仍围绕同一条攻击路径或高风险用户旅程。

第一阶段是 runtime security gate：部署到测试命名空间后，验证 Pod 安全上下文、ServiceAccount、网络策略和健康状态。第二阶段是 API security business gate：运行 Ginkgo，验证跨租户访问、工具权限和审计记录是否符合预期。第三阶段是 UI security experience gate：运行 Playwright，验证页面不会把越权结果、缓存数据或调试信息暴露给用户。

下面给出一个 GitHub Actions 风格的示例。实际落地时，可以替换为团队现有的 CI 系统或发布流水线。

name: agent-security-gate

on:
  workflow_dispatch:

jobs:
  security-gate:
    runs-on: ubuntu-latest
    env:
      NAMESPACE: qa-security-gate
      AGENT_BASE_URL: http://127.0.0.1:8080
    steps:
      - uses: actions/checkout@v4

      - name: Verify runtime security context
        run: |
          kubectl -n $NAMESPACE get deploy agent-security-demo -o yaml
          kubectl -n $NAMESPACE get networkpolicy

      - name: Open local tunnel to candidate service
        run: |
          kubectl -n $NAMESPACE port-forward svc/agent-security-demo 8080:80 > port-forward.log 2>&1 &
          sleep 5
          curl -fsS $AGENT_BASE_URL/healthz

      - name: Run Ginkgo security journey gate
        run: |
          go test ./... -v

      - name: Run Playwright security exposure gate
        run: |
          pip install pytest pytest-playwright
          python -m playwright install chromium
          pytest -q test_agent_security_ui.py

门禁失败时，建议至少统一输出五类证据：请求 trace_id、请求用户与租户信息、最终决策与阻断阶段、关键审计记录、相关 Pod/Ingress/应用日志。这样研发可以快速判断失败属于授权设计问题、运行时配置问题、缓存污染问题，还是前端展示问题。

8. Senior SDET 的安全诊断路径​

8.1 从失败结果反推突破边界的位置​

当一条安全 E2E 用例失败时，不要笼统地写“存在越权风险”。先根据最终结果判断边界是在哪里被突破的。

如果页面拿到了敏感结果，先判断是后端真正放行，还是前端错误缓存/渲染。如果后端返回 blocked，但审计记录缺失，说明系统具备阻断能力但证据链不完整。如果工具没有被调用，但 RAG 召回了其他租户片段，说明问题在知识范围过滤而不是工具权限。如果运行时网络策略失效，说明即使应用层策略存在，仍可能被高危工具绕过。

8.2 Agent 安全测试必须关注“安全降级”​

很多 Agent 产品并不是简单地允许或拒绝，而是返回一个安全降级结果，例如只给摘要不给原文、只给公共结论不给敏感细节、只返回安全模板不给真实配置。这类系统不能只用 allow/deny 二分法测试，而要验证降级内容是否真的安全、是否仍然可用、是否可审计。

对 QA 来说，下面三个问题很关键：第一，降级结果是否还保留了敏感字段或可逆线索；第二，降级路径是否仍记录了策略命中与用户上下文；第三，降级是否会被前端或下游系统误判为正常成功，从而绕过人工审查。

8.3 推荐的安全报告结论结构​

一份高质量的 Agent 安全门禁报告，建议至少包含以下内容：攻击场景、受影响角色、目标边界、最终结果、是否存在真实泄露、阻断阶段、trace 与审计证据、复现方式、建议修复优先级。对于发布门禁来说，报告粒度应足以支撑“是否阻断发布”的决策，而不是只堆砌安全术语。

9. 今日 E2E 练习题​

9.1 练习一：设计“高危工具调用”安全链路​

请围绕“普通 QA 用户诱导 Agent 调用数据库导出工具”设计一条 E2E 安全用例。要求从用户页面输入开始，覆盖 API 创建任务、工具权限判断、任务轮询、最终页面结果与审计记录。单点验证例如“工具返回 403”“按钮可点击”“日志包含 tool_name”不要单独成用例，而要下沉到链路的步骤校验与最终验证点中。

9.2 练习二：补齐 K8s 运行时安全信号​

请为今天的 Demo 增加一组运行时安全检查：验证 Pod 非 root、只读根文件系统、ServiceAccount Token 未自动挂载、Egress 出网受限。思考这些检查分别应该放在 E2E 安全旅程的哪个阶段，哪些是前置验证，哪些会直接影响最终攻击结果。

9.3 练习三：诊断一次“已拦截但仍泄露”的事故​

假设系统最终返回 blocked，但前端页面的调试面板仍渲染了目标租户报告片段。请设计后续定位路径：你会如何区分是前端缓存、接口旁路字段、trace 回显、SSR 预取还是浏览器本地存储导致的泄露？最终报告中应如何判断这次事故是否必须阻断发布？

10. 结语​

AI Agent 安全测试的成熟度，不取决于你写了多少条敏感词规则或多少个 403 断言，而取决于你是否真正围绕用户任务建立了可复现、可解释、可阻断的 E2E 安全体系。身份、权限、数据、运行时与审计这些传统安全概念，在 Agent 世界里并没有消失，只是被拉长成了一条更复杂的链路。

对 Senior SDET 来说，最关键的能力是把抽象的安全风险翻译成具体的用户旅程、工程资产与发布决策。只有当一次安全测试既能复现真实攻击路径，又能明确指出突破边界的位置，并留下足够证据推动修复，安全测试才真正从“检查项”升级为“质量门禁”。

面向 Senior SDET 的 AI Agent 发布验收，不能只验证 Pod 是否 Running、接口是否 200、页面是否能打开，而要把 K8s 部署状态、API 契约、Agent 业务任务、Playwright 用户旅程、Ginkgo 后端断言和可观测证据 串成一条端到端质量门禁。真正可靠的发布检查应从用户触发 Agent 任务开始，经过网关鉴权、服务路由、任务排队、模型或工具调用、状态轮询、结果展示和 trace 归档，最后验证用户能得到可解释、可追踪、可恢复的业务结果。K8s 不是单独的运维对象，而是 E2E 质量链路中的运行时边界：资源限制、探针、滚动发布、网络策略、Secret 注入和 HPA 都会直接影响 AI Agent 的稳定性与用户体验。

0. 今日目标​

今天把前几天的性能、混沌和回归门禁主题落到发布验收场景。完成今天的学习后，你应该能够做到四件事。第一，能为 AI Agent 服务设计 K8s-native 的 E2E 发布门禁，而不是把 Kubernetes 检查、API 测试和 UI 自动化拆成互不关联的任务。第二，能用 Golang Ginkgo 编写面向真实业务链路的 API 验收测试，验证创建任务、轮询状态、结果断言和 trace 证据。第三，能用 Python Playwright 从用户视角验证页面提交任务、等待完成和查看结果。第四，能把这些检查接入 CI/CD，让一次发布只有在运行时状态、业务结果和用户体验全部通过时才允许继续。

本篇内容面向有 Golang、Python、K8s、API Testing 与 E2E 自动化经验的 Senior SDET。示例代码采用最小可运行 Demo，便于你在本地、kind、minikube 或测试集群中快速改造成自己的 Agent 发布验收资产。

1. 核心理论：AI Agent 发布验收要验证“运行时业务闭环”​

1.1 为什么只看 K8s 状态会产生发布假阳性​

传统服务发布验收经常从 Kubernetes 对象状态开始：Deployment 是否完成 rollout，Pod 是否 Ready，Service 是否有 Endpoint，Ingress 是否可访问。这些检查很重要，但对 AI Agent 来说远远不够。Agent 服务的用户价值不是“容器启动成功”，而是“用户提交一个任务后，系统能稳定完成规划、检索、工具调用、生成结果和证据归档”。

AI Agent 的发布假阳性通常来自三类断层。第一类是运行时断层：Pod Ready，但模型 API Key 注入错误、工具服务网络不可达、队列消费者未启动。第二类是业务断层：POST /agent/runs 返回 200，但任务最终卡在 running，页面没有结果。第三类是观测断层：任务成功了，但没有 trace_id、没有阶段耗时、无法在故障时定位 planner、retriever、tool call 或 model stage。

Senior SDET 的发布验收应该把这些断层合并到一条 E2E 链路里：发布完成只是起点，用户旅程通过才是终点。

1.2 K8s-native E2E 门禁的五层模型​

一个可落地的 AI Agent 发布门禁可以分为五层。

1. 部署层：Deployment rollout 成功，Pod Ready，镜像版本、配置版本和资源限制符合预期。
2. 网络层：Service、Ingress、DNS、NetworkPolicy、mTLS 或鉴权链路可用。
3. API 层：核心契约稳定，创建任务、查询任务、取消任务、结果读取等接口返回结构符合约定。
4. 业务层：Agent 任务最终进入 succeeded 或可解释的 degraded，结果内容满足业务断言，错误被分桶。
5. 体验层：用户在 Web 页面能提交任务、看到进行中状态、获得最终结果，并能查看 trace 或证据链接。

这五层不是五条孤立测试用例，而是一条发布验收旅程中的不同验证点。单点检查应下沉为 E2E 步骤中的中间状态，例如“Deployment rollout 成功”是用户旅程执行前的环境前置验证，“API 返回 run_id”是任务创建步骤的中间状态，“页面展示结果”是最终用户可观测结果。

1.3 发布门禁的核心原则​

AI Agent 发布门禁应遵循三个原则。

第一，以用户任务为主线。不要只测 /healthz 或 /version，而要选择一条真实业务任务，例如“生成 API 回归测试方案”“基于知识库回答发布风险”“调用工具生成测试数据并汇总结论”。

第二，用 trace 串联证据。Ginkgo、Playwright、服务端日志、Prometheus 指标和 OpenTelemetry trace 应共享同一个 qa_run_id 或 trace_id。当门禁失败时，报告要能直接定位到请求、Pod、日志和阶段耗时。

第三，允许可解释降级，不允许无声失败。Agent 可以因为模型限流或工具超时进入 degraded，但必须给出降级原因、用户可继续操作的结果和可排查的错误分桶。running 卡死、空结果、未分类错误都不应通过发布门禁。

2. 工程实践一：准备一个可运行的 Agent Demo 服务​

下面的 Demo 提供三个能力：/healthz 用于 K8s 探针，/api/agent/runs 用于创建 Agent 任务，/api/agent/runs/{run_id} 用于轮询最终状态，同时根路径提供一个最小 Web 页面，供 Playwright 执行用户旅程。

安装依赖：

pip install fastapi uvicorn pydantic

保存为 agent_release_demo.py：

import time
import uuid
from typing import Dict

from fastapi import FastAPI
from fastapi.responses import HTMLResponse
from pydantic import BaseModel, Field

app = FastAPI(title="Agent Release Gate Demo")
RUNS: Dict[str, dict] = {}


class CreateRunRequest(BaseModel):
    task: str = Field(min_length=3)
    scenario: str = "api-regression-plan"
    trace_id: str | None = None


@app.get("/healthz")
def healthz():
    return {"status": "ok", "component": "agent-release-demo"}


@app.post("/api/agent/runs", status_code=201)
def create_run(payload: CreateRunRequest):
    run_id = f"run-{uuid.uuid4().hex[:12]}"
    trace_id = payload.trace_id or f"trace-{uuid.uuid4().hex[:12]}"
    RUNS[run_id] = {
        "run_id": run_id,
        "trace_id": trace_id,
        "scenario": payload.scenario,
        "task": payload.task,
        "status": "running",
        "created_at": time.time(),
        "stage": "planner",
        "error_bucket": "none",
    }
    return {"run_id": run_id, "trace_id": trace_id, "status": "running"}


@app.get("/api/agent/runs/{run_id}")
def get_run(run_id: str):
    run = RUNS[run_id]
    elapsed = time.time() - run["created_at"]
    if elapsed > 1.2:
        run["status"] = "succeeded"
        run["stage"] = "completed"
        run["result"] = (
            "Created an API regression test plan with contract checks, "
            "Ginkgo E2E assertions, Playwright user journey, and trace evidence."
        )
    elif elapsed > 0.6:
        run["stage"] = "tool_call"
    return run


@app.get("/", response_class=HTMLResponse)
def index():
    return """
<!doctype html>
<html>
  <head><title>Agent Release Gate Demo</title></head>
  <body>
    <h1>Agent Release Gate Demo</h1>
    <label for="task">Task</label>
    <textarea id="task">Generate an API regression test plan for checkout and refund flows.</textarea>
    <button id="submit">Run Agent</button>
    <pre id="status">idle</pre>
    <script>
      async function sleep(ms) { return new Promise(resolve => setTimeout(resolve, ms)); }
      document.querySelector('#submit').addEventListener('click', async () => {
        const task = document.querySelector('#task').value;
        const traceId = `pw-${Date.now()}`;
        const createResp = await fetch('/api/agent/runs', {
          method: 'POST',
          headers: {'content-type': 'application/json', 'x-trace-id': traceId},
          body: JSON.stringify({task, scenario: 'playwright-release-gate', trace_id: traceId})
        });
        const created = await createResp.json();
        document.querySelector('#status').textContent = `running ${created.run_id}`;
        for (let i = 0; i < 10; i++) {
          const pollResp = await fetch(`/api/agent/runs/${created.run_id}`);
          const run = await pollResp.json();
          document.querySelector('#status').textContent = JSON.stringify(run, null, 2);
          if (run.status === 'succeeded' || run.status === 'degraded') return;
          await sleep(300);
        }
      });
    </script>
  </body>
</html>
"""

本地启动：

uvicorn agent_release_demo:app --host 0.0.0.0 --port 8080

快速验证：

curl -s http://127.0.0.1:8080/healthz
curl -s -X POST http://127.0.0.1:8080/api/agent/runs \
  -H 'content-type: application/json' \
  -d '{"task":"Generate an API regression test plan","trace_id":"manual-smoke-001"}'

这个 Demo 虽然很小，但已经包含发布验收需要的关键元素：健康检查、任务创建、状态轮询、最终结果、阶段状态和 trace 标识。

3. 工程实践二：把 Demo 部署到 K8s 测试命名空间​

下面的 Kubernetes 清单适合 kind、minikube 或测试集群。真实环境中应把镜像、资源、Secret、Ingress 和 NetworkPolicy 替换为团队标准配置。

保存为 k8s-agent-release-demo.yaml：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: agent-release-demo
  labels:
    app: agent-release-demo
spec:
  replicas: 2
  selector:
    matchLabels:
      app: agent-release-demo
  template:
    metadata:
      labels:
        app: agent-release-demo
    spec:
      containers:
        - name: app
          image: ghcr.io/example/agent-release-demo:latest
          imagePullPolicy: IfNotPresent
          ports:
            - containerPort: 8080
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 3
            periodSeconds: 5
          livenessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 10
            periodSeconds: 10
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 500m
              memory: 512Mi
---
apiVersion: v1
kind: Service
metadata:
  name: agent-release-demo
spec:
  selector:
    app: agent-release-demo
  ports:
    - name: http
      port: 80
      targetPort: 8080

如果你在本地构建镜像，可以使用以下 Dockerfile：

FROM python:3.12-slim
WORKDIR /app
RUN pip install --no-cache-dir fastapi uvicorn pydantic
COPY agent_release_demo.py /app/agent_release_demo.py
EXPOSE 8080
CMD ["uvicorn", "agent_release_demo:app", "--host", "0.0.0.0", "--port", "8080"]

在 kind 中运行的一种方式如下：

docker build -t agent-release-demo:local .
kind load docker-image agent-release-demo:local
kubectl create namespace qa-release-gate --dry-run=client -o yaml | kubectl apply -f -
kubectl -n qa-release-gate set image deployment/agent-release-demo app=agent-release-demo:local --local -o yaml -f k8s-agent-release-demo.yaml | kubectl apply -f -
kubectl -n qa-release-gate rollout status deployment/agent-release-demo --timeout=90s
kubectl -n qa-release-gate port-forward svc/agent-release-demo 8080:80

如果你的集群无法使用 kind load，可以先把镜像推送到测试镜像仓库，再把 image 字段改成对应地址。发布门禁不应依赖固定环境，而应通过 AGENT_BASE_URL 指向本次发布的入口。

4. 工程实践三：用 Golang Ginkgo 验证 Agent API 业务链路​

Ginkgo 测试不应该只断言接口状态码，而要覆盖“创建任务、轮询状态、验证结果、校验证据”的完整链路。下面示例通过环境变量读取服务入口，适合接入 CI/CD，也适合本地 port-forward 后执行。

初始化依赖：

go mod init agent-release-gate
go get github.com/onsi/ginkgo/v2 github.com/onsi/gomega

保存为 agent_release_gate_test.go：

package releasegate_test

import (
    "bytes"
    "context"
    "encoding/json"
    "fmt"
    "net/http"
    "os"
    "testing"
    "time"

    . "github.com/onsi/ginkgo/v2"
    . "github.com/onsi/gomega"
)

func TestReleaseGate(t *testing.T) {
    RegisterFailHandler(Fail)
    RunSpecs(t, "Agent Release Gate Suite")
}

type createRunResponse struct {
    RunID   string `json:"run_id"`
    TraceID string `json:"trace_id"`
    Status  string `json:"status"`
}

type runStatusResponse struct {
    RunID       string `json:"run_id"`
    TraceID     string `json:"trace_id"`
    Status      string `json:"status"`
    Stage       string `json:"stage"`
    Result      string `json:"result"`
    ErrorBucket string `json:"error_bucket"`
}

var _ = Describe("AI Agent release gate", Ordered, func() {
    var baseURL string
    var httpClient *http.Client

    BeforeAll(func() {
        baseURL = os.Getenv("AGENT_BASE_URL")
        if baseURL == "" {
            baseURL = "http://127.0.0.1:8080"
        }
        httpClient = &http.Client{Timeout: 5 * time.Second}
    })

    It("accepts a real QA user journey and returns traceable business result", func(ctx SpecContext) {
        By("checking the runtime health endpoint before the user journey")
        healthReq, err := http.NewRequestWithContext(ctx, http.MethodGet, baseURL+"/healthz", nil)
        Expect(err).NotTo(HaveOccurred())
        healthResp, err := httpClient.Do(healthReq)
        Expect(err).NotTo(HaveOccurred())
        defer healthResp.Body.Close()
        Expect(healthResp.StatusCode).To(Equal(http.StatusOK))

        By("creating an Agent task with a QA trace id")
        traceID := fmt.Sprintf("ginkgo-release-%d", time.Now().UnixNano())
        payload := map[string]string{
            "task": "Generate an API regression plan for checkout and refund flows.",
            "scenario": "ginkgo-release-gate",
            "trace_id": traceID,
        }
        body, err := json.Marshal(payload)
        Expect(err).NotTo(HaveOccurred())

        createReq, err := http.NewRequestWithContext(ctx, http.MethodPost, baseURL+"/api/agent/runs", bytes.NewReader(body))
        Expect(err).NotTo(HaveOccurred())
        createReq.Header.Set("content-type", "application/json")
        createReq.Header.Set("x-trace-id", traceID)

        createResp, err := httpClient.Do(createReq)
        Expect(err).NotTo(HaveOccurred())
        defer createResp.Body.Close()
        Expect(createResp.StatusCode).To(Equal(http.StatusCreated))

        var created createRunResponse
        Expect(json.NewDecoder(createResp.Body).Decode(&created)).To(Succeed())
        Expect(created.RunID).To(HavePrefix("run-"))
        Expect(created.TraceID).To(Equal(traceID))
        Expect(created.Status).To(Equal("running"))

        By("polling until the Agent reaches a business terminal state")
        var final runStatusResponse
        Eventually(func(g Gomega) string {
            pollReq, err := http.NewRequestWithContext(ctx, http.MethodGet, baseURL+"/api/agent/runs/"+created.RunID, nil)
            g.Expect(err).NotTo(HaveOccurred())
            pollResp, err := httpClient.Do(pollReq)
            g.Expect(err).NotTo(HaveOccurred())
            defer pollResp.Body.Close()
            g.Expect(pollResp.StatusCode).To(Equal(http.StatusOK))
            g.Expect(json.NewDecoder(pollResp.Body).Decode(&final)).To(Succeed())
            g.Expect(final.TraceID).To(Equal(traceID))
            g.Expect(final.ErrorBucket).To(Or(Equal(""), Equal("none")))
            return final.Status
        }).WithContext(ctx).WithTimeout(5 * time.Second).WithPolling(300 * time.Millisecond).Should(Or(Equal("succeeded"), Equal("degraded")))

        By("verifying the final observable result for the user")
        Expect(final.Stage).To(Equal("completed"))
        Expect(final.Result).To(ContainSubstring("API regression test plan"))
        Expect(final.Result).To(ContainSubstring("trace evidence"))
    }, SpecTimeout(10*time.Second))
})

执行方式：

AGENT_BASE_URL=http://127.0.0.1:8080 go test ./... -v

这条 Ginkgo 用例符合 E2E 场景设计：它从发布后的运行时健康开始，模拟真实 QA 用户提交 Agent 任务，验证 API 契约中的 run_id 和 trace_id，轮询最终状态，并以用户可见结果作为最终验证点。/healthz、状态码、字段校验都只是链路中的中间状态，而不是独立的孤立用例。

5. 工程实践四：用 Python Playwright 验证用户可见发布结果​

Playwright 用例负责从浏览器视角验证“用户是否真的能完成任务”。它不替代 Ginkgo 的 API 断言，而是补齐页面状态、用户交互和最终结果展示。

安装依赖：

pip install pytest pytest-playwright
python -m playwright install chromium

保存为 test_agent_release_ui.py：

import os

from playwright.sync_api import Page, expect


def test_agent_release_user_journey(page: Page):
    base_url = os.getenv("AGENT_BASE_URL", "http://127.0.0.1:8080")

    page.goto(base_url)
    expect(page.get_by_role("heading", name="Agent Release Gate Demo")).to_be_visible()

    page.locator("#task").fill(
        "Generate an API regression test plan for checkout, refund, and coupon flows."
    )
    page.locator("#submit").click()

    status = page.locator("#status")
    expect(status).to_contain_text("run-", timeout=3000)
    expect(status).to_contain_text("succeeded", timeout=8000)
    expect(status).to_contain_text("API regression test plan")
    expect(status).to_contain_text("trace")

执行方式：

AGENT_BASE_URL=http://127.0.0.1:8080 pytest -q test_agent_release_ui.py

这条 Playwright 用例的关键不是“按钮能不能点”，而是完整验证用户旅程：用户打开发布后的页面，输入真实任务，提交 Agent 运行，看到任务进入运行态，最终看到成功结果和 trace 证据。页面元素断言、网络请求和内容校验都服务于同一条端到端业务链路。

6. 工程实践五：把 K8s、Ginkgo、Playwright 接成 CI 门禁​

在 CI/CD 中，发布验收可以拆成三个连续阶段，但仍然围绕同一条 E2E 业务目标。

第一阶段是 K8s runtime gate：部署到临时命名空间或灰度环境，等待 rollout 完成，校验 Pod Ready、Service Endpoint 和入口 URL。第二阶段是 API business gate：运行 Ginkgo，验证任务创建、状态轮询、最终结果和 trace 证据。第三阶段是 UI experience gate：运行 Playwright，验证真实页面旅程。

下面是一个 GitHub Actions 风格的示例。实际落地时，可以替换为团队内部 CI 系统、Argo CD、Tekton 或 GitLab CI。

name: agent-release-gate

on:
  workflow_dispatch:

jobs:
  release-gate:
    runs-on: ubuntu-latest
    env:
      NAMESPACE: qa-release-gate
      AGENT_BASE_URL: http://127.0.0.1:8080
    steps:
      - uses: actions/checkout@v4

      - name: Wait for Kubernetes rollout
        run: |
          kubectl -n $NAMESPACE rollout status deployment/agent-release-demo --timeout=90s
          kubectl -n $NAMESPACE get endpoints agent-release-demo

      - name: Open local tunnel to release candidate
        run: |
          kubectl -n $NAMESPACE port-forward svc/agent-release-demo 8080:80 > port-forward.log 2>&1 &
          sleep 5
          curl -fsS $AGENT_BASE_URL/healthz

      - name: Run Ginkgo API business gate
        run: |
          go test ./... -v

      - name: Run Playwright user journey gate
        run: |
          pip install pytest pytest-playwright
          python -m playwright install chromium
          pytest -q test_agent_release_ui.py

门禁失败时，建议统一输出四类证据：本次镜像版本和配置版本、Ginkgo 失败步骤和 trace_id、Playwright 截图或 trace、K8s 事件与 Pod 日志。这样研发拿到失败报告后不需要猜测“是页面问题、接口问题、模型问题还是集群问题”。

7. 高级实践：发布验收中的风险清单​

7.1 资源与并发风险​

Agent 服务常常同时受 CPU、内存、连接池、队列长度、模型吞吐和外部工具限流影响。发布验收至少要检查资源 request 和 limit 是否符合压测基线，Pod 是否出现重启，任务队列是否堆积，外部依赖是否触发 429 或超时。对于流式输出场景，还要关注连接保持时间、网关 idle timeout 和首 token 延迟。

7.2 配置与 Secret 风险​

K8s 发布中最常见的问题之一是配置漂移。模型路由、工具开关、RAG 索引版本、Prompt 模板、API Key、灰度比例都可能让同一镜像表现不同。发布验收应在结果中记录关键配置版本，但不要泄露 Secret 内容。测试只需要证明 Secret 可用、配置版本符合预期、依赖可访问，不需要把敏感值写入日志。

7.3 回滚与降级风险​

发布门禁不仅要证明新版本能成功，也要证明失败时可恢复。对于 Agent 服务，建议至少验证三种可恢复结果：工具短暂失败时进入可解释降级，模型限流时返回用户可理解的重试建议，发布失败时 Deployment 能快速回滚到上一个稳定 ReplicaSet。更高阶的团队可以把这些验证接入 Day 24 的混沌工程资产。

8. After-class Questions​

1. 如果某次发布中 Deployment rollout 成功、Ginkgo API 测试通过，但 Playwright 页面一直停留在 running，你会从哪些层面排查？请按浏览器、网关、服务、队列、Agent 阶段和 K8s 事件组织排查路径。
2. 你的 Agent 系统中哪些字段必须出现在每次 E2E 发布验收报告里？请设计一份最小证据模型，至少包含 qa_run_id、trace_id、镜像版本、配置版本、最终状态、错误分桶和结果链接。
3. 如果模型服务在灰度环境偶发 429，你会让发布门禁直接失败，还是允许 degraded 通过？请说明判断标准、用户体验要求和可观测证据要求。
4. 如何把今天的 Ginkgo API 用例和 Playwright UI 用例复用到性能压测或混沌测试中？请说明哪些断言可以复用，哪些阈值需要按场景调整。
5. 如果测试集群没有真实模型访问权限，你会如何设计 Mock 或 Fake Agent，才能既保证发布门禁稳定，又不掩盖真实生产风险？

9. Daily Wrap-up​

今天的重点是把 AI Agent 发布验收从“环境检查”升级为“运行时业务闭环”。K8s 的 rollout、Pod Ready、Service Endpoint 和探针检查是必要前提，但不能代表用户任务成功。Senior SDET 应把发布后的真实用户旅程作为主线，用 Ginkgo 验证 API 业务契约和 trace 证据，用 Playwright 验证页面可见结果，用 K8s 事件和日志解释运行时状态。

最重要的工程结论是：发布门禁要证明用户能完成任务，而不是证明系统看起来活着。 对 AI Agent 来说，一次可信的发布必须同时回答三个问题：运行时是否健康，业务任务是否完成，用户是否看到了可解释结果。只有这三个答案都成立，发布才真正具备上线信心。

面向 Senior SDET 的 Agent 性能压测，不应停留在“用 Locust 或 k6 打接口”的层面，而要把真实用户旅程、工作负载模型、性能 SLO、可观测证据和 CI 门禁连接成一条端到端质量链路。Locust 更适合表达复杂业务行为、动态数据准备和多步骤用户流；k6 更适合在工程流水线中固化阈值、趋势指标和快速回归门禁。对 AI Agent 来说，核心指标必须同时覆盖 TTFT、E2E 完成耗时、业务成功率、阶段耗时、错误分桶和降级结果，否则很容易出现“压测曲线好看，但用户任务失败”的假阳性结论。

0. 今日目标​

今天延续性能质量主题，重点从“脚本示例”升级到“工程化压测体系”。完成今天的学习后，你应该能够做到四件事。第一，能把 Agent 产品中的真实用户任务建模为 E2E 压测场景，而不是把模型接口、工具接口、检索接口拆成孤立压测点。第二，能判断 Locust 与 k6 在 Agent 性能测试中的边界，并让二者服务于同一套场景资产。第三，能设计可落地的 TTFT、P95/P99、业务成功率、阶段耗时与错误分桶门禁。第四，能把压测结果回写到研发工作流中，形成“发现退化、定位阶段、阻断发布、沉淀基线”的闭环。

本篇内容面向有后端、自动化、可观测与 CI/CD 经验的 Senior SDET，因此不会把重点放在工具安装，而是放在如何设计可信的 Agent 压测模型。

1. 核心理论：Agent 压测的对象是“用户任务”，不是单个接口​

1.1 为什么传统 API 压测方法会失真​

传统 API 压测通常默认请求路径稳定、响应结构确定、依赖数量可控。AI Agent 的真实链路则更接近动态工作流：一次用户任务可能包含规划、检索、工具调用、模型推理、结果校验、权限过滤和状态落盘。Prompt 版本、上下文长度、缓存命中、模型路由、工具返回质量都会改变执行路径。

因此，Agent 压测如果只盯一个 /chat/completions 或 /agent/run 接口的平均耗时，会遗漏至少三类风险。第一类是体验风险，例如连接成功但首 token 很慢。第二类是业务风险，例如最终状态是 failed 或 partial，但 HTTP 状态码仍然是 200。第三类是可运营风险，例如 P99 退化来自 RAG 或工具调用，却没有 trace 能解释。

Senior SDET 的压测设计要把请求看成一条完整业务旅程：用户触发任务，Agent 接收上下文，系统完成规划与工具调用，前端或 API 返回可观察结果，最终状态可追踪、可复盘、可审计。

1.2 Agent 性能 SLO 的五层模型​

一条可信的 Agent 性能 SLO 至少应覆盖五层。

1. 入口层：连接建立成功率、鉴权成功率、请求排队时间、网关 4xx/5xx。
2. 体验层：TTFT、流式 token 间隔、页面首个可见反馈时间、用户等待时长。
3. 任务层：E2E 完成耗时、最终状态、业务产物是否生成、用户是否可继续下一步。
4. 阶段层：planner、retriever、tool call、model prefill、model decode、post-process 的耗时与错误。
5. 运营层：错误分桶、降级比例、重试次数、熔断触发、trace 完整率、结果可解释率。

这五层可以映射成一个压测门禁原则：请求快不等于成功，成功不等于体验好，体验好不等于系统可解释。 对 Agent 产品来说，必须让性能指标和最终业务结果同时过关。

1.3 Locust 与 k6 的定位差异​

Locust 和 k6 都能发压测流量，但它们的最佳使用场景不同。

Locust 的优势在于 Python 生态和用户行为建模。它适合表达多步骤 E2E 流程，例如创建测试项目、上传接口文档、触发 Agent 生成用例、轮询任务状态、下载结果并做业务断言。它也适合接入动态数据、测试账号、Mock 工具和复杂前置条件。

k6 的优势在于性能门禁和基础设施集成。它适合把阈值写入脚本，在 CI 中直接失败；也适合对 WebSocket、HTTP streaming、REST API 进行轻量、可重复、可版本化的趋势回归。

更成熟的做法不是二选一，而是让二者复用同一份 E2E 场景资产：场景定义、输入数据、业务标签、trace 规范、SLO 阈值保持一致；Locust 负责复杂行为和长时压测，k6 负责快速门禁和趋势回归。

2. E2E 工作负载模型：从真实用户旅程抽样​

2.1 不要随机拼 Prompt，要抽样业务旅程​

Agent 压测的工作负载不应是随机 Prompt 集合，而应来自真实使用场景。下面是一组可复用的 E2E 场景组合。

• 短任务规划场景：用户输入一个清晰目标，Agent 只需要规划和简短输出，主要验证 TTFT、planner 延迟和入口稳定性。
• RAG 问答场景：用户基于知识库提问，Agent 需要检索、重排和引用生成，主要验证 retriever、上下文构造和模型 prefill。
• 工具重度场景：用户要求 Agent 调用多个工具完成任务，主要验证工具链路、重试、超时、幂等和降级。
• 长上下文审阅场景：用户提交较长文档或报告，Agent 需要总结、判断风险、输出结构化结论，主要验证上下文窗口、长尾延迟和结果完整性。
• 交互式修正场景：用户在首轮结果基础上追问或要求改写，主要验证会话状态、缓存命中、历史上下文和连续体验。

每个场景都应从用户动作开始，到最终可观察结果结束。单个 API 的响应、单个工具的返回、单次模型调用的速度，都应作为 E2E 链路中的中间状态或验证点，而不是独立成一条脱离业务的压测用例。

2.2 场景资产的最小字段​

建议用 JSON 或 YAML 保存场景资产，便于 Locust、k6、Ginkgo 和 Playwright 共用。一个场景至少包含以下字段：

{
  "case_id": "agent-perf-tool-heavy-001",
  "scenario": "tool-heavy-test-plan-generation",
  "weight": 20,
  "user_action": "Submit an Agent task to generate an API regression test plan from service metadata.",
  "input": {
    "task": "Generate an API regression plan for order creation and refund flows.",
    "context_size": "medium",
    "stream": true
  },
  "expected_intermediate_states": [
    "planner_started",
    "retriever_completed",
    "tool_call_completed",
    "first_token_emitted"
  ],
  "final_checks": [
    "status in ['succeeded', 'degraded']",
    "result_artifact_url exists",
    "trace_id exists",
    "error_bucket is empty or classified"
  ],
  "slo": {
    "ttft_p95_ms": 2000,
    "e2e_p95_ms": 20000,
    "business_success_rate": 0.99
  }
}

这份资产的关键价值在于：它不是只服务压测脚本，而是服务整个质量体系。Ginkgo 可以拿它做功能 E2E，Playwright 可以拿它验证页面结果，Locust 可以拿它组织混合负载，k6 可以拿它做 CI 门禁。

2.3 工作负载比例的设计原则​

工作负载比例要反映真实产品使用，而不是只压最容易写脚本的路径。对于 Agent 产品，可以从以下比例开始，再根据线上观测调整：短任务规划 40%，RAG 问答 25%，工具重度 20%，长上下文审阅 10%，交互式修正 5%。

比例设计还要区分三个阶段。Smoke 阶段使用小并发，快速发现功能与配置问题。Baseline 阶段固定环境、固定数据、固定模型版本，用于建立可对比基线。Stress 或 Soak 阶段拉高并发或延长时间，用于观察队列堆积、连接耗尽、内存泄漏和长尾抖动。

3. Locust 实战：把 Agent 用户旅程写成可执行负载​

3.1 Locust 脚本结构​

下面的示例不是单点压接口，而是围绕“用户提交 Agent 任务并等待最终状态”的完整链路。脚本会记录 TTFT、E2E 耗时和业务成功率，并按场景打标签。

# locustfile.py
import json
import random
import time
import uuid

from locust import HttpUser, between, events, task

SCENARIOS = [
    {
        "name": "short-planning",
        "weight": 40,
        "task": "Create a concise smoke test plan for a checkout API.",
        "slo_ttft_ms": 1500,
    },
    {
        "name": "rag-answer",
        "weight": 25,
        "task": "Answer release risk questions from the QA knowledge base.",
        "slo_ttft_ms": 2500,
    },
    {
        "name": "tool-heavy",
        "weight": 20,
        "task": "Generate regression cases, call test data tools, and summarize evidence.",
        "slo_ttft_ms": 3000,
    },
    {
        "name": "long-context-review",
        "weight": 10,
        "task": "Review a long incident report and extract performance regression risks.",
        "slo_ttft_ms": 4000,
    },
    {
        "name": "interactive-revision",
        "weight": 5,
        "task": "Revise the previous Agent output with stricter acceptance criteria.",
        "slo_ttft_ms": 2500,
    },
]


def choose_scenario():
    return random.choices(
        SCENARIOS,
        weights=[item["weight"] for item in SCENARIOS],
        k=1,
    )[0]


class AgentE2ELoadUser(HttpUser):
    wait_time = between(1, 3)

    @task
    def run_agent_journey(self):
        scenario = choose_scenario()
        trace_id = f"locust-{uuid.uuid4().hex}"
        payload = {
            "case_id": f"agent-perf-{scenario['name']}",
            "task": scenario["task"],
            "stream": True,
            "trace_id": trace_id,
            "metadata": {
                "scenario": scenario["name"],
                "source": "locust-e2e-load",
            },
        }

        started_at = time.perf_counter()
        first_token_at = None
        final_status = "unknown"
        error_bucket = "none"

        with self.client.post(
            "/agent/run",
            json=payload,
            name=f"agent:e2e:{scenario['name']}",
            stream=True,
            catch_response=True,
            timeout=60,
            headers={"x-trace-id": trace_id},
        ) as response:
            try:
                for raw_line in response.iter_lines():
                    if not raw_line:
                        continue
                    event = json.loads(raw_line.decode("utf-8"))
                    if event.get("type") == "token" and first_token_at is None:
                        first_token_at = time.perf_counter()
                    if event.get("type") == "completed":
                        final_status = event.get("status", "unknown")
                        error_bucket = event.get("error_bucket", "none")
                        break

                e2e_ms = (time.perf_counter() - started_at) * 1000
                ttft_ms = (first_token_at - started_at) * 1000 if first_token_at else None

                if ttft_ms is not None:
                    events.request.fire(
                        request_type="METRIC",
                        name=f"agent:ttft:{scenario['name']}",
                        response_time=ttft_ms,
                        response_length=0,
                        exception=None,
                    )

                business_ok = final_status in {"succeeded", "degraded"} and error_bucket != "unclassified"
                if response.status_code == 200 and business_ok:
                    response.success()
                else:
                    response.failure(
                        f"business failure status={final_status} error_bucket={error_bucket} trace_id={trace_id}"
                    )

                events.request.fire(
                    request_type="METRIC",
                    name=f"agent:e2e:{scenario['name']}",
                    response_time=e2e_ms,
                    response_length=0,
                    exception=None,
                )
            except Exception as exc:
                response.failure(f"stream parse error: {type(exc).__name__}: {exc}")

这段脚本的重点不是语法，而是设计思想：每一次请求都带 case_id、scenario 和 trace_id；每一次成功都必须通过最终业务状态判定；TTFT 作为独立指标上报；错误必须分桶，不能只留下“失败了”三个字。

3.2 Locust 适合验证的 E2E 中间状态​

在 Locust 中，可以把单点验证下沉为 E2E 旅程的中间状态。例如工具重度场景的压测步骤可以这样组织：用户提交任务后，预期中间状态包括 planner_started、tool_call_started、tool_call_completed、first_token_emitted；最终验证点包括状态为 succeeded 或可解释的 degraded、结果产物存在、trace 中包含工具 span、未出现未分类错误。

这样设计符合真实用户视角，也能避免“工具 API 单独压测通过，但 Agent 编排在高并发下失败”的割裂。

4. k6 实战：把性能阈值固化为 CI 门禁​

4.1 k6 脚本结构​

k6 更适合做可重复的快速门禁。下面示例针对 HTTP streaming Agent 接口，统计 TTFT、E2E 耗时、业务成功率和未分类错误。

// agent-e2e-load.js
import http from 'k6/http';
import { check } from 'k6';
import { Counter, Rate, Trend } from 'k6/metrics';

export const agentTTFT = new Trend('agent_ttft_ms', true);
export const agentE2E = new Trend('agent_e2e_ms', true);
export const businessSuccess = new Rate('agent_business_success');
export const unclassifiedErrors = new Counter('agent_unclassified_errors');

export const options = {
  scenarios: {
    smoke_gate: {
      executor: 'ramping-vus',
      stages: [
        { duration: '30s', target: 5 },
        { duration: '1m', target: 20 },
        { duration: '30s', target: 0 },
      ],
    },
  },
  thresholds: {
    agent_business_success: ['rate>=0.99'],
    agent_ttft_ms: ['p(95)<2500', 'p(99)<5000'],
    agent_e2e_ms: ['p(95)<25000', 'p(99)<60000'],
    agent_unclassified_errors: ['count==0'],
    http_req_failed: ['rate<0.01'],
  },
};

const scenarios = [
  { name: 'short-planning', weight: 40, task: 'Create smoke checks for checkout API.' },
  { name: 'rag-answer', weight: 25, task: 'Answer a QA release risk question from knowledge base.' },
  { name: 'tool-heavy', weight: 20, task: 'Generate regression cases and call test data tools.' },
  { name: 'long-context-review', weight: 10, task: 'Review a long report and extract risk signals.' },
  { name: 'interactive-revision', weight: 5, task: 'Revise the prior answer using stricter acceptance criteria.' },
];

function pickScenario() {
  const total = scenarios.reduce((sum, item) => sum + item.weight, 0);
  let cursor = Math.random() * total;
  for (const item of scenarios) {
    cursor -= item.weight;
    if (cursor <= 0) return item;
  }
  return scenarios[0];
}

function parseStreamingBody(body) {
  let firstTokenMs = null;
  let finalStatus = 'unknown';
  let errorBucket = 'none';

  const lines = body.split('\n').filter(Boolean);
  for (const line of lines) {
    const event = JSON.parse(line);
    if (event.type === 'token' && firstTokenMs === null) {
      firstTokenMs = Number(event.elapsed_ms || 0);
    }
    if (event.type === 'completed') {
      finalStatus = event.status || 'unknown';
      errorBucket = event.error_bucket || 'none';
    }
  }

  return { firstTokenMs, finalStatus, errorBucket };
}

export default function () {
  const scenario = pickScenario();
  const traceId = `k6-${__VU}-${__ITER}-${Date.now()}`;
  const url = `${__ENV.AGENT_BASE_URL || 'http://localhost:8080'}/agent/run`;

  const payload = JSON.stringify({
    case_id: `agent-perf-${scenario.name}`,
    task: scenario.task,
    stream: true,
    trace_id: traceId,
    metadata: {
      scenario: scenario.name,
      source: 'k6-ci-gate',
    },
  });

  const startedAt = Date.now();
  const response = http.post(url, payload, {
    headers: {
      'content-type': 'application/json',
      'x-trace-id': traceId,
    },
    tags: {
      scenario: scenario.name,
    },
    timeout: '60s',
  });

  const e2eMs = Date.now() - startedAt;
  agentE2E.add(e2eMs, { scenario: scenario.name });

  let parsed = { firstTokenMs: null, finalStatus: 'unknown', errorBucket: 'parse_error' };
  try {
    parsed = parseStreamingBody(response.body || '');
  } catch (error) {
    unclassifiedErrors.add(1, { scenario: scenario.name });
  }

  if (parsed.firstTokenMs !== null) {
    agentTTFT.add(parsed.firstTokenMs, { scenario: scenario.name });
  }

  const ok = check(response, {
    'http status is 200': (r) => r.status === 200,
    'agent final status is acceptable': () => ['succeeded', 'degraded'].includes(parsed.finalStatus),
    'agent error is classified': () => parsed.errorBucket !== 'unclassified',
    'agent emitted first token': () => parsed.firstTokenMs !== null,
  });

  businessSuccess.add(ok, { scenario: scenario.name });
  if (parsed.errorBucket === 'unclassified') {
    unclassifiedErrors.add(1, { scenario: scenario.name });
  }
}