夜雨聆风阅读方式也很简单：按文中顺序一步一步做，先接通、再验证，不要一上来追求“一句话全自动”。
如果你已经把 AUTO-MAS 和 MAA 装好了，真正让人卡住的，通常不是"能不能跑"，而是"怎么把这条链路接进对话入口里"。
很多人第一次看到 AUTO-MAS 的 MCP，会下意识把注意力放在协议名词上。但对这篇教程来说，MCP 不需要讲那么大。你只需要先记住一件事：AUTO-MAS 已经把管理和调度能力，暴露成了一个本地可接入的工具入口。而 OpenClaw 要做的，就是把这个入口接住。
这也是本篇的目标：不讲安装，不绕概念，直接把连接路径走通。
这篇教程默认你已经有什么
这篇默认你已经具备下面这些前提：
已经装好AUTO-MAS 已经装好MAA 你本机能正常启动 AUTO-MAS 你知道 OpenClaw 是自己的对话入口，准备把 AUTO-MAS 接进去
如果你现在还停留在"软件还没装好""MAA 还没跑起来"的阶段，请先解决这些。因为MCP 解决的是"接入与调用"问题，不是安装问题。
换句话说，今天这篇只处理一件事：
让 OpenClaw 能接到 AUTO-MAS 提供的本地 MCP 服务，并完成最基础的连通验证。
在这条链路里，MCP 到底是干什么的
别把它想得太学术。
放在这篇教程里，MCP 的作用可以直接理解成一句话：
它是 AUTO-MAS 留给外部 AI / 工具调用层的那个标准接口。
你平时在 AUTO-MAS 里看到的那些事情，比如脚本管理、多用户配置管理、调度队列、任务启动停止、状态信息、历史记录和日志读取，本来主要是在它自己的界面和后端里完成。现在 AUTO-MAS 提供了 MCP 服务，相当于把这些"可被调用的能力"开放出一个统一入口。
对我们来说，这就够了。
你不用在这里研究协议史，也不用背一堆抽象名词。你只要知道：
- AUTO-MAS：负责脚本、配置、队列和调度
- OpenClaw：负责承接自然语言请求
- mcporter：负责把 AUTO-MAS 这个本地工具接口接进来
- MAA：是这条链路里最容易感知价值的具体执行器之一
所以这不是"AI 直接玩游戏"。更准确地说，它是：
你把 AUTO-MAS 这个自动化控制层，接成了一个可以通过对话调度的工具。
先确认最关键的信息：AUTO-MAS 的 MCP 地址
AUTO-MAS 官方文档已经给出了 MCP 地址：
http://localhost:36163/mcp这一篇你先记住这一个结论就够了：OpenClaw 要接的，就是这个地址。
为了后面不来回返工，这里把最容易出错的前提一次说清：
默认前提是OpenClaw 和 AUTO-MAS 在同一台机器上 AUTO-MAS 必须已经启动，否则这个地址只是空门牌 地址要写完整， /mcp不能漏
也就是说，这一篇最核心的问题其实只有一个：把 OpenClaw 指到http://localhost:36163/mcp，再确认它真的能读到 AUTO-MAS 的能力。
接入思路很简单：让 OpenClaw 指向这个 MCP 服务
这一段不再讲抽象思路，直接讲怎么填。
如果你这边是通过mcporter管理 MCP 服务，那么它默认看的就是当前工作目录下的这个文件：
./config/mcporter.json这一点可以直接从 mcporter 自己的行为确认：
mcporter --help明写了：默认从 ./config/mcporter.json读取配置mcporter config doctor会告诉你当前项目配置文件的实际位置 mcporter config add automas http://localhost:36163/mcp --scope project写入出来的也是 config/mcporter.json
也就是说，最稳妥的写法不是先猜"全局配置藏在哪"，而是先在你准备用 OpenClaw 的那个项目目录里确认config/mcporter.json。
最小配置就写成这样
如果这个文件还没有，你可以手动创建。最小可用配置长这样：
{"mcpServers":{"automas":{"baseUrl":"http://localhost:36163/mcp"}},"imports":[]}这里最关键的只有一行：
"baseUrl":"http://localhost:36163/mcp"AUTO-MAS 的 MCP 地址就填在这里。别改成根地址，也别把/mcp漏掉。
不想手写的话，也可以直接用 mcporter 加进去
如果你更想走命令行，等价写法是：
mcporter config add automas http://localhost:36163/mcp --scopeproject这条命令的作用很直接：在当前项目目录下生成或更新config/mcporter.json，增加一个名字叫automas的 MCP 服务项。
写完之后，先做两步验证
先别急着问 OpenClaw"能不能帮我跑任务"，先做最基础的配置验证。
看配置文件有没有被 mcporter 认出来
mcporter config doctor你应该至少能看到它打印出当前项目配置文件的位置。只要路径对上了，说明 mcporter 看的文件没跑偏。
尝试让 mcporter 发现这个服务
mcporter list automas --schema如果你还没把服务写进配置，也可以临时直连测试：
mcporter list --http-url http://localhost:36163/mcp --allow-http --schema正常情况下，你应该看到它开始发现 AUTO-MAS 暴露出来的工具；如果 AUTO-MAS 没启动，mcporter 往往会直接报连接失败或超时，这反而是有价值的反馈，因为它能帮你把问题定位到"服务没起来"，而不是"字段写错了"。
这一步最常见的错误，基本就这几类
1）把地址写对了，但 AUTO-MAS 根本没开这是最常见的一种。配置看起来没问题，实际localhost:36163根本没人监听。
2）漏掉/mcphttp://localhost:36163和http://localhost:36163/mcp不是一回事，后者才是这篇要接的地址。
3）把配置写到别的目录去了mcporter 默认读取的是你当前工作目录下的./config/mcporter.json。如果你在 A 目录写了配置，却在 B 目录里运行 OpenClaw 或 mcporter，看起来就会像"明明配了但没生效"。
4）把字段名写成别的按 mcporter 当前实际写入结果，HTTP 服务项使用的是baseUrl。这一项别自己发明成别的名字。
5）HTTP 本地地址测试时忘了显式允许如果你用的是临时直连命令，mcporter 对http://会要求加--allow-http，少这个参数时会直接拒绝测试。这不代表 AUTO-MAS 有问题，只是 CLI 在做保护。
做到这里，这一节才算真正从"知道思路"走到了"可以照着填"。
配置时建议怎么做：不要一上来就追求"全自动"
这里给一个更稳的做法。
很多人一接入，就想马上验证"能不能一句话全跑完"。这其实很容易把排错难度抬高。更好的顺序是：
先只确认服务能发现
先不要管复杂工作流，只看一件事：
OpenClaw / mcporter 这一侧，能不能看到 AUTO-MAS 这个 MCP 服务 能不能识别出它暴露出来的工具能力
如果连"看见服务"和"列出工具"都还没完成，就先不要往调度、脚本、日志那一层冲。
再确认能做最轻量的查询动作
优先验证"读"而不是"写"。
例如优先看这些方向：
能不能读取信息总览 能不能查询脚本列表 / 配置概况 能不能查看调度队列 能不能获取历史记录或状态信息
原因很简单：查询型动作最适合做连通验证。
它们通常更安全，也更容易判断"到底是没接上，还是接上了但你调用错了"。
最后再去试执行型动作
等你已经确认服务正常、工具可见、查询能跑通，再去试：
启动某个任务 停止某个任务 调度某个队列 读取指定日志
这个顺序，会比一上来就"帮我跑一整套明日方舟日常"靠谱得多。
怎么验证自己真的接通了
这一段最关键。因为"我好像配好了"和"它真的能用"是两回事。
最稳的验证顺序就是四个字：先看，再调。
你至少做完下面这 3 层验证，才算真的接通。
先确认 AUTO-MAS 端确实在提供 MCP
先看两件事：
AUTO-MAS 正在运行 这个地址 http://localhost:36163/mcp对本机来说确实可达
这一步的意义很简单：先确认服务存在，再谈客户端接入。如果服务端本身没起来，后面所有症状都会长得像"配置有问题"。
再看 OpenClaw / mcporter 有没有发现它
接入成功后，你至少应该看到一个明确迹象：
OpenClaw 已经识别到 AUTO-MAS 这个 MCP 服务 或者 mcporter 已经把它当作一个可访问的 MCP endpoint 来处理
如果这层还没成立，问题就还停留在"接入配置"阶段，而不是"工具调用"阶段。
最后做一次低风险的真实调用
这一步不要急着跑执行型任务，优先做查询型动作。
比如先试这些方向：
看看当前有哪些脚本 看看有没有现成调度队列 查一下历史记录 读一下信息总览或状态信息
这一步的意义在于：只有真正调通一次，你才能同时确认地址对、服务在、工具可见、返回正常这四件事都成立。
一个很实用的判断标准
如果 OpenClaw 已经能根据你的请求，稳定返回 AUTO-MAS 那边的结构化信息，而不是模糊地说"好像连接成功"，那才算真的过线。
如果没通，先按这几件事排查
如果你卡住了，先别急着怀疑 OpenClaw 本身。大多数问题，先查下面这几件事就够了。
先查服务有没有真的起来
最常见的情况，不是配置写错，而是AUTO-MAS 根本没启动，或者启动了但 MCP 服务没有正常提供。
表面看起来像是 OpenClaw 连不上，实质上只是服务端没站稳。
再查地址有没有写对
这一项重点就盯住一个地址：
http://localhost:36163/mcp常见错误主要就三种：
漏掉 /mcp写错端口 把 localhost当成远程机器地址
如果地址有偏差，后面所有症状基本都会表现成"工具没发现"或者"服务不可用"。
再查问题到底卡在"发现服务"还是"调用工具"
这一步很关键。
如果 OpenClaw / mcporter 还看不到 AUTO-MAS，那问题就在接入配置层；如果服务已经能发现，但一调用就失败，那才需要继续看工具识别、参数填写，或者 AUTO-MAS 本身的脚本 / 队列 / 配置状态。
也正因为这样，我前面才一直强调：先读后写，先查后跑。一上来就测执行任务，只会把排错信息混在一起。
最后再看底层配置是不是本来就乱
就算 MCP 已经接通，也不代表 AUTO-MAS 底层一定健康。
下面这些问题，OpenClaw 不会替你自动修：
多用户配置本来就没整理清楚 调度队列顺序不合理 日志里已经有异常 某些自动化能力依赖第三方凭证、token 或登录态
换句话说，接入成功只是"入口通了"，不是"底层所有问题都消失了"。
保守提醒：这条链路能省事，但不是零维护
这一段我还是建议你别跳过。
更接近现实的说法是：
- OpenClaw
让入口更自然 - AUTO-MAS
让脚本、配置、队列更集中 - MCP
让它们之间能接起来
但你仍然要为下面这些事保留警惕：
登录凭证 / token 风险
涉及第三方账号、token、自动签到、凭证写入这类操作时，别因为"现在能对话调用"就放松警惕。方便，不等于可以乱配；能调，不等于可以乱存。
自动化失败边界
MCP 接通，不等于所有任务都会稳定执行。脚本失效、配置错误、环境变化、模拟器状态异常、日志已有报错，这些问题都不会因为多了一个对话入口就自动消失。
维护成本依旧存在
真正长期好用的前提，还是你自己的配置结构清楚、调度顺序合理、日志习惯健康。OpenClaw 能把操作入口变轻，但不会替你免除维护责任。
这一篇做到这里，就算接入完成了一半
如果你已经完成下面这几件事：
确认 AUTO-MAS 正在运行 确认 MCP 地址是 http://localhost:36163/mcp在 OpenClaw / mcporter 侧把这个服务登记进去 至少完成一次低风险查询验证
那就说明最难的第一关已经过去了。
你现在缺的，不再是"会不会接"，而是"接好以后，应该怎么说，怎么问，怎么把它真正用起来"。
这部分，我们留到下篇。
结尾：先把接口接稳，下篇再谈怎么对话指挥
上篇先做到这里。
这一篇的重点，不是炫技，而是把基础接通。因为只有 MCP 真接稳了，后面的自然语言操作才不是空中楼阁。
下篇我会继续写最实用的部分：接好之后，怎么通过对话去操作 AUTO-MAS。
包括：
什么样的请求最适合交给它 脚本管理、队列调度、启停任务可以怎么说 查询状态、看历史、读日志时，怎样问更稳 哪些需求可以交给它，哪些需求最好别说得太死
如果你正好也想把"自动化控制台"变成"聊天入口"，记得关注，下篇继续。下一篇，我们不再讲接口怎么接，而是直接讲怎么开口、怎么用、怎么把它用顺手。
