真正的 AI Agent不只是会调用工具的大模型AI Agent 是这两年最容易被反复提起、也最容易被说乱的 AI 概念之一。做模型的人在讲 Agent做产品的人在讲 Agent做应用的人也在讲 Agent。但很多时候大家说的并不是同一件事。有人把「能调用工具的大模型」叫 Agent。有人把「能自动完成任务的系统」叫 Agent。也有人把「负责某个子任务的模块」叫 Agent。这个词被用得越来越多边界却越来越模糊。2026 年 5 月 25 日Hugging Face 发布了一篇 AI Agent 术语表文章作者是 Sergio Paniego 和 Aritra Roy Gosthipaty标题是“Harness, Scaffold, and the AI Agent Terms Worth Getting Right文章链接我放在文末了你也可以读一读原文。这篇文章系统梳理了 Agent 讨论里最容易混淆的一批概念Model、Scaffolding、Harness、Agent、Context Engineering、Policy、Tool Use、Skill、Sub-agent以及训练阶段常见的Environment、Rollout、Reward和Trainer。它的价值不在于提出了某个全新的框架而在于把很多人平时混着用的词重新放回各自的位置。也要先说明一点这不是一份「全行业唯一标准答案」。**Agent 领域的术语还在快速演化不同论文、产品和框架会用不同口径。**Hugging Face 这篇文章更像是一份实用术语地图帮助我们在讨论时少一点混乱。它的直接背景也很有代表性ICLR 2026 之后作者提到很多人都在问harness和scaffold到底是什么意思但大家给出的解释并不统一。这很重要。因为当我们讨论 Agent 时如果不先把概念边界理清后面的判断很容易跑偏。比如一个 Agent 效果不好到底是模型能力不够还是工具设计不好是提示词写得不清楚是上下文管理出了问题还是执行系统没有处理好循环、失败和停止条件这些问题背后对应的是完全不同的工程层。所以这篇文章想做一件事借 Hugging Face 这份 AI Agent 术语表把 Agent 最核心的一组概念重新串起来用尽量直白的方式讲清楚。“AI Agent 不是一个单独的模型而是一套围绕模型搭建起来的任务执行系统。如果按照 Hugging Face 原文的精细拆分可以先记住这个三层结构“Agent Model Scaffolding HarnessModel是大模型本身。Scaffolding是模型能直接依据的行为定义层。狭义的Harness是执行引擎让模型、工具和任务循环真正跑起来。不过在社区和很多产品文档里Harness也经常被更宽泛地使用表示模型之外的一切。这个时候人们会把 Agent 简化成“Agent Model Harness这里的Harness就不是狭义执行层而是模型之外让 Agent 真正运行起来的整套工程系统。若采用广义口径拆分“Harness ≈ Scaffolding 执行循环 工具路由 上下文管理 权限与异常处理 子任务编排精细公式里的 Harness 是狭义执行引擎不含 Scaffolding。其中Scaffolding是模型能直接看见的规则层比如系统提示词、工具说明、输出格式和上下文规则。Harness的狭义用法则更偏向模型看不见的执行层比如调用模型、执行工具、处理循环、重试、超时和停止条件。所以下面这些概念不是一组完全平级的零件而是理解 Agent 时需要拆开的几个视角。Model负责理解和推理。Tool是外部能力本体Tool Use是调用这些能力的过程。Skill沉淀一类任务的做事方法但它的描述会进入 Scaffolding它的运行会依赖 Harness。Sub-agent是复杂任务里的分工方式创建、调度和汇总通常由 Harness 完成。Context Engineering横跨 Scaffolding 和 Harness一部分是模型可见的上下文规则一部分是运行时的检索、裁剪、压缩和注入。Policy决定 Agent 在不同情境下如何做选择。下面我们就按这个顺序把这些概念拆开讲清楚。01 ModelAgent 的大脑但不是 Agent 本身先从最基础的Model说起。Model就是大语言模型。它的本质能力是接收输入生成输出。你给它一段上下文它根据训练得到的参数生成下一段最合适的内容。它可以做很多事理解问题拆解任务生成代码判断下一步应该搜索还是读文件按照约定格式写出一个「工具调用请求」但模型本身并不会真的执行动作。它不会自己打开浏览器。不会自己访问数据库。不会自己运行代码。不会自己记住上一次调用结束后发生了什么。模型只是在一次调用里根据当前输入生成下一段文本。所以Model是 Agent 的核心但不是 Agent 的全部。可以这样理解“Model 负责判断「下一步应该做什么」。Agent 系统负责把「下一步」真的执行出来。这也是很多人误解 Agent 的地方。一个大模型可以很聪明但只要它没有外部执行循环没有工具接入没有上下文管理它仍然只是一个聊天模型。它可以告诉你「我建议你运行测试。」但 Agent 可以真的去运行测试然后把报错读回来再继续修改代码。差别就在这里。02 Tool让 Agent 接触外部世界如果说Model是大脑那Tool就是 Agent 伸向外部世界的手。这里要区分两个词“Tool 是工具本体。Tool Use 是 Agent 调用工具的过程。Tool可以是很多东西搜索引擎浏览器数据库文件系统代码解释器Shell 命令企业内部 API第三方 SaaS 接口比如你让一个 Agent「分析这份销售数据并生成一份报告。」模型本身并不知道你电脑里的 Excel 文件内容。它需要通过文件读取工具拿到数据。如果要计算指标可能需要调用 Python 或 SQL 工具。如果要补充市场信息可能需要调用搜索工具。如果要生成最终文档可能还需要调用文档工具。这些外部能力都是Tool。但要注意模型通常不会直接执行工具。它只是输出类似这样的意图“我要调用search工具关键词是「AI coding agent market 2026」。或者“我要读取/data/sales.xlsx这个文件。真正执行调用的是 Agent 系统里的执行层。工具返回结果后系统再把结果放回上下文让模型继续判断。所以Tool Use讲的不是某个工具本身而是这条调用链路“模型提出工具调用系统解析调用请求工具执行返回执行结果模型基于结果继续推理Tool解决的是“Agent 能做什么动作但它不解决什么时候做按什么顺序做失败了怎么办这些问题需要更上层的结构。在工程实现里工具的描述通常属于 Scaffolding因为模型需要看懂工具能做什么工具的路由、执行和结果回填则属于 Harness。03 Skill不是工具而是一套方法Tool和Skill很容易被混在一起。但它们不是一回事。“Tool 是一个动作。Skill 是一套方法。比如「调用搜索引擎」是Tool。但「写一份竞品分析」不是Tool。它是一套Skill。因为它通常包含很多步骤先确定分析维度再收集竞品资料再整理功能、价格、定位、用户群再提炼差异最后形成结论这不是一次工具调用能完成的。再比如「修复一个前端 bug」。它可能包括复现问题查看报错定位相关组件分析状态流修改代码运行测试检查页面效果这些步骤背后是一整套经验和流程。这就是Skill。“Tool 关注的是我可以调用什么能力Skill 关注的是面对这类任务我应该怎么做在 Agent 系统里Skill可以被理解为一种可复用的任务知识包。它可能包含说明文档、操作流程、约束条件、示例、检查清单甚至一组专门工具。更严谨一点说Skill 也有两层“Skill 的说明、触发条件和使用规则会进入 Scaffolding。Skill 的加载、调度、工具调用和校验则依赖 Harness。这也是为什么Skill对复杂 Agent 很重要。如果没有 SkillAgent 每次做任务都像从零开始摸索。有了 Skill它就能把过去沉淀下来的方法复用起来。一个数据分析 Agent 可以有「清洗数据」的 Skill。一个编程 Agent 可以有「定位测试失败」的 Skill。一个运营 Agent 可以有「生成周报」的 Skill。Skill 越清晰Agent 越不容易乱跑。04 Sub-agent把任务交给另一个 Agent当任务再复杂一点就会出现Sub-agent。Sub-agent可以理解为“被主 Agent 调用的另一个 Agent。它不是简单工具也不只是方法文档。它有自己的上下文、自己的目标也可以自己调用工具完成子任务。举个例子。你让一个 Agent 做一份「新能源汽车行业研究」。主 Agent 可能把任务拆成几块一个 Sub-agent 负责找政策资料一个 Sub-agent 负责分析主要公司一个 Sub-agent 负责整理销量和市场数据一个 Sub-agent 负责写报告初稿最后主 Agent 再把各部分整合成一篇完整文章。这里的 Sub-agent 不是一次 API 调用。它本身也会经历「观察、判断、行动、反馈」的循环。但 Sub-agent 不是凭空出现的。在真实系统里谁来创建子任务谁来调用 Sub-agent谁来收集结果谁来判断要不要继续拆分通常都是 Harness 或更上层 orchestrator 的工作。Orchestrator可以理解为更高一层的编排器。当系统里不止一个 Agent而是多个 Agent 或多个任务单元协作时orchestrator 负责决定谁做哪部分、结果怎么汇总、失败时要不要重试或换路。在一些产品和框架里orchestrator 会被算进广义 Harness在另一些架构图里它会被单独画出来。所以可以简单区分“Tool 是动作。Skill 是方法。Sub-agent 是分工。当任务很小的时候一个 Agent 自己完成就够了。但当任务涉及多个方向、多个阶段、多个资料来源时Sub-agent 可以降低复杂度。它让主 Agent 不必把所有事情都塞进同一个上下文里。这对长任务尤其重要。05 Scaffolding给模型搭一层工作框架接下来讲一个非常关键、但经常被忽略的词Scaffolding。它本来的意思是「脚手架」。放在 AI Agent 里可以理解为围绕模型搭出来的工作框架。更准确地说Scaffolding 是模型能直接感知的那部分框架。它不是执行代码而是告诉模型你是谁、能用什么工具、输出要长什么样、什么时候该继续、什么时候该停下来。它包括系统提示词工具说明输出格式约束解析逻辑任务规则角色设定记忆注入方式上下文组织方式错误处理提示这些内容不属于模型权重但会直接影响模型行为。同一个模型给不同的Scaffolding表现可能完全不同。比如一个代码 Agent如果系统提示词只写“你是一个编程助手。它可能会直接给建议。但如果 Scaffolding 明确规定先阅读相关文件再定位最小修改点修改后必须运行测试不要改无关代码遇到失败要继续分析日志那它的行为就会更像一个真正的工程助手。所以 Scaffolding 的作用是“让模型知道应该以什么方式理解任务、表达动作和遵守规则。它不负责执行。它负责约束模型的思考和输出方式。这里的「解析逻辑」也要稍微解释一下它不是指真的执行外部工具而是规定模型输出应该如何被理解比如工具调用要用什么 JSON schema、最终答案要用什么格式、哪些字段必须出现。在训练语境里Scaffolding 还会影响模型到底从交互轨迹里学到什么在推理语境里它更多影响模型每一步如何理解任务和表达动作。如果用广义 Harness 的说法Scaffolding 可以被看作 Harness 里「模型可见」的那一层。如果用狭义区分Scaffolding 和 Harness 可以分开讲前者管模型看见的规则后者管系统真正怎么执行。这也是为什么很多 Agent 产品看起来都在调用类似模型但体验差异巨大。差异不只在模型也在模型外面那层工作框架。06 HarnessAgent 工程里最容易被低估的一层如果Scaffolding是模型可见的规则层狭义的Harness就是模型看不见的执行层。Harness这个词可以理解为执行引擎或者运行时框架。它负责把模型、工具、上下文、任务循环串起来。不过这个词在行业里有宽窄两种用法。窄一点讲Harness 指执行引擎。宽一点讲Harness 可以指模型之外的整套 Agent 工程系统Scaffolding、工具、上下文管理、权限控制、子任务编排都可以算在里面。具体来说Harness 通常要做这些事调用模型接收模型输出判断模型是不是要调用工具解析工具参数真正执行工具把工具结果放回上下文决定是否继续下一轮处理报错、重试、超时和权限做上下文裁剪、压缩和回填调度 Sub-agent 或其他任务执行单元记录执行轨迹支持回放和评估管理沙箱、权限和安全边界判断任务是否完成这才是 Agent 真正「跑起来」的地方。举个代码助手的例子。用户说“帮我修一下这个项目里失败的测试。Harness 可能会这样工作先调用模型让模型判断从哪里开始。模型说要看测试日志Harness 去读日志。模型说要读某个源文件Harness 去读文件。模型说要修改某段代码Harness 执行修改。模型说要运行测试Harness 启动测试命令。测试失败Harness 把失败信息放回上下文。模型继续分析再次修改。直到测试通过或者达到停止条件。这里你会发现模型只是每一步的决策者。真正推动任务一轮轮前进的是Harness。所以可以这样记“Scaffolding 决定 Agent 应该按什么规则行动。Harness 决定这些行动如何被真正执行。很多 Agent 产品的核心竞争力其实就在 Harness 工程。因为这里涉及大量细节如何避免无限循环工具调用失败怎么办模型输出格式不合法怎么办权限边界怎么控制上下文太长怎么办任务状态怎么保存执行过程怎么回放和评估这些问题看起来不像「模型能力」但它们决定了 Agent 是否可靠。一个模型很强但 Harness 很弱最终体验仍然会很差。07 Context Engineering不只是写 Prompt而是管理信息流过去大家常讲Prompt Engineering。重点是提示词怎么写。但在 Agent 里更重要的是Context Engineering。因为 Agent 不是只调用一次模型。它是在任务执行过程中反复调用模型。每一轮调用时模型看到的信息都可能不同。Context Engineering 关心的问题是“在任务的每一步模型应该看到什么它不是一个完全独立于 Scaffolding 和 Harness 的模块而是横跨两层。“怎么规定模型应该看到什么属于 Scaffolding。程序如何检索、筛选、裁剪、压缩和注入上下文属于 Harness。这包括用户原始目标系统规则历史对话已完成步骤工具调用结果当前文件内容检索到的资料失败日志短期记忆长期记忆上下文不是越多越好。给少了模型缺关键信息。给多了模型会被干扰还会增加成本和延迟。所以 Context Engineering 的本质是在正确的时间给模型正确的信息。比如一个编程 Agent 修 bug 时不一定要把整个代码仓库都塞进上下文。它更需要看到相关报错相关测试相关函数最近修改项目约束这就够了。真正优秀的 Agent不是「什么都记住」而是「知道什么时候该看什么」。08 PolicyAgent 的行为偏好Policy是另一个容易抽象的词。可以把它理解为 Agent 的行为策略。在强化学习里Policy 通常指从状态到动作的选择规则。更严格一点说它是「在当前状态下对可选动作的概率分布」。放在 LLM Agent 里它更像是系统整体表现出来的行动倾向在多个可能动作之间它更可能选择哪一个。面对一个情况Agent 有很多可能动作直接回答先搜索先读文件先问用户先写计划先调用工具先拆分任务Policy 决定它更倾向于选择哪一个。Policy 不只存在于提示词或系统配置里。它至少来自三部分模型权重里学到的行为倾向单独训练出来的策略模型某些 RL Agent 会这么做Scaffolding 给出的规则和约束Harness 在执行层写死或动态调整的流程逻辑它还受到很多因素影响模型训练方式系统提示词工具集合ScaffoldingHarness 逻辑上下文内容记忆机制比如一个谨慎的 Agent遇到不确定事实会先搜索。一个偏执行的 Agent遇到代码任务会直接读文件和跑测试。一个安全边界更强的 Agent遇到高风险操作会先请求确认。这些行为差异都可以看作 Policy 的体现。所以“Policy 不是 Agent 本身。Policy 是 Agent 表现出来的行动方式。理解 Policy有助于理解为什么不同 Agent 即使用同一个模型也会有不同性格和工作习惯。09 训练视角Environment、Rollout、Reward 和 Trainer前面讲的是 Agent 如何被搭建和运行。如果进入训练阶段还会遇到另外一组概念。这里要注意一个区别“推理阶段关注的是Agent 如何在线完成任务。训练阶段关注的是如何收集交互轨迹、评价结果并用这些信号更新模型或策略。同样是 Environment、Rollout、Reward、Trainer放在训练和部署语境里关注点会不一样。Environment就是 Agent 可以交互的环境。它可以是浏览器、代码仓库、文件系统、游戏、数据库也可以是模拟出来的任务环境。Agent 在环境里观察状态采取行动然后获得新的状态。Rollout指 Agent 从任务开始到任务结束的一整段执行轨迹。它记录了 Agent 看到了什么做了什么调用了哪些工具最后结果如何。Reward是对一次执行结果的评价。比如代码任务里测试是否通过可以作为 reward。网页任务里是否完成指定操作可以作为 reward。写作任务里人工偏好或自动评分也可以作为 reward。Reward 也不一定只有一种形式。有些 reward 是可验证的比如测试通过、答案匹配、任务完成。有些 reward 来自学习型奖励模型用来判断输出质量或人类偏好。有些 reward 很稀疏只在任务结束时给分有些更密集会在中间步骤也给反馈。Trainer负责利用大量 rollout 和 reward 来更新模型让 Agent 在反复试错中学到更好的策略。它通常会做三件事跑出大量 rollout用 reward 对这些轨迹打分根据分数更新模型权重或策略所以训练阶段讨论 Agent重点不只是“它会不会调用工具而是“它能不能在环境里持续学习变得更会做选择10 把这些概念放回真实产品里看理解概念之后再看今天的 Agent 产品会清楚很多。一个代码 Agent不只是接了一个强模型。它还需要文件读取工具、代码编辑工具、终端工具、测试工具。它需要Skill沉淀如何排查报错、如何最小化修改、如何验证结果这类方法。这些方法的说明和约束会通过Scaffolding告诉模型比如不要乱改无关文件、修改后必须验证。真正把读文件、改代码、跑测试、继续修复串成循环的是Harness。Context Engineering则决定每一步应该给模型哪些代码、日志和任务状态。最终表现出来的Policy会决定它什么时候先计划什么时候直接执行什么时候请求用户确认。这才是一个完整 Agent。同样一个企业流程 Agent 也不是「聊天机器人加 API」。它要知道什么时候查 CRM什么时候调工单系统什么时候生成邮件什么时候需要人工审批。真正困难的地方不只是让模型「会说」而是让系统「会做」。11 最后用一张概念速记表收住AI Agent 不是一个单独的新模型。它是一套围绕模型搭建起来的行动系统。用最简公式说就是“精细拆分Agent Model Scaffolding Harness社区简化时也常写成“广义理解Agent Model Harness这里的 Harness 可以按广义理解模型之外那整套让 Agent 能运行、能行动、能反馈、能停止的工程系统。如果拆细看Model让它能理解和推理。Scaffolding是模型可见的规则层。Tool Use让它能触碰外部世界。Skill让它能复用做事方法。Sub-agent让它能拆分复杂任务。Context Engineering管理每一步进入模型视野的信息。Policy决定它在不同情况下怎么选择。而狭义的 Harness则负责把这些规则、工具、上下文和任务循环真正执行起来。Environment、Rollout、Reward和Trainer则帮助我们理解 Agent 如何被训练得更强。所以判断一个 Agent 好不好不能只问“它用了哪个模型还要问它接了哪些工具有没有稳定的 SkillScaffolding 是否清晰Harness 是否可靠上下文管理是否聪明失败后能不能恢复任务是否真的能闭环完成当你用这套框架去看 Agent就会发现AI Agent 的重点不只是智能本身而是把智能放进一个可执行、可反馈、可持续推进的工程系统里。这也是 Agent 真正有价值的地方。AI Agent 概念速记表概念一句话理解ModelAgent 的「大脑」负责理解、推理和生成但本身不会执行外部动作。Agent围绕模型搭建起来的任务执行系统精细拆分是 Model Scaffolding Harness广义简化可写成 Model Harness。Tool外部能力本体比如搜索、文件系统、数据库、浏览器、代码解释器。Tool UseAgent 调用工具的过程包括生成调用意图、执行工具、回填结果。Skill可复用的任务方法包说明规则进入 Scaffolding运行调度依赖 Harness。Sub-agent能独立处理子任务的 Agent通常由 Harness 或 orchestrator 创建、调度和汇总结果。Orchestrator更高层的编排器负责调度多个 Agent 或任务单元并汇总结果。Scaffolding模型可见的行为框架包括系统提示词、工具说明、格式约束、解析逻辑、上下文规则和任务规则。Harness广义指模型之外的整套工程系统狭义指执行引擎负责调用模型、执行工具、管理循环、异常、权限和停止条件。Context Engineering横跨 Scaffolding 和 Harness既包括上下文规则也包括运行时检索、裁剪、压缩和注入。PolicyAgent 对可选动作的概率分布或行为策略来自模型权重、策略模型、Scaffolding 约束和 Harness 执行逻辑的共同作用。EnvironmentAgent 可以交互的外部环境比如浏览器、文件系统、代码仓库或任务模拟器。RolloutAgent 从任务开始到结束的一整段执行轨迹。Reward对任务执行结果或中间步骤的评价信号可以是可验证奖励、学习型奖励、稀疏奖励或密集奖励。Trainer利用 rollout 和 reward 更新模型或策略的训练器通常包括跑轨迹、打分、更新权重三步。假如你从2026年开始学大模型按这个步骤走准能稳步进阶。接下来告诉你一条最快的邪修路线3个月即可成为模型大师薪资直接起飞。阶段1:大模型基础阶段2:RAG应用开发工程阶段3:大模型Agent应用架构阶段4:大模型微调与私有化部署配套文档资源全套AI 大模型 学习资料朋友们如果需要可以微信扫描下方二维码免费领取【保证100%免费】配套文档资源全套AI 大模型 学习资料朋友们如果需要可以微信扫描下方二维码免费领取【保证100%免费】
AI Agent真谛：不只是调用工具的大模型，更是智能执行系统
真正的 AI Agent不只是会调用工具的大模型AI Agent 是这两年最容易被反复提起、也最容易被说乱的 AI 概念之一。做模型的人在讲 Agent做产品的人在讲 Agent做应用的人也在讲 Agent。但很多时候大家说的并不是同一件事。有人把「能调用工具的大模型」叫 Agent。有人把「能自动完成任务的系统」叫 Agent。也有人把「负责某个子任务的模块」叫 Agent。这个词被用得越来越多边界却越来越模糊。2026 年 5 月 25 日Hugging Face 发布了一篇 AI Agent 术语表文章作者是 Sergio Paniego 和 Aritra Roy Gosthipaty标题是“Harness, Scaffold, and the AI Agent Terms Worth Getting Right文章链接我放在文末了你也可以读一读原文。这篇文章系统梳理了 Agent 讨论里最容易混淆的一批概念Model、Scaffolding、Harness、Agent、Context Engineering、Policy、Tool Use、Skill、Sub-agent以及训练阶段常见的Environment、Rollout、Reward和Trainer。它的价值不在于提出了某个全新的框架而在于把很多人平时混着用的词重新放回各自的位置。也要先说明一点这不是一份「全行业唯一标准答案」。**Agent 领域的术语还在快速演化不同论文、产品和框架会用不同口径。**Hugging Face 这篇文章更像是一份实用术语地图帮助我们在讨论时少一点混乱。它的直接背景也很有代表性ICLR 2026 之后作者提到很多人都在问harness和scaffold到底是什么意思但大家给出的解释并不统一。这很重要。因为当我们讨论 Agent 时如果不先把概念边界理清后面的判断很容易跑偏。比如一个 Agent 效果不好到底是模型能力不够还是工具设计不好是提示词写得不清楚是上下文管理出了问题还是执行系统没有处理好循环、失败和停止条件这些问题背后对应的是完全不同的工程层。所以这篇文章想做一件事借 Hugging Face 这份 AI Agent 术语表把 Agent 最核心的一组概念重新串起来用尽量直白的方式讲清楚。“AI Agent 不是一个单独的模型而是一套围绕模型搭建起来的任务执行系统。如果按照 Hugging Face 原文的精细拆分可以先记住这个三层结构“Agent Model Scaffolding HarnessModel是大模型本身。Scaffolding是模型能直接依据的行为定义层。狭义的Harness是执行引擎让模型、工具和任务循环真正跑起来。不过在社区和很多产品文档里Harness也经常被更宽泛地使用表示模型之外的一切。这个时候人们会把 Agent 简化成“Agent Model Harness这里的Harness就不是狭义执行层而是模型之外让 Agent 真正运行起来的整套工程系统。若采用广义口径拆分“Harness ≈ Scaffolding 执行循环 工具路由 上下文管理 权限与异常处理 子任务编排精细公式里的 Harness 是狭义执行引擎不含 Scaffolding。其中Scaffolding是模型能直接看见的规则层比如系统提示词、工具说明、输出格式和上下文规则。Harness的狭义用法则更偏向模型看不见的执行层比如调用模型、执行工具、处理循环、重试、超时和停止条件。所以下面这些概念不是一组完全平级的零件而是理解 Agent 时需要拆开的几个视角。Model负责理解和推理。Tool是外部能力本体Tool Use是调用这些能力的过程。Skill沉淀一类任务的做事方法但它的描述会进入 Scaffolding它的运行会依赖 Harness。Sub-agent是复杂任务里的分工方式创建、调度和汇总通常由 Harness 完成。Context Engineering横跨 Scaffolding 和 Harness一部分是模型可见的上下文规则一部分是运行时的检索、裁剪、压缩和注入。Policy决定 Agent 在不同情境下如何做选择。下面我们就按这个顺序把这些概念拆开讲清楚。01 ModelAgent 的大脑但不是 Agent 本身先从最基础的Model说起。Model就是大语言模型。它的本质能力是接收输入生成输出。你给它一段上下文它根据训练得到的参数生成下一段最合适的内容。它可以做很多事理解问题拆解任务生成代码判断下一步应该搜索还是读文件按照约定格式写出一个「工具调用请求」但模型本身并不会真的执行动作。它不会自己打开浏览器。不会自己访问数据库。不会自己运行代码。不会自己记住上一次调用结束后发生了什么。模型只是在一次调用里根据当前输入生成下一段文本。所以Model是 Agent 的核心但不是 Agent 的全部。可以这样理解“Model 负责判断「下一步应该做什么」。Agent 系统负责把「下一步」真的执行出来。这也是很多人误解 Agent 的地方。一个大模型可以很聪明但只要它没有外部执行循环没有工具接入没有上下文管理它仍然只是一个聊天模型。它可以告诉你「我建议你运行测试。」但 Agent 可以真的去运行测试然后把报错读回来再继续修改代码。差别就在这里。02 Tool让 Agent 接触外部世界如果说Model是大脑那Tool就是 Agent 伸向外部世界的手。这里要区分两个词“Tool 是工具本体。Tool Use 是 Agent 调用工具的过程。Tool可以是很多东西搜索引擎浏览器数据库文件系统代码解释器Shell 命令企业内部 API第三方 SaaS 接口比如你让一个 Agent「分析这份销售数据并生成一份报告。」模型本身并不知道你电脑里的 Excel 文件内容。它需要通过文件读取工具拿到数据。如果要计算指标可能需要调用 Python 或 SQL 工具。如果要补充市场信息可能需要调用搜索工具。如果要生成最终文档可能还需要调用文档工具。这些外部能力都是Tool。但要注意模型通常不会直接执行工具。它只是输出类似这样的意图“我要调用search工具关键词是「AI coding agent market 2026」。或者“我要读取/data/sales.xlsx这个文件。真正执行调用的是 Agent 系统里的执行层。工具返回结果后系统再把结果放回上下文让模型继续判断。所以Tool Use讲的不是某个工具本身而是这条调用链路“模型提出工具调用系统解析调用请求工具执行返回执行结果模型基于结果继续推理Tool解决的是“Agent 能做什么动作但它不解决什么时候做按什么顺序做失败了怎么办这些问题需要更上层的结构。在工程实现里工具的描述通常属于 Scaffolding因为模型需要看懂工具能做什么工具的路由、执行和结果回填则属于 Harness。03 Skill不是工具而是一套方法Tool和Skill很容易被混在一起。但它们不是一回事。“Tool 是一个动作。Skill 是一套方法。比如「调用搜索引擎」是Tool。但「写一份竞品分析」不是Tool。它是一套Skill。因为它通常包含很多步骤先确定分析维度再收集竞品资料再整理功能、价格、定位、用户群再提炼差异最后形成结论这不是一次工具调用能完成的。再比如「修复一个前端 bug」。它可能包括复现问题查看报错定位相关组件分析状态流修改代码运行测试检查页面效果这些步骤背后是一整套经验和流程。这就是Skill。“Tool 关注的是我可以调用什么能力Skill 关注的是面对这类任务我应该怎么做在 Agent 系统里Skill可以被理解为一种可复用的任务知识包。它可能包含说明文档、操作流程、约束条件、示例、检查清单甚至一组专门工具。更严谨一点说Skill 也有两层“Skill 的说明、触发条件和使用规则会进入 Scaffolding。Skill 的加载、调度、工具调用和校验则依赖 Harness。这也是为什么Skill对复杂 Agent 很重要。如果没有 SkillAgent 每次做任务都像从零开始摸索。有了 Skill它就能把过去沉淀下来的方法复用起来。一个数据分析 Agent 可以有「清洗数据」的 Skill。一个编程 Agent 可以有「定位测试失败」的 Skill。一个运营 Agent 可以有「生成周报」的 Skill。Skill 越清晰Agent 越不容易乱跑。04 Sub-agent把任务交给另一个 Agent当任务再复杂一点就会出现Sub-agent。Sub-agent可以理解为“被主 Agent 调用的另一个 Agent。它不是简单工具也不只是方法文档。它有自己的上下文、自己的目标也可以自己调用工具完成子任务。举个例子。你让一个 Agent 做一份「新能源汽车行业研究」。主 Agent 可能把任务拆成几块一个 Sub-agent 负责找政策资料一个 Sub-agent 负责分析主要公司一个 Sub-agent 负责整理销量和市场数据一个 Sub-agent 负责写报告初稿最后主 Agent 再把各部分整合成一篇完整文章。这里的 Sub-agent 不是一次 API 调用。它本身也会经历「观察、判断、行动、反馈」的循环。但 Sub-agent 不是凭空出现的。在真实系统里谁来创建子任务谁来调用 Sub-agent谁来收集结果谁来判断要不要继续拆分通常都是 Harness 或更上层 orchestrator 的工作。Orchestrator可以理解为更高一层的编排器。当系统里不止一个 Agent而是多个 Agent 或多个任务单元协作时orchestrator 负责决定谁做哪部分、结果怎么汇总、失败时要不要重试或换路。在一些产品和框架里orchestrator 会被算进广义 Harness在另一些架构图里它会被单独画出来。所以可以简单区分“Tool 是动作。Skill 是方法。Sub-agent 是分工。当任务很小的时候一个 Agent 自己完成就够了。但当任务涉及多个方向、多个阶段、多个资料来源时Sub-agent 可以降低复杂度。它让主 Agent 不必把所有事情都塞进同一个上下文里。这对长任务尤其重要。05 Scaffolding给模型搭一层工作框架接下来讲一个非常关键、但经常被忽略的词Scaffolding。它本来的意思是「脚手架」。放在 AI Agent 里可以理解为围绕模型搭出来的工作框架。更准确地说Scaffolding 是模型能直接感知的那部分框架。它不是执行代码而是告诉模型你是谁、能用什么工具、输出要长什么样、什么时候该继续、什么时候该停下来。它包括系统提示词工具说明输出格式约束解析逻辑任务规则角色设定记忆注入方式上下文组织方式错误处理提示这些内容不属于模型权重但会直接影响模型行为。同一个模型给不同的Scaffolding表现可能完全不同。比如一个代码 Agent如果系统提示词只写“你是一个编程助手。它可能会直接给建议。但如果 Scaffolding 明确规定先阅读相关文件再定位最小修改点修改后必须运行测试不要改无关代码遇到失败要继续分析日志那它的行为就会更像一个真正的工程助手。所以 Scaffolding 的作用是“让模型知道应该以什么方式理解任务、表达动作和遵守规则。它不负责执行。它负责约束模型的思考和输出方式。这里的「解析逻辑」也要稍微解释一下它不是指真的执行外部工具而是规定模型输出应该如何被理解比如工具调用要用什么 JSON schema、最终答案要用什么格式、哪些字段必须出现。在训练语境里Scaffolding 还会影响模型到底从交互轨迹里学到什么在推理语境里它更多影响模型每一步如何理解任务和表达动作。如果用广义 Harness 的说法Scaffolding 可以被看作 Harness 里「模型可见」的那一层。如果用狭义区分Scaffolding 和 Harness 可以分开讲前者管模型看见的规则后者管系统真正怎么执行。这也是为什么很多 Agent 产品看起来都在调用类似模型但体验差异巨大。差异不只在模型也在模型外面那层工作框架。06 HarnessAgent 工程里最容易被低估的一层如果Scaffolding是模型可见的规则层狭义的Harness就是模型看不见的执行层。Harness这个词可以理解为执行引擎或者运行时框架。它负责把模型、工具、上下文、任务循环串起来。不过这个词在行业里有宽窄两种用法。窄一点讲Harness 指执行引擎。宽一点讲Harness 可以指模型之外的整套 Agent 工程系统Scaffolding、工具、上下文管理、权限控制、子任务编排都可以算在里面。具体来说Harness 通常要做这些事调用模型接收模型输出判断模型是不是要调用工具解析工具参数真正执行工具把工具结果放回上下文决定是否继续下一轮处理报错、重试、超时和权限做上下文裁剪、压缩和回填调度 Sub-agent 或其他任务执行单元记录执行轨迹支持回放和评估管理沙箱、权限和安全边界判断任务是否完成这才是 Agent 真正「跑起来」的地方。举个代码助手的例子。用户说“帮我修一下这个项目里失败的测试。Harness 可能会这样工作先调用模型让模型判断从哪里开始。模型说要看测试日志Harness 去读日志。模型说要读某个源文件Harness 去读文件。模型说要修改某段代码Harness 执行修改。模型说要运行测试Harness 启动测试命令。测试失败Harness 把失败信息放回上下文。模型继续分析再次修改。直到测试通过或者达到停止条件。这里你会发现模型只是每一步的决策者。真正推动任务一轮轮前进的是Harness。所以可以这样记“Scaffolding 决定 Agent 应该按什么规则行动。Harness 决定这些行动如何被真正执行。很多 Agent 产品的核心竞争力其实就在 Harness 工程。因为这里涉及大量细节如何避免无限循环工具调用失败怎么办模型输出格式不合法怎么办权限边界怎么控制上下文太长怎么办任务状态怎么保存执行过程怎么回放和评估这些问题看起来不像「模型能力」但它们决定了 Agent 是否可靠。一个模型很强但 Harness 很弱最终体验仍然会很差。07 Context Engineering不只是写 Prompt而是管理信息流过去大家常讲Prompt Engineering。重点是提示词怎么写。但在 Agent 里更重要的是Context Engineering。因为 Agent 不是只调用一次模型。它是在任务执行过程中反复调用模型。每一轮调用时模型看到的信息都可能不同。Context Engineering 关心的问题是“在任务的每一步模型应该看到什么它不是一个完全独立于 Scaffolding 和 Harness 的模块而是横跨两层。“怎么规定模型应该看到什么属于 Scaffolding。程序如何检索、筛选、裁剪、压缩和注入上下文属于 Harness。这包括用户原始目标系统规则历史对话已完成步骤工具调用结果当前文件内容检索到的资料失败日志短期记忆长期记忆上下文不是越多越好。给少了模型缺关键信息。给多了模型会被干扰还会增加成本和延迟。所以 Context Engineering 的本质是在正确的时间给模型正确的信息。比如一个编程 Agent 修 bug 时不一定要把整个代码仓库都塞进上下文。它更需要看到相关报错相关测试相关函数最近修改项目约束这就够了。真正优秀的 Agent不是「什么都记住」而是「知道什么时候该看什么」。08 PolicyAgent 的行为偏好Policy是另一个容易抽象的词。可以把它理解为 Agent 的行为策略。在强化学习里Policy 通常指从状态到动作的选择规则。更严格一点说它是「在当前状态下对可选动作的概率分布」。放在 LLM Agent 里它更像是系统整体表现出来的行动倾向在多个可能动作之间它更可能选择哪一个。面对一个情况Agent 有很多可能动作直接回答先搜索先读文件先问用户先写计划先调用工具先拆分任务Policy 决定它更倾向于选择哪一个。Policy 不只存在于提示词或系统配置里。它至少来自三部分模型权重里学到的行为倾向单独训练出来的策略模型某些 RL Agent 会这么做Scaffolding 给出的规则和约束Harness 在执行层写死或动态调整的流程逻辑它还受到很多因素影响模型训练方式系统提示词工具集合ScaffoldingHarness 逻辑上下文内容记忆机制比如一个谨慎的 Agent遇到不确定事实会先搜索。一个偏执行的 Agent遇到代码任务会直接读文件和跑测试。一个安全边界更强的 Agent遇到高风险操作会先请求确认。这些行为差异都可以看作 Policy 的体现。所以“Policy 不是 Agent 本身。Policy 是 Agent 表现出来的行动方式。理解 Policy有助于理解为什么不同 Agent 即使用同一个模型也会有不同性格和工作习惯。09 训练视角Environment、Rollout、Reward 和 Trainer前面讲的是 Agent 如何被搭建和运行。如果进入训练阶段还会遇到另外一组概念。这里要注意一个区别“推理阶段关注的是Agent 如何在线完成任务。训练阶段关注的是如何收集交互轨迹、评价结果并用这些信号更新模型或策略。同样是 Environment、Rollout、Reward、Trainer放在训练和部署语境里关注点会不一样。Environment就是 Agent 可以交互的环境。它可以是浏览器、代码仓库、文件系统、游戏、数据库也可以是模拟出来的任务环境。Agent 在环境里观察状态采取行动然后获得新的状态。Rollout指 Agent 从任务开始到任务结束的一整段执行轨迹。它记录了 Agent 看到了什么做了什么调用了哪些工具最后结果如何。Reward是对一次执行结果的评价。比如代码任务里测试是否通过可以作为 reward。网页任务里是否完成指定操作可以作为 reward。写作任务里人工偏好或自动评分也可以作为 reward。Reward 也不一定只有一种形式。有些 reward 是可验证的比如测试通过、答案匹配、任务完成。有些 reward 来自学习型奖励模型用来判断输出质量或人类偏好。有些 reward 很稀疏只在任务结束时给分有些更密集会在中间步骤也给反馈。Trainer负责利用大量 rollout 和 reward 来更新模型让 Agent 在反复试错中学到更好的策略。它通常会做三件事跑出大量 rollout用 reward 对这些轨迹打分根据分数更新模型权重或策略所以训练阶段讨论 Agent重点不只是“它会不会调用工具而是“它能不能在环境里持续学习变得更会做选择10 把这些概念放回真实产品里看理解概念之后再看今天的 Agent 产品会清楚很多。一个代码 Agent不只是接了一个强模型。它还需要文件读取工具、代码编辑工具、终端工具、测试工具。它需要Skill沉淀如何排查报错、如何最小化修改、如何验证结果这类方法。这些方法的说明和约束会通过Scaffolding告诉模型比如不要乱改无关文件、修改后必须验证。真正把读文件、改代码、跑测试、继续修复串成循环的是Harness。Context Engineering则决定每一步应该给模型哪些代码、日志和任务状态。最终表现出来的Policy会决定它什么时候先计划什么时候直接执行什么时候请求用户确认。这才是一个完整 Agent。同样一个企业流程 Agent 也不是「聊天机器人加 API」。它要知道什么时候查 CRM什么时候调工单系统什么时候生成邮件什么时候需要人工审批。真正困难的地方不只是让模型「会说」而是让系统「会做」。11 最后用一张概念速记表收住AI Agent 不是一个单独的新模型。它是一套围绕模型搭建起来的行动系统。用最简公式说就是“精细拆分Agent Model Scaffolding Harness社区简化时也常写成“广义理解Agent Model Harness这里的 Harness 可以按广义理解模型之外那整套让 Agent 能运行、能行动、能反馈、能停止的工程系统。如果拆细看Model让它能理解和推理。Scaffolding是模型可见的规则层。Tool Use让它能触碰外部世界。Skill让它能复用做事方法。Sub-agent让它能拆分复杂任务。Context Engineering管理每一步进入模型视野的信息。Policy决定它在不同情况下怎么选择。而狭义的 Harness则负责把这些规则、工具、上下文和任务循环真正执行起来。Environment、Rollout、Reward和Trainer则帮助我们理解 Agent 如何被训练得更强。所以判断一个 Agent 好不好不能只问“它用了哪个模型还要问它接了哪些工具有没有稳定的 SkillScaffolding 是否清晰Harness 是否可靠上下文管理是否聪明失败后能不能恢复任务是否真的能闭环完成当你用这套框架去看 Agent就会发现AI Agent 的重点不只是智能本身而是把智能放进一个可执行、可反馈、可持续推进的工程系统里。这也是 Agent 真正有价值的地方。AI Agent 概念速记表概念一句话理解ModelAgent 的「大脑」负责理解、推理和生成但本身不会执行外部动作。Agent围绕模型搭建起来的任务执行系统精细拆分是 Model Scaffolding Harness广义简化可写成 Model Harness。Tool外部能力本体比如搜索、文件系统、数据库、浏览器、代码解释器。Tool UseAgent 调用工具的过程包括生成调用意图、执行工具、回填结果。Skill可复用的任务方法包说明规则进入 Scaffolding运行调度依赖 Harness。Sub-agent能独立处理子任务的 Agent通常由 Harness 或 orchestrator 创建、调度和汇总结果。Orchestrator更高层的编排器负责调度多个 Agent 或任务单元并汇总结果。Scaffolding模型可见的行为框架包括系统提示词、工具说明、格式约束、解析逻辑、上下文规则和任务规则。Harness广义指模型之外的整套工程系统狭义指执行引擎负责调用模型、执行工具、管理循环、异常、权限和停止条件。Context Engineering横跨 Scaffolding 和 Harness既包括上下文规则也包括运行时检索、裁剪、压缩和注入。PolicyAgent 对可选动作的概率分布或行为策略来自模型权重、策略模型、Scaffolding 约束和 Harness 执行逻辑的共同作用。EnvironmentAgent 可以交互的外部环境比如浏览器、文件系统、代码仓库或任务模拟器。RolloutAgent 从任务开始到结束的一整段执行轨迹。Reward对任务执行结果或中间步骤的评价信号可以是可验证奖励、学习型奖励、稀疏奖励或密集奖励。Trainer利用 rollout 和 reward 更新模型或策略的训练器通常包括跑轨迹、打分、更新权重三步。假如你从2026年开始学大模型按这个步骤走准能稳步进阶。接下来告诉你一条最快的邪修路线3个月即可成为模型大师薪资直接起飞。阶段1:大模型基础阶段2:RAG应用开发工程阶段3:大模型Agent应用架构阶段4:大模型微调与私有化部署配套文档资源全套AI 大模型 学习资料朋友们如果需要可以微信扫描下方二维码免费领取【保证100%免费】配套文档资源全套AI 大模型 学习资料朋友们如果需要可以微信扫描下方二维码免费领取【保证100%免费】
