夜雨聆风最近 AI 编程工具越来越多。但大部分人讨论的，还是同一个问题：
哪个模型写代码更准？哪个补全更快？
很少有人问另一个问题：
代码写出来之后，怎么保证它是对的？怎么证明它满足了需求？怎么在它出错的时候知道错在哪、怎么回退？
而且它不是在白皮书里问——它把答案写成了代码。
📐 先放下"AI 编程"四个字
市面上几乎所有的 AI 编程工具，底层逻辑都一样：
你打字，AI 回答。
本质上就是个聊天框，贴在了 IDE 旁边。
这个模式的问题不在于"聊天"。聊天本身没问题。问题在于——
聊天没有边界。
你丢一句话给 AI，它改了一堆文件。你怎么知道改对了？你怎么知道它理解你的意图了？你怎么知道它没有顺手改坏别的东西？
传统做法是：人盯着。
人看 diff，人跑测试，人判断能不能合。人就是那个 harness。
但如果你想让 AI 做更多事——不只是补一个函数，而是完成一个需求、交付一个功能——那"人盯着"就撑不住了。
不是因为人懒。是因为人的注意力是瓶颈。
Kun 看到的就是这个瓶颈。它的解法不是"更好的模型"，而是——
在模型外面，包一层工程结构。
🏗️ 三层结构：Harness → Loop → 模型
Kun 的架构，本质上是一个三层模型：
▎ 最外层：Harness 负责边界、权限、状态、验收、失败恢复。 回答：什么能做、什么不能做、做到哪里算完成、失败后怎么收场。▎ 中间层：Loop 负责执行节奏。 回答：模型输出 tool call → 执行 → 观察结果 → 决定下一步。▎ 最内层：模型 负责判断、生成、修复。 回答：看到了什么、应该做什么、怎么说。大部分 AI 编程工具的层级是反的：
模型在最外面，人肉充当 harness。
模型输出什么，人就判断什么。模型改了什么，人就检查什么。
Kun 把 harness 外部化了。需求文档、设计稿、实施计划、验收标准——这些不是"理念"，是 agent 在行动前必须读取、行动中必须遵守、行动后必须接受审计的外部契约。
你可能会觉得这太重了。确实重。但认真想想：
一个没有检查点的 CI/CD 流水线，跟一个"自动跑，跑完人看"的脚本有什么区别？
没有。CI/CD 的价值不是"它会一直跑"，而是"它过不了就停。"
Agent 也一样。没有 harness 的 agent loop，最常见的结果不是智能，而是——
更快地产生未经约束的动作，消耗更多 token，扩大副作用，并在事后说不清到底发生了什么。
🔌 一个运行时，三条路径
Kun 的工程实现里，有一个决策很说明问题。
它把 GUI 和 Agent 运行时拆成了两个独立进程。中间用 HTTP 和 SSE 通信。
这不是什么新鲜事——微服务架构二十年前就这么干了。但桌面应用里，这么做的人很少。大部分 Electron 应用会把所有逻辑塞在 React 组件里：
调 API、拼 prompt、处理 tool call——全在 hooks 里。
Kun 的做法是：
Agent 运行时是一个独立的 Node.js 进程，有自己的端口、存储、生命周期。GUI 只是一个展示层，不碰任何 Agent 逻辑。
这样做不是为了炫技。是因为 Kun 有三条完全不同的 UI 路径——
• 🖥️ Code 模式 • ✍️ Write 模式 • 📱 IM 连接（飞书 / 微信）
它们共用同一个 Agent 运行时。
如果你把 Agent Loop 写在 React 组件里，你就得为聊天面板写一套，再为 IM 消息写一套，再为定时任务写一套。三个版本，三种 bug，三套维护成本。
Kun 的选择是：
逻辑下沉，UI 上浮。
运行时只关心一件事——怎么把一个意图跑完。GUI 只关心一件事——怎么把运行过程展示出来。
这种架构纪律，在"先跑起来再说"的项目里相当罕见。但它的回报是长期的：
换模型供应商、换存储方案、加新工具——都不需要动核心逻辑。因为核心逻辑和外部依赖之间，隔着一层 ports & adapters 的抽象。
💰 缓存优化：工程纪律，不是功能
如果说架构是骨架，那缓存优化就是 Kun 最值得细看的部分。
Kun 的缓存命中率目标是 90%+。不是愿望，是实测数据。
什么概念？假设你每次对话，系统提示词和工具定义占 2000 token。没有缓存，每次请求都要重新计算这 2000 token。一天 100 次对话，就是 20 万 token 白白烧掉。
但真正有意思的不是"省了多少钱"。而是——
为了实现这个命中率，Kun 做了哪些工程上的约束？
第一，系统提示词只放不变量。
角色定义、行为规范、工具约束——这些在所有请求中保持不变。文件路径、当前时间、选中文本——全部放在 messages 里，不碰前缀。因为前缀差一个字节，缓存就失效。
第二，工具定义做 canonical sort。
同一个工具集合，不管注册顺序如何，序列化出来的字节必须一模一样。LLM 的缓存机制是按字节匹配的，差一个空格就命中不了。
第三，每次请求前验证指纹。
SHA-256 哈希一下前缀，和上次比对。如果变了，说明有人在系统提示词里偷偷拼了动态内容——立刻告警。
第四，消息历史做 repair 再发送。
模型有时候会产出缺 id 的 tool call、没爹没娘的 tool result。直接发给 API 会 400。Kun 在每次请求前自动修复。
这些细节，单拎出来都不起眼。但把它们串起来——
不是"实现了一个缓存功能"，而是"建立了一种缓存纪律。"
跟恒温器的滞回区间一样——不是"有反馈就行"，而是"反馈的参数必须经过设计，否则系统会振荡。"
跟 TCP 的序列号一样——不是"会重传就行"，而是"重传必须有状态语义，否则只是重复发送。"
缓存的"控制律"就是：
什么可以变、什么不能变、变了怎么发现、发现了怎么处理。
🔁 Loop 不是重点，Loop 的护栏才是
Kun 有一个可视化工作流画布，里面有一个叫 Loop 循环的节点。
传统的 AI 交互是人驱动 Agent：
你发一句话 → AI 回一段 → 你看了觉得不对 → 再发一句。
Loop 的思路是反过来的：
你一次性声明条件、循环体和停止规则，然后 Agent 自己转圈——写 → 自审 → 改 → 再自审 → 直到满足条件。
比如"写一篇技术文章，写完自己审一遍，改到没有语病为止。"
但真正重要的不是"它会循环"。
成熟工程系统里到处都是 loop——操作系统 event loop、TCP 拥塞控制、数据库重试、CI/CD 流水线、Raft 心跳和选举。没有一个因为"它会循环"就以 loop 命名自己。
Kun 的 Loop 节点真正值得看的，是它的护栏：
▎ 最大轮数硬顶▎ 嵌套深度不超过 5 层▎ 看门狗超时中断▎ foreach 的 continueOnError 开关这些护栏回答的是同一类问题：
什么时候必须停？什么错误可以跳过？什么情况必须暴露？多深算失控？
没有护栏的 loop，不是工程，是赌博。有了护栏，loop 才变成策略。
🧭 从 Prompt 到 Harness：人在哪里
早期 AI 编程，本质上还是把 LLM 当生成器：
指令 → Prompt → 输出
人站在循环里，负责补上下文、判断结果、纠正方向、决定是否继续。
Loop 模式的变化是：人不再手动拨动每一轮，而是把执行交给系统去跑。但人只是从键盘前移到了调度器旁边。
Kun 指向的更远一步：
把人的判断、边界和验收标准外部化成系统契约。
需求文档不是写给人看的，是写给 agent 读的。实施计划不是 PPT，是 agent 执行时的路径约束。验收标准不是"上线前跑一下"，是 agent 每一步都必须对齐的目标。
人在 loop 外面——设计 loop 的边界、证据和停止条件。
这比"写一个会循环的脚本"难得多，也更接近真正的工程。
🔚 一句话收束
模型可以犯错，但 harness 不能跟着失控。
Kun 做的事情，本质上就是把 harness 从"人肉"变成了"系统"。
它不是在跟 Cursor 比谁补全更快，而是在回答一个更根本的问题：
当 AI 从"写代码"变成"做软件"，你怎么保证它做的是对的？
这个问题，现在可能还太早了。
但方向是对的。而且有人已经把答案写成了代码。
