2026-08-22 18:38:00
「这个结果太疯狂了。」
本周五，AI 社区热烈讨论的是一个端侧大模型部署技术，它能让笔记本 RTX 4060 跑 Qwen 3.6-35B，桌面 RTX 5090 跑得起 DeepSeek-V4-Flash 284B。而且都是单卡，模型都是满血的。
Codex 生产 trace 的中位 decode 速度是 33 token/s，笔记本 RTX 4060 跑 Qwen3.6-35B 的 39.3 token/s 已经超过了这个数。
来自 UC Berkeley、MIT 等机构的联合团队开源了名为 FreeToken 的全新开源边缘端推理系统。并列一作杨硕（Shuo Yang）是伯克利 EECS 博士生，范晓泽（Xiaoze Fan）在 UT Austin，两人本科均毕业于上海交通大学。FreeToken 的作者还包括 Ion Stoica、Matei Zaharia、Kurt Keutzer、韩松等顶尖学者。
该系统专门针对 MoE（混合专家）大模型在消费级硬件上的本地部署进行了全栈协同设计，打破了大规模前沿模型必须依赖数据中心集群的硬件门槛。
论文：《FreeToken: Efficient Edge-Native MoE Serving with Bandwidth-Adaptive Execution》
论文链接：https://arxiv.org/abs/2608.16157
GitHub：https://github.com/FlashML-org/FreeToken
官网：https://www.flashml.ai/
FreeToken 现在已经提供了 Windows / Linux 桌面 App（带 GUI），CLI 一行 uv pip install "freetoken [accel]" 即可载入。
消费级硬件能跑什么？
传统的 CPU-GPU 权重卸载（Offloading）方案往往因为 PCIe 带宽瓶颈导致推理速度极慢（每秒几 token 甚至卡顿），而 FreeToken 实现了「交互级实用速度」的本地推理。
除了每秒 Token 速度，在处理长 Prompt（如 4-16k 上下文）时，传统 Offloading 方案因逐层从系统内存拉取 Expert 导致严重 I/O 阻塞。FreeToken 将首 Token 延迟（TTFT）降低了 42-58%。
针对如今常见的 Agent 工具，如 Claude Code、OpenClaw 等循环交互、逐步追加上下文的场景，在多次工具调用与思维链（CoT）迭代中，由于 FreeToken 引入的 Token 边界轻量级检查点与状态复用，后续多轮交互的 TTFT 减少了 65-80%。
论文在不同 PCIe 规格（PCIe 3.0 x8、PCIe 4.0 x16、PCIe 5.0 x16）及不同 CPU（如 Intel i7、AMD Ryzen 9、Threadripper）下进行了测试，当系统后台有其他高 I/O 任务抢占总线时，算法可以自动提升 CPU 端分流计算比例；当总线空闲时则提升 GPU 载入比例。
也就是说，无论处于何种总线带宽受限环境，系统均能稳定收敛至该硬件拓扑下的理论最大吞吐上限。
论文作者还做了压力测试，模拟用户在后台开启 3D 渲染、游戏导致可用显存骤降 4-8GB 的场景。传统方案会直接触发 CUDA Out of Memory (OOM) 崩溃退出，FreeToken 可以在 0 停机开销下无缝收缩 GPU 驻留的 LRU Cache 大小，将更多未命中 Expert 转交 CPU 计算，保证推理服务平滑降级而不中断。
可以说，现在跑大模型不需要死磕模型 100% 上显存了。
对于 MoE 这类稀疏激活架构，只要通过软硬件协同的「动态带宽感知 + 双缓冲数据流 + 状态复用」，完全可以利用 PC 上较为常见的 DDR5 大内存 + PCIe 高带宽通道 + 消费级单卡，以极高性价比获得可以日常个人使用的体验。
当然这意味着显存不够，内存来凑。比如 DeepSeek V4 Flash 的专家池约 140GB，就需要 32GB 显存（RTX 5090）加上最好有 192GB 的内存来跑才比较稳。
为什么 FreeToken 能做到？
如今，大模型开放权重解决的是谁能拿到模型，没解决「谁能跑得起模型」。 Kimi-K3、GLM-5.2、DeepSeek-V4-Flash 的能力已经逼近闭源第一梯队，但跑它们仍然默认要数据中心。结果就是能力的差距在快速收窄，可及性的差距还是很大。
如果以游戏平台 Steam 观之，大家的电脑约 72% 有 N 卡，其中最常见的单卡是笔记本版的 RTX 4060，如果大模型能把它们用起来情况就会大不一样。那么就需要一个能把 GPU、CPU、主机内存、互连当成一个统一平台来调度的服务系统。
MoE 恰好给了我们这个机会，以目前最火的 DeepSeek-V4-Flash 为例，它有 284B 总参数、43 层、每层 256 个路由专家选 6 个，单 token 只激活 13B。在部署精度下，活跃参数量塞得进 RTX 5090 的 32GB。
但稀疏只减少了计算，没有等比例减少内存，完整专家池仍然远超显存。当前的瓶颈在于，Prefill 会摧毁 MoE 的稀疏性：单个 token 只走 k 个专家，但一个长 prompt 里所有 token 路由的并集，几乎覆盖每层的全部专家。于是每次 prefill 都要把接近完整的专家池流过 PCIe 一遍。
在 DeepSeek-V4-Flash 的部署上，FP4 部署要搬约 140GB 专家权重，RTX 5090 需要额外的两秒钟，按需取专家的引擎，会把这整段暴露成 GPU 空转。
雪上加霜的是 Agent 每轮工具调用都会改上下文。而 Qwen3.6-35B 用 gated DeltaNet、Kimi-K3 用 KDA 这类循环层，会把整段前缀压成一个演化状态，不能局部复用，只能靠 checkpoint。一个 checkpoint 占的内存相当于几百 token 的 KV，所以引擎只能存少量。上下文一改，改动点之后的 checkpoint 全部失效，只能回退到上一个有效点，重算几千 token。而 RTX 5090 的 dense BF16 吞吐只有 H100 的约 1/5、B200 的约 1/10，扛不住这种重复劳动。
FreeToken 的解法是重新定义了端侧异构硬件的协同调度逻辑：
全层双缓冲（Double-Buffered Prefill）。在 Prompt 处理阶段，FreeToken 实现了计算与数据搬运的完全重叠：当 GPU 正在计算第 l 层时，第 l+1 层的 Expert 权重已经通过 PCIe 后台预取流式传输，基本消除了 I/O 等待气泡。
带宽自适应的混合调度（Bandwidth-Adaptive Execution）。运行时实时探测本机的 PCIe 实际带宽 与 CPU 瞬时算力，动态计算出最优分流比率 q*。一部分 Expert 命中 GPU LRU 缓存，未命中部分根据实时带宽智能分流，部分传输到 GPU，部分直接原地在 CPU 并行计算，将硬件吞吐拉到极限。
面向 Agent 的智能状态复用（Agentic State Reuse）。现代 Coding Agent 或工具调用模型会频繁微调 / 修改上下文历史（如添加思考步骤或工具返回结果）。FreeToken 在特殊 Token 边界设置轻量检查点，遇到上下文编辑时仅需从最近锚点恢复并增量 Prefill，避免重复计算整个上下文。
弹性显存动态热扩缩容。针对个人电脑经常有其他应用（如游戏、浏览器、开发工具）抢占显存的情况，FreeToken 支持在不重启 Serving 服务的前提下动态热调整显存中的 Expert Cache 大小，保证服务不中断。
其中面向 Agent 的机制非常有趣，这么做可以说是真的是瞄准如今热门的 Agent 任务在优化了。
结语
FreeToken 证明了让大模型走向普及的关键，不仅在于开源模型权重，更在于端侧调度软件系统的工程设计与算法重构。
通过将个人电脑的 CPU、系统内存、PCIe 总线与 GPU 作为一个统一的弹性计算平台，开发者和个人用户今后完全可以在本地笔记本或游戏 PC 上跑起顶尖 MoE Agent，极大降低了本地部署高智能模型的成本。
好了，现在就差个传说中的 Qwen3.8-A3B 了。
© THE END
转载请联系本公众号获得授权
投稿或寻求报道：[email protected]
2026-08-22 18:38:00
大模型圈流行「挂马甲」测试。
近日，一款名为 Ox Alpha 的匿名模型突然出现在 OpenRouter。Ox 本身就是「牛」的意思，国内网友很快给它起了一个更接地气的名字：
「牛来」大模型。
根据 OpenRouter 披露的信息，Ox Alpha 拥有 100 万 token 上下文，支持文本、图片和视频输入，可以调用工具，目前完全免费。
上线后不久，开发者就把它接入编码 Agent，扔进真实代码仓库进行测试。
初步测试结果显示，这款来历不明的「牛来」大模型，能力已逼近当前顶级代码模型。
与此同时，有网友爆料，一款名为 korrine 的匿名模型正在 Code Arena 上进行测试。有人猜它是 Kimi K3.1，也有人将其指向 Qwen 和 MiMo，说啥的都有。
8 月的大模型圈，突然变成了一场大型猜谜游戏。
「牛来」大模型表现抢眼
Ox Alpha 真正引发关注，靠的是代码能力。
开发者 Ben Davis 从 DeepSWE 中抽取 10 项任务进行测试，Ox Alpha 完成了其中 8 项，通过率达到 80%。其公布的对比结果中，Fable 5 Max 为 65%，GLM-5.3 Max 和 Grok 4.6 xhigh 均为 62%，GPT-5.6 Sol Max 为 52%。
DeepSWE 考察真实软件工程能力。模型需要阅读代码仓库，定位问题，修改代码，运行测试，再根据报错继续修复。相比单轮编程题，它更接近编码 Agent 的实际工作。
不过，10 项任务的样本很小。随后，其他开发者在另一组 DeepSWE 子集上测试，给出的结果约为 63%。两次测试的任务范围和运行配置并不完全相同，暂时无法据此确定 Ox Alpha 的准确排名。
不过这些结果初步显示，这款匿名模型已经表现出很强的长程编码潜力，能力逼近当前头部模型。
「牛来」大模型到底是谁家的？
「牛来」大模型的身份，目前流传最广的说法是智谱尚未发布的 GLM-5.3 Flash，或 GLM-5.3 的多模态版本。
有人还专门写了个博客进行分析：
1. 最强证据来自视频编码器。四段不同帧率、时长和分辨率的视频中，Ox Alpha 消耗的视觉 token 与 GLM-5V-Turbo 完全一致。MiMo、Qwen 和 GLM-4.6V 都呈现出明显不同的结果。
2. 文本 tokenizer 也高度吻合。研究者测试了 25 组提示词，Ox Alpha 与 GLM-5.3 的 token 数量始终保持固定的 75 token 差值。
3. 其他特征也指向智谱。Ox Alpha 拒绝处理音频，与 GLM-5V 的路由方式相同；回答风格、Agent 执行步数和推理接口也很接近 GLM。智谱此前还曾用 Pony Alpha 匿名测试 GLM-5，具备相同操作先例。
https://ox-alpha-evidence-production.up.railway.app/
还有网友从对话中寻到蛛丝马迹。
Ben Davis 认为 99% 确定这就是 GLM-5.x。
这些线索提高了 GLM 说的可信度，但还不足以完成身份确认。
截至目前，OpenRouter、智谱都没有公开回应。
korrine 身份更扑朔迷离
「牛来」大模型的身份还扑朔迷离，Code Arena 又出现了一个名为 korrine 的匿名模型。
最初，不少人猜测它是 Kimi K3.1，原因是 Kimi K3 发布前，曾被认为以 kivine 的代号接受测试。kivine 与 korrine 结构相近，因此引发了联想。
不过，最早传播消息的爆料者随后补充称，此前获知的 Moonshot 新模型可能对应另一个代号 adamant-ananke。korrine 也可能来自 Qwen 等其他中国团队。
评论区中，还有人将它指向 MiMo V3。
大模型厂商为什么喜欢「挂马甲」？
匿名测试正在成为大模型正式发布前的重要环节。
在 Arena 中隐藏厂商和型号，可以尽量削弱品牌带来的先入为主。用户看不到模型身份，只能根据实际输出进行选择，最终积累的对战结果，也更接近真实用户体验。
OpenRouter 提供的是另一类测试环境。
开发者会把模型接入各种编码 Agent，让它进入真实仓库，连续调用工具，处理长达数小时的软件工程任务。上下文能否保持稳定，工具调用是否可靠，模型会不会在长程任务中循环或跑偏，都能在高强度使用中迅速暴露。
对模型厂商来说，这相当于一次公开压力测试。团队可以提前观察失败案例，验证推理服务的承载能力，也能在正式发布前积累真实口碑。
此外，「猜模型」现在也越来越成为一种营销手段了，身份悬念确实可以拉长讨论周期。
最后回到模型本身。如果 Ox Alpha 真是一款 Flash 模型，其代码能力已经逼近头部水平，那么资源投入更高、能力更完整的完整版，又会把上限推到哪里呢？
参考链接：
https://x.com/Adidotdev/status/2090833298713096241
https://x.com/davis7/status/2090669483740279155?s=20
https://x.com/davis7/status/2090655207831298095?s=20
https://x.com/MaxForAI/status/2090783750217162788
© THE END
转载请联系本公众号获得授权
投稿或寻求报道：[email protected]
2026-08-22 17:12:00
近日，群体智能世界模型公司超脑未来、商业航天企业未来宇航与特种机器人企业希云柔控正式达成战略合作，共同启动 SpaceClaw（太空龙虾）计划。
三方将分别发挥群体智能基础模型、空间飞行器与柔性机械臂优势，共同建设全球首个以开源方式推进、以真实在轨验证为目标的太空具身智能合作项目。
SpaceClaw 计划在合作启动后的 6 个月内完成首阶段在轨验证，并同步发布面向全球开发者和科研机构的太空具身智能基准 OrbitBench。
项目将开放标准接口、仿真环境、任务数据、评测工具与基线模型，让更多人工智能团队不必先制造和发射一颗卫星，也能训练、测试和迭代面向轨道、月球、火星等不同重力环境的机器人模型。三方希望通过 SpaceClaw，为正在形成的太空经济提供一只可以被持续训练、不断升级并由全球开发者共同建设的「开源之手」。
不是一颗带机械臂的卫星
而是一台真正的太空具身机器人
传统空间机器人通常由卫星平台、机械臂和地面控制系统组成。不同模块之间高度定制，机器人主要依赖预先编写的程序和地面遥操作完成任务。
SpaceClaw 将改变这一架构。
在 SpaceClaw 系统中，未来宇航提供空间飞行器平台，包括能源、通信、测控、控制系统的总装集成测试、发射和在轨任务保障；希云科技提供轻量化空间机械臂、柔顺末端执行器及力 — 位 — 型融合控制系统；超脑未来则提供 SpaceClaw 的核心机器人大脑 ——WorldDreamer-Orbit。
WorldDreamer-Orbit 不是传统机械臂控制软件，而是面向轨道环境训练的群体智能基础模型。它将同时理解空间飞行器、双机械臂、任务目标与周围环境的状态，预测机器人动作可能引起的接触冲击、基座扰动和目标运动，并统一完成感知、预测、规划、决策与任务协同。
这意味着，SpaceClaw 不是「一颗卫星加两条机械臂」，而是一个能够感知自身、理解环境、预测未来并自主完成操作任务的太空具身智能体。
一脑多臂：
WorldDreamer-Orbit 首次进入真实轨道环境
在地面上，机械臂通常固定在稳定基座上；但在太空中，机械臂的每一次运动都会反作用于航天器本体。
机械臂伸展、接触或抓取目标，可能改变整个平台的姿态；目标自身可能处于自旋和章动状态；接触瞬间产生的冲击，还可能让机器人和目标同时失稳。
这使得太空机器人面对的不再是单一机械臂控制问题，而是一个由飞行器、机械臂、目标物体和轨道环境共同构成的动态系统。
WorldDreamer-Orbit 将通过共享世界状态，持续预测：
目标物体未来的位姿和运动趋势；
双机械臂动作对航天器姿态的影响；
接触瞬间可能产生的冲击与滑移；
不同捕获策略对应的碰撞风险；
通信延迟或传感器异常后的任务演化；
多个执行单元之间的最优角色分配。
在首阶段任务中，SpaceClaw 计划依次完成星上模型运行、空间目标感知、双臂协同规划、软捕获接触、稳定约束及异常恢复等在轨试验，形成从「大模型决策」到「真实物理操作」的完整闭环。
为确保任务安全，WorldDreamer-Orbit 不会在首阶段直接控制推力器和机械臂电机。模型负责理解任务、预测环境、制定策略并输出动作意图；航天级姿轨控制系统和机械臂控制器负责底层执行；独立安全系统则持续约束碰撞距离、接触力、能源余量与飞行器姿态。
这套架构让具身智能模型真正进入轨道环境，同时保留航天任务所必需的安全边界。
六个月完成首阶段在轨验证
SpaceClaw 将充分复用三方已经形成的技术基础，采用模块化、标准化和分阶段验证路线，加速完成从地面到轨道的工程闭环。
未来宇航致力于打造以空间飞行器为核心产品的太空新业态，目前已经形成空间飞行器研制、生产、发射、测运控的全周期交付和运维服务的工程能力，并正在推进商业空间飞行器的工程化与规模化。
希云科技团队成员长期从事空间机器人、绳驱柔性机械臂、遥操作和柔顺控制研究。团队研制的空间柔性连续体机械臂已经进入真实轨道环境，完成模拟加注和柔顺控制等关键技术验证。
超脑未来则长期研究群体智能基础模型和多智能体世界模型。其 WorldDreamer 模型将分散在不同机器人上的感知、决策和行动经验压缩进共享模型，使多个机器人能够共享一个世界观，并通过预测其他智能体状态减少通信和重复计算。
基于这些技术积累，三方计划在合作启动后的六个月内完成 SpaceClaw 首阶段在轨验证，重点验证：
1. WorldDreamer-Orbit 在星上计算平台的稳定运行；
2. 微重力环境下的空间感知与状态预测；
3. 双机械臂与飞行器本体的联合运动规划；
4. 自旋或运动目标的软捕获接触；
5. 接触后的姿态稳定与持续约束；
6. 通信延迟、感知误差和任务异常下的自主恢复；
7. 在轨数据回传及模型持续迭代。
此次任务的核心价值，不只是证明一台空间机器人能够完成一次动作，更是建立太空具身智能的第一条真实数据闭环：
仿真训练 — 地面验证 — 模型上星 — 在轨操作 — 数据回传 — 模型升级。
同步发布 OrbitBench：
让全球大模型接受不同重力环境的考试
OrbitBench仿真环境
与 SpaceClaw 在轨验证同步，三方将联合发布太空具身智能基准 OrbitBench。
目前，大多数机器人基础模型主要使用地面环境数据进行训练和评估，其运动规律、接触经验与任务策略默认建立在 1g 重力环境之上。一旦进入轨道、月球或火星，同一个动作可能产生完全不同的结果。
OrbitBench 将构建覆盖不同重力条件的统一训练与评测体系，包括：
理想零重力环境；
近地轨道微重力环境；
月球约 0.16g 重力环境；
火星约 0.38g 重力环境；
地球 1g 标准重力环境；
可连续调节的自定义重力环境。
首批任务将覆盖自由漂浮机器人控制、双臂协同操作、空间目标追踪、自旋目标捕获、软接触、稳定约束、在轨装配、多机器人协同巡检及故障恢复。
OrbitBench 不仅考察任务是否完成，还将评估：
模型跨重力泛化能力；
目标运动预测误差；
接触冲击与基座扰动；
碰撞风险；
能源消耗；
通信开销；
长序列任务成功率；
异常情况下的自主恢复能力；
仿真策略向真实在轨系统迁移的能力。
SpaceClaw 产生的部分真实在轨数据将在完成安全审查与数据处理后进入 OrbitBench，用于缩小仿真环境与真实太空之间的差距。
这意味着，OrbitBench 不是一个只存在于仿真中的排行榜，而是一个能够通过真实在轨数据不断校准的太空具身智能基准。
「开源之手」究竟开放什么
SpaceClaw 所定义的「开源」，不是简单公布一张机械图纸，也不是开放缺乏工程验证的概念模型。
项目计划分阶段开放：
OrbitBench 仿真环境与任务定义；
空间机器人本体描述与标准接口；
WorldDreamer-Orbit 模型接入协议；
代表性训练数据与在轨任务数据集；
基线感知、规划和控制策略；
模型评测工具与标准指标；
数字孪生资产和硬件在环测试工具；
面向高校和开发者的参考任务。
涉及飞行安全、航天器关键控制、客户数据和特定任务的敏感模块，将按照航天安全要求设置必要边界。
通过这套开放体系，人工智能研究者可以开发新的空间感知、世界建模和机器人策略；航天企业可以将自己的飞行器或机械臂接入统一系统；高校实验室可以在不同重力环境中验证模型；开发者也可以为 SpaceClaw 创造新的末端工具和任务能力。
SpaceClaw 希望建立的不是一台孤立的机器人，而是太空具身智能的 Linux 与开发者生态。
三方共同定义太空具身智能的新基础设施
在此次战略合作中，未来宇航将担任空间飞行器及在轨任务总体单位，负责平台研制、空间环境适配、总装测试、发射组织、测运控、在轨操控与任务安全。
希云科技将担任空间机器人分系统总体研制单位，负责双机械臂本体、柔顺末端执行器、动力学建模、力位控制、视觉伺服及飞行产品工程化。
超脑未来将担任智能系统总体单位，负责 WorldDreamer-Orbit、群体智能架构、星上推理、数据闭环、训练平台以及 OrbitBench 基准建设。
三方将共同推动空间飞行器、机器人硬件和人工智能模型之间的接口标准化，使 SpaceClaw 能够从一次在轨任务逐步发展为可复制、可扩展的太空机器人平台。
从 SpaceClaw-I 到太空机器人网络
SpaceClaw 将按照三阶段路线持续升级。
第一阶段，SpaceClaw-I 将聚焦双机械臂软捕获和稳定约束，完成 WorldDreamer-Orbit 首阶段在轨验证，并同步发布 OrbitBench。
第二阶段，SpaceClaw-II 将增加在轨补给、对接、组件操作与能源转移能力，进一步提升目标识别、姿态预测和精细操作能力。
第三阶段，SpaceClaw-III 将面向真实在轨服务，逐步开展非合作目标捕获、故障航天器维护、辅助离轨、多目标空间碎片治理及多机器人协同作业。
未来，不同时间发射、不同构型和不同任务的 SpaceClaw，可以共享同一个 WorldDreamer-Orbit，通过真实任务数据不断升级共同的具身大脑。
每一次飞行，都不仅完成一项任务，也为下一台机器人留下经验。
为太空经济提供第一只「开源之手」
未来的太空经济不仅需要更多火箭、卫星和空间站，也需要能够建设、巡检、维护和升级这些基础设施的机器人。
如果说火箭解决的是如何进入太空，卫星解决的是如何在太空获得信息，那么 SpaceClaw 希望解决的是：人类如何在太空持续行动。
超脑未来创始人兼 CEO 表示：「SpaceClaw 不是把一个地面大模型简单搬到卫星上，而是让模型真正进入一个全新的物理世界。不同重力、通信延迟、基座扰动和接触冲击，将迫使具身智能重新理解动作与后果。通过 WorldDreamer-Orbit 和 OrbitBench，我们希望让每一次在轨操作都变成整个机器人网络可以继承的经验。」
未来宇航创始人牛旼表示：「商业航天正在从『进入太空』走向『运营太空』。未来的轨道基础设施需要具备持续巡检、维护、补给和升级能力。SpaceClaw 把空间飞行器、机器人和人工智能结合起来，并通过开放生态降低太空机器人研发门槛，这将为在轨服务带来新的基础设施。」
希云科技创始人兼 CEO 谭俊波（师从清华大学深圳国际研究生院王学谦教授）表示：「我们的柔性机械臂已经完成从地面实验到真实轨道环境的跨越。下一步，空间机械臂需要从执行预设动作，升级为能够感知环境、预测接触并自主完成任务的具身智能体。SpaceClaw 将把航天级机器人本体与群体智能基础模型真正结合起来。」
SpaceClaw 的最终目标，不只是制造一只能够抓取卫星的机械手。它希望成为一只可以被全球开发者共同训练、被不同航天器重复使用、能够从每一次任务中持续学习的「开源之手」。
一只手，开始建设太空。一个模型，连接所有机器人。One World, One Model.
关于超脑未来
超脑未来是一家专注群体智能基础模型的 Physical AI 公司，致力于通过 WorldDreamer 构建能够连接并协同多种机器人和智能体的共享具身大脑，推动机器人从「一机一脑」走向「一脑控所有」。
关于未来宇航
未来宇航是一家专注空间飞行器研发、整星在轨交付及运维的商业航天企业，业务覆盖卫星项目工程总体、载荷集成、发射组织、测运控、轨道部署及在轨服务。
关于希云科技
希云科技由前清华大学深圳国际研究生院谭俊波副研究员联合前谷歌 Spatial AI 技术负责人（Tech Lead）付国峪共同创立，专注于连续体柔性机器人本体智能、柔顺控制、模块化技术，致力于商业航天、极端特种工业环境以及消费级机器人系统的工程化与产业化应用。
© THE END
转载请联系本公众号获得授权
投稿或寻求报道：[email protected]
2026-08-22 17:12:00
Coding Agent 正在进入一个新的阶段。
过去，我们通常让 Agent 修复一个 bug、完成一个 issue，或者实现一个相对独立的功能。围绕这类任务，SWE-bench 及其后续工作已经建立了相对成熟的评测范式：给定代码仓库和需求，让 Agent 修改代码，最终通过测试判断任务是否解决。
但随着 Coding Agent 开始支持持续执行、Goal Mode、动态工作流以及更复杂的任务编排，如何评测更长时间尺度上的 Agent 执行过程，也逐渐成为一个值得关注的问题：
当 Agent 不再只解决一个局部问题，而是要持续完成一组前后依赖的软件开发任务；当关注点从 Harness 内部的工具交互进一步扩展到外层的持续执行与任务编排，我们应该怎样评测它？
近日，微软、南京大学等机构的研究人员提出了 LoopsBench，这是一个面向 long-horizon software engineering 的 Coding Agent Benchmark，关注 Agent 能否在长时间执行中持续维护计划、推进依赖任务、保留已经完成的工作，并控制后续修改产生的回归。
论文认为，随着 Coding Agent 从一次性的工具调用逐渐走向持续的软件开发系统，Agent 基础设施的研究重点也正在从 Harness Engineering 向 Loop Engineering 扩展。Harness 解决的是模型如何访问代码、Shell、编辑器和测试环境，而 Loop 进一步决定：Agent 如何跨越更长的时间尺度组织工作，如何维护状态，以及一次执行结束之后如何继续推进。
论文：https://arxiv.org/abs/2608.00267
代码：https://github.com/microsoft/Loopsbench
项目主页：https://loopsbench.ai
从最终结果评测，到持续执行评测
现有 Coding Agent Benchmark 的一个共同特点，是任务通常以一个相对完整的最终目标出现。
Agent 获得一个 issue 或 feature specification，随后自由探索仓库、修改代码，评测器最终查看测试是否通过。
这个范式对于衡量 issue resolution 能力非常有效，但对于越来越长的软件开发任务，仅观察最终结果可能不足以完整刻画执行过程。
考虑一个典型的软件开发过程：
一个功能可能首先依赖某个基础数据结构，随后需要建立接口，再由上层模块调用这个接口，最后才能完成 CLI、异常处理以及系统级集成。后面的任务不仅依赖前面的任务，而且 Agent 在修改后续模块时，还必须保证已经完成的功能没有被破坏。
如果只在最后运行一次测试，我们能够知道最终代码是否正确，却很难进一步了解：
Agent 是否识别了任务之间的依赖关系？它是否沿着合理的软件开发顺序推进？它曾经完成过哪些功能？这些功能后来是否发生了 Regression？Agent 是持续稳定地向前推进，还是不断在不同子任务之间切换？
这正是 LoopsBench 希望补充的评测维度：对于长周期 Coding Agent，仅观察 terminal outcome 可能不足以完整刻画其执行过程，还需要进一步观察中间开发单元、持续累积的工程义务以及 Agent 的执行顺序。
LoopsBench 的核心抽象：把软件任务表示成 Dependency DAG
LoopsBench 的一个核心设计，是改变软件任务在 Benchmark 中的表示方式。
传统 Benchmark 通常把一个任务表示成一个整体需求，而 LoopsBench 将一个长周期软件任务拆分成多个可以独立验证的 Development Unit，再恢复这些 Development Unit 之间具有可验证证据支持的前置依赖关系。最终，一个任务被表示为一张 Dependency DAG。
DAG 中的节点是来自原始开发过程的实际工程单元；边则表示后一个开发单元对前一个开发单元存在明确的前置依赖。
例如，一个后续模块调用了前一个单元中新增加的 API，那么两者之间存在明确的 producer-consumer dependency；如果后一个阶段扩展了此前定义的 schema、interface 或 subclass，也会形成相应的前置关系。
但是，这张 DAG 并不是在宣称 “真实的软件开发只有一种正确顺序”，更像是一个 evaluation contract。
只要 Agent 采用的执行顺序符合依赖关系，LoopsBench 并不会要求它重现开发者历史上的完整顺序。Agent 可以并行完成相互独立的节点，也可以重新修改已经完成的实现。
从 LoopsBench 的评测定义来看，一个 Development Unit 在其前置条件满足之后，才进入可正常推进和评测的状态。
因此，Dependency DAG 给 LoopsBench 提供了一个过去 Benchmark 较难获得的参照系：我们不仅知道最终有多少功能完成，还能够进一步观察 Agent 究竟沿着软件依赖结构推进到了哪里，也就是在拓扑结构上走到了哪一层。
这些长周期任务从哪里来？
为了让 Dependency DAG 尽可能对应真实的软件开发过程，而不是由模型主观生成，LoopsBench 从真实的软件演化材料中构造任务。
论文最终构建并发布 112 个 long-horizon tasks，包含超过 5,300 个 Development Units，覆盖 8 种编程语言和 9 个软件领域；在该 Benchmark 中，任务依赖深度的中位数为 6。
这些任务来自三类软件演化过程。
第一类是大学课程中的大型编程实验。一个完整的课程 Project 通常天然包含多个阶段和模块，学生需要在数周甚至数月中逐步完成，因此能够提供相对清晰的长期开发结构。
第二类来自真实开源项目中的连续 Pull Request。这里的重点并不是随机抽取几个 PR，而是重建一段连续的软件演化过程。当早期 PR 引入新的接口、模块或数据结构，而后续 PR 建立在这些修改之上时，它们便形成具有明确证据支持的工程依赖。
第三类来自 Research Evolution。研究代码也经常沿着方法演化逐步发展：后续论文可能继承前一项工作的核心实现，再加入新的算法组件或系统设计。LoopsBench 通过具有实际方法继承关系的论文演化链，重建这类长期的软件变化过程。
最终的 112 个任务由 57 个 Course Labs、29 个 PR Sequences 和 26 个 Research Evolutions 构成。
从真实开发材料到可执行 Benchmark
论文的另一个关键部分，是如何把这些原始的软件开发材料转化成一个可复现、可执行的 Coding Agent Benchmark。
PR history 中包含大量和任务目标无关的修改；课程实验的要求可能分散在 handout、starter code 和测试中；研究代码的变化则可能同时涉及算法、实验和工程配置。
因此，LoopsBench 首先需要把不同来源的材料统一成 Development Units，然后恢复它们之间具有明确证据支持的 dependency relation。
在 DAG 构建中，论文采取了相对保守的策略：只有能够在原始软件材料中找到明确证据的依赖关系才进入图中。例如代码之间真实存在 symbol-level 的调用、导入和继承关系，或者两个开发阶段之间存在可以验证的结构复用。
这也是为什么论文将得到的 DAG 描述为真实 prerequisite structure 的一个 lower bound—— 它宁可遗漏某些隐式依赖，也不希望仅凭语义猜测制造大量错误的依赖边。
完成 DAG 之后，每一个 Development Unit 都还必须被转化成真正可执行的评测义务。
LoopsBench 会为任务建立可复现运行环境，并将每个开发单元对应到一组 executable tests。测试并不是简单生成后直接加入 Benchmark，而需要通过基于 Gold Solution 的验证流程：正确实现必须能够让测试从失败变成通过，没有实现时测试不能自然通过，同时，仅完成当前节点的前置工作也不能提前满足这个节点的测试。
因此，论文最终评测的并不是抽象的文本 milestone，而是可以在代码上真实执行和验证的 Development Unit。
Flow-aware Runtime：让测试跟着软件进度向前移动
有了 Dependency DAG，接下来的问题是：
评测器应该什么时候检查哪些任务？
LoopsBench 为此设计了 Flow-aware Evaluation Runtime。
假设开发单元 C 依赖 A 和 B。
在 A 和 B 尚未完成时，即使 C 的代码已经被 Agent 修改，评测器也不会把 C 当成当前正常推进的任务。
只有当 C 的所有 prerequisite 都已经完成，它才会进入当前的 Ready Frontier。
也就是说，随着 Agent 不断完成 Development Unit，可评测的任务 frontier 会沿着 DAG 动态向前推进。
这使 LoopsBench 不仅能够统计有多少测试通过，还能够从 Dependency DAG 的角度刻画 Agent 推进到了哪一层。
传统 Test Pass Rate 主要告诉我们多少测试通过，而 Ready Frontier 可以进一步区分：Agent 是否真正打通了关键的前置节点，并进入更深的软件依赖层。
因此，LoopsBench 观察的是 Agent 自己能否发现合理的工程路线，而不是通过 Benchmark 把一条固定的正确路线直接提供给它。
已经完成的工作，会变成后续必须保护的 Regression Obligation
Flow-aware Runtime 还有另一个关键机制。
假设 Agent 已经完成了一个底层模块，它的测试全部通过。
随后 Agent 开始开发上层功能。在普通分阶段评测中，之前的阶段可能已经结束；但在真实软件工程里，这些已经完成的功能并不会消失，新代码仍然需要保证它们正常工作。
因此，在 LoopsBench 中，一个 Development Unit 一旦完成，它对应的测试就会继续留在后续执行过程中，成为 Regression Obligation。
于是 Agent 每向前推进一步，实际上都承担越来越多的工程义务：它不仅需要让新的功能正确，还需要保证所有已经完成的功能继续正确。
这也构成了长周期 Coding Agent 需要面对的一类挑战：任务越往后推进，代码越来越复杂，同时 Agent 需要维护的正确状态也越来越多。
因此，LoopsBench 中的 Regression 并不是普通意义上 “最终测试失败了多少”，而是在观察：
Agent 曾经建立起来的正确状态，有多少在后续执行中重新丢失了。
为了捕获这种动态过程，LoopsBench 将 Agent 编辑环境与评测环境分离。Agent 在一个容器中持续工作，而 evaluator 在另一个容器中根据代码快照独立运行测试。Runtime 会在真实代码发生变化时记录新的状态，从而获得一条随时间演化的软件开发轨迹。
实验：今天的 Coding Agent 能把长周期任务推进多远？
在完成 Benchmark 构建后，论文并没有只给出一个排行榜，而是围绕三个 Research Questions 展开实验。
这三个问题对应 Long-horizon Agent 的三个层次：
它能走多远？它在执行过程中如何维护计划、代码和测试状态？哪些 Loop 设计会影响长期执行？
RQ1：当前 Coding Agent 究竟能持续推进多远？
第一个实验首先回答一个直接的问题：
当前具有代表性的模型与 Coding Agent，在 LoopsBench 上能够取得怎样的长期执行表现？
实验结果显示，当前系统在这类长周期任务上仍有较大的提升空间。
在 LoopsBench 论文所采用的基准测试设置下，使用最高配置并结合 outer continuation 的方案表现最好，其任务 Resolve Rate 为 25.00%，Test Pass Rate 为 53.05%。
也就是说，即使是该实验中表现最好的配置，也仍有约四分之三的任务未能完整解决。
论文随后分别控制了 model 和 loop。
在固定 Coding Agent Loop、更换不同模型时，在论文比较的模型范围内，能力更强的基础模型通常取得了更好的长期进展；但即使模型能力提升，整体 Resolve Rate 仍然有限。
反过来，在固定模型后更换不同 Coding Agent Loop，也会产生明显的性能差异。
实验结果表明，Model 与 Loop 分别从不同层面影响长期执行：前者主要影响局部推理与代码能力，而后者影响这些能力如何在更长时间尺度上被组织和持续利用。
论文还进一步加入了 outer continuation。当一次 Agent execution 主动停止之后，外部 Loop 会重新启动 Agent，让它继续处理尚未完成的工作。
在论文测试的多数配置中，Continuation 都带来了更好的任务进展。
例如，在其中一组高配置实验中，引入 continuation 后，Resolve Rate 从 16.96% 提高到 25.00%；另一组配置则从 14.29% 提高到 21.43%。这表明，一部分未完成任务与 Agent 的提前停止有关。
但实验也显示：
Continuation 可以缓解部分由提前停止带来的问题，却不能自动解决后续任务选择与推进路径的问题。
当任务进入更深的依赖层之后，Agent 仍然需要面对尚未完成的 prerequisite、不断累积的状态，以及越来越大的 Regression 压力。
RQ2：Agent 在长时间执行中，到底丢掉了什么？
如果第一组实验表明 Coding Agent 在 long-horizon task 中仍面临明显挑战，那么第二个研究问题开始进一步分析：
这些挑战可能与哪些执行过程因素有关？
LoopsBench 的优势在这里体现出来。因为任务拥有 Benchmark 构建得到的 Dependency DAG，同时 Runtime 记录 Agent 的真实执行轨迹，所以论文可以进一步分析 Agent 在 Planning、Implementation 和 Testing 三个层面的行为。
Planning
实验发现，目前 Agent 产生的计划只能恢复 Dependency DAG 中的一部分 prerequisite relation。
换句话说，Agent 的计划能够覆盖部分任务，但往往未能完整反映：
哪些任务具有前置依赖，哪些工作可以并行，以及哪一个节点正在阻塞后续工程推进。
这种差异在不同 Loop 中表现得并不相同。
部分 Coding Agent 已经开始显式使用 tree-shaped 或 concurrent execution structure，因此其计划宽度更接近参考 DAG；而在论文观察到的执行轨迹中，一些以线性执行为主的 Loop 更容易把本身具有并行结构的软件任务压成一条长链。
但并行并不天然意味着更好。
论文也观察到，有些 Loop 会走向另一个极端：把本来存在明确 prerequisite 的任务过早并行化。
因此，长周期 Planning 的核心并不是 “越并行越好”，也不是 “严格串行最安全”，而是：
并行结构需要尽可能与真实的软件依赖结构相匹配。
Implementation
论文发现，即使只观察最终成功完成的 Development Units，Agent 写出的 Patch 通常也比 Gold Reference 更长。
这一现象表明，在论文测试的任务中，Agent 除了任务路由之外，在实现过程中也可能逐渐累积额外修改。
这些修改未必立即造成错误，但随着任务越来越长，额外代码通常意味着更大的状态空间和更高的后续维护压力。
Testing
Testing 方面，论文观察到另一个值得关注的现象。
实验中的 Coding Agent 虽然普遍会运行已有测试，但较少随着开发过程持续建立足够的 Agent-authored tests。
这意味着在部分执行过程中，新功能的增加并未伴随同等程度的 regression protection。
结果是：已经完成的 Development Unit，在后续修改中仍然可能发生 Regression。
而且这种现象并不是某一个 Agent 的特殊情况。论文在不同 Loop profile 中都观察到了 Regression events。
从这个角度看，LoopsBench 提供的信息并不止于 “25% Resolve Rate” 这一最终指标。
对执行轨迹的进一步分析显示，计划对依赖关系的覆盖不足、实现过程中额外修改的累积、测试保护增长不足，以及后续修改引发的 Regression，都可能影响 Agent 在 long-horizon task 中的持续推进。
这些现象也指向了 Loop-level design 中值得进一步研究的问题。
RQ3：不同 Loop 机制如何影响 Long-horizon Execution？
论文的第三个 Research Question 进一步比较了多种长周期 Loop 设计，包括 Goal Mode、dynamic workflows 以及基于 fresh invocation 的循环机制。
这里论文关注的不再是某个 Agent 最终谁赢，而是不同 Loop 如何处理三个关键问题：
Objective persistence、Context renewal 和 Residual work。
Goal Mode 的核心思想，是让目标在一次较长的执行周期中持续存在。
Dynamic Workflow 则进一步把工作拆分给多个具有更窄上下文的 worker。
另一类循环机制采取不同路线：结束当前 invocation 后重新启动新的 invocation，让新的 Context 接管剩余任务。
这些机制代表了几种不同的 Long-horizon System Design。
实验发现，它们之间确实存在明显差异。
例如，采用 dynamic workflows 的设计可以产生更多独立的 context rounds，并取得较高的 Resolve Rate；Goal Mode 则通过长期维护目标来持续推进。
相比之下，在 LoopsBench 的相关实验设置下，单纯依赖 fresh invocation 重新接管 residual work 的循环机制，在更复杂任务上的表现相对较弱。
但在论文测试的这些机制中，没有一种能够完全消除 Regression。
这一结果表明，仅增加或刷新 Context 本身，可能还不足以解决 long-horizon execution 中的状态维护问题。
即使系统能够通过多次 continuation 持续执行，如果新的 Context 无法准确恢复 “哪些工作已经完成、当前为什么停在这里、哪些 invariant 必须继续保持”，它仍然可能重复工作、错误路由或者破坏已有结果。
因此，论文进一步将 state retention、residual routing 和 regression obligation retention 视为 Long-horizon Loop Engineering 中值得重点研究的问题。
为什么是从 Harness Engineering 扩展到 Loop Engineering？
这也是整篇论文希望提出的核心观点之一。
过去，Coding Agent 的不少系统能力提升都与 Harness Engineering 的发展密切相关。
我们不断改进模型与代码环境之间的接口：更好的文件搜索、更好的编辑工具、更好的 Shell、更好的 Sandbox、更大的 Context，以及更清晰的 Agent-Computer Interface。
这些工作回答的是：
How should the model interact with the software environment?
但当 Coding Agent 开始连续工作几十分钟、几小时，甚至更长时间时，另一个系统层开始变得重要：
当前目标是什么？已经完成了什么？真正阻塞工程的任务是什么？
哪些任务可以同时推进？哪些状态必须跨 Context 保留？什么时候应该运行测试？
什么时候需要重新规划？一次 Context 结束后，剩余工作应该交给谁？新的修改是否破坏了以前已经完成的功能？
这些问题已经很难单纯通过增加一个 Tool 或扩大 Context Window 来解决。
它们属于：
How should the agent continue working over time?
也就是 Loop Engineering。
Harness 是模型与环境之间的接口；Loop 则是跨时间组织 Agent 行为的控制系统。
因此，LoopsBench 的目的并不是宣称 Harness Engineering 已经不重要，而是强调：随着任务进入更长时间尺度，Harness 之上的 Loop 设计开始成为另一个值得独立观察的系统层，而现有 Benchmark 对这一层的直接测量仍然有限。
LoopsBench 希望改变测评范式
从论文角度看，LoopsBench 的核心变化之一，是将 Coding Agent Benchmark 的观察单位从最终结果进一步扩展到执行过程。
现有的一类主流 Coding Agent 评测主要关注一个任务最终是否 Resolve。
LoopsBench 则把一次软件开发过程展开成一条随时间变化的执行轨迹：
Dependency DAG 告诉我们工作之间如何关联；
Ready Frontier 告诉我们 Agent 实际推进到了哪里；
Regression Obligation 告诉我们它能不能守住已经完成的成果；
Loop Trace 则让我们进一步观察 Planning、Implementation、Testing、Routing 和 Context Renewal 如何共同影响最终结果。
从这一角度看，这提供了一种值得进一步探索的 Long-horizon Coding Agent Evaluation 思路：
Benchmark 不仅应该衡量 Agent 最终到达了哪里，也应该帮助我们理解它为什么停在那里。
© THE END
转载请联系本公众号获得授权
投稿或寻求报道：[email protected]
2026-08-22 14:00:00
"把光线调成午后暖阳"、"换成霓虹灯下的赛博氛围"、"来一束伦勃朗光，侧脸更有质感"。人像修图里，换光效是最常见也最难做好的需求之一，因为在复杂光照场景下，现有 AI 重打光方案常出现光照不稳定、阴影方向错乱，甚至把脸 "修成另一个人" 的问题。
当前三类基于扩散模型的人像重打光主流方法各有短板，其中控制信号驱动（Control-based）的方案可控性有所提升，但结果高度依赖控制信号的准确性和完整性；本征分解驱动（Decomposition-based）在复杂光照下容易出错，误差会传导至最终图像，导致阴影不一致、颜色偏移或细节丢失；直接图到图翻译（Image-to-image）未显式建模 "光照专属" 的特征位移，光照编辑的精度与表达力不足。
此外，由于公开人像重打光数据集规模有限，且多在受控环境下采集，缺乏复杂光照效果（多色温、空间变化阴影、非均匀照明等），难以支撑真实场景下的可控重打光学习。
对此，美图影像研究院（MT Lab） 提出 Consistent Feature Transport（CFT，一致特征传输），将人像重打光重新表述为光照一致的特征传输问题，在 Rectified Flow 框架上显式学习源图与目标图分布之间的光照变换，而非泛泛的图像翻译，该成果已被计算机视觉顶级会议 ECCV 2026 （European Conference on Computer Vision）录用。
论文标题：Consistent Feature Transport for Image Relighting
项目主页：https://github.com/Dixin-Lab/CFT
CFT 的 核心思路
CFT 在噪声、源图、目标图三个分布之间建立联合建模，训练目标由三部分组成：
1. 噪声→目标图（L₁）给定源图 (xsrc)、重打光目标图 (xtgt) 及文本条件 (ctgt)，学习从先验噪声到目标 latent 的速度场，完成条件生成。
2. 噪声→源图（L₂）在同一先验噪声下，以中性条件 (csrc) 重建源图分布。这条重建路径强化了对非光照内容（身份、几何、场景结构）的保持能力。
3. 源图→目标图：光照一致的特征传输（L₃，CFT 核心）借鉴无反演编辑方法，利用 Rectified Flow 的线性性质，通过 平行四边形法则 构造源到目标的直接传输路径：ztdirect=zsrc+zttgt−ztsrc 对应速度场为：vtdirect=vθ(zttgt,t,xsrc,ctgt)−vθ(ztsrc,t,xsrc,csrc)
值得注意的是 L₃的监督使用的是身份与场景内容不同，但光照变换相同的图像对作为真值（ground truth）。这样做的优势在于，如果监督来自同一对图像，模型容易拟合样本特有的内容差异，把光照变化与非光照变化混在一起；而换用 “同光照变换、不同内容” 的配对，可以让模型学习可跨实例复用的光照特征传输。 在生成稳定性与光照传输监督之间取得平衡。
此外，为了支撑复杂光照场景的学习，团队构建了包括室内、室外等主流场景的大规模人像重打光数据集，覆盖 14 类光照效果类别，该数据集强调空间结构化照明、多色温与复杂阴影，弥补了现有 portrait relighting 数据在复杂光效上的不足。
实验结果
在自建测试集上，CFT 相比目前的方案， 在像素保真、感知相似度、分布真实感与光照专用指标上均表现更优。定性实验结果显示，CFT 在多光源交互、空间结构化照明、色温大幅偏移等困难场景下，一致性及稳定性方面均有明显优势。
根据 30 名用户对 40 组随机样本打分结果显示，Flux-Kontext + CFT 在评估光照质量（IQ）、内容一致性（CC）、物理合理性（PP）、图像美学（IA）上表现最佳。此外，消融实验显示，单独增加 L₂不能提升重打光质量，但与 L₃联用时提供额外结构保持，完整 CFT 效果最优；L₃若用原始 (xsrc,xtgt) 或随机配对监督，性能反而下降甚至不如仅 L₁；传输速度场方差分析表明，完整 CFT 在训练集与测试集上均具有最低方差，能够学习到更一致、稳定的光照特征传输场。共四项指标上均获得最高分，
配置 |
SSIM↑ |
PSNR↑ |
LPIPS↓ |
FID↓ |
仅 L₁ |
0.9153 |
22.92 |
0.0985 |
20.38 |
L₁ + L₂ |
0.9141 |
22.83 |
0.1018 |
21.61 |
L₁ + L₃ |
0.9161 |
23.38 |
0.0972 |
19.32 |
L₃用原始配对监督 |
0.9141 |
22.8 |
0.1003 |
20.3 |
L₃用随机配对监督 |
0.9135 |
22.8 |
0.1035 |
19.55 |
完整 CFT（L₁+L₂+L₃） |
0.9202 |
23.51 |
0.0946 |
18.73 |
CFT 在风格迁移方面的可泛化能力
CFT 的 “一致特征传输” 思想并不局限于光照编辑，通过在 OmniStyle-150k 上构建风格迁移数据集并将 CFT 应用于 OmniStyle 与 Qwen-Image-Edit 上发现，CFT 在内容结构与感知保真上实现持续提升，生成结果在风格化上取得了更好平衡，这表明 CFT 还可迁移至风格迁移等多种属性的编辑任务。
方法 |
SSIM↑ |
PSNR↑ |
LPIPS↓ |
OmniStyle（w.o. CFT） |
0.5222 |
13.8 |
0.4125 |
OmniStyle（w. CFT） |
0.5275 |
14.12 |
0.3945 |
Qwen-Image-Edit（w.o. CFT） |
0.4422 |
12.97 |
0.3697 |
Qwen-Image-Edit（w. CFT） |
0.4648 |
13.37 |
0.3562 |
目前，图片打光能力已经上线美图旗下产品 Picchi、AirBrush 与 BeautyPlus，不需要输入冗长的提示词，就可以实现各种不同的光线效果。
作者简介：
美图影像研究院（MT Lab）是美图公司旗下核心研发团队，于厦门、北京、深圳、上海、悉尼、西雅图等海内外地区均设有研发分部。团队专注于计算机视觉、深度学习、机器学习等人工智能领域的前沿科技研发，并为美图旗下影像与设计产品提供技术支持，现已在CVPR、ICCV、ECCV、ICML、ICLR、AAAI、ACM MM、NeurIPS、TPAMI、TIP等顶级学术会议及期刊上累计发表75篇学术论文。
© THE END
转载请联系本公众号获得授权
投稿或寻求报道：[email protected]
