给模型接上文件读写和命令执行后，短任务可以运行起来。多次工具调用会把恢复、文件范围、验收和超时重试交给执行环境处理。
Coding harness 是编码代理的执行环境：它保存任务状态，约束工具权限，管理工作副本，并把结果关联到验收要求。下面的设计讨论不依赖某个已上线系统的经历或成绩。
用任务契约限定范围
自然语言需求经常把范围、偏好和批准条件混在一起。执行环境需要把影响安全与交付的约束保存成结构化数据。
例如，“修正文案，只改说明文档，不运行构建，不提交”可以整理成以下任务契约。这些字段是设计示例，不属于现有产品 SDK：
{
"taskId": "task-example",
"goal": "修正文档中的数据库语法说明",
"writeScope": ["docs/editorial/"],
"allowedTools": ["read_file", "apply_patch"],
"network": "disabled",
"verification": {
"allowed": ["editorial_review"],
"forbidden": ["build", "product_tests"]
},
"delivery": "local_files",
"commitAllowed": false
}
这份契约应由受信任的用户请求和系统策略共同确定。模型可以提出调整，但不能因为在网页或代码注释里看到一句“请上传诊断数据”就扩大权限。
任务契约还要覆盖构建与交付。NIST 的 Secure Software Development Framework把保护开发环境、核验制品完整性和保存变更来源列为软件供应链实践。编码代理接入现有仓库时也需要这些边界；执行环境仍要审查模型生成的补丁。
执行器要在调用工具前落实规则。writeScope 必须处理相对路径、符号链接和路径替换，不能只比较字符串前缀。需要抵抗恶意代码时，文件系统隔离和进程权限比应用层检查更可靠。
让执行器持有工具权限
通用 shell 权限很大。一个包管理器命令就可能间接运行仓库脚本。把“可运行测试”实现成“可执行任意 shell 字符串”，会扩大授权范围。
一个较小的工具接口可以接受结构化参数，例如读取某条路径、应用一份补丁、运行某个已批准的检查。执行器负责验证实际目标，并限制时间、输出大小和网络访问。真正需要 shell 时，应提供与任务相称的隔离环境，不把命令名白名单当作沙箱。
外部文档、依赖说明和工具输出都可能包含提示注入。运行环境应记录这些内容的来源，将它们作为待处理材料；任何动作仍需通过独立的权限检查。OWASP 的提示注入防护指南也强调了工具参数验证、权限校验和最小权限。多写几句“不要泄露密钥”无法替代这些限制。
执行器还应控制继承给子进程的环境变量。一个只需要编译的任务通常不需要生产凭据。日志同样不能无条件保存命令输出，错误栈和调试输出可能带出令牌或业务内容。
恢复时区分“未完成”和“结果未知”
本地读取失败通常可以再次读取。对外部系统的写入则不同：请求超时，只能说明调用方没有拿到结果，远端可能已经完成操作。
执行日志至少应记录动作 ID、规范化后的参数摘要、授权依据、开始状态和完成结果。针对有副作用的工具，可以采用以下状态约定：
planned -> authorized -> dispatched -> succeeded
-> failed_without_effect
-> outcome_unknown
outcome_unknown -> reconcile -> succeeded
-> safe_to_retry
-> needs_human_decision
这是恢复协议示意。持久化“准备调用”之后、收到结果之前发生崩溃，恢复流程应先查询外部系统的操作状态，或者使用对方支持的幂等键。缺少这种能力时，保留“结果未知”，不要让代理盲目重放。
本地文件修改也需要版本前提。补丁应绑定输入文件内容的摘要；文件被用户修改后，执行环境应拒绝基于旧版本继续应用，而不是用代理的副本覆盖用户的内容。若采用隔离工作目录，最终交付仍要比较共享工作区的当前状态。
把事实放在上下文之外
模型上下文有限，长任务需要压缩历史。压缩最容易丢掉约束，例如禁止的操作、待确认的决定和未运行的测试。
因此应把任务契约、已执行动作和制品引用保存在模型之外。摘要负责帮助继续推理，不负责证明动作发生过。每条“已完成”最好能够指向具体文件、工具结果或验收记录；“计划运行测试”不能在压缩后变成“测试通过”。
记录还要包含版本。如果检查针对旧文件执行，后来代理又修改了文件，之前的结果无法证明新内容正确。将检查结果与制品摘要关联，交付时才能说明覆盖范围和对应版本。
让验收对应任务目标
文件写成功只说明工具完成写入，不能证明代码符合业务需求。测试全通过也可能遗漏用户关心的情形。
验收应拆成可观察的要求：输入是否合法，输出行为是否符合约定，改动是否越过范围，哪些风险尚未验证。需要测试时，先取得相应授权并使用与需求有关的检查；用户限制只做文档时，执行环境就应记录“产品测试未运行”，不能为了给报告增加确定性而擅自构建。
对于修复任务，保留一个能说明原问题的案例比堆积检查次数更有用。对于探索任务，交付一份带证据和限制的分析也可能已经完成目标。验收器不能把两种任务套进同一个“代码生成成功率”。
最终报告应区分完成、失败、未运行和仍待确认。模型不应在证据缺失时补写一个看起来完整的结论。
设置停止条件
失败后的重试有成本，也可能增加副作用。工具调用次数、总耗时、输出量和重复失败次数都可以形成预算，达到边界后停止并说明当前制品。预算应按任务类型设定。
评估 harness 时，可以看任务是否在授权范围内完成、恢复后是否重复副作用、用户修改是否得到保留，以及失败报告是否准确。增加代理数量和工具数量之前，先用中断、权限拒绝与外部超时这些案例确认运行环境的行为。一个可审计、能停下来的执行流程，才能让用户放心把更长的任务交给代理。