返回首页
最新
我创建 Remoroo 是因为大多数编码代理在工作不再是短暂的编辑和运行循环时就会崩溃。<p>一个真正的工程实验可能会持续数小时。在这个过程中，代理需要读取文件、运行命令、检查日志、比较指标、尝试失败的想法，并且需要记住已经发生的事情。一旦上下文开始模糊，它就会忘记目标，失去基准，反复尝试不好的想法。<p>Remoroo 是我尝试解决这个问题的方案。<p>你只需将其指向一个代码库，并给出一个可衡量的目标。它在本地运行，尝试更改，执行实验，测量结果，保留有帮助的部分，丢弃无用的部分。<p>系统的一个重要部分是内存。长时间的运行会生成远超模型所能容纳的上下文，因此我构建了一个受操作系统虚拟内存启发的需求分页内存系统，以保持运行过程的连贯性。<p>这里有一份技术文档：
<a href="https://www.remoroo.com/blog/how-remoroo-works" rel="nofollow">https://www.remoroo.com/blog/how-remoroo-works</a><p>希望能得到从事长时间运行代理、训练循环、评估工具或类似工作流程的人的反馈。
我们构建了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有关呢？