少即是多：代码分析场景中LLM参与度的精准调控之道

本文通过对比三种LLM参与度的架构（直接生成、结构化中间表示、Agentic生成），挑战了"更多LLM参与等于更好结果"的直觉假设。核心发现：结构化中间表示方案效果最佳，且token消耗仅为Agentic方案的1/8，为形式化领域的LLM应用提供重要启示。

大语言模型在软件工程领域应用广泛，静态分析工具（如Joern、CodeQL）的自然语言接口是典型场景。但LLM参与度的问题常被忽视：现有系统从直接生成查询到Agentic多轮调用不等，差异被视为实现细节而非独立变量。本文将"LLM参与度"作为独立变量研究，挑战传统直觉。

研究设计三种沿参与度光谱分布的架构（以Joern的CPGQL为目标）：

1. 直接查询生成：LLM端到端输出完整CPGQL，最大化参与度；
2. 结构化中间表示：LLM输出预定义JSON模式的中间表示，再由确定性转换器编译为CPGQL；
3. Agentic生成：LLM作为Agent多轮调用工具（模式查询、验证等）迭代构建查询，参与度最高。

实验构建20个代码分析任务基准（简单/中等/复杂三级），采用2×2模型设计（2个家族×2个规模），每个配置重复3次确保统计显著性。评估核心指标为"结果匹配率"（生成查询返回与参考等价结果集，比语法正确更严格）。

实验结果显示：

1. 结构化中间表示方案表现最佳：比直接生成在大型模型上提升15-25个百分点，优于Agentic方案（后者消耗8倍token却效果更差）；
2. 模型规模效应：大型模型更能从结构化约束获益，小型模型因JSON模式合规性瓶颈受限；
3. Token效率：Agentic方案token消耗是结构化方案的8倍，成本更高。

结构化方案优势的原因：

1. 形式化领域特殊性：代码分析查询语言有严格语法语义，LLM对形式化语言掌握有限，约束输出空间规避风险；
2. 确定性后处理价值：分离LLM的语义理解与形式化查询构造，关注点分离；
3. 错误传播控制：Agentic多轮交互易累积错误，结构化方案单轮生成+确定性转换减少不确定性。

实践指南：

1. 决策框架：形式化领域优先结构化中间表示，匹配模型能力（大型模型更适用），考虑成本约束；
2. 中间表示设计：平衡表达能力、可学习性、可转换性，建议迭代优化；
3. 混合策略：根据任务特性选择（简单用直接生成，复杂用结构化，需动态信息用Agentic）。

局限：研究聚焦代码分析，向SQL生成、配置管理等领域泛化需验证；手动设计中间表示门槛高。未来方向：探索中间表示自动化学习，优化Agentic交互模式（选择性工具调用、早期终止等）。