跳转至

LINE

LINE 通过 LINE Messaging API 连接到 OpenClaw。该插件作为 Gateway 上的 webhook 接收器运行,并使用你的通道访问令牌 + 通道密钥进行身份验证。

状态:官方插件,需单独安装。支持直接消息、群聊、媒体、位置、Flex 消息、模板消息和快捷回复。不支持表情回应和线程。

安装

在配置通道之前,先安装 LINE:

openclaw plugins install @openclaw/line

本地检出(从 git 仓库运行时):

openclaw plugins install ./path/to/local/line-plugin

设置

  1. 创建 LINE Developers 账户并打开控制台: https://developers.line.biz/console/
  2. 创建(或选择)一个 Provider,并添加一个 Messaging API 通道。
  3. 从通道设置中复制 Channel access token 和 Channel secret。
  4. 在 Messaging API 设置中启用 Use webhook。
  5. 将 webhook URL 设置为你的 Gateway 端点(需要 HTTPS):
https://gateway-host/line/webhook

Gateway 会响应 LINE 的签名 webhook 验证请求:一个带有空 events 列表的 POST。LINE standby 模式下的签名事件会被确认,而不会排队或回复,因为另一个通道持有聊天控制权。其他签名入站事件会在返回 200 之前进入持久入站队列。Agent 处理会异步继续。 失败的投递会从队列中重试,包括在 Gateway 重启之后;毒丸事件在有限次重试后会变成失败的队列记录。如果持久化失败,请求会返回 500,而不是确认一个可能丢失的事件。 在队列到 Agent 的边界上,投递至少一次:Gateway 在活跃投递期间关闭或崩溃可能会重放该轮次。消息事件按 LINE 消息 ID 去重。其他事件类型使用 webhookEventId。保留的完成记录会抑制普通的重复 webhook,但执行外部副作用的处理器仍应是幂等的。 如果你需要自定义路径,请设置 channels.line.webhookPath 或 channels.line.accounts.<id>.webhookPath,并相应更新 URL。

安全说明:

  • LINE 签名验证依赖于请求体(对原始请求体进行 HMAC),因此 OpenClaw 在验证前会应用严格的预认证请求体限制(64 KB)和读取超时。
  • OpenClaw 从经过验证的原始请求字节中处理 webhook 事件。出于签名完整性安全考虑,上游中间件转换后的 req.body 值会被忽略。

入站持久性

设置 中的 webhook 契约只会在事件被持久化排队后确认该事件。持久化的 200 会携带 x-openclaw-delivery-accepted: durable。签名验证 ping(空事件列表)、仅 standby 的批次以及错误响应会省略该标记,因此反向代理可以要求该标记,以区分持久化接受和普通的 200。此后,投递通过核心通道入站排空流程运行,并带有 LINE 特定设置:

  • 按会话排序。 事件按源泳道串行化—— group:<groupId>、room:<roomId> 或 user:<userId>。没有会话来源的事件使用其自身的事件级泳道。在一个泳道内,事件按接收顺序分发,因此正在重试的事件会延迟同一聊天中后续的事件。一个聊天的积压永远不会阻塞另一个聊天的泳道,但所有泳道共享 8 个并发投递的上限:只要有空闲槽位,其他聊天就会独立推进,第 9 个泳道会等待其中一个槽位释放。
  • 重试。 失败的投递会以指数退避方式重试,从 1 秒开始,每次尝试翻倍,整个窗口内累计退避大约两分钟。第 8 次失败尝试后,事件会立即进入死信(retry-limit-exceeded):LINE 选择退出通用的 24 小时死信年龄下限,因此毒丸事件不会阻塞其会话泳道一整天。
  • 不可重试的失败。 这些会立即进入死信,无论尝试次数多少都不再重试:无法再解析的已存储载荷(invalid-event)、已经提交副作用的投递(delivery-side-effects-committed),以及 LINE API 身份验证失败(authentication-failed,HTTP 401/403)。
  • 停滞看门狗。 一个已认领的投递如果在 5 分钟内既未达到 Agent 轮次采纳,也未报告持续的延迟进度,就会被中止,并通过与其他失败相同的重试策略释放回其泳道:事件返回待处理状态,尝试次数递增,并记录 handler-timeout 作为其最后错误,同时保持在泳道头部的位置。停滞本身不会导致死信——只有上述重试上限才会以 retry-limit-exceeded 结束该事件。看门狗只覆盖从认领到采纳之间的窗口:延迟进度会重新启用它,采纳会清除它,因此长时间的 Agent 轮次永远不会被它中断。在看门狗触发后到达的采纳会被隔离,因此迟到的轮次无法认领一个已经交还的事件。
  • 崩溃恢复。 每次排空流程都会以一次恢复扫描开始,重新认领任何其所属 Gateway 进程不再运行的认领,因此因硬崩溃丢失的投递会在下一次扫描时重试,而不是在超时之后。30 分钟认领租约是相反情况的后备边界:如果没有成功的租约刷新,它会限制一个认领仅因为其所有者 PID 看起来仍然存活而保持受保护的时间——包括一个无法验证进程身份的复用 PID。在 Gateway 停止期间接受的事件仍会被持久化,并在下次启动后排空。
  • 重复抑制窗口。 每次准入时,LINE 会删除 30 天前的已完成和失败队列记录,然后每个账户保留每种类型最近更新的 4096 条记录。由于修剪在新事件入队之前运行,而不是按定时器运行,空闲账户上的记录可能会在 30 天后仍然存在,并且一条新完成的记录可能会使数量超过 4096,直到下一次准入。只要记录存在,同一事件重新投递的 webhook 会被确认,而不会进行第二次分发。一旦记录消失——无论是因年龄还是因上限——重新投递就会被准入并再次分发,因此具有外部副作用的处理器不应将此窗口视为自身幂等性的替代品。

在持久化失败时返回 500 的约定只有在 LINE 重新发送该事件时才有用。 当在 LINE Developers Console 中为该通道启用 Webhook redelivery(位于 Messaging API 设置中,与 Use webhook 并列),并且 bot 服务器未返回 2xx 时,LINE 会重新投递 webhook。如果没有启用该设置,被以 500 拒绝的事件不会被重新发送。即使已启用,重新投递也只是尽力而为,而非保证:LINE 文档说明它并不可靠,重试次数和间隔未公开,并且重新投递的事件可能乱序到达或多次到达(上述重复抑制窗口会吸收这些重复)。参见 重新投递未成功接收的 webhook。

死信事件仍可检查,并且根据失败原因可能可恢复。参见下文 入站死信 和 故障排查。

配置

最小配置:

{
  channels: {
    line: {
      enabled: true,
      channelAccessToken: "LINE_CHANNEL_ACCESS_TOKEN",
      channelSecret: "LINE_CHANNEL_SECRET",
      dmPolicy: "pairing",
    },
  },
}

公开 DM 配置:

{
  channels: {
    line: {
      enabled: true,
      channelAccessToken: "LINE_CHANNEL_ACCESS_TOKEN",
      channelSecret: "LINE_CHANNEL_SECRET",
      dmPolicy: "open",
      allowFrom: ["*"],
    },
  },
}

环境变量(仅默认账户):

  • LINE_CHANNEL_ACCESS_TOKEN
  • LINE_CHANNEL_SECRET

Token/secret 文件:

{
  channels: {
    line: {
      tokenFile: "/path/to/line-token.txt",
      secretFile: "/path/to/line-secret.txt",
    },
  },
}

tokenFile 和 secretFile 必须指向常规文件。符号链接会被拒绝。 内联配置值优先于文件。环境变量是默认账户的最后回退。

多个账户:

{
  channels: {
    line: {
      accounts: {
        marketing: {
          channelAccessToken: "...",
          channelSecret: "...",
          webhookPath: "/line/marketing",
        },
      },
    },
  },
}

访问控制

私信默认使用配对。未知发送者会收到配对码,其消息在批准前会被忽略:

openclaw pairing list line
openclaw pairing approve line <CODE>

允许列表和策略:

  • channels.line.dmPolicy:pairing | allowlist | open | disabled(默认 pairing)
  • channels.line.allowFrom:用于 DM 的允许列表 LINE 用户 ID。dmPolicy: "open" 要求 ["*"]
  • channels.line.groupPolicy:allowlist | open | disabled(默认 allowlist)
  • channels.line.groupAllowFrom:用于群组的允许列表 LINE 用户 ID。DM 的 allowFrom 条目不会允许群组发送者
  • 按群组覆盖:channels.line.groups.<groupId>.allowFrom(以及 enabled、requireMention、systemPrompt、skills)。当 groupPolicy: "allowlist" 时,设置 groupAllowFrom 或按群组的 allowFrom。空的群组允许列表会阻止群组消息,即使 DM 已开放。
  • channels.line.groups."*" 是每个群组和房间的默认条目,而不是会被命名条目替换的回退。命名条目会按字段覆盖 "*",因此命名条目省略的每个字段都会取自 "*"。这与 requireMention 通过共享群组作用域树解析的方式一致。参见 群组。
  • 升级检查:如果你只在 channels.line.groups."*" 上设置 enabled 或 allowFrom,同时列出了命名群组或房间,那么这些通配符值现在也会应用于该命名条目。早期版本只返回命名条目,因此仅通配符的字段从未到达它。升级前,请检查任何设置 enabled: false 或缩小 allowFrom 的 "*" 条目,并在需要保持当前访问权限的命名条目上重复该值。
  • 引用 bot 自己的一条消息即视为对其的提及,因此使用 LINE 的引用手势发出的群组回复会在没有显式提及的情况下到达 agent。设置 channels.defaults.implicitMentions.quotedBot: false 可阻止其绕过提及要求。LINE 读取该共享默认值,并且没有自己的通道作用域 implicitMentions 块。参见 群组。bot 会从它记得发送过的最近消息(每个账户数百条)中识别对自己消息的引用,因此引用较旧的消息,或在最后一次 Gateway 重启前发送的消息,仍然需要提及。
  • 静态发送者访问组可以通过 accessGroup:<name> 从 allowFrom、groupAllowFrom 和按群组的 allowFrom 中引用。参见 访问组。
  • 运行时说明:如果 channels.line 完全缺失,运行时会对群组检查回退到 groupPolicy="allowlist"(即使设置了 channels.defaults.groupPolicy)。

LINE ID 区分大小写。有效 ID 形式如下:

  • 用户:U + 32 个十六进制字符
  • 群组:C + 32 个十六进制字符
  • 房间:R + 32 个十六进制字符

目录

openclaw directory peers list --channel line 列出所选账户的 allowFrom、groupAllowFrom 和按群组 allowFrom 条目中的用户 ID。 openclaw directory groups list --channel line 列出已配置的群组和房间 ID。前缀会规范化为可发送的 ID,重复项只出现一次,并且会省略 * 和 accessGroup:<name> 条目。按 目录 中的说明使用 --account、--query、--limit 和 --json。

这些列表读取配置。它们不会获取实时的 LINE 联系人名单,也不会包含通过配对存储的批准。

群组加入介绍

当 bot 加入被允许的群组或多人房间时,它会在那里发布一条介绍。LINE 通过其群组摘要 API 暴露群组名称,但不提供多人房间的房间名称或主题。Messaging API 无法读取先前消息,因此介绍只使用可用元数据,并询问房间希望 bot 承担什么,而不是编造活动。

介绍默认启用。设置 channels.line.joinIntro: false 可禁用它们,或使用 channels.line.accounts.<accountId>.joinIntro 覆盖 一个账户。它们绝不会在一对一用户聊天中运行,也不会在其他成员加入时运行。 参见 群组加入介绍 了解房间准入、每房间一次的行为,以及将房间内容视为不可信且不使用工具的回合。

消息行为

  • 文本按 5000 个字符分块。
  • Markdown 格式会被去除。代码块和表格在可能时会被转换为 Flex 卡片。
  • 流式响应会被缓冲。LINE 接收完整块。加载动画仅在一对一聊天中运行——LINE 的加载 API 接受用户 id,并拒绝群组和房间 id——因此群组回复到达时没有加载动画。心跳轮次在生成回复期间也会显示加载动画。
  • 媒体下载大小受 channels.line.mediaMaxMb 限制(默认 10)。
  • 入站媒体在传递给 agent 之前会保存到 ~/.openclaw/media/inbound/,与其他通道插件使用的共享媒体存储保持一致。
  • LINE Webhook 只携带 id,不携带名称,因此发送者的显示名称和群组名称会被获取一次并缓存五分钟。群组和房间成员通过其会话读取,这是查看未将机器人添加为好友的成员的唯一方式。如果任一查找失败,则使用原始 id,消息仍会投递。多人房间没有名称 API,因此保留其房间 id。
  • LINE 使用元数据和替代文本描述内联表情。空的 () 替代文本会作为 [emoji] 传递给 agent。有意义的替代文本,例如 (hello),以及发送者输入的括号会被保留。
  • LINE 将一次操作中选择的多张图片作为每张图片一个 Webhook 事件发送,且顺序可能错乱。这些图片会被短暂保留,并作为携带所有图片的单个轮次回复,按 LINE 报告的索引排序;如果发送者的客户端省略了该索引——Android 上的 LINE 11.15 及更早版本——则保持图片被送达时的顺序。如果一组图片始终不完整,则用已到达的部分进行投递,而不是无限期保留,时间是在其最近部分到达后几秒——或者如果它仍在等待轮次,则在该聊天的队列轮到它之后。在此期间到达的其他内容——一条消息或另一组图片——会在其后面等待,因此回复保持聊天发送的顺序;在群组中,该队列是整个房间,因为 LINE 会话按聊天而不是按成员排序。没有原生视觉能力的模型只会读取第一张图片,除非 tools.media.image.attachments 同时设置 mode: "all" 和 maxAttachments;仅设置其中一个键时,限制仍为一。如果一组图片的各部分未声明总数,则用已到达的部分投递,并且不会提及其余部分,因为没有任何信息说明总共有多少张。

回复引用

channels.line.replyToMode 控制原生引用回复(出站回复会可见地引用它所回复的消息,这是群组中表明机器人正在与谁对话的方式):

值 行为
"off"(默认) 不自动引用
"first" 仅引用一个轮次中的第一条回复
"all" 引用一个轮次中的每条回复

其他通道接受的 "batched" 在此被拒绝:它用于区分对合并轮次的回复和对即时轮次的回复,而 LINE 路径上没有任何内容将轮次标记为已合并,因此这种区分不会出现。

按账户覆盖:channels.line.accounts.<id>.replyToMode。没有按聊天类型覆盖:Slack、Signal 和 Mattermost 接受的 replyToModeByChatType 在此被拒绝,因此同一账户在直接聊天和群组中以相同方式引用。

{ channels: { line: { replyToMode: "all" } } }

与 Telegram 一样,"off" 仅关闭自动引用:agent 编写的显式回复标签仍会生效。回复以内联方式引用,并保持在会话中可见,因此不会因线程化而隐藏任何内容。

LINE 通过随每条入站消息签发的令牌进行引用,而不是通过消息 id,并且 OpenClaw 只能引用其保留了该令牌的消息。因此,引用存在该设置无法解除的限制:

  • LINE 仅为文本、图片、视频和贴纸消息签发引用令牌。回复任何其他类型消息时,会以未引用方式发送。
  • LINE 拒绝在 Flex 卡片、媒体和位置标记上进行引用,因此一条回复只会引用一次,引用在第一个可承载引用的消息上。仅由这些内容组成的回复会以未引用方式发送。
  • 回复只能引用 OpenClaw 已接收的消息。LINE 也会为机器人自己发送的每条消息返回引用令牌,但这些令牌不会被保留,因此回复机器人自己之前某条消息时,会以未引用方式发送。
  • 只有 OpenClaw 作为其自身轮次交给 agent 的消息会被记住。在开启 requireMention 的群组中,被跳过的消息仍会作为一行群组历史到达 agent,但该行没有回复可以指名的 id,因此无法引用。
  • 由某人点击按钮启动的轮次本身没有消息,因此其回复会以未引用方式发送。
  • 令牌保存在正在运行的 Gateway 中,每个账户在其所有聊天中保留最近 500 个。回复上次重启之前的消息、同一账户中更繁忙的聊天后来将其挤出的消息,或由 openclaw message send 等独立进程发送的消息时,会以未引用方式发送。
  • 如果 LINE 以 HTTP 400 拒绝携带引用令牌的请求,OpenClaw 会重试同一回复但不带引用。删除或撤回被引用的消息本身不会使其令牌失效;LINE 可能改为显示被引用内容不可用。参见 LINE 引用消息。

块流式传输

块流式传输会将每个已完成的 assistant 块作为单独的 LINE 消息发送,而不是等待完整回复。它默认关闭,并且 channels.line.streaming 仅针对 LINE 决定它:

{ channels: { line: { streaming: { block: { enabled: true } } } } }
设置 效果
设置 效果
streaming.block.enabled: true 无论 agent 默认值如何,在块完成后立即发送已完成的块
streaming.block.enabled: false 即使 agent 默认值为 on,也保持 LINE 按完整回复发送
未设置(默认) 遵循 agents.defaults.blockStreamingDefault
streaming.block.coalesce 发送前合并小块(minChars、maxChars、idleMs)
streaming.chunkMode length(默认)或 newline,按段落边界拆分

按账户覆盖:channels.line.accounts.<id>.streaming。这些是跨渠道共享的块模式流式控制项;参见流式传输。

LINE 接收到的每个块都是一条独立消息,并且 LINE 会将消息计入渠道的月度配额,因此关闭此功能可让长回复保持最少的消息数。如果你希望块尽早到达,但不希望一次只发一个段落,coalesce.minChars 就是调节项——OpenClaw 自身的默认值为 800 个字符。

LINE 无法编辑已发送的消息,因此没有预览流式模式:这里没有 streaming.mode 或 streaming.preview,回复也永远不会就地修改。

结构化富消息

使用共享的消息展示字段来实现可移植选项。LINE 将 buttons 块渲染为 Flex 控件,将 select 块渲染为快捷回复。双按钮块是可移植的确认式表单。

buttons 块会渲染一张 Flex 卡片,承载展示内容的标题和文本。如果展示内容中唯一的控件是 select,则不会渲染卡片,因为快捷回复会附加到回复自身的文本消息上。其标题和文本块会改为追加到该文本中。LINE 在一条消息上最多绘制 13 个快捷回复,计数范围是回复中所有 select 块,而不是按单个块计数。每个 select 都会将其提示词和任何溢出选项一起保留在该文本中。提示词和溢出选项名称保持完整。只有原生快捷回复按钮标签会被缩短到 LINE 的 20 字符限制。

在直接聊天中,ask_user 问题提供的选项会变成同一张 Flex 卡片上可点击的控件,点击即可直接回答该问题。LINE 携带的是 Gateway 分配的选项索引,而不是标签,因此如果 Gateway 不再列出某个回复的选项,就会回退为可读文本,而不是绘制一个会回答错误选项的点击控件。符合条件的形态是一个单选、非秘密问题,提供两个到四个不同选项——这与 Telegram、Discord 和 Slack 使用的边界相同;其他情况仍保持为可读文本,通过输入回复仍可回答。群组、多人聊天以及无法识别的目标也使用这种可读回退。LINE 的群组和房间 postback 不包含允许接受问题回答所需的发送者身份;请改用选项文本回复。

其他… 自由文本控件不会被绘制。点击它本身不会解决任何问题,并且 LINE 无法从已交付的卡片上取回控件,因此该按钮只会增加一个点击,而不会带来问题自身文本未提供的任何变化。Discord 和 Slack 出于同样原因将该路径保留为文本。在符合条件的直接聊天中,每个已声明选项都保留一个原生控件,并且无论选项数量如何,其他… 都会以名称形式保留在卡片文本的 Actions: 下方。

LINE 无法编辑已交付的消息,因此问题结束后控件仍会留在屏幕上。此时到达的点击会以 That question is no longer waiting for an answer. 作为回答。初始点击遵循渠道的正常准入和配对规则。如果配对在问题被阅读期间被撤销,回答会被忽略,不会发出回答通知或新的配对挑战。Gateway 对已回答、已取消和已过期问题报告同一种终态,因此该通知不会声称具体是哪一种。

{
  action: "send",
  message: "Choose an action",
  presentation: {
    title: "Menu",
    blocks: [
      {
        type: "buttons",
        buttons: [
          { label: "Status", action: { type: "command", command: "/status" } },
          { label: "Website", action: { type: "url", url: "https://example.com" } },
        ],
      },
      {
        type: "select",
        placeholder: "Pick one",
        options: [
          { label: "Alpha", action: { type: "callback", value: "alpha" } },
          { label: "Help", action: { type: "command", command: "/help" } },
        ],
      },
    ],
  },
}

仅限 LINE 的输出使用 message(action="send") 上经过 schema 验证的 channelData.line 字段。发送一个 location 和/或一个 card。支持的卡片类型为 media_player、event、agenda、device 和 appletv_remote。

{
  action: "send",
  message: "Here you go",
  channelData: {
    line: {
      location: {
        title: "Office",
        address: "123 Main St",
        latitude: 35.681236,
        longitude: 139.767125,
      },
      card: {
        type: "event",
        title: "Team meeting",
        date: "2026-08-18",
        time: "10:00",
        location: "Conference room",
        description: "Weekly planning",
      },
    },
  },
}

其他卡片形态:

```json5 validate=false { type: "media_player", title: "Song", artist: "Artist", source: "Living Room", status: "playing", imageUrl: "https://example.com/cover.jpg" } { type: "agenda", title: "Today", events: [{ title: "Standup", time: "09:00", location: "Online" }] } { type: "device", name: "TV", deviceType: "Streaming box", status: "Playing", controls: [{ label: "Pause", action: "pause" }] } { type: "appletv_remote", name: "Living Room", status: "Playing" }

诸如 `[[buttons: ...]]` 的双括号字符串是纯文本,不会被解释为富消息指令。



LINE 插件还附带一个 `/card` 命令,用于 Flex 消息预设:

```text
/card info "Welcome" "Thanks for joining!"

卡片图片和图标必须使用 HTTPS。OpenClaw 会移除 URL 格式不正确或非 HTTPS 的图片,并在符合 LINE 的 30 KB 气泡和 50 KB 轮播限制时添加“Image unavailable”说明。视频主图会保留其必需的替代内容:不可用的视频或预览 URL 会回退到该内容,不可用的替代图片会变成文本框。无效的模板缩略图会被移除。轮播缩略图会一起移除,以便每一列保持相同的图片布局。文本和操作按钮保持完整。

ACP 支持

LINE 支持 ACP(Agent Communication Protocol)会话绑定:

  • /acp spawn <agent> --bind here 将当前 LINE 聊天绑定到 ACP 会话,而不会创建子线程。
  • 已配置的 ACP 绑定以及处于活动状态的会话绑定 ACP 会话在 LINE 上与其他会话渠道一样工作。

有关详情,请参阅 ACP 代理。

出站媒体

LINE 插件通过 agent message 工具发送图片、视频和音频:

  • 图片:作为 LINE 图片消息发送。预览图片默认使用媒体 URL。
  • 视频:需要预览图片。将 channelData.line.previewImageUrl 设置为图片 URL。
  • 音频:作为 LINE 音频消息发送。除非设置了 channelData.line.durationMs,否则时长默认为 60 秒。

当省略 mediaKind 时,LINE 会根据 LINE 特定选项或 URL 后缀推断它。原生后缀推断支持 JPEG/PNG、MP4 和 MP3/M4A。无后缀 URL 会保留图片回退。其他带后缀的 URL,以及未提供预览的推断 MP4,会变成文本链接。显式视频仍需要 previewImageUrl。

出站媒体 URL 必须是公开的 HTTPS URL,且最多 2000 个字符。OpenClaw 在将 URL 交给 LINE 之前会验证目标主机名,并拒绝回环、链路本地和私有网络目标。

故障排查

  • Webhook 验证失败: 确保 webhook URL 是 HTTPS,并且 channelSecret 与 LINE 控制台匹配。
  • 没有入站事件: 运行 openclaw channels status --probe。只有当渠道的 webhook URL 已注册,并且 LINE Developers Console 的 Messaging API 选项卡中 Use webhook 已开启时,LINE 才会传递事件,并且探测会报告这两项——对于 webhook 关闭或未注册的渠道,会指明需要更改的设置。OpenClaw 不会替你设置这两项:URL 有 API,但依赖于 OpenClaw 不知道的公开地址,而 Use webhook 开关完全没有 API。webhook 状态来自探测,因此不带 --probe 的 openclaw channels status 不会报告它。如果探测报告 webhook 已开启,请确认 webhook 路径与 channels.line.webhookPath 匹配,并且 Gateway 可从 LINE 访问。
  • 媒体下载错误: 如果媒体超过默认限制,请提高 channels.line.mediaMaxMb。
  • 推送被 HTTP 429 拒绝: 运行 openclaw channels status --channel line --probe --json。对于有限额度的账户,账户的 quota 包含 used 和 limit。缺少配额表示未知,而不是无限。健康的 bot 身份可能与已用尽的推送额度并存。在重试之前,请在 LINE Official Account Manager 中检查账户额度或套餐。429 也可能反映速率限制或临时消息预留。普通 reply-token 消息不会消耗此月度额度,而推送会。请参阅 LINE 消息定价。
  • Bot 静默跳过消息(事件进入死信): openclaw logs 会显示带有失败原因的 line: spooled update <id> ... dead-lettered 行。使用 openclaw channels dead-letters list --channel line --account default 进行检查,并在恢复前查看失败原因:resubmit 会按事件 id 重新入队,而不会检查事件失败的原因。在修复没有已提交副作用的失败原因后(例如提供商故障后的 retry-limit-exceeded),使用 openclaw channels dead-letters resubmit <event-id> --channel line --account default 重新入队一个事件。切勿重新提交 delivery-side-effects-committed 事件:该原因表示投递已经采用了 agent 轮次或消耗了其 reply token,因此重新入队会重复已提交的工作——例如第二次可见回复。openclaw health 会报告死信数量,openclaw doctor 会列出受影响的账户。
  • handler-timeout 重试: 投递已被认领,但在 5 分钟内既未达到 agent 轮次采用,也未报告延迟进度。这是轮次开始 之前 的停滞——采用会清除看门狗,因此已经在运行的轮次永远不会是原因,也永远不会被它中断。应改为查看分发路径:在认领和采用之间运行的投递准备工作,例如入站媒体下载,或一个未接受新工作的 Gateway。这不会使事件进入死信。openclaw logs 会显示 applying retry policy (handler-timeout),事件会等待其退避结束,最后错误为 handler-timeout。持续重复的停滞最终会耗尽重试限制,因此因停滞而进入死信的事件会归入 retry-limit-exceeded,而不是超时原因。检查受影响事件 id 附近的 openclaw logs --follow。

本页原文 Markdown:在 AtomGit 查看·内容源自开源项目 cl/openclaw