简介：本文围绕智能Agent设计中的核心准则“Thin Harness, Fat Skills”展开，系统对比了“轻量编排层”与“厚重能力层”两种设计哲学在架构、扩展性、稳定性及成本上的差异。文章从定义、优劣势、适用场景到选型建议逐一拆解，帮助开发者和架构师厘清如何在复杂任务中平衡Agent的自主决策能力与工具调用的可靠性，为构建高效、可控、可演进的智能体系统提供清晰的决策参考。
在智能Agent的工程实践中，一个长期困扰架构师的问题是：Agent的“大脑”应该承载多少逻辑，又该把多少能力“外置”到工具与环境中？传统的大模型单次对话模式中，模型本身既是决策者也是执行者，一切知识、推理与输出都在一次交互中完成。然而，当Agent被赋予“目标驱动的自主闭环执行能力”后，其行为链路被拉长，涉及环境感知、子任务拆解、工具选择、结果校验与记忆更新等多个环节。此时，一个直观但容易误入歧途的做法是，将尽可能多的规则、提示词、流程判断和业务逻辑塞入模型的主提示词或编排代码中，试图让Agent“想得更全面”。这种做法很快会遭遇三重困境：提示词膨胀导致模型注意力分散、规则冲突引发行为不可控、迭代更新牵一发动全身。
与之相对的，是“Thin Harness, Fat Skills”这一设计准则的提出。其核心思想可以类比为操作系统与应用程序的关系：Harness（马甲/鞍具）指Agent的编排骨架，即决策循环、任务状态管理和上下文传递机制；Skills（技能）则指Agent可调用的外部能力模块，包括工具、API、知识库查询、代码执行环境等。所谓“Thin Harness”，强调的是编排层应保持极简与稳定，只负责“何时调用什么”以及“如何评估调用结果”，而不承载具体业务知识或复杂的执行逻辑；“Fat Skills”则要求将领域知识、经验规则、敏感操作等重量级内容封装为独立、可复用、可测试的技能组件。本文的对比对象，正是这两种设计取向在真实Agent项目中的具体体现：偏向“厚编排、薄技能”的架构，与偏向“薄编排、厚技能”的架构。理解两者差异，是构建可落地、可维护、可扩展Agent系统的前提。
在“厚编排、薄技能”架构中，编排层承担了大量任务理解、步骤规划、异常分支判断乃至部分结果生成的工作。例如，一个电商售后Agent，其主控制流中直接书写了“如果用户申请退款，则检查订单状态，若已发货则引导退货流程，若未发货则直接退款”的详细条件分支。这些业务规则完全嵌入在Agent的主循环中，模型需要根据用户输入与当前状态，在众多预设分支中做出选择。其优势在于单次调用的响应路径较短，无需频繁跳转外部服务；但当规则数量增长到数十条时，提示词长度失控，模型容易在复杂分支中遗漏关键条件，且每调整一条业务规则，都需重新验证整个编排逻辑。
在“Thin Harness, Fat Skills”架构中，编排层被压缩为一个通用决策循环。仍以电商售后为例，主控制流只定义四个抽象步骤：感知用户意图、选择技能模块、执行技能并获取结果、评估是否达成目标。至于“退款金额如何计算”“退货地址如何提供”“哪些情况需要人工介入”，这些全部封装在“售后规则技能”“订单查询技能”“退款处理技能”等独立模块中。每个技能模块有明确的输入输出协议、自包含的参数校验与错误处理逻辑。编排层只依据一个轻量的“技能路由表”决定调用哪个技能，而不关心技能内部如何实现。
两者的本质区别在于“决策责任的分布”：厚编排架构将决策责任集中在模型推理中，依赖模型的上下文理解能力覆盖所有可能性；薄编排架构则将决策责任下沉到技能模块，模型仅负责高层意图识别与结果评估，业务规则由技能模块以代码或规则引擎的方式精确执行。
尽管两种架构在逻辑分布上差异明显，但它们在Agent系统的基本面要求上并无不同。首先，两者都需要具备环境感知能力，即解析外部输入（如用户消息、系统状态）并提取关键信息的能力。无论是厚编排中的显式条件判断，还是薄编排中的技能选择，都依赖这一步的正确性。其次，两者都必须实现目标驱动的闭环：设定目标、执行动作、观察结果、调整策略，直至任务完成或终止条件触发。这一循环是Agent区别于普通API调用的根本特征。再次，两者都需要记忆留存能力——短期记忆（当前任务上下文）与长期记忆（跨任务的经验与偏好），以保证多轮交互的一致性与持续优化。最后，两者在安全边界设计上的要求同样严格，都需要定义白名单式的允许操作集与黑名单式的禁止操作集，防止Agent越权或产生不可逆影响。可以说，架构选择不改变Agent的本质定义，只影响这些能力如何被组织和交付。
厚编排架构中，业务逻辑与决策逻辑高度耦合。主控制流中混合了“任务分解”与“任务执行”两个层次的代码，使得系统难以独立演进。任何业务规则的调整，都可能影响到模型的决策提示词，进而产生不可预知的连锁反应。而薄编排架构在模型与控制流之间插入了一层“技能抽象层”，业务规则被封装在技能内部，通过标准接口暴露。编排层只关心技能是否执行成功、返回结果是否符合预期，完全不必理解技能内部的实现细节。这种低耦合设计使Agent的骨架可以稳定复用，技能则能独立迭代与测试。
厚编排架构的扩展遵循“持续添加法”：每增加一个新功能，就在主提示词或分支判断中增加一段描述。这导致两个后果：一是提示词长度持续膨胀，模型的有效注意力被稀释，在复杂场景下出现“遗忘”早期指令的概率上升；二是回归测试覆盖难度加大，因为任何新增分支都可能影响既有分支的触发条件。相比之下，薄编排架构的扩展遵循“独立插件法”：新业务场景只需开发一个新的技能模块，并在技能路由表中注册即可。既不影响主循环的稳定性，也不需要对已运行良好的技能做额外测试。当技能数量达到一定规模后，这种模块化优势会转化为显著的维护成本降低。
厚编排架构的优势在于处理非标准化、开放式的任务。当用户请求超出预定义技能范围时，模型可以直接利用其内隐知识生成响应，无需依赖外部模块的配合。这种能力在冷启动或长尾场景中具有明显价值。然而，在标准化、高频次的业务场景中，厚编排的效率劣势也很明显：模型每次都需要重新推理业务规则，即使这些规则是固定不变的，例如反复判断“订单金额超过五万元需要人工审批”。薄编排架构则将这类规则固化在技能代码中，一次编写、准确执行，模型只负责识别触发该技能的意图，节省了每次推理规则的时间与计算资源。在吞吐量要求高、响应时间要求短的场景下，后者的优势更为突出。
厚编排架构的测试核心是“提示词调优”。测试人员需要构造大量覆盖各种分支条件的样本输入，观察模型的输出是否符合预期，且需关注模型在不同表述下的泛化稳定性。这种方式在规则数量少时可行，但规则数量增加后，难以保证所有组合都被覆盖。薄编排架构将大部分逻辑从模型推理中移出，使得可以使用传统的单元测试与集成测试方法对每个技能模块进行独立验证。例如，一个“计算退款金额”技能，可以编写明确输入输出用例，断言各种边界情况，而不依赖模型输出。这种可测试性的提升，意味着Agent系统的故障可以被更早发现、更精确定位，从而显著提高生产环境的可靠性。
安全边界的执行在两种架构中的严格程度不同。厚编排依赖模型“理解”安全规则并主动遵守。例如，在提示词中写明“不得修改订单金额”，模型在大多数情况下会遵循，但在遭遇复杂诱导或上下文冲突时，仍存在违反规则的可能。而薄编排架构通过物理隔离实现安全控制：修改订单金额的操作只存在于“财务技能”模块内部，且该模块对外只暴露“创建审批工单”的接口，根本不提供“直接修改金额”的能力。编排层即使被诱导，也没有路径调用不存在的功能。这种“能力最小化”原则使得安全边界从“软约束”变为“硬约束”，是金融、医疗等强监管领域选型时的关键考量。
| 对比维度 | 厚编排、薄技能架构 | 薄编排、厚技能架构 |
|---|---|---|
| 决策逻辑位置 | 主要位于模型提示词与主控制流 | 主要位于独立技能模块内部 |
| 业务规则变更 | 修改提示词，需整体回归验证 | 修改技能模块，影响范围可控 |
| 新功能扩展 | 增加提示词与分支判断，易引发冲突 | 新增技能模块与路由表项，隔离性好 |
| 响应延迟 | 规则推理依赖模型，延迟较高 | 规则执行依赖代码，延迟较低 |
| 长尾场景处理 | 模型内隐知识可覆盖，灵活性高 | 无对应技能时需回退到通用模型，能力有限 |
| 测试方式 | 样本测试与提示词调优为主 | 单元测试与集成测试为主 |
| 安全控制 | 依赖模型理解安全规则，存在越权风险 | 通过接口限制实现物理隔离，强约束 |
| 模块复用 | 规则嵌入提示词，难以跨任务复用 | 技能以标准接口封装，可跨Agent复用 |
| 失败定位 | 依赖日志分析模型每一步推理 | 技能模块运行时可单独追踪与隔离故障 |
选择哪种架构，应基于业务场景对“确定性”与“灵活性”的不同需求。在标准化程度高、操作边界清晰的场景中，例如订单处理、权限审批、日志分析、数据清洗等，确定性要求远高于创造性要求。此时，“薄编排、厚技能”架构几乎是必然选择。这类场景的特点是：规则明确、流程固定、高频重复，模型介入越多反而越容易出错。将业务规则封装为技能，由代码精确执行，可以最大限度降低错误率，且能轻松满足审计对操作留痕的要求。
相反，在开放性强、目标多维、输入高度非结构化的场景中，例如战略咨询问答、创意内容生成、复杂科研方案辅助设计等，预设技能往往无法穷尽所有可能性。此时，厚编排架构赋予模型的自由推理空间更具价值。但更务实的做法是混合架构：主循环保持轻量，负责意图识别与任务规划；对于识别出的标准化子任务，调用技能模块执行；对于无法归类的请求，允许模型使用内隐知识生成候选方案，但仍需经过层级评审或人工确认后被接受。这种“基线技能保障确定性，模型推理兜底灵活性”的组合，在多数生产级Agent项目中是更稳健的起点。
在具体选型时，建议从以下五个问题出发进行评估：
第一，业务规则是否可以被形式化描述？如果答案是肯定，这些规则就应该被封装为技能，而非依赖模型临场推理。第二，变更频率如何？如果业务规则每月甚至每周都在调整，技能的模块化封装可以显著减少回归测试工作量。第三，系统的吞吐量与响应时间是否符合SLA要求？如果要求在秒级内返回结果，应优先确保高频路径上的规则执行不依赖模型推理。第四，安全违规的代价有多大？对于财务、用户隐私、核心系统配置等场景，必须采用接口级的安全隔离，而不能只依赖提示词约束。第五，团队当前的工程能力结构如何？薄编排架构对后端开发和规则引擎的依赖更大，要求团队具备良好的代码抽象与测试能力；厚编排架构则更依赖模型调优与提示词工程技巧。团队应依据自身技术栈成熟度做出务实选择。
若从厚编排架构向薄编排架构迁移，需重点关注三个风险。一是功能灰度的风险：将原本由模型自由决策的规则迁移到技能模块中，可能会出现边界覆盖不全的情况，导致原有可处理的请求因找不到对应技能而失败。应对策略是设计“兜底技能”，即当技能路由表无法匹配任何技能时，回退到具备通用能力的模型调用，但将该次调用标记为低置信度，并触发人工抽查。二是上下文传递的兼容性：厚编排中模型天然保留全量对话历史，迁移后技能模块只能接收到明确传入的参数，可能丢失部分隐式上下文。因此技能接口设计需前置进行必要的上下文压缩与转写，确保不丢失关键信息。三是监控体系的调整：原有系统监控的是模型输出质量，迁移后需要监控技能执行的成功率、异常率、超时率等传统服务指标，运维团队需要时间适应这种指标维度的转移。
“Thin Harness, Fat Skills”并非否定模型推理的价值，而是强调在工程化Agent系统中，应当把模型的能力保留在它最擅长的领域——理解意图、评估结果、处理开放式难题；而把可枚举、可验证、可控制的逻辑从模型推理中剥离出来，封装为技能模块。这一准则的本质，是重新划分“智能”与“工程”的边界：让智能用于不确定性，让工程用于确定性。对于正在评估Agent架构的团队而言，最有效的切入点不是讨论哪种理念更先进，而是梳理自身业务中哪些部分必须保证正确、哪些部分可以容忍模型发挥。通常会发现，前者占比越高，越需要优先构建厚重的技能层；而编排层，则应当被刻意打磨得越薄越好。