正文
继续看前面使用的会议通知例子。用户要求查询下一次项目例会，核实日期、时间和地点，再把通知保存成草稿。模型可以判断需要查日历，也可以生成通知，但它不会仅凭这样的判断，自动获得日历连接、文件权限和任务进度记录。
负责安排这些事情的运行设施，就是这一篇要认识的 Agent Harness。
Agent Harness 可以先理解为：围绕模型组织起来，让任务能够运行、受到控制并留下结果的一组程序设施。 它接收输入，安排模型调用，把模型提出的工具请求交给相应程序，再接回执行结果。不同项目对这个词划定的范围可能有所不同，阅读时需要看作者具体包括哪些职责。Agent Harness 的工程定义
这个名称有时被译作“智能体运行框架”或“运行支架”。初学时不必急着记译名，可以先看：如果缺少这些程序，会议通知任务会在哪里停下来。
任务刚开始，程序需要把用户要求、当前日期、可用工具说明等内容提供给模型。模型接收的只是这次调用中的信息，并不会自动知道应用接了哪些日历账户，也不会自动看到文件夹里所有内容。
因此，Harness 需要组织输入。比如，提供查询项目日历的工具，说明它接受哪些参数；保留“只保存草稿”的要求；在下一轮调用中加入已经查到的会议记录。如果每次调用只传一句“继续”，模型就可能缺少判断下一步所需的依据。
接着，模型提出查询请求。程序需要识别工具名称，检查参数是否符合工具要求，确认这次操作处于允许范围内，然后把请求交给日历接口。查询结束后，再把真实返回结果放进后续输入。
这些环节解释了模型与运行设施的分工：模型参与判断查什么，程序负责把请求转换成可执行的调用。工具返回“两场同名会议”或“查询失败”，都应当成为系统后续处理的信息。程序如果丢掉错误，只告诉模型“操作结束”，模型就缺少发现问题的依据。
这里还需要区分 Harness 与实际执行操作的环境。
日历工具可能访问一个远程服务，文件工具可能操作本机目录；如果任务需要运行生成的代码，还可能配置一个隔离的执行环境，通常称为沙箱。沙箱关注代码可以在哪里运行、接触哪些资源，Harness 则负责组织任务过程。二者可以配合，也可以部署在不同地方。Anthropic 的一项架构说明，就把会话记录、执行循环和沙箱分开设计。执行循环、会话与沙箱的分工
所以，标题里的“运行环境与控制设施”是一种教学概括，不能理解成 Harness 必然是一台虚拟电脑，也不能理解成有了沙箱，模型就会自己完成任务。
回到会议任务。假设工具能够读写整个文件系统，用户却只授权把通知存进“会议草稿”文件夹。此时，仅在提示词里写“请不要操作其他目录”，还不足以代替程序层面的访问检查。
应用可以限制文件工具接受的路径，也可以只提供保存草稿的专用接口。模型即使提出其他操作，请求也需要通过相应检查才能执行。这些限制由实际程序落实，不能只依赖模型记住一句约定。
已经允许的查询和保存，也可以按规则直接进行。运行控制的目的，是把授权范围落实到执行过程；具体哪些操作还要询问用户，要根据任务和已有授权决定。
任务继续以后，Harness 还要处理进展信息。比如，系统已经排除一场同名会议，确认了另一场会议的时间，但草稿尚未保存。这些内容需要有地方记录，否则下一次调用可能重复查询，或者把“已经写好正文”误当成“已经保存文件”。
这里可以再次区分任务状态与模型上下文：任务状态描述工作做到了哪里；上下文是这一轮提供给模型的输入。程序可以保存较完整的状态，再选择相关部分放入上下文。保存状态也不等于更新模型参数。
如果任务会暂停或跨越程序重启，状态还需要合适的持久保存方式。例如，LangGraph 将当前任务的状态检查点与跨任务的长期存储分开，分别服务于继续执行和长期信息保留。只存在内存中的记录，则可能随进程结束而丢失。任务检查点与持久化存储
不过，保存了一份“准备写文件”的记录，并不能证明文件后来确实写成功。
假设保存请求发出后，连接突然中断。文件可能根本没有写入，也可能已经写入，只是成功消息没有送回来。恢复任务时，程序需要根据工具能力查询结果、核对文件或避免重复创建，不能看到没有成功消息，就毫无检查地重复所有动作。
这也是为什么“能恢复”比“把聊天记录再发一次”更复杂。恢复需要知道此前哪些事情已经发生、哪些仍不确定，以及下一步怎样取得依据。不同操作的恢复方式也可能不同。
执行过程中还需要管理时间、次数和费用。日历服务持续失败时，系统不应无限重试；模型反复查询相同记录时，程序可以根据预算或停止条件结束本次运行，并说明尚未完成的部分。
这些运行记录也有用途：用户说通知时间不对，开发者需要查明，是读错会议、输入漏掉了时区，还是正文生成时改动了时间。如果只保存最后一句“任务完成”，就很难找到问题发生的位置。
对于更长的任务，运行设施还可能帮助整理阶段结果，把已完成内容和后续工作留给下一次运行。相关工程经验强调，跨越多个上下文窗口时，需要清楚的进度与可继续使用的产物；仅仅不断调用模型，并不足以维持可靠进展。长任务中的进度与交接设施
任务结束以后，程序还需要按设计释放本次占用的连接、临时进程或工作空间，并保留应当交付的草稿。这里同样需要分清任务所有权：属于其他任务或用户的资源，不能因为这次工作结束就一并清理。
认识这些职责以后，就容易理解 Harness 与其他名称的关系了。
提示词规定模型应当怎样处理信息，是运行设施可以使用的输入之一。开发框架可以提供调用、状态管理等现成组件，帮助实现 Harness。实际应用中的 Harness，则是这些设施被配置和组织后，真正运行任务的那一部分。
小任务可以只需要少量程序，大任务可能需要更完整的状态、权限和恢复机制。具体需要哪些设施，要看任务会在哪些地方失败，以及发生后应该怎样处理，不能只按照某个组件清单堆叠功能。
Harness 也不能保证日历数据正确，或保证模型永远理解无误。它能帮助系统取得真实结果、限制执行范围并暴露错误；会议信息是否准确、草稿是否符合要求，仍然需要相应核对。
现在回看会议通知例子，可以发现任务能够持续推进，依赖模型的判断，也依赖输入组织、工具执行、状态记录和运行控制。下一篇会进一步讨论：这些设施运行起来以后，哪些事情可以自行处理，哪些事情应该留给人决定。
当前学习编号：01.10 Agent Harness：运行环境与控制设施。
下一学习编号：01.11 自主程度与人工参与边界。后续还有其他学习编号。
关联分支：输入组织对应 13.07 上下文窗口与有效信息预算、13.08 上下文选择与即时检索；工具执行对应 16.05 工具调用请求与实际执行的区别、16.06 参数校验与默认值。
连续运行对应 18.11 步数、时间与费用预算、18.12 检查点与持久化执行、18.13 暂停、恢复与取消、19.02 工作状态与业务状态；边界与排错对应 22.06 最小权限与能力范围、24.02 调用链与工具执行轨迹、24.13 资源所有权、清理与泄漏防治。这些支系会在各自编号中单独展开。