一、对比背景：一场关于“智能边界”的路线之争
随着基础模型能力在推理、指令遵循和代码生成等方面的持续跃升，一个尖锐的问题摆在了所有AI应用开发者面前：当模型本身足够强大时，我们还需要在外层构建复杂的工程框架（业界常称之为“Harness”或“脚手架”）吗？这个问题的答案直接决定了团队的技术资源投向——是应该继续在提示词工程、外部工具调用编排、上下文管理上投入重兵，还是应该将精力转向模型微调与数据清洗？
当前业界对此分化为两大阵营。一方秉持“模型至上”理念，认为任何外部的复杂包装都是暂时的、易朽的，其价值会在下一次模型参数升级时迅速归零。另一方则坚持“工程塑形”观点，认为模型的原始智能如同未切割的宝石，必须通过精巧的框架设计才能打磨成适配特定业务场景的锋利工具。本文将对这两种“薄”与“厚”的架构路线进行系统对比，剖析其技术逻辑、适用边界与演化趋势。
二、对象定义：何为“薄Harness”与“厚Harness”
为了展开严谨对比，我们首先对两个核心对象进行清晰定义：
薄Harness（模型派）：指一种极度精简的AI应用架构。在这种架构下，应用层几乎不包含复杂的状态管理、多步骤编排或重型上下文缓存逻辑。开发者倾向于直接调用模型的高级API，将业务规则和流程尽量简化，甚至合并到模型的原生指令中。其核心理念是信任模型的通用能力，避免重复造轮子。代码结构上，可能仅是一个包含系统提示词和工具调用接口的轻量封装。
厚Harness（工程派）：指一种重型的外层框架架构。该架构认为模型只是大脑中的一个“思考模块”，其周围必须构建完整的“神经系统”和“肢体”。这包括但不限于：复杂的Agent状态机（用于管理多轮任务中断与恢复）、外部知识库的检索增强生成（RAG）管道、复杂的工具调用路由与参数校验逻辑、以及精细化的输出解析与错误重试机制。其核心理念是通过工程手段将模型的不稳定输出约束在业务可接受的确定性边界内。
三、相同点分析：共同的终极目标与基础依赖
尽管两派争论激烈，但它们在底层逻辑上存在不可忽视的共识。
- 目标同源：无论是薄还是厚，最终目标都是提升特定任务的成功率与准确性。它们都是在“模型原始能力”与“业务复杂需求”之间搭建桥梁。
- 基础依赖相同：两者都高度依赖于基础模型的API稳定性和版本迭代。任何一派对模型输入/输出格式的假设，都会在模型更新后面临失效风险。
- 承认模型缺陷：即便最激进的“薄”派也不得不承认，当前模型在数学计算、实时信息获取和需要严格状态追踪的任务上仍存在局限。因此，即便是薄封装，也必须预留“工具调用”的插槽，只是它们希望这将变得越来越简单。
四、核心差异分析：理念、投入与风险的全面对比
这一部分将深刻剖析两派在技术哲学和工程实践上的显著分歧。
1. 性能提升的来源：依赖模型进化 vs 依赖工程优化
- 薄Harness观点：性能提升主要来自模型参数的更新。外部工程带来的10%-20%增益是“租赁”来的，而非“拥有”。一旦底层模型能力跃升，这部分“租来的增益”会被瞬间抹平，甚至变成负资产（因为可能需要重构适配）。因此，任何为了短期提升而构建的复杂逻辑，都是对未来的一次“技术负债”。
- 厚Harness观点：性能提升来自对模型行为边界的精准塑造。通过精心设计的上下文压缩策略、多Agent协作模式或记忆管理机制，能够有效突破单次模型推理的上下文窗口限制，解决复杂长尾任务。这种增益是结构性的，模型升级反而可能让这些精心设计的框架发挥更大的“杠杆效应”。
2. 架构复杂度与运维成本：轻量化 vs 重量级
- 薄Harness：架构极为简单，通常只包含一个核心循环（调用模型->获取结果）。部署简单，故障排查直观。系统提示词是整个架构的灵魂，但也被视为一种“随时可删除”的临时配置。监控与告警相对简单，主要关注模型API的延迟与配额。
- 厚Harness：架构复杂度高，涉及向量数据库、对象存储、消息队列等多种基础设施的协同。系统状态分散在外部存储中，导致调试困难，需要专门的链路追踪和日志分析体系。版本升级涉及多个子系统的兼容性测试，运维成本成倍增加。
3. 面对模型升级时的适应性与韧性：被动跟随 vs 主动重构
- 薄Harness：适应性极强。由于无重型依赖，模型升级通常只需调整提示词措辞即可。团队鼓励“删除代码”，一旦发现新模型能原生处理旧框架的某些步骤，立即废弃相应代码。这种模式的挑战在于，团队需要持续跟进模型能力更新公告，对技术敏锐度要求极高。
- 厚Harness：韧性取决于框架的抽象程度。若框架设计良好，模型升级仅需更换底层驱动接口。但若框架与特定模型的输出格式深度耦合（例如固执依赖某种特定的JSON结构），则升级可能带来灾难性的解析错误。善于设计的厚框架会引入“适配器层”来隔离这种变化。
| 对比维度 |
薄Harness（模型主导） |
厚Harness（工程主导） |
| 核心信念 |
模型的通用能力终将吞噬一切临时脚手架。 |
模型内在能力参差不齐，必须靠框架塑形。 |
| 性能极限 |
受限于基础模型单次推理能力。 |
可通过编排、记忆、检索突破单次推理限制。 |
| 迭代速度 |
极快，依赖模型API更新，代码改动量小。 |
较慢，涉及多模块协同迭代，周期较长。 |
| 失败模式 |
模型输出不可控时，通常直接表现为任务失败。 |
框架自身逻辑缺陷可能导致级联故障，或状态死锁。 |
| 技术栈要求 |
精通提示词工程、API调用与流式处理。 |
需要系统工程能力（状态机、数据库、分布式追踪）。 |
| 资源投入 |
人力投入主要在评测与提示词调优。 |
人力投入主要在框架开发与基础设施维护。 |
| 风险点 |
若新模型未能覆盖特定长尾场景，则应用能力停滞。 |
若模型能力指数级跃升，当前复杂框架可能瞬间显得笨重且多余。 |
五、典型应用场景选择：何时该“薄”，何时该“厚”
选择哪种路线，不应基于信仰，而应基于具体的业务约束。
选择薄Harness的典型场景：
- 通用对话助手：如面向公众的客服机器人或知识问答。任务开放，对延迟敏感，且容错率相对较高（可以回答“不知道”）。
- 快速原型验证：在未确定产品市场契合度（PMF）前，使用薄封装快速搭建Demo，测试用户需求。
- 代码生成辅助：在IDE中提供单函数或单文件的补全建议，不涉及跨文件的重构与多步骤执行。
选择厚Harness的典型场景：
- 复杂业务自动化：例如自动化报表生成、跨系统数据迁移，要求任务必须按照严格步骤执行，某一步失败需要自动回滚或人工介入。
- 企业级知识库问答：需要对私有数据进行精细的权限隔离，并确保回答有明确的引用来源。薄封装无法管理复杂的文档权限切割。
- 长周期Agent任务：例如市场调研Agent，需要连续工作数小时，且在过程中需不断迭代优化策略。厚框架中的持久化存储在此时至关重要。
六、选型建议：条件化的决策框架
基于上述差异，我们不应给出“非黑即白”的结论，而是建立一套基于团队能力与业务容忍度的决策参考。
- 评估你的业务瓶颈：如果业务失败的主要原因在于模型“理解错了”（语义歧义），则升级模型或优化提示词（薄路线）更为直接有效；如果失败原因在于模型“忘了做”或“流程混乱”（状态管理缺失），则必须投资厚框架。
- 评估团队的技术基因：若团队以算法工程师为主，擅长数据清洗和模型微调，建议采用薄路线，将核心精力放在训练数据的飞轮上。若团队以全栈开发为主，擅长复杂系统的工程治理，则构建厚框架是更稳妥的选择。
- 评估维护周期：对于生命周期短（如营销活动页面）的应用，薄封装足够。对于计划运营数年、且业务逻辑会持续复杂化的核心系统，建议初期就搭建具备良好抽象能力的厚框架，以避免在业务快速增长时被迫“中途加梁”。
七、迁移与使用注意事项
如果团队试图从“厚”向“薄”迁移，或反之，需要关注以下风险。
- 从厚到薄（减负）：需提前清理厚框架中隐含的“状态粘性”。长期运行的业务流程中，已持久化的会话数据可能无法被简单的提示词替代。迁移前必须验证新模型是否具备通过组织好的长文本上下文复现旧逻辑的能力。
- 从薄到厚（增重）：需警惕“过度工程化”。许多在简单Demo中表现不佳的模型输出，在引入复杂的重试机制和校验逻辑后可能已经达标，无需引入重量级数据库进行状态管理。建议先采用“轻量级厚模式”，即在无外部数据库的情况下，通过在系统提示词中注入历史关键决策摘要来模拟记忆。
八、总结：动态平衡是唯一常态
归根结底，“薄”与“厚”的辩论本质上是关于“无常”的辩论。模型能力的增强确实会不断侵蚀薄框架中“技巧性”部分的生存空间，但这绝不意味着工程团队将无事可做。未来的制胜关键在于构建一种“可溶解”的Harness——即采用清晰的模块化接口，将那些可能被模型能力覆盖的临时逻辑（如特定格式转换）与核心业务逻辑（如权限校验、审计日志）分离。这样，当模型升级的浪潮袭来时，我们能够以最小的代码删除成本，享受模型进化带来的红利，同时保留必须由工程系统提供的确定性保障。最优秀的开发者，应是那些既能深刻理解模型能力的边界，又能果断移除不再必要的复杂性，始终保持架构轻盈的“园丁”。