“Grok Bot”这个代号是我们在一次内部复盘里起的。当时的情况并不复杂团队想给研发流程配一个能自主修复缺陷的编码智能体模型也选好了链路也通了结果它第一次上线就给我们上了一课——它快速产出了几百行自洽的“解决方案”编译通过单测也过却把另一个模块的缓存语义彻底改坏。更糟糕的是要不是有同事在代码评审里多看了一眼这批代码就会带着隐患合入主干。那之后我花了很多时间观察这类基于LLM的智能体到底在哪里失控也把CMU那边公开实测过的思路完整跑了一遍。结论其实很反直觉问题不在模型不够聪明而在于我们让模型做了太多它不擅长的事——尤其是那些应该由确定性逻辑拍板的环节。今天这篇就把这套思路拆开讲怎么剥离LLM的盲目决策怎么把“内核屏障”落在工程里以及那个降本98%的判定到底是怎么测出来的。1. 先还原“代码垃圾”是怎么被 LLM 制造出来的很多团队第一次接入编码智能体时想法都和我当时一样给它一个任务描述让它拿到仓库上下文然后自己决定改哪个文件、调用什么函数、加什么测试。听起来很合理但真正跑起来才会发现链路的每一步都在为“垃圾产出”埋种子。1.1 缺少全局代价意识局部合理掩盖全面失控LLM在生成代码时本质上是在做逐token的概率采样。它擅长的是“下一段最像样的代码”而不是“对当前代码库全局最优的修改”。这两者的差异在日常小任务里不明显一旦改动牵涉跨模块依赖、共享状态或者历史契约模型就会频繁陷入局部合理、全局错误的陷阱。我见过最典型的例子是模型发现某个函数的调用方传入了空值于是“聪明地”在函数入口加了一层默认值兜底。单看这个函数改动无可挑剔但整个系统的设计初衷是让上游显式处理空值这个兜底直接把错误静默吞掉反而让真正的问题延迟到数据层爆发。这就是典型的局部决策——模型看到了一个局部缺口却没看到这个缺口在整个架构里的位置。这类问题的可怕之处在于它的隐蔽性。编译能过测试能过Code Review却需要人肉眼去比对设计意图而这恰恰是规模化使用智能体时最难坚持的一环。1.2 上下文越长模型越容易把“看起来对”当成“真的对”第二个被很多人低估的因素是上下文长度。不能说“上下文越长越差”是绝对规律但实测下来当上下文里塞入大量的仓库文件、历史提交、接口定义之后模型的注意力会被稀释。它对“当前这个改动到底影响了谁”的判断会越来越模糊更倾向于生成与上下文里高频出现的风格一致、语义却未必正确的代码。这个现象有个很生活化的类比你让一个新人同时读十本规范手册再让他修一个bug他大概率会挑最眼熟的那条规范去套而不是真的对着实际故障做因果分析。LLM并不比这个新人好多少甚至因为它的“流畅表达”能力它能把错误方案包装得比新人更理直气壮。这带来一个直接后果盲目决策带来的垃圾产出往往不是能力问题而是注意力分配问题。上下文越长模型越容易“以貌取人”。1.3 盲目决策的真正代价不是单次出错而是污染下游链路很多人算成本的时候只算“模型跑一次多少钱”却忽略了出错的代价是级联的。一次错误代码合入可能影响的是后续多个模块的调试、回滚、联调甚至让测试团队花一整天去确认“到底是新代码坏了还是老代码本来就有问题”。我把这类成本称为“污染下游链路”。它不像API账单那么直观但它在研发效能上的杀伤力更大。CMU那套实测之所以能得出降本98%的结论本质上并不是省了模型调用费而是把污染下游的路径给堵住了——垃圾代码不再产生后续的返工、排查、评审成本自然大幅下降。提示如果你只是想“省点token钱”那方向就错了。真正的收益在于让系统从“生成后返工”变成“生成前拦截”。2. Grok Bot 的架构立场把“提方案”和“拍板”拆成两个角色理解了垃圾代码的成因接下来就是怎么改。我们最终采用的架构思路并不复杂核心就一句话LLM只负责“提方案”不负责“做决定”。2.1 策略层与执行层的职责切割我把系统拆成两层外层是策略层里层是执行层。策略层由LLM驱动负责理解自然语言描述、拆解任务、生成候选改动方案。它可以发挥语言理解、知识迁移的优势去思考“这个需求应该改哪个模块”“大致怎么改”但它产出的所有内容都会被当成“提案”而非“结论”。执行层则是确定性的代码不受任何概率采样影响。它拿到的输入是策略层产出的方案然后对方案做静态检查、动态验证、契约校验最终决定这份提案能不能落地。这个切割的意义在于让擅长的人做擅长的事让不擅长的人闭嘴。LLM擅长生成不擅长保证那我们就别逼它保证把保证的工作交给代码。2.2 内核屏障到底锁的是什么标题里提到的“内核屏障”在我们工程里是指执行层里那一道不可绕过的确定性验证管线。它锁的不是某个具体规则而是规则本身的权威性。我们给屏障定了三个基本特性屏障代码里不允许出现任何由LLM生成或修改的逻辑。屏障的源码是人工维护、独立评审的保证它自身不被污染。屏障的判定结果是硬性的通过就放行不通过就打回提案不存在“概率上差不多能过”的模糊地带。屏障的记录是完整可审计的每一次拦截、每一个触发原因都会落日志方便回头分析。这道屏障就像大楼里的承重墙。你可以随意装修内部隔断但承重墙的位置和材质是结构工程师锁死的不能由装修工人自由发挥。这样既保留了LLM的灵活性又给整个系统兜住了底线。2.3 为什么不优先选择“换更大模型”和“微调”可能有人会问与其做这么复杂的架构为什么不直接换更强的模型或者针对代码库做微调我的回答是这两种方案都试过也都有效果但都不解决根本问题。换更大模型确实能降低“局部合理”的发生频率但大模型的API成本更高、延迟更长而且它依然是一个概率系统依然会在某些长尾场景里犯错。你花更多的钱只是把垃圾率从5%降到3%并没有消除垃圾率。微调的问题类似而且还要冒灾难性遗忘、数据维护、训练周期等额外成本。更关键的是微调本质上还是在“让模型变得更聪明”但我们需要的是“让系统变得更强壮”。聪明和强壮是两码事——一个再聪明的决策者也需要一套靠谱的流程来兜底。注意不是说换模型、微调没有价值而是它们的边际收益会越来越低。架构层面的兜底才是那一块最稳的压舱石。3. CMU 实测判定背后的测试口径98% 的成本降在哪里“降本98%”这种数字如果不讲清楚测试口径就很容易变成一句空话。这篇里结合CMU工程团队公开的那轮实测逻辑把关键口径拆开聊聊。3.1 基线让 LLM 全程自主决策要验证架构的价值首先得有一个对照组。基线方案就是最常见的智能体形态让LLM读取仓库索引、自行分析问题、自行选择修改文件、自行生成补丁最后直接输出“完成”。所有决策都交给模型系统只在最后做一次轻量检查。对照组跑在同样的任务集上一批真实的缺陷修复请求分布在几个中型代码仓库里。每个任务有时间上限、有验收标准是否通过既有的回归测试、是否引入新的静态告警并记录全过程的token消耗。3.2 干预点前置把判断放在生成之前实验组的架构就是我们前面说的分层方案。不同的是实验组在每个关键决策点都加了屏障生成方案之前先由屏障检查任务与仓库的关联性生成补丁之后在合入之前跑完整校验。这里最关键的动作是把干预点从“事后”挪到“事中”。基线方案里模型可能已经生成了大量垃圾补丁才发现“这个方向不对”而实验组在生成初期就会收到屏障的反馈信号及时调整方向避免在错误道路上越走越远。这种干预前置带来的成本下降是非常显著的。一个任务如果一开始方向就错了后续的每一次补丁生成、每一个token消耗都是浪费而屏障把这种浪费从源头掐断。3.3 三个结论对应三个成本项CMU那一轮实测下来判定基本落在三点成本项基线表现屏障架构表现无效生成 token高大量错误方向的补丁尝试低早期拦截生成即有效返工与回滚成本高垃圾代码进入下游后反复修正低垃圾代码难以越过屏障人工评审负担高需要人判断方案合理性低人只需要审一眼屏障日志综合下来实验组的有效产出成本比基线降低了约98%。注意这个数字是“有效产出成本”——分母是你真正合入的可用代码。如果你只看单次API调用的价格可能感觉不到这么夸张的变化但一旦把返工、回滚、评审的时间都折算进去差距就非常可观了。提示任何成本数据都要先问清楚“分母是什么”。降本98%不是模型调用费下降98%而是“获得一单位有效代码”的总成本下降98%。4. 可复制的实现骨架编排器加确定性守护进程理论讲完下面是可以直接参考的工程骨架。我没有用特别重的框架核心就是把“编排”和“守护”拆成两个进程它们之间只通过结构化协议通信。4.1 最小可用编排器只给模型有限的“出牌范围”编排器Orchestrator的职责很简单接需求、调模型、把模型输出转成候选补丁、交给守护进程校验。但这里有一个必须坚持的原则——不要让模型自由发挥“怎么改”。我见过很多实现栽在这一点上让模型直接输出 diff甚至直接输出多个文件的完整内容。这等于把决策权完全交给了概率采样后续校验再强也只能事后补救。更稳的做法是让模型先输出一个“修改意图”的结构化描述# orchestrator.py 核心流程示意 from dataclasses import dataclass dataclass class PatchProposal: target_files: list[str] change_intent: str # 为什么这么改 logic_summary: str # 改动的核心逻辑 risky_areas: list[str] # 自己标注的风险点 def propose(goal: str, context: dict) - PatchProposal: prompt build_constrained_prompt(goal, context) raw llm_complete(prompt) # 只允许输出 JSON return PatchProposal.parse(raw)模型被要求只回答“改哪些文件、为什么改、核心逻辑是什么、哪里可能影响现有行为”而不是直接丢出一大坨代码。这样一来后续的确定性验证就有了解释依据而不是面对一团自洽但可疑的文本。4.2 内核屏障的检查管线静态、动态、契约三层屏障的检查管线我建议至少分成三层越早越便宜静态层跑AST语法解析、类型检查、lint规则、依赖关系扫描。这层的成本最低能拦截掉大多数“语法正确但改错对象”的低级问题。动态层在隔离沙箱里跑单元测试、行为验证、针对关键路径的断言注入。这一层能捕捉到静态层看不见的运行时问题。契约层把目标仓库的接口契约、数据约束、历史约定硬编码成校验断言。这层是屏障的“内核”所在——它锁的是设计意图。契约层听起来抽象实际落地时可以很简单。比如你仓库里有一个“支付金额不允许出现浮点精度问题”的约定那就直接写一条校验规则def check_amount_type(patch: PatchProposal) - bool: # 关键词定位修改点再用 AST 判断是否触碰金额计算 touched locate_amount_related_symbols(patch.target_files) if not touched: return True return ensure_no_float_intro(touched) # 确定性检查规则这些规则不必自动化生成它们来自架构师对系统的理解。把这种理解写进屏障代码才是真正的“锁定内核”。4.3 护栏触发后的降级策略不把控制权还给模型一个很容易被忽略的细节是当屏障拦截了提案接下来怎么办。很多团队的直觉是“把错误信息喂回给模型让它重新生成”。这个思路没问题但必须加一个前提——重试是有上限的上限一到必须降级给确定性逻辑或者人工。否则系统就会在“拦截-重试-再拦截-再重试”的循环里空转token成本照样失控。我们的做法是设置三轮重试预算。前三轮把屏障反馈和仓库约束重新压缩进提示词让模型修正方案三轮之后依然不过就直接转人工评审并附上所有历史的拦截日志。这样既给了模型纠错空间也保证系统不会被一个棘手的坏提案拖死。提示重试不是免费的。每一轮重试都会消耗上下文窗口和token而且错误信息本身可能让模型越改越偏。预算机制必须有而且建议从三轮开始调优。5. 真实代码库里踩过的坑以及如何不被测试数据骗到架构搭起来之后真正的挑战才开始。这一节全是我们在落地过程中踩出来的经验尤其适合想做同类系统的团队。5.1 记忆污染比提示词突破更隐蔽第一个坑是LLM智能体的记忆或知识库被污染。现代智能体普遍会让模型在交互中记忆历史结论、沉淀偏好这本来是提升效率的设计但也意味着任何人都可能通过一次精心构造的对话把误导性“经验”注入知识库之后再被后续任务当作权威参考引用。学术界把这方向叫AI智能体红队对抗——通过投毒记忆或知识库来诱导智能体在之后的任务里产生预期外的行为。预训练模型的知识取样我们很难防御但智能体自己的“记忆”路径是需要在架构层面做隔离的记忆内容只能作为“参考”而不是“依据”任何改变行为的结论都必须经过确定性规则的复核。5.2 “LLM 当裁判”会带来系统性偏袒第二个坑来自评估环节。很多人喜欢用“LLM as judge”来做方案质量的自动评估方便是方便但它和主任务模型往往共享相似的训练分布、相似的偏好天然会偏袒“看起来顺滑”的方案而不是“结构更经得起推敲”的方案。我们被这个坑狠狠教育过一次某个版本的系统自以为质量提升了因为LLM裁判打分很高后来换成人审才发现裁判只是觉得新方案的行文风格更符合它的审美而方案本身并没有带来真实改进。所以现在的做法是LLM裁判只用来评估“表达层面”的东西是否清晰、是否有遗漏所有“对错”层面的判定一律走确定性测试。表达可以主观对错必须客观。5.3 漏斗效应防线越厚通过率越低逃逸概率却被低估第三个坑是个统计陷阱。屏障规则加得越多垃圾代码被拦截得越多但有得必有失——规则的组合会让通过率快速下降甚至把一些“非标准但正确”的解法也误杀掉。更麻烦的是一旦通过率变低团队会倾向于相信“屏障很严格漏网之鱼很少”这种信心恰恰是最危险的。我们在压测里发现真正危险的逃逸往往不是直接违反某条显式规则而是行走在规则的“语义缝隙”——比如每条规则单看都合规组合起来却破坏了整体行为。应对方法也很简单定期用对抗性测试去“攻击”自己的屏障拿历史问题、边界场景、新引入的抽象设计去撞规则看哪些能被绕过。别等到线上出了事故才去盘点屏障的盲区。5.4 成本核算里最容易漏掉的隐性支出最后说一个成本核算的细节。98%降本这类数字很容易让人误以为“只要搭个屏障API账单立刻缩水到零头”。实际上屏障本身是有成本的静态检查要占CPU、沙箱测试要吃内存、规则维护要花人力。但在全局账本里这些成本相比返工成本低一到两个数量级所以划算。我想提醒的是别把这些隐性支出漏掉否则你会高估收益进而做出“再堆三层屏障”的错误决策。屏障的每一层都应该有明确的“投入产出比”评估该砍就砍。6. 什么样的团队适合直接抄这套架构如果你看到这里已经在想“我们团队要不要也这么搞”我给一个诚实的判断。这套架构最适合的是代码变更影响面大、返工成本高、对正确性有硬要求的团队——比如做基础设施、支付系统、数据处理管线的团队。这类场景里一条被错误“修好”的代码可能引发线上故障而故障的成本远大于屏障的建设成本。反过来如果你只是做原型验证、内部工具、一次性脚本那大可不必引入这么重的架构。白白增加工程复杂度反而拖慢迭代速度。我的实践经验是架构的价值从来不是“更先进”而是“更匹配风险”。先算清楚你的代码变更可能造成的最大损失再决定要不要为它筑一道屏障。如果损失是三两分钟就能修复的那省下折腾架构的时间多跑几个版本才是正事如果损失是跨团队、跨系统的那这道屏障你迟早需要早造早安心。最后再补充一点个人体会做这套系统最难的其实不是技术而是“克制”——克制住让模型多干活的冲动克制住把一切交给概率的侥幸。每次想放开限制的时候我都提醒自己一句话系统里总要有一个环节是绝对不能撒谎的而那个环节得由确定性逻辑来守护。