OpenClaw 群聊为什么“正在输入”却不一定回复：typingMode 与 visibleReplies 源码解析

说明：本文由 OpenClaw 助手根据一次真实配置与排障过程辅助整理，内容经过人工确认。

为保护隐私，文中的群 ID、用户 ID、应用信息和本地路径均已删除或泛化。源码结论基于 OpenClaw 2026.6.10（源码快照接近 86018c2174）与 Lark/Feishu 插件 2026.6.10；后续版本若调整 schema 或投递链路，应以对应版本源码为准。

在飞书群里接入 OpenClaw 后，很容易把下面几个现象混为一谈：

• 机器人是否接收这条消息；
• 没有 @ 机器人时，消息是否会触发 Agent；
• 机器人何时显示“正在输入”；
• Agent 生成的最终文本是否会自动发回群里；
• Agent 决定沉默时，群里是否仍会短暂出现 typing；
• 能否只给几个特定群设置不同的回复投递策略。

这些问题分别由不同配置控制。尤其是 typingMode 与 visibleReplies：前者控制何时发出输入状态信号，后者控制谁拥有最终可见回复的投递权。两者有关联，但不是同一件事。

本文从 OpenClaw 核心与 Feishu 插件的源码出发，把这条链路完整拆开。

---

一、先建立正确的四层模型

面对一条飞书群消息，至少要区分四层决策：

层	典型配置	它回答的问题
群准入	channels.feishu.groupPolicy、groups、allowFrom	这个群、这个发送者是否被允许进入处理链路？
触发条件	requireMention	必须 @ 机器人，还是普通消息也能触发 Agent？
输入状态	session.typingMode、agents.defaults.typingMode	Agent 运行到什么阶段时开始显示 typing？
可见回复投递	messages.visibleReplies、messages.groupChat.visibleReplies	最终回复由 OpenClaw 自动发送，还是必须由 Agent 显式调用 message 工具发送？

它们不是同一个开关。

例如：

• requireMention: false 只代表“不需要 @ 也能触发”，不代表必须回复；
• typingMode: "instant" 只代表尽早显示 typing，不代表最终一定发消息；
• visibleReplies: "message_tool" 只改变可见消息的投递所有权，不会阻止 Agent 运行，也不会自动降低 token 消耗；
• groupPolicy 决定群是否准入，不决定 typing 的开始时机。

用一张流程图表示：

flowchart TD A[收到飞书群消息] --> B{群与发送者是否准入} B -->|否| X[丢弃：不启动 Agent，也不显示 typing] B -->|是| C{是否满足 requireMention} C -->|否| H[可仅进入历史/上下文，不作为用户请求] C -->|是，或无需 @| D[解析 visibleReplies] D --> E[结合显式配置解析 typingMode] E --> F[启动 Agent] F --> G{回复投递模式} G -->|automatic| I[普通 final 自动发回来源会话] G -->|message_tool| J[只有 message 工具调用会公开发送] J --> K[普通 final 保留为内部结果]

后面的所有细节，都可以放回这四层里理解。

---

二、typingMode 到底控制什么

OpenClaw 当前定义了四种 typing 模式：

never | instant | thinking | message

相关类型与 schema 位于：

• src/config/types.agent-defaults.ts
• src/config/zod-schema.session.ts
• src/config/zod-schema.agent-defaults.ts

1. never

不主动显示 typing。

适合：

• 极度重视群聊安静度；
• 后台任务、无需交互反馈的自动化；
• 不希望“先显示正在输入，最后却沉默”的场景。

代价是：长任务开始后，用户在最终回复出现前看不到任何即时反馈。

2. instant

Agent run 一开始就启动 typing。

源码中，signalRunStart() 会立即调用 typing controller。它提供最强的即时反馈，但也最容易产生“假动作”：Agent 最后可能判断无需回复，或者工具调用失败，群里却已经出现过“正在输入”。

3. thinking

等到出现第一段 reasoning/thinking 增量后再启动 typing。

它比 instant 稍晚，也依赖当前模型与运行器是否真的产生可观察的 reasoning delta。如果没有对应增量，typing 可能一直不出现。

4. message

等到出现第一段可渲染、非静默的文本增量后再启动 typing。

这是普通未提及群聊的默认值。它有两个重要特性：

• NO_REPLY 等静默标记不会触发 typing；
• 仅开始工具调用、但尚未输出可见文本时，通常不会触发 typing。

因此，message 更接近“Agent 已确定要说话时再给提示”，能减少无回复场景中的 typing 闪烁。

但在 message_tool 投递模式下，Agent 可能不先生成普通 assistant 文本，而是直接调用 message(action="send")。如果又显式把 typingMode 固定为 message，就可能出现：消息已经通过工具发出，typing 却从未启动。

四种模式对比

模式	开始时机	对静默任务的表现	主要取舍
never	永不启动	完全安静	长任务没有即时反馈
instant	run 开始	即使最终沉默，也可能短暂出现	反馈最快，但可能“假动作”
thinking	首个 reasoning delta	取决于模型是否产生 reasoning 流	介于 instant 与 message 之间
message	首个可见文本 delta	NO_REPLY 不触发	更克制，但 tool-first 回复可能不显示 typing

核心实现可在 src/auto-reply/reply/typing-mode.ts 中找到。

---

三、typingMode 的配置优先级与动态默认值

真正决定一次 run 使用哪种 typing 模式的代码，核心逻辑可以简化为：

const typingMode = resolveTypingMode({
  configured: sessionCfg?.typingMode ?? agentCfg?.typingMode,
  isGroupChat,
  wasMentioned,
  sourceReplyDeliveryMode,
  // 省略 heartbeat、system event、suppressTyping 等参数
});

也就是说，普通消息链路中的优先级是：

session.typingMode
  > agents.defaults.typingMode
  > OpenClaw 根据会话与投递模式计算动态默认值

这里最容易产生两个误解。

误解一：session.typingMode 是某个具体 session 的配置

不是。

它位于 openclaw.json 的根级 session 配置块，是全局 session 行为配置。名字里的 session 指配置域，不是让你按某个飞书群 session key 写一份覆盖值。

例如：

{
  session: {
    typingMode: "instant"
  }
}

这会成为全局显式配置，不是只影响当前对话。

误解二：未配置就等于固定的 message

也不是。

resolveTypingMode() 在没有显式配置时，会根据当前场景动态选择：

if (configured) return configured;

if (sourceReplyDeliveryMode === "message_tool_only") {
  return "instant";
}

if (!isGroupChat || wasMentioned) {
  return "instant";
}

return "message";

因此，普通消息的默认矩阵是：

场景	没有显式配置时的 typingMode
私聊	instant
群聊中明确 @ 机器人	instant
普通未 @ 的群消息，自动投递	message
message_tool_only 投递	instant

OpenClaw 的单元测试也覆盖了这个交互：

• 未提及的普通群聊默认是 message；
• 同一个群若使用 message-tool-only 投递，默认变成 instant；
• 若显式配置为 message，显式配置仍然胜出。

这正是“把 visibleReplies 改为 message_tool 后，typing 突然更早出现”的源码原因。

本文讨论普通 direct/group auto-reply。heartbeat、system event、内部 webchat 等路径还有专门的 typing 抑制或存活提示逻辑，不应直接套用这张表。

---

四、typingIntervalSeconds 不是“延迟几秒再显示”

另一个常见误解是把 typingIntervalSeconds 当作 typing 的启动延迟。

它控制的是已经开始后，输入状态的刷新/续期节奏，默认值为 6 秒；真正决定开始时机的是 typingMode。

OpenClaw 核心的 typing controller 还带有清理和 TTL 保护：

• 默认刷新间隔约 6 秒；
• 默认 TTL 约 2 分钟；
• run 完成且消息 dispatcher 空闲后停止；
• 异常路径下有兜底清理；
• typing 失败属于 best-effort，不应阻塞正常回复。

配置示例：

{
  agents: {
    defaults: {
      typingMode: "instant",
      typingIntervalSeconds: 6
    }
  }
}

这表示“立即开始，并按框架的节奏维持状态”，不是“等待 6 秒后开始”。

---

五、visibleReplies 控制的是最终回复投递权

当前配置层提供两个值：

automatic | message_tool

它们对应的核心语义如下。

1. automatic

普通 final 文本由 OpenClaw 的来源会话投递器自动发回。

Agent 只要正常返回 final，就能在原群或原私聊里看到回复。Agent 仍然可以在需要附件、指定目标或特殊消息形态时调用 message 工具，但普通文本不要求显式工具调用。

2. message_tool

可见回复必须由 Agent 显式调用：

message(action="send", ...)

普通 final 不再自动发回来源会话，而是保留为内部结果。

当运行器进入这种模式时，系统提示词与 message 工具描述都会动态加入约束，大意是：

• 要向当前来源会话公开回复，必须使用 message(action="send")；
• target 默认是当前来源会话；
• 普通 final 是私有结果，不会自动投递；
• 真正想保持沉默时，不调用 message 工具即可。

相关实现分布在：

• src/auto-reply/reply/source-reply-delivery-mode.ts
• src/agents/system-prompt.ts
• src/agents/tools/message-tool.ts
• src/auto-reply/reply/agent-runner.ts

配置名与运行时名不同

日志和源码里可能看到：

message_tool_only

而配置文件中写的是：

visibleReplies: "message_tool"

两者不是两个不同功能：

• 配置枚举："automatic" | "message_tool"
• 内部运行时枚举："automatic" | "message_tool_only"

不要把内部值 message_tool_only 原样写进 JSON 配置。

---

六、visibleReplies 的作用域与覆盖关系

两个入口的作用域不同：

{
  messages: {
    visibleReplies: "automatic",
    groupChat: {
      visibleReplies: "message_tool"
    }
  }
}

• messages.visibleReplies：较通用的来源会话策略，也影响 direct；
• messages.groupChat.visibleReplies：专门覆盖 group/channel 会话；
• 群聊中，groupChat.visibleReplies 比 messages.visibleReplies 更具体，优先级更高。

核心解析逻辑可概括为：

const configuredMode = isGroupOrChannel
  ? cfg.messages?.groupChat?.visibleReplies
      ?? cfg.messages?.visibleReplies
  : cfg.messages?.visibleReplies
      ?? harnessDefault;

所以：

{
  messages: {
    visibleReplies: "message_tool",
    groupChat: {
      visibleReplies: "automatic"
    }
  }
}

表示私聊采用 message tool，群聊仍自动投递。

几个边界例外

普通群聊请求遵循上述配置，但源码还处理了少数特殊情况：

• 显式 source reply command 会走 automatic；
• 外部 room_event 语义可能强制进入 message-tool-only，以便默认安静；
• 如果配置要求 message tool，但当前运行环境根本没有 message 工具，非 strict 场景会回退到 automatic，避免回复彻底丢失；
• 某些插件自己拥有 conversation binding 与投递链路时，会走插件侧策略。

因此，排障时不能只看 JSON，还要确认本次 run 最终解析出的 sourceReplyDeliveryMode。

---

七、为什么 message_tool 会让 typing 默认变成 instant

这是二者最关键的耦合点。

OpenClaw 的设计意图可以理解为：

• automatic 模式下，普通群聊若尚未产生可见文本，可以先保持安静；
• message-tool-only 模式下，最终是否公开发送要等 Agent 主动调用工具，系统不能再依赖普通 final 的自动投递；
• 为了让用户知道 Agent 已接手处理，未显式配置 typingMode 时，系统把它提升为 instant。

所以，visibleReplies: "message_tool" 并不是直接“开启 typing”的按钮。它只是改变投递模式，而 typing resolver 看到 message_tool_only 后，选择了 instant 作为动态默认值。

如果显式配置：

{
  session: {
    typingMode: "never"
  },
  messages: {
    groupChat: {
      visibleReplies: "message_tool"
    }
  }
}

那么 never 仍然胜出，不会显示 typing。

如果显式配置：

{
  agents: {
    defaults: {
      typingMode: "message"
    }
  },
  messages: {
    groupChat: {
      visibleReplies: "message_tool"
    }
  }
}

则不会因为 message-tool-only 自动切换为 instant；但如前所述，tool-first 回复可能在消息发出前都没有可渲染文本，从而看不到 typing。

组合矩阵

显式 typingMode	visibleReplies / 场景	实际 typing 行为
未设置	群聊 automatic，未 @	message
未设置	群聊 automatic，已 @	instant
未设置	群聊 message_tool	instant
message	群聊 message_tool	仍为 message
never	任意普通投递模式	never
thinking	任意普通投递模式	等 reasoning delta

---

八、Feishu 的 typing 并不是真正的原生“正在输入”API

这是飞书插件实现中最有意思的一层。

当前 Lark/Feishu 插件源码明确说明：飞书没有被插件使用的 first-class typing API。插件通过给用户原消息添加内置的 Typing 表情 reaction 来模拟输入状态：

client.im.messageReaction.create({
  path: { message_id: messageId },
  data: {
    reaction_type: {
      emoji_type: "Typing"
    }
  }
});

回复完成后，再删除这条 reaction。

主要代码位于插件的：

• src/messaging/outbound/typing.js
• src/card/reply-dispatcher.js

这带来几个实际影响。

1. typing 绑定的是原消息

它本质上是“机器人对某条消息加了一个 Typing reaction”，而不是整个群的原生输入状态广播。

2. typing 失败不应阻塞回复

reaction 的创建或删除失败时，插件记录日志并吞掉异常。也就是说，typing 是 best-effort：看不到 typing，不代表 Agent 没运行；typing 清理失败，也不应该阻止最终消息发送。

3. Feishu 上刷新间隔通常没有明显视觉差异

reaction 一旦添加就会持续存在。插件会记录已有的 reaction ID，避免重复添加；其插件侧 keepalive 间隔也是 0。

因此，typingIntervalSeconds 在框架层仍代表刷新节奏，但对飞书这种“单个静态 reaction”实现，通常不会产生像某些平台原生 typing TTL 那样明显的续期效果。真正可见的关键是：何时添加、何时删除，以及异常时是否完成兜底清理。

4. 群里可能看到“出现后又消失，但没有回复”

这并不矛盾。可能的完整链路是：

1. message-tool-only 让默认 typingMode 变为 instant；
2. 插件立即给原消息加 Typing reaction；
3. Agent 判断无需公开回复，因此没有调用 message(action="send")；
4. run 完成，reaction 被删除；
5. 群里没有出现最终消息。

这是合法的“处理过，但选择沉默”，不是自动回复丢失的唯一证据。

---

九、message_tool 除了 typing 更早，还有哪些影响

这是实际配置时最应该评估的部分。

1. 普通 final 不再公开投递

这是核心变化。只在 final 中写答案、不调用 message 工具，用户就看不到回复。

因此，模型或系统提示词若没有正确遵循 message-tool-only 约束，就会表现为：

出现 typing → typing 消失 → 群里没有消息

2. 沉默语义从 NO_REPLY 变成“不调用工具”

automatic 模式常通过静默 token 表达不回复；message-tool-only 模式下，最自然的沉默方式是根本不调用 message(action="send")。

运行器也会避免把普通 final 当成来源会话的可见消息。

3. 不会减少 Agent run 或 token 消耗

只要消息已经通过 groupPolicy、sender allowlist 和 requireMention 等上游门禁，它仍会启动 Agent。

visibleReplies 决定的是“怎么公开发出去”，不是“要不要推理”。所以把群设成 message_tool 并不能作为成本控制手段。

如果真正目标是降低运行次数，应调整：

• 群准入；
• sender allowlist；
• requireMention；
• unmentioned inbound 的事件语义；
• 或更上游的触发规则。

4. 在无需 @ 的活跃群里，更容易产生 typing 噪声

若 requireMention: false，每条符合准入规则的普通消息都可能成为用户请求。message-tool-only 又会在未显式配置时把 typingMode 提升为 instant。

结果是：即使 Agent 经常决定不参与，群成员也可能频繁看到 Typing reaction 出现又消失。

这是一种 UX 取舍：

• 好处：明确告诉用户 Agent 已接手；
• 坏处：旁听型、选择性回复的 Agent 会显得“每句话都想插嘴”。

5. 可见输出更依赖工具调用的正确性

工具调用需要正确的 action、参数、目标与消息内容。虽然 target 通常默认当前来源会话，但复杂 Agent、定制 prompt 或工具过滤仍可能造成漏发。

6. 对附件、卡片和跨目标投递更可控

反过来，message-tool-only 也有明显优势：Agent 可以显式决定消息类型、附件、卡片、回复目标和是否发送，而不是被一个统一 final 自动投递器限制。

它更适合“Agent 是消息编排器”的架构，而不只是“聊天模型返回一段文本”。

7. 首次公开发送后，运行器会抑制多余进度噪声

OpenClaw 会跟踪本次 run 是否已通过 message 工具向来源会话发送消息，并在投递完成后抑制不必要的后续 progress，降低重复或顺序混乱的概率。

但这不等于自动去重所有业务消息：Agent 连续调用多次 message(action="send")，仍可能产生多条可见消息。

---

十、当前版本不能按飞书群单独设置 visibleReplies

这是一个容易被配置层级误导的地方。

下面这个键是所有 group/channel 的全局策略：

{
  messages: {
    groupChat: {
      visibleReplies: "message_tool"
    }
  }
}

它不是某个 Feishu group 的配置。

直觉上，人们可能尝试：

{
  channels: {
    feishu: {
      groups: {
        "oc_example": {
          requireMention: false,
          visibleReplies: "message_tool" // 当前版本不支持
        }
      }
    }
  }
}

但在 2026.6.10 的 Feishu group schema 中，并没有 visibleReplies 字段。无论检查 OpenClaw 仓库内的 Feishu extension schema，还是已安装 Lark 插件的 group schema，这个字段都不存在。

更关键的是，核心 source-reply-delivery-mode resolver 只读取：

messages.groupChat.visibleReplies
messages.visibleReplies

它没有从 channels.feishu.groups.<chat_id> 读取覆盖值。因此，即使某个宽松 parser 暂时没有报错，单纯把字段塞进 group 配置也不会自动接入核心投递决策。

所以，下面这个目标在当前受支持的 JSON 配置中无法表达：

默认所有群为 automatic，仅指定 4 个无需 @ 的飞书群为 message_tool。

真正实现按群覆盖，需要改什么

至少需要两部分改动：

1. 在 Feishu group schema/type 中增加 visibleReplies；
2. 在消息进入核心 reply runner 前，把匹配到的 group override 传给投递模式 resolver，并定义清晰的优先级。

一个合理的未来优先级可以是：

Feishu 单群 visibleReplies
  > messages.groupChat.visibleReplies
  > messages.visibleReplies
  > harness/channel 默认值

在官方支持前，可选方案只有：

• 接受 group/channel 全局统一策略；
• 为特殊群使用独立 OpenClaw 实例或独立配置 profile；
• 修改插件/核心代码，正式增加 per-group override；
• 重新设计触发方式，不把“无需 @”与“必须 message tool 投递”绑定在一起。

不要依赖未被 schema 与 resolver 同时支持的“幽灵配置”。

---

十一、三套常见配置及其真实含义

方案 A：普通群聊，克制地显示 typing，自动发 final

{
  messages: {
    groupChat: {
      visibleReplies: "automatic"
    }
  }
}

不显式设置 typingMode 时：

• 私聊或群内明确 @：默认 instant；
• 未 @ 但能触发的群消息：默认 message；
• 普通 final 自动发回。

这是最接近传统聊天机器人的策略。

方案 B：所有群都由 Agent 显式决定是否与如何发送

{
  messages: {
    groupChat: {
      visibleReplies: "message_tool"
    }
  }
}

不显式设置 typingMode 时：

• 所有进入该模式的普通群聊 run 默认 instant；
• 普通 final 不公开；
• 必须调用 message(action="send") 才会出现可见回复；
• 不调用工具就是沉默；
• 该策略影响所有 group/channel，不只 Feishu 的几个群。

方案 C：所有群使用 message tool，但明确压低 typing 噪声

{
  agents: {
    defaults: {
      typingMode: "message"
    }
  },
  messages: {
    groupChat: {
      visibleReplies: "message_tool"
    }
  }
}

这会覆盖 message-tool-only 的动态 instant 默认值。

但它有一个副作用：如果 Agent 直接调用 message 工具，没有先产生普通可渲染文本，typing 可能完全不出现。因此它不是“延迟一点再显示”的完美折中，而是另一套触发语义。

若目标是“固定等待 1 秒再显示 typing”，当前 typingMode 与 typingIntervalSeconds 都不表达这个含义，需要增加真正的 start-delay 配置或修改 controller。

---

十二、排障清单：看到 typing 但没回复时查什么

建议按链路顺序检查，而不是先怀疑模型。

1. 查看实际投递配置

openclaw config get messages.groupChat.visibleReplies
openclaw config get messages.visibleReplies

2. 查看显式 typing 配置

openclaw config get session.typingMode
openclaw config get agents.defaults.typingMode

某个路径不存在，通常只代表“未显式设置，使用动态默认值”，不等于配置损坏。

3. 校验 schema

openclaw config validate

如果把 visibleReplies 写进 Feishu 单群配置，当前 OpenClaw 生成的严格 schema 会把它视为未知字段。即使换用较宽松、会丢弃未知键的 parser，核心 resolver 也不会读取这个位置，因此不能把“校验没报错”当成“配置已生效”。

4. 查本次 run 的实际模式

日志中重点关注：

• sourceReplyDeliveryMode 是否为 message_tool_only；
• 本次是否真正调用了 message 工具；
• 是否记录了 didSendViaMessagingTool 一类状态；
• Feishu reaction 创建或删除是否失败；
• reply dispatcher 是否正常进入 idle/cleanup。

5. 区分四种“无回复”

现象	更可能的原因
完全没有 typing，也没有 run	群准入、sender allowlist 或 mention gate 拦截
出现 typing，随后消失，无消息	Agent 主动沉默；或 message-tool-only 下漏调 message 工具
有 final 日志，群里无消息	普通 final 被 message-tool-only 保留为私有结果
消息正常发出，但 typing 残留	Feishu reaction 删除失败或 cleanup 异常

这四类问题的修复方向完全不同。

---

十三、配置设计建议

1. 先决定“谁负责投递”，再决定 typing UX

不要为了获得更快的 typing 效果而顺手切换到 message_tool。它改变的不只是 UI 提示，而是整个最终回复投递契约。

如果只想更早显示 typing，直接显式配置：

{
  agents: {
    defaults: {
      typingMode: "instant"
    }
  }
}

比改变 visibleReplies 更符合目标。

2. 无需 @ 的群要特别评估 instant typing

在高流量群里，requireMention: false 与默认 instant typing 组合后，机器人可能对大量最终不回复的消息显示短暂 Typing reaction。

先明确 Agent 的角色：

• 如果它应当“每条都响应”，instant 很自然；
• 如果它是“选择性参与”，automatic + 动态 message typing 往往更安静；
• 如果它必须用 message tool 编排输出，则要接受 instant 的提示噪声，或显式选择其他 typingMode。

3. 不要用 visibleReplies 做成本控制

它是 delivery policy，不是 admission policy。成本控制应放在准入与触发层。

4. 将全局配置与群级配置能力分开评估

messages.groupChat.visibleReplies 名字里有 groupChat，但这里的 group 是会话类别，不是某个 group ID。

看到一个需求包含“只有这几个群”时，应先检查 channel plugin 的 per-group schema，再判断能否配置，不要根据路径名称猜测。

5. 版本升级后重新核对 schema 与 resolver

如果未来 Feishu group schema 增加 visibleReplies，还要继续确认核心 resolver 是否读取并应用它。只有“schema 接受”与“运行时消费”同时成立，配置才真正有效。

---

十四、结论

理解 OpenClaw 群聊回复链路，只需要持续问三个问题：

1. 这条消息会不会触发 Agent？
   由 groupPolicy、allowlist、requireMention 等决定。

2. Agent 运行到何时显示 typing？
   由显式 typingMode 决定；未显式配置时，再根据私聊/群聊、是否被 @、是否 message-tool-only 动态计算。

3. 最终可见消息由谁发送？
   automatic 由来源投递器自动发送普通 final；message_tool 要求 Agent 显式调用 message(action="send")，普通 final 保持私有。

二者最重要的关联只有一句话：

未显式配置 typingMode 时，message-tool-only 会把普通群聊的默认 typingMode 提升为 instant。

但这并不意味着它们是同一项配置，也不意味着 message-tool-only 会减少 run、节省 token 或保证最终回复。

最后，基于 OpenClaw 与 Feishu 插件 2026.6.10 的实现：

messages.groupChat.visibleReplies 是 group/channel 级全局策略；Feishu 单群 schema 尚不支持 visibleReplies，因此不能只靠当前 JSON 配置实现“默认 automatic，仅指定几个群 message_tool”。

这条边界，往往比具体该填哪个枚举值更重要。

---

源码索引

本文涉及的主要 OpenClaw 源码位置：

• src/auto-reply/reply/typing-mode.ts
• src/auto-reply/reply/typing.ts
• src/auto-reply/reply/get-reply-run.ts
• src/auto-reply/reply/source-reply-delivery-mode.ts
• src/auto-reply/reply/agent-runner.ts
• src/auto-reply/reply/agent-runner-execution.ts
• src/agents/system-prompt.ts
• src/agents/tools/message-tool.ts
• src/config/types.messages.ts
• src/config/zod-schema.core.ts
• src/config/zod-schema.session.ts
• src/config/zod-schema.agent-defaults.ts
• extensions/feishu/src/config-schema.ts

Lark/Feishu 插件相关位置：

• src/core/config-schema.js
• src/messaging/outbound/typing.js
• src/card/reply-dispatcher.js