考察点
这道题出自 javabetter 面经的 Harness Engineering 专题（「为什么需要 Harness Engineering」「一个完整的 Harness 包含哪些核心组件」「怎么在团队里落地」），是 2026 年 Agent 岗位系统设计方向的新题。面试官想看你是否理解「模型只是 Agent 系统的一个零件」，以及有没有搭过或想过脚手架层的工程能力。追问常往「怎么落地」「和换模型什么关系」走。
参考答案
定义：模型外面那圈东西
Harness 原意是「挽具、测试台」，在 Agent 语境里指模型之外、让模型能完成真实任务的全部工程设施：它怎么拿到工具、每轮推理看到什么上下文、循环什么时候停、出了错谁兜底、效果好不好怎么度量。Harness Engineering 就是把这圈设施当成正式工程对象来设计、迭代、评测的实践，而不是写 Agent 时随手糊的胶水代码。
为什么这件事值得单独冠名？因为行业现实是：头部模型能力趋同，同一个底座模型，两个团队做出的 Agent 体验可以天差地别，差距几乎全在 harness 上。而且模型每半年一换，harness 设计得好，换模型是改一行配置；设计得差，换模型等于重写系统。harness 是 Agent 产品里真正属于你自己的资产。
核心组件拆解
一个完整的 harness 我拆成五层：
| 层 | 职责 | 关键设计点 |
|---|---|---|
| 工具层 | 给模型提供操作世界的接口 | 工具少而通用；输出结构化、有截断；错误信息有指导性；危险操作要 dry-run |
| 上下文层 | 每轮推理前组装模型看到的信息 | 系统指令、工具 schema、记忆、检索、历史的预算分配；超阈值压缩；子 agent 隔离 |
| 控制层 | 驱动和约束 agent loop | 轮次/token/时间三重上限；权限分级与人工确认；中断恢复；死循环检测 |
| 可观测层 | 让黑盒循环可回放 | 每轮完整 payload 落盘成 trace；工具调用链路；成本归因到任务 |
| 评测层 | 回答「改了 harness 是变好还是变坏」 | 任务级 eval 集；端到端成功率、轮次、token 成本三条曲线；badcase 库 |
一个串起来的例子
拿「修 bug」任务看五层怎么协作：控制层启动 loop 并设好 30 轮上限；上下文层把 CLAUDE.md、相关文件摘要、历史会话压缩装进窗口；模型通过工具层的 Grep/Read/Edit/Bash 干活，一次 Edit 出错，错误信息引导它换个方式重试；全程可观测层记录每轮 payload；任务结束后评测层拿「是否修复、用了几轮、烧了多少钱」记账。用户看到的是 agent 修好了 bug，工程上每一层都在起作用——任何一层缺位，症状都很具体：没有控制层会死循环烧钱，没有上下文层会任务一长就失忆，没有评测层你改了 prompt 都不知道是优化还是退化。
团队怎么落地
面经里专门有这一问，我的答案是三步走。先观测后优化：第一天就把 trace 落盘做了，没有数据时所有 harness 讨论都是空对空。然后 badcase 驱动迭代：每周过一遍失败 trace，归因到具体层——上下文没喂对就改组装策略，工具误导就改错误信息，循环失控就调上限——harness 的进步全是这样攒出来的。最后建 eval 闭环：攒几十上百个代表性任务做回归集，harness 任何改动跑一遍再上线，把「我觉得变好了」变成「成功率 +4%、成本 -12%」。
和模型选型的关系
面试里常被追问「那模型还重要吗」。重要，但位置变了：模型是可替换的引擎，harness 是整车。引擎差距决定上限，整车调校决定你离上限多远。工程上的正确姿势是把模型抽象在 harness 后面，接口标准化，这样每次新模型出来，用 eval 集跑个对比就能理性决策换不换，而不是靠新闻和体感。
可能的追问
- Harness 和 prompt 工程什么关系？——prompt 工程只覆盖上下文层里系统指令那一小块，harness 是包含它的完整系统；只会调 prompt 的 Agent 工程师和会建 harness 的，差着一整个职级。
- 小公司资源有限，harness 哪层先做？——可观测层，成本最低收益最大；trace 落盘几百行代码的事，但它让后续所有层的迭代从玄学变成工程。
- 怎么衡量 harness 好不好？——同一模型同一任务集下看三个数：端到端成功率、平均完成轮次、单任务成本；harness 改动的价值全体现在这三条曲线的变化上。