第 2 章 Chapter Outline：Agent、Harness 与运行环境

本文件是章节写作蓝图。四层划分是本书的工作模型；任何可归因事实都必须保留来源编号，任何设计案例都必须说明它是教学假设。

章节契约

读者完成后的能力： 能将一次 Agent 任务的模型、决策、编排和环境责任分开，针对失败先提出可观察证据，而不是仅凭最终文本归因；能把记录缺失、候选拒绝、运行环境阻塞、验证拒绝和验证接受分开处理，并用最小 Attempt Trace 将同一次尝试的证据关联起来。

前置知识： 已阅读第 1 章，了解“模型提议、工具执行、验证接受”是不同事实；具备基本的进程、文件权限和函数错误概念。

章节边界： 只建立责任坐标与初步诊断步骤。不在本章设计 Prompt 分层、工具协议、Sandbox 规则、工作流状态机或评估指标的完整实现。

读者问题： 如何在不确定时避免错误重试或错误授权？
叙述任务： 给出“模型候选不成立、Agent 决策不当、Harness 编排缺口、运行环境拒绝”四类假设及检查顺序；补充“未证实、候选拒绝、运行环境阻塞、验证拒绝、验证接受”的最小结论词表。
证据边界： 归因表是本书的诊断建议，不承诺覆盖所有故障。
计划工件： 故障归因表、“假设—证据—行动”诊断卡、最小排查流程和结论状态表。
验证： 每类故障都有一个“不能据此断定”的提醒；读者能为一个失败写出最小证据和当前不应执行的动作，并能将记录缺失标为未证实，避免伪因果、无效重试和无证据结论。
过渡： 引向各层之间的最小接口契约。

读者问题： 小型系统也需要四个独立服务吗？
叙述任务： 说明同一进程可实现多层，但仍应以“问题—工件—判定”显式表达候选、决策、请求、观察、验证与证据；补入以 attempt_id、请求关联和最小顺序关系避免错误拼接证据的 Attempt Trace，再给出从纯内存模拟器到真实受控适配器的渐进增强边界。
证据边界： 是本书设计建议；不产生可运行代码或产品兼容性承诺。
计划工件： 问题—工件—判定表、Attempt Trace 关系表、输入—输出—失败—证据四列表与增强顺序。
验证： 清单中每项都有明确责任、最小工件、判定条件或升级方向；Attempt Trace 不被写成产品格式或通用追踪标准，渐进步骤不被写成通用成熟度模型。
过渡： 第 3、5、10、11、12 与 17 章将分别实现这些边界。

已完成：Technical Review，确认来源观点与本书工作模型分开。
已完成：Mermaid 渲染与 Diagram Review；仅有源文件不计为图示审查完成的规则已通过实际渲染满足。
已完成：Example Implementation，使用纯内存运行边界示例并定义可执行验证命令；不将教学模拟器描述为真实环境。
已完成：Fact Check、Language Editing 与 Final Review；最终状态由 .ai/progress.md 与 .context/CURRENT_STATE.md 汇总。