一周热榜

我在一家开发武术健身房软件（MAAT）的初创公司工作。我们负责处理学员的会员管理，让健身房老板无需操心，通过支付系统和数据库来完成。随着我们接入的健身房越来越多，支持任务也随之增加：订阅问题、会员更新、数据导出…… 我们目前解决这个问题的方式是采用一个“LLM 树状结构”（tree of llms.txt）。通常，llms.txt 文件会引用网站或文档中可用的信息——我们内部也沿用这个思路来组织代理所需的信息。代理从一个文件夹开始，向下导航： ├── llms.txt # 引用此层级的每个文件夹 ├── stripe/ # info.md: 我们的 Stripe 账户结构 ├── firestore/ # info.md: 数据库 schema 结构 └── support/ ├── info.md # 如何解决支持任务 ├── runbooks/ # 每个任务一个文件，有自己的 llms.txt │ ├── cancel-subscription.md │ ├── export-gym-data.md │ └── fix-membership-mismatch.md └── logs/ # 每天一个文件，记录代理已解决的每个任务 通过这种方式，我们可以更好地引导代理，并在出现新的支持任务时创建新的 runbook。 您可以在每个集成中指定代理应该做什么和不应该做什么。gcontext 提示确保任何安全措施都得到一丝不苟地遵守。

我一直在使用这个工具来分析和优化 eBPF 程序，现在我将其发布出来，因为它极大地简化了我“性能极客的生活”。 这是一个用于分析 eBPF 程序本身、探针到内核的活动、与共享哈希表的交互等的工具。 由于 eBPF 程序是驻留在（内核）地址空间中的机器码片段，因此您可以像分析任何其他内核函数一样，使用标准的 perf 工具来分析它们。然而，单独使用 perf 无法显示像 `bpftop` 那样有用的指标，例如执行次数和 eBPF 程序的平均运行时长。此外，我还希望有一种简单的方法，在可能的情况下将 CPU 采样映射到原始源代码行。 我希望能够**统一**这两种方法，显示 `bpftop` 风格的调用计数和探针延迟，同时能够深入分析 eBPF 程序花费大部分时间的地方。