1. 项目概述：当新闻阅读遇上智能体

如果你和我一样，每天被海量的新闻资讯淹没，却又苦于找不到真正有价值、符合自己兴趣的深度内容，那么“eugeneyan/news-agents”这个项目可能会让你眼前一亮。这不仅仅是一个简单的新闻聚合器，而是一个基于智能体（Agent）架构的自动化新闻处理与分发系统。它的核心思想是，让多个具备不同“专长”的AI智能体协同工作，像一支专业的编辑团队一样，自动完成从发现、筛选、总结到个性化推送的全流程。

简单来说，它试图解决一个我们每天都在面对的问题：信息过载与信息茧房。传统的RSS或算法推荐，要么过于被动，要么容易陷入同质化。而news-agents项目通过引入大语言模型（LLM）驱动的智能体，让新闻消费从“被动接收”转向“主动管理”。你可以把它想象成一位不知疲倦、精通多国语言、且深刻理解你偏好的私人新闻助理。它不仅能帮你抓取全球各地的新闻源，还能理解新闻内容，进行跨语言摘要、情感分析、事件关联，甚至根据你的历史阅读记录，预测哪些内容你更可能感兴趣。

这个项目非常适合有一定技术背景，对新闻消费有更高要求，并且希望探索AI智能体实际应用的开发者、数据科学家或是科技爱好者。它提供了一个绝佳的、开箱即用的案例，来学习如何将多个LLM智能体编排成一个高效的工作流。接下来，我将深入拆解这个项目的设计思路、技术实现，并分享在部署和定制过程中可能遇到的“坑”以及我的实战经验。

2. 核心架构与智能体分工解析

news-agents项目的精髓在于其多智能体协作的架构设计。它没有采用一个“全能”的巨型模型来处理所有任务，而是将新闻处理流程拆解成多个子任务，并为每个子任务设计了一个专门的智能体。这种“分而治之”的思路，不仅让每个智能体的职责更清晰、效果更优，也提升了整个系统的可维护性和扩展性。

2.1 智能体角色分工详解

整个系统通常包含以下几类核心智能体，它们像流水线上的工人，各司其职：

1. 采集智能体（Fetcher Agent） ：这是系统的“触角”。它的职责是定期从预设的新闻源（如各大媒体网站的RSS、API，或特定网页）抓取原始文章。它的技术核心在于稳定、高效的网络请求与HTML解析。为了避免对目标网站造成压力，以及应对反爬机制，这个智能体需要实现礼貌的爬虫策略，如设置合理的请求间隔、使用轮换的User-Agent、处理JavaScript渲染的页面（可能需搭配无头浏览器）等。在news-agents的上下文中，它产出的是一份包含标题、链接、原始正文、发布时间等元数据的结构化列表。

2. 过滤与分类智能体（Filter/Classifier Agent） ：这是第一道“质量关”。并非所有抓取到的文章都值得进一步处理。这个智能体利用LLM的理解能力，对文章进行快速初筛。例如，它可以：

   • 去重 ：判断是否与已处理文章高度相似。
   • 相关性过滤 ：根据用户或系统设定的主题关键词（如“人工智能”、“宏观经济”），过滤掉完全不相关的文章。
   • 质量初筛 ：剔除内容过短、疑似广告或低质量的页面。
   • 基础分类 ：为文章打上初步的类别标签（如科技、财经、体育）。 这个环节极大地减少了后续环节的计算开销，是保证系统效率的关键。

3. 总结与摘要智能体（Summarizer Agent） ：这是系统的“翻译官”和“提炼者”。它的任务是将一篇可能长达几千字的文章，浓缩成一段保留核心事实、关键数据和结论的简短摘要。这里的技术挑战在于如何让LLM生成 忠实于原文、无信息失真、且流畅可读 的摘要。通常需要设计精细的提示词（Prompt），例如：“请基于以下文章，生成一段不超过150字的中文摘要，需包含事件主体、核心进展和可能的影响。避免添加原文中没有的意见或推测。”

4. 情感与观点分析智能体（Sentiment/ Perspective Analysis Agent） ：这个智能体为新闻添加了一层“色彩”分析。它试图判断一篇文章的整体情感倾向（积极、消极、中性），或者分析其在某个争议话题上的立场。这对于希望了解舆论风向的用户尤其有用。实现上，这通常是一个文本分类任务，可以直接使用LLM进行零样本或少样本分类，也可以微调一个更小、更专的模型。提示词可能是：“请判断这篇文章对‘电动汽车行业发展’的整体叙述基调是支持、质疑还是中立。仅输出一个分类标签。”

5. 个性化推荐智能体（Personalization Agent） ：这是面向用户的“贴心管家”。它根据用户显式（如订阅的标签）和隐式（如阅读历史、点击、停留时间）的行为数据，为用户排序和推荐新闻。其核心是一个推荐系统，可以相对简单（如基于内容标签的余弦相似度匹配），也可以复杂（如引入嵌入向量和协同过滤）。LLM在这里可以发挥的作用是，更深度地理解用户历史阅读内容之间的语义关联，从而做出更精准的推荐。

6. 编排智能体（Orchestrator Agent） ：它是整个系统的“大脑”或“调度中心”。它不直接处理新闻内容，而是负责任务流的调度与智能体间的协同。它决定何时触发采集任务，如何将一篇原始文章依次传递给过滤、总结、分析等智能体，并处理可能出现的错误或重试。这个智能体通常由一个工作流引擎（如Apache Airflow, Prefect）或专门的编排框架（如LangGraph, CrewAI）来实现。

注意 ：在实际部署中，并非所有智能体都必须启用。你可以根据需求组合。例如，一个最小可行系统可能只包含 采集 -> 总结 -> 推送 这三个智能体。

2.2 技术栈选型背后的逻辑

news-agents项目通常展现为一个技术栈的组合拳，每一部分的选择都有其考量：

• LLM 提供商（OpenAI GPT, Anthropic Claude, 开源模型如 Llama/Mistral） ：这是智能体的“心脏”。选择闭源API（如GPT-4）意味着强大的性能、简单的集成，但会产生持续成本且依赖网络。选择本地部署的开源模型（通过Ollama, vLLM等），则更注重数据隐私和成本控制，但对硬件有要求，且效果可能稍逊。 我的经验是，对于总结、分析这类核心任务，初期建议使用效果稳定的闭源API快速验证；对于过滤、分类等相对简单的任务，可以尝试轻量级开源模型以降低成本。

• 智能体框架（LangChain, LlamaIndex, CrewAI） ：这些框架提供了构建智能体所需的“乐高积木”，如便捷的LLM调用、记忆管理、工具使用等。LangChain生态丰富但有时抽象较重；LlamaIndex对检索增强生成（RAG）场景更友好；CrewAI则更专注于多智能体协作的编排。 选择哪一个，取决于你对框架复杂度的容忍度和团队熟悉度。 news-agents这类项目是学习这些框架的绝佳场景。

• 数据存储与向量数据库（PostgreSQL, SQLite, Chroma, Pinecone） ：需要存储文章元数据、用户数据、处理日志等结构化信息（用SQL数据库）。同时，为了做语义搜索和推荐，需要将文章摘要或内容转换为向量（嵌入），并存储到向量数据库中进行相似度检索。 对于个人或小规模使用，SQLite + Chroma（本地）是轻量且免费的选择。对于生产环境，PostgreSQL + pgvector（插件）或专业的向量数据库（如Weaviate）更合适。

• 任务队列与编排（Celery + Redis, Apache Airflow, Prefect） ：新闻处理是典型的异步、定时任务。Celery是一个分布式任务队列，非常适合处理“采集一篇篇文章”这类离散任务。Airflow或Prefect则擅长管理有复杂依赖关系的DAG（有向无环图），例如“等所有文章采集完，再批量进行总结”。 简单流水线用Celery足矣，复杂工作流建议上Airflow。

• 前端与通知（Web Dashboard, Email, Slack Bot） ：最终需要将处理好的新闻呈现给用户。可以是一个简单的Web界面，也可以直接通过邮件、Slack、Telegram等渠道推送每日摘要。 从最小阻力原则出发，先实现邮件或Slack推送，快速获得反馈，再考虑开发完整的Web应用。

3. 从零搭建：关键步骤与实操细节

假设我们现在要从头开始，搭建一个简化版的news-agents系统。我会以Python生态为例，分享具体的操作步骤和配置要点。

3.1 环境准备与依赖安装

首先，创建一个干净的Python虚拟环境，这是避免依赖冲突的最佳实践。

# 创建并激活虚拟环境
python -m venv venv
source venv/bin/activate  # Linux/macOS
# venv\Scripts\activate  # Windows

# 安装核心依赖
pip install langchain langchain-openai  # 智能体框架和OpenAI集成
pip install requests beautifulsoup4 feedparser  # 网络采集和解析
pip install sqlalchemy psycopg2-binary  # 数据库操作（以PostgreSQL为例）
pip install chromadb  # 向量数据库
pip install celery redis  # 任务队列
pip install python-dotenv  # 管理环境变量

接下来，准备你的配置文件（如 .env 文件），存放敏感信息和配置：

# .env
OPENAI_API_KEY=sk-your-openai-api-key-here
DATABASE_URL=postgresql://user:password@localhost/newsdb
REDIS_URL=redis://localhost:6379/0

3.2 构建采集智能体（Fetcher）

我们从一个简单的RSS采集器开始。创建一个 fetcher.py ：

import feedparser
import requests
from bs4 import BeautifulSoup
from langchain_core.messages import HumanMessage
from langchain_openai import ChatOpenAI
import hashlib
from datetime import datetime
from sqlalchemy import create_engine, Column, String, DateTime, Text
from sqlalchemy.ext.declarative import declarative_base
from sqlalchemy.orm import sessionmaker
import os
from dotenv import load_dotenv

load_dotenv()

Base = declarative_base()

class Article(Base):
    __tablename__ = 'articles'
    id = Column(String, primary_key=True)  # 使用URL的MD5作为ID
    url = Column(String, unique=True, nullable=False)
    title = Column(String)
    raw_content = Column(Text)
    summary = Column(Text)
    published_at = Column(DateTime)
    source = Column(String)
    fetched_at = Column(DateTime, default=datetime.utcnow)

# 初始化数据库
engine = create_engine(os.getenv('DATABASE_URL'))
Base.metadata.create_all(engine)
Session = sessionmaker(bind=engine)

def fetch_article_content(url):
    """从URL获取文章正文，处理反爬和JS渲染（简化版）"""
    headers = {'User-Agent': 'Mozilla/5.0 (News-Agent Bot)'}
    try:
        resp = requests.get(url, headers=headers, timeout=10)
        resp.raise_for_status()
        soup = BeautifulSoup(resp.text, 'html.parser')
        # 简单的正文提取：通常正文在<article>或<p>标签中
        # 这里需要根据目标网站结构调整，可考虑使用readability-lxml等库
        article_tag = soup.find('article') or soup.find('div', class_=lambda x: x and 'content' in x)
        if article_tag:
            text = article_tag.get_text(strip=True, separator=' ')
        else:
            # 备选方案：获取所有段落文本
            text = ' '.join([p.get_text() for p in soup.find_all('p')])
        return text[:10000]  # 限制长度
    except Exception as e:
        print(f"Error fetching {url}: {e}")
        return None

def fetcher_agent(rss_feed_url, source_name):
    """采集智能体主函数"""
    session = Session()
    print(f"Fetching from {rss_feed_url}")
    feed = feedparser.parse(rss_feed_url)
    new_articles = 0

    for entry in feed.entries[:10]:  # 每次取最新10条
        url = entry.link
        article_id = hashlib.md5(url.encode()).hexdigest()

        # 检查是否已存在
        if session.query(Article).filter_by(id=article_id).first():
            continue

        title = entry.title
        published = entry.get('published_parsed')
        published_at = datetime(*published[:6]) if published else datetime.utcnow()

        # 获取正文
        raw_content = fetch_article_content(url)
        if not raw_content:
            continue

        # 存入数据库
        article = Article(
            id=article_id,
            url=url,
            title=title,
            raw_content=raw_content,
            published_at=published_at,
            source=source_name
        )
        session.add(article)
        new_articles += 1

    session.commit()
    session.close()
    print(f"Fetched {new_articles} new articles from {source_name}")
    return new_articles

# 示例：运行采集
if __name__ == '__main__':
    # 可以配置多个RSS源
    feeds = [
        ('https://rss.example.com/tech', 'TechNews'),
        ('https://rss.example.com/finance', 'FinanceNews')
    ]
    for feed_url, source in feeds:
        fetcher_agent(feed_url, source)

实操要点 ：

• 去重策略 ：使用URL的MD5哈希作为主键是最简单有效的方法。更高级的可以去重相似内容，这需要用到后续的嵌入向量和相似度计算。
• 正文提取 ： BeautifulSoup 的简单规则很难应对所有网站。生产环境中，可以考虑使用 readability-lxml 、 newspaper3k 或专门训练的机器学习模型来提升正文提取的准确率。
• 礼貌爬虫 ：务必设置 User-Agent 标识自己是Bot，并在循环中添加 time.sleep() 避免请求过快。

3.3 构建总结智能体（Summarizer）

总结智能体是LLM能力的直接体现。我们使用LangChain来构建一个稳定的总结链。创建 summarizer.py ：

from langchain.prompts import ChatPromptTemplate
from langchain_openai import ChatOpenAI
from sqlalchemy.orm import Session
from .models import Article, engine  # 假设模型在另一个文件
from langchain_core.output_parsers import StrOutputParser
import os

# 初始化LLM
llm = ChatOpenAI(
    model="gpt-3.5-turbo",  # 对于总结任务，gpt-3.5-turbo通常性价比很高
    temperature=0.2,  # 低温度保证摘要的稳定性和事实性
    api_key=os.getenv('OPENAI_API_KEY')
)

# 定义提示词模板
summary_prompt = ChatPromptTemplate.from_messages([
    ("system", "你是一个专业的新闻编辑，擅长生成简洁、准确、客观的新闻摘要。"),
    ("human", """
请根据以下新闻文章，生成一段中文摘要。

要求：
1. 长度严格控制在100-150字之间。
2. 摘要必须包含：事件的核心主体、发生的关键事实或数据、以及事件的主要结果或影响。
3. 完全基于原文信息，不要添加任何原文中没有的推测、评价或个人观点。
4. 语言流畅，逻辑清晰。

新闻标题：{title}
新闻正文：{content}

现在，请生成摘要：
""")
])

# 构建总结链
summary_chain = summary_prompt | llm | StrOutputParser()

def summarizer_agent(article_id):
    """总结智能体：处理单篇文章"""
    session = Session(bind=engine)
    article = session.query(Article).filter_by(id=article_id, summary=None).first()
    if not article:
        session.close()
        return None

    print(f"Summarizing: {article.title}")

    try:
        # 调用LLM生成摘要
        # 注意：如果文章过长，需要先进行截断或分段处理
        content_preview = article.raw_content[:3000]  # 限制输入长度，控制token消耗
        summary = summary_chain.invoke({
            "title": article.title,
            "content": content_preview
        })

        # 更新数据库
        article.summary = summary
        session.commit()
        print(f"Summary generated for {article.id}")
        return summary
    except Exception as e:
        print(f"Error summarizing article {article.id}: {e}")
        session.rollback()
        return None
    finally:
        session.close()

# 批处理总结
def batch_summarize(limit=10):
    """批量处理未总结的文章"""
    session = Session(bind=engine)
    pending_articles = session.query(Article).filter_by(summary=None).limit(limit).all()
    session.close()

    for article in pending_articles:
        summarizer_agent(article.id)

注意事项 ：

• Token与成本 ：LLM API按Token收费。长文章需要截断。一个策略是先提取文章的前N个字符和最后M个字符（通常结论在文末），或者先用更简单的方法（如提取TF-IDF高的句子）生成一个草稿，再让LLM润色。
• 提示词工程 ：提示词的质量直接决定摘要的效果。明确要求“不添加个人观点”、“基于原文”可以减少LLM的“幻觉”。多次迭代优化你的提示词。
• 错误处理 ：网络超时、API限额、内容违规等都可能导致调用失败。必须要有重试机制和异常捕获，并将失败记录日志，以便后续排查。

3.4 引入向量数据库与个性化推荐雏形

为了让系统能“记住”内容并进行语义搜索，我们需要将文章摘要向量化并存储。这里使用ChromaDB。创建 vector_store.py ：

import chromadb
from chromadb.config import Settings
from langchain_openai import OpenAIEmbeddings
from sqlalchemy.orm import Session
from .models import Article, engine
import os

# 初始化嵌入模型和向量数据库客户端
embeddings = OpenAIEmbeddings(model="text-embedding-3-small", api_key=os.getenv('OPENAI_API_KEY'))
chroma_client = chromadb.PersistentClient(path="./chroma_db")  # 数据持久化到本地目录
collection = chroma_client.get_or_create_collection(name="news_articles")

def add_article_to_vector_store(article_id):
    """将单篇文章的摘要存入向量数据库"""
    session = Session(bind=engine)
    article = session.query(Article).filter_by(id=article_id).first()
    session.close()

    if not article or not article.summary:
        return

    # 生成摘要的向量
    # 注意：这里直接使用摘要文本。对于更精准的检索，可以结合标题和关键字段。
    embedding = embeddings.embed_query(article.summary)

    # 存入Chroma
    collection.add(
        embeddings=[embedding],
        documents=[article.summary],
        metadatas=[{
            "id": article.id,
            "title": article.title,
            "source": article.source,
            "url": article.url,
            "published_at": article.published_at.isoformat() if article.published_at else None
        }],
        ids=[article.id]
    )
    print(f"Article {article.id} added to vector store.")

def find_similar_articles(query_text, n_results=5):
    """语义搜索：找到与查询最相关的文章"""
    query_embedding = embeddings.embed_query(query_text)
    results = collection.query(
        query_embeddings=[query_embedding],
        n_results=n_results
    )
    return results  # 返回IDs, 距离，元数据等

# 在总结完成后，调用该函数将文章向量化
# 可以在 `summarizer_agent` 函数成功生成摘要后，紧接着调用 `add_article_to_vector_store(article_id)`

有了向量存储，一个最简单的“个性化推荐”就可以实现了：将用户最近阅读过的几篇文章的摘要向量取平均，得到一个“用户兴趣向量”，然后用这个向量去向量数据库里搜索最相近的、用户未读过的文章。这就是一个基于内容的推荐系统雏形。

3.5 使用Celery编排任务流

最后，我们用Celery把各个智能体串联起来，实现自动化。创建 tasks.py 和 celery_app.py 。

# celery_app.py
from celery import Celery
import os
from dotenv import load_dotenv

load_dotenv()

celery_app = Celery(
    'news_agents',
    broker=os.getenv('REDIS_URL', 'redis://localhost:6379/0'),
    backend=os.getenv('REDIS_URL', 'redis://localhost:6379/0')
)

# 配置
celery_app.conf.update(
    task_serializer='json',
    accept_content=['json'],
    result_serializer='json',
    timezone='UTC',
    enable_utc=True,
)

# tasks.py
from .celery_app import celery_app
from .fetcher import fetcher_agent
from .summarizer import batch_summarize, add_article_to_vector_store
from .models import Session, Article

@celery_app.task
def fetch_all_feeds_task():
    """定时采集任务"""
    feeds = [
        ('https://rss.example.com/tech', 'TechNews'),
        ('https://rss.example.com/finance', 'FinanceNews')
    ]
    total_new = 0
    for feed_url, source in feeds:
        new_count = fetcher_agent(feed_url, source)
        total_new += new_count
    return total_new

@celery_app.task
def process_new_articles_task():
    """处理新文章：总结并向量化"""
    session = Session()
    # 找出已采集但未总结的文章
    new_articles = session.query(Article).filter_by(summary=None).all()
    session.close()

    for article in new_articles:
        # 这里可以更精细地拆分成两个独立任务：summarize_task 和 vectorize_task
        # 并使用链式（chain）或组（group）来编排
        summary = summarizer_agent(article.id)
        if summary:
            add_article_to_vector_store(article.id)
    return len(new_articles)

# 启动Celery Worker: celery -A tasks.celery_app worker --loglevel=info
# 启动Beat调度器: celery -A tasks.celery_app beat --loglevel=info

然后，配置Celery Beat（定时任务）在 celery_app.py 中：

from celery.schedules import crontab

celery_app.conf.beat_schedule = {
    'fetch-news-every-hour': {
        'task': 'tasks.fetch_all_feeds_task',
        'schedule': crontab(minute=0, hour='*/1'),  # 每小时执行一次
    },
    'process-articles-every-30min': {
        'task': 'tasks.process_new_articles_task',
        'schedule': crontab(minute='*/30'),
    },
}

现在，启动Redis服务、Celery Worker和Beat调度器，你的自动化新闻智能体系统就开始运行了。

4. 部署、优化与避坑指南

将原型部署到生产环境，并让它稳定、高效地运行，会遇到一系列挑战。以下是我在实践中总结的关键点和避坑经验。

4.1 部署架构考量

对于个人使用，一台配置不错的云服务器（如2核4G）就足够了。将所有组件（PostgreSQL, Redis, Python应用）部署在同一台机器上。使用 systemd 或 supervisor 来管理Celery Worker和Beat进程的守护，确保它们意外退出后能自动重启。

对于更高要求或团队使用，建议采用容器化部署（Docker + Docker Compose）。这能带来环境一致性和易于扩展的好处。一个简单的 docker-compose.yml 可能包含以下服务： postgres , redis , web (一个提供API或前端界面的FastAPI/Flask应用), celery_worker , celery_beat 。

关键配置 ：

• 数据库连接池 ：确保SQLAlchemy或你的ORM配置了合适的连接池大小，避免数据库连接耗尽。
• Redis持久化 ：如果Redis仅用作Celery的消息代理，且任务可以容忍丢失，可以不用持久化。但如果用它存储中间状态，务必配置RDB或AOF持久化。
• 日志集中管理 ：将所有组件的日志（应用日志、Celery任务日志、系统日志）收集到同一个地方（如文件系统特定目录，或ELK栈），这是排查问题的生命线。

4.2 性能优化与成本控制

这是运营此类系统最实际的部分。

1. LLM API调用优化 ：

   • 缓存 ：对相同的输入内容（如完全相同的文章正文）进行摘要，结果应该是一样的。可以在调用LLM前，先计算内容的哈希值，查询缓存数据库（如Redis）。如果已有摘要，直接使用，避免重复调用和付费。
   • 批量处理 ：OpenAI等API支持批量请求（虽然news-agents场景下单条摘要更常见）。对于分类、情感分析等任务，可以将多篇文章组合在一个请求中，减少网络开销。
   • 模型选型 ：摘要任务不一定需要最强大的模型。 gpt-3.5-turbo 在大多数情况下效果足够好且成本仅为 gpt-4 的几十分之一。可以先用小模型跑，对效果不满意的文章再尝试用大模型重试。
   • Token限制 ：严格截断输入。一篇5000字的文章，可能只有前1000字包含了核心信息。设计一个“智能截断”函数，优先保留开头、结尾和包含高频关键词的段落。

2. 异步与并发 ：

   • Celery本身支持并发执行任务。合理设置Worker的并发数（ celery -A app worker --concurrency=10 ）。注意，并发数过高可能导致数据库连接数暴涨或API速率限制。
   • 对于IO密集型的网络请求（如采集）和CPU密集型的计算（如文本处理），可以考虑部署不同类型的Worker，分别处理不同类型的任务队列。

3. 数据库优化 ：

   • 为 articles 表的 summary 、 published_at 、 source 字段建立索引，加速查询。
   • 定期归档或删除非常旧的、无人问津的文章数据，保持主表轻量。

4.3 常见问题与排查技巧

在运行过程中，你几乎一定会遇到以下问题：

问题1：LLM生成摘要时出现“幻觉”，添加了原文没有的信息。

• 排查 ：检查提示词。是否明确要求了“严格基于原文”？尝试在提示词中加入“如果无法从原文确定，请输出‘信息不足’”的指令。
• 解决 ：在提示词中提供更严格的示例（Few-shot Learning）。例如，先给一个原文片段和一个好的摘要示例，再给一个坏的（有幻觉的）摘要示例，并解释为什么坏。让LLM学习你期望的格式和边界。

问题2：采集器被目标网站屏蔽。

• 排查 ：查看日志中是否有403、429状态码，或返回了验证码页面。
• 解决 ：
  • 降低请求频率，增加随机延迟。
  • 轮换User-Agent字符串池。
  • 使用住宅代理IP池（需注意合规成本）。
  • 考虑使用官方API或RSS源，这是最友好且稳定的方式。

问题3：向量搜索返回的结果不相关。

• 排查 ：检查用于生成向量的文本质量。如果用全文生成向量，噪声太大。如果用标题，信息可能不足。
• 解决 ：
  • 优化检索文本 ：尝试用“标题 + 摘要前100字”的组合来生成向量，效果通常比单一字段好。
  • 调整检索方式 ：ChromaDB支持多种距离函数（L2，余弦，内积）。对于文本嵌入，余弦相似度通常是默认且效果较好的选择。
  • 重排序（Re-ranking） ：先通过向量搜索召回一批候选文章（比如50篇），然后用一个更轻量、更精准的模型（如交叉编码器）对这50篇进行精排，选出最相关的5篇。这是提升检索质量的高级技巧。

问题4：Celery任务堆积，处理不过来。

• 排查 ：使用 celery -A app inspect active 或 celery -A app inspect reserved 查看任务状态。监控队列长度。
• 解决 ：
  • 增加Worker数量或并发度。
  • 分析任务瓶颈。如果是LLM API调用慢，考虑对任务设置更长的超时时间，并实现指数退避的重试机制。
  • 将大任务拆分成小任务。例如， process_new_articles_task 可以拆成 summarize_article_task 和 vectorize_article_task ，每个任务处理一篇文章，实现更细粒度的并行。

问题5：系统运行一段时间后，数据库或向量库性能下降。

• 排查 ：检查慢查询日志。对于向量数据库，当数据量超过百万级别后，扁平索引（默认）的搜索速度会变慢。
• 解决 ：
  • 对关系数据库，定期执行 VACUUM 和 ANALYZE （PostgreSQL）。
  • 对向量数据库，当数据量较大时（如超过10万条），考虑使用近似最近邻（ANN）索引，如HNSW。ChromaDB默认支持HNSW，但需要在创建集合时指定。

5. 扩展思路与高级玩法

一个基础的系统搭建完成后，你可以从以下几个方向进行深化和扩展，让它变得更强大、更智能：

1. 多模态智能体 ：不仅处理文本新闻，还可以引入处理图片、视频的智能体。例如，一个“图片理解智能体”可以描述新闻配图的内容；一个“视频摘要智能体”可以提取视频的关键帧和字幕进行总结。这需要集成多模态大模型（如GPT-4V, Claude 3）。

2. 事件追踪与脉络分析 ：让智能体不仅看单篇新闻，还能关联不同时间、不同来源的报道，梳理出一个事件的完整发展脉络。这需要更复杂的信息抽取和知识图谱技术。智能体可以识别文章中的命名实体（人物、组织、地点）和事件，并将它们关联起来，生成时间线。

3. 观点聚合与辩论可视化 ：对于有争议的话题，系统可以自动爬取正反双方的报道和评论，由智能体归纳出核心论点、论据，并以可视化的方式（如论点地图）呈现出来，帮助用户更全面地理解争议。

4. 深度分析与报告生成 ：每周或每月，系统可以自动生成一份领域简报。智能体被赋予“行业分析师”的角色，基于过去一段时间内的所有相关新闻，撰写一份包含趋势分析、重点事件回顾和未来展望的简短报告。

5. 自适应学习与反馈循环 ：引入用户反馈机制。当用户点击“不感兴趣”或“喜欢”时，这个信号应该能实时地反馈给个性化推荐智能体，调整其推荐策略。甚至可以训练一个强化学习智能体，以用户的长期阅读满意度为奖励，不断优化整个新闻筛选和分发的策略。

构建news-agents系统的过程，本质上是在打造一个高度自动化的、由AI驱动的信息处理中枢。它考验的不仅是编码能力，更是对业务逻辑的拆解、对AI能力的合理运用以及对系统稳定性的把控。从最简单的RSS摘要机器人开始，逐步添加新的智能体模块，你会发现，让机器理解并组织人类世界的信息，是一个充满挑战但也极具成就感的旅程。