【别再把逻辑全塞给LLM：后端做Agent的架构决策方法论】-平芜编程栈

注：文中TCC指我们日常用的动态配置中心。

在刚入行做后端开发的时候的黄金准则：

核心稳定、不怎么变的逻辑，老老实实写死在代码里，比如参数校验、权限拦截、接口调用逻辑
经常要改、运营产品天天调的规则，全扔TCC配置中心里，比如活动规则、流控阈值、黑白名单、提示文案

这套「代码+TCC配置」的二分法我一直在用，写过活动规则，配过限流降级开关，搞过风控敏感词拦截，从来没翻过车，——直到最近我业余时间自己折腾写个小Agent玩，被按在地上摩擦了大半个月。

一、自己造Agent玩，我两周改了5版

最近闲下来想写个自己用的代码审查小助手：输入我写的代码片段，自动帮我找bug、给优化建议、补注释，还能帮我写单测（不追求实用性，只为了尝试一下agent开发）

我下意识就按老经验拆分了：

硬编码层：代码解析逻辑、单测生成的固定模板、工具调用逻辑，全部写死在代码里
TCC配置层：把代码审查规则全放里面，比如"SQL语句必须加参数占位符"“循环里不能查数据库”（诸如此类，测试使用），我寻思这和之前做活动规则配置没区别啊，以后想到新的审查规则直接加配置就行，不用改代码重启。

结果调了两天就发现不对：

我写了个Go的goroutine泄露的代码，配置里我只配了"协程要加WaitGroup"，没配"channel未关闭会导致泄露"，小助手直接返回"代码没有问题"，我自己看了半天才发现漏了规则。
立马补上这条规则，过两天写Python代码的时候又卡壳：配置里都是Java的规则，Python的缩进问题、GIL锁相关的问题它完全不知道，我又得往配置里堆Python规则，堆了几十条还是漏。
后来我破罐子破摔，把配置里的规则全删了，让LLM自己想怎么审查，结果更离谱：我写了个正常的工具类，它给我扯了一堆分布式事务、微服务治理的优化建议，完全不沾边；甚至有时候还会把我正确的业务逻辑改错，说我写的不符合"阿里Java开发规范"，根本不管我写的是脚本。

那段时间我白天上班写业务，晚上回家改Agent，两周提交了5个版本，越改越混乱：要么规则配不全覆盖不了场景，要么全交给LLM就瞎给建议。我摸鱼的时候想破头：这套我用了两年的黄金准则，怎么自己写个小玩具都不好使了？

二、用了两年的二维模型，为什么突然失灵了？

我翻了之前做过的所有项目，突然发现之前的方法之所以好用，是因为所有场景都满足一个我从来没意识到的前提：输入可穷举、流程可预定义、Schema是封闭的。

不管是做活动规则还是风控拦截，我在写代码/配TCC的时候，总能把所有可能出现的情况列出来：

活动规则无非就是满减、折扣、优惠券几种组合，字段固定，判断逻辑固定
风控敏感词无非就是提前录入的词库，匹配到就拦截，输入输出都是固定的

我们常用的SPI扩展点、策略模式、规则引擎，本质上都是这个逻辑：不管你怎么扩展、怎么配置，接口是提前定义好的，输入字段是提前写死的，能处理的场景是开发者提前想到的——我把这种灵活叫做「假灵活」，灵活的范围早就被圈死了。

但我自己写这个代码审查Agent面对的场景完全不一样：

输入是开放的：我可能给它传Java、Go、Python、Shell甚至是SQL代码，可能是业务逻辑、可能是工具类、可能是并发代码，我就算想破头也不可能在配置里枚举完所有语言、所有场景的审查规则
流程是动态的：审查并发代码要重点看锁、协程泄露，审查数据库代码要重点看SQL注入、索引命中，审查工具类要重点看兼容性，审查步骤根本没法提前画好固定流程图
输出是不固定的：有时候要给bug修复建议，有时候要补注释，有时候要写单测，有时候要做性能优化，根本没法提前固定输出格式

我之前一直用两个维度做决策：

复杂度：逻辑难不难，出问题影响大不大
变更频率：逻辑改得勤不勤，发版成本高不高

但这个二维模型有个致命缺陷：它区分不了两类完全不同的逻辑：

一类是复杂但死板：比如TCC配置的解析逻辑、订单状态机流转，实现起来难，风险也高，但流程100%固定，半分都不能变
一类是复杂且灵活：比如代码审查的判断逻辑、自然语言意图理解，哪怕逻辑看起来简单，你也永远枚举不完所有可能的情况

之前做公司业务的时候，后一类逻辑占比不到5%，靠人工兜底就过去了，我从来没意识到需要单独把它拎出来；但自己做Agent的时候这类逻辑占了一半以上，二维模型彻底不够用了——我缺了第三个维度。

三、第三维度：灵活度

我把这第三个维度叫做「灵活度」，定义很简单：这块逻辑能不能处理我开发时根本没预想到的未知场景。

三个维度的边界非常清晰，完全不重叠：

复杂度是静态属性：逻辑本身难不难，出问题影响有多大
变更频率是时间属性：逻辑多久改一次，改的成本高不高
灵活度是行为属性：能不能适配没见过的新场景，要不要动态做决策

我之前最大的认知误区就是把复杂度和灵活度划等号，后来才发现这俩完全是两回事：

高复杂+极低灵活：之前做过TCC配置中心的推送逻辑优化，前前后后写了半个月，要考虑网络抖动、顺序一致性、灰度放量，复杂到爆炸，但流程100%固定，半分都不能灵活，乱序就可能导致配置错推引发故障
低复杂+极高灵活：我给Agent加的闲聊功能，逻辑简单到就调一下大模型接口，但用户可以和它聊任何内容，从问代码问题到问今天吃什么，根本不可能枚举完所有回复

还有个反常识的点：高灵活的系统一点也不简单。我之前以为把逻辑扔给LLM就完事了，结果复杂度只是从「写固定审查规则」转移到了「防幻觉、做边界兜底、校验输出格式、控制建议范围」上，一点也不比写硬编码轻松，这也是我踩了无数坑才明白的道理。

为了方便判断，我把灵活度分成了三级，拿到任何一块逻辑问三个问题就能定级：

L0 低灵活：开发的时候能100%枚举完所有输入、路径、输出，比如参数校验、TCC规则解析，没什么好说的
L1 中灵活：输入枚举不完，但执行路径、输入输出Schema是固定的，比如多语言代码解析、不同类型单测的模板生成，靠插件/策略就能覆盖
L2 高灵活：输入完全开放，执行路径要动态生成，输出也不固定，比如代码问题识别、优化建议生成、多轮对话答疑，根本没法提前枚举完

四、三维决策矩阵：写代码、配配置还是交给LLM？

踩坑踩多了也就总结了一套决策表：

复杂度	变更频率	灵活度	应该用什么方案	日常场景举例
任意	任意	L0	硬编码	代码解析逻辑、输出格式校验、配置文件解析、工具调用封装、高危操作拦截
低	高	L0/L1	配置/规则引擎	通用审查规则、敏感词、提示词模板、黑名单、默认兜底话术
中	中	L1	插件/策略模式/工作流	多语言解析器、不同类型代码的固定检查流程、单测模板生成
任意	任意	L2	LLM/Agent动态推理	代码问题识别、优化建议生成、自然语言理解、多轮对话答疑

我后来用这套方法把我的代码审查小助手重构了一遍，三层逻辑拆得明明白白：

硬编码层（L0）：代码解析封装、输出Markdown格式强制校验、工具调用逻辑、越权操作拦截——这部分改完之后到现在一个多月没动过
配置层（L0/L1）：通用代码规范规则、禁止生成的危险代码片段、不同语言的基础提示词模板、功能开关——我自己随时改配置文件就行，不用动核心代码
LLM动态层（L2）：识别代码语言和类型、动态选择适用的审查规则、生成针对性的优化建议、回答我关于代码的疑问——这部分完全交给大模型自由发挥，不做硬限制，但是有硬编码层兜底，绝不会出现乱改正确逻辑、给无关建议的情况。

重构之后效果特别明显：之前两周改8版，现在一个多月只改了2次核心逻辑，审查建议的准确率从最开始的50%多升到了90%以上，再也没出现过给分布式事务这种离谱建议的情况。

这里特别想说一个做Agent最核心的原则，我踩了无数坑才明白：灵活度必须被锁在硬边界里。
不管LLM怎么推理，绝对不能绕过配置里写的禁止危险代码规则，绝对不能跳过输出格式校验，不符合要求就直接重试或者返回兜底结果——没有任何一个能用的Agent是100%灵活的，三层配合才是真的稳。

五、几个踩过的坑

我这大半个月踩的坑比之前半年写业务都多，列几个最容易踩的，大家自己玩Agent的时候别再走弯路：

别过度灵活：别什么逻辑都扔给LLM，该硬编码的地方绝对不要省，固定规则比大模型靠谱多了。
别灵活不足：也别啥都想往配置里塞，我最开始想把所有可能的代码问题都枚举成规则配到文件里，配了一百多条发现永远有新问题，累到吐血还覆盖不全。
别模糊边界：一定要把三层边界划清楚，LLM绝对不能碰硬编码层的逻辑，比如不能直接修改我的代码文件不经过备份校验。
灵活度不是越高越好：每一级灵活都有代价：硬编码最稳最快成本最低，配置化次之，LLM推理速度慢、API花钱、还有幻觉风险。涉及到文件修改、数据写入这类操作，哪怕再需要灵活，也必须加硬编码校验，稳永远是第一位的。