企业官网建设流程全解析

DeepSeek Harness 可以理解为一个面向科研场景的 Agent 编排工具。科研工作中最耗时的部分往往不是某个单点操作，而是把文献调研、实验设计、结果分析和论文撰写串成一条完整流程。传统做法里，每一步都要人工搬运数据：读完文献后手动整理笔记，做完实验后手动复制结果，写论文时再回头翻实验结果和引用来源。DeepSeek Harness 这类工具的意义，是把大模型的规划能力、插件的工具调用能力、自动化脚本的执行能力组合起来，让科研流程在一个工作目录内完成闭环。这篇文章会围绕一个最小可复现项目，讲清楚如何搭建“文献综述 -> 自动实验 -> 论文撰写”的 Agent 工作流，包括插件调用、自动化脚本、自研插件封装、异常排查和生产化建议。

1. 先理解科研 Agent 的“闭环”为什么比单点工具更重要

1.1 科研工作流中的四个环节和它们的隐性依赖

一个典型的科研项目至少包含四个环节：

• 文献检索与综述：找到相关论文，提炼研究现状和未解决问题。
• 实验设计与执行：根据假设设计实验，运行代码，收集指标。
• 结果分析与可视化：统计数据、画图、判断结果是否支持假设。
• 论文撰写与引用管理：把背景、方法、结果和结论组织成论文，并保证引用真实。

这四个环节表面上是线性的，实际操作中却是互相依赖的。文献综述中提到的某个方法，会直接影响实验里要对比的 Baseline；实验输出的指标，会成为论文结果章节里的表格或图片；论文里的 Related Work，反过来又需要回到文献检索中去核验。问题在于，传统手工流程里每个环节都会产生“信息损耗”：摘要里的关键词被重复录入，实验结果被复制到论文时出现格式错乱，引用编号与真实文献对不上。这些损耗正是科研返工的主要来源。

所以，科研自动化的核心不是把某个环节做快，而是让四个环节的数据和上下文能够稳定传递。

1.2 DeepSeek Harness 在闭环中的定位：编排层

DeepSeek Harness 在整条工作流里承担的是“编排层”职责。大模型负责理解和生成，但不是唯一执行者。具体拆分下来：

• 大模型负责把研究主题拆成阶段，生成实验代码，撰写论文段落。
• 插件负责调用外部工具，例如检索文献、执行代码、绘制图表。
• 自动化脚本负责固定数据处理逻辑，保证同一份输入得到同一份输出。
• 落盘文件负责阶段间通信，让每个阶段的结果可追溯、可复查。

可以把这套结构理解成一个科研项目组：大模型是项目负责人，文献检索插件是图书馆管理员，代码执行插件是实验员，绘图插件是制图师，自动化脚本是实验记录板。项目负责人可以调整方向，但每个实际动作都由对应角色执行并留下记录。

这种设计还有一个更实际的原因：大模型不适合做所有事情。让模型直接输出一篇包含实验数据的论文，它很容易编造不存在的指标；让模型自己检索 arXiv，它本身不具备联网能力。必须把模型不擅长的确定性问题交给插件和脚本，模型只保留判断、规划和文本生成。

1.3 最小闭环链路：从问题到论文草稿

一条最小科研闭环可以这样表示：

研究主题 -> 文献综述阶段：检索文献 + 总结现状 + 生成候选假设 -> 实验阶段：生成实验脚本 + 执行脚本 + 保存指标 -> 分析阶段：读取结果 + 绘制图表 + 输出结论 -> 论文撰写阶段：组装 Markdown 草稿 + 生成参考文献列表

每个箭头代表一次数据流转。推荐用 JSON 文件作为阶段间的标准协议：上一个阶段把输出写入文件，下一个阶段读取文件后再继续。这样做的好处是，任何一步失败都能直接从文件定位问题，不用重新跑完整条链路。

这里要注意一个设计原则：大模型负责理解和生成，脚本负责确定性处理，插件负责外部工具，文件负责阶段通信。不要试图让大模型在一个 Prompt 里完成所有事情，那只会增加不稳定性和排查难度。

2. 环境准备：API 配置、工程目录和插件机制

2.1 前置条件与版本确认

在开始搭建之前，先确认环境。DeepSeek Harness 的安装方式在不同版本和平台上会有差异，不要直接照搬网上的命令行。你拿到的如果是桌面版安装包，按照官方指引安装即可；如果是命令行版或插件开发模式，通常需要先准备好 Python 环境。下面列出的是一个通用工程环境要求。

2.2 项目目录结构

推荐按下面这种方式组织项目目录：

harness-project/ ├── config.yaml ├── requirements.txt ├── client.py ├── harness_workflow.py ├── plugins/ │ ├── __init__.py │ ├── base_plugin.py │ ├── literature_search.py │ ├── code_executor.py │ ├── plot_result.py │ └── paper_draft.py ├── scripts/ │ ├── run_experiment.py │ └── collect_results.py ├── data/ │ ├── raw/ │ └── results/ └── output/ ├── figures/ └── drafts/

plugins目录放所有插件，scripts目录放独立自动化脚本，data/results放阶段输出，output/drafts放最终论文草稿。把数据和代码分开，是后续排查问题的前提。

2.3 配置文件与参数含义

在项目根目录创建config.yaml：

model: api_base: "https://api.deepseek.com/v1" api_key_env: "DEEPSEEK_API_KEY" model_name: "deepseek-chat" default_temperature: 0.3 plugin: plugin_dir: "plugins" auto_discover: true workflow: data_dir: "data" output_dir: "output" save_draft: true

关键参数说明：

不同阶段建议使用不同 temperature：文献综述可以放宽到 0.3 左右，实验代码生成要压到 0.1，论文撰写可以放到 0.4。原因是代码和数据解析需要确定性，而写作部分可以保留适度多样性。

2.4 最小调用验证：确认 API 能连通

在写复杂工作流之前，先用一个最小请求确认 DeepSeek API 能正常调用。创建client.py：

import os import requests API_KEY = os.environ["DEEPSEEK_API_KEY"] API_URL = "https://api.deepseek.com/v1/chat/completions" def chat(messages, temperature=0.3, max_tokens=4096): payload = { "model": "deepseek-chat", "messages": messages, "temperature": temperature, "max_tokens": max_tokens, } headers = { "Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json", } resp = requests.post(API_URL, headers=headers, json=payload, timeout=120) resp.raise_for_status() return resp.json()["choices"][0]["message"]["content"] if __name__ == "__main__": resp = chat([{"role": "user", "content": "请回复：API 连接正常"}]) print(resp)

运行前注入环境变量：

export DEEPSEEK_API_KEY=你的Key python client.py

如果返回“API 连接正常”，说明模型调用链路没问题。常见失败现象会在第 7 节单独说明。

3. 用插件把工具能力接入 Agent：文献检索与代码执行

3.1 插件机制要解决的问题

大模型自身不能检索论文，也不能直接运行代码。插件机制的意义，是把这些外部能力封装成 Agent 可以调用的工具。一个插件对外暴露若干“工具方法”，大模型根据任务选择合适的插件和方法，工作流再把模型输出的调用指令转成实际执行。

先看三种扩展方式的区别：

科研场景里，Agent 无法预先确定要检索什么关键词，也无法预先知道实验脚本长什么样，所以插件是最合适的扩展方式。

3.2 基础插件接口

先定义一个基类plugins/base_plugin.py：

class PluginToolNotFound(Exception): pass class BasePlugin: name = "base" description = "插件最基础的描述" def run(self, tool_name, **params): if not hasattr(self, tool_name): raise PluginToolNotFound( f"{self.name} 插件没有 {tool_name} 方法" ) tool = getattr(self, tool_name) if not callable(tool): raise PluginToolNotFound( f"{self.name} 插件的 {tool_name} 属性不可调用" ) return tool(**params)

run是统一入口。工作流只需要知道插件名称、工具名称和参数字典，不需要关心插件内部实现。这个约定让后续接入新插件变得非常直接。

3.3 文献检索插件

文献检索插件使用 arXiv 公共接口，示例代码如下：

# plugins/literature_search.py import arxiv from base_plugin import BasePlugin class LiteratureSearchPlugin(BasePlugin): name = "literature_search" description = "调用 arXiv 接口检索论文，返回标题、作者、摘要和链接" def search_arxiv(self, query, max_results=5): client = arxiv.Client() search = arxiv.Search(query=query, max_results=max_results) results = [] for item in client.results(search): results.append({ "title": item.title, "authors": [author.name for author in item.authors], "summary": item.summary[:500], "url": item.entry_id, "published": str(item.published), }) return results

这里有一个关键设计：摘要summary只截取前 500 个字符。原因是文献摘要很长，全部塞进 Prompt 会迅速消耗上下文窗口。截断后，大模型仍然能看到每篇文献的核心内容，但总 token 数保持在可控范围内。实际项目中，截断长度要根据模型上下文窗口和论文数量调整。

3.4 代码执行插件

实验环节需要运行大模型生成的代码。出于安全考虑，代码执行插件把代码写入临时文件，再用subprocess启动子进程执行：

# plugins/code_executor.py import subprocess import tempfile from pathlib import Path from base_plugin import BasePlugin class CodeExecutorPlugin(BasePlugin): name = "code_executor" description = "把 Python 代码写入临时目录并执行，返回 stdout、stderr 和退出码" def run_python(self, code, timeout=120): with tempfile.TemporaryDirectory() as tmpdir: workdir = Path(tmpdir) script_path = workdir / "task.py" script_path.write_text(code, encoding="utf-8") try: result = subprocess.run( ["python", str(script_path)], capture_output=True, text=True, timeout=timeout, cwd=str(workdir), ) except subprocess.TimeoutExpired: return { "returncode": None, "stdout": "", "stderr": f"执行超过 {timeout} 秒，已终止", } return { "returncode": result.returncode, "stdout": result.stdout[-3000:], "stderr": result.stderr[-3000:], }

返回结构包含三部分：退出码、标准输出、标准错误。stdout和stderr都只保留最后 3000 个字符，避免执行日志过长导致上下文溢出。

注意：不要在一台没有隔离的机器上直接执行大模型生成的任意代码。推荐做法是人工先审阅代码，再放入容器或独立虚拟机运行。科研场景强调的是可审计，不是无条件信任模型。

3.5 插件注册与调用链路

在harness_workflow.py中维护一个插件注册表：

PLUGINS = { "literature_search": LiteratureSearchPlugin(), "code_executor": CodeExecutorPlugin(), }

Agent 调用插件时，流程是：

1. 工作流把当前任务描述发给大模型。
2. 大模型输出结构化的调用指令，例如：{"plugin": "literature_search", "tool": "search_arxiv", "params": {"query": "learning rate"}}。
3. 工作流解析指令，找到注册表中的插件，调用plugin.run(...)。
4. 插件执行结果拼接回上下文，大模型拿到真实结果后继续生成。

这套链路的关键是“结构化指令”。如果大模型输出的是普通文本，工作流无法稳定解析。后面第 7 节会介绍如何增强 JSON 解析的稳定性。

4. 自动化脚本：把实验过程变成可重复、可追踪的流水线

4.1 为什么实验部分不能完全交给大模型

大模型生成的代码存在三个问题：不稳定、不可控、不可审计。同样一个 Prompt，模型可能两次输出风格完全不同的代码；模型也可能写出死循环或者把结果打印成不同格式。科研实验要求可重复性：同一份输入在同一个环境下必须得到同一份输出。

所以，正确分工是：大模型负责生成实验思路和核心代码片段，自动化脚本负责固定输入输出协议、执行任务、保存结果。即使模型生成的代码有缺陷，脚本也能把错误信息完整记录下来，供模型修正或供人工排查。

4.2 实验输入输出协议

先定义实验任务的输入文件data/raw/task.json：

{ "task": "compare convergence speed under different learning rates", "config": { "learning_rates": [0.001, 0.01, 0.1], "epochs": 20, "seed": 42 }, "dataset": { "type": "synthetic", "size": 500 } }

字段含义：

4.3 实验 Runner 脚本

scripts/run_experiment.py读入任务文件，执行一个简单的模拟训练，并把结果写成标准 JSON：

import json import random import sys from pathlib import Path def simulate_training(learning_rate, epochs, seed): rng = random.Random(seed) loss = 2.0 history = [] for _ in range(epochs): loss = loss * (1 - learning_rate) + rng.uniform(-0.05, 0.05) loss = max(loss, 0.01) history.append(round(loss, 6)) return history def main(): if len(sys.argv) < 3: print("usage: python run_experiment.py <input_json> <output_dir>") sys.exit(1) input_file = Path(sys.argv[1]) output_dir = Path(sys.argv[2]) output_dir.mkdir(parents=True, exist_ok=True) payload = json.loads(input_file.read_text(encoding="utf-8")) config = payload["config"] results = [] for lr in config["learning_rates"]: history = simulate_training(lr, config["epochs"], config["seed"]) results.append({ "learning_rate": lr, "history": history, "final_loss": history[-1], "converged": history[-1] < 0.1, }) output_path = output_dir / "train_results.json" output_path.write_text( json.dumps({"results": results}, ensure_ascii=False, indent=2), encoding="utf-8", ) print(json.dumps({"status": "ok", "output": str(output_path)})) if __name__ == "__main__": main()

运行方式：

python scripts/run_experiment.py data/raw/task.json data/results

这段脚本的价值在于：只要task.json不变，输出就完全一致。大模型可以根据脚本的输入输出格式，动态生成实验代码片段，但最终落地执行和结果落盘永远走这套固定脚本。

4.4 结果汇总与指标提取

scripts/collect_results.py把结果转成人类可读的 Markdown 表格：

import json import sys from pathlib import Path def build_summary(result_file): data = json.loads(Path(result_file).read_text(encoding="utf-8")) rows = [] for item in data["results"]: rows.append({ "learning_rate": item["learning_rate"], "final_loss": item["final_loss"], "converged": item["converged"], }) return rows def to_markdown(rows): lines = [ "| learning_rate | final_loss | converged |", "| --- | --- | --- |", ] for row in rows: lines.append( f"| {row['learning_rate']} | {row['final_loss']} | {row['converged']} |" ) return "\n".join(lines) if __name__ == "__main__": result_file = sys.argv[1] rows = build_summary(result_file) print(to_markdown(rows))

运行方式：

python scripts/collect_results.py data/results/train_results.json

大模型可以读取这个表格，再结合图表完成论文结果描述。把数据处理固定成脚本，能避免模型在文字描述里写出和实际数字不一致的内容。

5. 自研插件：封装私有工具与论文写作逻辑

5.1 自研插件要遵守的约定

自研插件不需要掌握复杂的框架，只要遵守一套稳定约定：

• 继承BasePlugin。
• 设置唯一的name，不要与已有插件重名。
• 方法名就是工具名，方法参数由大模型根据描述推断。
• 返回值必须能被 JSON 序列化。
• 错误信息要通过抛异常或返回结构化stderr反馈给上层。

这些约定保证了插件可以被注册表统一管理，也可以被大模型稳定调用。

5.2 可视化插件

plugins/plot_result.py封装 matplotlib 绘图逻辑：

# plugins/plot_result.py import matplotlib matplotlib.use("Agg") import matplotlib.pyplot as plt from base_plugin import BasePlugin class PlotResultPlugin(BasePlugin): name = "plot_result" description = "根据实验数据生成折线图，保存到指定路径并返回路径" def line_chart(self, x, y, title="result", output="output/result.png"): fig, ax = plt.subplots(figsize=(8, 5)) ax.plot(x, y, marker="o") ax.set_title(title) ax.set_xlabel("learning_rate") ax.set_ylabel("final_loss") fig.savefig(output, dpi=150) plt.close(fig) return {"figure": output}

返回的是图片路径而不是图片内容。原因在于，二进制图片不能直接塞进文本 Prompt，工作流可以读取路径后把图片展示给人工，或记录到结果文件里。

5.3 论文草稿插件

大模型负责生成摘要和章节内容，论文草稿插件负责把这些内容组装成结构稳定的 Markdown，并生成参考文献列表：

# plugins/paper_draft.py from base_plugin import BasePlugin class PaperDraftPlugin(BasePlugin): name = "paper_draft" description = "把标题、摘要、章节内容和参考文献组装成 Markdown 论文草稿" def assemble(self, title, abstract, sections, references): lines = [ f"# {title}", "", "## 摘要", "", abstract, "", ] for section in sections: lines.append(f"## {section['heading']}") lines.append("") lines.append(section.get("body", "")) if section.get("verify"): lines.append("") lines.append(f"> 待核实：{section['verify']}") lines.append("") if references: lines.append("## 参考文献") lines.append("") for idx, ref in enumerate(references, 1): lines.append(f"[{idx}] {ref}") return {"markdown": "\n".join(lines), "reference_count": len(references)}

这个插件本身不调用模型，只负责格式化。为什么这样设计？因为论文格式必须是稳定的，而大模型输出格式不稳定。把“生成内容”和“组装格式”分开，可以减少草稿结构被打乱的概率。

5.4 自研插件的测试方法

每写完一个插件，先用最小参数单独测试，不要直接接进工作流。例如：

python -c " from plugins.plot_result import PlotResultPlugin p = PlotResultPlugin() print(p.run('line_chart', x=[1, 2, 3], y=[0.5, 0.2, 0.1], output='output/figures/test.png')) "

测试时重点检查三件事：

• 能否正常返回 JSON 序列化结构。
• 缺少必要参数时是否会抛出明确异常。
• 输出文件是否真的生成到预期路径。

自研插件最容易踩的坑是“测试过正常路径，没测试错误路径”。插件一旦接进 Agent 工作流，大模型传来的参数是不可控的，缺失参数、类型不对、路径不存在都很常见，所以必须提前设计错误处理。

6. 完整闭环演示：从文献综述到论文草稿的一次运行

6.1 任务定义

用一个具体题目演示整条链路：验证学习率对随机优化算法收敛速度的影响。这个题目足够小，可以在一台普通机器上跑完，又能体现文献检索、实验、分析和写作的完整过程。

在harness_workflow.py中实现各阶段调度。先准备两个工具函数，负责从模型输出中提取代码和 JSON：

import re import json def extract_python(text): match = re.search(r"```(?:python)?\n(.*?)```", text, re.S) return match.group(1) if match else text.strip() def extract_json(text): text = text.strip() if text.startswith("```"): text = re.sub(r"^```(?:json)?\s*", "", text) text = re.sub(r"\s*```$", "", text) try: return json.loads(text) except json.JSONDecodeError: match = re.search(r"\{.*\}", text, re.S) if not match: raise ValueError("无法从模型输出中提取 JSON") return json.loads(match.group(0))

6.2 各阶段编排逻辑

以函数为单位拆分阶段：

def stage_literature_review(topic): print("[stage] literature_review") papers = PLUGINS["literature_search"].run( "search_arxiv", query=topic, max_results=5 ) summary = chat( [ {"role": "system", "content": "你是科研助手，负责从文献中提炼研究现状和假设。"}, {"role": "user", "content": f"研究主题：{topic}\n文献数据：{json.dumps(papers, ensure_ascii=False)[:4000]}"}, ], temperature=0.2, ) save_json("data/results/literature_summary.json", {"papers": papers, "summary": summary}) return papers, summary def stage_experiment(summary): print("[stage] experiment") code = chat( [ {"role": "system", "content": "你是科研工程师，只输出可直接运行的 Python 模拟实验脚本。"}, {"role": "user", "content": f"请根据假设生成实验脚本：{summary}"}, ], temperature=0.1, ) clean_code = extract_python(code) exec_result = PLUGINS["code_executor"].run("run_python", code=clean_code, timeout=120) save_json("data/results/execution_log.json", exec_result) if exec_result["returncode"] != 0: raise RuntimeError("实验脚本执行失败") parsed = extract_json(exec_result["stdout"]) save_json("data/results/train_results.json", parsed) return parsed def stage_analysis(parsed): print("[stage] analysis") result = parsed["results"] figure = PLUGINS["plot_result"].run( "line_chart", x=[item["learning_rate"] for item in result], y=[item["final_loss"] for item in result], title="Learning Rate vs Final Loss", output="output/figures/learning_rate_loss.png", ) print("[info] figure ->", figure) return figure def stage_paper_draft(papers, summary, parsed): print("[stage] paper_draft") references = [f"{p['title']} {p['url']}" for p in papers] draft = PLUGINS["paper_draft"].run( "assemble", title="学习率对优化算法收敛速度影响的初步实验与分析", abstract=summary, sections=[ {"heading": "1 相关工作", "body": "需要根据检索结果补充具体文献编号。", "verify": "补充真实文献编号"}, {"heading": "2 实验设置", "body": "实验使用合成数据，不同学习率在固定随机种子下训练 20 轮。", "verify": "与 data/results/train_results.json 一致"}, {"heading": "3 结果分析", "body": f"最终损失值分别为 {parsed['results']}，具体趋势见图表。", "verify": "检查图表编号和坐标轴"}, ], references=references, ) save_json("output/drafts/draft.json", draft) print(draft["markdown"])

主入口：

def run_workflow(topic): papers, summary = stage_literature_review(topic) parsed = stage_experiment(summary) stage_analysis(parsed) stage_paper_draft(papers, summary, parsed) if __name__ == "__main__": import sys if len(sys.argv) != 3 or sys.argv[1] != "--topic": print("usage: python harness_workflow.py --topic <research_topic>") sys.exit(1) run_workflow(sys.argv[2])

这段代码是为了展示编排思路，实际项目里可以进一步引入配置读取、失败重试和人工审批。核心是每个阶段都独立成函数，阶段之间通过返回值或文件传递数据。

6.3 运行方式与预期输出

export DEEPSEEK_API_KEY=你的Key python harness_workflow.py --topic "learning rate impact sgd convergence"

正常运行的输出大致如下：

[stage] literature_review [stage] experiment [stage] analysis [info] figure -> {'figure': 'output/figures/learning_rate_loss.png'} [stage] paper_draft # 学习率对优化算法收敛速度影响的初步实验与分析 ...

运行结束后，目录下会多出这些文件：

6.4 人工校验点

完整闭环不意味着全自动交付。在以下节点必须有人工参与：

• 实验脚本执成功后，检查是否运行了预期之外的操作。
• 结果图表生成后，检查坐标轴和数值趋势是否符合领域常识。
• 论文草稿生成后，逐个检查“待核实”标记，确认引用编号和数据没有错位。

Agent 的价值是帮你把重复性工作压缩到分钟级，而不是替你做学术判断。

7. 常见问题排查：插件失效、脚本超时、输出格式不稳定

7.1 场景排查速查表

7.2 插件调用失败

插件调用失败最常见的原因是注册表不完整或方法名不匹配。写一个小脚本检查注册表：

from plugins.literature_search import LiteratureSearchPlugin from plugins.code_executor import CodeExecutorPlugin from plugins.plot_result import PlotResultPlugin for plugin in [LiteratureSearchPlugin(), CodeExecutorPlugin(), PlotResultPlugin()]: tools = [method for method in dir(plugin) if not method.startswith("_")] print(plugin.name, tools)

如果大模型输出中的tool字段不在列表里，工作流就会报错。解决办法是把插件方法名写进插件描述中，让大模型看到调用选项；同时在注册流程里增加“工具名白名单”校验。

7.3 脚本执行超时

subprocess.run(timeout=...)超时后会把子进程杀掉，并返回一个returncode=None的异常结果。遇到这种情况，先看执行日志：

• 如果是训练轮数过多，调小epochs或分批运行。
• 如果是代码陷入死循环，人工检查大模型生成的循环条件。
• 如果确实需要长时间运行，把结果改成增量落盘，不要等全部结束再输出。

时间策略上，建议把大模型生成代码的预期执行时间控制在 60 秒以内。科研实验中真正耗时的训练任务，应该走独立调度系统，而不是塞进 Agent 的同步调用里。

7.4 模型输出不稳定的后处理

大模型有时会在要求的 JSON 外加 Markdown 代码块，或者输出一段说明文字。extract_json函数可以处理两种情况：去掉外层代码块，再用正则提取第一个 JSON 对象。更进一步增强稳定性的方式有三种：

• 在系统 Prompt 里写明“只输出 JSON，不要代码块，不要解释”。
• 在用户输入里提供一个目标 JSON 的结构示例。
• 在后处理时用pydantic等工具做结构化校验。

最理想的做法是让模型直接调用工具而不是输出复杂 JSON：工作流定义好工具函数，让模型输出“工具名+参数”，由工作流代码负责组装请求。这样可以减少一层解析难度。

7.5 文献引用断链

大模型写论文时喜欢引用[1]、[2]，但模型并不知道[1]具体是哪篇文献。推荐做法是：文献检索阶段保存完整元数据，论文草稿阶段用占位符引用，最后统一替换成参考文献列表。

例如，在literature_summary.json中保留每篇文献的title、authors、url、published，论文撰写阶段让模型引用[[lit_0]]，随后由paper_draft插件把占位符替换为[1]。这样做可以避免引用断链，也能保证引用编号真实可查。

8. 生产化实践：科研 Agent 要“可审计”，不要“全自动”

8.1 学习环境与正式课题的差异

本地跑通闭环只是第一步。把同样的工作流放到正式科研项目里，需要考虑的维度完全不同。

8.2 在关键节点保留人工审批

科研场景不建议做“全自动”。至少保留三个审批节点：

1. 实验代码执行前人工确认，避免模型生成危险命令。
2. 统计数据进入论文前人工核实，确保数字与实验日志一致。
3. 论文草稿完成后的逐段审阅，确认结论没有超出实验支撑范围。

实现审批的方式可以很简单：工作流在每个阶段之间检查一个配置文件，例如approval/status.json。只有当人工把状态改为approved，工作流才继续执行下一阶段。这样既能保留自动化效率，又能守住科研质量底线。

8.3 数据安全、版本与可复制性

科研自动化最怕“跑完了但无法复现”。建议从四个方面约束：

• API Key 放在环境变量或密钥管理服务中，绝不能进入 Git 仓库。
• 依赖用requirements.txt或 lock 文件固定版本。
• 每次运行的工作流输入输出统一归档到带时间戳的目录。
• 代码、Prompt、插件版本全部纳入 Git 管理。

只要做到这四条，任何一个结果都能回溯到当时的代码和数据，这比追求“一步到位全自动交付”重要得多。

8.4 发布前检查清单

把下面这份清单保存到项目里，每次运行前逐项勾选：

[ ] DEEPSEEK_API_KEY 未出现在代码、日志和提交记录中 [ ] 插件目录可被工作流正确加载 [ ] 每个插件至少用最小参数跑通一次 [ ] 实验脚本在相同输入下可重复执行 [ ] 结果数据已落盘并记录生成时间 [ ] 图表坐标、标题、单位已人工确认 [ ] 文献元数据完整且引用编号正确 [ ] 论文草稿包含人工待核实标记 [ ] 工作流日志完整记录每个阶段调用

这份清单直接对应本文提到的最容易出问题的地方，检查通过后再进入正式课题环境会省掉大量定位问题的时间。

沿这个方向继续扩展，可以把文献综述接入机构数据库，把实验调度放到独立计算集群，把 Prompt 和插件版本纳入持续集成，并逐步加入缓存与自动重试。核心判断始终不变：科研 Agent 的价值不在替代研究者，而在把可重复、可审计的环节交给机器，把判断和决策留给人类。