Nuxt3 AI Agent 控制台实战 15：公网试用前的访问控制、限频与模型开关

真实模型接入之后，我开始准备把 Agent Console 发给朋友试用。

本地自测和公网试用是两个阶段。

本地自测时，请求量、输入内容、执行次数都是可控的。

但一旦放到公网，就会出现很多不确定性：

复制代码

访问链接可能被转发
用户可能连续点击
用户可能输入超长文本
同一时间可能出现多个 Run
每次模型调用都会消耗 token
轻量服务器资源有限

所以在发给朋友之前，我先补了一层公网试用保护。

这部分不属于 Agent 核心执行链路。

但它决定了这个项目能不能安全地从本地 Demo 进入公网内测。

1. Access Code 访问控制

当前阶段没有做完整注册登录系统。

原因是项目还处在朋友内测阶段，没有必要接手机号、验证码、用户注册、密码找回等完整账号体系。

所以使用 Access Code。

流程是：

css 复制代码

用户打开网站
↓
输入 access code
↓
服务端校验 code
↓
校验通过后写入 httpOnly cookie
↓
后续页面和接口通过 cookie 判断访问身份

这样可以先满足内测阶段的基本访问控制。

这里还加了一个可选昵称。

昵称不是登录凭证。

它只是用于反馈场景。

比如用户提交反馈时，可以关联到这个昵称，方便后续追问上下文。

css 复制代码

access code：用于身份识别
nickname：用于反馈追踪

这两个职责分开。

2. 普通用户和管理员区分

普通访问用户只需要使用 Agent 功能和提交反馈。

但管理员需要查看线上数据，用于排查问题。

所以增加了 Admin Code。

普通 access code 登录后，只能访问：

复制代码

Agent 主页面
创建 Run
查看自己的当前执行过程
提交 Feedback

Admin code 登录后，可以访问：

复制代码

Run 列表
Conversation 列表
Feedback 列表
Run 详情页

这里的核心是权限边界。

即使是个人 Demo，也不能让普通用户看到所有会话和 Run 记录。

所以访问码分成两类：

css 复制代码

普通 access code
admin access code

这样既不用搭完整用户体系，又能满足内测阶段的权限隔离。

3. Run 创建频控

接入真实模型后，Run 创建频率必须限制。

因为每次 Run 都可能触发模型调用和 token 消耗。

当前增加了几类频控：

复制代码

单用户每分钟最多创建 Run 数
单用户每天最多创建 Run 数
全站每分钟最多创建 Run 数
全站每天最多创建 Run 数

可以理解为两层维度：

复制代码

用户维度
全站维度

用户维度防止某个访问码被频繁使用。

全站维度防止整体流量突然升高。

这里还有一个设计取舍：

如果多个人使用同一个 access code，他们会被识别成同一个 userId。

也就是说，他们共享同一套用户频控额度。

对于内测阶段，这是可以接受的。

因为可以给不同朋友发不同 code。

如果某个 code 使用异常，也更容易定位。

4. 并发 Run 限制

频控限制的是一段时间内创建 Run 的次数。

但 Agent Run 本身是持续执行的。

它可能会：

复制代码

保持 SSE 连接
调用真实模型
执行 Tool
执行 Skill
持续推送事件

所以还需要限制并发。

当前增加了：

复制代码

单用户同时最多执行 Run 数
全站同时最多执行 Run 数

这解决的是另一个问题：

复制代码

同一时间正在跑的任务不能太多

频控和并发限制的区别是：

复制代码

频控：限制创建频率
并发：限制运行中任务数量

Agent 项目里两者都需要。

因为 SSE 是长连接。

模型请求也可能持续一段时间。

如果并发不限制，几个长任务同时运行，就可能拖慢轻量服务器。

5. 输入长度限制

模型调用还需要限制输入长度。

因为用户可能一次性粘贴非常长的内容。

比如：

复制代码

长篇文章
整段日志
几十页文档
大量无关文本

这些都会增加 token 消耗。

所以增加了：

复制代码

MAX_RUN_INPUT_LENGTH

超过长度时，服务端直接拒绝创建 Run。

这不是最终形态。

更完整的方案可能是：

复制代码

文件上传
文档解析
分块
摘要
RAG

但当前 MVP 阶段，先做输入长度限制更直接。

目标是避免超长输入直接打爆模型成本。

6. 模型能力开关

这是最重要的一层保护。

增加环境变量：

ini 复制代码

MODEL_ENABLED=false

当模型能力关闭时：

复制代码

页面仍然可以访问
登录仍然可以使用
Feedback 仍然可以提交
但创建 Agent Run 会被拒绝

这样如果出现异常情况：

复制代码

访问码泄露
请求量异常
token 消耗异常
模型服务不稳定
服务器压力异常

可以先通过配置关闭真实模型能力。

不需要停整个网站。

也不需要马上改代码重新部署。

这个开关相当于模型调用的 Kill Switch。

对公网试用来说非常有必要。

7. Feedback 反馈入口

除了访问控制和频控，还增加了 Feedback 功能。

页面右下角提供反馈入口。

用户可以提交：

复制代码

问题
建议
使用感受
异常情况

反馈会写入数据库。

管理员可以在后台查看 Feedback 列表。

这个功能不复杂，但对内测很重要。

因为内测不是只看功能能不能跑。

更重要的是收集真实用户使用时遇到的问题。

反馈入口让用户可以在问题发生现场直接记录下来，而不是事后通过微信模糊描述。

8. 当前公网试用保护链路

现在一次用户访问大致是：

css 复制代码

访问网站
↓
输入 access code
↓
服务端校验 code
↓
写入 httpOnly cookie
↓
用户提交输入
↓
服务端校验 cookie
↓
校验输入长度
↓
校验用户频控
↓
校验全站频控
↓
校验用户并发 Run 数
↓
校验全站并发 Run 数
↓
校验 MODEL_ENABLED
↓
创建 Agent Run
↓
建立 SSE 连接
↓
推送 AgentEvent

管理员访问则多一层：

css 复制代码

输入 admin code
↓
写入管理员身份
↓
允许访问 Run / Conversation / Feedback 管理页面

这样项目就不再是裸奔的公网 Demo。

它有了基本的访问控制、成本保护和问题反馈能力。

9. 当前结果

这一阶段完成后，项目增加了：

css 复制代码

access code 登录
httpOnly cookie 身份标识
可选 nickname
admin code 管理员入口
Run 列表
Conversation 列表
Feedback 列表
Feedback 提交弹窗
单用户每分钟 Run 限制
单用户每日 Run 限制
全站每分钟 Run 限制
全站每日 Run 限制
单用户并发 Run 限制
全站并发 Run 限制
MAX_RUN_INPUT_LENGTH
MODEL_ENABLED Kill Switch

这些能力不属于 Agent 推理核心。

但它们属于公网试用必需的工程保护。

10. 本阶段踩到的关键点

这一阶段主要有几个感受。

第一个是：

复制代码

访问控制不一定一开始就做完整账号系统

朋友内测阶段，Access Code 足够简单，也足够实用。

第二个是：

复制代码

限频和并发限制不是一回事

限频控制创建次数。

并发控制运行中任务数量。

Agent + SSE 场景下，两者都要考虑。

第三个是：

复制代码

真实模型必须有 Kill Switch

只要接了真实模型，就要考虑 token 成本失控。

模型能力开关可以在异常时先止血。

第四个是：

复制代码

反馈入口是内测闭环的一部分

如果只发链接，没有反馈入口，问题很容易散落在聊天记录里。

有了 Feedback，问题可以回到系统里沉淀。

11. 总结

这一阶段不是在做 Agent 推理能力。

而是在补公网试用的边界。

以前本地开发时，我更关心：

复制代码

功能能不能跑通
SSE 能不能推送
模型能不能返回
数据库能不能落库

但一旦要发给别人试用，就要开始关心：

复制代码

谁能访问
能访问多少次
能不能并发
输入有没有限制
模型成本会不会失控
普通用户能不能看到管理数据
出问题能不能快速关闭模型能力
反馈能不能收集

这些不是核心功能。

但它们决定了一个项目能不能从本地 Demo 变成可试用产品。

当前阶段完成后，Agent Console 已经具备了基本公网试用能力。

下一步，就可以把链接小范围发给朋友，观察真实使用反馈，再继续迭代 Agent 的稳定性和体验。