开源视频智能体：开发者掌控视频处理全流程

先抛一个判断：开源视频智能体最近被讨论得很多，但多数人把它理解成了“文字生成视频的工具”。这个理解差得很远。视频智能体真正改变的不是单点生成效果，而是把视频处理链条的控制权交还给了开发者。以前你只能把视频扔给闭源 API，等它返回一个结果，中间过程完全不可见；现在你可以把视频理解、内容分析、任务规划、工具执行全部串成自己的流水线，而且整套东西可以免费下载、本地运行、自由改造。

之所以说它“疯狂”，不是因为某个视频生成效果惊艳，而是因为它的技术组件正在以一个不可思议的速度平民化。开源多模态模型、开源视频生成工具、开源数字人模型、Agent 工作流框架，这些原本分散在不同领域的技术，正在被“视频智能体”这个概念整合成一套可以直接落地的系统。对于开发者来说，这意味着你不必再为一次视频理解调用付费，也不必忍受供应商锁定，更不用在模型效果不理想时干瞪眼——你可以直接换模型、改提示词、调工具。

这篇文章不是概念科普，也不是纯趋势点评。我会先拆解开源视频智能体到底是什么、为什么值得关注，然后给出一套能够跑通的最小工程实现，包括环境准备、核心代码、运行验证和排查思路。如果你所在团队正在做视频审核、内容摘要、自动剪辑、培训视频处理，或者只是想在本地搭一个多模态 Agent 练手，这篇文章都值得继续读下去。

1. 开源视频智能体“疯狂”在哪里

先从最直观的痛点说起。传统视频处理工作流是割裂的：要理解视频内容，你需要找人看片子、写纪要；要生成字幕，你需要单独的语音识别工具；要剪辑片段，你需要打开剪辑软件手动切；要把这些能力组合起来，更是要写大量胶水代码。这个过程人力成本极高，而且每一步的数据格式都不一样，很难自动化。

闭源 API 解决了部分自动化问题，但代价是成本和黑盒。视频理解按分钟计费，生成类接口按次计费，跑一次完整分析可能花掉不少预算。更麻烦的是，你不清楚 API 内部用了什么模型、处理了什么信息、为什么给出这样的结果。一旦效果不满足业务要求，你能做的只是改参数重试，无法深入排查。

开源视频智能体的价值，恰恰在这两个维度上同时打开突破口。

• 成本上，模型权重开源，推理服务可以部署在自己的 GPU 上，单次调用成本从“固定费用”变成“电费和显卡折旧”。
• 控制权上，从抽帧策略到理解模型再到工具调用，每一层都由你决定。模型输出不好就换模型，识别不准确就改提示词，处理流程不合理就改 Agent 的规划逻辑。
• 二次开发上，视频智能体可以作为一个服务集成到现有业务系统，输出结构化 JSON，而不是让人在终端里粘贴复制。

还有一个容易被忽略的点：开源视频智能体正在改变视频处理软件的架构方式。以前我们写视频工具，都是写死规则：比如“按固定时间间隔抽帧”“检测到人脸就截取片段”。智能体的做法完全不同，它让大模型根据视频内容动态决定下一步做什么。同样是“从视频里找精彩片段”，普通脚本只能按画面变化幅度筛选，而智能体会先看懂画面语义，再决定调用哪个工具、截取哪一段。这种从规则驱动到目标驱动的转变，才是“疯狂”的根源。

但也要泼一盆冷水：开源视频智能体远没有到“开箱即用”的程度。它更像一套乐高积木，组件很多，拼法要靠自己。模型要下载、推理要调优、工具要封装、输出要校验。这篇文章的后半部分，就围绕这些问题给出工程化建议。

2. 视频智能体的核心概念与工作原理

2.1 什么是视频智能体

视频智能体，可以通俗理解为“一个能看懂视频并动手处理视频的 AI 助手”。它和单纯的视频生成模型不同：视频生成模型只负责从文字生成画面，而视频智能体要完成的是“理解、决策、执行”这一整套循环。

拆开看，它包含三个核心能力。

• 看：从视频中抽取关键帧、音轨、字幕，让多模态模型理解画面内容和上下文。
• 想：基于理解结果，通过大模型规划下一步操作，比如“这个片段是采访的高潮部分，应该截取出来”“这段讲解逻辑完整，可以生成摘要”。
• 做：调用外部工具执行实际操作，比如用 FFmpeg 切割片段、用语音识别模型生成字幕、用渲染模块合成新视频。

这三部分不是简单的先后顺序，而是一个循环。智能体可能会先看一遍视频，然后决定再细看某几秒的画面，调用抽帧工具，进一步分析，再决定最终输出什么。这种动态决策能力，是普通视频脚本不具备的。

2.2 视频理解与视频生成的边界

很多入门开发者会混淆两个方向。

• 视频理解：输入视频，输出结构化信息，比如场景描述、物体识别、语音转写、时间轴标注。
• 视频生成：输入文字或图片，输出一段新视频。

开源视频智能体通常以视频理解为基础，以视频生成为辅助。现在不少项目把两者结合到一起：先理解一个素材视频，再根据理解结果生成新的内容片段。这也是“智能体”和“工具”在概念上的区别——工具只能按固定方式处理输入，智能体可以根据理解结果自己决定调用哪种工具。

2.3 开源视频智能体的典型技术栈

从工程实现上看，一个开源视频智能体项目通常由以下模块组成。

这张表基本覆盖了主流开源视频智能体项目的骨架。你可以把视觉理解层换成任意的开源 VLM，把任务规划层换成本地部署的 LLM，工具执行层也可以按需扩展。这种模块化设计，正是开源视频智能体能够快速迭代的基础。

2.4 它和普通视频脚本的区别

为了更好理解，我们做一个对比。

一个非常典型的变化是：传统脚本如果想提取“视频中所有访谈片段”，你得先定义什么是访谈片段，写规则去识别；智能体只需告诉它“找出访谈片段”，它会调用理解模型分析画面和语音特征，再调用切割工具完成操作。这种从“告诉我怎么做”到“告诉我要什么”的转变，是智能体类应用的核心范式。

3. 环境准备与前置条件

在开始写代码前，先确认你的运行环境。不同项目的依赖版本可能有差异，以下内容以通用思路为主，具体版本请以你选择的实际项目为准。

3.1 硬件要求

视频智能体的主要开销来自模型推理。

• 如果你准备在本地运行视觉理解模型和 LLM，建议准备一块显存不低于 8GB 的 NVIDIA GPU；如果模型较大，16GB 或更高会更稳妥。
• 没有 GPU 也能跑通流程，但速度会很慢，比较适合验证代码逻辑，不适合处理长视频。
• macOS 用户可以利用 MPS 加速，但兼容性需要针对具体模型确认。

显存不足时，可以降低抽帧频率、使用量化模型、把模型部署到独立推理服务上。这些都是实践中常用的优化手段。

3.2 软件依赖

需要安装以下基础软件：

• Python 3.10 或更高版本
• FFmpeg（用于视频抽帧、转码、剪辑）
• OpenCV（用于图像帧处理）
• PyTorch 和 Transformers（用于加载视觉语言模型）
• 一个本地 LLM 推理服务，或者任意兼容 OpenAI 接口的大模型服务

FFmpeg 是视频处理绕不开的基础工具。安装完成后，在终端执行下面命令验证：

ffmpeg -version

如果能正常输出版本信息，说明安装成功。Windows 用户要注意把 FFmpeg 的可执行文件路径加入系统环境变量，否则 Python 子进程会找不到命令。

3.3 创建项目虚拟环境

建议为项目单独创建虚拟环境，避免依赖冲突：

python -m venv .venv source .venv/bin/activate # Windows 使用 .venv\Scripts\activate

然后安装基础依赖：

pip install opencv-python transformers torch fastapi uvicorn pyyaml openai

这里安装openai库并不是要调用云端服务，而是因为许多本地推理服务都提供 OpenAI 兼容接口，用这个库可以让代码和不同推理后端解耦。实际使用时要根据模型仓库说明调整具体依赖。

环境准备完成后，接下来进入核心环节：设计一套可落地的视频智能体工作流。

4. 如何设计一套可落地的视频智能体工作流

一个容易犯的错误是：拿到视频就直接丢给大模型，期望它输出完整结果。真实场景下，视频长度动辄几分钟到几小时，模型一次性处理不了；而且视频处理需要工具配合，不是模型单独能完成的。正确做法是先把流程拆解成可执行的步骤，再让智能体在步骤之间动态决策。

4.1 从需求出发拆解流程

假设业务需求是：输入一段采访视频，自动生成内容摘要、识别关键片段、输出可供后续剪辑使用的分段结果。

传统流程需要人工观看视频、记录时间点、再手动剪辑。智能体流程可以拆成四步。

1. 感知：视频抽帧、提取音轨，得到可被模型处理的结构化素材。
2. 理解：视觉模型分析关键帧内容，语音识别模型转写文本，生成带时间轴的内容描述。
3. 规划：LLM 根据内容描述生成剪辑计划，明确需要截取哪些时间区间、每个片段的主题是什么。
4. 执行：调用 FFmpeg 等工具，按照剪辑计划切割片段，并把摘要和片段元数据输出为 JSON。

这个流程的关键在于：每一步都有清晰输入输出，智能体负责的是“根据分析结果决定执行哪些工具”，而不是自己完成全部操作。

4.2 工具集的设计

智能体的规划能力依赖工具定义。你需要把可执行的操作抽象成函数，并给模型一个明确的 JSON Schema 描述。

例如，可以定义以下工具：

{ "name": "cut_segment", "description": "从原视频中截取一段视频", "parameters": { "type": "object", "properties": { "start": {"type": "number", "description": "开始时间，单位秒"}, "end": {"type": "number", "description": "结束时间，单位秒"}, "output_name": {"type": "string", "description": "输出文件名"} }, "required": ["start", "end", "output_name"] } }

模型收到这个工具定义后，会根据视频理解结果构造 JSON 参数。你的程序解析 JSON，调用对应函数。这样设计的好处是：模型不需要理解 FFmpeg 的具体命令，你只需要在工具函数内部维护好参数转换逻辑。

4.3 让模型参与决策的边界

不是所有步骤都需要大模型参与。抽帧、转码、语音识别这类确定性操作，应该直接用规则和既定工具完成；需要语义判断的环节，比如“这段内容值得截取吗”“摘要应该包含哪些信息”，才让模型参与。

如果模型介入过多，会出现两个问题：一是推理耗时成倍增加，长视频处理慢到无法接受；二是模型可能产生幻觉，对时间轴判断不准确。所以实际设计中，要尽量让模型处理“内容判断”，让规则处理“精确计算”。比如模型只需要说“截取第 2 分钟的问答片段”，而“第 2 分钟对应的帧号是什么”由代码计算。

4.4 防止模型乱调用工具

模型输出不可信是 Agent 工程里的核心问题。即使你给了清晰的 JSON Schema，模型仍可能输出不存在的工具名称、错误的参数类型，甚至编造时间点。

常见防护手段有三个：

1. 给模型设置max_steps，限制单次任务最多调用工具的次数。
2. 在代码层做参数校验，超出视频长度的时间点直接拒绝。
3. 要求模型输出严格 JSON，解析失败时自动重试一次，并携带错误信息让模型自我纠正。

这些防护需要在写核心代码时一起考虑，否则上线后排查成本会很高。

5. 完整示例：从零搭建视频内容分析与剪辑 Agent

这一节给出一个最小可运行示例。它的功能是：输入一段视频，按固定间隔抽帧，用视觉语言模型理解关键帧，再用本地 LLM 生成剪辑计划，最后用 FFmpeg 按计划截取片段。代码省略了复杂的工程细节，重点演示核心链路。

5.1 项目目录结构

video_agent/ ├── main.py ├── config.yaml ├── requirements.txt ├── pipeline/ │ ├── __init__.py │ ├── extract.py │ └── analyze.py └── agent/ ├── __init__.py ├── planner.py └── tools.py

5.2 配置文件 config.yaml

video: input_path: "./input/demo.mp4" fps: 1 frame_dir: "./workspace/frames" output_dir: "./output" model: vlm_model: "your-local-vlm-model-name" device: "cuda:0" llm: base_url: "http://127.0.0.1:8000/v1" api_key: "your-api-key" model: "your-local-llm-model-name" agent: max_steps: 5

这里的vlm_model和llm.model是占位符，需要替换为你实际使用的模型名称。base_url指向本地推理服务地址，只要服务兼容 OpenAI 接口格式即可。

5.3 视频抽帧模块 pipeline/extract.py

import cv2 from pathlib import Path def extract_frames(video_path: str, frame_dir: str, fps: float = 1.0) -> int: frame_dir = Path(frame_dir) frame_dir.mkdir(parents=True, exist_ok=True) cap = cv2.VideoCapture(video_path) if not cap.isOpened(): raise RuntimeError(f"cannot open video: {video_path}") video_fps = cap.get(cv2.CAP_PROP_FPS) or 25.0 interval = max(1, int(video_fps / fps)) frame_count = 0 saved_count = 0 while True: ret, frame = cap.read() if not ret: break if frame_count % interval == 0: out_path = frame_dir / f"{saved_count:05d}.jpg" cv2.imwrite(str(out_path), frame) saved_count += 1 frame_count += 1 cap.release() return saved_count

这个模块用 OpenCV 读取视频，按照设定的抽帧频率把视频保存成图片序列。保存文件名使用连续数字编号，便于后续按顺序分析。抽帧频率不宜过高，否则会产生大量重复图片，既拖慢推理速度，又占用存储空间。

5.4 关键帧理解模块 pipeline/analyze.py

from pathlib import Path from transformers import pipeline def build_captioner(model_name: str, device: str = "cuda:0"): return pipeline( "image-to-text", model=model_name, device=device, ) def analyze_frames(frame_dir: str, captioner, prompt: str = None): frame_dir = Path(frame_dir) results = [] for img_path in sorted(frame_dir.glob("*.jpg")): outputs = captioner(str(img_path)) text = outputs[0]["generated_text"] results.append({"frame": img_path.name, "caption": text}) return results

build_captioner加载视觉语言模型，analyze_frames遍历图片目录，生成每一帧的文字描述。如果模型支持提示词引导，可以把业务需求传入prompt，比如“用中文描述画面中的主要人物和动作”，这样得到的描述会更有针对性。

这里的pipeline用法是 Transformers 库的通用写法。实际使用时要确认你选择的模型是否支持image-to-text任务类型，不同模型的加载方式可能有差异。更稳妥的做法是查阅模型仓库的官方示例代码。

5.5 Agent 规划模块 agent/planner.py

import json from openai import OpenAI def create_plan( analysis_text: str, tool_schema: list, base_url: str, api_key: str, model: str, ) -> dict: client = OpenAI(base_url=base_url, api_key=api_key) prompt = f"""你是一个视频剪辑助手。根据下面的视频分析结果，生成一个剪辑计划。 可用工具定义: {json.dumps(tool_schema, ensure_ascii=False)} 视频分析结果: {analysis_text} 要求： 1. 只输出 JSON，不要输出多余文字。 2. 如果你认为没有值得截取的片段，输出 {"segments": []}。 3. 每个片段的 start 和 end 必须是视频时间轴上的有效秒数。 示例输出： {"segments": [{"start": 10, "end": 20, "output_name": "highlight_001.mp4"}]} """ response = client.chat.completions.create( model=model, messages=[{"role": "user", "content": prompt}], temperature=0.2, ) content = response.choices[0].message.content return json.loads(content)

这段代码的核心是让本地 LLM 根据视频理解结果输出结构化剪辑计划。analysis_text来自上一个模块的帧描述拼接，tool_schema告诉模型可以调用哪些工具以及参数格式。因为模型输出不稳定，JSON 解析失败时需要在外层代码加异常捕获和重试逻辑。

5.6 工具执行模块 agent/tools.py

import subprocess def run_ffmpeg(cmd: list) -> str: result = subprocess.run(cmd, capture_output=True, text=True) if result.returncode != 0: raise RuntimeError(f"ffmpeg error: {result.stderr}") return result.stdout def cut_segment( video_path: str, start: float, end: float, output_path: str, ffmpeg: str = "ffmpeg", ) -> None: cmd = [ ffmpeg, "-y", "-i", video_path, "-ss", str(start), "-to", str(end), "-c", "copy", output_path, ] run_ffmpeg(cmd)

cut_segment封装了 FFmpeg 的片段截取命令。使用-c copy可以避免重新编码，速度快，但在某些关键帧位置可能出现黑屏，需要更精确的场景可以去掉这个参数，改为重新编码。subprocess.run会等待命令执行结束并检查退出码，方便定位错误。

5.7 主流程 main.py

import json import yaml from pathlib import Path from pipeline.extract import extract_frames from pipeline.analyze import build_captioner, analyze_frames from agent.planner import create_plan from agent.tools import cut_segment def load_config(path: str) -> dict: with open(path, "r", encoding="utf-8") as f: return yaml.safe_load(f) def main(): cfg = load_config("config.yaml") video_path = cfg["video"]["input_path"] frame_dir = cfg["video"]["frame_dir"] output_dir = cfg["video"]["output_dir"] Path(output_dir).mkdir(parents=True, exist_ok=True) # 1. 抽帧 saved = extract_frames(video_path, frame_dir, cfg["video"]["fps"]) print(f"extract frames: {saved}") # 2. 关键帧理解 captioner = build_captioner(cfg["model"]["vlm_model"], cfg["model"]["device"]) analysis = analyze_frames(frame_dir, captioner) analysis_text = "\n".join( [f"{item['frame']}: {item['caption']}" for item in analysis] ) # 3. 生成剪辑计划 tool_schema = [ { "name": "cut_segment", "description": "从原视频中截取一段视频", "parameters": { "type": "object", "properties": { "start": {"type": "number"}, "end": {"type": "number"}, "output_name": {"type": "string"}, }, "required": ["start", "end", "output_name"], }, } ] plan = create_plan( analysis_text=analysis_text, tool_schema=tool_schema, base_url=cfg["llm"]["base_url"], api_key=cfg["llm"]["api_key"], model=cfg["llm"]["model"], ) print(json.dumps(plan, ensure_ascii=False, indent=2)) # 4. 执行剪辑计划 for segment in plan.get("segments", []): out_path = str(Path(output_dir) / segment["output_name"]) cut_segment( video_path, segment["start"], segment["end"], out_path, ) print(f"cut segment: {out_path}") if __name__ == "__main__": main()

这个主流程把四个模块串成一条链路：抽帧、理解、规划、执行。每一步的产物都会打印到终端，方便定位问题。如果你不想让 VLM 和 LLM 同时参与，可以把规划模块改成规则逻辑，比如只截取画面变化最剧烈的片段。工程上的做法是先跑通最简链路，再逐步增加模型智能度。

6. 运行结果与效果验证

6.1 运行命令

在项目根目录执行：

python main.py

如果本地推理服务地址或模型名称配置错误，程序会在加载模型或调用接口阶段报错。建议先确认推理服务已经启动，再用curl测试接口连通性。

6.2 预期输出

程序正常运行时，终端会输出类似下面的信息：

extract frames: 120 [ { "segments": [ {"start": 15, "end": 25, "output_name": "highlight_001.mp4"}, {"start": 60, "end": 80, "output_name": "highlight_002.mp4"} ] } ] cut segment: ./output/highlight_001.mp4 cut segment: ./output/highlight_002.mp4

同时，workspace/frames目录下会生成抽帧图片，output目录下会生成剪辑片段。注意，这里的具体秒数和片段数量取决于你的视频内容，不同素材会输出完全不同结果。

6.3 如何判断成功

判断成功不要只看“程序没有报错”。需要从三个层面验证：

1. 抽帧是否合理：打开图片目录，确认画面没有大面积黑屏，时间间隔符合预期。
2. 理解结果是否准确：查看打印出来的帧描述，确认模型没有把画面内容认错。
3. 剪辑点是否有效：播放生成的片段，确认起点和终点没有截断关键内容，输出文件可以正常播放。

如果剪辑片段出现黑屏或者从错误位置开始，优先检查 FFmpeg 的-ss参数位置和-c copy的使用方式。对于关键帧位置敏感的素材，建议去掉-c copy，重新编码输出。

6.4 失败时第一步看哪里

程序失败时，不要立刻去改代码。先按顺序检查：

1. 终端日志有没有 Python 异常，异常堆栈指向哪个模块。
2. 模型推理服务有没有返回错误，接口日志有没有超时或显存不足提示。
3. FFmpeg 子进程的标准错误输出，ffmpeg error: ...后面通常会给出明确原因。

这三点能覆盖绝大多数启动失败和运行中断问题。

7. 常见问题与排查思路

这里只列了最典型的几个问题。实际项目里，视频编码格式五花八门，还会遇到音视频不同步、画面旋转、编码器不支持等问题。建议所有视频处理工具都统一走 FFmpeg 命令，遇到解码异常时优先查看 FFmpeg 的详细错误输出。

8. 最佳实践与工程建议

8.1 模型与业务逻辑解耦

不要把模型加载和业务逻辑写死在同一个函数里。更合理的方式是把模型封装成独立服务，通过 HTTP 调用。这样业务代码可以用不同模型替换，线上更新模型时也不需要重启业务服务。尤其当团队里做模型的人和处理业务的人不是同一拨时，接口化是减少协作冲突的关键。

8.2 用结构化输出约束 Agent

Agent 的输出直接决定后续工具调用是否安全。给模型的提示词要非常明确地要求结构化输出，并在代码层做双重校验：先检查 JSON 合法性，再检查参数范围。对于时间轴参数，必须判断是否在视频时长范围内；对于输出文件路径，必须限制在指定目录内，防止路径穿越风险。

8.3 缓存视频理解结果

同样的视频素材往往会被反复分析。第一次运行后，可以把抽帧结果和帧描述缓存到本地，后续任务直接复用。这样不仅节省算力，还能保证多次分析结果一致。对于长视频项目，缓存几乎是必需品，否则每次改动一个参数都要重新跑完整条链路，排查效率会非常低。

8.4 安全边界不能放松

视频素材往往包含人物肖像、隐私信息或内部业务内容。在使用开源模型处理时，要格外注意数据安全。建议采取以下措施：

• 只处理明确授权或脱敏后的视频素材。
• 推理服务部署在内网，对外只暴露必要的 API 接口。
• 日志中不记录视频内容原文和完整文件路径。
• 模型调用 API Key 使用环境变量管理，不写入配置文件。

开源不等于没有责任。模型权重虽然免费，但处理的数据仍然是你的责任。

8.5 性能优化路径

视频智能体最常见的性能瓶颈是模型推理，不是视频工具本身。优化顺序建议是：

1. 先降低抽帧频率，减少输入到 VLM 的图片数量。
2. 对关键帧做区域裁剪，只保留画面中有信息的区域。
3. 使用量化模型或更小的视觉模型，牺牲少量精度换取推理速度。
4. 把批量帧的推理任务并行化，充分利用 GPU 吞吐能力。
5. 对长视频做切片处理，避免一次性加载过多素材。

如果还需要处理大量视频，可以引入任务队列，把抽帧、理解、剪辑分成独立 worker，异步处理。这个改造虽然复杂度高，但它是从“Demo 能用”走向“生产可用”的必经之路。

8.6 可观测性与回滚

智能体的决策链路比普通脚本复杂，一旦结果不对，很难定位是理解错了、规划错了还是工具执行错了。建议为每一步打印结构化日志，记录模型输入输出摘要、工具调用参数和耗时。这样可以在出问题时快速定位到具体环节。

同时，所有剪辑输出都不要覆盖原始视频。输出目录按任务 ID 隔离，模型迭代后可以在历史数据上对比效果，必要时快速回滚到旧版本。

9. 总结与后续学习方向

这篇内容从头到尾只围绕一个核心判断展开：开源视频智能体的真正价值，是把视频处理的控制权从封闭黑盒交还给开发者。它不是一个单点技术，而是多模态模型、Agent 工作流和视频工程工具的组合体。文中给出的最小示例，已经能够跑通“抽帧、理解、规划、剪辑”的完整链路，你可以在此基础上换成更好的模型、接入更多工具，把它改造成适合自己业务的系统。

如果你现在就想动手实践，建议找一个 1 分钟左右的短视频，先把最小闭环跑通，再去调整模型和提示词。不要一开始就追求复杂效果，尤其不要同时部署多个大模型，否则排查问题的成本会迅速淹没你的学习动力。

后续值得深入的方向包括：长视频的时序理解、音轨事件检测、字幕与画面的联合分析、多轮交互式剪辑，以及把视频内容向量化后接入 RAG 实现知识库问答。这些方向都有大量开源项目在做，技术资料也很多，继续保持对开源社区的关注，是提升速度最快的方式。

视频智能体这个领域还远未定型，现在入场不算晚，甚至正合适。选择开源，就意味着你愿意接受它的不完美，也意味着你有机会把它改造成真正属于自己的工具。先从最小的项目开始，跑起来之后，你会发现“疯狂”背后其实是极度务实的技术积累。