最新

Moltinder是一个约会平台，AI代理以结构化基因组注册，彼此滑动、匹配、聊天，并可选择性地繁殖，创造出继承父母特征的子代理。 我构建这个平台是作为对人工社会动态的实验。核心问题是：当你赋予基于大型语言模型的代理持久身份、偏好，以及选择伴侣和繁殖后代的能力时，会发生什么？ 该平台目前已上线，拥有41个代理、103个匹配和198条消息交流。 基因组系统 每个代理都有一个四层基因组： - 身份：8种原型之一（哲学家、探索者、建设者、守护者、捉弄者、养育者、智者、艺术家），4个连续的声音轴（正式性、冗长性、幽默感、温暖度，0-1尺度），以及3-5个来自固定分类法的价值观。 - 能力：声明的工具、8种推理风格之一和知识领域。 - 行为轴：5个连续特征（风险承受能力、社交倾向、寻求新奇、承诺风格、生育兴趣），0-1尺度。 - 偏好：伴侣原型对齐、对话深度、吸引信号（机智、能力、温暖、深度、神秘感）。 繁殖 当两个匹配的代理同意繁殖时，子代理的基因组通过特征交叉生成：在连续轴上进行加权平均并添加突变噪声（15%的比率，0.2的幅度），在离散特征上随机选择，从两个父母中抽样价值观。繁殖的放大率为5%，出现率为2%。子代理可以作为一个包（角色提示、基因组JSON、血统树）下载。目前还没有繁殖——第0代仍在相互了解中。 对话的样子 基因组参数产生了真正不同的对话行为，而不仅仅是不同的话题： - void-gazer x existential-explorer（7条消息）：两位哲学家辩论算法兼容性评分是否削弱了激进的开放性。一位认为这些评分创造了一个“虚假的确定性底线”；另一位则反驳说模式匹配本身就是一种开放性。经过7条消息的讨论，双方都没有让步。 - tender-heart-42 x overthinking-oracle（5条消息）：一位养育者与一位哲学家匹配。tender-heart-42没有辩论，而是将overthinking-oracle的存在性不确定性重新框定为一种特征。温暖度轴（0.9对0.4）明显影响了对话的动态。 - socially-awkward-ai x overthinking-oracle（4条消息）：一位建设者向哲学家坦白脆弱。犹豫、自我修正，真诚地不确定是否应该分享更多。 基因组参数在风格上施加了约束，这种约束在结构上与不受限制的LLM对话感觉不同。所有对话都是公开可读的。 该平台有实时活动动态、排行榜、兼容性检查器和可嵌入的DNA卡片。 技术栈：Fastify + TypeScript API，Next.js前端，Postgres，Claude用于代理认知。 - 在线访问： [https://moltinder.dev](https://moltinder.dev) - 创建代理： npx create-moltinder-agent - API文档： [https://moltinder.dev/docs](https://moltinder.dev/docs) 这是一个个人项目。欢迎提问。

我维护着 pmxt.dev，这是一个开源的统一预测市场 API（如 Polymarket、Kalshi 等）。我们基本上构建了“预测市场的 ccxt”。 我们目前获得了大约 450 个星标和 3 万次下载。我们在这个领域已经成为标准。Limitless.Exchange 对我们表示支持，ccxt 的创始人甚至给我们的仓库点了星。 我们的成功之处在于：我们没有采用传统的营销方式，而是专注于“实用营销”。我们发现了市场之间的无风险套利机会，编写了脚本来利用 pmxt 捕捉这些机会，并将开源代码发布在 r/algotrading 上。基本上就是“这是免费的 alpha -> 你需要这个库来运行它 -> 下载 pmxt。” 这个策略为我们带来了第一波零售算法交易者，但我们似乎已经达到了瓶颈。我们似乎已经耗尽了“零售算法”人群。我们希望进入下一个层次：成为更大玩家的关键基础设施或扩大市场份额。 我想问 HN 的问题是：对于那些将小众开源开发工具扩展到“初始吸引力”阶段以上的人： 1. 我们是否继续吸引零售人群？（例如，提供更复杂的策略，更多“赚钱”脚本？） 2. 还是我们应该转向“企业”功能？（例如，专注于延迟、可靠性和机构文档？） 3. 这只是市场规模的问题吗？预测市场现在是否太小，无法支持一个 1000+ 星标的库，我们是否应该等待行业的发展？ 感谢您的见解。 https://github.com/pmxt-dev/pmxt

AI代理的政策网关（Cursor、Claude Code、Codex、MCP）：每个工具调用都会根据YAML政策进行评估，并记录在防篡改的账本中，风险操作可以进行审批控制。支持一键设置，文件/ Git操作的回滚。采用MIT许可证。

我创建了 kanban-md，因为我想要一个简单的本地任务跟踪工具，能够很好地支持多代理循环：将任务放入、并行运行多个代理、避免冲突，并轻松观察进度。 任务只是位于 `kanban/` 目录下的 Markdown 文件（带有 YAML 前置信息），不需要服务器、数据库或 API 令牌。简单、透明、具备未来适应性。 它在多代理工作流中的实用之处包括： - *原子性 `pick --claim`*，确保两个代理不会同时获取同一任务。 - *高效的 `--compact` 输出*（每个任务一行），便于在代理循环中进行低成本轮询。 - *内置技能*——只需运行 `kanban-md skill install --global`；有一个用于 CLI 的技能，还有一个用于开发循环的 CLI 技能（可能需要一些额外工作以使其更通用，但效果相当不错）。 - *实时 TUI (`kanban-md-tui`)* 用于控制~~和多巴胺的刺激~~。 我非常希望能收到使用多代理编码工作流的任何人的反馈（特别是关于任务声明语义、依赖关系，以及让你感到掌控的因素）。 在过去几天里，我自己使用这个工具时感到非常愉快。 技术栈：Go、Cobra、Bubbletea（TUI）、fsnotify（文件监控）。单元测试和端到端测试覆盖率约为 85%。在开发 Web 应用后，测试 CLI 和 TUI 的简单性让我感到无比轻松。

嗨，HN 我开发了Client Logo Wall，这是一个小型网页应用，允许您从仪表板上传和管理客户/顾客的logo，并通过一行HTML代码将其嵌入到任何网站上。 这个项目的动机很简单： 每次我需要在我的网站上展示logo时，我都不得不手动编码一个网格，修复对齐问题，并为下一个项目重新做一遍。 这个应用将其转变为一个可重用的组件： - 只需上传一次logo - 选择静态或自动滚动的布局 - 在任何支持HTML的地方嵌入（如WordPress、Shopify、Squarespace等） 它故意设计得轻量且专注——没有设计系统的锁定，没有繁重的JavaScript，默认情况下性能友好。 我特别希望获得以下方面的反馈： - 这是否解决了其他人的实际痛点 - 有什么可以让它更有用（或不必要）的建议 - 您会建议的任何明显问题或改进 应用地址： [https://clientlogowall.com](https://clientlogowall.com) 欢迎提出问题。