*“直到今天，我依然相信当年我们把重心放在目标程序的执行效率而非语言设计上，是完全正确的……下一次编程革命只有在以下两个条件同时满足时才会发生：1、开发出一种远比今天强大的新型编程语言；2、找到一种以不比今日程序高太多的成本来执行它的技术。”——[John Backus（FORTRAN 之父、1977 年图灵奖，1978 年编程语言历史大会）](https://doi.org/10.1145/800025.808380)*

## 一、长话短说

**意图编译**：人类通过自然语言向 AI 发出指令，由 AI 完成意图理解、任务规划、工具调用与结果整合，最终交付任务的过程。在这一过程中，**作为意图载体的自然语言，可看作比程序语言更高一级的源语言；AI 的执行过程则可视为对自然语言的编译**。

**行为缓存**：在意图编译过程中被构建出的、可复用的工具调用结果或动作序列。在模型推理成本高于确定性计算成本的条件下，复用行为缓存类似于即时编译器（JIT）的**热代码编译**（将高频重复的代码块编译优化），只在真正变化的地方保留模型推理；如环境变化导致缓存失效，再通过回退机制安全地交还给模型重新规划。

**意图编译的工作范式让过去无法被标准化软件覆盖的深度长尾需求得以实现，针对此类意图的开发意味着极高的用户粘性；行为缓存的构建则负责压低持续产生的推理成本，保持边际成本优势。**

下面详细讨论：意图编译这一范式如何形成，围绕其编译器面临的困难及现有的工作，行为缓存如何作为可复用中间件运作，我们将如何通过端云协同架构切入跨应用长尾市场，以及如何看待模型能力演进与外部缓存的边界。

---

## 二、为何现在出现

试图将自然语言作为一种编程语言并非新想法。1950 年代 Grace Hopper 设计 FLOW-MATIC 与 COBOL 时，就曾试图让代码贴近英语句式；到了 1970 年代，随着早期符号 AI 的兴起，学界与工业界也曾掀起一股“自然语言自动编程”热潮——MIT 的 SHRDLU、IBM 的对话式编程系统 NLPQ、斯坦福的 PSI 程序合成系统等。当时的主要做法也简单：手工加各种语法规则，用规则匹配英语，再解析为程序指令。

毫无疑问，这些尝试最终都没能成为主流。原因在于：系统底层仍是死板的规则匹配，没有人类常识，也无法补全隐含假设。在中间层手动加各种语法规则来把自然语言形式化，会遭遇歧义性引发的组合爆炸——写中间层比写程序语言还困难，还会各种报错。如同图灵奖得主 Dijkstra 在 1978 年《[论“自然语言编程”的愚蠢](https://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD667.html)》中所批判的：试图将自然语言作为编程语言，既丢掉了形式化符号的简洁精确，又制造出了“看似像英语、但写错一个介词就崩溃的怪胎”。

大语言模型（LLM）的出现改变了这一切。LLM 至少带来了两项过去从未同时具备的基础能力：其一是**对自然语言所蕴含的人类语义的深度理解能力**，其二是**强大的形式化代码与动作生成能力**。在此基础上，叠加：

1. **模型的多步规划与控制能力**：得益于后训练（Post-training）技术的突破，模型从只能单轮问答，演进到能够自主拆解任务、调用外部工具、并根据环境反馈动态修正下一步。
2. **工具调用和脚手架**：[MCP（Model Context Protocol）](https://modelcontextprotocol.io/)将工具调用标准化，同时 Harness 工程帮助 LLM 具备在操作系统环境中执行动作的能力，而非局限于单一云端进程。
3. **还有最重要的**：Token 成本持续下降，LLM 不再是少数 AI 实验室的玩具。

这类工作，可称为 Agent 工作流、Vibe Coding、Loop Engineering 等。不过整体归纳，就是：**人类用自然语言表达意图，大模型作为编译器的核心进程完成理解、规划与工具编排，最终实现计算机的状态转移。** 正如 Andrej Karpathy 所言“[最热门的新编程语言是英语](https://x.com/karpathy/status/1617979122625712128)”——**自然语言正在取代传统程序语言成为顶层的源语言，而传统的程序语言则退居为类似汇编或字节码的下游编译产物。**

那么一个自然的追问：**我们该如何建造这门语言的编译器，以及如何优化它？**

过去两年涌现的工程实践，已经为这座“自然语言编译器”搭起了初步的骨架。但仍有两道核心难关尚未跨过：

---

## 三、两个问题

建造并优化自然语言编译器，至少还要解决两个问题：
1. **源语言与编译器核心进程的非确定性**：自然语言的语义是模糊的、非形式化的，并且 LLM 的输出结果是概率性的，会漂移（即使在 Temperature 降为 0 时也无法完全重现）。
2. **推理成本**：对人类意图的编译意味着每次执行都要持续消耗模型推理，而**推理高于计算成本，推理资源少于计算资源**。

### 3.1 模糊的源语言与概率性的编译进程

程序语言以牺牲表达力换取可判定性：语法受约束、类型可检查、副作用明确（语法错误编译器是会报错的）。自然语言相反，常常充满歧义、缺省假设、指代不明、无类型约束，且人类的真实意图并非提前完全规划好然后一次性编译，常常需要边执行边调整（尤其对于长链条任务）。与此同时，作为编译器核心进程的大模型，其底层是“一次一个 Token”的条件概率采样，本身也会带来随机波动。

尝试解决这个问题的做法主要有三类：

**第一种是把输出锁进语法与类型契约，主要为了应对 LLM 输出的不确定性：**
* **[OpenAI Structured Outputs](https://platform.openai.com/docs/guides/structured-outputs)**：在模型逐词采样时直接屏蔽违反 JSON Schema 的词，保证输出语法 100% 合规；
* **[微软 TypeChat](https://github.com/microsoft/TypeChat)**：用代码里的 TypeScript 类型定义充当提示词，将自然语言翻译并校验为强类型结构；
* **[Pydantic](https://docs.pydantic.dev/) / [Instructor](https://github.com/567-labs/instructor)**：用 Python 类型注解声明输出契约，解析失败时自动把报错信息喂回给模型令其修正重试；
* **[BAML (BoundaryML)](https://github.com/BoundaryML/baml)**：允许模型在思考时自由输出，再通过外部用 Rust 编写的容错解析器，毫秒级地将松散文本对齐修复为强类型数据。

**第二种是对模糊意图进行细化（SDD，规范驱动开发），主要应对自然语言的模糊特征：**
* **[GitHub Spec Kit](https://github.com/github/spec-kit)**：采用“章程、规格、计划、任务”四步模板，把模糊需求拆解为可审阅的中间文档；
* **[AWS Kiro](https://kiro.dev/)**：在 IDE 层面强制先将提示词转化为需求与设计文档，并引入基于属性的测试来捕捉边界漏洞；
* **[OpenSpec](https://github.com/Fission-AI/OpenSpec)**：先写文档再开发，同时在代码库中维护一份随每次变更同步演化的“活规格”；
* **[Tessl](https://tessl.io/)**：主张“规格即源码”，代码由规格自动生成且禁止手改，靠脚本做链接与归属的机械校验。

**第三种是增加外部独立验证与轨迹观测，主要应对 LLM 调用工具产生的行为漂移：**
* **[LLM-Modulo 框架](https://arxiv.org/abs/2402.01817)**：让大模型只负责生成候选方案，外挂编译器、求解器或测试脚本充当确定性裁判，不通过即携带报错打回重算；
* **[Guardrails AI](https://github.com/guardrails-ai/guardrails) / [NeMo Guardrails](https://github.com/NVIDIA/NeMo-Guardrails)**：在模型与工具之间架设独立的规则与代码校验管线，拦截越界参数与高危操作；
* **[OpenTelemetry GenAI](https://opentelemetry.io/docs/specs/semconv/gen-ai/) 与轨迹观测平台（[Langfuse](https://github.com/langfuse/langfuse)、[Arize Phoenix](https://github.com/Arize-ai/phoenix)、[AgentOps](https://github.com/AgentOps-AI/agentops)、[Braintrust](https://www.braintrust.dev/)）**：将 Agent 走过的每一步推理、每一次 MCP 工具调用与返回结果记录为结构化的调用树（Trace），支持“时间旅行式”的回放归因，并将线上失败轨迹转化为 CI/CD 回归测试门禁。

对于 LLM 执行任务的工程优化，2026 年已经完全进入了“大开发”时代。但这些工作同时也带来明显的负担：

其一，**它们在自然语言的意图表达与结果之间人为增加了一层厚重的“中间表示”**。软件工程学者 [Martin Fowler 与 Birgitta Böckeler](https://www.martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html) 曾提醒，这极易重蹈上世纪形式化规格语言失败的覆辙——**当为了消除歧义而把规范写得像代码一样繁琐时，写规范和维持同步的负担反而超过了写代码本身**。事实上，随着模型能力提升，我们反而不太需要原先 OpenSpec 这种比较重的 Harness。

针对此的解决方案是：**规范产生的负担不会消失，只能转移**。既然自然语言“低成本的模糊”是人类表达意图的最大红利，那么将模糊意图补全、细化为规范的工作，应该交给大模型去做，人类只负责对关键结果做确认与审计。

其二，**过度给 AI 套上死板的格式枷锁与重型编排框架**。生成阶段过于严苛的格式指令会抢占注意力带宽，导致模型推理准确率下降 10% 至 30%（[Tam et al., 2024](https://arxiv.org/abs/2408.02442)）——为了让 LLM 不犯粗心的错误，给它加上输出约束，结果它的主要精力用来应对约束了。

对于这个问题，可以借鉴现代编译器基础设施 **[MLIR（多级中间表示）](https://mlir.llvm.org/)**：在各个垂直领域建立轻量的“领域中间表示”，再由这一层之下的确定性编译系统完成向底层执行的转换。**一旦某个领域的中间层有了确定性的编译器，模型在该领域内便可向上抽象一层，停止向下推理**（《[编译式认知](https://chhzh123.github.io/blogs/2026-07-26-compiled-cognition/)》）。

现阶段对于编译模糊性问题的解决还在持续推进，尚未形成完全成熟的路线。即便能在单次任务中校准方向，长链条任务的可靠性依然存在问题。这是好消息：**还存在属于我们的工程优化机会**。

### 3.2 推理成本

传统软件在完成初次开发编译后，运行时消耗的是极其廉价的硬件计算资源；而意图编译不同，大模型推理成本无法像传统计算一样做到廉价且普遍。**如果每次执行任务都让大模型充当“解释器”从头推理一遍，就会持续产生高昂的“解释性开销”——不仅慢，而且每次都在为重复的决策消耗 Token 与算力。试图把所有的计算工作都 LLM 化，是不可取的、反经济学的。**

这里先解释下我们所说的“推理”和“计算”：尽管 Transformer 也只是一个运行在 GPU 集群上的进程，其本质也是一堆矩阵运算，但本文语境下的**计算**，是指用确定的规则处理确定的输入（无论该规则是在软件、系统或者硬件层面）；**推理**，则是用参数模型对符号序列做概率预测。例如调用硬件加法器求解 `"2+2="`，代价是一次纳秒至微秒级的电路延迟得到结果 `"4"`；而把 `"2+2="` 编码为 Token 输入 Transformer，经过多层神经网络预测出下一个 Token 为 `"4"` 的概率为 99.999% 并输出，代价则是毫秒乃至秒级的算力与昂贵的显存带宽消耗。

在降低推理成本方面，基础设施层已经做了大量底层优化，比如：
* **KV Cache 与提示词缓存**（如 [vLLM PagedAttention](https://arxiv.org/abs/2309.06180)、[Anthropic](https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching) 与 [OpenAI Prompt Caching](https://platform.openai.com/docs/guides/prompt-caching)）：复用相同上下文前缀的注意力矩阵状态，避免重复计算；
* **投机解码**（[Speculative Decoding](https://arxiv.org/abs/2211.17192)）：用轻量草稿模型快速猜词，再由大模型并行一次验算通过；
* **语义缓存**（如 [GPTCache](https://github.com/zilliztech/GPTCache)、[Redis LangCache](https://redis.io/solutions/use-cases/langcache/)）：通过向量相似度匹配，对相近的提问直接返回历史回答文本。

AI 基础设施的优化，在未来很长时间都将是十分重要的工作目标。过去三年 Token 成本已经大幅下降，但还远远不够：单位推理成本的降低，反而激发了更长思维链（CoT）、更复杂跨系统任务的全面爆发（杰文斯悖论）——需求与调用的膨胀速度，远超单价下降的速度。**推理资源成本高，计算资源成本低；推理资源不足，计算资源充足**。这种现象会长期存在，也是后文一切工程优化工作成立的前提。

---

## 四、行为缓存：状态转移路径中的可复用中间件

### 4.1 核心定义：状态转移路径中的可复用中间件

我对于行为缓存的简单定义是：**在意图编译过程中被构建出的、可复用的工具调用结果或动作序列，将其转化为更快速和低成本的确定性计算。**

大模型在意图编译中的核心任务，可以看作：**从初始意图（状态 $S_0$）到最终交付结果（状态 $S_n$），在未知的状态空间里“寻找路径”；而行为缓存的任务是：发现流量大的路径，修高速。**

```
[初期：全链路推理寻路（意图编译）]
人类意图(S0) ──(模型推理)──► 状态节点A ──(模型推理)──► 状态节点B ──(模型推理)──► 最终结果(Sn)

[成熟期：固定节点间的计算短路（行为缓存）]
人类意图(S0) ──(模型推理)──► 状态节点A ══(行为缓存：确定性计算/重放)══► 状态节点B ──(模型推理)──► 最终结果(Sn)
                                      │                              ▲
                                      └── (若环境守卫校验失败：回退模型) ──┘
```

**它的核心，是在意图编译（寻路）过程中找到稳定的、可复用的确定性中间件。** 

如果每次执行任务，都让大模型从 $S_0$ 到 $S_n$ 全程充当“解释器”重新寻路，就必然受困于第三章所提的两大难题：长链条路径容易发生概率漂移，且每一次执行都在重复支付高昂的推理成本。借鉴即时编译器（JIT）**热代码编译**的思想：在从意图到结果的整条状态转移路径中，并非所有路段每次都在变化；如果某两个中间节点（节点 $A$ 到节点 $B$）之间的转移被证明是高频且稳定的，我们就可以用廉价、确定的“计算与存储”替掉昂贵、概率性的“模型推理”。

它不需要整条任务从头到尾 100% 僵化不变，也不排斥在首尾两端继续保留大模型的灵活理解——只要路径中有一段中间节点间的到达方式可以被确定性地固化下来，它就构成了行为缓存：
* **结果即状态（缓存节点产物）**：很多时候，从节点 $A$ 到节点 $B$ 的目标本身就是产出一个确定的新状态——比如解析生成一份结构化的 Markdown 文件、得到一张清洗完的数据表、或是获取一次只读工具调用的返回值。把这份中间产物直接保存下来，下次遇到相同条件直接读取交付、一步跨到节点 $B$，就是最直接的行为缓存。
* **路径即程序（缓存动作序列）**：而当节点 $A$ 到节点 $B$ 每次面对的输入参数都在变化（如处理不同日期的业务数据），或者需要在环境中执行一系列产生实际改变的操作（如修改本地文件、点击软件界面）时，静态文件无法直接照搬，我们就把从 $A$ 到 $B$ 的工具调用顺序、代码脚本或动作序列固化下来，填入新参数直接由确定性计算跑完，同样省去了中间的模型推理。

### 4.2 演进谱系：从运行前（AOT）人工预判到运行时（JIT）动态编译

我们已经观测到的一系列探索：

* **[MCP](https://modelcontextprotocol.io/)** 与 **[Skills](https://github.com/anthropics/skills)**：MCP 固定了常用工具调用的接口定义与传输协议，Skills 固定了模型应当遵循的操作说明并将常用动作保存为本地脚本；它们先把“路标与接口”修好，但每次执行仍需模型阅读说明并实时推理编排。
* **[工具调用结果缓存（Tool Result Caching）](https://agentpatternscatalog.github.io/patterns/patterns/tool-result-caching.html)**：对重复出现的工具调用保留返回值（或如康奈尔大学 **[TVCache](https://arxiv.org/abs/2602.10986)** 将多步调用组织为有状态的“工具调用图”，在沙箱前缀匹配时直接复用结果与快照），在下次请求时直接返回结果而不必重新执行工具。
* **多步压缩的原语服务（[Firecrawl](https://www.firecrawl.dev/) / [Context7](https://context7.com/)）**：对多步骤、长链条的高频通用任务进行压缩再打包。例如 **Firecrawl** 将“启动浏览器、渲染、正文提取、OCR、生成 Markdown 文件”压缩为一个 API 接口服务，首次请求生成 Markdown 文件可视作一次解释执行，后续对同一网页的请求直接返回该文件结果，即可视作编译执行；**Context7** 则将各类代码库的版本匹配、切分与检索压缩为一个文档查询服务，遇到接口或语法变更时，模型不用每次 grep 整个代码库，直接询问 Context7 接口即可。

对比：

| 实践形态                                                                                  | 固化的对象                     | 固化时机与方式         | 命中后是否调用大模型                | 适用边界                   |
| ------------------------------------------------------------------------------------- | ------------------------- | --------------- | ------------------------- | ---------------------- |
| **提示词缓存（KV Cache）**                                                                   | 相同前缀的注意力中间状态              | 运行时，自动          | 是（省去 Prefill，仍需逐词 Decode） | 长系统提示词、多轮对话前缀          |
| **语义缓存（Semantic Cache）**                                                              | 相似问题的最终文本答案               | 运行时，自动          | 否                         | 仅适用于无状态、无副作用的纯问答       |
| **Skill / MCP**                                                                       | 声明式操作流程说明 / 工具通信协议        | 设计时，人工编写        | 是（模型仍需阅读说明并推理编排）          | 跨任务的通用知识注入与标准化连接       |
| **工具调用结果缓存**                                                                          | 单次只读调用的返回值或沙箱状态树          | 运行时，自动          | 否（单步跳过工具执行，但模型仍需编排）       | 相同参数的幂等只读接口，或前缀完全一致的沙箱 |
| **原语服务（[Firecrawl](https://www.firecrawl.dev/) / [Context7](https://context7.com/)）** | 通用节点间的多步操作与产出文件压缩为 API    | 设计时（AOT），人工预判   | 否（在该子任务段内零推理）             | 跨应用高频共用的横向通用节点         |
| **轨迹级行为缓存（Behavioral Cache）**                                                         | 特定业务节点间的参数化动作序列、状态产物与环境守卫 | 运行时（JIT），自动/半自动 | **否（守卫通过则确定性重放，越界才回退模型）** | 高频、低方差、含副作用的多步长尾任务     |

可以看出，现有工作已经可以做到：**由开发者在运行前（AOT）预判了全行业的高频共性需求，提前设计好压缩路径并将其固化为 API**。我们真正希望突破的方向，是**从“运行前人工预判”走向“运行时（JIT）动态编译”——在意图编译的运行过程中动态寻找热路径，由系统自动将其固化为行为缓存。**

### 4.3 行为缓存层的核心机制

构建运行时的行为缓存层将围绕以下四个核心工程问题：

**第一，中间过程的可观测性与热路径自动挖掘。**
通过将 Agent 的执行流插桩记录为结构化的状态—动作调用树，系统可以在后台对多条散乱轨迹做流程挖掘与公共子图提取，让高频走通的中间子路径自动浮现。

**第二，区分“结果重放”与“动作重放”。**
单次问答、语义缓存或公开网页抓取本质上是无状态只读（Read-only）的，缓存的只是历史返回值；但真实的复杂任务往往包含改变外部世界状态的写操作（Write / Side Effects，如点击 UI、修改文件、提交表单、发送请求），或者后一步的输出高度依赖前一步引起的环境状态变更。一句话概括：**读操作可以乐观地直接返回历史结果，而写操作必须在真实环境中重新执行动作序列。

**第三，将工具之间的组合与控制流一并编译掉。**
即使将路径中的单个工具调用节点固化下来，每两个工具调用之间，大模型依然要反复介入做“观察—思考—下一步决策”。进一步将多步工具的组合、循环与条件分支直接编译成一段确定性的控制流代码，只在真正需要语义判断的节点保留模型调用，才能压低延迟。

**第四，缓存动态校验、淘汰与安全生命线。**
处于谱系最深层的轨迹级行为缓存收益最激进，但工程风险也最高——没有环境校验的盲目重放，一旦遇到界面改版或接口字段漂移，就会在错误的地方点击错误的按钮；而如果缓存只增不减，庞大臃肿的缓存库又会拖慢检索效率。因此，需要建立缓存的生命周期管理机制，一条完整的行为缓存中间件必须包含：
1. **参数化轨迹（Trajectory）**：记录从节点 $A$ 到节点 $B$ 所产出的中间状态结果，或所执行的工具序列、代码骨架与动态参数槽位；
2. **环境守卫（Guards）**：记录该轨迹成立所依赖的环境状态前提（如页面 DOM 结构、屏幕视觉特征、接口版本、数据口径哈希）；
3. **复用判定与回退（Validation & Fallback）**：在重放前与重放中比对当前环境与环境守卫，吻合则直接走毫秒级的确定性计算，失配则立即中断并安全回退给大模型重新规划；
4. **入库验证与缓存淘汰（Verify-before-store & Eviction）**：录制不等于可用，新生成的轨迹必须在留出集（Held-out set）上通过独立的一致性测试才允许入库；入库后则借鉴 Redis 的 **TTL（过期时间）、LFU/LRU（基于访问频率与近期的容量淘汰）以及定期探针抽检**，自动清理低频或失效的陈旧缓存。

---

## 五、开发范式与商业化

提出了意图编译与行为缓存的概念之后，接下来的问题是：**围绕这套机制，软件开发范式会发生怎样的重构？作为既非基础模型厂、也非超级应用大厂的创业者，我们又该如何构建自己的竞争壁垒？**

### 5.1 开发范式：从“一次性开发成本”到“持续推理成本”

在传统的软件开发范式下，商业闭环建立在**“高固定成本、零边际成本”**的前提之上：产品经理去寻找市场上最广泛的最大公约数需求，研发团队投入数月乃至数年的时间完成编码与部署；在付出了这笔高昂的**一次性开发成本**之后，软件公司便可以近乎**零边际成本**向成千上万用户售卖软件授权，而用户的行为则必须削足适履地通过固定软件的菜单与按钮来表达。在这一旧范式下，大量低频、跨软件、个性化的深度长尾需求无法被挖掘：一是真实意图隐藏在碎片的软件操作行为背后，二是收不回高昂的一次性研发成本。

意图编译的工作范式让用户不再受限于单一软件预设的功能边界，那些跨软件、长链条、小批量但持续存在的深度长尾需求，第一次能够通过自然语言直接交由 AI 实现。但与此同时，**系统的成本不再像过去那样在开发阶段一次性付清，而是变成了运行阶段每一次任务执行时都必须持续付出的推理成本。**

因此，构建**行为缓存层**在经济学上的核心意义在于：它把意图编译在运行期持续消耗的“可变推理成本”，通过节点间的状态结果复用与动作轨迹重放，重新压缩回传统软件“接近零边际成本”的轨道上。**意图编译打开了深度长尾的可能性天花板，而行为缓存则托住了长尾落地的成本底线——用 Token 建立能力，再尽可能不用 Token 重复执行这种能力。**

### 5.2 架构：端云协同

**端侧表达—云端编译—共性路径缓存—云端持续巡检**。

**云端 Personal Agent 可以替代人类完成“生产”，却永远无法替代人类“消费”**——这是纯云端 Agent 不可避免的缺陷。手机和电脑，不仅是为了处理报表和写代码，更是为了看电影、打游戏、阅读与社交。**只要人类的“消费与体验”还发生在个人终端上，个人设备粘性就会持续；而个人设备的高频粘性与本地上下文（屏幕画面、本地文件、登录态与隐私权限），决定了人类的“意图层”会停留在个人设备侧而非云端推理侧。**


```
┌─────────────────────────────────────────────────────────────────────────┐
│                              云端（Cloud）                               │
│  1. 寻路编译器（大模型 + Harness） ──► 2. 共性路径聚类与入库验证（Verify Gate）│
│                                              │                          │
│         ┌────────────────────────────────────┴────────────────────┐     │
│         ▼ (只读段：状态结果/文件重放)                              ▼     │
│  [云端行为缓存网关（类 CDN 共享结果）]                   [3. 持续探针巡检与热更新] │
└─────────▲─────────────────────────────────────────────────────────┼─────┘
          │                                                         │
          │ 零推理直接返回状态产物                         下发带守卫的动作缓存制品
          │                                                         ▼
┌─────────┴─────────────────────────────────────────────────────────┴─────┐
│                            个人设备端（Edge）                             │
│  用户自然语言意图 / 本地屏幕与文件上下文 ──► 本地执行器（守卫校验 + 动作轨迹重放）│
│                                              │                          │
│                                    (若本地守卫失配：断点上报回退云端模型)    │
└─────────────────────────────────────────────────────────────────────────┘
```

1. **设备端表达意图，云端寻路编译**：用户在个人设备端发出自然语言意图，端侧具备完整的屏幕、文件与权限上下文。当遇到从未处理过的新任务（或本地守卫失配）时，端侧唤醒云端大模型，由云端大模型调用工具与运行时（Harness）完成初次路径探索。
2. **提炼多用户的“共同路径”，按读写属性分层分发**：在成千上万不同用户的意图编译过程中，看似千差万别的长尾任务，往往在许多中间节点之间存在着高度重合的**共同路径**（例如在特定网页或软件中提取某类结构化数据、将某类文档解析为特定格式的中间文件、跨系统完成标准格式转换或对账校验）。系统在云端识别并聚类这些高频共同路径，经入库验证后编译为行为缓存中间件。
3. **云端持续巡检与热更新**：外部环境（网页 DOM、第三方接口、软件 UI 版本）处于动态变化之中。云端利用测试集与端侧上报的“守卫未命中（Guard Miss）”抽样信号，对已入库的行为缓存进行持续的健康度巡检；一旦发现某段共同路径的缓存失效率上升或环境守卫报警，云端立即重新唤醒大模型探路重编，向端侧平滑推送更新后的缓存制品，实现“一处修复、全网生效”。

### 5.3 核心资产

在这一新范式与端云架构下，代码从核心资产变成了随时可以由编译器重新生成的下游产物。难以被复制的核心资产变成了：**意图层粘性、验证套件、私有上下文，以及行为缓存库。**

而对于我们，机会在：**切入原有 App 未能覆盖的、“跨 App、长链条”的深度长尾需求，用行为缓存建立结构性的成本优势。**

---

## 六、苦涩的教训

*“我们必须吸取惨痛的教训：将我们思考的方式融入人工智能系统，从长远来看是行不通的。这个惨痛的教训基于以下历史观察：1）人工智能研究人员经常试图将知识构建到他们的智能体中；2）这在短期内总是有效，并且能给研究人员带来个人满足感；但 3）从长远来看，这种方法会停滞不前，甚至阻碍进一步的进步；4）最终取得突破性进展的，是另一种基于搜索和学习来扩展计算能力的相反方法。最终的成功往往伴随着苦涩，而且常常难以完全消化，因为它战胜了人们偏爱的、以人为中心的方法。”——Rich Sutton，“[苦涩的教训](http://www.incompleteideas.net/IncIdeas/BitterLesson.html)”*

针对 AI 所作的工程优化常常面临的反对意见：**如果 AI 本身的能力还在持续提升，那么现在所搭建的工具或框架，未来还有存在的必要吗？模型能力的提升会不会直接吃掉今天的 Harness 与规范层？为什么不让 LLM 端到端包揽一切，而试图在中间路径做优化？**

更危险的是，如果**过度依赖外部工具与死板的人工约束，有可能减缓模型自身智能的发展**——这是纯粹强化学习支持者最有力的论点：我们必须让模型接触最真实的环境并获得反馈，它们才会提升。外围的工具和框架都会产生遮蔽效应（Hinton & Nowlan, [Shielding Effect](https://pages.ucsd.edu/~rbelew/courses/cogs184_w10/readings/HintonNowlan97.pdf)），削弱智能本身进化的可能性。个体在环境中能轻易靠外部拐杖解决生存问题时，自然选择作用于基因（或模型底层参数）的进化压力就会被屏蔽——就像我们的祖先因为环境中柑橘类果实充足、能随时从外部摄取维生素 C，体内负责合成维生素 C 的基因在演化中退化丢失。

**我必须说：任何理论都应有其边界。在数据充足、反馈成本几乎为零的领域，我们当然应该用强化学习的思路，把数据做大、把算力做强。但现实世界中并不是所有场景都如此。**

**首先，效率层面，“能内化”绝不等于“有效率”。**
如果我们一个一个地去数，人类也能回答“$2^{64}$ 之内有多少个以 1 结尾的质数”，但足够聪明的办法是写一个 Python 脚本去跑。一个强大的 LLM，完全可以在内部参数里内化出一个加法器、乘法器乃至一颗完整的 CPU，从头到尾在神经元里推理出一个 Linux 系统来跑（**[Qwenputer](https://github.com/divagr18/qwenputer)**），不调用任何外部工具，就能在模型中精确运行 C 语言和 Python 程序。但一个足够聪明的模型会这么做吗？**用昂贵的神经网络推理去硬跑确定性指令，效率会相差好几个数量级。**

其次，智能与智能所使用的工具，并不看作完全分离（[The Extended Mind](https://doi.org/10.1093/analys/58.1.7)），人类在做计算题时，有两种打草稿的方式：一是在脑子里打草稿，二是在纸上打草稿。为了保持进化的选择压力，我们应该取消草稿纸和计算器的使用吗？**不该因为迷信“通用模型能力”，就放弃对外部工具与缓存的优化。** 就像一家具身智能公司，如果想要让机器人实现高速长距离移动，聪明的做法是**让机器人学会开汽车，而不是强化机器人的双腿让它跑到 120 公里/小时**。

另外，更直接的证据：为什么 Transformer 架构本身要运行在专用的 GPU 上，而不是等着通用 CPU 的算力变强从而碾压 GPU 呢？一切的算子优化，也都是在假设：算力无法无限扩充。并且，这个假设是成立的。

因此，工程优化的意义，并不是假设模型能力停滞不前，而是承认：模型的行为模式是有其边界的，LLM 的底层原理决定了它的模糊性和推理成本。让模型用慢思考去探索未知路径，再由系统自动把探明的热路径编译为符号缓存——模型能力越强，它能探通的长尾链条就越深，自动沉淀下来的行为缓存反而越丰富。

---

## 七、结语

围绕智能工程的实践才刚刚开始，重要的是，在行动中解决问题。

*万炎杰 2026.11.02*

---
## 参考

1. **编译史与基础理论**：
   - Edsger W. Dijkstra, [*On the Foolishness of "Natural Language Programming"* (EWD 667)](https://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD667.html), 1978.
   - John Backus, [*The History of FORTRAN I, II, and III*](https://doi.org/10.1145/800025.808380), ACM SIGPLAN Notices, 1978.
   - Chris Lattner et al., [*MLIR: Scaling Compiler Infrastructure for Domain Specific Computation*](https://mlir.llvm.org/), CGO 2021.
   - Hongzheng Chen, [*Compiled Cognition: When Agents Should Stop Thinking*](https://chhzh123.github.io/blogs/2026-07-26-compiled-cognition/), 2026-07.
   - Andy Clark & David Chalmers, [*The Extended Mind*](https://doi.org/10.1093/analys/58.1.7), Analysis, 1998.
   - Rich Sutton, [*The Bitter Lesson*](http://www.incompleteideas.net/IncIdeas/BitterLesson.html), 2019；Geoffrey E. Hinton & Steven J. Nowlan, [*How Learning Can Guide Evolution* (Shielding Effect)](https://pages.ucsd.edu/~rbelew/courses/cogs184_w10/readings/HintonNowlan97.pdf), Complex Systems, 1987；Divyansh Agrawal, [*Qwenputer: a computer compiled into the weights of a pretrained language model*](https://github.com/divagr18/qwenputer), 2026-10.
   - Subbarao Kambhampati et al., [*LLMs Can't Plan, But Can Help Planning in LLM-Modulo Frameworks*](https://arxiv.org/abs/2402.01817), ICML 2024.
   - Chao Li, 《[大模型应用的工程哲学](https://onenightcarnival.github.io/llm-engineering-philosophy/)》（*The Engineering Philosophy of LLM Applications*）, 2026.
2. **自然语言即源码、类型契约、规范驱动开发（SDD）与轨迹观测**：
   - Andrej Karpathy, [*The hottest new programming language is English*](https://x.com/karpathy/status/1617979122625712128), 2023；Sean Grove, [*The New Code*](https://www.youtube.com/watch?v=8rABwKRsec4), 2025.
   - 类型与解析层：[OpenAI Structured Outputs](https://platform.openai.com/docs/guides/structured-outputs)、[Microsoft TypeChat](https://github.com/microsoft/TypeChat)、[Pydantic](https://docs.pydantic.dev/)、[Instructor](https://github.com/567-labs/instructor)、[BAML (BoundaryML)](https://github.com/BoundaryML/baml).
   - 规范层：[GitHub Spec Kit](https://github.com/github/spec-kit)、[AWS Kiro](https://kiro.dev/)、[OpenSpec](https://github.com/Fission-AI/OpenSpec)、[Tessl](https://tessl.io/)；实证研究 *Spec-Driven Development as Prescribed and as Practiced*（[arXiv:2608.25202](https://arxiv.org/abs/2608.25202)），2026-08.
   - 验证与轨迹观测层：[Guardrails AI](https://github.com/guardrails-ai/guardrails)、[NeMo Guardrails](https://github.com/NVIDIA/NeMo-Guardrails)、[OpenTelemetry GenAI](https://opentelemetry.io/docs/specs/semconv/gen-ai/)、[Langfuse](https://github.com/langfuse/langfuse)、[Arize Phoenix](https://github.com/Arize-ai/phoenix)、[AgentOps](https://github.com/AgentOps-AI/agentops)、[Braintrust](https://www.braintrust.dev/).
   - 工程反思：Birgitta Böckeler & Martin Fowler, [*Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl*](https://www.martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html), 2025-10；Tam et al., [*Let Me Speak Freely?*](https://arxiv.org/abs/2408.02442), EMNLP 2024.
3. **推理经济学、基础设施优化与工具原语**：
   - 成本趋势：Epoch AI, *The Plunging Price of Thought*, 2026-09；Du, *Tiered Super-Moore's Law*（[arXiv:2603.28576](https://arxiv.org/abs/2603.28576)）；*The Price of Progress*（[arXiv:2511.23455](https://arxiv.org/abs/2511.23455)）.
   - 推理与缓存优化：KV Cache / [vLLM PagedAttention](https://arxiv.org/abs/2309.06180)、[Anthropic Prompt Caching](https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching)、[OpenAI Prompt Caching](https://platform.openai.com/docs/guides/prompt-caching)、投机解码 [Speculative Decoding](https://arxiv.org/abs/2211.17192)、语义缓存 [GPTCache](https://github.com/zilliztech/GPTCache) / [Redis LangCache](https://redis.io/solutions/use-cases/langcache/).
   - 协议、原语与工具缓存：[MCP](https://modelcontextprotocol.io/)、[Anthropic Skills](https://github.com/anthropics/skills)、[Tool Result Caching](https://agentpatternscatalog.github.io/patterns/patterns/tool-result-caching.html)、[Firecrawl](https://www.firecrawl.dev/)、[Context7](https://context7.com/)、有状态工具值缓存 [TVCache](https://arxiv.org/abs/2602.10986)（2026-02）.