最新

我在切换“掌控”状态时总是面临这种明显的挣扎，最好的例子就是司机与乘客对道路的感知差异。<p>使用人工智能进行编码让我想起了这种感觉，时而“驾驶”，时而“乘客”的切换感觉比全心投入其中的任何一方都要疲惫。我有一个理论，强制减少参与感在任何形式上都会产生各种副作用。<p>想知道是否还有其他人也有这种感觉，如果有的话，你们有没有成功尝试过什么方法来应对？

这是我尝试用生成性人工智能做一些有趣的事情。我已经和一些家人及他们的孩子进行了测试，孩子们似乎很喜欢。制作这些故事的成本有点高，我在定价模型上反复考虑过。现在我决定暂时免费，如果这个项目获得关注，我可以稍后解决这个问题。 我非常希望能得到你们对网站的反馈！ 关于技术细节——这个项目是用NextJS构建的，托管在Vercel上，代码是用Cursor和Claude Code编写的。我们在工作中不允许使用Cursor或Claude Code，所以看到这些工具的实际效果让我大开眼界。我在工作中专业使用React，但主要是内部工具，所以我们不使用服务器端渲染（SSR）。能够亲自操作这些工具真的很不错。

地点：远程 技能：Apache Flink, Kafka, Spark, Hadoop, Spring Boot, AWS, C++, FastAPI, 机器学习, 深度学习, Java, MongoDB, Postgres, 定价选项 我构建了一个实时投资组合优化系统，该系统通过Kafka将来自卡萨布兰卡交易所的股票和指数数据流入Flink，计算对数收益，并使用马科维茨/套利定价理论模型动态更新投资组合权重。 我处理去重、使用RocksDB进行状态管理，并在本地和云环境（包括混合Hadoop集群）中部署组件。 此外，我还为摩洛哥政府构建了一个聊天机器人，使用了RAG、FAISS、CamemBERT和FastAPI，部署在Ubuntu上，并与前端Drupal集成。 希望能为专注于基础设施、交易系统或可扩展后端问题的团队贡献力量。

嘿，HN！我们正在构建Agentic Trust，一个统一的平台，可以将您的代码转化为具备内置身份验证、安全性和可观察性的生产就绪MCP（模型上下文协议）服务器。 *问题：* 随着AI代理变得越来越强大，它们需要安全的方式来访问工具和数据。MCP（Anthropic的开放协议）非常适合标准化代理与工具之间的通信，但在生产环境中部署MCP服务器是复杂的。您需要身份验证、速率限制、审计日志、多租户等，同时确保您的代理不会通过提示注入或其他攻击被利用。 *我们的解决方案：* 一个端点（agentictrust.com）处理您所有的MCP服务器。您编写工具逻辑，我们处理其他所有事务： - 带有范围权限的OAuth 2.0身份验证 - 速率限制和使用分析 - 合规审计轨迹 - 自动版本控制和路由 - 防止提示注入攻击 *技术细节：* 我们还在研究OIDC-A（代理的OpenID Connect），这是一个扩展OIDC以支持代理身份的提案。它增加了代理证明、委托链和能力的声明。最近，这一提案在Identiverse上由WorkOS的首席执行官进行了介绍。 我们的想法是，代理应该像用户一样拥有可验证的身份。当代理代表用户行动时，您需要跟踪该委托链以确保安全和合规。 *为什么是现在：* 随着微软在Windows 11中宣布支持MCP，以及OpenAI采纳该协议，我们看到MCP使用量的爆炸性增长。但大多数实现都不安全——端点暴露、没有身份验证、容易受到攻击。我们正在解决这个问题。 *链接：* - 平台：<a href="https://agentictrust.com" rel="nofollow">https://agentictrust.com</a> - OIDC-A提案：<a href="https://subramanya.ai/2025/04/28/oidc-a-proposal/" rel="nofollow">https://subramanya.ai/2025/04/28/oidc-a-proposal/</a> - WorkOS关于我们工作的文章：<a href="https://workos.com/blog/identity-for-ai-agents" rel="nofollow">https://workos.com/blog/identity-for-ai-agents</a> 我们目前处于早期访问阶段，非常希望听到HN社区的反馈。您对AI代理有哪些安全担忧？您今天是如何处理代理身份验证的？

我厌倦了每次需要部署 Docker 镜像时都要进行的推送到注册中心/从注册中心拉取的繁琐操作。在某些情况下，使用一个完整的外部（甚至本地）注册中心会带来烦人的开销。而且如果仔细想想，任何启用 Docker 的主机上实际上已经存在一种形式的注册中心——Docker 自身的镜像存储。 因此，我构建了 Unregistry [1]，它通过标准的注册中心 API 暴露 Docker（containerd）的镜像存储。它添加了一个 `docker pussh` 命令，可以通过 SSH 将镜像直接推送到远程 Docker 守护进程。它只传输缺失的层，使得操作快速高效。 ```bash docker pussh myapp:latest user@server ``` 在后台，它会在远程主机上启动一个临时的 unregistry 容器，通过 SSH 隧道进行推送，并在完成后进行清理。我在开发 Uncloud [2]（一个用于在 Docker 主机网络中部署容器的工具）时作为副产品构建了这个工具，并认为它作为一个独立项目会很有用。 非常希望听到你的想法和使用案例！ [1]: [https://github.com/psviderski/unregistry](https://github.com/psviderski/unregistry) [2]: [https://github.com/psviderski/uncloud](https://github.com/psviderski/uncloud)