从想法到作品 / 章节 06
第六章｜用 MCP 让 Agent 真正操作作品
读完这一章，你可以
连接浏览器工具，把检查方法变成真实操作与结果。
上一章我们准备了一份游戏检查 Skill。它已经说明先看什么、怎样检查、如何记录。但执行这些步骤，还需要能够打开网页、点击按钮和读取结果的能力。
如果你使用的 Agent 已有浏览器工具，可以直接用现有工具完成。想再接入一个外部工具时，可以通过 MCP。我们用微软维护的 Playwright MCP作为案例，把“有一套检查方法”接到“能实际操作页面”。
先看一次连接里谁在做什么
想象你对 Agent 说：“打开当前游戏，检查开始和暂停。”其中有几层关系：
你提出任务
↓
Agent 决定下一步需要什么操作
↓
当前应用通过 MCP 与 Playwright 服务通信
↓
服务操作浏览器，返回页面信息和操作结果
↓
Agent 根据结果继续检查或报告问题承载 Agent 的应用通常称为 host，它通过客户端连接 MCP 服务。服务可以提供工具和数据等能力。需要时可以回看浏览器工具与 MCP。
对我们当前的目标来说，先抓住一个重点：模型决定调用什么，具体工具执行动作并返回结果。连上一个服务之后，要继续确认它提供了什么能力，以及 Agent 怎样使用。
为什么先选浏览器案例
浏览器操作的结果比较直观。你能看到页面是否打开、按钮是否点击、界面是否改变；同时还可以检查控制台里的错误。它与前面的试玩直接相连。
Playwright MCP 提供页面导航、结构快照、点击、截图和日志等工具。我们先用这些基本能力，不急着配置一大批服务。等它解决了眼前的检查任务，再根据新的需求扩展。
MCP 也可以连接文档、数据库或其他系统。每次选择服务时，都先说清楚它要补哪一项能力。当前的问题是操作游戏，所以从浏览器开始。
先读配置，再把它填进去
先按工具准备安装 Node.js，运行 node --version，确认版本不低于 18。下面的配置使用 Microsoft Edge；先确认电脑上已经安装 Edge，服务会用它打开页面。
配套文件 playwright.json采用常见的服务配置结构：
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": [
"--registry=https://registry.npmmirror.com",
"-y",
"@playwright/mcp@latest",
"--browser",
"msedge"
]
}
}
}先理解它的意思：服务名是 playwright；command 是要运行的程序；args 是交给它的参数。这里由 npx 启动指定的软件包；--registry 指定国内 npm 镜像，首次运行从那里下载；--browser msedge 指定使用已安装的 Edge。
这属于在本机启动的服务，常见通信方式叫 stdio。有些服务运行在远端，需要填 URL，可能还要完成认证。不要把远程地址填进本地命令栏；先看该服务给出的接入方式。
在 ZCode 中添加并确认连接
打开设置中的 MCP 服务管理，添加一个当前项目使用的服务。可以在表单中填名称、启动方式、命令和参数，也可以按完整配置入口导入 JSON。具体入口见 ZCode MCP 文档。
配置完成后启用服务，查看连接状态和可用工具。先找是否出现页面导航、页面快照、点击等浏览器能力。让 Agent 列出这次任务可以使用的浏览器工具，也是一个容易理解的确认方式。
服务显示在线，是连接这一环完成；接下来还要进行一次最小调用，确认它能按预期工作。先让它打开一个普通页面并读取标题，再进入我们的游戏，能把服务问题与项目问题分开。
让工具真的操作一次
为本地游戏准备一个地址
单文件游戏可以在自己的浏览器里直接打开。交给自动化工具时，我们给它一个本地 HTTP 地址，便于工具访问同一份作品。
在 snake-lab 目录中，通过终端运行：
python3 -m http.server 8000 --bind 127.0.0.1Windows 上如果使用 Python 启动器，可以改用：
py -m http.server 8000 --bind 127.0.0.1保持这个终端运行，在浏览器访问 http://127.0.0.1:8000/。目录中有 index.html 时，通常直接展示它。127.0.0.1 指当前电脑，8000 是这个服务监听的端口；命令结束后，这个地址也就暂时不可访问。
终端在这里承担了一个明确任务：把项目文件提供给浏览器读取。你可以让 Agent 帮忙启动，并告诉你它运行在哪个目录、怎样停止。
第一次调用：先观察页面
请使用已连接的浏览器工具打开 http://127.0.0.1:8000/。
先读取页面结构，找出开始、暂停和重开按钮，说明当前可执行哪些操作。Playwright MCP 主要使用结构化页面信息定位元素。截图适合辅助看外观，按钮操作则应依据页面快照中的元素信息。
如果快照中看不到某个控件，可以先检查页面是否加载、控件是否有明确文字或标签。有些游戏把整个界面都画在画布里，内部元素不会自动变成普通按钮；此时让 Agent 根据实际结构选择检查方式，必要时改善控件表达。
这里又出现了一个按需学习的机会：为了让作品更容易被操作和检查，我们开始关心标签、结构和可访问名称。这些知识有了当前用途，再去学就更具体。
把 Skill 和工具接起来
现在再次调用检查技能：
$playable-review
当前游戏地址是 http://127.0.0.1:8000/。
请使用浏览器工具检查：开始、暂停、继续和重新开始。
记录操作与结果，再指出最值得优先修改的一项。Skill 提供方法，MCP 工具提供操作能力。它们的组合可以沿一轮具体检查来理解：读取玩法，安排操作，调用工具，记录变化，整理建议。
观察报告是否对应实际行动。涉及蛇身位置、实时移动等画布内部行为时，可以结合截图、日志、代码与人工试玩。把工具能直接观察的结果与还需要进一步检查的部分分清，下一步任务就更明确。
连接失败时，按层找原因
先看错误发生在哪个位置：
| 卡在哪里 | 先检查什么 |
|---|---|
| 服务启动不了 | Node.js、命令和参数、包下载、启动日志 |
| 服务在线但没有预期工具 | 启用状态、工具列表、当前会话是否刷新 |
| 工具调用失败 | 参数、返回错误、浏览器是否启动 |
| 页面打不开 | 本地服务是否运行，端口和目录是否正确 |
| 页面打开但检查走不下去 | 元素结构、按钮状态、实际操作顺序 |
这样，你可以先处理连接，而不是反复改游戏代码；也可以确认服务正常后，把注意力放回作品。
换一个任务想一想
如果你想让 Agent 阅读外部文档，再修改项目，它需要什么能力？先说清资料在哪里、怎样认证、希望读取什么、输出用在哪里，再去选择合适的服务。
到这里，我们已经走过一条完整路线：把想法说清楚，借助 Agent 做出第一版，学习需要的知识，继续修改；遇到问题就排查和恢复，重复的方法整理成 Skill，需要的工具通过 MCP 接进来。
给自己的项目留一页记录：当前目标、已有结果、下一项最想做的修改，以及准备怎样检查。后面集中实战，我们就从这一步继续。
接下来可以打开补充教程：在 DSH 中接入模型，通过一次界面配置认识 API 的常见名词。
停一下，检查自己的理解
RECALL / 一分钟回忆
先凭自己的理解选一项，再看解释。