HackerNews中文版

现实情况：他们没有。但这项技术是真实的。我正在构建一个人工智能销售开发代表（SDR）平台，想与HN社区分享这个技术栈。项目：Babuger Babuger自动化整个外呼/内呼生命周期。它通过训练你最佳销售代表的脚本来筛选潜在客户、处理异议，并全天候安排会议。问题：传统的SDR团队成本高昂（每年15万美元），人员流动率高，并且忽视“死”线索。解决方案：一个人类协调者管理20多个专业的人工智能代理。结果：90%的任务自动化和70%的被忽视管道的响应率。技术栈我保持现代和模块化，以处理复杂的多步骤推理：代理协调：LangGraph。这对于处理非线性对话流程（循环、条件路由和状态管理）至关重要，而标准的有向无环图（DAG）无法处理这些情况。大型语言模型框架：LangChain。用于提示模板、输出解析和整合各种工具集（Gmail/Cal.com/HubSpot）。前端：Next.js。管理仪表板、实时电子邮件线程预览和实时管道分析。我为什么要发布我在寻找“HN压力测试”。使用LangGraph的代理方法是否适合扩展到每月超过1万次的互动，还是应该考虑更自定义的状态机？查看一下：Babuger.com

查看原文

The Reality: They didn't. But the tech is real. I’ve been building an AI SDR platform and I wanted to share the stack with the HN crowd.The Project: Babuger Babuger automates the entire outbound/inbound lifecycle. It trains on your best rep's scripts to qualify leads, handle objections, and book meetings 24/7.The Problem: Traditional SDR teams are expensive ($150k/yr), have high turnover, and ignore "dead" leads.The Solution: One human orchestrator managing 20+ specialized AI agents.The Result: 90% task automation and 70% response rates on neglected pipelines.The Tech Stack I kept it modern and modular to handle complex multi-step reasoning:Agent Orchestration: LangGraph. This was crucial for handling non-linear conversation flows (loops, conditional routing, and state management) that standard DAGs can't touch.LLM Framework: LangChain. Used for prompt templating, output parsing, and integrating various toolsets (Gmail/Cal.com/HubSpot).Frontend: Next.js. Managed the dashboard, live email thread previews, and real-time pipeline analytics.Why I’m Posting I’m looking for the "HN stress test." Is the agentic approach with LangGraph the right move for scaling to 10k+ interactions/mo, or should I be looking at a more custom state machine?Check it out: Babuger.com

展示HN：OpenAI要以10亿美元收购Babuger.com？（开个玩笑，我是它的创始人）