Agent这个词，这两年已经被聊得有点“概念疲劳”了。

如果你问Agent是什么，答案可能五花八门——机器人、数字员工、甚至“龙虾”。但一旦Agent落到工程层面，尤其是企业应用，它就不是玄学，而是一套围绕大模型构建的系统工程：执行循环、工具链、上下文、知识结构，以及人机协作机制。

如果你正在学习或尝试Agent应用落地，下面这20个核心概念，是现阶段Agent工程领域最值得搞懂的东西。

我们会把它们拆成两篇来讲。上篇聚焦运行机制，解释Agent如何感知、推理与执行；下篇则侧重系统能力层，探讨如何扩展、协同与工程落地。

01 Agent（智能体）：从聊天到行动的执行体

很多人接触生成式AI是从ChatGPT这类聊天机器人开始的。但Agent和ChatBot的差别，不在于回答是否更像真人，而在于：Agent不仅会想、会说，更重要的是，它会“做”——而且会根据结果不断调整下一步，直到达成目标（当然也可能失败）。

ChatBot像咨询台：你问一句，它答一句，答完就结束。Agent像带着工具箱的工程师：你布置一个任务，它会思考方法，然后用工具来执行步骤；如果没完成，再继续下一步。

• 任务的进度：当前处于总流程的哪个节点、下一步是什么等。
• 窗口内的短期状态：提示词、最新消息记录、工具调用及结果、规则等。
• 需加载的长期状态：需要Agent从长期存储或接口中加载的内容，比如文件、数据库、API结果、搜索结果等。

有了Agent State管理，Agent系统随时可以“知道”：我从哪里来、要到哪里去、和模型说了什么、改了哪些代码、查了哪些客户的信息等等。

Agent State在实际系统中需要具备可持久化保存的能力：缓存、文件、数据库（容错级别不一样）等。

【工程 Tips】

Agent State在工程上的一个重要意义在于：通过其持久化保存与必要的检查点机制，可以让Agent系统具备随时“断点续运行”、甚至“重放任务”的能力。这对关键任务下的企业Agent系统尤为重要。

06 Context Engineering（上下文工程）：模型能“看到什么”

如果说Agent State解决的是Agent在运行时“知道什么”（当前进度、历史对话、从记忆中加载的必要信息等），那么上下文解决的是另一个问题：在每一轮与模型对话时，模型“能够看到什么信息”。

所以上下文（Context）与状态（State）之间的界限就很清楚了：State是Agent的事实空间——但不一定在每轮交互中都输入LLM；Context是LLM的可见视野——LLM用于推理与决策的全部信息。

既然这样，把所有的信息都交给模型不就行了？显然不行，原因在于：模型的上下文空间是有限资源（比如最大1M），而且上下文并非越多越好，“营养搭配”很重要，要有结构、有重点。

所以，我们才需要上下文工程：为LLM提供所有用于合理推进任务的上下文信息的方法。更具体一点，它不是简单地往模型里塞资料，而是要把正确的信息，在正确的时间，以正确的形式送到模型面前。

以一个Bug修复的任务为例：不是直接塞给它所有代码和设计文档，而是要决策送入哪些设计文档、业务知识、代码、日志、可用工具；这些信息什么时候获取；哪些历史对话要被丢弃，哪些要压缩；哪些人类约束和边界；用什么结构与顺序送入模型。

【工程 Tips】

理解了上下文工程，它的工程意义就非常清楚：它本质上是Harness工程的一部分，直接决定了LLM到底在基于什么做决策。看到的是一个清晰的“环境”，还是混乱的“世界”，这是整个Agent系统的大脑——LLM正常工作的前提。

07 Context Rot（上下文腐化）：复杂上下文的信息退化

上下文工程解决的是“把正确的信息送进模型”，但随着任务推进，上下文窗口中的信息越来越拥挤，模型反而开始“看不清重点”。这就是著名的“上下文腐烂”问题。

它说的是尽管当前主流模型的上下文窗口越来越大（从最初的4K、8K到现在的1M），可以容纳更多信息输入，但模型未必更聪明，反而可能被分散注意力、被无关信息干扰甚至误导。早期“Lost in the Middle”以及“大海捞针”的研究已经发现，上下文中的信息并非总会被“关注”到，窗口大小、信息所处的位置都会有影响。

这就像开会时会议桌上的情况。如果只有一份合同在，大家很容易聚焦并理解会议主题；但如果堆积了大量文档和邮件，大家反而抓不住重点。

Agent也是一样，长上下文并不总是越多越好。如果信息有用而结构清晰，自然有帮助；但大量冗余、无关的内容只会干扰模型的注意力，让推理不稳定。比如，在一个行业应用的Agent中，给模型塞入大量与当前任务无关的、未经治理的业务知识文档，很容易让模型“失焦”；而应该通过检索机制、按需加载等策略，让模型优先看到最重要的信息。

【工程 Tips】

具体到Agent系统工程，应遵循的规则是：借助上下文工程，让上下文尽量保持精简。具体包括：指令与规则保持短而具体、过期信息及时卸载、日志信息先压缩或摘要、借助索引做精准检索、检索结果做合理排序（Rerank）、及时清理无用的工具结果等。分层、按需加载、压缩、检索，都是真正可持续的上下文策略。

08 Prompt Caching（提示词缓存）：别让模型理解重复信息

现在我们解决了“给模型看什么”，也知道“并非越多越好”，但还有一个问题：每次给模型的上下文中，一些重复的内容，是否都要重新运算一遍？

在一个真实的Agent系统中，每一轮对话可能会携带同一批内容：系统提示、工具说明、项目规则、少量示例、前几轮对话等。本质原因是模型本身是无状态的——没有“记忆”能力，每一轮对话都需要输入必要的全部上下文。

如果每一轮都让模型完整重读并计算这些重复内容，就像学习新课文时，每次都把前面学过的课文重新理解一遍，不仅慢，而且昂贵（浪费Token）。

所以Prompt Caching的思路就是：把那些每次不变的上下文“存起来”，下次就不必重新处理。在模型实现中，缓存通常基于前缀匹配，因此稳定内容需要被组织在Prompt的前部，所以也被称为“稳定前缀”。

第一次调用时，系统会完整处理所有内容，包括系统提示、工具定义、规则和背景信息，并进行缓存。之后的每一轮调用，输入中重复的“稳定前缀”就可以命中并复用缓存，处理成本大大降低。这特别适合长会话、长时间运行、前缀稳定的Agent任务，比如编码。如果没有缓存，成本会被稳定上下文反复放大。

【工程 Tips】

工程实践中的一个关键策略是：保持稳定的上下文前缀，有助于降低成本并提高响应速度。把稳定、有价值、反复用的内容（如系统提示、整体规则、任务背景等）放前面；而每轮变化的用户输入、执行反馈等放后面。但注意，缓存并不能使你的上下文质量更高。错误的上下文被缓存，也只是让错误的成本更低，并没有让错误变正确。

09 Ontology（本体）：让AI听懂企业的业务语言

即使已经学会了如何筛选信息、组织信息、控制信息进入模型的方式，Agent依然会在企业任务中理解出错。原因不在于你给的信息不够多，而是：模型并没有真正理解你的信息在企业自身业务背景下的语义和规则。

比如，在企业系统里，一个词的含义可能并非固定的。“ALLOCATED”在ERP里可能代表库存已锁定，在生产系统里可能代表产能已分配，在客服系统里又可能只是一个状态字段。但对于语言模型来说，它看到的是一个字符串——如果不提供更多的语义信息，模型在做判断时可能就是基于通用语义做推测。这也是企业Agent常见的一类失败来源。

而这正是Ontology要解决的问题：用一种标准的形式，对企业的业务世界进行建模，作为Agent的“业务地图”。

说白了，就是把企业里的业务对象、属性、关系和规则讲清楚。比如电信系统里的客户、套餐、订单、工单、开通、计费、退订分别是什么、有什么属性，它们之间什么关系（比如客户-<生成>-订单），有哪些约束规则（比如欠费客户无法变更套餐等）。注意，本体一定是语义的表达，而不是定义数据库结构——企业的多个系统可能有不同的“客户表”，但在语义层，“客户”只有一个含义。

【工程 Tips】

本体对于Agent系统的一个典型应用是：让企业规则从代码和经验中抽离，沉淀到可计算、可推理、可复用的业务语义层（本体），并提供给Agent系统使用（通过本体的“推理机”）。这样，当业务规则发生变化时，不需要在多个系统中同步修改逻辑，只需要在本体中调整定义，所有基于它的Agent行为都会自然变化。总的来说，本体的意义在于帮助企业级Agent系统理解企业业务，并基于统一的业务语义层做推理，而不是简单的“文字”推理。

10 Live Retrieval（实时检索）：别让模型靠过期信息推理

上下文工程解决的是“在这一轮推理中，模型应该看到什么信息”，但这些信息，特别是企业的业务知识与事实，从哪里、用什么方式获得？

模型并不直接拥有真实世界的数据，它看到的所有内容，本质上都必须被“喂进Context”。但业务事实在不断变化，代码在不断更新，系统状态在不断流转。如果这些变化不能被持续地、准确地送入模型上下文，那么即使Context设计得再好，也只是基于“过期信息”做推理。

这就是Live Retrieval可以发挥作用的地方：为Agent提供一个持续连接外部世界的“信息获取机制”，让模型在需要做决策时，能够随时获取当前最新的知识与事实。

相对于本体：Ontology定义“业务世界是怎样的”，Live Retrieval则提供“这个世界发生了什么”。

我们熟知的RAG可以作为Live Retrieval的一种实现方式——用来在任务开始或过程中，从外部知识源（文档库、代码库、知识库）中检索与当前任务相关的信息，并注入到Context中。具体的检索技术可以是向量、图谱、关键词，或者融合检索。但实际上Live Retrieval的范围更大，它强调的是实时性与持续性，也就是说，模型在执行过程中可以不断从外部系统获取最新状态。例如：编码Agent可能查询数据库的最新Schema，客服Agent需要查询CRM系统的客户信息等。

【工程 Tips】

在工程上，“检索”这件事情远没有看起来那么简单。因为AI世界的检索不是一个简单的数据库查询，而是一个决策系统：查什么、查多少、如何确保相关性、如何排序等等。如果检索做得不好，错误的信息会进入Context，会被模型当作参考知识使用，从而放大决策错误。

所以，Live Retrieval的核心是建立一种机制：让模型每一次关键决策，都尽可能基于真实世界的知识与状态，而不是静态的历史记忆。

如果把这10个概念连起来看，它们都侧重在基础运行机制——让Agent在运行时能够看到必要的信息，并理解、思考与行动。但当Agent真正进入工程落地，还需要考虑更多的系统能力问题：怎么使用工具、如何记忆、Agent之间怎么协作、如何评估与管控等等。这些，我们将在下篇拆解。