★ FEATURED ARTICLE 简介围绕清华大学团队推出的 DeepSeekResearch 科研工具这份 PDF 以“让科研像聊天一样简单”为主线面向数据挖掘、自然语言处理与机器学习方向的研究生、科研人员和数据分析初学者梳理多 agent 协同完成数据采集、清洗、集成、变换、特征工程到分析应用与可视化的全流程。内容结合社交媒体、数据库、文本与接口等多源数据场景展示诊断、预测、关联、聚类以及客户细分、信用评分、时序模式挖掘等应用并对 DeepSeek R1、OpenAI o3mini、Claude 3.5 Sonnet、Kimi k1.5 在爬虫采集和文件读取中的表现做了对比测试附有提示词示例与结果讨论。整包为 1 个 PDF 文件约 5.43MB便于集中阅读和资料留存已有 211 人学习。读者可从中了解该工具的能力边界、模型选型思路和可解释性设计也能借助测试结论与提示词模板规划自己的科研数据流程减少在重复数据操作上的试错成本。1. 科研像聊天真正的难点不在对话框而在对话框背后的编排大多数人第一次看到科研像聊天一样简单这句话会下意识认为难点在自然语言理解——模型得听懂人话。真正跑过一遍完整流程的人会给出相反的结论听懂人话是最容易的一环难的是把一句模糊的人类意图拆成一条能落地、能验证、能回滚的产物链。数据挖掘、机器学习这些词在论文里很轻落到工程上每一步都会产生大量中间物一份网址列表、一个能跑的脚本、一张对齐的表格、一组统计量。DeepSeekDeepResearch 这套工具真正解决的问题是把这条链子藏进一个多 agent 的状态机里用户只看见聊天框看不见五个交接窗口。搞懂它怎么编排比搞懂它支持什么功能有用得多。2. 多 Agent 编排一句自然语言怎么被拆成五段流水线这套系统的骨架不是一个大模型加一堆工具而是若干个职责单一的 agent 串成流水线。理解它的第一步是搞清楚每个 agent 到底交付什么、交给谁、失败时怎么退回。2.1 五段产物流水线采集、处理、分析、挖掘、可视化各自交付什么从输入素材里能清晰读出一条五段式结构。数据采集段负责通过编写爬虫代码、访问数据库、读取文件、调用 API 等方式拿到原始数据覆盖社交媒体文本、库表记录、接口返回等来源数据处理段做清洗、集成、变换和特征工程目标是纠错、整合、格式转换、特征提取数据分析段做诊断、预测、关联和聚类落点是问题定位、需求预测、异常检测数据挖掘段做分类、社交网络分析、时序模式挖掘落点是客户细分、信用评分、营销与趋势预测数据可视化段把结果转成柱状图、热力图、网络关系图、词云、树形图。关键在于这五段不是五个功能按钮而是五种带类型的产物。采集段的产物是结构化记录集JSON 或 CSV处理段的产物是清洗后的规整表分析段的产物是指标与统计结论挖掘段的产物是分类标签或多维关联可视化段的产物是图表规格。每一段的输出必须能被下一段直接消费否则流水线在交接处就断了。这里有个容易被忽略的细节素材里反复出现文件数据读取文本数据集成这类任务本质是让 agent 跳过前两段直接从一段已有文本里重建整条链。这说明流水线在设计上支持从任意中间段切入——这是产物契约清晰之后才可能有的灵活性。2.2 调度器怎么判断下一步交给谁产物契约与状态机编排层要做的事用一句话概括维护当前上下文里有哪些产物、每个产物的类型是否满足下一段的入口条件。常见的实现思路是一个显式状态机加一个产物登记表而不是让模型自由发挥我接下来想干什么。# 简化的编排器骨架状态机 产物契约校验 STAGES [collect, process, analyze, mine, visualize] # 每段声明自己的入口产物类型和出口产物类型 CONTRACT { collect: {in: {query}, out: record_set}, process: {in: {record_set}, out: clean_table}, analyze: {in: {clean_table}, out: metrics}, mine: {in: {clean_table}, out: segments}, visualize: {in: {metrics, segments}, out: chart_spec}, } def run_pipeline(state, user_intent): # 模型只负责选下一段不负责决定是否可以执行 next_stage planner.select(state, user_intent, STAGES) contract CONTRACT[next_stage] # 入口产物缺失 - 立刻回退去补而不是硬跑 missing contract[in] - set(state.artifacts) if missing: return rollback(state, next_stage, missing) artifact executor.invoke(next_stage, state, user_intent) validator.check(artifact, expectcontract[out]) # 类型不合法直接抛错 state.artifacts[contract[out]] artifact return state这段骨架里有两个刻意的设计。第一选择权和执行权分离planner 只输出下一段是哪一段executor 才真正调模型干活这样可以在执行前插校验。第二validator.check是硬失败而不是软降级——产物类型不对就抛错回退不允许带着脏数据往下走。真实系统里这套东西通常更复杂会带重试计数和人工确认点但主干就是这个形状。常见的实现思路是给每段加一个最大重试次数 失败原因回灌上下文让下一次生成带上上一轮的错误信息。参数上值得注意的几处planner.select一般用低温度0 或接近 0因为这里要的是稳定路由而不是创意executor.invoke里做代码生成的段落反而需要稍高的温度否则容易反复输出同一种错误写法contract[out]的校验越靠近 JSON Schema 越好因为自然语言描述的表格在代码里没法校验。2.3 拆 Agent 而不是写一个巨型函数的三个理由有人会问既然都是一个模型在干活为什么不写一个超长提示词让它一次输出采集、清洗、分析、可视化的全部结果从素材里的实测数据看这条路走不通原因有三层。第一层是长度预算。一次请求里同时生成爬虫脚本、清洗逻辑、统计结论和图表规格输出会非常长而自回归生成越长越容易在中后段失准。素材里输出表格末尾缺失长文本无法给出答复这类现象都是长度预算被吃穿之后的典型表现。拆成多段之后每段的输出长度可控失准被限制在单段内。第二层是可替换性。不同模型在不同环节各有强弱素材的对比里某推理模型在爬虫代码生成和数据完整性上更稳某小模型响应快但附件支持受限某长上下文模型在 15000 token 场景反而更全面某通用模型表格工整但不支持直接出图。这些差异是真实存在的把流程拆开之后每一段可以挂不同的模型做能力互补的组合——素材里提出的优势互补、协同应用本质上就是这个思路的工程化。第三层是可验证性。爬虫脚本能不能跑通、表格有没有漏列、统计量对不对都是可判定的。拆成 agent 之后每段之间有一个明确的检查点出错能定位到段。写成一个大函数出错时只能看到最终结果不对中间发生了什么完全没有痕迹排查起来就是黑匣子。提示判断一套 AI 科研流水线是否成熟不看它支持多少种图表看它在两个 agent 之间有没有硬校验。没有校验的流水线前一段的幻觉会安静地流到后一段最后以结论看起来挺像样但数字不对的形式爆出来。3. 采集 Agent从网页源码到能跑通的爬虫脚本采集是整条链上最容易翻车的一段因为它同时依赖模型的语义理解、代码生成和外部环境。素材里那个春运数据爬取的例子很典型先让模型阅读网页源码、提取符合特定格式的网址、去重合并成列表再基于列表写 Python 脚本抓取字段并写入文件。这个任务把采集 agent 的三个能力点全考了一遍。3.1 提示词真正要锁死的是产物形状不是任务描述把素材里的提示词结构拆开看它其实做了五件事读源码、提网址、去重合并、生成脚本、写文件。这五步按顺序编号每一步都有明确的输出物。这种写法的价值不在描述清楚而在把中间产物显式化——如果只写帮我爬取春运数据模型会直接跳到写脚本网址列表这一步被隐式完成一旦出错就无从查起。我在设计这类提示词时一般会强制三件事。一是要求先输出网址列表再输出代码顺序不能反因为列表是可人工核对的代码不是。二是对列表提出去重和格式约束比如每行一个 URL、不带引号、不带序号减少下游解析成本。三是明确产出文件名让写文件变成一个可验证的动作而不是一句描述。3.2 生成代码之后的执行—回读—重试闭环素材里的模型对比暴露了一个非常关键的分歧有的模型能提取全部网址、生成可运行脚本、跑出完整数据有的模型代码能跑但产出为空还有的模型连代码都跑不通。这三种结果指向同一个结论——代码生成正确不等于任务完成中间必须有一个执行与回读的闭环。import subprocess, json, os def run_collect_agent(urls, target_file, max_retry3): feedback for attempt in range(max_retry): # 把上一轮的真实报错/空结果回灌而不是只说再试一次 code llm_generate_script(urls, target_file, feedbackfeedback) proc subprocess.run( [python, -c, code], capture_outputTrue, textTrue, timeout120 ) if proc.returncode ! 0: feedback f运行报错: {proc.stderr[-800:]} # 只回灌尾部避免上下文爆炸 continue # 关键不信跑完了只信文件里真的有数据 if not os.path.exists(target_file) or os.path.getsize(target_file) 64: feedback 脚本执行成功但输出文件为空或过小请检查选择器与翻页逻辑 continue rows load_rows(target_file) if len(rows) len(urls) * 0.8: # 覆盖率阈值 feedback f仅采集到 {len(rows)} 条覆盖率不足疑似选择器不匹配 continue return rows raise RuntimeError(f采集失败最后反馈: {feedback})这段逻辑的重点在三个判定条件返回码、文件存在性与大小、记录覆盖率。返回码只能说明语法没错文件大小能排除跑通了但没写东西覆盖率能排除只抓到第一条就退出。三者缺一都会出现素材里描述的那种代码运行后生成本地文件但提取数据结果为空的尴尬局面。max_retry一般设 2 到 3。设 1 太少模型第一次往往栽在选择器上设 5 以上收益递减因为同一段报错回灌多次之后模型会开始瞎改。feedback截断到 800 字符左右是个经验值完整 traceback 动辄几千字塞进上下文反而挤掉了源码本身。覆盖率阈值 0.8 不是硬标准按数据源稳定性调整结构规整的站点可以提到 0.95。3.3 四模型实测差异背后的机制短板素材里那组对比很有信息量但需要翻译成机制语言才看得懂。四个模型下面用 R、O、C、K 代指同类推理模型、小参数模型、通用模型和长上下文模型的差异可以归到三类能力上。第一类是联网与源码获取能力。素材明确提到有的模型支持联网查询网址、有的不支持。不支持联网的模型只能依赖用户上传的网页源码一旦源码不完整网址列表就必然缺失。这不是模型智力问题是输入通道问题。第二类是代码生成的可执行性。R 和 O 生成的脚本能正常执行数据采集C 和 K 出现代码中罗列 URL 不全输出文本中提取数据为空这类问题。这两种失败模式指向不同的根因URL 不全属于长列表复制时的遗漏是生成阶段的问题提取为空属于选择器与真实 DOM 不匹配是理解阶段的问题。前者靠分片喂入解决后者靠把真实 HTML 片段一并塞进上下文解决。第三类是响应速度与完整性的取舍。素材里 O 响应更快但数据完整性略逊R 更慢但结果更准。这个差异在采集段尤其明显因为采集任务的成功与否是二值的——少一条数据就是失败快没有意义。所以这类环节我一般会优先选慢而稳的模型把快模型留给后续的交互式追问。素材里还有一句很关键的免责说明测试结果受数据样本、测试环境、提示词模板等因素影响。这句话不是客套。生成式任务的方差本来就大同一个提示词跑两次结果不同是常态把这叫抽卡其实挺准确。工程上的应对不是追求单次完美而是把重试和校验做进流程让方差被吸收在系统内部。4. 读取、抽取与分析 Agent长文本下的结构化塌陷采集之后是读取与分析。这一段看起来最纯智力实际上受工程约束最深因为它的输入是一大段文本输出是一张结构化表格中间隔着一个自回归生成过程。4.1 7000 与 15000 token上下文里最先坏掉的是什么素材做了一个很聪明的对照实验同一份文本分别在约 7000 token 和 15000 token 两个量级下测试表格抽取。结果呈现出清晰的规律一般长度下多数模型能整理出规整表格但维度有缺失长文本下部分模型直接无法给出答复部分模型反而表现更好。这里最先坏掉的不是理解而是输出预算的分配。表格抽取是一个输出长度与输入长度正相关的任务输入里有多少天、多少个指标输出就有多少行多少列。当输入涨到 15000 token输出也要跟着涨而生成过程在接近上限时会出现两类退化行数截断后面几天没了和列合并环比和同比被合成一列。素材里输出表格末尾缺失集成数据维度不够全面描述的正是这两种。反过来长文本下某模型表现反而更全面这个反直觉现象也有解释长上下文模型对位置信息的保持更稳不容易在中段丢锚点。普通模型读到后半段时前半段建立的行列结构已经开始模糊于是出现前面几行列很全、后面几行只剩两列的塌陷。工程上的应对是分段加汇总而不是硬扛CHUNK 4000 # 每片字符数约 1500-2000 token留足输出预算 OVERLAP 200 # 相邻片重叠防止跨片的行被切断 def extract_table(text, schema): rows [] for chunk in sliding_window(text, CHUNK, OVERLAP): # 强制模型只输出 JSON 数组不输出解释文字压缩输出预算 out llm(chunk, json_schemaschema, temperature0) rows.extend(validate_and_fix(out, schema)) # 分片会带来重复行按日期主键去重并排序 return dedupe_by_key(rows, keydate).sort(date)CHUNK取值是这一步的核心参数。切得太小表格的跨行结构被打散模型看不到表头切得太大输出预算又被挤掉。我通常按每片能稳定输出 30 到 50 行来估字符数落在 3000 到 5000 之间。OVERLAP的作用是防止某一天的数据正好落在切口上代价是产生重复行所以后面必须去重。json_schema传参比在提示词里描述字段名可靠得多因为 schema 是机器可校验的。4.2 表格抽取为什么会漏列结构化输出的对齐问题素材里反复出现数据维度有所缺失没有提及环比和同比数据这类描述。这类问题比整段失败更麻烦因为结果看起来是对的只有逐列核对才发现少了。根因在于表格抽取本质是一个对齐任务输入里有若干个指标名输出里要有同样多的列且一一对应。语言模型做对齐靠的是注意力而注意力在长文本里会衰减。当某一列的取值在原文中分布稀疏比如只有部分日期有民航数据模型倾向于这一列没什么内容索性不输出而不是输出空值占位。这种省略在自然语言里完全合理在表格里就是数据丢失。解决办法是让列从生成目标变成约束条件。常见的做法有三条一是显式列举所有列名并要求缺失值填 null不允许省略列二是先让模型输出一份列清单人工或规则确认后再逐列填充三是在后处理里做列数校验发现列数少于 schema 定义就整片重跑。第三条最笨但最有效因为它把漏列从一个隐蔽的质量问题变成了一个可见的失败信号。4.3 分析 Agent 的推理链相关性与异常检测分析段的输入是一张表输出是结论。素材里对某推理模型的评价是详细展示长思维链精准提取关键指标分析多个因素特征对核心指标的影响结合历史背景对数据及规律进行验证并敏锐察觉数据异常。这段话里其实藏着分析 agent 的三个能力层次。最底层是指标定位从一堆列里找出哪个是核心指标比如幸存率这种比率型字段哪些是解释变量。这一层靠的是语义理解相对容易。中间层是关联分析把每个特征与核心指标做交叉看哪些因素有显著影响。这一层靠的是统计直觉模型不一定真跑检验但它能给出方向性判断。最高层是异常察觉与外部验证意识到数据里有不合常理的记录并引入领域背景去校验结论。这一层最难也最能区分模型强弱——素材里明确写到两个强模型都能做因素分析但只有一个察觉到了数据异常。从机制上看第三层能力依赖的是走出表格模型要把表内模式和它训练语料里的常识做对照。这也是为什么给分析 agent 的提示词里加上一句如果发现与常识不符的记录请单独列出并说明可能原因能显著提升输出质量——这句话等于给了模型一个许可允许它把内部常识作为证据使用。自然语言处理在这里的角色不是理解文本而是激活先验。值得提醒的是分析 agent 输出的结论天然带不确定性。素材里所有对比表都附了免责声明说结果受样本、环境、提示词影响不作为决策依据。这个态度是对的。分析段应该被定位为提出假设而不是给出答案后续要么人工复核要么用确定性脚本重算一遍关键指标。5. 常见问题排查多 Agent 流水线最容易翻车的五个地方这条流水线的失败模式很有规律绝大多数问题集中在交接处而不是单点。下面五条是从实际跑这类系统时最常撞上的坑每条按现象、原因、解决三层写。5.1 采集段脚本能跑通但产出为空现象模型生成了语法正确的爬虫脚本执行没有报错也确实生成了目标文件但文件里是空的或者只有表头。原因九成是选择器幻觉。模型根据对网页结构的想象写出了 CSS 选择器或 XPath而这些选择器在真实 DOM 里根本匹配不到元素。另一种情况是页面内容由脚本异步渲染静态 HTML 里压根没有数据。素材里多个模型都出现过这个现象说明这不是个别模型的毛病是任务本身的结构性风险。解决把真实 HTML 片段一并喂给模型而不是只给网址在提示词里明确要求只用源码中真实出现的标签和 class执行后加覆盖率校验低于阈值就把真实 HTML 的头部片段和报错一起回灌重试。如果页面确实是异步渲染采集 agent 应该主动切换到接口抓取而不是解析 DOM这个判断要写进提示词。5.2 采集段网址列表看起来完整实际漏了一大截现象模型输出的网址列表格式规整、有去重但人工抽查发现符合条件的页面只收了一半。原因长列表生成时的复制遗漏。当源码里有几十条候选链接模型在生成 URL 列表时会跳读尤其是格式相似的连续链接很容易抄着抄着串行。素材里代码中罗列 URL 不全就是这个问题的下游表现。解决不要指望一次性输出全部 URL。改成先让模型输出符合条件的链接在源码中的定位特征比如共同的 class 或 URL 前缀再用确定性脚本做正则提取模型只负责判断规则而不是搬运数据。这个改法把生成任务转成了分类任务方差立刻降下来。5.3 抽取段表格前几行很全后面越来越窄现象抽取出来的表格开头几行列数齐全、数值准确越往后列越少最后几行只剩一两个字段。原因输出预算耗尽导致的渐进式退化。自回归生成在接近上限时不会突然停止而是倾向于输出更短的结构于是列被合并、字段被省略。素材里末尾缺失维度不够全面都是这个机制的表现。解决分片抽取加列数校验。每片控制在能稳定输出完整结构的长度抽取完立刻校验列数是否等于 schema 定义的列数不等就整片重跑而不是局部修补。另外在提示词里明确缺失值写 null禁止省略任何一列把省略从默认行为改成违规行为。5.4 输入段附件传不上去粘贴之后格式全乱现象某些模型不支持附件上传只能把文本粘贴进对话框。粘贴之后表格的制表符丢失、换行错位抽取出来的数据整体偏移一列。原因结构信息在粘贴过程中被剥离。纯文本粘贴只保留字符不保留列边界模型只能靠空格数量猜列一旦某个单元格内容较长就猜错。解决喂之前先转格式。CSV 用逗号分隔并加表头或者直接转成 Markdown 表格这两种格式对模型最友好列边界明确。如果必须粘贴长文本加一句以下内容以竖线分隔字段第一行为表头把分隔符显式声明出来。这类预处理花不了几秒钟能省掉后面大量返工。5.5 交接段上游跑完了下游拿到的字段对不上现象采集和清洗都成功分析 agent 也正常返回但结论里全是未发现明显规律之类的空话或者图表画出来是空的。原因字段名不匹配导致的静默失败。上游产出的是date、rail_passengers下游提示词里写的是日期和铁路客运量模型在两张表之间做了模糊匹配没匹配上就直接当作缺列处理不报错也不提示。解决在 agent 之间约定固定的中间格式用 schema 文件固化字段名交接时跑一次校验器字段缺失就 fail fast 而不是继续往下走。这一条是最值得投入的因为它把最难排查的结果不对但不知道哪错了变成了明确告诉你缺哪个字段。血泪经验是宁可让流水线在交接处大声报错也不要让它安静地产出一个看起来很专业的错误结论。6. 设计取舍聊天入口加确定性内核为什么是现在的合理答案把这条流水线拆完会发现它最值得琢磨的地方不是用了哪个模型而是分层方式外层是自由的自然语言对话内层是带契约的确定性执行。这个结构不是偷懒是被约束逼出来的。维度单模型直出多 Agent 流水线输出长度受单次生成上限约束长任务易截断分段生成单段可控失败定位只能看到最终结果错可定位到具体段落模型选型全流程一个模型强弱无法互补每段可挂不同模型重试成本整轮重跑只重跑失败段幻觉扩散一次生成内无法拦截交接处可硬校验工程复杂度低高需要状态机与 schema表格右侧不是全赢。多 agent 的代价很实在状态管理、产物序列化、重试策略、上下文裁剪每一样都要写代码和维护。一个只做单次表格抽取的小工具套上这套框架纯属自找麻烦。这套结构的价值在长链路、多来源、需要反复迭代的科研场景里才显现——因为这类场景的失败成本高而失败往往发生在交接处而不是单点。另一个取舍是模型组合。素材里提出的优势互补思路很实在让推理强的模型做采集和分析让响应快的模型做交互和格式化让长上下文的模型啃大文本。这个组合不是固定配方得按任务调整。我自己的判断标准是看这一段的任务是不是二值的——采集成功或失败是二值的就该用稳的模型格式整理是连续的快模型足够。搞反了要么慢得难受要么错得离谱。还有一个容易被忽视的点可解释性。素材里特别提到某类模型注重输出的可解释性和透明性这在科研场景不是加分项而是必需项。科研结论要能被追溯如果中间某一步是黑匣子最终的图表再漂亮也没法写进论文。多 agent 结构天然提供了追溯能力——每一步的产物都留在那里随时可以回看是哪个环节把数据带偏了。验证这套东西是否真的在按设计工作有个简单办法拿一份你已经知道正确答案的小数据集几十行、字段清楚跑完整条链然后逐段核对中间产物。采集段的记录数对不对、清洗后的字段类型对不对、分析段的指标能不能手算出来。中间任何一段对不上就说明那一环的校验缺失。这个动作我一般会在接入新数据源时做一遍五分钟能省掉后面几小时的排查。从那以后我每次接一条新的数据链路都会先拿一份能手工核对的小样本把五个交接点全走一遍确认每段产物都能被下一段正确消费再放开数据量。这个习惯救过我不止一次——有回上游把日期格式从2025-01-14悄悄改成2025/01/14全靠这一步在数据量还小的时候暴露出来。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
