RavenClaw介绍_006_对话任务Agent

总结

---

2.1.1 Dialog Task agents

Two categories of dialog agents populate the task tree: fundamental dialog agents and dialog agencies.

两种对话agents填充了任务树：基础对话agents和对话agencies。

The fundamental dialog agents appear as leaf nodes (i.e. Welcome, AskRegistered) and represent atomic dialog actions.

基础对话代理以叶节点的形式出现（即Welcome、AskRegistered），并代表原子对话动作。

RavenClaw uses four types of fundamental agents:
Inform - sends an output (e.g. Welcome),
Request - requests information (e.g. AskRegistered),
Expect - expects information, but without requesting it (e.g. Projector)
and
DomainOperation - performs other domain-related operations (e.g. GetResults).

RavenClaw使用四种类型的基础代理：
Inform - 发送输出（例如Welcome），
Request - 请求信息（例如AskRegistered），
Expect - 期待信息，但不请求（例如Projector），
以及
DomainOperation - 执行其他与域相关的操作（例如GetResults）。

---

The non-terminal nodes in the tree are dialog agencies (e.g. Login, GetQuery); agencies control the execution of their subsumed agents, capturing the higher level temporal and logical structure of the dialog task.

树中的非终端节点是对话机构（例如Login、GetQuery）；agencies控制其包含agents的执行，捕获对话任务的更高层次的时间和逻辑结构。

Each agent implements an Execute routine, and holds a set of preconditions and triggers, and a completion criterion.

每个代理都实现了一个执行例程，并持有一组前提条件和触发器，以及一个完成标准。

The Execute routine is specific to the agent type.

执行例程特定于代理类型。

For example,
Inform-type agents simply generate an output when executed,
while Request-type agents also trigger an Input Phase (see subsection 2.2.2) to collect the user’s response.

例如，
Inform类型的代理在执行时简单地生成输出，
而Request类型的代理还会触发输入阶段（参见第2.2.2小节）以收集用户的响应。

For agencies, the Execute routine is in charge of planning the order of the execution of the sub-agents.

对于机构，执行例程负责规划子代理的执行顺序。

This sub-task planning problem is currently resolved by combining a set of simple policies (i.e. left-to-right traversal), with the preconditions that each agent holds.

这个子任务规划问题目前通过结合一组简单策略（即从左到右遍历）和每个代理持有的前提条件来解决。

The system is however open to more sophisticated policies, and even learning at the dialog task level (e.g. by casting the sub-agent planning problem as a Markov Decision Process[^4]).

然而，该系统对更复杂的策略开放，甚至可以在对话任务级别进行学习（例如，通过将子代理规划问题视为马尔可夫决策过程[^4]）。

[4]

Litman, D. J.，

Kearns, M. S.，

Singh, S.，

以及

Walker, M. A.，

“对话管理的自动优化”，

收录于COLING 2000会议论文集。

解释

关于Expect类型的对话代理，我们可以结合其定义和特性来举例说明。

Expect类型的对话代理示例

假设在一个会议室预订系统中，有一个Expect类型的对话代理被命名为Projector。

这个代理的目的是期待用户可能提到的关于投影仪的需求，但不会在对话中显式询问用户是否需要投影仪。

场景描述

用户通过语音与系统进行交互，以预订一个会议室。

在对话过程中，用户可能会提到他们需要在会议中使用投影仪，但这并不是系统必须询问的信息，因为有些会议可能不需要投影仪。

然而，如果用户提到了投影仪，系统应该能够识别并作出相应的处理。

Expect代理的作用

1. 期待信息：当Projector代理处于激活状态时，它会期待从用户的输入中捕获到与投影仪相关的信息。这种期待是隐式的，即系统不会主动询问用户是否需要投影仪。

2. 处理信息：如果用户在对话中提到了投影仪（例如，“我们还需要一个投影仪”），Projector代理将能够识别这一信息，并触发相应的处理机制。

   1. 这可能包括记录用户的需求、调整会议室的配置（如果系统具有这样的能力）或向用户提供关于投影仪使用的进一步信息。

3. 不干扰对话流程：由于Projector代理不会主动请求信息，因此它不会打断对话的自然流程。

   1. 这允许对话更加流畅地进行，同时仍然能够捕获用户可能提到的与投影仪相关的需求。

与其他代理的对比

与Request类型的对话代理相比，Expect类型的代理（如Projector）在对话中更加被动。

Request类型的代理会主动向用户请求信息（例如，“您需要投影仪吗？”），

而Expect类型的代理则只是静静地等待并准备处理可能出现的相关信息。

这种差异使得Expect类型的代理在某些情况下更加合适，因为它们允许对话在不受干扰的情况下自然发展，

同时仍然能够捕获和处理重要的信息。

然而，这也意味着Expect类型的代理可能不如Request类型的代理那样能够确保所有必要的信息都被明确获取。

因此，在实际应用中，开发人员需要根据对话的具体需求和上下文来选择合适的代理类型。