向AI Agent提出质疑，它竟改掉了我的系统设计

传统的开发流程里，架构决策往往由人拍板。但当我真正把AI Agent引入设计环节，一次简单的追问，却让整个方案发生了转向。这并非科幻情节，而是我在使用内置Agent Spaceship时真实发生的一幕。

一次质疑引发的设计变更

在搭建一个多模型路由系统时，我原本打算沿用已有的索引路由（Index Router）模式——从不同供应商那里挂载编码器（Encoders）。这个模式在团队里已经跑得很顺，复用起来似乎理所当然。

但看着屏幕上的结构图，我犹豫了：既然编码器可以这样挂载，为什么决策模型（Decision Models）不照做？带着这个疑问，我直接在内置Agent Spaceship中提出了质疑。

我输入的内容很直白：“这是正确的选项吗？在索引路由中，我们从不同供应商挂载编码器，为什么不对决策模型做同样的事？”

索引路由（Index Router）与编码器挂载：在多模型系统中，索引路由是一种将请求按预设规则分发到不同模型端点的模式。所谓“从不同供应商挂载编码器”，是指将各家的 embedding 模型（编码器）作为可插拔组件注册到统一路由下，由路由层根据索引类型或任务特征选择调用哪一个。这种模式的优势在于解耦了调用方与具体供应商，新增编码器只需注册而无需改动业务代码，因此团队容易形成路径依赖。但编码器与决策模型在职责上并不对等：编码器通常是无状态的向量化服务，而决策模型往往涉及会话上下文、工具调用与成本权衡，直接照搬挂载方式可能掩盖路由层需要承担的调度职责。

结构的不确定性：两条路径的权衡

坦白说，提问时我并没有标准答案。我向Agent承认了自己的纠结：我可以沿编码器的路线走，为每个决策模型单独配置一个决策路由；也可以走另一条路，把决策模型统一挂载到现有路由体系下。

“老实说，对于这个结构，我不太确定哪个才是正确答案。”这种坦诚反而让对话更有价值——Agent没有迎合我的预设，而是开始分析两种方案在扩展性、维护成本上的差异。

决策模型与独立决策路由层：决策模型指在 Agent 流程中负责规划、选择工具或生成最终判断的模型，与仅做向量化的编码器不同，它通常需要多轮交互和状态管理。为决策模型引入独立的决策路由层，意味着在原有索引路由之外增加一层专门负责“选哪个决策模型、以何种策略调用”的调度逻辑。这样不同来源的决策模型可以像插件一样注册接入，路由层则集中处理降级、重试、成本与延迟的权衡。其代价是系统多了一层抽象，需要明确两层路由的边界，避免职责重叠导致调试困难。

Agent的回应与设计转向

根据Agent的反馈，我们最终调整了设计：不再简单复制编码器的挂载方式，而是为决策模型引入独立的决策路由层。这一改动让不同来源的决策模型可以像插件一样接入，同时保留了路由逻辑的灵活性。

这个决策被记录进了项目文档。回头看，如果我没有提出那个问题，系统很可能沿着惯性走了一条并不最优的路。Agent的价值不在于替你做决定，而在于当你不确定时，它能帮你把思考过程摊开，让真正合理的方案浮现出来。

对AI编程协作的启示

这次经历让我重新理解了“AI Agent作为协作者”的含义。它不是一个只会执行指令的工具，而是一个可以被质疑、也会回应质疑的对话对象。当你把不确定性坦诚地摆出来，Agent往往能给出超出预期的结构化分析。

对于正在使用AI编程助手的开发者，我的建议是：不要只把它当成代码生成器。在架构设计阶段，主动向它提出“为什么不这样做”的问题，可能会带来意想不到的设计优化。