如何为基于代理的模型实现基于规则的决策者？

Question

在我试图开发的基于代理的模型中，我很难理解如何将基于规则的决策方法结合到基于代理的模型中。

代理的接口非常简单。

public interface IAgent
{
   public string ID { get; }

   public Action Percept(IPercept percept);
}

为了这个例子，让我们假设代理代表在一个大仓库内穿越道路的车辆，以便装卸他们的货物。他们的路线(从起点到代理目的地的道路顺序)由另一个代理，即主管指定。车辆代理的目标是遍历其指定路线，卸下货物，装载新的货物，接受主管指定的另一条路线，并重复这一过程。

车辆还必须注意可能发生的碰撞，例如在交叉点，并根据某些规则给予优先权(例如，运载最重货物的车辆具有优先权)。

据我所知，这是我想要构建的代理的内部结构：

​

​

所以车辆代理可以是：

public class Vehicle : IAgent
{
  public VehicleStateUpdater { get; set; }

  public RuleSet RuleSet { get; set; }

  public VehicleState State { get; set; }

  public Action Percept(IPercept percept)
  {
    VehicleStateUpdater.UpdateState(VehicleState, percept);
    Rule validRule = RuleSet.Match(VehicleState);
    VehicleStateUpdater.UpdateState(VehicleState, validRule);
    Action nextAction = validRule.GetAction();
    return nextAction;
  }
}

对于车辆代理人的内部状况，我正在考虑这样的事情：

public class VehicleState
{
  public Route Route { get; set; }

  public Cargo Cargo { get; set; }

  public Location CurrentLocation { get; set; }
}

对于此示例，必须为车辆代理实现3条规则。

1. 如果另一辆车辆在代理人附近(例如少于50米)，则货物最重的车辆有优先权，其他代理人必须保持其位置。
2. 当代理到达目的地时，他们卸载货物，装载新的货物，并等待主管分配新的路线。
3. 在任何特定的时刻，主管，无论出于什么原因，都可以发出命令，接收车辆必须遵守(保持位置或继续)。

VehicleStateUpdater必须考虑代理的当前状态、接收到的感知的类型，并相应地更改状态。因此，为了使状态反映出主管收到了例如命令，可以对其进行如下修改：

public class VehicleState
{
  public Route Route { get; set; }

  public Cargo Cargo { get; set; }

  public Location CurrentLocation { get; set; }

  // Additional Property
  public RadioCommand ActiveCommand { get; set; }
}

如果RadioCommand可以是值为None的枚举，请保持，继续。

但现在，如果另一辆车接近，我也必须在代理人的状态下登记。因此，我必须向VehicleState添加另一个属性。

public class VehicleState
{
  public Route Route { get; set; }

  public Cargo Cargo { get; set; }

  public Location CurrentLocation { get; set; }

  public RadioCommand ActiveCommand { get; set; }

  // Additional properties
  public bool IsAnotherVehicleApproaching { get; set; }

  public Location ApproachingVehicleLocation { get; set; }
}

这是我很难理解如何进行的地方，我有一种感觉，我没有真正遵循正确的方法。首先，我不知道如何使VehicleState类更加模块化和可扩展。第二，我不知道如何实现定义决策过程的基于规则的部分.我是否应该创建相互排斥的规则(这意味着每一种可能的状态必须不超过一条规则)？是否有一种设计方法允许我添加额外的规则，而不必来回地添加/修改VehicleState类的属性，以确保每种可能的Percept类型都可以由代理的内部状态处理？

我在“人工智能:现代方法手册”和其他资料中看到了这些例子，但现有的例子太简单，当需要设计更复杂的模型时，我无法“理解”这个概念。

如果有人能在执行基于规则的部分方面指出正确的方向，我将不胜感激。

我是用C#写的，但据我所知，它与我试图解决的更广泛的问题并没有真正的关系。

更新：

我试图纳入一项规则的一个例子：

public class HoldPositionCommandRule : IAgentRule<VehicleState>
{
    public int Priority { get; } = 0;

    public bool ConcludesTurn { get; } = false;


    public void Fire(IAgent agent, VehicleState state, IActionScheduler actionScheduler)
    {
        state.Navigator.IsMoving = false;
        //Use action scheduler to schedule subsequent actions...
    }

    public bool IsValid(VehicleState state)
    {
        bool isValid = state.RadioCommandHandler.HasBeenOrderedToHoldPosition;
        return isValid;
    }
}

代理决策者的样本，我也试着去实现。

public void Execute(IAgentMessage message,
                    IActionScheduler actionScheduler)
{
    _agentStateUpdater.Update(_state, message);
    Option<IAgentRule<TState>> validRule = _ruleMatcher.Match(_state);
    validRule.MatchSome(rule => rule.Fire(this, _state, actionScheduler));
}

Answer 1

我认为你的问题包含两个主要的子问题：

• 建模的灵活性，特别是如何使添加属性和规则更容易的系统。
• 如何制定出正确的规则集，以及如何组织它们，使代理正常工作。

所以让我们每个人都来看看。

建模柔性

实际上，我认为你现在所拥有的还不算太糟。让我解释一下原因。

您表示关注的是，“一种设计方法允许我添加额外的规则，而不必反复使用VehicleState类并添加/修改属性”。

我认为对此的答案是“否”，除非您遵循完全不同的路径，让代理自主学习规则和属性(如在深度强化学习中)，这会带来自身的一系列困难。

如果要像问题中描述的那样手动编码代理知识，那么在添加新规则时，如何避免引入新属性的需要？当然，您可以尝试预测您需要的所有属性，而不允许自己编写需要新属性的规则，但是新规则的本质是带来问题的新方面，这通常需要新的属性。这与软件工程没有什么不同，软件工程需要多次迭代和更改。

基于规则的建模

有两种书写规则的方式:祈使式和声明式。

• 在命令式风格中，您可以编写采取行动所需的条件。当两者都适用时，您还必须注意选择一个操作而不是另一个操作(可能使用优先级系统)。因此，你可以有一个规则沿一条路线移动，另一个规则是在高优先级车辆接近时停车。这似乎是您目前正在追求的方法。
• 在声明式风格中，您声明您的环境的规则是什么，操作如何影响环境，以及您关心什么(将实用程序分配给特定的状态或子状态)，并让系统处理所有这些来为您计算最佳操作。在这里，你宣布一个移动的决定如何影响你的位置，你宣布碰撞是如何发生的，你宣布到达你路线的尽头是好的，碰撞是坏的。请注意，这里没有作出决策的规则；系统使用规则来确定特定情况下具有最大值的操作。

理解命令式和声明式风格之间区别的一种直观方法是考虑编写一个下棋的代理。在一种命令式的风格中，程序员对国际象棋的规则进行编码，还包括如何下棋、如何打开游戏、如何选择最佳的动作等等。也就是说，系统将反映程序员的国际象棋技能。在声明式风格中，程序员只需对国际象棋规则进行编码，以及系统如何自动探索这些规则并确定最佳动作。在这种情况下，程序员不需要知道如何下好棋，这样程序才能真正地下棋。

命令式风格更容易实现，但不那么灵活，而且随着系统复杂性的增加，会变得非常混乱。你必须开始考虑各种情况，例如，当三辆车相遇时，你该怎么做。在国际象棋的例子中，想象一下，如果我们稍微改变了国际象棋的规则，整个系统需要被审查！在某种程度上，在命令式系统中几乎没有“人工智能”和“推理”，因为是程序员提前进行了所有的推理，想出了所有的解决方案并对它们进行编码。它只是一个常规的程序，而不是人工智能程序。这似乎是你说的那种困难。

声明式风格更加优雅和可扩展。您不需要弄清楚如何确定最佳的操作；系统会为您做这件事。在国际象棋示例中，您可以很容易地修改代码中的一条国际象棋规则，系统将使用新规则来查找更改后的游戏中的最佳动作。然而，它需要一个推理机，这个软件知道如何接受许多规则和实用程序，并决定哪一个是最好的操作。这样一个推理机就是系统中的“人工智能”。它会自动考虑所有可能的场景(不一定一个接一个，因为它通常会使用更聪明的技术来考虑不同的场景)，并确定每个场景中的最佳操作。然而，推理机的实现是复杂的，或者，如果使用现有的引擎，它可能非常有限，因为这些通常是研究包。我相信，当涉及到实际的实际应用时，使用声明式的方法，人们可以为他们的特殊需要编写一个定制的系统。

我发现了几个类似这些思路的开源项目(见下文)；这将让您了解可用的内容。正如你所看到的，这些都是研究项目，而且范围相对有限。

在那之后，该怎么做？我不知道你的目标是什么。如果您正在开发一个玩具问题来实践，您当前的命令式系统可能就足够了。如果你想学习声明式的风格，深入阅读AIMA教材会更好。作者还维护了一个本书中一些算法的实现的开源存储库。

https://www.jmlr.org/papers/v18/17-156.html

https://github.com/douthwja01/OpenMAS

https://smartgrid.ieee.org/newsletters/may-2021/multi-agent-opendss-an-open-source-and-scalable-distribution-grid-platform