SKILL.md — AgentSpeak(L) & BDI 智能体架构
当自主实体必须感知、推理并行动，同时管理相互竞争的目标并对事件做出响应，且不放弃正在进行的工作时。
决策点
主要架构选择
如果系统只需要事件反应且没有持久目标
→ 使用反应式/规则系统（BDI 过于复杂）
否则如果系统需要在静态环境中进行规划且无中断
→ 使用经典规划器
否则如果系统在动态环境中需要同时具备反应性和目标持久性
→ 使用 BDI 架构
选择函数调用表
| 情况 | 使用的函数 | 决策标准 |
|---|---|---|
| 新事件到达 | SE（事件选择） | 优先级、紧急程度、资源约束 |
| 事件需要计划 | SO（选项选择） | 上下文守卫、计划成功历史、风险容忍度 |
| 多个活跃意图 | SI（意图选择） | 截止时间、资源分配、公平策略 |
| 计划失败时 | SO 然后 SI | 寻找失败处理计划，然后重新调度意图 |
计划失败恢复决策树
计划 P 在执行动作 A 时失败：
如果存在针对此失败类型的失败处理计划
→ 发布失败事件，让 SO 选择恢复计划
→ 继续使用修改后的意图堆栈
否则如果存在针对同一触发事件的替代计划
→ 回溯到事件，让 SO 尝试下一个适用计划
→ 从考虑中移除失败的计划
否则如果没有可用替代方案
→ 将失败向上传播到意图堆栈
→ 如果存在父计划 → 在父级别触发失败事件
→ 否则完全放弃意图
信念更新影响评估
新信念 B 到达：
如果 B 与现有信念矛盾
→ 运行信念修订协议
→ 检查所有活跃意图的上下文守卫是否违反
→ 如果上下文不再成立 → 暂停意图（不要删除）
否则如果 B 启用了新的适用计划
→ 检查事件队列中是否有现在具有适用计划的休眠事件
→ 使用 SE 重新排序优先级
否则如果 B 满足了待处理的目标条件
→ 标记完成，清理相关意图
→ 发布完成事件以进行计划清理
故障模式
1. 计划抖动
症状： 智能体在计划之间快速循环而没有任何进展；同一事件重复触发不同的计划。 检测规则： 如果同一事件在 N 个执行周期内被处理超过 3 次，且每次选择不同的计划，则存在计划抖动。 根本原因： SO（选项选择）函数是非确定性的，或者上下文守卫太弱/存在重叠。 修复： 使 SO 显式地按优先级排序；加强上下文守卫使其互斥；将计划成功/失败历史添加到选择标准中。
2. 过时信念瘫痪
症状： 智能体基于过时的世界模型选择计划；由于对环境做出错误假设，计划立即失败。 检测规则： 如果计划失败率超过 50%，且失败是由于执行时的上下文守卫违反（而非规划时）造成的，则存在过时信念。 根本原因： 信念更新频率相对于环境变化率太低；信念修订没有传播到意图上下文检查。 修复： 增加感知频率；添加信念过时时间戳；当意图的上下文守卫变得无效时暂停它们。
3. 无限意图循环
症状： 智能体创建意图，这些意图发布事件，而事件又为同一目标创建更多意图；意图堆栈无限增长。 检测规则： 如果意图堆栈深度随时间单调增加，而没有相应的目标达成，则存在意图循环。 根本原因： 计划创建的子目标最终导致回到原始目标，而没有终止条件。 修复： 在上下文守卫中添加目标达成检测；实现意图合并（合并重复意图）；添加最大递归深度限制。
4. 计划中的策略反模式
症状： 相同的事件根据计划体内的条件语句触发不同的行为；智能体策略分散且难以更改。
检测规则： 如果计划体包含优先级/紧急程度条件语句（if high_priority then X else Y），则策略放错了位置。
根本原因： 智能体的理性被编码在计划逻辑中，而不是选择函数中。
修复： 将所有优先级/策略逻辑移至 SE/SO/SI 函数；使计划策略中立且仅对上下文敏感。
5. 单意图瓶颈
症状： 智能体无法处理中断；紧急事件在智能体完成长时间运行的任务时等待；没有并发性。 检测规则： 如果智能体在任何时候最多只有一个活跃意图，则存在单意图瓶颈。 根本原因： SI（意图调度）函数没有实现真正的并发；将意图视为互斥而非并发。 修复： 允许多个活跃意图；在 SI 中实现抢占式调度；将计划设计为可中断的序列。
工作示例
示例 1：具有计划冲突的多智能体任务分配
场景： 两个智能体（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) - 放弃失败的意图
- 收到消息：
新手错误： 两个智能体都会尝试交付，造成资源冲突。 专家见解： 协调通过信念共享和计划上下文守卫实现，而非硬编码的智能体知识。
示例 2：具有意图重新考虑的中断处理
场景： 智能体正在执行长时间运行的数据处理任务，收到紧急安全警报。
初始状态：
- 活跃意图 I1：
[process_batch(data1), process_batch(data2), generate_report()] - 当前执行：
process_batch(data1)进行中（还需要 10 分钟）
事件： +security_alert(intrusion_detected, server_3)
决策过程：
-
事件选择（SE）：
- SE 优先级：安全事件 > 常规处理
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 调度策略是显式的且可配置的。
质量门禁
- 智能体架构具有显式的 SE、SO、SI 选择函数，并记录其策略
- 每个计划都有定义良好的触发事件和上下文守卫，可根据当前信念进行评估
- 计划库包含针对每种主要计划类型的失败处理计划（而不仅仅是成功路径）
- 信念更新机制能够处理矛盾信息，并将更改传播到活跃意图
- 多个意图可以并发活跃，并具有清晰的调度/抢占规则
- 事件队列处理是优先级的（而非 FIFO），并具有显式的优先级分配
- 计划失败触发事件，而不是系统崩溃或静默失败
- 上下文守卫是互斥的，或者计划选择是显式排序的，以避免非确定性
- 智能体能够通过公开意图堆栈和触发事件来解释其行为
- 系统在高事件负载下性能优雅降级（无无限循环或堆栈溢出）
不适用的边界
不适用于： 所有行为都是反应式的简单基于规则的系统（没有持久目标） → 改用： 基本规则引擎或事件-动作系统
不适用于： 执行期间环境不会变化的静态规划问题 → 改用： 经典规划器（A*、STRIPS、HTN）
不适用于： 需要保证响应时间或硬截止时间的实时系统 → 改用： 具有时序分析的实时调度系统
不适用于： 所有协调可以由中央控制器处理的系统 → 改用： 工作流编排或集中式任务队列
不适用于： 没有自主决策的纯数据转换流水线 → 改用： ETL 工具、流处理框架
不适用于： 需要机器学习或统计推断作为主要能力的应用程序 → 改用： ML 框架，如果需要，可将 BDI 作为协调层使用