原文内容

使用 Claude Code 与大模型辅助自动化科研 Agent 开发实践

作者：白有辉、游兴业、王宇航

最近我们参加了第四届世界科学智能大赛（AI for Science 方向），我们的目标是设计一套能够辅助科研工作的自动化 Agent 系统，希望让大模型不仅能"聊天"，还能真正参与复杂科研任务的执行。当前，我们在某子类任务上已取得前三名的好成绩。

在整个开发过程中，我大量使用了 Claude Code 以及 DeepSeek v4 pro 等大模型能力来辅助开发、调试和优化 Agent 系统。这次经历让我越来越清楚地感受到一件事：AI 已经不仅仅是一个问答工具，而正在逐渐成为科研与工程开发中的重要生产力工具。

相比单次对话，我更关注的是另一件事：

大模型能不能围绕一个目标，连续完成搜索、判断、执行、修正和交付

这也是我做这套自动化科研 Agent 的出发点。

背景：为什么"自动科研 Agent"是一个真问题

科研工作者日常面对的大量任务，其实具有很强的结构性和重复性：

• 进入一个新方向时，需要快速检索和整理相关文献
• 设计实验方案时，需要对比已有方法、找出研究空白
• 撰写论文时，需要确认引用的准确性、检查论证链的完整性
• 跟踪前沿进展时，需要持续监控新论文并进行筛选

这些工作如果完全靠人工完成，非常耗时且容易遗漏。反过来说，它们也很适合交给具备语言理解、信息检索和推理能力的 Agent 系统来处理。

但在实际落地中，我们很快发现了一个现实问题：

"文献综述型"Agent 和"科研辅助型"Agent 之间，存在巨大差距

前者本质上就是 search + summarize，很多开源项目都能做；后者则需要真正的任务规划、多步执行和基于中间结果的自我修正能力。我们的目标就是后者。

项目目标：构建真正可执行的科研 Agent

我们希望实现的系统，不只是简单调用一个 LLM，而是一套具备：

• 任务拆解
• 工具调用
• 文献搜索
• 全文理解
• 多步推理
• 自动执行
• 结果整理
• 自我修正

能力的科研 Agent。

例如，对于一个科研任务：

“帮我调研某个方向近年的方法，并自动总结实验路线”

理想情况下，系统不是只返回一段综述，而是需要能够：

1. 自动分析研究主题
2. 生成检索策略
3. 搜索相关论文
4. 扩展引用关系
5. 判断论文是否相关
6. 下载并处理全文
7. 提取核心方法和证据
8. 形成对比与总结
9. 生成实验计划或研究建议
10. 输出结构化结果

这已经不是传统 chatbot 能完成的工作，而更接近真正的"科研助手"。

我们最终把它做成了什么样

在系统设计上，我们逐渐把它从"一个会回答问题的模型"做成了"一个可追踪、可验证、可反思的 Agent loop"。

上图展示了系统的整体执行流程。从顶部的用户输入开始，系统依次经历研究问题分析、检索词规划、文献搜索与引用扩展，经过相关性筛选后进入全文处理与证据抽取阶段。右侧的紫色区域是整个系统的核心——证据矩阵整理后进入反思与补充搜索的闭环：如果发现信息缺口或方向偏差，系统会回溯到检索或搜索阶段进行补充，直到信息充分后才进入综合总结、引用校验和最终报告输出。图中不同颜色区分了不同的处理阶段：蓝色为规划阶段、绿色为检索阶段、橙色为筛选与抽取阶段、紫色为反思闭环、粉色为最终输出阶段。

整个流程大致是：

1. 研究问题分析 — 解析用户输入的研究主题，识别关键概念、子问题和约束条件
2. 检索词规划 — 生成多组检索词组合（包括同义词、上下位词、缩写扩展等），并为每组检索词预估召回面
3. 文献搜索 — 调用学术 API（如 Semantic Scholar、arXiv、PubMed 等）进行批量检索
4. 引用扩展 — 以高相关度论文为种子，向前追溯引用、向后追踪施引文献，扩展候选池
5. 相关性筛选 — 基于标题+摘要，由 LLM 逐篇判断是否与研究主题相关，输出 screening decisions
6. 全文下载与预处理 — 通过开放获取渠道下载 PDF，进行文本提取和分块（chunking）
7. 证据抽取 — 从每篇论文的全文或摘要中，按维度（方法、数据集、指标、结论等）抽取关键信息
8. 证据矩阵整理 — 将所有论文的抽取结果合并为结构化对比表，便于横向比较
9. 反思与补充搜索 — 检查证据矩阵中是否存在信息缺口或方向偏差，决定是否需要补充检索
10. 综合总结 — 基于证据矩阵生成综述性分析，包含方法分类、趋势总结和研究空白识别
11. 引用校验 — 验证关键引用是否准确，确保每条引用对应正确的论文，避免幻觉引用
12. 更新监控建议 — 生成后续需要持续跟踪的关键词和作者列表，便于建立监控策略
13. 生成最终报告 — 输出结构化 Markdown 报告，包含综述、证据矩阵、引用列表和研究建议

这件事很重要，因为很多看起来像 Agent 的系统，本质上只是：

prompt + workflow + 几个工具调用

它们能"跑流程"，但不一定真的具备围绕目标持续修正的能力。

而我们在开发过程中越来越明确：

自动化 Agent 的关键，不是让它多说几步，而是让它在每一步都有明确目标、可检查结果，并且能基于中间结果继续调整后续行为。

架构设计要点

在实际实现中，我们没有采用"一个大 prompt 管全程"的方式，而是把系统拆成了几个核心模块：

Planner（规划器）

负责任务拆解和执行计划生成。输入是用户的研究问题，输出是结构化的执行计划（包含步骤、依赖关系和预期产出）。我们在 Planner 这里引入了"显式中间目标"的概念——每一步执行前，Planner 都会明确这一步的预期产出格式，执行后由 Evaluator 检查是否达标。

Executor（执行器）

负责按计划调用工具并收集结果。Executor 本身不做判断，只负责"执行指令"和"收集返回"。它需要处理工具调用的技术细节：重试机制、超时控制、并发限制、结果格式化等。

Evaluator（评估器）

负责检查中间结果的质量。Evaluator 是一个轻量级的评估节点，它会对照 Planner 设定的预期产出，判断当前步骤的结果是否满足继续向下的条件。如果不满足，会触发反思回路。

Memory Manager（记忆管理器）

负责管理三类信息：

• 短期记忆：当前任务窗口内的对话和中间结果
• 长期记忆：跨任务的持久化知识（如已知的方法分类、常用检索词等）
• 外置状态：写入磁盘的结构化文件，作为"事实中心"（source of truth）

这种架构的核心思想是：

不要让任何一个模块同时承担"理解意图"“执行操作”"判断质量"三个职责

职责分离之后，每个模块出错的范围是可控的，调试也更容易定位。

DeepSeek v4 pro 在复杂任务中的表现

在实际测试中，我们发现，对于简单问答，大部分模型差距并不明显；但在真正复杂的 Agent 场景下，大模型的任务规划能力、上下文管理能力和长链路推理能力会直接影响系统效果。

我们后端接入了 DeepSeek v4 pro 等模型，在以下任务中表现较好：

• 多轮任务规划
• 长链路推理
• 工具调用链组织
• 自动纠错
• 多步骤科研分析
• 基于中间结果继续补搜和修正

例如，Agent 在完成文献分析时，需要连续完成：

• 阅读摘要
• 判断是否相关
• 提取方法
• 比较多个方案
• 决定还要不要继续搜索
• 最终生成总结

如果模型上下文能力不足，很容易出现：

• 中途丢失目标
• 重复调用工具
• 推理链断裂
• 输出结构混乱
• 前后结论不一致

而 DeepSeek v4 pro 在复杂任务上的稳定性更好，这也是我们后续重点使用它的重要原因。

多模型混合策略

在实际系统中，我们并没有只用一个模型处理所有任务。不同的环节对模型能力的要求不同，成本也不同：

这样一来，既能保证关键环节的质量，又能控制整体成本。如果所有环节都使用最强的模型，单次完整任务的 API 费用会非常高；但如果减少关键环节的预算，输出质量就会明显下降。

一个典型失败案例

这里分享一个实际调试中遇到的具体案例：

某次执行文献调研任务时，Agent 在第三步（文献搜索）返回了 50 篇论文，但在第五步（相关性筛选）时，LLM 把其中 30 篇都判定为"相关"。这本身不算异常——检索时适当扩大范围是合理的。

但问题出在后面：这 30 篇论文进入证据抽取阶段时，其中有 12 篇实际上只有摘要可用，没有获取到全文。当时的系统设计没有严格区分"全文级别的证据"和"摘要级别的证据"，导致证据矩阵中混入了大量不精确的信息，最终总结的质量受到了严重影响。

这让我们意识到一个架构上的缺失：

证据的质量层级必须显式标注

后来我们引入了"证据质量标签"：

• Level A：从全文中直接提取的数据和方法描述
• Level B：从摘要中推断的信息
• Level C：从引用关系中推断的间接证据

只有 Level A 证据才参与核心结论的生成，Level B 和 C 仅作为辅助参考。这个改动对输出质量的提升非常明显。

做自动化 Agent 过程中的几个关键经验

这部分是我觉得最值得分享的地方。真正开始做之后，我发现自动化 Agent 和普通应用开发的难点并不一样，很多坑不是"模型不够强"，而是系统设计方式不对。

1. 不要一上来就堆模型，先定义"可交付结果"

一开始很容易陷入一种误区：只要模型更强、prompt 更长，Agent 就会更聪明。

但实际开发中，更重要的是先定义每一步到底要产出什么。

比如我们后面逐渐把中间结果都做成了可检查的产物：

• query plan：检索策略的显式 JSON，包含检索词、数据库选择、预期召回量
• screening decisions：每篇论文的相关性判断 + 判断依据（1-2 句话理由）
• evidence matrix：结构化表格，每行一篇论文，每列一个证据维度
• reflection notes：反思阶段的自由文本，记录发现的信息缺口和补充策略
• citation verification：引用校验结果，标注每条引用的状态（已确认 / 存疑 / 无法验证）
• final report：最终的 Markdown 报告

这样做有两个好处：

第一，系统是否真的完成任务是可验证的；

第二，一旦出错，可以迅速定位到底是搜索阶段、筛选阶段还是提取阶段出了问题。

也就是说，Agent 不是"最后给一个答案"就算完成，而是要把中间推理过程沉淀成可以复查的结果。

一个反例：

我们早期有一个版本，中间状态全部存在一个 dict 里，一步步往里追加字段。表面上系统跑通了，但一旦某一步的输出格式稍有变化，后续步骤就会静默失败——不是报错，而是拿到了错误的输入继续往下跑，最终输出的报告看起来"还行"但经不起细看。拆分中间产物并落盘之后，这个问题才真正被解决。

2. Agent 不是简单 workflow，必须保留"反思 - 修正"回路

很多系统看起来步骤很多，但本质上只是一次性串联执行。

真正复杂的科研任务里，前面的搜索结果会影响后面的判断，后面的总结也会反过来暴露前面搜索不充分的问题。

所以我们后面越来越强调一个闭环：

执行 -> 评估 -> 反思 -> 修正 -> 再执行

例如：

• 如果筛选到的论文方向太散，需要回到 query planning 重新收缩检索范围
• 如果证据矩阵信息不足，需要继续补充搜索
• 如果引用不可靠，需要增加引用校验

这类"会回头修正自己"的能力，才更接近我们理解中的 Agent。

反思循环的实现方式：

我们在 Evaluator 阶段设计了一个具体的检查清单：

1. 证据矩阵中是否存在信息空白？（例如某篇高相关论文的关键方法未提取）
2. 覆盖的论文是否方向过于集中于某个子领域？
3. 时间分布是否合理？（是否遗漏了近两年的重要工作？）
4. 证据间是否存在明显矛盾？（如果有矛盾且未解决，说明需要更多信息）
5. 引用是否完整且准确？

只要以上任何一项不通过，系统就会明确标注"需要补充"并回到对应的执行阶段。

一个重要的设计决策：

反思不是"让模型自己决定要不要继续"。我们发现，如果不加约束，模型倾向于"满意"——即使信息不完整，它也会生成一个看起来像样的结论。所以我们最终采用了结构化的检查清单（checklist）配合规则触发的机制，而不是完全由 LLM 自由判断是否需要反思。

3. 长上下文不是万能的，状态必须外置

这是我在开发过程中感受非常深的一点。

做文献 Agent 时，如果把所有论文内容、摘要、提取结果、历史对话都堆到一个长 prompt 里，短期看起来很方便，但一旦任务变长，很快就会出现：

• 上下文过长，中间信息被"挤压"
• 历史信息污染当前判断（模型更关注"最近看到的内容"）
• 不同论文内容互相干扰（尤其是方法相似的论文）
• 成本快速上升（长上下文意味着每次调用的 token 消耗翻倍）
• 调试困难（你根本不知道模型在哪个环节读了什么信息）

所以后面我们把很多状态显式外置到磁盘和结构化文件中，比如：

• 每篇论文单独的全文上下文（papers/{paper_id}/full_text.txt）
• 分块后的文本（papers/{paper_id}/chunks/chunk_*.txt）
• reader context（papers/{paper_id}/reader_context.json）
• chunk-level extract（papers/{paper_id}/chunk_extracts.json）
• 最终 extract（papers/{paper_id}/final_extract.json）
• evidence matrix（workspace/evidence_matrix.csv）

这样做的好处是，主控制器只需要读取"必要摘要"，而不是永远背着全部原始材料前进。

简单说就是：

不要让大模型记住一切，而要让系统知道去哪里取回需要的信息

一个具体的实践：

在进行证据抽取时，我们不会把一篇 30 页的论文全文塞给 LLM，而是先做分块，每个 chunk 独立抽取关键信息，再由一个汇总步骤把 chunk-level 的抽取结果合并成论文级别的提取。这样既避免了上下文过载，又让抽取过程变得可追踪——如果最终提取结果有问题，你可以回溯到是哪个 chunk 的抽取出了问题。

4. 让 LLM 负责判断，让程序负责确定性执行

我们后来逐渐明确了一个分工原则：

• 需要语义理解和判断的，交给 LLM
• 需要稳定执行和可重复运行的，交给程序

比如：

LLM 更适合做：

• 检索策略规划
• 论文相关性判断
• 方法总结
• 证据归纳
• 反思补搜

程序更适合做：

• 搜索结果收集（API 调用、去重、排序）
• 文件下载（带重试、断点续传）
• PDF 预处理（文本提取、分块、格式清洗）
• 状态持久化（读写结构化文件、维护任务进度）
• 结果导出（格式化报告、生成对比表）
• 异常重试与日志记录

如果把这两部分混在一起，系统就会变得很不稳定。很多时候不是模型回答错了，而是工具调用、状态管理或数据边界出了问题。

一个典型的错误设计：

早期我们让 LLM 直接生成文件路径来读取中间结果。结果发现模型有时会"发明"一个不存在的路径，或者在路径里出现奇怪的前缀。后来我们把所有文件操作的逻辑交给程序侧，LLM 只负责告诉程序"我需要读取 paper_id=xxx 的全文"，程序负责查找对应的文件路径并返回内容摘要。这个改动虽然简单，但直接消除了一个非常令人头疼的错误来源。

5. 真正的难点，常常不在"推理"，而在工程边界

很多人以为做 Agent 最难的是 prompt 设计，但真正做下来我发现，很多最耗时间的问题其实是工程问题：

• 文献下载不到全文（很多论文没有开放获取，或者 PDF 链接已失效）
• 看起来像 PDF 的链接实际不是 PDF（重定向到了 HTML 登录页或摘要页）
• 某一步返回为空，后面全部被带偏（空结果不等于"没有信息"，但系统不知道）
• screening 阶段太慢，看起来像卡死（50 篇论文逐篇判断，加上 API 调用延迟）
• 配置、日志和中间状态难以追踪
• PDF 解析失败（扫描版 PDF、双栏排版、数学公式被破坏）

这些问题如果不解决，模型再强也很难稳定交付结果。

所以一个可用的 Agent，不只是"会思考"，还必须：

• 可观察（每一步的状态和中间结果都能看到）
• 可调试（出错后能快速定位到具体环节）
• 可回放（给定相同的输入和配置，能复现相同的结果）
• 可定位错误（错误信息清楚地指向具体环节，而不是笼统的"系统出错"）

这一点和普通 demo 的区别非常大。

一个实用的实践：

我们在每个步骤之间都写入了 checkpoint 文件，记录这一步的输入、输出、耗时和状态。这样如果系统在第 8 步失败了，你可以直接从第 7 步的 checkpoint 恢复，而不需要重跑整个流程。在开发调试阶段，这个设计节省了大量时间。

6. 严格失败，往往比"兜底成功"更重要

在 Agent 开发里，有一种很常见的诱惑：

某一步失败了，要不要先随便给个兜底结果，让流程继续跑下去？

短期看，这样系统"更顺滑"；但长期看，这通常会制造假成功。

比如：

• 没拿到全文，却还在继续做全文总结（实际上是在总结摘要）
• LLM 没有真正返回结构化结果，却被默认解析成功（解析器默默吞掉了格式错误）
• 某一步信息不足，却继续向下游传播（垃圾进，垃圾出）

我们后来越来越倾向于：

• 缺全文就明确失败，标记为"无全文"状态，由上层决定是否降级处理
• 关键 JSON 不合法就回退重试（最多 3 次），3 次失败后抛出明确错误
• 返回空结果就直接暴露问题，而不是静默地用一个空列表继续执行

因为只有这样，系统才会逼着我们真正修复问题，而不是用表面上的"流程跑通"掩盖质量问题。

一个反例：

我们第一版的 JSON 解析器做了"最大努力解析"——即使 LLM 返回的 JSON 不完整，也会尝试截取其中的部分字段。这导致了很多"看起来成功"但数据不完整的中间结果，后续步骤基于残缺数据继续执行，最终报告里出现了大量"信息不足"的标记。当后来加上严格模式之后，第一次运行就有 30% 的步骤因为格式问题触发了重试——这才是真实的系统质量。

7. 先跑通小闭环，再追求全自动

自动化 Agent 很容易一开始就做得特别大：多工具、多阶段、多角色、多轮反思、长记忆、自动报告。

但实际开发里，更有效的方式通常是：

1. 先缩小任务范围
2. 先跑通最小闭环
3. 再一点点增加复杂度

比如先验证：

• 能不能正确规划 query（输入主题 → 输出检索策略，人工检查是否合理）
• 能不能筛出相关论文（给定 20 篇论文的标题+摘要，LLM 筛选的准确率能否达到 85%+）
• 能不能拿到可用全文（给定 DOI，系统能成功获取全文的比例）
• 能不能稳定抽取证据（给定一篇论文全文，能否以 90%+ 的准确率提取方法、数据集、指标）

这些基本能力都确认没问题之后，再去做多轮反思和自动报告，成功率会高很多。

我们的迭代过程：

• 第一周：只做"给定一个研究主题 → 输出 10 篇相关论文的总结"，人工验证质量
• 第二周：加入自动搜索和多轮筛选
• 第三周：加入全文处理和证据矩阵
• 第四周：加入反思回路和自动报告生成

每一周都在前一周已验证的基础上增加复杂度，而不是一步到位。

8. Prompt 工程在 Agent 系统中的特殊性

Agent 系统中的 prompt 设计和单次对话场景完全不同。在单次对话中，prompt 只需要引导一次输出；但在 Agent 系统中，prompt 需要引导模型在多轮交互中保持一致性。

我们总结了几条实用原则：

输出格式要"过度约束"

对于中间步骤的输出，我们不只是说"输出 JSON"，而是给出完整的 JSON Schema 和反例。例如：

• 正面示例：{"relevance": "high", "reason": "该方法直接解决了...", "key_contribution": "..."}
• 反面示例：{"relevant": true, "note": "interesting paper about..."}（字段名不对，缺少理由）

只给正面示例，模型还是容易偏离格式；加上反面示例后，格式遵从率显著提升。

使用"角色 + 约束 + 输出格式"三段式 prompt 结构

我们发现一个有效的 prompt 模板：

你是一个[角色]，任务背景是[上下文]。

你需要完成以下工作：
1. [具体步骤]
2. ...

约束条件：
- [约束1]
- [约束2]

输出格式（严格遵守）：
{...JSON Schema...}

这个结构简单但有效，避免了在 prompt 中混入过多"建议"和"提示"导致模型分心。

不要让 LLM 做计算

如果需要在证据矩阵中比较数值（如准确率、F1 分数），不要依赖 LLM 做大小比较。我们遇到过模型在比较"89.2%"和"91.5%"时判断错误的情况。数值比较应该交给程序，LLM 只负责提取和描述。

9. 幻觉问题在 Agent 场景下更加危险

单次对话中的幻觉是"给出错误信息"，但 Agent 场景下的幻觉是"基于错误信息继续执行后续步骤"——错误的放大效应更严重。

我们遇到过的典型幻觉场景：

• 模型"编造"了一篇看似合理的论文（标题、作者、方法都有，但不存在）
• 模型在证据矩阵中"补充"了论文中没有的方法细节
• 模型在反思阶段"发现"了一个信息缺口，但这个缺口实际上不存在，导致不必要的补充搜索

应对策略：

• 引用校验作为独立环节：每一条引用在进入最终报告前，必须与原始检索结果进行比对
• 证据必须可溯源：evidence matrix 中每条证据都附带来源标记（论文 ID + 页码/段落号）
• 不信任模型的"自信"：模型越自信地给出某个具体数值或细节，越需要验证

10. AI 编程真正提升的，不只是"写代码速度"

整个项目里，AI 对开发效率提升非常明显，但我后来觉得，它最大的价值不只是"生成代码"，而是帮助我们：

• 快速搭框架
• 快速理解报错
• 快速重构模块边界
• 快速联调 prompt 和 workflow
• 快速把问题从"感觉不对"缩小成"这里出了问题"

例如以前开发 Agent 时，经常会遇到：

• workflow 逻辑复杂
• prompt 难调
• 状态管理混乱
• 工具调用容易出错
• debug 成本高

现在很多问题都可以直接和 Claude Code 协作完成。

比如：

自动生成 Agent 框架

Claude Code 可以快速生成：

• tools/ — 工具定义和调用封装
• memory/ — 短期/长期记忆管理
• planner/ — 任务规划和拆解
• executor/ — 执行引擎
• workflows/ — 具体业务流程定义

等模块结构。

自动分析报错

以前调试一个异步调用错误，可能需要查半天。

现在我会直接：

• 把 traceback 给 Claude Code
• 让它分析调用链
• 自动修改代码

很多问题几分钟就能定位到。

Prompt 与 Workflow 联合优化

Agent 系统里，prompt 和代码往往是耦合的。

Claude Code 可以：

• 根据 workflow 改写 prompt
• 根据 prompt 调整状态结构
• 自动补充异常处理
• 帮助重新划分模块职责

这种"边写代码边讨论系统设计"的体验，在 Agent 开发里尤其有价值。

一个具体的协作案例

在开发反思回路时，我们最初的设计是让 Evaluator 直接给 Executor 发送"重新执行某一步"的指令。但实现后发现了问题：Executor 收到重新执行的指令时，它不知道该用哪些参数、保留哪些中间状态。

我把这个问题描述给 Claude Code，它建议引入一个"修正上下文"（correction context）的概念——Evaluator 触发的重新执行不是"从头再跑"，而是携带一个记录了哪些参数需要调整、哪些中间结果需要保留的上下文对象。这个方案我们花了一个下午就实现并验证了，如果没有 AI 辅助，从设计到实现可能需要一整天甚至更多。

比赛中的一些真实感受

目前我们已经基于免费 API 和已有算力资源完成了系统初步版本，并在部分赛道测试中取得了较好的效果。

在最近的阶段性评测中，我们已经获得：

单赛道排名第四

这个结果当然和模型能力有关，但更重要的是，Agent 系统一旦进入复杂任务场景，真正拉开差距的往往不是某个单点能力，而是整体系统有没有做到：

• 目标清晰
• 状态可控
• 环节可验证
• 问题可定位
• 结果可交付

这也是这次比赛给我最深的一个认识：

自动化 Agent 不是"更会聊天的大模型"，而是"围绕目标持续执行、持续修正、持续交付的系统"。

比赛中观察到的几个现象

现象一：很多队伍在模型能力上并不差，但系统设计拖了后腿

我们和其他参赛队伍的交流中发现，不少人花了大量精力选模型、调参数，但系统架构上存在明显短板——比如没有中间状态持久化，一次运行失败就要从头再来；或者没有反思回路，第一次输出的质量就是最终质量。这些工程问题反而是更容易拉开差距的地方。

现象二：任务越复杂，"编排"比"生成"更重要

简单任务靠 LLM 一次生成就能得到不错的结果。但在我们的赛道中，任务链路长、中间决策多，单纯依赖 LLM 的生成能力远远不够。真正有价值的是"如何编排多个 LLM 调用、如何管理它们之间的信息流、如何在每个节点上做质量检查"。

现象三：比赛环境的不确定性让鲁棒性成为关键

比赛评测时的网络环境、API 可用性和本地开发环境完全不同。我们花了不少精力处理各种边界情况：API 超时、PDF 无法下载、返回结果格式异常等。这些处理在本地看起来是"过度设计"，但在比赛环境中恰恰是决定系统能不能跑完的关键。

我的感受

这次开发过程中，我最大的感受是：

AI 已经开始改变"写代码"和"做系统"的方式。

以前：

人需要自己完成所有细节

现在更像是：

人负责目标、边界和设计，AI 负责协助实现、调试和优化

尤其是在 Agent 开发这种复杂系统中，Claude Code + 大模型的协同开发体验已经非常接近：

“一个真正参与项目的开发搭档”

未来我希望继续探索：

• 多 Agent 协作（多个专业化 Agent 分工合作，由一个协调器统一调度）
• 自动化科研工作流（从选题、调研、实验到写作的完整闭环）
• 长期记忆系统（跨项目的知识积累和复用，让 Agent 随着使用越来越"懂行"）
• 自主任务规划（Agent 自主拆解复杂任务，不需要人工定义每一步）
• AI for Science（将 Agent 能力扩展到更多科研领域，如生物信息学、材料科学等）

等方向。

我也越来越相信，未来的大模型系统不会只是"回答问题"，而会越来越多地参与：

• 科研辅助
• 工程开发
• 信息整理
• 工具调用
• 长流程任务执行

AI Agent 很可能会逐渐成为未来科研与工程开发的重要基础设施。

附录：给同样在做 Agent 开发的朋友几点建议

如果你也在开发类似的 Agent 系统，以下是我踩过坑之后的一些建议：

1. 不要从复杂的全自动系统开始。从最简单的"能做好一件事"开始，验证核心能力后再扩展。
2. 把中间产物落盘。无论是 JSON、CSV 还是 Markdown，每一步的输出都要能独立查看和验证。
3. 显式管理引用和来源。Agent 系统中丢失来源追踪是致命的，每一条信息都要能回溯到原始出处。
4. 测试不要只用 happy path。故意制造异常情况（断网、空结果、格式错误）来验证系统的鲁棒性。
5. 用 AI 辅助开发 AI 系统。Claude Code 这类工具在 Agent 开发的场景中尤其有价值，不要只把它当代码补全工具。
6. 成本意识要贯穿始终。一个能跑但成本不可控的 Agent 系统是没有实际价值的，设计时就要考虑每一步的 token 消耗和 API 调用次数。