这是我第一次参加 Agent Infra 方向的比赛，也是我第一次比较完整地尝试设计一个多 Agent 项目。

一开始我其实没有特别明确的想法。看到赛道要求之后，我发现它并不是简单做一个聊天机器人，而是要考虑 Agent 之间怎么分工、工具怎么调用、结果怎么验证，以及后续能不能复用。

在选择场景时，我想到自己平时查资料、找论文时经常会遇到一个问题：真正花时间的并不是输入关键词，而是后面的筛选、阅读和整理。一篇论文看完以后，还要记下它解决了什么问题、用了什么方法、有哪些不足，最后还要把这些内容整理成一份比较完整的调研记录。

所以我把项目定成了“多 Agent 协同学术文献调研助手”。

我是怎么设计的

我的设计比较简单，主要分成四个 Agent：

• Planner Agent：负责理解用户的问题，把一个大的调研任务拆成几个小任务。
• Researcher Agent：负责检索论文，并对结果进行去重和排序。
• Analyst Agent：负责分析论文摘要和内容，提取方法、结论和研究空白。
• Auditor Agent：负责检查报告里的结论有没有来源，标记一些不太确定的内容。

整个流程大致是：

用户输入研究主题后，Planner 先生成调研计划；Researcher 再根据计划检索论文；Analyst 对论文进行整理和总结；最后 Auditor 检查引用和证据链，生成最终报告。

刚开始设计的时候，我也想把流程做得很复杂，比如接入多个数据库、做完整的 RAG、支持 PDF 全文解析等。但后来发现，如果一开始把范围定得太大，很容易最后什么都做不完整。

所以我把初赛 Demo 控制在一个比较小的范围内，先让流程能够跑通。

Skill 是怎么设计的

为了让 Agent 的能力不要全部写在一起，我把几个常用功能拆成了 Skill：

• scholar_search：检索论文并返回结构化信息；
• paper_parse：解析论文标题、作者、摘要和结论；
• claim_verify：检查结论有没有对应的文献依据；
• citation_trace：记录结论和论文来源之间的关系；
• review_report：生成 Markdown 格式的调研报告。

其中，我花时间比较多的是 scholar_search。

它需要接收关键词、时间范围、数据源和返回数量等参数，最后返回论文标题、作者、年份、摘要、URL 和相关性评分。如果接口请求失败，就进行重试；如果没有搜到结果，就换一种关键词组合；如果遇到受限内容，就只保留论文的公开信息。

通过这种方式，Skill 不只服务这一个项目。以后如果要做技术选型、竞品分析或者政策资料整理，也可以继续复用类似的检索和验证能力。

Demo 做到了什么

目前我完成了一个本地 Web Demo。

用户可以输入研究主题、年份范围和数据源。点击运行后，页面会依次显示四个 Agent 的执行状态，同时展示检索到的论文、生成的调研报告和 Trace 日志。

Demo 目前优先通过本地代理请求 arXiv Atom API，返回真实的论文标题、作者、年份、链接和摘要。如果网络请求失败，也会自动使用本地样例数据，这样录屏或展示时不会因为网络问题中断。

在报告中，我还保留了检索模式和 trace_id。这样可以知道这次结果是来自真实 arXiv 检索，还是使用了样例数据。

目前还不完善的地方

这个项目现在还只是一个初步原型，距离真正可用还有不少差距。

比如，当前还没有完成 PDF 全文解析，也没有接入完整的向量数据库。Analyst Agent 的分析结果目前主要是流程演示，不能完全代替人工阅读论文。对于引用准确性，也还需要进一步增加测试和人工核验。

另外，AgentTeams、MCP、RAG 这些概念我也是在做项目的过程中逐渐理解的。很多地方现在还停留在设计和原型阶段，后面还需要继续学习和完善。

我的第一次参赛体验

这次做项目让我比较明显地感受到，多 Agent 项目并不是 Agent 越多越好。真正重要的是每个 Agent 为什么存在，它负责什么，和其他 Agent 怎么交接，以及出了问题之后怎么处理。

以前我更关注最后能不能生成一段文字，但这次开始关注过程本身：任务是怎么拆开的，工具调用是否有记录，结论能不能找到来源。

对我来说，这次最大的收获不是做出了一个多么复杂的系统，而是第一次把一个想法从选题、方案、Skill 设计，一直推进到了可以运行和展示的 Demo。

后面我还会继续完善真实 API 接入、报告质量评估和 Trace 回放功能。至少现在，我算是迈出了第一次尝试 Agent Infra 的一步。