1. 三个名字背后的真实主角模型、运行时和工具链先分清最近一周我先后把 OpenClaw、Codex CLI 和一整套基于 Hermes 模型的 Agent 环境都部署了一遍本意是想做工具对比结果越装越觉得有意思这三样东西一个来自开源社区的多面手自动化框架一个来自大厂的编程智能体一个是开源模型加社区工具拼起来的组合出身完全不同可把它们拆开看骨架居然长得几乎一样。这个观察让我把之前零散的认知串起来了——AI Agent 架构正在收敛而且收敛速度比大多数人想象的要快。这篇文章会围绕这个主题展开OpenClaw、Codex、Hermes 分别是什么它们的架构共性在哪里为什么收敛会发生在这些层以及我从真实部署和排错中总结出来的判断。适合三类人看正在选型 Agent 工具的开发者、想理解 Agent 底层架构的产品和技术负责人以及打算自己动手搭一套 Agent 但不知道从哪下手的新手。首先要做的事是把这三个名字对应的“东西”搞清楚。“从 OpenClaw、Codex 到 Hermes”这句话很容易让人误以为它们是同一类事物其实不是。它们分别代表了 Agent 生态里的不同层次而架构收敛恰恰是在这几个层次上同时发生的。1.1 OpenClaw定位是“什么都能干的个人自动化 Agent”OpenClaw 是一个开源的 AI Agent 运行时社区里也有些人按项目习惯把它和另一个同名项目混着提反正你搜的时候都能找到。它的定位非常直白给你一个可以常驻运行的 Agent 进程通过自然语言下达指令它去调用文件系统、命令行、各种 API 扩展完成自动化任务。和很多同类项目相比OpenClaw 的最大特点是“通用”——它不像某些 Agent 只盯编程任务它能接智能家居、接日历、接各类自建服务更像一个“个人数字管家”。架构上OpenClaw 的核心模块是这几块模型接入层、技能系统、扩展系统和执行审批机制。模型接入层负责对接各种模型后端默认支持 OpenAI 系、Anthropic 系、Google 系还可以配置 NVIDIA NIM 这类私有化推理服务。技能系统是给 Agent 预置的“能力清单”每个技能描述清楚自己什么时候该被调用、需要什么参数扩展系统则是连接外部世界的大门接 GitHub、接 Slack、接你自己的 REST API。执行审批机制解决的是安全问题后面我会专门展开。安装方面OpenClaw 支持 Windows 原生环境、Linux、macOS也可以 Docker 部署。社区里现在问得最多的是两个问题Windows 上怎么装以及怎么配置 NVIDIA NIM 当后端。前者主要是环境变量和路径的坑后者主要是 NIM 端点地址和模型名称的匹配。具体配置我放到后面的部署章节讲。1.2 Codex一个“编程智能体”从模型到 CLI 的完整演变Codex 这个名字在圈子里有歧义必须掰开讲。最早 OpenAI 发布过一代代码模型代号就叫 Codex当时主打“用自然语言生成代码”内部跑在 GPT 架构上。后来这个品牌基本不单独提了。但从近两年开始OpenAI 又把 Codex 这个名字捡起来用在一款“编程智能体”产品上——它不再是一个单纯的补全模型而是一个能在终端里跑命令、读文件、写代码、跑测试、甚至提 Pull Request 的 Agent。我们现在聊的架构收敛主要指的是后者也就是 Codex CLI 或者说 Codex Agent。Codex 的架构可以拆成三层前端 CLI、Agent Harness、模型 API。CLI 负责接收自然语言指令把进度渲染在终端里Harness 是整个 Agent 的“套具”这一层包含系统提示词、工具定义、任务拆解循环、上下文窗口管理、权限提示等模型 API 是大脑默认走 OpenAI 的 /responses 端点——这个端点是后来 OpenAI 主推的 Agent 交互端点和早期的 completion、chat completion 接口都不一样它直接把工具调用、上下文、状态管理设计成了协议的一部分。社区里大量讨论集中在两件事上一是怎么把 Codex CLI 接进其他模型服务比如“Codex 接入 DeepSeek”二是 Harness 层面的行为约束。你会发现官方模型当然用起来最顺但社区通过改配置、改网关也能让 Codex 的 Harness 去驱动第三方模型。这就触及了架构收敛的一个核心Agent 的骨架和大脑是分离的而且骨架已经开始标准化了。1.3 Hermes更多时候代表“Agent 化的开源模型底座”Hermes 是这三个名字里最容易让人懵的。它不像 OpenClaw 和 Codex 那样指一个明确的框架产品在社区里至少有三层含义混着用。第一层也是源头是 NousResearch 的开源模型系列。Hermes 系列模型通常是基于 Llama 或其他开源基座做指令微调特别擅长 function calling 和对话式任务执行。因为 Agent 需要模型稳定输出工具调用格式所以这类“为 Agent 优化过”的开源模型在自建 Agent 的圈子里很受欢迎。第二层含义是各种挂了 Hermes 名字的 Agent 工具或项目有的和模型本身没什么关系纯粹是借这个名字。第三层是某些工作流里把 Hermes 当成“智能体运行时”来部署配合 Docker 使用。在“deepseek hermes”这个搜索组合里我看到社区多是在讨论“用 Hermes 工具链部署 DeepSeek 模型做 Agent”。这恰好印证了我的判断Hermes 在当前 Agent 架构讨论里更多是作为“开源模型底座 配套 Agent 工具”的整体生态出现。它代表的是 Agent 收敛的另一个侧面——模型层也在收敛越来越多的开源模型主动适配工具调用标准让上层 Agent 框架可以无缝切换大脑。把这三个角色分清后你会发现一个事先没想到的事OpenClaw、Codex 和 Hermes 并不在同一个赛道竞争它们原本是三个层次——运行时工具链、编程智能体应用、开源模型底座——却在互相靠拢。靠拢的结果就是我下面要讲的几个“收敛层”。2. 收敛层一模型后端可插拔Agent 不再是单一模型的附属品如果只看一两年前的早期 Agent 项目你会觉得“Agent 就等于一个大模型加几个 Prompt”。但现在无论是 OpenClaw、Codex 还是围绕 Hermes 的 Agent 工具架构图上第一个标准模块都是“模型接入/路由层”。这个层的作用是让你可以把任何兼容模型接到同一个 Agent 骨架上想换就换。2.1 三个项目各自怎么处理模型切换OpenClaw 的做法是配置文件里声明 provider。我在本机试过最省事的路径是把 API Key 写在环境变量里然后在配置里指定默认模型。比如你想让 OpenClaw 走 NVIDIA NIM 上的自建模型核心就是三件事NIM 服务地址、模型名称要和 NIM 暴露的一致、鉴权信息。它不关心你后端到底是 OpenAI 还是 NIM只要走 OpenAI 兼容协议就行。Codex CLI 的情况稍微特殊因为它是 OpenAI 的产品默认绑定自家的 /responses 端点。但它的配置里留有 provider 相关的设置项。社区“接入 DeepSeek”的方案本质就是改掉默认的 endpoint 和 token让 Codex 的 Harness 去调用兼容的接口。我自己在这条路上踩过不少坑后面排错章节会详细讲。Hermes 系工具链本来就是开源模型生态模型切换更是家常便饭。你甚至可以在同一套工具里对话任务用一个模型、工具调用任务用另一个模型。这种“任务级路由”已经在很多 Agent 框架里成了标配这是前几年完全没预料到的变化。2.2 为什么可插拔成了架构底线这里要理解一个关键逻辑Agent 的真正资产是编排逻辑、工具链和上下文管理而不是模型本身。模型只是“大脑”这个零件而且这个零件更新快、供应商多、价格浮动大。如果你把 Agent 架构焊死在某个模型上那模型一改版、一涨价、一限流你的整个自动化体系就瘫痪了。用现实一点的话说过去我们做传统系统数据库选型是核心轻易不换但 Agent 时代的模型比数据库更“善变”所以架构上必须有一个中间层来隔离这种变化。这个中间层就是模型网关/路由层。它像一个转接头一边是 Agent 框架发出的统一工具调用协议另一边是各家模型的差异接口由它负责翻译和转发。我在调 OpenClaw 切换后端时切身感受过这个转接头的重要性。切到另一家模型后Agent 的思维链、系统提示词、工具调用全都不用动只需要改路由配置。没有这层抽象每次模型升级都等于把 Agent 重写一遍谁也受不了。所以你现在去看任何一个认真的 Agent 项目模型路由层都是第一优先级设计的模块。2.3 可插拔不等于无缝替换不过这里必须泼一盆冷水模型路由层解决的是“能不能接”的问题解决不了“接得好不好”的问题。不同模型对工具调用格式的遵循能力差异非常大。有些开源模型看起来支持 function calling实际一压测参数名拼错、该转 JSON 的字段给你返回字符串、多轮工具调用后格式直接崩。这都正常。所以收敛的架构只是降低了“切换成本”没有消除“适配成本”。踩过这个坑之后我才明白选 Agent 框架时真正要看的不是它支持多少模型而是它对“模型差异”有多大的容错和补偿能力。比如有些框架会在路由层做工具调用结果修复失败后自动重试、格式化纠正有些框架完全不管把烂结果直接交给上层最后表现就是 Agent 行为混乱。建议你在选型时把这一层的能力也算进去。3. 收敛层二执行审批与技能目录成了 Agent 的“标准配件”第二个所有 Agent 都在往一个方向走的层是执行安全层。过去聊大模型没人关心权限但 Agent 一旦真的去执行命令、写文件、调接口权限问题就从“运维话题”变成了“架构核心话题”。有意思的是OpenClaw、Codex、Hermes 系工具不约而同地给出了几乎相同的答案动作级审批加技能目录。3.1 OpenClaw 的 exec-approvals把“让不让执行”做成持久化配置OpenClaw 里有一个很重要的概念叫 exec-approvals也就是执行审批。具体表现是Agent 第一次准备执行某个敏感操作比如运行一段 shell 命令、写入某个文件、调用某个扩展时不会直接动手而是先停下来向你确认。你同意之后这条规则会被记录到审批配置里下次同样是这个操作就不再反复问你了。社区里有很多关于这个机制的提问最有代表性的一个报错大意是提示在 /root/.openclaw/ 路径下存在旧的 exec-approvals.json 文件工具启动时检测到了历史遗留数据需要手动处理。我当时看到这条信息的第一反应是版本升级后旧版审批文件格式和新版不兼容。解决办法通常是备份旧文件、让它生成新的审批配置或者手动做字段迁移。这类报错看起来吓人其实机制设计上是好事——它说明工具在一丝不苟地维护“执行权限边界”而不是默认放行一切。我在实际使用中最深的体会是审批机制不是摆设。没有它即使模型再强你也不敢把 Agent 放到有真实数据的环境里跑。它本质上是给大模型这个“不可控的执行者”加的一层保险丝。3.2 Codex 的权限提示与 Harness 约束Codex 的权限模型没有独立的审批文件但它把“权限确认”做进了 Harness。每一次文件写入、命令执行、网络请求都可以配置成“自动放行”“询问我”或“直接拒绝”。这样做有两个好处一是保证了安全边界二是保证了可审计性——干了什么都有痕迹随时可以回看。这里我想多说一句 Harness 的概念。英文里 harness 原意是马具、套具用在 Agent 架构里指的是“套在模型外面、约束它行为的那层工具”。系统提示词、工具定义、任务循环、权限策略、上下文管理全都在 Harness 里。Codex 和其他同类编程 Agent 的差距很多时候不在模型而在 Harness 的精细度。Harness 写得好小模型也能稳定完成多步任务Harness 写得糙再强的模型也会在复杂任务里跑偏。3.3 技能系统为模型预置“能力目录”第三个所有 Agent 都长出来的模块是技能系统。OpenClaw 有 SkillsCodex 有类似插件和 Harness 扩展的机制Hermes 系 Agent 普遍支持工具调用定义。它们的共同逻辑是把 Agent 可能用到的能力——发邮件、查天气、操作数据库、调某个 API——提前写好描述放进一个目录里模型在执行任务时先审视这个目录再决定调用哪个技能。其底层原理是大模型的上下文窗口是有限的不可能把所有工具的完整代码都塞进去而技能目录相当于“压缩后的工具说明手册”让模型知道“有这个工具它能干什么参数是什么”。等到真正调用时再加载对应的执行代码。这种“按需加载”的设计和传统软件里的插件机制很像但有一个显著区别技能描述是给 LLM 看的不是给人看的。我在这上面栽过跟头。刚开始给 Agent 写技能描述时我按写 API 文档的习惯写得特别简洁结果模型经常在明明该调用技能的场景下不调用或者调用了但参数传得乱七八糟。后来我把技能描述拆成三部分——场景触发条件、参数说明含默认值和示例、返回结果格式——调用成功率立刻上去了。如果你也在自己写技能目录这个经验可以直接抄技能描述的核心不是“代码怎么写”而是“模型什么时候该用它”。3.4 为什么这套设计会收敛到这同一个形态深想一层执行审批和技能目录几乎是 Agent 架构的“必然收敛解”。原因很简单Agent 的不可控性来自大模型的概率生成而概率生成恰恰不能在敏感动作上“自由发挥”。所以架构上必须引入确定性机制——权限审批是确定性规则技能目录是确定性接口——用确定性去约束概率性。凡是做不到这两点的 Agent 项目要么只能停在 Demo 状态要么早晚出事。因此成熟的 Agent 框架在迭代中必然会收敛到同一个答案这不是谁抄谁而是需求推出的最优解。4. 收敛层三部署形态趋同——本地 CLI、Docker 容器和远端服务各司其职第三个收敛发生在部署层面。如果你早几年搜“Agent 部署”看到的可能是一堆云平台、托管服务的宣传但现在的社区风向非常明确本地优先、容器可选、远程接入。OpenClaw、Codex CLI 和 Hermes 系 Agent全都默认给你一套本地可跑的工具链而 Docker 容器化则成为隔离环境的标准姿势。4.1 Windows 上部署 Hermes 系 Agent 的最稳路径“Windows 系统如何部署 Hermes 智能体比较合适”是近期的高频问题。我的答案很直接别在裸的 Windows 环境里硬装一堆依赖。Hermes 系 Agent 往往要跑 Python 或 Node 环境、要下载模型、要装各种工具库直接在宿主环境里塞大概率过几个月系统就乱了。推荐的做法是 Docker Desktop 加 WSL2。具体路径先启用 WSL2并在 PowerShell 里设置 WSL2 为默认版本。安装 Docker Desktop设置里确认 Use WSL 2 based engine 是打开状态。为 Agent 单独建一个工作目录写好 docker-compose.yml把模型目录、技能目录、配置目录用 volume 挂载出来。在容器里运行 Agent 主进程日常通过端口或本地命令交互。这样做的理由是Agent 在运行过程中会频繁安装依赖、写缓存、调本地工具容器隔离能把这些“脏活”锁在一个可随时重建的环境里。而 WSL2 解决了 Windows 本地文件访问和 Docker 运行时的兼容问题。我自己的经验是这套方案比直接跑 Python 虚拟环境要省心得多。唯一要注意的是文件挂载的路径建议放在用户目录下的独立文件夹避免权限问题。4.2 OpenClaw 的部署形态从桌面进程到边缘设备OpenClaw 的部署形态更“野”一点。它本身可以作为一个常驻进程跑在桌面电脑上也支持 Docker社区里甚至有人在树莓派上跑它来充当家庭自动化中心。这个跨度说明的其实是同一个趋势Agent 正在从“云端的对话服务”变成“贴近你设备的常驻服务”。贴近设备的好处是能操控真实世界——读本地文件、控制智能家居、跑本地脚本。这与传统 SaaS 完全不同SaaS 时代的自动化发生在云端Agent 时代的自动化发生在你的设备上。所以在架构收敛的现象背后其实是使用场景发生了根本变化。任何不允许“本地部署”的 Agent 产品都会天然丧失一批需要掌控数据、掌控执行环境的用户。4.3 docker hermes 这类组合本质上是在给 Agent“打包环境”社区里的另一个高频词是 “docker hermes”。把 Hermes 和 Docker 放在一起搜的人通常是想快速把 Agent 环境跑起来不想被依赖地狱折磨。用 Docker 部署 Hermes 系 Agent最大的收益是环境一致性——你同事那份配置、生产环境那份配置、你本机这份配置可以完全是同一份镜像。但这里有个容易踩的坑容器环境里跑 Agent它的“本地文件访问”往往会被限制在容器内部。如果你打算让 Hermes 类 Agent 去操作宿主机上的文件一定要把对应目录以 volume 方式挂进去并且设置好用户权限。否则模型可能明明觉得自己已经把文件写好了实际上写进了容器里一个不存在的持久化层容器一删全没了。我见过太多次这种“容器里一切正常宿主机上啥都没有”的尴尬。4.4 部署形态收敛的底层原因为什么部署形态会收敛到“本地 CLI Docker 远程接入”三件套我想了很久最后得出一个比较简单的解释这是“可控性”和“便利性”博弈的平衡点。纯云端方案便利但数据不受控、延迟高纯本地裸装方案可控但环境极易污染。Docker 容器正好站在中间环境可控、依赖隔离、可复制、可销毁重来。本地 CLI 则保证 Agent 能访问真实的工作目录和工具链远程接入解决的是“人不在设备旁”的场景。三个形态各有各的存在理由所以最后的收敛结果必然是三者并存而不是某一种吃掉另外两种。5. 一个真实报错还原/responses endpoint 请求失败的完整排查前面几章都在讲架构层面的收敛但架构落到地就是一个个具体的报错。这几天社区里有一条非常典型的报错几乎可以当成 Agent 架构收敛的一个活教材大意是cc switch 的本地转发组件在处理 Codex 的 /responses 端点请求时失败后面通常还跟着 provider 相关的提示。这条报错的信息量很大拆开看场景是这样的你让 Codex 客户端把请求发到一个本地转发组件再从这个组件转发到真正的模型服务结果转发这一步挂了。整个链路是Codex 客户端构造了一个访问 /responses 端点的请求交给本地转发层本地转发层再转发给目标模型服务。5.1 先从架构图上判断故障点这种报错千万别急着改配置先画一遍请求路径脑子里画就行客户端 → 本地转发层 → 目标模型服务/responses 请求失败可能的原因有五种客户端里配置的 endpoint 地址写错了指向了一个不存在的本地端口。本地转发服务没有启动或者启动后监听的不是配置里写的端口。路由映射规则没配对——客户端请求 /responses但转发层只定义了旧的聊天补全端点。转发层起来了但目标模型服务地址配错或当前不可达。鉴权信息没带对目标服务直接拒绝。5.2 逐步排查的实操过程我最常用的排查方式是不依赖任何调试工具从外层往内层一层层剥。第一步先验证“目标模型服务”本身是否正常。如果目标是 DeepSeek 这类 API 服务直接用 curl 测一下curl https://api.deepseek.com/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer $API_KEY \ -d {model:deepseek-chat,messages:[{role:user,content:hi}]}如果这一步通了说明目标服务没问题问题在本地转发层或客户端配置如果这一步都不通先看网络连通性和密钥别往下查。第二步确认本地转发层是否真的在监听。不同工具检查方式不同但通用的命令是看端口监听状态Linux 和 macOS 用 lsofWindows 用 netstat。比如你配置文件里写的转发端口是 8080先确认这个端口有人监听。没监听就去查转发服务的启动日志——十有八九是服务根本没拉起来或者启动时配置路径读错了。第三步验证客户端到转发层的请求。Codex CLI 这类工具通常支持 verbose 或 debug 日志打开之后能看到完整请求头和目标 URL。重点检查两件事请求 URL 的端口、路径和转发层配置是否一致Authorization 头是否还在。很多转发层为了让请求能转出去会重写请求头结果重写后鉴权丢了目标服务直接返回 401。第四步检查路由映射。我发现最容易出问题的是“端点版本不匹配”。Codex Agent 默认走 /responses 端点而市面上很多兼容服务只实现了老式的 /v1/chat/completions。中间转发层如果没做端点映射请求就会撞上一堵墙。解决思路有两个要么给你的转发层配一条“把 /responses 映射成目标服务兼容端点”的规则要么在客户端配置里切换成目标服务支持的端点格式。5.3 这类报错为什么是“收敛”的缩影仔细想想这个报错本身就是架构收敛带来的新问题。以前模型厂商自己出 CLI、自己出后端不存在“本地转发层”这种东西也就不存在转发失败。但现在大家都把模型后端做成可插拔了中间自然多出一层基础设施——转发层。转发层的出现让“用 A 框架驱动 B 模型”成为可能但也引入了新的故障点。这也解释了为什么现在社区问答里大量 Agent 技术问题都集中在“接口适配”而非“算法原理”。你不需要理解 Transformer 的注意力机制才能用 Agent但你必须理解 endpoint 背后的一整套协议否则连第一个 Hello World 都跑不通。所以我的建议是学习 Agent 开发与其死磕某个框架的 API 文档不如先把 OpenAI 兼容协议、/responses 端点、工具调用格式这些跨框架的公共知识吃透。它们才是 Agent 架构收敛之后所有系统共用的语言。6. 架构都收敛了选型反而要回到“边界条件”最后聊聊选型。很多读者看完前面的分析可能会产生一个问题既然架构在收敛那 OpenClaw、Codex、Hermes 这些是不是随便选一个就行我的回答是架构收敛降低的是“切换成本”降低不了“任务适配差异”。选型还是要回到你自己的边界条件。6.1 三套体系的核心适用场景对照我根据实际部署和一段时间的使用体验做了这么一张对照表体系本质最合适的场景典型运行环境主要学习成本OpenClaw通用 Agent 运行时个人自动化、智能家居、跨应用编排Windows/Linux/macOS 原生或 Docker技能开发和扩展配置Codex CLI编程智能体写代码、改 Bug、跑测试、提 PR本地终端 GitHub 协作Harness 与权限模型的理解Hermes 系工具链开源模型底座 Agent 工具私有化部署、模型可控、研究实验Docker WSL2 最常见模型部署与工具调用格式调试需要注意的是表格里只是“天然更合适”的场景不是“只能干这个”的场景。OpenClaw 也能写代码Codex 也能做点自动化Hermes 配上合适的工具也能办公。但术业有专攻用“通用 Agent 跑编程任务”和“编程 Agent 干编程任务”体验差距会很明显尤其任务一复杂差距立刻显现。6.2 我的个人选型建议如果你问我自己怎么选我的判断标准是三条。第一看任务类型。你的核心需求是“帮我干杂活、整合各种服务”首选 OpenClaw 这类通用运行时核心需求是“帮我把代码写对、把工程跑通”Codex CLI 这类编程智能体更顺手。第二看运行环境。你的 Agent 要长期跑在一台 Windows 电脑上并且需要和本地文件、本地服务频繁交互那 Docker 加 WSL2 的隔离方案几乎是最优解。如果你想要极致简单先跑通再说那直接本地裸装也未尝不可反正环境乱了可以推倒重来。第三看你对模型底座的掌控力需求。如果你在意数据隐私、想部署私有模型Hermes 系和开源模型生态绕不开。如果你更在意效果、愿意把模型交给更强大的商用模型来驱动那 OpenClaw 和 Codex 支持的商用模型后端会更省心。6.3 别被“大一统”叙事迷惑最后想提醒一句架构收敛不等于模型能力收敛。OpenClaw、Codex、Hermes 可以长成相似的骨架但骨架上的“大脑”差距依然悬殊。架构收敛带给我们的真正红利是低成本实验——你可以今天用这个模型、明天换那个模型用同一套 Agent 工具快速跑对比找到最适合任务的那一个而不是被某个生态绑死再也没有选择权。所以在实际操作中我的态度是框架不追新协议要跟紧。凡是把模型网关、执行审批、技能系统这三层做扎实的项目都值得认真学凡是只靠一个模型 API 拼出来的“套壳 Agent”不管包装多华丽都建议直接跳过。我自己把这套思路在真实项目里验证了一轮之后最大的体会是AI Agent 架构的收敛不是某个团队灵光一闪想出来的标准而是被同样的问题逼出来的统一解。大模型不可控所以需要确定性的执行审批工具越来越多样所以需要标准化的技能目录模型更新太快所以需要可插拔的模型路由。谁都得过这几关架构自然就长得越来越像。分享一个我实际用下来最顺手的小技巧不要在 Agent 项目里堆功能先把“模型网关 权限审批 技能目录”这三个模块当成地基来搭。想清楚这三层任何新框架出来你都能在半天内上手——因为它们的骨架你已经提前理解了。最后再补一个更落地的提醒部署任何 Agent 之前先花十分钟把官方文档里关于配置文件的默认路径找出来。OpenClaw 的配置集中在用户目录下的 .openclaw 文件夹里Codex CLI 的配置也在它自己的配置目录里容器部署的 Hermes 系工具则要留意 volume 挂载路径。你后面八成以上的排错工作几乎都会围绕这几个文件展开。先把地图拿到手再开始探索就没什么好慌的了。