1. Agent LLM 上下文 工具你的原话我们现在所说的 Agent 其实就是 LLM 上下文 工具也可以理解为 LLM Harness。评分8.5/10。整体正确但第二个等式不够严谨。第一个公式是一个很好的入门抽象LLM理解输入、生成输出、提出行动Context / 上下文向模型提供完成当前任务所需的信息Tools / 工具让系统能够执行外部操作、获得结果Agent 运行系统还需要执行循环、状态管理和停止条件等机制不过更完整的理解是Agent 不仅需要模型、上下文和工具还需要一个运行时控制机制把模型的决策转化为实际行动并根据执行结果决定下一步。例如模型生成了一个get_weather(Tokyo)的工具调用请求并不意味着东京天气已经查到了。还需要程序识别模型返回的是工具调用请求。检查工具名称和参数是否合法。执行对应函数。把函数结果交给模型。决定继续执行还是结束任务。这部分就是 Agent 的运行时机制也是 Harness 需要负责的重要工作。至于你写的LLM Harness问题在于 Harness 本身通常就包含上下文构建、工具接口、执行循环和其他运行时机制因此不能简单地认为它与上下文、工具是完全并列且互不包含的组件。2. LLM 负责理解、推理、选择下一步行动你的原话LLM模型就是起到一个理解推理选择下一步行动的作用。评分9/10。基本正确。但这里需要补充一个关键认识LLM 不只是一个负责思考的模块它本质上仍然是根据输入生成输出的模型。例如你向模型发送Python运行messages [ {role: system, content: 你是旅行助手}, {role: user, content: 帮我查东京天气} ]模型可能生成普通文本东京是日本的首都……也可能根据接口支持的工具定义生成结构化工具调用JSON{ name: get_weather, arguments: { city: Tokyo } }这里要注意模型可以判断应该调用什么工具。模型可以生成工具名称和参数。模型不会仅仅因为生成了这段 JSON就自动执行 Python 函数。真正执行函数的是外部程序。另外模型输出的推理过程也不一定会完整展示给你。不同模型和接口对推理内容的提供方式不同不能认为所有模型都会返回可见的完整思考过程。你需要建立的边界是模型生成决策或行动请求运行时系统负责执行并管理后续流程。3. 模型的聪明来自把数据放进上下文、把操作封装成工具你的原话许多模型所谓的聪明就是把任务所需的数据纳入上下文把完成任务所需的操作封装成工具。评分8/10。方向正确但你把两个不同层次的能力混在了一起。这一句话里有两个正确的工程思想第一把相关数据提供给模型。例如你希望模型根据用户的旅行偏好规划路线就要给它提供相关偏好、目的地信息、预算等数据。第二把外部操作封装成工具。例如把天气查询、数据库搜索、文件读取等能力封装成函数让模型能够请求程序调用。但需要纠正的是模型本身的能力不完全来自上下文和工具。模型还具有通过训练获得的语言理解、模式识别、知识关联和推理等能力。上下文和工具的作用是让这些已有能力更好地服务于具体任务。可以区分成三个层面层面决定什么模型能力模型原本能够理解和生成什么上下文工程模型当前能利用哪些信息工具与运行时模型能请求系统执行哪些操作举个例子。你让一个没有天气查询工具的模型回答东京今天的天气。它可能只能根据已有知识猜测或者坦诚表示无法获取实时天气。给它提供天气工具后它可以请求查询最新数据。这里不是模型突然学会了气象学而是系统让它能够访问外部信息。同样如果上下文里没有某个用户的预算信息模型也不能凭空可靠地知道这个预算。记住模型能力、当前可用信息、外部行动能力是三个相关但不同的东西。4. 上下文是眼睛包含五类内容你的原话上下文起到一个观察环境历史记忆任务状态的这个功能他是眼睛。包含系统提示词工具定义用户消息模型回复工具执行结果。前二者是静态前缀后三者是随着交互不断增长的。评分7.5/10。这是你最值得进一步修正的部分。首先“上下文是眼睛”是很好的比喻。模型只能根据当前实际收到的信息进行判断。即使某个信息存在于数据库里只要系统没有把它取出来并放进模型可用的输入中模型就不能直接利用它。但是上下文不完全等于眼睛。环境观察例如天气查询工具的返回结果。历史记忆例如之前的聊天记录。任务状态例如已经完成了哪些步骤。指令与约束例如必须使用指定工具不能超出预算。这些都可以进入上下文。更重要的是你对“五类内容”的划分可以作为一个入门模型但不能把它当作固定的协议结构。你的分类中有两个细节需要修正问题一前两者是静态前缀后三者动态增长并不总是成立。系统提示词往往相对稳定工具定义也可能相对稳定但两者都可以动态变化。例如系统提示词可以根据任务类型动态选择。工具列表可以根据权限或任务动态调整。用户消息、模型回复和工具结果通常会随着交互变化。所以更准确的分类是内容通常的变化情况系统提示词相对稳定也可以动态变化工具定义相对稳定也可以动态变化用户消息随交互变化模型回复随交互变化工具执行结果随执行变化问题二上下文不等于完整的长期记忆。这是一个很重要的区别。假设你的旅行 Agent 记住了user_memory { interests: [历史, 文化], budget: 3000元 }这些信息可以保存在数据库或其他持久化存储中。下一次用户发起新任务时系统读取这部分记忆再把它放入模型上下文。完整流程是持久化记忆数据库、文件、向量库等记忆检索与上下文构建筛选当前任务需要的信息模型收到的上下文当前这次调用实际可见的信息因此记忆可以是持久化保存的信息。上下文是当前模型调用所使用的信息。记忆管理决定保存什么、检索什么、何时更新。三者相关但不是同一个概念。还有一点工具定义有时会以接口规范的形式提供给模型但具体实现代码并不一定在上下文里。模型需要知道如何使用工具不代表它能够看到工具函数的完整源码。5. 工具调用的四步流程你的原话上下文中声明工具。2. 模型决定调用什么工具。3. 工具执行完后结果追加到上下文中。4. 模型基于结果回复。评分9.5/10。这是你这段话里理解得最好的一部分。你的流程已经抓住了工具调用的核心。更严谨一点可以补充参数验证、执行失败和继续调用等情况。① 注册并声明工具告诉模型工具的名称、用途和参数格式② 模型生成工具调用请求例如 get_weather(cityTokyo)③ 运行时验证并执行检查参数、权限和执行结果④ 将结果交回模型模型据此继续决策或者生成最终回答如果任务尚未完成可以再次调用工具形成循环。特别注意两个细节。第一模型决定调用工具不等于模型直接执行工具。这是整个 Agent 机制最重要的边界之一。第二工具调用不一定只发生一次。比如旅行 Agent查询东京天气。查询景点开放时间。查询景点之间的交通。根据结果安排路线。输出计划。整个过程可能经历多轮模型调用与工具执行。你已经理解了基本闭环接下来真正需要做的就是从代码中找出每一步具体由哪个函数完成。6. ReAct、Plan-and-Solve、Reflection 三大范式你的原话除去模型选择智能体的不同就主要体现在这些范式的构建上了是想做看的循环是先拆分问题执行在汇总还是执行之后反思在优化。评分8/10。基本理解正确但要注意它们并不是三个互斥的 Agent 类型。你的概括是准确的加入收藏ReAct边观察边行动Reasoning Acting模型根据当前信息判断下一步行动执行工具再利用返回结果继续行动。思考 → 行动 → 观察 → 思考……加入收藏Plan-and-Solve先规划再执行Planning Execution先把复杂任务拆成子任务再按计划执行最后汇总结果。规划 → 执行 → 汇总加入收藏Reflection执行后反思和改进Evaluate Refine对已有结果进行评估识别问题必要时修改或重新执行。生成 → 评估 → 修正 → 再评估但有三点需要进一步理解。第一三种范式不一定只能选择一种。一个 Agent 完全可以先规划任务再使用 ReAct 完成每个子任务最后通过 Reflection 检查结果。第二Reflection 不一定真的能提升结果。反思本身也是模型生成的内容。如果没有客观标准、测试工具、外部反馈或可靠的验证机制模型可能只是重复自己的错误。第三它们不是 Agent 的全部设计空间。即使两个 Agent 都采用 ReAct也可能因为以下方面而表现不同使用的模型不同。可调用的工具不同。上下文构建策略不同。任务状态管理不同。错误恢复和停止条件不同。是否有权限控制、验证与人工确认。因此你最后那句话可以调整成Agent 的行为方式不仅由模型决定也受到控制流程、上下文构建、工具设计和运行时机制的共同影响。三大范式是理解控制流程的经典入口而不是 Agent 设计的全部。7. Harness 是模型之外的竞争力你的原话Harness 就是这个模型之外的竞争力他的核心就是上下文工具接口外加约束验证纠错。评分8/10。这是一个很有潜力的工程认识。你已经意识到一个重要事实即使使用同一个模型不同的外围系统也可能带来很大的实际表现差异。例如两个系统都使用同一个大模型来完成旅行规划。系统 A把用户问题直接发给模型。让模型自行组织答案。系统 B读取用户偏好和预算。提供天气、景点和交通工具。验证工具参数。检查预算与开放时间。发现错误后重新规划。对无法确定的信息明确标注。两者使用同一个模型但系统 B 有机会得到更可靠、更符合约束的结果。不过要纠正你对 Harness 的两个潜在误解。第一Harness 不只是上下文和工具接口。在 Agent 工程语境中Harness 通常还可能包含运行循环和任务调度。状态与记忆管理。工具权限与执行隔离。超时、重试和异常处理。结果验证与终止条件。日志、监控和评估机制。不同团队对 Harness 的具体边界定义可能不完全一致但它通常指围绕模型构建的运行和控制系统。第二Harness 好不代表一定能让结果变好。如果上下文构建错误、工具设计不合理、验证标准有问题Harness 反而可能让错误更稳定地发生。因此真正重要的不是“给模型加更多东西”而是让模型在正确的信息、合适的工具和可靠的执行约束下完成任务。现在最需要纠正的四个认知认知一上下文不等于记忆记忆可以存储在外部上下文是当前模型实际接收到的信息。认知二模型请求调用工具不等于工具已经执行工具调用请求与实际执行之间需要运行时程序进行连接。认知三三大范式不是互斥的技术分类它们是不同的任务组织和控制思路可以组合使用。认知四Harness 不只是 Prompt 加工具它还涉及执行、状态、验证、异常恢复、权限和停止条件等工程机制。我对 Agent 的理解Agent 可以理解为以 LLM 为核心、通过上下文获取信息、通过工具与外部环境交互并由运行时系统组织执行流程的应用系统。1. 三个核心组成LLM决策与生成。模型根据当前输入生成文本或结构化行动请求可以完成语言理解、推理和下一步行动选择但生成工具调用请求并不意味着工具已经执行。Context当前任务的信息环境。上下文是当前模型调用能够使用的信息通常包含系统指令、工具定义、用户消息、历史交互、工具结果和任务状态等。上下文会随着任务推进而变化但不一定每次都无限增长。Tools外部行动能力。工具将查询数据、访问接口、操作文件等能力封装为可调用的接口。模型提出工具调用请求运行时系统负责参数验证、权限检查和实际执行再将结果交回模型。2. 工具调用闭环向模型提供工具定义。模型生成工具调用请求。运行时系统验证参数并执行工具。将执行结果加入后续上下文。模型根据结果继续行动或生成最终回答。这个过程可以循环多次直到任务完成、达到停止条件或发生无法恢复的错误。3. 三种经典控制范式ReAct根据观察进行推理和行动通过多轮交互逐步完成任务。Plan-and-Solve先拆解任务、制定计划再执行子任务并汇总结果。Reflection对已有结果进行评估并根据反馈决定是否修正。这些范式并不互斥可以组合使用也不是 Agent 所有设计方式的总和。4. HarnessHarness 是围绕模型构建的运行和控制系统。它可以负责上下文构建、工具接口、执行循环、状态管理、权限控制、异常恢复、结果验证和终止条件等。模型提供基础能力Harness 则决定这些能力如何被组织、约束和执行。良好的 Harness 能提升系统的可靠性和任务完成质量但效果仍取决于具体设计和验证。