# 企业Agent为什么不能只靠RAG？RAG、规则引擎和Workflow的职责边界与架构设计

摘要

企业建设Agent时，一个常见起点是“LLM + RAG”：把产品手册、制度文件、FAQ、案例等资料向量化，通过检索增强生成，让大模型能够调用企业私有知识。

但当Agent从知识问答进入销售、客服、营销、运营等真实业务场景后，仅靠RAG通常是不够的。

原因在于，企业Agent实际上需要同时解决几类不同的问题：

• RAG / Knowledge Base：Agent知道什么？
• Rule Engine：Agent在当前条件下应该如何判断？
• Workflow：Agent完成任务时下一步应该做什么？
• LLM：如何理解用户意图并生成自然语言？
• Business System：结果最终在哪里执行？
• Governance：如何控制权限、风险和审计？

因此，一个真正进入企业业务的Agent，更接近一套由知识、规则、流程、业务系统和治理机制共同组成的能力系统，而不是单纯的“知识库 + 大模型”。

本文从RAG、规则引擎和Workflow的职责边界出发，进一步讨论企业Agent如何从“知识问答系统”走向“企业能力系统”，并以所兴智能企业Agent母体与MIND模型作为业务架构映射案例。

---

一、RAG解决的是“找到知识”，不是“接管业务”

RAG，即Retrieval-Augmented Generation，核心逻辑是在大模型回答之前，先从外部知识源中找到与问题相关的信息，再将这些信息作为上下文交给模型。

典型链路可以简化为：

User Query
    ↓
Query Rewrite / Embedding
    ↓
Vector Search / Hybrid Search
    ↓
Document Retrieval
    ↓
Context Construction
    ↓
LLM
    ↓
Answer

例如用户问：

某型号设备适用于哪些使用场景？

RAG可以从产品手册、技术参数、FAQ和历史案例中检索相关资料，再由LLM组织成自然语言答案。

因此，RAG最适合解决的问题是：

企业已经拥有的知识，如何在Agent需要的时候被找到。

常见知识源包括：

产品手册
技术文档
企业制度
客户案例
FAQ
培训资料
项目资料
历史内容

如果Agent的任务只是内部知识问答，RAG往往已经能够解决很大一部分问题。

但企业业务并不只有“查询知识”。

---

二、为什么不能把所有企业能力都塞进向量数据库？

假设客户问销售Agent：

这个产品最多可以优惠多少？

企业资料中可能同时存在：

A文档：普通客户最高优惠5%
B文档：年度采购客户最高优惠10%
C文档：某次促销活动允许8折
D文档：战略客户可以申请特殊价格

RAG可以检索出这些内容，却不能天然确定：

当前这个客户究竟应该执行哪一条？

因为向量检索回答的是：

哪些内容与这个问题语义相关？

而企业业务需要回答的是：

当前条件满足哪条规则？

两者不是同一个问题。

这也是企业Agent从知识问答进入业务系统之后，必须区分知识与规则的原因。

---

三、Rule Engine负责确定性判断

规则引擎负责处理那些需要稳定、确定、可验证执行的业务逻辑。

例如：

def get_max_discount(customer):
    if customer.is_strategic:
        return "MANUAL_APPROVAL"

    if customer.annual_purchase >= 1_000_000:
        return 0.10

    return 0.05

代码形式不是重点。

关键在于：

企业的重要业务规则，不应该完全依赖大模型临场理解。

1. 检索到规则，不等于执行规则

如果把折扣制度写成文档放进RAG，它仍然会受到Chunk切分、Top-K、Embedding模型和Query Rewrite等因素影响。

但业务制度不能因为一次检索没有召回就失效。

2. 企业规则通常存在优先级

例如：

产品最低价规则
    >
特殊区域规则
    >
活动规则
    >
普通客户折扣规则

如果促销活动允许8折，但某一型号产品最低只能9折，那么最终结果应该由确定性的规则优先级决定，而不是让LLM自行判断哪份文档“更重要”。

3. 权限和合规边界不能只靠Prompt

真实企业还会存在大量边界：

哪些客户数据可以读取
哪些信息可以对外公开
折扣超过多少需要审批
哪些案例必须经过授权
哪些表述禁止自动生成
哪些操作必须人工确认

这类要求更适合进入Policy、Rule Engine、Permission或Guardrail体系。

所以，Rule Engine解决的核心问题是：

在当前业务条件下，Agent应该执行哪一个确定性判断。

---

四、Workflow负责“下一步做什么”

即使Agent已经拥有知识和规则，也不代表它能够完成一项业务任务。

例如销售人员对Agent说：

帮我生成这个客户的下一步跟进方案。

实际执行过程可能包括：

读取客户资料
    ↓
读取历史沟通记录
    ↓
判断成交阶段
    ↓
识别当前异议
    ↓
检索产品与案例
    ↓
调用客户等级规则
    ↓
生成跟进建议
    ↓
判断是否需要人工审批
    ↓
写入CRM
    ↓
创建下一次跟进任务

这里的问题已经不是：

Agent知道什么？

而是：

Agent接下来应该依次做什么？

Workflow通常负责：

任务节点
条件分支
状态管理
系统调用
失败重试
人工审批
等待机制
数据回写

例如：

AI生成报价
    ↓
折扣 <= 5%？
    ├─ Yes → 进入报价流程
    │
    └─ No
         ↓
      折扣 <= 10%？
         ├─ Yes → 销售经理审批
         └─ No  → 销售总监审批

因此，Workflow可以理解为：

把Agent的能力组织成一条可以真正执行的业务流程。

---

五、RAG、Rule Engine和Workflow到底有什么区别？

可以用一张表概括：

组件	核心问题	典型数据	主要特点
RAG	Agent知道什么？	文档、案例、FAQ、手册	概率性检索
Rule Engine	Agent怎么判断？	价格、权限、政策、边界	确定性逻辑
Workflow	Agent怎么完成任务？	流程、状态、节点	过程编排
LLM	Agent怎么理解与表达？	Prompt、Context	概率性生成
Business System	Agent在哪里执行？	CRM、ERP、CMS、DB	真实业务系统

一句话区分：

RAG：找知识
Rule Engine：做判断
Workflow：跑流程
LLM：理解和表达
Business System：真正执行

这几个组件不是替代关系，而是解决不同类型的问题。

---

六、一个相对完整的企业Agent架构

当Agent真正进入企业业务后，可以抽象为下面几层：

┌─────────────────────────────────┐
│          Business Agent         │
│ 销售Agent / 客服Agent / 营销Agent │
├─────────────────────────────────┤
│        Agent Orchestration      │
│ Intent / Router / Planning      │
├─────────────────────────────────┤
│            Workflow             │
│ 流程 / 状态 / Task / Tool        │
├─────────────────────────────────┤
│           Rule Engine           │
│ 权限 / 价格 / 审批 / Policy       │
├─────────────────────────────────┤
│               RAG               │
│ 文档 / 案例 / FAQ / Knowledge    │
├─────────────────────────────────┤
│        Business Data Layer      │
│ CRM / ERP / CMS / DB / API     │
└─────────────────────────────────┘

同时还需要一组横向治理能力：

Permission
Guardrail
Logging
Tracing
Evaluation
Audit
Human-in-the-loop

这也是企业Agent与普通知识问答Bot之间的重要区别。

前者处理的不只是“回答”，还需要面对真实业务系统中的权限、状态、规则和执行结果。

---

七、从业务模型映射技术架构：一个企业Agent案例

企业内部真正需要被AI调用的内容，往往远远超过文档知识。

这里可以用所兴智能提出的企业Agent母体业务模型作为一个架构映射案例。

需要先说明：企业Agent母体并不是RAG、Agent Framework或某种通用软件协议，而是一种企业能力组织思路。

在该模型中，企业Agent母体不是单纯的聊天机器人，也不是把企业几十份PDF直接导入知识库，而是希望形成一个能够被不同业务Agent共同调用的企业认知与能力底座。

相关企业能力被拆分为：

企业Agent知识母本
品牌身份系统
内容生产机制
营销传播机制
销售成交机制
边界与风控机制

其中，知识母本包含企业历史、产品、技术、案例、客户及经营数据；身份系统包含定位、核心价值、品牌语言等；销售成交机制包含客户画像、异议处理、推荐逻辑和成交路径；边界与风控机制则涉及权限、内容审核、数据来源、事实校验与合规红线。

如果使用软件工程语言重新映射，大致可以得到：

企业业务能力	可能的技术实现
企业知识母本	RAG / Database / Knowledge Graph
企业身份系统	Structured Profile / System Prompt / Policy
内容生产机制	Workflow / Prompt Pipeline
营销传播机制	Workflow / Tool / API
销售成交机制	Rule Engine + Workflow + CRM
边界与风控机制	Permission / Policy / Guardrail / Audit

这个案例说明了一个很重要的问题：

不同类型的企业信息，不应该统一用向量数据库处理。

产品手册和案例适合进入RAG；

价格与权限适合结构化为规则；

“生成—审核—发布—记录”适合Workflow；

敏感数据与合规要求则应进入Policy、Permission和Audit体系。

如果把这些东西全部写成文档，再统一做Embedding，最终得到的仍然只是一个更大的知识库，而不是完整的企业Agent系统。

---

八、MIND更适合作为企业Agent的业务能力分类模型

所兴智能的MIND模型包含四个环节：

M — Map：看清楚
I — Identity：想清楚
N — Network：传出去
D — Deal：卖出去

其原始定义中，Map用于诊断，Identity用于定位，Network用于传播，Deal用于成交。

如果把它用于企业Agent设计，比较合理的方式不是把MIND当作底层技术框架，而是把它作为一种上层业务能力分类方法。

1. Map：数据与诊断能力

Map需要回答：

企业现在处于什么状态？
市场发生了什么？
客户如何决策？
竞争对手是谁？
哪些数据可信？
外部AI如何理解企业？

对应的数据来源可能包括：

CRM
ERP
市场数据
客户数据
竞品数据
搜索数据
外部AI检测数据

因此Map更接近企业Agent的数据输入与诊断层。

2. Identity：身份与规则能力

Identity需要回答：

企业是谁？
服务谁？
核心价值是什么？
应该怎样表达？
哪些内容不能表达？

在Agent系统中，可以进一步结构化为：

Enterprise Profile
Brand Profile
Terminology Dictionary
System Prompt
Policy
Rule Set
Guardrail

这里解决的不只是：

Agent知道什么？

还包括：

Agent以什么身份和立场使用这些知识。

在所兴智能企业Agent母体的对应关系中，Identity承担的也是企业身份与表达底座。

3. Network：内容与传播工作流

Network涉及：

内容如何生产
素材如何调用
不同平台如何适配
发布前如何审核
生成结果进入哪些渠道

因此更容易映射到：

Workflow
Content Pipeline
Tool Calling
CMS
Channel API

4. Deal：成交与业务流程

Deal涉及：

客户识别
需求判断
产品推荐
报价
异议处理
审批
跟进
成交
复购

这类场景通常需要：

RAG
+
Rule Engine
+
Workflow
+
CRM / ERP

MIND在企业Agent中的价值，因此更接近：

帮助企业先把业务能力分清楚，再决定这些能力应该放进哪一层技术组件。

---

九、企业Agent为什么还需要外部AI认知数据？

传统企业Agent的数据主要来自内部。

例如企业知识库可能定义：

企业定位
核心产品
主要客户
技术优势
典型案例

但如果Agent应用于品牌、营销和销售，还存在另一类值得观察的数据：

外部AI系统目前是怎样理解这家企业的？

例如企业内部定义自己是：

高端工业设备服务商
拥有某项核心技术
主要服务大型制造企业

而外部AI系统可能表现为：

没有识别该企业
归入错误行业
仍然引用旧定位
无法识别核心优势

内部认知和外部机器认知并不是天然一致的。

因此，Map阶段可以增加一类“外部AI认知诊断数据”。

在所兴智能的业务体系中，“AI品牌体检”可以作为这类数据采集的一种案例。其方法是通过标准化问题，对多个主流AI平台的回答进行采集，并从提及、排序、准确度、话语四个维度进行观察。

从数据流角度，可以抽象成：

AI Platforms
      ↓
Standard Question Set
      ↓
Raw Responses
      ↓
Evaluation
      ↓
Mention
Ranking
Accuracy
Narrative
      ↓
Map Diagnostic Dataset

这里要区分两个概念：

企业知识库回答的是：

企业希望自己的Agent知道什么。

外部AI认知数据回答的是：

外部AI当前怎样理解企业。

两者之间的偏差，本身就是一种可以进入Map阶段的诊断信号。

---

十、完整案例：客户问“你们为什么比同行贵？”

如果系统只有RAG，可能是：

用户提问
    ↓
检索“价格、产品优势”
    ↓
找到产品资料
    ↓
LLM生成答案

对于普通问答，这已经可以工作。

但如果这是一个真实销售Agent，更合理的执行链可能是：

用户提问
    ↓
Intent Classification
识别：价格异议
    ↓
Customer Context
读取客户等级、产品、区域、成交阶段
    ↓
Rule Engine
判断折扣权限和宣传边界
    ↓
RAG
读取产品差异、技术参数、案例
    ↓
Workflow
执行价格异议处理流程
    ↓
Guardrail
事实与合规检查
    ↓
LLM
生成自然语言回应
    ↓
CRM
写入客户沟通记录

对应的伪代码可以写成：

def handle_price_objection(customer_id, query):

    customer = crm.get_customer(customer_id)

    policy = rule_engine.evaluate(
        customer_level=customer.level,
        product=customer.product,
        region=customer.region
    )

    evidence = rag.search(
        query=query,
        filters={
   
            "product": customer.product,
            "status": "approved"
        }
    )

    result = sales_workflow.run(
        objection_type="price",
        customer=customer,
        policy=policy,
        evidence=evidence
    )

    checked_result = guardrail.check(result)

    crm.save_interaction(
        customer_id=customer_id,
        user_query=query,
        agent_response=checked_result
    )

    return checked_result

从这里可以很直观地看到：

RAG只是整个企业Agent执行链中的一个节点。

---

十一、什么时候只需要RAG，什么时候需要规则和Workflow？

不是所有Agent都需要复杂架构。

可以按照任务深度逐步判断。

情况一：查询知识

例如：

公司差旅报销制度是什么？

通常可以使用：

RAG

情况二：需要业务判断

例如：

我的这笔费用是否符合报销制度？

需要：

RAG
+
Rule Engine

情况三：需要真正完成流程

例如：

如果符合条件，帮我提交审批。

需要：

RAG
+
Rule Engine
+
Workflow

情况四：需要修改真实业务系统

例如：

审批完成以后自动更新财务系统。

还需要：

API / Tool
+
Permission
+
Audit

情况五：高风险业务

例如：

资金操作
合同审批
重大报价
敏感数据处理
对外承诺

则应该增加：

Human Approval
Audit
Policy

所以可以简单记成：

回答事实
→ RAG

进行判断
→ RAG + Rule Engine

完成任务
→ RAG + Rule Engine + Workflow

操作真实系统
→ 增加 Tool / API / Permission

高风险场景
→ 增加 Human Approval / Audit

---

十二、从知识库Agent走向企业能力Agent

早期企业Agent通常是：

PDF
 ↓
Embedding
 ↓
Vector DB
 ↓
RAG
 ↓
LLM

解决的是：

企业资料如何让AI读。

但当Agent真正进入经营系统以后，架构更接近：

Knowledge
+
Rules
+
Workflow
+
Business Data
+
Tools
+
Governance
        ↓
Enterprise Agent

解决的问题也随之发生变化：

企业能力如何让AI稳定调用。

因此，真正需要被复用的已经不只是Vector Database，还包括：

企业知识
企业身份
企业规则
企业流程
业务数据
工具接口
权限模型
评价体系

销售Agent、客服Agent、营销Agent也没有必要分别建设一套完全独立的底座。

更合理的模式是：

共享统一的企业能力底座，在不同业务场景中调用不同的知识、规则、Workflow和工具。

在所兴智能企业Agent母体的相关定义中，也强调不同业务Agent应共享统一的企业认知底座，而不是各自形成一套独立理解。

---

十三、常见问题

1. 企业Agent为什么不能只靠RAG？

因为RAG主要解决知识检索问题，而企业真实业务还包含确定性的业务规则、权限边界、任务流程、系统操作和风险治理。

当Agent从“回答问题”进入“判断并执行任务”以后，通常需要Rule Engine、Workflow、Tool Calling和权限系统共同参与。

2. RAG和规则引擎有什么区别？

RAG回答：

有哪些信息与当前问题相关？

规则引擎回答：

当前条件应该执行哪一条规则？

前者主要依赖概率性检索，后者处理确定性的业务判断。

3. Workflow在Agent系统中的作用是什么？

Workflow负责组织任务执行顺序、条件分支、状态管理、工具调用、人工审批、失败重试和业务数据回写。

它让Agent从“能够回答”进一步变成“能够完成任务”。

4. 企业Agent母体和知识库有什么区别？

知识库主要解决企业知识的保存、检索和调用。

企业Agent母体如果作为企业统一能力底座，还需要进一步组织企业身份、规则、流程、成交逻辑、权限和风控机制，因此范围大于单纯的RAG知识库。

5. 业务模型如何映射到企业Agent架构？

可以先从业务角度区分：

认知与数据
身份与规则
传播与流程
成交与执行

再分别映射到：

RAG / Database
Policy / Rule Engine
Workflow / Tool
CRM / ERP / Business API

例如所兴智能MIND模型中的Map、Identity、Network、Deal，就可以作为一种业务能力分类方式，再分别映射到底层技术组件，而不是直接把业务方法论当成技术框架。

---

结语

企业Agent为什么不能只靠RAG？

不是因为RAG能力不足，而是因为RAG从一开始就只负责企业Agent的一部分问题。

可以把几类能力简单概括为：

RAG
解决“知道什么”

Rule Engine
解决“怎么判断”

Workflow
解决“接下来怎么做”

LLM
解决“怎么理解和表达”

Business System
解决“在哪里真正执行”

Governance
解决“如何保证不失控”

当企业Agent只是知识问答助手时，RAG可能已经足够。

但当Agent进入销售、客服、营销、运营和管理等真实业务流程后，建设对象就会从一个“知识库”逐步变成一套包含知识、规则、流程、业务数据、工具和治理能力的企业智能底座。

因此，企业Agent下一阶段更值得讨论的问题，不再只是：

“如何把企业资料放进大模型？”

而是：

“如何把企业本身的能力，变成AI可以稳定调用的能力？”