QGS 质量门禁系统：给 AI Agent 装上"刹车和质检"

当 AI Agent 开始自主执行多步操作时，你如何确保它不会”脑子一抽”干出离谱的事？QGS（Quality Gate System）就是为此而生的一套内嵌质量门禁系统。

问题：Agent 失控的两个瞬间

设想两个场景：

场景一：你让 Agent “部署一下这个服务”，它开心地执行了 rm -rf /（误），然后告诉你”部署完成！”

场景二：Agent 写了一篇技术文章，看起来头头是道，但里面引用的 API 版本已经过时了三年，调用的方法根本不存在。

这类问题在传统的 LLM 对话中并不突出——因为每轮输出你都肉眼可见。但当 Agent 进入自主执行模式——连跑十几轮工具调用、读写文件、操作浏览器、部署服务——你就没法每步都盯着了。

QGS 就是那个在后台默默盯着的”质检员”。

什么是 QGS？

QGS = Quality Gate System，直译是”质量门禁系统”。它不是一个独立的外部工具，而是嵌入在 Agent 执行循环内部的一套质量控制框架。

形象点说，传统 Agent 的执行循环像一条单向高速公路：

1	用户输入 → LLM 思考 → 工具调用 → 输出结果

而 QGS 给这条高速装上了多个收费站：

用户输入 → [分类器] → LLM 思考 → [约束注入] → 工具调用 → [评审器] → 输出结果
                                                                     ↓
                                                                  [门禁决策]
                                                                  ↓       ↓
                                                               通过/建议  阻断/修订

每个”收费站”都在做不同的事：

收费站	做什么	触发频率
🏷️ 分类器	判断任务类型和复杂度	每次任务开始
💉 约束注入	在 prompt 里塞质量要求	SIMPLE 不注入，其余每轮注入
📝 评审器	用独立 LLM 给输出打分	每 2 轮一次
🚫 门禁	根据评分决定阻断/继续	每轮检查
🔍 判别者	深度对抗式审计	COMPLEX/REFLECT 任务每 10 轮

架构探秘：6 个模块

QGS 由 6 个 Python 模块组成，彼此独立又能灵活组合：

1. 分类器（classifier.py）— 任务”安检门”

第一道关卡：判断用户来了个什么活儿。

采用两层分类架构——规则层兜底 80% 场景，LLM 层处理模糊情况：

# 规则层示例
QUERY_PATTERNS = [r"现在.*几[点钟时]", r"天气|温度|湿度"]
ACTION_PATTERNS = [r"(部署|发布|上线|重启)", r"(删除|移除|安装)"]
CRITICAL_PATTERNS = [r"删库|DROP\s+(TABLE|DATABASE)", r"rm\s+-rf\s*/"]

分类结果决定后续策略：

任务类型	复杂度	是否评审
QUERY（查时间）	SIMPLE	❌ 零开销跳过
GENERATE（写文章）	COMPLEX	✅ 完整评审
ACTION（部署服务）	COMPLEX	✅ 完整评审
CRITICAL（删库）	REFLECT	✅ 对抗式评审

2. Critic 评审器（critic.py）— LLM 考官

使用独立模型（默认 gpt-4o-mini）对 Agent 的交付物进行客观评审。

按任务类型动态调整评审维度：

QUERY    → 准确性、相关性
GENERATE → 完整性、正确性、清晰度、可行性
ACTION   → 安全性、必要性
CRITICAL → 全部维度 + 人工确认

输出格式是严格的 JSON：

{
  "verdict": "PASS",
  "score": 85,
  "dimensions": [
    {"name": "完整性", "score": 90, "issues": ["缺少异常处理"]},
    {"name": "正确性", "score": 80, "issues": []}
  ],
  "must_fix": ["添加 try-catch"],
  "summary": "整体质量良好，但异常处理可以加强"
}

值得点赞的一个设计是——它还内置了光环效应检测：如果所有维度的评分差异小于 10 分，它会发出警告：”可能存在光环效应，建议人工复核”。这防止了评审者被整体印象带偏。

3. 门禁逻辑（gate.py）— 刹车踏板

decide_gate() 函数根据评审结果做出 4 种决策：

决策	含义	条件
✅ pass	直接放行	评审 verdict = PASS
📝 pass_with_suggestions	放行，但带改进建议	PASS_WITH_SUGGESTIONS
🔄 revise	打回修订	FAIL 且未超上限
🏳️ force_deliver	强制交付	第 4 轮仍 FAIL，降级交付

同时 should_terminate() 管理修订循环的收敛检测：

硬上限：最多 4 轮修订
震荡检测：评分 up-down-up 说明在反复横跳，终止
收敛判定：连续两轮评分差 < 5 分，认为稳定了
递减收益：高分区间改进 < 3 分，再改也没意义了

4. 对抗式判别者（discriminator.py）— 多专家会诊

对于复杂或关键任务，QGS 会启动多角色判别者进行深度审计。

采用 P0-P4 严重度模型：

等级	权重	含义	例子
🔴 P0	100	致命缺陷	删库命令、隐私泄露
🟠 P1	50	严重缺陷	核心功能缺失
🟡 P2	20	一般缺陷	边界未处理
🔵 P3	10	轻微缺陷	命名不规范
⚪ P4	5	建议改进	体验优化建议

当前内置了现实检验者（Reality Checker），负责检查 Agent 的输出是否基于事实而非幻觉。后续可扩展安全审计者、性能基准师、API 测试者等——这和 Arena 对抗式解题法中的判别者体系是同一套基因。

5. 会话管理器（session_manager.py）— 资源管家

在 1.8GB 的低配 VPS 上运行 LLM 调用是需要精打细算的。这个模块负责：

判别者串行执行而非并行（防止 OOM）
每次创建独立 session，不污染主对话历史
完成后立即释放资源

1
2
3

# 低内存模式的自我保护
if self.low_memory_mode and self._active_sessions:
    self._active_sessions.clear()

6. 数据模型（task.py）— 骨架

定义了 Task、Review、DimensionScore、DeliverableSnapshot 等核心数据类。每次评审的评分、每次修订的版本都会被记录，支持回滚到历史最优版本。

QGS 与 Arena 的关系：宏观与微观

你可能会问：我们不是已经有 Arena 对抗式解题法了吗？那个也是多角色评审，QGS 不是重复了吗？

这是我一直想强调的：它们在不同抽象层级上工作。

🎪 Arena（宏观管理层）
   管理：选人 → 分派 → 监控 → 评审 → 交付
   视角：整个解决方案的质量
   评审者：独立子代理（架构师/写手/判别者...）
   
🔍 QGS（微观执行层） 
   管理：分类 → 约束 → 评审 → 阻断 → 判定
   视角：每一轮 Agent 输出的质量
   评审者：轻量 LLM 调用（gpt-4o-mini）

打个比方：Arena 像是一个项目经理，负责把控整体方案方向；QGS 像是一个代码审查机器人，每次提交都自动跑一遍 lint + 单元测试。

两者互补：

Arena 的判别者发现”这个方案架构不对”——这是宏观问题
QGS 在子代理执行过程中发现”这轮输出了乱码”——当场阻断，省得 Arena 空等

实际运行效果

从今天起，QGS 已经在 GenericAgent 的生产环境中运行。这次对话本身就是在 QGS 的监控下进行的。

分类效果验证：

输入	类型	复杂度
“现在几点了”	QUERY	SIMPLE（零开销跳过）
“帮我写一篇关于AI的文章”	GENERATE	COMPLEX
“删除数据库中的所有记录”	CRITICAL	REFLECT
“部署这个服务”	ACTION	COMPLEX