多智能体常见坑点

核心结论（4 条必记）

先做可控，再追求智能 -- 在受限场景验证基本能力，再扩展到开放场景
先做工程，再做功能 -- 生产系统必须具备"容错、可观测、可控制"三要素
先做监控，再做优化 -- 没有数据支撑的优化是盲目的
先做安全，再做发布 -- 安全是生产系统的底线

一、盲目追求"智能涌现"

坑点描述

以为堆砌多个 Agent 就能"涌现"出智能，忽略基础工程能力。看到 MetaGPT 的 Demo 很酷，就迫不及待地在自己的业务场景上复制，结果发现效果远不如预期。

根本原因

混淆了"Demo 效果"和"生产效果"
没有针对具体业务场景做工程设计
过度依赖模型的"创造力"，缺乏约束

解决方案

智能 = 好的设计 + 好的工程 + 好的数据。先做可控，再追求智能。

明确每个 Agent 的职责边界，不做"万金油"Agent
设计清晰的输入输出接口，而不是让 Agent 自由发挥
先在受限场景（如 FAQ 回答）验证基本能力，再扩展到开放场景
每次只增加一个变量，观察效果变化

二、Demo 思维上生产

坑点描述

用 Jupyter Notebook 跑通了一个 Demo，就直接上线了。没有异常处理、没有日志监控、没有成本控制、没有安全防护。上线后问题频出：偶发超时、Token 消耗失控、输出格式不一致。

根本原因

缺乏工程化思维，把"能跑"等同于"可用"
没有建立生产级的质量标准
忽略了 LLM 的不确定性（同样输入可能不同输出）

解决方案

生产系统必须具备"容错、可观测、可控制"三要素。

上生产前检查清单：

检查项	要求
异常处理	每个 LLM 调用都有 try-catch，超时保护
日志记录	记录输入、输出、耗时、Token 消耗
成本控制	单次请求限额、每日预算上限
安全防护	输入检测、输出审核、敏感信息脱敏
格式控制	Pydantic 校验输出格式，格式错误自动重试
降级方案	主模型不可用时的备选方案
监控告警	错误率、延迟、成本的实时告警

三、过度依赖 OpenAI

坑点描述

系统全部使用 OpenAI API，结果遇到：国内访问不稳定、延迟高、成本快速上升、数据合规风险。

根本原因

没有做模型抽象层，直接硬编码 OpenAI SDK
没有评估国产模型的实际能力
没有考虑数据出境的合规风险

解决方案

尽早做国产化适配，设计时保持模型无关性。

封装统一的模型调用层，支持多厂商切换
按任务复杂度分级使用模型：简单任务用国产模型，复杂任务用 GPT
优先使用 OpenAI 兼容接口，减少代码改动
建立模型能力对比表，定期评估国产模型进展

模型选择策略：

任务类型	推荐方案	月成本估算
简单问答/分类	Qwen-Turbo / DeepSeek	< 500元
内容生成/摘要	Qwen-Plus / GLM-4	< 2000元
复杂推理/代码	GPT-4o / DeepSeek-V3	< 5000元

四、忽略 RAG 精度问题

坑点描述

把文档"扔进"向量数据库就以为知识库建好了。实际使用中发现：检索结果不相关、关键信息被遗漏、回答出现幻觉。

根本原因

切片策略不合理，切断了语义完整性
Embedding 模型选择不当
只用了简单的 Top-K 检索，没有调优
没有对检索结果做质量评估

解决方案

RAG 不是"扔进去就行"，需要精细调优。

优化路径：

切片优化：使用 RecursiveCharacterTextSplitter，chunk_size=500，overlap=50
模型选择：中文场景使用 bge-large-zh-v1.5 或 M3E
检索策略：混合检索（向量 + BM25）+ Rerank
Query 优化：HyDE、Query 改写、多 Query 检索
效果评估：建立标注测试集，定期评估检索准确率

五、Agent 间无限循环

坑点描述

Reviewer 发现问题后反馈给 Writer，Writer 修改后 Reviewer 又发现问题，如此反复，最终陷入死循环。系统卡住，Token 消耗不断增加。

根本原因

没有设置最大迭代次数
没有定义"足够好"的终止条件
Reviewer 的反馈不够具体，Writer 无法有效改进
状态没有持久化，无法手动中断后恢复

解决方案

每个 Agent 都要有明确的终止条件和最大迭代次数限制。

python

termination_config = {
    "max_iterations": 5,
    "quality_threshold": 0.8,
    "timeout_seconds": 300,
    "max_no_improvement": 2
}

额外保障措施：

设置全局超时（如5分钟），超时自动终止
每次迭代记录状态到持久化存储
提供手动中断接口
Token 消耗达到阈值时强制终止

六、工具调用幻觉

坑点描述

Agent 在不该调用工具时调用了工具，或者调用了不存在的工具，或者传递了错误的参数。比如用户问"你好"，Agent 却尝试调用 search_web 工具。

根本原因

工具的 description 不够清晰，LLM 无法准确判断何时该用
工具数量过多，LLM 选择困难
缺少工具调用的校验和确认机制

解决方案

工具定义要清晰，加入工具调用的验证机制。

优化措施：

工具描述优化：明确适用场景和不适用场景，使用枚举约束减少参数错误
工具调用校验：检查工具是否存在、参数类型是否正确
工具精简：每个 Agent 最多配备 3-5 个工具，避免选择困难
调用频率限制：单次任务中同一工具最多调用 N 次

七、成本失控

坑点描述

上线初期没有做成本预估和监控，一个月后收到账单发现花费远超预期。某次调试时因为循环调用，单次请求消耗了几十元的 Token。

根本原因

没有做成本预估
没有单次请求的成本上限
没有实时成本监控
Agent 循环调用导致 Token 消耗指数级增长

解决方案

上生产前必须做成本评估，加入实时成本监控。

成本控制三层防线：

层级	措施	粒度
请求级	单次请求 Token 上限（如 8000）	每次调用
任务级	单次任务成本上限（如 5元）	每次任务
系统级	每日/每月预算上限	全局

实时监控指标：

每次 LLM 调用的 Token 消耗和成本
每个任务的累计成本
每日总成本和趋势
成本异常告警（单次请求超过阈值）

八、安全漏洞

坑点描述

系统上线后被用户发现可以通过特殊输入获取系统提示词，或者让 Agent 执行危险操作（如发送邮件、删除数据）。更有甚者，通过外部数据源（如网页内容）注入恶意指令。

根本原因

没有对用户输入做安全检测
Agent 权限过大，能执行危险操作
缺少输出审核，可能泄露敏感信息
外部数据源的内容没有经过安全过滤

解决方案

安全是生产系统的底线，加入多层防护机制。

安全防护体系：

用户输入 -> [输入检测] -> [输入清理] -> [Prompt加固] -> LLM调用 -> [输出审核] -> 用户输出
                                          |
                                    [权限控制]
                                    [成本控制]
                                    [人工审批]

关键措施：

输入检测：识别 Prompt 注入、角色扮演等攻击模式
权限最小化：每个 Agent 只能使用必要的工具
输出审核：检查是否泄露敏感信息、是否符合安全规范
外部数据过滤：对 RAG 检索到的内容做安全检查
操作审批：高风险操作需人工确认
审计日志：记录所有操作，支持事后追溯

多智能体常见坑点 ​

核心结论（4 条必记） ​

一、盲目追求"智能涌现" ​

坑点描述 ​

根本原因 ​

解决方案 ​

二、Demo 思维上生产 ​

坑点描述 ​

根本原因 ​

解决方案 ​

三、过度依赖 OpenAI ​

坑点描述 ​

根本原因 ​

解决方案 ​

四、忽略 RAG 精度问题 ​

坑点描述 ​

根本原因 ​

解决方案 ​

五、Agent 间无限循环 ​

坑点描述 ​

根本原因 ​

解决方案 ​

六、工具调用幻觉 ​

坑点描述 ​

根本原因 ​

解决方案 ​

七、成本失控 ​

坑点描述 ​

根本原因 ​

解决方案 ​

八、安全漏洞 ​

坑点描述 ​

根本原因 ​

解决方案 ​

多智能体常见坑点

核心结论（4 条必记）

一、盲目追求"智能涌现"

坑点描述

根本原因

解决方案

二、Demo 思维上生产

坑点描述

根本原因

解决方案

三、过度依赖 OpenAI

坑点描述

根本原因

解决方案

四、忽略 RAG 精度问题

坑点描述

根本原因

解决方案

五、Agent 间无限循环

坑点描述

根本原因

解决方案

六、工具调用幻觉

坑点描述

根本原因

解决方案

七、成本失控

坑点描述

根本原因

解决方案

八、安全漏洞

坑点描述

根本原因

解决方案