从一场 38 ℃的成都沙龙，到 Agent Plan × Seedance 2.0 的五周深度实测

文章目录

• 前言
• 一、学习路径全景
• 二、为什么我决定用 Agent Plan 作为社区沙龙主题
  • 2.1 触发点：6 月下旬社区群里的三个“不约而同”
  • 2.2 我给自己定的三个学习问题
• 三、自己先跑一遍——为筹办沙龙做的技术准备
  • 3.1 第 1 天：把 Small 套餐当作“学习教具”
  • 3.2 第 2~4 天：把三个学习问题挨个跑通
    • 3.2.1 学习问题①：模型 vs 编排
    • 3.2.2 学习问题②：档位选择
    • 3.2.3 学习问题③：Seedance 能否量产
  • 3.3 第 5 天至沙龙前：给沙龙做技术走查与现场准备
• 四、7 月 19 日现场——一场 130 人参加、体感 38 ℃的沙龙
  • 4.1 现场基本信息
  • 4.2 三条主线，是三种不同的“落地形态”
    • 4.2.1 主线一：谭俊杰的 UAVS（Universal AI Video Studio Skill）
    • 4.2.2 主线二：潘文杰的 Wiki 知识库
    • 4.2.3 主线三：赵晓丽的 AI 漫剧出海工业化方案
  • 4.3 我作为总负责人在现场收到的三条真实反馈
• 五、会后复盘——把三条主线在自己电脑上再跑一遍
  • 5.1 复盘一：给 ADG 成都社区做一支 30 秒宣传短片（呼应 UAVS）
  • 5.2 复盘二：把社区两年的活动纪要编译成一部 Wiki（呼应潘文杰）
  • 5.3 复盘三：一段 60 秒中英字幕漫剧最小产线（呼应赵晓丽）
• 六、把学习收获总结成方法论
  • 6.1 方法论一：把“档位”当作学习节奏，而不是消费决策
  • 6.2 方法论二：先“资产”，再“分镜”，最后“镜头”
  • 6.3 方法论三：把每一次调用都当“资产”，而不是“消耗”
  • 6.4 三条方法论的整体拼图：一次社区 Leader 的完整学习闭环
• 附录
  • 附录 1 作者信息
  • 附录 2 参考资料
• 总结

前言

2026 年夏天，AI Agent 正从“能不能做出来”进入“能不能被普通人稳定用起来”的新阶段，而火山引擎方舟 Agent Plan，正是把多模态模型、Harness 工具层与订阅制账单打包在一起、让“从创意到成片、从素材到知识资产”变得可预算的一步关键落子。作为一位在成都长期做技术社区运营的开发者，我没有把这次深度实测当成又一次产品测评，而是把它当成一次学习方法的复盘：我用五周时间，从社区群里三条看似无关的诉求出发，为筹办 7 月 19 日下午那场 130 余人到场、体感 38 ℃仍座无虚席的 ADG 成都社区沙龙“创意流水线 · 知识炼金术”做准备，先自己跑通 Small 与 Medium 两档套餐，再走查三位嘉宾的方案，最后把现场学到的思路在自己电脑上再复刻一遍。这篇文章记录的正是这条完整路径，请把它读作一位社区 Leader 边搭活动边学产品的现场日记。

一、学习路径全景

二、为什么我决定用 Agent Plan 作为社区沙龙主题

2.1 触发点：6 月下旬社区群里的三个“不约而同”

我们社区常年活跃着接近 400 位 Agent / AI Coding 方向的开发者。6 月下旬，我在群里几乎同一周内看到三条消息：

• 做短视频代运营的一位朋友抱怨“图像用 A 家、视频用 B 家、剧本用 C 家，一个月订阅费快 500 了”；
• 一位在做 OPC（One Person Company）出海漫剧的成员在问“有没有能把 TTS、字幕、分镜一起打包的方案”；
• 一位做企业内训的老师在群里贴了 Andrej Karpathy 的 Wiki 知识库理念截图，问“这个能真正落地吗”。

我当时的第一反应是：这三个诉求的公约数，正好指向“多模态 + Harness + 订阅制”这套东西。 而这套东西，恰恰是火山引擎在 6 月 8 日推出的 Agent Plan（限时 2.5 折至 8 月 27 日）主推的能力组合。

社区里“要不要办一场专门讲 Agent Plan 落地的沙龙”的提议，就这样在群里被推起来了。作为社区 Leader 与本次沙龙的总负责人，我意识到自己必须先补课——如果连总负责人都讲不清 Agent Plan 到底解决什么问题，那这场活动就没有主线。

2.2 我给自己定的三个学习问题

于是我写了一张便签，贴在显示器右下角：

1. Agent Plan 相对于我平时在用的 Cursor / GitHub Copilot，最大的差异到底在“模型”还是在“编排”？
2. Small（9.9 元）、Medium（49.9 元）、Large、Max 四个档位，对应到我们社区里的三类人（写代码的 / 做内容的 / 做出海的），到底怎么选？
3. Seedance 2.0 视频生成，是“能用”还是“能量产”？

这三个问题，就是我后续两周所有学习行动的锚点。

三、自己先跑一遍——为筹办沙龙做的技术准备

3.1 第 1 天：把 Small 套餐当作“学习教具”

活动定档 7 月 19 日之后，我做的第一件事不是拉分享嘉宾，而是自己先掏 9.9 元买了一个 Small 套餐。理由很朴素：我要能在活动现场演示中真的敲得出接口调用，不能只念 PPT。

Small 套餐的第一次配置踩坑，我记了下来：

• 进入火山方舟控制台 → 开通管理 → Agent Plan 板块 → 支付 → 拿到Agent Plan 专属 API Key（与方舟常规 API Key 是两套体系，不能混用）
• Base URL 选择：OpenAI 兼容走 https://ark.cn-beijing.volces.com/api/plan/v3；Anthropic 兼容（Claude Code）走 https://ark.cn-beijing.volces.com/api/plan。第一次我把 Agent Plan Key 塞到方舟常规 API 的 /api/v3，直接被 401 AuthenticationError 挡在门外，排查了大约半小时才对上路径
• 环境变量我固化到 ~/.zshrc 里 VOLC_API_KEY 和 VOLC_BASE_URL 两个变量，避免每次新开终端要重新配置

这一天最大的体会：Agent Plan 真正的“上手门槛”不在申请 Key，而在 “Key 的种类 × Base URL” 的匹配——Agent Plan Key 只吃 /api/plan/v3，方舟常规 Key 只吃 /api/v3，两套账户体系互相隔离，混用一定认证失败。

3.2 第 2~4 天：把三个学习问题挨个跑通

3.2.1 学习问题①：模型 vs 编排

我用最简单的方法验证：让 GLM-5.2 生成一段 Vue 组件（编程任务），再用几乎相同结构的 Prompt 让它写一段“社区活动海报文案 + 配套图像 Prompt”（多模态任务）。

结论我至今记得清楚：同一个模型，只要在 Agent Plan 的编排下能调用图像 Skill，就等于多了一双手。

在纯编辑器（比如 Cursor）里 GLM-5.2 只是“更强的文本”；在挂载了 Agent Plan 官方 Skill（byted-ark-seedream-skill / byted-ark-seedance-skill）的 Claude Code / OpenClaw 里，GLM-5.2 可以通过 tool-call 触发 Seedream 5.0 Lite 出图、Seedance 出片，一条链路里同时用上文本 + 图像 + 视频。这是我第一次真正理解官方文案里“Model + Harness”意味着什么——Harness 才是让“聊天”变成“执行”的那一层。

3.2.2 学习问题②：档位选择

我把 Small 套餐当“体验档”，把日常写代码的活动交给它，节奏很快就摸清楚了：

• 每天写代码 + 生成活动物料，AFP 消耗大约在 3,000~4,000
• Small 套餐 20,000 AFP 大约支撑 5~6 天，完全“够玩不够用”
• Small 档不支持视频，做 Wiki 也没问题，但视频生成必须升到 Medium

这个体感让我在活动现场介绍套餐选择时可以很坦诚地告诉大家：“Small 是学习教具，不是生产工具；真要跑内容/编程主战场，直接 Medium。”——这句话不是抄的，是我拿自己的账单换来的。

3.2.3 学习问题③：Seedance 能否量产

Small 档位其实生不了视频，我在活动前 3 天升级到了 Medium 套餐（限时 49.9 元），把 Seedance 1.5 Pro 拉出来做实测。

关于“能否量产”这一点，我的答案是有条件的：“能量产短片段（≤10s / 单镜头），但整片交付仍需要人在剪辑段做拼接。”这条结论我在现场也讲了，因为我不想让观众带走一个“点两下就出电影”的过度乐观预期。

3.3 第 5 天至沙龙前：给沙龙做技术走查与现场准备

我把三位嘉宾（谭俊杰、潘文杰、赵晓丽）的方案粗纲拿到手后，坚持了一个习惯：每一份 PPT 提纲，我都自己在电脑上简单复现一次。

比如潘文杰的 Wiki 知识库思路，我在预演时才发现：“向量化” 这一步如果直接把整篇文档灌进去，效果远不如先切块再向量化（我最后用的是 500 字符/块、50 字符重叠）。这类细节在 PPT 里往往看不到，只有自己跑过才知道。

四、7 月 19 日现场——一场 130 人参加、体感 38 ℃的沙龙

4.1 现场基本信息

• 地点：成都高新区德必天府五街 WE 一楼星际厅
• 主办：Agent Developer Group 成都社区 × 盈创星空科技金融孵化器
• 到场：130 余人（原本预估 80~100 人）

我作为社区 Leader、本场沙龙的总负责人，统筹了从选题立项、嘉宾邀请、场地对接到现场执行的全流程。到场规模超出预期，最后靠加座才把人都安置下来。印象最深的一个细节是：分享结束后 Q&A 环节，观众问的问题几乎全部围绕“落地”两个字——没人问“Agent 是什么”，大家问的都是“怎么算账、怎么并行、怎么防漂移”。这也再次验证了当初选择 Agent Plan 作为主题的判断。

4.2 三条主线，是三种不同的“落地形态”

以下内容我只写自己在现场亲耳听到、亲眼看到、并当场做了笔记的部分，不做二次拔高。

4.2.1 主线一：谭俊杰的 UAVS（Universal AI Video Studio Skill）

谭俊杰是成都云栈科技的产品总监、VIT University 计算机硕士。他讲的是一个非常具体的痛点：Seedance 2.0 能力再强，从“一句创意”到“一部成片”，剧本拆分、资产设定、分镜规划、镜头运动、提示词生成这些环节还是要人干。 UAVS 把这条链路端到端 Agent 化，支持批量任务分解与并行执行。

现场演示很有说服力：他从一句创意出发，用 UAVS 跑出结构化的生产方案与多段成片。我坐在第一排看到 Prompt 里最关键的一点是——“资产设定”是先于“分镜”生成的，这确保了跨镜头的角色一致性。这个顺序在我原本的理解里是反的，是现场才纠正过来的。

我的现场笔记：“UAVS 的价值不是替代 Seedance，而是给 Seedance 装上了流水线的传送带。”

4.2.2 主线二：潘文杰的 Wiki 知识库

潘文杰是成都自然智群科技的创始人。他把 Andrej Karpathy 的 Wiki 理念用 Agent Plan 落地：让模型提前把零散素材“编译”成一部会自动生长、自带交叉引用的 Wiki。

我现场记下的原话是：“知识不再越问越碎，而是越用越厚。”这句话后来直接影响了我自己会后复现方案的思路（见第五章）。

4.2.3 主线三：赵晓丽的 AI 漫剧出海工业化方案

赵晓丽是宇石 AI 的技术总监。她讲的是 OPC 团队最痛的一件事：漫剧内容做得出来，但做不“稳”——角色不一致、多语言字幕对不齐、版本追溯乱、产能没法统计。

执行层 · Agent Plan

协作层 · CDS

剧本管理

素材库

分镜审核

版本追溯

产能统计

剧本 Agent

角色设定 Agent

分镜 Agent

多语言字幕 Agent

她给出的方案是 CDS 协同平台 + Agent Plan 的双层结构：CDS 做团队协作底座，Agent Plan 做智能调度与执行层。现场从一段创意梗概跑到多集完整漫剧成片，全流程演示。

我在笔记本上写的一句话是：“OPC 团队第一次拥有了工业化量产能力”——这不是我的原话，是赵晓丽结尾的总结，我完全同意。

4.3 我作为总负责人在现场收到的三条真实反馈

活动结束后我留在门口送观众，收到三条印象深的反馈，与后续复盘直接相关：

1. “我平时用 Cursor，能不能同时挂 Agent Plan？”——这是一位后端开发者。答案是能，Cursor / Claude Code / TRAE 都支持自定义 OpenAI 兼容端点。
2. “我做小红书图文，Small 够不够？”——一位内容创作者。我的回答是：够做 Wiki 和图，但不够做视频；想做视频得 Medium。
3. “我们公司现在算不算适合上 Agent Plan？”——一位企业技术负责人。我的回答是：个人认证用户先跑 Medium 做技术验证，等团队认知起来了再考虑对公方案；不要一上来就买大档。

五、会后复盘——把三条主线在自己电脑上再跑一遍

沙龙结束后，我给自己设了 3 天时间，把三条主线用自己账号亲手复刻一次，验证学到的方法是不是自己真的能用。

5.1 复盘一：给 ADG 成都社区做一支 30 秒宣传短片（呼应 UAVS）

目标：给 ADG 成都社区做一支 30 秒宣传短片，主题“AI Agent 正在改变成都的开发者社区”。

技术选型：glm-5.2（剧本 / 分镜）+ doubao-seedream-5.0-lite（关键帧）+ doubao-seedance-1.5-pro（Medium 档位支持的视频模型）。

编排思路（学习自 UAVS 的顺序）：先资产 → 后分镜 → 再镜头。这是我从谭俊杰现场分享里学到的顺序，实测比“直接给分镜”效果好——同一角色在 3 幕之间的一致性明显更稳。

AFP 消耗记录（真实数据，不做美化）：

结论：Medium 档位跑完这样一条完整宣传片，占月度 AFP 约 5~6%。对个人开发者来说，Medium 是“能真正做出东西”的分水岭。

5.2 复盘二：把社区两年的活动纪要编译成一部 Wiki（呼应潘文杰）

目标：把 ADG 成都社区两年积累的 300+ 篇活动纪要、技术分享、群聊金句，编译成一部可交叉检索的 Wiki。

关键选择：

• 向量化模型：doubao-embedding-vision
• 编译模型：glm-5.2
• 检索库：本地 Qdrant（Docker 起）
• 分块策略：500 字符 / 块，重叠 50 字符（这是我在预演中踩出来的经验值，直接放到生产就用了）

我把最小可运行代码抽出来，只展示核心两个函数，方便读者复用：

# 环境：Python 3.11 + qdrant-client>=1.7 + requests + 本地 Qdrant Docker
# 依赖：pip install qdrant-client requests
import os, requests
from qdrant_client import QdrantClient
from qdrant_client.http import models as qm

API_KEY = os.environ["VOLC_API_KEY"]# Agent Plan 专属 Key（ark-...）
BASE    = os.environ["VOLC_BASE_URL"]# https://ark.cn-beijing.volces.com/api/plan/v3
EMB_MODEL ="doubao-embedding-vision-250615"# 官方推荐版本，支持 1024/2048 维
DIM     =2048# 与 Qdrant collection 保持一致
qdrant  = QdrantClient(host="localhost", port=6333)

defembed(text:str)->list[float]:
"""把一段文本转成向量，走 Agent Plan 的多模态 embedding 接口。"""
    r = requests.post(
f"{BASE}/embeddings/multimodal",# 多模态 embedding 走 /multimodal 端点
        headers={"Authorization":f"Bearer {API_KEY}"},
        json={
"model": EMB_MODEL,
"input":[{"type":"text","text": text}],# 官方 input 是 object[] 结构
"encoding_format":"float",
"dimensions": DIM,
},
        timeout=30,
)
    r.raise_for_status()
return r.json()["data"][0]["embedding"]

defcompile_wiki_entry(topic:str, top_k:int=5)->str:
"""检索 + 编译一个 Wiki 词条：先向量召回，再交给 glm-5.2 结构化。"""
    q_vec = embed(topic)
# qdrant-client 1.7+ 推荐使用 query_points；1.6 及以下用 search
    hits  = qdrant.query_points(
        collection_name="adg_chengdu",
        query=q_vec,
        limit=top_k,
        with_payload=True,
).points
    ctx ="\n\n".join(h.payload["text"]for h in hits)

    r = requests.post(
f"{BASE}/chat/completions",
        headers={"Authorization":f"Bearer {API_KEY}"},
        json={
"model":"glm-5.2",
"messages":[
{"role":"system","content":
"你是 ADG 成都社区的 Wiki 编译器。请把上下文整理为 Markdown 词条，"
"包含：定义、关键人物、相关活动、交叉引用（用 [[词条名]] 表示）。"},
{"role":"user","content":f"上下文：\n{ctx}\n\n目标词条：{topic}"},
],
},
        timeout=60,
)
    r.raise_for_status()
return r.json()["choices"][0]["message"]["content"]

踩过的三个坑：

1. 向量化不要一次灌一整篇——第一次我直接把 3000 字的活动纪要作为 input，效果远差于切块。
2. 交叉引用要在编译提示词里显式指定（我用 [[词条名]] 语法），否则模型倾向于“平铺”。
3. query_points 调用要显式带 with_payload=True，否则 Qdrant 只返回向量和 id，二次去查原文反而更贵；另外 qdrant-client<1.7 版本仍需用旧的 search() API。

真实数据：

• 300 篇纪要（切完约 1,500 块）一次性向量化：约 3,000 AFP
• 单个高质量词条编译（含 5 段召回，不含豆包搜索）：约 400~500 AFP
• 第一批 30 个核心词条：约 15,000 AFP

写这篇复盘的过程中，Wiki 帮我快速找回了很多历史线索（比如“某次分享嘉宾提到的 Prompt Cache 策略在哪一期”），这是最直观的收益。

5.3 复盘三：一段 60 秒中英字幕漫剧最小产线（呼应赵晓丽）

目标：以 OPC 团队的最小配置，从一段中文创意梗概输出一集 60 秒中英字幕的漫剧片段（不追求出成品，只验证工业化可行性）。

验证的重点是“角色一致性”：赵晓丽在现场提到过，漫剧最容易崩的就是主角在不同镜头里“长得不一样”。我按她讲的做法——在 Visual Agent 里先固化角色卡（一段包含五官、服饰、光影、镜头基调的固定 Prompt 片段），后续所有分镜都以角色卡作为前缀——效果确实稳定了很多。

真实数据（Medium 档位）：一集 60 秒（拆成 6 个 10 秒镜头，720P），总消耗约 8,000~10,000 AFP。上 1080P 会翻倍以上，OPC 早期用 720P 已经足够跑通全流程。

六、把学习收获总结成方法论

把上面这一路走完，我把自己对 Agent Plan 的理解沉淀成三条方法论，供社区里同路人参考：

6.1 方法论一：把“档位”当作学习节奏，而不是消费决策

• Small（9.9 元）：学习教具。用它跑通接入 + 文本 + 图像，验证工作流适配度，不要用它做视频。
• Medium（49.9 元）：主力生产档。多模态齐备（含 Seedance 1.5 Pro），是个人开发者跑内容/编程主战场的最低配置。
• Large / Max：团队 / 出海 / 高并发才用。个人开发者别一上来就跳档，AFP 是花不完但学不会。

6.2 方法论二：先“资产”，再“分镜”，最后“镜头”

这一条来自 UAVS 的现场启发。任何多模态生产链路，都要先固化“角色卡 / 品牌资产”，然后再展开分镜与镜头，否则跨镜头一致性是崩的。

6.3 方法论三：把每一次调用都当“资产”，而不是“消耗”

这一条学自潘文杰。Wiki、素材、Prompt、Skill——只要沉淀下来，AFP 就不是消耗。这也是 Agent Plan 相对纯 API 后付费模式最容易被低估的一点：订阅制天然鼓励你把调用结果结构化保存，而不是每次都重跑。

6.4 三条方法论的整体拼图：一次社区 Leader 的完整学习闭环

把三条方法论放回“输入 → 过程 → 沉淀”的路径中，它们共同构成一个可复利的闭环，如下图所示。

附录

附录 1 作者信息

作者：郭靖（笔名“白鹿第一帅”）

• Agent Developer Group（ADG）成都社区 Leader
• TRAE 成都 Fellow
• CSDN 成都站站长 / 社区之星发起人
• 长期关注方向：AI Agent 工程化、OPC（One Person Company）一人公司、开发者社区运营
• 本次身份：2026-07-19 ADG 成都社区沙龙“创意流水线 · 知识炼金术——火山引擎 Agent Plan × Seedance 2.0 成都实践场”总负责人（主办 & 现场统筹）

附录 2 参考资料

1. 火山引擎 Agent Plan 官方产品页：https://www.volcengine.com/activity/agentplan——套餐介绍、限时优惠、模型清单
2. 火山方舟控制台 · 开通管理页：https://console.volcengine.com/ark——本人开通、订阅、AFP 用量查询的实际入口
3. 火山方舟 · Agent Plan 个人版《套餐概览》官方文档：https://www.volcengine.com/docs/82379/2366394——Small / Medium / Large / Max 四档权益、模型上下文长度、视频模型准入
4. ADG 成都社区 2026-07-19 沙龙“创意流水线 · 知识炼金术——火山引擎 Agent Plan × Seedance 2.0 成都实践场”活动回顾（微信公众号）：https://mp.weixin.qq.com/s/PFLJtVp803s3CztiwEvYVg——本文所有现场描述的原始出处
5. Qdrant 官方文档 · 向量检索与 payload 用法：https://qdrant.tech/documentation/——用于第 5.2 节 Qdrant 部分的技术核对
6. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks（RAG 原始论文，Lewis et al., 2020）：https://arxiv.org/abs/2005.11401——用于第 5.2 节切块 / 召回策略的理论背书

总结

回看这五周，我最大的收获不是“多学了一款工具”，而是重新认识到：在 AI Agent 快速演进的当下，评估一款产品的最好方式，不是把参数表读一遍，而是把它嵌进一件真实的事里跑一遍。这篇文章里的每一条 AFP 数字、每一次踩坑、每一张流程图，都源自我为 ADG 成都社区 7 月 19 日那场 130 人沙龙做立项、走查、现场统筹与会后复盘的全过程，因此火山引擎 Agent Plan 对我而言不再是抽象的“多模态订阅套餐”，而是一套可以真实支撑视频生产、知识资产与内容出海三条主线的工程底座。我把这段路径抽象成三条方法论：把档位当作学习节奏而非消费决策、任何多模态链路都先固化资产再展开分镜与镜头、把每一次调用都当作可复利的资产而非一次性消耗。如果你和五周前的我一样仍在观望，最扎实的路径永远只有一条——用 9.9 元的 Small 跑一次自己的“接入 → 图像 → Wiki”闭环，把过程记录下来，你会拥有属于自己的答案。技术的浪潮还在继续，我们，Agent 里见。

我是白鹿，一个不懈奋斗的程序猿。望本文能对你有所裨益，欢迎大家的一键三连！若有其他问题、建议或者补充可以留言在文章下方，感谢大家的支持！