OpenClaw

项目简介

OpenClaw 通过 Gateway 连接聊天渠道、Agent 与工具，将不同账号和对话中的消息路由到对应助手，管理会话上下文，并把执行结果返回指定渠道或线程。

如何写进简历

面试题与回答

1. 多渠道多 Agent 系统如何设计消息路由，OpenClaw 的匹配优先级是什么？

   展开收起

   核心回答

   多渠道多 Agent 系统需要分开解决三件事：谁处理、使用哪段会话、回复发到哪里。渠道适配器先提供渠道、接入账号、聊天对象、组织和线程等身份信息；路由层按确定的优先级选 Agent；会话层生成上下文标识；投递层保留回复的渠道、账号、目标和线程。入口身份应来自可信的渠道上下文，不能让模型生成的参数决定用户身份。

   OpenClaw 使用 TypeScript 和 Node.js 构建 Gateway，连接消息渠道与 Agent 执行层。普通入站路由由配置规则决定，选出一个 Agent，再确定其工作区和会话。它的匹配顺序是：精确聊天对象 → 父聊天对象 → 聊天对象通配 → Guild 与角色 → Guild → Team → 账号 → 渠道 → 可确定的兜底 Agent。同一级按配置顺序选第一个满足条件的规则。

   这类规则路由与按问题内容选择专家可以同时存在：渠道绑定先确定负责这段对话的 Agent，选中的 Agent 内部再决定是否委派任务。普通渠道路由本身不要求模型判断，也不意味着把消息广播给所有 Agent。

   实际匹配优先级

   解析前先规范化渠道名和 accountId，只取当前渠道、当前账号及账号通配规则作为候选。这里的账号是接入平台的机器人或账号实例，发送消息的人则属于聊天对象身份，两者不能混用。

   当前共享路由解析器按以下顺序检查：

   1. 精确聊天对象：匹配 peer.kind 与 peer.id，例如指定某个私聊用户、群或频道。
   2. 父聊天对象：当前对象未命中时，使用渠道提供的 parentPeer 查找绑定，让线程可以继承父频道的 Agent。
   3. 聊天对象通配：匹配指定对象类型的 peer.id: "*"，例如该账号下所有私聊。
   4. Guild 与角色：匹配 guildId，并要求发送者的角色 ID 与配置的 roles 至少有一个相同，常用于 Discord。
   5. Guild：匹配所在服务器的 guildId。
   6. Team：匹配 teamId，例如 Slack 工作区。
   7. 账号：当前渠道下的具体 accountId 绑定。
   8. 渠道：该渠道中 accountId: "*" 的绑定，覆盖任意账号。
   9. 兜底 Agent：使用调用方明确给出的所属 Agent，或配置中可以唯一确定的所属 Agent；多 Agent 场景无法确定时，需要补绑定或指定 Agent，不会任取名册第一项。

   优先级先于配置顺序，配置顺序解决同级冲突。 一个精确对象规则即使排在账号规则后面，也仍先检查；两个同级规则都能命中时，则由先出现的规则获胜，而不是按字段数量临时计算“更具体”。

   复合条件仍然全部有效。绑定同时写了 peer、guildId、teamId 或 roles，不能只满足其中一个就命中；父对象继承阶段也继续检查组织与角色条件。角色匹配使用平台提供的角色 ID，不是看到消息里提到某个角色就转发。

   还有一个容易配错的地方：省略 accountId 表示默认账号，显式写 "*" 才覆盖任意账号。入站账号和配置账号使用同一套归一化规则，例如 " WORK " 会按 work 参与匹配。

   Session key 决定上下文范围

   选定 Agent 后，还要确定消息进入哪段历史。SessionKey 用于持久化上下文和控制会话并发，不能简单固定为“渠道加用户”。OpenClaw 的私聊作用域由 session.dmScope 或命中绑定中的覆盖配置决定：

   • main：默认值，进入该 Agent 的主会话，形如 agent:<agentId>:main。
   • per-peer：按聊天对象区分，可跨渠道共享同一对象的会话。
   • per-channel-peer：按渠道与聊天对象区分。
   • per-account-channel-peer：进一步包含接入账号，适合同一渠道存在多个账号的情况。

   session.identityLinks 可以把已配置的跨渠道身份映射为统一对象标识，在非 main 的私聊模式中参与生成会话标识。是否最终合并，还取决于所选作用域是否继续包含渠道与账号；它不是自动识别人，也不是授权机制。

   群或频道默认使用 per-group 范围，线程或话题由渠道继续补充标识；配置也可以将选定群组并入主会话。因此私聊默认并不按用户隔离，多人接入时需要明确选择合适的范围。会话划分解决上下文共享问题，入口授权和工具执行权限还要分别控制。

   路由目标与回复投递目标分开

   agentId 和 SessionKey 决定在哪里执行、读写哪段上下文；回复的 channel、accountId、to 和 threadId 决定发给谁。同一个主会话可能承接多个渠道的输入，但本轮回复仍应使用对应来源的投递坐标，不能从共享主会话推导出唯一收件人。

   OpenClaw 会结合当前 OriginatingChannel、OriginatingTo、账号和线程解析回复路由；内部事件或符合条件的 sessions_send 交接可以继承已保存的外部投递信息。普通交互不能任意借用旧的外部目标，当前显式路线与已保存路线不同，也不应继承旧房间的描述信息。选中 Agent、获得执行准入、生成回复和确认投递，是不同阶段。

   用冲突场景验证路由

   例如在同一个 Discord 账号 work 下，分别配置：频道 C17 交给 reviewer，服务器 G1 交给 support，整个账号兜底交给 general。

   • G1 中来自 C17 的消息命中精确对象，交给 reviewer。
   • C17 的子线程没有自己的绑定时，渠道提供父对象信息，可继承 reviewer；线程自身有精确绑定时，精确绑定优先。
   • G1 的其他频道交给 support，其他服务器中未命中的消息再落到账号规则。
   • 另一账号的消息不能误用仅属于 work 的规则；两条同级规则重叠时，应检查配置顺序。

   还应覆盖跨账号相同聊天对象、角色不符、私聊作用域切换，以及当前回复来源与历史投递路线不同的情况。检查路由结果中的 matchedBy、agentId 和 SessionKey，再单独核对投递坐标，可以区分“选错 Agent”和“回复发错地方”。

2. 同一工具如何按场景控制权限，OpenClaw 的工具策略管道如何分层？

   展开收起

   核心回答

   同一工具的权限应由可信的身份和场景决定：先限制这次任务允许使用哪些工具，再在执行时检查具体参数、资源和调用者权限。 模型可以提出调用，但不能通过填写“我是管理员”给自己授权。

   OpenClaw 把工具策略分成基础工具集、全局与 Agent 配置、渠道会话与发送者、沙箱与子 Agent 等层，逐层过滤候选工具。普通策略中 deny 优先，各层允许范围共同约束结果；后层写了 allow，不会恢复前层已经移除的工具。owner 权限还会作用于当轮执行，模型看见工具定义，不等于本轮能够调用。

   例如，本地开发者可以用 exec 调试，群聊助手则可通过群组策略禁止 exec、process 以及文件修改工具。这里解决的是工具准入；命令在哪运行、能写哪些目录，以及业务接口能操作哪个对象，仍分别由执行环境和具体工具检查。

   工具策略管道怎样分层？

   固定版本的 buildDefaultToolPolicyPipelineSteps() 按以下顺序使用已经解析好的策略：

   1. 基础工具集：profilePolicy、providerProfilePolicy，分别对应通用和模型供应方的工具 profile。
   2. 全局与 Agent：globalPolicy、globalProviderPolicy、agentPolicy、agentProviderPolicy。
   3. 当前会话与发送者：groupPolicy、senderPolicy。同一个 Agent 在不同群组、不同发送者的请求下，可以得到不同工具范围。

   会话管道随后追加 sandboxPolicy、subagentPolicy、按需要纳入的 runtimeToolPolicy，以及 inheritedToolPolicy。未配置的层跳过；已配置的层继续收窄当前候选。沙箱层只在相应沙箱场景生效，子 Agent 层与继承限制也不是每次普通聊天都凭空产生。默认层次、会话附加层。

   applyToolPolicyPipeline() 保存当前工具数组，每经过一层，就对上层结果执行 filterToolsByPolicy()。匹配器先检查拒绝规则，再检查允许规则，支持工具组和通配模式。alsoAllow 是向相应层已有允许集合补充条目，不是跨层的授权通行证。逐层过滤、名称匹配。

   渠道、插件与子 Agent 各影响什么？

   渠道策略约束请求所处的对话。 群组、账号与发送者信息应由宿主解析，不能信任模型自报的身份。当前实现通过请求者策略解析群组和发送者范围；子 Agent 还会携带持久化的继承限制，不能换一个会话就丢掉来源约束。请求者策略解析。

   插件扩展工具来源，不自动扩大权限。 管道按插件元数据把插件 ID、group:plugins 展开成具体工具名，再应用策略。已加载插件的工具仍可能被全局、发送者或沙箱层排除；配置了 MCP 服务，也不代表当前沙箱会话可以调用它。插件工具组展开。

   子 Agent 另受子任务限制与继承范围约束。 例如控制平面、直接跨会话投递等工具存在额外限制。显式的跨 Agent 工具委派是运维配置授予的能力，不能由模型在 sessions_spawn 参数里自行声明；普通 allow 也不能消除其它来源的拒绝。子 Agent 工具策略。

   owner 权限为什么不能只靠隐藏工具？

   这个版本会区分提供给模型的工具定义与当轮真正可调用的工具。resolveTurnToolSurface() 对未获 owner 权限或超出当轮请求者权限的工具，保留定义并包装执行入口；调用会被拒绝，同时从本轮 callableTools 和后代继承的 exportedTools 中排除。这既保持会话工具前缀稳定，也避免把“定义仍在”当成有效授权。具体工具仍可以拥有动作级和对象级检查。当轮工具权限处理。

   工具策略能保证什么，不能替代什么？

   工具策略回答“允许调用哪个工具”，沙箱回答“工具在哪里运行、能接触什么”。允许 exec 后，即使拒绝 write、edit，命令仍可能修改文件，因此不能据此宣称整个 Agent 只读。elevated 也不增加工具集合，不能绕过已经拒绝的 exec。

   对同一个被允许的工具，执行层仍应依据真实身份检查目标、参数和当前状态。例如允许调用发消息工具，不等于可以向任意群组投递；允许执行命令，也不等于获得所有主机或目录的访问权。实际系统需要把工具准入、具体动作授权与执行隔离分别落实。沙箱、工具策略与 elevated 的区别。

3. Agent 插件系统如何设计，OpenClaw 的插件 API 提供哪些扩展契约？

   展开收起

   核心回答

   Agent 插件系统需要把能力声明、加载策略、运行时注册和资源生命周期分开：宿主定义渠道、工具和事件的接口，插件提供实现，再由配置选择启用哪些提供者。注册表保存能力及所属插件，宿主统一负责调用、诊断和卸载，避免每增加一种能力就修改主循环。

   OpenClaw 使用 openclaw.plugin.json 声明身份、配置结构和能力，再向插件的同步 register(api) 入口注入 OpenClawPluginApi。插件通过 registerTool、registerChannel、api.on(...) 和 registerService 等契约贡献行为；宿主将它们登记为可调用的运行时能力。

   设计时还应明确接口版本、同名冲突、调用上下文、失败处理和资源释放。清单合法与注册成功只代表接入满足契约，不意味着第三方代码已获得进程隔离或业务操作授权。

   清单、配置与加载怎样配合

   该版先发现插件根目录并读取清单与包元数据，检查路径安全，再依据 plugins.enabled、allow、deny、entries、槽位和激活条件决定加载范围。清单中的 configSchema 用于校验该插件的配置，静态能力声明允许宿主在不导入运行时代码时完成发现和归属判断。

   选中的运行时模块才进入加载与注册。例如工具须出现在 contracts.tools 中，registerTool 会核对运行时工具名称与声明；导出身份与清单身份不一致也会产生加载错误。这样能区分“目录里存在一个包”“配置允许它参与”和“其运行时能力已注册”三个状态。

   register(api) 必须同步完成注册，该版会拒绝返回 Promise 的注册函数。需要连接外部系统或执行长期后台任务时，应先登记服务，把异步工作交给服务的启动阶段；不能在注册结束后继续补注册。

   主要扩展契约是什么

   • 工具：api.registerTool(...) 接受工具对象或按上下文创建工具的工厂，定义名称、描述、参数和执行结果。工具进入模型可见集合后，实际调用仍受宿主工具策略和执行层约束；参数结构也不能替代业务字段与权限校验。
   • 渠道：api.registerChannel(...) 提交渠道插件，配置适配器负责账号解析，按能力提供认证、收发、状态、线程或消息转换等适配器。渠道的运行和投递通过统一接口接入 Gateway，而不把平台细节散布到 Agent 主循环里。
   • 事件 Hook：api.on("before_tool_call", ...)、api.on("agent_end", ...) 等注册有类型的执行阶段回调，参数与返回值由具体事件契约决定。api.registerHook(...) 则属于内部事件 Hook 路径，两者不能按名称互换；将 before_tool_call 注册到后一条路径并不会获得同样的调用。
   • 后台服务与清理：api.registerService(...) 提供 id、start 与可选 stop，由宿主安排服务运行和停止。受宿主管理的插件实例还可通过 api.lifecycle 接入取消信号、销毁回调与 registerRuntimeLifecycle，把插件持有的后台工作和状态纳入清理。

   插件还可以扩展模型提供者、HTTP 路由、CLI 命令等，但每个扩展点都要使用对应的身份、输入输出与所有权契约，而不是拿到一个宿主内部对象后任意修改共享状态。

   在多渠道故障工单平台的场景化接入中，可将查询与进度记录做成两个插件工具：前者接收工单号，后者再接收进度文本；渠道、账号与线程由宿主上下文传入，返回工单号、办理状态与回执，供来源会话答复。写入超时应先保留“待确认”状态并查询工单结果，再决定是否重试，避免把网络超时当作未写入。工单接口及这项处置属于业务适配设计，不是 OpenClaw 已内置工单系统或业务幂等。

   怎样处理兼容、失败和卸载

   兼容性需要固定宿主与 SDK 版本，核对包声明及实际使用的 API，并验证发现、注册、调用、停用这条完整路径。该版 OpenClawPluginApi 仍标为实验性接口，不能仅因为 TypeScript 类型检查通过，就认为后续宿主升级一定兼容。

   加载或注册抛错时，宿主记录插件归属与失败阶段，并回收已登记的宿主侧贡献；插件停用时，也要停止连接、定时任务和事件订阅，避免旧实例继续处理请求。对状态变更类 Hook 和纯观测 Hook，应分别定义失败后停止还是继续，不能把所有异常统一吞掉。

   原生插件在宿主进程中运行。清单校验、配置允许名单和注册回收有助于管理能力，但不能撤销插件代码任意产生的文件或网络副作用。若设计要求运行不可信代码，需要额外的进程、容器或远程服务边界，不能把内存注册表当成安全沙箱。