Agent Harness

把模型、工具、上下文与恢复边界组合成可执行系统的外围层。

模型产生的是下一段内容或行动请求，harness把这些请求放进一个有边界的工作系统。同一个模型接上不同的工具、历史管理、停止条件和恢复机制，会呈现不同的Agent能力。企业选型因此应问“这层替我承担哪些责任”，而不是只问能否调用某个模型。金融研究需要可复算产物，合同研究需要来源与法域，教学需要区分提示和独立作答；这些领域合同不应藏在通用循环里。

公开的Claude Code文档把harness解释为提供工具、管理模型上下文的外围层。OpenAI托管架构进一步区分harness、environment与application server。两者支持一个重要拆分：推理进程可以重启，计算环境可以重建，业务Task与证据仍须有权威记录。不要因为某个沙箱有文件，就将它当数据库；也不要因为模型服务保存了conversation，就认为外部业务动作能够安全恢复。

设计上至少列出三张责任表：谁决定下一步，谁有权执行，谁证明完成。主Agent负责探索与综合；工具网关持有真实授权；验证器检查业务后置条件。编排可以是同一服务内的模块，不要求一开始拆出微服务。接口应允许替换运行时，同时保留Task、ToolOperation、Artifact和Evidence的稳定身份。

选择托管harness能减少沙箱、流处理和压缩的维护，但会增加对供应商会话格式、配额、区域和生命周期的依赖。选择SDK可掌握部署和数据，却要自己处理租约、取消、恢复和运维。评估两条路线应使用同一业务范围与失败场景；只跑通问答或安装示例不能证明企业适用。

一个可实施的起点是保留企业自己的Task与证据服务，把托管harness接成RuntimeAdapter。输入是一份范围明确的研究任务，输出是结构化产物、工具回执和轨迹引用。若未来更换供应商，业务记录仍能读取，测试集仍能重跑，而不是只能看到某个已停用会话的ID。这个退出能力应在试用时验证，不必等到采购合同结束。

实践重点：区分业务控制、模型推理、执行环境与持久状态；以适配器接入托管或自运维运行时。

验证抓手：用真实工具、权限和重启场景验证整条任务链。

常见误区：把模型API当完整Agent，或把coding harness直接当企业平台。

Claude Code：工作原理；OpenAI：托管Agents架构。