把一个持续几小时的软件任务交给 AI，困难往往出现在后半程：它忘了先前约束，不知道某个检查是否真的跑过，或者中断后重复已经执行的动作。解决这些问题，需要设计模型周围的执行系统。
可以先把规划、实现和验证分成明确的职责，再用状态文件连接各个步骤。即使只有一个 Agent，也需要知道什么时候继续、什么时候重查，以及什么时候交给人。
配图中的像素编辑器能显示画布与颜色面板，但画笔是否生效、保存后能否重开，仍需要逐项操作验收。界面看起来完整，只是长任务交付的一部分。
Harness 是模型周围哪些东西#
这里的 Harness 可以理解为任务执行环境：它接收需求，给模型提供工具，记录工作状态，执行验证，并决定下一步继续、重试还是交接给人。
模型负责提出和执行某些动作；Harness 负责让这些动作处在一个可观察的流程里。把聊天窗口换成命令行，并不会自动得到可靠的长任务系统。真正的问题是：进程中断后，另一个执行者能否根据现存证据继续工作？
一个简单系统也可以完成这些职责。早期项目未必需要单独部署队列、数据库和多个 Agent，清晰的任务文件、隔离工作区及可重复运行的验证命令，已经能建立有用的起点。
把大目标拆成能够验收的切片#
假设需求是“给管理后台增加订单导出功能”。直接让 Agent 一口气完成，容易把接口、权限、文件生成和页面交互混在一起，最后只能得到一句“功能已完成”。
按可观察行为拆分，比只按文件拆分更容易验收：
| 工作切片 | 交付行为 | 最小验收证据 |
|---|---|---|
| 查询范围 | 导出与列表采用相同筛选条件 | 固定数据下返回一致的记录集合 |
| 文件格式 | 输出约定列和金额格式 | 解析导出文件后检查表头、行数与值 |
| 页面交互 | 显示处理中、完成与失败状态 | 实际浏览器操作与错误场景检查 |
| 权限控制 | 无权限账号无法发起导出 | 独立接口检查，而非仅隐藏按钮 |
列定义、时间范围和权限语义应先由需求负责人确认。切片的目标是缩小验证范围，不必让每个步骤都产生额外文档。
状态文件要保存事实，而不只是计划#
计划回答“接下来做什么”，状态记录回答“已经有什么证据”。两者混在一个不断打勾的清单里，很容易把“代码写好了”误当作“功能验证通过”。
状态记录可以采用下面的结构。它是应用侧的示意格式，需要由执行系统读写：
task_id: export-demo
phase: waiting_for_review
workspace_revision: EXAMPLE_COMMIT_ID
completed:
- export_column_contract
pending:
- browser_acceptance
evidence:
- kind: file_parse_check
result: passed
artifact: artifacts/export-check.json
next_action: review_browser_flow
external_effects:
production_changed: falseworkspace_revision 应关联真实代码版本；示例中的占位符没有证据效力。completed 应只记录满足完成定义的切片，pending 明确未做事项，evidence 指向执行输出。若报告文件丢失、版本对不上，下一位执行者就需要重新核验，而不能照单全收。
运行日志适合回答“发生了什么”，状态文件适合回答“现在在哪里”，交接说明适合回答“下一步怎么继续”。三者用途不同，没有必要把几万行日志全部塞进新会话。
独立验证怎样避免自说自话#
假设生成者新增了导出接口。它运行单元测试通过后，可以提交给验证步骤；验证者读取产物，在固定数据集上真正下载并解析文件，检查筛选和权限。
独立验证并不要求一定使用另一个大模型。可机器判断的内容可以由脚本检查；需要判断交互是否清楚的内容可以由人工查看；模型审查适合辅助发现问题。关键是验证使用外部证据，而不是重复阅读生成者的完成报告。
评估也应有停止条件。例如，限定修复轮数和预算，连续两轮没有新增有效证据时交接给人。这些阈值需要按任务成本制定。无限循环会让“继续优化”变成无法验收的目标。
中断恢复先确认状态，再决定是否重做#
恢复时可以依次检查：当前代码版本与状态记录是否一致；未提交变更是否属于本任务；最近的验证报告对应哪个版本；是否存在进行中的外部操作。
纯本地计算通常可以重跑，但带外部影响的步骤必须单独处理。比如已经向对象存储上传导出文件，却在记录成功前断线，直接重试可能产生重复文件。应为该步骤保存操作标识，并先查询服务端结果；状态未知时标成待核对，而不是自行认定失败。
恢复成功也不等于所有步骤都可靠。源代码可以保存在 Git，运行中的进程、临时文件和远端操作状态却不在提交里。恢复设计需要列清这些状态分别放在哪里，以及丢失后如何重建。
工作区隔离与持久执行#
Git worktree 允许同一仓库拥有多个工作目录，并为各目录保留独立的 HEAD、索引等状态，但仍共享仓库对象与部分元数据。可以用它隔离编程任务的文件修改；数据库、端口和凭据仍需另外隔离。
Temporal 则提供持久化工作流执行，通过事件历史支持恢复与重放。这是运行系统层面的能力，与把进度写进 Markdown 不在同一层次。是否需要引入它，应由跨进程恢复需求和维护成本决定，而非因为任务里出现了“Agent”。
对个人开发流程，可以先把每个任务控制在独立工作区内，维护小而准确的状态记录，并为关键行为准备验证命令。只有当任务需要跨机器、等待很久或持续恢复时，再考虑更完整的调度与持久执行设施。
人工交接应该留下什么#
一份有用的交接内容应能回答四个问题：已经实现了哪些行为、哪些证据能够证明、还有哪些未知事项、下一步需要谁做什么。
例如可以写：“文件生成和固定数据检查通过；手机端下载流程未验收；生产未变更；请在预览环境检查下载按钮、失败提示和文件编码。”这比一句“基本完成，建议人工看看”更可操作。
长任务系统的价值，是让完成状态能够被确认，让中断后的下一步能够被找到。随着模型更新，工具和编排方式可以调整，但这些证据、边界和交接要求仍然值得保留。
参考来源#
- Prithvi Rajasekaran：Harness design for long-running application development，2026-03-24。
- Git 项目：git-worktree。
- Temporal：Temporal Workflow Execution overview。
- 配图：Anthropic，图片出处。