从 Prompt 到 Harness 的控制范围
一句话收获：每一层扩大控制范围，但没有一层能让概率性候选自动正确。
这个场景在解决什么问题
目标（goal）是理解 Prompt、Context、Spec、ReAct、Loop 与 Harness 这六层工程对象的递进关系。观察方式是逐层增加工程对象，看每一层解决了什么新问题，又留下了什么缺口。值得单独学，是因为很多人以为"加一层魔法"就能让 AI 自动变对，但真相是每一层只是扩大控制范围，谁都不能保证概率性的候选自动正确。
先理清这条判断链（文字版）
先看最基础的三层 Prompt、Context、Spec 各自解决什么问题，再看 ReAct 如何让外部反馈回流，接着看 Loop 如何让多轮持续推进，最后看 Harness 如何把所有东西放进受控工程环境。判断链是：
- 用 Prompt 启动生成、Context 组织环境、Spec 稳定任务基线，解决表达、信息与可追踪。
- 用 ReAct 让外部行动结果重新进入判断，解决一次生成用不上新反馈的问题。
- 用 Loop 让判断、行动、观察、停止检查持续循环，支撑复杂任务多轮推进。
- 用 Harness 把上下文、工具、权限、状态、验证、预算、恢复、接管都放到模型外，实现受控。
逐层详解
第 1 步：Prompt、Context、Spec
原文：Prompt 启动生成，Context 组织当前环境，Spec 稳定任务语义基线。
白话：Prompt 是点火开关，负责把生成"启动"起来；Context 是把当前环境相关信息组织好装进去；Spec 是一份稳定的任务语义基线，让每次生成都可以跟同一份基准对比。
类比：Prompt 像开工指令"现在开始写周报"，Context 像把相关资料文件夹摆到你桌上，Spec 像一份固定的周报模板和评分标准——照着它写，好坏能对比。
举例：让 AI 写一份需求规格，Prompt 是"请生成这份功能的规格说明"，Context 装进客户原始需求和历史文档，Spec 是团队约定好的规格结构（目标、范围、异常、验收等），确保每次生成都对齐同一套标准。
为什么重要：前三层解决表达、信息与可追踪——表达靠 Prompt，信息靠 Context，可追踪靠 Spec 这条稳定基线。
怎么验证（证据点）：
- 目标可表达：Prompt 能把要做什么说清楚。
- 环境可装载：Context 能把相关信息装进去。
- 基线可比较：Spec 让结果能跟同一套基准对比。
别踩的坑（边界）：三者都不能强制业务执行——写得好、环境全、基线稳，都不等于事情真的被做成了。
落地检查：提示和基线仍需外部检查——落地时别指望这三层自己会"管住"结果，还得在外面加检查机制。
第 2 步：ReAct
原文：外部行动结果重新进入判断，下一步可以改变。
白话：ReAct（Reasoning + Acting，推理加行动）让系统不只是一口气生成完就算了——它执行一个外部动作，把结果拿回来重新判断，下一步就可以根据新情况调整。
类比：像你打电话问客服，先问第一个问题，听到回答后改变第二个问题——而不是事先把 10 个问题一次性问完。
举例：报销 Agent 先查这笔单子的预算，查到"预算不足"，于是改变下一步——不再继续填报销单，而是转去提示用户补充预算审批。
为什么重要：ReAct 解决一次生成无法使用新反馈——单次生成看不到行动结果，ReAct 让"做了→看到结果→再决定"成为可能。
怎么验证（证据点）：
- 行动候选：系统能提出要执行的动作。
- 环境结果：动作执行后环境返回结果。
- 后续判断变化：拿到结果后，下一步判断确实改变了。
别踩的坑（边界）：不需要公开模型内部思维链——ReAct 展示的是"可观察的行动和结果"，不要求把模型内部怎么想的每一步思考都暴露出来。
落地检查：只展示可观察行动和结果——落地时让系统暴露"做了什么、结果是什么"，而不是把内部推理过程当交付物。
第 3 步：Loop
原文：系统持续执行判断、行动、观察和停止检查。
白话：Loop 是把"判断→行动→观察→检查要不要停"这一圈变成一个循环，让系统一轮一轮推进，直到满足停止条件才退出。
类比：像洗碗机的工作循环——放水、冲洗、排水、再检查干不干净，反复几轮直到"干净了"这个条件满足才停。
举例：一个自动处理工单的 Agent，反复执行"读工单→查知识库→尝试解决→检查是否解决"，直到解决或轮次用尽才停止。
为什么重要：复杂任务需要多轮推进——真实任务很少一步到位，必须靠循环多轮逼近。
怎么验证（证据点）：
- 任务状态：当前推进到哪一步、什么状态。
- 轮次预算：最多允许跑多少轮。
- 停止条件：什么情况下该停下来。
别踩的坑（边界）：更多轮次可能放大错误和成本——循环不是越多越好，跑得久可能越错越多、越烧钱。
落地检查：Loop 必须有真实反馈和出口——落地时要确保每一轮都有真实的外部反馈，并且有明确的停止出口，不能无限空转。
第 4 步：Harness
原文：上下文、工具、权限、状态、验证、预算、恢复和接管位于模型外。
白话：Harness 是一套"外骨骼"，把上下文管理、工具、权限、状态、验证、预算、恢复、人工接管这些工程能力全部放在模型外面——模型只是其中的一个部件，不是全部。
类比：像赛车的安全笼和仪表盘——发动机（模型）负责输出动力，但刹车、限速、油量表、救援通道都在车架和赛道规则上，不靠发动机自觉。
举例：报销 Agent 的 Harness 里，权限系统拦住越权操作、预算系统限死花费上限、状态管理随时可回滚、人工接管按钮可随时喊停——模型只说"建议怎么做"，Harness 决定"允不允许做"。
为什么重要：Harness 将 Agent 放入受控工程环境——把开放的模型关进可控的工程笼子里，是让 Agent 真正可用的关键。
怎么验证（证据点）：
- 候选可阻断：模型的候选动作可以被拦截。
- 状态可恢复：出错后能回到之前状态。
- 完成独立验收：完成与否由模型外的独立机制验收。
别踩的坑（边界）：Harness 不能保证模型每次候选都正确——Harness 能"拦错、恢复错"，但不能让模型每次都"说对"。
落地检查：工程目标是发现、阻断和恢复错误——落地时把目标定为"能发现错误、能拦住错误、能恢复错误"，而不是"让模型永不犯错"。
落地可行性小结
本场景涉及的技术栈：Prompt、Context、Spec、ReAct、Loop、Harness，对应真实项目里的提示词工程、上下文组装、规格文档、ReAct 风格的工具调用循环、循环控制（轮次预算 + 停止条件）、以及 Harness 这一层模型外的工程框架（权限、状态、验证、预算、恢复、接管）。落地动作：把 ReAct 循环用代码写成显式循环，配上轮次上限和停止条件；把权限、预算、回滚、人工接管做成 Harness 的独立模块。常见坑：一是不设轮次预算导致循环烧钱跑飞；二是把模型内部思维链当成可交付的"证据"。检查点：每个 Loop 是否有真实外部反馈和明确出口；Harness 是否独立于模型完成验收。
回顾
- Prompt、Context、Spec 解决表达、信息与可追踪，但都不能强制业务执行。
- ReAct 让外部反馈回流、下一步可改变，但不要求公开内部思维链。
- Loop 支撑多轮推进，但更多轮次会放大错误和成本，必须有真实反馈和出口。
- Harness 把权限、状态、验证、预算、恢复、接管放到模型外，目标是发现、阻断、恢复错误，而非保证模型永不犯错。