1. 问题背景
2026年5月下旬，三部门发布《智能体规范应用与创新发展实施意见》，明确智能体需具备“自主感知、记忆、决策、交互与执行能力”。政策推动企业加速Agent落地，但实践中暴露架构问题。
某制造企业上线20多个Agent后，早高峰GPU利用率从15%飙至98%，响应时间从3秒拖至47秒。一个RAG+多步调用的报表任务，单次消耗12万Token，且经常答非所问。
核心问题：用RAG架构去承载Agent任务，导致性能与成本双失控。
2. 本质差异：RAG vs Agent
RAG的前提是“答案已在知识库中”。企业实际任务常涉及实时查ERP、判断条件、调用飞书API等，RAG无法完成这些确定性操作。
3. 实测对比：同一任务，两种架构
任务描述：查项目X进度，若延期则拉去年同期数据对比，并@项目经理。
数据源：项目文档库（RAG用）+ Jira API + 飞书消息接口（Agent用）
方案A：RAG加强版
- 做法：将Jira查询结果预置为文档导入知识库，让模型生成时“顺便”判断延期并尝试输出@指令
- Token消耗：11.8万（5次平均）
- 成功率：延期判断正确率60%，@功能成功率0%
- 平均耗时：26秒
方案B：轻量Agent + RAG
- 做法：规划模块拆解为3步——查Jira状态 → 判断延期 → 若延期则拉去年同期数据 → 拼接消息触发飞书webhook。RAG仅用于第一步检索“延期判定规则”
- Token消耗：3.8万（5次平均）
- 成功率：100%
- 平均耗时：11秒
结论：Agent方案Token减少68%，任务全部完成；RAG方案Token更高，关键动作失败。
4. 深层原因：生成≠执行
RAG失败的根本原因：把“调用工具”当作生成的一部分，LLM在文本中“幻想”操作。
Agent成功的原因：LLM只负责决策“该不该调、调什么”，实际调用由代码执行。生成与执行之间隔着“确定性鸿沟”，LLM擅长模糊匹配，不擅长精确操作。
5. Token降价不会改变架构选择
DeepSeek近期将API价格降至原价1/4，高缓存场景再降90%。但更便宜的Token解决不了“不知道该调什么工具”的问题。
多Agent并发场景下，让每个Agent背负大段上下文运行，GPU集群难以承受。架构错误无法靠降价弥补。
6. 适用边界总结
场景 |
推荐架构 |
静态文档问答、法规检索、FAQ |
RAG |
多步推理、API调用、条件分支、消息发送 |
Agent（可搭配RAG做局部检索） |
混合场景 |
Agent为主，RAG作为工具之一 |
欢迎评论区讨论。
声明：图片由AI 辅助生成
