考察点
Harness 是 2025 年以来 AI 工程圈的热词，Claude Code 等编程 Agent 带火了「Harness Engineering」这个说法。面试官问这题是想看你有没有意识到：让 Agent 好用的往往不是模型本身，而是模型外面那层工程。能举出具体组件和权衡是加分项。
参考答案
定义：模型外面那层壳
Harness（挽具/马具）指包裹在 LLM 外面、支撑它完成实际任务的全部工程设施。模型只负责一件事：吃上下文、吐下一个动作。剩下的一切都是 Harness 的活——把模型输出的 tool_call 真正执行掉、把结果填回上下文、管权限、管循环、记日志。Claude Code 这类产品里，模型是同一个 Claude，拉开体验差距的全在 Harness 层。
为什么需要它？因为裸模型有三个先天缺陷：无状态（每次调用都失忆）、无手（不能真的执行任何操作）、无边界（不知道什么能做什么不能做）。Harness 把这三件事补上，模型的智能才能转化成可靠的行动。有个说法我很认同：同样的模型，换一套 Harness，能力表现能差出一档——这也是为什么各家 coding Agent 模型可以互切，Harness 却都是自研的命根子。
一个完整 Harness 的核心组件
1. 循环控制器（Loop）。驱动 感知 → 决策 → 行动 → 观察 的主循环，带步数上限、超时、token 预算。这是 Harness 的骨架。
2. 工具运行时（Tool Runtime）。工具注册、参数校验、沙箱执行、超时控制、结果截断。编程 Agent 里这层最重的投入在 bash 工具和文件编辑工具上——比如编辑文件不用全量重写，而是用 diff/patch 方式，既省 token 又降低出错率。
3. 上下文管理器（Context Manager）。上下文窗口是稀缺资源，Harness 决定每一轮往窗口里放什么：系统提示、工具描述、历史消息压缩、大文件的分页读取、超长输出的截断策略。Claude Code 的自动压缩（compact）就是这个组件在干活。
4. 权限与安全层（Permission）。哪些工具自动放行、哪些需要用户确认、哪些永远禁止。读文件放行，写文件提示，rm -rf 拦截。权限策略做得细，用户才敢把 Agent 放在真实环境里跑。
5. 可观测与回放（Observability）。每一次 LLM 调用、每一次工具执行的完整记录，支持回放调试。Agent 的行为是概率性的，没有 trace 就等于裸奔。
6. 状态与恢复（State）。会话持久化、断点续跑、任务中断后恢复现场。
Harness Engineering 的工程权衡
做 Harness 不是堆功能，核心权衡有三个：
- 给模型多少自由。工具粒度太粗（一个「执行任意 SQL」），模型自由但危险；太细（几十个专用小工具），安全但选择困难。经验是按「不可逆程度」划分：可逆操作给粗粒度，不可逆操作拆细并加确认。
- 往上下文里放多少。放少了模型变瞎，放多了又贵又稀释注意力。好 Harness 的标志是有明确的上下文预算分配策略，而不是无脑全塞。
- 错误如何呈现。工具报错是给原始堆栈还是给结构化摘要，直接影响模型下一步的判断质量。Harness 是模型看世界的眼睛，你给它看什么它就信什么。
怎么在团队落地
我的路径是：第一步先把 Loop + Tool Runtime + 权限层做成与业务无关的独立模块，业务 Agent 只声明「我要哪些工具、什么 prompt」；第二步补 trace，没有观测不谈优化；第三步才是上下文压缩、子 Agent 这些高级能力。反过来的顺序（先堆功能后补观测）几乎必然翻车。
可能的追问
- 「Harness 和 LangChain 这类框架是什么关系？」 框架提供了 Harness 的部分零件（链、工具抽象），但生产级 Harness 的权限、上下文预算、沙箱这些核心件通常要按业务自建，框架只是起点。
- 「Claude Code 为什么比同模型的裸 API 好用？从 Harness 角度分析。」 工具设计贴合编程场景（diff 编辑、grep/glob）、上下文自动压缩、权限分层、todo 机制帮模型自我规划——模型相同，差距全在 Harness。
- 「Harness 里最难做的是哪部分？」 上下文管理。它直接决定模型的输入质量，又没有标准答案，只能靠评估集反复调，是最吃经验的部分。