返回首页
24小时热榜
嗨，HN，
在Imbue，我们一直在关注代理领域的快速发展，并注意到代理与第三方服务在用户授权下的互动方式常常不尽如人意。现有的集成方式往往是临时的、复杂的、依赖上下文的，并且要么对非技术用户不友好，要么与某种锁定机制绑定。
我们正在尝试一种命令行工具——Latchkey，旨在为非技术用户提供本地代理服务，同时避免远程中介。根据我们所知，这是在这两个目标交汇处唯一现有的方法。
核心理念：代理通过在普通的 `curl` 调用前添加 `latchkey` 命令来访问第三方服务的API，示例如下：
```
latchkey curl -X POST 'https://slack.com/api/conversations.create' \
-H 'Content-Type: application/json' \
-d '{"name":"something-urgent"}'
```
Latchkey会透明地将凭据注入这些调用中，并在需要时提示用户通过浏览器弹窗登录。一旦登录成功，浏览器自动化将用于从浏览器会话中提取API令牌。
好处：
* 只需掌握一项技能即可与所有服务集成。
* 代理与第三方服务之间的直接通信（无需OAuth中介应用）。
* 非技术用户也能使用代理。
* 秘密信息不会泄露到日志或聊天记录中。
我们相信这与一个去中心化的未来愿景相符，在这个未来中，人们无需向企业请求使用自己数据的权限。我们想象一个充满活力的本地代理生态系统，人们可以自由使用，同时社区互相帮助，使这些工具保持实用和功能性。
我们也意识到这种方法存在一些缺点，期待您的反馈。
附言：这里还有一个链接，展示了使用Latchkey构建的玩具演示AI助手应用Passepartout： [https://github.com/imbue-ai/passepartout](https://github.com/imbue-ai/passepartout)
我建立了一套 webhook 技能，因为 AI 编码代理在 webhook 集成方面的表现令人惊讶地糟糕。生成的代码看起来合理，但一旦运行，就会出现签名验证失败、原始请求体处理错误或中间件顺序破坏一切的问题。
PostHog 对 LLM 代码生成的研究（[链接](https://posthog.com/blog/correct-llm-code-generation)）发现，当代理参考已知有效的示例时，生成的代码更可靠，而不是从训练数据中重构。这就是这里采用的方法。
`webhook-skills` 是基于 Agent Skills 规范（agentskills.io）构建的一套特定于提供商的 webhook 实现和最佳实践指南：
```
- 可运行的示例（目前支持 Express、Next.js、FastAPI，未来将增加更多框架）
- 记录了特定于提供商的签名验证注意事项
- 最佳实践模式：幂等性、错误处理、重试逻辑
- 启动时支持 11 个提供商（Stripe、Shopify、GitHub、OpenAI、Clerk、Paddle 等），将根据我的需求或请求进行扩展。
```
示例：
```
# 列出技能
npx skills add hookdeck/webhook-skills --list
# 安装技能
npx skills add hookdeck/webhook-skills --skill stripe-webhooks --skill webhook-handler-patterns
```
该工具与 Claude Code、Cursor、Copilot 兼容。这些示例即使没有代理也很有用：您可以直接复制的最小化、经过测试的处理程序。
欢迎提交 PR 以支持新的提供商和框架。我还构建了一个 AI 驱动的生成器，可以自动创建新的提供商技能。只需指向 webhook 文档，它就会研究签名方案，为每个框架生成验证代码，编写测试，并打开一个 PR。