最新

我们构建了Kontext CLI，因为AI编码代理需要访问GitHub、Stripe、数据库以及其他数十种服务——而目前大多数团队的处理方式是将长期有效的API密钥复制粘贴到.env文件或实际的聊天界面中，然后听天由命。<p>问题不仅仅是密钥泛滥。更重要的是，没有访问的溯源。你不知道哪个开发者启动了哪个代理，它访问了什么，或者是否应该被允许访问。当你将原始凭证交给一个进程时，你就失去了执行策略、审计访问或无痛轮换的能力。凭证就是授权，当自主代理每个会话进行数百次API调用时，这种方式从根本上就是错误的。<p>Kontext采用了不同的方法。你可以在.env.kontext文件中声明项目需要的凭证：<p><pre><code> GITHUB_TOKEN={{kontext:github}} STRIPE_KEY={{kontext:stripe}} LINEAR_TOKEN={{kontext:linear}} </code></pre> 然后运行`kontext start --agent claude`。CLI通过OIDC对你进行身份验证，对于每个占位符：如果服务支持OAuth，它会通过RFC 8693令牌交换将占位符换成一个短期的访问令牌；对于静态API密钥，后端会将凭证直接注入到代理的运行时环境中。无论哪种方式，密钥只在会话期间存在于内存中——永远不会写入你的机器上的磁盘。每个工具调用都会在代理运行时进行流式审计。<p>最接近的类比是安全令牌服务（STS）：你只需进行一次身份验证，后端就会动态生成短期的、有范围的凭证——但与传统的STS不同的是，我们持有上游密钥，因此没有任何长期有效的密钥会到达代理。后端持有你的OAuth刷新令牌和API密钥；CLI永远不会看到它们。它会收到范围限定于会话的短期访问令牌。<p>CLI为每个工具调用捕获的内容：代理尝试做什么，发生了什么，是否被允许，以及是谁做的——归属于用户、会话和组织。<p>只需一个命令即可安装：`brew install kontext-dev/tap/kontext`<p>CLI用Go语言编写（每个工具调用大约5毫秒的钩子开销），使用ConnectRPC进行后端通信，并将身份验证存储在系统密钥环中。目前支持Claude Code，Codex的支持即将推出。<p>我们接下来正在研究服务器端策略执行——用于对每个工具调用进行允许/拒绝决策的基础设施已经就绪，我们只需要闭合循环，以便工具调用也可以被拒绝。<p>我们很乐意收到关于此方法的反馈。特别感兴趣的是：目前团队如何处理AI代理的凭证管理？你只是将环境变量粘贴到代理聊天中，还是找到了更好的方法？<p>GitHub: <a href="https://github.com/kontext-dev/kontext-cli" rel="nofollow">https://github.com/kontext-dev/kontext-cli</a> 网站: <a href="https://kontext.security" rel="nofollow">https://kontext.security</a>

假设我有一个由 n 块拼图组成的拼图游戏？如果我完全没有参考图（也许它完全是白色的，或者类似的东西），那么复杂度是否为 O(n!)，因为我需要查看是否可以将每一块拼图与其他所有拼图连接起来？ 但它不仅仅是一个线性排列。它是一个矩形（或者可能是正方形）。那么，如果它是一个正方形（大小为 m * m，其中 m = sqrt(n)），这会如何改变复杂度？ 然后你有边框，大小为 4m。至少你可以识别出这些拼图（除非某些内部拼图有直线边，这在某些拼图中会发生）。这会如何改变复杂度？ 然后你有参考图。这会给你提供更多信息。至少，它让你能够根据拼图上的图案将拼图分成不同的组。那么，在实践中，实际的复杂度是多少？是类似 O(n^2) 吗？ 当然，一定有一些关于这方面的文献。有人知道吗？

编码代理让一切都感觉再次变得快速——除了管理发布二进制文件。 像这样的操作应该成为你可以从终端运行的真实命令： - "将登录修复部署到预演环境" - "生产环境和预演环境的功能差异是什么？" - "当任何安全修复进入生产环境时通知我" - "将 Jen 的最新更改推广到预演环境" - "与 Acme 的合作伙伴分享新的 Beta API SDK" 这就是 Fly 所做的。 每次 CI 运行将工件推送到 Fly 注册表时，它都会创建一个发布版本——包括生成的二进制文件、AI 生成的摘要、捕获的架构决策、合并的 PR 和提交。所有这些都是可搜索的。因此，当你问你的代理“我们什么时候发布了连接超时修复程序”时，它会在所有这些内容中运行语义搜索，并找到正确的证据。没有版本号，无需深入研究运行 ID，无需 Git 哈希。 Fly 还了解你的运行时环境，并与你的编码代理已经知道的任何部署框架一起工作——Argo CD、Flux 等。它会自动跟踪通过它们部署的内容，因此“目前生产环境中的最新更改是什么”会得到真实的答案。 还有一些其他值得了解的事情： - 开箱即用地与你的 GitHub 存储库集成 - 通过 MCP 与 Claude Code、Cursor、Codex 等一起使用 - 与你的运行时环境的无代理集成 - 自然语言的 Slack 通知——Fly 监视发布，并在有匹配项时提供上下文通知 - 在后台运行 Artifactory 作为可扩展的软件包注册表 - 支持 Docker、Helm、npm、PyPI、Maven、Gradle、Go 和 .NET，并且将支持更多软件包类型 - 安装后，你的软件包管理器即可正常工作：npm publish、pip install、docker push——所有这些都会自动通过你的私有 Fly 注册表进行路由。无需编辑 .npmrc，无需处理令牌 试一试，升级你管理发布二进制文件的方式——最终真正了解实际运行的内容和位置。很乐意深入探讨它的工作原理、它还处理什么以及我们下一步将把它带到哪里。 [https://jfrog.com/fly](https://jfrog.com/fly)