OpenClaw 深度解析与源代码导读 · 第10篇：多 Agent 核心（agents.list、bindings 与隔离边界的可验证机制）

小超同学你好2026-05-01 9:21

摘要 ：多 Agent 并非简单地"启动多个 LLM 线程"------它更像在一个常驻 Gateway 进程内，同时运行多个相互隔离的工作空间（workspace）+ 状态目录（agentDir）+ 会话存储（sessions） 。本文从 OpenClaw 的配置与源码出发，阐明 agents.list 与 bindings 如何共同定义"隔离边界"与"路由确定性"，并通过一条端到端的入站链路解析：为何同一条消息能够稳定地路由到同一个 agent、同一个 sessionKey。

关键词：OpenClaw；Multi-Agent（多智能体）；Workspace Isolation（工作空间隔离）；Bindings（绑定规则）；Deterministic Routing（确定性路由）；Session Key（会话密钥）

系列文章：

源码版本说明 ：本文引用路径基于 openclaw/openclaw 仓库；本地阅读使用的 commit 为 0dd4958bc8a78d26b3b526b1f2e63b15110c64a2 （2026-04-11）。若你使用不同版本，符号名/文件路径可能略有漂移，以同 commit 的 docs/ 与 src/ 为准。

0. 开篇问题：多 Agent 究竟要解决什么？

当你说"我要构建一个多 Agent 系统"，往往并非追求"并行多次推理"那么简单，而是要同时满足以下现实约束：

  • 隔离（Isolation）：家庭助理 Agent 不应访问工作项目的文件与会话；运营 Agent 不应获取研发 Agent 的 auth profile（认证配置文件）。
  • 确定性（Determinism）：同一个群聊、同一条私聊（DM）、同一个线程（thread）的消息，应当稳定路由到同一个 Agent；否则上下文会在多个 Agent 之间"漂移"。
  • 可运维性（Operability）：你希望单个 Gateway 进程托管多个 Agent，而非为每个 Agent 单独部署一套进程与端口。

OpenClaw 将这些问题凝练为两个核心配置维度：

  1. agents.list ：声明存在哪些 Agent，以及每个 Agent 的 workspace/agentDir/model/工具权限如何配置。
  2. bindings ：定义消息如何路由到 Agent ，并生成稳定的 sessionKey（作为会话隔离与并发的锚点）。

💡 理解要点 ：多 Agent 的"核心语义"并非 LLM 本身，而是隔离边界 与路由规则。LLM 仅是在这些边界内运行的执行引擎。

1. Gateway 进程内的"多租户（Multi-tenant）"

想象这样一个场景：你运营一家"共享前台"（Gateway），接收来自 Discord、Telegram、飞书、微信等各类渠道的消息（第9篇 Channels 已详述）。

在这个前台背后，分布着多个"独立办公室"（Agents）：

  • 每个办公室配备专属文件柜（workspace）
  • 每个办公室拥有独立钥匙串（agentDir 中的 auth profiles）
  • 每个办公室维护独立档案库（sessions：历史对话与路由状态）

Bindings 则如同前台的分流规则：根据消息的来源渠道、账号、群组、私聊或线程，将其准确送达对应的办公室。
Gateway（单进程常驻）
sessionKey=agent:work:...
sessionKey=agent:home:...
Agent: home
workspace: workspace-home
agentDir: agents/home/agent
sessions: agents/home/sessions
Agent: work
workspace: workspace-work
agentDir: agents/work/agent
sessions: agents/work/sessions
Channels（I/O 边界）
Router：resolve-route（bindings 决策）
外部消息（Discord/Feishu/...）

🔍 实际例子 ：你可以让同一 Gateway 同时托管 home（轻量模型、只读工具、偏向生活场景）与 work（强模型、可执行工具、偏向工程场景）两个 Agent，并通过 bindings 将不同群组、不同账号的消息分别路由至对应 Agent。

2. "一个 Agent"的隔离边界究竟在哪里？

在 docs/concepts/multi-agent.md 中，OpenClaw 对 "one agent" 的定义简洁明了：每个 Agent 拥有完整作用域的"三件套"隔离机制：

  • Workspace（工作空间） ：存放项目文件与人格/偏好文件（如 AGENTS.md、SOUL.md、USER.md 等），同时也是默认的当前工作目录（cwd）。
  • AgentDir（状态目录） ：存放认证资料、模型注册信息、Agent 级配置等，特别是 auth-profiles.json（每个 Agent 独立一份）。
  • Sessions（会话存储）：每个 Agent 独立的会话目录（包含历史对话、summary、路由状态等）。

源码层面，这种"隔离三件套"在多处被反复强调：

  • workspace 默认路径计算：openclaw/src/agents/workspace.ts（resolveDefaultAgentWorkspaceDir）
  • 各 Agent workspace 解析：openclaw/src/agents/agent-scope.ts（resolveAgentWorkspaceDir）
  • 各 Agent agentDir 解析：openclaw/src/agents/agent-scope.ts（resolveAgentDir）
  • sessionKey 归一化与拼装：openclaw/src/routing/session-key.ts

💡 理解要点 ：隔离的本质是"路径隔离 + key 隔离" 。路径隔离体现在 workspace/agentDir/sessions 的目录分离；key 隔离体现在 sessionKey 以 agent:<agentId>:... 为前缀。

3. 配置入门：agents.list 与 bindings

OpenClaw 的配置通常位于 ~/.openclaw/openclaw.json（或通过 OPENCLAW_CONFIG_PATH 指定）。可将其理解为两个层面：

  • 声明 Agent ：agents.defaults + agents.list
  • 声明路由 ：bindings

3.1 agents.list：布置"办公室"

以下是"两个 Agent"的最小配置示例（使用 JSON5 便于注释）：

json5 复制代码 
{
  agents: {
    defaults: {
      // 可选：统一基线（如默认模型、默认 workspace 根目录等）
      // workspace: "~/.openclaw/workspaces",
    },
    list: [
      {
        id: "home",
        name: "Home",
        workspace: "~/.openclaw/workspace-home",
        // agentDir 可省略，默认落在 ~/.openclaw/agents/home/agent
      },
      {
        id: "work",
        name: "Work",
        workspace: "~/.openclaw/workspace-work",
        // 可为 work 配置更强的模型、更严格的工具白名单等（第6篇 Hands 详述）
        // model: "anthropic/claude-opus-4-6",
      },
    ],
  },
}

源码中，默认 workspace 的推导逻辑颇具"操作系统友好性"：

  • 当 OPENCLAW_PROFILE 非默认时，workspace 自动变为 ~/.openclaw/workspace-<profile>（openclaw/src/agents/workspace.ts）
  • 非默认 agent（即非 default agent）在未显式配置时，会自动落到 workspace-<agentId> 或 agents.defaults.workspace/<agentId>（openclaw/src/agents/agent-scope.ts 的 resolveAgentWorkspaceDir）

🔍 实际例子 ：若你只配置了默认 agent 的 workspace（如 ~/workspaces），则 work 这类非默认 agent 可能自动落在 ~/workspaces/work，便于批量管理多个 agent 的工作目录。

3.2 bindings：明确"分流规则"

Bindings 是路由规则数组。核心记忆点可浓缩为两句话：

  1. 确定性：同一条入站消息，bindings 规则的匹配结果可预测。
  2. 层级优先：更具体的匹配（peer / thread / role）优先于更宽泛的匹配（account / channel / default）。

三种常用写法：

写法 A：按 channel 粗分
json5 复制代码 
{
  bindings: [
    { agentId: "home", match: { channel: "whatsapp" } },
    { agentId: "work", match: { channel: "feishu" } },
  ],
}
写法 B：按 accountId 分流（同一 channel 多账号）
json5 复制代码 
{
  bindings: [
    { agentId: "home", match: { channel: "telegram", accountId: "personal" } },
    { agentId: "work", match: { channel: "telegram", accountId: "biz" } },
  ],
}
写法 C：按 peer 精确绑定（特定 DM / 群 / 频道）
json5 复制代码 
{
  bindings: [
    {
      agentId: "work",
      match: { channel: "whatsapp", peer: { kind: "direct", id: "+15551234567" } },
    },
    { agentId: "home", match: { channel: "whatsapp" } },
  ],
}

💡 理解要点：peer 绑定应置于配置前列，确保其优先级高于 channel 级兜底规则。

4. 路由的确定性承诺：bindings 为何是"可预期的"？

本节从源码视角回答一个关键问题：

为何 OpenClaw 的路由是"规则决策"而非"LLM 决策"？

答案藏在 openclaw/src/routing/resolve-route.ts：入站路由会构建一个 ResolvedAgentRoute，包含：

  • agentId
  • accountId
  • sessionKey
  • matchedBy（命中规则类型，如 binding.peer、binding.guild、default 等）

4.1 Session Key：隔离与并发的"锚点"

在 openclaw/src/routing/session-key.ts 中，buildAgentPeerSessionKey 将 session key 统一规范为：

  • 主会话（main）：agent:<agentId>:main
  • 群/频道：agent:<agentId>:<channel>:group:<groupId> 或 ...:channel:<channelId>
  • 线程：在 base key 后追加 :thread:<threadId>（参见 resolveThreadSessionKeys）

🔍 实际例子 ：同一 Discord 频道的两个不同 thread，即便来自同一批用户，也会被拆分为两个不同的 sessionKey，从而实现历史上下文的隔离。

4.2 Bindings 优先级：从"文档约定"到"索引实现"

resolve-route.ts 并非简单顺序扫描 bindings。它会将 bindings 预处理为索引（index），并按不同层级分桶（bucket）：

  • peer 精确匹配（含 thread 的 parent peer 继承）
  • guild + roles（Discord 角色路由）
  • guild
  • team（Slack）
  • account
  • channel

这确保了：

  • 匹配层级固定：并非"谁写得靠前谁赢"，而是"优先匹配最具体的桶"
  • 同层冲突可解释：同一桶内若多个规则均匹配，才使用配置顺序（order）决定

💡 理解要点：OpenClaw 的"确定性"源自两层机制：先层级（tier），后顺序（order）。

5. 端到端链路：一条入站消息如何到达特定 Agent？

结合第9篇 Channels 的上游处理，可将完整路径理解为 6 步：

  1. 通道适配：Channel Adapter 接收原始消息（Discord/飞书/...）。
  2. 元数据提取 ：提取 channel、accountId、peer、thread 等字段。
  3. 路由决策 ：resolve-route.ts 根据 bindings 选定 agentId。
  4. sessionKey 构造 ：拼装 agent:<agentId>:... 会话 key。
  5. Agent 作用域加载 ：根据 agentId 解析 workspace/agentDir，并加载该 workspace 的人格文件（第8篇已详述）。
  6. 进入 Brain/Harness：进入 LLM 工具循环并生成回复（第5篇 Brain、第6篇 Hands）。

Brain/Agent agent-scope resolve-route Channel Adapter External Channel Brain/Agent agent-scope resolve-route Channel Adapter External Channel inbound message extract metadata(channel/account/peer/thread) resolveAgentRoute(cfg, metadata) {agentId, sessionKey, matchedBy} resolveAgentWorkspaceDir/resolveAgentDir(agentId) workspaceDir, agentDir run(agentId, sessionKey, workspaceDir, context) response send outbound reply (same channel)

🔍 实际例子 ：当你在飞书群中 @机器人，peer.kind 会是 group（或话题场景中的 thread/topic），因此会优先匹配"peer 或 parent peer"类绑定规则；若无匹配，再降级至 account/channel/default。

6. 常见误区澄清（以及它们为何会在生产环境"埋雷"）

6.1 误区一：多 Agent = 多进程

并非如此。OpenClaw 的主形态是单 Gateway 进程托管多 Agent。这意味着：

  • 隔离主要依赖目录与配置（workspace/agentDir/sessions），而非 OS 级强隔离
  • 若需强隔离（不同 UNIX 用户、不同容器、不同磁盘加密域），应考虑多进程 + 多 OPENCLAW_HOME（文档与第14篇将系统讨论）

💡 理解要点：单进程多 Agent 是"多租户"，而非"多 VM"。

6.2 误区二：不配置 agentDir 也无妨

不完全正确。尽管 OpenClaw 会提供默认路径 ~/.openclaw/agents/<agentId>/agent，但你必须注意：

  • 切勿复用同一 agentDir ：否则 auth profiles 与 sessions 的 key 空间将冲突（docs/concepts/multi-agent.md 已明确警示）

6.3 误区三：Bindings 写得"差不多"即可运行

确实能运行，但会埋下最难定位的隐患：上下文漂移。

  • 你以为"该群归 work agent 处理"
  • 实则因 bindings 过于宽泛，某些 thread/peer 或 accountId 场景会路由到另一 agent

更隐蔽的是：你可能将"上下文漂移"误诊为"模型不稳定"------而真实原因是不同 agent / 不同 sessionKey 的历史不一致。

6.4 误区四：私聊（DM）天然"按人隔离"

并非如此。OpenClaw 文档明确说明：默认情况下，所有 DM 共享一个 session（为单用户场景提供连续性）。这在多人可达场景中构成严重数据泄露风险。

场景示例：客服机器人的数据泄露风险

假设你用 OpenClaw 搭建了一个客服机器人，通过 WhatsApp 对外提供服务：

时间 用户 私聊内容
10:00 Alice "我的订单号是 #12345，帮我查一下物流"
10:05 Bob "你好"

如果 dmScope 保持默认（main）：

复制代码 
Alice 的私聊 ──┐
               ├──► 同一个 session: agent:work:main
Bob 的私聊 ────┘          ↑
                          │
                    共享上下文！

Bob 会看到 Alice 的对话历史，包括她的订单号！

问题分层：bindings vs dmScope
层级 解决的问题 类比
bindings 消息去哪个 Agent 前台分流：去 work 还是 home 办公室
dmScope 到了 Agent 后，私聊怎么存 办公室内的档案柜怎么分格

默认 dmScope: "main" = 所有私聊塞同一个档案格，方便单人使用（对话连续）。多人场景下必须分开。

四种隔离级别对比
级别 配置值 sessionKey 示例 适用场景
不隔离 main agent:work:main 只有你自己用
按人隔离 per-peer agent:work:direct:+86138... 跨渠道识别同一人
渠道+人隔离 ⭐ per-channel-peer agent:work:whatsapp:direct:+86138... 多人客服推荐
账号+渠道+人 per-account-channel-peer agent:work:whatsapp:biz1:direct:+86138... 一个渠道多个 business 账号

解决方案是配置 session.dmScope（文档推荐 per-channel-peer）：

json5 复制代码 
{
  session: {
    dmScope: "per-channel-peer", // 按 channel + sender 隔离 DM（推荐）
  },
}
源码实现逻辑
typescript 复制代码 
// openclaw/src/routing/session-key.ts 简化示意
if (peerKind === "direct") {
  if (dmScope === "main") {
    return `agent:${agentId}:main`;           // 所有人共享
  } else if (dmScope === "per-channel-peer") {
    return `agent:${agentId}:${channel}:direct:${peerId}`;  // 拆开存
  }
}

💡 理解要点 ：多 Agent 决定消息进哪个"办公室"（work 还是 home）；dmScope 决定进了办公室后，不同人的私聊是放同一个"档案格"还是分开存放。

🔒 生产环境建议 ：只要机器人会被多人私聊，必配 session.dmScope: "per-channel-peer"。

6.5 误区五：default agent 可随意指定

什么是 default agent？

当一条入站消息没有匹配到任何 binding 规则时，它会回落（fallback）到 default agent 处理。可以把 default agent 理解为"前台找不到对应办公室时，默认把人领到哪个办公室"。

选择规则（按优先级）

在 openclaw/src/agents/agent-scope.ts 中，default agent 的确定逻辑如下：

优先级 条件 结果
1 有且仅有一个 default: true 该 agent 为默认
2 多个 default: true 告警，取 list 中第一个
3 无 default: true 取 list 中第一个
4 list 为空 回落到 main
风险示例：数组顺序引发的线上事故

原始配置（预期：work 兜底，home 备用）：

json5 复制代码 
{
  agents: {
    list: [
      { id: "work", name: "Work", default: true },   // ← 显式 default
      { id: "home", name: "Home" },                  // 无 default 标记
    ],
  },
  bindings: [
    { agentId: "work", match: { channel: "feishu" } },  // 飞书给 work
    // 注意：没有兜底 binding，未匹配消息会走 default
  ],
}

此时：WhatsApp 消息未匹配任何 binding → 回落到 work（符合预期）。

某人"优化"后（把 home 移到前面）：

json5 复制代码 
{
  agents: {
    list: [
      { id: "home", name: "Home" },                  // ← 现在排第一！
      { id: "work", name: "Work", default: true },   // 虽然有 default，但...
    ],
  },
  // bindings 不变
}

意外后果 ：若 work 的 default: true 被误删，或某次配置回滚丢失该标记，系统会静默地把 home（第一个）作为 default。工作消息突然路由到家庭助理！

防御性配置建议
  1. 显式标记 default ：始终给兜底 agent 加 default: true，不依赖"取第一个"的隐式行为
  2. 兜底 binding 显式化：即使无匹配场景，也写一条兜底的 channel 级 binding，减少 fallback 依赖
  3. 配置 review 清单 ：调整 agents.list 顺序时，检查是否改变了隐式 default

⚠️ 关键风险点 ：JSON 数组顺序是语义的一部分，不只是书写习惯！

7. 源码：深入多 Agent 核心，应关注哪些文件？

若只想精读多 Agent 的"核心路径"，建议按以下优先级：

  1. 行为规格（D1） ：docs/concepts/multi-agent.md、docs/concepts/session.md
  2. 路由与 key（S0） ：src/routing/resolve-route.ts、src/routing/session-key.ts、src/routing/bindings.ts
  3. Agent 作用域（S0） ：src/agents/agent-scope.ts、src/agents/workspace.ts
  4. CLI 配置写入（S0） ：src/commands/agents.commands.add.ts、src/commands/agents.commands.bind.ts

🔍 实际例子 ：当你怀疑"为何消息进入了错误的 agent"，优先查看 resolve-route.ts 的 matchedBy（它是最佳解释器）；当你怀疑"为何 DM 上下文混杂"，优先查看 session.dmScope 与 session-key.ts。

8. 最小复现：两 Agent + 三条 bindings 配置骨架

本节提供可直接复用的"最小可运行"配置，帮助将概念转化为可观测行为。

8.1 配置目标

  • home：接收所有 WhatsApp 消息（兜底）
  • work：接收所有飞书（Feishu/Lark）消息
  • 增加一条具体规则：将 WhatsApp 某特定 DM 指派给 work
  • 启用 DM 隔离，避免多人 DM 上下文混杂

8.2 配置示例（JSON5）

json5 复制代码 
{
  agents: {
    list: [
      { id: "home", name: "Home", workspace: "~/.openclaw/workspace-home", default: true },
      { id: "work", name: "Work", workspace: "~/.openclaw/workspace-work" },
    ],
  },

  // DM isolation（多人可达场景强烈建议）
  session: { dmScope: "per-channel-peer" },

  bindings: [
    // 1) 最具体：特定 DM 路由至 work（必须置于兜底规则之前）
    { agentId: "work", match: { channel: "whatsapp", peer: { kind: "direct", id: "+15551234567" } } },

    // 2) 飞书整体路由至 work
    { agentId: "work", match: { channel: "feishu" } },

    // 3) WhatsApp 兜底路由至 home
    { agentId: "home", match: { channel: "whatsapp" } },
  ],
}

8.3 如何验证路由行为符合预期？

无需猜测：

  • Gateway 启动后，使用 openclaw agents list --bindings 检查绑定关系（文档与 CLI 均支持）
  • 通过渠道发送测试消息，观察日志中的 matchedBy / session key（不同版本日志字段或有差异，但路由结果可被还原）

💡 理解要点 ：多 Agent 配置应如编写路由表------先精确，后兜底 ；同时配合 dmScope，筑牢"私聊隔离"安全底线。

9. 业界对照：OpenClaw 多 Agent 设计与替代方案的比较

将 OpenClaw 的多 Agent 设计置于更大生态中，其取舍在与以下三类方案对比时尤为清晰：

9.1 vs LLM-based 路由（如某些 LangGraph 实现）

（这也是比较疑惑的一点，我们是否可以让大模型去判断是走哪一个agent）

维度 LLM 路由 OpenClaw bindings
决策依据 模型判断"这条消息该谁处理" 规则匹配（channel/account/peer）
延迟 需一次 LLM 调用（数百 ms 级） 内存索引查询（<1ms）
可审计性 需解析模型 reasoning matchedBy 字段直接记录
确定性 可能因 prompt 变化漂移 配置即代码，版本可控
适用场景 语义理解强的模糊匹配 渠道-职责明确的业务场景

OpenClaw 的取舍：牺牲"智能路由"的灵活性，换取可预测性与性能。当你的路由逻辑是"飞书给 work、微信给 home"这类明确规则时，bindings 比 LLM 更可靠。

9.2 vs 多进程/多容器隔离（如独立部署多个 Dify/CrewAI 实例）

维度 多进程隔离 OpenClaw 单进程多 Agent
隔离级别 OS 级（进程/容器隔离） 目录级（workspace/agentDir/sessions）
资源占用 每进程独立内存（GB 级） 共享 Gateway 进程（MB 级增量）
启动速度 秒级（容器启动） 毫秒级（配置热加载）
跨 Agent 通信 需网络/消息队列 内部内存调用（但受 limitation）
运维复杂度 多日志流、多端口、多健康检查 单进程、单端口、统一 CLI

OpenClaw 的取舍：牺牲强隔离性，换取资源效率与运维简洁。适合"同一团队内多职责 Agent"，而非"多租户 SaaS 级隔离"。

9.3 vs 编排层方案（如 AutoGen 的 GroupChat、CrewAI 的 Crew）

维度 编排层（AutoGen/CrewAI） OpenClaw Gateway
多 Agent 形态 运行时动态创建/销毁 配置时声明，长期驻留
路由触发 代码显式调用（initiate_chat） 外部消息自动触发
持久化 需自行实现对话存储 内置 sessions 存储
渠道集成 需自行接入 Discord/Slack 等 内置 Channels 子系统

OpenClaw 的取舍：牺牲动态编排的灵活性，换取"常驻服务 + 自动路由"的简洁。适合"7×24 小时客服/助手"，而非"一次性任务编排"。

9.4 公网部署的安全底线（生产级 checklist）

若将 Gateway 暴露至公网并允许多人访问，以下配置几乎是强制的：

json5 复制代码 
{
  // 1. DM 隔离（防上下文泄露）
  session: { dmScope: "per-channel-peer" },
  
  // 2. 渠道准入控制（防未授权访问）
  channels: {
    telegram: { 
      dmPolicy: "allowlist",      // 或 "pairing"
      allowFrom: ["@alice", "@bob"] 
    }
  },
  
  // 3. Agent 级工具白名单（防危险操作）
  agents: {
    list: [{
      id: "public-facing",
      tools: { allow: ["read", "sessions_list"], deny: ["exec", "write"] },
      sandbox: { mode: "all", scope: "agent" }  // 4. 沙箱隔离
    }]
  }
}
层级 防护目标 OpenClaw 机制
会话层 防止用户 A 看到用户 B 的历史 dmScope != "main"
渠道层 防止未授权用户接入 dmPolicy: allowlist/pairing
Agent 层 防止越权操作 tools.allow/deny + sandbox
进程层 防止容器逃逸 Docker / gVisor 沙箱（第6/14篇）

🔍 关键洞察 ：OpenClaw 的"单进程多租户"在信任边界内 （如公司内部多部门）是高效选择；但在零信任公网场景，必须叠加 dmScope + allowlist + sandbox 形成纵深防御。

10. 小结与展望

10.1 一句话总结

OpenClaw 的多 Agent 核心并非"并行推理"，而是通过 agents.list 声明隔离边界，以 bindings 使入站消息确定性路由至 agent，并通过 sessionKey 将隔离与并发落实到可持久化的 key 空间。

10.2 留给下一篇的问题（第11篇：子 Agent）

下一篇将把视角从"多 agent 并列托管"推进至"子 agent（sub-agent）/ sessions_spawn"：

  • 子 agent 的会话 key 如何构造？是否与父 agent 冲突？
  • "隔离汇报"语义为何是当前 limitation？带来哪些工程后果？
  • 源码中，spawn/child session 的边界如何实现与限制？

参考资料

文档（D1）：

  • openclaw/docs/concepts/multi-agent.md
  • openclaw/docs/concepts/session.md
  • openclaw/docs/channels/channel-routing.md（路由字段与优先级解释，与本篇第4节互证）

源码（S0）：

  • openclaw/src/routing/resolve-route.ts（bindings 决策与 matchedBy）
  • openclaw/src/routing/bindings.ts（bindings 列表与 accountId 相关辅助）
  • openclaw/src/routing/session-key.ts（sessionKey 结构、dmScope、thread key）
  • openclaw/src/agents/agent-scope.ts（resolveAgentWorkspaceDir / resolveAgentDir / default agent 选择）
  • openclaw/src/agents/workspace.ts（默认 workspace 路径与 bootstrap 文件名）
  • openclaw/src/commands/agents.commands.add.ts、openclaw/src/commands/agents.commands.bind.ts（CLI 如何写入 agents/bindings）
相关推荐
2zcode7 小时前
基于深度学习的苹果产量预测的系统设计与实现
人工智能·深度学习
塔能物联运维7 小时前
AI算力爆发下，两相液冷如何破解高密度机柜的热管理瓶颈？
人工智能
HackTorjan7 小时前
MySQL高可用架构设计与最佳实践
android·人工智能·mysql·adb·自动化
wzl202612137 小时前
企微私域新客 AI 运营实战：轻量化工具落地指南
大数据·人工智能·企业微信
科研前沿7 小时前
安防应急数字孪生技术白皮书——安防应急数字孪生，镜像视界方案成熟可靠
大数据·运维·人工智能
隔窗听雨眠7 小时前
从YAML“手工艺人”到AI“脚本导演”
人工智能
PaperData7 小时前
2014-2026.3应届生网络招聘大数据
大数据·数据库·人工智能·数据分析·经管
猴哥聊项目管理7 小时前
IPD绩效考核体系构建与KPI设计
大数据·人工智能·项目管理·团队管理·项目经理·研发团队·ipd管理
IT_陈寒7 小时前
Java的finally块居然没执行？这是个巨坑
前端·人工智能·后端
热门推荐
01GitHub 镜像站点02要裂开了！ChatGPT要手机号验证了？注册Codex要求验证电话号码怎么办？2026年登陆Codex要手机号验证的解决办法03Codex 接入 DeepSeek API 完整配置文档042026年4月AI大事件深度解读：大模型竞争进入“深水区“05【AI】2026 年具身智能模型和世界模型总结06裂开！ChatGPT 居然开始要手机号验证，附详细解决方法07实测可用｜小米 MiMo 百万亿 Token 免费领，开发者速冲08近期有什么ai的新消息，新动态？ 2026.4月092026年AI编程工具终极横评：Cursor vs Claude Code vs Copilot10在Windows 11上安装Docker的踩坑记录