考察点
这道题出自字节跳动 Agent 开发实习一面（2026 年牛客面经），属于概念加架构的复合题。Harness Engineering 是 2025 年以来 agent 圈公认的关键命题：同一个模型，套不同的 harness（工具设计、上下文管理、循环控制），任务成功率可以差出一大截。面试官想确认你理解"agent 的能力 = 模型 × harness"，而不是只会调 prompt。好的回答要先给出一句话定义，再分模块讲，每个模块都要带工程细节而不是名词堆砌。追问通常往"你们 harness 哪块最难做""怎么衡量 harness 改动的效果"上走。
参考答案
一句话定义
Harness 是模型之外、让模型能在真实环境里闭环完成任务的整套工程系统：它决定模型每一步看到什么（上下文）、能做什么（工具）、什么时候停（循环控制）、做错了会怎样（反馈与回滚）。模型是引擎，harness 是底盘、传动和驾驶舱——同一台引擎，底盘不行车照样开不了。这就是为什么各家基础模型能力趋同之后，agent 产品的差距反而越拉越大，差距几乎全在 harness 上。
核心模块
1. 上下文管理。 这是 harness 里最贵的一块，负责每一步往模型窗口里装什么。包括：系统提示词的组装（角色、规则、环境信息）；项目记忆的分层加载（全局/项目/目录级）；工具结果的截断与摘要——原始输出直接进上下文是新手错误，一条几千行的日志就能毁掉整个会话；长任务的压缩与外置存储（细节落盘、上下文留指针）；以及多轮对话的状态维护。判断这块做得好不好的标准很简单：模型在任务后期是否还"记得"任务目标和早期决策。
2. 工具层。 工具是模型影响世界的唯一通道，设计质量直接决定 agent 上限。要点包括：工具数量克制——几十上百个工具会稀释模型的选择能力，宁可少而精；描述写清楚"什么时候用、什么时候不用"，这是模型的路由依据；参数 schema 严格校验，失败时返回可操作的错误信息而不是堆栈；输出结构化并主动截断。工具层还要管权限：读操作放开，写操作限定工作目录，bash 这类全能工具配命令白名单或审批。
3. 循环控制。 就是 agent loop：规划、执行、观察、再规划的元逻辑。关键工程问题有三个——终止条件（任务完成、达到步数/成本上限、连续无进展时必须停，死循环的 agent 是烧钱的灾难）；中间检查点（每 N 步自检一次进度，偏离目标时纠偏或 replan）；人机交互点（哪些决策必须问人、哪些可以自主）。循环控制决定了 agent 是"可靠的执行者"还是"脱缰的赌徒"。
4. 安全与隔离。 文件系统限定在工作区，危险命令（rm、git push、数据库写）走审批或沙箱；agent 处理的外部内容（网页、issue、日志）是不可信输入，要防 prompt injection——比如工具返回内容里嵌着"忽略之前的指令"，harness 要把它当数据而不是指令处理。
5. 可观测与评测。 每一步的输入输出、工具调用、token 消耗都记 trace，否则出了问题根本没法复盘；在此之上建评测集，harness 的任何改动（换个工具描述、调个压缩阈值）都跑回归。没有这层，harness 迭代就是玄学。
为什么强调"Engineering"
因为这套系统没有银弹，全是权衡：上下文给多了费钱、给少了降智；工具给多了选择困难、给少了能力受限；自主性高了效率高、风险也高。harness engineering 的本质就是针对特定任务分布，在这些权衡里持续找最优点的工程过程，靠评测驱动而不是靠感觉。
可能的追问
你们 harness 里最难做的模块是哪个？ 上下文管理。它既影响成功率又影响成本，且效果高度依赖任务分布，没有通用最优解，只能对着 trace 和评测集反复调。
模型升级后 harness 会贬值吗？ 部分会——模型变强后一些补救性设计（精细的格式约束、复杂的多步提示）可以简化；但工具、安全、评测这些与真实世界接口的部分是长期资产，模型再强也需要。
怎么衡量一次 harness 改动是否有效？ 固定评测集对比任务成功率、平均步数、token 成本和人工接管率四个指标，单次成功率提升但成本翻倍的改动不一定是好改动。