让 Agent 修改代码，通常很快就能得到结果。但让它把一个需求做到上线，过程会长得多：服务在哪里创建，接口怎样接入，代码怎样发布，测试请求会打到哪个环境，失败以后又该去哪里找原因。

这些步骤过去常常依靠开发者对团队系统的熟悉程度。Agent 接手以后，原来藏在操作习惯里的知识，需要变成它能够找到的说明、能够调用的工具，以及能够判断的执行结果。本文以我们的后端开发环境为例，介绍这条链路如何组织。

业务拆成多个服务之后，数据也分散到了不同的数据库中。项目、内容、推荐和通知各自维护自己的表，但运营分析往往需要把这些数据放在一起：按天看项目生成情况，关联内容的发布与曝光，再按不同维度计算中间结果。

我们为此建设了独立的分析库，并把生产 PostgreSQL 到分析库的同步交给 GamePlatform 管理。底层使用 Debezium 读取数据库变更，平台负责接入范围、表映射、运行调度和故障恢复。本文介绍这条链路如何工作、上线后遇到的具体问题，以及我们为什么在已有阿里云 DTS 的情况下继续建设它。

在 Combos，Agent 生成的 H5 游戏最初主要在浏览器里运行。要增加排行榜、云端存档和多人房间，就需要给每个游戏准备一个能够保存数据、交换消息的后台。我们在 2026 年 4 月接入 Supabase，9 月开始把新游戏的联机方案切换到 Cloudflare Workers 与 Durable Objects，后文简称 Worker 和 DO。

这次选型涉及两个阶段的目标：早期先让 Agent 能够开通后端、使用数据和联机能力；后来，实时对局需要一个稳定的服务端来执行规则，大量低频访问的游戏也开始暴露实例启停与闲置成本问题。下面结合当时的讨论、代码变化和目前的实现，分别介绍两套方案如何工作，以及我们做了哪些取舍。

用户让 Agent 安装了一个工具，安装成功，任务也执行完了。过一段时间回来继续用，项目文件都在，再执行那个命令却变成了 command not found。

我们遇到的就是这类问题。用户可以在 Sandbox 里安装软件，而实例回收、重新创建以后，安装过的东西没有跟着回来。

上一篇文章讨论了如何把源码留在 NAS，把依赖安装和构建放到本地盘。这次要继续看工作区之外的内容：软件到底装在哪里，怎样让这些安装结果跨实例保存，以及三种持久化方案各自需要解决什么问题。

一个新项目还没有开始修改代码，准备过程就先等了六七秒。拆开日志以后发现，其中接近一半时间花在初始 Git 推送上。

2026 年 4 月 6 日，测试环境两次新项目准备的平均耗时是 6.66 秒，负责推送的 push_remote 步骤平均用了 2.90 秒，占约 43.6%。沿着这次推送继续看，Gitea 服务端的仓库目录挂在 NAS 上，文件存储由此进入了排查范围。

后面我们又测了不同文件系统上的依赖安装和构建，遇到了“包已经缓存，安装仍然很慢”的问题。这篇文章从 Git push 开始，沿着这些测量与实现，讲到 NAS 选型，以及本地盘上的依赖和编译。

Agent 接收到任务后，会多次调用模型和工具，直到任务结束。组织这个过程的程序称为运行时，也就是 Runtime。

本文讨论两种部署方式：由中心服务运行 Agent，通过远程接口操作工程；或者把 Codex 放进 Sandbox，由沙箱内的引擎直接操作工程。下面分别介绍它们的组成、数据存储、执行过程，以及中断后的恢复方法。

生成链路最初由两个核心服务组成：Gateway 接收请求并处理项目接口，Runtime 运行 Agent，调用模型和工具，返回执行过程与结果。

随着业务增加，项目管理、调度和不同客户端的接入逐步拆开。服务之间的调用、环境选择、发布与排障，也需要相应调整。本文按这些问题的出现顺序，介绍各阶段的结构和实现方法。

游戏 Agent 的目标是把用户需求转换成一个可以运行的游戏。这个过程包含需求分析、素材生成、代码修改、测试和发布，需要模型与业务系统共同完成。

本文记录我们在实现这条链路时做过的几次调整，依次介绍 Prompt、多 Agent 分工、Skills、工具接口和任务恢复。每一部分说明原来的实现、遇到的问题，以及后续采用的处理方式。原生引擎的接入状态以本文最初整理时为准。

市面上的 ios 功耗采集工具往往通过 电池瞬时放电电流 x 电压 来计算 IOS 系统的瞬时功耗。那么有没有一种方法在有线连接时也能反应设备的功耗呢？ 这篇文章介绍 SystemLoad参数，并验证其有效性。

学习ELuaProfiler和Miku-LuaProfiler，讨论 lua profiler 的前置能力 希望通过学习主流的 lua profiler 的前置能力，来讨论 webgl 平台 lua profiler 的可行性