1. 项目缘起与核心痛点最近在折腾一个AI热点监控的小项目初衷很简单我想让AI帮我自动追踪特定领域比如AI技术本身的每日热点然后生成一份简洁的日报推送到我的飞书或者钉钉。听起来是个典型的Agent应用场景对吧用大模型理解网页内容提取关键信息总结归纳然后定时推送。我一开始也是这么想的撸起袖子就干用上了时下最火的Agent框架心想这不就是让AI自己上网、思考、然后告诉我结果嘛。但项目跑起来没多久我就被现实狠狠教育了。最初的架构非常“经典”一个调度器Cron定时触发调用一个封装好的AI Agent。这个Agent的工作流是访问预设的几个资讯网站和社区抓取内容让大模型分析哪些是“热点”提炼标题、摘要和链接最后组装成消息发送出去。我满心期待地设置了每两小时运行一次结果第一天就出了大问题。我发现Agent经常把几个小时前甚至昨天已经处理过的旧闻又当成新热点提出来。更头疼的是对于同一个持续发酵的事件Agent每次生成的摘要角度都飘忽不定缺乏连续性我根本无法从这些零散的记录里看出事件发展的脉络。这时我才恍然大悟Agent不能只靠聊天记录或者说单次会话的上下文来工作。在需要持续追踪、状态维护和基于历史决策的场景里那个每次被Cron唤醒、干完活就失忆的“一次性”Agent是完全不够用的。它缺少一个持久化的“记忆体”和“工作台”。这个认知成了我重构整个项目的转折点。2. 架构演进从“失忆特工”到“有记忆的助手”最初的架构我称之为“失忆特工”模式。每次Cron触发都像是召唤了一个全新的特工它没有之前的任何任务记忆只能根据我预设的指令提示词重新开始搜集、判断、汇报。这种模式存在几个致命缺陷2.1 无法去重Agent没有记忆所以每次看到相同的或高度相似的资讯它都会当作新发现来处理。这不仅产生了大量垃圾信息也浪费了API调用次数都是钱啊。2.2 缺乏状态跟踪对于一个热点事件它可能经历“爆发 - 热议 - 官方回应 - 逐渐平息”等多个阶段。一个优秀的监控系统应该能识别出这是同一个事件并记录其状态变迁。但“失忆特工”每次提交的报告都是孤立的快照无法串联。2.3 决策缺乏历史依据比如Agent可能会学习到某个信源的质量不高经常发布标题党内容。在人类工作中我们会下意识地降低对该信源的关注度。但“失忆特工”没有这个学习能力下次依然会平等地对待所有信源。为了解决这些问题我必须给Agent配备一个持久化的“大脑”。这个大脑需要负责记忆存储记住它看到过的每一条资讯。状态管理记录热点事件的生命周期。知识积累存储从历史数据中提炼出的经验如信源权重。技术选型上重型的关系型数据库如MySQL/PostgreSQL对于这个个人小项目来说有点杀鸡用牛刀而简单的文件存储如JSON在频繁读写和复杂查询时会变得笨拙。因此我选择了SQLite。它零配置、单文件、支持完整的SQL完美契合个人项目或轻量级服务对嵌入式数据库的需求。它就是这个Agent的“长期记忆中枢”。3. 核心组件设计与实现我的项目最终形成了以SQLite为核心协同多个组件的架构。整个系统围绕着数据库中的几张核心表运转。3.1 数据层设计SQLite表结构剖析数据库是整个系统的基石设计好坏直接决定了Agent的“智商”。我主要设计了以下几张表-- 资讯原始记录表存储爬虫抓取到的原始内容 CREATE TABLE raw_articles ( id INTEGER PRIMARY KEY AUTOINCREMENT, url TEXT UNIQUE NOT NULL, -- 链接作为唯一标识用于去重 title TEXT, content TEXT, -- 可能是全文或摘要 source TEXT, -- 信源名称 fetch_time DATETIME DEFAULT (datetime(now, localtime)), processed BOOLEAN DEFAULT 0 -- 是否已被处理 ); -- 热点事件表将多条资讯聚合为一个持续追踪的事件 CREATE TABLE hot_events ( id INTEGER PRIMARY KEY AUTOINCREMENT, event_key TEXT UNIQUE NOT NULL, -- 事件唯一标识可由核心关键词哈希生成 summary TEXT, -- 由AI生成的当前事件摘要 status TEXT DEFAULT tracking, -- 状态tracking, rising, peak, fading, archived first_seen DATETIME, last_updated DATETIME, article_count INTEGER DEFAULT 1 -- 关联的资讯数量 ); -- 事件-资讯关联表多对多关系记录哪些资讯属于哪个事件 CREATE TABLE event_article_relation ( event_id INTEGER, article_id INTEGER, FOREIGN KEY (event_id) REFERENCES hot_events(id), FOREIGN KEY (article_id) REFERENCES raw_articles(id), PRIMARY KEY (event_id, article_id) ); -- 信源质量表让Agent学会“挑食” CREATE TABLE source_credibility ( source TEXT PRIMARY KEY, score REAL DEFAULT 1.0, -- 可信度分数初始为1.0 last_checked DATETIME );提示event_key的生成是关键。我实践下来的有效方法是用大模型或简单的NLP库从资讯标题和内容中提取出核心实体如“GPT-5”、“Sora”、“某某公司”然后排序、拼接、再取哈希。这能保证同一事件在不同时间、不同信源下能被关联起来。3.2 智能调度中心Cron表达式的精准控制定时任务是系统的脉搏。我使用apscheduler库Python环境来管理Cron任务。监控不同阶段的事件需要不同的扫描频率。from apscheduler.schedulers.background import BackgroundScheduler scheduler BackgroundScheduler() # 高频扫描针对状态为 rising上升期的热点每30分钟检查一次是否有新进展 scheduler.add_job(check_rising_events, cron, minute*/30) # 中频扫描常规全网爬取每2小时一次发现潜在新热点 scheduler.add_job(routine_crawl, cron, hour*/2) # 低频扫描每天凌晨1点清理陈旧数据更新信源评分 scheduler.add_job(daily_maintenance, cron, hour1) # 日报生成每天上午9点汇总前一天的热点生成报告 scheduler.add_job(generate_daily_report, cron, hour9, minute0) scheduler.start()注意Cron任务千万不要设置得太密集尤其是涉及AI API调用的任务。一方面避免给目标网站造成压力另一方面也是控制成本。对于状态稳定的fading消退中事件我甚至会将其检查频率降低到一天一次。3.3 Agent大脑升级从单次提示到工作流引擎这是改造的核心。Agent不再是一个简单的“提示词API调用”。它变成了一个与数据库紧密交互的工作流引擎。我以一次常规扫描任务为例拆解其工作流数据获取与去重爬虫将新抓取的资讯插入raw_articles表。利用url的唯一约束数据库天然完成了去重。事件关联Agent被触发。它首先从raw_articles中取出所有processed0的新资讯。对于每一条资讯Agent调用大模型API让其判断这条资讯是否属于某个已有热点事件查询hot_events表或者需要创建新事件。这个判断的依据就是对比资讯内容与已有事件的summary和event_key。状态研判与更新当一条资讯被关联到某个事件后Agent会重新评估该事件的状态。例如如果一个事件在短时间内关联了多条高热度资讯其状态可能从tracking变为rising。这个逻辑可以基于规则如单位时间内的资讯增量也可以让大模型根据所有关联资讯的内容综合判断。信源学习每次处理资讯后会根据该资讯最终是否被判定为有效热点、以及其内容质量可简单由AI给出一个置信度分数反向更新source_credibility表。分数低的信源在未来抓取时其内容可能会被降低优先级或需要更严格的验证。生成输出对于需要报告的事件如状态刚变为rising或到达peakAgent会从event_article_relation和raw_articles中取出所有关联的最新资讯让大模型生成一份连贯的、有前因后果的综合摘要更新到hot_events.summary字段并发送通知。这个过程中Agent的每一次“思考”都基于SQLite中存储的完整历史记录从而做出了更明智、更连贯的决策。3.4 开发利器Cursor与DB Browser for SQLite在开发这个数据密集型的项目时两个工具给了我巨大帮助。Cursor作为一款AI驱动的编辑器它在编写与数据库交互的代码时尤其高效。例如当我需要编写一个复杂的SQL查询来统计每个信源过去一周产生热点的事件数时我可以在Cursor中直接描述这个需求“写一个Python函数用sqlite3连接数据库查询source_credibility表并关联raw_articles和event_article_relation计算每个信源过去七天贡献的有效热点资讯数量。” Cursor能快速生成准确的代码框架和SQL语句极大提升了开发效率。记得在设置中开启自动补全和代码建议功能。DB Browser for SQLite (DB4S)这是一个图形化的SQLite数据库管理工具。在调试阶段单纯看日志是不够的。通过DB4S我可以实时打开项目的.db文件直观地浏览表结构、执行即席SQL查询、查看数据内容甚至手动修改一些测试数据。这对于验证Agent的逻辑是否正确、数据关联是否正常至关重要。官网提供了各个平台的安装包使用起来非常直观。4. 关键实现细节与避坑指南4.1 设计稳定可靠的数据关联策略如何让AI准确判断两条资讯是否属于同一事件纯靠大模型进行两两比较成本太高。我的策略是分层过滤关键词/实体快速过滤首先利用离线NLP库如jieba分词TextRank或大模型快速提取资讯的核心关键词和实体。如果两条资讯的核心实体集合毫无重叠它们大概率不是同一事件。语义相似度计算对于通过第一层过滤的资讯使用嵌入模型如OpenAI的text-embedding-3-small计算其标题和摘要的向量并计算余弦相似度。在SQLite中可以使用vector扩展或直接将向量存储为BLOB但为了简单起见我是在内存中计算阈值设定为0.85。大模型最终裁决对于相似度在模糊区间比如0.75-0.9的资讯对再调用大模型做最终判断并让其给出理由。这个理由可以记录下来作为优化前两层规则的依据。4.2 优化提示词工程以获取结构化判断要让大模型更好地为数据库“打工”提示词必须引导它输出结构化、可解析的判断。例如在事件关联的提示词中我会这样设计你是一个AI热点分析助手。请分析以下新闻内容并与现有事件列表进行关联。 现有事件列表 [事件1] 事件ID001 当前摘要关于“某公司发布新一代AI芯片”的讨论... [事件2] 事件ID002 当前摘要关于“某框架发布重大安全更新”的讨论... 待分析新闻 标题某公司AI芯片实测性能曝光能效比提升50% 内容...略... 请严格按照以下JSON格式输出你的分析结果 { belongs_to_existing_event: true, // 是否属于现有事件 event_id: 001, // 如果属于填写事件ID否则为null confidence: 0.95, // 判断置信度 (0-1) reasoning: 该新闻直接讨论了某公司AI芯片的具体性能是事件1的后续进展。 // 简要理由 suggested_status_update: rising // 建议更新的事件状态如无需更新则为null }这样我的代码就可以直接解析JSON将结果写入数据库实现了AI判断与系统流程的无缝衔接。4.3 成本控制与容错机制这个项目一旦跑起来涉及网络请求、AI API调用、数据库操作处处都可能出错且AI调用成本不菲。设置预算与熔断为每个AI任务如事件关联、摘要生成设置独立的Token预算和月度金额上限。使用令牌桶算法进行限流。当连续出现多次网络超时或API返回错误时触发熔断机制暂停该任务一段时间并发送警报。异步与重试所有IO密集型操作网络请求、数据库批量写入均采用异步方式避免阻塞主线程。对于可重试的错误如网络抖动实现指数退避的重试逻辑。数据一致性保障SQLite在并发写入时需要小心。我采用了两个策略一是对于写操作使用with conn:上下文管理器和显式的事务二是将不同的数据更新任务如爬虫写入、Agent状态更新在时间上稍微错开减少并发冲突的概率。5. 效果对比与项目反思系统改造前后效果对比非常明显对比维度“失忆特工”模式“有记忆助手”模式信息去重完全无法去重重复报告率高基于URL和内容相似度重复率极低事件连续性报告孤立无法追踪进展能清晰展示事件从出现、发酵到平息的全过程决策质量每次判断都是“初判”容易误判基于历史信源评分、事件上下文判断更精准系统成本每次执行都是“从头开始”AI调用冗余智能调度只对新内容、状态变化内容进行深度分析成本降低输出价值零散的资讯列表结构化的热点事件追踪报告5.1 踩过的坑与心得不要过度依赖大模型做简单匹配初期我让大模型做所有的事件关联成本飙升且速度慢。后来将流程改为“规则过滤 - 向量相似度 - 大模型裁决”三层后成本降低了70%速度提升数倍。SQLite并发写入的坑在多线程环境下同时写入SQLite即使使用了WAL模式也偶尔会遇到database is locked错误。我的解决方案是引入一个简单的任务队列将所有数据库写操作序列化。热点事件的生命周期管理什么时候将一个事件标记为archived归档不能只依赖时间。我结合了多个信号关联资讯数连续N天无增长、最新关联资讯的情感倾向趋于中性、大模型综合判断事件热度已消退。这是一个需要持续调优的规则。提示词的稳定性同样的提示词不同的大模型版本如GPT-3.5与GPT-4输出格式的稳定性不同。务必在代码中做好防御性解析对不符合预期的输出要有降级处理方案例如记录日志并跳过该条而不是让整个任务崩溃。5.2 未来的优化方向目前这个系统已经能稳定运行但还有不少可以优化的地方向量数据库引入当积累的资讯数量达到万级以上在内存中计算向量相似度会成为瓶颈。考虑引入ChromaDB或Qdrant这类轻量级向量数据库专门用于高效相似性检索。更复杂的Agent协作可以将任务拆解得更细例如由一个“调度Agent”根据事件状态决定调用“分析Agent”、“总结Agent”还是“核实Agent”形成一个小型的多智能体系统。前端可视化目前报告是文本形式。可以搭建一个简单的Web面板用时间线图表直观展示热点事件的起落和关联资讯体验会更好。通过这个项目我深刻体会到一个真正有用的AI Agent尤其是涉及持续监控和状态管理的其核心能力往往不在AI模型本身而在于如何设计它的记忆、思考和工作流程。数据库不再是简单的存储而是Agent的长期记忆和思考平台调度系统不再是简单的定时触发而是Agent的节奏控制器。把这两者与AI的感知判断能力有机结合起来才能打造出真正智能、实用的自动化系统。