本文最新版已更新至：http://thinkinside.tk/2012/03/20/rule_engine_1.html
問題的提出
假設這樣一個場景：
某公司生產兩種型號的設備，M{m1,m2}，兩種型號都支持四種功能F{f1,f2,f3,f4}，但開放哪些功能取決於出廠設置。在出廠之前需要對設備進行多方面的測試，目前定義了五種測試T{t1,t2,t3,t4,t5}，要執行哪些測試取決於型號。對每台設備的每種測試都有一個最晚執行日期D的要求，D取決於設備要執行的測試項。
由於業務需要，每種型號的設備要進行哪些測試、D與要執行的測試項的關系會經常變化。比如其中的一組規則是：
測試項規則：
if m=m1, exec(t1,t2,t5)
if m=m2 and m.hasfunction(f1), exec(t2,t3)
if m=m2 and m.hasfunction(f2), exec(t4,t5)
if m=m2 and m.hasfunction(f3), exec(t3,t4)
if m=m2 and m.hasfunction(f4), exec(t1,t3)
測試時間規則（其中d表示天數，如3表示最晚執行日期為3天后）按照優先級從高到底如下：
if m.todo(t1), d=3
if m.todo(t2),d=7
if m.todo(t3),d=10
if m.todo(t4),d=12
if m.todo(t5),d=14
要實現的功能是，根據給定的規則和一組設備，得出每個設備的測試項和測試時間。
即使不考慮規則的變化，要實現這樣的業務規則也是非常繁瑣和乏味的。而為了避免頻繁的部署，規則必須能夠以某種形式進行定義和配置，不能硬編碼實現。（當然，如果你采用OSGI架構，定期更新規則的bundle我也無話可說）。
推理機和規則引擎
上面例子中的問題是典型的推理問題：根據已有的知識，分析實際情況並給出結論。如果由程序來處理推理過程，那么這個程序就叫做推理機/推理引擎（Inference Engine）。推理機是專家系統（專家系統是人工智能的一個分支）的核心模塊。
推理引擎根據知識表示的不同采取的控制策略也是不同的，常見的類型包括基於神經網絡、基於案例和基於規則的推理機。其中，基於規則的推理機易於理解、易於獲取、易於管理，被廣泛采用。這種推理引擎被稱為“規則引擎”。
在規則引擎中，將知識表達為規則（rules），要分析的情況定義為事實（facts）。二者在內存中的存儲分別稱為Production Memory和Working Memory，如下圖：
rules和facts是規則引擎接受的輸入參數，而規則引擎本身包括兩個組成部分：Pattern Matcher和Agenda。Pattern Matcher根據facts找到匹配的rules，Agenda管理PatternMatcher挑選出來的規則的執行次序。在外圍，還會有一個執行引擎（Execution Engine）負責根據Agenda輸出的rules執行具體的操作。
其中Pattern Matcher是規則引擎負責推理的核心。和人類的思維相對應，規則引擎中也存在兩種推理方式：正向推理（Forward-Chaining）和反向推理（Backward-Chaining）。
正向推理也叫演繹法，由事實驅動，從 一個初始的事實出發，不斷地應用規則得出結論。首先在候選隊列中選擇一條規則作為啟用規則進行推理，記錄其結論作為下一步推理時的證據。如此重復這個過程，直到再無可用規則可被選用或者求得了所要求的解為止。
反向推理也叫歸納法，由目標驅動，首先提出某個假設，然后尋找支持該假設的證據，若所需的證據都能找到，說明原假設是正確的；若無論如何都找不到所需要的證據，則說明原假設不成立，此時需要另做新的假設。
規則引擎是一種相對簡單的推理機，可以將規則引擎作為一種組件潛入到應用系統中，從而將業務決策從應用程序代碼中分離出來，並使用預定義的規則語言編寫業務決策。使用規則引擎帶來的好處是：
1. 避免業務規則變化帶來的重新編譯和重新部署的問題；
2. 使用聲明性編程方法，大大提高業務規則代碼的可讀性；
3. 開發人員不需要過多關注業務邏輯（根據各種情況判斷發生了什么事情），可以專注於應用邏輯（在發生了什么事情時進行什么樣的處理）