影片筆記:Codex要是抄一下Kimi Code这个功能就好了!
YouTube 影片框會固定在左上方;點擊右側逐字稿時間戳可跳到對應時間。
一句話總結
影片探討了 Kimi Code 在多模態視頻理解上的技術優勢,指出其通過將視頻作為「時空塊」編碼而非僅抽幀,能更好地保留時間維度信息(如節奏、因果關係),從而優於僅支持圖片層級的 Codex 和 Claude Code。作者建議開發者關注模型廠推出的工具鏈(Harness)與新服務,以搶先獲取技術紅利。
核心重點
視頻理解機制差異:
- 主流 Agent (Codex, Claude Code, OpenCode):處理視頻時採用「抽幀」方式,將視頻拆解為多張獨立圖片,丟失幀與幀之間的變化關係,處於「殘血」狀態。
- Kimi Code:將連續幾幀視為一個「時空塊」進行編碼,保留時間維度信息(動作、轉場、節奏、因果關係),並明確將視頻放入上下文(Context)及 Agent 循環中。
實測對比結果:
- 在復刻遊戲 Demo、粒子動畫及複雜敘事視頻時,Kimi Code 表現更佳。
- Codex 僅給視頻片段效果差;即使提供時間戳對齊字幕,仍將運鏡效果做成 PPT,視覺呈現差。
- Kimi Code 能更好地對齊原始音頻,模擬攝像機運鏡效果,並支持同時讀入兩個視頻(原始視頻與成品)進行精修迭代。
潛在商業機會:
- 構建「剪輯與敘事經驗知識庫」:在符合道德和版權約束下,將授權或開源視頻作品通過視頻理解,蒸餾成知識庫。
- 自動化流程:Agent 在知識庫中檢索類似案例經驗,結合腳本核查提取敘事與動畫方案,通過 HyperFrame 等框架快速實現動畫。
行業洞察與建議:
- 模型廠的 Harness(工具鏈)不是殼,而是模型能力的放大器與技術路線的風向標。
- Kimi K2.7 Code 推出高速版(6倍速度,3倍價格),反映生產流程跑通用戶對「將 Token 轉化為成果」的速度有剛需。
- 建議開發者不要只等模型變強,要關注工具如何讓模型能力被看到,並儘快在新能力上跑通工作流以獲取紅利。
詳細大綱
一、 核心發現:Kimi Code 的視頻理解機制
- 現象觀察:Kimi Code 能完整復刻 Fable5 遊戲 Demo 及中國功夫粒子動畫,甚至包含錄屏時誤入的播放控件。
- 技術差異:
- 主流 Agent:僅支持圖片層級,處理視頻時採用「抽幀」方式,將視頻拆解為多張獨立圖片。這導致丟失幀與幀之間的變化關係。
- Kimi Code:明確將視頻放入上下文(Context)及 Agent 循環中。參考《Kimi K2.5: Visual Agentic Intelligence》論文,Kimi Code 將連續幾幀視為一個「時空塊」進行編碼,而非孤立截圖。它保留了時間維度信息(動作、轉場、節奏、因果關係)。
二、 實測對比:Kimi Code vs. Codex
- 實驗對象:SpaceX IPO 解讀視頻(含複雜敘事邏輯與動畫展示)。
- Codex 表現:
- 僅給視頻片段:效果差,無法從截圖中找到邏輯。
- 提供時間戳對齊字幕:仍將運鏡效果做成 PPT,視覺呈現效果差。
- 限制:上下文由服務端管理,視頻內容肯定未以原始形態保留。
- Kimi Code 表現:
- 更好地對齊原始音頻。
- 模擬出攝像機運鏡效果,表達有邏輯。
- 支持同時讀入兩個視頻(原始視頻與成品)進行精修迭代,此功能為其他工具暫不支持。
- AE 動畫測試:Kimi Code 不僅復刻視覺效果,還復刻了動畫節奏與轉場時機,這依賴於時間維度信息的保留。
三、 潛在商業機會:AI 輔助視頻製作工作流
- 構建知識庫:在符合道德和版權約束下,將授權或開源視頻作品通過視頻理解,蒸餾成「剪輯和敘事經驗的知識庫」。
- 自動化流程:
Agent 在知識庫中檢索類似案例經驗。
結合腳本,核查提取敘事與動畫方案。
通過 HyperFrame 等框架快速實現動畫。
- 價值主張:博主只需構思內容,表達與製作交給 Agent。
四、 Kimi Code 的其他技術特性與擴展
- 模型接入:支持其他模型接入。
- 本地部署能力:
- 修改代碼後,本地部署的 Qwen3.6 27B 也能實現視頻駐留上下文。
- 實現了本地模型分析帶音軌視頻的功能(對音頻類型留有接口)。
- Agent Swarm 支持:
- 網頁版功能現已在 Kimi Code 中直接支持。
- 示例:同時讀入兩個視頻佔用 40% 上下文後,可啟動 Agent Swarm 進行後續任務,主 Agent 無需觸發 Compact(壓縮上下文)。
五、 行業洞察與建議
- Harness 的意義:模型廠的 Harness 不是殼,而是模型能力的放大器與技術路線的風向標。
- 高速版信號:Kimi K2.7 Code 推出高速版(6倍速度,3倍價格),反映生產流程跑通用戶對「將 Token 轉化為成果」的速度有剛需。
- 行動建議:
- 不要只等模型變強,要關注工具(Harness)如何讓模型能力被看到。
- 最先理解模型廠技術路線、在新能力上跑通工作流的開發者,將最早拿到紅利。
工具 / 模型 / 名詞整理
- Kimi Code:Kimi 推出的工具,被描述為對原先 Kimi CLI 的重構和升級。
- Kimi CLI:Kimi 原先的工具,Kimi Code 是其升級版。
- Kimi K2.7:Kimi 發布的模型。
- Kimi K2.7 Code:搭配 Kimi K2.7 的模型/工具版本。
- Kimi K2.5:提及的模型版本,相關論文為《Kimi K2.5: Visual Agentic Intelligence》。
- Anthropic:公司名稱。
- Fable5:Anthropic 發布的模型(原文聽寫為 Fable5,疑點見下)。
- Codex:OpenAI 的模型/工具,文中多次作為對比對象。
- Claude Code:Anthropic 的 Coding Agent。
- OpenCode:主流 Coding Agent 之一。
- Higgsfield:提及的平台或工具名稱(用於 Fable5 遊戲 Demo)。
- HyperFrame:視頻製作工具/框架。
- Qwen3.6 27B:本地部署的模型名稱(疑點見下)。
- Agent Swarm:Kimi Code 中支持的 Agent 架構功能。
- 牛马 Agent:作者自稱使用的 Agent 體系名稱。
- Base64:數據編碼格式。
- Harness:文中多次出現「模型厂的Harness」,通常指代工具鏈或框架,此處用法較特殊,保留原詞。
- Compact:在 Agent Swarm 語境下提及「主 Agent 再也不用触发 Compact」,Compact 指上下文壓縮機制,此處用法符合技術語境,但需確認是否為特定術語。
操作流程整理
視頻理解與復刻:
- 輸入視頻(如遊戲 Demo、粒子動畫、敘事視頻)。
- Kimi Code 將視頻作為「時空塊」編碼,保留時間維度信息。
- 復刻視覺效果、動畫節奏、轉場時機及攝像機運鏡效果。
- 對齊原始音頻。
精修迭代:
- 同時讀入兩個視頻(原始視頻與成品)。
- 佔用上下文(如 40%)。
- 啟動 Agent Swarm 進行後續任務。
- 主 Agent 無需觸發 Compact(壓縮上下文)。
自動化視頻製作工作流:
- 構建知識庫:將授權或開源視頻作品通過視頻理解,蒸餾成「剪輯和敘事經驗的知識庫」。
- Agent 檢索:在知識庫中檢索類似案例經驗。
- 方案核查:結合腳本,核查提取敘事與動畫方案。
- 動畫實現:通過 HyperFrame 等框架快速實現動畫。
值得注意的限制或風險
- 主流 Agent 的局限性:Codex、Claude Code、OpenCode 等主流 Agent 僅支持圖片層級,處理視頻時採用「抽幀」方式,丟失幀與幀之間的變化關係,屬於「殘血」狀態。
- 上下文管理限制:Codex 的上下文由服務端管理,視頻內容肯定未以原始形態保留。
- 版權與道德約束:構建知識庫時需符合道德和版權約束,僅限授權或開源視頻作品。
- 訂閱成本:作者提及自己訂閱價格為 200 刀,需查證對應哪個平台的訂閱等級及具體服務內容。
逐字稿辨識疑點
- Fable5:原文聽寫為「Anthropic的Fable5」,通常 Anthropic 的模型為 Claude 系列,此處名稱存疑,需查證是否為特定內部模型名稱或聽寫錯誤(如可能是 Flux 或其他模型,但不得自行更正)。
- Qwen3.6 27B:原文提及「本地部署的Qwen3.6 27B」,Qwen(通義千問)版本號通常為 1.5, 2, 2.5, 3 等,「3.6」版本號存疑,需查證是否為聽寫錯誤(如 Qwen2.5 或 Qwen3)。
- Higgsfield:原文提及「higgsfield里的Fable5做的游戏的demo」,Higgsfield 為一公司名,此處指代存疑,需查證具體產品或平台名稱。
- Harness:文中多次出現「模型厂的Harness」,通常指代工具鏈或框架,此處用法較特殊,保留原詞。
- Compact:在 Agent Swarm 語境下提及「主 Agent 再也不用触发 Compact」,Compact 指上下文壓縮機制,此處用法符合技術語境,但需確認是否為特定術語。
- 200刀的订阅:作者提及自己訂閱價格,指代具體服務套餐,需查證對應哪個平台的訂閱等級。
可延伸追問
Kimi Code 的「時空塊」編碼具體技術實現細節為何?與傳統抽幀方法在計算資源消耗上有何差異?
如何確保在構建「剪輯與敘事經驗知識庫」時,嚴格遵守版權與道德約束?
Kimi K2.7 Code 的高速版(6倍速度,3倍價格)具體適用於哪些場景?其性價比如何評估?
Agent Swarm 在 Kimi Code 中的具體應用場景有哪些?除了視頻製作,是否適用於其他多模態任務?
本地部署的 Qwen3.6 27B 實現視頻駐留上下文的功能,對硬件配置有何要求?
逐字稿時間軸
右側可一路往下捲;左側影片框會固定。點擊時間戳會讓左側影片跳到對應秒數。
00:00:00.033 → 00:00:02.833
朋友们我真的没有碰瓷Codex的意思
00:00:03.066 → 00:00:05.750
但是在视频理解这个多模态场景
00:00:05.900 → 00:00:07.950
很可能你用的Coding Agent
00:00:07.950 → 00:00:09.100
一直都是残血
00:00:09.433 → 00:00:10.750
那谁不是残血
00:00:11.066 → 00:00:13.783
所有搭配了Kimi Code的多模态模型
00:00:14.700 → 00:00:16.150
我说的是所有模型
00:00:16.350 → 00:00:18.783
我知道Kimi刚发的K2.7很强
00:00:18.983 → 00:00:21.466
但本期视频不是模型测评
00:00:21.500 → 00:00:24.150
请跟我把注意力都放在Kimi Code上
00:00:24.350 → 00:00:26.233
我要分享一个新的发现
00:00:26.383 → 00:00:27.583
在多模态领域
00:00:27.583 → 00:00:29.900
它到底是补齐了什么样的能力
00:00:30.066 → 00:00:32.750
以及它可能带来的一个重大商机
00:00:33.783 → 00:00:35.033
但内容很好理解
00:00:37.150 → 00:00:38.266
事情是这样子的
00:00:38.700 → 00:00:41.583
不是Kimi推出了Kimi Code这个工具吗
00:00:42.350 → 00:00:45.500
是对原先Kimi CLI的一次重构和升级
00:00:45.750 → 00:00:47.783
而且官方在浓墨重笔的强调
00:00:47.783 → 00:00:49.233
它的视频理解能力
00:00:49.300 → 00:00:51.833
最近不是Anthropic的Fable5也出了
00:00:51.900 → 00:00:54.700
随即Kimi K2.7 Code的这个模型也发布了
00:00:54.750 → 00:00:56.266
那我就想着我也试试吧
00:00:56.266 → 00:00:58.500
拿它来和Fable5比一比
00:00:59.666 → 00:01:00.950
我看到一位推友发的
00:01:00.950 → 00:01:04.266
用higgsfield里的Fable5做的游戏的demo
00:01:04.433 → 00:01:05.950
于是呢我就录了个屏
00:01:06.150 → 00:01:08.433
把这个视频丢给了Kimi Code
00:01:08.583 → 00:01:11.500
我的提示词就几个字读取这个demo
00:01:13.033 → 00:01:14.750
它居然就做出来了
00:01:14.783 → 00:01:15.983
不能说完全一样
00:01:18.183 → 00:01:19.833
我又找了一个Fable5实现的
00:01:19.833 → 00:01:21.833
中国功夫的粒子动画的Demo
00:01:21.866 → 00:01:24.500
我的提示词是让它1:1的复刻
00:01:24.950 → 00:01:26.350
它不仅实现了
00:01:26.350 → 00:01:28.033
甚至还把我录屏时
00:01:28.033 → 00:01:30.350
不小心录进去的视频播放控件
00:01:31.866 → 00:01:33.750
我后来还测试了很多Demo
00:01:33.750 → 00:01:35.033
全部都复刻出来了
00:01:35.150 → 00:01:37.300
可是官方在发布Kimi Code的时候
00:01:37.300 → 00:01:38.950
他就在强调视频能力的
00:01:38.950 → 00:01:42.233
但那个时候K2.7还没发布啊
00:01:42.233 → 00:01:43.550
难道说这个能力
00:01:43.550 → 00:01:46.066
关键在于Kimi Code这个工具本身
00:01:46.300 → 00:01:47.466
那么带着这个疑问
00:01:47.466 → 00:01:49.433
我就开始分析Kimi Code的代码
00:01:49.433 → 00:01:50.900
以及主流的Coding Agent
00:01:50.900 → 00:01:52.700
我想看看到底有什么区别
00:01:53.066 → 00:01:54.750
欸还真让我猜中了
00:01:54.866 → 00:01:57.300
我调查了所有主流Agent里
00:01:57.383 → 00:01:58.633
只有Kimi Code
00:01:58.633 → 00:01:59.900
它的这一套链路
00:01:59.900 → 00:02:02.583
明确的把视频放进了上下文
00:02:02.583 → 00:02:04.300
放进了Agent循环中
00:02:04.583 → 00:02:06.266
所以它在执行任务的过程中
00:02:06.266 → 00:02:08.033
始终都会有视频的信息
00:02:08.066 → 00:02:11.233
那我们用ClaudeCode或者是Codex OpenCode
00:02:11.383 → 00:02:12.700
它们当下的版本
00:02:12.700 → 00:02:14.900
都只支持到了图片这一层
00:02:15.183 → 00:02:16.950
一旦这类工具读取了视频
00:02:16.950 → 00:02:18.866
他们都会用抽帧的方式
00:02:18.866 → 00:02:19.983
来读许多张图
00:02:19.983 → 00:02:21.383
来实现视频理解
00:02:22.550 → 00:02:23.866
这个确实也够用了
00:02:23.866 → 00:02:25.700
比如说你复刻一个网页游戏
00:02:25.750 → 00:02:26.700
通过几张图(关键帧)
00:02:26.700 → 00:02:28.066
你就能理解出整个游戏
00:02:28.066 → 00:02:30.066
或者是前端界面的交互逻辑
00:02:31.550 → 00:02:33.950
抽帧理解视频其实是残血的
00:02:34.150 → 00:02:36.033
因为Kimi Code的代码告诉我
00:02:36.033 → 00:02:38.233
视频它不是多张图
00:02:39.183 → 00:02:40.500
我恍然大悟啊
00:02:40.500 → 00:02:41.433
我仔细分析了Kimi在
00:02:41.433 → 00:02:44.883
《Kimi K2.5: Visual Agentic Intelligence》这篇论文的描述
00:02:45.483 → 00:02:48.466
它不是简单的把视频拆成多张图的
00:02:48.583 → 00:02:49.866
它是把连续的几帧
00:02:49.866 → 00:02:51.900
当做一个时空块来编码
00:02:52.383 → 00:02:54.300
模型看到的不是孤立的截图
00:02:54.300 → 00:02:56.500
而是这些截图之间的变化关系
00:02:56.633 → 00:02:57.666
这个就很关键
00:02:57.666 → 00:02:59.900
因为视频里的动作转场节奏
00:02:59.900 → 00:03:01.033
速度因果关系
00:03:01.033 → 00:03:02.633
它都不在一张图里
00:03:02.766 → 00:03:04.433
而在图和图之间
00:03:04.583 → 00:03:05.500
那抽帧的方案
00:03:05.500 → 00:03:07.300
你看到只是一个状态
00:03:07.383 → 00:03:07.550
但视频的上下文看到的是整个的过程
00:03:07.550 → 00:03:10.383
但视频的上下文看到的是整个的过程
00:03:10.783 → 00:03:11.550
这就是为什么说
00:03:11.550 → 00:03:13.266
如果你使用的是Claude Code这种
00:03:13.266 → 00:03:15.783
只是通过抽帧方式的Coding Agent
00:03:15.783 → 00:03:17.550
用它来使用K2.7
00:03:17.550 → 00:03:18.583
那这个视频任务里
00:03:18.583 → 00:03:21.033
就会少掉一部分时间维度的信息
00:03:21.033 → 00:03:22.750
因为你把视频拆成帧了
00:03:22.950 → 00:03:25.183
帧和帧之间的变化关系就会失真
00:03:26.950 → 00:03:29.066
那时间这个信息就这么重要吗
00:03:29.983 → 00:03:32.350
难道不能推理出前后的逻辑吗
00:03:32.433 → 00:03:33.983
于是我又做了一个实验
00:03:34.300 → 00:03:36.266
我有一位很喜欢的财经类博主
00:03:36.266 → 00:03:39.466
他前年发布了一段对SpaceX IPO的解读
00:03:39.500 → 00:03:41.266
哇那段桥的故事
00:03:41.300 → 00:03:43.833
无论是叙事逻辑还是动画展示
00:03:43.866 → 00:03:45.266
都堪称是经典
00:03:45.466 → 00:03:47.433
那我用这段做了一个小的测试
00:03:47.433 → 00:03:49.983
我考验了Kimi Code和Codex
00:03:50.066 → 00:03:51.583
能不能通过理解视频
00:03:51.583 → 00:03:54.300
再通过HyperFrame这种视频制作工具
00:03:54.300 → 00:03:56.300
完整的把这个故事讲出来
00:03:56.750 → 00:03:58.266
但是我要先叠个厚厚的甲
00:03:59.066 → 00:04:01.633
我只是为了测试Harness的能力边界
00:04:01.633 → 00:04:03.183
所以才用了这段做测试
00:04:03.633 → 00:04:05.866
我也完全不赞同用多模态模型
00:04:05.866 → 00:04:08.100
蒸馏其他视频博主的剪辑
00:04:09.700 → 00:04:11.833
我更想通过这个视频提醒各位博主
00:04:12.183 → 00:04:14.150
视频里的叙事和剪辑技巧
00:04:14.150 → 00:04:16.266
被AI实现正在成为可能
00:04:16.266 → 00:04:17.500
实验的结果是这样子
00:04:17.500 → 00:04:19.433
我给了Codex两次机会
00:04:19.433 → 00:04:21.100
第一次给它视频片段
00:04:22.066 → 00:04:23.950
我还开了最高档的思考
00:04:24.266 → 00:04:25.633
可他完成的效果很差
00:04:25.983 → 00:04:28.866
他是不是还没法从截图中找到逻辑
00:04:28.983 → 00:04:31.033
第二次我给他提供了完整的
00:04:31.033 → 00:04:33.750
根据时间戳对齐的字幕文件
00:04:33.750 → 00:04:35.100
帮他来理解上下文
00:04:35.483 → 00:04:36.750
可他依然是把一段
00:04:36.750 → 00:04:38.866
充分利用摄像机运镜的效
00:04:38.866 → 00:04:41.150
果硬生生是给做成了PPT
00:04:41.500 → 00:04:44.183
那整个视觉的呈现效果也差了很多
00:04:44.666 → 00:04:46.550
但是Kimi Code的版本就不一样了
00:04:46.550 → 00:04:47.900
让人十分的意外
00:04:48.033 → 00:04:50.783
它不仅更好的对齐了原始的音频
00:04:50.833 → 00:04:53.266
还模拟出了摄像机运镜的效果
00:04:53.433 → 00:04:55.633
哇那整个表达是十分有逻辑的
00:04:56.183 → 00:04:58.500
和原视频还是有很大距离的
00:04:58.500 → 00:05:00.433
我建议大家可以去找一下原视频
00:05:00.783 → 00:05:03.466
但是如果把原始视频和成品
00:05:03.500 → 00:05:04.783
都交给Kimi Code
00:05:04.950 → 00:05:07.150
再让它一次读入两个视频
00:05:07.150 → 00:05:09.633
并且对不足的方向进行精修
00:05:09.633 → 00:05:10.700
再迭代个几轮
00:05:10.700 → 00:05:12.466
我相信结果会越来越好
00:05:12.583 → 00:05:14.666
而且同时读两个视频的方式
00:05:14.666 → 00:05:15.833
只有它能支持
00:05:16.183 → 00:05:17.950
这个实验让我是有些惊讶
00:05:17.950 → 00:05:19.500
但是也在意料之中
00:05:19.866 → 00:05:21.750
因为脱离了软件开发场景
00:05:21.750 → 00:05:24.150
缺少了帧与帧之间的时间关系
00:05:24.383 → 00:05:26.150
Codex是很难拿出惊艳的
00:05:26.150 → 00:05:27.550
成果 我知道
00:05:27.550 → 00:05:29.983
Codex的上下文是在服务端管理的
00:05:30.100 → 00:05:32.433
所以我们并不清楚他读过的图片
00:05:32.500 → 00:05:34.500
是不是始终以原始的形态
00:05:34.500 → 00:05:35.266
留在上下文里
00:05:35.266 → 00:05:38.150
比如说base64 编码就是一种原始形态
00:05:38.350 → 00:05:39.383
但我十分确定的是
00:05:39.383 → 00:05:41.433
视频类的内容是肯定没有的
00:05:41.583 → 00:05:44.266
所以Codex未来会不会在这个能力上
00:05:44.266 → 00:05:45.583
对齐Kimi Code呢
00:05:45.666 → 00:05:47.583
这就是我标题里提出的问题
00:05:47.783 → 00:05:48.950
我希望他会啊
00:05:48.950 → 00:05:50.100
我是200刀的订阅
00:05:50.100 → 00:05:51.950
我特别希望他也能理解视频
00:05:51.983 → 00:05:53.983
另外在做了这个测试之后
00:05:53.983 → 00:05:56.500
我又拿了一些AE动画在做测试
00:05:56.750 → 00:05:57.900
结果和之前一样
00:05:58.100 → 00:06:00.583
不但完整的复刻了动画的视觉效果
00:06:00.783 → 00:06:01.866
连动画的节奏
00:06:01.866 → 00:06:03.833
转场的时机都复刻出来了
00:06:04.300 → 00:06:06.866
这不是普通的低频率抽帧的方案
00:06:06.866 → 00:06:08.983
能稳定做到的只有Kimi Code的这条
00:06:08.983 → 00:06:10.750
链路上时间这个维度的信息
00:06:10.750 → 00:06:12.150
才能被保留的更多
00:06:12.233 → 00:06:15.066
好那我想说的商机到底是什么
00:06:16.466 → 00:06:19.266
如果在符合道德和版权的约束下
00:06:19.266 → 00:06:20.700
我们把一批经过授权
00:06:20.700 → 00:06:22.233
或者开源的视频作品
00:06:22.300 → 00:06:23.983
通过视频理解的方式
00:06:24.100 → 00:06:25.383
来蒸馏成一个
00:06:25.466 → 00:06:27.983
剪辑和叙事经验的知识库
00:06:28.666 → 00:06:30.066
如果你接到一个剪辑任务时
00:06:30.066 → 00:06:31.066
你先用Agent呢
00:06:31.066 → 00:06:31.900
在这个知识库里
00:06:31.900 → 00:06:33.666
检索类似的案例的经验
00:06:34.750 → 00:06:37.550
来核查提取出叙事动画的方案
00:06:37.766 → 00:06:40.033
最后再通过HyperFrame这样的框架
00:06:40.033 → 00:06:41.550
来快速实现动画
00:06:42.550 → 00:06:44.750
博主是不是只需要构思内容本身了
00:06:44.750 → 00:06:47.100
而所有的表达全部都可以交给Agent
00:06:47.183 → 00:06:49.350
你们说这个库如果能做成
00:06:49.350 → 00:06:50.750
会不会成为一个商机呢
00:06:50.933 → 00:06:52.700
反正我现在已经把Kimi Code
00:06:52.700 → 00:06:54.866
集成到了我的牛马Agent的体系里了
00:06:54.866 → 00:06:56.266
我已经开始用这种能力
00:06:56.266 → 00:06:57.783
去做可行性的验证了
00:06:58.100 → 00:06:59.550
OK商机说到这里
00:06:59.550 → 00:07:00.583
咱们回到现实
00:07:00.666 → 00:07:02.300
我对Kimi Code的代码库
00:07:02.300 → 00:07:03.833
又做了进一步的研究
00:07:03.833 → 00:07:06.466
我发现其实还有很多值得说的内容
00:07:06.633 → 00:07:09.033
比如说它支持其他模型的接入
00:07:10.033 → 00:07:12.900
如果你稍微对代码做一些修改的话
00:07:13.100 → 00:07:15.466
本地部署的Qwen3.6 27B
00:07:15.466 → 00:07:17.433
也能实现视频常驻
00:07:17.433 → 00:07:18.833
上下文的这种玩法
00:07:18.950 → 00:07:21.466
那本地多模态模型现在也可以满血
00:07:22.750 → 00:07:25.500
他甚至对音频类型也留了接口
00:07:25.750 → 00:07:26.700
顺着他的思路
00:07:26.700 → 00:07:27.900
我稍微对他的代码
00:07:27.900 → 00:07:29.750
做了一点点的小改动
00:07:29.750 → 00:07:31.866
我甚至实现了能用本地的模型
00:07:31.866 → 00:07:33.366
分析带音轨的视频
00:07:33.466 → 00:07:34.466
另外我还发现
00:07:34.466 → 00:07:37.033
原本在网页版才能用的Agent Swarm
00:07:37.033 → 00:07:39.350
现在在Kimi Code里就直接就支持
00:07:39.900 → 00:07:41.433
比如就拿我们刚才这个场景举例
00:07:41.433 → 00:07:43.466
我给Kimi Code两个视频让它分析
00:07:43.983 → 00:07:46.483
可能就用掉了40%的上下文了
00:07:46.483 → 00:07:47.633
但接下来的任务
00:07:47.633 → 00:07:49.900
我就可以启动Agent Swarm来实现
00:07:50.033 → 00:07:50.583
主Agent呢
00:07:50.583 → 00:07:52.350
再也不用触发Compact
00:07:52.433 → 00:07:53.350
所以总的来说
00:07:53.350 → 00:07:55.100
很多更有价值的信息
00:07:55.100 → 00:07:56.633
其实都在它的代码里
00:07:57.033 → 00:07:58.750
官方宣传真不到位啊
00:07:59.266 → 00:08:01.633
一个第一方还是开源的Harness
00:08:01.633 → 00:08:03.900
其实真的值得我们投入更多注意力
00:08:04.100 → 00:08:05.583
那在写这篇稿子的时候
00:08:05.583 → 00:08:06.383
我还有个发现
00:08:06.383 → 00:08:07.866
让我稍微有点失落
00:08:08.100 → 00:08:09.633
把视频放入上下文
00:08:09.633 → 00:08:11.950
其实是在1月的Kimi CLI版本时
00:08:12.983 → 00:08:14.783
而我这半年却毫无意识
00:08:15.100 → 00:08:16.666
这就是我正在反省的点
00:08:16.666 → 00:08:18.583
也是想在结尾和大家共勉的
00:08:18.900 → 00:08:20.066
模型厂的Harness
00:08:20.066 → 00:08:21.983
它从来就不只是一个壳
00:08:22.066 → 00:08:23.900
它是模型能力的放大器
00:08:23.950 → 00:08:25.950
也是技术路线的风向标
00:08:26.150 → 00:08:27.100
就拿我刚刚解锁的
00:08:27.100 → 00:08:29.666
Kimi K2.7 Code 的高速版本来说吧
00:08:30.150 → 00:08:32.833
它是可以提高6倍速度 3倍价格
00:08:33.183 → 00:08:34.100
但这不是重点
00:08:34.100 → 00:08:35.583
它不是提速那么简单
00:08:35.950 → 00:08:37.100
它很可能意味着
00:08:37.100 → 00:08:39.666
那些生产流程已经跑通了的用户
00:08:40.750 → 00:08:42.983
把TOKEN转化成成果这件事
00:08:43.066 → 00:08:44.266
有了一种刚需
00:08:45.466 → 00:08:47.383
模型厂商最先感知到了
00:08:47.383 → 00:08:49.150
所以他们就推出了这个服务
00:08:49.233 → 00:08:50.700
那这就是一个风向标
00:08:51.750 → 00:08:54.233
第三方工具都在忙着兼容各家的API
00:08:54.233 → 00:08:55.500
忙着实现各种功能
00:08:56.633 → 00:08:58.183
而模型厂自己的Harness
00:08:58.183 → 00:08:59.066
已经把注意力
00:08:59.066 → 00:09:01.833
放在了扩大模型能力的边界上了
00:09:02.100 → 00:09:04.183
我们总是在等模型变强
00:09:06.266 → 00:09:07.666
才是那个让模型能力
00:09:07.666 → 00:09:09.266
真正被看到的窗口
00:09:09.550 → 00:09:11.383
而那个所谓的商机咱
00:09:12.583 → 00:09:14.633
也不只是做几个视频剪辑
00:09:14.633 → 00:09:15.750
Agent的那么简单
00:09:16.050 → 00:09:17.183
真正的机会在于
00:09:17.183 → 00:09:19.700
谁最先理解模型厂的技术路线
00:09:19.750 → 00:09:22.433
谁最先在新能力上跑通整个工作流
00:09:22.433 → 00:09:24.633
谁就能在新一轮的模型和工具的迭代里
00:09:24.700 → 00:09:25.950
最早拿到红利
00:09:26.500 → 00:09:28.783
希望今天的视频能启发到大家
00:09:28.900 → 00:09:30.383
咱们必须得动起来了
00:09:30.550 → 00:09:32.700
好了以上就是本期的全部内容了