万字干货 | Prompt、Context、Harness、Loop和Graph：从AI到系统

最近读完了小枣君（周圣君，@鲜枣课堂）写的《通信简史》。这本书从技术史、企业史和人物史三个维度展开，没有把通信史写成一串孤立的发明，而是把技术演进、企业发展与人物选择放在同一段历史中。书中保留了必要的专业细节，也让没有通信背景的读者能够理解一项技术为什么出现、怎样落地，又如何影响后来的系统与产业。

这种叙事方式给了我很大启发。回头再看此前写下的《Prompt、Context、Harness、Loop 和 Graph：从 AI 到系统》，文章虽然试图说明模型能力与系统能力之间的差别，但仍有不少地方需要重新推敲。有些概念被归纳得过于整齐，有些工程实践与系统部件之间的边界没有讲清，个别表述也没有严格区分行业术语、具体实现与本文为了说明问题所作的分类。

因此，这次重写不再停留在五个术语的表面定义上，也不把 Prompt、Context、Harness、Loop 和 Graph 排列成一条从低到高的升级路线。我会把它们放回各自形成和发展的背景中，说明每个概念是什么、解决什么问题、依靠什么逻辑发挥作用，今天又被怎样使用。

下文将分别梳理五个概念的发展脉络、核心原理、常见方法和相互边界，并用“创建一个个人网页”贯穿说明：Prompt 怎样表达任务，Context 怎样组织信息，Harness 怎样连接模型与外部动作，Loop 怎样利用反馈继续工作，Graph 又怎样协调分支、等待和恢复。论文、官方文档和开源项目只作为这些判断的证据。最终要讨论的不是五个术语怎样排列，而是它们如何共同把一次模型回答组织成一个可执行、可反馈、可控制的系统。

一、先说明：这不是五代技术

Prompt、Context、Harness、Loop 和 Graph 经常一起出现，是因为一个模型要从回答问题走向参与完成任务，确实会遇到表达、信息、执行、反馈和协调等不同问题。**它们不是五层楼，也不是五代产品。**通过输入模板和示例引导模型的实践，早于 Prompt Engineering 这个名称的流行；Context Engineering 是近年开始被更多工程讨论用来概括的一类信息组织工作；Graph 则来自更早的工作流和状态机传统。它们会重叠，也可以被同一个程序同时承担。

为了让后面的讨论有一条主线，设想一个普通任务：请 AI 帮你制作一个个人网页。网页要介绍你的经历，放一张经过授权的照片，适合手机阅读，语气不要夸张，最后需要你确认才能发布。这个任务不要求读者懂编程，却足以暴露五个概念各自处理的问题。

二、Prompt：把任务说成可执行的要求

它是什么

Prompt 是一次模型调用中的输入说明。它可以包含任务、限制、示例、语气、输出形式和角色范围。它首先是一种信息表达，不是权限，也不是外部世界本身。

如果只说“帮我做一个个人网页”，模型还不知道网页面对谁、重点介绍什么、应当怎样写、交付到哪里。更好的 Prompt 会说明读者是谁，页面需要哪些内容区块，语气是克制还是活泼，手机上要容易阅读，以及交付时要包含什么。它把人的意图压缩成模型可以据此组织回答的条件。

作用、历史和边界

Prompt 主要解决歧义。它让系统知道当前要完成哪件事，也让评价结果有一个参照。示例则进一步说明希望模仿的结构和尺度。不过，示例只能告诉模型什么样的回答更接近要求，不能替代真实材料。

让输入形式影响模型输出，并不是聊天机器人出现后才有的做法。2019 年的 LAMA 研究用完形填空模板测试预训练模型能否从语言形式中表达事实知识，可以看作今天 Prompt 实践的一段技术前史，但不能说它发明了现代 Prompt Engineering。[1]

2020 年 GPT-3 论文展示了 zero-shot、one-shot 和 few-shot 的 in-context learning。模型可以根据任务说明和示例，在不更新参数的情况下完成不同类型的任务。[2] 这让“怎样组织输入”成为更明显的工程问题，但 GPT-3 并没有发明 Prompt Engineering。2021 年至 2022 年的《Pre-train, Prompt, and Predict》系统梳理了 prompt-based learning。[3] InstructGPT 则提醒人们，instruction tuning 与用户设计 Prompt 不是一回事，前者改变训练后的行为倾向，后者设计某次调用的输入。[4]

网页任务的 Prompt 可以说明目标读者、内容区块、语气、手机阅读要求和交付标准，也可以明确“没有确认的经历不要补写”“照片只能使用已授权版本”。这些要求会改变模型的写作方向，却不会自动把履历送进来，也不能单独阻止系统使用另一张照片。资料属于 Context，动作和权限属于 Harness。

Prompt 是 Context 的一部分，但两者不等同。Prompt 偏向怎样表达当前任务，Context 关注这一步究竟让模型看到哪些信息。Prompt 不能制造事实和权限，也不能保证模型一定遵守自然语言规则。把所有失败都归因于提示词，常常会掩盖材料缺失、工具未执行或没有验收环节。

核心原理与常见方法

模型每次生成都受当前输入条件影响。指令、示例、限制和格式要求，会改变它面对的任务模式，因而改变可能的回答；它们不会修改模型权重，也不会把猜测变成事实。Prompt Engineering 的核心，不是寻找一句神奇口令，而是把任务对象、判断标准和交付形式表达得足够清楚。

初学者可以用 RTF 做一个非正式检查表：Role、Task、Format，分别是角色、任务和格式。**RTF 不是标准，也不是成功保证。**官方文档分别支持清楚的角色和指令、具体任务、输出格式与示例，但并没有把 RTF 认证为一个完整方法包。[5][6][7]

网页任务可以这样写：

Role：你是负责个人主页内容整理的编辑，语气克制，不夸大经历。
Task：根据我提供的经历，组织一页面向招聘者的个人网页。保留事实，分成简介、经历和联系方法；缺少资料时列出问题，不要自行补写。
Format：先给出页面结构，再给出每一栏的文字。最后列出待我确认的事实和图片，不要直接发布。

这里的 Role 主要限定观察角度、语气和取舍，不会凭空赋予模型专家能力。Task 要说明对象、动作、约束和完成条件；“写一段介绍”不如“根据已确认履历写 120 字简介，不增加未经证实的成果”明确。Format 规定呈现方式，例如表格、标题或结构化字段，但格式正确不等于语义正确，更不等于事实真实。

RTF 之外还有几种常见方法。Few-shot 是给出一两个输入与理想输出，让模型看见具体范例；它补充的是抽象说明不容易表达的尺度和样式，不等于训练模型。分隔符和分区标题把“任务”“材料”“限制”“待确认项”分开，减少不同文字之间的混淆，但分隔符不是安全边界。结构化输出要求结果符合预先约定的字段或数据形状，方便程序检查；它能减少格式解析问题，不能保证字段内容正确。评估则用一组代表性案例和明确标准比较不同 Prompt，避免只凭一次感觉选择写法。OpenAI 的 Prompt Engineering、Structured Outputs 和 Evals 文档分别给出了这几类实践的官方说明。[5][8][9]

Prompt 方法的共同边界是：它们改变输入呈现，不改变模型参数，不补齐缺失证据，也不替代权限和独立验收。RTF 适合帮助人把要求写全，却不是算法、标准或成功保证。

三、Context：决定这一步让模型看到什么

定义与作用

Context 是一次调用可用的信息状态。它通常包括 Prompt、历史消息、项目规则、检索结果、工具说明、工具返回、用户资料和任务中间状态。“上下文窗口”只描述一次可以放入多少文字或其他输入，不等于系统已经选好了信息，更不等于模型能稳定使用每一处信息。

Context Engineering 关注材料的选择、排序、更新和淘汰。一个系统可能拥有很多资料，但下一步真正需要的只有其中几项。它要先找到候选内容，再判断哪些有关，保留来源和时间，必要时压缩旧历史，并把工具刚返回的观察放进下一轮。

核心原理与组装逻辑

Context 的核心不是“把更多东西塞给模型”，而是为当前一步组装一份有用、可追溯、成本可接受的信息包。Prompt 已经在其中，但还要和规则、事实材料、历史状态、工具结果及最新反馈一起决定下一步。选择材料时至少要问五件事：是否与当前任务相关，来源是否有权威性，内容是否足够新，能否追溯原出处，以及加入它的成本是否值得。

例如，网页任务的上下文包可以包括已确认的个人简介、授权照片、品牌颜色、目标读者、当前预览和上一轮“手机上文字太小”的反馈。旧的候选照片和已经解决的反馈可以压缩或移除。另一边，若任务是“根据会议记录写一封客户邮件”，同一句 Prompt“请写一封简洁、礼貌的邮件”在不同 Context 下会产生不同结果：放入会议确认的交付日期和客户异议，邮件会围绕承诺与回应展开；放入内部讨论和未确认的猜测，邮件就可能把内部意见误当成对外事实。

组装过程可以先用普通话描述：先保留必须遵守的规则和本轮任务，再挑选与对象最相关的材料，最后加入最新反馈；每项材料都带来源，冲突时优先更权威、更新且能核验的版本。用步骤表示就是：

必须遵守的规则
+
本轮任务
+
与任务相关的材料
+
更权威、更新且可追溯的来源
+
最新反馈
↓
本轮 Context

这个逻辑仍然需要人工或程序定义“相关”“权威”和“新”。Context 组装得再整齐，也不能保证材料没有错误，不能保证模型充分利用每条信息，更不能把外部数据自动提升为指令。

2020 年的 Retrieval-Augmented Generation 研究把先检索外部知识、再辅助生成作为明确方法提出。[10] 论文当时并没有使用今天流行的 Context Engineering 这个总称，把 RAG 回溯性地改名会混淆实践和后来形成的术语。随着对话变长、工具增多和任务持续时间增加，系统还要管理状态、历史、工具说明、压缩、缓存和淘汰。Anthropic 在 2025 年的工程文章中用 Context Engineering 概括这类工作，帮助术语获得更清楚的公共表达。[11] 这属于重要的阐释和推广，不是发明，也不是全行业标准。

长上下文同样有边界。2024 年发表的 Lost in the Middle 研究显示，在特定模型和受控任务中，关键信息放在长输入的不同位置，会影响模型使用它的效果。[12] 它不等于所有模型都遵循同一条位置规律，却说明容量和有效利用不是一回事。

网页例子与边界

制作网页时，Context 可以包括个人简介、授权照片、品牌颜色、参考网页、当前预览和修改意见。系统还应知道哪些资料已确认，哪些只是待核实的候选。完成照片选择后，旧候选可以移出；发现手机标题太小后，这条观察应保留到下一轮。把所有历史原样塞回去，并不等于记得更多。

Context 不是事实正确性的保证，也不是持久数据库。检索资料可能过时，网页和工具返回的文字可能夹带诱导性指令。外部内容进入 Context 后仍然只是数据，不会自动变成可信规则；跨次运行需要的状态仍要由外部系统保存。

Context 可以包含“只能使用授权照片”，却不会自己打开预览或阻止读取其他照片。Harness 负责把材料、工具和权限连接起来。两者常常由同一套程序管理，但负责的问题不同。

四、Harness：模型周围的工作台

定义与发展背景

Harness 没有全行业统一的定义。本文用它指围绕模型、负责准备输入、暴露工具、执行动作、管理权限和状态、保存轨迹并处理运行限制的一组工程支架。它可以是一个模块，也可以分散在应用服务、工具层和运行时中。

可以借用软件工程里的“测试支架”来理解 Harness。测试支架为被测对象准备环境、输入和检查方式，Agent Harness 则为模型准备工作环境，并把模型请求连接到外部动作。两者只是工程角色上的类比，不能据此断言 Agent Harness 来自某一个测试工具或存在单一发明者。

Harness 解决的是“模型想做什么”和“外部世界实际发生什么”之间的断层。网页任务中，它可以允许系统创建页面、使用批准素材、打开预览和检查链接，并限制可访问范围。模型提出动作请求，程序判断是否放行，外部环境返回结果。

核心原理与执行逻辑

Harness 的基本链条是：模型提出动作，应用检查参数和权限，外部工具执行，系统记录结果，再把结果返回给模型。自然语言中的“只修改这张网页”是意图说明，不是操作系统权限；真正的权限必须由应用或工具层执行。

网页例子很直观。模型请求“使用这张照片并打开预览”，Harness 要确认照片在批准清单中、预览目标属于当前页面，然后才执行。若模型请求使用另一张未授权照片，程序应拒绝，而不是希望模型自己想起那句提示。

日历或邮件也一样。模型可以建议“下周二下午三点和客户开会”，但系统还要检查时区、日历冲突和参与者，然后在发送邀请前请求确认。模型可以写好邮件，真正发送仍是有副作用的动作，不能因为输出看起来合理就自动放行。

把这条边界写成执行顺序，就是：

模型提出动作
↓
检查参数是否完整
↓
检查权限是否允许
├─ 不允许 → 拒绝或等待人工确认 → 记录结果
└─ 允许 → 外部工具执行 → 记录结果
↓
返回给模型或用户

这里的关键不是语法，而是执行顺序：模型不能跳过检查直接改变外部世界，结果也不能只停留在模型的口头描述里。Harness 仍不能判断所有业务真相，不能保证工具没有故障，也不能把一条自然语言规则自动变成完备安全策略。

这组支架里通常还包括三类东西：工具说明负责告诉模型可以提出什么请求；受限环境负责控制它能接触哪些文件、网络或程序；检查规则负责在输入、输出或动作发生前后拦截风险。另一类常见概念 Runtime 更偏向维持身份、连接、调度、持久状态和恢复条件。具体项目可以合并或拆分这些职责。

Cloudflare Agents 的文档把Harness与 Runtime 分开描述：前者构造 Prompt、加载记忆、选择工具、处理工具结果并决定继续或停止，后者提供持久身份、状态、连接、调度和恢复。[13][14] 这是项目自己的划分。mini-SWE-agent 的固定版本把模型请求、外部动作和返回结果连成一条较小的执行流程，并记录成本、调用次数、时间和步数限制。[15] OpenAI Agents SDK Python 则用 Runner 组织工具调用、轮数限制、任务转交、历史保存和审批后的恢复。[16] 这些都是实现案例，不是永久的统一定义。

Harness 不能替模型判断网页事实是否准确，也不能保证工具结果可靠。自然语言写着“只用授权照片”，不等于程序真的能拒绝其他照片。Harness 可以提供边界，但边界本身仍需设计、测试和审计。

五、Loop：让回答接受外部反馈

Loop 是一种反复经历“准备信息、调用模型、执行动作、取得观察、判断是否继续”的控制过程。它不是让模型多写几段话，而是让动作改变外部状态，新的结果再参与下一次判断。

核心原理与停止逻辑

Loop 有效的前提是观察带来新的外部证据。网页预览显示文字太小、链接失效或照片没有加载，这些事实能改变下一轮决定；如果下一轮只是把同一段要求重新发给模型，没有新材料，就只是重复，不是反馈。

非网页例子是整理一份旅行计划：系统先生成路线，查询实际营业时间后发现周一闭馆，再调整安排。若没有查询结果，只让模型反复说“我再检查一下”，并没有增加可靠性。

停止逻辑应当和继续逻辑一样明确。可以要求每轮经过一个独立检查者：网页通过手机阅读检查就进入人工确认，路线遇到无法确认的营业时间就升级给人；同时设置最大轮数，防止无进展循环。

先用流程图看完整闭环。只有“执行动作”之后产生了新的外部观察，并且观察真正改变下一步，这条回路才有意义：

组装当前 Context
↓
调用模型
↓
模型给出候选结果或动作请求
↓
Harness 检查并执行动作
↓
取得新的外部观察
↓
独立检查结果
├─ 通过 → 结束或等待人工确认
├─ 证据不足 → 补充信息或交给人
└─ 需要修改 → 更新 Context → 回到“调用模型”

再把停止逻辑单独展开：

最多运行“预先约定的最大轮数”

每一轮：
1. 模型提出下一步
2. Harness 执行动作
3. 系统取得外部观察
4. 独立检查结果

如果通过 → 停止
如果需要人判断 → 暂停并升级
如果需要修改 → 更新 Context，进入下一轮
如果达到上限 → 停止，并报告未完成原因

真正的系统还要区分可安全重试和不可重复的副作用。Loop 可以让系统有更多修正机会，却不能保证收敛；如果观察器本身不可靠，循环只会把错误反复传递。

网页任务中的最小 Loop 是：提出页面修改，打开预览，发现文字太小或图片缺失，把观察送回下一轮，修改后再次预览，直到检查通过或交给你确认。

这种思想早于今天的 Agent 术语。2021 年 WebGPT 通过浏览工具辅助回答问题，展示了工具使用如何把网页观察接入生成过程。[17] ReAct 在 2022 年公开预印本、并于 2023 年发表为 ICLR 论文，将推理、行动和环境观察交错起来，成为有代表性的 reasoning-action-observation 范式。[18] 它不是所有 Agent Loop 的发明者，也不意味着开放环境中的循环已经可靠。

结构化的工具调用接口，让“模型提出请求、应用执行动作、结果返回模型”更容易由程序连接起来。[19] 工具调用本身不等于 Loop。只有系统把结果用于下一次决策，并规定何时结束，才形成完整循环。

网页反馈可以很具体：简介太长，照片被裁切，链接指向错误页面。每条观察都可能改变下一轮 Context。Loop 必须有最大步数、时间和成本上限，也要处理权限拒绝、重复动作、人工中断和结果不明的写操作。网络超时只有在动作可安全重复时才适合重试。

Loop 不能保证每次成功。语言反思可以总结失败，却不能替代独立检查；没有外部反馈时，反复自我纠错甚至可能改坏正确答案。Loop 也不等于无限重试或多 Agent。它需要 Harness 提供环境，但关注的是控制过程。一个 Loop 可以成为Graph中的循环分支。

六、Graph：把依赖、状态和分支写到台面上

本文说的 Graph 主要是控制流图或状态图，一种协调表示。节点表示步骤或执行单元，边表示依赖、路由、循环和汇合，还可以记录共享状态和恢复位置。它不是知识图谱，也不自动代表更高的智能。

核心原理与编排逻辑

Graph 可以拆成几类基本元素。节点表示一个可执行步骤，边规定步骤之间的先后依赖和路由条件，状态记录任务进度与中间结果。在此基础上，分支根据结果选择路径，汇合点等待多条路径完成，回边把未完成的工作送回前面的步骤；暂停点和恢复位置则让流程能够等待人工决定或外部事件，并在条件满足后继续。Graph 的价值，是把“谁先做、谁可以并行、失败后回到哪里”从隐含约定变成可以检查和执行的关系。

网页任务可以拆成“整理文字”和“准备图片”两个并行节点；页面组装依赖二者；组装后分别进入手机检查和可访问性检查；两项都通过后才等待人工确认。若图片失败，只回到图片节点，不必重做已确认文字。

日常例子是报销：先收集发票和填写金额，金额超过限额时走主管审批，否则进入财务复核；审批未完成不能付款，付款结果不明时先查询而不是重复付款。这里的 Graph 管理的是工作依赖，不是把发票内容组织成知识图谱。

下面的流程图把并行、汇合、返工和批准放在同一张图里：

整理文字 ─┐
├→ 组装网页 ─┬→ 手机阅读检查 ─┐
准备图片 ─┘ └→ 可访问性检查 ─┤
↓
两项检查是否都通过
├─ 否 → 返回对应步骤修改
│ ↓
│ 重新组装与检查
└─ 是 → 等待人工确认
├─ 退回 → 修改
└─ 批准 → 发布

Graph 仍然是可选的协调表示。只有当依赖、并行、审批、局部恢复或跨时间状态值得显式管理时，引入它才有收益。它能组织 Loop，也能包含不需要模型的确定性步骤，却不能让节点里的模型自动变准确。

Graph 的思想远早于 LLM。Airflow 的 DAG 是常见工作流例子，用一张不能回头的有向图表达任务的先后关系。[20] 2010 年的 Pregel 则展示了另一条图计算与消息传递的系统传统，后来 LangGraph 的运行方式也明确受到它的启发。[21] 今天的 Agent Graph 是把既有调度和状态思想应用到模型任务，不是从零发明图编排。

个人网页中，文字整理和图片准备可以并行，但页面组装要等两者完成。组装后要做手机阅读和可访问性检查，发布还必须等你批准。Graph 可以明确表示这些依赖，也可以让检查失败只回到对应步骤，而不是重做全部工作。

AutoGen 在 2023 年展示了以对话和消息组织多 Agent 协作的路径。[22] 这说明图不是唯一的协调方式。LangGraph 在 2024 年 1 月公开发布，把共享状态、循环工作流和图式协调带入 LLM Agent 场景。[23] 它不是图编排的起点。LangGraph 0.2 在 2024 年 8 月继续发展 checkpoint 和持久化方向。[24]

落实到系统里，图不仅要画出步骤，还要保存当前进度，判断哪些工作已经具备开始条件，并处理多条分支返回的结果。有些框架会把某一时刻的进度保存成“检查点”，从而支持暂停、等待人工决定或在失败后继续。但检查点不能撤回已经发出的邮件或已经发布的页面；恢复流程时，系统仍要防止同一个外部动作被重复执行。

Graph 不等于知识图谱。知识图谱回答实体之间是什么关系，控制流图回答什么完成后才能做什么。Graph 也不等于 Loop，一个 Loop 可以看作很小的循环图，但差别在于依赖、状态和调度是否被显式管理。多 Agent 也不等于 Graph，消息协作可以没有状态图，而一个 Graph 可以只有一个模型和多个普通程序步骤。

如果任务只有单一目标、工具很少、整体重试便宜、不需要审批和跨时间恢复，建图可能只是增加维护工作。Graph 能管理关系，却不能让节点里的模型自动更准确。

七、五个概念如何共同落在一个网页任务上

Prompt 说明目标读者、内容区块、语气、手机阅读要求和交付标准，解决“要做什么”。Context 补入个人简介、授权照片、品牌颜色、参考风格、当前预览和上一轮反馈，解决“模型凭什么判断”。

Harness 提供创建页面、使用批准素材、打开预览和检查链接的能力，并限制访问范围，解决“动作怎样进入受控环境”。Loop 把预览观察带回下一轮，解决“动作之后发生什么，以及何时停止”。Graph 只在文字、图片、组装、检查和批准出现明确依赖时介入，解决“多个步骤怎样等待、汇合和恢复”。

因此，Prompt 是 Context 的一部分；Harness 可能组装 Context 并运行 Loop；Graph 可以组织 Loop 和确定性步骤，但完全可选。五者并不是相互替代的零件。

八、从 AI 到系统，改变的是什么

同一个模型在不同产品里表现不同，通常不只因为参数不同。系统给它安排了不同的工作条件：能看到的材料、能够使用的工具、权限边界、失败后的观察，以及步骤之间的等待关系。

这些结构不会自动提高模型智力。Context 可能提供证据，也可能加入噪声；Harness 可能减少危险动作，也可能暴露错误工具；Loop 可能找到修正机会，也可能陷入重复；Graph 可能让依赖可审计，也可能制造状态冲突。

所以应当从最小结构开始。简单问答先把 Prompt 说清楚。需要资料时管理 Context。需要外部动作时补 Harness。动作结果会改变下一步时加入 Loop。只有并行、审批、局部恢复和跨时间状态值得显式管理时，再引入 Graph。

九、实践中的识别方法

这五个答案可以同时成立。概念的价值不在于给系统贴标签，而在于让责任边界清楚。Prompt 不能制造事实和权限，Context 不能保证资料可信，Harness 不能替模型作出所有正确判断，Loop 不能保证反复尝试收敛，Graph 不能把复杂流程自动变聪明。

从 AI 到系统，不是把模型包装得越来越厚，而是把信息、动作、反馈和依赖放到合适的位置。什么时候只需要一句说清楚的要求，什么时候需要整理上下文，什么时候必须让程序接管权限，什么时候应当停止增加结构，才是理解这五个概念真正有用的地方。

十、五个概念总表

五个概念关注的是不同工程问题，它们可以同时存在，也不会自动相互替代。

参考文献