灵感来自知乎“直答 Agent”

今年年初，知乎开放了他们的直答 Agent API。

说白了就一件事：你提一个问题，它自动去搜索引擎搜、读网页内容、整合分析、给你一个带来源引用的回答。不需要自己搭知识库，不需要折腾 RAG 管线——搜索引擎就是你的"数据库"。各大引擎的 API Key 一配就能跑。

它提供了三档模式，挺聪明：

I当时就在想这方面，这就是个搜索类 Agent 啊。话说回来，

LangChain 学了点、LangGraph 翻了三天文档没看懂、Agent 概念模模糊糊。但你让我直接上手写一个，好像可以。因为搜索类 Agent 有个天然优势——数据不用操心。

不做知识库就不需要处理文档切分和 Embedding 质量；按理说，不做 RAG 就不需要调 chunk size 和检索策略；不微调模型就不需要准备数据集。数据全在搜索引擎里你要做的就是：搜 → 读 → 分析 → 回答。链路清晰得跟流水线一样，

对于想学 AI Agent 的新手这是个绝佳的切入点——API 接入简单、链路可见、效果马上见效。于是我就动手了，其实，

说到背景。AI 把岗位卷没了我选择主动拥抱它

一、TruthSeeker 到底做什么？

四个档位，丰俭由人

二、技术选型的酸甜苦辣

整体架构

|Next.js| Frontend
Frontend -->|API / SSE| Backend
Backend --> PG
Backend --> Redis
Worker --> Redis
Worker --> PG
Worker --> Search
Worker --> LLM

FastAPI vs Django：选轻的。别选全的

LangGraph vs 纯 LangChain：状态机才是正道

• 至于学习曲线陡峭，从 React 到 Python，再到 LangGraph 的状态机概念，一步一步摸索，需要大量时间投入。
• 至于成本压力大。LLM 调用费用高昂，一次深度研究可能耗费数块钱；预算为零迫使必须精打细算。
• 从数据安全顾虑来看。使用者 API Key 存储与加密、防篡改措施必须到位，否则泄露后果严重。说起来，
• 并发与性能瓶颈：单 worker 的 CPU 占用过高导致响应慢。需要 Semaphore 控制并发。
• 断线重连体验差异化难题：SSE 与 Redis Stream 的结合实现仍需调整，以保证断线后完整恢复状态。
• 部署运维难度大：单机 Docker Compose 无健康检查和滚动更新，在真实环境下易失效。
• 插件程序缺乏 A/B 对比评测，导致无法判断不同搜索引擎质量差异。
• SSEResponse Parser 固化为 if‑else。升级 LangGraph 时可能破坏兼容性，需要更灵活配置方案。
• 日志脱敏不足。多租户未启用 PostgreSQL 原生 Row‑Level Security，潜在跨租户泄露风险。