一个桌面放置游戏进度不是靠定时器模拟而是由一个真实的 coding-agent 在后台写代码、改文件、跑测试来推动。这个项目把“玩家点击——游戏产出”变成了“玩家下发任务——AI 代理真实完成——游戏结算奖励”。核心不是游戏画面多精致而是它成功把真实开发行为映射成了增量游戏的成长曲线。对两类人来说这个项目特别值得研究一类是玩过 Cookie Clicker、Melvor Idle 这类放置游戏的玩家好奇“如果游戏里的资源真的来自现实劳动”会是什么体验另一类是关注 coding-agent 落地形态的开发者想看看除了自动补代码、修 issue 之外AI 代理还能被包装成什么有趣的东西。下面我按实际运行、核心循环、挂机坑位和自制原型四个方向拆一遍。1. 先说结论它不是“装成写代码”的放置游戏而是“真的在写代码”1.1 项目把“真实劳动”当成游戏增量来源增量游戏最常见的做法是设置一个间隔计时器每隔几秒给你加一点金币、经验或材料。玩家看到数字增长本质上只是程序在后台累加。这个项目最大的不同在于增量来源是编码代理的真实执行结果。一个典型循环是这样的游戏里有一个任务队列玩家或系统往队列里塞任务编码代理拿到任务后按真实开发流程执行——创建文件、修改代码、跑命令、读输出、再修改直到任务完成。任务完成的判定不是游戏虚构的而是代理确实把代码写出来了、把测试跑过了。这时候游戏才给玩家结算对应奖励。这个设计的妙处在于游戏里每一个金币、每一段经验值背后都有真实事件作为依据。玩家看到“我的代码仓库多了一个功能模块”和“我的游戏角色涨了一级”同时发生而且二者因果关系是真实的不是随机数。1.2 它解决的实际问题不是“好玩”而是“让代理过程可见”编码代理目前最大的使用痛点之一是过程不透明。你给它一个需求它吭哧吭哧跑几分钟最后给你一个结果中间发生了什么、哪些尝试失败、为什么选这个方案很多时候玩家根本不知道。这个桌面游戏等于给代理执行过程加了一层可视化外壳。任务状态、执行步骤、产出文件、耗时统计都被包装成游戏里的任务进度条、奖励弹窗和资源收入。玩家看到的不再是黑盒调用而是“代理正在读文件”“代理正在安装依赖”“代理正在修改配置”这些过程节点。所以它的价值不只是娱乐而是提供了一种观察 coding-agent 行为的交互方式。从这个角度看它更适合被当作“代理执行可视化工具 游戏化外壳”来理解而不是单纯一个游戏 DEMO。1.3 和普通增量游戏的核心差异看这张表对比项普通放置游戏coding-agent 驱动的放置游戏产出来源定时器累加编码代理真实任务执行资源依据随机数或固定公式真实文件变更、命令输出、测试结果失败影响几乎无感任务失败会中断产出需要重试或换方案成本无每次任务调用会有模型服务成本可复现性确定性高代理行为有随机性结果不完全可预测新手友好度低门槛需要先配好代理环境和开发目录2. 运行前先弄清楚三件事通信、成本和安全边界2.1 桌面壳和编码代理是怎么配合的这个项目基本可以拆成两层外层是桌面应用负责游戏界面、任务展示、奖励结算内层是编码代理负责真实执行开发任务。两层之间需要一套通信机制。常见的做法有几种桌面应用直接调用代理提供的命令行接口启动一个子进程把输入输出重定向到游戏日志系统。桌面应用通过本地 HTTP 服务或 WebSocket 与代理服务通信代理服务独立运行二者通过端口交互。桌面应用读取代理生成的日志文件和工作目录快照用轮询方式判断任务状态。具体用哪种取决于作者在项目里怎么接的。但这三件事是通用的任务输入要能传给代理代理输出要能被游戏读取任务状态要能从“排队”切换到“执行中”再到“完成”或“失败”。2.2 资源和成本不能忽视这是最容易让新手误判的地方。普通放置游戏开一晚上没问题但这种由真实代理驱动的游戏每执行一个任务都要调用模型推理服务。如果你用的是云端大模型 API那每次任务的 token 消耗都是真金白银。我的建议是第一次运行先看三样东西单次任务的平均消耗包括输入 token、输出 token 和执行时长。任务的频率控制是不是每个任务都必须完整跑完一个代理循环。有没有缓存或结果复用机制同一个任务反复执行是否会重复计费。如果只是体验可以选择本地小模型或者限制任务队列长度。不要把任务频率设得太高否则你可能睡一觉起来发现账单比游戏数据增长得还快。2.3 权限边界必须提前收紧编码代理意味着它能在你电脑上真实执行命令、读写文件。如果游戏把代理接入到你的个人开发目录那它就有能力修改这些文件。这里一定要做好权限隔离。我建议至少做到以下几点给游戏单独建一个工作目录不让代理直接操作你的正式项目。检查代理的允许命令列表默认不要开放任意 shell 命令。任务来源如果来自网络或社区要仔细看是不是存在恶意指令注入的可能。定期备份工作目录尤其是你想长时间挂机的情况下。注意任何 coding-agent 驱动的应用本质都是一台能执行命令的本地机器。第一次运行前先看一眼它到底会在哪个目录下做什么比急着看游戏画面重要得多。3. 第一次运行怎么判断代理真的在干活而不是装样子3.1 一次完整启动流程大概长这样虽然不同项目的入口不一样但通用的启动顺序大致是安装基础运行环境通常需要桌面应用对应的语言运行时和 Node、Python 之类的开发环境。配置编码代理的后端模型地址、API Key 和工作目录。启动桌面应用检查任务面板是否出现初始任务。观察日志输出确认代理开始执行而不是一直停在初始化状态。第一次跑不要急着接复杂任务。先给一个最小任务比如“创建一个名为 hello.txt 的文件内容为 hello world”然后看它能不能完整闭环。3.2 成功和失败的判断标准一个任务真正完成的判断标准不是游戏界面上出现了“任务完成”四个字而是以下条件同时满足工作目录里确实出现了对应文件或代码变更。命令行执行记录里有完整的命令和输出。游戏日志里记录了任务从开始到结束的时间线。如果任务包含验证步骤验证命令必须执行成功。如果这些条件里只有界面显示完成但文件目录没有任何变化那说明游戏只是给代理发了个请求但代理的产出没有被正确回收。这时候优先检查代理的输出解析逻辑看它是依据什么来判断“完成”的。3.3 我常用的验证方法是直接看工作目录比起盯着游戏界面我更习惯直接打开工作目录看文件。游戏界面可能美化真实性但文件系统不会骗人。跑完第一个任务后我一般会执行这样几个检查# 查看工作目录下新增了哪些文件 find . -type f -mmin -10 # 看最近一次任务产生的文件内容是否跟预期一致 cat hello.txt # 查看代理执行日志的最后 50 行 tail -n 50 agent.log如果文件存在、内容正确、日志时间线完整那基本可以认为这套链路是通的。下一步再考虑给游戏加真实任务。3.4 第一次运行最容易出现的三个问题第一个问题是代理根本没有拿到任务。原因通常是任务队列和代理进程之间的通信没建立客户端把任务发到端口但代理服务没监听。第二个问题是代理执行了任务但游戏没有收到完成事件。这往往是代理和游戏之间的状态同步只靠进度日志解析而解析规则没覆盖代理所有可能的输出格式。第三个问题是环境依赖不完整。代理执行任务时可能尝试安装依赖但桌面应用没有给代理足够的权限或者网络环境不允许访问包管理器。看到“任务失败”之前先确认失败日志到底是模型报错、权限报错还是网络报错。4. 核心循环拆解任务队列、奖励曲线和升级逻辑4.1 任务从哪来决定了游戏能不能持续放置游戏最怕内容耗尽。这个项目里任务来源的设计直接决定了长期可玩性。可能的方向有三类固定任务集项目内置一批写好的开发任务玩家按顺序解锁。玩家自定义任务玩家在输入框里描述需求代理执行。系统生成任务由另一个 LLM 根据当前仓库状态、用户目标或游戏进度自动生成下一个任务。固定任务集最简单但玩两小时就腻了。玩家自定义任务有互动感但对任务格式校验要求高。系统生成任务最可持续但需要额外接一个任务规划模型而且生成质量不稳定时会影响游戏体验。我自己的判断是做原型阶段先用固定任务集验证闭环跑通后再考虑系统生成。不要一开始就上自动生成否则你很难判断到底是游戏逻辑有问题还是任务生成本身有问题。4.2 奖励曲线要和任务难度匹配增量游戏的核心是奖励曲线。如果所有任务奖励一样玩家很快失去目标如果奖励曲线设计得太陡玩家会觉得后期无所事事。基于实际代理任务奖励可以这么设计任务类型复杂度典型耗时建议奖励档位创建单个文件低10-30 秒基础修改一个函数低20-60 秒基础偏上新增一个小功能模块中2-5 分钟中等重构整个模块高5-15 分钟高修复一组失败的测试中高3-10 分钟中高完成一个跨文件的完整特性高10 分钟以上高奖励不仅要看任务数量还要看任务是否真实完成、是否包含验证步骤。一个只改了代码但没有跑测试的任务奖励应该低于附带测试验证的任务。这样才能引导玩家和代理都去做更完整的工作。4.3 升级系统的本质是缩短时间或扩大任务池放置游戏的升级系统本质上是两种形式要么让单位时间产出更多要么解锁新的可玩内容。在这个项目里“单位时间产出更多”可以体现为代理并发数提升、任务队列容量扩大、执行速度优化。“解锁新内容”可以体现为新的任务类型、新的工作目录、新的代码仓库或者更复杂的技术栈。不过这里有一个和纯虚拟游戏不同的坑提升并发数不等于真正提速。如果你的代理后端是单请求模型服务同时跑多个任务只会排队不会并行。升级面板里写的“并发 1”必须要落到真实的任务调度层才有意义否则只是一个没有实际效果的数值。5. 长时间挂机最容易踩的坑5.1 速率限制和接口配额挂机是放置游戏的标配玩法但带 coding-agent 的放置游戏挂机时要格外小心。绝大多数模型服务都有速率限制和配额限制你可能连续跑了几十个任务之后突然发现所有任务都开始报错。处理方式记录每个任务的系统级错误区分速率限制、超时、配额不足和模型侧错误。遇到速率限制时采用退避重试不要立即拼命重发。设置单日任务上限超过后游戏自动进入“休眠模式”只展示进度不触发新任务。我建议把“配额不足”当成一种游戏事件来设计。比如当天额度用完后游戏显示“代理疲惫了明天再来”既避免成本失控也比直接报错更有游戏感。5.2 工作目录会越挂越乱代理执行几十个任务以后工作目录里会堆积大量临时文件、未提交的改动、互相冲突的代码片段。如果没有清理机制后期代理自己都会看花眼任务成功率明显下降。解决思路每个任务使用独立子目录避免任务间互相干扰。定期清理临时文件和缓存目录。任务开始前先记录当前 git 状态任务结束后对比变更内容判断改动了哪些文件。如果支持沙箱尽量在隔离环境里让代理执行命令。5.3 任务卡死和输出一致性问题卡死是这类项目最让人头疼的问题。代理可能在等待模型响应可能在等待用户确认也可能陷入一个死循环反复执行同一个命令。游戏界面看起来还在运行但其实已经完全不推进了。我的排查顺序是这样的先看代理进程的 CPU 和网络占用判断它是不是真的还在干活。再查看最近一条日志的时间戳如果超过阈值没更新基本可以判定卡死。如果卡在模型请求阶段检查网络和模型服务状态。如果卡在命令执行阶段检查命令是不是在等待输入。输出一致性问题则是另一个隐蔽坑。同一个任务代理第一次用一个方案第二次可能用另一个方案导致产出文件结构不一致。如果你后面要做批量任务或自动化评估一定要先固定任务验收标准比如必须包含哪些文件、必须通过哪些测试、代码风格必须符合哪个规范。注意挂机不是搭好环境就不管了。合理的设计应该是在任务失败到达一定次数后自动暂停并且把失败任务单独放一个队列避免失败任务污染后续任务。6. 如果自己做同款原型怎么最小化起步6.1 一个最小可运行的架构如果你看过这个项目之后也想做一个同款原型我建议不要一开始就做完整桌面游戏先做一个最小闭环一个任务输入 一个代理执行 一个结果展示。最小架构可以这样拆任务输入一个 JSON 文件或简单的输入框。代理执行复用现成的 coding-agent 开源框架不自己实现代理逻辑。状态记录把代理输出重定向到日志文件。结果展示一个本地网页或命令行界面轮询日志文件显示状态。对应的目录结构大概是这样game-root/ ├── tasks/ # 任务定义 ├── workspace/ # 代理工作目录 ├── logs/ # 代理和游戏日志 ├── config.json # 模型、路径、并发配置 └── game-loop.py # 游戏主循环6.2 核心代码不需要很复杂真正的核心逻辑就三块读任务、调代理、写状态。伪代码形式大概是for task in task_queue: # 把任务写入代理输入 result agent_execute(task, workspace) # 把执行结果写入日志 append_log(task.id, result) # 根据结果结算游戏奖励 if result.success: player.gold reward_for(task) else: task_retry(task)这里最需要花心思的是agent_execute返回结果的结构化解析。代理输出通常很冗长你必须从中提取出“是否完成”“改了哪些文件”“测试是否通过”这些关键字段。如果这一步做不好后面所有奖励结算都会失真。6.3 建议的起步顺序按这个顺序推进踩坑成本最低先跑通一个命令行版的最小闭环不写任何界面。确认任务从输入到执行到结果判定全链路可用。再加一个简单的界面层展示日志和任务状态。然后设计奖励曲线和升级逻辑。最后才考虑任务自动生成、并发队列、沙箱隔离这些高级功能。6.4 值得扩展的方向这个项目真正有意思的地方在于它打通了“真实劳动”和“虚拟奖励”之间的映射。往远处想有很多可扩展空间把任务结果做成可视化的“代码贡献时间线”玩家可以看到自己的游戏进度快照对应的代码仓库演化过程。根据代理最终产出的代码质量评定游戏成就比如“首次通过全部测试”“完成一次跨文件重构”。把多人玩法做成团队副本多个玩家各自运行代理共同完成一个更大的代码任务。把任务池做成玩家之间互发任务让“给别人写需求”也成为游戏机制。不过这些方向都应该放在最小闭环验证之后再考虑。先确认一件事游戏里的增量是否真的等于代理产出的增量如果是这个项目就已经成功一大半了。我自己试过类似方案之后最大的体会是这类项目最大的风险不是技术实现而是设计失衡。如果代理执行太快游戏会变成“排队看演示”失去游戏性如果奖励和真实产出脱节又变成了套了一层壳的普通任务管理器。真正合适的节奏是让玩家既能感受到真实代理在工作又愿意为了游戏里的目标不断给代理安排更有挑战的任务。这个平衡点花多少时间调都值得。