1. 先搞清楚 Skill、Agent、Harness、Subagent 到底在解决什么问题如果你最近在关注 AI 应用开发尤其是想构建能执行复杂任务的智能体那么 Skill、Agent、Harness、Subagent 这几个词一定高频出现。它们听起来很酷但混在一起讲很容易让人晕头转向不知道从哪下手。这篇文章不绕圈子直接用一个“视频剪辑”的完整工作流作为例子帮你把这几个概念串起来讲清楚它们各自扮演什么角色以及在实际项目中如何组合应用。核心结论先放在这里这四者不是一个并列的选项而是一个从原子能力到组织架构的协作体系。搞混了你的项目就容易变成一堆散装功能无法协同用对了就能搭建出稳定、可扩展的智能工作流。简单来说Skill技能是最小的、可复用的“手”或“工具”。比如“调用字幕生成 API”、“调整视频亮度”、“读取 SRT 文件”。它只管执行一个明确、具体的动作。Agent智能体是拥有“大脑”的决策者和协调者。它理解任务目标如“为这个视频加字幕”然后规划步骤、调用合适的 Skills 去执行并处理执行结果。Harness套件/框架是给 Agent 和 Skill 运行的“舞台”和“工具箱”。它提供运行时环境、工具调用规范、状态管理、错误处理等基础设施。没有 HarnessAgent 和 Skill 就是一盘散沙。Subagent子智能体是复杂任务下的“部门主管”。当一个 Agent主智能体的任务太庞大时它可以创建或协调多个 Subagent每个 Subagent 负责一个子目标并可能拥有自己的一套 Skills。下面我们就以“为一个英文视频生成并嵌入中文字幕”这个具体任务拆解它们如何协作。2. 从零搭建定义你的 Skills原子工具库一切从 Skill 开始。这是最具体、最应该先实现的部分。不要一上来就想设计一个万能的 Agent先把一个个小工具做稳定。在我们的视频字幕任务里至少需要这些 Skills2.1 核心输入输出处理 SkillSkill 1:extract_audio_from_video作用从视频文件中分离出纯净的音频流。输入视频文件路径如./input_video.mp4。输出音频文件路径如./temp/audio.wav。实现可以封装 FFmpeg 命令ffmpeg -i input_video.mp4 -q:a 0 -map a temp/audio.wav。为什么先做这个后续的语音识别需要干净的音频输入这是流水线的第一步。Skill 2:transcribe_audio_to_text作用将音频文件转写成文本这里先转成英文原文。输入音频文件路径、可选的语言参数‘en’。输出包含时间戳的文本序列如列表[(0.0, 2.5, “Hello world”), …]或 SRT 格式字符串。实现调用 OpenAI Whisper、Google Speech-to-Text 或本地 VADASR 模型的 API。关键参数model_size权衡速度与精度、language指定可加速、tasktranscribe还是translate。Skill 3:translate_text作用将文本从一种语言翻译成另一种语言。输入原文文本或带时间戳的文本序列、源语言、目标语言。输出翻译后的文本保持时间戳结构。实现调用 GPT、Claude 的 API或本地部署的 NLLB、M2M-100 等翻译模型。注意点翻译时要保持时间戳对齐不能打乱顺序。对于 SRT通常逐句翻译。2.2 字幕文件处理与合成 SkillSkill 4:burn_subtitle_into_video作用将字幕文件如 SRT硬编码到视频中。输入原始视频路径、字幕文件路径、输出视频路径、字幕样式参数字体、大小、颜色、位置。输出嵌入了字幕的新视频文件。实现封装 FFmpeg 命令例如ffmpeg -i input.mp4 -vf “subtitlessubtitle.srt:force_style‘Fontsize24,PrimaryColourHFFFFFF’” output.mp4。避坑提示字体文件路径在服务器上可能不存在最好将字体文件打包进项目或使用系统通用字体。开发 Skill 的原则单一职责一个 Skill 只做一件事做好一件事。明确接口输入、输出参数定义清晰最好是强类型如使用 Pydantic Model。错误处理Skill 内部要能捕获常见异常如文件不存在、API 调用失败并抛出有意义的错误信息。可测试性每个 Skill 都应该能独立进行单元测试。当你把这几个 Skill 开发并测试通过后你就拥有了一个可靠的“工具盒”。接下来需要有一个“大脑”来指挥它们。3. 设计中枢构建任务规划 Agent大脑Agent 的核心是“规划”和“决策”。它不直接处理视频或音频而是理解用户意图拆解任务并按顺序调用 Skills。3.1 Agent 的核心循环一个典型的 Agent 工作流遵循感知 - 规划 - 执行 - 反思的循环。 在我们的例子中感知接收用户请求“为my_video.mp4生成中文字幕”。规划内部推理“要完成这个任务我需要先提取音频然后转写成英文文本接着翻译成中文最后把中文字幕烧录进视频。”生成执行计划[Skill1, Skill2, Skill3, Skill4]。执行调用Skill1.extract_audio_from_video(“my_video.mp4”)得到audio.wav。将上一步结果作为输入调用Skill2.transcribe_audio_to_text(“audio.wav”)得到en_srt。调用Skill3.translate_text(en_srt, src_lang‘en’, tgt_lang‘zh’)得到zh_srt。调用Skill4.burn_subtitle_into_video(“my_video.mp4”, “zh_srt.srt”, “output_video.mp4”)。反思检查每个 Skill 的执行结果是否成功中间文件是否生成。如果某一步失败决定重试、换方案还是报错。3.2 实现 Agent 的两种常见模式基于规则/模板的 Agent适合流程固定的任务。就像我们上面写的顺序是预设好的。实现简单但缺乏灵活性。# 伪代码示例规则型 Agent class VideoSubtitleAgent: def run(self, video_path): try: audio_path skill1.extract(video_path) en_text skill2.transcribe(audio_path) zh_text skill3.translate(en_text, ‘en’, ‘zh’) output_path skill4.burn(video_path, zh_text) return {“status”: “success”, “output”: output_path} except Exception as e: return {“status”: “failed”, “error”: str(e)}基于 LLM 的规划 Agent让大语言模型来动态规划步骤。灵活性极高能处理未知或复杂任务。# 伪代码示例LLM 规划型 Agent class LLMPlannerAgent: def plan(self, user_request): # 将可用的 Skills 描述提供给 LLM skills_description “”” 可用的工具有 1. extract_audio: 输入视频路径输出音频路径。 2. transcribe_audio: 输入音频路径输出英文字幕文本。 3. translate_text: 输入文本和语言对输出翻译后文本。 4. burn_subtitle: 输入视频路径和字幕文本输出带字幕的视频。 “”” prompt f””” 用户请求{user_request} {skills_description} 请规划出完成任务所需的工具调用步骤以 JSON 列表格式输出每个步骤包含 ‘skill’ 和 ‘input’ 字段。 “”” plan_json call_llm(prompt) # 调用 LLM API return parse_json(plan_json)关键点LLM 规划需要清晰、结构化的工具描述并且要有后置的“执行器”来解析 LLM 的输出并真正调用 Skill。Agent 设计的经验状态管理Agent 需要跟踪任务的整体状态比如当前步骤、中间结果、哪些步骤成功了/失败了。错误恢复不要一个步骤失败就整个任务崩溃。设计重试机制如网络超时重试、备选方案如 ASR 模型 A 失败换模型 B。上下文管理确保上一个 Skill 的输出能正确传递给下一个 Skill 作为输入。现在Agent 和 Skill 都有了但它们需要一个地方来“生活”和“协作”这就是 Harness。4. 提供舞台利用 Harness 实现工程化基础设施Harness 不是一个具体的 Skill 或 Agent而是一个框架或平台它解决了单体 Agent 难以应对的工程问题。你可以把它想象成 Kubernetes 之于 Docker 容器。一个成熟的 Harness 通常会提供以下能力4.1 核心基础设施Skill/工具注册与管理提供一个中心化的地方注册所有 SkillAgent 可以通过统一的接口如harness.call_tool(“skill_name”, kwargs)来调用而不需要直接 import。统一的输入/输出I/O处理定义任务的标准输入格式和输出格式处理不同 Skill 之间数据的序列化与传递比如把音频文件路径、文本、二进制数据在流程中传递。状态持久化与回溯自动保存每个任务、每个步骤的执行状态、输入、输出和日志。当任务中断或需要调试时可以轻松回溯。并发与队列管理多个并发任务排队调度避免资源冲突比如同时处理多个视频请求。可观测性提供日志、指标Metrics、追踪Tracing面板让你能清晰地看到任务流经了哪些 Skill耗时多少成功与否。4.2 以我们的项目为例Harness 带来的好处标准化调用我们不再写skill1.extract(...)而是写harness.execute(“extract_audio”, {“video_path”: “xxx”})。Harness 负责找到 Skill 的实现并运行它。依赖注入Harness 可以管理 Skill 所需的配置如 API Keys、模型路径并以依赖注入的方式提供给 Skill使 Skill 本身更纯净。流程编排我们可以用 Harness 提供的 DSL领域特定语言或可视化界面来编排extract - transcribe - translate - burn这个流程而无需将顺序硬编码在 Agent 代码里。错误处理与重试在 Harness 层面配置全局的重试策略如网络错误重试3次而不需要在每个 Skill 里重复写。结果存储Harness 自动将最终视频和中间产物音频、字幕文件存储到指定的存储服务如 S3、本地目录并管理其生命周期。Harness 的选择与实践使用现成框架像 LangChain、LlamaIndex 的 Agent 执行器或更专门的如Semantic Kernel、AutoGen、LangGraph都提供了不同程度的 Harness 功能。自建轻量 Harness如果任务不复杂可以自己用 Python 构建一个简单的注册中心和执行循环。class SimpleHarness: def __init__(self): self._skills {} def register_skill(self, name, skill_func): self._skills[name] skill_func def execute_workflow(self, workflow): context {} for step in workflow: skill_name step[“skill”] inputs step[“inputs”] # 将上一步的 context 合并到 inputs 中 combined_inputs {**context, **inputs} result self._skills[skill_name](**combined_inputs) context.update(result) # 将结果存入上下文供后续步骤使用 return context当你的视频处理业务变得极其复杂比如不仅要加字幕还要同时进行内容审核、精彩片段剪辑、多平台格式适配时一个 Agent 会变得过于臃肿。这时就需要引入 Subagent。5. 应对复杂任务引入 Subagent 进行分工组织架构Subagent 的本质是将复杂任务进行领域分解。主 Agent 担任“CEO”负责接收最高层任务并分解Subagent 担任“部门总监”负责解决具体的子领域问题。5.1 视频处理项目的 Subagent 划分设想假设我们有一个“全功能视频后期处理平台”的需求主 Agent (VideoProcessingCEO)接收请求“处理这个采访视频生成带中文字幕的精华片段并适配抖音和 YouTube 平台”。Subagent 1 (TranscriptionSubagent)专精于音频转写和翻译。它内部可能协调更细的 Skill如“降噪 Skill”、“说话人分离 Skill”、“专业领域术语校正 Skill”。Subagent 2 (ContentHighlightSubagent)专精于基于文本和视觉分析提取精彩片段。它需要调用“情感分析 Skill”、“关键帧抽取 Skill”、“镜头切换检测 Skill”。Subagent 3 (PlatformAdaptSubagent)专精于多平台适配。它需要调用“视频裁剪 Skill9:16”、“转码 Skill码率适配”、“平台元数据生成 Skill”。主 Agent 的工作流变为理解请求将其分解为三个子目标[“生成字幕”, “提取精华”, “平台适配”]。将原始视频和“生成字幕”指令发给TranscriptionSubagent等待其返回带时间戳的中英文字幕文件。将原始视频和字幕文件连同“提取精华”指令发给ContentHighlightSubagent等待其返回精华片段时间范围。将原始视频、精华片段时间范围、字幕文件连同{“platforms”: [“douyin”, “youtube”]}配置发给PlatformAdaptSubagent等待其返回最终成品。汇总所有结果返回给用户。5.2 Subagent 间的通信与协调通信方式可以通过消息队列如 RabbitMQ、Redis Pub/Sub、RPC 调用或者直接在 Harness 框架内通过定义好的接口进行调用。数据传递中间数据如大的视频文件最好通过共享存储如对象存储传递引用URL 或路径而不是在内存中直接传递。错误处理一个 Subagent 的失败应由主 Agent 决定是整体失败、重试该 Subagent还是启用降级方案例如精华提取失败则返回原视频。优势模块化每个 Subagent 可以独立开发、测试和升级。可扩展新增一个处理环节如“自动打码”只需增加一个新的 Subagent无需改动主逻辑。易维护问题被隔离在特定领域内调试范围更小。引入 Subagent 的时机不要一开始就设计复杂的多 Agent 系统。只有当你的单体 Agent 逻辑变得过于复杂、团队需要分工协作、或者不同任务对资源GPU、内存的要求差异很大时才考虑引入 Subagent 架构。6. 实战复盘从开发到部署的完整 checklist走完整个概念流程最后给出一份从零开始构建这样一个系统的实操清单和避坑点。6.1 开发阶段 checklistSkill 先行[ ] 列出所有需要的原子操作每个定义一个 Skill。[ ] 为每个 Skill 编写独立的、可单元测试的函数或类。[ ] 明确每个 Skill 的输入、输出格式使用 Pydantic 等工具进行验证。[ ] 处理 Skill 内部的常见错误文件 I/O、API 限流、模型加载失败。设计 Agent 逻辑[ ] 确定 Agent 类型规则驱动还是 LLM 规划驱动[ ] 绘制任务流程图明确 Skill 的调用顺序和条件分支。[ ] 实现 Agent 的状态管理当前步骤、中间结果。[ ] 设计清晰的用户请求解析逻辑。选择或搭建 Harness[ ] 评估需求是否需要并发、持久化、可视化编排[ ] 如果简单可以自建一个轻量级的注册-执行器。[ ] 如果复杂直接采用 LangGraph擅长工作流、AutoGen擅长多 Agent 对话等成熟框架。[ ] 在 Harness 中配置好 Skill 注册、全局错误重试、日志收集。考虑 Subagent 分解[ ] 当前 Agent 的代码是否超过 500 行且职责混杂[ ] 是否有明显可以独立出来的功能领域[ ] 团队是否需要分模块开发[ ] 如果答案是肯定的开始设计 Subagent 的接口和通信协议。6.2 部署与运维避坑点资源管理视频、音频处理是计算和 I/O 密集型任务。务必监控 CPU、内存、磁盘 I/O 和 GPU 显存。使用任务队列如 Celery、Dramatiq来控制并发避免撑爆服务器。文件存储不要用本地临时路径。使用共享的对象存储S3、MinIO或网络文件系统NFS确保任何一个处理节点都能访问到中间文件。可观测性这是排查问题的生命线。确保每个 Skill 调用、Agent 决策都有日志记录并关联到唯一的任务 ID。使用 PrometheusGrafana 监控任务耗时、成功率等指标。版本管理Skill 可能会更新如换用新的 ASR 模型Harness 配置可能会变。要有版本控制并能灰度升级避免全站中断。成本控制如果大量使用商用 API如 OpenAI、Google Cloud需要在 Harness 或 Agent 层面加入预算控制和用量报警。最后的核心建议不要追求一步到位构建一个完美的多 Agent 系统。最务实的路径是先实现几个核心的 Skill然后用一个简单的、规则驱动的 Agent 把它们串成一个能跑通端到端流程的最小可行产品MVP。在 MVP 上验证需求、观察性能瓶颈、收集错误日志。当这个简单系统开始变得难以维护或无法满足新需求时再逐步引入更强大的 Harness 框架或者拆分成 Subagent。这样迭代风险可控每一步都有实实在在的产出。