返回首页
最新
嗨，HN，
我们开发了 LUML（<a href="https://github.com/luml-ai/luml" rel="nofollow">https://github.com/luml-ai/luml</a>），这是一个开源（Apache 2.0）MLOps/LLMOps 平台，涵盖实验、注册、LLM 跟踪、部署等功能。
该平台将控制层与数据和计算分离。所有的工件都是自包含的。每个模型工件都包含所有元数据（包括实验快照、依赖项等），并存储在您的存储中（兼容 S3 或 Azure）。
文件传输直接在您的机器和存储之间进行，执行则在您托管并连接到 LUML 的计算节点上进行。
我们非常希望您能尝试这个平台并分享您的反馈！
构建一个能够接收人际或人机对话信号并付诸实践的系统。想象一下：对话结束后，事情真的得以完成。我们的主要产品面向中小企业，但如果你想试试，我们提供了一个实验平台 - <a href="https://hoster.primeorbit.ai/" rel="nofollow">https://hoster.primeorbit.ai/</a>，也可以访问 <a href="https://primeorbit.ai/" rel="nofollow">https://primeorbit.ai/</a>。
我们很想知道你会尝试什么。感谢你的阅读！
大家好，
我构建了一个运行时环境，用于通过 WebAssembly 沙箱隔离不可信代码。基本上，它保护您的主机系统免受不可信代码可能引发的问题。最近我们对 Python 中的沙箱化进行了深入讨论，更详细地阐述了这个问题[1]。在 TypeScript 中，由于两个生态系统之间的紧密联系，WebAssembly 的集成显得更加自然。
核心部分是用 Rust 编写的。在此基础上，我通过 wasmtime 和组件模型使用了 WASI 0.2，并结合自定义 SDK，使其尽可能符合语言习惯。
例如，在 Python 中，我们有一个简单的装饰器：
```python
from capsule import task
@task(
name="analyze_data",
compute="MEDIUM",
ram="512mb",
allowed_files=["./authorized-folder/"],
timeout="30s",
max_retries=1
)
def analyze_data(dataset: list) -> dict:
"""在一个隔离的、资源受控的环境中处理数据。"""
# 您的代码在 Wasm 沙箱中安全运行
return {"processed": len(dataset), "status": "complete"}
```
在 TypeScript 中，我们有一个包装器：
```typescript
import { task } from "@capsule-run/sdk"
export const analyze = task({
name: "analyzeData",
compute: "MEDIUM",
ram: "512mb",
allowedFiles: ["./authorized-folder/"],
timeout: 30000,
maxRetries: 1
}, (dataset: number[]) => {
return {processed: dataset.length, status: "complete"}
});
```
您可以设置 CPU（通过 compute）、内存、文件系统访问权限和重试次数，以精确控制您的任务。
虽然现在还处于早期阶段，但我非常希望能听到反馈。我会在这里回答问题。
GitHub: [https://github.com/mavdol/capsule](https://github.com/mavdol/capsule)
[1] [https://news.ycombinator.com/item?id=46500510](https://news.ycombinator.com/item?id=46500510)
我对 Go 验证器中的运行时反射感到沮丧，因此我采用了代码生成的方法。
govalid 读取结构体标记并生成普通的 Go 验证代码。没有反射，运行时没有内存分配，速度比 go-playground/validator 快 5-44 倍。还支持 CEL 以处理复杂规则。
欢迎反馈 :)
你好，HN。
我想首先说明，我是一名开发者，开始这个研究项目是为了挑战自己。我知道像MCP这样的标准协议是存在的，但我想探索一条不同的道路，并享受为桌面应用程序创建专门通信层的乐趣。
这个项目旨在以一种自主的方式处理桌面应用程序之间的通信，因此重点严格放在这个进程间通信（IPC）层上（忘记HTTP API调用吧）。
RAIL（远程代理调用层）的核心有两个基本概念。名字可能听起来有些吓人，但请记住这是一个研究项目：
内存逻辑注入 + 反射
范式转变：聊天是服务器，应用程序是客户端。
为什么采用这种方法？这个想法是避免创建庞大的包装器或API端点，仅仅为了调用内部方法。相反，代理应用程序将其自己的实例传递给SDK（例如，RailEngine.Ignite(this)）。
我发现以下流程非常有趣：
- 应用程序将其实例传递给在其自身进程中运行的RailEngine库。
- 聊天（协调者）接收可用方法的清单。模型决定该做什么，并通过命名管道将命令发送回去。
- 触发器：应用程序中的RailEngine接收到命令，并对持有的实例使用反射直接执行.Invoke()。
本质上，我是通过SDK将“代理逻辑”直接注入到应用程序的内存空间中，使聊天能够远程触发本地方法。
关于代码库的说明：GitHub仓库已经变得庞大。核心关注点是RailEngine和RailOrchestrator。你会发现其他连接器（C++、Python），坦率地说，它们是“垃圾代码”或不完整的实验。我在C++中强行使用RTTR实现反射，但对此并不太满意。请跳过这些，它们与架构讨论无关。
我希望能将讨论集中在内存管理语言（如C#/.NET）上，并请教你们：
- 架构：这种反转的架构（应用程序通过IPC“拨打回家”）对于本地代理来说，与标准的服务器/API模型相比是否有意义？
- 性能：关于每次调用都使用反射——是否值得在启动时实现一个机制，将方法缓存为委托？还是考虑到LLM本身的延迟，这种优化无关紧要？
- 安全性：由于我们实际上绕过了API层，假设的安全层应该是什么，以防止恶意使用？（例如，用户签名的能力清单？）
我很想听听关于架构的比较和批评。
受到这个 Ask HN 的启发：https://news.ycombinator.com/item?id=46834977
但我想更早地回顾一下，看看这里是否还有人使用计算尺？