AI 代理：已知限制与解决方法

AI 代理功能强大，但存在一些平台级别的限制需要注意。 请使用下面推荐的解决方法，以确保代理的行为一致且可靠。

对话可见性

AI 代理对对话的元数据、历史记录和内部上下文的可见性有限。

渠道和来源元数据

AI 代理无法查看渠道特定的详细信息，例如：

• 联系人连接的是哪个渠道

• 联系人来自哪里（例如，广告或评论）

• 联系人来自哪个TikTok 广告

这意味着 AI 代理在做决策时不应依赖渠道或来源的元数据。

推荐的解决方法：

如果你的用例需要知道联系人来自何处，请使用工作流捕获该信息并将其存储在联系人字段中。

例如：

• 创建一个以对话已打开为触发器的工作流

• 根据渠道或来源添加条件（例如：TikTok 广告）

• 更新联系人字段，例如线索来源或活动名称

然后你可以在 AI 代理的指令中要求其引用该联系人字段。

这种方法使 AI 代理能够可靠地使用与来源相关的上下文，即使它们无法直接访问渠道元数据。

分配历史

AI 代理无法查看分配历史或过去的分配操作，包括是否有其他 AI 代理将对话分配给它们。

这意味着：

• 如果AI 代理 1 将对话分配给 AI 代理 2，AI 代理 2 不会知道它刚刚被分配。

• AI 代理 2 无法区分由 AI 代理 1 发送的消息与人工客服发送的消息。

• 因此，AI 代理 2 可能在不了解对话上下文的情况下开始响应，或不必要地重复操作。

推荐的解决方法：

如果你将多个 AI 代理串联使用，请包含一个明确的交接消息以提示下一个代理开始工作。

示例：在 AI 代理 1 的指令中

在将对话分配给 AI 代理 2 之前，发送一条消息：'我会把你转交给 AI 代理 2，接下来将由该代理为你服务。'  然后将其分配给 AI 代理 2。 

示例：在 AI 代理 2 的指令中

只有在看到该消息后才开始你的顶层流程：'我会把你转交给 AI 代理 2，接下来将由该代理为你服务。'  看到该消息后，向用户打招呼并开始你的资格确认/支持流程。 

这可确保：

• AI 代理 2 知道交接已发生

• AI 代理 2 在正确的时刻开始

• 用户在代理之间获得顺畅的过渡

内部上下文和消息历史

AI 代理无法查看内部评论，并且在对话中只能访问最近的 20 条消息。

因此，在做决策时，AI 代理不应依赖渠道来源、内部备注或较早的对话上下文。

推荐的解决方法：

将重要上下文存储在联系人字段或生命周期阶段中，并指示 AI 代理改为引用这些字段。

例如：

• 使用工作流或人工流程来保持诸如计划类型、客户状态或问题类别等字段的最新状态

• 使用生命周期阶段（例如：新线索、合格线索、客户）来指导代理的响应方式

• 在你的 AI 代理指令中，明确引用这些字段（例如，"如果生命周期是 客户，优先提供与支持相关的回应。"）

这可确保 AI 代理即使在无法访问较早消息或内部评论的情况下，也能使用可靠的结构化数据做出一致的决策。

外部能力

AI 代理目前在 respond.io 内运行，无法访问外部工具。 因此，它们无法进行网页搜索。

任何需要外部数据或 API 调用的逻辑应通过工作流或集成来处理。

注意：对 HTTP 请求的支持即将推出。

消息类型与附件

AI 代理只能发送文本消息，目前无法发送文件或媒体，例如：

• 文件（例如：PDF、文档）

• 图像

• 视频

• 语音消息

• 贴纸或其他富媒体

这意味着 AI 代理不应用于需要发送附件的流程（例如：宣传册、入职文档、发票或截图）。

推荐的解决方法：

当联系人请求文件或媒体时，使用工作流步骤或将对话分配给人工客服。 你也可以配置一个工作流，在将控制权限返回给 AI 代理之前自动发送所需文件（若该渠道支持）。

模型配置

AI 代理不支持手动的温度设置，因为较新的 AI 模型不再暴露温度控制。

如果你想调整 AI 代理的"创造性"（类似于温度），最佳方法是在你的指令中直接提示它。 例如，你可以根据用例引导 AI 表现得更富创造性或更为严格。

高创造性（更高的"温度"）：

以客户的语气热情且富有创造性地回应。 

低创造性（更低的"温度"）：

仅使用提供的公司知识来源和对话历史来回答客户的问题。  不要猜测或添加新信息。 

这使你在无需专用温度设置的情况下，更好地控制语气和一致性。