SKILL.md — AgentSpeak(L) & BDI Agent Architecture
當自主實體需要感知、深思與行動，同時管理相互競爭的目標並回應事件，而不中斷正在進行的工作。
Decision Points
Primary Architecture Selection
IF system needs only event-reaction with no persistent goals
→ Use reactive/rule system (BDI is overkill)
ELIF system needs planning in static environment with no interrupts
→ Use classical planner
ELIF system needs both reactivity AND goal persistence in dynamic environment
→ Use BDI architecture
Selection Function Invocation Table
| 情境 | 使用函數 | 決策準則 |
|---|---|---|
| 新事件抵達 | SE (Event Selection) | 優先級、緊急程度、資源限制 |
| 事件需要計劃 | SO (Option Selection) | 情境防護條件、計劃成功歷史、風險容忍度 |
| 多個活躍意圖 | SI (Intention Selection) | 截止期限、資源分配、公平性策略 |
| 計劃執行失敗 | SO 接續 SI | 尋找失敗處理計劃，然後重新排程意圖 |
Plan Failure Recovery Decision Tree
計畫 P 在執行動作 A 時失敗：
IF 此失敗類型存在失敗處理計畫
→ 發布失敗事件，讓 SO 選擇恢復計畫
→ 繼續使用修改後的意圖堆疊
ELIF 存在同一觸發事件的其他適用計畫
→ 回溯至事件，讓 SO 嘗試下一個可用的計畫
→ 將失敗計畫從考慮範圍中移除
ELIF 無其他替代方案可用
→ 向上傳播失敗至意圖堆疊
→ IF 存在父計畫 → 在父層級觸發失敗事件
→ ELSE 完全拋棄此意圖
Belief Update Impact Assessment
新信念 B 抵達：
IF B 與現有信念衝突
→ 執行信念修正協定
→ 檢查所有活動意圖的情境防護條件是否違反
→ IF 情境不再成立 → 暫停意圖（不要拋棄）
ELIF B 啟用新的適用計畫
→ 檢查事件佇列中是否有因 B 而出現適用計畫的休眠事件
→ 使用 SE 重新安排優先級
ELIF B 滿足待處理目標的條件
→ 標記達成，清理相關意圖
→ 發布達成事件以便計畫清理
Failure Modes
1. Plan Thrashing
症狀： 代理程式在不同計畫間快速循環而毫無進展；相同事件反覆觸發不同計畫。 檢測規則： 如果同一事件在 N 個執行週期內被處理超過 3 次，且每次選擇不同計畫，即為計畫震盪。 根本原因： SO（選項選擇）函數不確定或情境防護條件太弱/重疊。 修正方法： 讓 SO 明確按優先級排序；強化情境防護條件使其互斥；將計畫成功/失敗歷史加入選擇準則。
2. Stale Belief Paralysis
症狀： 代理程式根據過時的世界模型選擇計畫；計畫因對環境的錯誤假設而立即失敗。 檢測規則： 如果計畫失敗率 >50% 且失敗原因為執行時（非規劃時）的情境防護條件違反，即為過時信念麻痺。 根本原因： 信念更新頻率低於環境變化速率；信念修正未傳播至意圖情境檢查。 修正方法： 提高感知頻率；加入信念過時時間戳；當意圖的情境防護條件失效時暫停該意圖。
3. Infinite Intention Loops
症狀： 代理程式建立的意圖會發布事件，這些事件又為相同目標建立更多意圖；意圖堆疊無限增長。 檢測規則： 如果意圖堆疊深度隨時間單調增加，而無對應的目標達成，即為意圖循環。 根本原因： 計畫建立的子目標最終回到原始目標而無終止條件。 修正方法： 在情境防護條件中加入達成檢測；實作意圖合併（合併重複意圖）；加入最大遞迴深度限制。
4. Policy-in-Plans Anti-Pattern
症狀： 相同事件根據計畫本體內部的條件式觸發不同行為；代理策略分散且難以修改。
檢測規則： 如果計畫本體包含優先級/緊急度條件式（if high_priority then X else Y），則表示策略放錯了位置。
根本原因： 代理理性被編碼在計畫邏輯中，而非選取函數中。
修正方法： 將所有優先級/策略邏輯移到 SE/SO/SI 函數；使計畫策略中立且僅對情境敏感。
5. Single-Intention Bottleneck
症狀： 代理程式無法處理中斷；緊急事件等待代理完成長時間執行的任務；無並行性。 檢測規則： 如果代理在任何時刻最多只有一個活動意圖，即為單意圖瓶頸。 根本原因： SI（意圖排程）函數未實現真正的並行；將意圖視為互斥而非並行。 修正方法： 允許多個活動意圖；在 SI 中實作搶佔式排程；將計畫設計為可中斷序列。
Worked Examples
Example 1: Multi-Agent Task Allocation with Plan Conflicts
場景： 兩個代理（A1、A2）協作達成 deliver(package, destination)。兩者都有計畫但能力不同。
初始狀態：
- A1 信念：
location(A1, warehouse)、can_carry(A1, small_items)、location(package, warehouse) - A2 信念：
location(A2, depot)、can_carry(A2, any)、has_vehicle(A2) - 共享信念：
size(package, large)、destination(customer_site)
事件： +!deliver(package, customer_site) 發送給兩個代理
決策流程：
-
A1 計畫選擇 (SO)：
- 計畫 P1：
+!deliver(X,Y) : can_carry(A1,small_items) & size(X,small) <- pickup(X); transport(X,Y) - 情境防護條件失敗：
size(package,large)與size(X,small)矛盾 - 無適用計畫 → 發布
plan_failure(deliver, no_capability)
- 計畫 P1：
-
A2 計畫選擇 (SO)：
- 計畫 P2：
+!deliver(X,Y) : can_carry(A2,any) & has_vehicle(A2) <- pickup(X); drive(X,Y); dropoff(X) - 情境防護條件成功 → P2 被選中
- 建立意圖 I1：
[pickup(package), drive(package,customer_site), dropoff(package)]
- 計畫 P2：
-
A1 信念更新：
- 接收訊息：
attempting(A2, deliver, package) - 更新信念：
+delegated(deliver, package, A2) - 放棄失敗的意圖
- 接收訊息：
新手錯誤： 兩個代理都會嘗試送貨，造成資源衝突。 專家見解： 協調是透過信念共享和計畫情境防護條件來達成，而非硬編碼的代理知識。
Example 2: Interrupt Handling with Intention Reconsideration
場景： 代理正在執行長時間的資料處理任務，突然收到安全警報。
初始狀態：
- 活躍意圖 I1：
[process_batch(data1), process_batch(data2), generate_report()] - 目前執行：正在進行
process_batch(data1)（還需要 10 分鐘）
事件： +security_alert(intrusion_detected, server_3)
決策流程：
-
事件選擇 (SE)：
- SE 優先級：security_events > routine_processing
security_alert被選中，而非繼續 I1
-
計畫選擇 (SO)：
- 計畫 P3：
+security_alert(Type,Location) : has_admin_access <- isolate_system(Location); notify_team(Type) - 情境防護條件滿足 → P3 被選中
- 建立意圖 I2：
[isolate_system(server_3), notify_team(intrusion_detected)]
- 計畫 P3：
-
意圖排程 (SI)：
- 目前意圖：I1（在
process_batch(data1)處暫停）、I2（新的、緊急） - SI 策略：安全意圖優先於處理意圖
- 選擇 I2 執行
- 目前意圖：I1（在
-
執行：
- 立即執行
isolate_system(server_3) - 執行
notify_team(intrusion_detected) - I2 完成，從意圖集合中移除
- 立即執行
-
恢復：
- 僅剩 I1：
[process_batch(data1), process_batch(data2), generate_report()] - 從暫停點恢復執行
process_batch(data1)
- 僅剩 I1：
新手錯誤： 會忽略安全警報或完全放棄處理任務。 專家見解： 意圖暫停在保留進度的同時，實現了靈敏回應行為。SI 排程策略是明確且可配置的。
Quality Gates
- 代理架構具有明確的 SE、SO、SI 選取函數，並記錄其策略
- 每個計畫都具有定義明確的觸發事件和可根據當前信念評估的情境防護條件
- 計畫庫包含每個主要計畫類型的失敗處理計畫（不僅是成功路徑）
- 信念更新機制能夠處理矛盾資訊並將變更傳播至活動意圖
- 多個意圖可以同時活動，並有明確的排程/搶佔規則
- 事件佇列處理具有優先級（非 FIFO），並有明確的優先級指派
- 計畫失敗會觸發事件，而不是系統當機或靜默失敗
- 情境防護條件互斥，或者計畫選擇明確排序以避免不確定性
- 代理可以透過公開意圖堆疊和觸發事件來解釋其行為
- 系統在高事件負載下優雅降級（無無限循環或堆疊溢位）
NOT-FOR Boundaries
不適用於： 所有行為都是反應式的簡單規則系統（無持久目標） → 請改用： 基本規則引擎或事件-動作系統
不適用於： 執行期間環境不變的靜態規劃問題
→ 請改用： 經典規劃器（A*、STRIPS、HTN）
不適用於： 需要保證回應時間或硬性截止期限的即時系統 → 請改用： 具有時序分析的即時排程系統
不適用於： 所有協調可由中央控制器處理的系統 → 請改用： 工作流程編排或集中式任務佇列
不適用於： 無自主決策的純資料轉換管線 → 請改用： ETL 工具、串流處理框架
不適用於： 需要機器學習或統計推論作為主要能力的應用 → 請改用： ML 框架，必要時以 BDI 作為協調層