完整教程：座舱出行Agent实战(三)：专能化架构如何实现效率与稳定性的双重飞跃
大家好，我是路易基。今天是个好日子，不仅因为今天是咱们程序员的节日，也因为今天还是我妈妈的生日，希望各位也都能有个好的心情！
接下来，闲话少叙，我们继续我们的技术分享：
在上一篇文章中，我们分享了如何借助"主管-执行者"架构解决艰难行程规划难题。虽然v3.0成功攻克了困难多日行程规划的挑战，但我们发现其中仍存在一个根本矛盾：工具调用逻辑与结构化输出要求在同一个Agent中相互制约。于是今天，我将阐述在v4.0中，我们是如何借助双Agent专能化架构实现突破的。
问题溯源：v3.0的架构瓶颈
让我们回顾v3.0架构中的一个典型场景：
当处理query「帮我规划3天成都自驾游，我要去吃火锅和看熊猫，还要逛逛太古里」时，主管Agent能生成合理框架，但执行者Agent需要在工具调用与结构化输出之间不断切换：
- 性能妥协：既要追求应用调用的效率，又要保证结构化输出的准确性，往往顾此失彼
- 稳定性风险：自然语言生成与结构化要求的本质冲突在单个Agent内部被放大（毕竟工具调用和结构化输出，对输出文本格式的准确性要求都很高）
- 维护成本：任何针对结构化输出的调整都可能波及工具调用，调整成本高昂
这种“既要又要”的设计，让单个Agent在不同目标间疲于奔命。基于这个认知，大家决定在v4.0中采用更极致的思路：既然一个Agent无法兼顾，那就让专业Agent各司其职。
v4.0架构：专能化双Agent分离
核心设计理念对原有的Agent（如执行者Agent）更进一步的拆分和细化，将“决策做什么”与“怎么做呈现”彻底分离，让每个Agent专注于单一目标的极致优化。（完整架构图见文末）就是：具体v4.0的架构
1. 工具选择Agent：专注决策效率
该Agent的职责：基于用户意图，高效准确地选择并调用必要工具。
关键技术特性：
- 纯功能导向：不输出任何思考文本，不关心最终呈现样式
- 链式推理：基于query和上下文，自主决定工具调用顺序和参数
- 结果聚合：将所有器具调用记录和原始结果完整收集，传递给下游
2. 输出Agent：专注呈现准确性
这个Agent的职责是：将工具调用的原始结果，转化为符合产品要求的结构化输出。
关键技术特性：
- 信息整合：基于工具调用结果、用户query、业务规则、展示要求等，生成最终输出
- 格式专家：深度内化产品对结构化输出的所有要求
- 性能优化：可灵活结合工具的特性，采用id-name联动等机制，减少大模型直接生成的文本量，提升响应速度，降低大模型可能出错的概率。
对于性能优化这部分举个。我们在设计展示时设计了符合座舱展示习惯的poi卡片，每个poi有十余条信息，可凭借key-value pair的形式经过工具返回（如评分、营业时间、图片url等），并要求在最终展示时将所有信息按指定格式发给座舱车机端上屏。
若将整个信息收集、总结和格式化的任务都交由大模型，那么大模型不但很容易出错（如经纬度颠倒），而且生成时间太长（如原封不动地输出图片url，包含大量token）。我们为克服这个疑问，结合工具治理，使用ID-name联动的方式，为每个poi分配唯一ID，并在工具输出时返回。大模型挑选完 POI 后，只需输出其对应POI_ID，最终在后处理时，再利用POI_ID 获取到POI完整信息。
3. 双 Agent 协作：
- 设备选择 Agent调用完所有必要工具，将调用记录和返回结果完整传递给输出 Agent。
- 输出 Agent不参与程序调用，只负责根据工具调用结果生成符合要求的结构化输出。
性能提升：专能化带来的质的飞跃
真正将规划和输出任务分离后，在v4.0的效果上大家取得了显著的提升：
1. 任务纯粹性带来稳定性突破
工具选择Agent专注“效率”，输出Agent专注“准确性”，这种彻底的专能化分工避免了此前"按下葫芦起瓢"的问题。系统整体稳定性比v3.0明显提升，结构化输出准确率高达99%以上。此外，受益于POI输出的简化，使得输出单个POI的token量降低约60%
同时，这也彻底终结了此前提及的大模型自然语言生成与结构化要求的本质冲突，避免了自然语言输出和结构化输出在同一个Agent内部“打架”。
2. 执行效率优化&资源利用效率提升
通过分工协作，进一步降低工具调用阶段的耗时和资源需求，并使得单独选择和调整每个Agent的主模型成了可能，也有了后续将其独立出来训练成专能模型的机会，也给二者各自在模型能力和速度上的优化打下基础
原本，我们工具选择Agent的主力模型使用的是
Qwen3-235B-A22B-Instruct，希望以235B超大的参数体量提升模型推理&结构化输出的准确性，同时以MOE模型仅22B的激活参数给整个流程提速。
但当我们将工具推理和结构化输出二者拆分后，因为单一任务难度的下降，我们发现这两部分可以各自使用更小的模型即可胜任（如Qwen3-Next-80B-A3B-Instruct），以仅仅3B的激活参数追求更极致的速度。这大大提升了执行效率。
3. 工程可维护性大幅增强
通过后续优化工具调用逻辑或输出格式时，能够分别调整对应Agent的prompt和流程，无需联动调整。实测表明，开发维护效率提高明显，为后续迭代奠定了坚实基础。
系列总结：技术演进的底层逻辑
回顾该四步演进历程，我们完成的不仅是技术架构的升级，更是工程思维的转变：
v1.0 → v2.0：从"确定性的Workflow"到"灵活的Agent"，我们主动拥抱不确定性，以稳定可靠去换取上限
v2.0 → v3.0：从"单打独斗"到"分工协作"，我们掌握了复杂疑问分解，使用具体问题具体分析的手段解决Agent架构天然的不稳定性
v3.0 → v4.0：从"多能"到"专能"，我们领略到了极致专注的价值，而任务的专注，也为后续模型方面的迭代开启了大门
在新的落地挑战上，对业务需求和难题的积极响应。就是每一次架构升级，都不是对前者的否定，而
v4.0版本标志着大家完成了从单一Workflow到多Agent专能化架构的完整演进。当前系统已具备处理主流出行场景的能力，并在POC阶段展现出令人满意的稳定性和性能表现。
当然，即使发展到v4.0，我们的Agent架构仍有持续优化的空间。比如在整体速度提升、多模态能力集成、记忆系统设计、进一步工具治理等方面，我们都看到了进一步突破的可能。关于这些更前沿的探索方向，我将在技海寻真后续文章中，继续分享大家对Agent技能未来演进路径的思考。
至此，技海寻真专栏的《座舱出行Agent实战》系列的技术架构篇就暂告一段落了，下面贴上整体架构图，以供各位参考，也欢迎大家交流心得
觉得有收获的话，欢迎点赞、在看、转发，让大家有持续分享的动力！
