【智能体软件工程·实践篇】把 Kimi K3.1 Pro 放入真实 Rust 项目之后

本文从 UU 工程审查、Oseasy 逆向到深度调研报告，看看 Kimi 在 OctoLoop 双环里提供了什么价值，并收获 uu 远程 omarchy rust实现开源版本（非官方）和三份论文级深度调研报告（见另外三篇文章）。结尾有彩蛋。

起因：我想在 MateBook Fold 上用 Omarchy

我最近入手了一台华为 MateBook Fold，DHH 同款。

买来之后，我想在这台鸿蒙 PC 上用上 Omarchy。围绕这个需求，我同时推进了两个项目。

第一条路是远程使用。 Omarchy 跑在另一台 Linux 机器上，我用 MateBook Fold 上的官方 UU 客户端连接过去。为此，我用 Rust 开发了运行在 Omarchy 上的 UU 兼容被控端，让官方客户端能够看到并操作它的桌面。主控端界面继续沿用官方客户端，重点补齐 Linux 被控端的连接、画面、输入和音频能力。

这个项目叫 uu-remote-rs，我准备将它开源，仓库地址是 ZhangHanDong/uu-remote-rs。

第二条路是在本机运行。 我尝试通过鸿蒙 PC 上的 Oseasy 虚拟机运行 Omarchy（没有 root 权限只能这样），希望关机、退出应用或重启宿主之后，同一个实例还能继续使用。桌面已经能跑起来，并且效果还不错，对于体验完整 Omarchy 功能很实用。但实例一直停在“安装中”，正常关机就报安装失败。后面的 GuestAgent 和 OETool 逆向，就是为了弄清这套安装与保留流程。

两条路的出发点相同：让我用这台新电脑访问自己的 Omarchy 环境。连接断开、画面延迟、键盘映射、虚拟机状态，都是做着做着碰到的具体问题。

因为整个过程中会涉及逆向一些api和协议，所以我使用了 Octoloop + kimi 来解决这些问题。

其实 KIMI k3 我也一直在用，之前我参与组织的 GOSIM Agentic App 黑客松 https://create.gosim.org/agenticapp26/ 比赛也得到了 KIMI 的赞助，大家使用 K3 产出了不少有创意的作品。

整体我感觉 kimi 无论在编码还是视觉上，都非常不错，只是慢了点（局限于算力，这是个难题啊）。这次正好恰逢 Kimi k3.1-pro 发布，就拿来尝试解决本文遇到的这些问题。

先说清楚：OctoLoop 双环是什么

OctoLoop 是一种让多个 AI Agent 分工、执行和相互复核的工作方式。 它把推进项目的过程分成两个循环：外环围绕目标和验收做决策，内环围绕具体任务反复查证、实现和自测。

外环管方向和验收。 它把我的目标拆成有边界的任务，写清输入、交付物和验收标准；执行中观察进展，交付后独立复验，再决定采纳还是返工。复验发现的新问题，进入下一张任务卡。

内环管执行和交付。 它读取任务，查资料、读源码、改代码或写报告，必要时拆出多个子 Agent 分头工作；在任务范围内迭代，最后交回产物、验证证据和完成状态。

两个环这样接起来：外环派单 → 内环执行与自测 → 交回产物 → 外环独立复验 → 采纳或派出下一轮修订。 目标、重要取舍和授权由我来定；模型说“完成”之后，还要经过复验才算交付。

本次实践中，Codex 担任外环，Kimi 承担内环的调研、审查和部分小型实现，（如果你有的话，还可以让 Claude Code 参与实现与复核。内外环是职责，不绑定某个模型。任务通过共享黑板传递，每张卡写明版本、范围、预算与验收要求；涉及代码时，内环只提交，外环复验后再推送。

几个工具名也先交代一下：OctosCode 是内环的终端界面，octos serve 承载 Agent 运行时，herdr 用来管理、查看和驱动窗口。运行时拆出的子 Agent 称为 peer；本文 UU 工程案例里的“集群”，指的就是这些 peer 的并行协作，不是 Kimi 官方集群基准。后面的五份调研报告是另一组产物，不与工程样本合并计算性能。OctosCode 与 OctoLoop 文档

为什么把 Kimi 放进这套工作流

先看 UU 这条路。要让 MateBook Fold 成为日常使用 Omarchy 的入口，连接、输入和画面反馈都得稳定。

问题琐碎而具体。手机上看到设备在线，点进去却可能断开；键盘输入已经到了远端，画面要晚一到三秒才更新；双指滚动有时变成拖选文字；声音刚能播放，又要确认断连、换代和长时间运行是否稳定。

这类问题正好用来检验编程模型：它得读懂现有代码，追踪协议，看清“测试通过”到底证明了什么，还得在我暂停现场设备操作的阶段，交付下一步用得上的分析。

于是 Kimi K3.1 Pro 进了内环，Codex 在外环监督，Claude Code 负责实现和复核。几轮下来，在范围明确的协议查证、专项审查和功能盘点上，Kimi 的产出有用；整个工程能否交给它独立完成，这次没有测。

写作背景说明

这篇文章依据 2026 年 10 月 27—28 日（本地时间）留下的任务卡、执行记录、报告文件、外环复核和后续源码，回顾 UU 项目的六个子任务：两次早期的协议与验收审查，一次聚焦的协议复核，一次延迟分析，以及两次并行的功能盘点。

它们来自真实开发，没有随机抽题，也没有让不同模型在同一输入上重复对照。所以我只谈这套工具、这样的任务设计和这样的审查流程里，Kimi 的实际表现：线索是否成立，结论是否越界，成果能不能被收取，任务能不能收住。成本或速度是否占优、模型该排第几，这些样本回答不了。

关于模型身份：四个完成的子任务，在用量记录里都观察到了 moonshot-coding/k3.1-pro 这个标识，它是本次接入使用的名字。

Oseasy 逆向案例和五份调研报告会各自交代范围，不与 UU 的任务数量和用量混算。

协议边界：Opus 的 maxaveragebitrate

在 UU 远程 Omarchy 的 Rust 实现里，音频审查中，Kimi 盯住了一个协商参数。Opus 是一种音频编码格式，maxaveragebitrate 表示最大平均接收码率。被审查的旧实现遇到低于 6000 的值，会返回不支持错误，音频协商随之被禁用。Kimi 对照 RFC 7587 指出：规范允许正整数，对 6000 到 510000 之外的值，建议忽略。RFC 7587 第 6.1 节

它把几件容易混在一起的事拆开了。规范用的是 SHOULD，不能当成 MUST 式的违规；忽略范围外的参数，也不是把它硬抬到 6000；范围内的平均码率约束仍然要遵守。

外环核对了原文和源码，把修正交给实现任务。现在代码已改为忽略范围外的正整数，并有边界测试：零、负数、非整数仍被拒绝，特别大的正整数被忽略。音频测试后面一步通过。

这条链路里，Kimi 提供的是可核查的协议线索和测试方向，源码固定、协议文本在手、问题够窄时，它的判断足以进入工程修改，规范里的关键语义也没有丢。

延迟：没让我过早下结论

用户最直接的感受是：鼠标操作很快到了 Omarchy，画面却慢几秒。

我手上已有一些本机计时，也做过降低视频码率的实验。顺理成章的想法是：数据量小了，发得更轻松，画面应该更及时。

Kimi 的延迟分析给这个想法泼了盆冷水。用大白话说，它指出了三个容易被忽略的地方：

• 程序“拿到一帧”的时刻，不等于这帧刚被拍下的时刻，中间可能已经等了一阵；
• 程序显示“发出去了”，不等于对面收到了、解出来了、显示在屏幕上了；
• 每次只放一帧过去，也不能说明后面没有排队。

所以码率降下来，只能说明“要发的数据变少了”，不能直接说“画面变快了”。这个提醒让我把注意力从“某个数字变好看了”，拉回到真正的问题：用户眼前的画面到底晚了多久。

这是 Kimi 在这件事上最有用的地方：大家顺着一个看似合理的推论往下走时，它能指出哪一步其实还没有证据。外环复核后，又把报告的措辞收紧了半步：本机指标能解释一部分排队和写入，但分不清采集、发送、接收、显示每一段各占多少。

两个并行 peer：各自交出了完整报告

早期的一次审查，内环主任务拉起了两个 Kimi peer 分头干活：一个看协议，一个看验收边界。

回头翻工具执行记录，两个 peer 分别做了 82 次和 93 次工具调用：读代码、查资料、逐项核对，最后都把报告写成了文件。从启动到文件落盘，分别约 9 分 01 秒和 8 分 26 秒，都在当时十分钟的产物窗口之内。当时界面上看不出进展，一度以为没交出东西；对照记录和文件才确认，报告早就写好了。

这让我看到 Kimi 在“并行分头查证”上的用处：一个主任务可以同时拉起几个 peer，每个管一块，互不干扰，而且每个都能把自己那块做到底、落成文件。

但它也有个明显的习惯：问题给得宽，它就倾向于多读多查。 两个 peer 各用了八十多、九十多次工具调用，最后只交出两份短报告，读取和核对的往返比任务需要的多。

所以后来我把派单收敛：固定源码版本，只问一个问题，限定必要文件、工具次数和输出长度，写完文件就返回。之后，后面的子任务都顺利收到了报告。

任务缩小后，交付恢复，预算仍不牢

后续四个子任务（前面讲的协议边界和延迟分析就在其中），都收到了报告和最终回执。工具调用情况如下。

四项实际工具调用为 6、9、14、12 次，约定上限为 8、8、10、10 次，有三项超限。也就是说，Kimi 在这些回合里并不会严格守住写在提示里的次数上限，它往往还想再查一步、再核一遍。这只是四个回合的观察，样本很小，但足够提醒：别指望靠一句“最多 8 次”就卡住它。

这四项和早期两个 peer 的问题、输入和输出要求都不一样，所以不能读成“缩小任务让 Kimi 快了几倍”。能确认的是，聚焦之后的工作包更容易收取和复核。

按这次的经验，我会这样用：

• 把预算写成“最多几个结论”，而不是只写工具次数。 结论数量比调用次数更容易约束它的发散。
• 工具上限要留余量，并且先写文件。 让它尽早把已有结论落盘，再继续补充；超限被截断时，已经写好的部分不会丢。
• 真要硬限制，交给运行时。 工具计数、截止时间和产物保留，应该由运行环境来执行，不要只靠模型自觉。
• 按“会超一点”来排预算。 审查时间也算进去：多出来的几次调用，往往意味着外环要多读几页。
• 问题越窄越具体，它越稳。 给定版本、文件和一个具体问题，它的发挥最好；开放式的“看看有没有问题”，最容易跑偏、超支。

功能盘点：能当初审，不能当产品验收

最后一轮把盘点拆成两路并行：一个看登录、桌面、输入和媒体，另一个看文件、终端、端口和平台。两份报告都完整交付，也为后续任务清单提供了覆盖面：先稳定 Omarchy 的连接、输入、H.264 与系统音频，再安排剪贴板、文件等日常能力，最后是其他桌面和平台后端。

静态盘点容易把“看到相关字段”写成“已经支持产品功能”，也容易把“没找到构建产物”写成“不支持”。外环复核时纠正了几类判断：文本注入不是双向剪贴板；嵌入光标不是独立的指针形状同步；测试画面不是生产环境的无头桌面；ARM 没有构建验收，不等于源码被证明无法支持；在 Mac 上能编译共享协议代码，也不代表已有真实桌面采集、输入注入、系统声音和权限恢复的原生被控后端。

所以这两份盘点适合用来排任务，每项支持状态还得顺着生产路径和真实验收再确认，才能对用户承诺。

Oseasy 逆向：能沿线索推进，转述时会丢条件

本地虚拟机这条路，卡在了 Oseasy 的安装状态与实例保留上。Kimi 承担内环逆向和部分实现，外环拆任务、审查证据，再执行实机验证。

这一案例只统计 2026 年 10 月 27—28 日切换 Kimi 后的任务单 #4—#13，截至提交 c008bfa。依据是提交内容、证据引用与外环审查记录，不只看模型自己的完成声明。

Kimi 交付了有用的分析和代码，尤其是沿明确入口追踪函数链、整理证据，以及实现验收标准清楚的小工具。

但首稿不能直接放行。六个实质交付批次是 #4、#5、#7、#8、#10、#12，其中 #5、#8、#10、#12 四个批次之后各有一张纠正单（#6、#9、#11、#13）。也就是 6 个批次里有 4 个需要正式返工，这个 4/6 不是代码错误率，也不是全部修订提交数；纠正单不另计批次，#6 的回执问题仍归在 #5 的修订过程里。

最严重的是 method 20 的报告。它引用了相关函数，转述时却抹掉了回复条件；协议帧又同时存在头部长度、正文长度和校验和不一致，足以误导后续实现。修订版删除了错误帧，恢复条件表达（这个 Bool 连“两次注册表写入都成功”也不能直接证明），并把“宿主是否等待这个回复”重新列为未知。OETool 的分支与返回值误读也属于同一类：函数引用是对的，解释错了。

#6 的回执还有一处错：它声称提交是 8189605…，本地并不存在该对象，真实提交为 6aebf88…，本轮写作再次查询，结果相同。实际修改已经完成，错在对交付身份的转述；后来改用脚本读取真实 HEAD，不再让模型重述哈希。

实机结果的归属要分开写。发送 53 字节、收到 455 字节、解析 11 帧的观察由外环操作；Kimi 贡献了探针实现和部分协议分析。探针只记录收到的宿主请求，不执行入站处理器，也不发送回复。备份、端口核验、设备操作与独立验收，不能都算在它名下。

到评测截点，我们观察到了真实宿主协议响应，但还没证明安装状态切换，也没完成同一实例在关机、应用退出和宿主重启后的保留验证。宿主代码与权限不足同样限制了进展。通信成功，不能写成用户目标已经解决。

这个案例里，Kimi 做的是受监督的逆向执行：定点分析、小型实现，以及按外环反馈纠正。首稿的语义准确度还不够让实机操作脱离复核。记录范围内，它遵守了设备访问和推送限制；独立规划整个逆向项目，则没有测过。

由此我想到一个集群分工方案：执行节点分别追踪接收分发、启动通知、配置处理等函数链，交回原始证据、结论和未知项；汇总节点核对方向、字段和分支条件，找出矛盾；独立审查节点再把关进入实现和实机测试的结论；提交哈希、帧长度和校验和交给脚本检查。

这只是建议，没有大规模测过。多个同模型节点互相赞同，也代替不了原始证据。

该项目缺少完整 token、账单和分阶段耗时的具体数据，就不多表。

论文级调研报告

这一次我也专门考察 Kimi 集群调研能力：围绕 Rust unsafe、LLM 生成代码的缺陷、Polonius 借用检查器，生成了三份报告。

具体报告我会开源在这个仓库：https://github.com/ZhangHanDong/deep-reporter

这组材料令我十分惊叹：Kimi 能把一个跨度很大的问题，展开成层次清楚、可以继续深挖的研究底稿，并且是论文级水平。

一份调研最麻烦的地方，往往是读者想追问时无处下手。这几份报告可以顺着章节、来源分类和版本边界往下问，对想在陌生领域快速建立地图的人很有用。

归属上有一点要交代：unsafe 全景、LLM 代码缺陷和 Polonius 四份经过后续复核修订，修订涉及强断言与数字口径。

我会把这组报告整理成 PDF，另行发布到 GitHub，读者可以对照原文检验我的评价。

那份账本：短报告背后的上下文处理

回到 UU 工程任务，它们还留下了一份用量记录。这里的四项，是六个子任务中取得完整终态用量的四项。token 取自各回合唯一的 UI 终态事件，每回合只取一次，避免把累计进度重复相加；完成时间和模型标识来自对用量库的只读字节恢复，已按事件去重，token 字段与 UI 终态逐项核对一致。这不是在线账单查询。

按运行时口径，四项累计处理量是 1,007,613 token。这里包含多次请求里重复携带的上下文，不是一次塞进去百万 token，也不是报告有百万 token。输入合计 984,417，其中约 90.2% 记录为缓存读取；缓存写入四项都记为 0，但缺失的细分字段也可能被记成 0。已报告的推理细分合计 7,825，已包含在 23,196 的输出里，不能再加一次。

耗时方面，四项从回合开始到用量持久化，分别约 161.6、123.4、203.0 和 227.6 秒。这个区间含模型等待、工具执行和终点的完成计量落盘，不是首 token 延迟，也不是纯推理耗时。早期两项的 8 分 26 秒、9 分 01 秒截止于报告文件落盘，终点不同，不能放在同一个速度指标里。

范围一并列在这里：早期两个并行 peer 的子任务没有找到完整的终态用量，不能记为 0，也没有纳入上表；这四项不含内环主任务、外环审查、Codex 实现和后续测试，也不含 Oseasy 逆向与五份调研报告。费用来源记录为 unavailable，没有账单可对，所以不推算费用；我也没有拿到可核验的完整 HTTP 请求数，工具次数、模型请求次数和推理轮数是三个不同的指标。

这份账本最让我在意的一点是：一份几页的短报告背后，可能累积了大量上下文处理。评测 Agent，除了看最终答案，还要看它读了多少次、哪些上下文被反复携带，以及审查者还要花多久把结论修到可用。

实践总结

如果你也打算让 Kimi 参与现有工程，可以从一个能单独复验的问题开始。下面是依据这次经验整理的模板，不是历史任务卡原文。

问题：当前 Opus 参数处理是否符合约定的兼容策略？只审这一处。

输入：指定提交里的参数解析函数、它的生产调用路径、对应测试、相关规范原文。版本无法固定时先报告，不混用不同快照的行号。

输出：最多三项结论。每项写清源码位置、规范依据、影响范围和最小修法；没有证据的客户端行为写“未知”。

验证：列出下一步可执行的测试，以及什么结果会推翻当前判断。没运行的测试不能写通过。

预算与回执：限定工具次数，写入约定的报告文件，再返回最终回执；无法完成时保存已有证据并说明阻塞，不反复扩展问题。

最费功夫的是输入。把整个仓库丢过去说“看看有没有问题”，模型得自己猜边界；给出具体问题、版本和生产入口，外环才容易检查它是否真的回答了问题。找不到调用路径时要允许它交“证据不足”，否则它可能拿附近的一个 helper 或一条绿色单测来充数。

交付物里最好带一条完整的验证路径：哪个输入触发哪个分支，代码产生什么行为，现有测试覆盖到哪一步，还缺哪项真实环境观察。实现者接手时就不必猜发现者的思路。

外环也有一张对应的检查卡：先读约定文件，核对任务和版本，再看子任务状态；报告文件与最终回执分别登记。准备超时中止时，先收取已经产生的内容，标注“部分产物已收、回合未结束”。不要只看窗口安不安静，也不要靠不断追加消息去催一个还在工作的回合。

哪些活我会交给它

之后我仍会把 Kimi 放在内环，先安排这几类工作：围绕一个协议参数的查证；围绕一段生产路径的专项审查；围绕明确目录和问题的功能盘点；研究类的专题拆解、材料汇总与增量跟踪；Oseasy 这类逆向里，沿某条函数链做定点分析，或在验收标准写清楚时实现小工具。

涉及实机操作的结论，我会继续留给外环复核；产品支持状态要实际验收，工具预算则由运行时执行。至于独立完成整个项目的能力，这次还没有测到。

下一轮若要认真比较模型，我会固定同一代码快照和任务卡，保存实际模型与推理配置，重复执行，记录输入输出 token、墙钟时间、外环纠错时间和最终通过率，并把外环花了多久把结果修到可用算进去。

至于收取报告，我现在有两个固定动作：一个 Agent 写完报告，先确认文件真的收到了；收到之后，再逐条核对里面的判断。

彩蛋时间