Kimi K3 的卖点是长程 Agent 编程：1M 上下文、原生多模态，让 Agent 在长任务里持续读代码、看截图、跑工具、修问题。本文用三个递进的案例检验这套说法：从 0 到 1 的全栈热点追踪系统、存量 Java 项目的修复与加特性、以及一个可玩的第三人称动作游戏 Demo。

背景与接入

K3 支持主流 Coding Agent 框架。最短路径是官方的 Kimi Code CLI：安装后在项目目录执行 kimi，/model 选择 k3 即可让它读代码、改代码、跑命令。已经在用 Claude Code、Roo Code 或 CC Switch 的，不必重搭工作流——创建 Kimi Code API Key 后通过兼容接口接入，K3 只负责模型推理，读文件、调工具、管权限仍由外层 Agent 框架处理。

正式开跑前建议先做一次只读小测试：”阅读当前项目的目录结构和核心代码，说明各模块职责，先不要修改文件”——确认上下文理解正常再放权。

案例一：HotPulse 热点追踪系统（长程交付）

验收目标是一套能跑的 MVP：用户创建关键词 Monitor，系统定时或手动抓取 Hacker News/RSS，原始内容落成 Observation，经 analyze 生成 Entry，最后走 Notify 投递；前端能看 Feed、运行记录与投递状态。技术栈在需求里就锁死：后端 Hono + SQLite + Drizzle，前端 React 19 + TanStack Query；测试不依赖真实公网（fake webhook、临时 SQLite）。

任务用 /goal 推进，全程不启用任何 Skills，以便观察模型本身的长任务能力。K3 的推进顺序很”工程师”：先做 shared 契约、Zod schema 和单测，再补数据库、队列、领域服务，服务端测试跑到 94/94 全绿后才切前端；中途报错自己跑 TypeScript 检查和测试回去修。后续两轮迭代也很典型：一轮把”能用”推向”产品形态”（新手引导、防重复提交、删除确认）；另一轮做多源扩展——亮点不是多写几个抓取器，而是把 RSS、Webpage、GitHub 等来源统一收进 source_items 中间层，用 (monitorId, externalId) 做唯一键、contentFingerprint 做内容变化检测。

这个案例的价值在于：长任务里它能持续咬住目标，交出可验证结果。真正的监控系统难在”某个来源挂了、页面结构变了之后链路能否降级续跑”，这部分仍是后续要压的工程题。

案例二：存量 Java 项目改造（工程习惯）

这类任务的重点是先读懂已有代码，再沿现象追调用链。两个小任务：

修复股票搜索乱码。 现象是搜索结果中文名全乱码。K3 从搜索入口追到数据源回退逻辑，定位到新浪接口返回 GBK 编码，而项目的 HTTP 工具固定按 UTF-8 解码；修复是让该数据源按 GBK 解码并补上 Referer 请求头，随后重新构建、重启、实测返回正常中文名。过程没有扩大到无关模块——比”写个工具类”更能看出工程习惯。

持仓收益看板。 需求看似一张页面，实际要同时补后端计算、接口分层、前端展示和测试。K3 先读自选股字段与行情接口再动手，金额统一 BigDecimal，行情缺失时单只股票降级、不拖垮整页。第二轮 V2 更有看头：它没有直接在前端堆字段，而是先回后端确认 K 线字段、交易日期对齐与停牌降级口径，再把计算收进独立的 PortfolioRiskCalculator，补上收益贡献排行、HHI 集中度、年化波动率、最大回撤——把”能展示”推进到”口径靠谱”。

案例三：3A 质感游戏 Demo（多模态迭代）

业务系统看分层、接口与数据口径，游戏看的是另一套能力：画面、物理、输入手感、镜头、战斗反馈，以及”能不能真的玩起来”。提示词要求用 Vite + TypeScript + Three.js + Rapier 从零做一款第三人称科幻动作 Demo，并列出移动/闪避/瞄准/射击、多阶段 Boss、PBR 材质、雾效、Bloom、命中反馈、镜头震动等验收点。

第一轮交付已是完整游戏循环：普通与精英敌人、三阶段 Boss、任务目标、死亡重开，它还在交付报告里自曝已知问题（无跳跃、Boss 遮挡视线、构建产物偏大）。第二轮是关键：把截图和实际体验反馈给它，它列出 7 个影响手感的问题（枪口与准星不齐、瞄准时角色挡画面、换弹音效与动作脱节等），再逐个模块修。射击手感很难用单元测试定义，准星有没有被挡住、命中有没有反馈，都要靠视觉和体验判断——这正是多模态加长程 Agent 的用武之地。

分析与思考

三个案例分别对应三种能力：长任务里的目标保持（案例一）、存量代码里的最小范围定位与口径意识（案例二）、把主观体验翻译成代码细节（案例三）。适用边界也随之清晰：把 K3 放在目标清楚、验收条件具体、允许它持续执行命令和修复的任务里——搭 MVP、修跨模块 Bug、做可玩交互 Demo，比”生成一个页面”更能发挥其长。

也要看到约束：长会话存在漂移风险，里程碑要写成 Spec 并配合 git tag 留档；全栈任务要防前后端契约不一致；游戏 Demo “看起来完成”不代表性能可玩，帧率与加载时间要实测。榜单与口碑都只是参考，最可靠的评价方式仍是拿自己的真实项目跑一遍。

小结

  • 接入：Kimi Code CLI 最短，已有 Agent 框架走兼容接口即可，先只读测试再放权。
  • 长程交付：/goal + 明确验收条件，能让 K3 从契约、测试一路推进到可运行 MVP。
  • 存量改造与创意工程都能接，但契约测试、口径核对、性能实测这些验收环节一个都不能省。