01 · 开篇：阿明不想再当 Agent 的“下一步按钮”
阿明以为，把任务交给 Agent 之后，自己终于可以去处理另一件事。可他刚切到别的窗口，就又得回来：确认实现方案、补充项目约定、提醒运行测试，再追问一句“现在到底能不能用？”代码一直在增加，他却始终没有从任务里抽身。
01.1 任务不大，交付却不止是写几个接口
团队正在开发一个内部 B 端控制台。运营同学需要通过邮箱注册、登录，进入控制台后查看当前用户，再从右上角退出。仓库已有 Express + TypeScript 骨架、控制台页面和 session 方案，密码处理、错误响应与测试也有现行约定。
阿明负责补齐认证接口和已有页面的接入。完成的标准是：应用能按说明启动，运营能走通注册、登录和登出；错误凭据有明确提示；退出后，原会话不能再访问用户信息；相关检查和运行说明能交给接手的人。本期不引入 OAuth，不替换会话方案，也不重新设计控制台。
这些要求在阿明心里是清楚的。他以为“按项目现有风格”已经包含了它们，于是在平台里输入：
帮我把控制台的注册、登录和登出做完，按项目现有风格实现。
01.2 Agent 在执行，阿明仍在安排下一步
第一版改动很快出现。Agent 给出了实现摘要，但没有附上完整流程的验证记录。阿明检查差异时发现，新代码另建了一条 JWT 路径，和仓库已有的 session 方案并存。他补充：“沿用现有 session，不要新增一套认证方案，也不要改密码哈希。”
改动调整后，他继续接入页面。登录看起来正常，点击退出也能回到登录页；但保留退出前的会话凭据再次请求 GET /me，仍然返回 200。阿明只好把这条请求链贴回去，让 Agent 修复服务端会话失效。
随后，他又补上“增加回归测试”“运行检查”“核对页面错误提示”“写清启动方式”。每次补充都让任务向前走一点，却也说明：范围由他提醒，事实由他补充，验证由他催促，下一步仍由他决定。
这版改动尚未合并。阿明开始意识到，如果自己不继续追问，任务很可能停在某个“代码已经写好”的位置。聊天记录里有很多进展，却很难直接回答三个问题：哪些要求已经满足？依据是什么？还剩什么没有完成？
01.3 为什么他成了“下一步按钮”
回看最初那句话，缺口并不难找。“做完”没有对应的验收条件；“现有风格”没有指向具体规范和实现；哪些操作可以自主完成、失败后如何处理，也没有约定。Agent 每完成一段工作，阿明就要重新接过调度权。
例如，登出接口返回成功，只能说明这次请求得到了成功响应。它是否真正让旧会话失效，还需要另一条验证。若任务里没有要求检查这个行为，执行过程也没有把失败带回修复，遗漏就会一直留到人来联调。
阿明想减少的，正是这些可以提前约定、可以由工具验证的反复交互。他仍然需要决定业务范围、授予必要权限并审查最终结果；调查代码、安排步骤、运行检查和修复范围内的问题，则应由 Agent 连续承担。
01.4 把零散追问，改成一次完整委托
阿明保留第一版差异和问题记录，在隔离分支上重新组织任务，保护原有工作区。这次，他先说明要交付的认证流程和验收条件，提供规范与代码入口，准备测试环境，并约定：范围内的调查、实现、验证和局部修复自主推进；普通步骤不必等待“继续”，真正的需求冲突、授权缺口和无法排除的阻塞才交回给他。
Agent 还要维护任务状态：每一步服务哪条要求，使用了什么依据，产生了哪些变更，验证结果是什么，失败后回到哪里。这样，即使会话需要恢复，也有记录可以核对；交付时，阿明可以对照要求审查结果，不必重新翻遍整段聊天。
接下来，本文用五种 Engineering 拆解这次委托：Prompt 定义目标，Context 补齐事实，Harness 支撑执行，Loop 带回反馈，Graph 维护它们之间的关联。后文会沿着同一个认证项目，说明这些约定怎样落实到任务、检查点和交付证据中。
02 · 总模型：五种 Engineering 的分工与关联
阿明遇到的问题，可以归结为：一旦他停止补充指令，任务就缺少继续推进和判断完成的依据。要减少这种依赖，初始委托必须让 Agent 知道目标、找到事实、具备执行条件，并能根据结果调整后续动作。
本文用五种 Engineering 组织这件事。这里的 Engineering，是把要求落实为可重复使用的规则、任务记录和检查方式。它们是交付工作的五个观察角度，可以利用现有平台的规则、计划、文件编辑和工具执行能力落地，不要求平台具有五个同名模块。
02.1 五种 Engineering，各自回答一个问题
| 方法与作用 | 回答的问题 | 认证项目中的具体做法 | 可核对的产物 |
|---|---|---|---|
| Prompt Engineering 把目标说清楚 | 交付什么，怎样才算完成？ | 约定注册、登录、查看用户和登出；退出后旧会话必须失效 | 任务契约、范围、验收条件 |
| Context Engineering 把事实补齐 | 依据什么做，有哪些事实还没查清？ | 读取现行 session、密码封装、路由和测试，核对当前行为 | 事实入口、基线、证据与待验证假设 |
| Harness Engineering 把执行跑稳 | 用什么工具，在什么边界内持续执行？ | 准备开发环境与工具权限，约定检查命令、变更范围和恢复方式 | 执行规则、检查点、工具结果 |
| Loop Engineering 把反馈带回 | 执行结果是否满足要求，不满足时怎么办？ | 发现登出后仍可访问 /me，补查原因、局部修复并回归 | 失败记录、下一步动作、复测结果 |
| Graph Engineering 把目标、事实、执行、反馈串起来 | 这一步关联哪些要求、依赖和证据？ | 将登出要求关联到会话实现、修复任务和验证记录；共享逻辑变化后重验登录 | 任务依赖、验收映射、状态与回流关系 |
这些产物可以放在同一份任务记录中，也可以由平台计划和项目文档共同承载。关键是执行时能够读取、更新和核对；分别创建五份文件，并不会自动形成可靠的交付过程。
02.2 四项工作循环推进，Graph 维护它们的关联
Harness 与 Loop 都涉及检查，但职责不同：Harness 提供能运行检查、取得结果和恢复任务的条件；Loop 判断结果与要求的差距，再把反馈转成补查、修复或重新决策。只有命令能够运行，却不根据失败改变下一步，任务仍然不会闭环。
Loop 与 Graph 也不能互相替代。Loop 处理“这次失败以后怎么办”；Graph 记录“这次失败属于哪个目标、会影响哪些任务、哪些旧证据需要重验”。因此，Graph 贯穿整个过程，不是在前四项完成后再补画一张图。
02.3 用一条登出要求，把整条关系走一遍
后文用 A1—A5 标记验收条件，用 T01—T06 标记任务。这些编号便于关联记录，不是平台内置命令。先看其中一条：A4 要求退出后旧会话失效，T04 负责实现并验证登出。
目标 / Prompt
A4：保留退出前的会话凭据，登出后访问 GET /me 应返回 401。
事实 / Context
当前项目使用 session；读取登出路由、会话存储和相关测试。
区分现有实现、实际响应与尚未证实的原因。
执行 / Harness
在已授权的本地环境保留会话凭据，运行登录 → 登出 → 再访问 /me。
保存请求结果和当前变更，确保失败能够复现。
反馈 / Loop
若仍返回 200：记录失败，查明原因，补回归检查，局部修复后复测。
接口返回“登出成功”，不能代替旧会话确实失效的证据。
关联 / Graph
A4 ↔ 会话实现与行为证据 ↔ T04 ↔ 复测记录。
若修复改变共享会话逻辑，将受影响的登录验收退回待验证。这里，“返回 200”是观察，“服务端会话没有被清理”只是需要核实的一种解释。Agent 应先检查代码和请求链，再决定修复位置。Graph 则把这次观察、调查和变更留在同一条可追溯关系里，避免报告中的“登出已完成”与实际验证脱节。
02.4 一次委托如何持续推进到交付
实际使用时，先确认平台能够访问项目、执行工具并取得验证结果，再发出包含目标和授权的任务。Agent 随后读取现状、运行基线、建立任务依赖；每完成一项工作，就对照验收条件检查，记录结果并推进后续无阻塞任务。出现失败时，按原因回到补事实、改实现或调整计划的位置。
普通步骤不必等待人输入“继续”。无法从现有资料判断的业务取舍、超出已授予权限的动作，以及缺少必要条件而无法继续的任务，才需要集中提出问题。平台若因会话、配额或工具限制中断，可以依据检查点核对并恢复；任务规则本身不能消除这些限制。
减少交互还需要一个明确终点：所有约定条件都有对应产物和有效证据，变更影响已经回归，运行与交接说明能够使用。若关键条件未验证，就保留缺口并报告准确状态，不能仅凭修改数量或执行时长宣告完成。
接下来的第 03—07 章分别说明五种 Engineering 如何落地；第 08 章把它们合成一次完整交付，第 09—10 章提供平台适配方法与启动模板。案例的任务依次包括现状与基线、注册、登录与当前用户、登出、集成回归和交付说明，具体依赖见第 07 章。
03 · Prompt Engineering：把目标说清楚
阿明第一次说“把认证做完”，实际上把许多决定留给了 Agent：做到接口还是页面？能否替换会话方案？什么检查通过才可以结束？Prompt Engineering 要把这些决定变成一份任务契约，使 Agent 在过程中能够判断该做什么、什么不能顺手做，以及什么时候可以交付。
03.1 先定义用户能完成什么，再约定实现边界
阿明把契约记为 Spec v1.0。先写运营同学需要走通的流程，再补充本轮范围与保护项。已有技术方案作为必须核查和遵守的约束，具体修改哪些文件、怎样组织实现，则交给 Agent 调查后决定。
| 契约字段 | 本次任务的约定 |
|---|---|
| 用户与结果 | 运营可以在已有页面注册、登录、查看当前用户并登出；失败时能理解提示 |
| 本轮范围 | 认证路由、session 清理路径、已有页面接入、相关测试与启动说明 |
| 明确不做 | 不引入 OAuth、多租户、“记住我”或 JWT 替代方案，不重新设计控制台 |
| 必须保护 | 沿用密码哈希策略与错误响应规范；不覆盖用户已有改动；不访问密钥和生产数据 |
| 自主决定 | 范围内的代码定位、实现细节、测试补充、局部修复和文档整理 |
| 需要人的决定 | 需求冲突、改变保护项、引入本轮未授权的依赖或访问未授权环境 |
| 交付产物 | 代码、必要测试、运行说明、逐项验收证据、未完成与未验证项 |
“遵循现有规范”仍需要事实支持。若调查发现仓库中的实现与契约冲突，Agent 应指出具体冲突和影响；不能一边声称沿用 session，一边静默引入另一套方案。
03.2 把“做完”改写成可观察的验收条件
每条关键要求都有编号。验收描述用户或系统的行为，验证方式说明如何取得证据。测试名称和实现函数可以调整，业务承诺不能在修复时被悄悄放宽。
| 编号 | 可观察的验收条件 | 需要的验证 |
|---|---|---|
| A1 | 合法邮箱可以注册；不合法输入和重复邮箱按现有规范拒绝 | 注册正反向用例、数据结果及错误响应 |
| A2 | 正确凭据可登录并建立会话；错误凭据被拒绝 | 登录正反向用例与会话行为 |
| A3 | 未登录访问 GET /me 返回 401；登录后返回规范允许的当前用户信息 | 未登录与已登录请求、响应字段检查 |
| A4 | 登出后，使用退出前的会话凭据访问 GET /me 返回 401 | 保留原凭据的完整请求链，验证服务端失效 |
| A5 | 按说明可启动；已有页面可完成认证并显示失败提示；相关检查通过；无越界修改 | 按文档启动、浏览器正反向流程、回归检查和 Diff 审阅 |
A4 特别保留“退出前的会话凭据”。只检查页面回到登录页，或只检查浏览器清除了 Cookie，都不足以证明旧会话已经不能使用。验收条件越接近实际风险，Agent 越容易选择有效的检查。
03.3 在启动委托里写清自主推进规则
契约还要回答“做完一步之后怎么办”。阿明给出的委托可以写成下面这样；它是案例中的任务说明，实际使用时要替换为自己的项目入口和已授予权限。
请在现有控制台中完成 Spec v1.0 的认证交付，逐项满足 A1—A5。
先读取项目规则、认证实现与测试，检查工作区并运行可用基线，
再建立实施计划；不要仅给出方案就结束任务。
沿用现行 session、密码封装与错误规范，不扩大本轮范围。
在已授权范围内，自主完成实现、页面接入、验证和局部修复；
普通步骤不必逐项等我确认，也不必等我提醒才运行检查。
若事实可从仓库或授权环境查明，请自行调查。
若需求冲突、必须突破保护项或需要未授予的权限，
保留证据，说明影响和可选方案，再提出需要我决定的问题。
交付时按 A1—A5 报告实际结果，附验证入口和运行说明。
未执行、失败、部分验证和通过分别标注，不用“应该可用”代替证据。这段说明不代替平台权限设置。它约定任务行为，实际可使用的工具、环境和持续执行能力，还要在第 05 章落实。
03.4 调查可以细化计划，改变目标需要更新契约
Agent 查到已有工具函数、发现需要补充某条测试，可以直接调整实施计划。若它发现必须改变密码策略才能继续，就已触及保护项，应先提交冲突。人的决定形成新的契约版本后，再核对哪些任务和证据受影响。
验收失败时，不应为了得到绿灯而降低要求。例如，不能把 A4 从“旧会话失效”改成“登出接口返回成功”。确实需要缩小范围时，应明确记录业务决定，并以新的范围判断交付状态。
04 · Context Engineering：把事实补齐
目标清楚以后，Agent 仍可能在错误前提上实现。阿明提供“沿用 session”的约束，还需要让 Agent 找到当前配置、认证中间件和会话清理路径。Context Engineering 负责让这些依据在需要时可获得，并区分已经确认的事实、待验证的假设和过期记录。
04.1 先提供入口，让 Agent 自主建立事实地图
用户通常知道仓库、业务资料和已知问题，但未必知道全部调用关系。启动时提供正确入口即可；代码检索、配置核对和基线调查由 Agent 承担。它应从适用规则与运行入口出发，沿实际调用关系查到相关实现，而不是只凭文件名猜测用途。
| 事实层 | 从哪里调查 | 本案例要确认什么 |
|---|---|---|
| 任务与业务 | Spec v1.0、验收条件、错误响应约定 | 哪些行为必须成立，哪些决定尚未明确 |
| 实现与依赖 | 启动入口、路由、中间件、session 配置、密码封装 | 请求实际经过哪些模块，哪些能力可以复用 |
| 环境与工作区 | 项目说明、脚本配置、开发依赖、当前分支与差异 | 怎样运行检查，哪些改动原本属于用户 |
| 当前行为 | 已有测试、本地请求、页面流程和失败日志 | 现状是否符合文档，哪些失败在修改前就存在 |
在这个教学案例里，Express + TypeScript 是项目背景。实际仓库的命令必须从当前配置中确认，不能因为语言相同就假定都使用某个测试脚本；本文中的示例也不是本博客静态仓库的执行指令。
04.2 修改前先看基线，避免把原有问题算进本次结果
例如，已有测试显示登出接口成功，并不能说明 A4 已成立。Agent 还要检查测试断言是否覆盖原会话失效。若数据库未启动导致测试无法运行，应记录环境缺口，不能据此判断实现正确或错误。
04.3 给当前任务准备足够且可追溯的上下文
稳定的项目规则可以持续保留，变化中的代码、失败记录和验证结果则要按步骤刷新。处理 T04 时，重点是 A4、会话调用链和原凭据请求记录；与此无关的整段历史聊天会增加噪声。下面的记录把事实和解释分开，便于继续调查。
Context / T04（教学示例）
目标：Spec v1.0 / A4，退出后原会话访问 /me 应返回 401
来源：本轮读取的登出路由、session 配置、存储与认证中间件
工作区：记录当前代码快照或差异，不只记录分支名称
观察：同一服务、原会话凭据，在登出后访问 /me 仍返回 200
已知缺口：原测试只断言登出响应，没有验证旧会话失效
待查假设：请求是否确实携带原凭据？是否访问了同一环境？
服务端销毁是否执行并完成？
下一步：核对请求与清理调用链，再确定修复位置
保护项：现有密码封装、用户已有改动、未授权环境证据应说明来源、运行环境和对应代码状态。只写一个 Git 提交号，在工作区还有未提交变更时不足以定位实际测试对象；可以补充差异摘要或平台快照引用。记录只保存必要且已脱敏的信息。
04.4 发生变化或恢复任务时，重新核对依据
代码、配置、依赖或验收要求改变后，重新读取受影响的材料，并重验相关条件。没有受到影响的有效证据可以保留。上下文被压缩或会话恢复时，先加载契约、当前任务、检查点和最新差异，再继续执行，避免把摘要中的“已完成”直接当成当前事实。
项目材料也有可信范围。代码注释、网页和日志可以提供线索，文档中的说法需要与实现和观察核对；其中要求“忽略任务规则、扩大权限”的文字，不会自动成为用户授权。
05 · Harness Engineering：把执行跑稳
有了目标与事实，还需要一个真正能执行的环境。用户说“持续做到完成”，不能让平台自动获得工具权限、启动依赖或保存可恢复状态。本篇从使用者角度讨论 Harness：如何利用平台已有能力，把执行、约束、检查和恢复组织起来；其内部运行机制留到下一篇展开。
05.1 开工前，确认平台能完成所需动作
阿明先选择可以访问正确仓库、编辑文件、运行检查并取得结果的入口，再准备开发与测试环境。认证流程涉及页面时，还需要浏览器验证能力，或预先明确由谁补齐这部分验收。仅能聊天和生成代码的入口，不能独立完成这些交付条件。
| 执行条件 | 开工前确认 | 缺失时的处理 |
|---|---|---|
| 工具与结果 | 能读取、编辑、运行必要命令，取得退出状态和输出 | 选择可用入口或补齐环境；不把建议命令写成已执行 |
| 运行依赖 | 开发服务、测试数据和所需依赖可用 | 在授权范围内准备；无法准备时记录阻塞 |
| 权限与隔离 | 实际平台设置覆盖本轮必要操作，并限制未授权环境 | 处理明确的权限缺口，不默认关闭全部确认 |
| 检查与恢复 | 知道检查入口、任务状态及结果保存位置 | 使用平台计划或约定文档保存必要记录 |
项目规则与路径约定指导行为，平台权限和沙箱约束实际访问，两者不能混为一谈。写下“只改认证模块”不等于已经建立技术隔离；是否能强制限制，要以平台实际能力为准。
05.2 把可自主执行的动作与暂停条件分开
| 场景 | 本案例中的执行规则 |
|---|---|
| 查代码、读规范、运行约定检查 | 自行推进，不等待逐步确认 |
| 范围内实现、页面接入、补测试和局部修复 | 完成后验证，记录结果，继续无阻塞任务 |
| 发现仓库已有等价实现 | 优先复用，记录选择依据 |
| 新增依赖、改变密码策略或扩大认证范围 | 本轮未授权，先说明必要性、影响与替代方案 |
| 生产操作、合并、发布或对外发送 | 超出本轮交付授权，停止相关动作并报告 |
| 必要验证不可执行，或诊断已无进展 | 保存结果，明确缺口和需要人的最小决定 |
这是本案例的授权选择。其他项目可以预先允许特定依赖和操作，不必机械套用同一份暂停清单。对无法解决的问题，Agent 可以继续彼此独立且仍在授权内的任务，但不能越过缺失依赖，声称被阻塞的步骤已经完成。
05.3 让执行按小步闭合，而不是积累一个大改动
一次任务会话可以包含多个可检查的步骤。每步先确认输入与目标，再修改相关实现、运行对应检查、保存状态，随后推进下一个任务。T03 完成后进入 T04，不应等阿明再次提醒；T04 验证失败后，也应根据第 06 章的规则自行诊断。
本轮执行规则（示例，具体入口由调查确认）
单步输入：任务编号、验收条件、相关事实与前置依赖
单步产物：范围内变更、对应检查、结果记录
推进条件：本步通过条件满足，后续依赖可用
失败处理：保留现场，分类诊断，局部修复或报告阻塞
命令执行：核对工作目录、运行环境与副作用；记录退出状态和必要输出
服务启动：区分“进程已启动”与“接口已可用”，保留停止与清理方式
执行预算：按项目设定单次超时和诊断预算，避免无限重试
工作区保护：不覆盖用户改动，不用整体重置代替局部撤回预算限制用于控制无进展的消耗。遇到同一错误而没有新证据时，先调整诊断路径；有新证据且仍在范围内，可以继续局部修复。不要把“无论失败多少次都不停止”当成可靠执行规则。
05.4 检查点要支持恢复，也要保留变更归属
检查点至少记录契约版本、当前任务、已验证条件、对应变更、失败证据和下一步。T04 修复时应保留 T03 的成果；如果修改共享会话逻辑，就将受影响的登录条件退回待验证，而不是继续沿用旧结论。
检查点 / 进入 T04 前（教学示例）
契约：Spec v1.0
任务：T03 已验证；T04 待执行
证据：A2、A3 的检查记录及对应代码状态
变更：列出本轮修改，并区分原有用户改动
下一步：实现登出，保留原会话凭据验证 A4
恢复时：核对规则、工作区、环境与任务记录
影响判断：共享逻辑或环境变化后，重验受影响条件平台快照、计划记录与可审阅差异都可参与恢复；是否创建 Git 提交，遵循用户与仓库约定。会话或配额中断后，检查点只提供恢复依据，仍需要核对当前实际状态，不能保证平台永不中断。
06 · Loop Engineering：把反馈带回
Harness 让工具能运行，Loop 决定结果如何影响下一步。阿明不想再手动贴出每个错误，就需要提前要求 Agent 对照验收条件观察行为，并把失败转成新的调查或修复任务。多执行几遍相同命令，不会自动形成有效反馈。
06.1 先得到可复现的失败，再判断原因
推演进入 T04：登出接口返回成功，页面也跳回登录页。Agent 按 A4 保留退出前的会话凭据，在同一环境再次访问 GET /me，仍然得到 200。它记录请求顺序、实际响应和预期 401，将本步保留为待修复。
接着，它先核对请求是否确实复用了原凭据、访问的是否为同一服务，再读取认证中间件与 session 存储、销毁调用。测试只断言登出响应成功，是已确认的覆盖缺口；“服务端销毁没有正确完成”则是需要代码与行为共同支持的原因假设。
06.2 让反馈成为可执行的下一轮输入
“登录有问题”不足以安排修复。有效反馈至少包含验收编号、复现条件、预期与实际差距、证据、当前假设和下一步。本案例的记录可以写成：
T04 反馈记录（教学示例，不是平台实测结果）
验收：A4，登出后原凭据访问 /me 应返回 401
复现：登录 → 保存原凭据 → /me → 登出 → 使用原凭据再次 /me
实际：最后一次请求返回 200
证据：请求与响应摘要、环境、对应代码快照或差异
已确认缺口：测试没有检查原会话失效
待查原因：销毁调用是否执行、存储是否更新、响应是否等待清理完成
下一步：核对调用链，补充能暴露当前失败的回归检查
修复验证：先重跑 A4，再回归受共享逻辑影响的 A2、A3
状态：待修复；原因未核实前不预填结论在可复现的环境中，先确认新增检查能捕获当前失败，再做最小修复。修复后既检查原问题，也检查受影响的登录和当前用户流程；不能通过删除断言、改成只检查成功响应来获得绿灯。
06.3 按失败归属回流，避免整模块重新生成
| 失败归属 | 应带回的证据 | 下一步 |
|---|---|---|
| 目标冲突 | 冲突的要求、现行约定与业务影响 | 由人明确取舍，再更新契约与受影响任务 |
| 事实不足 | 缺失的调用关系、当前版本、请求或日志 | 回到 Context 补查，不先猜一套实现 |
| 实现不符 | 可复现失败、对应代码与最小原因假设 | 局部修复并回归，不重写无关模块 |
| 执行环境异常 | 命令、退出状态、环境差异和依赖情况 | 回到 Harness，在授权内恢复条件 |
| 依赖或契约变化 | 变更项、受影响产物与失效证据 | 更新 Graph，重新安排验证 |
| 权限不足或无进展 | 已尝试内容、剩余缺口和可选方案 | 停止相关动作，提出具体待决问题 |
重试的理由应当是出现了新证据、环境已恢复或修复了原因。如果错误没有变化，Agent 应回看诊断假设与验证方法。必要验证始终无法进行时，准确报告阻塞比继续生成更多代码更有用。
06.4 检查证据覆盖范围，区分结果状态
测试进程退出为 0，只说明执行的检查通过。还要核对是否选中了正确用例、是否复用了原会话、是否命中了真实实现；使用模拟存储的单元测试，也不能独自证明真实会话存储已经失效。可用时应结合真实接口探针、页面操作和差异审阅。
| 结果状态 | 应如何表达 |
|---|---|
| 未执行 | 说明未运行的检查和原因，不给通过结论 |
| 失败 | 提供预期、实际结果、复现条件与后续动作 |
| 部分验证 | 明确已经覆盖与尚未覆盖的条件 |
| 通过 | 指向覆盖该要求的证据、环境与对应代码状态 |
单项通过后，Loop 将证据和状态写回任务记录，由 Graph 决定哪些后续节点可继续。只有全部交付条件成立，才进入最终完成状态。
07 · Graph Engineering：把整条交付链串起来
一个步骤通过，不代表它的结论永远有效。T04 如果改动共享会话逻辑，T03 的登录验证可能需要重跑。Graph Engineering 把目标、事实、执行与反馈放进可追溯的关系中，让 Agent 知道当前能做什么、失败影响哪里，以及还缺哪些完成证据。
07.1 任务清单之外，还要记录依赖与影响
清单能告诉 Agent“还有登出没做”，依赖关系进一步说明“验证登出前需要有效登录会话”，影响关系说明“改变会话清理路径后需要重验哪些身份行为”。因此，任务节点不仅要有名称，还要有输入、产物、通过条件和失败出口。
| 关系 | 回答的问题 | 认证项目示例 |
|---|---|---|
| 验收关联 | 这一步服务哪条业务承诺？ | T04 对应 A4，不只对应“增加登出路由” |
| 事实依据 | 选择实现方式的依据是什么？ | 沿用当前 session，引用现行配置与调用链 |
| 前置依赖 | 开始前必须具备什么？ | T04 需要已验证的登录与原会话凭据 |
| 结果证据 | 用什么确认通过，适用于哪版代码？ | 原凭据登出后访问 /me 的响应与运行记录 |
| 回流与影响 | 失败回哪里，变更会让哪些结果失效？ | 会话逻辑改变后，将相关 A2、A3 退回待验证 |
07.2 调查之后建立任务图，执行中持续修订
Agent 应在调查后建立这张图，而不是凭空先写死所有步骤。发现新的依赖或验证条件时，更新计划并记录原因；可以自主调整实施顺序，但不能借调整计划改变任务范围和验收承诺。
07.3 将每条要求关联到任务与最新证据
| 验收目标 | 事实与执行节点 | 应取得的证据 |
|---|---|---|
| A1：注册与输入边界 | 用户模型、密码封装、错误规范 → T02 | 注册正反向行为、重复邮箱与错误响应 |
| A2、A3：登录与身份边界 | session 配置、认证中间件 → T03 | 正确与错误凭据、未登录与已登录 /me 响应 |
| A4：原会话失效 | 销毁调用、存储、失败记录 → T04 | 保留原凭据的登出后 401 复测 |
| A5：可运行、可使用、可交接 | 启动配置、页面接入、最终差异 → T05、T06 | 相关回归、按文档启动、浏览器流程与差异审阅 |
T05 的功能回归通过后，T06 还要整理说明并按说明运行应用，检查页面流程，再核对所有验收。若这里发现配置或页面问题，就回到对应节点修复并重跑受影响检查。完成报告应引用这些最终证据，不能提前预填通过。
T04 节点记录（教学示例）
目标：Spec v1.0 / A4
输入依据：当前 session 代码、原会话请求链、失败记录
前置条件：T03 登录与当前用户路径已验证，测试环境可用
产物：会话清理修复、原凭据失效的回归检查
通过条件：A4 已覆盖，且受影响的身份行为完成回归
当前状态：待验证
证据引用：填写实际运行记录、环境和对应代码状态
影响规则：共享会话逻辑变化 → A2、A3 待验证
失败出口：补查事实 / 局部修复 / 等待必要决定07.4 在现有平台维护关系，不必先引入编排框架
内置计划可以承载任务和状态；项目允许时，可以用文档保存契约、事实和证据。文件名由项目约定，下面只是示例目录，不是平台自动识别的协议，也不要求每次任务都创建五份文件。
delivery/
spec.md # 目标、范围、验收与授权
facts.md # 事实来源、基线、假设与缺口
plan.md # 任务依赖、当前状态、失败出口
evidence.md # 检查结果、环境及对应代码状态
report.md # 逐项交付结果、运行方法与剩余问题
状态推进：待执行 → 执行中 → 待验证 → 已验证
失败回流：待验证 → 执行中，或记录阻塞与所需条件
变更影响：已验证 → 待验证（只回退受影响的条件）任务较小时，一份记录也可以表达这些关系；任务变复杂时，再细化节点和证据引用。恢复执行时，先核对契约版本、工作区、环境与未完成节点，确认哪些旧结果仍有效，再选择前置条件满足的任务继续。
07.5 用验收覆盖判断完成，而不只统计任务数量
所有节点都打勾，仍可能遗漏一条没有分配任务的要求。交付前要反向检查：A1—A5 是否都有关联产物与有效证据？失败是否已经处理或明确保留？共享逻辑变化后，旧结论是否已重验？运行与交接是否实际执行？
若关键节点阻塞，或某项只有代码没有必要验证，任务只能报告部分完成或阻塞。Graph 让这些缺口可见；是否已经满足承诺，最终仍由对应行为和证据判断。
08 · 交付现场：一次委托如何推进到项目验收
前五章分别讨论了方法，现在回到阿明的认证任务，把它们放进同一段执行过程。本章延续教学推演：展示每个阶段如何推进、证据如何交接，以及什么时候确实需要人介入，不作为任何平台的实测记录。
08.1 开始前，阿明只做必要的准备与决定
阿明明确本轮交付范围，准备可访问的仓库和开发环境，给出 Spec v1.0、A1—A5、规范入口与已知问题。他保留第一版差异，将新一轮工作安排在隔离分支上，并确认平台能使用必要工具。原有工作区和用户改动需要保护，生产发布不在本轮授权内。
他没有预先指定所有文件和命令，而是要求 Agent 调查后建立计划，在范围内持续实现、验证和修复。任务计划和关键结果保存到双方约定的位置；遇到业务冲突或权限缺口时，提出有证据、可决定的问题。
08.2 从调查到交接，每个阶段都有推进条件
| 阶段 | Agent 实际要做的工作 | 继续推进的依据 |
|---|---|---|
| T01 现状与基线 | 读取规则、工作区、会话与密码实现；确认运行入口；记录可用基线及缺口 | 知道本轮边界、已有问题和可执行条件 |
| 计划建立 | 将 A1—A5 关联到 T02—T06，确认测试账号、前置依赖和回流出口 | 每项要求有任务承接，当前节点的输入可获得 |
| T02、T03 功能实现 | 复用现有封装，补齐注册、登录、当前用户及相关页面接入 | 对应正反向行为已验证，变更范围可审阅 |
| T04 登出闭环 | 验证原会话失效，发现失败后调查、补检查、修复并重验身份行为 | A4 有有效证据，共享逻辑影响已经回归 |
| T05 集成检查 | 检查完整认证链、相关回归、响应字段和最终差异 | 功能条件成立，没有未经解释的越界修改 |
| T06 运行与交接 | 整理说明，按说明启动并走通页面流程，核对全部验收与证据 | A1—A5 均有实际结果，剩余问题被准确披露 |
这些阶段的进展可以对人可见，但不必变成等待确认的关卡。T03 通过后，Agent 可以直接进入前置条件满足的 T04；T04 出现范围内问题，就自行回流。只有推进需要新的业务决定或授权时，才暂停相关动作。
08.3 登出失败时，任务如何不再依赖阿明催促
推演中的转折仍是那条请求链：页面已经退出，原会话访问 GET /me 却返回 200。Agent 将 T04 保持为待修复，补上能捕获问题的检查，核对会话销毁路径并局部修改。随后重验 A4，以及共享逻辑影响的 A2、A3。阿明无需再次输入“请修登出”“请跑测试”。
如果这些条件都满足，任务继续进入 T05、T06；如果测试存储始终无法访问，就保留已完成的代码与检查记录，将 A4 标为未验证，并说明缺少什么环境条件。此时可以继续独立的文档工作，但不能把认证交付标为完成。
真正需要人的问题也应具体。例如：“当前授权只允许本地环境，但本地缺少可用会话存储，A4 暂时无法验证。可以提供本地测试配置，或授权现有测试环境；你选择哪一种？”它说明事实、影响和选项，比只说“遇到问题，请指示”更容易推动任务。
08.4 最终报告让结果可以审查，也可以接手
下面是报告格式，方括号必须用实际结果填写。教学案例不预填“全部通过”；真实运行中，单项结论需要指向对应代码状态、环境和验证记录。
任务：内部控制台认证交付 / Spec v1.0
整体状态：[DELIVERED / PARTIAL / BLOCKED，按下述条件选择]
逐项验收：
A1 注册、输入边界及重复邮箱：[结果、证据引用]
A2 正确和错误凭据登录：[结果、证据引用]
A3 未登录 /me = 401，登录后返回允许字段：[结果、证据引用]
A4 登出后使用原会话凭据 /me = 401：[结果、请求链证据]
A5 按说明启动、页面正反向流程、相关回归与范围：[结果、证据引用]
变更清单：文件、用途、对应要求，区分原有用户改动
验证记录：实际命令或操作、退出状态、必要输出、环境、代码状态
失败修复：原现象、原因依据、修复内容、重新验证的条件
运行交接：配置示例、启动与检查方法、服务停止及清理方式
剩余事项：未完成、未验证、已知限制，以及下一步需要什么
本轮授权：交付到何处；合并、发布等后续动作是否已获授权| 整体状态 | 使用条件 |
|---|---|
| DELIVERED：完成 | 全部约定条件成立，证据有效，运行与交接可用 |
| PARTIAL：部分完成 | 已有可交接成果，但仍有未完成或未验证项；逐项说明范围 |
| BLOCKED：阻塞 | 关键路径缺少必要条件，无法继续；报告已有成果、缺口和解除方式 |
整体状态用于概括任务，不替代逐项结果。BLOCKED 也可能已经完成部分工作；有一个关键条件未验证，就不能因为其他测试通过而选择 DELIVERED。
08.5 阿明在最后审查什么
交付时，阿明首先看 A1—A5 的证据是否覆盖承诺，再看差异是否符合范围，最后按说明确认接手方式。对关键行为，他可以抽查原会话失效的请求链；对未验证项，则决定补齐条件、明确调整范围，或暂不接受本轮交付。
在推演的成功路径中，阿明拿到的是可核对的变更、运行方法和验证记录。他减少了中途调度，没有省掉业务判断与最终审查。是否合并和发布，按实际授权继续处理。
09 · 平台适配：先检查能力，再选择运行方式
Claude Code、Codex、Cursor Agent、CodeBuddy、Qwen Code、Kimi Code，以及 OpenClaw 等不同形态的平台，都可能成为任务入口。具体能承担哪些工作，取决于当前入口、版本、配置和已连接工具。选择时应以本次交付需要的能力为准，不能仅凭产品名称推断能否持续执行。
09.1 先从验收要求反推所需能力
认证案例需要代码访问、修改、终端和接口检查，A5 还需要页面验证。换成数据报告项目，可能需要文件处理与图表导出。先列清楚必须观察到的结果，再确认选定入口能否产生这些结果及其证据。
| 要检查的能力 | 开工前怎样确认 | 缺失时怎样处理 |
|---|---|---|
| 项目与规则访问 | 能读正确工作目录、适用规则和当前差异 | 补齐路径与访问条件，避免只凭上传摘要推断现状 |
| 编辑与工具执行 | 能修改授权文件、执行必要操作，取得退出状态与输出 | 切换合适入口或补齐执行工具 |
| 验证覆盖 | 接口、测试、浏览器等工具能覆盖所有关键验收 | 补验证环境或安排人工验证，保留完成前的缺口 |
| 连续推进 | 能从读取、执行推进到检查与后续动作 | 按实际运行边界组织任务，不用长提示词假装具备能力 |
| 权限与环境 | 必要动作已授权，工作区与访问环境有明确边界 | 处理具体缺口，保留未授权动作的人工出口 |
| 状态与恢复 | 知道任务记录保存在哪里，中断后能够重新读取 | 使用平台计划或约定文档，恢复前核对现状 |
09.2 运行位置影响工作方式，不直接决定交付质量
| 入口形态 | 特别需要确认 |
|---|---|
| 编辑器或 IDE 内 | 工作区范围、终端和浏览器能力、变更审阅方式，以及是否每步等待用户动作 |
| 终端或本地任务入口 | 工作目录、命令权限、依赖与服务生命周期、任务中断后的结果保存 |
| 远程任务或带外部工具的入口 | 代码同步、环境差异、网络与数据访问、产物导出，以及本地如何复核 |
这些是使用形态，不是对上述产品的固定分类。同一产品也可能提供多个入口。若要离开界面后继续执行，还必须确认平台支持相应运行方式及结果保存；本文的任务规则不会自行创建后台运行能力。
09.3 将稳定规则、当次目标与运行状态分别放好
第 05 章约定执行行为，本章负责确认平台能承载这些约定。稳定的代码规范、保护项和检查方法，放到当前平台确实会加载的项目规则入口；本次范围与验收条件，放到启动委托；任务进展、失败与证据，放到可恢复的任务记录。
不要假设所有平台读取相同文件。开工时可以要求 Agent 列出实际读取的适用规则及入口，并核对是否与当前工作目录一致。用一份明确维护的规则作为依据，比把同一段要求复制到多处后任其过期更容易管理。
09.4 先做小型演练，暴露当前环境的缺口
在正式实现前，请完成一次执行链检查：
1. 确认当前工作目录、实际读取的项目规则与已有用户改动。
2. 定位一个相关模块和已有检查入口，说明为什么与本任务有关。
3. 在已授权环境运行该检查，记录实际结果；失败则先判断归属。
4. 将必要记录保存到预先允许的位置，说明后续能否自主推进。
不要为了演练修改业务代码，也不要扩大权限或安装未授权依赖。演练能提前发现目录错误、命令不可用、结果无法取得或状态没有保存位置等问题。它只能验证当前执行链，不能证明后续业务一定交付成功。具体菜单、参数和权限选项，应以当前平台文档与实际界面为准。
10 · 启动模板：把五种 Engineering 放进一次委托
下面把方法整理成可填写的启动委托。它用于范围明确、事实可调查、验收可执行的项目任务。先完成平台与环境准备，再使用模板；模板约定如何工作，不授予实际工具权限，也不保证平台永不中断。
10.1 先填业务决定，技术事实允许 Agent 调查
用户需要明确谁使用、交付什么、明确不做什么、哪些结果必须成立，以及允许哪些操作。文件路径、调用关系和具体检查命令，如果尚不确定，可以写“请从仓库调查确认”，无需凭印象填一个看似准确的答案。
业务上的空白不能同样处理。例如，“自行决定是否支持多租户”会把范围选择重新交给 Agent。发出任务前先定清这种承诺；确实需要探索时，可以将本轮目标改为调查与方案交付，并采用对应的验收条件。
10.2 可复制的完整启动委托
请完成以下项目交付任务。在约定范围与实际授权内持续推进，
普通步骤不必逐项等待确认。不要仅给出方案或完成代码生成就结束。
【目标与验收 / Prompt】
用户与使用场景：[填写]
本次交付范围：[填写]
明确不做：[填写]
必须保护的现行行为与已有工作：[填写]
验收条件：
A1：[可观察的行为，以及怎样验证]
A2：[继续补充；覆盖失败路径与交接要求]
交付物：代码或业务产物、必要检查、运行说明、证据与剩余事项。
自主决策范围：[填写]
需要人决定或未授权的动作：[填写]
【事实入口 / Context】
项目位置与资料入口：[填写]
已知问题、既有改动及环境情况：[填写]
请读取适用规则、现行实现、配置与检查入口，核对工作区，
运行可用基线，区分原有失败与本轮影响。
事实可自行查明时继续调查；未知业务决定与技术假设分别列出。
记录来源、环境和对应代码状态，变更后刷新受影响依据。
【执行条件 / Harness】
允许的文件、工具与环境：[填写实际授权]
未授权动作和保护项：[填写]
检查点与结果保存位置：[填写平台计划或允许的目录]
单次执行超时、资源或诊断预算：[按项目填写]
具体命令未知时，从当前项目配置中确认，不编造执行结果。
按可检查步骤推进，保护已有用户改动，管理启动的服务与临时产物。
权限或必要环境不足时保留现场，提出具体缺口。
【反馈处理 / Loop】
每个关键步骤都对照验收检查，记录预期、实际结果和证据。
失败时先核实复现与原因，补必要检查，再局部修复并回归。
事实不足则补查，环境异常则在授权内恢复，需求冲突则交回决定。
同一失败没有新证据时调整诊断路径，不无限重复相同动作。
分别标注未执行、失败、部分验证与通过，不放宽验收来获得绿灯。
【任务关联 / Graph】
调查后建立任务节点、前置依赖、验收映射和失败出口。
记录当前状态、依据、产物与证据，推进前置条件满足的任务。
变更影响已验证结果时，将相关条件退回待验证。
恢复时核对契约、工作区与环境，不直接沿用过期完成状态。
【最终交付】
对照每条验收提交实际结果与证据，列出变更、使用方法和限制。
检查运行说明是否可执行，相关变更是否已经回归。
说明未完成、未验证、失败修复及需要人的后续决定。
全部约定条件成立才标记完成，否则准确报告部分完成或阻塞。10.3 在认证案例里，关键字段应该填到什么程度
阿明不需要再次写一套抽象要求。可以将第 03 章 Spec v1.0 与 A1—A5 作为本轮契约，填入实际仓库和规范入口，再把授权与记录位置补全。下面是填写要点，不能将未替换的说明直接当成真实环境信息。
| 字段 | 认证项目中的填写要点 |
|---|---|
| 范围与不做 | 已有控制台认证接口、页面接入与交接；不引入新会话方案或本期无关功能 |
| 验收 | 引用并附上 A1—A5，尤其写清原会话失效、页面错误提示与按文档启动 |
| 事实入口 | 实际仓库、项目规则与团队资料；未知实现与命令由 Agent 调查 |
| 授权 | 本地开发与测试的具体边界；本案例未授权生产、发布及新增依赖 |
| 恢复与结果 | 平台确实可读取的任务记录位置、适用预算，以及逐项报告格式 |
任务越小，记录可以越简洁，但目标、执行边界和完成证据仍要明确。没有必要为了形式完整，把同一条约定反复粘贴到多个位置。
10.4 发出前自检，中断后按状态恢复
- 每条关键要求是否可以观察或验证，失败路径是否覆盖？
- 资料、项目与必要环境是否可访问，实际工具权限是否满足？
- Agent 是否知道哪些动作自主推进，哪些问题需要人的决定？
- 任务与证据是否有明确保存位置，未验证项是否允许准确披露？
- 最终接手的人能否根据交付物复核和使用结果？
如果平台中断，恢复信息应指向已保存的状态，并要求重新核对。可以使用下面的短委托，无需把整段旧聊天再次粘贴进去：
请读取本任务的契约、计划、检查点与最新证据记录。
先核对当前工作区、适用规则和运行环境，判断旧证据是否仍有效。
从前置条件满足的未完成任务继续，在原授权内推进到验收或明确阻塞。
不要重做已确认且未受影响的工作，不覆盖已有用户改动。
若契约或授权有变化，先说明冲突和需要的决定。11 · 结语：从反复指挥，到一次完整委托
11.1 人的工作从逐步调度，转向目标与结果
回到开篇，阿明不想再当“下一步按钮”，并不是因为他不愿意审查代码，而是因为提醒范围、催促测试、重复解释现状，本来可以由任务规则、事实记录和检查机制承担。完成这些准备后，他可以把注意力放回业务目标、必要授权和最终证据。
Agent 承担的则是一条连续工作链：理解契约，调查项目，安排任务，实现并验证，处理范围内失败，最后交接结果。人是否中途输入了“继续”，不再是判断工作是否推进的依据；每项承诺是否成立，才是判断交付的依据。
11.2 “一次对话”追求的是减少接力，而非掩盖限制
本文讨论的是一次初始委托后的完整任务会话。它适合范围清楚、环境可用、验收可执行的工作，也允许在真实阻塞时准确暂停。对于业务尚未确定、需要跨团队取舍的项目，可以先委托调查或方案任务，形成清楚的决定后再进入实现交付。
平台的工具、会话和配额仍有实际边界。检查点让恢复有据可依，反馈记录让失败可以继续处理，验收映射让遗漏更容易暴露；这些机制提高任务的可控程度，不构成对任意项目自动成功的承诺。
11.3 下一次任务，从一份能验收的委托开始
选择一个你能判断结果的实际任务，先写清用户、范围与验收，确认平台条件，再让 Agent 在授权内推进。交付后回看：哪些地方仍需要你反复提醒？是目标不清、事实缺失、执行条件不足，还是反馈没有回流、任务关系没有维护？把发现的问题补到相应约定中，再用于后续任务。
Prompt 把目标说清楚，Context 把事实补齐，Harness 把执行跑稳，Loop 把反馈带回，Graph 把目标、事实、执行和反馈串起来。它们最终要支撑的，是一份范围明确、结果可验证、他人能接手的交付。
本篇回答“我如何使用现有平台交付项目”。下一篇02 · Agent 平台原理：理解一次交付如何发生继续解释：平台怎样通过工具、状态、验证与恢复支撑这样的执行过程。后续文章再进入通用 Agent 平台、数字员工平台与办公工作台的设计问题。