最近读完了小枣君周圣君鲜枣课堂写的《通信简史》。这本书从技术史、企业史和人物史三个维度展开没有把通信史写成一串孤立的发明而是把技术演进、企业发展与人物选择放在同一段历史中。书中保留了必要的专业细节也让没有通信背景的读者能够理解一项技术为什么出现、怎样落地又如何影响后来的系统与产业。这种叙事方式给了我很大启发。回头再看此前写下的《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] 它不是图编排的起点。LangGraph0.2 在 2024 年 8 月继续发展checkpoint和持久化方向。[24]落实到系统里图不仅要画出步骤还要保存当前进度判断哪些工作已经具备开始条件并处理多条分支返回的结果。有些框架会把某一时刻的进度保存成“检查点”从而支持暂停、等待人工决定或在失败后继续。但检查点不能撤回已经发出的邮件或已经发布的页面恢复流程时系统仍要防止同一个外部动作被重复执行。Graph不等于知识图谱。知识图谱回答实体之间是什么关系控制流图回答什么完成后才能做什么。Graph也不等于Loop一个Loop可以看作很小的循环图但差别在于依赖、状态和调度是否被显式管理。多 Agent 也不等于Graph消息协作可以没有状态图而一个 Graph 可以只有一个模型和多个普通程序步骤。如果任务只有单一目标、工具很少、整体重试便宜、不需要审批和跨时间恢复建图可能只是增加维护工作。Graph能管理关系却不能让节点里的模型自动更准确。七、五个概念如何共同落在一个网页任务上Prompt说明目标读者、内容区块、语气、手机阅读要求和交付标准解决“要做什么”。Context补入个人简介、授权照片、品牌颜色、参考风格、当前预览和上一轮反馈解决“模型凭什么判断”。Harness提供创建页面、使用批准素材、打开预览和检查链接的能力并限制访问范围解决“动作怎样进入受控环境”。Loop把预览观察带回下一轮解决“动作之后发生什么以及何时停止”。Graph只在文字、图片、组装、检查和批准出现明确依赖时介入解决“多个步骤怎样等待、汇合和恢复”。因此Prompt是Context的一部分Harness可能组装Context并运行LoopGraph可以组织Loop和确定性步骤但完全可选。五者并不是相互替代的零件。八、从 AI 到系统改变的是什么同一个模型在不同产品里表现不同通常不只因为参数不同。系统给它安排了不同的工作条件能看到的材料、能够使用的工具、权限边界、失败后的观察以及步骤之间的等待关系。这些结构不会自动提高模型智力。Context可能提供证据也可能加入噪声Harness可能减少危险动作也可能暴露错误工具Loop可能找到修正机会也可能陷入重复Graph可能让依赖可审计也可能制造状态冲突。所以应当从最小结构开始。简单问答先把Prompt说清楚。需要资料时管理Context。需要外部动作时补Harness。动作结果会改变下一步时加入Loop。只有并行、审批、局部恢复和跨时间状态值得显式管理时再引入Graph。九、实践中的识别方法问题是怎样把目标、限制和输出说清楚主要是Prompt。问题是这一轮给模型哪些资料、保留哪些历史主要是Context。问题是模型怎样访问工具、谁执行动作、谁限制权限主要是Harness。问题是动作后怎样取得观察、是否继续、何时停止主要是Loop。问题是哪些步骤并行、什么必须等待、失败从哪里恢复主要是Graph。这五个答案可以同时成立。概念的价值不在于给系统贴标签而在于让责任边界清楚。Prompt不能制造事实和权限Context不能保证资料可信Harness不能替模型作出所有正确判断Loop不能保证反复尝试收敛Graph不能把复杂流程自动变聪明。从 AI 到系统不是把模型包装得越来越厚而是把信息、动作、反馈和依赖放到合适的位置。什么时候只需要一句说清楚的要求什么时候需要整理上下文什么时候必须让程序接管权限什么时候应当停止增加结构才是理解这五个概念真正有用的地方。十、五个概念总表五个概念关注的是不同工程问题它们可以同时存在也不会自动相互替代。概念本质主要解决的问题主要产物或结构创建网页时的作用不能替代或保证Prompt一次模型调用中的任务说明怎样表达目标、限制、示例和交付形式指令、示例、输出要求、评估标准说明网页面向谁、包含什么、采用什么语气不能补齐事实、授予权限或保证正确Context本轮调用可使用的信息状态此刻应让模型看到哪些资料和反馈经过筛选、排序并保留来源的上下文包提供简介、授权照片、品牌颜色、预览和修改意见不能保证资料真实也不等于持久记忆Harness围绕模型的工程支架和执行边界模型请求怎样连接工具、权限和外部环境工具接口、权限门禁、运行状态和执行记录创建页面、使用批准素材、打开预览并检查链接不能替模型判断所有事实也不能自动保证安全Loop动作、观察和下一步判断反复发生的控制过程外部结果怎样改变下一轮以及何时停止反馈回路、状态更新、停止和升级条件预览网页、发现问题、修改后再次检查不能保证循环收敛也不能用重复代替新证据Graph显式表示步骤、依赖、分支和状态的协调结构多项工作怎样并行、等待、汇合和恢复节点、边、共享状态、检查点和批准路径协调文字、图片、组装、检查、返工和发布不能提高节点本身的准确性也不是复杂任务的必选项参考文献Petroni et al., “Language Models as Knowledge Bases?”, 2019。https://aclanthology.org/D19-1250/Brown et al., “Language Models are Few-Shot Learners”, 2020。https://arxiv.org/abs/2005.14165Liu et al., “Pre-train, Prompt, and Predict”, 2021/2022。https://dl.acm.org/doi/10.1145/3560815Ouyang et al., “Training language models to follow instructions with human feedback”, 2022。https://proceedings.neurips.cc/paper/2022/hash/b1efde53be364a73914f58805a001731-Abstract-Conference.htmlOpenAI, “Prompt engineering”清晰指令、示例与评估建议。https://developers.openai.com/api/docs/guides/prompt-engineeringAnthropic, “Claude prompting best practices”角色、指令、示例与结构化提示建议。https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practicesGoogle Cloud, “Write clear instructions”清楚指令与任务描述建议。https://cloud.google.com/vertex-ai/generative-ai/docs/learn/prompts/clear-instructionsOpenAI, “Structured Outputs”结构化输出官方文档。https://developers.openai.com/api/docs/guides/structured-outputsOpenAI, “Evals”评估提示和模型输出的官方文档。https://developers.openai.com/api/docs/guides/evalsLewis et al., “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks”, 2020。https://proceedings.neurips.cc/paper/2020/hash/6b493230205f780e1bc26945df7481e5-Abstract.htmlAnthropic, “Effective context engineering for AI agents”, 2025。https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agentsLiu et al., “Lost in the Middle”, TACL 2024。https://aclanthology.org/2024.tacl-1.9/Cloudflare Agents, “Harnesses”。https://developers.cloudflare.com/agents/harnesses/Cloudflare Agents, “Runtime”。https://developers.cloudflare.com/agents/runtime/mini-SWE-agent,DefaultAgent固定提交。https://github.com/SWE-agent/mini-swe-agent/blob/25941c89cfbc91eb40b3f8756348c91d9977d57e/src/minisweagent/agents/default.pyOpenAI Agents SDK Python, “Running agents”。https://openai.github.io/openai-agents-python/running_agents/Nakano et al., “WebGPT”, 2021。https://arxiv.org/abs/2112.09332Yao et al., “ReAct”, 2022/2023。https://openreview.net/forum?idWE_vluYUL-XOpenAI, “Function calling”。https://platform.openai.com/docs/guides/function-callingApache Airflow, “DAGs”。https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/dags.htmlMalewicz et al., “Pregel”, 2010。https://research.google/pubs/pregel-a-system-for-large-scale-graph-processing/Wu et al., “AutoGen”, 2023。https://arxiv.org/abs/2308.08155LangChain, “LangGraph: Multi-Agent Workflows”, 2024 年 1 月。https://www.langchain.com/blog/langgraphLangGraph, v0.2.0 release2024 年 8 月。https://github.com/langchain-ai/langgraph/releases/tag/0.2.0 万字干货 | 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] 它不是图编排的起点。LangGraph0.2 在 2024 年 8 月继续发展checkpoint和持久化方向。[24]落实到系统里图不仅要画出步骤还要保存当前进度判断哪些工作已经具备开始条件并处理多条分支返回的结果。有些框架会把某一时刻的进度保存成“检查点”从而支持暂停、等待人工决定或在失败后继续。但检查点不能撤回已经发出的邮件或已经发布的页面恢复流程时系统仍要防止同一个外部动作被重复执行。Graph不等于知识图谱。知识图谱回答实体之间是什么关系控制流图回答什么完成后才能做什么。Graph也不等于Loop一个Loop可以看作很小的循环图但差别在于依赖、状态和调度是否被显式管理。多 Agent 也不等于Graph消息协作可以没有状态图而一个 Graph 可以只有一个模型和多个普通程序步骤。如果任务只有单一目标、工具很少、整体重试便宜、不需要审批和跨时间恢复建图可能只是增加维护工作。Graph能管理关系却不能让节点里的模型自动更准确。七、五个概念如何共同落在一个网页任务上Prompt说明目标读者、内容区块、语气、手机阅读要求和交付标准解决“要做什么”。Context补入个人简介、授权照片、品牌颜色、参考风格、当前预览和上一轮反馈解决“模型凭什么判断”。Harness提供创建页面、使用批准素材、打开预览和检查链接的能力并限制访问范围解决“动作怎样进入受控环境”。Loop把预览观察带回下一轮解决“动作之后发生什么以及何时停止”。Graph只在文字、图片、组装、检查和批准出现明确依赖时介入解决“多个步骤怎样等待、汇合和恢复”。因此Prompt是Context的一部分Harness可能组装Context并运行LoopGraph可以组织Loop和确定性步骤但完全可选。五者并不是相互替代的零件。八、从 AI 到系统改变的是什么同一个模型在不同产品里表现不同通常不只因为参数不同。系统给它安排了不同的工作条件能看到的材料、能够使用的工具、权限边界、失败后的观察以及步骤之间的等待关系。这些结构不会自动提高模型智力。Context可能提供证据也可能加入噪声Harness可能减少危险动作也可能暴露错误工具Loop可能找到修正机会也可能陷入重复Graph可能让依赖可审计也可能制造状态冲突。所以应当从最小结构开始。简单问答先把Prompt说清楚。需要资料时管理Context。需要外部动作时补Harness。动作结果会改变下一步时加入Loop。只有并行、审批、局部恢复和跨时间状态值得显式管理时再引入Graph。九、实践中的识别方法问题是怎样把目标、限制和输出说清楚主要是Prompt。问题是这一轮给模型哪些资料、保留哪些历史主要是Context。问题是模型怎样访问工具、谁执行动作、谁限制权限主要是Harness。问题是动作后怎样取得观察、是否继续、何时停止主要是Loop。问题是哪些步骤并行、什么必须等待、失败从哪里恢复主要是Graph。这五个答案可以同时成立。概念的价值不在于给系统贴标签而在于让责任边界清楚。Prompt不能制造事实和权限Context不能保证资料可信Harness不能替模型作出所有正确判断Loop不能保证反复尝试收敛Graph不能把复杂流程自动变聪明。从 AI 到系统不是把模型包装得越来越厚而是把信息、动作、反馈和依赖放到合适的位置。什么时候只需要一句说清楚的要求什么时候需要整理上下文什么时候必须让程序接管权限什么时候应当停止增加结构才是理解这五个概念真正有用的地方。十、五个概念总表五个概念关注的是不同工程问题它们可以同时存在也不会自动相互替代。概念本质主要解决的问题主要产物或结构创建网页时的作用不能替代或保证Prompt一次模型调用中的任务说明怎样表达目标、限制、示例和交付形式指令、示例、输出要求、评估标准说明网页面向谁、包含什么、采用什么语气不能补齐事实、授予权限或保证正确Context本轮调用可使用的信息状态此刻应让模型看到哪些资料和反馈经过筛选、排序并保留来源的上下文包提供简介、授权照片、品牌颜色、预览和修改意见不能保证资料真实也不等于持久记忆Harness围绕模型的工程支架和执行边界模型请求怎样连接工具、权限和外部环境工具接口、权限门禁、运行状态和执行记录创建页面、使用批准素材、打开预览并检查链接不能替模型判断所有事实也不能自动保证安全Loop动作、观察和下一步判断反复发生的控制过程外部结果怎样改变下一轮以及何时停止反馈回路、状态更新、停止和升级条件预览网页、发现问题、修改后再次检查不能保证循环收敛也不能用重复代替新证据Graph显式表示步骤、依赖、分支和状态的协调结构多项工作怎样并行、等待、汇合和恢复节点、边、共享状态、检查点和批准路径协调文字、图片、组装、检查、返工和发布不能提高节点本身的准确性也不是复杂任务的必选项参考文献Petroni et al., “Language Models as Knowledge Bases?”, 2019。https://aclanthology.org/D19-1250/Brown et al., “Language Models are Few-Shot Learners”, 2020。https://arxiv.org/abs/2005.14165Liu et al., “Pre-train, Prompt, and Predict”, 2021/2022。https://dl.acm.org/doi/10.1145/3560815Ouyang et al., “Training language models to follow instructions with human feedback”, 2022。https://proceedings.neurips.cc/paper/2022/hash/b1efde53be364a73914f58805a001731-Abstract-Conference.htmlOpenAI, “Prompt engineering”清晰指令、示例与评估建议。https://developers.openai.com/api/docs/guides/prompt-engineeringAnthropic, “Claude prompting best practices”角色、指令、示例与结构化提示建议。https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practicesGoogle Cloud, “Write clear instructions”清楚指令与任务描述建议。https://cloud.google.com/vertex-ai/generative-ai/docs/learn/prompts/clear-instructionsOpenAI, “Structured Outputs”结构化输出官方文档。https://developers.openai.com/api/docs/guides/structured-outputsOpenAI, “Evals”评估提示和模型输出的官方文档。https://developers.openai.com/api/docs/guides/evalsLewis et al., “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks”, 2020。https://proceedings.neurips.cc/paper/2020/hash/6b493230205f780e1bc26945df7481e5-Abstract.htmlAnthropic, “Effective context engineering for AI agents”, 2025。https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agentsLiu et al., “Lost in the Middle”, TACL 2024。https://aclanthology.org/2024.tacl-1.9/Cloudflare Agents, “Harnesses”。https://developers.cloudflare.com/agents/harnesses/Cloudflare Agents, “Runtime”。https://developers.cloudflare.com/agents/runtime/mini-SWE-agent,DefaultAgent固定提交。https://github.com/SWE-agent/mini-swe-agent/blob/25941c89cfbc91eb40b3f8756348c91d9977d57e/src/minisweagent/agents/default.pyOpenAI Agents SDK Python, “Running agents”。https://openai.github.io/openai-agents-python/running_agents/Nakano et al., “WebGPT”, 2021。https://arxiv.org/abs/2112.09332Yao et al., “ReAct”, 2022/2023。https://openreview.net/forum?idWE_vluYUL-XOpenAI, “Function calling”。https://platform.openai.com/docs/guides/function-callingApache Airflow, “DAGs”。https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/dags.htmlMalewicz et al., “Pregel”, 2010。https://research.google/pubs/pregel-a-system-for-large-scale-graph-processing/Wu et al., “AutoGen”, 2023。https://arxiv.org/abs/2308.08155LangChain, “LangGraph: Multi-Agent Workflows”, 2024 年 1 月。https://www.langchain.com/blog/langgraphLangGraph, v0.2.0 release2024 年 8 月。https://github.com/langchain-ai/langgraph/releases/tag/0.2.0