← 返回 PaperDaily 大模型与智能体

LLM不只会写代码，还能修内存？MOA给出答案

内存优化最烦的不是“找不到问题”，而是“找到也修不完”。MOA把这事拆成三段：先从 profiling 里挖出反模式，再自动长出静态检查器，最后批量生成补丁，挺像给性能工程装了一条流水线。

龙哥读论文 阅读 3 查看原文
#大语言模型 #Agent #模型训练 #AI应用
LLM不只会写代码，还能修内存？MOA给出答案
🐉 龙哥读论文知识星球来了！
公众号每日8篇拆解不够看？星球无上限更AI领域论文、资讯、招聘、招博、开源代码，一站式干货，每日2分钟刷完即赚！
👇扫码加入「龙哥读论文」知识星球，前沿干货、实用资源一站式拿捏～ xingqiu_header

龙哥导读：
内存优化最烦的不是“找不到问题”，而是“找到也修不完”。MOA把这事拆成三段：先从 profiling 里挖出反模式，再自动长出静态检查器，最后批量生成补丁，挺像给性能工程装了一条流水线。


原论文信息如下：
论文标题:
MOA: A Profiling-Guided LLM Framework for Memory-Optimization Automation at Codebase Scale 发表日期:
2026年06月 发表单位:
The University of Hong Kong, China 原文链接:
https://arxiv.org/pdf/2606.31368v1.pdf

性能瓶颈总是偷偷摸摸？MOA：让LLM帮你一键排查和修复内存问题

内存优化这件事，最烦人的地方从来不是“完全没问题”，而是问题明明在那儿，却像一只会隐身的猫：不崩、不报错、还能跑，就是偷偷吃内存、偷偷涨二进制体积、偷偷拖慢性能。开发者往往得先看 profiling，再翻源码，再猜原因，再改代码，最后还要担心改动会不会把别的地方搞崩。MOA（Memory-Optimization Automation，内存优化自动化）想做的，就是把这条“人工肉搏链条”拆成一条可自动运转的流水线。
封面
图2：MOA整体流程图。它先从 profiling 证据里挖反模式，再把反模式变成静态检查器，最后批量生成补丁，直接把“发现问题”推进到“修复问题”。
这篇论文最有意思的地方，不是“用了大模型”，而是它没有把大模型当成万能嘴炮机，而是当成一个受约束的工程工人：先分析，再校验，再修补。这个思路很实在，因为性能优化不是写作文，不能只讲道理，还得能落到代码上、编译过、测得通、维护得住。

从分析到修复：MOA如何用三个AI智能体打通全流程？

MOA的核心不是一个大模型，而是三个分工明确的智能体：Analyzer、Checker Generator 和 Patcher。这三位角色像一条接力赛：前一个把症状讲清楚，后一个把症状变成规则，再下一个把规则变成补丁。听起来简单，实际很容易翻车，所以论文专门加了“审核”和“验证”两道闸门。
图1：消除头文件初始化常量映射的动机示例
图1：一个非常典型的内存反模式示例。头文件里定义了非平凡静态对象，结果被多个翻译单元重复实例化，最后变成二进制体积膨胀和初始化期开销叠加。问题不是“某一个变量坏了”，而是“这种写法本身就容易重复造轮子”。
先看第一步，Pattern Mining，也就是反模式挖掘。MOA把 profiling 数据导入数据库，不是为了装腔，而是为了让大模型能按需查证据，不必把一大坨日志整个塞进上下文里。Analyzer 会结合运行时症状和源码语义，先提出候选反模式，再写成结构化报告。这里的关键点是：profiling 看到的是症状，源码语义解释的是病因，两者缺一不可。
报告模板也不是随便写写。论文要求每份反模式报告至少包含四块内容：现象描述、为什么会浪费内存、如何检测、如何优化。这个设计很“工程”：前两项负责解释，后两项负责落地。否则大模型很容易输出一段“看起来很懂”的废话，像在性能工程里念经，听着挺玄，实际上不能编译。
图3：报告撰写与审核迭代示例
图3：报告撰写与审核的迭代过程。Analyzer 先给出候选结论，Reviewer 再独立审查是否证据充分、是否和已有模式重复、是否足够具体。这个“第二双眼睛”很重要，因为大模型最怕自我说服，一旦认定了一个解释，就容易越写越顺，越顺越错。
第二步是 Checker Synthesis，也就是把反模式变成静态检查器。这里的思路很妙：既然 profiling 只能告诉系统“哪儿出过事”，那就把这些经验抽象成规则，让检查器去全代码库扫描“同类问题”。论文选用 Clang Static Analyzer 作为底座，原因也很朴素——它适合 C/C++，而 OpenHarmony 正是这个栈。
不过，能生成代码不等于能生成对的代码。MOA先做原型合成，让检查器至少能编译；再做反复校验，用报告里的样例去测误报和漏报。这里的关键是把“反模式描述”变成“可执行逻辑”，而不是停留在自然语言层面。换句话说，MOA不是让大模型写检讨书，而是让它写检查规则。
图4：Patcher的状态机工作流
图4：Patcher 的状态机工作流。它把补丁生成拆成准备、编辑、验证三步，并允许失败回退。这个设计很像给大模型装了“刹车”和“倒挡”，避免它一边胡改一边自信满满地往前冲。
第三步是 Patch Generation，也就是生成补丁。这里最容易出事故，因为内存优化往往不是一行替换一行那么简单，而是牵一发而动全身。MOA先把检测到的目标去重、补上下文，再按文件或相关性分块；随后 Patcher 在状态机控制下先收集上下文，再写补丁，最后做语法和诊断验证。只要验证没过，就回退重来。
这套设计的价值在于，它承认了一个现实：大模型生成代码的最大敌人不是“不会写”，而是“上下文不够、边界不清、改动不稳”。所以 MOA不是靠一次性神来之笔，而是靠多轮收敛，把“能改”变成“改得稳”。

实战检验：在1亿行代码的“巨无霸”项目上，效果如何？

论文的实验对象是 OpenHarmony，一个超过一亿行 C/C++ 代码的开源操作系统。这个量级很关键，因为很多方法在玩具项目上看着很灵，在工业代码库里就会原形毕露。MOA能不能站住脚，核心就看它能不能在这种“巨无霸”上跑通全流程。
表1：MOA调用的工具
表1：MOA调用的工具列表。这里能看出它不是单靠聊天框硬推，而是把数据库查询、状态机控制、语言服务器、检查器构建、补丁验证都接进来了，典型的“LLM + 工程工具链”组合。
先看反模式挖掘。MOA从 3 个系统服务的 profiling 数据里，最终验证出 13 类内存反模式，其中 9 类是以前没被发现过的。这个结果挺有意思：它说明 profiling-guided 的方式不只是重复发现老问题，还能挖出传统规则库没覆盖到的盲区。论文还指出，和 Clang-Tidy 的性能检查相比，约 69.3% 的反模式没有现成对应规则，说明不少问题确实不是靠老式静态规则就能扫出来的。
表2：已验证的C/C++内存反模式类别
表2：已验证的 C/C++ 内存反模式类别。可以看到，问题主要集中在静态对象滥用、低效字符串、重复拷贝和常驻堆结构这几类，都是“看起来不大，积累起来很疼”的典型工程病。
表3：MOA与Clang-Tidy的模式重叠
表3：MOA 与 Clang-Tidy 的模式重叠。重叠的部分说明 MOA 能重新发现传统规则；不重叠的部分则说明它确实从运行时症状里挖出了新东西，而不是把已有工具换个马甲再讲一遍。
再看检测规模。MOA 在 7 个系统服务里一共扫出了 10,067 个低效实例，这个数字不小，说明它的静态检查器不是“玩具级提示”，而是能在大项目里真正跑开。这里最值得注意的是，检测量大并不等于噪声大，关键还得看后面的修复质量。
表4：跨OpenHarmony系统服务的检测结果
表4：跨 OpenHarmony 系统服务的检测结果。可以看到，不同服务里的问题分布并不均匀，有的服务字符串重建特别多，有的静态表格问题更突出，这也说明内存反模式具有明显的业务和模块差异。
真正决定论文成色的，是修复结果。MOA 最终生成了 769 个补丁，经过人工维护者审查后，92.5% 被接受为有效补丁。这个接受率很关键，因为它意味着方法不是只会“报问题”，而是真的能“改问题”。平均下来，补丁带来了 42.2% 的堆内存下降和 10.6% 的二进制体积下降。对于性能工程来说，这种收益已经不是“优化一下”，而是能让系统呼吸顺畅不少。
表5：T1与T4的补丁生成和优化结果
表5：T1 与 T4 的补丁生成和优化结果。这里能看出，某些静态对象和常驻堆结构一旦被清理，收益会非常直接，尤其是二进制体积和初始化开销，往往会立刻变轻。
表6：补丁生成结果
表6：补丁生成结果。论文在这里展示了不同类型补丁的生成情况，说明 MOA 不是只会修一种“模板病”，而是能针对不同反模式输出不同的修复策略。
表7：Camera Service上的消融实验结果
表7：Camera Service 上的消融实验结果。消融的意义在于证明三段式设计不是摆设：少了审核，报告质量会掉；少了检查器合成，检测规模会缩水；少了状态机，补丁稳定性就会变差。

优势与局限：MOA是“银弹”吗？我们该如何看待它？

MOA 的优点很清楚：它把“运行时症状”“静态检测”“代码修复”串成了闭环，而且每一步都加了验证机制，尽量避免大模型胡说八道。对于大代码库来说，这种闭环很值钱，因为人工排查内存问题的成本极高，尤其是在系统软件里，问题常常散落在多个文件、多个模块、多个调用链上。
表8：各阶段平均成本拆解
表8：各阶段平均成本拆解。成本主要花在分析、合成和验证上，这也提醒一个现实问题：MOA虽然自动化程度高，但不是“零成本魔法”，它仍然需要算力、工具链和多轮迭代。
它的局限也不能装看不见。第一，MOA依赖 profiling 数据，没采到的症状就没法谈起；第二，它当前主要验证在 C/C++ 系统软件上，迁移到别的语言和框架，工具链要重做；第三，补丁虽然通过率高，但仍然要人工审查，说明它离“完全无人值守”还有距离。换句话说，MOA更像是一个高质量自动化助手，而不是直接替开发者上班的替身。
但这并不妨碍它很有启发性。它真正值得借鉴的，不是“某个检查规则”本身，而是这套方法论：让大模型负责从证据到抽象，再从抽象到修复，但始终把编译、验证、回退这些硬约束握在手里。这才是大模型进工程场景的正确姿势，既不神化，也不放飞。

龙迷三问

下面是龙哥对于大家可能的一些问题的解答：

这篇论文到底解决了什么问题？它解决的是“大型代码库里的内存低效问题怎么自动发现、自动归纳、自动修复”这个老大难。传统做法要靠人盯 profiling、翻源码、写规则、改补丁，MOA把这条链路尽量自动化了。

文中的 Analyzer、Checker Generator、Patcher 分别在干什么？Analyzer 负责从 profiling 和源码里挖反模式；Checker Generator 把反模式变成静态检查器；Patcher 则根据检测结果生成并验证补丁。三者分别对应“找病、定病、治病”。

MOA里的 profiling 为什么这么重要？因为内存低效很多时候不是单看源码就能猜到的，它依赖运行时行为。profiling 提供了“症状证据”，再结合源码语义，才能把局部现象抽象成可复用的反模式，不然就容易只见树木不见森林。

如果你还有哪些想要了解的，欢迎在评论区留言或者讨论~

龙哥点评

论文创新性分数：★★★★☆。把 profiling、静态分析和补丁生成串成闭环，这个组合不算空前，但把它做成可执行、可验证、可回退的工程流水线，还是挺有想法的。

实验合理度：★★★★☆。OpenHarmony 这个场景很硬，数据量也够大，且有消融和人工接受率验证，整体比较可信；不过仍主要集中在单一系统栈，外推性还要再看。

学术研究价值：★★★★☆。它把“运行时症状如何转成可复用规则”这条链路讲得比较清楚，对软件工程自动化和性能工程都有启发。

稳定性：★★★☆☆。有状态机和验证机制加持，已经比纯生成式方法稳不少，但仍依赖 profiling、工具链和人工审核，离“全自动无人值守”还有差距。

适应性以及泛化能力：★★★☆☆。在 C/C++ 系统软件上很有潜力，但换语言、换架构、换工具链，迁移成本不低。

硬件需求及成本：★★★☆☆。需要 profiling、LLM 多轮迭代、静态分析和补丁验证，算力和工程成本都不算低，但换来的是大代码库里的高收益。

复现难度：★★★☆☆。论文给了完整流程和工具栈，但要在真实大项目上复现，仍需要较强的工程环境和数据准备。

产品化成熟度：★★★☆☆。更像高价值的性能工程助手，适合辅助专家做大规模排查和批量修复，不适合直接无脑上线替代人工。

可能的问题：对 profiling 质量依赖较强，且补丁生成仍需人工把关；方法更适合已知栈和可观测系统，不是通吃型银弹。


主要参考文献

[1] Jiaxi Liang, Yuanxiang Shi, Zezhou Yang, Chenxiong Qian. MOA: A Profiling-Guided LLM Framework for Memory-Optimization Automation at Codebase Scale. arXiv:2606.31368v1, 2026.
[2] Clang Static Analyzer 官方文档与 Clang-Tidy 性能检查规则。
[3] Memoro：用于内存行为 profiling 的工具，基于 LLVM/Clang AddressSanitizer 框架。

end
欢迎加入龙哥读论文粉丝群，扫描下方二维码或者添加龙哥助手微信号加群：kangjinlonghelper。一定要备注：研究方向+地点+学校/公司+昵称（如 图像处理+上海+清华+龙哥），根据格式备注，可更快被通过且邀请进群。
『龙哥读论文』微信群目前包含：图像处理、大模型及智能体、自动驾驶及机器人、AI医疗及AI金融5个群
wechat_helperdianzan
转发文章 微博 X LinkedIn Facebook
龙哥读论文 · PaperDaily

本文基于龙哥读论文 PaperDaily 数据库整理，结合论文原文与工程视角进行解读。