返回首页
最新
技术背景：每个代理循环都以一个真实的Astro项目模板开始，该模板已预先复制到工作区中。Claude并不是从头生成文件树，而是扩展和修改这个已知的良好基线。这个设计决策避免了模型生成的支架所带来的低效和不一致性。通过在一个预构建的、可编译的结构中工作，模型可以专注于高价值的任务，例如文案撰写、布局和视觉层次。
关于代理循环、Postgres作为队列、通过简历编辑等的完整架构说明，请访问这里：<a href="https://www.adamhsn.com/blog/conversational-website-builder-claude-agent-sdk" rel="nofollow">https://www.adamhsn.com/blog/conversational-website-builder-...</a>
由于最近出现了npm配置问题，我们需要这样一个工具来修复基本问题。
我是一名SAP集成顾问，这个项目是我作为副业开发的。痛点在于：大多数自托管的LLM可观察性工具需要Postgres、Redis和复杂的基础设施。团队只想了解他们的代理在生产环境中实际做了什么，而这种设置成本让人望而却步。
Torrix作为一个单一的Docker容器运行，后端使用SQLite。完整安装步骤是：<p>curl -o docker-compose.yml <a href="https://raw.githubusercontent.com/torrix-ai/install/main/doc" rel="nofollow">https://raw.githubusercontent.com/torrix-ai/install/main/doc</a>... 然后运行docker compose up<p>没有外部依赖。所有数据保存在您机器上的本地SQLite文件中。<p>它通过HTTP代理或Python/Node SDK记录LLM调用：包括令牌、成本、延迟、完整的提示和响应跟踪，以及推理令牌捕获。支持OpenAI、Anthropic、Gemini、Groq、Mistral、Azure Open AI以及任何兼容Apen AI的端点。<p>在实际使用真实代理管道时，我添加了一些功能：成本预测和严格的预算上限、个人身份信息（PII）遮蔽、模型路由规则、与黄金运行的评估、AI评审、带版本历史的提示库、用于按环境过滤的运行标签、MCP服务器以便AI助手可以查询您自己的日志，以及OTLP/HTTP摄取，适用于已经使用OpenTelemetry的应用程序。<p>社区版对一个用户免费，保留数据7天。专业版增加了团队、基于角色的访问控制（RBAC）、30天保留、API密钥管理、全文搜索和审计日志。<p>SQLite不适合高写入吞吐量。这款工具旨在为每天记录数百到低千的LLM调用的团队服务，而不是数百万次。欢迎大家提出意见和建议。<p>GitHub / 安装：<a href="https://github.com/torrix-ai/install" rel="nofollow">https://github.com/torrix-ai/install</a> 网站：<a href="https://www.torrix.ai" rel="nofollow">https://www.torrix.ai</a>
大家好，我是汤姆，我很高兴向大家介绍 Diom（<a href="https://diom.com" rel="nofollow">https://diom.com</a>）——一个后端组件服务器。
Diom 包含了常见后端原语的实现，如缓存、键值存储、幂等性、速率限制、队列和流，未来还会有更多功能。
在构建 Svix 的过程中，我们不得不重新实现每个人都需要重新实现的后端原语。我们也时常感受到在现有基础设施（如 Redis 和 Postgres）上构建自定义解决方案与添加更多专用服务（如 RabbitMQ 和 Kafka）之间的矛盾，这些服务需要我们进行配置、操作、备份和维护。对于我们来说，这种情况更为糟糕，因为 Svix 是开源的，额外的基础设施意味着对客户的额外负担。
六个月前，我们终于决定构建 Diom，专注于开发者体验和操作的简便性。它是开源的，自包含的，并使用 fjall（类似于 RocksDB 的快速 LSM 树存储）管理自己的存储。它不需要外部运行时依赖（不需要 Redis/Postgres/Kafka 等），并支持作为单节点或高可用的 Raft 集群运行。
Diom 的目标是为开发者提供所需的后端原语，而无需在 Redis、RabbitMQ、Kafka 之上编写自定义代码，甚至无需运行这些服务。它目前支持缓存、键值存储、幂等性、速率限制、队列和流。我们还计划添加认证令牌、分布式设置、功能标志和其他常见组件，并为现有组件增加更多功能。
Diom 更加注重操作的简便性而非扩展性，因此它的吞吐量无法与 Kafka 相提并论，也无法达到像 Redis 和 Dragonfly 那样的高 QPS。然而，大多数产品和开发者并不需要处理每秒数 TB 和数十亿事件的数据。也就是说，Diom 在其目标用例中仍然能够实现高性能，因为它实现的是更高层次的原语，而不是基本操作。此外，由于原语与存储在同一进程中，网络往返次数更少，从而保持了低延迟。
它使用 HTTP/2 和 msgpack 作为传输协议（在浏览器中运行良好），并提供了 Python、TypeScript、Rust、Go 和 Java 的 CLI 和 SDK，未来还会有更多语言支持。
我们已经将 Svix 完全移植到 Diom，并在我们的一个预发布环境中持续运行测试和模拟工作负载。计划在今年晚些时候推出 GA（正式发布），届时我们将把 Svix 的生产工作负载迁移过来。
代码库（MIT 许可）：<a href="https://github.com/svix/diom" rel="nofollow">https://github.com/svix/diom</a>
文档：<a href="https://docs.diom.com" rel="nofollow">https://docs.diom.com</a>
在线演示：<a href="https://diom.com/playground" rel="nofollow">https://diom.com/playground</a>
我很高兴终于能分享 Diom，并希望听到大家的想法，以及你们希望我们构建的其他组件！我也希望能得到帮助来想出一个合适的名称。目前我们称之为“组件平台”，但我对这个名字并不太满意。