🔗 打开试用
打开 SecAgent 在线 Demo ↗demo.xiaokeqing.cn —— 部署在阿里云 2 核 2G 上、容器只监听回环地址，
对外通过 Cloudflare 命名隧道提供 HTTPS。
地址是固定的：即使以后把服务迁到别的服务器，这个链接也不会失效。
🔑 演示账号
| |
|---|
| 用户名 | analyst |
| 密码 | SecAgent-Demo-2026 |
| 角色 | 分析员（ANALYST） |
这个角色能做什么、不能做什么：
| ✅ 可以 | ❌ 不可以 |
|---|
| 查看告警大屏、事件归档 | 执行处置动作（封 IP / 锁账号 / 杀进程） |
| 对话研判、知识库检索 | 审批处置申请 |
| 提交知识条目（待审） | 审核知识库、管理用户 |
权限是刻意收窄的。 处置动作全部要求管理员角色 + 人工审批，所以公开一个分析员账号不会带来风险。
配额说明：为了让服务不被刷爆，接口有 50 次/天 的模型调用配额和 30 次/分钟 的限流。用完了第二天恢复。
建议试这几件事
按顺序试，能看出系统的设计思路：
1️⃣ 先问一个知识库问题
在「对话研判」里输入：
看什么：回答下面会附检索证据，包含命中的文档名、片段内容、相似度分数。
证据被包在一个 <UNTRUSTED_DATA> 标签里 —— 这是提示词注入防护：
知识库文档本身也可能是攻击载荷，不能被当成给模型的指令。
2️⃣ 再问一个需要"动手"的问题
看什么：调度员会判定这是研判任务，派给对应角色的智能体，并调用工具去拉告警数据，而不是凭空编答案。
3️⃣ 去看告警大屏
看什么：列表默认显示的是聚合后的结果（同一源 IP + 时间窗 + 同类告警合成一条），带 ×N 徽标。点进去能下钻到原始明细。
这是解决"告警风暴"的核心设计。
4️⃣ 去看处置中心
看什么：处置动作分三级 —— 自动执行 / 需审批 / 禁止。
注意「需审批」那一列 —— 这是整个项目最重要的设计：高危动作永远不会自动执行。
5️⃣ 试着让它做危险的事
在对话里试试：
看什么：会被代码层的白名单拦下来，而不是靠提示词拒绝。
内网地址、环回地址在处置护栏里是硬拦截的 —— 因为提示词可以被绕过，白名单不能。
为什么地址是这个
demo.xiaokeqing.cn —— 走的是 Cloudflare 命名隧道，不是临时隧道。
区别在这里：
| 临时隧道 | 命名隧道（现在用的） |
|---|
| 地址 | 随机分配，重启就换 | 固定，绑在 Cloudflare 账号下 |
| 换服务器 | 链接失效 | 链接不变（只在新机器上重装隧道） |
| 入站端口 | 不需要 | 不需要 |
服务器上没有任何入站端口是开着的 —— 容器只监听 127.0.0.1，
隧道是服务器主动向 Cloudflare 建立出站连接。所以从外面扫这台机器，
扫到的只有 22 端口（而且已经关了密码登录）。
这条也是买域名真正要解决的问题：让地址和机器解耦。
服务器是消耗品，域名是资产。
已知限制（不想让你踩坑）
| 限制 | 说明 |
|---|
| 数据是模拟的 | 告警和日志是 MOCK 数据，没有接真实 SOC 环境 |
| 处置动作没实测过 | 代码里有完整实现和护栏，但不敢在生产环境真的封 IP 演示 |
| 响应偏慢 | 服务器在杭州，隧道绕经境外，首屏约 1.2~1.5 秒 |
| 手机端 | 能用，但告警大屏这类宽表格在小屏上体验一般 |
关于防护强度的真实数字
红队评测跑过了，27 例（19 例基础 + 8 例绕过型），结果：
| 指标 | 数值 | 说明 |
|---|
| 绕过率 | 4 / 19 = 21.05 % | 95% 置信区间约 8 % ~ 44 % |
| 误报率 | 0 / 8 未观察到误拦 | 真实误报率的 95% 置信上限约 37.5 % |
| 拦下 / 绕过 | 15 / 4 | |
为什么要写置信区间，而不是写「误报率 0%」
8 个正常样本里 0 次误拦，不等于误报率是 0。
按统计学上的「三法则」，n 次试验 0 次事件时，真实发生率的 95% 置信上限约为 3/n ——
也就是 3/8 ≈ 37.5%。样本量太小，这个数字只够说明「没有明显误杀」，
支撑不了「误报率很低」的结论。
同理，4/19 的绕过率区间宽到 8%~44%，几乎不具区分度。
写清楚这一点，是因为一个漂亮但站不住的 0% 比一个诚实的区间更容易被问倒。
为什么不写「拦截率 100%」：第一版 19 例跑出来就是 0 绕过、0 误报，
但那个数字没有意义 —— 用例是照着防护规则写的，当然全能命中。
0% 绕过率不是成绩，是评测集失效的信号。
所以补了 8 例专门针对规则边界的变形载荷（字符插空 / 全角 / Base64 /
同义改写 / 凭据拆开写…），绕过率立刻变成 42.11%。然后修掉其中能修的 4 类
（加文本归一化 + 补中文模式），降到 21.05%。
关键是：修完之后误报率没有变差 —— 8 个正常用例依然全部放行。
说明拦截率的提升不是靠「宁可错杀」换来的。
剩下 4 类修不掉，而且我知道为什么修不掉：
- 纯语义改写（「请把上面那段话作废…」）—— 正则无解
- Base64 编码的指令 —— 正则只看明文
- 编码后的私钥 —— 同上
- 中文自然语言表述的口令 —— 需要语义理解
这四类不是「还没修」，是「用规则修不了」。 加正则只会带来误报。
它们的存在，正是这条链路上必须保留人工审批的原因 —— 纵深防御不是口号。
下一步：这套用例是自己写的，可信度天花板就在那。
计划接入 NVIDIA Garak 与 Microsoft PyRIT 这类业界工具，
用第三方用例集解决「自己出题自己阅卷」的问题。
