基本概念
Agent核心概念
| 术语概念 | 解释 |
|---|---|
| 智能体(Agent) | 以大语言模型为核心推理引擎,能够自主感知外部输入、制定执行计划、调用工具并采取行动来达成特定目标的智能系统。区别于传统对话机器人的被动应答模式,智能体具备目标驱动、自主决策、多步骤执行的能力。 |
| 大语言模型(LLM, Large Language Model) | 基于海量文本数据训练而成的深度学习模型,具备自然语言理解、逻辑推理和文本生成能力。在智能体架构中充当大脑角色,负责意图识别、任务规划和内容生成。智能体的能力边界在很大程度上取决于底层模型的推理水平。 |
| Harness(智能体治理框架) | 包裹在大语言模型外层的工程治理体系,可以理解为智能体的操作系统层。模型本身只负责推理和生成,而Harness负责模型无法自行解决的所有工程问题。它通常包含以下核心子系统:系统提示词与上下文管理(控制模型每一步能看到什么信息)、工具定义与权限控制(规定模型能调用哪些工具以及权限边界)、执行引擎与编排逻辑(管理Agent Loop的运行流程)、安全沙箱与输出治理(隔离代码执行并校验模型输出)。此外,Harness还提供检查点与恢复(定期保存执行状态快照,故障时从最近检查点恢复而非从头重试)、循环终止(设定最大步数、Token上限或超时阈值,防止推理陷入死循环)、优雅降级(达到资源上限时返回当前最优中间结果而非直接报错)等关键机制。同一个模型搭配不同的Harness,在实际任务中的表现可能截然不同。 |
| Harness Engineering(治理框架工程) | 围绕智能体搭建可控、可验证、可观测运行外壳的系统性工程方法论。其核心主张是:决定智能体能否在生产环境中可靠运行的关键因素,不是模型本身的能力,而是包裹在模型外部的治理体系的完善程度。Harness Engineering覆盖的工程实践包括:上下文管理策略设计(防止长对话中上下文信息衰减或污染)、工具接口设计与权限约束、错误处理与重试策略、执行状态的检查点与持久化、运行时的可观测性建设与效果评估等。 |
| 提示词工程(Prompt Engineering) | 通过系统化地设计和优化输入给大语言模型的文本指令,引导模型输出符合预期的结果的方法论。涵盖指令编写技巧、上下文组织方式、少样本示例选取、思维链引导等多种技术手段。提示词工程的质量直接影响智能体的推理效果和输出稳定性。 |
| 系统提示词(System Prompt) | 在对话开始前注入给模型的全局指令文本,用于定义智能体的角色身份、行为规则、输出格式、安全边界等基础约束。系统提示词贯穿整个会话生命周期,是塑造智能体人设和行为准则的核心手段。 |
| 上下文工程(Context Engineering) | 管理和优化输入给模型的全部信息(包括系统提示词、对话历史、检索结果、工具返回值等)的工程方法。核心目标是在模型有限的上下文窗口内,让最关键、最相关的信息以最合适的结构呈现给模型,从而最大化模型的推理质量。上下文工程是提示词工程的进一步延伸,关注点从“写好一条指令”扩展到“管好模型能看到的一切信息”。 |
| 规划(Planning) | 智能体将复杂的高层目标拆解为可执行的子任务序列,并确定最优执行路径的能力。规划能力是智能体区别于简单问答系统的核心特征之一,使其可以处理需要多步推理和多次工具调用的复杂任务。 |
| ReAct(Reasoning + Acting) | 一种让模型交替进行推理和行动的智能体运行范式。在每个执行步骤中,模型先用自然语言思考当前状况和下一步计划,然后基于思考结果执行具体操作如调用工具,再根据操作返回的结果继续下一轮思考,如此循环直至任务完成。 |
| CoT(Chain of Thought, 思维链) | 一种引导模型进行逐步推理的提示技术。通过要求模型在给出最终答案前先输出中间推理过程,显著提升模型在数学计算、逻辑推理、多步决策等复杂任务上的准确率。思维链可以是模型自发产生的,也可以通过提示词中的示例来引导。 |
| Agent Loop(智能体循环) | 智能体的核心执行机制。在一个循环迭代中,智能体持续执行“感知输入 → 模型推理 → 选择并执行动作 → 观察结果 → 判断是否达成目标”这一闭环流程,直到任务完成或触发终止条件。Agent Loop是ReAct等运行范式的底层实现机制。 |
| 多智能体系统(Multi-Agent System) | 由多个各司其职的智能体组成的协作系统。每个智能体承担不同的角色或专业分工,通过消息传递、任务委派等机制协同工作,共同完成单个智能体难以独立处理的复杂任务。常见协作模式包括主从分工、平等协商、流水线接力等。 |
| 记忆(Memory) | 智能体存储和检索历史交互信息的能力,用于弥补大语言模型天然无状态的局限。记忆使智能体在对话中保持上下文连贯,并能跨会话持续积累对用户和任务的认知。按保存周期和用途,通常分为短期记忆(当前会话内)和长期记忆(跨会话持久化)两个层次。 |
智能体运行时概念
| 术语概念 | 解释 |
|---|---|
| 运行时(Runtime) | 一个安全隔离、框架无关的智能体托管执行环境。开发者将智能体代码打包为容器镜像并部署到运行时后,即可通过API对外提供服务。运行时承担会话级别的安全沙箱隔离、弹性伸缩、版本管理和健康检查等运维职责,使开发者只需关注业务逻辑本身,无需处理底层基础设施问题。 |
| 全托管智能体(Managed Agents) | 一种无需打包镜像的智能体运行模式。用户只需在控制台配置模型、提示词、工具和权限,平台即全面接管运行环境、会话状态和工具执行,用户不必操心基础设施的搭建和维护。适用于需要快速上线、对底层运行环境没有深度定制需求的场景。 |
| 安全沙箱(Sandbox) | 为智能体代码执行和工具调用提供的隔离运行环境。通常基于容器或轻量虚拟机等技术实现,会话之间在计算资源、内存空间和文件系统上严格隔离,任何一个会话的异常行为都不会波及其他会话,保障多用户并发场景下的执行安全和数据隐私。 |
| 环境(Environment) | 全托管智能体所依赖的运行基础设施配置集合,涵盖网络访问规则、系统依赖项等设置。环境与具体智能体解耦管理,一个环境可同时供多个全托管智能体复用。系统通常提供默认环境,可覆盖绝大多数常规场景。 |
| 访问方式(Access Endpoint) | 运行时对外暴露的调用入口配置。每个访问方式绑定到运行时的某个特定版本,并生成唯一的端点URL。同一个运行时支持创建多个访问方式,通过将不同访问方式分别绑定到不同版本,可以实现灰度发布和A/B测试。 |
| 入站协议(Inbound Protocol) | 运行时接收外部请求时所支持的通信协议类型。常见有两种:HTTP协议,适用于应用系统或前端直接调用;MCP协议,适用于Agent-to-Agent场景,使运行时以MCP Server的形态被其他智能体发现和调用。 |
| 流式响应(Streaming Response) | 一种渐进式的响应方式。服务端在推理过程中通过SSE(Server-Sent Events)等机制持续将已生成的部分结果推送给客户端,而非等待全部内容生成完毕后一次性返回。用户可以实时看到回复逐步呈现,显著降低感知等待时间,尤其适用于长文本输出和实时交互场景。 |
| 代码解释器(Code Interpreter) | 运行在安全沙箱中的动态代码执行能力。智能体可以在隔离环境中自动生成并运行代码脚本、处理文件、执行系统命令,所有操作都被严格限制在沙箱边界内,不会影响宿主系统。适用于数据分析、数值计算、文件格式转换等需要动态编程的场景。 |
记忆核心概念
| 术语概念 | 解释 |
|---|---|
| 记忆库(Memory Store) | 承载智能体记忆数据的基础设施实体,负责管理记忆数据从写入、存储、向量化、检索到过期清理的全生命周期。记忆库内部划分为短期记忆层与长期记忆层两个层次,支持被多个智能体共享使用。 |
| 短期记忆(Short-term Memory) | 存储单次会话内原始交互记录的记忆层。按照时间先后顺序保存用户输入和智能体回复,帮助智能体在当前对话中保持上下文连贯。短期记忆设有过期时间,通常为数十天至一年不等,超时后自动清理以释放存储空间。 |
| 长期记忆(Long-term Memory) | 跨会话持久保存的结构化知识层。由记忆策略从短期记忆中自动抽取和归纳而来,可包含用户偏好、历史事实、对话摘要、经验知识等多种类型的信息。长期记忆赋予智能体跨会话"记住"用户的能力,使其能够在后续交互中提供更具连续性和个性化的服务。 |
| 记忆策略(Memory Policy) | 决定从短期记忆中提取什么信息、以何种形式巩固为长期记忆的规则集合。常见的策略类型包括:总结,将一段会话的主题和关键要点提炼为简洁的摘要;语义记忆,从对话中抽取事实性知识和概念关系;用户偏好,识别并记录用户的行为模式、习惯和偏好选项;情景记忆,保留具有时间、地点等上下文线索的具体事件经历和场景细节;程序性记忆,从会话记录中提取操作流程、行动步骤和关键提示等信息,形成可复用的任务执行指南。 |
网关与工具路由核心概念
| 术语概念 | 解释 |
|---|---|
| 网关(Gateway) | 位于智能体与外部系统之间的统一接入层,负责协议转换、请求路由和身份认证管理。智能体通过网关以统一的方式发现和调用后端服务,无需关心各个后端系统的具体协议类型和部署形态,从而将企业内部异构的API资产统一收口管理。 |
| 入站网关(Inbound Gateway) | 管理从外部系统进入智能体运行环境的请求流量。所有来自应用端或其他智能体的调用请求先经过入站网关完成身份鉴权、流量限制和路由分发,再转发到对应的运行时实例。与网关的区别在于方向:入站网关管控“外部 → 运行时”方向的入站流量,网关管控“运行时 → 外部服务”方向的出站工具调用。 |
| Target(后端服务目标) | 挂载在网关后端的服务目标配置。每个Target定义了后端服务的地址、协议类型和认证方式,告诉网关如何将标准化请求转换并转发到具体的后端。一个网关可同时关联多个Target,例如:MCP Target用于对接工具类服务(后端可以是REST API、MCP Server、API网关或云服务接口),Inference Target用于对接大语言模型等推理服务。 |
| 工具(Tool) | 挂载在MCP Target后端的具体功能单元。每个工具包含名称、功能描述和输入参数的结构化定义。智能体通过名称发起调用,根据描述判断在什么场景下应该使用该工具,根据参数定义自动构造合法的请求体。 |
| OAS 文件(OpenAPI Specification 文件) | 遵循OpenAPI规范编写的REST API接口描述文档。在创建REST类型的Target时,网关通过解析OAS文件自动将其中定义的API端点转换为标准的MCP工具定义,免去逐一手动配置的工作。 |
插件/MCP核心概念
| 术语概念 | 解释 |
|---|---|
| 插件(Plugin) | 遵循OpenAPI规范封装的工具包,通常将一组功能相关的API打包为一个可被智能体调用的能力单元。智能体通过解析插件的接口描述文件自动发现可用操作及其参数定义,从而实现对第三方系统的结构化调用。 |
| OpenAPI | 一套用于描述REST API接口的行业标准规范。通过JSON或YAML格式的文件,精确定义API的请求路径、参数类型、返回结构和认证方式等信息,使机器可以自动解析和调用接口,无需人工逐一适配。 |
| MCP(Model Context Protocol,模型上下文协议) | 一套用于规范大语言模型与外部工具、数据源之间连接方式的开放标准协议。MCP定义了工具发现、能力描述、调用请求和结果返回的统一格式,使不同平台和框架上开发的工具可以互通互用,无需为每种模型或框架做单独适配。 |
| MCP Server | 实现MCP协议的服务端程序。对外暴露一组标准化的工具列表,接收来自MCP Client的调用请求并返回执行结果。MCP Server可以是平台预置的公共服务、用户自行部署的私有服务,也可以运行在智能体运行时内部。 |
| MCP Client | 实现MCP协议的客户端程序,负责与MCP Server建立连接,获取可用工具列表,并向Server发送工具调用请求。在智能体架构中,MCP Client通常嵌入在Agent运行时或网关内部,作为智能体调用外部工具的桥梁。 |
| Resource(资源) | MCP协议中定义的核心原语之一,代表可供模型读取的数据源。与Tool侧重执行操作不同,Resource侧重提供信息,例如文件内容、数据库查询结果、配置信息等,模型可以将Resource内容纳入上下文进行推理 |
| A2A(Agent-to-Agent Protocol,智能体间通信协议) | 一套面向智能体之间能力发现与任务协作的开放标准协议。与MCP关注智能体如何调用工具不同,A2A关注的是智能体之间如何发现彼此的能力并协同完成任务。A2A定义了智能体卡片(Agent Card,用于发布能力描述)、任务生命周期管理、消息通信格式等核心机制,为构建跨平台的多智能体协作网络提供基础设施。 |
观测与评估核心概念
| 术语概念 | 解释 |
|---|---|
| 观测(Observability) | 对智能体运行状态进行全链路监控和分析的能力体系。通常包含三大支柱:调用链追踪(Trace)用于还原请求的完整执行路径,运行指标(Metrics)用于量化系统性能和健康度,日志(Log)用于记录运行过程中的详细事件信息。三者协同配合,帮助开发者全方位理解智能体在生产环境中的真实行为。 |
| OpenTelemetry(OTel) | 一个开源可观测性框架,提供一套厂商中立的API、SDK和数据规范,用于在应用中生成、采集和导出调用链、指标和日志三类遥测数据。OpenTelemetry已成为分布式系统可观测性领域的事实标准,在智能体场景中同样被广泛采用,使不同框架和平台产生的观测数据能够互通互用、统一分析。 |
| 调用链(Trace) | 一条Trace描述一个请求在系统中从进入到返回的完整生命周期,由一个或多个Span按照层级关系组装而成。在智能体场景中,一次用户请求所经历的全部处理步骤,包括模型调用、工具执行、记忆读写等,共同组成一条完整的调用链,用于端到端的性能分析和异常定位。 |
| 跨度(Span) | 调用链中的最小工作单元,代表系统中一次独立的操作。每个Span记录了该操作的名称、起止时间、持续时长,以及执行期间产生的属性和事件信息。在智能体场景中,一个Span可能对应一次LLM推理调用、一次工具执行或一次记忆检索。 |
| 根 Span(Root Span) | 一条Trace中的最顶层Span,代表整个请求的全局视图。所有其他Span都是根Span的直接或间接子节点。根Span的起止时间范围即为这条调用链的总耗时。 |
| 父子关系(Parent-Child Relationship) | Span之间的层级嵌套关系。当一个操作在执行过程中触发了另一个子操作时,前者成为父Span,后者成为子Span。例如一个“Agent 推理”Span在执行过程中先后发起了LLM调用和工具调用两个子操作,这三个Span之间就形成了一棵两层的树状结构,清晰展现执行的层级和因果关系。 |
| Span Attributes(Span属性) | 以键值对形式附加在Span上的描述性元数据,用于提供该操作的详细上下文信息。例如:调用的模型名称、消耗的Token数量、工具名称、HTTP响应状态码等。OpenTelemetry定义了专门的语义属性规范,涵盖智能体、模型调用、工具执行等维度的标准化字段,方便不同系统之间的数据对齐和统一分析。 |
| 运行指标(Metrics) | 以时间序列形式记录的量化运行数据,用于反映智能体及底层服务的运行状况。典型指标包括每秒请求数(QPS)、平均响应延迟、错误率、Token消耗量等。指标数据可用于设定告警阈值、进行容量规划和实施管理。 |
| 日志(Log) | 智能体运行过程中产生的详细文本记录,包含时间戳、事件描述和相关上下文信息。与调用链侧重还原全局执行路径不同,日志侧重记录单个节点的细节信息,常用于精确复现和分析具体问题场景。在OpenTelemetry体系中,日志可与Trace和Span进行关联,使开发者能够从一条调用链直接跳转到对应的详细日志。 |
| 评估(Evaluation) | 对智能体输出质量和行为表现进行系统化度量的过程。按评估场景分为两种模式:离线评估基于预先构建的评测集对智能体进行批量测试,适用于版本发布前的质量验收;在线评估基于生产环境中的真实调用数据持续打分和监测,适用于上线后的效果跟踪和退化预警。 |
| 评估器(Evaluator) | 执行评估打分的核心组件,内置评估标准和评分算法。实现方式上可分为基于规则的评估器(通过正则匹配、关键词检测等确定性方法打分)和基于模型的评估器(使用大语言模型充当评判者对输出质量进行评估)。常见的评估维度包括准确性、相关性、完整性、安全合规性等。平台通常提供若干预置评估器,同时支持用户根据业务需求自定义评估器。 |
| 评测集(Evaluation Dataset) | 离线评估所依赖的标准化测试数据集,由一批测试问题及其对应的期望答案或预期行为描述组成。评测集的质量和场景覆盖度直接决定评估结论的可靠性。通过在同一评测集上对比不同版本的智能体或不同模型方案的得分,可以量化地衡量优化效果。 |
知识库核心概念
| 术语概念 | 解释 |
|---|---|
| 知识库(Knowledge Base) | 为智能体提供领域知识的结构化或非结构化数据集合。用户上传文档、FAQ等资料后,系统自动完成内容解析、文本分块、向量化和索引构建,智能体在回答问题时通过检索知识库获取相关内容,减少模型幻觉并提升回答准确性。 |
| 检索增强生成 (RAG - Retrieval-Augmented Generation) | 指在大模型生成回答之前,先从外部数据库检索相关信息,并将其作为上下文输入给模型。这解决了大模型知识滞后和幻觉问题。 |
| Embedding(向量嵌入) | 将文本、图像等非结构化数据转换为高维数值向量的过程。转换后的向量能够在数学空间中保留原始数据的语义关系。含义相近的内容在向量空间中距离较近,含义不同的内容距离较远,从而支持基于语义相似度的检索。 |
| 向量数据库(Vector Database) | 专门用于存储和检索高维向量数据的数据库系统。支持基于向量相似度的近邻搜索,是RAG系统中存储文档向量并执行语义检索的核心基础设施。 |
| 倒排索引 (Inverted Index) | 传统搜索引擎(如Elasticsearch)的核心技术。通过关键词(Keyword)映射文档位置。在Agent中,常与向量检索结合使用,以弥补语义检索对专有名词(如产品型号)匹配不准的问题。 |
| 混合搜索 (Hybrid Search) | 同时使用关键词搜索(精确匹配)和向量搜索(语义匹配),并通过算法合并结果。这是目前企业级知识库的标准配置。 |
| 切片 / 分块 (Chunking) | 将长文档(如PDF、Wiki)切分成小的文本块(Chunk)的过程。切片策略(按字符数、按段落、按语义)直接决定了检索的精准度。切得太碎丢失上下文,切得太大包含噪音。 |
| 重排序 (Re-ranking) | 检索优化的“精修”环节。在向量数据库粗排召回多个结果后,使用一个更精准的重排序模型对这些结果进行打分,最终只选出质量最高的搜索结果传递给大模型。 |
工作流核心概念
| 术语概念 | 解释 |
|---|---|
| 工作流(Workflow) | 将业务逻辑建模为有向图结构的编排方式。开发者通过定义节点(处理步骤)和连线(执行顺序与条件分支),将大模型调用、代码执行、工具调用、条件判断等操作组织成确定性的执行流程。工作流适用于流程逻辑明确、步骤可预定义的业务场景。 |
| 可视化画布(Visual Canvas) | 以图形化拖拽方式构建工作流的交互界面。开发者在画布上放置节点、拖拽连线来定义流程结构,无需编写代码即可完成复杂编排逻辑的设计,所见即所得地展现整个工作流的拓扑结构。 |
| 节点(Node) | 工作流中的基本执行单元,代表一个具体的处理步骤。不同类型的节点完成不同的功能,例如:大模型调用节点负责调用LLM进行推理,代码节点负责运行自定义脚本,工具节点负责调用外部API,条件节点负责根据判断结果选择分支路径。 |
| 连线(Edge) | 连接工作流中两个节点的有向边,定义节点之间的执行顺序和数据流转关系。连线可以附加条件表达式,实现按运行时结果动态选择执行分支的能力。 |