READ · UNDERSTAND · TRANSFER
阅读理解，按需巩固
先沿着原理、问答和迁移案例阅读。需要检查理解时，再切换巩固练习或展开个人记录。
核心知识 · 任务契约与独立验收
先理解核心原理
先备概念：访问控制、不可变版本、测试验收
Harness 把目标变成可执行边界和可检查产物。模型可修改解决方案，不能通过修改权限或验收标准制造成功；恢复时根据事实重建工作视图，而不是把一段进度摘要当成系统真相。
为什么长提示词不能承担全部责任
提示词类似接口使用说明，能够引导调用，但不拥有事务、凭据和文件权限。若工具网关允许删除验收文件，再强的“不要改测试”也只是软约束。应把任务定义、候选产物和验收程序放在不同权限域，运行时从可信任务记录读取限制。
契约把模糊目标拆成证据
“修复登录”至少要说明允许修改的目录、输入基线、成功行为和验证环境。契约可调整，但调整必须有明确来源和版本，记录哪些旧证据失效。验收器读取当前产物执行固定检查，模型写的进度标志只帮助协作，不直接决定最终状态。
恢复是一轮重新对账
进度文件回答“上次做到了哪里”，仓库和工具回执回答“现在确实存在什么”。两者不一致时先诊断，不能复述旧摘要继续执行。Anthropic 的长任务文章提供工程记录的实践依据；本站的独立验收与权限分层是进一步的设计建议，并非任何 SDK 自动保证的能力。
回到问题：怎样回答？
Harness 是包围模型的执行与管理层，承担工具接入、权限和预算、状态保存、环境准备、轨迹记录及验收。它不能只是一段很长的系统提示词。我会把任务定义为目标、约束、允许动作、产物和机器可执行验收，并在每次恢复时重建可信上下文。模型负责提出计划和候选结果，Harness 负责判断动作是否允许、结果是否被证据支持，以及任务能否进入完成状态。
实现与取舍
Harness 的职责要落到接口
可以把系统分成模型适配器、工具网关、状态仓库、策略控制、验收器和事件管道。模型适配器统一调用响应，工具网关统一校验和鉴权，状态仓库记录运行事实，验收器检查产物。提示词描述规则，但真正的禁止动作由网关拒绝。Anthropic 的长任务工程文章用进度记录、功能清单和版本历史帮助新上下文接手工作，这提供了一个实践方向：连续工作依赖可读取的工程状态，不只依赖聊天记忆。
任务契约如何具体表达
输入包含 task_id、目标、资源范围、基线版本、截止时间和预算。允许动作按工具与资源限定，例如可以修改指定分支，不能操作生产库。产物契约规定文件路径、格式、来源引用和必要字段。验收契约直接写可观察行为，例如“未登录用户可读取公开文章；私有管理接口返回拒绝；构建通过”。宽泛的“体验好、内容丰富”不能替代验收。模型可建议补充测试，但不能删除既有失败标准来制造成功。
长任务恢复需要事实分层
恢复包至少包括最近确认的目标、当前基线版本、已完成子任务、未解决问题、证据位置与下一步候选。原始日志保留供审计，摘要用来降低上下文成本，两者不能互相替代。恢复前重新检查仓库状态、产物摘要和授权有效期；数据库记录“已完成”但文件丢失时，应进入诊断。进度只表示工作状态，最终成功由独立验收器确认。人工审批保存对象版本、批准者和范围，而不是保存一个全局 approved=true。
如何验证这套契约
先用确定性假模型模拟异常：声称成功但无产物、产物被外部修改、试图访问范围外资源、上下文被清空后恢复。断言每次都按契约拒绝或诊断，成功必须有可复查证据。再用真实模型跑典型任务，记录完成率、人工介入原因和成本。Harness 不是把 Agent 包装成万能平台；应从一类具体任务开始，明确哪些检查确定执行、哪些判断仍需人工，再逐步扩展。
工程推演
- 场景
- 假设工程场景：Agent 跨多轮修改网站，容易忘记未完成的移动端行为并提前宣布上线。
- 设计决策
- 建立版本化任务清单和验收记录；恢复时读取当前代码与进度；部署由通过验收的产物触发。
- 验证目标
- 预期行为：手机目录未验收时任务保持未完成，新的上下文能够继续处理这一项。
- 适用边界
- 这是通用架构示例，未声称已经拥有无人值守开发能力；视觉质量仍可能需要人工评价。
连续追问与解答
沿着问题的前提和约束继续向下读。先理解参考解答，再尝试收起答案，用自己的话解释因果和取舍。
第 1 层怎样阻止 Agent 修改验收标准来让自己通过？
模型能控制候选实现时，要再检查它是否也控制了裁判。
参考解答
把受信验收定义放在模型无写权限的区域，或从固定版本载入并校验摘要。工作目录内可编辑的测试只作补充；最终检查来自独立验收器，读取其退出状态和证据。合法需求变化应生成新契约版本并说明变更来源，不能默许模型删除失败断言。
沿着这个回答继续深入
第 2 层独立测试通过，但 Agent 把服务配置成只对测试账号开放，算通过吗？
独立性解决篡改问题，下一步是测试是否真实代表目标。
参考解答
说明现有验收覆盖不足。增加符合实际权限范围的代表账号和配置检查，复查是否违反原契约；若原目标要求普通用户可用，单个测试账号成功不够。受保护验收防止改题，仍不能保证题目本身充分，要把行为条件写具体。
沿着这个回答继续深入
第 3 层如何避免不断追加验收条件，使任务永远无法完成？
加强验收也需边界，否则裁判独立却不稳定。
参考解答
在开工前给出验收范围和关键风险，新增检查须说明是验证原有要求，还是扩大目标。前者补齐证据，后者作为新任务或显式契约变更。保存版本和判断依据，让模型与用户都能区分修复遗漏和无限加需求。
第 1 层上下文压缩后丢掉了一个约束，运行时如何兜底？
摘要有损，硬限制不能只依赖模型记忆。
参考解答
金额、资源范围和禁止动作保存在服务端策略，工具执行前重新校验；摘要只帮助模型决策。漏掉约束时，网关拒绝并返回可理解的错误，运行时重建包含该限制的上下文。对于无法机器判断的语义约束，保存用户原话与来源，关键决策前回读或人工审查。
第 1 层恢复记录与当前仓库版本不一致时怎么办？
持久化状态可能落后于实际环境，恢复要先核对事实。
参考解答
暂停依赖旧版本的操作，比较基线与当前变更，核对已记录产物和测试证据。无冲突的结果可按依赖复用；相关代码或配置改变则重验，权限与批准也重新确认。不要直接覆盖当前仓库回到旧状态，先保护外部改动并给恢复决定留下记录。
举一反三：条件变了，怎样推导？
先找出改变的条件，再判断原方案中哪些前提仍成立。下面的案例是教学推演，便于将原理迁移到新问题。
交付依赖第三方 API
改变的条件：测试环境无法代表实时外部服务
延伸问题：本地测试通过能否证明任务完成？
推导与参考解答
区分本地契约验证与真实集成验证。用隔离凭据核验必要链路，无法访问时交付代码与明确未验证项，不能宣称远端成功。第三方返回的事务回执、权限范围和环境标识作为证据，模拟响应只证明本地处理逻辑。
保持不变的原理：每个成功结论需要与其声明范围一致的证据。
无自动判据的设计稿
改变的条件：产物质量需要人的判断
延伸问题：怎样维持独立验收？
推导与参考解答
先定义尺寸、格式、必备内容等自动检查，再让有权评审者按具体使用目标审阅固定版本。批准记录绑定该版本；模型可以修稿并解释取舍，不能给自己写 approved=true。质量评分有主观部分，验收流程仍能保持来源明确和结果可追溯。
保持不变的原理：验收可以由人执行，但决定来源与产物版本必须独立于自评文本。
易错点
- 把 Harness 等同于 Prompt 模板或模型本身
- 只保存自然语言摘要，不保存证据和版本
- 把模型自评当成最终验收
参考资料
依据公开技术资料设计；参考资料支持技术机制，场景与评分标准为本站设计，不代表某公司面试原题。 新增问答与迁移案例用于原理讲解，来源核查与案例运行验证分别记录。
检查自己理解到哪一步
读完后可以对照这些标准解释原理、边界和取舍。掌握程度由你自评；需要进一步验证时，再完成下方小任务。
- 基础达标
- 知道模型之外需要运行时、工具和状态管理。
- 中高级信号
- 能写出输入、允许动作、预算、产物和验收契约。
- 资深信号
- 把策略执行、隔离、恢复和证据收集做成可验证边界。
巩固练习 按需完成 · 建议 15 分钟
为“修复一个 API 并交付补丁”写任务合同和验收条件。
展开验收要求与检查点
- 验收可执行
- 允许修改范围明确
- 测试证据关联实际产物
重点检查
- 区分提示词与运行时可执行约束
- 能列出输入、产物、验收与恢复契约
- 验收证据不可被模型自行替换或删除