外观
第 1 章 Research Brief：从 Prompt Engineering 到 Harness Engineering
任务与读者问题
本章不把 Prompt Engineering 描述成已经失效的技术，也不宣称 Harness 是统一的行业标准。它要帮助有编程经验的读者回答一个工程问题：当任务需要调用工具、保存状态、验证结果并在失败后恢复时，除了改写 Prompt 之外还必须设计哪些可观察的系统部件？
读者完成本章后应能：
- 说出 Prompt 的职责与它不能单独承担的职责。
- 使用本书的工作定义区分基础模型、Prompt、Harness 和运行环境。
- 为一个简单任务列出指令、状态、工具、验证和记录五个最小交付物。
- 识别“模型输出看起来合理”与“任务已被验证完成”的差别。
范围与非范围
范围： 用两个一手作者来源建立问题背景；用一个不访问外部系统的最小 Harness 说明任务闭环；为后续组件和案例章节建立术语边界。
非范围： 不比较任何 Agent 产品的最新能力、价格或基准；不介绍 Prompt 技巧大全；不讨论模型训练、权重更新或递归自改进的具体算法。正文初稿另见 第 1 章正文，本 Brief 不替代其技术审查或最终事实核验。
研究问题
| 问题 | 需要的证据 | 当前结论 |
|---|---|---|
| Prompt Engineering 的最小职责是什么？ | 作者对 Prompt Engineering 的定义与作用范围。 | 可将其视为在不更新模型权重时，通过输入信息引导模型行为的方法；它仍是任务表达的一层。 |
| 为什么不能只以 Prompt 解释长任务 Agent？ | 作者对 Harness 及其组件的工作性描述。 | Harness 需要处理执行编排、工具调用、上下文、工件和评估等外部系统职责。 |
| 本书的新增工程视角是什么？ | 本书的设计决定与可运行示例。 | 本书把这些职责转成显式接口、状态、权限和可验证证据；这是本书的工程扩展，不是对来源作者观点的转述。 |
| 本章应避免什么过度主张？ | 来源范围、产品变化风险与版权规则。 | 不将工作定义包装为行业标准；不以动态产品能力或未复现的基准支持论点。 |
已核验的来源与可用陈述
| ID | 可在本章使用的陈述 | 证据边界 | 核验状态 |
|---|---|---|---|
| REF-001 | 来源文章将 Harness 描述为围绕基础模型、协调执行、规划、工具、上下文、工件与评估的系统。 | 这是作者的工作描述；本章将以自己的图示和案例重组，不逐句翻译。 | 2026-07-15 已复核原文。 |
| REF-002 | 来源文章将 Prompt Engineering 定义为在不更新模型权重的条件下，使用输入信息引导语言模型行为的方法。 | 本章只使用这一背景定义，不复刻其示例、技巧列表或实验叙述。 | 2026-07-15 已复核原文。 |
本书的工程扩展
以下内容是本书的设计建议，必须以“本书采用”“本书建议”或案例说明，不归因给来源作者：
- 将任务描述拆为稳定指令、任务输入、上下文包和验收条件。
- 将运行过程保存为可恢复的状态与证据，而不是只保留模型文本。
- 将工具调用视为有输入、输出、错误和副作用边界的接口。
- 将验证置于成功声明之前；验证失败应进入恢复或人工升级，而不是直接总结为完成。
术语与边界
| 术语 | 本章用法 | 交由后续章节处理 |
|---|---|---|
| Prompt Engineering | 任务表达与模型引导的一层。 | 第 05 章讨论 Instructions 与 Prompt 的分层设计。 |
| Harness | 围绕模型组织任务闭环的工作性术语。 | 第 02 章细分模型、Agent、Harness 与运行环境。 |
| 验证（Evaluation） | 根据可观察证据判断任务是否满足成功条件。 | 第 17 章系统讨论评估设计。 |
| 工作记忆（Working Memory） | 本章只指出需要显式状态。 | 第 07 章讨论短期与长期记忆。 |
计划叙述与工件
章节结构
- 从“修复测试失败”的单次请求引入：文本建议与受控任务闭环的差别。
- 用原创边界图说明 Prompt、Harness、工具与验证器的不同责任。
- 以最小 Harness 示例展示指令、状态、工具、验证和记录。
- 用失败情境说明为何仅有“工具返回成功文本”不足以报告任务完成。
- 总结本章的工作定义，并交给第 02 章细分运行环境和系统责任。
计划图示
图示文件拟命名为 diagrams/mermaid/chapter-01-prompt-to-harness.mmd。图应回答“哪些责任仍属于任务描述，哪些责任必须在模型外被实现和验证”，不描绘具体产品界面或宣称通用行业架构。
计划示例
使用 examples/agent/minimal-harness.mjs：它只在内存中调用一个确定性工具，不使用模型、网络、密钥或文件写入。读者可观察到成功、工具失败和验证失败三种终态；该示例证明 Harness 的接口和验证闭环，不证明模型质量。
事实核验与版权计划
- 在正文中，REF-001 与 REF-002 的归因紧贴相关陈述出现，并同步保留在
.ai/references.md。 - 后续若提及特定产品、模型或工具能力，必须在写作当日查询官方资料；当前 Research Brief 不包含这类事实。
- 不使用来源文章中的长引文、图像或案例表格；本书图示、术语结构和示例自行创作。
- 已于 2026-07-15 复核来源链接、标题与页面日期；后续 Fact Check 阶段仍须确认正文中的每个归因句未超出本表限定范围。
风险与下一阶段输入
| 风险 | 预防措施 | 交给的阶段 |
|---|---|---|
| 把“Harness”写成无争议定义 | 使用“本书工作定义”，保留来源归因和边界。 | Chapter Outline、Technical Review |
| 将 Prompt 描述成被替代 | 明确它仍是任务表达层，只是不覆盖系统职责。 | First Draft、Language Editing |
| 最小示例被误解为真实 Agent | 在 README 和章节中说明其不调用模型、不代表生产架构。 | Example Implementation、Fact Check |
| 引入动态产品信息 | 当前阶段拒绝产品比较；需要时另建官方来源证据卡。 | 后续章节 Research Brief |
Research 完成检查
- [x] 研究问题、范围、非范围和读者目标明确。
- [x] 来源观点与本书工程扩展分开记录。
- [x] 来源链接、访问日期和可用陈述已登记。
- [x] 计划图示、示例、风险和后续阶段输入明确。
- [x] Chapter Outline、事实核验清单、示例计划和候选参考资料已建立。
- [x] 正文起草当天已重新访问 REF-001 至 REF-004；正文仅使用各来源的限定范围。