Launch HN:Agnost AI(YC S26)——从智能体对话中提取用户反馈
Launch HN: Agnost AI (YC S26) – Extract user feedback from agent conversations
我们发现了什么
Launch HN:Agnost AI(YC S26)——从智能体对话中提取用户反馈。大家好 HN,我们是Shubham和Parth,两位从小一起长大的朋友,正在打造Agnost AI(https://agnost.ai),为构建聊天和语音智能体的团队提供产品分析。
- 来源:Hacker News(发现于 2026-07-15)
- 证据等级:D · 发现产品或需求信号,暂未获得可核验的商业证据。
- 商业模式:待核验
- 主题:AI Agent
- 初筛评分:26.1/100 · 收录 1 次
证据,比故事更重要。
规则清洗与初筛,未经人工商业核验。原文语境、实际客户和付费情况仍需自行验证。
引用与数字披露
来源类型(原作者自述/第三方测算/媒体转引)需采集端标注,本版尚未落字段。
- 作者
- 未标注
- 抓取日期
- 来源类型
- 未标注
- 币种
- 未标注
- 口径
- 未标注
- 披露主体
- 未标注
- 披露日期
- 未标注
中文辅助译文(全文)
嘿 HN,我们是 Shubham 和 Parth,从小一起长大的朋友,正在构建 Agnost AI(https://agnost.ai),为构建聊天和语音代理的团队提供产品分析。我们阅读生产环境中的对话,发现行为层面的失败,例如用户"愤怒提示"(咒骂代理)、反复改写同一请求、纠正代理、询问缺失的功能,或者在技术上成功的回答之后离开。这里有一个无需注册的交互式演示:https://app.agnost.ai?demo=true 这里是演示视频:https://www.tella.tv/video/agnost-ai-launch-hn-demo-9haa 核心问题是聊天和语音产品没有与 Web 应用相同的指标。当产品界面是语言时,点击和漏斗变得不太有用。用户也很少给出明确的反馈,即便给也通常是美化过的。我自己在 Claude 或 Codex 中几乎不打 /feedback。大多数用户只是咒骂、再次提问、纠正代理或离开。因此,产品工程师从延迟、错误和追踪中获取技术层面的可见性,但仍需猜测用户是否得到了他们想要的东西。我们走到这一步是因为过去一年围绕代理进行构建,并收到几位创始人的请求,希望为他们正在构建的 AI 助手提供类似对话版 PostHog 的工具。我们并不打算进入可观测性或评估(evals)领域。可观测性告诉你技术上发生了什么。评估验证你已经知道的案例。我们更偏向发现端——比如用户想要什么、在哪里感到沮丧、反复询问什么,以及应该存在哪些新的评估。团队通过 SDK 或 OTel 向我们发送代理对话消息,可附带元数据,如账户、套餐、来源、组织等。我们将对话聚类为产品特定的意图。
功能请求和 bug 是默认类别;大多数其他聚类是根据客户数据动态创建的,并随时间演变。你可以用简单的英文创建自己的聚类。如果一个聚类过于宽泛,我们会拆分它。如果出现新的模式,我们会建议它。一家 AI 视频编辑公司使用 Agnost AI 发现了隐藏在聊天中的功能请求。最大的一项是大约 70 个用户想要自动字幕,但用户的表达方式是:在单次会话中"在这一帧加这段文字"重复 12 次、"能给加字幕吗"、"给我音频的文字稿",以及跨语言的多种变体。该团队后来构建了该功能。最初最困难的部分是在数百万条消息上完成这一工作,同时不把所有内容都发送给 LLM。在 ClickHouse 中,"按时间跨对话获取最近 50 个事件"和"获取本对话中的所有事件"需要不同的排序顺序,因此我们不得不在排序键、分区、物化视图和投影上反复迭代。对于发现新聚类,将所有内容通过 LLM 处理太慢且成本太高。HDBSCAN 风格的嵌入聚类在大规模下也会因为成对比较而变得痛苦。我们首先根据余弦漂移将对话分割为片段,运行 BIRCH 来压缩 ca…
译文由上游机器翻译生成,可能有误;判断请以英文原文为准。
英文原文(来源本站未改写)
Hey HN, we’re Shubham & Parth, childhood friends building Agnost AI ( https://agnost.ai ), product analytics for teams building chat and voice agents.We read production conversations and find behavioral failures like users rageprompting (cursing at the agent), repeatedly rephrasing the same request, correcting the agent, asking for missing features, or leaving after an answer that was technically successful.We have an interactive demo with no signup here: https://app.agnost.ai?demo=true Here's a demo video: https://www.tella.tv/video/agnost-ai-launch-hn-demo-9haa The core problem is that chat and voice products do not have the same metrics as web apps.
When the product interface is language, clicks and funnels become much less useful.Users also rarely give explicit feedback, and when they do it's usually sugarcoated.I barely type /feedback in Claude or Codex myself.Most users just curse, ask again, correct the agent, or leave.So product engineers get technical visibility from latency, errors, and traces, but still have to guess whether users got what they wanted.We got here after building around agents for the last year and got a couple of founders asking for something like a PostHog for conversations for the AI assistants they were building.We are not trying to be in the observability or evals space.
Observability tells you what happened technically.Evals validate cases you already know.We're more on the discovery side like what users wanted, where they got frustrated, what they asked for repeatedly, and what new evals should exist.Teams send us agent conversation messages through SDKs or OTel, optionally with metadata like account, plan, source, organization, etc.We cluster conversations into product-specific intents.Feature requests and bugs are default categories;most other clusters are created dynamically from the customer’s data and evolve over time.You can create your own cluster in plain English.If a cluster gets too broad, we split it.If a new pattern appears, we suggest it.
One AI video editor company used Agnost AI to find feature requests hidden inside chat.The biggest one was that around 70 users wanted auto-subtitles, but users said it as “add this text in this frame” 12x in a single session, “can you caption it”, “give me transcript of audio” and variations across languages.The team later built the feature.Doing this over millions of messages without sending everything to an LLM was the hard part initially.In ClickHouse, “fetch the last 50 events by time across conversations” and “fetch all events in this conversation” want different sort orders, so we had to iterate a lot on sorting keys, partitions, materialized views, and projections.
For finding new clusters, sending everything through an LLM was too slow and expensive.HDBSCAN-style embedding clustering also gets painful at scale because of pairwise comparisons.We first split conversations into segments based on cosine drift, run BIRCH to compress the can
这条还缺什么证据?
下面每条都由本条已有字段推出(等级、理由、商业模式、来源次数、是否演示), 本站不生成推测性结论;通用验证方法放在方法论页。
- 可核验的收入或付费证据查官网定价页与付费口径;第三方数据源(如 GetLatka)只作旁证,需标注来源与时点。
- 商业模式未定确认按席位/按用量/授权还是开源托管版收费;开源项目另查 LICENSE 与是否存在付费版。
- 只有单一来源找一手站点或其他渠道是否重复出现同一产品;社区热帖数量不等于商业进展。
通用验证清单(谁有这个问题/谁愿意付费/一个人能交付哪一小步)见我们的筛选方法。