先这样答
Harness 直译是「马具」，指套在模型外围、让模型能真正干活的那套系统。具体包括：主循环（每一轮把什么喂给模型、什么条件下终止）、上下文管理（历史怎么裁剪、哪些信息长期保留）、工具执行（调用怎么发、结果怎么回填、超时和失败怎么处理），再加上权限控制和日志。模型在这套系统里只承担一个角色：看当前状态，决定下一个动作。
为什么换框架效果差很多。因为同样的模型决策，质量被外围环节放大或削弱。上下文管理差的框架把历史塞满窗口，关键信息被挤掉，模型看起来就「变笨」；工具描述写得含糊，模型选错工具的概率上升；调用失败不重试、错误信息不回传，一个小异常就终止整个任务。这些都不是模型能力问题，是模型能力被兑现了几成的问题。同一个模型，好的 harness 能稳定跑几十步的任务，差的 harness 三五步就崩，差距全在这一层。
总结：评估 Agent 时要把模型能力和 harness 质量分开看，否则框架调不好会误判成「模型不行」。做选型时，上下文策略和错误处理机制比「支持多少工具」更值得看。
面试官会怎么追问
- 「自己搭 harness 还是用现成框架？」 从现成框架起步验证流程，跑通后把关键环节（上下文策略、工具错误处理）换成自己的实现。主循环本身不难写，难的是长期维护的细节，自建要为这部分留出工作量。
- 「harness 里最难做的是什么？」 上下文管理。历史每轮增长而窗口有限，裁掉的信息可能正是后面要用的；什么进长期记忆、什么丢弃、什么压缩成摘要，这些决策没有通用答案，和任务强相关。
- 「怎么判断问题出在模型还是 harness？」 同一批任务在不同 harness 下对比失败模式：失败集中在调用格式、上下文丢失这类工程环节，是 harness 问题；模型对任务本身理解错误、规划混乱，才是模型问题。
回答的坑
- 把 harness 说成「就是提示词模板」。提示词只是一小块，循环控制、上下文裁剪、错误恢复才是工作量大头。
- 效果不好就换模型。很多「模型不行」实际是上下文被塞爆、工具报错没回传，先排查 harness 再下结论。
同系列的题
—— 本题完 ——