用户说：“读取订单 A1042 的售后资料，生成一份有依据的报告。”模型返回了一段措辞完整的文字。可是资料读了吗？文件写在哪里？其中“质量问题已确认”究竟来自哪一条记录？这些问题没有得到回答，任务就还没有完成。
本系列讨论的 Harness，就是把模型输出接到真实工作过程中的那部分程序。它准备工作环境，把动作交给可执行的工具，把观察结果送回模型，并依据外部证据决定继续、暂停还是结束。先理解这条循环，再讨论 Skill、Sandbox 和恢复，读者才能知道每个组件为什么出现。
一次回答与一次任务，中间差了什么
普通文本生成可以写成“输入消息，得到输出消息”。有工具的任务还多了一次环境交互：模型先提出动作，程序执行动作，环境发生变化，程序拿到结果，下一轮模型才有新的信息。
例如第一轮输出 read_order("A1042")，并不表示模型自己访问了订单库。只有控制器识别这个名字，校验参数和当前用户权限，再调用业务函数，订单数据才被读取。第二轮输出报告正文也不表示磁盘中出现了文件。还需要文件工具完成写入，返回路径和版本。
可以用下面的关系描述这个过程。这里是系统行为的简化模型，不是训练公式：
本轮可见信息 = 固定规则 + 当前任务 + 选中的历史与资料
动作建议 = 模型(本轮可见信息)
执行结果 = 执行器(动作建议, 当前权限, 工作环境)
新状态 = 更新(旧状态, 执行结果)其中每个参数都有现实意义。如果工具定义进入了请求，但执行器没有注册对应工具，会出现“模型会提出、系统却不会执行”的断裂。如果权限只写在固定规则里，执行器不检查身份，动作仍可能越权。模型是否遵守指令和程序是否允许动作，是两个独立问题。
用一份报告看完整闭环
本系列使用虚构教学数据：订单 A1042 已签收十天，客户声称存在质量问题，但商家尚未完成核验。政策 P7-v2 规定，经确认属于质量问题时由商家承担退货运费；未核验时应继续收集证据。报告必须区分客户陈述、系统事实和条件性结论。
第一次尝试可能生成“已确认质量问题，商家承担运费”。Verifier 将它与订单快照比较，返回“quality_verified 预期为 false”。模型获得这条反馈后，应修正报告为“待核验”，而不是修改原始订单来让报告通过。
这个流程可以拆成六个阶段：准备输入、形成动作、执行动作、观察结果、验证候选产物、导出交付。阶段不是强制每次调用一个模型；输入准备和确定性校验通常直接由程序完成。模型主要处理需要解释、选择和生成的部分。
报告没有通过时，控制器可以允许有限修复。权限被拒绝时，控制器应返回可理解的拒绝原因。任务需要缺失资料时，应进入等待，而不是在没有新信息的情况下反复生成答案。这些分支才是 Harness 的实际工作。
Harness、Framework 和 Runtime 怎样分工
这些词没有跨项目统一的固定分层。一个 SDK 可以同时提供工具循环、工作区管理和状态保存。下面的划分是分析职责的方法，不能根据产品名推断它一定具备什么保证。
| 职责 | 在报告任务中的具体内容 |
|---|---|
| Application，业务应用 | 用户有权查看哪些订单；报告应该包含哪些业务事实 |
| Harness，任务控制与装配 | 本轮加载什么规则、允许哪些动作、怎样接收反馈和交付 |
| Framework，编程抽象 | 用节点、事件、中间件或普通函数表达上述逻辑 |
| Runtime，持续执行设施 | 任务在哪个 Worker 执行；怎样保存进度、等待和恢复 |
例如用 LangGraph 表达 prepare → act → verify，图的节点和边是框架抽象；你定义的工具集合与完成规则属于 Harness；数据库 Checkpointer 是状态保存设施的一部分；订单授权仍然属于业务规则。换一个图框架，不应该导致商家政策随之变化。
Sandbox 是执行环境的隔离机制。它与上述职责相交：Harness 决定要启动什么环境，Runtime 管理生命周期，操作系统或虚拟化设施执行隔离。将它画成一个框，并不意味着边界已经生效。
为什么更强的模型仍然需要 Harness
模型能力决定它能否理解任务、选择合理步骤和修正错误，但它无法凭空知道宿主进程有没有写成功。模型可以推测文件存在，只有读取文件或存储回执才能确认。
同一个模型在不同 Harness 下的表现也可能不同。一个工具返回几万行无关日志，另一个返回错误位置、退出状态和完整日志引用，后者通常更容易让下一步聚焦。但反馈被过度裁剪，关键异常也可能消失。因此效果取决于模型与接口的配合，而不是工具越多越好。
长任务还需要把成果留在模型窗口之外。把所有聊天反复发送，可能保留大量尝试过程，却没有可靠地记录哪一份文件已经交付。持久进度、工作区和外部操作回执承担不同职责，不能都压成一段“上轮摘要”。
从普通程序逐步增加控制能力
不需要为了使用 Harness 先搭建平台。固定输入生成固定结构、没有环境动作的任务，普通函数加校验就足够。开始读写文件时，补上工作区和工具入口；需要根据失败反馈继续时，补上循环与预算；跨进程执行时，再加入持久化和任务所有权。
完整 Python 示例下载采用标准库展示这个过程。模型部分是明确标注的固定轨迹，文件写入和事实验证则是真实代码行为。它帮助读者观察控制逻辑，不声称已经接通模型或具备生产沙箱。
阅读后续文章时，可以一直追问：这项能力读取什么输入，在什么地方改变状态，它给下一步留下什么可检查的结果？按照这三个问题理解代码，比记住一串组件名称更容易建立完整认识。
下一篇讨论指令与 Skill 怎样进入一次请求。配套文件与执行说明集中在实践指南下载。