提示词、上下文、控制机制与循环设计：AI智能体的四层结构
提示工程与上下文工程涵盖了四个层次中的两个。而 harness 和 loop 工程则控制着其余两个层次，还有一个 GitHub 分类处理的示例以及构建顺序。
来源: Prompt, context, harness, loop: the four layers of engineering an AI agent
2025年中期，Shopify首席执行官Tobi Lütke指出，与大型语言模型合作的真正关键并非提示工程，而是为任务提供足够的上下文，使其能够被合理地解决。Andrej Karpathy也持相同观点，认为这门技艺在于为模型接下来的操作在上下文窗口中精准地放入合适的信息。此后不久，在关于如何利用大型语言模型的诸多严肃讨论中，“上下文工程”便取代了“提示工程”这一术语。
一年过去了，那些致力于开发自主编程代理、问题分类机器人以及自愈部署管道的团队依然面临着同样的困境。事实证明，上下文工程只是四层问题结构中的一小部分。从最窄到最广，这四层分别是提示词、上下文、工具框架和循环机制，每一层都包裹着其内部的那层。最外层的工具框架工程和循环机制工程却最少受到关注，这很奇怪，因为目前大部分价值都集中在这两个层面。
可以把这看作四个问题：请求是如何表述的？那就是提示词。模型启动时已经掌握了什么信息？那就是上下文。模型运行后实际上能做什么？那就是工具框架。而有人何时、多频繁地调用它？那就是循环机制。如今，大部分实际价值都集中在循环机制这一层，而在一年前它还几乎没有名字。
以下是用于区分各层的实用框架以及构建顺序。该框架假设你已对 LLM API 进行过工具或函数调用；若尚未操作，请从这里开始。
实际使用中存在一种规律，解释了为何该框架如此有用：当智能体的输出不符合预期时，解决方案几乎从不在于提示词本身，而总是在更高一层。
第 1 层：提示词，即你所说的内容
提示词设计是最为基础的一层，其核心任务仅有一项：如何表述给模型的指令。
例如：系统提示词的表述方式、几组示例的呈现形式、是否要求逐步推理或仔细思考，以及答案应以 JSON 还是自由文本形式返回。这门技艺旨在通过撰写一条信息，让模型在下一步响应时按照你的要求行事。
这项工作是真实的。对于同一任务，模糊的指令与精确的指令所带来的准确性差异可能非常大。以 GitHub 项目中的任务分派工具作为具体示例。一个较弱的提示如下所示：
Look at this GitHub issue and label it.
还有一个精确的：
You are a triage agent for project X. For each issue, output JSON with:
component (one of the values in the taxonomy provided in context)
severity (critical | high | medium | low)
team (the owning team from the on-call table provided in context)
Base severity only on user-facing impact stated in the issue, not on your
own guess about difficulty. If the component is ambiguous, set
"component": "unknown" rather than guessing.
模型、工具以及其他所有要素都完全相同，但第二个提示语却能生成结构化且可解释的输出。不过要留意其中被视作理所当然的假设：它仅需在单次调用的一次轮次内即可运行，且假定分类体系与待处理任务表早已加载完毕，工具也存在，同时还有其他机制决定何时调用模型。
大多数教程仅讲解到这一步，而大多数实际的生产级智能体系统也才刚刚起步。
第二层：上下文，即模型所知晓的信息
上下文工程涉及在模型对提示语进行分析之前进入其处理范围的的一切内容，它位于提示语处理流程的上游。即便提示语毫无瑕疵，若上下文有误，依然会产生错误结果。
这包括要检索并注入哪些文档、代码文件或数据库记录，加载哪些工具架构以及为节省令牌而保留哪些内容，多少对话历史会被保留、被总结还是被丢弃，以及系统指令中对模型角色和限制的说明。
Drew Breunig在2025年总结了上下文出错的各种方式。上下文污染是指幻觉内容进入上下文窗口并不断被引用；上下文分心是指过长的上下文窗口导致模型依赖它而忽视训练中学到的内容；上下文混淆是指无关信息降低输出质量；上下文冲突则是新添加的工具或事实与现有指令相矛盾。
上下文处理同样需要成本，而编码方式会直接影响费用。据称，作为JSON数据模型的紧凑型编码格式，TOON在2026年中的测试集中使用的标记数量比JSON少约42.6%，检索准确率则处于相近水平（72.2%对71.4%）。节省的程度取决于数据结构：对于扁平的表格数据，节省比例可高达近59%；而对于混合嵌套的数据，这一比例则降至约33%；当数据完全为扁平结构时，纯CSV格式甚至能优于前两者。这些数据来自该项目自身的测试结果，因此需结合实际数据进行验证。关键在于，相同的信息以三种不同格式呈现时，不仅在成本上存在差异，其被准确读取的可靠性也有所不同。上下文工程意味着不仅要决定包含哪些内容，还要考虑如何对其进行编码。
一个简短的示例展示了问题出在哪里。想象一个持续生成泛化内容的文章生成智能体，人们花了两天时间重写提示词、添加示例与约束条件、细化角色定义，但情况毫无改善。问题从来不在提示词本身。由于有30种工具架构被预先加载到上下文中，相关的指令反而被淹没。改为延迟加载方式，即仅在智能体提出请求时才提供相应定义，无需修改提示词一字，就能提升质量。之前的努力其实是在错误的层面进行的。
如果提示词工程是选择用哪些词语，那么上下文工程则是决定在你说话之前模型能看到什么。
第三层：框架，即模型能够做什么
框架是围绕模型存在的可执行环境：模型能够获取的一切，以及能够反馈给模型的一切。
Anthropic关于构建高效智能体的著名指导提出了“智能体-计算机界面”的概念，这一概念刻意与“人-计算机界面”相对应。其观点是，应在设计智能体如何使用工具上投入与行业在设计人类如何使用软件相同的精力。
以下是分类示例中简化的工具定义：
{
"name": "apply_label",
"description": "Apply a label to a GitHub issue. Only use after reading the issue body and checking the component taxonomy.",
"parameters": {
"type": "object",
"properties": {
"issue_number": { "type": "integer" },
"labels": { "type": "array", "items": { "type": "string" } }
},
"required": ["issue_number", "labels"]
}
}
description字段负责处理上下文相关的工作。它决定了模型何时调用工具，而不仅限于模型传递哪些参数。不过，架构只是整个框架的一半。
另一半则存在于调度器中，它会用模型无法看到的元素来封装工具。审批机制会决定是让apply_label自动执行还是交由人工处理。例如每小时最多写入60个标签的速率限制，可以防止循环失控从而对仓库造成垃圾数据污染。沙箱边界则限制了工具能够操作的范围。这些封装层无需修改系统提示即可塑造工具的行为。
该框架还包括：
- 文件系统。模型可以打开、编辑、创建或删除的文件。
- 内存。信息在多轮对话中的存储与检索方式，比如修正日志、过往决策以及项目规范。
给一个普通的提示词配上合适的工具，其表现通常会优于那些拥有出色但无工具支持的提示词。如果智能体无法打开所需的文件，再好的措辞也无法让它发挥作用。先确保工具可用。
第4层：循环机制，即智能体的核心特征
循环工程是让智能体具备自主能力的机制。它会采取行动、观察结果、决定下一步该做什么，如此循环直至目标达成或触发停止条件，整个过程无需人工干预。这一层将只会使用工具的聊天机器人转变为能够独立解决问题的存在。
以下是该思路的伪代码形式。它仅用于说明，无法实际运行：像 model.decide 和 execute 这样的辅助函数并未包含在内。
def agent_loop(goal, max_iterations=10):
context = gather_initial_context(goal)
consecutive_errors = 0
for i in range(max_iterations):
action = model.decide(context, goal)
if action.type == "done":
return action.result
result = execute(action)
if result.error:
consecutive_errors += 1
if consecutive_errors >= 3:
# stuck: same approach keeps failing, decompose differently
context.add("Previous approach failed 3 times. Try a different strategy.")
consecutive_errors = 0
else:
consecutive_errors = 0
context.add(result)
return escalate_to_human(context)
寥寥几行代码便决定了关键决策：何时停止、何时改变策略、何时放弃。2026年4月，OpenAI在Codex CLI中加入/goal命令时，将这种机制融入了产品中。用户设定目标后，系统会持续运行，直到判断目标已完成或Token预算耗尽。
简单的循环会不断重试直至出现问题解决。而设计精良的循环则会察觉到陷入僵局，以不同方式拆分问题，向人工求助，或放弃无效的尝试。设计师Matt Webb在2026年3月指出，只要给智能体一个问题并配上循环结构，它最终一定能解决问题。但“最终”这一限定词恰恰体现了工程设计的精髓：包括重试次数限制、多次失败后的延迟策略，以及当单次处理受阻时的问题拆分方法。
这就是为什么这一层代表了最大的权力转移。在提示工程中，由人来编写每一条指令；在上下文工程中，由人决定模型在每次调用时能看到什么内容；在工具工程中，由人一次性构建工具，模型则可以无限次地重复使用它们。而循环工程则有所不同——由人设计一个系统，该系统负责向模型发出提示、评估结果，然后再再次调用模型，整个过程无需人在场。控制权从发出提示的人手中转移到了设计出该提示系统的人手中。
乔恩·乌德尔在2026年中期提出了一个值得记住的观点：他不喜欢“人在循环中”这一说法，因为这似乎将权力交给了机器，而实际上这依然是我们的循环，我们只是招募智能体来加入团队而已。
单个智能体上的全部四层功能：GitHub问题分类处理
想象一下，有个工作人员正在处理一个中型开源项目的新GitHub问题：为相关组件添加标签、评估问题严重程度，然后将每个问题转发给对应的团队。
- 提示词。系统提示词会指示其找到受影响的组件，按严重程度从高到低进行分级，分配合适的团队，并以结构化的JSON格式返回结果。
- 上下文信息。对于每一个决策，该系统都会提供问题的标题和内容、最新的五条评论、组件的分类体系（每季度更新一次的YAML文件）、之前类似的问题及其标签（通过向量搜索获取作为参考），以及当前负责处理该问题的人员信息。
系统每处理100个问题就会将其准确率与人工修正结果进行比较，并据此调整阈值。在类似的系统中，据称置信度阈值必须从0.85开始设定，而非原本假设的0.7，因为错误标签带来的人工处理工作量比漏标标签更多。这种校准属于循环工程：只有通过运行系统并持续观察其错误情况才能实现。
去掉任意一层功能，系统的表现都会不同。没有提示时，输出格式只能靠猜测；没有上下文时，组件名称就需要自行编造；没有配套工具时，系统虽能判断该做什么，却无法进行标注或搜索；没有循环机制的话，它就只能在一个接一个地等待有人在聊天窗口输入“处理这个问题”时才采取行动。
词汇的来源
“提示工程”这一术语出现于2022年。2023年，Riley Goodside提出将其拆分为上下文工程和提示编程，但直到2025年6月Lütke和Karpathy使用“上下文工程”一词，且Simon Willison解释了为何这一划分更为合适后，该术语才真正普及。
“利用”和“支架”这两个概念因Anthropic在高效智能体方面的研究而进入常规用语，这些研究明确了智能体与计算机之间的接口，并将工具设计视为一级工程任务。
循环工程是这四种中最新的，也没有人首创它。它是多种发展思路融合的结果：OpenAI在Codex中提出的目标驱动型循环，Anthropic将工作流（固定路径）与智能体（由模型驱动的循环）分开处理，LangChain从路由器发展到状态机再到自主智能体，此外还逐渐形成了由人类设计循环而不干预其具体执行步骤的习惯。
这里的四层划分是对这些融合用法的一种总结，并非行业标准。不过，给各层命名有助于加快问题诊断速度。通过判断问题是出在提示词、上下文、工具框架还是循环机制上，就能立即缩小搜索范围。
首先应投资何处
这些层是按范围从窄到宽排列的，但实际上应从范围最广的部分开始构建，或者说先从工具框架开始。对于首个自主编程智能体，构建顺序如下。
- 工具框架。需提供文件读写功能、Shell访问权限，以及运行测试和git命令的途径。非编程型代理则通过API调用、数据库查询或消息传递来实现相同功能，核心思路一致。
- 循环机制。即便是最简单的循环也有帮助：运行任务，检查测试是否通过，未通过则返回错误信息，尝试三次后或任务成功后即停止。仅此一点就能带来大部分自主性带来的好处。
- 上下文信息。在观察代理在循环中的运行情况后，就能知道它缺少什么，无论是代码、历史错误还是项目规范。事先猜测大多只会浪费时间。
- 提示信息。有了可用的工具框架和循环机制，所需的提示通常简短明了。此时复杂的工程工作早已在其他环节完成。
有一个例外情况。如果智能体需要生成格式严格的输出，比如用于 API 的结构化 JSON 或特定的 Markdown 格式，那么在早期阶段就设计好提示词非常重要，因为在循环执行过程中很难再修正格式问题。这属于特殊情况，并非默认情况。
新手们通常会颠倒顺序，花费数周时间设计复杂的系统提示词，而此时智能体还缺乏工具、没有循环机制，其上下文中的文件也不正确。
从提示词设计转向上下文工程，意味着人们开始认识到提供给模型的内容比请求的表述更为重要；而进一步发展到利用循环机制进行优化，则意味着：构建模型周边系统的人比与模型交流的人拥有更大的控制权。
相关阅读
- 代理上下文工程：面向机器学习工程师的分步指南：讲解如何设计大语言模型代理在每一步所看到的内容，包括信息检索、结构化上下文、记忆存储、压缩处理与评估方法，并通过一个机器学习调试代理的实例进行演示。
- 从零样本到自我一致性：实用的提示工程技术阶梯：介绍如何在零样本、少样本、分解法、批判循环和推理提示之间进行选择，通过辅助机器人的示例进行说明，同时指出何时应转而使用普通代码来解决任务。