看起来又出现了一轮Zendesk的邮件垃圾信息。我在过去半小时内收到了数百封。
返回首页
最新
你好,HN。我是Maxime,LimaCharlie的创始人(<a href="https://limacharlie.io" rel="nofollow">https://limacharlie.io</a>),我们是一个为安全运营提供基础构件的超大规模平台,就像AWS为IT所做的那样。
我们在平台上开发了一款新产品,旨在解决一个紧迫的问题,充当你们的人工智能与外界之间的护栏:Viberails(<a href="https://www.viberails.io" rel="nofollow">https://www.viberails.io</a>)。
这里的朋友们可能对此并不陌生,但我们识别出了团队在使用AI工具时面临的四个挑战:
```
1. 审计工具的操作。
2. 控制工具调用(及其对世界的影响)。
3. 集中管理。
4. 轻松访问上述内容。
```
进一步解释:
审计日志是安全的基础,但在AI工具中,这一方面尚未跟上发展。能够在事件发生后回顾并说“实际上发生了什么”在事件处理和合规性方面极为重要。
工具调用是大型语言模型(LLM)与外界交互的方式,我们应该能够对其施加基本控制,例如:不读取凭证文件、不发送电子邮件、不创建SSH密钥等。能够不仅查看这些调用,还能阻止它们,对于防止事件发生至关重要。
一旦超出单一贡献者在一台设备上的操作,问题就变成了:如何通过为团队创建一个权威配置来扩展流程。拥有一个集中存放所有审计、检测和控制政策的地方变得至关重要。这与雪花服务器的情况类似。
最后,市场上有很多公司提供部分解决方案,但它们大致可以分为两类:
```
- 它们没有处理上述的“集中”点,意味着它们只是将信息发送到syslog,所有复杂的基础设施问题都留给你自己处理。
- 它们被“预约演示”、销售团队、合同以及随之而来的所有浪费精力的事情锁住。
```
我们开发了Viberails来解决这些问题。以下是它的特点:
```
- 开源客户端,使用Rust编写。
- 使用Curl进行安装,分享一个URL给你的团队以加入,完成。支持Linux、MacOS和Windows。
- 检测本地AI工具,你可以选择要安装的工具。我们为每个相关平台安装钩子,这些钩子使用CLI工具。我们支持所有主要工具(包括OpenClaw)。
- CLI工具将webhook发送到你在LimaCharlie的团队(称为组织)。与工具相关的钩子是阻塞的,以便进行控制。
- 阻塞webhook的往返时间大约为50毫秒。
- 你的LimaCharlie租户记录交互以便审计。
- 我们为你创建一组初始检测规则作为示例。默认情况下,它们不阻止。你可以创建自己的规则,没有不透明的黑箱。
- 你可以在云中查看审计、警报等。
- 你可以设置输出,将审计、阻止事件和检测发送到你选择的各种其他平台。简化版即将推出,目前这是在主LimaCharlie用户界面中完成的,而不是简化的Viberails视图。
- 检测/阻止规则支持各种操作符和逻辑,具有高度可定制性。
- 所有数据保留一年,除非你删除租户。数据中心位于美国、加拿大、欧洲、英国、澳大利亚和印度。
- 社区版的唯一限制是全球吞吐量为10kbps。
```
试试吧:<a href="https://viberails.io" rel="nofollow">https://viberails.io</a>
代码库:<a href="https://github.com/refractionPOINT/viberails" rel="nofollow">https://github.com/refractionPOINT/viberails</a>
总之,我们希望为各种开发者和团队提供一个超级简化的解决方案,让他们能够接触到保护其AI工具的基本内容。
感谢阅读——我们非常高兴能与社区分享这一内容!如有任何问题或反馈,请在评论中告诉我们。
这本可以是“问HN:我们现在处于衰退吗?”,但事实并非如此。
嗨,HN,
我和我的团队正在构建 Tabstack,旨在处理 AI 代理的网络层。今天,我们分享了 Tabstack Research,这是一个用于多步骤网络发现和综合的 API。
在许多代理系统中,从单一页面提取结构化数据与回答需要跨多个来源阅读的问题之间存在明显的区别。第一种情况目前得到了相对较好的支持,而第二种情况通常不然。
大多数团队通过结合搜索、抓取和总结来处理研究。这在规模扩大时变得脆弱且成本高昂。你最终需要管理浏览器编排,移动大量原始文本仅仅是为了提取几个主张,并编写自定义逻辑来检查问题是否真正得到了回答。
我们构建了 Tabstack Research,将这一推理循环移入基础设施层。你只需发送一个目标,系统会:
- 将其分解为针对不同数据孤岛的子问题。
- 根据需要使用抓取或浏览器自动化进行网络导航。
- 在综合之前提取并验证主张,以保持上下文窗口专注于信号。
- 检查与原始意图的覆盖情况,并在检测到信息缺口时进行调整。
例如,如果搜索企业政策发现数据分散在多个子服务中(如 Teams 数据存储在 SharePoint 中),引擎会检测到这一缺口并自动调整以寻找缺失的文档。
我们的目标是返回应用程序可以直接依赖的内容:一个带有内联引用和直接链接到源文本的结构化对象,而不是一系列链接或一个黑箱摘要。
上面链接的博客文章详细介绍了引擎架构和扩展代理浏览的技术挑战。
我们提供一个免费层,每月包含 50,000 个积分,您可以在没有信用卡的情况下进行测试: [https://console.tabstack.ai/signup](https://console.tabstack.ai/signup)
我非常希望能听到您对这种方法的反馈,并回答您关于该技术栈的任何问题。