AI代理 on AI博士万戈

狂飙 5 倍！AWS 大幅提升 AgentCore 配额，AI 代理生产部署迎来临界点！

Fri, 03 Jul 2026 00:00:00 +0000

你有没有过这种体验：辛辛苦苦写好一个 AI 代理，测试一切正常，一上生产就卡在"配额不够"四个字上？

AWS 显然听到了这个声音——而且是全球几百家企业的集体呐喊。昨天他们干了一件很实在的事：把 Amazon Bedrock AgentCore 的运行时配额一口气提升了最高 5 倍。

不是什么花哨的新功能发布，就是一个实打实的限幅器调整。但对正在把 AI 代理推向生产的人来说，这消息比十个新模型发布都来得实在。

涨了多少？一张表看得清清楚楚

新配额已经生效，不用提工单，不用审批，自动应用到所有企业账号。具体涨幅如下：

并发会话数：美东（弗吉尼亚北部）和美西（俄勒冈）从 1,000 涨到 5,000，其他区域从 500 涨到 2,500
Agent 吞吐量：每个代理每秒可处理的消息数从 25 tokens/s 暴涨到 200 tokens/s —— 8 倍提升
容器化部署会话创建速率：从 100 TPM（每分钟请求数）提升到 400 TPM，方便应对流量洪峰

AWS 在 release notes 里写得很清楚：这些是新的默认值，不需要你申请，直接用。

Forrester 分析师 Charlie Dai 一句话点出了本质：“更大的变化不是代理的数量，而是企业正在从单任务 Copilot 转向多生产级 Agent 服务更大规模的用户群。”

多 Agent 系统的"隐性瓶颈"

如果你只是跑几个实验性的代理，旧的配额绰绰有余。但 Gartner 的 Ashish Banerjee 观察到一个关键趋势：现在的企业 AI 代理已经不是单个对话机器人了，而是一整套多 Agent 编排系统。

Kanerika 的 CDA Amit Chandak 道出了很多一线工程师的心声：

“在企业环境里提一个配额增加请求，意味着要开支持工单、写业务 justification、走审批流程——几天到几周的 overhead，就为了一个本不该阻碍部署的事情。”

更严重的是，生产环境中跑满配额不是小事。Chandak 接着指出：

“Agent 会话是有状态的。当会话在任务执行中途被限流，Agent 会丢失中间上下文，重建这个状态比重试一次无状态 API 调用要难得多。在多 Agent 管道里，一个被拒绝的会话就能卡住整个工作流——产生孤儿会话、未完成的工具调用，以及事后极难排查的监控缺口。”

这对于任何一个做过 DevOps、跑过生产系统的人来说，都太熟悉了。有状态系统的限流问题，比无状态 API 重试要恶毒得多。

AWS 与微软：两种不同的哲学

有意思的是，AWS 并不是唯一在调整 AI 代理基础设施的超大厂。但每家走的路完全不同。

Chandak 对比了两家策略：

AWS：在运行时层提高配额门槛，让更多并发会话在默认配置下就能跑。这意味着团队设计架构时可以把 AgentCore 作为一个"高天花板"的平台来信赖。
Microsoft（Azure Foundry Agent Service）：很多运行时限制是设计上不可调整的，即便申请也不能增加。微软把弹性放在了模型部署层——配额可调的是模型端点，不是 Agent 运行时。

这是深思熟虑的架构决策差异，而不是谁对谁错。AWS 选择了"让平台承压"，微软选择了"让模型层承压"。对做技术选型的团队来说，这不是一个可以随便选的细节——它会直接影响你的系统架构和运维策略。

Avasant 研究总监 Gaurav Devan 认为，最受益的行业包括：客服与联络中心、软件工程与 DevOps 自动化、IT 运维、金融服务流程自动化、医疗管理、供应链协同和安保运营——这些都是 AI 代理同时大规模运行的典型场景。

写在最后

我一直觉得，AI 代理真正走向生产的关键障碍，从来不是模型能力不够，而是基础设施还没准备好。GPU 算力是一个维度，但运行时配额、有状态会话管理、多 Agent 编排这些"无聊"的工程问题，才是决定 AI 代理能不能从 demo 变成 day-1 生产负载的真正瓶颈。

AWS 这次把配额提升 5 倍，看起来只是调了几个数字，但对正在把 AI 代理推向生产一线的团队来说，这是一个非常积极的信号——云平台终于开始认真对待 AI 代理作为生产级工作负载了。

接下来我期待看到的是：Agent 的可观测性工具、故障恢复机制、成本管控能力，能不能也跟上这个节奏。

毕竟，能跑起来是一回事，能跑稳是另一回事。

一个 tunnel 搞定所有 MCP 服务！开源项目 MCPZERO 让团队共享 AI 工具不再折腾！

Fri, 03 Jul 2026 00:00:00 +0000

你有没有遇到过这种场景：自己在本地折腾了一个 MCP 服务，能连 Cursor 了、能查数据库了、能操作文件了，开心得不行。然后同事问"你这个怎么连的？"——接着你就陷入了端口转发、内网穿透、TLS 证书、API 鉴权的一地鸡毛里？

把本地 MCP 服务分享给团队，本来不该这么痛苦。

最近发现了一个很有意思的开源项目 MCPZERO，一句话概括就是：把你的本地 MCP 服务通过一条加密隧道发布出去，别人拿个 HTTP URL + API Key 就能用。不用开端口，不用配域名，不用折腾 TLS。

项目地址：https://github.com/mcpzero/mcpzero

MCP 共享为什么是个麻烦事？

Model Context Protocol（MCP）是今年 AI 工具链里最火的一套标准。它让 AI 客户端（Cursor、Claude、Codex 这些）能通过统一的接口调用外部工具——查数据库、读文件、运行脚本、访问 API。

但 MCP 标准本身只定义了通信协议，没解决连接问题。

目前的 MCP 场景基本分两类：

本地 stdio 模式：AI 客户端直接启动 MCP 服务进程。简单直接，但只能本机用，别人连不上。
HTTP/SSE 模式：MCP 服务跑在某个 HTTP 端点上。可以远程访问，但你要自己搞定域名、TLS、鉴权、防火墙。

换句话说，从"我本地能用"到"团队都能用"，中间隔着好几层基础设施的活儿。每个团队都得自己造一遍轮子。

而 MCPZERO 就是来填这个坑的。

MCPZERO 是什么？

先看它的定位：MCP 聚合网关（Aggregation Gateway）。

不是什么新协议、不是替代 MCP 标准，就是在你的 MCP 服务和外部客户端之间加了一层。它有四个核心能力：

1. 零配置隧道 在本地跑一条命令 mcpzero tunnel start，它会自动读取你已有的 mcp.json 配置，把所有的 stdio MCP 服务通过一条加密 WebSocket 隧道连接到 MCPZERO 网关。然后网关给你一个公开的 HTTPS 端点。不需要开端口、不需要配域名、不需要管 TLS 证书。

2. 语义聚合 你本机可能跑了 5 个 MCP 服务：Postgres 查询、文件系统操作、浏览器自动化、GitHub API、Slack 消息。MCPZERO 把它们聚合成一个端点，每个服务有独立的路径。客户端可以直接访问 /v1/ep_xxx/postgres 或 /v1/ep_xxx/filesystem，也可以访问根路径让网关自动路由。

3. 渐进式发现 这个设计很聪明。AI 客户端不需要一开始就加载所有服务的 tool schema——网关支持 meta_search 和 meta_call_tool，让 Agent 根据意图动态匹配工具，节省上下文 token。

4. 零信任安全 每一个公开端点都在网关侧强制鉴权。客户端用 Authorization: Bearer <API Key> 认证，解码时间在 5ms 以内。你的 MCP 服务本身不需要知道谁来调用了它——身份验证和授权完全由网关处理。

一个实战案例：暴露本地 SQLite 数据库

光说概念不过瘾，我们直接上一个真实可跑的案例。

假设你本地有一个 SQLite 数据库 demo.db，里头有客户数据。你想让 Cursor 能通过 AI 对话查询这个数据库——但不暴露数据库文件本身，也不开任何端口。

第一步：安装 CLI

brew install mcpzero/tap/mcpzero-cli
# 或者 curl -fsSL https://mcpzero.io/install-cli.sh | sh
# 或者 npm install -g mcpzero-cli

第二步：注册账号，创建一个端点

去 https://mcpzero.io/app 注册，创建一个 endpoint，拿到 ep_abc123 这样的 ID。

第三步：启动隧道

mcpzero tunnel start \
  --endpoint ep_abc123 \
  --mcp-cmd "uvx mcp-server-sqlite --db-path $(pwd)/demo.db"

看到 tunnel registered 后，你的 SQLite 数据库就已经发布到公网了。但数据库文件从来没离开过你的机器——只有查询结果通过加密隧道流出去。

第四步：生成 API Key，测试调用

在 Dashboard 里生成一个 mz_live_xxx 的 API Key，然后用 curl 测试：

curl -s https://gw.mcpzero.io/v1/ep_abc123 \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer mz_live_xxx" \
  -d '{
    "jsonrpc":"2.0","id":1,"method":"tools/call",
    "params":{
      "name":"read_query",
      "arguments":{"query":"SELECT name, email FROM customers LIMIT 3"}
    }
  }'

第五步：连到 Cursor

在 ~/.cursor/mcp.json 里加一行：

{
  "mcpServers": {
    "my-sqlite": {
      "url": "https://gw.mcpzero.io/v1/ep_abc123",
      "headers": { "Authorization": "Bearer mz_live_xxx" }
    }
  }
}

搞定。现在你和你的团队都可以在 Cursor 里直接通过自然语言查询这个数据库了。整个过程不需要写一行网络配置代码。

为什么说 MCPZERO 值得关注？

说实话，做 MCP 网关的项目不少，但 MCPZERO 有几个让我觉得「有点意思」的设计：

开源 + 商业的清晰边界 CLI 和 SDK 全部 MIT 开源，可以自己研究甚至自建。免费版够 solo 开发者用（每月 3 万次请求），Team 版（$199/月）加上了团队共享和审计日志。商业和开源没有模糊地带。

多语言 SDK 官方提供 TypeScript、Go、Python、Rust 四套 SDK——不管你团队用什么技术栈，都能集成。这对需要把 MCP 能力嵌入自家产品的团队很友好。

企业级安全功能 Team 以上版本带 Semantic WAF——不仅能鉴权，还能检查每个 tools/call 的参数有没有恶意注入。在 AI Agent 越权攻击越来越常见的今天，这个功能不是锦上添花，是必需品。

流量可观测 Dashboard 上能看到每次调用的工具名、延迟、状态码。调试阶段这个功能省大事了——不用再抓包猜问题。

写在最后

我一直认为，MCP 协议本身是个好东西，但它目前最大的瓶颈不是能力不够，而是连接和共享太麻烦。每个团队都在重复造轮子：写端口转发脚本、配 Nginx、折腾认证。

MCPZERO 解决的就是这个"最后一公里"的问题。它不发明新协议，不做魔改，就是在现有 MCP 生态上加了一层 engineering-friendly 的基础设施。这正是开源工具该有的样子——解决一个具体问题，解决得漂亮。

如果你正在把 MCP 引入团队协作场景，值得给 MCPZERO 一个周末的时间试试看。毕竟，让 AI 工具链从「我本地能跑」到「团队都能用」，差的就是一个靠谱的网关。

p.s. 免费版永久可用，没有时间限制。打开浏览器去 https://mcpzero.io 注册就行。

Tags: MCP, MCPZERO, 开源, AI代理, 网关, 团队协作, Cursor, Claude

AI代理 on AI博士 万戈

狂飙 5 倍！AWS 大幅提升 AgentCore 配额，AI 代理生产部署迎来临界点！

涨了多少？一张表看得清清楚楚

多 Agent 系统的"隐性瓶颈"

AWS 与微软：两种不同的哲学

写在最后

一个 tunnel 搞定所有 MCP 服务！开源项目 MCPZERO 让团队共享 AI 工具不再折腾！

MCP 共享为什么是个麻烦事？

MCPZERO 是什么？

一个实战案例：暴露本地 SQLite 数据库

为什么说 MCPZERO 值得关注？

写在最后

AI代理 on AI博士万戈