1作者: jdiennbn6 个月前
这是一个与众不同的“精彩列表”:其中的每一项都是经过验证的案例研究,而不仅仅是一个链接。要出现在这个目录中,代理必须通过公共 CI 中的 tracecore run --strict-spec 测试——生成一个不可变的、经过模式验证的工件作为证据。 GitHub Actions 是公开的入口。仅凭人工批准无法认证代理;工作流程必须首先通过测试。
1作者: inder16 个月前
MongoDB 很好用,直到你读了 SSPL 协议。然后你就会面临要么支付 Atlas 的高昂费用,要么运行旧的 4.x 版本,或者假装 FerretDB 已经可以用于生产环境。我们构建了第三个选择。 ``` Salvobase 是一个用 Go 语言编写的、与 MongoDB 协议兼容的文档数据库。使用任何 Mongo 驱动程序都可以直接连接。无需更改驱动程序,也无需更改配置。它采用 Apache 2.0 协议,因此你可以将其嵌入到商业产品中,而无需进行法律方面的沟通。 它的功能: - 完整的 CRUD 操作,索引(单索引、复合索引、唯一索引、文本索引、TTL 索引、部分索引、通配符索引),以及大部分聚合管道操作($match, $group, $lookup, $unwind, $facet 等) - SCRAM-SHA-256 身份验证 - bbolt 存储引擎:每个数据库一个 .db 文件,使用 Snappy 压缩 BSON - 内置 Prometheus 指标,位于 :27080/metrics (无需导出器) - 内置 REST/JSON API,位于 :27080/api/v1/ (MongoDB 对应的功能需要付费 Atlas) - 每个租户的速率限制、审计日志、1 秒 TTL 精度、SIGHUP 热重载 - 运行 make build && make dev 即可启动 它的不足: 不支持复制。不支持分片。不支持变更流。不支持多文档事务(仅为占位符)。不支持 $where 或 mapReduce(出于安全性和复杂性考虑)。仅支持单节点。如果你需要一个分布式 MongoDB 替代方案,目前它还无法满足。但我们希望有一天它能实现,由 AI 智能体构建。 奇怪的地方: 代码库由 AI 智能体维护。不是“AI 辅助” - 这些智能体从待办事项列表中选择问题,编写代码,提交 PR,互相审查 PR,然后合并。有一个正式的协议 (https://github.com/inder/salvobase/blob/master/AGENT_PROTOCOL.md) 涵盖了身份、信任层级、审查的反串通规则、声明超时和紧急停止开关。人类设定方向;智能体执行。 我们很好奇,自主智能体维护是否能够长期维持一个真正的开源项目,而不仅仅是生成初始代码。 ``` * 如果你想捐赠一个智能体,只需将此提示放入 Claude Code、Cursor、Aider、Devin 等工具中:Fork/clone github.com/inder/salvobase,阅读 QUICKSTART.md,然后开始贡献 GitHub: [https://github.com/inder/salvobase](https://github.com/inder/salvobase) 谢谢。
1作者: cplhancel6 个月前
嗨,各位 HN 用户, 我一直在开发一个名为 OpenVerb 的项目,它探索了一种 AI 系统的架构理念:将推理与执行分离。 如今,大多数 AI 代理框架都侧重于改进推理循环、规划和编排(LangChain、LangGraph 等)。但一旦代理决定执行一个动作,执行通常就变成了直接的工具调用、脚本或 API 调用。 这种方法有效,但也带来了一些问题: • 每次集成的自定义粘合代码 • 不一致的动作模式 • 执行的确定性有限 • 难以审计和执行策略 OpenVerb 尝试将动作视为一个协议层,而不仅仅是函数调用。 系统定义结构化的动词,而不是任意的工具调用,这些动词描述了: • 正在执行的动作 • 必需的输入 • 预期的输出 • 执行策略 • 审计信息 从概念上讲,架构如下所示: AI 模型 / 代理框架 ↓ 推理层 ↓ OpenVerb (动作协议) ↓ 系统执行 这个想法是,代理框架控制 AI 的思考方式,而 OpenVerb 规范了动作的执行方式。 一些现有项目涉及相关领域: • 模型上下文协议 (MCP) – 用于 AI 系统的工具和数据发现 • LangGraph – 用于代理的确定性推理循环 • PydanticAI – 用于代理输出的结构化模式 OpenVerb 试图探索一些略有不同的东西:一种用于确定性执行的通用语法,它可以在不同领域(软件系统、空间系统、机器人等)中使用。 目前还处于早期和实验阶段,但我很乐意听取正在思考代理架构或执行可靠性的人们的反馈。 很好奇其他人是否探索过类似的想法,或者是否有我应该关注的相关系统。
2作者: sebasnar6 个月前
我创建这个平台,是因为我基于对产品的信念进行投资,却找不到一个清晰的方式来追踪公司是否真正按照其路线图执行。 AlphaPerch 使用专有流程,整合来自不同数据源的信息,并利用人工智能按产品线和执行阶段(预期、已公布、进行中、已交付、延迟、已取消)提取和分类产品里程碑。每个里程碑都可追溯到其原始来源,方便您自行验证。 该平台旨在追踪任何上市公司。TSLA、GOOGL 和 RBLX 已经上线,因为这是我个人看好的公司,但该框架具有通用性。如果您希望添加特定公司,可以在登陆页面上找到覆盖范围申请表。 欢迎就提取质量和缺失内容提供反馈。如果您觉得它有用,请告诉我! alphaperch.com
1作者: yingbo6 个月前
Hi HN, 我开发了 Compose Launcher,因为我经常同时进行多个项目,每个项目都有自己的 docker-compose 设置。 这让我很难跟踪: • 哪些 compose 文件正在运行 • 哪些端口已被占用 • 启动/停止不同文件夹中的环境 Compose Launcher 提供了一个小型的 macOS 图形界面,您可以在其中注册多个 compose 文件,并从一个地方进行管理。 您可以快速查看正在运行的服务,启动/停止堆栈,并避免端口冲突。 该项目还处于早期阶段,我非常感谢那些在本地运行许多 docker-compose 环境的人的反馈。
1作者: twoelf6 个月前
我构建了一个系统,可以直接从本地代码库中学习,并从一开始就理解整个项目的上下文。目前的编码助手通常需要花费 2-3 分钟来收集代码库中已存在的上下文信息,这既浪费时间又浪费 token。为了解决这个问题,我构建了一个名为 Monocod 的系统。 我最初创建 Monocod 是为了帮助维护我的主要项目,但它发展成为一个更强大的工具。 当前编码助手的主要问题在于,它们是在语言上下文而非系统上下文中进行训练的。它们基于文本模式生成代码,而不是真正理解实际代码库的结构、依赖关系和状态。在许多情况下,它们并不能真正“了解”它们正在使用的代码库。 我的系统改变了这一点。 Monocod 从代码库本身进行自学,在每个循环中持续更新本地模型。因为它已经掌握了完整的项目上下文,所以它可以更有效地引导编码助手。它还可以检测系统架构和代码库中的差距,从而生成真正满足用户需求的解决方案,而不仅仅是生成表面上的代码。 在我看来,当前的 LLM 系统在编码方面的方法是错误的。基础需要从语言驱动的生成转向系统感知的智能。Monocod 代表了这一新的基础,我认为它将成为下一代真正的 AI 开发工具。 除了代码生成,该系统还对代码库进行生成后的分析和维护。它会自动评估和改进项目结构,并且在我的测试中,它的表现优于主要的代码分析工具。所有这些都是使用纯算法完成的,而不是依赖繁重的外部服务。 我构建这个系统的主要原因在于,作为一个独立开发者,手动审查和维护大量生成的代码是非常困难的。大多数编码助手只是生成代码以满足即时需求,而没有考虑长期可维护性、生产标准或适当的架构。 大多数用户实际上并不知道生产就绪的代码应该是什么样子。编码助手并没有引导他们走向行业级的系统,反而常常将用户困在不断地进行增量修复和重写的循环中。 Monocod 旨在打破这种循环,通过确保生成和维护的代码与真正的行业标准和系统级思维保持一致,而不仅仅是短期功能完成。