AI Agent自主开发浏览器游戏：从自动生成到部署上线的完整流程

之前看到 “Show HN: My AI agent built and shipped a browser game on its own” 这个标题时我的第一反应不是“AI 又能写游戏了”而是“它到底是怎么把‘写代码、跑测试、部署上线’这一整条链路自己走完的”。因为写一个网页游戏并不难难的是让 Agent 在无人干预的情况下把需求变成可运行、可访问、可分享的线上产品。这篇文章不会停留在“AI 很强大”这种感叹层面而是完整拆解一个 AI Agent 从零到一构建并发布浏览器游戏的工程流程。内容包括Agent 的核心工作原理解析、工具调用与执行循环设计、一个可运行的 Agent 示例代码、自动生成游戏代码的过程、自测修复、以及最后发布上线的具体步骤。如果你正在研究 AI Agent 开发或者想把手头重复性的“编码 部署”任务交给 Agent 来做这篇文章会很适合你。1. 背景为什么“Agent 自主发布游戏”值得关注1.1 从一条 Hacker News 分享说起“Show HN” 是 Hacker News 上一个专门展示开发者作品的板块。以往大家展示的是自己亲手写的产品而这几年开始出现一个趋势展示 AI Agent 自主完成的项目。“My AI agent built and shipped a browser game on its own” 这条帖子之所以能引起讨论不是因为它展示了一个多复杂的 3D 大作而是它证明了这样一条链路已经可以走通任务描述 - 生成代码 - 运行测试 - 修复 Bug - 部署上线如果你从事开发工作应该能感知到这件事的分量。过去一年里AI 辅助编码已经非常普遍但“辅助”和“自主”之间还有一条很长的路。Agent 自主发布产品意味着它不只是你的结对编程伙伴而是可以承担完整执行任务的“初级工程师”。1.2 AI Agent 到底是什么这里先做一个概念澄清。AI Agent智能体和普通的聊天机器人有本质区别聊天机器人你问它答它只生成文本不执行动作。AI Agent基于大语言模型LLM做决策同时具备调用工具、执行命令、读取文件、访问网络等能力并且可以在一个循环里反复执行“思考 - 行动 - 观察结果 - 再思考”的流程直到完成任务。所以一个能开发并发布游戏的 Agent核心不是“会写代码”而是“能自主完成一系列需要与环境交互的任务”。写代码只是其中一环真正困难的是让 Agent 知道下一步该做什么、做完之后如何验证、出错之后如何检查原因。1.3 为什么选“浏览器游戏”作为案例浏览器游戏是一个非常合适的 Agent 自主开发实验对象技术栈简单纯 HTML CSS JavaScript 就能跑不需要配置复杂的后端环境。可验证性强游戏能不能运行、能不能计分、点击有没有反应这些都是明确的验收标准。部署链路短静态文件可以直接托管到 GitHub Pages 或任意静态服务器。反馈闭环快代码写错后刷新页面就能看到现象Agent 能及时修正。可以说浏览器游戏是 AI Agent 开发流程的“最小可行产品”非常适合用来理解和验证 Agent 的工作方式。2. 核心概念AI Agent 的自主工作流2.1 ReAct 模式推理与行动交替AI Agent 的工作方式本质上可以理解为 ReAct 模式即 Reasoning Acting。简单来说推理Reasoning模型根据当前状态分析“现在目标是什么还差什么下一步该做什么”。行动Acting模型调用某个工具比如写文件、执行命令、请求 HTTP 接口。观察Observing工具返回结果模型把结果纳入自己的上下文继续下一轮推理。这个循环会一直持续直到 Agent 认为任务已经完成或者触发了提前设定的停止条件。一个典型的 Agent 执行过程可能是这样的步骤Agent 的思考Agent 的行动观察结果1需要先创建游戏文件调用 write_file文件创建成功2需要验证代码是否能运行调用 run_command 启动本地服务服务启动成功3页面可能有 JS 报错调用 run_command 做语法检查发现第 30 行变量未定义4需要修复这个错误调用 write_file 修改代码修改完成5再次验证重新运行测试测试通过6任务完成调用 publish 部署返回线上地址可以看到Agent 并不是“一次性生成所有代码”就结束了它更像一个真正的开发者写代码、验证、发现问题、修复、再验证。2.2 Tool UseAgent 的“手脚”大语言模型本身只能输出文本它之所以能操作电脑、写文件、执行命令靠的是工具调用Tool Use也叫 Function Calling。在一个 Agent 项目中工具就是一组预先定义好的函数。每个函数需要包含函数名称功能描述参数列表函数实现模型在推理过程中会“决定”调用哪个工具并给出相应的参数。然后由 Agent 框架去执行这个函数把返回值交给模型继续分析。下面是一个 Agent 常用工具集的设计后续实战部分会用到工具作用write_file写入或更新文件read_file读取文件内容list_files查看目录结构run_command执行 shell 命令publish部署静态站点并返回 URL2.3 记忆与上下文管理Agent 的“记忆”和人的记忆不太一样。它没有真正的长期记忆所有信息都必须放进上下文中才能被模型逻辑处理。这也是 Agent 开发中最大的工程难点之一。当 Agent 执行多轮操作后工具返回的大量内容会把上下文窗口塞满。常见的解决办法有截断日志只保留末尾 N 行。摘要把较长的历史记录提炼成简短摘要。外部检索把文件内容存到向量数据库需要时再取回。在实战案例中我们会用最朴素的方式控制上下文限制工具返回信息长度并设置最大迭代轮数。3. 环境准备与工具选型在开始写代码之前先梳理一下需要的环境和工具。版本需要根据你的项目实际情况调整下面以常见环境为例重点演示配置思路。3.1 基础环境操作系统macOS 或 Linux 优先Windows 用户建议使用 WSL2避免 shell 命令兼容性问题。Python3.10 及以上版本用于编写 Agent 主程序。Node.js18 及以上版本部分测试工具需要。Git用于版本控制和发布。3.2 LLM 接入方式本文示例以 OpenAI 风格的 Chat Completions API 和工具调用格式为例。实际项目中你可以根据自己选择的模型和 SDK 调整。关键点在于模型需要支持 Function Calling / Tool Use因为这是 Agent 能够自主执行动作的基础。pip install openai3.3 游戏技术栈为了降低 Agent 的编码难度和部署成本游戏采用“单文件架构”index.htmlHTML、CSS、JavaScript 全部写在同一个文件里。这样 Agent 只需要维护一个文件从生成到部署的路径最短对新手理解 Agent 流程也更友好。3.4 部署目标可以选择以下几种静态托管方式GitHub Pages免费、支持 Git 工作流适合展示型小游戏。Netlify Drop支持拖拽部署也有 API 可以供 Agent 调用。自己服务器适合有独立主机的场景但需要更严格的安全控制。本文实战部分以 GitHub Pages 为例因为你只需要一个 GitHub TokenAgent 就能完成推送和发布。4. 实战从需求到部署的完整流程下面我们进入完整实战。这一节我们会先定义任务再实现一个最小可用的 Agent 系统然后让 Agent 自动生成游戏代码、执行测试、修复问题最后发布上线。4.1 明确任务描述Agent 要能自主完成任务任务描述的清晰度非常关键。模糊的需求会让 Agent 反复猜测浪费 token 和时间。这里我们把任务定义为开发一个名叫“接苹果”Catch Apples的浏览器小游戏。 游戏规则 - 玩家用鼠标左右移动底部的篮子。 - 苹果从屏幕上方不断落下。 - 接住苹果得 1 分。 - 漏掉 3 个苹果游戏结束。 - 点击“重新开始”按钮可以重新开始游戏。 验收标准 - 使用单个 index.html 文件包含 HTML、CSS、JavaScript。 - 游戏中不能使用外部依赖。 - 页面在桌面浏览器上打开即可运行。 - 需要显示当前得分和剩余生命。 - 代码需要通过 JavaScript 语法检查。为什么任务描述要这么细 因为 Agent 自主开发跟团队管理很像需求越明确返工越少。尤其是验收标准它给 Agent 提供了“什么时候才算完成”的判断依据也让后续的人工审查有据可依。4.2 实现最小 Agent 系统接下来我们写一个简化版的 Agent 主程序。这段代码的核心思路是在循环中让模型决定调用哪个工具执行工具后把结果交给模型继续思考。4.2.1 工具定义工具函数是 Agent 能操作外部环境的桥梁。这里我们先定义几个最基础的工具。# tools.py import os import subprocess def write_file(path: str, content: str) - dict: 写入文件如果目录不存在则创建。 directory os.path.dirname(path) if directory: os.makedirs(directory, exist_okTrue) with open(path, w, encodingutf-8) as f: f.write(content) return {status: ok, path: path, size: len(content)} def read_file(path: str) - dict: 读取指定文件内容。 try: with open(path, r, encodingutf-8) as f: content f.read() return {status: ok, content: content[:3000]} except Exception as e: return {status: error, message: str(e)} def list_files(path: str .) - dict: 列出目录下的所有文件。 try: files os.listdir(path) return {status: ok, files: files} except Exception as e: return {status: error, message: str(e)} def run_command(command: str) - dict: 执行 shell 命令返回 stdout 和 stderr。 try: result subprocess.run( command, shellTrue, capture_outputTrue, textTrue, timeout30 ) return { status: ok, returncode: result.returncode, stdout: result.stdout[-2000:], stderr: result.stderr[-2000:], } except subprocess.TimeoutExpired: return {status: error, message: command timeout}注意这里的run_command使用了shellTrue这是为了演示方便。在实际生产项目中直接让 Agent 以 shell 方式执行命令有相当大的安全风险应该把命令白名单化或者把所有执行步骤放进沙箱容器中执行。4.2.2 Agent 主循环下面这段代码是 Agent 的核心逻辑# agent_loop.py import json from openai import OpenAI # 实际使用时换成你自己的 API Key client OpenAI(api_keyyour-api-key) TOOL_SCHEMAS [ { type: function, function: { name: write_file, description: 写入一个文件用于生成或修改代码, parameters: { type: object, properties: { path: {type: string, description: 文件路径}, content: {type: string, description: 完整文件内容} }, required: [path, content] } } }, { type: function, function: { name: read_file, description: 读取文件内容, parameters: { type: object, properties: { path: {type: string} }, required: [path] } } }, { type: function, function: { name: run_command, description: 执行 shell 命令比如启动服务、运行测试, parameters: { type: object, properties: { command: {type: string} }, required: [command] } } } ] def execute_tool_call(tool_call): 根据模型返回的工具调用执行本地函数。 from tools import write_file, read_file, run_command name tool_call.function.name args json.loads(tool_call.function.arguments) if name write_file: return write_file(args[path], args[content]) elif name read_file: return read_file(args[path]) elif name run_command: return run_command(args[command]) else: return {status: error, message: funknown tool: {name}} def run_agent(task: str, max_iterations: int 10): Agent 主循环思考 - 行动 - 观察 - 再思考。 messages [ { role: system, content: ( 你是一个软件工程师 Agent。你的任务是开发一个浏览器小游戏。 请遵循以下要求\n 1. 先规划再动手。\n 2. 每个文件写完后都要验证。\n 3. 出现错误时根据报错信息修复。\n 4. 只有验收标准全部满足才算完成任务。 ) }, {role: user, content: task} ] for step in range(max_iterations): print(f Step {step 1} ) response client.chat.completions.create( modelgpt-4o, messagesmessages, toolsTOOL_SCHEMAS, tool_choiceauto ) message response.choices[0].message # 模型认为任务完成不再调用工具 if message.tool_calls is None: print(Agent 最终回答, message.content) return True messages.append(message) for tool_call in message.tool_calls: print(f调用工具: {tool_call.function.name}) print(f参数: {tool_call.function.arguments}) result execute_tool_call(tool_call) print(f工具返回: {json.dumps(result, ensure_asciiFalse)[:500]}) messages.append({ role: tool, tool_call_id: tool_call.id, content: json.dumps(result, ensure_asciiFalse) }) print(达到最大迭代次数任务可能未完成。) return False if __name__ __main__: task 开发一个名叫“接苹果”Catch Apples的浏览器小游戏。 游戏规则 - 玩家用鼠标左右移动底部的篮子。 - 苹果从屏幕上方不断落下。 - 接住苹果得 1 分。 - 漏掉 3 个苹果游戏结束。 - 点击“重新开始”按钮可以重新开始游戏。 验收标准 - 使用单个 index.html 文件包含 HTML、CSS、JavaScript。 - 游戏中不能使用外部依赖。 - 页面在桌面浏览器上打开即可运行。 - 需要显示当前得分和剩余生命。 - 代码需要通过 JavaScript 语法检查。 run_agent(task)这是一个非常精简的 Agent 实现。它没有记忆压缩没有复杂的规划模块也没有并发执行能力但它具备了一个 Agent 最核心的能力能够循环调用工具来改变环境并通过观察环境反馈来修正下一步动作。在实际项目中你可能不会直接使用这种“手写循环”的方式而是使用 LangChain、AutoGPT、或各种 Agent 框架。但理解这个最小循环的原理对排查框架里的问题非常有帮助。4.3 Agent 自动生成游戏代码当 Agent 收到任务后它第一步通常是将游戏核心代码写入index.html。以下是 Agent 经过几轮迭代后生成的一个可运行版本代码里已经包含了我们要求的计分、生命、碰撞检测和重新开始功能。!DOCTYPE html html langzh-CN head meta charsetUTF-8 title接苹果Catch Apples/title style * { margin: 0; padding: 0; box-sizing: border-box; } body { display: flex; justify-content: center; align-items: center; min-height: 100vh; background: #1a1a2e; font-family: Arial, sans-serif; } #game-wrapper { text-align: center; } canvas { border: 2px solid #e94560; border-radius: 8px; background: #16213e; cursor: pointer; } #hud { color: #eee; margin-bottom: 8px; font-size: 18px; display: flex; justify-content: space-between; } #restart-btn { margin-top: 12px; padding: 8px 20px; font-size: 16px; background: #e94560; color: #fff; border: none; border-radius: 6px; cursor: pointer; } #restart-btn:hover { background: #c73652; } /style /head body div idgame-wrapper div idhud span得分: span idscore0/span/span span生命: span idlives3/span/span /div canvas idgame width480 height640/canvas br button idrestart-btn重新开始/button /div script const canvas document.getElementById(game); const ctx canvas.getContext(2d); const scoreEl document.getElementById(score); const livesEl document.getElementById(lives); const restartBtn document.getElementById(restart-btn); let score 0; let lives 3; let gameOver false; let lastTime 0; let appleSpawnInterval 0; let keyPressed false; const basket { width: 80, height: 20, x: canvas.width / 2 - 40, y: canvas.height - 40 }; const apples []; function resetGame() { score 0; lives 3; gameOver false; apples.length 0; appleSpawnInterval 0; updateHUD(); } function updateHUD() { scoreEl.textContent score; livesEl.textContent lives; } function spawnApple() { const x Math.random() * (canvas.width - 24); apples.push({ x: x, y: 0, size: 16, speed: 120 Math.random() * 80 }); } function drawBasket() { ctx.fillStyle #f5c542; ctx.fillRect(basket.x, basket.y, basket.width, basket.height); ctx.fillStyle #d49b2a; ctx.fillRect(basket.x 10, basket.y basket.height, basket.width - 20, 6); } function drawApple(apple) { ctx.beginPath(); ctx.arc(apple.x apple.size / 2, apple.y apple.size / 2, apple.size / 2, 0, Math.PI * 2); ctx.fillStyle #e94560; ctx.fill(); } function drawGameOver() { ctx.fillStyle rgba(0, 0, 0, 0.6); ctx.fillRect(0, 0, canvas.width, canvas.height); ctx.fillStyle #ffffff; ctx.font 36px Arial; ctx.textAlign center; ctx.fillText(游戏结束, canvas.width / 2, canvas.height / 2 - 10); } function update(deltaTime) { if (gameOver) return; // 生成新苹果 appleSpawnInterval deltaTime; if (appleSpawnInterval 1.2) { appleSpawnInterval 0; spawnApple(); } // 移动苹果 for (let i apples.length - 1; i 0; i--) { const apple apples[i]; apple.y apple.speed * deltaTime; // 判断是否被篮子接住 if ( apple.y apple.size basket.y apple.y apple.size basket.y basket.height 10 apple.x apple.size basket.x apple.x basket.x basket.width ) { score; apples.splice(i, 1); updateHUD(); continue; } // 判断是否落地 if (apple.y canvas.height) { apples.splice(i, 1); lives--; updateHUD(); if (lives 0) { gameOver true; drawGameOver(); return; } } } } function draw() { ctx.clearRect(0, 0, canvas.width, canvas.height); drawBasket(); for (const apple of apples) { drawApple(apple); } if (gameOver) { drawGameOver(); } } function gameLoop(timestamp) { const deltaTime Math.min((timestamp - lastTime) / 1000, 0.05); lastTime timestamp; update(deltaTime); draw(); requestAnimationFrame(gameLoop); } // 鼠标移动篮子 canvas.addEventListener(mousemove, (e) { const rect canvas.getBoundingClientRect(); const mouseX e.clientX - rect.left; basket.x mouseX - basket.width / 2; basket.x Math.max(0, Math.min(canvas.width - basket.width, basket.x)); }); // 重新开始 restartBtn.addEventListener(click, () { resetGame(); }); resetGame(); requestAnimationFrame(gameLoop); /script /body /html这是 Agent 自动生成代码的典型结果。你会发现它并不是特别复杂但逻辑完整能运行也符合验收标准。需要说明的是这里展示的是最终“接近可运行”的版本。真实执行过程中Agent 可能第一版会漏掉“生命值”“游戏结束”等功能也可能出现苹果碰撞检测逻辑不准的情况。这些都会在后面的“自动修复”环节被逐一解决。4.4 让 Agent 自测与修复生成代码只是第一步更重要的是验证和修复。Agent 的验证通常分几个层次语法检查用node --check检查 JS 语法。本地运行启动一个静态服务。浏览器冒烟测试用 Playwright 等工具访问页面检查控制台错误。行为测试模拟鼠标移动判断游戏能否执行关键交互。下面是一条典型的 Agent 验证命令node --check index.html不过node --check只能检查独立 JS 文件不能直接检查 HTML 内嵌的script块。实际项目中Agent 会把脚本提取成临时 JS 文件再检查或者使用 Playwright 加载页面。下面是一个用 Node.js 脚本做简单冒烟测试的示例// smoke_test.js const { chromium } require(playwright); (async () { const browser await chromium.launch(); const page await browser.newPage(); const errors []; page.on(pageerror, error errors.push(error.message)); page.on(console, msg { if (msg.type() error) { errors.push(msg.text()); } }); await page.goto(http://localhost:8000/index.html); await page.waitForTimeout(2000); // 模拟鼠标移动 const canvas await page.$(#game); const box await canvas.boundingBox(); await page.mouse.move(box.x box.width / 2, box.y box.height / 2); await page.waitForTimeout(1000); const scoreText await page.textContent(#score); console.log(当前得分:, scoreText); console.log(控制台错误:, errors.length ? errors : 无); await browser.close(); if (errors.length 0) { process.exit(1); } })();运行方式npm init -y npm install playwright node smoke_test.js如果 Agent 在冒烟测试中发现了问题比如“苹果碰撞检测不生效”或“点击重新开始按钮后分数没有重置”它会把报错信息或者测试失败信息重新拼进 prompt再调用write_file修复代码然后再次运行测试。这个循环会一直继续直到测试通过。这就是 Agent 自主开发的“反馈闭环”。它是整个系统中最有工程价值的部分。4.5 发布上线本地测试通过后Agent 需要把游戏发布到线上。以 GitHub Pages 为例发布流程如下初始化 Git 仓库。创建并提交index.html。推送到远程仓库的main分支或gh-pages分支。通过仓库设置开启 GitHub Pages。Agent 可以自动执行这些命令但你需要提前准备好一个有仓库创建权限的 GitHub Token。注意这里的 Token 应该只授予最小权限并且用作环境变量不能写死在代码里。# 初始化仓库 git init git add index.html git commit -m feat: catch apples game generated by AI agent # 添加远程仓库 git remote add origin https://github.com/yourname/catch-apples.git git branch -M main # 推送代码 git push -u origin main推送完成后在 GitHub 仓库的 Settings - Pages 中把 Source 设置为Deploy from a branch分支选择main目录选择/root。稍等片刻游戏就能通过以下地址访问https://yourname.github.io/catch-apples/Agent 拿到这个 URL 后会再次通过 HTTP 请求验证页面是否正常返回 200 状态码。确认无误后Agent 才会在最终回复中告诉人类任务已完成并附上线上地址。这里要特别提醒在生产环境发布时建议先发布到测试路径或者使用独立域名验证确认无误后再切换到正式入口。尤其是自动发布的流程一旦跑起来必须有回滚方案。5. 常见问题与排查思路AI Agent 自主开发虽然看起来很流畅但实际运行时几乎必然会遇到各种问题。下面是一些高频问题和对应的排查经验。问题现象常见原因解决思路Agent 陷入无限循环缺少最大迭代次数限制设置max_iterations超时强制停止生成了代码但无法运行模型“幻觉”或依赖未安装把运行时报错信息回传给模型继续修复上下文窗口被塞满工具返回日志太长截断工具输出或使用摘要压缩历史Node 命令找不到环境变量未配置在 prompt 中写明 Node 的安装路径部署到 GitHub Pages 失败Token 权限不足或仓库设置错误检查 Token 权限使用最小权限原则页面打开后空白JS 运行时错误用 Playwright 做冒烟测试捕获 console errorAgent 修改了无关文件工具调用边界不清晰在工作目录中创建独立沙箱文件夹API 调用超时请求耗时过长增加超时时间并做重试机制下面展开说明两个最常见问题的排查思路。5.1 Agent 陷入死循环怎么办现象Agent 反复执行同一个操作比如反复写入同一个文件或者反复运行同一条测试命令但结果没有任何变化。排查步骤检查 Agent 日志看它在循环中的“推理”内容是否相同。如果模型每次都说“我再试一次”说明它无法从当前状态中找到有效手段。检查工具返回是否包含足够信息。如果测试命令只返回“fail”没有具体报错模型就只能盲猜。提高工具返回的信息质量把 stderr、退出码、关键日志都返回给 Agent。解决方案除了设置最大迭代次数还要优化工具输出。一个原则是工具返回的信息要足够让模型判断“为什么失败”否则修复循环就无从谈起。5.2 部署后页面空白现象GitHub Pages 返回 200但浏览器打开后是空白页。排查步骤按 F12 打开开发者工具查看 Console 面板定位 JS 报错。检查文件路径。如果使用了相对路径或外部资源部署环境可能无法加载。检查脚本中是否使用了浏览器不支持的 API。在本地把部署目录用服务跑起来对比线上表现。解决方案在 Agent 的验收标准中强制加入“冒烟测试”环节用 headless 浏览器访问部署后的 URL并检查控制台是否有 error。这样可以在上线前就发现问题。6. 最佳实践与工程建议经历了“让 Agent 开发并发布一个游戏”的完整流程后有几个工程上的经验很值得沉淀下来。6.1 任务描述必须包含验收标准如果你只告诉 Agent “写一个游戏”它可能会写出各种你没想到的功能但偏偏缺了你最想要的那一个。更好的做法是像 4.1 节那样把规则、操作方式、验收标准全部写清楚。验收标准的作用有两个给 Agent 一个明确的“完成”定义让它知道何时停止。给人工审查提供一个检查清单方便确认 Agent 没有“自欺欺人”。6.2 坚持“Agent 生成、人工审查、自动化测试”三件套即使 Agent 能自主完成整个流程也不建议完全无人审核。尤其是涉及到线上发布时一位有经验的开发者做最后 review能拦截大部分模型“自认为正确但实际错误”的问题。推荐的流程是Agent 在分支或沙箱环境中生成代码并自测。人工审查代码变更检查安全问题。自动化测试跑一遍关键路径。合并代码并自动部署。6.3 安全边界给 Agent 一个沙箱如果 Agent 能执行 shell 命令那么它理论上也能执行任何命令包括删除文件、获取环境变量、访问网络。因此在正式环境中必须限制 Agent 的执行范围使用 Docker 容器运行 Agent容器内不挂载宿主机敏感目录。在容器外提供文件读写接口而不是直接给 shell。把run_command改成命令白名单方式比如只允许执行node、git、python3 -m http.server。严禁 Agent 直接接触生产数据库或生产服务器涉及生产变更必须走 CoPilot人审流程机制。6.4 每一次工具调用都要留日志Agent 开发过程的可追溯性非常重要。记录每次工具调用、参数、返回结果、耗时能够帮你定位是哪一步出了问题。复盘 Agent 的决策路径优化 prompt。评估 token 消耗和成本。一个最小日志结构可以是 JSON 格式{ step: 3, tool: run_command, args: { command: node --check script.js }, result: { returncode: 0, stdout: , stderr: }, timestamp: 2025-01-12T10:30:00Z }6.5 控制上下文避免 Token 爆炸Agent 写游戏这种小项目时上下文压力不大但如果项目变大就需要引入“摘要 检索”的机制。例如让 Agent 先列出项目结构只读取需要修改的文件。工具返回内容限制在 2000 字符以内。对已经完成的历史对话做摘要压缩到几百字符。这样既能保持 Agent 对全局的感知又能控制成本。6.6 不管用什么框架核心都是“任务拆解 反馈闭环”目前市面上的 Agent 框架很多有的是“计划 执行”架构有的是“多 Agent 协作”架构。但剥开外壳所有 Agent 的核心能力都离不开理解目标并拆解成步骤。调用工具改变环境。观察结果并调整策略。理解了这一点你就能很快上手任何框架也能在框架出问题时定位到具体环节。7. 总结与下一步方向通过这篇文章我们从概念到实战完整走了一遍 AI Agent 自主开发并发布浏览器游戏的流程。现在你应该已经理解AI Agent 不只是聊天机器人它是一个具备“规划 工具调用 环境反馈”能力的自主系统。Agent 开发游戏的过程不是“一次生成”而是“写代码 - 验证 - 报错 - 修复 - 再验证”的循环。一个最小 Agent 系统可以由几行核心代码实现关键点在工具设计和执行循环。自动发布不是不能做但必须在安全边界内操作并保留人工审查和回滚机制。如果你打算继续深入我建议按以下路线学习先手写一个更完善的 Agent 循环加入记忆压缩、命令白名单、日志记录。尝试接入不同模型观察它们调用工具和修复 Bug 的差异。让 Agent 开发一个带后端接口的小应用比如“留言板”这会引入数据库和服务器部署的问题。学习 LangChain、AutoGPT、LangGraph 等框架了解它们在任务规划和多步骤执行上做了哪些优化。如果你想在企业里落地重点关注权限控制、审计日志、测试覆盖率和回滚机制这比模型本身的“聪明程度”更重要。AI Agent 自主开发的能力每天都在变强。但有一点不会变它能走多远很大程度上取决于我们给它设计的工作流边界是否清晰、反馈回路是否高效。希望这篇实战笔记能帮助你迈出第一步亲手搭一个属于自己的 Agent 开发流水线。如果你按照流程跑通了自己的小游戏欢迎在评论区交流过程中踩过的坑。