让Codex给AI Agent装“眼睛和耳朵“：视频解析技能开发与踩坑修复全流程

小丶舟

293人浏览 · 2026-07-04 20:56:18

小丶舟 · 2026-07-04 20:56:18 发布

本文基于 Codex CLI v1.2 + Coze Agent平台 + Groq Whisper API 验证，截至2026年7月有效。涉及API/SDK的内容如遇版本更新，以官方changelog为准。

一、问题背景：AI Agent的感官缺陷

用过大模型Agent的人都知道一个尴尬——Agent能写代码、能查资料、能分析数据，但给它丢一个视频文件，它就抓瞎了。MP4扔进去，返回的是一堆乱码或者干脆报错"unsupported format"。音频文件同理，WAV、MP3都处理不了。

这事的根源其实很简单：Agent的工具箱里没有视频/音频解析能力。LLM本身只能处理文本，要让它"看懂"视频、"听懂"音频，得给它外挂工具。

我最近在Coze Agent平台上做了一个实验：写一份需求文档，让Codex（OpenAI的代码生成CLI工具）帮我生成一个完整的视频解析技能包，让Agent具备"看视频+听视频"的能力。结果整个过程踩了4个坑，但最终跑通了。

二、方案设计：FFmpeg + read_image + Whisper三段式架构

在让Codex写代码之前，我先理清了技术路线。视频包含画面和声音两条信息流，处理策略自然也分两条线：

画面线：用FFmpeg按固定间隔抽取关键帧（JPEG图片）→ 把图片路径交给Agent的read_image工具做画面分析

声音线：用FFmpeg从视频中提取音频轨（WAV格式）→ 调用Whisper API做语音转文字

这样做的好处是Agent不需要自己解码视频，只需要调用两个现成工具——FFmpeg负责"拆"，read_image和Whisper负责"理解"。Agent的角色是协调者，拿到画面描述和文字转录后做综合分析。

我把需求文档写得很详细，包括目录结构、每个脚本的输入输出格式、错误处理逻辑。然后丢给Codex，让它生成完整的技能包。

三、Codex生成的技能包结构

Codex拿到需求文档后，生成了以下目录结构：

video-parse-skill/
├── SKILL.md          # 技能描述文件，告诉Agent什么时候调用这个技能
├── scripts/
│   ├── extract_frames.py    # FFmpeg抽帧脚本
│   ├── extract_audio.py     # FFmpeg提音频脚本
│   ├── transcribe.py        # Whisper语音转文字
│   └── analyze_frames.py    # 帧分析脚本
└── requirements.txt

架构看着挺清晰，四个脚本各司其职。SKILL.md里写了触发条件——当用户提到"分析视频"、“视频解析”、"看视频"等关键词时自动调用。

但当我实际跑的时候，4个坑接踵而至。

四、踩坑实录：Codex生成的4个Bug

4.1 坑一：Windows反斜杠路径导致目录名错误

第一个坑出现在extract_frames.py里。Codex生成的代码用了硬编码的Windows路径分隔符：

# Codex生成的代码（有bug）
output_dir = "frames\\video_001"
os.makedirs(output_dir)

在Windows上这段代码能跑，但我的Agent跑在Linux沙箱环境里，反斜杠被当成普通字符，结果创建了一个名叫frames\video_001的目录而不是嵌套目录。后续read_image去找frames/video_001/frame_001.jpg当然找不到。

修复方式：用os.path.join和pathlib.Path替代硬编码路径分隔符：

# 修复后的代码
from pathlib import Path

output_dir = Path("frames") / "video_001"
output_dir.mkdir(parents=True, exist_ok=True)
# Python 3.12 / pathlib / 跨平台验证通过

pathlib.Path会自动处理不同操作系统的路径分隔符，比os.path.join更现代，代码也更清晰。

4.2 坑二：中文编码乱码

第二个坑在transcribe.py里。Codex生成的代码在处理包含中文字符的文件名和转录文本时，直接用了默认编码打开文件：

# Codex生成的代码（有bug）
with open(transcript_path, 'w') as f:
    f.write(transcript_text)

在中文环境下，Whisper转录出来的文本包含UTF-8中文字符，但open()默认用系统编码（Windows上是GBK），写入时直接报UnicodeEncodeError。

修复方式：所有文件操作显式指定encoding='utf-8'：

# 修复后的代码
with open(transcript_path, 'w', encoding='utf-8') as f:
    f.write(transcript_text)

这个坑其实很基础，但Codex在生成代码时没有考虑到跨平台编码问题。Python 3里open()不指定编码就用系统默认编码，这是个历史包袱。

4.3 坑三：import openai被沙箱禁止

第三个坑比较要命。Codex生成的transcribe.py直接用了OpenAI的Python SDK来调用Whisper：

# Codex生成的代码（有bug）
import openai

client = openai.OpenAI(api_key=os.environ.get("OPENAI_API_KEY"))
result = client.audio.transcriptions.create(
    model="whisper-1",
    file=open(audio_path, "rb")
)

问题是，我的Agent跑在Coze平台的沙箱里，沙箱环境禁止直接import openai——所有外部API调用必须通过平台的安全网关。直接import会抛ModuleNotFoundError。

修复方式：改用coze_workload_identity安全网关发HTTP请求，绕过SDK直接调API。但后来我发现Groq的免费Whisper API更适合这个场景（下一节详述），所以最终方案换成了Groq。

这里有个判断过程。OpenAI的Whisper API要收费（$0.006/分钟），而且需要绑定信用卡。对于Agent这种可能高频调用的场景，成本不好控。Groq的免费Whisper API每天2000次请求额度，不要信用卡，用的是whisper-large-v3-turbo模型，速度还更快。

4.4 坑四：帧分析是假数据桩实现

第四个坑最隐蔽。Codex生成的analyze_frames.py看起来功能完整——接收帧图片路径列表，返回每帧的画面描述。但仔细一看代码：

# Codex生成的代码（假数据桩）
def analyze_frames(frame_paths):
    results = []
    for path in frame_paths:
        # TODO: 实际画面分析逻辑
        results.append({
            "frame": path,
            "description": "A frame from the video."  # 假数据
        })
    return results

所有帧的描述都是同一个字符串"A frame from the video."，这是个假数据桩（stub），Codex知道这里需要画面分析能力，但它自己没有视觉理解能力，就放了个占位符。

修复方式：既然Agent平台自带read_image工具可以做真实的画面分析，analyze_frames.py不需要自己实现视觉理解，只需要把帧路径输出给Agent，让Agent调用read_image：

# 修复后的代码
def list_frames_for_analysis(frame_paths):
    """输出帧路径列表供Agent调用read_image分析"""
    print(f"共抽取 {len(frame_paths)} 帧关键画面：")
    for i, path in enumerate(frame_paths, 1):
        print(f"  帧{i}: {path}")
    print("\n请使用 read_image 工具逐一分析以上帧图片，")
    print("然后结合音频转录文本做综合内容理解。")
    return frame_paths

这样修改后，脚本只负责列出帧路径，真正的画面理解交给Agent的read_image工具完成。职责分离更干净，也不引入额外依赖。

五、四坑对照表

坑位	问题表现	根因	修复方式
路径分隔符	目录创建为单层而非嵌套	硬编码`\\`分隔符	改用`pathlib.Path`
中文编码	写入转录文本报UnicodeEncodeError	`open()`未指定UTF-8编码	显式`encoding='utf-8'`
import被禁	ModuleNotFoundError	沙箱禁止直接import第三方SDK	改用安全网关/Groq API
假数据桩	所有帧描述相同	Codex无视觉能力放占位符	输出路径交read_image分析

六、Groq免费Whisper API接入

修复完四个坑后，transcribe.py最终改成了调用Groq的免费Whisper API。Groq的接入方式很简单，注册账号拿API Key，HTTP请求调用即可：

# transcribe.py 修复版 — 调用Groq Whisper API
# 环境：Python 3.12 / requests 2.32.0 / 截至2026年7月验证
# Groq免费额度：每天2000次请求，whisper-large-v3-turbo模型

import requests
import os
from pathlib import Path

GROQ_API_KEY = os.environ.get("GROQ_API_KEY")
GROQ_WHISPER_URL = "https://api.groq.com/openai/v1/audio/transcriptions"

def transcribe_audio(audio_path: str, language: str = "zh") -> str:
    """
    调用Groq Whisper API做语音转文字
    audio_path: WAV/MP3音频文件路径
    language: 语言代码，zh=中文，en=英文
    返回: 转录文本
    """
    audio_file = Path(audio_path)
    if not audio_file.exists():
        raise FileNotFoundError(f"音频文件不存在: {audio_path}")

    with open(audio_file, "rb") as f:
        response = requests.post(
            GROQ_WHISPER_URL,
            headers={
                "Authorization": f"Bearer {GROQ_API_KEY}"
            },
            files={"file": (audio_file.name, f, "audio/wav")},
            data={
                "model": "whisper-large-v3-turbo",
                "language": language,
                "response_format": "text"
            },
            timeout=120
        )

    response.raise_for_status()
    return response.text.strip()

运行后检查以下几点确认调用成功：

终端输出中文转录文本且无乱码 → 编码问题已修复
转录内容与视频中的语音一致 → Whisper识别准确
返回HTTP 200且response.text非空 → API调用正常

如果返回429（Too Many Requests），说明当天免费额度用完了。Groq免费层每天2000次请求，对个人Agent使用足够了。

七、完整工作流验证

修复全部Bug后，整个视频解析技能的工作流程如下：

步骤	脚本	输入	输出	耗时（1分钟视频）
1. 抽帧	extract_frames.py	video.mp4	10张JPEG关键帧	~3秒
2. 提音频	extract_audio.py	video.mp4	audio.wav	~2秒
3. 转文字	transcribe.py	audio.wav	transcript.txt	~5秒
4. 帧分析	Agent调read_image	10张JPEG	10条画面描述	~15秒
5. 综合	Agent自行完成	画面描述+转录文本	视频内容总结	~3秒