这篇主要解决一个实际问题Context Engineering 不只是 Prompt Engineering。本文结合 Microsoft、Anthropic、Google 官方资料与 XBSTACK 本地实测解释…直接答案Context Engineering 不是把 Prompt Engineering 换一个更时髦的名字。Prompt Engineering 解决“指令怎么写”Context Engineering 解决“模型这一轮到底应该看到什么”。对一个 AI Agent 来说真正进入上下文的通常同时有 system instructions、工具定义、MCP 描述、检索文档、Memory、消息历史、任务状态和工具返回这些内容每轮都可能变化也都会消耗 Token 和模型的注意力。这个方向现在值得单独写是因为几家大厂已经从不同角度收敛到同一个问题。Anthropic 把 context 看成有限的 attention budgetGoogle 把 context engineering 描述为围绕 Agent 建立结构化数据和环境管线Microsoft 2026 年 9 月 2 日则直接把 Knowledge Retrieval、Tool Search、Skills 和 Memory 放进生产 Agent 的成本优化体系。本文仍不是“模型成本实测”。Microsoft 的百分比继续按厂商内部/产品评估引用XBSTACK 新增的是本地 context-assembly audit只验证真实项目上下文从全量包收敛到聚焦包后的 token 规模与预设证据保留。它已经能回答“是否存在大量可避免的上下文装配开销”但还不能回答“模型成功率是否提高”或“最终账单到底下降多少”。Context Engineering 和 Prompt Engineering 到底差在哪Anthropic 给出的区分非常实用Prompt Engineering 主要研究如何编写、组织模型指令Context Engineering 则是在每一次模型推理前策划和维护最合适的一组 Token包括 Prompt 之外所有可能进入模型视野的信息。一个 Agent 的真实上下文可能是System instructions User task Few-shot examples Tool schemas MCP server/tool descriptions Retrieved documents User/session memory Project notes Prior messages Previous tool results Current checkpoint/state如果只优化第一行和第二行后面的 80% 信息仍然可能又长、又旧、又互相冲突。Anthropic 因此把 Context Engineering 称为 Prompt Engineering 的自然延伸。随着 Agent 进入多轮工具循环和长时间任务“把一句 Prompt 写漂亮”不再足以控制模型。官方原文https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents为什么 Context Window 越大Context Engineering 反而越重要直觉上模型从 128K 走到 1M、2M 上下文后好像可以直接把所有资料塞进去。但这会混淆“容量”和“有效注意力”。Anthropic 提到 context rot随着上下文变长模型对其中信息的精确提取和长距离关系理解可能下降。它把 context 描述为有限 attention budget建议寻找“能最大化目标行为概率的最小高信号 Token 集”。Google Cloud 的官方解释也强调 Context Engineering 是一个数据/环境系统而不是把大 Context Window 当作仓库。即使模型可以读取很长输入生产系统仍然要决定稳定 instructions、半持久 Memory 和动态外部数据如何组合。这一点和今天的 GPT-6 Astra 105 万上下文 很契合窗口更大确实扩大了任务空间但它不会自动判断哪些日志、工具和历史已经失效也不会自动替你控制每轮重复输入的成本。为什么 Agent 的成本不能只看模型单价Agent 是模型调用循环不是一次 completion。它计划、调用 Tool、读取结果、再推理完成一个结果可能包含很多请求。因此真正的成本近似可以写成Outcome cost Σ(每轮 input cached input/write output tool fee) retry cost failed-run cost human correction cost上下文膨胀的问题是历史越长、工具越多、检索结果越杂每一轮都可能重复支付这些输入。Microsoft 在 9 月 2 日的官方文章里直接提出很多生产 Agent 在原型阶段就固定了“模型每轮看什么”以后很少重新优化而这往往既影响成本也影响回答质量。因此 Context Engineering 的目标不是“尽量少 Token”而是保留完成任务需要的高价值 Token删除当前轮不需要的低价值 Token。Microsoft 官方https://azure.microsoft.com/en-us/blog/the-economics-of-agent-optimization-context-engineering-for-enterprise-ai-agents/第一层Instructions 应该足够明确但不要写成程序Anthropic 对 system prompt 的建议很克制不要把所有业务逻辑硬编码成几百条 if/else也不要只写“你是一个有帮助的 Agent”这种空指令。更好的状态是“正确高度”明确角色与目标明确边界和不可做事项明确工具使用原则给少量代表性例子结果格式需要时明确把动态事实留给 Retrieval/Tools而不是复制进长期 Prompt。指令越稳定越适合放长期层事实越动态越应该运行时获取。第二层Retrieval 不是“搜到越多文档越好”RAG 解决的是从大量外部知识里拿到当前任务需要的证据。Context Engineering 关心的是下一步拿哪些、多少、以什么顺序、带什么 metadata 放进 context。一个生产检索链通常至少要考虑Query rewrite / decomposition ↓ Candidate retrieval ↓ Filter / ACL ↓ Semantic / hybrid rerank ↓ Deduplicate ↓ Token budget ↓ Context packing citationsMicrosoft 在其 Foundry 文章里公布了 BrowseComp-Plus 上的内部结果通过更好的 evidence retrieval/reranking报告最高54% evidence recall 提升和 34% retrieval token cost 降低。这组数字只能写成 Microsoft 的官方内部评估不能改写成“Context Engineering 能给你省 34%”。真实知识库、文档质量和查询分布都会改变结果。站内 AI Agent RAG 集成 可以作为 Retrieval 实现的下一步阅读。第三层Tool Search 为什么可能比“把所有工具都告诉模型”更合理当 Agent 只有 5 个 Tool 时全量 tool schema 很简单当它连接 MCP、SaaS、数据库、浏览器和内部 API 后可能有几十甚至几百个 Tool。如果每轮都把全部定义放进 context会同时产生两种成本Token 成本工具描述本身可以非常长决策噪声功能相近的 Tool 越多模型越难选。一种 Context Engineering 方案是 Tool Search模型先看到一个小型工具索引/发现能力需要时再加载相关工具详细 schema。Microsoft 报告其大工具库内部 benchmark 中平均input-token reduction 约 97%。仍然要强调这是微软特定工作负载和产品能力的内部结果而不是一般规律。MCP 同样需要这个思路。MCP 让 Tool/Data 接入更标准但“接上 100 个 MCP Tools”不等于“每轮应该把 100 个工具都暴露给模型”。协议层与 context selection 是两个不同问题。可参考 MCP 协议指南。第四层Memory 不应该等于“把聊天历史全部带回来”长期 Agent 需要 Memory但 Memory 的价值是把跨会话仍然有用的信息带入当前轮而不是无限累加消息。Microsoft 在文章里把 Memory 分成 session、user、procedural 等类型Anthropic 更强调 structured note-taking 与动态检索。无论具体实现如何一个好 Memory 层都需要回答这条信息为什么值得长期保存来源是什么什么时候写入是否过期当前任务真的需要吗和新的事实冲突怎么办Microsoft 文中还给出 Memory 相关内部评估约5% benchmark improvement同样不能直接推广到任意 Agent。如果你在做具体记忆系统可以继续看 AI Agent Memory System如果关心 Coding Agent 原始 trace 检索Funes Agent Memory 是另一个值得继续验证的方向但本站相关实测仍处于草稿阶段暂不提供公开链接。第五层Skills 把稳定“方法”从每次 Prompt 里抽出来Skills 和 Memory 容易混淆。Memory 主要回答“过去发生了什么、用户/项目有什么长期状态”Skill 更接近“遇到某类任务应该如何做”。例如一套 PDF 财报校验流程、一套部署验收步骤、一套代码 review 方法都属于可复用 procedure。把稳定 procedure 做成 Skill 的好处是不需要每次在 user prompt 里重复粘贴完整 SOPAgent 可以在任务需要时加载。但 Skills 同样需要版本和适用范围否则旧流程会像旧 Memory 一样污染新任务。第六层长任务里的 History 怎么处理无限保留全部 message history 最简单也最容易膨胀。Anthropic 对长时间 Agent 给出的几个常见策略是Compaction把旧消息压成高价值摘要在活动 context 里保留当前计划、关键状态、失败信息和后续步骤。Structured note-taking让 Agent 主动把长期重要状态写到 context 之外例如文件、Memory 或 durable notes需要时再取回。Just-in-time retrieval上下文只保留轻量引用例如路径、URL、query ID真正需要时再通过工具加载数据而不是一开始预加载所有东西。Sub-agent把子问题隔离到独立 context主 Agent 最后只接收压缩后的必要结果避免所有调查过程污染主上下文。这四种手段解决的都是同一件事不要让每一轮模型请求都背着过去所有工作。Context Engineering 和 RAG、MCP、Memory 到底是什么关系可以把它们看成层级关系Context Engineering ├── Instructions / Examples ├── Retrieval / RAG ├── Tool selection / Tool Search │ └── MCP can be one tool/data connection layer ├── Skills / procedures ├── Memory ├── History / Compaction / Notes ├── Runtime state └── Context caching / packing / budgetRAG、MCP、Memory 都不是 Context Engineering 的同义词。它们是供 Context Engineering 调用的数据与能力组件。因此一个系统“用了 RAG”仍然可能 context 很差检索出 30 个重复 chunk 全部塞进去“用了 MCP”也可能很差每轮暴露 80 个重叠工具“用了 Memory”也可能很差把过期信息一直注入新任务。XBSTACK 本地 Context Audit先测“进入上下文的东西”再谈模型成本2026 年 9 月 5 日我先做了一轮不调用外部模型的本地 Context Assembly Audit。目的不是证明 Context Engineering 一定能让模型更准而是先回答一个更基础的问题同一个真实工程任务如果把整包项目上下文全部塞进去和只检索当前任务所需的规则、脚本与证据相比进入模型窗口的内容规模到底差多少这次使用的都是真实 XBSTACK 项目资料AGENTS.md、搜索问题运营规则、package.json发布/增长脚本、当天daily-operation-evidence以及刚完成的 LangGraph 首个 checkpoint 崩溃实验结果。Token 只用tiktoken o200k_base做本地统一估算不代表任何厂商实际账单。任务全量上下文聚焦上下文减少比例预设关键证据每日运营门禁20,3971,64791.93%3/3文章发布门禁20,3971,54192.44%3/3LangGraph 首个 checkpoint 恢复20,3971,16594.29%3/3这里的“关键证据 3/3”是一个很克制的检查例如每日运营任务必须仍然保留growth:daily-operation-gate、DAILY_OPERATION_PASS和候选数量门槛LangGraph 恢复任务必须仍然拿到EmptyInputError、accepted与最终completed的证据。它只能证明这组确定性检索没有把我事先定义的关键证据丢掉不能证明模型准确率提高 90%更不能把 91.93%–94.29% 直接写成真实账单节省。实验文件在experiments/context-engineering-context-audit/同一套规则可以重复运行。下一步真正需要继续测的是模型层聚焦上下文后任务成功率、重试次数、Tool Call 数、延迟和最终任务成本是否仍然不差于全量上下文。所以给现有 Agent 做 Context Audit 时我仍然建议记录下面这些指标而不是只看输入 Token指标为什么看System / instruction tokens长期 Prompt 是否膨胀Tool-schema tokens是否每轮带全量 ToolsRetrieved tokensRAG 是否过量Memory tokens长期状态是否真正相关History tokens多轮重复成本Cached tokens重复内容是否利用缓存Output tokens推理/回答规模Tool calls上下文变短是否导致更多探索Retry / failure不能为了省 Token 降低成功率Total outcome cost最终业务指标最终比较仍然应该是两套方案A全量上下文—— 现有 Prompt、所有历史、所有 Tool schemas、固定 top-k retrieval。BContext Engineering—— 动态 Tool Search/过滤、just-in-time retrieval、Memory 筛选、compaction/notes、明确 token budget。成功标准不是 B 的 input token 更少而是在任务质量不下降的前提下完成结果的总成本、重试和时间更低。一个可落地的 Context Engineering 检查表在模型调用之前逐项问这条 instruction 是否稳定且仍然需要当前任务真正需要哪些 ToolsTool 描述有没有重叠哪些事实必须实时 Retrieval而不是写死在 Prompt检索结果是否去重、rerank、受 ACL 约束哪些 Memory 真的和当前任务相关Memory 是否有来源、版本和时效旧 history 能否 compaction哪些大数据可以只保留引用需要时再读取子任务是否值得用 Sub-agent 隔离 context可重复上下文是否能 cache失败时应该增加信息还是换工具/策略这个清单比“把 context 控制在某个固定 Token 数”更实用因为不同任务需要的信息密度完全不同。安全减少 Context 也不能破坏权限Context Engineering 不只是成本工程。检索、Tool Search、Memory 都涉及数据可见性。一个常见错误是为了方便 Agent 检索把用户本来无权看到的文档放进统一向量库另一个错误是 Tool Search 只按语义找工具却忘了当前用户/Agent 是否有权限调用它。因此 context pipeline 应该遵守retrieval ACL 在召回前/后都可验证Tool discovery 先做 permission filterMemory 按用户、项目、租户隔离凭据不直接进入模型上下文audit 能追踪每条外部信息为何被注入high-impact write 仍走 approval。Context 越动态数据边界越应该显式。最终判断为什么这会成为 Agent 工程的基础能力Prompt Engineering 不会消失。好的 Instructions 仍然重要。但生产 Agent 一旦进入多轮、Tools、Memory、RAG、Computer Use 和长期任务影响每轮结果的变量已经远超一段 Prompt。Context Engineering 真正提供的是一个工程视角把模型视为有有限注意力与按 Token 计费的执行核心每一轮都应该给它足够但不过量、当前且有权限、高信号且可追溯的信息。Microsoft 的最新成本文章、Anthropic 的 Agent 工程方法和 Google 的 Context Engineering 页面都指向这条主线但具体产品和 benchmark 各自不同。不能因为三个厂商都谈 Context Engineering 就把它包装成一个统一标准。对 XBSTACK 来说这篇未来发布最需要证明的不是“Context Engineering 很重要”而是同一个真实 Agent在不降低成功率的前提下通过更少重复历史、更少无关 Tool schema、更精准 Retrieval 和更合适 Memory能不能用更少总输入完成同一个结果。FAQContext Engineering 是什么Context Engineering 是设计和动态筛选每一轮模型可见信息的工程实践范围包括 Instructions、Tools/MCP、Retrieval、Memory、History、Runtime state 与缓存不只是 Prompt 文本。Context Engineering 会取代 Prompt Engineering 吗不会。Prompt Engineering 是 Context Engineering 的一部分。明确 system instructions、示例和输出要求仍然重要只是生产 Agent 还必须管理动态工具、数据、Memory 和历史。Context Engineering 和 RAG 有什么区别RAG 主要负责从外部知识检索证据Context Engineering 还决定检索多少、怎样 rerank/去重、与哪些 Instructions、Tools、Memory、History 一起放进模型以及总 token budget。Context Engineering 和 MCP 有什么关系MCP 是连接 Tools/Data 的协议层Context Engineering 决定当前轮应该发现、加载和暴露哪些 MCP 能力。接入很多 MCP Server 不代表所有 Tool schemas 都应该每轮进入上下文。Context Engineering 一定能省 Token 吗通常有机会减少重复和无关输入但不能预设固定节省比例。真实结果需要在同任务、同成功标准下比较总 input/output、工具调用、重试、耗时和成功率。Microsoft 的 34%、97% 等数字是其特定内部评估不是通用保证。官方资料Microsoft AzureThe Economics of Agent Optimization — Context engineeringAnthropicEffective context engineering for AI agentsGoogle CloudWhat is AI context engineering?继续阅读AI Agent RAG检索怎么接入生产工作流AI Agent Memory SystemMCP Protocol GuideAI Agent 生产化治理原文链接https://www.xbstack.com/ai/context-engineering-agent-cost-memory-tools/?utm_sourcecsdnutm_mediumreferralutm_campaigncontext_engineering_agent_cost_memory_toolsutm_contentcontext-engineering-agent-cost-memory-toolsrefcsdn标签#AI #实战 #问题排查 #Context Engineering #Prompt Engineering #AI AgentRelated XBSTACK readingAI Agent Memory System: https://www.xbstack.com/ai/agent-memory-system/?utm_sourcecsdnutm_mediumreferralutm_campaigncontext_engineering_agent_cost_memory_toolsutm_contentrelated_1AI Agent RAG Integration: https://www.xbstack.com/ai/ai-agent-rag-integration/?utm_sourcecsdnutm_mediumreferralutm_campaigncontext_engineering_agent_cost_memory_toolsutm_contentrelated_2AI Agent Tool Use: https://www.xbstack.com/ai/ai-agent-tool-use/?utm_sourcecsdnutm_mediumreferralutm_campaigncontext_engineering_agent_cost_memory_toolsutm_contentrelated_3
这篇主要解决一个实际问题Context Engineering 不只是 Prompt Engineering。本文结合 Microsoft、Anthropic、Google 官方资料与 XBSTACK 本地实测解释…直接答案Context Engineering 不是把 Prompt Engineering 换一个更时髦的名字。Prompt Engineering 解决“指令怎么写”Context Engineering 解决“模型这一轮到底应该看到什么”。对一个 AI Agent 来说真正进入上下文的通常同时有 system instructions、工具定义、MCP 描述、检索文档、Memory、消息历史、任务状态和工具返回这些内容每轮都可能变化也都会消耗 Token 和模型的注意力。这个方向现在值得单独写是因为几家大厂已经从不同角度收敛到同一个问题。Anthropic 把 context 看成有限的 attention budgetGoogle 把 context engineering 描述为围绕 Agent 建立结构化数据和环境管线Microsoft 2026 年 9 月 2 日则直接把 Knowledge Retrieval、Tool Search、Skills 和 Memory 放进生产 Agent 的成本优化体系。本文仍不是“模型成本实测”。Microsoft 的百分比继续按厂商内部/产品评估引用XBSTACK 新增的是本地 context-assembly audit只验证真实项目上下文从全量包收敛到聚焦包后的 token 规模与预设证据保留。它已经能回答“是否存在大量可避免的上下文装配开销”但还不能回答“模型成功率是否提高”或“最终账单到底下降多少”。Context Engineering 和 Prompt Engineering 到底差在哪Anthropic 给出的区分非常实用Prompt Engineering 主要研究如何编写、组织模型指令Context Engineering 则是在每一次模型推理前策划和维护最合适的一组 Token包括 Prompt 之外所有可能进入模型视野的信息。一个 Agent 的真实上下文可能是System instructions User task Few-shot examples Tool schemas MCP server/tool descriptions Retrieved documents User/session memory Project notes Prior messages Previous tool results Current checkpoint/state如果只优化第一行和第二行后面的 80% 信息仍然可能又长、又旧、又互相冲突。Anthropic 因此把 Context Engineering 称为 Prompt Engineering 的自然延伸。随着 Agent 进入多轮工具循环和长时间任务“把一句 Prompt 写漂亮”不再足以控制模型。官方原文https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents为什么 Context Window 越大Context Engineering 反而越重要直觉上模型从 128K 走到 1M、2M 上下文后好像可以直接把所有资料塞进去。但这会混淆“容量”和“有效注意力”。Anthropic 提到 context rot随着上下文变长模型对其中信息的精确提取和长距离关系理解可能下降。它把 context 描述为有限 attention budget建议寻找“能最大化目标行为概率的最小高信号 Token 集”。Google Cloud 的官方解释也强调 Context Engineering 是一个数据/环境系统而不是把大 Context Window 当作仓库。即使模型可以读取很长输入生产系统仍然要决定稳定 instructions、半持久 Memory 和动态外部数据如何组合。这一点和今天的 GPT-6 Astra 105 万上下文 很契合窗口更大确实扩大了任务空间但它不会自动判断哪些日志、工具和历史已经失效也不会自动替你控制每轮重复输入的成本。为什么 Agent 的成本不能只看模型单价Agent 是模型调用循环不是一次 completion。它计划、调用 Tool、读取结果、再推理完成一个结果可能包含很多请求。因此真正的成本近似可以写成Outcome cost Σ(每轮 input cached input/write output tool fee) retry cost failed-run cost human correction cost上下文膨胀的问题是历史越长、工具越多、检索结果越杂每一轮都可能重复支付这些输入。Microsoft 在 9 月 2 日的官方文章里直接提出很多生产 Agent 在原型阶段就固定了“模型每轮看什么”以后很少重新优化而这往往既影响成本也影响回答质量。因此 Context Engineering 的目标不是“尽量少 Token”而是保留完成任务需要的高价值 Token删除当前轮不需要的低价值 Token。Microsoft 官方https://azure.microsoft.com/en-us/blog/the-economics-of-agent-optimization-context-engineering-for-enterprise-ai-agents/第一层Instructions 应该足够明确但不要写成程序Anthropic 对 system prompt 的建议很克制不要把所有业务逻辑硬编码成几百条 if/else也不要只写“你是一个有帮助的 Agent”这种空指令。更好的状态是“正确高度”明确角色与目标明确边界和不可做事项明确工具使用原则给少量代表性例子结果格式需要时明确把动态事实留给 Retrieval/Tools而不是复制进长期 Prompt。指令越稳定越适合放长期层事实越动态越应该运行时获取。第二层Retrieval 不是“搜到越多文档越好”RAG 解决的是从大量外部知识里拿到当前任务需要的证据。Context Engineering 关心的是下一步拿哪些、多少、以什么顺序、带什么 metadata 放进 context。一个生产检索链通常至少要考虑Query rewrite / decomposition ↓ Candidate retrieval ↓ Filter / ACL ↓ Semantic / hybrid rerank ↓ Deduplicate ↓ Token budget ↓ Context packing citationsMicrosoft 在其 Foundry 文章里公布了 BrowseComp-Plus 上的内部结果通过更好的 evidence retrieval/reranking报告最高54% evidence recall 提升和 34% retrieval token cost 降低。这组数字只能写成 Microsoft 的官方内部评估不能改写成“Context Engineering 能给你省 34%”。真实知识库、文档质量和查询分布都会改变结果。站内 AI Agent RAG 集成 可以作为 Retrieval 实现的下一步阅读。第三层Tool Search 为什么可能比“把所有工具都告诉模型”更合理当 Agent 只有 5 个 Tool 时全量 tool schema 很简单当它连接 MCP、SaaS、数据库、浏览器和内部 API 后可能有几十甚至几百个 Tool。如果每轮都把全部定义放进 context会同时产生两种成本Token 成本工具描述本身可以非常长决策噪声功能相近的 Tool 越多模型越难选。一种 Context Engineering 方案是 Tool Search模型先看到一个小型工具索引/发现能力需要时再加载相关工具详细 schema。Microsoft 报告其大工具库内部 benchmark 中平均input-token reduction 约 97%。仍然要强调这是微软特定工作负载和产品能力的内部结果而不是一般规律。MCP 同样需要这个思路。MCP 让 Tool/Data 接入更标准但“接上 100 个 MCP Tools”不等于“每轮应该把 100 个工具都暴露给模型”。协议层与 context selection 是两个不同问题。可参考 MCP 协议指南。第四层Memory 不应该等于“把聊天历史全部带回来”长期 Agent 需要 Memory但 Memory 的价值是把跨会话仍然有用的信息带入当前轮而不是无限累加消息。Microsoft 在文章里把 Memory 分成 session、user、procedural 等类型Anthropic 更强调 structured note-taking 与动态检索。无论具体实现如何一个好 Memory 层都需要回答这条信息为什么值得长期保存来源是什么什么时候写入是否过期当前任务真的需要吗和新的事实冲突怎么办Microsoft 文中还给出 Memory 相关内部评估约5% benchmark improvement同样不能直接推广到任意 Agent。如果你在做具体记忆系统可以继续看 AI Agent Memory System如果关心 Coding Agent 原始 trace 检索Funes Agent Memory 是另一个值得继续验证的方向但本站相关实测仍处于草稿阶段暂不提供公开链接。第五层Skills 把稳定“方法”从每次 Prompt 里抽出来Skills 和 Memory 容易混淆。Memory 主要回答“过去发生了什么、用户/项目有什么长期状态”Skill 更接近“遇到某类任务应该如何做”。例如一套 PDF 财报校验流程、一套部署验收步骤、一套代码 review 方法都属于可复用 procedure。把稳定 procedure 做成 Skill 的好处是不需要每次在 user prompt 里重复粘贴完整 SOPAgent 可以在任务需要时加载。但 Skills 同样需要版本和适用范围否则旧流程会像旧 Memory 一样污染新任务。第六层长任务里的 History 怎么处理无限保留全部 message history 最简单也最容易膨胀。Anthropic 对长时间 Agent 给出的几个常见策略是Compaction把旧消息压成高价值摘要在活动 context 里保留当前计划、关键状态、失败信息和后续步骤。Structured note-taking让 Agent 主动把长期重要状态写到 context 之外例如文件、Memory 或 durable notes需要时再取回。Just-in-time retrieval上下文只保留轻量引用例如路径、URL、query ID真正需要时再通过工具加载数据而不是一开始预加载所有东西。Sub-agent把子问题隔离到独立 context主 Agent 最后只接收压缩后的必要结果避免所有调查过程污染主上下文。这四种手段解决的都是同一件事不要让每一轮模型请求都背着过去所有工作。Context Engineering 和 RAG、MCP、Memory 到底是什么关系可以把它们看成层级关系Context Engineering ├── Instructions / Examples ├── Retrieval / RAG ├── Tool selection / Tool Search │ └── MCP can be one tool/data connection layer ├── Skills / procedures ├── Memory ├── History / Compaction / Notes ├── Runtime state └── Context caching / packing / budgetRAG、MCP、Memory 都不是 Context Engineering 的同义词。它们是供 Context Engineering 调用的数据与能力组件。因此一个系统“用了 RAG”仍然可能 context 很差检索出 30 个重复 chunk 全部塞进去“用了 MCP”也可能很差每轮暴露 80 个重叠工具“用了 Memory”也可能很差把过期信息一直注入新任务。XBSTACK 本地 Context Audit先测“进入上下文的东西”再谈模型成本2026 年 9 月 5 日我先做了一轮不调用外部模型的本地 Context Assembly Audit。目的不是证明 Context Engineering 一定能让模型更准而是先回答一个更基础的问题同一个真实工程任务如果把整包项目上下文全部塞进去和只检索当前任务所需的规则、脚本与证据相比进入模型窗口的内容规模到底差多少这次使用的都是真实 XBSTACK 项目资料AGENTS.md、搜索问题运营规则、package.json发布/增长脚本、当天daily-operation-evidence以及刚完成的 LangGraph 首个 checkpoint 崩溃实验结果。Token 只用tiktoken o200k_base做本地统一估算不代表任何厂商实际账单。任务全量上下文聚焦上下文减少比例预设关键证据每日运营门禁20,3971,64791.93%3/3文章发布门禁20,3971,54192.44%3/3LangGraph 首个 checkpoint 恢复20,3971,16594.29%3/3这里的“关键证据 3/3”是一个很克制的检查例如每日运营任务必须仍然保留growth:daily-operation-gate、DAILY_OPERATION_PASS和候选数量门槛LangGraph 恢复任务必须仍然拿到EmptyInputError、accepted与最终completed的证据。它只能证明这组确定性检索没有把我事先定义的关键证据丢掉不能证明模型准确率提高 90%更不能把 91.93%–94.29% 直接写成真实账单节省。实验文件在experiments/context-engineering-context-audit/同一套规则可以重复运行。下一步真正需要继续测的是模型层聚焦上下文后任务成功率、重试次数、Tool Call 数、延迟和最终任务成本是否仍然不差于全量上下文。所以给现有 Agent 做 Context Audit 时我仍然建议记录下面这些指标而不是只看输入 Token指标为什么看System / instruction tokens长期 Prompt 是否膨胀Tool-schema tokens是否每轮带全量 ToolsRetrieved tokensRAG 是否过量Memory tokens长期状态是否真正相关History tokens多轮重复成本Cached tokens重复内容是否利用缓存Output tokens推理/回答规模Tool calls上下文变短是否导致更多探索Retry / failure不能为了省 Token 降低成功率Total outcome cost最终业务指标最终比较仍然应该是两套方案A全量上下文—— 现有 Prompt、所有历史、所有 Tool schemas、固定 top-k retrieval。BContext Engineering—— 动态 Tool Search/过滤、just-in-time retrieval、Memory 筛选、compaction/notes、明确 token budget。成功标准不是 B 的 input token 更少而是在任务质量不下降的前提下完成结果的总成本、重试和时间更低。一个可落地的 Context Engineering 检查表在模型调用之前逐项问这条 instruction 是否稳定且仍然需要当前任务真正需要哪些 ToolsTool 描述有没有重叠哪些事实必须实时 Retrieval而不是写死在 Prompt检索结果是否去重、rerank、受 ACL 约束哪些 Memory 真的和当前任务相关Memory 是否有来源、版本和时效旧 history 能否 compaction哪些大数据可以只保留引用需要时再读取子任务是否值得用 Sub-agent 隔离 context可重复上下文是否能 cache失败时应该增加信息还是换工具/策略这个清单比“把 context 控制在某个固定 Token 数”更实用因为不同任务需要的信息密度完全不同。安全减少 Context 也不能破坏权限Context Engineering 不只是成本工程。检索、Tool Search、Memory 都涉及数据可见性。一个常见错误是为了方便 Agent 检索把用户本来无权看到的文档放进统一向量库另一个错误是 Tool Search 只按语义找工具却忘了当前用户/Agent 是否有权限调用它。因此 context pipeline 应该遵守retrieval ACL 在召回前/后都可验证Tool discovery 先做 permission filterMemory 按用户、项目、租户隔离凭据不直接进入模型上下文audit 能追踪每条外部信息为何被注入high-impact write 仍走 approval。Context 越动态数据边界越应该显式。最终判断为什么这会成为 Agent 工程的基础能力Prompt Engineering 不会消失。好的 Instructions 仍然重要。但生产 Agent 一旦进入多轮、Tools、Memory、RAG、Computer Use 和长期任务影响每轮结果的变量已经远超一段 Prompt。Context Engineering 真正提供的是一个工程视角把模型视为有有限注意力与按 Token 计费的执行核心每一轮都应该给它足够但不过量、当前且有权限、高信号且可追溯的信息。Microsoft 的最新成本文章、Anthropic 的 Agent 工程方法和 Google 的 Context Engineering 页面都指向这条主线但具体产品和 benchmark 各自不同。不能因为三个厂商都谈 Context Engineering 就把它包装成一个统一标准。对 XBSTACK 来说这篇未来发布最需要证明的不是“Context Engineering 很重要”而是同一个真实 Agent在不降低成功率的前提下通过更少重复历史、更少无关 Tool schema、更精准 Retrieval 和更合适 Memory能不能用更少总输入完成同一个结果。FAQContext Engineering 是什么Context Engineering 是设计和动态筛选每一轮模型可见信息的工程实践范围包括 Instructions、Tools/MCP、Retrieval、Memory、History、Runtime state 与缓存不只是 Prompt 文本。Context Engineering 会取代 Prompt Engineering 吗不会。Prompt Engineering 是 Context Engineering 的一部分。明确 system instructions、示例和输出要求仍然重要只是生产 Agent 还必须管理动态工具、数据、Memory 和历史。Context Engineering 和 RAG 有什么区别RAG 主要负责从外部知识检索证据Context Engineering 还决定检索多少、怎样 rerank/去重、与哪些 Instructions、Tools、Memory、History 一起放进模型以及总 token budget。Context Engineering 和 MCP 有什么关系MCP 是连接 Tools/Data 的协议层Context Engineering 决定当前轮应该发现、加载和暴露哪些 MCP 能力。接入很多 MCP Server 不代表所有 Tool schemas 都应该每轮进入上下文。Context Engineering 一定能省 Token 吗通常有机会减少重复和无关输入但不能预设固定节省比例。真实结果需要在同任务、同成功标准下比较总 input/output、工具调用、重试、耗时和成功率。Microsoft 的 34%、97% 等数字是其特定内部评估不是通用保证。官方资料Microsoft AzureThe Economics of Agent Optimization — Context engineeringAnthropicEffective context engineering for AI agentsGoogle CloudWhat is AI context engineering?继续阅读AI Agent RAG检索怎么接入生产工作流AI Agent Memory SystemMCP Protocol GuideAI Agent 生产化治理原文链接https://www.xbstack.com/ai/context-engineering-agent-cost-memory-tools/?utm_sourcecsdnutm_mediumreferralutm_campaigncontext_engineering_agent_cost_memory_toolsutm_contentcontext-engineering-agent-cost-memory-toolsrefcsdn标签#AI #实战 #问题排查 #Context Engineering #Prompt Engineering #AI AgentRelated XBSTACK readingAI Agent Memory System: https://www.xbstack.com/ai/agent-memory-system/?utm_sourcecsdnutm_mediumreferralutm_campaigncontext_engineering_agent_cost_memory_toolsutm_contentrelated_1AI Agent RAG Integration: https://www.xbstack.com/ai/ai-agent-rag-integration/?utm_sourcecsdnutm_mediumreferralutm_campaigncontext_engineering_agent_cost_memory_toolsutm_contentrelated_2AI Agent Tool Use: https://www.xbstack.com/ai/ai-agent-tool-use/?utm_sourcecsdnutm_mediumreferralutm_campaigncontext_engineering_agent_cost_memory_toolsutm_contentrelated_3
