一文讲透 Agent 应用中的上下文工程
目录
（二）为什么在 Agent 时代，上下文会取代 Prompt 成为核心问题
（三）为什么很多 Agent 项目在原型阶段顺利，在生产阶段失速
（四）第四阶段：Planner、State、Workflow
一、上下文工程到底为什么重要
（一）从几个真实的工程症状说起
如果一个团队只是做过几次 Agent Demo，通常会形成一种相对乐观的判断：现在的大模型已经足够强，只要补上函数调用、接一点知识库、再做一层工作流封装，一个可用的 Agent 系统似乎就差不多成形了。很多原型阶段的项目，确实也会给出这样的信号。用户提问，模型回答；用户下指令，模型调工具；接入私域文档后，业务回答看起来也比纯大模型更像样。
但系统一旦进入真实流量环境，很多问题会迅速浮出水面，而且这些问题往往并不零散，而是具有很强的一致性。
最常见的现象，是系统在短对话里表现不错，在稍长一点的任务链路中就开始漂移。用户前面明确提过的约束，在后面轮次被模型忽略；工具执行结果明明返回成功，模型下一步却继续重复调用；RAG 已经召回了正确文档，最终答案却建立在一段无关内容之上；会话越长，系统越慢，token 消耗越高，而回答质量并没有同步上升。更复杂一点的场景中，还会出现跨轮记忆污染、工具结果误解、任务状态丢失、多个 Agent 之间信息不一致等问题。
这些症状看上去分别属于不同模块：有些像检索问题，有些像记忆问题，有些像规划问题，有些像模型能力问题。但如果把这些现象放到同一条因果链上去分析，会发现它们的根部往往相同：模型每一次推理时，究竟拿到了什么信息，这些信息是如何被筛选、组织、裁剪、更新和传递的。
这就是上下文工程的核心。
它不是一个只关乎 prompt 写法的小技巧，也不是在已有 Agent 架构上再补一层装饰。对于真正进入生产的 Agent 系统来说，上下文工程决定了系统是否能够持续稳定地把对的信息，在对的时刻，以对的方式交给模型。
（二）为什么在 Agent 时代，上下文会取代 Prompt 成为核心问题
在传统软件系统里，程序状态通常是显式的。变量、数据库记录、缓存、事件消息、状态机节点，这些都以可计算、可验证、可追踪的形式存在。工程师知道系统当前处于哪个阶段，也知道某个结果是由什么输入和什么规则推导出来的。
但在大模型驱动的 Agent 系统中，真正做决策的引擎并不是一段确定性程序，而是一个高度依赖输入上下文的概率模型。对于模型来说，是否能做出正确决策，取决于本轮输入中包含了哪些事实、规则、状态和约束。这意味着，系统行为的稳定性很大程度上不再由代码逻辑直接保证，而是由上下文质量间接决定。
在单轮问答时代，提示词工程之所以重要，是因为 prompt 几乎就是模型的全部输入；而在 Agent 时代，prompt 已经只是上下文的一部分。系统提示词、用户输入、历史对话、RAG 召回结果、工具返回值、阶段计划、长期记忆、权限信息、运行策略、错误摘要，这些都可能进入模型的工作上下文。真正影响效果的，不再是某一句提示词写得是否优雅，而是这个上下文工作集是否被工程化地管理起来。
从这个意义上说，Prompt Engineering 更像是 Context Engineering 的子集。前者关注怎么写，后者关注写什么、何时写、写给谁、保留多久、出了问题如何追踪。
（三）为什么很多 Agent 项目在原型阶段顺利，在生产阶段失速
这是一个非常典型的现象。原型阶段的数据量小、任务短、用户耐心高、场景约束弱，团队往往能通过堆 prompt、堆示例、堆工具快速做出一个惊艳的交互原型。此时，系统的大部分问题都还没有显形。
但生产环境会强行放大上下文工程中的短板。用户请求不再标准，历史上下文开始累积，工具返回结果不再总是干净，知识库变得庞大且重复，安全权限边界开始显得重要，系统成本与延迟也进入约束条件。原型阶段靠大上下文拼接和模型自由发挥解决的问题，在生产里会逐渐暴露为系统性的不可控。
这也是为什么很多团队会产生一种错觉：模型升级了，效果却没有显著变好；RAG 加上了，复杂任务还是不稳定；Memory 做了，Agent 反而开始胡乱记忆。问题并不在于这些能力无效，而在于它们如果没有统一纳入上下文治理框架，就只是增加了新的信息源和新的复杂性来源。
二、什么是上下文工程
（一）定义
如果用一句更工程化的话来定义，上下文工程就是围绕模型推理所需工作集而展开的设计、组织、传递、压缩、更新和治理体系。
这里的关键不在于上下文这个词，而在于工作集。工作集意味着，进入模型输入的内容不是简单的信息堆积，而是一组在当前任务阶段真正需要被模型消费的材料。它们必须兼顾完整性、相关性、时效性、结构性与成本约束。
因此，上下文工程不是做一段长 prompt，也不是把所有可能有用的信息全塞进去。它关心的是，系统如何判断什么信息应该进入当前上下文，什么信息应该保留在外部状态中，什么信息应该以摘要方式呈现，什么信息必须保持原始精度，什么信息应该完全禁止进入模型。
这种视角的变化非常重要。因为一旦把上下文看成工作集，而不是看成输入文本，系统设计思路就会从文本拼接转向信息治理。
（二）上下文的组成
很多刚接触 Agent 的开发者，在提到上下文时，想到的通常只有两类东西：历史对话和检索文档。这当然是上下文的一部分，但离真实系统的全貌还差得很远。
在一个成熟的 Agent 系统里，上下文通常至少包含以下几层内容。
一类是规则与指令层。这包括系统提示、角色设定、行为边界、合规要求、输出格式、工具使用约束、冲突处理规则等。它们决定模型应该如何行动。
一类是任务与状态层。这包括当前任务目标、阶段计划、已完成步骤、待确认事项、失败重试记录、用户确认结果、节点间传递变量等。它们决定模型当前身处哪里、接下来应该做什么。
一类是事实与知识层。这包括用户当前输入、历史事实、RAG 检索结果、数据库查询结果、工具返回值、业务实体属性、组织知识和实时环境数据。它们决定模型可以基于什么信息进行判断。
一类是个性化与长期记忆层。这包括用户偏好、历史行为画像、组织常用规则、稳定习惯和跨会话持久信息。它们决定系统是否能够在长期交互中形成连续性。
一类是控制与安全层。这包括权限、可用工具白名单、租户隔离信息、脱敏策略、审计标识和风险等级。它们决定哪些信息和能力可以被模型看到和使用。
如果这些内容都混在一段自然语言里交给模型，系统很快就会变得不可解释、不可维护。上下文工程的职责，恰恰就是把不同性质的内容分层处理，并在必要时对不同层采用不同的表达形式。
（三）上下文的生命周期
理解上下文工程，一个很关键的切口是生命周期。很多设计失败，不是因为单次上下文组装得不好，而是因为没有意识到上下文本身会在系统中流动、累积、变形和失效。
一段上下文从产生到消亡，通常会经历几个阶段。它首先被生成，可能来自用户输入、知识检索、工具执行、模型推理或者系统规则。生成之后，并不会全部进入模型，而是要经过筛选和排序。进入当前模型上下文后，部分信息会被保留原文，部分被压缩摘要，部分被结构化提炼。模型完成本轮推理后，又会产生新的中间信息，这些信息中有一部分会写回状态系统、记忆系统或日志系统。随着任务推进，原先的上下文可能变得无效甚至有害，必须被替换、降权或删除。
所以，上下文工程更像是一个循环系统，而不是一个单次模板。
如果没有这个生命周期视角，团队就很容易把所有注意力放在入口，拼命思考如何把更多信息送给模型，却忽略了更重要的问题：哪些信息不该继续留在系统里。
（四）分层理解上下文
为了让上下文治理具备可操作性，实践中通常需要做分层。一个非常实用的分法，是把上下文区分为瞬时层、会话层和长期层。
瞬时层服务于当前一步决策。它往往包括当前用户输入、当前任务节点指令、最近一次工具结果、当前阶段必要的状态变量，以及本轮最相关的检索片段。它的特点是相关性最高、时效性最强、生命周期最短。瞬时层最怕噪声，因为它直接影响当前决策。
会话层服务于一次任务或一次连续会话。它记录这个会话中已经确认过的内容、执行到的步骤、尚未解决的问题、阶段摘要以及关键用户选择。会话层的价值不在于保留所有原始对话，而在于维持任务连贯性和恢复能力。
长期层服务于跨会话复用。它更关注稳定信息，比如用户长期偏好、组织规范、常见知识、历史案例、长期业务关系和被确认过的重要事实。长期层最怕的是污染和过期，因为一旦写进去，它会在未来很多次任务中被反复使用。
一旦分层清楚，很多架构决策就变得自然了。瞬时层强调按需供给和严格预算；会话层强调结构化快照和可恢复性；长期层强调写入门槛、版本控制与过期机制。真正成熟的 Agent 系统，几乎不会把这三层混成一个统一的大 prompt。
三、为什么上下文会成为 Agent 的第一性约束
（一）模型不是在思考世界，而是在思考你给它的世界
这是上下文工程中最值得反复强调的一点。我们经常说大模型有推理能力、规划能力、总结能力和工具调用能力，但所有这些能力都有一个前提：模型只能基于当前可见的上下文做推理。它并不直接接触真实世界，而是接触你拼接给它的一个局部世界。
这个局部世界如果缺失了关键约束，模型就会在错误边界内做出看似合理的决策。如果其中掺杂了过期状态、冲突事实和无关噪声，模型也可能在错误信息之上保持高度流畅。换句话说，很多时候模型出错并不是因为能力不足，而是因为上下文让它在错误的地基上工作。
一旦接受这一点，就会明白一个重要结论：Agent 的可靠性不是单纯由模型上限决定，而是由模型上限与上下文质量的乘积决定。模型再强，如果输入世界是错的、乱的、过期的，输出也很难真正稳定。
（二）上下文窗口不是唯一约束，注意力稀释更关键
讨论上下文时，大家最先想到的常常是上下文窗口长度。窗口不够大，当然会限制系统能力，但在很多真实系统里，真正更棘手的问题并不是窗口装不下，而是装得下之后模型并没有更好地使用这些信息。
随着上下文变长，模型会出现注意力稀释。重要约束被埋在无关信息中，模型虽然从 token 数量上看到了它们，却未必在推理时赋予足够权重。特别是在多轮 Agent 场景里，前文聊天、检索碎片、工具日志、任务计划、系统规则同时存在，模型面对的是一个复杂的混合输入。此时问题已经不是容量，而是组织。
这也是为什么一个 30k token 的混乱上下文，效果常常不如一个 6k token 的精心编排上下文。上下文工程真正要解决的，是让模型把注意力放在正确位置，而不是一味追求更多 token。
（三）状态缺失，是很多 Agent 不稳定的真正原因
很多团队一开始会把 Agent 做成对话系统，认为只要保留聊天历史，模型就能维持连续性。短会话中这通常还能成立，但只要任务稍微复杂，问题就会出现。
因为对话历史是叙事性的，不是状态性的。模型可以通过对话推测当前任务到了哪一步，但这种推测本身并不可靠。任务已经确认的参数、已完成的步骤、需要人工审批的节点、失败后的回退位置、工具执行结果的最终状态，这些都更适合以显式状态形式存在，而不是留在对话中让模型自己回忆。
这也是为什么很多 Agent 表现得像一个聪明但不稳定的助理：它理解语言很好，但对流程和状态控制经常失误。原因不是模型不会理解，而是系统没有把状态显式交给它。
（四）知识、状态、记忆，三者必须分开治理
在很多落地失败的项目里，有一个非常典型的问题：知识、状态和记忆被混为一谈。结果就是系统越来越会存东西，却越来越不知道该怎么用。
知识通常是外部的、规模化的、按需召回的内容，比如文档、手册、政策、数据库记录。状态通常是当前任务进行中的结构化信息，比如步骤进展、已确认参数、待办事项、节点结果。记忆则更偏长期和跨会话，是被提炼后的用户偏好、业务关系、稳定事实。
这三者虽然都可能进入模型上下文，但它们的治理策略完全不同。知识重在召回质量与时效性，状态重在准确性与显式控制，记忆重在筛选、沉淀和防污染。如果不把它们拆开，系统就会既查不准资料，也存不好状态，还会把记忆搞成垃圾场。
四、架构演进
（一）第一阶段：单轮 Prompt 驱动
Agent 的最早形态，其实并不复杂。系统提示词加上用户输入，模型生成回答。如果需要格式化输出，就再加一点 Few-shot 示例和模板约束。这个阶段的优点是极其简单，链路短、开发快、效果可见。
但它的边界也十分明确。单轮 Prompt 本质上是一次性推理，模型无法持续维护任务状态，也无法可靠接入外部世界。所有能力都被压缩在一个输入窗口里，一旦任务涉及跨轮追踪、知识更新或工具协同，这种模式就很快到顶。
（二）第二阶段：RAG 增强
随着企业知识问答需求大量出现，RAG 成为最先成熟起来的增强路径。系统不再把知识硬编码进 prompt，而是在用户提问时检索相关文档，将召回结果拼接到上下文中。这样既减轻了窗口压力，也提高了知识的新鲜度和扩展性。
这一步很重要，因为它把上下文从静态文本扩展成了动态检索结果。但要注意，RAG 解决的是模型知道什么，不是模型当前处于什么状态、应该做什么。很多团队在这个阶段误以为有了 RAG 就有了 Agent，结果在复杂任务中很快发现，知识丰富了，过程却依旧混乱。
（三）第三阶段：Tool Use 与 Memory
当系统开始接工具时，Agent 的性质发生了明显变化。模型不再只是回答问题，还要根据当前上下文选择工具、解释工具结果、决定下一步行为。与此同时，记忆模块开始出现，用来保留多轮对话中的事实和偏好。
这个阶段的变化在于，上下文第一次具备了行为闭环。模型根据上下文决定行动，行动产生新的上下文，新的上下文又影响后续推理。系统已经不再是静态问答，而是动态执行。
但这一阶段也是很多系统最脆弱的时候。因为工具结果、历史对话、长期记忆开始共同作用于推理，如果没有明确治理，它们会迅速形成信息缠绕。看起来系统变强了，实际上控制面变弱了。
（四）第四阶段：Planner、State、Workflow
再往后，复杂任务推动了 Planner、状态存储、工作流编排和图式执行框架的发展。大家开始意识到，靠模型在大上下文里自主规划并不稳妥，必须让系统承担更多控制职责。
于是，任务被拆成显式节点，状态被存入结构化存储，模型只在特定节点做局部推理，节点之间的跳转由工作流规则或状态机控制。这样一来，上下文不再是一次性堆给模型的全集，而是按节点供应的工作包。
这一步标志着 Agent 从模型驱动应用，演化为模型参与的系统。上下文工程也从输入组装，演化为上下文操作系统。
（五）第五阶段：上下文操作系统
真正成熟的生产系统，会进一步意识到，光有工作流还不够。因为即使节点划分清晰，节点内部仍然面临同样的问题：要向模型提供哪些知识，保留哪些状态，如何处理摘要，如何屏蔽无关信息，如何做权限隔离，如何追踪某次错误是如何被上下文放大的。
于是，架构开始出现一个更清晰的中间层：上下文编排与治理层。它既不同于底层存储，也不同于业务工作流，更不是简单的 prompt builder。它负责把外部知识、状态系统、记忆系统、权限系统、工具返回结果统一装配为模型可消费的工作集。
所谓上下文操作系统化，并不是一个夸张说法，而是在强调：在复杂 Agent 里，上下文已经不是附属物，而是一层需要独立设计、独立观测、独立演进的基础设施。
五、主流方案
（一）直接拼接历史对话
很多 Agent 最早的做法，是把最近若干轮对话直接带入上下文。这种方法之所以普遍，不是因为它最先进，而是因为它几乎不需要额外设计。对于聊天型产品、小型 Copilot 或任务长度很短的场景，它也确实有效，因为对话本身就包含了大量上下文线索。
它的优势主要体现在两个方面。其一是实现成本低。系统只需要维护消息列表并控制截断策略，就能让模型感受到连续对话。其二是语义自然。相比结构化状态，自然语言对话更完整地保留了语气、偏好变化和隐含背景，模型往往也更容易直接消费。
但它的问题也非常明显。最核心的问题，是对话历史是一种叙事载体，而不是状态载体。模型可以从中推测任务状态，却很难稳定地从中提取出精确、可复用的控制信息。对话越长，噪声越多；越靠前的关键约束，越容易被后续内容稀释。与此同时，历史对话里还会混入闲聊、误解、临时假设和已经失效的信息，这些内容原样保留并不总是有益。
所以，直接拼接对话历史适合短链路、低风险、以语义连贯性为主的场景，例如泛助手、轻咨询、陪伴式交互。但一旦任务涉及明确步骤、多次工具调用和状态恢复，仅靠聊天历史几乎一定会遇到稳定性瓶颈。
（二）RAG
RAG 之所以成为 Agent 体系中的基础能力，是因为它很好地解决了模型知识边界问题。对于知识密集型任务，把海量文档交给模型记忆显然不现实，也不经济；通过向量检索、关键词检索、混合检索等方式，在需要时把最相关文档送进上下文，是更合理的路径。
RAG 的工程优势很明显。它让知识从模型参数中解耦，具备更新性、可治理性和企业适配性。对于 FAQ、政策问答、合同分析、知识助手、文档搜索增强等场景，RAG 是几乎不可替代的底层能力。
但 RAG 也有非常明确的边界。它解决的是信息召回，不是任务控制。它可以告诉模型有哪些相关材料，却不会告诉模型当前任务执行到了哪里、用户在此前轮次已经确认了什么、这次工具调用结果该如何写回状态、当前阶段是否允许继续动作。很多团队把 RAG 接上之后，发现回答变得更专业了，但复杂任务还是不稳，原因就在这里。
此外，RAG 的效果高度依赖索引质量、分块策略、召回排序与上下文组织方式。很多人以为 RAG 问题主要出在 embedding 模型不够强，实际上工程上更常见的问题是文档切块不合理、召回结果重复、排序不感知当前节点语境，以及被召回内容进入上下文后没有重新组织，只是简单拼接。
RAG 适合承担事实性知识供给层，而不应被误用为状态管理层或记忆层。
（三）Memory
Memory 听起来非常符合直觉。人类助理之所以像助理，是因为会记住你的偏好、项目背景和历史决策。所以很多 Agent 系统一开始就会引入记忆模块，希望它帮助系统实现个性化和长期连续性。
从目标上看，这个方向是对的。没有长期记忆，Agent 很难真正形成用户感知中的连续服务能力。特别是个人助理、客服助手、CRM 场景、销售辅助、长期项目协作场景，没有记忆几乎不可能建立深度体验。
但 Memory 之所以难，不是因为存不进去，而是因为不知道该存什么、何时存、以什么形式存、什么时候删。很多系统把每轮对话都摘要写入记忆库，或者把模型推断出来的内容也一并长期保存。短期看像是在让 Agent 越来越懂用户，长期看却非常容易造成污染。一次误判、一次错误抽取、一次临时偏好，都可能在未来被反复召回，逐渐放大为系统性偏差。
因此，Memory 的核心不是存储，而是记忆治理。它需要明确区分稳定偏好与临时意图，区分确认事实与模型推断，区分高复用长期信息与一次性会话状态。真正成熟的 Memory 系统，通常会有写入门槛、置信度标注、来源记录、过期机制和冲突修正策略，而不是把它做成一个长期聊天摘要仓库。
（四）显式 State
如果说 RAG 是知识供给层，Memory 是长期连续性层，那么 State 就是复杂 Agent 真正的骨架。很多团队在做多步任务、工具执行和流程控制时，最终都会走到这一步：必须把状态显式存下来，而不能依赖模型从历史文本里自行恢复。
显式 State 的价值在于，它把任务当前的关键控制信息转化为结构化、可验证、可回放的对象。比如，当前步骤编号是什么，已确认参数有哪些，哪些子任务已完成，哪些待人工确认，最近一次工具调用是否成功，失败原因是什么，当前是否允许进入提交阶段。这些内容如果只存在于聊天历史中，系统永远处于模糊控制；一旦变成显式状态，工作流和模型都能围绕它稳定运行。
显式 State 的局限在于设计成本。它要求团队对业务任务有相对清晰的过程认知，能够抽象出状态字段和节点转移规则。这对探索期项目可能显得笨重，但对复杂生产任务而言几乎是必要条件。尤其是在需要重试、回滚、人工介入、审计追踪的场景里，没有 State 的 Agent 往往看起来灵活，实际上非常脆弱。
一个常见误区是把 State 做成另一个大 JSON，然后仍然无差别丢给模型。那样虽然形式上结构化了，但没有发挥 State 的真正价值。State 的重点不只是结构化，更是系统用它来控制行为和限制上下文范围。
（五）工具返回结果作为上下文
工具是 Agent 与外部世界连接的主要方式。无论是查数据库、下工单、发邮件、执行代码还是调用业务 API，工具都会生成大量外部事实。理论上，这些结果比模型自己的推断更可信，因此很多团队会把工具结果当成高优先级上下文直接回灌给模型。
这件事方向没错，但实践中最容易被忽视的问题，是工具结果往往不是为模型设计的。真实系统中的 API 返回通常包含大量元信息、内部字段、分页结构、错误码、埋点字段和与当前任务无关的数据。把它们原样塞进模型上下文，等于要求模型临时充当数据解析器、字段筛选器和业务语义转换器。
结果往往是两头失效：一方面模型消耗了大量注意力处理噪声；另一方面真正有用的字段被淹没在结构细节中，导致工具已经正确执行，模型却没有正确理解。
因此，工具结果不应该直接等于模型上下文。两者之间通常需要一个中间表示层，把原始工具结果翻译成业务语义明确、结构清晰、字段经过筛选和解释的上下文片段。对于高风险任务，甚至应该区分哪些工具结果只用于系统状态更新，哪些工具结果才有必要交给模型继续推理。
（六）工作流编排
当 Agent 开始涉及多步骤任务时，工作流编排看起来是天然答案。通过显式节点、条件分支、重试策略、人工审批和状态转移规则，系统终于从纯模型驱动走向了更可控的执行方式。
工作流编排确实能显著提升稳定性，特别是在流程明确、节点边界清晰的业务里，比如客服工单、审批流、生产运维 SOP、订单处理、代码生成流水线等。系统可以决定什么阶段调用模型、什么阶段调用工具、什么阶段必须人工确认，从而把模型限制在更可控的局部问题内。
但工作流并不会自动解决上下文问题。很多团队上了工作流之后，仍然在每个节点里拼一个巨大的上下文，让模型自行理解。这时工作流只是控制了节点顺序，并没有控制节点内部的信息供给。换句话说，工作流解决的是宏观过程控制，上下文工程解决的是微观决策输入。两者必须配合，缺一不可。
六、主流架构的详细对比
（一）模型中心架构
模型中心架构的思路很直接：系统把尽可能多的信息、工具描述和行为规则交给模型，由模型统一决定怎么理解任务、是否需要拆解、何时调用工具、工具结果如何解释、下一步如何继续。很多早期 Agent 实现、Auto Agent 风格原型，以及部分研究型系统都接近这一思路。
这种架构的优势主要体现在灵活性和开发速度上。由于系统控制逻辑较少，开发者可以快速验证新任务类型，不需要过早抽象状态模型或流程结构。对于需求快速变化、任务模式还不明确的探索期项目，这种方式非常有吸引力。模型本身拥有较大自主权，也意味着它可以在未知边界内展示出一定涌现能力。
但模型中心架构的问题同样明显。第一，它对上下文质量高度敏感，一旦信息组织混乱，模型行为会迅速漂移。第二，它很难做强约束控制，因为很多决策依赖模型自己遵守提示词和角色边界。第三，它不利于回放和调试。出现错误时，往往很难界定是检索问题、提示问题、状态问题还是模型自由发挥造成的问题。第四，它在成本和延迟上通常也不够友好，因为为了让模型具备足够全局感知，系统倾向于持续喂入大上下文。
因此，模型中心架构适合探索期、研究型系统、开放性创作任务、流程不确定任务，以及对严格可控性要求不高的场景。但只要业务开始强调稳定率、成功率、审计性和确定性，这种架构通常会碰到很强的天花板。
（二）系统中心架构
系统中心架构则采取相反思路。它把流程控制、状态管理、权限边界、工具调度和上下文装配更多地收回到系统层。模型仍然负责语义理解、局部判断、文本生成和模糊决策，但不再承担整个系统的全局控制责任。
这种架构的优势在生产场景中尤其突出。首先，它有更清晰的职责边界。系统负责确定性的事，模型负责概率性的事。其次，它更容易做可观测与调试。因为每个节点输入、状态变更、工具调用和模型输出都可以被追踪。再次，它更利于控制成本。不同节点只注入必要上下文，不必长期维持大窗口。最后，它也更利于安全治理，因为权限和脱敏可以在上下文装配之前完成，而不是事后依赖模型遵守规则。
当然，系统中心架构并非没有代价。它需要更高的前期设计投入，尤其是在复杂业务中，需要团队抽象任务节点、状态字段和转移规则。这意味着它不适合所有探索型项目，也不适合业务模式尚未清晰的极早期阶段。过早进行系统化设计，也可能导致架构僵化，限制模型的灵活发挥。
因此，系统中心架构更适合明确业务流程、对稳定性要求高、需要可审计与权限控制的生产任务。它不是万能架构，但在大多数企业 Agent 落地里，往往是更长期可持续的方向。
（三）链式架构与图式架构
很多 Agent 框架的早期实践是链式架构，也就是把一组模型调用、检索、工具调用按顺序串起来。链式架构的好处是理解成本低，适合表达较简单的线性任务，比如检索后回答、总结后分类、提取后填写表单等。
但现实任务很少严格线性。只要出现条件判断、循环重试、工具失败回退、人工介入、并行子任务或多路径决策，链式结构就会迅速变得难以维护。很多项目最开始看似是几步顺序调用，后面业务一扩展，代码里就开始出现大量 if-else、嵌套重试和分支拼接，最后演变成隐式工作流。
图式架构在这个阶段的优势就显现出来了。它把节点、边、状态和转移规则显式表达出来，使得复杂任务不再依赖代码中的隐式流程，而成为可视、可调试、可回放的状态图。上下文也可以围绕节点来设计，而不是围绕整条链路统一设计。
图式架构并不意味着一切都必须复杂化。它真正的价值在于，当任务复杂度超过某个阈值时，图式表达能显著降低整体系统的不透明度。特别是在需要多角色、多工具、多轮状态演进的场景里，它通常比链式架构更适合长期演进。
（四）单 Agent 架构与多 Agent 架构
多 Agent 架构这两年非常受关注，因为它看起来更接近人类组织协作：一个负责规划，一个负责执行，一个负责审查，一个负责调研。对于某些任务，这种分工确实有价值，尤其是角色边界清晰、知识域差异明显的场景，比如代码开发、研究分析、复杂内容生产。
多 Agent 的真正优势，是角色隔离和上下文局部化。每个 Agent 只看到与自己职责相关的上下文，这有助于减少单一大模型承担全部复杂性。同时，不同 Agent 可以采用不同的提示策略、工具权限和记忆策略，从而形成更有结构的协作。
但多 Agent 并不天然更好。它引入了新的系统复杂度：Agent 之间如何传递上下文，传递的是原文、摘要还是结构化状态；一个 Agent 的中间结论如何被另一个 Agent 验证；上下文冲突时谁裁决；共享记忆如何隔离权限；通信成本和延迟如何控制。这些问题如果没有设计清楚，多 Agent 很容易演变成多个不稳定单 Agent 叠加后的更大不稳定系统。
因此，多 Agent 适合角色边界清晰、任务天然可分解且协作收益显著高于协调成本的场景。而在很多企业流程里，一个显式状态驱动的单 Agent 加若干系统节点和工具节点，往往比引入多 Agent 更稳、更便于调试。
七、生产实践
（一）把上下文组装器做成独立层
如果项目已经进入生产落地阶段，我非常建议把上下文组装器从业务逻辑里抽离出来，做成清晰的独立模块。它不应只是一个 helper 函数，更不应散落在各个 Agent 节点里以字符串拼接形式存在。
一个更合理的总体架构，通常包括网关与会话管理、任务编排层、上下文组装器、检索层、状态层、记忆层、工具执行层，以及评测与观测层。模型只是其中的推理内核，而不是全部。
这个架构中，上下文组装器需要承担几类关键职责。它要根据当前节点识别上下文需求类型，向状态层、记忆层、检索层和工具层发起拉取；它要做相关性排序和预算分配；它要把原始数据转成模型可消费形式；它还要在调试时输出完整的上下文快照，便于回放和问题定位。
一旦上下文装配成为独立层，系统就从凭感觉拼 prompt，升级为可治理的信息供应链。
（二）上下文供给流程
在生产中，上下文供给最好不要一步到位，而是分阶段完成。
第一步是采集。系统从所有可能相关的来源获取候选信息，包括会话摘要、状态字段、检索结果、工具返回、长期记忆和系统规则。采集阶段不必过早裁剪，它的目标是建立候选池，避免关键事实漏掉。
第二步是筛选。筛选必须围绕当前任务节点，而不是只围绕用户表面问题。因为同一句话在不同任务阶段，其相关信息完全不同。筛选通常需要结合语义相关性、状态匹配、业务规则和优先级策略。
第三步是组织。组织不是简单排序，而是给信息分区。规则放哪，状态放哪，知识片段放哪，工具结果如何解释，记忆信息如何标注来源，冲突信息如何提示模型，都是组织阶段要解决的问题。
第四步是压缩。压缩的重点不是让文本变短，而是让信息密度更高。可以通过去重、字段抽取、表格化、模板化、摘要化等方式完成，但必须保证关键约束不丢失。
第五步是验证。对于高风险节点，系统还应在上下文送入模型前做一次基础校验，比如检查关键字段是否齐全、是否出现明显冲突、是否有越权数据、token 是否超预算。很多线上事故并不是模型回答错，而是上下文在进入模型前就已经不完整或不合法。
（三）会话摘要
会话摘要几乎是所有长对话 Agent 都会用到的技术，但它常常被做得过于粗糙。很多系统只是定期把一长段历史对话交给模型，请它总结成一段话。这在信息压缩上有帮助，但对复杂任务不够。
更稳妥的方式，是把摘要拆成两部分。一部分是叙事摘要，帮助模型理解会话语境和语义延续；另一部分是状态快照，明确记录当前任务的关键字段。例如，已确认目标、当前阶段、已完成动作、待决问题、外部依赖、失败记录、用户限制条件等。
前者保证对话自然性，后者保证系统可控性。两者缺一不可。只有叙事摘要，系统容易丢状态；只有状态快照，系统又容易丢失语义背景和用户表达中的隐含含义。
（四）知识召回
RAG 工程里最容易偷懒的一件事，就是把用户输入直接拿去做向量检索，然后把 Top-K 文档塞进模型。这种方式对简单问答还可以，但在 Agent 场景里，通常远远不够。
更有效的做法，是做任务感知检索。也就是说，检索 query 不是简单等于用户当前输入，而是由当前任务节点、已确认条件、业务实体、时间范围和用户权限共同构成。比如，在售后工单处理场景中，当前节点可能是判断是否可退款，那么检索时最相关的并不是用户整段抱怨文本，而是订单状态、退款政策、商品类目、支付方式和时效规则。
此外，检索结果进入上下文前，还应该经过去重、重排和引用标注。很多情况下，模型需要的不只是相关文档，而是被组织成可判断证据的文档。尤其在高准确要求场景中，给模型一个标注了来源和时间的知识片段，往往比给一大段未整理原文更有效。
（五）工具结果
工具结果回灌时，一个很实用的实践是双通道写入。原始结果优先进入状态系统或日志系统，作为权威记录；经过清洗、字段提炼和语义转译的结果，再进入模型上下文。
这相当于把工具结果的权威性和可消费性分开处理。系统层保留精确信息，便于回放、审计和后续业务逻辑判断；模型层只拿到当前任务真正需要的部分，减少认知负担。对于复杂 API，这种做法非常重要，因为原始结果往往对系统有价值，对模型却是干扰。
（六）可观测性设计
没有上下文可观测，就几乎不可能系统性优化 Agent。因为当回答错误时，你无法知道模型到底看到了什么、漏掉了什么、被什么干扰了。
因此，生产系统至少应保存以下几个层面的日志：一是模型调用前的最终上下文快照；二是各来源上下文的构成比例，例如历史、状态、RAG、工具、记忆各占多少 token；三是检索候选和最终入选内容；四是摘要前后差异；五是状态变更记录；六是关键节点的模型输出和系统裁决结果。
这套观测不是为了追求日志丰富，而是为了回答真正重要的问题：错误究竟发生在信息获取、信息组织、信息压缩，还是模型推理阶段。
八、常见坑
（一）上下文膨胀
这是最常见、也最容易被误判的问题。系统效果一旦下降，团队的直觉往往是再多喂一点信息，希望模型别漏掉关键背景。短期看，部分样例可能确实变好；长期看，这种做法往往会形成膨胀螺旋。
膨胀之后的上下文，一方面增加 token 成本和延迟，另一方面会稀释关键事实。模型不是一个无限专注的阅读器，它面对大而杂的上下文时，也会发生注意力分散和权重错配。很多时候，系统不是因为信息不够而错，而是因为信息太多、层次太乱。
真正有效的解决方式，不是无脑摘要，而是建立上下文准入制度和预算制度。哪些信息属于强制进入项，哪些是按需项，哪些必须在特定节点才能出现，哪些永远只保存在外部状态里，这些都要有明确策略。
（二）记忆污染
Memory 是最容易被过度乐观对待的模块。很多团队以为，只要把更多历史信息存起来，Agent 就会越来越聪明。但现实常常相反。没有筛选机制的记忆系统，最终会被临时偏好、错误抽取、模型误判、重复内容和过期事实填满。
记忆污染最危险的地方在于，它不像一次模型输出错误那样即时显现，而是会在未来不断被召回和放大。系统会显得越来越自信，但依据越来越不可靠。
因此，对 Memory 的治理应该像治理数据库主数据一样谨慎。记忆写入最好来自高置信度事件，比如用户明确确认、工具系统返回、长期重复行为模式，而不是模型的单次推断。记忆也要允许修正、撤销和过期，而不是永久追加。
（三）摘要失真
摘要是上下文压缩的重要手段，但如果过于依赖自由生成式摘要，它会在不知不觉中引入事实偏差。尤其是涉及时间、数字、条件、责任边界、例外条款等信息时，自然语言摘要很容易把原始精度磨平。
对于纯聊天型产品，这种问题也许可以接受；但对于合同、财务、审批、报价、工单、交易、运维等场景，摘要失真可能直接导致业务事故。因此，关键上下文不应只做生成式总结，而应配合抽取式字段保留、模板化摘要和结构化快照。
（四）把模型推理过程当长期资产保存
一些团队会把模型的长链条思考、试探性推理和中间分析全文保存在系统里，甚至在后续任务中继续回灌，希望这样能保留思考连续性。实验环境下，这种方式可能在某些任务上有效，但生产中风险很高。
因为模型推理过程本身包含大量假设、尝试和未验证结论。它适合辅助当前轮推理，却不适合作为长期状态或长期记忆。系统真正应该保留的是经过筛选后的决策结果、关键依据、待验证事项和失败原因，而不是完整思维链。
（五）权限和安全边界处理太晚
很多团队在设计上下文时，先考虑效果，最后才补权限和脱敏。这在企业环境里非常危险。因为一旦上下文组装时没有做权限隔离，敏感信息就已经进入模型输入链路，后面再想补救就只剩输出约束了。
正确做法应当是，把权限控制前置到上下文候选池阶段。模型能看到什么，首先由系统决定，而不是先把所有数据都给模型，再希望模型自己不说出来。这是上下文工程和安全工程必须融合的地方。
未来 Agent 系统的差异化，未必主要体现在谁先接入了多少工具、谁做了多少角色分工，而更可能体现在谁拥有更成熟的上下文操作系统。这个系统能够完成分层存储、智能召回、状态抽象、动态压缩、权限控制、质量评估和全链路回放，使模型始终工作在一个高质量、低噪声、强约束、可演进的上下文环境里。
当我们把问题看到这一层，就会明白，上下文工程不是给 Agent 应用锦上添花，而是在决定它能否从一个看起来聪明的原型，成长为一个真正可靠的生产系统。
如果说提示词工程解决的是如何让模型更会说，那么上下文工程解决的，就是如何让模型在复杂系统中持续说对话、做对事、并且在说错和做错时还能被定位、被修正、被进化。这才是 Agent 工程进入深水区之后，真正值得长期投入的核心能力。
~码文不易，留个赞再走吧~
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。
更多推荐
10
0- 0
已为社区贡献6条内容
所有评论(0)