最新

想知道 AI 智能体权限存在哪些标准。类似于 Linux 的读、写、执行权限，但适用于 AI 智能体。例如，是否存在提供“购买”权限的标准方法，或者用于智能体商务代理？ 我见过一些相关内容，但想听听社区的意见。

几分钟前收到了来自 Github 的邮件，要求我轮换我的 webhook 密钥，邮件的相关内容如下： 我们写信通知您，在 2025 年 9 月至 2026 年 1 月期间，您负责的 webhook 的 webhook 密钥被无意中包含在 webhook 传递的 HTTP 标头中。这意味着在此期间接收 webhook 负载的任何系统都可能从请求标头中记录了 webhook 密钥。Webhook 传递通过 TLS 在传输过程中进行加密，因此包含密钥的标头只能以 base64 编码的格式被接收端点访问。我们没有证据表明您的密钥被拦截。此问题已于 2026 年 1 月 26 日修复。请继续阅读以获取更多信息。 用户隐私和安全对于维护信任至关重要，我们希望尽可能透明地公开此类事件。GitHub 本身并未因此事件而遭受任何入侵或数据泄露。 发生了什么？ 2026 年 1 月 26 日，GitHub 在新版本的 webhook 传递平台中发现了一个错误，该错误导致 webhook 密钥被包含在随 webhook 负载一起发送的 `X-Github-Encoded-Secret` HTTP 标头中。此标头不应作为传递的一部分，并且使 webhook 密钥可以以 base64 编码的格式提供给接收端点。Webhook 密钥用于验证传递是否确实来自 GitHub，并且应该仅为 GitHub 和 webhook 所有者所知。 该错误仅限于使用此新版本 webhook 平台的 webhook 传递的子集。该错误存在于 2025 年 9 月 11 日至 2025 年 12 月 10 日之间，并在 2026 年 1 月 5 日短暂出现。该错误已于 2026 年 1 月 26 日修复。 涉及了什么信息？ 在存在该错误的期间，每个受影响的 webhook 的 webhook 密钥都包含在 HTTP 请求标头中。Webhook 负载内容本身被正常传递，并且没有受到额外影响。没有其他凭据或令牌受到影响。Webhook 传递通过 TLS 在传输过程中进行加密，因此包含密钥的标头只能被接收端点访问。 如果接收系统记录了 HTTP 请求标头，则 webhook 密钥可能存在于这些日志中。Webhook 密钥用于计算传递的 `X-Hub-Signature-256` HMAC 签名——如果被泄露，知道密钥的攻击者可以伪造 webhook 负载，使其看起来像是来自 GitHub。

在过去的几年里，我一直在构建 50 多个投入生产的 AI 智能体（其中一些每天的会话量超过 100 万次），而最难的部分从来都不是构建它们，而是弄清楚它们为什么会失败。 AI 智能体不会崩溃。它们只是默默地给出错误的答案。你最终不得不逐个滚动浏览追踪记录，试图在数百个会话中找到规律。 Kelet 自动化了这项调查。它的工作原理如下： 1. 你连接你的追踪记录和信号（用户反馈、编辑、点击、情绪分析、LLM 充当评判者等） 2. Kelet 处理这些信号并提取关于每个会话的事实 3. 它形成关于每个案例中出现问题的假设 4. 它将跨会话的相似假设进行聚类，并一起调查它们 5. 它会呈现根本原因，并提供你可以审查和应用的修复建议 关键见解：单个会话的失败看起来是随机的。但当你对假设进行聚类时，就会出现失败模式。 最快的集成方式是通过 Kelet Skill for coding agents——它会扫描你的代码库，发现应该收集信号的地方，并为你设置好一切。如果你更喜欢手动设置，也有 Python 和 TypeScript SDK。 目前在 Beta 测试期间免费。无需信用卡。 文档：[https://kelet.ai/docs/](https://kelet.ai/docs/) 我很乐意收到关于这种方法的反馈，特别是来自任何正在运行生产环境智能体的人。自动化手动错误分析听起来正确吗？

我没有 Karma，所以无法发布链接，而且我对刷 Karma 也没兴趣，但我认为你们中的一些人可能会觉得我的数据很有意思。特别是研究报告。<p>https://github.com/ASIXicle/persMEM