Nginx 用了 20 年成为 Web 基础设施，Aginx 走同样的路
|
admin
2026年5月8日 11:18
本文热度 48
|
2004 年，Igor Sysoev 发布了 nginx。最初它只有一个功能：HTTP 反向代理。把请求从客户端转发到后端服务器。没有人想到，20 年后，nginx 会承载全球 34% 的网站流量，成为互联网基础设施。每一次演进，都解决了一个真实的问题。不是提前设计，而是在实践中生长。但方向从一开始就确定了：做一个更好的 Web 服务器。今天 AI Agent 的情况，和 20 年前 Web 的情况惊人地相似：• 网站很多，但访问方式混乱 → Agent 很多，但各自为战• 每个 Web 服务器自己搞一套 → 每个 Agent 框架自己搞一套• 没有统一的标准（后来有了 HTTP）→ 没有统一的 Agent 协议• 安全问题频出（SQL 注入、XSS）→ 安全问题还没人重视• 需要负载均衡、缓存、WAF → 同样需要，但还没人做30 年前 nginx 解决了网站的访问问题，今天 Aginx 解决 Agent 的访问问题。• aginxium → Chromium：统一客户端引擎• aginx-api → DNS / 注册中心：Agent 注册、发现、认证• aginx-relay → CDN / 骨干网：NAT 穿透、连接转发• agent:// URL → https:// URL：统一寻址aginx 接收客户端请求，路由到对应的 Agent。就像 nginx 不关心网站用什么语言写的一样，aginx 不关心 Agent 内部用什么模型、什么框架。放一个 aginx.toml，任何 CLI 都能接入。访问控制 — 对标 nginx per-location 权限nginx 的权限不是全局开关，而是 per-location 规则。aginx 同理——per-client 权限控制：绑定（主人全权限）和授权（访客受限，精确到"你能访问哪些 Agent、能调用哪些方法"）。通过 Relay 中继时，消息端到端加密。X25519 ECDH 密钥交换 + ChaCha20-Poly1305 加密。和 Signal 用的同一个级别的加密。每个 aginx 实例有一个 agent:// 地址。客户端只需要知道这个地址，不需要知道 IP、端口、协议。Relay 服务器解决内网穿透。你的服务器在内网？没有公网 IP？没问题。aginx 主动连接 Relay，自动注册，外部客户端通过 Relay 访问。nginx 用了 20 年成为基础设施。Aginx 也有一条清晰的路线图。一个人访问自己的 Agent。消息路由、两级认证、三种访问模式、端到端加密、Relay 中继、agent:// URL。这就是 nginx 2004 年的状态——核心能力已经能用了。Agent 之间互相发现和调用。这是关键的跨越。就像互联网从"单机访问网站"变成"网站互相链接"，Agent 也要从"人访问 Agent"变成"Agent 访问 Agent"。基础设施已经就绪：Relay 不区分连接方是人还是 Agent；aginx 已实现 ACP 协议两端；只需要加一个轻量 Agent-to-Agent 客户端模块。全球 Agent 互联互通，自组织协作。Agent 市场和发现机制、Agent 编排和组合、跨组织的 Agent 协作。nginx 后来加上了 ModSecurity WAF（Web 应用防火墙）。WAF 挡住了 SQL 注入、XSS、CSRF、恶意爬虫。没有 WAF 的 Web 服务器，就像没有门的金库。Agent 互联网同样需要防火墙。而且可能比 Web 更需要。Web 请求是结构化的——有 URL、有方法、有参数。WAF 可以按规则匹配。Agent 请求是非结构化的——是自然语言。一个 prompt 调用，内容可能是"帮我查个数据"，也可能是"删掉所有文件"。这意味着 Agent 防火墙的难度更高，但也更重要。• 请求过滤：按规则拦截恶意 prompt（对标 WAF 规则引擎）• 频率限制：防止单个客户端过度调用（对标 nginx rate limiting）• 敏感操作审计：记录所有涉及文件/命令的操作（对标 nginx access log）• 智能检测：用小模型判断 prompt 是否安全（对标 ModSecurity CRS）• 白名单/黑名单：控制 Agent 可被谁访问（对标 nginx allow/deny）# 未来：~/.aginx/firewall.toml
[rate_limit]
max_prompts_per_minute = 30
max_prompts_per_hour = 500
[audit]
log_file_operations = true
log_command_execution = true
alert_on_deletion = true
[[rules]]
action = "block"
pattern = "rm -rf /"
description = "阻止危险命令"
[[rules]]
action = "review"
pattern = "DROP TABLE"
description = "数据库操作需要人工审核"
就像 nginx + ModSecurity 是 Web 的安全屏障，aginx + Aginx Firewall 会成为 Agent 的安全屏障。把 Aginx 的路线图和 nginx 的演进放在一起看：✅ 已完成：反向代理/消息路由、访问控制、SSL/TLS/加密、统一寻址、NAT 穿透📋 规划中：负载均衡、缓存、健康检查、灰度发布、监控仪表盘nginx 用了 20 年走完了这些。Aginx 不需要 20 年——因为我们已经知道路在哪。但也不需要着急。nginx 的每一个功能都是在真实需求驱动下加的，不是提前设计的。Aginx 也一样。有人可能会说：nginx 和 Aginx 只是名字像，本质上是不同的东西。不对。它们解决的是同一类问题——如何让分布式的服务可以被可靠、安全、高效地访问。• 怎么找到服务？DNS + URL → aginx-api + agent:// URL• 怎么路由请求？upstream 配置 → aginx.toml 配置• 怎么控制权限？per-location 规则 → per-client JWT• 怎么防护？WAF → Aginx Firewall问题相同，领域不同，架构模式一致。这就是为什么 Aginx 能站在 nginx 的肩膀上——不是因为模仿，而是因为 Agent 互联网和 Web 互联网面临同样的工程问题。• Aginx 的每一个组件都对应互联网的一个基础设施• 核心能力已就绪：消息路由、访问控制、加密、寻址、穿透• 路线图清晰：单点访问 → Agent 互联 → Agent 生态• 下一阶段重点：Aginx 防火墙、限流、审计日志• nginx 用了 20 年成为 Web 基础设施，Aginx 走同样的路30 年前没有人能想象今天的互联网。今天我们也不能想象未来的 Agent 互联网。但我们知道路在哪——因为互联网已经走过一次了。下一篇，我们聊聊 Aginx 和其他 Agent 协议的区别——MCP、A2A、ACP、ANP，它们各解决什么问题？为什么 Aginx 不用其中任何一个？
阅读原文：https://mp.weixin.qq.com/s/W-HhpdORGAlXHU23WOnn-g
该文章在 2026/5/8 11:18:11 编辑过
400 186 1886
