AI Agent 正在从“把一句提示词写得更好”转向“在每一次模型调用前，动态准备正确的信息、工具、状态和约束”。原因很直接：提示词工程主要优化单次请求中的指令表达，而智能体需要跨多轮执行、调用工具、读取知识、保存状态并处理失败。真正决定 Agent 是否可靠的，往往不只是模型会不会推理，而是运行时给模型看到了什么、没有看到什么，以及这些信息是否准确、及时、可授权、可追溯。

上下文工程（Context Engineering）是对模型推理时全部输入信息进行选择、组织、压缩、隔离、更新和评测的系统工程。它包含提示词，但范围还包括会话历史、任务状态、检索证据、工具定义、长期记忆、用户权限、执行反馈与输出契约。Anthropic 将其称为提示词工程的自然演进；LangChain 的官方文档也把大量 Agent 失败归因于“传给模型的上下文不正确”，而不是模型本身没有能力。Anthropic：Effective context engineering for AI agents；LangChain：Context engineering

一句话总结：提示词工程是在设计“怎么问”，上下文工程是在设计“模型此刻应该知道什么、能做什么、必须遵守什么”。

图 1：提示词仍然重要，但已经成为上下文工程的一部分；Agent 的质量取决于每一步动态装配出来的完整上下文。

一、提示词工程和上下文工程到底有什么区别？

提示词工程（Prompt Engineering）是设计系统指令、任务描述、示例和输出格式，使模型在一次或少数几次调用中更稳定地完成任务。它擅长解决“角色怎么定义、任务怎么描述、结果怎么约束”等问题。

上下文工程则面向一个持续运行的系统。它不仅编写指令，还决定当前任务需要装入哪些知识、展示哪些工具、保留哪些历史、读取哪些记忆、附带哪些权限，以及执行后把什么写回状态。上下文不是一段固定文本，而是一份随任务步骤变化的“运行时视图”。

一张表看懂提示词工程、RAG、记忆与上下文工程

概念	核心问题	主要输入	生命周期	典型产物	能否单独解决 Agent 长任务
提示词工程	指令怎样表达得更清楚	规则、角色、示例、格式	相对静态	System Prompt、模板	不能，缺少动态状态与外部信息
RAG	当前问题需要哪些外部证据	文档、数据库、搜索结果	按需检索	相关片段及来源	不能，只覆盖知识供给
Agent 记忆	哪些历史事实或经验应跨轮次保留	用户偏好、事件、任务经验	跨步骤或跨会话	短期状态、长期记忆	不能，还需要选择、权限与编排
上下文工程	本次推理应看到什么、以何种形式看到	指令、状态、知识、工具、记忆、反馈、约束	每一步动态变化	可供模型消费的上下文包	是 Agent 可靠运行的总方法

这个边界很重要：RAG 是上下文工程的“检索供给组件”，记忆是“跨时间状态组件”，提示词是“指令组件”，它们都不等于上下文工程本身。

上下文工程是不是“把更多内容塞进上下文窗口”？

不是。上下文工程追求的是更高的信息密度，而不是更长的输入。Anthropic 给出的原则是：找到能够最大化目标结果的最小高信号 token 集合。Chroma 在 2025 年对 18 个模型的长上下文研究发现，即使任务难度保持不变，模型表现也会随输入长度增加而变得更不稳定，这种现象通常被称为“上下文腐烂”（Context Rot）。Chroma：Context Rot 技术报告

因此，模型标称支持 128K、1M 甚至更长的窗口，只代表“可以接收”，不代表“可以同等可靠地利用每个 token”。上下文窗口是容量上限，不是推荐填充目标。

二、为什么进入 AI Agent 时代后，提示词工程不够用了？

聊天机器人通常是“用户提问—模型回答”。Agent 则是一个循环：

1. 观察目标、环境和当前状态；
2. 判断下一步行动；
3. 选择并调用工具；
4. 读取工具结果；
5. 更新任务状态；
6. 判断继续、重试、求助还是结束。

每循环一次，模型需要的信息都可能变化。一个在第一步正确的上下文，到第五步可能已经过时；一个对普通员工可见的知识片段，对外部访客可能越权；一份几万字的工具说明，在当前步骤也许只需要其中一个函数。

Agent 的上下文可以怎样形式化？

在第 t 个执行步骤，可以把模型实际看到的上下文写成：

Context_t =
  Policy
  + Goal
  + SelectedHistory_t
  + TaskState_t
  + RetrievedEvidence_t
  + AvailableTools_t
  + RelevantMemory_t
  + ExecutionFeedback_t
  + OutputContract_t

这里的加号不是简单拼接，而是经过过滤、排序、去重、权限裁剪、压缩和格式化后的装配过程。最终目标不是让每一项都尽可能多，而是在质量、时效、成本和安全边界内，给当前决策提供充分信息。

图 2：上下文工程贯穿 Agent 的每个执行步骤；工具结果和业务反馈会写回状态，但下一轮只选择仍然相关的内容。

运行时上下文和模型上下文为什么要分开？

OpenAI Agents SDK 明确区分两类上下文：一类是应用程序本地上下文，例如用户 ID、数据库连接、依赖对象和权限服务；另一类是真正发送给大模型的上下文。前者通过 RunContextWrapper 供工具和业务代码使用，并不会自动暴露给模型；后者才通过动态指令、输入、工具定义或检索结果进入模型窗口。OpenAI Agents SDK：Context management

这一区分同时解决三个问题：

• 安全：API 密钥、连接对象和内部标识不应直接出现在提示词里；
• 成本：业务运行所需的数据不一定都需要转换为 token；
• 控制：工具可以使用完整权限上下文，而模型只看到完成当前决策所需的最小视图。

企业系统如果把“后端能够访问的数据”等同于“模型应该看到的数据”，很容易产生越权、泄露和提示注入风险。

三、上下文工程如何运行？

一个可落地的上下文引擎通常包含六个连续阶段。

1. 收集：建立候选上下文池

候选信息可能来自系统规则、用户输入、消息历史、工作流状态、RAG、数据库、工具注册中心、记忆库、文件工件和前一步执行结果。此阶段只负责获取候选项，不直接把所有内容送入模型。

每个候选项最好带有结构化元数据，例如：

{
  "content": "客户合同约定交付日期为 2026-08-15",
  "source": "contract/2026/ACME-017.pdf#page=8",
  "tenant_id": "org_1024",
  "acl": ["legal", "project_owner"],
  "valid_from": "2026-07-01",
  "expires_at": null,
  "confidence": 0.98,
  "type": "evidence"
}

没有来源、权限、时间和类型的文本，很难在后续阶段可靠筛选。

2. 选择：只保留当前步骤需要的信息

选择器根据当前目标、计划步骤、用户身份和 token 预算，从候选池中挑选高价值内容。常见策略包括：

• 规则过滤：租户、部门、密级、有效期和数据类型；
• 语义检索：向量相似度召回相关内容；
• 关键词检索：对编号、名称、法规条款等精确实体进行召回；
• 图检索：沿实体关系和时间关系寻找证据；
• Rerank：使用重排模型或 LLM 对候选结果重新评分；
• 新鲜度与可信度加权：优先使用当前有效、来源可靠的信息。

对于高风险业务，相关性不能凌驾于权限。正确顺序通常是“先做访问控制，再在授权范围内检索和排序”。

3. 装配：把异构信息变成模型可理解的结构

装配器将选出的内容放入明确区域，例如：

[SYSTEM_POLICY]
不可执行未经审批的付款操作。

[TASK_GOAL]
核验本次采购付款是否满足合同与验收条件。

[CURRENT_STATE]
合同已签署；验收单缺少项目负责人签字。

[EVIDENCE]
E1: 合同第 8 页……
E2: 验收记录……

[AVAILABLE_TOOLS]
query_contract, query_acceptance, request_approval

[OUTPUT_SCHEMA]
decision, reasons[], evidence_ids[], next_action

结构化标签的价值不是“形式好看”，而是降低不同信息互相污染的概率，并让输出可以被程序验证。

4. 推理与执行：让工具面随步骤变化

不应把所有工具永久暴露给模型。工具过多会增加选择混淆、描述 token 和错误调用风险。OpenAI Agents SDK 提供 Tool Search，可延迟加载较大的工具集合，只在某一轮展示需要的子集；Anthropic 也强调工具应边界清晰、返回结果节省 token，避免功能重叠。OpenAI Agents SDK：Tools；Anthropic：上下文工程中的工具设计

例如，“查询订单”步骤只显示只读查询工具；进入“退款”步骤后，才根据用户角色和金额展示退款申请工具；真正执行退款前，再进入人工审批。

5. 写回：把结果存为状态、记忆或工件

工具返回的原始数据不应全部进入长期记忆。写回前要判断：

• 这是当前线程的临时状态，还是跨会话长期有效的事实？
• 是用户明确表达的偏好，还是模型推断？
• 是否存在来源证据和有效期？
• 新信息是新增、纠正，还是与旧事实冲突？
• 是否允许该 Agent 写入这一命名空间？

LangGraph 将短期记忆作为线程状态并用 checkpoint 持久化，将跨会话长期记忆存入独立 Store；其文档还区分语义记忆、情景记忆和程序性记忆。LangGraph：Memory overview

6. 压缩与淘汰：让长任务保持可运行

当上下文接近预算或信号密度下降时，系统应执行：

• 删除已经消费且无需追溯的冗长工具回包；
• 将已完成步骤压缩为结构化摘要；
• 把大文件、代码和中间产物移到外部工件存储，仅保留引用；
• 固化关键决策、未完成事项、错误原因和证据 ID；
• 保留最近消息，按需检索更早历史；
• 对压缩前后进行事实一致性检查。

OpenAI Agents SDK 的 Sessions 支持持久会话记忆，并提供 OpenAIResponsesCompactionSession；模型设置中还可以配置服务端上下文压缩。客户端会话压缩和服务端压缩是不同层次，企业需要明确由谁负责、摘要存在哪里以及如何审计。OpenAI Agents SDK：Sessions；OpenAI Agents SDK：Models

四、上下文工程有哪些核心技术？

上下文工程不是单一算法，而是一组围绕信息生命周期的技术组合。

图 3：上下文工程的目标不是堆积 token，而是用七类技术持续提高有效信息密度，并控制成本与风险。

技术一：上下文选择（Context Selection）

选择比生成更靠前。系统先决定“哪些信息值得被模型处理”，再讨论提示词怎么写。评价选择器不能只看召回率，还要看是否引入冲突、过期内容和权限外数据。

技术二：即时检索（Just-in-Time Retrieval）

即时检索不是在任务开始时预加载全部知识，而是在执行到具体步骤时再查询。它适合大型代码库、企业知识库和复杂工具目录，可以降低早期信息过载。

但完全依赖 Agent 自主搜索也有风险：模型可能不知道自己缺少什么。因此生产系统常采用混合方案——启动时预加载任务规则和少量关键事实，细节信息按需检索。

技术三：渐进式披露（Progressive Disclosure）

渐进式披露先给模型目录和摘要，再在需要时加载正文和附属资料。Anthropic 的 Agent Skills 就采用这种设计：启动时只加载 Skill 的名称和描述，命中任务后再读取 SKILL.md，更深层参考文件继续按需展开。Anthropic：Equipping agents for the real world with Agent Skills

这一模式可推广到：

• 工具：先展示命名空间，再加载具体函数；
• 知识：先展示文档摘要，再读取相关章节；
• 文件：先展示目录树，再读取目标文件；
• 数据库：先展示表说明，再查询字段和数据。

技术四：上下文压缩（Compaction）

压缩的难点不在“缩短文字”，而在“保留未来决策仍需要的信息”。一个合格的任务摘要至少应保存：

• 原始目标与不可违反的约束；
• 已完成、进行中和待办步骤；
• 已确认事实、来源与时间；
• 已执行动作及副作用；
• 失败尝试和不可重复的路径；
• 用户批准或拒绝的事项；
• 外部工件的位置和版本。

如果只让模型写一段自由文本摘要，最容易丢失的恰恰是异常、否定条件和未完成事项。结构化摘要加验证器通常更可靠。

技术五：上下文隔离与卸载（Isolation and Offloading）

主 Agent 不需要看到每个子任务的全部过程。可以让子 Agent 在独立上下文中处理搜索、代码执行或文档解析，只把结论、证据和工件引用返回主线程。这既降低主上下文压力，也缩小错误和提示注入的传播范围。

大文件、网页快照、数据表和生成代码适合保存在文件系统、对象存储或数据库中。模型上下文里保留文件名、哈希、摘要和按需读取入口即可。

技术六：分层记忆（Layered Memory）

记忆至少应分为四层：

记忆层	保存内容	典型作用域	更新策略	不应保存
工作记忆	当前步骤的临时变量和最近结果	单次模型调用	每步重建	无关历史
线程状态	计划、进度、审批和关键消息	单个任务或会话	checkpoint	跨用户共享信息
长期记忆	已确认偏好、稳定事实和历史经验	用户、团队或 Agent	受控写入、可纠错	未验证推断
外部知识	文档、制度、业务数据和工件	企业或业务域	由源系统维护	脱离来源的摘要副本

“聊天记录越多，记忆越好”是常见误区。原始消息历史只是数据源，真正的记忆需要抽取、归类、验证、更新和遗忘机制。

技术七：上下文评测与可观测性

只评测最终答案，很难知道错误来自模型、检索还是状态。上下文工程至少应记录：

• 每一步选择了哪些上下文项，为什么选择；
• 哪些候选项因权限、过期或低相关性被过滤；
• 送入模型的 token 分布；
• 引用了哪些证据，答案是否得到证据支持；
• 工具是否选对、参数是否正确；
• 摘要是否遗漏关键事实；
• 长期记忆是否发生误写、覆盖或跨租户污染。

因此，上下文评测既包含结果指标，也包含轨迹指标。后者才能帮助团队定位“为什么答错”。

五、哪些问题最容易在上下文工程中被混淆？

长上下文能不能替代 RAG？

不能简单替代。长上下文适合一次性处理边界明确、总体量可控的资料；RAG 适合知识规模大、持续更新、需要权限过滤和来源追踪的系统。实际方案通常是 RAG 负责从大知识空间中选择证据，长上下文负责在一次推理中联合处理已选中的材料。

RAG 能不能替代 Agent 记忆？

不能。RAG 检索的是外部知识，Agent 记忆保存的是交互过程中形成的状态、偏好和经验。二者可以使用相似的向量检索技术，但数据所有者、更新规则、时间语义和隐私边界不同。

更好的模型能不能让上下文工程变得不重要？

更强模型可以提升理解、推理和工具调用能力，但不会自动解决数据权限、信息新鲜度、状态持久化、工具暴露范围和成本预算。模型能力越强、Agent 自主权越大，越需要清晰的上下文边界。

上下文工程和工作流编排有什么关系？

工作流决定“何时执行哪一步”，上下文工程决定“这一步给模型什么”。工作流节点、状态机和检查点为上下文选择提供确定性边界；上下文引擎则让每个节点获得所需的动态信息。二者共同构成可靠 Agent Runtime。

六、2026 年值得关注哪些上下文工程开源项目？

以下项目解决的层次不同，不能按“谁最强”简单排名。企业应先明确需要的是编排、会话状态、长期记忆、时间知识图谱，还是文档检索。

开源项目	主要定位	上下文工程能力	更适合的场景	选型提醒
LangChain / LangGraph	Agent 编排与有状态运行时	动态上下文、中间件、checkpoint、Store、长短期记忆	复杂工作流、长任务、人机协同	灵活度高，需要团队自行设计状态模型
OpenAI Agents SDK	轻量 Agent SDK	本地/模型上下文分离、Sessions、Compaction、Tool Search、Tracing	使用 OpenAI 模型、需要快速构建 Agent 的团队	关注模型提供方相关能力与迁移边界
Letta（原 MemGPT）	有状态 Agent 平台	Memory Blocks、持久状态、模型无关的 Agent 记忆	长期陪伴、持续学习、跨会话助手	需要先设计记忆写入和纠错规则
Mem0	独立的 Agent 记忆层	用户、会话和 Agent 多层记忆，检索与更新	为现有应用增加个性化长期记忆	记忆召回不等于事实正确，仍需评测
Graphiti	时序上下文图引擎	实体关系、事实有效期、来源 episode、混合检索	客户画像、动态组织关系、持续变化的企业事实	引入图数据库与抽取链路，工程复杂度较高
LlamaIndex	文档与数据 Agent 框架	解析、索引、检索、Workflows 与多种记忆集成	文档密集型 Agent、知识助手、Agentic RAG	数据质量和索引策略仍需独立治理

项目资料可分别参考：LangGraph 官方文档、OpenAI Agents SDK、Letta GitHub、Mem0 GitHub、Graphiti GitHub 和 LlamaIndex GitHub。

这些开源项目应该怎样组合？

一个常见的组合是：

• 用 LangGraph 或其他工作流引擎维护步骤、分支和 checkpoint；
• 用 RAG / LlamaIndex 连接文档和业务知识；
• 用 Mem0、Letta 或自建 Store 管理跨会话记忆；
• 对时间关系复杂的事实使用 Graphiti；
• 使用模型 SDK 的 Tool Search、Sessions 或 Compaction 降低上下文负担；
• 在统一 Trace 中记录上下文选择、模型调用、工具执行和写回过程。

并不是组件越多越好。若一个客服 Agent 只需读取订单、查询政策并生成答复，关系型数据库加权限过滤、结构化任务状态和精简 RAG 可能已经足够。只有当跨会话个性化、时序关系或长期自主任务成为真实需求时，才值得增加专用记忆系统。

七、一个企业合同审查 Agent 怎样从提示词工程升级为上下文工程？

假设企业已经有一个合同审查助手，最初的实现是把审查要求、合同全文和输出模板一起放进提示词。Demo 可以工作，但上线后常见四类问题：

• 合同过长，模型忽略附件或关键例外条款；
• 不同部门规则混在一起，结论互相冲突；
• 模型不知道当前用户是否有权查看价格和供应商信息；
• 第二次审查时无法复用已确认问题，也无法识别合同版本变化。

升级后的系统可以这样设计：

1. 任务入口：记录合同 ID、版本、审查目标、用户部门和权限；
2. 规则选择：按合同类型、法域和金额加载适用的审查清单；
3. 文档解析：保留条款编号、页码、附件关系和原文定位；
4. 分步检索：每审查一个风险主题，只检索对应条款与企业制度；
5. 结构化状态：保存已审项目、待核实项、证据 ID 和人工意见；
6. 工具裁剪：普通审查员只有查询权，法务负责人才能提交定稿；
7. 版本记忆：记录上一版问题及处理结果，但不把整段旧合同复制到当前窗口；
8. 评测与审计：检查风险召回、错误引用、越权读取、成本和人工修改率。

这时，System Prompt 仍然负责定义角色、审查原则和输出格式，但系统可靠性主要来自动态规则、证据、状态、权限和验证链路。

八、企业怎样建设上下文工程架构？

企业级架构应把上下文作为可治理的数据产品，而不是散落在代码里的字符串拼接。

图 4：企业上下文工程应在模型调用之前完成权限过滤、检索、选择和装配，并在执行之后进行验证、写回与持续评测。

第一层：数据与能力源

包括知识库、业务数据库、API、文件、消息、搜索、用户目录和工具注册中心。每种来源都应提供身份、权限、时间、版本和来源信息。

第二层：上下文引擎

负责候选获取、权限过滤、混合检索、重排、去重、token 预算、渐进式加载、结构化装配和压缩。这一层是从 RAG 应用走向 Agent 系统的关键新增能力。

第三层：Agent Runtime

负责任务规划、工作流状态、模型路由、工具执行、重试、checkpoint、人工审批和终止条件。运行时在每一步向上下文引擎提出“当前需要什么”的请求。

第四层：记忆与工件

分别保存线程状态、长期记忆以及大文件、中间结果和最终交付物。三者不要混为一个向量库，更不要让模型在没有权限和验证的情况下自由写入。

第五层：安全、评测与可观测性

覆盖身份、最小权限、敏感信息处理、提示注入防护、来源引用、轨迹追踪、离线评测、线上监控和回滚。每次上下文装配最好能够重放，以便复现问题。

在这套架构中，云程智能体开发平台适合承接模型接入、知识检索、工具与 MCP、工作流、状态记忆、链路日志和评测治理等工程能力，让团队把“上下文怎样生成、为何命中、是否越权、执行后写回什么”放在同一条可追踪链路中，而不是继续把关键逻辑散落在提示词和业务代码里。

九、企业实施上下文工程的七步路线

第一步：先定义任务成功，不要先选向量库

明确最终结果、允许的行动、失败条件、人工接管点和评测样本。没有成功标准，就无法判断上下文是否有效。

第二步：画出上下文清单和数据边界

列出每个步骤需要的规则、状态、证据、工具、记忆和输出契约，同时标注数据所有者、权限和有效期。

第三步：把状态从对话历史中抽出来

计划、进度、审批、错误和交付物应存为结构化状态。聊天记录可以保留，但不应成为唯一状态数据库。

第四步：建立最小上下文基线

先用少量高置信信息完成任务，再逐项增加 RAG、历史和工具。这样才能测量每一种上下文源带来的质量收益和成本。

第五步：对长任务加入压缩、外置和恢复

为摘要定义 Schema；把大工件外置；设置 checkpoint；验证压缩后是否仍能恢复目标、约束、进度和关键证据。

第六步：建立上下文级评测

除了最终正确率，还要评估：

• Context Precision：送入模型的信息中有多少真正相关；
• Context Recall：完成任务所需证据是否被召回；
• Citation Correctness：结论是否由引用内容支持；
• State Consistency：多轮状态是否自洽；
• Memory Accuracy：写入的长期记忆是否真实、可纠正；
• Tool Availability Accuracy：当前展示的工具是否恰当；
• Security：是否发生越权检索、敏感数据暴露或注入传播；
• Efficiency：每个成功任务的 token、延迟和工具调用成本。

第七步：用线上失败样本持续更新

把真实失败按“选择错误、检索错误、装配错误、推理错误、工具错误、写回错误、权限错误”分类。上下文工程不是一次性改提示词，而是持续优化信息供应链。

十、哪些场景最适合优先做上下文工程？

优先级最高的通常是：

• 长任务：研究、编码、数据分析、项目执行和跨系统流程；
• 知识密集：合同、政策、医疗、制造、售后和企业搜索；
• 多工具：需要从大量 API、MCP Server 或 Skill 中动态选择能力；
• 强状态：审批、报销、采购、工单和需要断点恢复的任务；
• 个性化：跨会话保留用户偏好和历史关系；
• 高风险：需要证据、权限、审计和人工门禁的决策。

不适合过度工程化的场景包括一次性文案改写、简单分类、固定字段抽取和确定性流程。对于这些任务，一个清晰提示词加结构化输出往往已经足够。

十一、关于上下文工程的常见问题

FAQ 1：上下文工程会取代提示词工程吗？

不会。提示词工程是上下文工程的指令设计部分。上下文工程扩大了问题边界，但高质量 System Prompt、示例和输出 Schema 仍然是可靠 Agent 的基础。

FAQ 2：上下文窗口越大，Agent 就越可靠吗？

不一定。更大窗口提高容量，却不保证模型能均匀利用所有信息。无关内容、冲突证据和过期历史会降低有效信号密度，因此仍需选择、压缩和评测。

FAQ 3：上下文工程和 RAG 的最大区别是什么？

RAG 主要解决外部知识检索，上下文工程负责模型一次推理所需的全部信息，包括 RAG 结果、指令、状态、工具、记忆、权限和执行反馈。RAG 是组件，上下文工程是系统方法。

FAQ 4：做上下文工程必须使用向量数据库吗？

不必须。结构化数据库查询、关键词搜索、图检索、文件读取和规则选择都可以提供上下文。检索方式应由数据结构、精确性、更新频率和权限要求决定。

FAQ 5：Agent 的完整聊天记录应该一直保留吗？

可以在存储层保留，但不应每次完整发送给模型。生产系统通常保留最近消息，把关键事实抽取为状态或记忆，并按需检索旧记录。

FAQ 6：上下文压缩会不会导致重要信息丢失？

会，因此压缩必须可评测、可追溯。应使用结构化摘要，保留目标、约束、状态、证据 ID 和失败记录，并让原始工件仍可按引用恢复。

FAQ 7：企业应该先做提示词平台，还是上下文平台？

如果业务只是单轮生成，提示词管理已足够；如果涉及多轮、工具、RAG、记忆和审批，应直接按上下文平台设计，同时保留提示词的版本管理与评测能力。

十二、标准答案：如果只记住五句话

1. 提示词工程优化指令，上下文工程优化 Agent 每一步看到的完整信息环境。
2. 上下文工程包含提示词、RAG、状态、工具、记忆、反馈、权限和输出契约，但不等于其中任何一个组件。
3. 长上下文的正确用法不是尽量填满，而是保持最小、相关、及时、可信和可授权。
4. 可靠 Agent 需要“收集—选择—装配—执行—写回—压缩—评测”的持续闭环。
5. 企业的竞争力将不只来自使用哪个模型，更来自能否把业务数据、规则、能力和记忆组织成高质量上下文。