这次是实训，这次不单打独斗#

之前写的 GameMind 是一个「单 Agent + RAG」的问答系统——一个大模型从头包办到底。这次的实训项目换了个打法：多智能体架构。系统叫「游戏知识与游戏识别多智能体系统」，要解决的问题是——

Steam 上躺着 382MB、125,855 条、32 个字段的游戏数据。想从里面知道「近十年发行的最贵游戏是哪款」，传统路径是：装数据库 → 学 SQL → 写查询 → 学个可视化工具画图。而在这个系统里，你只需要把这句话原样说出来。

七个智能体，各干各的#

一次提问的完整旅程是七步：敏感词过滤 → 角色判定 → 智能路由 → 权限校验 → Agent 执行 → 结果解析 → 前端渲染。问「画一个各类型游戏数量的柱状图」，Chart Agent 出图、右侧面板同步弹数据表格；问「把这份报告发到我邮箱」，得先看你的角色有没有这个权限。

最想聊的设计：LLM 只花在刀刃上#

这个项目做完，我最有感触的反而是——两个最关键的「决策」环节，压根没用 LLM。

路由是纯关键词匹配。Router Agent 维护一张带优先级的关键词表，命中即分发，全部没命中就兜底给游戏问答：

1
# 优先级：chart/email/file/predict > sql > game
2
for cat in _PRIORITY_ORDER:          # 按优先级检查，先匹配到的 wins
3
    for kw in ROUTE_CATEGORIES[cat]["keywords"]:
4
        if kw in question_lower:
5
            return {"agent": info["agent"], "confidence": 0.9}
6
return {"agent": "game_agent", "confidence": 0.5}   # 兜底

角色判定也是纯正则。一段 _ADMIN_KW/_ANALYST_KW 的关键词正则，毫秒级判定 admin / analyst / user。

为什么不上模型？因为这两个环节对「快、稳、便宜」的要求远高于对「聪明」的要求——用 LLM 做路由，每次提问多一次 API 往返、多一分幻觉风险，换来的是几乎为零的收益增益。真正需要智能的环节——自然语言转 SQL、总结查询结论、选择图表类型——才把 MiMo 大模型请出来。多智能体系统设计的第一个问题不是「用几个模型」，而是「哪些环节值得用模型」。

SQL Agent 的双保险#

让 LLM 生成 SQL 是件危险的事，所以做了两层防护：

第一层，提示词约束——明确只允许生成 SELECT、规定 SQLite 方言（禁用 SUBSTRING_INDEX 这类 MySQL 函数）、约定按类型查用 tags LIKE '%类型%'，并要求返回严格的 JSON 格式。

第二层，代码层校验——LLM 的输出永远不可信，提示词只是「请求」，校验才是「法律」：

1
sql_stripped = sql.strip().rstrip(";")
2
if not sql_stripped.startswith("SELECT") and not sql_stripped.startswith("WITH"):
3
    return '{"error": "安全限制：只允许 SELECT 查询"}'

不是 SELECT/WITH 开头，直接拒绝。数据库层面同样只读——写操作在物理上就不存在通道。这套「提示词约束 + 代码校验 + 最小权限」的组合拳，是我这次实训里学到的最实用的 LLM 安全姿势。

权限三件套#

系统按 admin / analyst / user 三种角色做了权限矩阵：分析师能查数据、画图、做预测，普通用户只能问游戏知识，邮件和文件分析只有管理员能碰。配上入口处的敏感词过滤，构成「内容安全 + 功能权限 + 数据只读」三道闸门。

有意思的是权限判定的时机——它发生在路由之后、执行之前：先搞清楚「这个问题该谁管」，再检查「你有没有资格让它管」。职责链清晰，每一层都可以独立测试。

技术栈#

从 GameMind 的单 Agent 到这次的七 Agent 分工，我对多智能体的理解从「多就是好」收敛成了一句话：多智能体的本质不是堆模型，而是把一个系统拆成「路由、权限、执行」三种角色，让贵的智能只出现在值得的地方。路由用关键词，判定用正则，生成用大模型——各安其位，这大概就是工程和炫技的区别。