Jentic Mini

大家好，Product Hunt 👋 来自 Jentic CEO 的消息： 我是 Sean，Jentic 的联合创始人。过去 18 个月，我们一直在解决每个构建 AI Agent 的开发者都会遇到的难题：如何让 Agent 安全地调用真实 API，而不泄露凭证或失去控制？ 当前的典型模式是：将 API 密钥硬编码到提示词中，为每个服务编写定制包装函数，并祈祷信息不会被记录、缓存或幻觉式地返回。这在演示中可行，但在生产环境中会出问题。 Jentic Mini 的实际功能 它是一个 API 执行层——一个可通过 Docker 自托管的 FastAPI 服务器——位于 Agent 与其需要调用的每个 API 之间。架构非常直观： 搜索：Agent 通过 BM25 全文索引，在我们的公共目录中搜索 10,000+ API 规范和 380 个 Arazzo 工作流源，无需编写任何包装代码即可找到正确的操作。 执行：Jentic Mini 代理请求。凭证存储在 Fernet 加密的本地保险库中，并在运行时注入。Agent 永远不会看到它们，也不会通过 API 返回。 工具包：每个 Agent 都会获得一个限定范围的工具包密钥 (tk_xxx)，包含其专属的凭证包和访问策略。每个 Agent 一个密钥，可单独撤销。如果出现问题，只需吊销密钥即可。 观测：完整的执行跟踪和审计日志。可以精确查看 Agent 调用了什么、何时调用以及返回了什么。 构建原因 我们已经运营着托管的 Jentic 平台（具备语义搜索、基于 Lambda 的代理、SOC 2 级安全），并且是 Claude 的已验证连接器。但我们不断从开发者那里听到同样的声音："我想自己运行这个。" 因此我们构建了 Mini，拥有相同的 API 接口，可自托管，采用 Apache 2.0 许可证。 只需一条命令即可开始： $ docker run -d --name jentic-mini -p 8900:8900 -v jentic-mini-data:/app/data jentic/jentic-mini 通过 localhost:8900 的 UI 添加 API 凭证，规范会自动从公共目录导入。Agent 通过 X-Jentic-API-Key 标头使用工具包密钥进行身份验证，并立即开始搜索和执行。 后续计划 这是早期访问版本。可能存在粗糙之处。我们现在分享它，是希望构建 Agent 的社区（无论是 OpenClaw、NemoClaw、LangChain、CrewAI，还是任何技术栈）能够测试它、破坏它，并告诉我们缺少什么。 很想知道大家首先希望连接哪些 API 和工作流。