今天讨论 AI 方案时，经常会听到几个词：

Rule、RAG、Knowledge Graph、LLM、Agent。

于是一个非常自然的问题出现了：

一个业务问题，到底什么时候应该用规则，什么时候应该用知识图谱，什么时候应该交给 LLM，什么时候又需要 Agent？

这个问题看起来像是在做“技术选型”。

但如果再深入一层，它其实是在讨论一个更重要的问题：

一个智能系统，应该把不同类型的判断交给什么样的推理机制？

这可以称为：

AI Reasoning Architecture

也可以称为：

AI Decision Architecture

它可能是今天企业落地 AI 时，比“选择哪个模型”更重要的问题。

一、AI 架构设计的第一原则：不要从 LLM 开始

很多 AI 项目的起点是：

这个场景能不能接一个大模型？

但从架构设计角度，更合理的问题应该是：

这个问题本质上是什么问题？

因为不同问题，需要的并不是同一种智能。

例如下面四个问题：

问题 A

用户年龄小于 18 岁，是否允许注册某项服务？

这是一个确定性问题。

问题 B

某家公司和另外三家公司之间存在什么股权关系？

这是一个关系问题。

问题 C

帮我总结这份 50 页报告最重要的三个观点。

这是一个语言理解问题。

问题 D

帮我规划一次旅行，考虑天气、预算、交通、酒店和景点，并根据实际情况调整安排。

这是一个多步骤任务。

虽然它们都可以包装成“AI 问题”，但本质完全不同。

因此，AI 架构设计的第一步不是选模型。

而是：

Problem Decomposition——问题分解。

二、Rule：解决确定性问题

Rule，也就是规则系统，解决的是：

如果条件已经明确，系统应该如何确定性执行？

最典型的形式就是：

IF condition AAND condition BTHEN action C

例如：

如果订单金额 > 5000并且账号最近 24 小时发生过密码修改→ 要求额外身份验证

Rule 最大的优势不是“智能”。

而是：

• 可预测

• 可测试

• 可解释

• 可审计

• 可重复

相同输入，应该得到相同结果。

这对于很多企业系统非常重要。

常见场景

例如：

• 权限判断

• 合规规则

• 风险阈值

• 税率计算

• 状态机

• 工作流

• 数据校验

• SLA 判断

• 优惠资格

这些问题通常不需要“思考”。

系统只需要：

按规则执行。

三、一个重要原则：不要把 Rule 交给 LLM

假设政策规定：

金额 > 100000→ 必须人工审核

最可靠的实现方式就是：

if amount > 100000:    manual_review()

而不是：

“请让 LLM 判断这笔交易是否需要人工审核。”

为什么？

因为 LLM 本质上是概率模型。

而 Rule Engine 是确定性系统。

如果一个规则要求：

100% 一致执行

那么就不应该交给概率模型。

因此，一个非常重要的架构原则是：

Deterministic problems should remain deterministic.

确定性问题，应该继续由确定性系统解决。

四、Knowledge Graph：解决关系问题

另外一种问题不是：

条件是什么？

而是：

谁和谁存在什么关系？

例如：

Company A↓ suppliesCompany BCompany B↓ ownsCompany CCompany C↓ locatedInCountry DCountry D↓ regulatedByRegulation E

如果现在问：

Regulation E 可能影响哪些供应商？

核心任务并不是生成文本。

而是沿着关系进行查询。

这就是知识图谱非常擅长的问题。

五、知识图谱真正解决的是什么？

知识图谱最核心的价值不是：

把数据画成一张图。

而是：

显式表达语义关系。

例如在传统数据库里，我们可能有：

Customer TableOrder TableProduct TableSupplier Table

数据库擅长保存事实：

OrderId = 1001ProductId = P001

但是知识图谱更关注：

Customer↓ purchasedProductProduct↓ suppliedBySupplierSupplier↓ locatedInCountry

它把：

数据

转化成：

关系网络。

六、知识图谱特别适合什么问题？

当问题包含这些关键词时，可以考虑 KG：

• 属于

• 影响

• 依赖

• 来源

• 关联

• 上游

• 下游

• 引用

• 组成

• 负责

• 适用于

例如：

哪些零部件被哪些产品使用？

某项法规会影响哪些业务流程？

某篇论文引用了哪些理论？

某项指标依赖哪些数据字段？

某个故障可能关联哪些组件？

这些问题本质上都是：

Relationship Reasoning

关系推理。

七、LLM：解决模糊问题

Rule 和 KG 有一个共同特点：

它们通常需要较明确的输入。

但现实世界的问题往往不是这么表达的。

用户不会说：

Intent = TrackOrderOrderType = Headphone

用户更可能说：

我前几天买的耳机怎么还没到？

LLM 的价值就在这里。

它能够把：

人类语言

转换成：

机器可以处理的任务。

例如：

用户输入↓LLM↓Intent = TrackOrderEntity = Headphone Order

八、LLM 更像什么？

从系统架构角度，我更愿意把 LLM 看成三种角色。

1. Language Interface

语言接口。

负责把自然语言转换成结构化任务。

2. Reasoning Layer

推理层。

负责处理：

• 模糊问题

• 多条件问题

• 文本推理

• 信息归纳

• 多步骤分析

3. Generation Layer

生成层。

负责把复杂结果转换成人可以理解的答案。

因此：

LLM 很重要，但 LLM 不等于整个 AI 系统。

九、Database：负责事实

在讨论 AI 架构时，还有一个经常被忽略的角色：

Database。

数据库解决的是：

What is true?

也就是：

事实是什么？

例如：

今天有多少订单？库存是多少？客户余额是多少？订单状态是什么？

这些问题真正的权威来源应该是：

数据库。

而不是 LLM。

这是企业 AI 非常重要的一条原则：

LLM should not become the system of record.

LLM 不应该成为事实记录系统。

真正的事实应该来自：

• Database

• ERP

• CRM

• Data Warehouse

• Data Lake

• API

LLM 只是：

理解和解释事实。

十、Search 和 RAG：解决知识检索问题

还有一类问题是：

我知道答案存在某个文档里，但我不知道在哪里。

例如：

公司差旅政策规定酒店最高可以报销多少钱？

这种问题既不是纯 Rule，也不是纯 LLM。

更像是：

Information Retrieval

信息检索。

这时可以使用：

User↓LLM↓Search / Vector Search↓Relevant Documents↓LLM↓Answer

这就是 RAG 的基本结构。

十一、RAG 和知识图谱有什么区别？

这个问题很重要。

RAG 通常解决的是：

哪段文本与问题最相关？

Knowledge Graph 解决的是：

哪些实体之间存在什么关系？

例如用户问：

哪些疾病与药物 A 有关联？

RAG 可能搜索：

有关药物 A 的医学文档。

知识图谱则可能直接查询：

Drug A↓ treatsDisease BDrug A↓ contraindicatedForDisease C

所以：

RAG

更偏：

Text Retrieval

Knowledge Graph

更偏：

Semantic Relationship

两者并不冲突。

事实上它们经常同时存在。

十二、Agent 并不是第四种“知识技术”

接下来是一个非常重要的概念。

Rule、KG、RAG、Database、LLM 和 Agent，并不是完全平级的东西。

Agent 更像：

Orchestration Layer

编排层。

它负责：

现在应该做什么？↓应该调用哪个工具？↓结果回来以后怎么办？↓是否还需要下一步？↓任务是否完成？

所以 Agent 本质上解决的是：

任务执行问题。

十三、一个 Agent 实际上可能长这样

                  ┌── Rule Engine                  │                  ├── Database                  │User → LLM → Agent Router                  │                  ├── RAG                  │                  ├── Knowledge Graph                  │                  ├── Search                  │                  └── External API                          ↓                      LLM Response

这里：

LLM 负责理解。

Agent 负责协调。

Rule 负责确定性判断。

Database 负责事实。

KG 负责关系。

RAG 负责文档知识。

API 负责执行动作。

十四、案例一：银行智能客服

用户问：

我昨天转的一笔钱为什么还没有到账？

系统可能执行：

User↓LLM识别 Intent = Transfer Status↓Bank API查询交易状态↓Rule Engine判断是否超过 SLA↓Knowledge Base查询异常原因↓LLM生成解释

如果交易已经超过 SLA：

Rule:Delay > 24h→ Create Investigation Ticket

这里没有必要让 LLM 决定：

“24 小时算不算超时。”

Rule 已经知道答案。

十五、案例二：医疗知识助手

用户问：

Drug A 和 Drug B 可以一起服用吗？

系统可能执行：

User↓LLMEntity Extraction↓Drug ADrug B↓Knowledge GraphDrug Interaction Query↓Medical Knowledge BaseEvidence Retrieval↓RuleHigh Risk Interaction Check↓LLMGenerate Explanation

在这个系统中：

KG 找关系。

RAG 找证据。

Rule 判断风险等级。

LLM 解释结果。

十六、案例三：旅行 Agent

用户说：

我准备去日本玩五天，不喜欢特别拥挤的地方，希望多看看自然风景，预算不要太高。

这类问题非常适合 Agent。

因为它需要：

LLM↓理解用户偏好↓Search查询目的地↓Weather API查询天气↓Hotel API查询住宿↓Transport API计算交通↓Rule预算过滤↓Recommendation↓LLM生成行程

如果第二天发现天气变化：

Agent 还可能重新规划。

这已经不再是简单的“问答”。

而是：

Goal-Oriented Execution

目标驱动执行。

十七、案例四：合同审查系统

用户上传一份合同：

帮我看看有没有需要特别注意的地方。

系统可以拆成：

Document↓LLMClause Extraction↓RAGRelevant Regulation Retrieval↓Knowledge GraphClause–Regulation Relationship↓Rule EngineMandatory Clause Check↓LLMRisk Explanation

例如：

Rule 可以判断：

Missing Termination Clause→ Warning

KG 可以表示：

Clause↓ governedByRegulation

LLM 则负责：

为什么这个问题值得关注。

十八、真正成熟的 AI 系统通常是 Hybrid AI

因此现实中往往不存在：

Rule 还是 LLM？

这种简单二选一。

更常见的是：

Rule+Database+RAG+Knowledge Graph+LLM+Agent

组合成：

Hybrid AI Architecture

混合智能架构。

十九、如何快速判断应该用什么？

可以用一个简单的判断框架。

1. 答案是否必须完全确定？

如果是：

Rule

2. 核心问题是不是“关系”？

如果是：

Knowledge Graph

3. 答案是否存在某些文档里？

如果是：

Search / RAG

4. 是否需要实时事实？

如果是：

Database / API

5. 是否需要理解自然语言或模糊意图？

如果是：

LLM

6. 是否需要完成一个多步骤目标？

如果是：

Agent

如果同时满足多个条件：

那么通常应该考虑：

Hybrid Architecture

二十、还有一个重要维度：错误成本

技术选型不能只看：

能不能做。

还应该问：

如果它做错了，代价是多少？

例如：

推荐电影

回答不完美，风险很低。

LLM 可以承担更多自由度。

财务计算

错误成本较高。

应该使用确定性计算。

医疗建议

风险非常高。

需要：

• 权威知识

• 规则

• 证据

• 人工审核

• LLM 辅助解释

因此：

AI Architecture 其实也是 Risk Architecture。

系统架构必须考虑错误成本。

二十一、还有一个维度：变化速度

另一个容易被忽略的问题是：

知识变化得有多快？

例如：

税率。

可能每年变化。

可以配置 Rule。

公司政策。

可能每几个月变化。

适合：

Document + RAG。

产品库存。

每秒都可能变化。

必须查询：

Database / API。

通用语言知识。

变化相对慢。

LLM 可以直接处理。

因此一个很重要的问题是：

这个知识应该存在模型里，还是存在系统外部？

很多情况下答案是：

应该存在系统外部。

因为系统外部知识更容易：

• 更新

• 审计

• 控制

• 回滚

• 管理版本

二十二、企业 AI 架构最重要的原则之一

可以用一句话概括：

Do not put everything into the model.

不要试图把所有东西都塞进模型。

真正成熟的 AI 系统应该让不同组件承担自己擅长的责任。

二十三、一个完整的责任分工

可以总结为：

Rule for Control

规则负责控制。

Database for Facts

数据库负责事实。

Knowledge Graph for Relationships

知识图谱负责关系。

RAG for Knowledge Retrieval

RAG 负责知识检索。

LLM for Understanding and Reasoning

LLM 负责理解和推理。

Agent for Orchestration and Action

Agent 负责编排和行动。

二十四、未来 AI 系统真正竞争的可能不是模型

过去大家很关注：

GPT、Claude、Gemini……

哪个模型更强？

但随着模型能力逐渐接近，真正影响企业 AI 系统质量的，可能变成：

Architecture。

也就是：

如何把不同类型的智能组合起来。

一个好的系统不一定使用最大的模型。

但它往往有：

• 清晰的事实来源

• 清晰的规则边界

• 清晰的知识结构

• 清晰的工具接口

• 清晰的 Agent 流程

• 清晰的验证机制

二十五、从 Model-Centric 到 System-Centric

今天很多 AI 项目仍然是：

Model-Centric

模型中心。

思路是：

User↓LLM↓Answer

但未来真正成熟的 AI 系统可能越来越像：

                 Data                  │            Knowledge                  │User → LLM → Reasoning Layer                  │             Tool Layer                  │            Rule / API                  │               Action

也就是说：

AI 工程正在从：

Model Engineering

逐渐走向：

AI System Engineering

最后

真正重要的问题已经不再是：

Should we use an LLM?

而应该是：

Which reasoning mechanism should solve each part of the problem?

这个问题背后，是一个更大的变化：

过去软件系统主要解决：

Logic。

后来数据系统解决：

Facts。

知识图谱解决：

Relationships。

LLM 开始解决：

Language and Reasoning。

Agent 则开始解决：

Goal and Action。

未来真正强大的 AI 系统，并不是让一个大模型承担所有事情。

而是让：

正确的机制，在正确的位置，解决正确的问题。

这可能才是 AI Engineering 真正开始成熟的标志。