返回首页
最新
我很好奇关于人工智能代理权限的标准有哪些。类似于Linux的读取、写入、执行类型，但针对人工智能代理。例如，是否有标准的方法来提供“购买”权限，或者用于商业代理的权限？我见过一些相关内容，但想听听社区的看法。
几分钟前收到了来自Github的邮件，要求我更换我的webhook密钥，相关内容如下：
<p><i>我们写信通知您，在2025年9月至2026年1月期间，您负责的webhook的密钥不小心包含在webhook交付的HTTP头中。这意味着在此期间接收webhook负载的任何系统都可能从请求头中记录了webhook密钥。webhook交付在传输过程中通过TLS加密，因此包含密钥的头部仅以base64编码格式对接收端点可访问。我们没有证据表明您的密钥被拦截。此问题已于2026年1月26日修复。请继续阅读以获取更多信息。</i></p>
<p><i>用户隐私和安全对于维护信任至关重要，我们希望在此类事件中保持尽可能的透明。GitHub本身并未因这一事件而遭遇安全漏洞或数据泄露。</i></p>
<p><i>发生了什么？</i></p>
<p><i>在2026年1月26日，GitHub发现了webhook交付平台新版本中的一个错误，该错误导致webhook密钥被包含在随webhook负载发送的`X-Github-Encoded-Secret` HTTP头中。这个头部并不应该成为交付的一部分，使得webhook密钥以base64编码格式对接收端点可用。webhook密钥用于验证交付确实来自GitHub，应该仅为GitHub和webhook所有者所知。</i></p>
<p><i>该错误仅限于一部分被标记为使用此新版本webhook平台的交付。该错误存在于2025年9月11日至2025年12月10日之间，以及在2026年1月5日短暂出现。该错误已于2026年1月26日修复。</i></p>
<p><i>涉及了哪些信息？</i></p>
<p><i>在该错误存在的窗口期间，每个受影响的webhook的密钥被包含在HTTP请求头中。webhook负载内容本身正常交付，并未受到额外影响。没有其他凭证或令牌受到影响。webhook交付在传输过程中通过TLS加密，因此包含密钥的头部仅对接收端点可访问。</i></p>
<p><i>如果接收系统记录了HTTP请求头，webhook密钥可能会出现在这些日志中。webhook密钥用于计算交付的`X-Hub-Signature-256` HMAC签名——如果被泄露，知道密钥的攻击者可以伪造webhook负载，使其看起来来自GitHub。</i></p>
我在过去几年中构建了50多个生产环境中的AI代理（其中一些每天的会话超过100万），最困难的部分从来不是构建它们，而是找出它们失败的原因。
AI代理不会崩溃。它们只是安静地给出错误的答案。你最终会逐个查看追踪记录，试图在数百个会话中找到模式。
Kelet自动化了这一调查过程。它的工作原理如下：
1. 你连接你的追踪记录和信号（用户反馈、编辑、点击、情感、LLM作为评判者等）。
2. Kelet处理这些信号并提取每个会话的事实。
3. 它形成关于每个案例出错原因的假设。
4. 它将相似的假设在会话中进行聚类，并一起进行调查。
5. 它提出一个根本原因，并提供一个建议的修复方案，供你审核和应用。
关键见解：单个会话的失败看起来是随机的。但当你对假设进行聚类时，失败模式就会显现出来。
集成的最快方式是通过Kelet技能来编码代理——它会扫描你的代码库，发现应该收集信号的位置，并为你设置一切。如果你更喜欢手动设置，还有Python和TypeScript的SDK可供使用。
目前在测试阶段是免费的，无需信用卡。
文档：<a href="https://kelet.ai/docs/" rel="nofollow">https://kelet.ai/docs/</a>
我很想听听大家对这种方法的反馈，特别是那些在生产环境中运行代理的人。自动化手动错误分析听起来合适吗？
我没有 Karma，所以无法发布链接，也不想去刷 Karma，但我认为你们中的一些人可能会对我的数据感兴趣，特别是研究报告。
https://github.com/ASIXicle/persMEM