最新

我创建 Remoroo 是因为大多数代码编写助手一旦工作不再是短时间的编辑-运行循环就会崩溃。<p>一个真正的工程实验可能需要运行数小时。在此过程中，助手会读取文件、运行命令、检查日志、比较指标、尝试失败的想法，并且需要记住已经发生的事情。一旦上下文开始丢失，它就会忘记目标，失去对基线的跟踪，并重试错误的方案。<p>Remoroo 是我尝试解决这个问题的方法。<p>你将它指向一个代码仓库，并给它一个可衡量的目标。它在本地运行，尝试更改，执行实验，测量结果，保留有帮助的内容，并丢弃无用的内容。<p>该系统的一个重要组成部分是内存。长时间的运行会产生比模型能够容纳的更多的上下文，因此我构建了一个受操作系统虚拟内存启发的按需分页内存系统，以保持运行随时间的连贯性。<p>这里有一篇技术文章： <a href="https:&#x2F;&#x2F;www.remoroo.com&#x2F;blog&#x2F;how-remoroo-works" rel="nofollow">https:&#x2F;&#x2F;www.remoroo.com&#x2F;blog&#x2F;how-remoroo-works</a><p>欢迎从事长时间运行的助手、训练循环、评估工具或类似工作流程的人提供反馈。

我们构建了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>