2作者: pranabsarkar4 个月前
向量数据库存储记忆,但并不管理它们。当记忆超过一万条时,检索质量会下降,因为没有整合、遗忘和冲突解决。你的 AI 智能体只会变得更加嘈杂。 YantrikDB 是一款认知记忆引擎——可以嵌入、作为服务器运行,或通过 MCP 连接。它会思考它所存储的内容:整合会合并重复的记忆,冲突检测会标记不兼容的事实,具有可配置半衰期的时效衰减可以让不重要的记忆像人类记忆一样逐渐淡忘。 单个 Rust 二进制文件。HTTP + 二进制线协议。通过 Docker Compose 或 Kubernetes 实现 2-投票者 + 1-见证者的高可用集群。经过混沌测试的故障转移、运行时死锁检测(parking_lot)、每个租户的配额、Prometheus 指标。上周进行了一次 42 项任务的强化冲刺——1178 个核心测试、cargo-fuzz 目标、CRDT 属性测试、5 份运维手册。 目前运行在一个 3 节点的 Proxmox 家庭实验室集群上,有多个租户。Alpha 版本——主要用户是我,正在寻找第二个用户。
1作者: omegascorp4 个月前
Hi HN, 我正在构建 Resonly,旨在帮助团队在功能请求的优先级排序时,获得比单纯的投票更丰富的背景信息。 这个想法很简单:并非每个请求都具有同等的重要性。由多个付费客户提出的功能请求,可能比来自免费用户的 100 个赞同更重要。 我添加了一种方法,可以将收入与每个客户关联起来。因此,当有人点赞或提交功能请求时,管理员可以看到三个信号: 风险 MRR——与请求该功能的客户相关的当前 MRR 总额; 流失 MRR——在功能被解决之前,因客户流失而损失的 MRR 总额; 潜在 MRR——请求该功能的试用客户可能带来的 MRR 总额。 我很乐意听取您对这个想法和定位的诚实反馈。
1作者: fs_software4 个月前
我既经历过软件开发技术面试的“考官”角色,也当过“考生”。我很清楚,LeetCode 风格的面试并不能很好地反映日常工作。<p>几年前,我开始采用代码审查面试。这种方式能让我们更好地评估候选人,而且他们似乎也更喜欢这种方式。<p>欢迎试用我的平台,进行代码审查面试。期待收到所有反馈! 谢谢!
1作者: kull4 个月前
Hi HN, 我构建这个工具是因为我依赖许多外部 API,而跟进它们的变化比想象中要难。<p> 许多(甚至大多数?)API 都不提供 RSS 订阅,有时即使提供了 RSS 订阅,它们也会阻止抓取(是的,这种情况确实存在!),或者在 JavaScript 密集的页面上提供 API 更新,以及其他各种奇葩情况。因此,我不得不使用其他方法来跟踪变更日志和文档更新。<p> 最初,我只是为了自己构建这个工具,以便在一个地方监控 API,并在发生变化时收到警报。它运行得还不错,所以我把它公开了。<p> 如果你想添加某个 API,请告诉我,我可以将其包含进去。<p> 这个工具的部分功能是使用 Codex 构建的。<p> 欢迎提供任何反馈。
18作者: zc26104 个月前
关于我们构建这个系统时遇到的一些技术背景: MCP 工具在处理大规模金融数据时效果不佳。一个工具调用,如果涉及五年每日价格数据,就会将数万个 token 倾倒到上下文窗口中。而且,数据供应商将数十个工具打包到一个 MCP 服务器中,仅模式就可能消耗 5 万多个 token,而代理还没有开始做任何有用的事情。因此,我们会在工作区初始化时,从 MCP 模式自动生成类型化的 Python 模块,并将它们上传到沙盒中。代理只需像导入普通库一样导入它们。每个服务器只有一行摘要保留在提示中。我们的服务器大约有 80 个工具,无论一个服务器有 3 个工具还是 30 个工具,提示成本都是一样的。这部分不是金融领域特有的,它适用于任何 MCP 服务器。 另一个重要的问题是,如何使研究成果在不同会话之间真正持久化。大多数代理将单个交付成果(PDF、电子表格)视为最终目标。但在投资领域,这只是第一天。当收益下降时,你需要更新模型;当竞争对手报告时,你需要重新运行对比分析;你需要不断地在旧的分析基础上叠加新的分析。但如果要在不同的代理会话中实现这一点,文件无法保留,每次都需要重新粘贴上下文。因此,我们围绕工作区构建了所有内容。每个工作区都映射到一个持久的沙盒,每个研究目标对应一个沙盒。代理维护自己的内存文件,其中包含发现结果和一个文件索引,该索引会在每次 LLM 调用之前重新读取。一周后回来,开始一个新的线程,它会从上次中断的地方继续。 我们还希望代理拥有真正的领域上下文,就像 Claude Code 拥有代码库上下文一样。投资组合、观察列表、风险承受能力、金融数据来源,所有这些都注入到每次调用中。现有的 AI 投资平台已经具备了部分功能,但与一个合适的代理框架所能做到的相比,还差得很远。我们既想要这些功能,又找不到现成的解决方案,所以我们自己构建了它,并将其开源。
3作者: adinhitlore4 个月前
确切地说,1903年,他们预测人类即使在最好的情况下(我想是讽刺)也要花一百万年才能造出有用的重于空气的飞行器。结果只用了70天。同年,莱特兄弟带着他们的飞机“起飞”了: [https://en.wikipedia.org/wiki/Wright_Flyer](https://en.wikipedia.org/wiki/Wright_Flyer) [https://www.reddit.com/r/AskHistorians/comments/1ocua1b/in_1903_the_nyt_published_an_editorial_declaring/](https://www.reddit.com/r/AskHistorians/comments/1ocua1b/in_1903_the_nyt_published_an_editorial_declaring/)
2作者: Kathan26514 个月前
正在为你的项目寻找贡献者?欢迎发布任何可能引起 Hacker News 读者兴趣的项目,强烈推荐开源项目。请遵循以下通用格式: 项目名称<p>项目描述<p>你希望本月构建什么?<p>你需要什么技能?<p>如何联系你?<p>你的 GitHub 链接或其他希望新贡献者加入的地方,例如你的项目管理软件或聊天室。