项目背景
Eugene Yan 是前亚马逊应用科学家，在 ML 系统和推荐系统领域有大量产出，其博客在 AI 工程圈广泛传阅。这篇文章记录了他用 MCP、Amazon Q CLI 和 tmux 搭建多 Agent 新闻日报系统的实验过程。
这不是理论探讨，而是一个实际可运行的系统，附有 GitHub 仓库和完整实现细节。
系统架构
整体采用一主多从的 Agent 编排模式：
主 Agent（Orchestrator）
- 读取
feeds.txt配置文件，其中包含六个新闻源 URL - 将六个源分成三批，每批两个
- 为每批启动一个子 Agent，在独立 tmux 窗格中运行
- 监控三个子 Agent 的完成状态
- 合并各子 Agent 的输出，生成最终综合摘要
子 Agent（Sub-agents）× 3
- 各自独立运行在一个 tmux 窗格
- 处理分配给自己的两个 RSS 源
- 解析 RSS、提取文章内容、按主题分类
- 将结果写入
summaries/目录
Amazon Q CLI
- 提供 Agent 框架层：自主决策、任务委派、工具调用、多步骤工作流管理
- 控制整个 Agent 执行循环
MCP 工具层
五个 MCP 工具覆盖不同信源：
- Hacker News — 异步 HTTP 请求 + XML 解析，提取故事 ID、标题、链接、发布时间
- TechCrunch — RSS 解析 + 内容提取
- WSJ Tech — 华尔街日报科技版 RSS
- WSJ Markets — 华尔街日报市场版 RSS
- AI News — AI 垂直领域新闻聚合 RSS
每个工具通过 MCP 的 @tool 装饰器定义，统一了工具接口——Agent 调用这些工具的方式完全一致，无论底层解析逻辑有多大差异。
tmux 的角色：可观察性的土方法
多 Agent 系统的调试难点在于可见性：当多个 Agent 并发运行时，很难知道每个 Agent 在做什么、卡在哪里。
传统方案需要引入日志系统、追踪工具（如 OpenTelemetry）或者专用的 Agent 监控框架。
这个系统的选择是 tmux：每个子 Agent 运行在一个独立窗格，实时显示输出。主 Agent 也在自己的窗格里运行，可以随时切换查看。
结果是：不需要任何额外基础设施，一个终端分屏就能实时监控所有 Agent 的执行状态。
这在 Agent 数量较少（< 10 个）的场景里具有实际价值：快、直接、零额外依赖。
测试运行结果
测试运行处理了 124 条新闻项，识别出的跨源主题分布：
| 主题 | 提及次数 |
|---|---|
| AI/机器学习行业整合 | 31 |
| 贸易政策与关税 | 12 |
| AI 安全关切 | 9 |
| 政府 AI 实施 | 7 |
输出除了各源的独立摘要，还包含跨源的趋势分析——识别多个信源共同关注的话题。
可扩展性
新增信源：在 feeds.txt 添加 URL，在 MCP 层注册对应工具。整个过程从"从头写一个 RSS 爬虫"变成"把新 URL 接入已有的工具模板"。
批次数量调整：如果要处理 12 个源，可以改为四批，每批三个，启动四个子 Agent——主 Agent 的分发逻辑不需要改变。
其他应用场景：作者提到这个多 Agent 并行模式可以迁移到设计文档解析、协作写作、分布式代码任务等场景。
局限性
作者坦诚地指出了两个主要局限：
- 远程 MCP 托管：在 Daytona 等平台上运行远程 MCP 时遇到问题，目前本地执行比分布式部署更可靠
- RSS 解析的泛化性：当前各 Feed 有专用解析逻辑，作者认为未来可以用 LLM 统一解析不同格式的 RSS，减少 feed-specific 代码
安装与使用
系统依赖 Amazon Q CLI、Python（通过 uv 管理依赖）和该 GitHub 仓库。启动流程：环境初始化 → 注册 MCP 全局上下文 → 用适当权限调用主 Agent。