CAKE架构：编译器与Agent协同演进，重塑AI辅助编程

大家都在聊 AI 辅助编程但大多数路数还是“Agent 写代码编译器在旁边事后报错”。代码写得不对Agent 改一版编译器又报一次错来回拉锯。我自己折腾过一段时间之后越来越觉得这个模式有问题编译器掌握的信息量极大却只被当作一个报错器在用Agent 手里拿着大模型却对编译器内部状态一无所知。所以当朋友跟我聊起“CAKE编译器与Agent协同演进”这套思路时我一下子来了兴趣。CAKE 的核心就是把编译器从“门卫”变成“助手”让 Agent 不再盲改代码而是基于编译器给出的结构化反馈来决策两边形成闭环一起迭代。这篇文章我想把自己对 CAKE 的理解、设计拆解和一份最小可跑的实操 Demo 都写下来适合正在做 AI 编程工具、编译器工具链或者 Agent 框架的工程师参考。1. 编译器与Agent先从各自的天花板说起1.1 传统编译器为什么管不住现代 AI 编程编译器本质上是把“代码文本”翻译成“机器可执行信息”的通道同时在翻译过程中做大量静态检查。它的优势非常明确精确、可判定、有完整的类型系统和数据流信息。但传统编译器的输出面向的是人类开发者是“第几行第几列有错”这样的事件流而不是“这个错误为什么会出现、应该怎么改更合理”的知识输出。Agent 恰恰相反。基于大语言模型的编程 Agent 优势在于理解模糊意图、生成代码、做跨文件修改。但它有一个致命弱项它对代码真实语义没有稳定的感知。它“读过”代码但读法跟编译器完全不同它看不到符号表看不到作用域链也看不到类型约束。我把这个矛盾总结成一个比喻Agent 像一个凭经验和直觉画图纸的设计师编译器像一个只按规范验收的质检员。设计师画完一版质检员打回来设计师改再画一版质检员再打回来。两个人之间没有对话只有结果传递。这样的协作效率大家各自心里都有数。1.2 协同的真正收益不只在“少报几次错”一开始我以为把编译器信息和 Agent 结合起来无非是让 Agent 少犯几次错。但等我真正梳理完 CAKE 的设计逻辑后发现收益远不止这一点。反馈从“事件”变成“证据链”传统报错只告诉 Agent 哪里错协同模式下编译器可以提供错误发生的推导链路比如某个变量第一次在哪个作用域声明、后来在哪里被遮蔽、最终在哪里被误用Agent 就能看懂问题根源。修改从“盲试”变成“可预演”Agent 在动手改之前可以先问一下编译器“如果我把这个表达式的类型换成 X依赖它的那几个函数会受影响吗”编译器可以提前给出影响范围。上下文从“猜”变成“按需加载”Agent 通常面临上下文窗口限制。编译器可以精确地告诉 Agent这个问题只涉及哪几个函数、哪几条数据流路径Agent 只需加载这些代码片段不需要把整个仓库倒进上下文。协同演进的核心逻辑就藏在第二点上编译器不再是一个被动检查器Agent 也不再是一个只会写代码的生成器两者通过一套稳定的接口交换信息互相把对方的能力边界往外推一层。1.3 谁最适合参考这套设计我自己做的是语言工具链和 AI 编程助手相关的方向所以会从这两个角度切入。不过 CAKE 的思路并不局限于这两个领域下面几类人应该都能从中找到一些值得借鉴的东西做 IDE 插件、代码补全、自动重构工具的人做 Agent 框架、智能编程助手的人研究编译原理、程序分析但想把这些能力落地到 AI 场景的人被 AI 写代码的“乱改一通”坑过很多次的一线程序员。后续的实操 Demo 我会尽量降低门槛哪怕你对编译器内部不熟也能跟着跑起来。2. CAKE 的整体架构编译器与 Agent 之间的双向信息回路2.1 五个层面从代码文本到执行反馈CAKE 的整体架构我习惯按五个层面去看每一层只干一件事层与层之间靠约定好的数据格式通信不直接用内部对象互相调用。层面职责典型输出感知层词法分析、语法分析、生成 ASTToken 流、AST、语法错误列表语义层类型检查、作用域解析、符号表构建类型信息、符号表、语义诊断策略层根据诊断信息与代码结构生成修改建议补丁建议、影响范围、冲突提示决策层Agent 综合用户意图与编译器反馈做判断修改计划、下一步动作执行层应用修改、回归验证、增量编译新代码、验证结果、更新后的诊断传统编译器只做前两层最多给出一堆诊断信息。Agent 单独跑时是直接从代码文本跳到第四、五层中间缺少语义支撑。CAKE 把中间三层串起来形成一个完整回路。2.2 接口设计不追求“原生融合”追求“协议稳定”我看过很多项目试图把 Agent 直接嵌进编译器内部调编译器内部 API短期跑起来很爽但升级编译器版本就崩了维护成本极高。CAKE 在接口设计上换了一个思路不试图让 Agent 理解编译器内部细节而是把编译器能力封装成一组稳定、可描述的服务。编译器对外开放的能力至少包括describe(file, symbol)查询某个符号的定义、引用、类型diagnose(file)返回基于作用域和类型推导的结构化诊断predict(change_patch)在虚拟环境中预演某个补丁的影响范围minimize(span)把一大段报错缩小到最小可复现区间apply(patch)安全地把补丁应用到代码中并返回新诊断。Agent 反向提供给编译器的接口则简单得多核心只有两个report_modify(plan)告知本次修改想动哪些文件、哪些函数意图是什么report_done(context)修改完成后同步最终状态让编译器重新建立索引。这两个方向的接口也不一定需要复杂的框架支撑直接用 JSON 或者简单的远程调用协议就能实现。关键是让两端只依赖这份协议不要让对方碰自己的内部数据结构。一旦 Agent 想直接读取编译器的符号表或者编译器想直接获取大模型内部向量这种耦合一定会把整个系统拖垮。2.3 每一次修改都是一次“小步验证”CAKE 里最核心的机制不是对话而是“验证回路”。Agent 每提出一个修改方案编译器立刻给出一份影响评估Agent 根据评估决定是继续、调整还是放弃。这个回路保证任何错误在变成代码之前至少先经过一次静态层面的预演。我自己的体会是这个回路必须做得很轻不能每次都要跑完整套编译、链接、测试否则 Agent 等待反馈的时间太长交互体验会非常差。一个比较可行的做法是为每个项目建一个轻量的增量编译服务只重新编译受影响的那几个编译单元把单次反馈时间压到百毫秒级。这样 Agent 可以很流畅地在几次小步修改中逼近一个正确版本。3. 核心实现要点让编译器“会说话”让 Agent“有约束”3.1 编译器侧把内部信息翻译成 Agent 可消费的知识编译器的潜能其实远超一般人的认知。它手里有完整的 AST、符号表、类型约束、数据流图问题是这些数据结构都是为编译器后端准备的Agent 根本读不动。CAKE 的第一步不是让 Agent 变强而是让编译器学会“翻译”。我举个例子。假设代码里有个类型错误把一个字符串传给了期望整数参数的函数。传统报错会写“参数类型不匹配”Agent 收到这条消息后只能盲猜。CAKE 模式下编译器输出的诊断会变成这样{ span: { file: src/order.py, start: [124, 17], end: [124, 29] }, message: 字符串类型的表达式被传给了期望 int 类型的参数, evidence: [ 变量 user_id 在 src/auth.py:86 被赋值为 str 类型, 函数 load_order 在 src/order.py:210 定义第二个参数声明为 int ], suggested_fixes: [ { kind: cast, patch: int(user_id), affected: [src/order.py:210] }, { kind: type_change, patch: 将 load_order 第二参数声明改为 str, affected: [src/order.py:210, src/api.py:77] } ] }这是关键一步诊断信息里带上证据链和候选修复方案Agent 拿到的不再是一句冷冰冰的报错而是一份“问题说明书”。在实际实现中这类结构化诊断仍然保留人类可读的消息字段因为日志和快速排查还是需要它但额外增加机器可读的证据与候选就会让 Agent 的决策质量高出一个级别。3.2 Agent 侧在不牺牲“自由发挥”的前提下加限制给 Agent 加太多约束会让它丧失灵活性不给约束又会出现“自信地输出错误代码”。CAKE 的做法是给 Agent 一个“决策骨架”而不是一堆死规则。所谓决策骨架指的是把 Agent 每次决策拆成固定阶段理解阶段先让编译器返回当前文件的诊断概况Agent 自己定位“哪些错误是同一根源”。计划阶段针对一个根源问题生成候选修改方案必须显式声明“动哪些函数、改哪些类型”。预演阶段调用编译器的predict接口获得影响范围如果影响范围为非空必须说明“这个影响是可接受的”。执行阶段应用补丁再触发一次诊断确认错误列表缩短。收尾阶段更新编译索引记录本轮修改的经验摘要供下次决策参考。这套骨架不会告诉 Agent 具体怎么写代码只要求它每一步都要跟编译器对齐一次信息。这样既保留了 Agent 理解意图和生成代码的能力又避免它像没头苍蝇一样乱试。上下文管理上我也踩过一个坑一开始把编译器所有诊断结果全塞进 promptAgent 的注意力被劈成好几块反而抓不住重点。后来改成“诊断摘要 按需展开”的方式默认只给 Agent 前三个最核心的错误证据只要 Agent 还想看更细的信息再动态向编译器发请求。实际效果比全量塞入好不少生成质量也明显更稳。3.3 协同演进的“演进”到底体现在哪里“协同演进”里的“演进”两个字不是指产品版本迭代而是指编译器与 Agent 的能力边界会随着协同过程不断往外扩展。刚开始编译器比 Agent 强Agent 主要负责按编译器给的线索做修补跑了一段时间之后Agent 开始累积“哪些修改模式更容易被编译器接受”再过一段时间编译器侧也在收集 Agent 高频使用的查询模式在诊断时就可以优先给出 Agent 熟悉的那种修复形式。我把这个过程拆成三步落地第一步基础能力对接。先把编译器的诊断接口、查询接口稳定下来Agent 学会使用这些工具实现“能对话”。第二步反馈数据回流。记录 Agent 的每次决策、每次修改是否降低编译错误数、是否引入新问题把这些结果作为评估信号写回两个系统。第三步策略自适应。编译器看到某些诊断的“修复采纳率”很低就调整候选修复的排序Agent 看到某些修改模式反复引入新错误就在决策时降低这类模式的优先级。“演进”的核心不是某一个系统的升级而是两个系统之间形成一个持续优化的闭环。这个闭环跑的时间越长系统整体能力越强。这里有个容易被忽视的细节不要让 Agent 直接修改自己的策略权重这会让行为不可解释。更好的做法是让编译器或外部评估模块生成“策略调整建议”Agent 只接收不拒绝但要不要采纳由更高层模块决定。4. 实操环节半小时搭一个最小可运行的 CAKE 原型理论说太多不动手终究是虚的。下面我用一个极简的示例语言来搭 CAKE 最小原型。语言本身很简单只支持整数运算和变量赋值但足够把“编译器反馈 - Agent 决策 - 修改 - 再编译”的闭环跑通。我用的 Python主要是方便大家直接复现不需要额外装编译器。4.1 定义 AST 与前端解析器先定义一种叫 L0 的小语言每条语句只有两种形式。# ast_nodes.py class Assign: def __init__(self, name, expr): self.name name self.expr expr class BinOp: def __init__(self, op, left, right): self.op op self.left left self.right right class Var: def __init__(self, name): self.name name class Num: def __init__(self, value): self.value value解析器不需要很复杂按行读取用最简单的分词逻辑。# l0_parser.py from ast_nodes import Assign, BinOp, Var, Num def tokenize(line): tokens [] for ch in line: if ch.isalpha(): tokens.append([var, ch]) elif ch.isdigit(): tokens.append([num, int(ch)]) elif ch in -: tokens.append([op, ch]) elif ch : tokens.append([eq, ch]) return tokens def parse_assign(tokens): name tokens[0][1] expr parse_expr(tokens[3:]) return Assign(name, expr) def parse_expr(tokens): left None op None for typ, val in tokens: if typ num: if left is None: left Num(val) elif op: left BinOp(op, left, Num(val)) op None elif typ var: if left is None: left Var(val) elif op: left BinOp(op, left, Var(val)) op None elif typ op: op val return left这一小段代码就完成了感知层的初步工作后面所有分析都基于这棵 AST。4.2 编译器侧输出结构化诊断搭一个简单的符号表检查变量是否定义、类型是否为整数。# l0_checker.py def check(ast_list): symbols {} diags [] for stmt in ast_list: if isinstance(stmt, Assign): check_expr(stmt.expr, symbols, diags, stmt.name) symbols[stmt.name] int return diags def check_expr(expr, symbols, diags, ctx): if isinstance(expr, Var): if expr.name not in symbols: diags.append({ span: f{expr.name}, message: f变量 {expr.name} 未定义在给 {ctx} 赋值时使用, evidence: [f当前作用域已有变量: {list(symbols.keys())}], candidate_fixes: [ {kind: insert, patch: f{expr.name} 0, before: ctx} ] }) return int if isinstance(expr, BinOp): lt check_expr(expr.left, symbols, diags, ctx) rt check_expr(expr.right, symbols, diags, ctx) if lt ! int or rt ! int: diags.append({ span: fbinop, message: f二元运算 {expr.op} 的操作数类型异常左{lt}右{rt}, evidence: [], candidate_fixes: [] }) return int return int这里的重点是每个诊断里都带着candidate_fixes这正是“让编译器会说话”的最小实现。在实际系统里候选修复可以来自静态分析规则比如未定义变量可以自动补一个默认初始化类型不匹配可以自动套一层转换。4.3 Agent 侧按“理解-计划-执行”来做决策先不用大模型我用一个简单的规则“Agent”来演示决策逻辑。它的任务是读取诊断按候选项生成补丁然后再让编译器重查。# l0_agent.py def agent_plan(diags): patches [] for d in diags: fixes d.get(candidate_fixes, []) if fixes: fix fixes[0] patches.append(fix[patch]) return patches def apply_patch(src_lines, patch, target_file): new_lines list(src_lines) for p in patch: if in p and p.count() 1: # 补丁是“变量名 默认值”时插入到文件开头 new_lines.insert(0, p) return new_lines为了方便演示这里的补丁处理直接做字符串级操作实际工程必须用语法树层面的补丁否则很容易改坏代码。4.4 闭环把整个循环串起来# l0_cake.py from l0_parser import tokenize, parse_assign from l0_checker import check from l0_agent import agent_plan, apply_patch source [a x 2, b a y, c a 1] ast_list [parse_assign(tokenize(line)) for line in source] diags check(ast_list) print(第一次诊断, diags) patches agent_plan(diags) if patches: source apply_patch(source, patches, demo.l0) print(Agent 生成补丁, patches) ast_list [parse_assign(tokenize(line)) for line in source] diags check(ast_list) print(第二次诊断, diags) print(更新后代码, source)跑一下这个脚本你会看到输出大致是这样第一次诊断 [{span: x, message: 变量 x 未定义...}, {span: y, message: 变量 y 未定义...}] Agent 生成补丁 [x 0, y 0] 第二次诊断 [] 更新后代码 [x 0, y 0, a x 2, b a y, c a 1]虽然只是个玩具级实现但它已经把 CAKE 的核心回路展示清楚了。真实场景中把规则 Agent 换成大模型 Agent、把 L0 换成 Python/Java 编译器、把字符串补丁换成语法树补丁架构骨架是不变的。4.5 从最小原型迁移到真实工程的几个台阶从原型往生产级走至少要补上几块硬骨头在线编译服务真实项目的编译耗时不可忽略需要把编译器做成常驻服务用增量编译和缓存缩短反馈时间。C、Rust 这类重型编译器尤其需要精心设计增量策略。补丁格式不要直接让 Agent 返回整段新代码而是返回结构化补丁。我建议使用类似“多文件 diff 描述 语义修改说明”的格式让编译器可以在应用前先预演。评估体系建立“错误消除率”“新错误引入率”“修改收敛步数”三个指标每次 Agent 修改完都要自动更新这些指标作为协同演进的基线数据。回滚机制Agent 修改引发新错误时必须有快速回滚到上一版本的能力。CAKE 的理想状态是编译器的诊断可以让 Agent 自我纠错但现实世界中总有系统覆盖不到的行为回滚是最后的安全网。5. 常见问题与避坑经验5.1 问题速查表现象根因解决办法Agent 反复尝试同一类修改错误原样不动诊断信息不够具体Agent 只能猜强化evidence字段给出更长的因果链Agent 一次改了过多文件引入新错误缺少影响范围限制用predict接口限制补丁影响边界编译器反馈太频繁Agent 上下文被打爆诊断输出没有分级按“摘要 按需展开”的方式组织反馈补丁应用后代码格式混乱补丁基于字符串操作改用语法树层面补丁应用后自动格式化Agent 和编译器版本不同步接口错乱协议版本没锁接口层加版本号不兼容时显式报错5.2 几个我自己踩过的坑提前帮你避开第一“想让编译器一下诊断出所有问题”是个诱惑但要克制。实际跑下来一次性暴露八十个错误和暴露三个错误Agent 最后的修复结果没什么区别但前者的失败率高得多。因为问题太多时Agent 分不清哪些是根源哪些是衍生修改动作会变得很碎。我目前的策略是让编译器默认只报 Top 5 错误Agent 修复完一轮后再往下展开。第二不要忽视编译器的“沉默成本”。编译器检查通过之后Agent 的任务在很多人看来就算完成了。但在真实项目里类型检查通过不代表没有逻辑错误更不代表没有性能问题。CAKE 这类架构的下一步一定要把运行期反馈也接进来比如测试覆盖率、Profiling 结果、运行时 panic 信息。这属于协同演进的进阶形态但架构上从设计第一天就要为这类“执行反馈”留下扩展位。第三协议设计要容忍“二进制信息”。我最早设计诊断接口时强制要求所有信息都能变成文本给大模型读后来发现某些大型代码库的依赖图特别大转成文本极其冗长且低效。更好的方案是给 Agent 一个“句柄”比如一个不可读的依赖图 IDAgent 需要时再向编译器发起定向查询。这个设计能让上下文占用减少一半以上。5.3 演进路线上容易走偏的三个信号很多团队做类似协同系统时中期会出现几个危险信号我列出来你可以拿来自查。信号一Agent 效果不错但完全依赖人工设计好的修复模板。这说明系统还没进入“演进”阶段本质还是一条静态规则流水线。判断标准是如果换一个模型或换一种代码风格效果是否大幅下降。信号二编译器接口升级之后Agent 行为大面积劣化。这说明反馈回路没有带上版本兼容意识Agent 在依赖一个“可能变化但没约定”的内部行为。信号三离线评估指标好线上一塌糊涂。这通常是测试集和真实代码分布差异太大。解决方法是把线上真实诊断数据脱敏后回流到离线评估集让评估集跟着线上分布持续刷新。我个人很长一段时间内一直纠结要不要给 Agent 接 LSP语言服务器协议而不是直接接编译器。后来发现 LSP 是个不错的中间层但它面向“人类阅读诊断”设计信息粒度对 Agent 来说还是偏事件化。CAKE 的价值恰恰在于直接在编译器这个“信息源头”层面做一次结构化加工输出的东西既可以让 Agent 消费也可以再转成 LSP 格式给 IDE 用。这样是一条更干净、扩展性更好的路。6. 协同演进里的设计取舍与后续扩展6.1 三个关键取舍“快反馈”优先于“准反馈”。做这个系统时我一度特别想把错误分析做得很深、很细让 Agent 一次性获得最准确的根因分析但很快就发现等待时间太长Agent 决策节奏完全被打乱。改成先给一个“八成准确但很快”的预分析让 Agent 先动起来再逐步补充信息之后整体收敛速度反而更快。这个取舍在互动高频的系统里非常关键编译器一次全量分析可能花 10 秒而增量预分析往往只需要 200 毫秒我建议所有接入 Agent 的反馈路径都以 200 毫秒以内作为设计目标。“意图记录”比“代码生成”更重要。Agent 修改完代码后很多人只关心代码对不对忽略记录“为什么要这么改”。CAKE 的协议里我预留了report_modify接口刚开始觉得是多余的后来发现它价值极高下一轮编译器分析时可以顺着 Agent 的意图去判断“这是有意为之还是无心之失”。比如 Agent 改了一个变量类型编译器可能觉得不匹配但如果 Agent 记录了“接口回归需要换成新类型”的意图编译器就不会把这条当作新错误上报。“可解释性”不靠事后解释靠事前结构化。很多大模型系统会在出错后让模型自己解释为什么犯错这种事后解释大多不可靠。CAKE 的做法是把决策过程本身结构化成可查询的日志文件Agent 的每一步修改、每一次预演、每一个被拒绝的方案都自动进入决策日志。需要排查时直接看日志就能还原整个过程不依赖大模型的口供。6.2 扩展方向一运行期反馈回路静态编译器反馈能覆盖的问题很有限真正有价值的协同演进必须一路扩展到运行期。比如某个 Agent 修改了内存池的配置静态检查完全没问题但跑压力测试时内存占用异常这种现象数据如果不回流到 Agent 的决策依据下次它还会再犯。我建议在架构上把“编译器反馈”和“运行时反馈”都抽象成同一类消息格式事件 证据 候选行为。静态错误是事件运行期性能抖动也是事件类型推导链是证据Profile 调用栈也是证据“改类型”是候选行为“增加缓存大小”也是候选行为。这样 Agent 学会的决策模式可以平滑迁移到不同类型的问题上。6.3 扩展方向二多智能体协同CAKE 的回路并不限定单 Agent。当项目规模变大时可以拆成多个 Agent一个负责重构、一个负责修 bug、一个负责补测试但它们不能各干各的必须通过同一个编译反馈服务来同步状态。编译器的角色在这种场景下会升格为“公共事实来源”任何一个 Agent 修改了符号或接口状态变化实时广播给其他 Agent相当于整个团队共享一张“变量状态表”。实现上也不复杂只需要在编译服务里加一个订阅发布机制。Agent 修改代码后发送意图编译器更新索引并推送影响事件订阅了相关模块的 Agent 自动收到变更通知。这个过程里没有人类介入但每个 Agent 的行为都受到编译器反馈的实时校准。最后再分享一点个人体会一开始做 CAKE 这类协同架构时我犯过最多的错误是把编译器当“神”总觉得它的反馈一定是对的Agent 只要照着改就行。跑了一段时间才发现编译器有时给出的候选修复并不适合当前项目风格它只保证“类型正确”不保证“重构合理”。后来我在设计里加了一个“建议采纳率”的指标编译器每次给候选修复Agent 是否采纳采纳之后错误是否真正消失都会被记录。这个指标反过来也在逼着编译器优化自己的“表达方式”——同样的一个类型错误是建议我改函数签名还是建议我改调用点这里面的项目上下文差别很大。另外在实际工程里千万别想着一步到位。先挑一个最频繁报错、最让 Agent 头疼的错误类别接入反馈回路比如未定义变量、类型不匹配、缺失导入把这三个类别跑稳了再逐步扩大到安全检测、性能分析、架构约束。每扩一个类别都要把编译器输出的结构化诊断格式审查一遍确保新增信息不会污染已有的分析链路。这样迭代下来整个系统的稳定性和数据质量都会超出你最初的预期。我也见过有团队把这类协同系统用在代码评审流程中编译器先把所有潜在问题过一遍Agent 结合提交意图筛选出真正需要人关注的子集评审人只需要看筛选结果反馈效率提升非常明显。CAKE 这条路现在还没到成熟阶段至少在我接触过的项目里编译器和 Agent 真正形成高频双向回路的还在少数。但方向很清晰编译器不该继续当一个只会挑刺的裁判Agent 也不该继续当一个看不见类型系统的盲修改者。两边真正协同起来AI 编程的可靠性和工程化水平才会有质的提升。