最新

A2A 协议是谷歌开发的一种代理间通信协议。我六个月前曾研究过它，但当时感觉并没有真正理解如何使用它。这可能是因为我们当时还在摸索代理的概念，然后 MCP 协议变得非常重要。但现在我开始认为，一旦代理拥有了工具、服务、数据以及联系人，交互的重点就变成了代理本身。然后，如果你要构建其他代理，你会希望它们能够进行交互，因为它们拥有最相关的上下文和回答任何查询的能力。所以，我想知道是否有人已经在使用这个协议了？<p>https://github.com/a2aproject/A2A

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

我在一家开发武术健身房软件（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 提示确保任何安全措施都得到一丝不苟地遵守。