使用Rust重写mtr -- AI编程的一次探索性实践
使用Rust重写mtr -- AI编程的一次探索性实践
成果展示
编写这个项目的核心目的
核心目的其实没有那么复杂。对于我个人来说，我就是喜欢折腾。折腾技术的感觉会给我带来成就感或思考的动力以及行动上的正反馈。其次，说的可能大众化一点，那就是为了探索AI的实际使用案例，得到更多的使用经验，为后续继续使用AI积累更多的经验。再者，我也想尝试一下，对于mtr这个接近一万行的源码仓库，重构起来，对于当前的大语言模型来说，会不会存在困难。
OpenClaw
我使用的工具，最开始是openclaw。其实没有特别的原因，只是单纯我刚好打开了浏览器，进入了openclaw的gateway页面，我就让他开始规划项目。我最开始做的是将mtr的源代码拉到了本地。
一万行的源代码其实不算特别多，也正是因为如此，我并没有使用claude code，codex等专门为编码使用的agent。加上我对于我自己之前使用模型来编写代码这件事情，一直没有特别认真去研究，总感觉我自己用的和那些公司宣传的差距很大(可能真就是宣传)。所以我想使用比较不那么专一的工具来完成这个项目，进而体现出所谓harness或者非模型之外的流程或者环境对项目的完成度的影响。
Docs
架构&PRD
我第一步做的事情是让openclaw先分析mtr的c语言代码，生成足够多以及足够详细的文档。这些文档中，包括: 项目总览、架构分层设计、实现细节，然后在根据这些细节设计PRD、用户故事(Epic)、做需求拆分。当然这个流程中可以使用多个agent来并行编写不同的文档。
最终生成的文档如下
这个时候我还是没有让agent继续干活，而是继续让agent先参考C语言的源代码，编写好测试和benchmark的说明。当然这个过程中使用了superpowers的skill，这个skill集合确实不错，推荐一下。
需求拆分
为了实现这个工具，整体的需求拆分还是需要的。这个对于模型来说不要太简单。同样，结果写入文件(这里的任务分级有一些类似jira，也存在MileStone等)
Tasks
在最终的编码开始之前，还做了的一件事情就是对需求的任务拆分。这其实算是一种对于当下模型还存在能力不足的一种应对方式。对于比较大的需求，更细致的拆分，以及更细致任务描述有助于模型针对性地解决问题。
将任务拆分后写入到对应的task.json，并且限定每一项task继续进行的依赖task，以及状态。这些操作能在一定程度上降低模型在项目需求实现上的随意性，也能更好地让人直观地看到当前进行到哪里了。
WORKFLOW.md
为了更规范地限制模型的工作流程，我让模型制定了一套工作流，里面描述了如何获取task，完成task之后需要更新状态，什么时候需要求助，如何进行feature的开发(比如新开一个分支，测试验证通过后再来合并到主分支等等)，提交之前一定要进行完整的测试等等。其实在这里，如果给到更大的权限，以及外部一个更大的循环来不断运行agent，那可以实现一个相当长时间的运行。也就是说，确实是可以让模型一直自己实现功能，测试，review，提交。
准备差不多之后，可以开始真的实现功能了。下面是第一个阶段(task分为了不同的MileStone)的提交情况
额外插一嘴: 这里vscode的插件是git graph。我其实不是vscode的死忠粉，我更喜欢终端下编辑，我日常使用的是自己配置的neovim。后续找了下插件，发现neogit这个插件也能实现同样的功能如下图。
openclaw的webui界面一个我比较喜欢的点是，可以看到当前跑的agent有哪些(显然，有这种展示功能的工具也不少)。这样至少让我对整个项目的进度有一定的把控感。
停滞不前
当整个项目进行到要进行整体的验证结果的时候，开始出了问题。这个时候Agent仿佛陷入到一个debug漩涡里面。可以看到，这里未提交的已经修改的代码，已经到1.2行了
过于自信
对于一个任务，在没有进行测试的情况下，agent会直接提交代码，并且向我汇报已经完成。这个时候其实是最让人火大的。这个时候我还得重新和它说明,应该严格按照之前规划好的流程来继续完成任务。
忘记之前的约定
由于过分长得上下文，模型开始遗忘之前我和它的约定。一个比较明显的例子就是，在最开始我和agent约定，在测试没有完全通过时，不要提交代码。但是在后续的任务中，经常出现直接提交的情况(不排除工具和模型的问题)。
是否是测试迷惑了模型？
其实在构建整个项目之前，我就已经给agent定了方向。在拆分出task之后，一定要构建相应的的测试，用于验证task的完成情况。起初这个方法让agent工作的很好。但是随着项目的越来越复杂，要测试的task越来越多。agent仿佛被之前的task的测试成功迷惑，对于当下的任务的失败置之不理，或者说总能找到一个"安慰自己的理由"来说服自己继续进行。
过于爆炸的上下文
上下文在这个AI发展的初期(至少我这么认为)，真的是一个非常珍贵的资源。如何合理地分配好不同内容在上下文中的占比成了当下harness的一部分。当然，在编码中其实很难预料到这一点。
在一开始，我让agent生成prd、项目结构、需求分析、用户故事、实现流程、工作流程等等。agent为我生成了大量的文档。每次一个session启动时(后续会说，其实我会为了更新上下文，顺序启动多个session)，都会先去读取这些巨量的md文件。很明显，这非常占用上下文。我使用opus4.6，30美元还没开始写代码，token就用完了(饿啊～，快给我token！！！我浑身蚂蚁爬！！！)。
继续前进
手动reset session
和前面说的一样，上下文是一种资源，而承载这种资源的一个独立单元就是session。或者说每一次单独的对话。当某一次对话的上下文太长时，模型的能力会快速下降。所以很多agent都会做context compact。也就是上下文压缩。但是从我自己的使用情况以及anthoropic的Harness design for long-running-application development文章来看，其实启动一个新的对话，来继续前面未完成的任务。
不需要那么多文档占用上下文
每次新session启动，我都会让agent读取巨量的文档，这不仅耗时，而且占用上下文。我每次其实很不想和agent说去读那些文件，或者说agent会自动去读(可能是因为读了，反而任务实现的效果不好)。所以我直接删除了之前的文档。每次开始的提示词也变得简单，在分析项目代码的基础上，只告诉agent当前的需求，虽然有整体的目标记录，但是不再是一次性喂给agent。从这之后，效果反而好了。总之轻装上阵，确实比满身的包袱上手地快。
权衡输入信息和项目信息在有限上下文总量中的占比平衡
当前我们要做的，其实很多在权衡给到agent的不同信息的占比，以及模型生成结果的概率分布。就当前而言(2026-04)agent的核心是 大模型+外围工具。即基于大模型的决策与预测能力(亚符号主义，或者说一种大模型具有的"直觉")与拥有确定结果的工具(符号主义)的结合。因此，在一个任务中，我们可以通过prompt，上下文来调整大语言模型的"直觉"，通过这些可以调整模型在生成结果上的概率分布(本身模型的基础是基于条件概率的生成)。在prompt的输入中，我们可以规定模型一个角色，或者具有某方面的专业技能，在任务的过程中，工具的结果，项目的信息都会作为输入，来影响模型的生成情况。有限的上下文中，我们如何分配，是巨大的prompt,还是更多去读取项目信息亦或是工具的选择都是在AI harness工程中可以思考和优化的方向。(比如工具方面，github上已经有很多专门针对agent调用来进行优化的终端工具，用于替代ls，grep等"上古时代"的工具)
对于代码，能不能只关注问题部分的最小依赖
这里还可以插入的一个点是，最小依赖问题。对于一个任务来说，它可能会以来不同的其他部分的代码，而其他代码又可能会依赖其他的其他。那怎么让模型在检索代码时找到最小的依赖，而不飓风吸入代码库而导致上下文爆炸呢？其实我想到的一个点是，我们可以使用AST(抽象语法树)。这是编译原理里面的一个概念。我们在写出编程语言的代码之后，编译器会对我们的的代码文本进行词法分析(基础的token，如关键字，变量，字符串等的结构化)，语法分析(分析语法是否合法，这一个阶段会生成ast)，中间代码生成(优化部分代码，解开语法糖等等)，生成对应平台的机器码(不同平台的架构不同，如x86，arm等)。ast包含了结构化的代码内容，我们可以通过ast的mcp来让agent获取最小代码依赖，从而减少不必要的上下文输入。这个mcp其实叫做tree sitter mcp。其实在neovim0.12之前，tree sitter都是我们这些终端党的最爱，可以用来高亮代码，也可以自定义不同token的颜色。
重新规划 -- 单一化，细致化方案
在删除了prd，项目文档之后。我并没有直接让AI来规划一个新的路径。针对mtr这个工具，我只是整理了核心需求，并且我自己做了核心需求的任务拆分。比如核心是发包和收包以及计算时延。这三个功能可以继续往下拆分，发包可以拆分为不同类型的包构建，而构建规则可以根据相关的rfc文档来实现。在人工规划和细致化任务之后，事情慢慢开始走向了正轨。
更多地输出debug信息
在测试以及实现功能的过程中，更多的debug信息能更好地指导agent进行下一步计划。其实这一点也很好理解，从我们自身出发，上古时代，人类还在手动编写代码的时候也会在代码里面增加debug的信息输出，不说使用trace(rust)，go(zap)这些优秀的日志库，最基础，我们都使用过print来打印结果。ai时代也是如此。更多的运行信息可以帮助AI更好的了解在运行时，代码的状态。
妥善处理权限问题
mtr这个工具本身需要cap_net_raw权限，在每次需要测试时，ai都因为没有被授予sudo的权限而开始胡乱猜测或者所谓"另辟蹊径"，但往往结果一般都是南辕北辙。这里我的处理是，提前预定遇到类似的权限问题，需要停下来询问我，让我来执行授予权限的命令。这个其实也是比较麻烦的，你必须得带在电脑旁，守着agent，看它啥时候给你"整个活"。并且，随着前面说的上下文的爆炸，这个约定也会被慢慢忘记。所以在开启一个项目前，最好考虑好权限可能带来的问题。目前我想到的一个方法是把agent放在隔离环境内，授予最大权限。(mtr这个项目我是完全在我自己的主力机器上，所以我并不敢给到更高的权限了)
装好Agent的"手"和"脚"之后，"抽象整活"，这是我们的近未来
如同上面说的，当前agent其实是大模型+外围工具。除了我们通过调整prompt，上下文来调整大模型本身，给agent装好相关的工具手脚也很重要。比如我的博客前端页面，其实经历了一轮重构，之前使用的是hugo现成的theme。我看了几年了，有点腻了，所以我让claude code+deepseek-v4-pro重构了我的博客。在这之中使用到的最重要的两个工具就是superpowers skill和expect skill。第一个skill，可以根据我的需求进行规划，甚至它能让agent先生成一个demo在浏览器中展示，让我选择不同的风格，或者交互方式。记录下来后再按照我的选择来进行实现。而第二个skill则是前端debug神器，它可以让agent使用"人话"来运行chrome浏览器，类似截图，点击按钮，输入，查看console的log等等。这大大提高了agent的准确率。
给agent装好"手"和"脚"后，我们该干什么呢？从前面的结论来看，作为agent的指挥官，我们需要有全局思维，以及对任务的抽象分解能力。全局是我们需要对大局的方向掌控，目标是目标，可以发散但不能偏离。抽象则是对当前AI还未完全介入生活工作的一个前置。生活与工作的很多任务，其实有比较清晰的流程，如果我们能抽象出这些流程，并且给到agent可以操作的接口，其实很多事情，我们可以放手(前提是我们对于权限隐私的掌控要在自己的可控范围内)。这其实是我认为的当下AI时代，我们能够体现价值的地方。
保持良好的心态
目前而言，整个流程虽然在往前推进但是中途会有很多分叉出现，agent会出现诸如上面说的一些列问题。这个时候我也有非常沮丧的时候，觉得不过如此。但是每次在平心静气之后，仔细思考可能的原因，比如看看AI的思考过程，看看它为什么出错，再根据这些错误去应用对应的对策，这个流程也是非常对我有正向激励的。
后续
项目的可维护性
其实ai写的代码，最让我担心的就是后续的迭代。目前来说，其实在遇到问题时，遵循我自己总结的几个方法，ai的准确性还可以。不同功能的维护，以及新需求的实现，可以继续遵循上述流程，但是一个很重要的点是对当前工作的总结，方便将工作传递给下一个session。虽然但是，可能是当前项目仓库还不够大，目前只有4-5k的rust代码量。这个后续还有待继续深入讨论。
尝试更完善的模型与工具
这个项目我使用的工具是openclaw+minimax2.7，可能工具和模型并不是最好。在使用了deepseek-v4-pro，以及gpt-5.5等模型之后，目前我得出的一个结论是
上述所谓的一系列问题: 自信、上下文爆炸、胡乱猜测等等问题都会随着模型的迭代得到解决
我们会进入一个更加便利的AI时代，这些所谓的驾驭工程也会随着模型的完善，消失在历史的长河中。所以，选择合适的工具和模型吧！！！
国家十五五规划 -- 算力网络的铺开
突然且生硬的专场后
在《中华人民共和国国民经济和社会发展第十五个五年规划纲要》，简称十五五规划中，有这么一段话。
全国一体化算力网 建设新一代超算、通算、智算设施体系，积极发展公有云服务。建设算力监 测调度平台，制定完善算力资源池化、并网、监测、运营、调度等标准规范。
其实在更宏观的层面，国家已经在规划算力网络的建设了。在2025年3月的一个央视采访里，阿里云的创始人王坚院士在两会的提案里说到了这个概念。给了我一个大大的震撼。未来算力或许会和电力一样，即接即用。
身处这个时代趋势下，国家政府确实在把控整体的发展方向。或许就像汽车的出现到普及，现在的人不必知道车子的每一个细节和原理，但一样可以便利我们的生活，也由此衍生出出租车司机、代驾等岗位。AI，算力也是如此，或许我们对底层的算法细节不清楚，但是我们需要利用好以此来便利我们的生活和工作。我也相信由此一定会衍生出相关的岗位与职业。
作为一个普通人，顺势而为, 不断学习 是我对当下个人发展方向的看法。
Peace
没有总结，来自一个对技术热爱，更喜欢折腾的Linux爱好者😁
评论 (...)
加载中...