嗨，HN——我刚刚开源了Hibana和hibana-agent。
Hibana是一个针对Rust的仿射多方会话类型（MPST）运行时。它旨在解决分布式系统中的协议漂移问题。与其在每个组件中维护单独手写的状态机，不如将交互定义为全局编排，并在编译时投影角色本地行为。在运行时，只有有效的协议转换是可执行的，因此诸如跳过、重用或走错分支等无效操作将被协议模型拒绝。
其实际价值在于，一个全局的真相源取代了多个手写的状态机，并消除了协议漂移错误的一类。
核心仓库： [https://github.com/hibanaworks/hibana](https://github.com/hibanaworks/hibana)
一个具体的例子是hibana-agent，它在AI代理工作流中展示了相同的模型：允许的动作路径在编排中定义，只有这些转换在运行时是可执行的。
示例应用： [https://github.com/hibanaworks/hibana-agent](https://github.com/hibanaworks/hibana-agent)
返回首页
最新
我搭建了一个MCP服务器，可以返回您在各种生态系统中使用的依赖包的最新版本，例如Python、NPM、Go和GitHub Actions。
该服务器还支持通过mise-en-place工具查找近1000种工具的最新版本，包括开发运行时（如Python、Node、dotnet）、开发工具（如Gradle）以及各种DevOps工具（如kubectl或Terraform）。
支持的生态系统/工具包括：
1) 开发者生态系统：NPM、PyPI、NuGet、Maven/Gradle、Go、PHP、Ruby、Rust、Swift、Dart
2) DevOps生态系统：
- Docker：来自Docker注册表的Docker容器镜像
- Helm：来自ChartMuseum仓库和OCI注册表的Helm图表
- GitHub Actions：在GitHub.com上托管的Actions，返回其当前版本、输入和输出，以及（可选）完整的README和使用示例
- Terraform提供者和模块：来自Terraform Registry、OpenTofu Registry或自定义注册表的提供者和模块
- 各种工具，如kubectl、terraform、gradle、maven等（只要它们被mise-en-place支持）
在<a href="https://package-version-check-mcp.onrender.com/mcp" rel="nofollow">https://package-version-check-mcp.onrender.com/mcp</a>上有一个免费托管版本，您可以使用Docker或uv（uvx）运行它。
这个MCP当然不是第一个解决“过时依赖”问题的工具。然而，我认为它相较于其他MCP有多种优势：
- 它提供的生态系统覆盖范围（远）优于其他MCP
- 完整的测试覆盖，具有自动化的依赖更新（由Renovate提供支持）和定期的自动化发布构建。相比之下，其他项目往往是随意编码的，测试不充分（或没有测试），并且已经被放弃
- 这个MCP使用了一个最小的Docker/OCI镜像，经过安全加固。您使用Trivy等工具生成的SBOM被认为是正确的，并且该镜像使用Cosign签名（这使您在想要自托管MCP时可以验证其真实性）
请告诉我您的想法。
我和我的妻子已经进行了五年的餐饮计划。我们使用的是 Google Keep，这对我们来说一直有效，但随着时间的推移，我们需要简化这个过程。我们尝试了其他方法，但都没有奏效，因此我花了一个月的时间开发了这个自定义应用程序。它包含了我们所需的一切，使我们的餐饮计划效率提高了至少五倍。具体功能包括：同步、一键导入食谱、购物清单、购物模式、每周餐饮计划、自定义餐点（如剩菜、素食、外出就餐等）。
上周日，我们在不到一分钟的时间内完成了餐饮计划，因为我们所有喜欢的（100多道）食谱都集中在一个地方。我们还根据每日饮食主题进行了标记（周一-意大利面，周二-肉类等），这样我们可以快速且无脑地为每一天选择一餐。
在这个应用程序中，我使用了人工智能对食品杂货进行过道分类，但不是生成式的，因为我发现简单的机器学习模型效果更好。
我非常欢迎其他开发者的反馈。
欢迎随意使用这个应用。它是免费的，除了同步功能，由于服务器成本，我不得不添加了订阅费用。我尽量让订阅条件宽松：每10个人一个订阅。
我是一名来自巴基斯坦的CNC设计师。我开发了一种新的矢量视频（SVGV）逻辑，用数学路径替代传统的像素。这种方法旨在解决预算型移动传感器上模糊和“劣质”视频的问题，并将高保真内容（如韩剧）的文件大小减少多达85%。我希望能获得对研究论文的技术反馈，并寻找潜在的C++/NDK合作伙伴。
在过去的一年里，我们一直在企业系统中实验大型语言模型（LLMs）。<p>我们发现一个根本性的矛盾：LLMs 是概率性和非确定性的，而企业则建立在可预测性、可审计性和问责制之上。<p>目前大多数方法试图通过提示、重试或启发式方法来“驯服” LLMs。这在演示中有效，但在需要可解释性、政策执行或事后问责时就开始出现问题。<p>我们发现，将 LLMs 视为建议引擎而非决策者，能够彻底改变架构。实际执行需要在一个确定性的控制层中进行，该层能够强制执行规则、记录决策并安全失败。<p>想知道在座的其他人是如何处理概率性人工智能与确定性企业系统之间的差距的。你们在生产中也遇到类似的问题吗？