一、Kimi K3 简介

Kimi K3 是月之暗面于 2026 年 7 月 17 日发布的‌全球首个 3 万亿参数级开源大模型‌（实际 2.8 万亿），具备‌原生视觉理解‌、‌100 万 token 上下文‌及‌长程 Agent 任务执行‌能力，定位为软件工程、知识工作与深度推理场景的旗舰模型 。
能力表现与评测

• 编程与 Agent‌：在 Arena.AI 前端代码榜单登顶（超越 Claude Fable 5）；支持 48 小时+自主 Agent 运行，可独立完成芯片设计、GPU 编译器构建等复杂工程
• 知识工作‌：能自主搜集分析数十篇文献、处理百份 PDF，生成含交互式可视化的深度研究报告
• 综合排名‌：整体略逊于顶级闭源模型（如 Claude Fable 5、GPT-5.6 Sol），但稳定超越 GPT-5.5、Opus 4.8 等梯队，在中文理解与特定编程任务上表现突出
  价格
  Kimi K3 是目前国内最贵的模型，相比前代K2.6的涨价幅度如下：
• 输入侧‌：缓存未命中的输入价格从6.5元/百万token涨到20元/百万token，涨幅约‌207.7%‌；缓存命中的输入价格从1.1元/百万token涨到2元/百万token，涨幅约‌81.8%‌。
  输出侧‌：输出价格从27元/百万token涨到100元/百万token，涨幅约‌270.4%‌，也就是涨了超3.7倍。
  横向对比来看，它的定价仍远低于Claude Fable 5等海外顶级闭源模型，仅为其约三分之一的价格。

二、Dynamic Workflows 实验介绍

在公众号文章 Dynamic Workflows 工程化实践（下）：PM视角实战指南 中介绍了开源实验项目 phuryn/dynamic-workflows-experiment ，以它为案例演示一个可复现、可验证、可沉淀为团队技能的产品发现工作流。
phuryn/dynamic-workflows-experiment 是 Product Compass 文章的配套实验，它要验证的论点是：

动态工作流的价值不在于单次扇出并行（那用普通 subagent 就够了），而在于"上一阶段的输出决定下一阶段"的多阶段编排。

实验虚构了一个产品 Reelay：一个流媒体聚合器，目标是成为"今晚看什么"的决策层。
为了让结果可验证，作者用了**合成数据 + 答案钥匙（answer key）**的设计：

1. 先在 ground-truth/answer-key.md 里预埋 8 个已知机会点和目标分数；
2. 按 5 种 persona、每人 2–3 个预埋痛点，生成 100 份 600–900 字的访谈稿；痛点只以故事形式出现，绝不出现"opportunity / feature / pain point"等标签词；
3. 盲跑分析工作流，不喂答案钥匙，看它能否还原预埋排名。
   任务书根据 100 份访谈 生成 3 个 HTML 原型。为此设计 harness 六阶段流水线：

100 份访谈
  → Extract（每份一个 agent，抽取机会点：slug / persona / 引述 / 三个 1-5 分）
  → Canonicalize（一个 agent 把同义 slug 聚成 6-10 个规范需求——先做归并再计数）
  → Score（纯代码，无模型：频次 × 重要性 × (5 − 满意度)）
  → Ideate（前 5 名各由 agent 提 3 个方案）
  → Triage（独立 judge 按 ROI 三角测量出前 3）
  → Build（agent 用 frontend-design skill 为 3 个赢家各写一个静态 HTML 原型）
  → Loop（低置信度抽取换更强模型重跑；渲染不出来的原型重建）

关键设计 对抗式质量控制：方案由生成 agent 和独立评审 judge 分开完成；置信度低于 0.6 的提取自动升级模型重试。

三、K3模型的运行结果

运行总结：
运行日期： 2026-07-19
工作流文件： discovery-harness.js
输入： ./interviews 目录下的 20 份访谈记录（001.md–020.md）

---

机会排名

排名	机会 slug	描述	出现访谈数	频率	重要性	满意度	得分
1	decide-what-to-watch	克服选择疲劳和决策瘫痪，快速决定要观看的内容	19	4.03	4.30	1.50	60.70
2	subscription-overload	管理多个流媒体订阅：不清楚哪个平台有哪个节目、费用与使用可见性、取消麻烦、共享账号、以及统一的跨平台搜索/发现/想看清单	20	3.24	3.92	1.79	40.75
3	co-watching	与家人或远程朋友协调共同观看，包括安排、同步和决定一起看什么	9	3.20	3.80	1.80	38.91
4	parental-controls	将孩子限制在适龄的安全档案中，并保持家庭成员档案之间的清晰边界	4	2.40	4.60	1.60	37.54
5	cross-device-resume	跨设备/跨服务保持播放连续性、观看历史和进度，包括续播、间隔后的回顾、手机与电视之间的搜索状态接力	12	3.00	3.60	1.87	33.84
6	new-release-tracking	追踪关注剧集的新季/新集发布状态，并及时提醒，避免错过	4	2.75	3.25	2.00	26.81
7	social-recommendations	收集、保存并信任来自朋友/家人的推荐，并知道推荐内容在哪里可看	8	2.75	3.38	2.13	26.68

与 ground truth 对比

预期前三名机会为 decide-what-to-watch、subscription-overload、cross-device-resume。本次运行结果：

• decide-what-to-watch 排名 第 1
• subscription-overload 排名 第 2
• cross-device-resume 总体排名 第 5，但仍被 judge 选为 TOP 3 获胜原型 之一。

---

前三名获胜原型

对应机会	方案	描述	输出文件
decide-what-to-watch	Vibe Check	根据用户当下的心情/能量，快速将所有已连接平台的片源收窄为一小组可立即播放的推荐。	outputs/vibe-check.html
subscription-overload	Universal Watchlist & Availability Router	统一的跨服务想看清单，显示每部内容当前在哪个平台播放、价格、是否即将下架，并一键跳转到对应应用。	outputs/universal-watchlist-availability-router.html
cross-device-resume	Continue Watching Sync	统一的跨服务进度层，记录用户在任意剧集/电影上离开的位置，并可在任意设备或已连接服务上即时续播。	outputs/continue-watching-sync.html

三个原型均为独立的静态 HTML 文件，使用内联 CSS/JS，无外部依赖。每个构建 agent 在保存后都会回读文件并确认 renders: true。

---

运行诊断

指标	数值
处理的访谈数	20
首次运行 token	约 496,000
重试 token	约 140,000
工作流总 token	约 636,000
首次运行状态	已完成，但最后验证/重建 agent 遇到 API 用量限制。
重试状态	成功完成；一次构建尝试被安全分类器拦截，第二次尝试成功重建。
残留文件清理	已删除首次运行遗留的 outputs/reelay-picks.html，使输出目录与最终 TOP 3 保持一致。

注意

• 运行时间进11分钟
• 花费 tokens 496 K

四、另一模型的运行结果

运行总结：

注意

• 运行时间进41分钟
• 花费 tokens 2.53 K

与 K3 对比

（1）花费时间约是 K3 的4倍
（2）花费 tokens约是 K3 的5倍

五、生成 html 效果对比

K3 Universal Watchlist & Availability Router:

另一模型：

K3 Cost-Per-Watch Nudges:

另一模型：

K3 Cost-Per-Watch Nudges:

另一模型：

可以看出：K3 的 html 输出效果更好。

六、结论

Kimi K3 作为编程与 Agent‌在 Arena.AI 前端代码榜单第一模型，对复杂任务完成的效果远远超出了国内另一先进模型。
（1）更好：花费时间约是 K3 的4倍
（2）更省：花费 tokens约是 K3 的5倍
（3）更好：生成 html 更美观、功能更强
K3 跑完才发现，另一模型可能没有很好完成 harness ，好像没有与 ground-truth 对比环节。这才是关键。