外观
第 2 章 Research Brief：Agent、Harness 与运行环境
任务与读者问题
第 1 章说明了为何一个需要外部操作的任务不能只靠 Prompt。第 2 章把这个问题变成可用于排错的责任划分：当任务失败时，哪些证据指向模型的候选输出、Agent 的循环决策、Harness 的编排与验证，或运行环境的权限和状态？
读者完成本章后，应能用本书的工作模型画出这四个边界，并为一次失败提出先收集什么证据、不能直接下什么结论。
范围与非范围
范围： 建立模型、Agent、Harness 和运行环境的职责表；用同一任务在只读与可写环境中的假设场景讲解故障归因；为后续的指令、工具、权限、状态和评估章节确定坐标。
非范围： 不比较特定 Agent 产品或其动态能力；不定义通用行业标准；不报告模型分数、基准数字或生产事故；不把 ReAct 的研究结论外推为生产系统保证。
研究问题
| 问题 | 需要的证据 | 当前结论 |
|---|---|---|
| Agent 常由哪些功能类别组成？ | 一手系统概览。 | REF-003 以规划、记忆和工具使用组织 LLM Agent 系统的概览；它不是唯一架构。 |
| Harness 覆盖哪些模型外责任？ | 作者对 Harness 的直接工作描述。 | REF-001 将其描述为围绕基础模型协调执行、规划、工具、上下文、工件和评估的系统。 |
| 模型与现实世界之间为何还需要运行边界？ | 来源对 deployment system、工具和外部环境的说明。 | REF-001 强调模型与真实世界语境之间的部署层；REF-004 说明行动可与外部来源或环境交互。 |
| 四层是否是来源提出的标准分层？ | 来源原文与本书设计决定。 | 不是。本章的四层责任表是本书为诊断与教学提出的工作模型。 |
已核验来源与可用陈述
| ID | 可在本章使用的陈述 | 证据边界 | 复核状态 |
|---|---|---|---|
| REF-001 | 来源将 Harness 描述为围绕基础模型、协调执行并决定规划、工具调用、上下文、工件和评估的系统；文章也把它置于模型与真实世界语境之间的部署层。 | 使用归因表达；不照抄定义，不把作者的观察写成行业标准。 | 2026-07-15 已复核原文。 |
| REF-003 | 来源以 Planning、Memory、Tool Use 三组功能介绍 LLM-powered autonomous agents。 | 仅作历史性系统概览；不能推出每个 Agent 都必须有相同模块。 | 2026-07-15 已复核原文。 |
| REF-004 | ReAct 研究交错生成推理轨迹与任务动作；摘要说明推理轨迹可跟踪、更新行动计划和处理例外，动作可访问外部信息来源或环境。 | 仅说明研究对象和交互边界；不使用性能数字，也不称为生产参考实现。 | 2026-07-15 已复核摘要页。 |
本书的工程扩展
以下内容是本书为工程诊断提出的工作模型，不是对来源观点的逐句转述：
- 模型（Model） 产生候选文本、结构化调用参数或下一步建议；它的输出本身不是外部世界已经改变的证据。
- Agent 负责在当前观察下选择下一步，维护任务循环的决策语义；它可使用模型，但不等同于模型。
- Harness 负责把指令、状态、工具、验证和记录组织为可执行、可观察的流程。
- 运行环境（Runtime） 提供进程、文件、网络、凭证和隔离等实际条件；Sandbox 与权限是其边界的一部分。
- 结论状态词表 将记录缺失标为“未证实”，并区分候选拒绝、运行环境阻塞、验证拒绝与验证接受；它是本书的诊断设计，不是来源、产品或通用状态机的既有枚举。
- Attempt Trace 用一次尝试标识、候选、决策、请求、观察与验证之间的关联，防止交接者将不同尝试的证据拼接为因果链；它是本书工程模型，不是产品事件格式、分布式追踪标准或来源定义。
这四层可以在一个很小的程序中由同一进程实现，也可以分散在多个服务中。划分的目的不是增加组件数量，而是避免把不同故障都归咎于“模型不够聪明”。
术语与章节边界
| 术语 | 本章的最小用法 | 后续章节 |
|---|---|---|
| Agent | 使用模型和观察来推进任务的执行循环。 | 第 09、10、15 至 20 章讨论计划、状态与闭环。 |
| Harness | 组织执行、工具、状态、验证和证据的运行结构。 | 第 05 至 14 章分别细化其组件。 |
| 运行环境（Runtime） | 任务实际运行所依赖的进程、资源与访问条件。 | 第 12 章细化环境、Sandbox 与权限。 |
| 工具（Tool） | 具有输入、输出、错误与副作用边界的外部操作接口。 | 第 11 章定义工具协议。 |
计划叙述与工件
- 以“同一修改建议在两个环境中结果不同”的场景建立观察与宣称的差异。
- 给出四层工作模型、每层可回答的问题和可收集的证据。
- 以 Mermaid 图解释请求、执行、观察与错误如何跨层流动。
- 用故障归因表和“假设—证据—行动”诊断卡说明先检查什么，避免直接把所有失败写成模型问题。
- 用“问题—工件—判定”界定最小接口，并给出从纯内存模拟器到受控真实适配器的渐进增强边界；详细机制交给后续章节。
事实与版权计划
- 正文紧贴相关陈述引用 REF-001、REF-003 或 REF-004；章节级登记见 参考资料候选清单。
- 只使用概念范围，不翻译来源段落、图示或案例；架构图、场景和表格全部原创。
- 只读仓库和可写测试环境的案例是教学假设，不是某个真实仓库的执行记录。
- 如后续加入具体产品、Sandbox 实现或权限机制，必须在写作当天改用官方资料建立新的证据卡。
本轮增补复核
2026-07-15 为补强正文中的责任框架与诊断卡，重新读取了 REF-001、REF-003 的原文与 REF-004 的 arXiv 摘要。新增的来源陈述只使用 REF-004 对“推理轨迹帮助跟踪、更新行动计划和处理例外；动作连接外部来源或环境”的摘要描述。责任框架、诊断卡、结论状态词表、Attempt Trace 和渐进增强顺序仍全部属于本书工程扩展；它们不声称是论文、作者文章或任何产品的既有接口。
Research 完成检查
- [x] 明确了范围、非范围、读者问题与章节出口。
- [x] 复核了三个一手来源，并限制其可用陈述。
- [x] 将四层划分、案例与诊断表标为本书工程扩展。
- [x] 建立了详细 Outline、事实核验清单、图示源文件和候选参考资料。
- [x] 未引入未经当日官方资料核验的动态产品事实。