想用一个低延迟模型玩游戏，最省事的起点是找一套已经能运行、还能看清决策过程的项目。画面动起来只是第一步：还要知道模型看到了什么、返回了什么，以及代码有没有替它改动作。
这次筛选了十个现成项目，重点读了三套实现：PlayJev、本地 Laya 与 Jev 的对战 Arena，以及社区 Playground 里的 MicroDuck。它们分别代表画面输入、游戏状态输入和传感器输入三条路线。本文整理源码与启动方式，没有把作者报告的速度和得分当作自己的复现实测。
过去一年，很多团队已经不再问“哪个模型更会写代码”，而是在问另一个更产品化的问题：当团队里同时存在人类工程师和一组 coding agents，谁来分配任务、记录进度、保存上下文、管理运行机器和复用经验？
Multica 的回答不是再造一个 coding agent，而是把 Claude Code、Codex、Hermes、Cursor Agent、OpenCode 等本地 AI coding tools 包成一个协作系统：Agent 出现在 assignee picker 里，issue 会触发 task，runtime 负责 claim 和执行，结果再写回 issue timeline。
“文件分享”至少有三种完全不同的产品：一种把 目录/文件名 直接变成 URL；一种上传后生成高熵临时链接；还有一种提供 S3 bucket/object API，接近七牛、MinIO 和对象存储。
如果不先把这三类分开，很容易一边比较极简文件服务器，一边又把完整 Web 产品和分布式对象存储拉进来，最后得到一个没有决策价值的功能总表。
这篇围绕 ChatShare 的第一阶段目标做静态调研：一个共享 Key、上传/下载 API、文件名或 object key 与 URL 明确关联、尽量轻量、不把账号体系和存储集群提前塞进来。
AutoResearch 最容易被描述成一条越来越长的流水线：搜论文、提 idea、改代码、跑实验、画图、写 LaTeX，再让另一个模型 review。按照这个口径，覆盖阶段越多，系统就越接近“AI Scientist”。
但两个代表项目给出了相反信号。
karpathy/autoresearch 只允许 Agent 修改一个 train.py，每轮训练 5 分钟，只看一个 val_bpb；AI Scientist-v2 则从主题、idea 和文献一路走到实验树、论文与 review。后者的行动空间大得多，官方 README 却明确提醒：开放探索的成功率低于模板更强的 v1，有强起始模板时也不一定生成更好的论文。
这不是“简单 Agent 比复杂 Agent 聪明”，而是两套系统承担了不同的验证债务：Agent 每多获得一种行动能力，系统就必须多证明一件事——它没有因为扩大搜索、重复看分数、选择性报告或自我审查而制造假改进。