AI写代码已经够快了，真正拖慢软件开发的，是没人能证明它做对了。

一个叫Morluto的开发者，几个月里连续做出六个开源工具，分别帮助AI调查陌生软件、定位源码、执行数学计算、寻找性能瓶颈、验证运行结果，以及参与复杂的开源工程。

其中最出名的REA，Reverse Engineer Anything，2026年4月14日才创建，到10月12日GitHub Star已经接近13万。它能让Codex、Claude Code等Agent调查没有源码的软件，从界面行为一路追查到程序内部的函数、调用关系和机器指令，再尝试重建其中的功能。

但REA只是Morluto最容易被理解的一件作品。

把他的六个工具放在一起，几乎就是一套AI时代的软件工程方法：调查问题、定位代码、研究实现、编写程序、验证逻辑、检查性能，最后凭证据决定能否交付。

他正在把优秀工程师过去依赖个人经验完成的专业工作，逐一变成Agent可以调用的能力。

这件事比一个开源项目拿到十几万Star更值得研究。

Morluto的真实身份并不透明。GitHub没有可靠披露他的真实姓名、年龄、教育背景和完整职业经历。个人博客主要记录论文阅读、开源开发和研究心得，自述的研究方向包括Agent、强化学习环境、偏好学习和AI数学。

但他的代码记录相当丰富。

GitHub公开展示了252个仓库，其中9个是非Fork仓库，其余243个是Fork。大量Fork属于技术研究和参与上游开发的工作副本，真正值得看的是他参与了哪些项目。

他给Triton修复过自动调优逻辑，给NVIDIA NeMo优化过强化学习回报计算，给TileLang修复过GPU代码生成问题，还给SymPy修复过多项式算法错误。

另一批贡献发生在Qwen Code、OpenClaw、MCP TypeScript SDK、RepoPrompt和Reef，涉及权限检查、异常处理、进程生命周期、上下文管理和持续学习记录。其中多项PR已经被原项目维护者合并。

这些工作涉及GPU编译器、强化学习框架、Agent运行时和数学计算库。能够进入陌生的复杂代码库，找到具体缺陷，并提交被上游接受的修复，至少证明了他具备扎实的跨技术栈工程能力。

更有意思的是他关注的问题：调用失败后资源有没有释放，类型转换会不会丢失信息，权限边界是否正确，循环中有没有隐藏的重复计算，训练记录发生冲突能否恢复。

这些事情很少出现在AI产品发布会上，却决定着软件能否长期运行。

2026年7月，他接连创建LeanToken、GitContribute、Jacobian和flameox，8月又发布SmokingGun和internalcot。开发语言横跨Rust、Go、Python和TypeScript。

看起来分散的项目，背后其实有相当一致的工程思路。

传统逆向工程早就有Ghidra、IDA和Hopper等成熟工具。它们能够检查二进制程序、反汇编指令、生成伪代码、查找函数引用。

真正困难的是调查过程。

一个软件可能包含几万个函数，工程师需要判断从哪里开始，沿着什么调用关系继续追踪，以及什么证据足以支持结论。

REA通过MCP和CLI，把这些专业工具组织成Agent能够调用的调查能力。用户提出问题，Agent选择工具、分析目标、获取证据，再决定下一步调查什么。它支持原生程序、Electron应用、JavaScript、.NET程序集等不同分析路径。

REA本身没有发明万能反编译算法。它借助成熟工具，让Agent接管大量需要人工判断和操作的调查步骤。

官方有一个很精彩的案例。

1996年的Windows游戏DX-Ball，有一段控制声音左右声道位置的程序。开发者希望把这个功能恢复成可以维护的C代码。

最初得到的反编译结果并不完整，只能看到部分调用，具体计算过程仍然不清楚。Agent继续沿调用关系调查，检查汇编指令、寻找输入参数，从二进制数据中读取出1.5625和500两个常量，最终恢复了屏幕横坐标如何转换成声音位置的算法。

重建以后，项目又进行了3205组原始x86行为对比，并使用指定的VC4.0编译环境检查，最终匹配了完整函数的63个机器码字节。

到2026年10月7日，DX-Ball重建项目已经实现55个可维护的C函数，累计完成45380次原始代码行为对比，其中33个函数实现了编译字节匹配。

AI没有因为得到一段看起来合理的伪代码就宣布成功。它继续寻找证据，直到可以用原始程序检查重建结果。

这是REA真正有价值的地方。

企业迁移旧系统，经常遇到源码丢失、供应商停止维护、接口文档不完整的情况。团队也可能需要研究第三方软件的数据格式、兼容机制和实际行为。过去，这些工作大量依赖高级工程师的个人经验。

REA让Agent有机会参与调查，并把结论、依据和未知项一并交回来。当然，逆向分析仍需符合合法授权、知识产权和软件许可要求，技术上能够理解某个功能，也不意味着可以随意复制受保护的代码和资源。

REA改变的是知识获取方式。软件开发可以从调查未知系统开始，而不必始终受限于现有源码和文档。

Morluto的另外五个主要工程工具，分别对准软件开发中的其他薄弱环节。

按照任务顺序排列，可以得到一套相当完整的工作流程。

这六个工具目前是独立项目，Morluto并没有发布将它们全部集成的一键式开发平台。代码编写仍需要Codex等Agent，需求判断、业务验收和持续运营也需要其他能力。

但它们已经展示了一条非常清楚的工程路线。

每个阶段负责解决一种问题，产生下一阶段能够使用的结果。缺少必要证据，就继续调查或明确记录风险，不能让Agent凭想象填补空白。

假设一家企业要升级使用多年的报价系统。旧代码复杂，业务规则分散在不同模块里。管理层希望加快订单搜索，同时保证历史报价计算规则不变。

普通Agent可能阅读几个文件后就开始修改，遇到错误继续修，直到测试通过。看起来效率很高，却可能从第一步就理解错了任务。

Morluto的几个工具，恰好可以改变这段工作过程。

GitContribute负责开发任务的前期调查。

GitHub上的一条Issue可能已经过时，其他工程师可能处理过类似问题，维护者也可能否定过某种方案。GitContribute会收集仓库规范、相关Issue、PR、讨论和代码上下文，存入本地SQLite资料库，帮助Agent检查任务是否仍然有效，有没有重复工作，以及修改需要遵守哪些约束。

它主要服务于开源仓库的工程任务研究，不替企业判断商业需求，也不会擅自向GitHub提交修改。

这体现了一条简单的原则：没调查清楚的任务，执行得再快也可能是浪费。

任务确认以后，接下来是定位相关代码。

传统编码Agent常常大量搜索文件、读取源码、重复传送上下文。一个只涉及两个函数的Bug，可能消耗大量Token才能找到。

LeanToken用Rust建立代码索引，支持按任务检索文件、函数、符号和精确代码范围，还可以利用内容哈希和检索记录，减少重复发送已经读过的源码。

项目公开的一项60次受控测试显示，相比两种不同程度的基础仓库探索方式，LeanToken分别减少约20.1%和37.6%的模型输入Token。这个结果不能简单推广到所有项目，但说明了它的设计价值。

优秀工程师进入陌生代码库，通常先寻找入口、依赖关系和相关测试，再阅读关键实现。LeanToken尝试把这种代码定位能力工具化。

上下文窗口再大，也不能代替准确的信息定位。把十万行源码交给AI，远不如让它先找到真正相关的两百行。

如果有源码，就用LeanToken定位实现；如果源码缺失，或者已发布程序的行为无法从现有源码解释，再用REA补充调查。

两者解决了软件工程中两种常见的知识缺口：已有代码找不到，未知系统看不懂。

直到任务范围、关键代码和实现依据基本清楚，才进入开发阶段。

Morluto没有重新开发一个通用编码Agent。代码编辑、命令执行和功能实现，可以交给Codex、Claude Code等现有工具。他把精力集中在编码Agent容易出错的专业环节。

Jacobian就是典型例子。

AI写数学代码，经常出现算法思路看起来成立，却在符号计算、数值精度或者边界条件上出错的问题。模型可以临时生成Python脚本，但反复编写计算程序既浪费资源，也增加验证负担。

Jacobian把数学计算封装成语义明确、可以组合的操作。它借助SymPy、NetworkX、Z3和Python-FLINT等成熟计算后端，提供多项式、精确线性代数、图论和部分约束求解能力。

Agent决定需要什么计算，调用工具获得类型明确的结果，再继续推理。

这种设计很重要。需要反复使用的专业能力，应该沉淀成可验证的工具，没必要让模型每次重新发明。

Jacobian适合有明确数学计算需求的项目，不能代替普通业务系统的单元测试、集成测试和权限验证。它保证的是受支持操作在明确条件下的计算结果，完整程序的正确性仍需要其他证据。

完成代码和功能测试以后，接下来才是优化。

这里有两个不同的问题：哪些地方可能存在性能问题，以及修改以后究竟有没有变快。

SmokingGun负责前一个问题。

它扫描代码中的潜在复杂度热点，结合已有的性能测量材料，帮助Agent判断哪些实现值得调查。它不会自动执行目标程序，也不会擅自修改源码。

一个订单函数即使存在多层循环，如果每天只执行几十次，也可能没有优化价值。反过来，一条简单的数据库查询，如果每笔订单重复执行几百次，可能成为整个系统的主要瓶颈。

SmokingGun提供候选问题，flameox进一步提供运行证据。

flameox协调Profiler、Benchmark和Trace等工具，分析程序实际运行时的资源消耗、热点和性能表现，并保存必要的执行来源、实验条件和结果限制。

例如Agent声称让AI推理服务的延迟降低30%。如果测试前后的输入规模、GPU配置、并发条件和缓存状态不同，这个数字很可能没有可比性。如果速度提高却损害了结果正确性，优化同样不能算成功。

代码复杂，不代表值得优化。测试跑得快，也不代表产品真的变快。

SmokingGun负责发现候选问题，flameox帮助验证实际效果。这种分工比让Agent看到复杂代码就开始大规模重构可靠得多。

AI能够快速生成几十种优化方案以后，真正耗费工程资源的，恰恰是判断哪些方案有效，以及它们有没有引入新的问题。

研究Morluto的项目，我认为最值得认真阅读的，甚至不是README，而是AGENTS.md。

这些文件规定了参与项目开发的编码Agent必须遵守的架构约束、操作权限、修改原则和测试要求。几个项目的具体规则不同，但可以提炼出四条非常一致的工程纪律。

第一，修复错误，要找到错误产生的源头。

REA的开发规则明确要求，遇到Bug时，应调查错误第一次发生的边界，检查其他模块有没有重复解释同一份数据，优先修复造成问题的表示或归属规则。

假设报价系统把一个客户识别成两个账户。普通Agent可能在页面增加去重判断，测试通过，问题暂时消失。但如果错误来自底层客户标识没有统一处理，换一个入口，同样的问题还会出现。

正确的修复应该找到身份数据第一次变错的位置，修复底层规则，再检查相关模块，清理已经多余的补丁。

测试通过，只能证明被测试的场景没有再次出错，不能证明根本原因已经消除。

第二，没有证据的地方，必须承认不知道。

GitContribute要求把缺失、过期和不完整的资料标记为未知。SmokingGun不能因为部分代码没有扫描到，就宣称没有问题。REA要求区分实际观察、推导结论、推测和未知项。

这条规则非常重要。语言模型擅长把不完整的信息补成连贯的解释，但工程系统经不起这种自信。一次错误判断如果被后续Agent当成事实，问题会沿着工作流程不断放大。

第三，工具权限必须明确。

REA的安装和配置要求展示操作计划、保留备份，并在修改前取得批准。GitContribute把数据读取、网络访问、本地写入、进程执行和GitHub修改区分为不同能力。

Agent可以自动调查问题，不意味着它应该自动获得修改所有文件、运行所有程序和操作外部系统的权限。

第四，验证必须对应真实环境。

REA要求尽可能通过公开CLI、MCP和真实分析工具链验证功能。模拟测试通过，不能冒充真实Hopper、Ghidra环境已经验证成功。

LeanToken也规定，不能仅凭一次微基准测试的速度提升，就牺牲存储正确性、一致性或确定性。

这些规范背后有一个共同判断：

AI可以积极修改代码，但不能轻易宣布成功。做了什么，和证明了什么，必须分开。

一个Agent一天提交上百次修改，并不值得炫耀。如果没有明确的任务、证据、测试和回归检查，高速开发只会让技术债务加速累积。

这也是Morluto的几个工具能够形成统一方法的真正原因。它们各自处理不同问题，却都试图让Agent的判断接受外部证据检验。

Morluto还与长期合作者N0zoM1z0研究了一个存在约33年的Erdős数学问题，并公开了候选证明、Lean 4形式化代码和计算验证材料。

这项研究目前仍需独立专家审查，部分形式化结论依赖尚待确认的外部输入，不能直接视为已经得到数学界确认的成果。

不过，研究过程很有代表性。

面对复杂数学问题，他尝试利用AI提出思路，通过精确计算工具检查局部结果，再用形式化系统验证推理链条，并把没有完成验证的部分明确记录下来。

这与他的软件工程方法高度一致。

在2026年9月发表的《AI Math, Paul Erdos & Attention》中，他讨论过数学研究如何受到人类注意力的限制。研究人员很难同时熟悉大量领域、探索所有可能思路，而Agent有机会增加探索广度。

但探索次数增加，也会带来大量错误和无效尝试。只有可靠的计算工具与验证机制，才能让更多探索真正产生价值。

这也是Jacobian出现的背景。

他参与的Reef项目，则尝试为Agent持续学习提供基础设施，包括记录反馈、管理训练历史和安全处理版本更新。

从逆向工程到数学研究，再到Agent持续学习，可以看到一条相当清晰的技术主线：让Agent尝试复杂任务，通过专业工具获得证据，再利用验证结果决定下一步行动。

他还有一个名为Preference的项目，面向金融研究和交易Agent提供市场数据与研究基础设施。它也延续了相似的思路：把真实数据和结构化工具交给Agent，让它能够在复杂环境中开展研究。

这些项目跨越多个领域，却都围绕Agent如何可靠地完成专业工作展开。

回到软件产品开发。

如果用Morluto的工具组合升级一家企业的报价系统，工作流程已经相当清楚：先确认任务与约束，调查已有代码和参考实现，交给编码Agent完成修改，再检查逻辑、发现潜在瓶颈，最后凭测试和性能数据验收。

每个环节都有明确的交付结果，也能够记录哪些问题仍未解决。

对于AI软件工程而言，这是一套很值得借鉴的工作方法。

不过，要把它升级成完整的软件产品生产体系，还缺两个关键环节。

第一个是需求价值判断。

REA可以研究别人怎么实现某项功能，LeanToken可以找到相关代码，Codex能够生成实现，flameox可以测量性能。但它们无法单独回答一个商业问题：这个功能值得开发吗？

一个软件可能功能完整、性能优秀，最后却没有多少用户愿意付费。技术调查不能代替真实客户研究，竞品拥有某种功能，也不能证明自己的产品需要同样的东西。

需求价值应该成为整个流程的起点。谁需要它，解决什么问题，现有办法为什么不够好，如何确认用户愿意采用，这些问题必须先有答案。

第二个是持续运营与业务验收。

软件通过测试以后，还要面对真实用户、生产数据、规模变化和外部依赖。系统需要监控、回滚、故障恢复和业务效果复核，还需要根据用户反馈决定下一次修改。

Morluto的工具已经覆盖了相当一部分工程调查与验证工作，却没有完整解决商业软件从需求发现到长期经营的全部问题。

把这两个环节补齐，才是一套更完整的AI软件生产体系：需求价值决定做什么，专业工具负责调查和实现，测试与证据决定能否交付，真实用户和生产数据决定下一轮改什么。

这对小型软件团队尤其重要。

过去，需要不同资历的工程师分别承担代码分析、程序开发、性能优化和测试验收。Agent能够调用专业工具以后，小团队也有机会复用成熟工程组织的一部分能力。

但开发人员减少，不代表工程责任消失。AI承担的执行工作增加，对需求决策、权限控制和结果验收的要求反而更高。

REA的爆火，证明了开发者对Agent专业能力的强烈兴趣。十几万GitHub Star能否转化成稳定用户、长期维护能力和商业收入，还需要时间检验。Morluto的其他几个原创工具也大多处于早期阶段。

但他已经展示了一种值得长期研究的产品方法。

先找到复杂工作中最昂贵、最依赖专业经验的环节，再利用成熟技术和清晰的接口，把这项能力交给Agent。通过工程规则控制权限，通过测试与真实数据检验结果。

每个项目解决一个具体问题，组合起来就有机会改变整条工作流程。

AI时代，写出代码的能力会越来越普遍。最值钱的工程能力，将集中到三个问题：该做什么，怎么知道做对了，出了问题如何找到真正的原因。

REA负责调查未知系统，LeanToken负责找到相关代码，Jacobian提供精确数学操作，SmokingGun发现潜在问题，flameox取得运行证据，GitContribute帮助Agent理解已有工程及其协作规则。

这些工具未必都会成为长期成功的产品，但它们体现了一种很值得保存的软件工程思想。

未来软件公司的竞争，可能会从拥有多少会写代码的人，转向能否把正确的工作方法，变成Agent可以反复执行、逐步验证的生产体系。

Morluto已经给出了一个很有说服力的雏形。