🧑💻 面试官：现在模型已经会写代码、调用工具了，Agent Harness 还负责什么？
🙋♂️ 我：它可以把模型、工具和循环组织起来，让模型持续完成任务。
🧑💻 面试官：如果模型说“头像上传功能已经做好了”，但是用户刷新页面后头像又没了，循环算结束了吗？
🙋♂️ 我：还需要检查实际结果，不能只看模型的回答。
🧑💻 面试官：谁提供测试环境？谁保存执行进度？模型想顺便修改生产数据库，又由谁拦住？
模型能提出下一步，不代表这一步已经被可靠地执行。Harness 要补上的，就是从“提出动作”到“完成任务”之间的运行机制。
面试速答（60 秒版）
Agent Harness 可以理解为围绕模型搭建的一套运行系统。模型负责根据当前信息做判断，Harness 则负责把需要的信息交给模型、执行允许的工具调用，再把结果送回去。
例如 AI 编程时，模型可以提出修改文件、运行测试，但真正读写文件、启动程序、记录进度和检查权限的，仍然是应用提供的运行环境。
因此，Harness 不只是一个循环，也不只是很长的提示词。它还需要处理上下文、执行失败、任务结束条件等问题。对于长任务，还要考虑进度保存和中断后的继续执行。
不过，这个术语没有一份统一的组件清单。简单任务用很薄的一层就够了，只有遇到具体问题，再补充相应能力。判断它有没有用，要看同样的模型和任务，能否更稳定地交付结果。
知识点详解：模型和 Harness 分别在做什么？
模型返回的动作，需要有人接着执行
假设咱们让一个编程 Agent 给资料页增加头像上传功能。
模型读取需求后，可能请求查看页面文件。这个请求只是工具名称和参数，文件内容并不会凭空出现在模型面前。应用需要检查路径，读取文件，再把结果加入下一轮输入。
之后，模型提出修改代码、安装依赖、启动开发服务，同样需要运行系统把这些请求变成实际动作。某个命令卡住了，应用还得处理超时，并告诉模型发生了什么。
这套围绕模型安排输入、动作和反馈的机制，就是讨论 Harness 时最核心的部分。Anthropic 对运行组件的说明也把模型调用循环、工具路由和执行环境区分开来。不同项目可能把其中一些能力放进独立服务，所以不要把 Harness 理解成某个固定类名。
跟着一次头像上传任务，看它如何工作
接到需求后，系统先明确工作目录、允许使用的工具，以及这次任务不能碰的资源。比如只能修改测试项目，不能操作生产数据库。
接着，运行器把需求和必要代码交给模型。模型要求读取更多文件时，工具执行器返回内容；模型要求修改代码时，执行器在授权目录内完成改动。这是“判断—执行—反馈”的基本循环。
但是，做到这里仍然可能只得到一份看起来正确的代码。
头像上传涉及选择图片、提交请求、保存地址和重新加载。如果模型只看见上传接口返回成功，就宣布任务完成，它可能漏掉“刷新后仍然显示新头像”这个要求。
因此，系统需要提供能够验证这一行为的环境和验收条件：在测试账号中上传图片，重新进入资料页，检查图片地址和实际展示结果。模型可以参与执行测试，但不能仅凭自己说“通过了”就替代可检查的测试记录。
整个过程中，还有一些事情不该完全交给模型决定。例如执行时间上限、禁止访问的目录、是否允许发起外网请求。这些限制应由应用或隔离环境落实。提示词可以告诉模型规则，但权限检查要有真实的拦截能力。
为什么一个长提示词不够？
在提示词里写“请记住进度”，不等于服务重启后进度还在。
写“完成后必须测试”，也不等于系统已经有可运行的测试环境。如果缺少测试账号、依赖服务或者浏览器，模型最多只能描述自己准备怎么测。
所以，可以把这个案例里的工作分成两类：
| 要求 | 谁来提供实际能力 |
|---|---|
| 判断要改哪些代码 | 模型结合上下文判断 |
| 读取文件、执行命令 | 工具及执行环境 |
| 记住当前做到哪一步 | 持久化状态或工作产物 |
| 阻止访问生产资源 | 应用权限与环境隔离 |
| 证明头像刷新后仍然存在 | 验收用例、运行环境和测试证据 |
提示词负责说明怎么工作，后面这些组件负责让工作真正发生。两者可以配合，但不能相互替代。
Harness 是不是做得越完整越好？
也不是。一个只查询天气再组织回答的助手，可能不需要文件系统、任务规划和多 Agent 协作。强行加上这些能力，只会增加理解和维护成本。
对头像上传任务，也应该先看实际失败发生在哪里。如果失败原因是没验证刷新后的效果，就补验收用例和浏览器环境；如果是换一轮上下文后忘记已经改了哪些文件，再补进度记录。
Anthropic 的长任务实践展示了通过持久工作记录和测试帮助后续执行继续推进的做法。这能提供参考，但不意味着所有系统都要照搬它的文件或流程。
评估时，尽量固定模型版本和任务集合，只改变准备验证的运行机制，观察目标达成情况、失败位置、耗时和成本。否则，同时换模型、换提示词、加工具，最后即使结果变好了，也很难知道是哪一项起了作用。
面试官继续追问
Harness 和 Agent Framework 是一回事吗？
有重叠，但讨论的角度不同。框架通常提供模型接口、状态流转、工具调用等可复用能力；Harness 更关注一个实际 Agent 是怎样被组织和运行的。你可以用框架搭 Harness，也可以自己实现；有些框架直接提供较完整的 Harness，不能按名字硬切开。
模型变强了，Harness 会不会不再需要？
一些为了弥补模型能力不足而写的复杂提示和规划流程，可能可以简化。但文件要由程序读取，权限要由可信系统执行，进度要有地方保存，这些职责仍然存在。应该重新评测哪些机制还有必要，而不是把所有历史设计永久保留。
怎样避免 Harness 限制模型发挥？
把必须执行的规则和可以自由探索的部分分开。例如只读权限由系统强制执行，但允许模型选择查询哪些文件。不要为了方便验收，把唯一正确路径写死；只要符合限制并满足目标，可以接受不同的执行顺序。
面试速记卡
- 模型职责：结合当前信息，判断下一步要做什么。
- Harness 职责：组织输入、执行动作、保存进度并处理运行过程。
- 提示词边界：说明规则，不等于提供环境或落实权限。
- 设计原则：针对实际失败补能力，不按组件数量判断成熟度。
- 验收标准：看任务结果和执行证据，不只看模型宣布完成。
