前沿大模型之间的能力差距正在缩小，智能体系统真正的差异化因素，正逐渐转向模型之外的基础设施——Agent Harness（智能体运行框架）。
它围绕大语言模型（LLM），负责组织智能体循环、工具调用、记忆、上下文管理、错误处理与结果验证。模型决定智能体"能做什么"，Harness 则决定这些能力能否稳定、可控地落地。
在多数生产场景中，智能体执行多步骤任务失败，往往不只是模型能力不足，更常见的原因是上下文出了问题：模型没有在正确的时间获得正确的信息。Harness 的核心价值，正是控制模型能看到什么、何时看到，以及发生故障后采取什么行动。
模型提供智能，Harness 负责把智能组织成可执行、可控制、可验证的系统。
如果要构建自己的 Agent Harness，需要重点做出以下 7 个设计决策。
智能体数量：单智能体还是多智能体
建议优先从单智能体开始。多智能体可以拆分角色与任务，但也会增加路由、协调和状态同步的成本；在智能体切换过程中，还可能丢失关键上下文。只有当任务确实需要明确的职责隔离、可以真正并行的任务、不同的工具或权限边界、需要相互复核的角色分工时，再引入多智能体通常更稳妥。
推理与执行策略
如何组织"思考"与"行动"有两种主流方式：
- 交替推理与行动：模型根据每一步工具反馈动态决定下一步，适应性强，但调用次数和成本通常更高。
- 先规划、后执行：先生成计划，再按计划执行，路径更清晰、效率更高，但面对环境变化时可能不够灵活。
生产系统常采用混合策略：先生成粗粒度计划，再允许执行器根据实时反馈局部调整。
上下文管理策略
上下文不是越多越好。无关信息会占用窗口，也会稀释真正重要的线索；关键内容位于长上下文中部时，还可能更难被模型有效利用。Harness 需要回答三个问题：哪些内容应该进入上下文、哪些需要长期保留、什么时候应该压缩或丢弃信息。
合理的压缩策略应保留目标、约束、架构决策和未完成事项，同时丢弃已经失去价值的冗长工具输出。
上下文管理的目标不是让模型看到所有信息，而是让它在当前步骤看到最相关的信息。
结果可验证性
可验证性可能是 Agent Harness 中最值得投入的部分。没有验证，智能体只能"看起来完成了"；有了验证，系统才能判断结果是否真的满足要求。验证机制分为两类：
- 确定性检查：测试、类型检查、静态分析、格式校验、规则引擎等，能够给出明确结果。
- 语义检查：使用 LLM 评审内容完整性、逻辑一致性或表达质量，适合处理难以完全规则化的问题。
验证顺序：先问"机器能否确定地检查"，再问"是否需要模型进行语义判断"。
权限范围设计
权限设计需要在效率与安全之间取得平衡。更实用的做法是按风险分级：
- 低风险、可恢复的操作自动批准
- 涉及外部系统或敏感数据的操作限制范围
- 高风险、不可逆的操作暂停并请求确认
- 将文件系统、网络、凭据和外部服务分别设置权限边界
工具范围控制
工具并非越多越好。一次向模型暴露过多工具，会增加选择难度，占用上下文，并提高误调用概率。Harness 应根据当前任务动态提供最相关的工具。例如通过延迟加载或分组注册，让智能体先判断任务类型，再加载所需能力。
框架厚度
最后一个决策是确定多少逻辑由 Harness 显式控制，多少逻辑交给模型自行判断：
- 较薄的 Harness：依赖模型完成规划、路由和纠错，框架更灵活，也更容易适配能力更强的新模型。
- 较厚的 Harness：通过工作流、状态机或显式图结构控制执行路径，可预测性更强，但开发与维护成本也更高。
选择哪一种，取决于任务风险、可预测性要求和维护成本，而不是单纯追求"厚"或"薄"。
Harness 会变薄，但不会消失
整个行业的趋势是：随着模型能力提升，部分原本写在框架里的规划、路由和纠错逻辑，会逐渐被模型内部化，Harness 可能因此变得更薄。但它不会消失，即使是能力最强的模型，也仍然需要一套机制来管理上下文、执行工具、控制权限、处理故障、验证结果。
模型决定能力上限，Agent Harness 决定这些能力能否在真实环境中稳定运行。
