视频检索平台需要 Agent 吗？

从视频语义检索和聚合笔记出发，记录我与 AI 怎样反复追问 Agent 的必要性，逐步讨论到状态感知排障、经验检索，以及仍需验证的视频价值。

我最初想做一个视频检索平台。用户上传一些视频，描述某个画面或某件事情，系统就能找到对应的视频和时间点；再往后，还能关联不同视频，整理笔记，做聚合分析。

但我不太确定，里面的 Agent 究竟应该干什么。

如果只是找出一段素材，多模态检索系统已经能承担相当一部分工作。接上聊天界面，或者让模型自动生成笔记，并不能说明 Agent 有必要存在。我想找的是一种需要它根据中间结果作出判断、调整行动的任务。

于是，我带着这个问题和 ChatGPT 做了一轮讨论：视频检索用于学习时，是否应该以帮助理解为核心？再往下推，用户到底缺少什么？

讨论没有沿着最初的方向一路走下去。AI 先提出学习助手，又提出操作排障；先建议做开发工具，后来又修正这个建议。我的两次选择缩小了用户场景，而“为什么不直接用 ChatGPT”这个问题，在几轮回答里反复出现。下面按对话发生的顺序记录这些变化。文中的产品方案和实验都还停留在讨论阶段。

第一轮：先看视频提供什么，再看学习缺什么

AI 先追问了一个更早的问题：人为什么会选择视频？

讨论给出的几个理由是动态过程、情境信息和难以说完整的操作细节。视频可以同时展示老师说了什么、屏幕上出现了什么，以及操作如何一步步改变结果。只提取字幕，可能会丢掉恰好最有用的部分。

然后，AI 把学习中的需求分成了三个层次：找到知识、建立理解，以及迁移与验证。

找到知识比较直观。对话用了一个例子：用户记得某个老师讲过 Go Channel 阻塞，却不记得在哪个视频、哪个时间点。关键词、字幕、画面文字和向量检索，都可以参与定位。这个阶段未必需要 Agent。

建立理解更复杂一些。找到了片段，用户仍然不明白为什么会阻塞；另一个老师的解释似乎还不一样。此时需要回看代码与上下文，比较两段解释的前提，而不能只返回几个相关时间戳。

再往后，是判断自己能否在新情境里使用这些知识。看懂了视频中的程序，换一段代码，还能不能预测它的行为？AI 因此把最初的“帮助理解”继续往前推，提出让系统通过新例子、练习和反馈，判断用户是否真正掌握了。

这时，Agent 的候选价值才具体起来：它需要判断用户究竟卡在哪个概念，现有证据够不够，接下来应该补充解释、比较另一段视频，还是让用户尝试一道题。

判断 Agent 是否有必要，可以先看任务中有没有需要根据反馈不断调整的决策。 自动生成摘要、按固定顺序调用几个工具，都还不足以回答这个问题。

笔记的组织方式也随之发生了变化。最初想的是视频 A 生成笔记 A，视频 B 生成笔记 B；后来讨论的是围绕“Channel 为什么阻塞”这样的具体问题，把不同片段、解释、练习和理解误区放在一起。

不过，这还只是一个学习助手的设想。AI 随即对自己的建议提出了反问：如果用户只是想理解 GMP 调度，直接问 ChatGPT，为什么不行？

第一轮回答给出的边界是：当答案依赖某段视频中的具体演示、操作过程、实验结果，或者多个来源之间的关系时，回到视频证据才更有意义。

这个回答没有证明视频普遍不可替代，只是把可能有用的范围缩小了。

我第一次选择：帮助正在操作、却卡住的人

第一轮结束时，AI 给了我两个方向：帮助已经看过视频但忘记、没理解的人，或者帮助正在实际操作、卡在某一步的人。

我选择了后者：

「正在实际操作、卡在某一步不知道怎么继续的人」

AI 据此把方向改成了“基于视频经验的交互式问题解决 Agent”。用户要解决的事情也随之变了：找到一个操作示范以后，系统还需要帮助用户判断自己的状态，并决定下一步。

对话用了一个假设场景：用户参考 Kubernetes 教程部署服务，老师成功了，用户的 Pod 却一直处于 Pending。此时用户需要知道自己走到了哪一步、预期结果是什么、实际结果有什么不同，以及接下来该查什么。

只知道视频里发生过什么还不够，Agent 也得知道用户现在发生了什么。

于是，用户当前的截图、日志和终端输出进入了产品模型。Agent 先取得这些信息，对比预期与实际状态，提出一个排查动作，再根据结果继续调整。它不能只围绕原视频反复搜索。

索引单元先从片段变成操作步骤

这一轮里，AI 先提出了 Procedure，也就是操作流程的抽象。每一步除了时间戳，还应该记录前置条件、操作、预期状态、成功证据，以及已知的失败表现和恢复办法。

这些信息的作用，是帮助判断某个演示是否适合当前用户。两个视频都在“运行服务”，一个用 Docker Compose，一个用 Kubernetes，不能因为主题相似就把步骤混着推荐。

Agent 的动态判断也有了更明确的对象：它可以先决定还缺什么证据。面对 Pod Pending，先要求查看 Events，再根据实际输出决定下一项检查，比直接生成一篇完整的 Kubernetes 原理解释更贴近现场。

但“为什么不用通用 AI”的问题又回来了。即使通用助手也能看截图、指导操作，专门做一个产品还能多提供什么？

这一轮给出的回答，是把当前状态与过去的具体经验对照起来，并检查版本、配置和操作条件是否一致。视频引用要能支持这次判断，而不能只是答案后面附上的装饰。

同一轮讨论也留下了一条限制：如果日志和官方文档已经足够，就应该优先使用它们，不能为了体现视频能力而强行搜索视频。

第一版 MVP，当时还偏向开发工具

考虑到我的 Go 后端和基础设施方向，AI 此时建议先做编程、开发工具与 DevOps 操作教程。理由是日志比较容易取得，操作是否成功也相对容易判断。

当时的最小可行版本（MVP）是：准备同一任务的 3～5 个教程，建立步骤索引；用户点击“我卡住了”，提交截图或日志；Agent 对比状态，给出带视频依据的下一步，用户执行后再反馈。

第一版不需要持续观看整个屏幕。先让用户主动提交信息，检验它能不能提高卡点解决率、缩短解决时间、减少无效排查，比先做好实时交互更有意义。

这个建议后来被重新审视了。它适合验证排障流程，却未必适合验证视频本身的价值。

第二次选择：我选了独立操作时按需求助

在继续往下推之前，AI 又把使用场景分成了两种模式。

模式 A 是伴随式学习：用户正在跟着某个视频操作，Agent 帮助识别哪一步偏离了演示。模式 B 是按需式经验求助：用户本来就在独立完成任务，遇到问题后，Agent 才去寻找相关视频经验。

我选择了 B：

我更倾向 B：独立操作时遇到问题，Agent 检索视频经验来解决。继续从第一性原理推导产品。

这次选择进一步改变了产品的起点。用户未必看过某个教程，甚至未必知道自己需要什么教程。系统也就不能默认，先有一个视频，再帮助用户理解它。

用户先有任务和卡点，资料在后面才被找出来。

选完 B，AI 却再次追问：为什么一定要视频

我原本要求继续推导产品，AI 的下一轮回答却先挑战了前提：用户遇到问题时，为什么一定要搜索视频？为什么不直接问 ChatGPT？

这个问题已经出现过，但放到模式 B 里更难回避。用户没有复习原课程的需求，也不一定关心答案来自哪种媒介。即使视频数据库、检索增强生成（RAG）和 Agent 都做出来了，也可能没有独立使用的理由。RAG 能让模型先取得资料再作答，但取得资料仍不等于解决问题。

于是讨论再次把技术名词拿掉，只保留用户的任务。AI 换了一个 Blender 材质操作的假设场景：用户有期望效果，也有当前效果，却不知道两者之间差在哪里。

此时需要解决三件事：认清当前状态，选择下一步行动，判断行动有没有带来改善。对话把它称为 Goal-oriented Troubleshooting，即面向目标的问题诊断和解决。

视频能参与其中，是因为它记录了操作前后的变化。一个材质教程除了说出参数值，还可能展示操作者选中了哪个对象、进入了哪个面板、其他设置是什么，以及调整后画面怎样变化。老师没有说出口的条件，也可能留在画面里。

但这并没有让视频成为唯一可靠的依据。AI 紧接着补上了反例：视频里连续修改三个参数，最后效果正确，并不能据此确认究竟哪个参数起了作用。

视频中的先后顺序不能直接当作因果关系，成功演示也不能自动变成故障解决经验。

讨论到这里，几种证据有了各自的用途：视频展示过程，文档说明规则与约束，当前环境提供实际状态，历史排障记录补充失败与恢复过程。Agent 需要判断这次该用哪一种，以及它们之间能否互相印证。

Experience：检索与当前条件相符的操作经验

在前一轮的 Procedure 之后，AI 进一步提出了 Experience，也就是经验单元。

相似的视频片段未必能解决相同的问题。还需要核对用户目标、初始状态和环境条件。一个经验单元可以包含：

对话暂时把这种方向叫作 Experience Retrieval，经验检索。它是为了让数据组织更贴近问题，不意味着立刻开发一种新数据库。

这里容易混淆的是 Result State 和 Outcome。前者记录发生了什么，后者记录结果有没有达到目标、是否经过确认。Agent 提出了一条建议，并不等于已经得到一条成功经验。

这也让聚合笔记有了更具体的位置：围绕一个问题，保留当时条件、参考证据、做过的尝试和实际结果。它可以供后来的人复用，但前提是不能把未经验证的推断写成事实。

Agent 的循环：每一步都要能看到反馈

有了目标、状态和经验，Agent 要负责的过程才逐渐收敛。对话把它称为 State-aware Troubleshooting Agent，状态感知的排障 Agent。

它围绕同一个目标反复做五件事：

1. Observe，观察。 取得用户当前的截图、日志与环境信息。
2. Hypothesize，提出假设。 根据已有证据，判断可能的原因，并保留不确定性。
3. Retrieve，检索。 寻找条件相符的操作经验和其他证据。
4. Act，行动。 建议一个可以执行、可以检查结果的下一步。
5. Verify，验证。 看执行后是否改善；没有解决，就更新假设和下一轮观察。

在这个产品设想里，Act 首先可以是用户执行建议，不必一开始就让 Agent 接管软件。关键在于执行结果能否回来，成为下一次判断的依据。

原对话仍用 Blender 材质不正确作为例子。Agent 未必应该立刻搜索这个宽泛问题，而可能先确认渲染引擎、版本和材质设置。确认以后，检索范围和建议才会变化。

因此，Agent 的价值不只在于组织答案，还在于决定当前最值得获得哪条信息。如果输入不完整，它需要先取得证据；如果证据不支持原来的猜测，它需要换一种解释。

这是一个待实现的工作循环。把五个英文词排出来，仍然没有证明系统能可靠完成它。

方案逐渐具体以后，两个陷阱又把它往回拉

第一个陷阱，是视频里可能根本没有所需的经验。

一段顺利部署 Kubernetes 应用的教程，未必出现过 ImagePullBackOff。检索再准确，也找不出视频中不存在的排障过程。正常操作示范能帮助确认预期流程，却不能因此被标成解决过这种故障的案例。

AI 因而把经验积累放到了后续阶段：用户在 Agent 协助下完成一次排障，经过允许，再保存真实的错误、操作和结果。教学演示与实际排障记录可以互补，但成功案例必须经过确认。

这时才出现了一个可能的长期优势：积累条件清楚、结果可追溯的经验。不过，这仍然是产品假设。没有足够的真实问题和结果反馈，数据不会因为多用几次模型就自动变得可靠。

第二个陷阱，是内容准备的成本。

用户独立操作时突然卡住，会愿意先上传十小时教程、等待索引吗？模式 B 越明确，这个问题越突出。准备资料花掉的时间，可能已经超过求助本身。

讨论因此转向预先准备某个领域的内容，而非要求每个用户从零建立视频库。来源可以是经过授权的教程、用户自己的录屏，以及企业已有的 SOP 和培训材料。具体选哪种供给方式，当时没有定下来。

竞争差异也得重新回答

原对话曾用视频搜索、材料问答和屏幕辅助类工具提醒我们：不能只依靠“能检索视频”“能看屏幕”或“能生成笔记”来解释产品价值。这些提醒没有经过完整的竞品实测，不能当作市场结论。

更需要检验的差异是：在一个具体领域，系统能否更准确地匹配环境和操作状态，提出更少的错误建议，并帮助用户完成任务。带时间戳的答案只有实际支持判断，才值得用户为它增加一个工具。

AI 修正了前面的建议：DevOps 未必适合证明视频价值

讨论到垂直场景时，AI 明确回头修改了自己先前的建议。

Go、Docker、Kubernetes 适合展示我的后端与 Agent 工程能力，却不一定适合证明视频经验检索有用。很多故障可以通过日志、配置和官方文档定位。如果视频只是额外出现的引用，产品即使解决了问题，也没有说明视频带来了什么。

于是候选方向转向视觉操作更密集的软件：Blender、剪辑工具，以及设计软件。这些任务的界面状态、操作顺序和结果变化可能更值得对照。实验和设备维修也有过程性信息，但安全与准确性要求更高。

这不是一份已经验证的市场需求排名，也不是断言开发工具没有机会。它区分了两个目标：验证排障 Agent 的工程流程，和验证视频证据的增量价值。前者跑通，不能替后者作答。

后来的 MVP，缩到了 Blender 的一个小问题域

到这一轮后半段，MVP 已经缩成 Blender 材质与修改器操作排障。

设想是找一小组有使用授权的教程，整理时间戳、关键画面与操作步骤。用户提交当前截图和期望结果，Agent 根据环境与状态找到相关片段，提出下一项检查，再等待反馈。

原对话给过一个交互示例：用户想做出透明玻璃效果，Agent 先说明仅凭截图不能确定原因，要求确认渲染引擎，并引用展示相关设置的教程片段。

这是示例，不是真实诊断。它表达的是一轮交互的分寸：尽量给出一个有依据、能验证的下一步，避免一次扔出十种可能，让用户自己承担全部筛选工作。

我们还没有在 DevOps 与 Blender 之间作出经过验证的最终选型。这一轮只是更清楚地发现，选择场景时必须问：视频画面究竟补上了什么？

A/B/C 实验：允许结果推翻整个方向

最后，讨论把问题从“怎样做出来”拉回“怎样知道值得做”。AI 建议收集 20～30 个真实问题，对比三种方案：

这里的 B 是实验组，与前面“独立操作时按需求助”的模式 B 含义不同。

观察指标也不再是生成多少笔记、返回多少片段，而是问题解决率、解决耗时、错误建议次数，以及用户付出的操作成本。

如果 B 与 A 几乎没有区别，就需要怀疑视频检索的核心假设；如果 C 比 B 更好，才有理由进一步检验状态建模与动态诊断的作用。若用户不愿准备视频，则需要调整内容供给，而不是继续增加技术模块。

最后留下的问题，比最初更具体了

讨论结束时，AI 暂时把产品定义为：从真实操作视频和历史解决案例中取得经验，理解用户当前状态，动态指导用户完成任务的 Agent。

紧接着，它又提出了一个尚未由我回答的选择：我们是在做一个拥有 Agent 的视频知识库，还是一个能够使用视频知识库的 Agent？

前者更看重视频资产和索引能力，后者要对解决问题的过程负责，视频是它可能使用的证据之一。AI 在当时明显更倾向后者，但这还不是已经验证、由双方最终拍板的产品定位。

我明确选定的是使用情境：帮助独立操作、遇到卡点的人。至于这个情境能否支撑一个独立产品，讨论还没有给出证据。

剩下的问题至少包括：哪些卡点确实依赖视频中的过程信息？通用助手加上合适资料之后还差多少？可靠且可持续使用的内容从哪里来？当前状态能否被准确识别？用户愿意提交多少信息，又愿意等多久？经验的成功结果由谁确认？

这轮讨论改变了最初的问题。开始时，我想知道如何给视频检索平台加一个有价值的 Agent；到最后，更值得检验的是，在什么任务里，视频经验能够帮助 Agent 提高解决问题的能力。