MAKE RESERVATIONS 是活动，它说明以下内容：
一位顾客联系预订人员，询问汽车租赁事宜。
客户引用所需的开始和结束日期、首选车辆和取货处。
预订人员查找价格文件并报价。客户同意价格。
检查车辆可用性以查看在所需办公室是否有合适的车辆在所需时间内可用。
如果所请求的车辆在指定的取件处可用，则为客户保留。在登记预订的车辆可用性中进行条目。
预订人员向客户发出一个出租号码。然后在租赁文件中创建租赁协议，包括租赁编号、租赁期限、车辆类型和取车处。
例外
- 接送办公室没有合适的车辆。为客户提供替代车辆。
- 客户不同意价格并要求更换车辆和/或期限。
我为上面的活动设计了活动图，但我不知道我是否必须将问题放在控制流上的决策节点或上面？在我的情况下，同意价格应该在决策节点上还是在输入节点的控制流箭头上？
除此之外，如果用例仅指定一个条件，例如“如果有车辆可用，则向客户提供车辆并报价。如果客户接受，则开始租赁。” 决策节点是什么样子的？
此外，如果有 3 个不同的参与者，应该有一个泳道代表参与者，还是没有一个可以绘制活动图？
上面用例的活动图贴在下面
不知道是不是一定要把问题放在决策节点或者控制流上面？
就像您所做的那样，它们被写入流程中。在 UML 中，决策节点是空的（这与基本流程图不同，后者将在节点中写入条件）。来自决策节点的每个流都可以用警卫（即条件）进行注释。当决策节点被执行时，任何一个guard评估为真的流都可以被选择执行（通常情况下，guard的条件是排他的，只能选择一个guard，但这不是必须的）。
除此之外，如果用例仅指定一个条件，例如“如果有车辆可用，则向客户提供车辆并报价。如果客户接受，则开始租赁。” 决策节点是什么样子的？
它看起来像你的图，但是在决策节点之前应该有一个用于询问客户端的动作节点，因为决策节点的唯一目的是在几个可能的流中进行选择。作为决策节点执行的一部分，不执行任何操作。
此外，如果有 3 个不同的参与者，应该有一个泳道代表参与者，还是没有一个可以绘制活动图？
这取决于您要建模的内容，如果系统的不同部分执行不同的操作，您可以使用泳道（我最近在这里画了一个示例），但如果对分离建模不感兴趣，您可以避免使用泳道。通常，参与者会向系统提供输入，但他们不会自己执行操作。
例如，您的示例基于来自客户的输入（初始报价和协议）和客户接收输出（租赁号码）对预订人员（这是您系统的一部分）的行为进行建模。我建议您将其作为一个单独的问题提出，强调第三个演员。