最新

我们构建了Kontext CLI，因为AI编码代理需要访问GitHub、Stripe、数据库以及其他数十种服务——而目前大多数团队通过将长期有效的API密钥复制粘贴到.env文件或实际的聊天界面中来处理此问题，同时寄希望于一切顺利。 问题不仅仅是秘密的扩散。更重要的是，没有访问的来源追踪。你不知道哪个开发者启动了哪个代理，它访问了什么，或者是否应该被允许访问。当你将原始凭证交给一个进程时，你就失去了执行政策、审计访问或轻松更换凭证的能力。凭证就是授权，当自主代理每个会话进行数百次API调用时，这种方式在根本上是有问题的。 Kontext采取了不同的方法。你在一个.env.kontext文件中声明一个项目所需的凭证： ``` GITHUB_TOKEN={{kontext:github}} STRIPE_KEY={{kontext:stripe}} LINEAR_TOKEN={{kontext:linear}} ``` 然后运行`kontext start --agent claude`。CLI通过OIDC进行身份验证，对于每个占位符：如果服务支持OAuth，它会通过RFC 8693令牌交换将占位符替换为短期访问令牌；对于静态API密钥，后端会将凭证直接注入到代理的运行环境中。无论哪种方式，凭证仅在会话期间存在于内存中——从未写入你机器上的磁盘。每个工具调用在代理运行时都会被流式记录以便审计。 最接近的类比是安全令牌服务（STS）：你只需进行一次身份验证，后端动态生成短期、范围限定的凭证——但与传统STS不同的是，我们持有上游的秘密，因此没有长期有效的凭证会到达代理。后端持有你的OAuth刷新令牌和API密钥；CLI从未见过它们。它返回的是针对会话的短期访问令牌。 CLI为每个工具调用捕获的信息包括：代理尝试做了什么、发生了什么、是否被允许，以及是谁执行的——这些信息都归属于某个用户、会话和组织。 只需一条命令即可安装：`brew install kontext-dev/tap/kontext` CLI使用Go编写（每个工具调用大约5毫秒的钩子开销），使用ConnectRPC进行后端通信，并将身份验证信息存储在系统密钥环中。今天支持Claude Code，Codex支持即将推出。 我们接下来将致力于服务器端的政策执行——每个工具调用的允许/拒绝决策的基础设施已经搭建好，我们只需完善流程，以便工具调用也可以被拒绝。 我们非常希望能听到你们对这种方法的反馈。特别想了解的是：团队目前是如何处理AI代理的凭证管理的？你们只是将环境变量粘贴到代理聊天中，还是找到了更好的解决方案？ GitHub: [https://github.com/kontext-dev/kontext-cli](https://github.com/kontext-dev/kontext-cli) 网站: [https://kontext.security](https://kontext.security)

自周六以来，我注意到这个模式，Claude Code在处理最基本的问题时，思考时间达到3-5分钟以上，版本为4.6。<p>这是否与他们降低缓存TTL有关呢？