最开始，我们这条生成链路的核心就是两个服务：一个 Gateway，一个 Runtime。

Gateway 接用户请求，处理项目相关的接口，再通过 RPC 把执行交给 Runtime。Runtime 跑 Agent，调模型和工具，维护执行状态，把过程和结果传回来。项目、素材、用户以及各种外部依赖，很多都围着这两个服务接。

当时这么做很自然。产品还在快速变化，先把一条生成链路跑通，比提前设计十几个服务更重要。两边接口对齐，部署两个应用，就能开始验证。

但今天再看，前面有 NLB 和 Nginx，有按业务划分的 Gateway，也有面向移动端的 WAP；后面有项目服务、调度、Runtime 和其他领域服务。旁边还长出了一整套环境管理、发布、监控、日志和告警。

这些东西是怎么一步步长出来的？我觉得值得讲的，是每次拆开一个边界以后，我们又必须补上什么。

服务拆开了，调用关系就要有人管理；允许不同版本同时跑，环境选择就要贯穿整条链；发布不再只有两个应用，制品、目标和运行结果就必须能对得上。 后面的研发平台，就是沿着这些问题做出来的。

刚开始做游戏 Agent 的时候，我们其实挺迷茫的。

目标很清楚：用户说一个想法，最后拿到一个能玩的游戏。但对于模型，我们还没有建立起足够清楚的判断。它能独立完成多长的一段工作？什么时候需要拆开？做不好，是模型能力的问题，还是我们给它的信息和工具有问题？

我们先写长 Prompt，再补各种工具，后来按开发、配置、美术拆 Agent，又把一部分能力放回主 Agent。这中间最值得复盘的，是我们对这些问题的理解怎么变了。

现在回头看，我觉得早期有几类问题被混在了一起：模型暂时做不到的、模型缺少游戏知识的，以及系统本身没有处理好的。于是解决办法也容易混在一起，最后都变成更多的提示、角色和流程。

模型往前走以后，这种做法就需要重新考虑了。我们逐渐学会先判断模型已经能够承担什么，再决定自己还需要补什么。 这也是我理解的 follow 模型的发展方向。

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

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

ToLua是Unity开发者常用的Lua框架，这篇文章分析了其如何利用UserData将C#Object托管到Lua中使用，介绍了了Lua中的UserData机制。

ToLua 能够实现 C# 与 Lua 之间的互通，这篇文章分析这一机制的实现原理

使用Lua开发过程中经常需要使用第三方库扩展lua的能力, 这篇文章介绍如何引入 & 实现第三方库

XLua 实现了 unity 中 c# 脚本与 lua 脚本之间的互调功能，并且提供了热更的能力，这篇文章学习 XLua 的使用

了解LevelDB对外暴露的接口使用方法，并揭示其数据结构、执行流程。

从完成一个grpc服务开始逐步搭建微服务集群