提示、上下文、工具利用、循环：构成AI智能体的四层结构
提示词、上下文、工具与循环：构成每个AI智能体的四层结构，从提示词工程开始，每一层的存在都是因为其下层存在不足。
一个常见的疑问是：如果聊天模型只是输入文字和输出文字，那么人工智能代理是如何预订航班或编写代码的？答案可分为四个层面，每一层的存在都是因为其下层无法单独解释一个能够正常工作的代理。用简短的话概括它们的关系：没有上下文的优秀提示语就像在空房间里说出的美妙句子；没有框架的优质上下文则如同没有双手的完美计划；没有循环机制的完整框架则相当于技术娴熟的工人，仍需有人不断告诉他们“接下来做任务”。
第一层：提示语
这里的处理单元是单个输入。模型不会记住调用之前的任何信息，因此提示语必须包含所有所需内容：角色设定、背景信息、指令、示例以及输出格式，所有这些都要整合在一条消息中。当结果不理想时，关键在于找出出问题的部分，而非重新撰写全部内容。
可用的工具相当丰富：
- 零样本提示直接提出问题而不提供示例，期望模型能够理解。
- 少样本提示提供两三个输入-输出样本，模型会从中寻找模式进行匹配。
- 思维链提示要求模型先逐步推理，这对数学、逻辑及多步骤问题有明显帮助。
- 角色提示，如“你是一名资深编辑”或“你是一名持怀疑态度的审稿人”，可以改变语气和严谨程度。
归根结底，这一切都依赖于良好的指令，就像一封条理清晰的邮件一样，其目的只是回答一个具体问题：针对当前这个请求，应该使用哪些词语？一份精心撰写的科研总结提示语能够生成结构清晰、毫无冗余的精准结果。
问题出现在后续请求中。如果在同一对话中提出与三条消息之前的内容相关的问题，模型可能会完全忽略它，反而自信地回答一个略有不同的问题。它似乎记不住自己所处的“对话场景”。由此可见，一个好的句子虽然必要，但还不够，提示语之外还缺少某些关键要素。
为何不继续编写更好的提示词呢？因为提示词工程原本就是为一次性任务设计的：提出问题、得到答案，任务完成。而一旦目标需要多步骤执行、记忆事件、使用工具，或是无需人工逐条输入指令即可运行，那么巧妙的句子就不再是瓶颈。真正的瓶颈变成了其周围的种种因素。提示词的重要性依然存在，只是不再占据主导地位。
第二层：上下文
在这里，每一步中模型窗口内保留的内容即为处理单元。窗口大小是有限的，而可用信息却无限，因此筛选变得至关重要。如果没有筛选机制，重要细节就会被过时的工具输出和旧对话记录所掩盖，模型的注意力也会随之下降。筛选者需要决定保留什么，压缩那些有用但体积庞大的内容，并丢弃其余部分。关键在于懂得舍弃什么，而非试图塞进更多信息。
模型所处的环境有一个名称：上下文。这意味着在某次交互中模型所能看到的所有内容，而不仅仅是提示词——还包括系统指令、检索到的文档、工具定义、对话历史、长期记忆以及之前的工具输出。上下文工程可以概括为通过精心筛选模型所看到的内容来获得更好的结果。提示词设计关注的是该使用哪些词语，而上下文工程则关注模型在当前时刻掌握了哪些信息。
用建筑行业的一个类比来说明会更清楚。即便请来承包商工作一天，也能交给一份措辞完美的工作指令，但如果没有平面图、许可记录以及昨天的检查记录，这些措辞也无法解决问题。承包商会自信地做出错误操作。这正好对应了上文提到的后续失败情况：模型并非愚蠢，只是信息不足。大多数代理系统的失败都是因为缺乏上下文信息，而非模型本身的问题。模型本身运行正常，只是没人提供平面图而已。
显而易见的解决办法是向模型提供所有信息：完整的对话内容、每份文档以及以往的所有交互记录。信息越多，答案就越准确。然而实践者们发现了相反的现象，并为其起了个名——上下文腐败。即便模型拥有巨大的上下文窗口，当其中充斥着仅有微弱相关性的内容时，其性能也会明显下降。模型并非真的没有存储空间，而是有效信号被噪声淹没，那些无关的细节开始被当作重要信息处理。更好的做法是提供正确的文件夹，而非整个文件柜。用一句话概括这种原则，就是“精选而非堆积”：决定哪些内容应该被纳入模型处理范围，同样重要的是，也要明确哪些内容应被排除在外。
即便房间布置得再完美，第二面墙也会很快出现。完美的环境能让人想出下一步的绝佳方案，但模型就此停止了。它无法打开文件、运行代码或检查方案是否有效。这就好比拥有完美平面图的工人却没有双手。
第三层：控制框架
现在的处理单元就是机器本身。单纯的模型只能生成文本，而控制框架通过三个阶段将其转变为能够执行操作、自我检查工作并从故障中恢复的实体：
- 收集：整合所需资源。
- 执行：运行模型，调用工具或子代理。
- 验证：通过测试或评判标准检查输出结果。
一旦出现故障，整个循环会利用更新后的环境重新尝试。正是这种差异区分了调用API与运行智能体。
一个实用的公式：智能体 = 模型 + 工具集。模型周围的一切都属于工具集，包括代码、配置以及执行逻辑等。这涵盖了可调用的工具、可读写的内存、允许执行的操作限制、决定下一步行动的协调机制，以及会持续存在于会话之外的状态。
这个词用得很贴切。马虽然力量强大，但没有马具就无法耕作，因为马具和缰绳能将它的原始力量转化为有用的劳动。把马换成模型：模型拥有智能，但如果没有工具、内存、约束机制以及协调系统，这种智能就无处发挥。
有一点能改变整个局面。该框架并不会让模型变得更聪明。用更好的模型替换它，框架依然保持不变，因为它只是底层的一个可插拔组件，而非核心所在。它所起的作用是提供结构：一个本身没有状态的智能模型，会变成一个封闭系统中的组成部分，该系统能够执行操作、检查结果，并在今日结束之处继续推进到明日。
这也解释了为什么人工智能会在不同会话间似乎记得某些内容。实际上模型并没有真正记住，而是由框架将相关内容记录在某处，之后再传递给模型。每次模型调用都是从零开始，框架通过调取昨天的记录、今天的任务列表以及文件系统的状态，在模型开始思考之前将这些信息作为上下文提供出来，从而伪造出连续性。因此，上下文设计与框架设计是紧密关联的，因为框架决定了每次调用时要整合哪些上下文。
第四层：循环机制
拥有工具和记忆功能的模型似乎已达到极致。智能体还需要什么吗？心跳功能。循环机制是最新添加的层次，目前仍在人们不断构建它的过程中确定其名称。
这就是其中的差距。即便使用了完整的操作套件，仍需有人坐在键盘前决定智能体下一步该做什么：输入提示词、查看结果、选择下一个提示词，如此循环。也就是说，始终需要人类介入，一次一轮地处理任务。
循环工程将这种手动来回操作替换为能够自动驱动整个循环的系统：思考、行动、观察结果、选择下一步动作，然后再次重复，中间无需人工重新输入指令。这就好比开车与设置定速巡航的区别——人们不再需要每秒都踩油门，而是预先设定好巡航速度和停止条件。
一个具体的例子能让这一点更清晰。负责修复错误的程序员会先阅读错误信息，制定计划，修改代码，然后运行测试套件。如果测试仍然失败，它就会调整方法，再次修改代码并重新运行测试。只有当测试通过，或者经过足够多次尝试后仍无法解决问题时，它才会向人类求助。每一个这样的循环都是一次迭代，而其间并没有人手动输入“再试一次”这样的指令。
可能会出现什么问题呢？在没有监督的情况下运行的循环可能会更快地重复同样的错误，而且一段时间内没人会察觉。因此，精心设计的系统会在循环中加入评估机制：设置检查点，偶尔让另一个模型充当评判者，根据标准对结果进行评分。只有通过评估后，循环才会认为任务已完成。一旦没有人在监督每一步，验证就不再是可选的，而成为循环工作内容的一部分。
四者结合
提示就是一次性告诉某人该做什么。上下文则确保他们在开始工作前桌上已有正确的文件夹。辅助装置为他们提供双手、工具以及能延续到周末的记忆。循环机制意味着不再需要站在他们身后监督：他们自己工作，检查成果，出错则重新尝试，只有真正完成时才会来找你。
这四个层层递进的问题，前一个问题无法回答后一个问题。合在一起，就构成了现在人们简单称之为“智能体”的东西，仿佛这本来就是显而易见且永远如此简单的。其实并非如此。每一层之所以变得清晰，都是因为有人不断追问原因，直到前一层级的局限显现出来。