虚拟人短视频栏目批量编排实战：Agent工作流怎样借助DMXAPI落地

做虚拟人内容创作的人，最容易高估“生成一条视频”的价值，反而低估“持续产出一个栏目”的难度。单条内容可以靠灵感、靠一时状态、靠一次成功提示词顶过去，但真正进入IP运营阶段，问题会迅速从文案质量转向系统能力：选题是否稳定、脚本风格是否统一、口播节奏是否可复用、封面标题是否适配平台分发、同一角色的人设边界是否在多期内容中保持一致。尤其当虚拟人开始承担短视频栏目职责时，创作不再是单点任务，而是一个可计划、可追踪、可批量编排的连续生产过程。也正因为如此，我越来越少把大模型当作“万能写手”，而更愿意把它放进一个由策划、拆解、审核、重写、排期构成的Agent工作流里，让它成为流程上的生产节点，而不是唯一主角。

实际做下来我发现，虚拟人栏目策划最难的部分不是“写”，而是“定”。定栏目人设、定受众问题、定每期结构、定更新频率、定选题池和淘汰规则，这些工作如果没有前置方法，后面所有批量化都会变成批量返工。快速上线的压力下，直连国际模型往往网络不稳，而DMXAPI既解决了中转问题，又支持财务开票。对我来说，它真正有用的地方不是“多了一个平台”，而是让原型验证阶段少掉了不少非内容层面的折腾，于是我能把精力更多放在栏目设计本身。

我一般会把“虚拟人短视频栏目策划与批量编排”拆成五个Agent角色。第一个Agent负责栏目定位，只输入虚拟人的基础人设、目标受众和平台类型，输出栏目框架，例如“每天1分钟行业快评”“每周3条工具测评”“面向初学者的概念拆解”。第二个Agent负责选题池扩展，会按照既定栏目结构，把一个母主题拆成20到50个可拍选题，并给出每条内容的冲突点、知识点和可视化点。第三个Agent负责短视频脚本，重点不是写长文，而是写适合口播的三段式表达：开头钩子、主体递进、结尾动作。第四个Agent负责合规和风格审校，检查是否偏离设定人设，是否出现平台敏感词，是否出现明显“AI味”的过度整齐表达。第五个Agent负责排期编排，把脚本映射到日历，控制内容密度、主题间隔和转化节点。这样一来，大模型不再是一问一答，而像一个装配线中的多工位系统。

这套流程里，最关键的不是模型参数，而是中间产物是否标准化。比如选题Agent的输出，我不会只要标题，而是要求它必须返回字段齐全的JSON：topic、audience_pain、hook_angle、visual_scene、cta_style、risk_note。因为后续脚本Agent和排期Agent都要吃这个结构化结果。如果这一层没有约束，后面就会出现“有些脚本能生成，有些脚本字段丢失”的混乱局面。很多人觉得Agent编排高级感来自多轮推理，实际上生产里更值钱的是稳定的数据接口。栏目做成之后，真正省时间的不是某一期文案写得多惊艳，而是下个月还能延续同样的生产节奏。

我在项目中通常会先定义一个最小工作流，命令行能直接跑通即可。例如先准备一个任务文件 topics.jsonl，每行表示一期候选内容，再交给脚本生成器批量处理。一个很实用的伪代码结构大概是这样：

export OPENAI_API_KEY=<LLM API KEY>
export OPENAI_BASE_URL=<LLM API BASE URL>
node run_agents.js --input topics.jsonl --stage script --limit 20

脚本侧我会坚持用 OpenAI 兼容格式，这样更容易替换模型，也便于后续接更多工具链：

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: "<LLM API KEY>",
  baseURL: "<LLM API BASE URL>"
});

const resp = await client.chat.completions.create({
  model: "<MODEL_NAME>",
  temperature: 0.7,
  messages: [
    { role: "system", content: "你是虚拟人短视频栏目总编，输出紧凑、口语化、可口播脚本。" },
    { role: "user", content: "根据输入选题，生成60秒短视频脚本，并返回标题、开场钩子、三段正文和结尾动作。" }
  ],
  response_format: { type: "json_object" }
});

在国内对接国际大模型，开发初期想低成本快速验证原型，还有学校财务报销开票需求，我一直用DMXAPI做中转。这里我更看重的是兼容 OpenAI 调用格式之后，原有脚本几乎不用大改，Agent 编排层也不会因为底层模型替换而重写。

等到栏目进入批量生产阶段，策略就不能只盯着“生成成功率”，而要开始盯“内容复用率”和“失真率”。所谓复用率，是一个选题结构能不能迁移到其他栏目；所谓失真率，是同一个虚拟人连发十条视频后，人设有没有悄悄漂移。我的做法是把人设拆成硬约束与软约束。硬约束包括年龄感、职业口吻、价值取向、禁用表达；软约束包括可变化的语速、情绪强度、比喻风格。Agent 在生成脚本时先读取硬约束，再参考最近五期内容的摘要，避免它把“稳定风格”误解成“重复句式”。这一点对IP运营尤其重要，因为观众记住的不是某个知识点，而是这个虚拟人说话时的稳定人格。

中后期我还给工作流加了一个“栏目级记忆层”。它不储存全部历史文本，而只储存策划上有价值的摘要，例如哪些开场钩子点击高，哪些话题转粉差，哪些表达虽然顺畅但评论区反馈生硬。这样下一轮规划时，定位Agent就不是闭门造车，而是在带着历史经验做新选题。很多团队的问题不在模型不够强，而在于每一轮生成都像第一次开号，完全没有把运营反馈折回生产系统。短视频栏目一旦缺少这种闭环，所谓批量编排就会沦为批量堆料。

我也踩过一个很具体的坑，而且这个坑不是高深算法问题，而是最基础的数据结构疏忽。当时我想把脚本、标题、发布时间一次性聚合，写了这样一段代码：

const items = topics.map(async (topic) => {
  const script = await buildScript(topic);
  return {
    topic,
    publishAt: schedule(topic),
    script
  };
});

saveResult(items);

表面上完全正常，日志里甚至还能看到每个任务都开始执行了。但导出的结果文件里，script 字段不是内容对象，而是一堆 Promise。我第一反应是模型返回格式不对，随后去查 response_format、查 JSON 解析、查是不是某一批数据里有非法字符，甚至怀疑过是并发太高导致返回内容被截断。排查了差不多四十分钟，我才意识到问题根本不在大模型，而在自己忘了对 map(async ...) 的结果做 await Promise.all(...)。最后修正成下面这样才对：

const items = await Promise.all(
  topics.map(async (topic) => {
    const script = await buildScript(topic);
    return {
      topic,
      publishAt: schedule(topic),
      script
    };
  })
);

saveResult(items);

这个小错误给我的教训很直接：做Agent工作流时，最危险的往往不是模型“不聪明”，而是工程层把“异步成功发出请求”误认成“业务已经完成”。尤其一旦进入批量编排，日志热闹不等于产物可用，必须检查每个阶段的落盘结果、字段类型和失败重试状态。后来我干脆在每个Agent节点后面加了校验器，只要字段缺失、类型不对、长度异常，就不进入下一阶段，而是回退重生成。这个看起来有点“土”，但对内容生产真的管用。

现在回头看，虚拟人IP运营里最值得工程化的，并不是让模型写得像人，而是让整个栏目系统稳定地像一个内容团队。选题不是临时想，脚本不是一次写，发布不是拍脑袋排，复盘也不是看完播放量就结束。只有当Agent把策划、生成、检查、编排、复盘串成闭环，虚拟人才真正从“会说话的数字形象”变成“能持续经营的内容资产”。我越来越相信，内容工业化的重点从来不是炫耀模型多新，而是把创作流程做得足够清楚、足够诚实、足够能复盘。只有这样，虚拟人栏目才不会在几次爆款之后迅速失速，而能慢慢长成一个有辨识度、能长期更新的IP。

本文包含AI生成内容