Prompt、Context、Harness、Loop分别解决什么问题？

做大模型应用时，很多录友会遇到这种情况：模型用的是同一个，Prompt也改了好几轮，结果还是不稳定。问题可能出在模型看到的信息不对、工具权限不合适，也可能是任务失败后系统根本没有正确重试。

前面的《结构化Prompt设计》讲指令怎么写，《Context Engineering入门》讲本轮信息怎么编排。这篇接着往执行现场走一步：模型拿到指令和材料后，周围还需要什么，才能安全地把任务做完？

所以，先别急着继续“优化提示词”。这篇用一个报销助手，把四个经常一起出现的词拆开：Prompt、Context、Harness、Loop分别负责什么，出了问题该从哪一层查。

先说明一下：这四个词不是所有团队都采用的统一标准分类。这里把它们当作排查问题的实用分层。真实系统里它们会互相影响，Harness通常也会负责驱动Loop。

面试官问：Agent总是做错，先改哪一层？

常见回答是：“先把Prompt写得更详细，再加几个示例。”

这招有时有效，但如果模型没拿到最新报销规则，或者它没有查询订单的工具，再长的Prompt也补不回缺失的信息和能力。反过来，工具执行失败后系统不读取错误、没有重试策略，改Prompt也救不了执行链路。

先识别故障发生在哪，再选对应的工程手段。

简要回答

• Prompt：告诉模型这次要完成什么、遵守什么规则、按什么格式回答。解决“该怎么做”的问题。
• Context：给模型这次判断所需的事实、历史、状态和工具结果。解决“依据什么做”的问题。
• Harness：提供模型周围的工具、权限、运行时、校验、日志和资源限制。解决“能做什么、怎么安全运行”的问题。
• Loop：把模型判断、工具执行、结果观察、继续或停止串成多步过程。解决“失败后怎么调整，什么时候算完成”的问题。

可以用四个问题快速记忆：怎么说、看什么、能做什么、做完怎么办。

图里程序员给报销助手一张写清任务、规则和输出格式的便笺。它说明Prompt能把目标和行为边界讲明白；它不会自动补出模型没看到的报销政策，也不会替模型执行查单操作。

Prompt解决：模型该怎么做

Prompt是发给模型的指令。它适合描述任务目标、角色、约束、步骤提示和输出格式。

比如报销助手的Prompt可以写：

你是公司报销助手。
根据当前生效的报销政策和用户提供的凭证判断材料是否齐全。
缺少信息时先询问，不要猜测金额或审批状态。
按“结论、依据、缺少材料、下一步”四项输出。

这段话解决的是行为约定：模型要扮演什么角色，判断时遵循什么原则，以及回答要长什么样。Prompt写得含糊，模型就可能自行补全要求；约束彼此冲突，模型也可能不知道该听哪条。

但Prompt不是万能配置。写“查询最新报销单”，不会凭空给模型数据库权限；写“必须依据本月制度”，也不代表制度文件已经进入本轮输入。

当目标、规则或输出方式不清楚时，检查Prompt。

Context解决：模型这次看到了什么

Context是模型本轮实际拿到的信息和状态。它可以包含系统指令、用户请求、历史对话、检索文档、工具定义、工具返回和当前任务进度。Prompt通常也会作为输入上下文的一部分，所以两者不是互斥的盒子；这里区分的是“指令”与“事实材料”这两种职责。

报销助手即使知道“按当前制度审核”，也得拿到当前生效的制度版本、员工提交的发票信息和已有审批状态。若检索结果里混入旧制度，模型可能会照着过期规则给出自信的错误结论。

画面把桌面上堆满旧文件的状态，和助手拿到本次申请、当前制度及订单状态后的状态放在同一场景中。它说明Context工程关注信息的选择、时效和相关性：材料太少会缺依据，材料太杂会让关键事实被淹没。

Context Engineering因此关心：从哪里取信息，哪些信息过期或冲突，如何排序、压缩并控制Token预算。Prompt告诉模型按什么原则判断，Context决定它手里有什么证据。

如果模型重复追问已给过的信息、引用旧规则，或对着不存在的事实作答，先查本轮Context，而不是一味加长Prompt。

Harness解决：模型在什么环境里行动

Harness可以理解为包住模型的运行支架。它把模型接进真实软件系统，提供可用工具，并负责权限、执行、校验和可观测性。

一个报销助手的Harness可能包括：查询员工和报销单的只读接口、上传凭证的工具、金额与币种校验、身份权限检查、超时处理、调用日志，以及对写入或提交动作的二次确认。

图中的机器人能查看申请，却被权限闸门挡在“直接打款”按钮前；金额校验员会检查格式，操作日志记录每一步。它解释Harness提供行动能力，也把高风险操作限制在允许范围内。只有说明“请谨慎操作”的Prompt，不能替代代码层的权限检查。

Harness的问题常表现为：工具根本不可用、参数和返回值设计不清、权限过宽、超时后状态不明、错误没有记录，或者本应由程序强制的规则只写在自然语言里。

模型知道怎么做却做不了，或能做不该做的事，检查Harness。

Harness不是模型本身。更换底层模型后，工具、沙箱、权限策略和校验逻辑仍然可以保留；同样的模型放进不同Harness，实际能力和风险也会不同。OpenAI对Harness Engineering的实践 (opens new window)也把工具、运行环境、代码库结构和反馈能力视为让Agent可靠完成工作的工程组成。

Loop解决：执行结果出来后，下一步是什么

Loop是多步任务的运行节奏：把当前Context交给模型，接收它的回答或动作请求，执行动作，把结果反馈给模型，再判断继续、重试还是结束。

以“核对报销并补齐材料”为例：模型先判断缺少发票抬头，系统向用户询问；用户补交后，模型再调用校验工具；工具发现票据日期不清晰，系统继续追问；信息满足要求后，流程才进入人工审批。每一步都依赖上一轮得到的真实结果。

图里第一张发票校验失败，机器人根据错误提示向用户补问；拿到新照片后重新校验，成功才把申请交给审批。它强调Loop不是“多调用几次模型”，而是让每轮结果改变下一步，并用明确条件决定何时停止。

一个可靠的Loop至少要想清楚：

• 继续条件：什么情况下还需要模型或工具再做一步？
• 重试边界：哪些错误可以重试，最多几次，是否需要退避？
• 停止条件：任务完成、达到预算、用户取消或遇到不可恢复错误时，如何退出？
• 状态传递：每轮把哪些新事实、失败原因和进度带入下一轮？

没有这些规则，Agent可能对同一个失败工具无限重试，也可能拿到半成品就宣布完成。OpenAI的Codex Agent Loop拆解 (opens new window)展示了模型请求、工具执行和结果回传如何构成持续运行的Agent循环。

结果没被检查、失败没改变下一步，问题就在Loop。

四层怎么配合：从一句需求到可验收结果

把四层放进同一个报销任务里看：Prompt规定审核原则，Context装入制度和申请材料，Harness开放受限的查询与校验工具，Loop根据工具返回继续补材料或结束任务。

层次	核心问题	典型故障	优先检查
Prompt	该怎么做？	目标含糊、格式不符、规则冲突	指令、约束、示例、输出协议
Context	依据什么做？	信息缺失、过期、冲突或过量	检索结果、历史状态、版本、预算
Harness	能做什么、怎么运行？	工具不可用、越权、异常未兜住	工具接口、权限、校验、超时、日志
Loop	怎么继续、何时停止？	重试无效、重复执行、过早结束	状态更新、反馈、重试上限、终止条件

层与层之间确实会互相影响。比如Context决定工具结果是否被模型看见，Harness负责把工具接进Loop，Loop每走一步又会产生新的Context。因此这张表适合定位“先查哪里”，不能理解成四个完全独立的模块。

出了问题，怎么少走弯路？

调试时先拿一条具体失败请求，保存当时实际发送的指令、上下文、工具调用、返回值和每轮状态。只看最终回答，通常分不清是哪一层先出错。

然后沿着下面的顺序查：

1. 模型是否理解目标和约束？检查Prompt以及实际渲染后的指令。
2. 它是否拿到了正确事实？检查Context来源、时间戳、冲突和截断情况。
3. 它能否通过正确权限完成动作？检查Harness中的工具、参数、权限和异常处理。
4. 系统是否根据结果继续并正确结束？检查Loop状态、重试次数和停止条件。

例如模型用错了旧审批规则，修法应该是更新检索或版本过滤；工具已经返回“申请不存在”，Agent却原样再查十次，应该补Loop的错误分类与停止策略；模型直接把自然语言当成付款授权，则要在Harness中增加真实权限和人工确认。

面试时可以这样回答

“我会把Agent工程拆成四个排查视角：Prompt描述任务和行为约束，Context管理模型当轮能用的信息，Harness提供工具和受控运行环境，Loop根据模型与工具反馈推进任务并判断结束。它们不是四套互不相关的标准，实际系统里会交织在一起。线上出错时，我会保留完整调用轨迹，再分别检查指令、输入信息、执行能力和反馈状态，而不是默认所有问题都靠改Prompt解决。”

录友记住这四句就够了：指令写清楚，事实给准确，能力设边界，结果能闭环。