Nuxt3 AI Agent控制台实战：访问控制、限频与模型开关配置指南

当真实的AI模型接入系统后，接下来的一步，就是把Agent Console发给朋友们试试水了。

这里有个关键的分水岭：本地自测和公网试用，完全是两码事。

在本地，一切尽在掌握——请求量、输入内容、执行次数，都是可控的。但一旦把链接扔到公网上，各种不确定性就扑面而来了：访问链接可能被转发分享，用户可能连续狂点按钮，也可能直接粘贴进来一篇万字长文。更不用说，同一时间可能出现多个并发任务，而每一次模型调用，都意味着实实在在的Token消耗。别忘了，我们用的还只是轻量级的服务器资源。

所以，在把链接发出去之前，得先给这个项目套上一层“公网试用保护甲”。这部分代码虽然不属于Agent执行的核心链路，但它却决定了这个项目能否安全地从本地Demo，平稳过渡到公网内测阶段。

1. Access Code 访问控制

项目还处在朋友内测的早期，现在就上马一套完整的注册登录系统（手机号、验证码、密码找回），显然有点杀鸡用牛刀了。所以，我选择了更轻量的方案：Access Code（访问码）。

流程设计得很直白：

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

这样一来，内测阶段最基本的访问控制需求就满足了。我还额外加了一个“可选昵称”的字段。注意，这个昵称不是登录凭证，它纯粹是为了反馈场景服务的——当用户提交问题时，可以关联到这个昵称，方便后续追踪和了解上下文。

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

两者职责分离，清晰明了。

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

普通访问者只需要使用Agent功能和提交反馈。但作为管理员，我需要一个入口来查看线上的数据，以便排查问题。于是，就有了“Admin Code”的概念。

用普通Access Code登录后，权限仅限于：

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

而使用Admin Code登录，则可以看到更多：

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

这里的核心在于权限边界。即便是个人Demo，也不能让所有用户都能看到其他人的会话和执行记录。所以，访问码干脆分成了两类：普通码和管理员码。这样，既不用搭建完整的用户体系，又能在内测阶段实现基本的权限隔离。

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. 模型能力开关

这是整个保护链路中最重要的一环，我称之为“安全阀”。我增加了一个环境变量：

MODEL_ENABLED=false

当模型能力被关闭时：

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

这样一来，如果出现任何异常情况——比如访问码意外泄露、请求量异常飙升、Token消耗过快、模型服务不稳定，或者服务器压力过大——我可以第一时间通过修改配置关闭真实的模型调用能力。

不需要停止整个网站，也无需立即修改代码重新部署。这个开关，本质上就是一个模型调用的“紧急制动拉杆”（Kill Switch），对于公网试用来说，至关重要。

7. Feedback 反馈入口

除了访问控制和频控，一个便捷的反馈入口也必不可少。我在页面右下角添加了反馈功能，用户可以提交遇到的问题、改进建议、使用感受或任何异常情况。

这些反馈会被写入数据库，管理员可以在后台统一查看。这个功能本身不复杂，但对内测却极其重要。内测的目的不仅仅是看功能能否跑通，更重要的是收集真实用户在使用中遇到的具体问题。一个嵌入场景的反馈入口，能让用户在遇到问题的当下就记录下来，远比事后在微信上模糊描述要高效得多。

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

现在，一次完整的用户访问流程大致如下：

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

管理员访问则额外多一层校验：

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

经过这番加固，项目不再是一个在公网上“裸奔”的Demo。它具备了基本的访问控制、成本防护和问题反馈能力。

9. 当前结果

这一阶段的工作完成后，项目增加了以下特性：

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的稳定性和用户体验。