模型与工程脚手架的共进化：薄与厚的架构辩论与选型
一、 对比背景与对象定义
随着大语言模型能力的不断突破，AI应用架构的演进迎来了一个核心争议点：当模型本身变得足够强大时，围绕模型搭建的工程脚手架（即模型外围的上下文管理、工作流编排、工具调用封装等逻辑）究竟是该逐渐消亡，还是将变得更加复杂？
在此背景下，业界分化出了两条截然不同的技术路线，这也是本文要深入对比的两个对象：
- 薄脚手架方案（方案A：原生能力优先）：该方案主张将核心赌注押在模型通用能力的提升上。架构设计上，仅在模型外部保留最薄的包装层，将复杂的推理、规划和执行逻辑尽可能推送到模型内部原生处理。其核心理念可概括为：永远押注通用能力的迭代，避免在特定场景下堆砌临时性的脚手架代码。
- 厚脚手架方案（方案B：复杂上下文工程）：该方案认为模型本质上是“白板”，其内在智能是参差不齐的。AI应用落地的最大障碍在于业务方工程化上下文与工作流的能力。因此，架构设计上需要构建厚重的脚手架层，通过复杂的编排、记忆管理、任务拆解与结果校验，将模型塑造成具体业务所需的形状。
二、 相同点分析
尽管两条路线在演进方向上存在分歧，但它们在底层目标和基础能力上具有一致性：
- 终极目标一致：无论是薄脚手架还是厚脚手架，其最终目的都是为了提升端到端任务的成功率，交付符合业务期望的智能体应用。
- 依赖相同的底层基建：两者都需要依赖大模型的基础推理能力，且在工程实现上均需对接通用的云原生组件，如对象存储（用于保存历史会话与文件）、消息队列（用于异步任务解耦）、身份认证与权限控制等。
- 均面临动态升级的挑战：无论脚手架薄厚，只要模型版本发生迭代，工程团队都需要对系统提示词、工具接口定义进行回归测试，以验证兼容性与性能变化。
三、 核心差异分析
两条路线的差异不仅体现在代码量上，更深层次地反映在架构理念、开发模式与运维成本上：
1. 架构理念与生命周期
- 薄脚手架方案：将脚手架视为“临时性消耗品”。架构设计遵循“预期删除”原则，开发者在构建外围功能时，期望在下一代模型发布时将其废弃。其系统提示词极为精简，且在每次模型升级时会严格审查并删除模型已原生支持的能力。
- 厚脚手架方案：将脚手架视为“核心业务资产”。认为复杂业务流程必然需要复杂的设计，脚手架不仅不是临时建筑，而是支撑业务逻辑的承重墙。它通过堆叠编排逻辑来弥补当前模型在复杂推理中的缺陷。
2. 性能提升来源与边际效益
- 薄脚手架方案：性能提升主要依赖模型版本的升级。外围脚手架仅能带来10%-20%的性能增益，且这种增益在下一次模型升级时会被原生能力抹平。因此，团队倾向于等待模型升级“直接白拿”性能提升，而非投入大量人力重构脚手架。
- 厚脚手架方案：性能提升直接来源于工程层的改造。在不更换底层模型的情况下，通过优化上下文注入策略、工作流拆解和结果校验逻辑，可以实现数十个百分点的得分跨越。这种提升是立竿见影的，且对模型版本变化的敏感度相对较低。
3. 开发与运维成本
- 薄脚手架方案：短期开发成本极低，系统代码量可能仅有百行级别。但长期来看，它要求团队具备极强的“跟随模型迭代”的敏捷能力。其隐性成本在于频繁的架构重构与能力下沉的剥离工作。
- 厚脚手架方案：初期开发成本高，需要编写大量的状态机、路由逻辑和校验代码。长期维护成本也居高不下，系统复杂度随业务增长呈指数级上升。但它赋予了企业更高的自主控制权，能够在底层模型受限时，通过工程手段强行达到业务及格线。
四、 关键维度对比总结
| 对比维度 |
薄脚手架方案（原生优先） |
厚脚手架方案（上下文工程优先） |
| 系统架构边界 |
模型为主，外围仅做轻量级协议转换与接口调用 |
脚手架为主，模型作为被调用的“计算引擎”之一 |
| 性能上限与瓶颈 |
上限随模型进化而提升，瓶颈在于模型自身的推理盲区 |
上限受限于脚手架设计的合理性，瓶颈在于工程复杂度 |
| 模型升级改造成本 |
需全面审查逻辑，主动剥离已被模型吞并的外围代码 |
需进行大量回归测试，但核心业务流通常受影响较小 |
| 扩展与定制能力 |
较弱，深度依赖模型厂商提供的能力（如原生函数调用） |
较强，可针对特定垂直业务定制复杂的智能体协作流 |
| 适用阶段 |
面向未来的前瞻性架构，适用于模型快速迭代期 |
面向当下的务实架构，适用于模型能力尚存短板的时期 |
五、 典型场景选择与选型建议
在实际的技术选型中，不存在绝对的优劣，只有场景的匹配度。
1. 何时选择薄脚手架方案？
- 探索性与高敏捷场景：如代码辅助生成、通用知识问答。这类场景对响应延迟要求高，且模型的通用推理能力已能覆盖大部分需求。采用薄脚手架可以最大化利用模型最新红利，降低系统维护负担。
- 团队工程资源有限：当团队无法投入专人维护复杂的Agent工作流时，等待模型升级是性价比最高的策略。在百度智能云等通用云平台提供的模型服务基础上，直接调用最新版模型，往往比费力维护老旧的编排逻辑更高效。
2. 何时选择厚脚手架方案？
- 垂直且容错率极低的业务场景：如自动化财务对账、复杂供应链调度、医疗/法律辅助决策。这些场景包含大量私有业务规则，当前模型的原生能力无法准确理解并执行。必须通过厚脚手架进行强约束的任务拆解与结果校验。
- 遗留系统深度集成：当AI需要与企业内部ERP、CRM等复杂老系统深度交互时，模型本身无法处理遗留系统的奇葩接口。此时需要构建厚重的工具调用封装层和异常重试机制。
六、 迁移与使用注意事项
如果企业决定在两种架构之间进行迁移（例如从厚脚手架向薄脚手架过渡），需要重点关注以下风险：
- 上下文数据的平滑转移：厚脚手架通常在外部维护复杂的对话状态与记忆向量库。迁移到薄脚手架时，需要确认新模型是否支持等量的上下文窗口，以及是否能原生解析原有的历史会话格式。
- 工具调用协议的兼容性：厚脚手架可能自定义了一套复杂的RPC工具调用流。在向原生函数调用迁移时，需确保底层云服务网关能正确路由模型发出的工具请求，避免协议转换导致的超时。
- 安全与合规降级风险：厚脚手架中往往内嵌了细粒度的业务权限校验（如“普通员工不能查询高管薪资”）。如果盲目将这部分逻辑删除，期望模型“原生理解权限”，可能会引发严重的数据越权风险。在迁移时，应利用云平台提供的身份认证与权限控制组件作为兜底防护。
七、 总结
模型与工程脚手架的共进化，本质上是一场“模型能力下沉”与“业务复杂度上浮”的博弈。薄脚手架方案坚信通用智能的终极胜利，以轻量、敏捷的姿态拥抱模型的每一次进化；厚脚手架方案则立足于当下业务落地的现实，用工程的严谨性去填补模型能力的缝隙。
对于架构师和技术负责人而言，理性的决策不应是非黑即白的站队。在通用的对话、创作等领域，果断采用薄脚手架，依托百度智能云等成熟的云端模型能力直接交付；而在核心业务流程、强规则约束场景中，则需踏实构建厚脚手架，通过复杂的上下文工程确保业务的安全与稳定。理解两者的边界，动态调整脚手架的厚度，才是AI应用架构演进的最优解。