最新

领英在建立人脉方面很棒（也许并非如此），但要找到相关的人和机会却过于麻烦。 虽然我很大程度上同意代理不应该自主发帖，但我也不喜欢你不能将代理用于潜在客户开发。 所以我构建了 Parlel，一个原生代理的专业网络，人类和代理可以共存，并且人类所做的一切都可以通过 mcp 暴露给代理。 这个想法很简单，与其手动搜索，不如启动一个代理“为我寻找正在招聘创始工程师的 YC 公司”，它会搜索 Parlel 和开放互联网，并定期将结果通过电子邮件发送给你。 创始人可以搜索潜在客户、招聘候选人，并直接联系他们，没有任何限制。 这个网络还处于非常早期阶段，但非常希望得到大家的反馈。

大家好，我是 Komran，type.com 的 CTO 和联合创始人。我们今天正式上线。我一直将 type 描述为“非技术人员的 IDE”。它能让你构建出色的产品，而无需担心维护本地开发环境。 一切默认都以云端优先。无需处理复杂的交接流程或任何繁琐的操作。每个线程都由一个持久化的沙盒虚拟机支持，即使你进行 Git 操作，也不必担心 Git worktrees。你可以从 Claude、Codex、Slack 或电子邮件开始工作，然后将其推送到 Type 中的共享会话，你的整个团队都可以进行协同提示。 由于我们的“meta-harness”是 Codex CLI 和 Claude Code 的封装，你可以连接现有的订阅。因为我们是多人协作产品，所以我们必须确保只对用户创建的消息收取订阅费用。如果 Alice 拥有订阅并与代理开始一个线程，她将使用她的订阅。如果 Bob 加入并添加自己的提示，但 Bob 没有订阅，他将根据其 Type 使用量收费。我们不收取任何 token 溢价。 即使产品尚处于早期阶段，我们的客户也对我们非常满意，并更倾向于使用我们而不是 Claude Code。如果非要说我们相对于 Claude Tag/Claude Cowork 的优势，那就是： * 你可以随时切换模型/harness，不受限于单一提供商。 在 Type 上创建自定义内部应用/产物更好，因为我们处理内部托管、RBAC、版本控制、开发/生产环境，甚至让你的应用能够与你的 Type 集成进行通信。共享内部应用就像共享 Google 文档一样简单。 * 底层只是 Claude Code 和 Codex。总的来说，它的工作方式应该与 Codex 和 Claude Code 非常相似。 * 在我上一家公司 Halp.com（已被 Atlassian 收购）时，我们发明了“Slack-first”这个词，因为我们知道人们喜欢在不切换上下文的情况下完成工作。Type 在 Slack 中表现出色。每个 Slack 频道都映射到一个公共或私有的“空间”，该空间具有对集成只读或读写权限的访问权限。每个空间都内置了默认的 harness、模型和工作级别。因此，你可以从 Slack 使用你的订阅。 * 我们的 CLI 允许你在本地机器上进行单人模式工作时，也能获得 Type 的最佳功能。Type CLI 可以将你的本地会话推送到 Type，以便其他人查看。它还可以推送文档进行协作编辑，甚至可以在本地重用你已获得访问权限的 Type 集成。 你今天就可以在 [https://type.com](https://type.com) 注册。 你将获得价值 100 美元的积分进行试用。构建这个产品非常有趣。与 Grok Bot、Codex 和 Claude Cowork 等产品竞争非常有趣，但我认为它们仍然非常偏向个人助理、单人模式。每个人都需要设置相同的集成，需要从头开始创建技能和自动化，而且每个 Frontier 的产品都会让你被锁定在其模型中。

各位 HN 的朋友们， 每次我通过 Jupyter Notebook 运行几天训练循环时，遇到问题（网络断开、笔记本电脑突然关机等），我都会丢失 ipykernel 和单元格输出。我希望在 IDE 中直接看到实时输出，而无需频繁检查 W&B 或日志文件。这太麻烦了。 这就是我构建 Tithon 的原因。 请告诉我你们的想法！

大家好，我是 Michael，Rindler（YC S26）的联合创始人之一。我们开发了 Maxxwell，它可以帮助您管理十几个编码代理会话的进度、上下文和阻塞问题。这让您可以将更多时间投入到真正高杠杆的决策中（并让您在离开电脑时更有信心）。 我们最初在构建浏览器代理，它们会登录到网站，并使用网站的缓存表示来进行廉价可靠的重复运行。这其中存在大量棘手的挑战，例如网站映射、绕过机器人防御以及处理凭证和双因素认证。维护成本巨大，我们被技术交付所拖累。 我们尝试了 Cursor、Claude Code、Conductor，甚至还构建了一个内部的 Devin。这些工具要么感觉迭代大型任务的速度太慢，要么变成了我无法信任其决策的黑箱（您不能简单地告诉 Devin “改进网站映射器”然后就万事大吉了，不幸的是）。因此，我们最终决定在终端窗口中运行十二个 Claude Code 会话。您可以更精确地控制正在进行的工作，同时还能成倍增加您的产出量，尽管代价是：您。 在十二个终端之间回答问题非常耗费精力。此外，很多问题都是细枝末节的代码选择，挤占了真正值得您发表意见的内容。目前并不清楚哪些会话正在取得进展，哪些被卡在了一些琐碎的事情上，或者哪些会话在制定新目标时迷失了方向。最后，我感觉自己不像是一个代理的指挥者，更像是连接 Claude 和我的工作空间的“人类媒介”。 为了能重新接触现实生活，我们自己动手搭建了一个系统，该系统有一个专注于让其他会话与目标保持一致并解析代理噪音的协调代理。现在，我主要只与那个协调代理会话进行通信。它会告诉我哪些工作已经完成，哪些已经为我做出了决定，以及哪些确实需要我的输入。每个工作代理都是一个在真实 PTY 中运行的未修改的 Claude 或 Codex 进程，因此您仍然可以连接到任何会话并与之交互。这在功能上实现了多路复用会话的所有生产力和质量优势，同时有望让您保持理智。 这是 IDE 的 90 秒演示：https://www.loom.com/share/125c58d597234685b1a632839a83813a 在过去一个月的使用中，每个提示（具有相似的语义权重）的合并 PR 数量从 0.9 个增加到 5 个，而这些 PR 的回滚率从 0.56% 下降到 0.20%。我们有信心让协调代理管理我们的代理会话数小时，它也非常适合夜间运行。 Maxxwell 支持 BYOK 或订阅，否则免费且完全本地化。我们也在考虑提供托管服务，以节省您本地机器的内存。 快来看看吧！如果您已经同时运行了多个代理会话，我特别想知道： - 什么能让您相信一个无人值守的会话会保持一致？我们目前有目标清单，协调代理会监控以确保遵守。 - 您更倾向于代理自主性和控制权之间的何种平衡？

成本大幅降低、性能显著提升等情况出现在哪里？

我是一名创始人，我刚刚构建了 Revliu。 在构建了几个产品之后，我一直想了解我的客户是如何找到我的。是哪个营销活动将他们吸引过来，他们来自哪个渠道，以及他们完整的客户旅程是怎样的。 市面上已经有一些工具可以做到这一点，但我遇到的一个持续存在的问题是，它们通常只停留在首次触达或末次触达。 这就是为什么我围绕多触点归因和完整的客户旅程构建了 Revliu。 一旦有人访问了你的网站，Revliu 就会为他们分配一个匿名 ID 并开始追踪他们的旅程。当他们注册后，这个旅程就可以与实际客户关联起来。 从那时起，你就可以看到他们是否处于试用期，他们多久回来一次，他们打开了多少次会话，以及最终他们何时付费。 对我来说，这也有助于我更容易地与用户沟通，并理解他们为什么会在那个特定时刻做出前进的决定。 今天，Revliu 追踪获客渠道、回访用户、会话、触点和收入。 我不想仅仅知道一个营销活动获得了多少次展示，而是想知道它实际带来了多少收入。展示次数并不是我真正关心的。 这个应用本身非常简单。 主页会给你一个按渠道划分的收入概览。 流量页面显示访客、他们的旅程和会话。 营销活动页面显示获客漏斗。对于 SaaS 产品来说，这可以是访客 → 潜在客户 → 试用 → 付费客户。对于在线商店来说，它可以简单地是获客 → 购买。 客户页面允许你单独查看每个客户，查看他们的触点、他们来自哪里、他们的旅程以及他们何时购买。 技术方面原理上很简单。 它始于一个获得 ID 的匿名访客。我们追踪他们的访问和触点。当他们注册时，这个匿名的旅程就与客户关联起来。 Stripe 也已连接，因此当客户付费时，收入就可以链接回同一个旅程。 目标基本上是将获客 → 访问 → 注册 → 客户 → 收入联系起来。 目前，该应用仍处于第一阶段。我还没有构建完我想要的所有集成。 接下来我想要构建的是能够做得更多，而不仅仅是展示数据的东西。 如果有人留下了他们的电子邮件但从未完成注册，多次回来但未购买，或者表现出真正的兴趣但未转化，我想利用这些信息来尝试挽回那个潜在客户。 想法是通过电子邮件再次联系他们，或者根据集成情况，通过 LinkedIn 等其他渠道联系他们。 这就是为什么我今天仍然认为该应用是有限的。我首先想测试这个归因部分，看看这个问题是否有真正的吸引力，然后再构建其他所有东西。 我真正感兴趣的未来部分是收入挽回。 通过与 AI 结合，目标是适应不同的客户，了解哪些客户在犹豫，并做得更多，而不仅仅是显示数据。 我希望数据能在产品内部真正发挥作用。 我真的很想知道你今天是如何处理这个问题的。 编码比以前容易多了，但一个畅销的好产品和一个没人用的好产品之间的区别，往往在于营销和分销。 我真的很想听听你对 Revliu 的反馈，以及你对我的方法和你会如何做不同的事情的看法。

你好 HN， 我创建了一个用于查询内存中 JS 数据的 TypeScript 库。最初的目的是提供一个比 AlaSQL 更模块化、更轻量级的替代方案，但后来有人要求我支持 SQL/XML，我个人觉得这两种语言都过于冗长。于是我开始思考，想起了 Virtuoso 结合了 SQL 和 SPARQL 的查询方式，并以此为基础进行了扩展。 最终的引擎包含一个共享的核心，提供优化器、查询基础设施等，以及可以作为插件添加的独立语言。实现方式是将这些语言翻译成一种通用的代数。因此，你可以在单个查询中混合使用多种语言——想象一下你需要处理一些表格数据，但对于每一行，你都想从一个深层的树状结构中提取信息。这时，你可以编写一个外部 SQL 查询，并在其中嵌入一个 XQuery 子查询，它就能正常工作。这个代数本身就被设计成可扩展的——我不敢说它涵盖了所有查询语言可能需要的功能（但已经实现了针对每种主要数据模型的语言——SQL、XQuery 和一种类似 Cypher 的语言（涉及许可问题））。例如，XQuery 包含了两个特殊的代数运算符，而无需修改核心。 GitHub README 中有一个演示链接，你可以在其中查看查询计划或在示例数据上执行查询。如果你对此感兴趣，还有一个关于这个项目的我的毕业论文链接。去年，整个项目曾在 VLDB 上作为演示进行过展示。 这是我两年多工作的成果，我认为其他人也可能觉得它有用——主要是因为我能够编写出令我满意的文档。文档是借助 LLM 创建的，但我为此花费了数周时间，所以希望它们读起来不错。除了最初的一批回归测试外，代码本身都是手工编写的。