AI Agent架构核心抉择：确定性编排与LLM推理的边界该划在哪？

一个被反复追问的架构难题

构建AI Agent系统的开发者迟早会撞上同一堵墙：系统里的每一个决策，到底应该交给确定性的编排逻辑，还是交给大语言模型的推理能力？这不是一个技术选型问题，而是关乎整个Agent系统可预测性与灵活性平衡的根本性架构决策。

一位在Reddit上分享实践经验的开发者提出了这个问题。他在长期搭建Agent基础设施的过程中发现，一个典型的Agent设计往往会演化成这样的线性结构：

输入
  ↓
LLM / 路由器
  ↓
图 / 工具
  ↓
LLM
  ↓
结果

这种设计的隐含假设是：模型应该参与每一次状态转移的决策。但随着系统复杂度上升，这位开发者开始质疑这个假设的合理性——对于系统本就能够确定性处理的操作，真的有必要每次都调用概率推理吗？

reddit讨论：Agent中确定性编排与LLM推理的边界

针对上述疑问，他提出了一种替代性的架构思路，把请求处理拆分成两条并行路径：

              ┌→ 确定性路径 ─┐
请求 → 路由 ──┤             ├→ 结果
              └→ 语义路径 ──┘

这个设计的核心在于职责分离。语义路径留给模型真正擅长的场景：处理歧义、理解自然语言、模糊推理，以及在状态空间尚未明确时进行规划。而确定性路径则接管那些系统根本不需要概率推理就能明确知道下一步该做什么的情况。

这种分叉的价值在于，它拒绝了"模型必须介入每个环节"的默认思维。很多Agent场景中，输入的意图一旦被识别，后续流程其实是完全确定的——比如查询一个已知格式的数据、执行一次标准化的API调用。让LLM去"决定"这些本已确定的转移，不仅浪费算力和延迟，还引入了不必要的不确定性。

这套思考也让作者重新审视了LangGraph这类框架。图结构（graph）的优势在于它提供了对状态转移、状态管理和检查点（checkpoint）的确定性控制——这正是生产环境所渴求的可预测性。

但框架本身并不能替你回答那个根本问题：哪些决策属于图，哪些决策属于模型？

这里存在一个两难：

换句话说，把决策权推向任何一个极端都会带来反噬。真正的工程挑战是找到那个"甜蜜点"。

这场讨论中最尖锐的一个反问是：有没有人做到某个程度后，发现路由/控制层本身比直接让模型多做决策更难维护？

这是一个容易被忽视的陷阱。开发者往往出于对可预测性的追求，不断把逻辑塞进确定性层，结果控制层的复杂度呈指数级增长。当你需要维护的规则、分支和状态转移逻辑多到一定程度，它带来的心智负担可能已经超过了直接信任模型判断所带来的不确定性成本。

这提醒我们：确定性并非免费的午餐。它把不确定性从运行时转移到了开发时——你用更多的前期设计和代码来换取运行时的稳定。当这笔交易变得不划算时，反而应该让模型承担更多。

虽然这个讨论没有给出标准答案（架构问题本就没有银弹），但它提炼出了几个值得每个Agent开发者自问的判断标准：

真正成熟的Agent架构，往往不是二选一，而是像作者提出的分叉路径那样，让两种范式各司其职——确定性负责它能确定的，模型负责它才能处理的模糊地带。这个边界不是一次性划定的，而是随着系统演进持续调整的动态平衡。