你写的代码量是过去的 10 倍，但我敢打赌，你做 profiling 的频率并没有提高到 10 倍。实际上我敢打赌，你做得比过去还少。但这没关系！我也犯过同样的错！

但说实话，我觉得你根本不该自己做 profiling。我认为 agent 应该自己去干这件事。而且它应该每天在循环里做。

这就是为什么我给自己的项目做了一套 profiling 循环，结果非常惊人。我的项目 CPU 消耗下降了 70%！

不，我不觉得自己是个烂工程师。我只是像疯了一样不停地推新代码，而由于日程紧张、期望又高，我有点忽视了 profiling。

于是我干脆把 profiling 这件事交给了一个 agent，让它持续寻找优化点，比如更换库、增加缓存，还有更多有意思的东西。

下面我来解释我是怎么搭建这套 agentic profiling 循环的，你也可以照着做。

项目是 owLSM，一个用 C/C++ 写的 Linux 运行时安全工具。项目就介绍这么多。

如果你喜欢这个想法，把它转发给你的朋友，顺便在 GitHub 上给我们点个星 ⭐

在我们开始聊 AI、skills、agentic loops 这些 GenZ-Dev 黑话之前，有一些决策要先定、有一些环境要先搭。

我们会把整个流程拆开，逐部分讲。

所以这是目录：

可以尝试优化的指标有很多。

有些指标对世界上大多数项目都一样：CPU 消耗、内存消耗……

还有些指标是项目特有的：完成 X 所需的时间、锁 profiling、每秒事件数等等。

在我的项目里，我从这几个开始：CPU 消耗、每秒事件数，以及丢弃的事件。

未来我还会加上：内存 profiling（RSS）、锁 profiling，以及 cache-miss 优化。

对我这类项目来说，优化目标是提高 events_per_second、不丢任何事件，同时降低 CPU 消耗。如果你只盯着 CPU，agent 会很乐意给你的线程加个 sleep(1)，把你的吞吐量直接干掉。我知道，因为它真这么干过。

不同的指标需要不同的工具。

工具可以是真正的第三方工具，比如 perf；也可以是你自己写的脚本（比如采样 /proc）；甚至可以是能追踪事件、时间等信息的代码改动。

关于选工具，再给几条额外建议：

你需要的是对你和 agent 都容易读懂、容易理解的东西。

我的项目有 3 个输出文件。每个都给我提供不同的指标和数据：

资源消耗图：展示 CPU%、RSS 和 VIRT 随时间变化的整体消耗情况。它还会展示空闲状态和极端压力之间的变化。

这是一张非常值得拥有的图，因为它能告诉你太多信息。光靠这张图我就能了解：

火焰图：展示各个调用栈在整个项目 CPU 消耗中所占的百分比。

Brendan Gregg 写过一篇很好的指南讲这个。

事件统计。对像我这样的运行时安全项目来说，关键的统计包括：

在我们开始聊 AI 之前，你需要一个可以运行的环境（实验室）。

一个装好了所有必需工具的环境。必需的工具和环境搭建方式因项目而异。比如我的项目是 C++ 写的，只跑在 Linux 上。所以我建了一个 Linux VM，装了 perf（CPU profiler）、HeapTrack（堆 profiler）、火焰图 perl 脚本（Brendan Gregg 的），等等。

把这个环境保存成 VM 模板、容器或其他形式。这样以后就能复用。

就像你有“自动化测试”或“端到端测试”来在不同场景下测试产品一样，你需要一些测试，在单一工具做 profiling 的同时，把你的产品跑在特定的确定性场景下。

在我的项目里，整体流程是：

我简化了很多，但大体思路就是这样。

现在 agent 想跑一个 profiling 场景时，只需按它的 SKILL.md 里写的那样运行一个 Python pytest 程序。

现在该开始看 AI 相关的东西了。

skill 就是 agent 阅读并遵循的指令（SKILL.md）、脚本和知识库。

我实际的流程是一个非常详细的 16 步过程。这里我来写一个粗糙的伪流程：

整体思路就是这样。下面讲的所有内容，都是我怎么防止 agent 在这个流程里干出疯狂蠢事的。

skill 至少应该接收 1 个参数。

我的 skill 只接收一个参数，就是它要运行的场景：/cpp_profiler_optimizations_loop [Scenario]

我们希望 agent 尽可能确定、尽可能省 token。所以对于事先已知的重复性工作，我们应该用脚本和知识库，而不是让 agent 自己去干。

那留给 agent 的是什么？只有艺术性的部分。那些稍后再说。

我们不希望 LLM 一遍又一遍地尝试同样的优化。

除此之外，我们还希望 LLM 能从以往的经验和优化尝试中学习。

所以我们在 skill 里建了一个专门的知识库，多少受了“AI 第二大脑”架构的影响。

kb/ ├── index.md ├── error-consume-thread-cv-instead-of-sleep-25102026/ │ ├── report.md │ └── diff.md ├── async-shell-in-memory-cache-of-known-shells-26102026/ │ ├── report.md │ └── diff.md

每次优化尝试都有一个专门的子目录。

子目录名是 {1-10 个词描述这次尝试}-{DDMMYYYY}，内容是：

index.md 让 agent 能快速查找，这样它就不会去翻不相关的报告。

每个子目录在 index.md 里都有一条约 3 行的描述：

index.md content

• error-consume-thread-cv-instead-of-sleep-25102026: summarizes the report in 3 lines
• async-shell-in-memory-cache-of-known-shells-26102026: summarizes the report in 3 lines

agent 在选择优化候选方案和做实现决策时，会用到这个知识库。

我把知识库加进了 .gitignore，因为我不想公开它；但在私有仓库里，我觉得把知识库在团队成员之间共享是好事。

report.md 必须有固定的结构，简洁但包含所有必要信息。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）