01 · 开篇：发出委托以后，平台里发生了什么
阿明把任务发出去后，没有再补一句“继续”。界面里陆续出现了读文件、修改代码和运行检查的记录。任务似乎一直在前进，但他开始关心另一件事：这些动作为什么会发生？平台怎样知道下一步该做什么，又凭什么判断可以结束？
01.1 从一次完整委托开始
这个项目是一个已有的管理后台，使用 Express、TypeScript 和 Session。阿明要补齐注册、登录、当前用户查询和退出功能，还要接入已有页面，补上测试与运行说明。完成的标准是别人能够运行、检查和接手这次变更。
这里的 Session 是服务端保存的登录状态；浏览器通过 Cookie 携带会话标识。GET /me 用来查询当前用户：本案例约定未登录或会话失效时返回 401，已登录时返回允许公开的用户字段。清除浏览器 Cookie 与使服务端会话失效，是两个不同动作。
在上一篇中，他已经学会把目标、事实入口、执行规则和验收条件放进委托。这一次，交给平台的任务可以简化为：
先阅读现有项目，沿用当前 Session、密码处理与错误响应约定，补齐认证流程及页面接入。自主完成必要的调查、修改、验证和修复；交付时说明变更、运行方式与验收证据。遇到无法自行补齐的业务决定或授权缺口，保存进度并说明阻塞。
这段委托给出了推进任务的依据。真正让项目发生变化，还需要平台持续取得当前事实、执行工具并检查结果。于是，本文把视角从“阿明怎样委托”，移到“委托之后平台怎样运行”。
下文用 A1–A5 表示验收：A1 注册，A2 登录，A3 当前用户与匿名访问，A4 退出后旧凭据失效，A5 页面、运行说明和变更范围；用 T01–T06 表示工作节点。A 是承诺检查的结果，T 是为满足承诺安排的工作，两者不能混用。
01.2 一个返回 200 的退出接口，为什么还没完成
任务推进到退出功能时，平台运行了一条请求链：先登录取得会话凭据，再调用退出接口，最后带着原来的凭据访问 GET /me。退出接口返回了 200，最后一个请求却也返回了 200。
| 检查动作 | 案例中的观察 | 能得出什么结论 |
|---|---|---|
| 登录并取得会话凭据 | 可访问当前用户接口 | 测试所需的登录状态已建立 |
| 调用退出接口 | 返回 200 | 接口给出了成功响应，仍需检查会话效果 |
| 携带原凭据再次请求 /me | 仍返回 200，预期为 401 | 旧凭据仍能访问受保护接口，退出验收未通过 |
如果平台只看退出接口的响应，就可能把这一项打勾。完整的检查则暴露了差距：本案例约定退出后旧凭据应失效，后文把这条验收记为 A4。
读者已经知道本故事设定的缺陷，但执行中的 Agent 此刻只看见 200。它仍需核对环境、原凭据和清理调用，取得证据后才能定位原因。后文会展示它如何走到“清了 Cookie，却没销毁 Session”的结论，以及怎样验证修复。
01.3 一次对话，内部包含多次模型与工具往返
阿明没有为上述每一步发送新消息。运行系统根据任务与当前状态，反复组织输入、调用模型、校验动作、执行工具、记录观察，再选择继续、修复、等待或交付。这解释了为什么一次初始委托可以支撑较长的任务过程。
| 参与者 | 在退出问题中承担什么职责 |
|---|---|
| 模型 | 理解验收、分析已有观察，提出调查方向和修改建议 |
| 工具与外部环境 | 读取实际代码、写入补丁、执行请求和测试，产生真实结果 |
| 运行系统 | 组织上下文，管理调用、权限、预算和任务状态，衔接验证与恢复 |
模型生成“已修复”只是一项陈述。工具需要实际执行，验收需要对应证据，任务状态也需要据此更新。因此，“一次对话完成项目”指一次连续任务会话，其中可以包含多轮模型调用、工具执行与失败修复。
这种连续性依赖具体平台的运行条件。工具权限不足、环境不可用或业务规则存在歧义时，合理的结果是保存进度并等待必要条件；关闭窗口后能否继续，也取决于平台如何部署和保存任务。
01.4 带着三个问题，进入九项理论
接下来的内容围绕三个问题展开：
- 判断从哪里来？LLM 依据什么理解目标，当前代码和工具结果怎样进入上下文？
- 任务怎样往前走？工具调用、ReAct、规划执行与按需分工，怎样把长任务变成可推进的工作？
- 结果怎样值得信任？验证、Harness、动态路由与持续演进，怎样处理失败、恢复执行，并减少下一次的同类错误？
02 · 总览：一次交付需要哪些能力共同工作
阿明的认证任务看起来是一张功能清单，实际包含几类不同问题：模型要理解目标，工具要取得事实并修改代码，计划要安排先后，验证要判断行为是否达标，中断时还要知道从哪里恢复。九项理论分别解释这些问题怎样被处理。
02.1 先分清模型、工具与运行系统的职责
LLM 是参与判断的内核。面对“退出后旧凭据仍然有效”，它可以分析观察、提出调查方向、生成代码修改建议。工具与环境产生实际结果：文件有没有被修改，请求返回什么，测试是否通过，都需要真实执行。
运行系统把两者接起来：为本轮调用选择上下文，检查动作与权限，调度工具，保存任务状态，组织验证，再决定继续、等待还是交付。这些职责可能放在客户端、服务端或不同组件中，不要求每个平台采用相同实现。
这张时间线说明故事先后，下一张运行图说明任意一个节点内部怎样往返。03–11 按理论组织，因此会从不同侧面回看同一事件；例如 07 解释修复如何验收，09 再还原验收前的中断恢复。章节顺序不代表任务要重新执行一次。
02.2 九项理论分别回答什么问题
| 理论与后文章节 | 通俗问题 | 认证案例中的落点 |
|---|---|---|
| 03 · LLM 基础 | 模型能判断什么，哪些事实必须另外取得 | 知道常见认证方案，仍要读取项目使用的 Session |
| 04 · 工具调用 | 模型提出的动作怎样真正发生 | 读取代码、写入补丁、执行请求和测试 |
| 05 · ReAct | 出现意外后，怎样依据现场决定下一步 | 发现旧凭据仍可访问，继续核对环境与清理调用 |
| 06 · 规划执行 | 长任务怎样拆解，先做什么、后做什么 | 组织注册、登录、退出、联调、回归和交付说明 |
| 07 · 反思校验 | 怎样发现遗漏和假完成 | 退出响应成功后，继续检查旧凭据是否失效 |
| 08 · 多 Agent | 什么时候值得分工，结果由谁汇总 | 按需分开接口实现与页面审阅，再统一验收 |
| 09 · Harness | 谁维持整段执行，失败或中断怎样恢复 | 保存状态，管理权限、进程、预算和检查点 |
| 10 · 动态路由 | 当前问题应该交给哪个模型、工具或人工路径 | 读取代码与生产写入采用不同处理条件 |
| 11 · 持续演进 | 怎样减少下一次的同类失败 | 把旧会话失效纳入回归用例和评测集 |
这些理论存在不同作用范围。ReAct 处理局部的观察与行动；规划执行组织整个任务；Harness 支撑全程；持续演进通常跨越多次任务。多 Agent 属于可选协作方式，简单任务可以由一个 Agent 完成。
在平台界面中，这些能力可能表现为项目规则、文件搜索、终端调用、任务计划、检查结果、子任务、运行日志或恢复入口。名称和可用程度因产品而异。理解时应检查入口背后的行为：读到了什么、执行了什么、状态怎样变了，而不是仅凭一个按钮推断实现。
02.3 五种 Engineering 与九项理论怎样对应
上一篇从使用者的角度讲五种 Engineering：怎样把目标、事实、规则和验收交给平台。本篇进一步解释平台内部怎样承载它们。两组概念是同一次交付的不同视角，存在交叉关系。
| 01 的使用方法 | 02 对应的机制 | 认证案例 |
|---|---|---|
| Prompt 把目标说清楚 | 模型理解输入，规划关联验收 | A4 成为持续检查的目标 |
| Context 把事实补齐 | 工具取得事实，上下文选择、检索与刷新 | 现行 Session 和最新请求结果进入判断 |
| Harness 把执行跑稳 | 执行框架、权限、预算、恢复与协作管理 | 工具能运行，中断后有条件续跑 |
| Loop 把反馈带回 | ReAct、反思校验；跨任务时再进入持续演进 | 失败触发调查、修复、重验和用例沉淀 |
| Graph 串起交付链 | 任务依赖、状态、验收与证据的关联 | Session 变更影响哪些登录条件，需要重新验证 |
Context 会贯穿模型输入、工具结果和恢复过程；Graph 会贯穿规划、分工、验证和状态变化。它们在本篇中继续存在，融入相关机制，不是额外排在九项理论之后的步骤。
02.4 学习可以按章推进，执行需要反复往返
后文按照从模型能力到运行和改进的顺序展开，实际任务不会把九项理论各运行一次就结束。一次模型调用可能同时涉及上下文、规划和工具选择；工具失败要先区分参数、环境或执行问题；业务验证失败则回到调查或修复。
如果旧凭据仍返回 200，就记录 A4 失败并继续调查；如果 Session 变更影响登录路径，就重新核对相关验收；如果缺少必须的业务决定，就保存进度并等待。工具已结束、任务已结束和业务已完成，需要分别表达。
02.5 用三个问题检查交付链有没有接上
理解一个平台时，可以持续追问：当前判断依据什么事实？建议的动作是否真的执行？完成结论对应什么验收证据？这三个问题分别帮助定位上下文、执行和验证上的缺口。
后文每项理论都会回到阿明的任务，解释某一段怎样工作、可能怎样失败，以及它与其他机制怎样配合。读完后，应当能沿着任务记录还原一次交付，而不只是记住九个名称。
03 · LLM 基础：模型能判断什么，不能凭空知道什么
任务刚建立，模型还没有读取仓库。阿明写了“沿用现有认证”，但这句话不能替代代码事实。平台把仓库规则、Session 配置和现有路由装入上下文后，模型才能提出复用方案。此时发挥作用的是模型理解能力与事实装载能力。
03.1 模型根据输入生成判断，流畅表达不等于事实正确
语言模型把文本、代码等输入表示为 Token，结合训练中学到的模式生成后续内容。指令训练让它能够遵循要求、解释问题、生成代码或提出结构化动作请求；具体推理能力和工具支持因模型而异。生成过程可以帮助解决复杂问题，但不会自动获得仓库、终端或数据库的访问能力。
它可能知道 Session 和 JWT 的常见做法，却不知道阿明的项目已经使用哪种会话中间件，也不知道当前测试是否通过。即使回答写得笃定，仍可能引用不存在的函数、过期接口或不适用的约定。判断的可信程度，需要与当前材料和外部验证一起看。
03.2 Prompt 说明任务，Context 提供本轮判断依据
Prompt 用来表达目标、约束和期望输出；Context 是模型本轮实际收到的输入集合，其中也包括 Prompt、项目规则、代码、计划、历史摘要和工具结果。两者有重叠，并不是两个互不相关的容器。
教学输入片段：
目标：补齐认证流程，沿用现有约定
约束：当前项目使用 Session，不另起一套 JWT
当前节点：T04 退出与旧凭据失效
验收 A4：退出后原凭据访问 GET /me 应为 401
观察：同一请求链中实际返回 200
相关材料：退出路由、Session 配置、请求记录引用
待确认：凭据、运行环境与清理调用是否一致“返回 200”是观察，“可能没有销毁会话”是假设，“当前使用 Session”应有代码来源。把它们混写成一个结论，会使模型把未证实的原因当成事实。平台需要给材料保留来源、代码状态和适用环境。
本案例用 R0 表示任务开始时的基线，R1 表示注册、登录等工作推进后首次复现退出缺陷的代码，R2 表示退出修复后的代码，R3 表示集成并补齐运行说明后的最终交付版本。它们只是教学版本标签。平台需要绑定的是具体代码状态，而不是笼统的“最新版本”。上面的输入片段截取自 R1 的 T04；同一任务在 T01 时尚没有这条失败观察。
03.3 上下文、检索与记忆承担不同职责
| 信息来源 | 在任务中的用途 | 使用边界 |
|---|---|---|
| 模型训练知识 | 解释认证模式、提出实现和排查候选 | 不直接证明当前项目状态 |
| 项目文件与工具结果 | 取得当前实现和实际行为 | 核对分支、环境、时间和调用关系 |
| 检索 / RAG | 按问题查找相关资料，再放入本轮上下文 | 命中材料仍可能过期或不适用 |
| 持久化记忆与任务状态 | 保存约定、进度、失败及证据入口 | 恢复后重新核对，不自动成为当前事实 |
| 本轮上下文 | 把以上材料组织为一次决策输入 | 容量有限，重要材料也可能被忽略 |
RAG 可以理解为“先查资料再回答”。查到一篇 Session 文章，不等于已经查明仓库的退出实现。检索结果是调查入口；项目内旧文档与外部页面中的文字，也不会因此获得覆盖任务规则或改变授权的资格。
03.4 长任务需要选择、压缩和刷新上下文
上下文窗口按 Token 计量，输入与输出预算的具体分配取决于模型和接口。容量更大有助于容纳材料，但把整个仓库塞进去并不会保证判断更好，还可能增加成本、延迟和噪声。处理 T04 时，应优先带入 A4、退出路由、Session 配置和最新请求链；页面样式规则可以在联调时再取。
历史太长时，平台可能截断或压缩内容。摘要应保留当前目标、关键约束、未完成节点、已知失败和证据入口，而不只写“前面都完成了”。代码或环境变化后，旧测试结论需要按影响范围重新验证。记忆帮助找到线索，刷新事实才能安全继续。
03.5 模型选择要服务于问题，并接受外部检验
读取文件、格式化代码等确定动作适合直接交给工具；跨模块诊断可能需要更强的模型、更完整的材料或更多调用预算。模型参数、推理预算和生成设置可以影响质量、成本与时延，但固定设置也不能保证输出永远正确或完全相同。
模型提出 JWT 时，应先检查上下文是否遗漏 Session 事实；测试失败时，应先分辨是环境、调用还是实现问题。确认输入和执行链没有缺口后，再比较模型能力。下一章沿着这个边界，解释动作请求如何变成真正的执行。
04 · 工具调用：模型的建议怎样变成真实动作
进入 T04，模型提出“检查退出实现并运行原凭据请求链”。平台先用读取工具取得代码，再调用测试执行器。调用结束后带回“退出为 200，旧凭据请求 /me 仍为 200”。工具调用这一章，解释建议怎样变成动作，以及结果怎样重新进入判断。
04.1 工具定义说明能做什么、怎样调用和返回什么
一个工具通常有名称、用途、参数结构和返回约定。模型根据这些描述选择候选动作并生成参数，运行系统再解析和执行。函数调用是一种结构化请求方式；执行器背后可以连接本地函数、命令行或远端 API。不同接口形式不改变职责边界。
教学工具定义，非平台真实接口：
名称：read_project_file
用途：读取授权项目内的文本文件
输入：{ "path": "src/auth/session.ts" }
参数约定：path 必填，类型为字符串
执行约束：限制到授权工作区，禁止越界路径
成功结果：内容、文件版本引用、必要截断标记
失败结果：错误类型、原因、是否可重试描述过于宽泛时，模型可能选错工具；参数结构不明确时，可能传错路径或缺少字段。工具定义应让模型知道适用场景，执行器则真正落实访问限制。仅在提示中写“不要越界”无法替代权限检查。
04.2 从动作请求到结果回填，中间有执行边界
请求需要关联到任务、节点和本次调用，便于回答“哪个动作产生了哪条结果”。执行前检查参数、授权、目标环境和资源；执行后保存状态、输出和产物引用，再把与当前判断有关的结果放回上下文。某些确定步骤可以由系统直接调度，不必全部经过模型选择。
测试等长进程要区分已提交、运行中、已结束、超时和取消。拿到进程标识只能说明它已启动，不能立刻报告测试通过。结果被截断时，应保留关键错误和完整记录入口。
在 R1 上，请求工具实际执行“登录取得原凭据 → 退出 → 携原凭据访问 /me”。若界面显示调用已结束，它只说明工具结束；断言失败仍要返回 T04。这就是终端或测试工具与任务进度联动的具体方式。
04.3 工具成功与业务通过需要分层表达
| 观察到的状态 | 已确认 | 尚未确认 |
|---|---|---|
| 请求被接收 | 接口接受参数或动作已排队 | 动作已完成 |
| 补丁应用成功 | 指定工作区发生写入 | 代码语义正确、没有回归 |
| 测试退出为 0 | 本次实际运行的检查通过 | 需求被充分覆盖 |
| 退出接口返回 200 | 请求获得成功响应 | 旧会话已失效 |
| 浏览器操作完成 | 页面上的某项操作执行了 | 后端状态、异常路径和整个业务流程正确 |
因此，工具结果先是观察，经过覆盖核对后才能成为验收证据。模型对结果的摘要也应保留限制，例如“认证单元测试通过，页面流程待验证”。
04.4 失败要分类，结果不明时先核对副作用
| 失败类型 | 下一步 | 避免 |
|---|---|---|
| 参数或工具选择错误 | 按定义修正请求 | 原样重发同一错误参数 |
| 权限拒绝 | 调整为授权路径或等待必要决定 | 换工具绕过限制 |
| 环境不可用 | 检查服务、依赖与配置 | 把环境故障当代码缺陷修改 |
| 暂时网络或限流 | 在预算内退避重试 | 无上限密集调用 |
| 写入结果不明 | 查询外部状态，核对操作标识 | 假定未执行并重复写入 |
超时可能发生在请求到达之前，也可能发生在动作已经完成、响应却丢失之后。读取通常较容易重试；注册、发送消息或提交变更则需要核对状态。幂等键和去重只有在工具与外部系统支持并正确使用时才有效。
04.5 把结果变成下一轮可用的观察
教学结果摘要：
任务 / 节点：auth-delivery / T04
动作：执行登录 → 退出 → 原凭据访问 /me 的请求链
执行环境与代码状态：本次运行引用
状态：进程已结束；业务断言失败
观察：退出为 200，之后 /me 仍为 200
证据入口：原始请求和测试记录，敏感凭据已隐藏
尚未确认：环境、凭据及清理调用是否符合预期这份记录没有提前断定原因，却足以驱动下一轮调查。接下来，ReAct 解释模型如何用这类观察选择下一步动作。
05 · ReAct：边观察、边判断、边行动
原凭据仍能访问 /me，T04 被标为失败。阿明没有追加指令，系统把失败观察放进下一轮输入；模型选择先核对请求，再检查清理路径。ReAct 解释的就是这段“观察 → 判断 → 行动 → 新观察”的调查。
05.1 ReAct 让判断与外部观察交替发生
ReAct 通常指 Reasoning 与 Acting 的结合。通俗地说，就是“看现场，决定一步，做完再看”。它适合文件内容、接口行为和错误原因尚不确定的任务，因为下一步往往要等工具返回后才能决定。
这是一种交互模式，不是所有 Agent 都必须采用的固定算法。系统可以结合规则、计划和工具自动化；它也不要求公开模型的私有内部推理。对外可检查的是动作依据摘要、实际调用、观察和后续选择。
05.2 把“可能有问题”拆成可被证伪的假设
| 当前问题 | 可检查的假设 | 取证动作 | 结果如何影响下一步 |
|---|---|---|---|
| 为何旧凭据仍可访问 | 请求可能没有命中同一环境 | 核对服务地址、实例和测试配置 | 环境不一致先纠正，暂不改代码 |
| 凭据是否正确 | 请求链可能用了新凭据或漏带凭据 | 核对脱敏后的请求关联记录 | 修正测试流程再复现 |
| 会话为何未失效 | 清理调用或存储操作可能未完成 | 读退出路由及相关 Session 行为 | 结合运行记录判断修复位置 |
动作的价值在于区分候选原因。重复运行同一个请求只能再次确认现象，未必能说明原因。优先选择能带来新信息、范围较小且符合授权的动作。
05.3 新观察回来后，更新假设而不是固守第一次猜测
在本教学故事中，工具记录先确认请求来自同一测试环境，并且退出后重放的是原来的会话标识。随后读取退出实现，发现它只发出了清除浏览器 Cookie 的响应，服务端 Session 仍在。这个结论来自请求链与代码的共同核对；若查到的是环境不一致，下一步就应处理环境，而不能照搬本故事的修法。
为什么浏览器看似退出，旧凭据却仍可用？清 Cookie 只让该浏览器不再自动携带标识，不能消除服务端保存的登录状态。持有原标识的请求仍可能被识别为已登录。模型据此提出最小修复，工具把补丁写进工作区：
教学伪代码，省略具体框架与错误响应细节：
原退出路径：
清除浏览器中的会话 Cookie
返回成功
修复路径：
尝试销毁服务端当前 Session
若销毁失败，按项目错误约定返回失败
销毁成功后，按原 Cookie 配置清理浏览器标识
返回成功
注意：函数形式、异步等待和 Cookie 参数按实际框架核对。
补丁写入成功后，仍必须执行原凭据请求链。故事到这里，只能说“调查找到原因，修复已写入”。业务状态仍是待验证。前面按旧实现复现的检查应先失败，修复后再重跑，防止写出无论怎样实现都会通过的测试。
05.4 为局部探索设置预算与停止条件
循环需要明确目标：这一轮是为了确认凭据、排除环境，还是验证修复？预算可以约束时间、调用次数、费用和可修改范围。当没有新观察、相同错误持续出现或必要条件缺失时，应换调查方法、缩小目标或保存阻塞。
停止不只有“成功”一种结果。原因无法确认、工具不可用或需要业务决定时，报告已知事实与缺口比继续猜测更有用。预算用尽也不应被包装成完成。
05.5 ReAct 推进局部调查，规划维护全局进度
这一轮 ReAct 给出原因和 R2 补丁，T04 从“调查中”进入“待验证”。它还不能变为“通过”，全局任务也没有结束：A2、A3 需要按影响重验，页面与运行说明还要完成。下一章回看 T01 建立的计划，说明系统如何记住这些工作。
06 · 规划执行：长任务怎样拆解和推进
暂时回到 T01：平台读完基线后，已经把认证项目拆成六个工作节点。后来 T04 出错，平台仍知道注册和登录做到了哪里，也知道页面与交付说明尚未全部验收。本章回看这份计划如何维持全局进度，避免一次局部修复吞掉整个任务。
06.1 先调查基线，再制定可执行计划
平台先检查规则、现有代码、已有能力和检查入口，再确定要改什么。仓库若已经有注册接口，就先核对和复用；环境若无法启动，计划应先暴露这个条件。基线调查能减少重复实现，也有助于分清原有失败和本次引入的问题。
计划可以由模型提出，也可以来自固定流程或两者结合。模型给出的清单还需要与实际环境、资源和验收核对。任务名称应表达结果，例如“旧凭据退出后失效”，比“写退出函数”更能约束完成标准。
06.2 把六个节点与验收条件关联起来
| 节点 | 工作范围 | 推进依据 |
|---|---|---|
| T01 基线与约定 | 读取仓库规则、认证实现、环境和现有检查 | 形成适用事实与范围，记录基线问题 |
| T02 注册 | 核对或补齐注册及关联页面接入 | A1：有效、无效注册和重复邮箱 |
| T03 登录与当前用户 | 登录、匿名访问、字段和相关页面接入 | A2、A3：登录行为与当前用户边界 |
| T04 退出 | 清理会话并验证原凭据行为 | A4：退出后原凭据访问 /me 为 401 |
| T05 集成回归 | 组合流程、受影响条件和差异审阅 | 功能回归与范围检查 |
| T06 运行与交付 | 完善说明，按说明启动并核验页面，整理证据 | A5 与最终清单；无法验证的条件明确保留 |
T05 可以检查功能和变更范围，T06 再按最终说明验证启动与页面流程。不能在说明尚未形成时，就声称“按说明运行”已经验收。这两步分开，是为了避免完成条件互相循环依赖。
06.3 节点需要契约，Graph 需要表达不同关系
教学节点：T04 退出与旧凭据失效
输入：退出实现、Session 配置、原凭据请求链
前置条件：T03 可用；测试服务与会话存储可访问
关联验收：A4
产物：必要的差异、回归用例、实际请求结果
通过条件：A4 满足，受影响的 A2、A3 已重新核对
失败出口：补事实 / 修实现 / 等待必要条件Graph 可以用对象、表格或显式图表达，不要求图数据库或某个框架。依赖关系回答“何时可做”，验收映射回答“为什么做”，证据关系回答“凭什么通过”，影响关系回答“变更后哪些旧结论需要重验”。图中的虚线是影响提示，不是要求先做 T04 才能做 T03 的硬前置。
06.4 调度既看依赖，也看共享资源和状态
注册与登录可以分开调查，但如果同时改同一个文件、共享测试账号或数据库，就可能互相干扰。并行前应核对资源和写入范围；冲突明显时采用串行，或隔离后统一集成。调度的目标是稳定推进，而不是增加同时运行的节点数。
节点可处于待执行、执行中、待验证、通过、失败或等待状态。状态要由动作和证据驱动，不能只根据模型生成的勾选更新。某项结果有效性丢失时，退回相关待验证节点即可，无需推翻所有已完成工作。
R2 修改了退出和共享会话相关逻辑，系统将 A4 保持为待验证，并把受影响的 A2、A3 重新安排到检查队列。注册与页面工作保留已有产物；最终集成时仍按 A1–A5 核对覆盖。Graph 让系统知道“哪里要重验”，状态记录让它知道“现在还没验完”。
06.5 重规划可以改变路径，不能悄悄改变目标
读到新事实后，系统可以复用已有接口、合并重复节点或增加必要调查。若变更涉及密码策略、身份范围或其他业务承诺，则应说明影响并取得必要决定，再更新契约和关联任务。路径调整与范围变更需要分别处理。
计划让工作可推进，验证决定节点能否通过。下一章将把“通过”从一个勾选，展开为有来源、有覆盖、有有效期的证据结论。
07 · 反思校验：怎样发现做错、漏做和假完成
教学情节中，退出缺陷已经被定位，修复后的代码记为 R2。现在关键问题从“改哪里”变成“如何证明改对了”：原凭据是否真的失效，重新登录是否仍然正常，页面会不会只退出了显示状态？反思与验证在这里把补丁连接到业务验收。
07.1 自查、外部验证与验收分别承担什么职责
| 层次 | 工作方式 | 用途与限制 |
|---|---|---|
| 自查 / 反思 | 模型对照需求、差异和已有结果检查遗漏 | 适合提出疑点和改进候选，可能重复自身误判 |
| 外部验证 | 运行测试、接口探针、浏览器流程和静态检查 | 获得实际观察，结论受环境和覆盖限制 |
| 交付验收 | 逐条核对业务标准、范围、运行方式与证据 | 决定完成、部分完成或阻塞，不以语言自信程度判断 |
让模型再看一次答案，有时能发现缺陷，也可能让它给原错误补上更流畅的解释。独立规则、真实请求和人工审阅可以提供不同来源的证据，但各自仍有盲区。
07.2 先明确验收，再选择能覆盖它的检查
| 验收 | 要观察的行为 | 合适的检查入口 |
|---|---|---|
| A1 注册 | 有效注册、无效输入、重复邮箱按约定处理 | 业务测试、真实接口与相关页面 |
| A2 登录 | 正确凭据成功，错误凭据按约定失败 | 接口正反例与页面提示 |
| A3 当前用户 | 匿名为 401，登录后仅返回允许字段 | 匿名 / 登录请求与响应字段断言 |
| A4 退出 | 退出后原会话凭据请求 /me 为 401 | 真实凭据链和相关回归 |
| A5 交付 | 按说明可运行，页面链路可用，差异不越界 | 启动复现、浏览器流程、差异和说明审阅 |
测试脚本退出为 0，只能证明执行过的断言满足。需要检查断言是否覆盖正确结果、异常路径和副作用。把退出接口模拟为成功，却不检查真实会话行为，就无法证明 A4。模型生成的测试也要经过这层审阅。
在故事中，平台对 R1、R2 执行同一条业务请求链，并为修复后的登录行为补查。下表是设定的教学结果：
| 检查 | R1：修复前 | R2：恢复后重验 |
|---|---|---|
| 登录后访问 /me | 200，返回允许字段 | 200，返回允许字段 |
| 调用退出 | 200 | 200，服务端 Session 已按约定清理 |
| 原凭据再次访问 /me | 200，A4 失败 | 401，A4 通过 |
| 新一次正常登录与匿名访问 | 已有局部记录 | 重新检查 A2、A3，通过对应断言 |
同样返回 200 的退出接口，在两份代码上对应了不同业务效果。平台不能只比较退出响应；关键证据是退出后的请求结果及相关回归。R2 的验证在中断恢复后取得，09 会解释这段恢复过程。
07.3 失败反馈要定位缺口，并返回合适的处理点
“A4 失败”比“再完善一下”更有行动价值。反馈应包含预期、实际、复现条件、代码状态、原始记录入口及未确认点。若是环境错误，回到环境检查；若是实现不符，进入修复；若是验收歧义，等待业务决定。覆盖不足则补检查，不一定先改业务代码。
07.4 证据需要来源和有效范围
教学验收记录 E03，非实测：
验收：A4
代码：R2；环境：同一测试服务与会话存储
预期：退出后原凭据 GET /me = 401
故事中的实际结果：401
状态：通过；同时关联本轮 A2、A3 的回归记录
来源：本轮登录 → 退出 → 原凭据请求链
对照：E02 是 R1 上同一请求链返回 200 的失败记录
限制：该结果不代替页面与运行说明的 A5 检查修改了共享认证逻辑后，旧代码上的通过记录不能直接用于新版本。证据是否需要作废由影响关系决定。记录中也应控制敏感信息，保留可关联的标识即可，不把密码或完整会话凭据放进报告。
07.5 完成门槛不能由最后一句回答替代
最终状态至少区分通过、部分完成与阻塞。关键验收缺证据时，可以交付当前差异和已知结果，但要保留未验证项及原因，不能默认通过。模型评审结论也不应自行覆盖失败断言。
只有范围、行为、运行说明和必要回归都满足约定，才汇总为完整交付。这种门槛需要运行系统持续维护，下一章先看多角色协作时怎样保持同一份验收责任。
08 · 多 Agent：什么时候需要分工，怎样避免越帮越乱
核心修复回归后，任务进入 T05。为了演示可选协作，平台委派一个只读审阅角色检查页面和运行说明，主执行者继续汇总功能结果。审阅者发现说明遗漏了会话存储的启动前提。这项发现如何返回主任务，又由谁负责最终通过？
08.1 先判断任务是否值得拆分
一个 Agent 具备完整上下文、工具和验证路径，就能完成许多项目。多 Agent 适合相对独立的调查、专门工具操作或需要不同视角的审阅。如果任务很小，或几个角色反复修改同一个模块，协调成本可能超过收益。
多 Agent 与并行不是同义词：多个角色可以串行交接；多个只读工具也可以并行而不需要多个 Agent。先明确工作边界，再决定使用多少执行者。
08.2 每份委派都要带输入、边界、产物和返回条件
| 角色示例 | 收到什么 | 交回什么 |
|---|---|---|
| 认证实现 | 契约、相关代码状态、A1–A4、授权范围 | 变更、检查记录、未决项及影响范围 |
| 页面审阅 | 接口约定、已有页面、当前集成版本、A5 | 页面正反例记录与缺陷，不擅改认证策略 |
| 集成与验收协调 | 各角色产物、差异和证据引用 | 集成版本、统一验收结果、冲突与阻塞清单 |
审查者应读取实际代码和验收，不只读实现者的总结。角色权限也要按工作范围授予；子任务不能扩大总任务授权。返回结果应注明所基于的版本，避免拿旧分支的绿灯认可新集成版本。
本案例的可选委派：
输入：R2 差异、A5、已有页面、运行说明草稿
权限：只读审阅与已授权测试环境中的页面检查
任务：检查页面正反例及说明是否足以复现
返回：发现会话存储的启动前提未写入说明；A5 尚未满足
主任务处理：主执行者补说明，T06 再按说明完整启动检查
最终归口：主任务统一维护 A1–A5，审阅角色不自行宣布交付08.3 并行写入前先处理隔离与共享资源
可通过独立分支、工作区或明确文件范围降低覆盖风险，但隔离不能自动解决集成语义冲突。共享数据库、账号和后台进程仍需协调。测试数据要避免互相污染，谁启动的服务由谁记录并按规则清理。
| 失败表现 | 常见原因 | 协调方式 |
|---|---|---|
| 重复实现 | 任务范围重叠 | 明确节点归属和已有能力 |
| 代码互相覆盖 | 同时写同一工作区 | 隔离变更，按顺序集成 |
| 测试结果矛盾 | 环境或数据不同 | 统一复现条件，保留各自证据 |
| 两个角色都说通过但集成失败 | 各自只测局部版本 | 对集成版本重新执行相关验收 |
08.4 冲突靠证据解决，最终状态要有归口
实现角色认为退出已完成，审查角色发现旧凭据仍有效时，不应投票决定。先复现、核对版本与环境，再依据 A4 和工具记录处理。如果争议来自业务规则，就提交具体决定，而不是让角色彼此说服。
在故事里，主执行者接受了“启动前提遗漏”这一具体缺口，补齐说明，再由 T06 检查。角色意见通过产物和验收进入总任务，避免停在一段聊天建议里。审阅完成不自动使 A5 通过，集成版本仍需实际运行；多角色也可能共享同类偏差。
08.5 只有收益明确时才保留这种分工
比较分工前后的交付耗时、缺陷发现、集成返工与成本。如果信息同步越来越多、角色长期等待或返工增加，就应缩减角色或改成串行。多 Agent 是可调整的执行方式，不是平台成熟度的数量指标。
09 · Harness：怎样让整段执行稳定、可恢复、可评估
现在回看修复与验收之间的一次中断演练：R2 补丁已写入，测试进程却还没返回结果，运行进程意外停止。恢复后，平台不能把代码重新改一遍，也不能凭“之前启动过测试”记为通过。Harness 解释如何核对现场、找回进度并安全续跑。这里采用运行框架的广义用法，不同产品的术语边界可能不同。
09.1 聊天记录与运行状态需要分别维护
聊天记录便于回看交流，但从长文本里猜测“T04 是否验证过”容易出错。任务状态应显式表达当前契约、节点、验收、待执行动作和证据引用。可以用文件、对象或数据库承载，关键是状态变化有来源、恢复后可核对。
教学状态示例，非平台真实接口：
task_id: auth-delivery
spec_version: v1.0
status: running
current_step: T04
acceptance:
A4: failed
observation: 退出后原凭据访问 /me 仍为 200
pending_action: 核对清理调用
code_ref: 当前代码状态引用
evidence_ref: 本次请求链与检查记录
policy_ref: 当前授权、环境与预算字段写成“通过”不代表证据真实。运行系统需要知道由哪个事件、哪个版本和哪条检查更新状态，并防止过期结果覆盖当前进度。多个执行者并发返回时尤其如此。
09.2 把环境、权限、进程和预算作为执行条件
工具分发前检查路径、目标环境、网络和命令权限；执行时限制资源和超时；长进程保留可查询、取消及清理的标识。测试环境和生产环境应有明确边界，能力描述不能代替实际隔离。
预算不仅是 Token，也包括总时长、工具次数、外部费用和重试上限。预算接近耗尽时，应优先保存有效进度与缺口。连续执行同一动作却没有新证据时，系统应识别无进展，避免陷入无限循环。
09.3 检查点保存任务线索，恢复要核对外部世界
| 检查点记录 | 恢复时重新核对 |
|---|---|
| 契约、当前节点、等待原因 | 任务规则、业务决定和授权是否变化 |
| 代码状态、产物和证据引用 | 工作区是否被人或其他任务修改 |
| 运行中的进程和操作标识 | 动作仍在运行、已经完成还是结果不明 |
| 检查结果和环境引用 | 服务、依赖和数据是否使旧结论失效 |
补丁写入之后、状态保存之前进程可能崩溃；远端动作也可能完成而响应丢失。恢复时不能把检查点当作外部世界的快照。先核对已发生的动作，再选择补录、续跑、重验或等待。
中断演练的恢复记录如下。它插入在 R2 补丁写入之后、07 中的通过结果产生之前：
- 读取任务状态：T04 待验证，A4 没有可用的修复后通过记录。
- 核对工作区：R2 补丁仍在，且没有被其他任务改写，因此不重复应用补丁。
- 查询原测试进程：确认已经终止，没有可采信的最终结果；不是把“未收到输出”直接当成失败或未执行。
- 重新核对测试服务、会话存储、授权和测试数据，再启动一次检查。
- 新的结果完整返回后，关联 E03，更新 A4 和相关 A2、A3；随后继续 T05。
恢复入口实际做的是核对与续跑。若原测试仍在运行，应继续查询；若是创建账号等写操作结果不明，应先查询对应外部状态。本例确认旧测试终止、环境可重置后才重新执行。
幂等操作、去重和补偿可以减少重复副作用，但取决于外部系统配合。跨任意工具，不能仅凭一个 Checkpoint 承诺严格只执行一次。撤销代码变更与撤销数据库或外部动作也需要分别处理。
09.4 按失败类型选择恢复路径
| 故障 | 恢复方向 | 限制 |
|---|---|---|
| 模型请求暂时失败 | 有界重试并保留输入与状态引用 | 遵循限流和预算，不重复已确认外部动作 |
| 工具运行失败 | 读取退出信息，检查参数或环境 | 不自动扩大权限 |
| 业务验收失败 | 保留证据，回到调查与修复 | 不能只重试相同错误实现 |
| 权限或业务条件缺失 | 保存等待原因与具体恢复条件 | 没有条件变化不反复询问或调用 |
| 副作用结果不明 | 查询外部状态，必要时人工协调 | 未确认之前不盲目重复写入 |
09.5 监控解释当前运行，评测比较系统版本
运行日志应把任务、节点、调用、产物和验收关联起来，回答“这次为什么停在这里”。监控观察错误率、耗时、重试和预算；评测则用固定案例比较不同版本的交付成功率、误报完成、回归、成本和恢复表现。两者用途不同。
记录要脱敏，并控制访问与保留范围。可以保存证据引用和决策摘要，不需要收集模型私有内部推理或完整业务敏感数据。可靠的 Harness 应让人看清限制和失败，而不是只展示一条平滑的进度条。
10 · 动态路由：为什么不同任务要走不同路径
同一个认证项目，在不同节点需要不同路径：T01 用只读工具收集事实；T04 用模型诊断和请求工具复现；T05 按需派出审阅角色；T06 用启动与浏览器检查取得证据。动态路由解释这些选择怎样发生，而非另开一个案例。
10.1 路由对象包括模型、工具、流程和人工出口
读取配置可以直接调用只读工具，分析跨模块故障可能需要补充材料和适合诊断的模型，已有测试适合交给执行器，业务歧义则需要具体决定。路由可以由明确规则、模型判断或混合策略实现。安全和授权约束应由实际执行边界落实。
不能只按“任务看起来简单”决定一切。一个很短的生产删除操作，风险可能高于较长的本地分析。质量门槛与环境约束应先成立，再在允许路径中比较成本与时延。
本故事的实际选择是：先取事实而不升级模型，诊断确认后局部修复，已有检查直接交给执行器，页面与说明采用只读审阅。整个交付限定在授权工作区与测试环境，没有进入生产发布。后文的生产动作是边界对照，不是故事里新增的一步。
10.2 先识别缺口，再决定是否升级模型
| 当前情况 | 合适路径 | 不合适的替代 |
|---|---|---|
| 缺当前代码事实 | 读取、检索并核对适用性 | 仅更换更贵模型继续猜 |
| 工具参数错误 | 按接口定义修正参数 | 原样重复请求 |
| 环境变量或服务缺失 | 检查运行条件 | 把配置故障当成业务代码问题 |
| 复杂判断仍不可靠 | 补足输入后比较更适合的模型或审阅 | 无限增加角色而不核对证据 |
| 需要改变业务规则 | 提交具体选项、影响和待决定事项 | 让模型自行决定范围 |
| 未经授权的外部操作 | 不执行，采用授权替代或说明阻塞 | 通过其他工具绕行 |
10.3 切换路径时要带上同一份任务状态
换模型或交给专门角色时，应交接目标、约束、当前节点、代码状态、已有观察、证据入口和剩余预算。只转发“帮忙看看登录问题”，会使新执行者重新猜测已经查明的内容。
切换也要有上限和退出条件。连续在两个模型间来回、每次都重新调查，会增加成本并丢失进度。恢复后仍应验证当前授权与结果有效性，不能因为执行者改变就放宽完成条件。
10.4 路由选择路径，授权判断动作能否执行
本地读取通常可在已有授权范围内继续；生产写入、范围变化或必要业务决策需要按实际规则处理。权限拒绝是约束结果，不是寻找其他执行方式的提示。动作的目标环境、参数或影响变化后，旧许可需要重新核对适用性。
教学等待记录：
本故事无需变更会话策略，沿用原契约即可继续。
若另一个需求要求修改策略，才进入下列等待分支：
原因：必要业务规则尚未决定
待决定：具体方案及影响，附当前证据
保存：节点、差异、未验证项
恢复：决定生效后更新契约，并重验受影响条件10.5 评估路由效果，要看交付而不只看调用成本
便宜的路径如果频繁返工，整体可能更贵；强模型如果仍缺事实，效果也可能不变。比较路由策略时，应同时观察验收通过、误报完成、总耗时、重试与总费用。一次降本有效，不代表适用于所有风险等级。
这些运行记录会成为下一章持续演进的材料：路由如何调整，需要案例和评测支持，而非凭单次体验扩散新规则。
11 · 持续演进：怎样把一次失败变成下一次的改进
T06 已完成本轮核验，阿明收到差异、运行说明和 A1–A5 的教学验收记录。任务随后进入复盘：这次完整请求链捕获了退出缺陷，平台应怎样让未来任务也稳定执行这项检查？持续演进作用于下一次交付，不是本轮完成前必须训练一次模型。
11.1 把失败保留成可重现的案例
记录“Agent 没做好退出”太笼统。应保留任务目标、适用代码与环境、预期和实际、执行路径、错误完成信号及证据入口。案例要控制敏感信息，并说明重现所需条件。
本次运行没有因为退出返回 200 就提前结束，它通过完整请求链捕获了 R1 的业务缺陷。复盘由此保留两类样本：业务回归检查旧凭据是否失效；平台评测检查 Agent 有没有实际执行这条链、遇到失败能否继续修复。还可以构造“只看退出响应就结束”的对照运行，测试误报完成门槛，而不是把对照失败写成本次事实。
11.2 诊断缺口，再选择要改的系统部分
| 缺口 | 可能改进 | 需验证什么 |
|---|---|---|
| 目标遗漏退出后的行为 | 明确任务和验收表达 | 是否更完整覆盖，同时不误改其他认证策略 |
| 未读取现行 Session | 优化调查规则和上下文选择 | 是否找到适用事实，而非增加无关材料 |
| 工具未回传失败状态 | 修正接口约定和状态处理 | 失败是否能稳定进入反馈 |
| 只看响应码就宣布完成 | 补断言、验收门槛和评测样本 | 误报完成是否下降 |
| 模型切换丢失上下文 | 完善路由交接信息 | 进度与证据是否保留 |
| 恢复后重复外部操作 | 改进去重与状态核对 | 中断场景是否安全续跑 |
11.3 用固定基线和未参与调优的案例比较效果
改动前先保存基线，改动后在相同环境与预算条件下比较。既测试旧凭据失效，也测试正常登录、匿名访问、页面接入和不适用的认证场景，避免新规则只对一个案例有效。随机性较大的任务需要多次运行，记录样本数和波动。
调优用的案例与评估最终效果的保留案例应尽量分开。否则系统可能只记住固定解法，却没有提高对新任务的处理能力。评测不只看最终答案，还应核对实际产物、验收覆盖、误报完成、恢复和费用。
本例沉淀的规则不是“所有退出都必须调用某个函数”，而是“对声明旧会话失效的任务，检查原凭据在退出后的实际行为”。将它加入适用范围明确的检查模板，再用未参与调优的任务验证，才能形成下一版本的改进。
11.4 发布需要版本、适用范围和回退方式
提示、规则、工具、模型配置与路由策略都应能定位到版本，便于比较和恢复。若一次同时改很多部分，就难判断哪项导致效果变化。可以先小范围验证，观察线上任务中的回归，再逐步采用。遇到质量下降，恢复旧配置，并重新审阅正在执行任务的适用状态。
失败记录和外部内容也不应直接变成永久指令。需要核对事实、适用范围与授权，再纳入规则；某个 Session 项目的经验，不能自动推广到所有 JWT 或第三方身份系统。
11.5 区分任务内修复、持久记忆和模型训练
当前会话重试是在完成当前任务；把线索存入记忆是在保存信息；调整规则和工具是在改进系统；训练或微调才会改变模型参数。持续演进可以只改规则、测试、上下文和路由，不要求自动训练。
每一种改动都需要回答：改了什么、针对什么问题、依据哪些样本、有什么回归、怎样回退。接下来用一次完整复盘，把这些跨章节机制放回实际交付顺序。
12 · 交付复盘：九项能力怎样共同完成一次任务
现在把各章回看的片段接回同一条时间线：同一个项目、同一个退出缺陷、同一组验收。下面给出教学故事的完整结局，并用状态与记录说明平台为什么能结束。所有版本、记录编号和结果仍为教学设定，不是认证项目实测。
12.1 启动时先建立目标、事实与基线
阿明发出完整委托，运行系统保存目标和 A1–A5，检查授权工作区、环境与工具。T01 读取现行规则、Session、密码处理、响应约定、页面和检查入口。模型据此提出计划，避免在不了解仓库时另起 JWT。已有失败被记为基线，不能默认为本次造成。
这一阶段同时涉及 LLM、Context、工具、规划和 Harness。动态路由可以让确定读取直接执行，把复杂判断交给模型；并没有先“跑完 LLM 模块”才开始工具模块。
12.2 从 R1 的失败，到 R2 的恢复与通过
| 阶段 | 动作与观察 | 状态与后续 |
|---|---|---|
| T02–T03 | 核对或补齐注册、登录、当前用户及相关页面；取得检查结果 | 按 A1–A3 更新状态，记录适用版本 |
| T04 首次验证 | 登录、退出、携带原凭据访问 /me；发现仍为 200 | A4 失败，保留请求链，不能宣告退出完成 |
| 局部调查 | ReAct 核对环境、凭据和清理调用 | 观察与假设分开；证据决定修复位置 |
| 修复与重验 | 局部变更、补回归，重跑 A4 和受影响 A2、A3 | 仅在真实结果满足时转为通过；否则继续修复或阻塞 |
| 必要协作 | 按需委派页面审阅或独立验收 | 对子任务的输入、版本与返回证据统一汇总 |
本故事在 R2 写入后插入中断演练。平台确认补丁仍在、旧测试已终止且结果不可用，核对环境后重跑。原凭据得到 401，相关登录和匿名检查也满足约定，E03 才成为修复后的通过证据。这里没有等待阿明回复“继续”，也没有因为恢复而跳过验证。
12.3 功能回归以后，还要完成交付核验
T05 汇总功能回归与差异审阅，可选审阅角色发现说明遗漏会话存储的启动前提。主执行者补齐后，T06 在 R3 上按最终说明依次启动依赖和服务，再操作注册、错误登录、正常登录、当前用户与退出页面。在教学设定中，这些行为满足 A1–A5，最终才进入完整交付。
| 验收对象 | 交付时应关联的证据 | 缺失时如何表达 |
|---|---|---|
| A1 注册 | 有效、无效和重复输入的行为记录 | 标明具体未覆盖情况 |
| A2–A3 身份与当前用户 | 正确 / 错误登录、匿名访问和允许字段 | 说明环境或覆盖限制 |
| A4 退出 | 同一原凭据退出后访问 /me 为 401 的请求链 | 旧凭据未检查，不能记通过 |
| A5 可接手性 | 按说明启动、页面流程、差异范围与最终版本 | 说明文档、页面或环境尚待核验的部分 |
12.4 交付报告应让接手者能够复查
教学交付摘要，以下为故事结果，非实测：
范围：现有后台认证与页面接入；沿用 Session，不做生产部署
代码：R3，集成 R2 退出修复，含关联页面、回归检查与最终运行说明
E01：R0 基线与项目约定记录
E02：R1 退出后原凭据 /me = 200，保留失败
E03：R2 恢复后的请求链 /me = 401，关联 A2、A3 回归
E04：R3 最终集成版本的 A1–A4 与范围检查记录
E05：R3 补齐前提后按说明启动、页面正反例及 A5 核验
结论：在约定测试环境与范围内，A1–A5 均满足，完成本次交付
边界：生产部署和未约定环境不在本轮结论内
实际交付时，以上标签需关联真实记录、文件与代码状态；
缺证据则写未验证，不可复制教学结果充当实际通过记录。R1 的失败记录没有被覆盖，R2 的通过记录也没有替代最终集成与页面检查。阿明据 E01–E05 能复查“为什么改、改在哪里、怎样验证、如何运行”。这是交付结果与一段成功自述的具体区别。若 E05 缺失，就应报告 A5 未验证，即使 E03 已经通过，也不能给出这里的完整交付结论。
12.5 用症状定位链条断点，而不是一概归因于模型
| 症状 | 优先核对 | 对应机制 |
|---|---|---|
| 只给方案，没有实际改动 | 是否有工具、是否分发成功、是否等待权限 | 工具调用、Harness、路由 |
| 不断改错模块 | 上下文是否当前有效、是否调查实际调用链 | LLM 输入、Context、ReAct |
| 工具成功却业务失败 | 断言和验收是否混淆，覆盖是否充分 | 反思校验 |
| 修退出破坏登录 | 变更影响是否关联旧证据并触发重验 | Graph、规划与验证 |
| 多角色意见一致但集成失败 | 输入版本、共享资源和汇总责任 | 多 Agent、集成验收 |
| 恢复后重复写入 | 外部副作用是否核对、操作是否可去重 | Harness、工具契约 |
| 新规则改善一例却破坏其他任务 | 评测范围、版本与适用条件 | 持续演进 |
同一症状可能有多个原因。先取得输入、动作和结果记录，再缩小问题；这也是理解平台之后能够进行有效诊断的基础。
13 · 思考：从理解平台，到设计平台
阿明最后收到的不是一句“认证已完成”，而是可接手的代码差异、检查记录、启动说明及验收结论。他沿着记录能看到退出缺陷怎样被发现、补丁怎样在中断后接续、页面审阅怎样补上说明遗漏。理解一次交付，就是能够解释这些变化为什么发生、依据在哪里。
13.1 用一条完整关系理解九项理论
LLM 基础解释判断的能力与输入边界；工具调用让建议进入外部世界；ReAct 根据现场继续调查；规划与 Graph 保持全局目标、依赖和影响关系；反思校验用证据判断差距。多 Agent 按需分工，Harness 支撑运行，动态路由选择合适路径，持续演进改进后续版本。
Context 持续补齐当前事实，Loop 持续带回反馈，Graph 关联任务与证据。它们不是彼此竞争的名词。理解这些关系后，就可以问一个具体平台：这些职责由什么承载，哪些能力已经实现，哪些仍需要使用者补齐？
13.2 可靠交付包含边界、证据与合法的停止方式
自主执行的目标是减少无必要的人工接力，不是让系统在任何条件下都不停运行。合理的结果包括完成、部分完成和阻塞；平台应说明每种状态的依据。权限、业务歧义、环境条件和预算，都可能成为真实边界。
同样，支持长上下文、多个角色或恢复按钮，只说明提供了某种能力入口。是否能可靠交付，还要通过具体任务检查事实获取、动作执行、证据覆盖和中断恢复。产品能力应以可验证行为评估。
13.3 把运行机制翻译成用户能理解的产品对象
| 运行机制 | 下一篇要面对的产品问题 |
|---|---|
| 目标、约束与验收 | 用户怎样创建任务、确认范围和完成标准 |
| 计划、状态与 Graph | 怎样展示进度、依赖、返工与等待原因 |
| 工具执行与权限 | 用户怎样理解允许范围、风险和需要决定的动作 |
| 验证与证据 | 怎样让人复查“完成”依据及未覆盖部分 |
| 检查点与恢复 | 中断后从哪里继续，哪些条件需要重新核对 |
| 评测与持续演进 | 怎样呈现能力边界并验证版本改进 |
把这张表放回阿明的任务：他需要看见 T04 为什么失败、R2 是否已经写入、中断后哪些检查重跑，以及 A5 为什么还在等待说明补齐。这些可理解的任务事实，比向用户直接堆出九个技术名词更有用。
13.4 阅读完之后，可以自己做一次机制核对
选择一个你正在使用的平台，挑一次真实任务，沿着记录回答：目标和验收在哪里？模型依据哪些当前材料？工具实际做了什么？失败怎样改变下一步？中断后如何恢复？最终结论有哪些证据？无法确认的能力先标为未验证，不从界面名称推断实现。
01 解决如何使用现有平台交付，02 解释交付如何发生。继续阅读03 · 通用 Agent 平台：构建可复用的交付能力，把这些机制转化为任务对象、交互流程与可实现的产品承诺。