目录一、上下文工程的真正变化不是“少写提示词”而是重新分配控制权一从Prompt Engineering到Context Engineering1. 模型看到的从来不只是一条用户提示词2. 上下文的核心矛盾信息丰富度与决策清晰度之间存在张力二“删掉80%”意味着什么也不意味着什么1. 它说明模型能力提升后过去的补丁式规则可能成为技术债2. 它绝不等于“所有场景都应该删除80%的规则”二、六条旧规则失效背后的共同机制一从“给规则”到“让模型判断”控制粒度从动作级转向原则级1. 旧规则解决的是模型能力不足新原则解决的是任务差异2. 但“判断力”必须有边界不能把治理责任交给模型二从“给示例”到“设计接口”最好的提示词可能是一个好的Schema1. 示例会提供先验但也会缩小探索空间2. 参数名、枚举、类型和错误信息本身都在“提示”模型三从“全部前置”到“渐进式披露”上下文开始像虚拟内存一样被调度1. 全量注入的问题不是只有Token贵更严重的是注意力被稀释2. 渐进式披露的关键不是拆文件而是建立可发现性四从“重复强调”到“单一事实源”上下文也需要配置治理五从“把记忆写进CLAUDE.md”到“自动记忆”状态从文件转向长期服务六从“简单规格”到“丰富引用”让模型直接看高保真事实三、重新设计上下文架构四层、四类信息、三条边界一四层上下文架构1. 四层上下文分别承担不同职责1.1 系统层稳定身份、权限边界与产品级目标1.2 项目层组织特有知识、仓库gotchas与工作方式1.3 任务层本次目标、引用材料与验收标准1.4 运行时层工具结果、环境状态与验证反馈2. 四层之间需要明确的覆盖关系二四类信息应该放到不同载体1. 规则、知识、引用、状态不能混为一谈2. 一个判断载体的简单方法看信息是否能够被重新获得三三条边界决定上下文工程是否可治理1. 能力边界模型会什么不要重复教什么2. 权限边界模型能决定什么系统必须决定什么3. 时效边界什么可以缓存什么必须重新取证四、从“提示词工程师”到“智能体系统设计师”企业级方法论一上下文预算把Token当作有限的决策带宽1. 衡量上下文不应只看长度还要看“单位Token决策价值”2. 上下文预算需要关注冲突率而不只是重复率二工具接口把自然语言控制转化为结构化约束1. 一个好的工具比十段解释更能约束行为2. 工具返回值也应该进行“上下文压缩”三丰富引用与Rubric把“品味”变成可检查对象1. 参考物可以替代大量抽象描述2. Rubric让主观标准进入验证环节五、风险边界什么时候不能“松绑”一高风险动作仍然需要硬边界1. 破坏性和不可逆操作不能依赖模型自觉2. 合规规则属于“不可协商约束”不是偏好二模型判断力不能替代可验证性1. 让模型自由选择路径必须让环境负责验证结果2. 最可靠的上下文往往来自“刚刚发生的事实”三自动记忆必须有生命周期治理1. 记忆应该区分“偏好”“事实”“策略”2. 记忆必须能够被检查、更新和遗忘六、落地路径一套可执行的Context Refactoring Playbook一第一步做上下文资产盘点而不是直接删Prompt1. 建立上下文来源清单2. 给每条信息标记四个属性二第二步建立冲突地图和重复地图1. 找出语义重复而不是只做字符串去重2. 找出互相竞争的目标三第三步把信息迁移到正确载体1. 可以由接口表达的不再用自然语言反复表达2. 可以按需检索的不再永久前置四第四步建立“瘦身前—瘦身后”评测而不是凭感觉上线1. 评测集必须覆盖典型任务与高风险边界2. 不只看成功率还要看成本、延迟和行为稳定性五第五步把上下文维护纳入模型升级流程七、进一步推演上下文工程将走向“操作系统化”一上下文将从静态文本资产变成运行时资源1. 上下文调度会越来越像缓存与虚拟内存管理2. 上下文淘汰会和上下文加载同样重要二企业竞争力会从“谁有更长Prompt”转向“谁有更好的上下文资产”1. 可复用的高质量Skills会成为组织知识接口2. 高保真引用会成为比自然语言规则更重要的数据资产三Agent质量评估会从“回答像不像”转向“系统是否形成可靠闭环”1. 单次输出质量不再足以衡量Agent2. 上下文工程与评测工程会逐渐合流八、结语少不是目的正确的信息在正确时机出现才是参考文章干货分享感谢您的阅读过去两年许多团队把大模型应用的优化重点放在“提示词写法”上角色要写清楚、步骤要写完整、边界要写死、示例要覆盖尽可能多的情况、重要要求最好重复三遍。这个方法在早期模型上有现实基础因为模型的自主判断、工具调用和长任务稳定性有限工程师不得不用越来越厚的规则层来补足能力缺口。但当模型能力进入新的阶段同一套方法开始出现副作用。2026年7月24日Anthropic在《The new rules of context engineering for Claude 5 generation models》中给出一个极具象征性的结果面向Claude Opus 5、Claude Fable 5等新一代模型Claude Code系统提示被删除80%以上在其编码评测上没有可测量的性能下降。[1] 这与“更强模型需要更长提示词”的直觉相反却与过去一年Agent工程的发展趋势高度一致Agent真正需要的不是永久携带一部百科全书而是在当前决策点拿到最相关、最高保真、最可信、最可验证的那一小组信息。[2]这意味着上下文工程已经不再只是写作技巧而越来越像一种运行时架构设计。它处理的对象包括系统提示、项目说明、Skills、工具定义、代码和文档引用、记忆、检索结果、执行反馈、测试结果以及长任务中的阶段性状态。真正的问题不是“还要加什么”而是“什么信息应该常驻、什么应该延迟加载、什么应该由工具接口表达、什么应该从环境中重新获取、什么必须被硬约束、什么应该交给模型判断”。上下文工程不再等同于Prompt Engineering而是由稳定规则、项目知识、任务引用、运行时事实与验证反馈共同构成。一、上下文工程的真正变化不是“少写提示词”而是重新分配控制权一从Prompt Engineering到Context Engineering1. 模型看到的从来不只是一条用户提示词在典型的智能体系统里用户消息只是上下文的一部分。模型同时会看到产品层系统指令、项目级约束、代码库文件、Skills、工具描述、历史会话或记忆、检索到的文档、工具执行返回值等。Anthropic在给定材料和官方文章中都明确强调了这一点Context Engineering关心的是“模型在推理时实际拿到的全部信息”而不只是用户输入的那一段Prompt。[1][2]这个区别非常关键。提示词通常服务于一次请求因此可以非常具体上下文却往往跨很多请求复用所以它必须在“足够通用”和“足够有用”之间寻找平衡。一个用于代码仓库的长期说明文件如果把某一次重构任务的特殊要求写成永久规则就会污染未来所有请求一个企业级智能体如果把临时组织政策缓存成长期记忆也可能在政策变化后继续执行过时规则。因此上下文工程的第一原则不是“信息越多越好”而是“信息必须匹配它的生命周期”。稳定信息适合常驻易变信息应动态获取通用能力适合由模型本身承担组织特有知识适合放入Skills或知识库安全边界适合写成不可绕过的系统规则而实现细节可以交给模型根据环境判断。2. 上下文的核心矛盾信息丰富度与决策清晰度之间存在张力大模型对信息的利用并不是无成本的。上下文越长不仅意味着Token费用和延迟上升更重要的是相关性会下降。多个来源可能重复同一要求也可能以略有差异的措辞表达相互冲突的意图。给定材料举了一个很典型的内部记录现象系统提示可能要求“适当保留文档”某个Skill却要求“不要写注释”用户又可能明确要求补充解释。模型通常能够权衡但它需要额外推理成本来判断哪个指令更贴近当前任务。从系统设计角度看这是一种“控制平面拥塞”。传统软件把控制逻辑写进程序智能体系统则往往把大量控制逻辑写进自然语言上下文。当规则层不断累积问题就会从“模型不知道做什么”转变为“模型同时被告知太多互相竞争的做法”。所以高质量上下文的目标不是最大覆盖而是最大信号密度。二“删掉80%”意味着什么也不意味着什么1. 它说明模型能力提升后过去的补丁式规则可能成为技术债Claude Code早期为了避免删除文件、滥写注释、生成无关规划文档等坏结果需要非常强的防守性指令。随着模型判断能力提高一部分规则不再提供净收益。Anthropic的新做法更倾向于表达目标和环境例如“让代码读起来像周围代码匹配注释密度、命名和惯用法”而不是枚举所有禁止事项。[1]这里反映的是模型工程中的一个普遍现象为旧模型写下的Prompt补丁不会自动过期但模型能力会持续变化。如果团队只新增规则、不删除旧规则系统提示会像多年无人清理的配置文件一样膨胀。每次模型升级之后都应该重新评估哪些约束仍然必要哪些已经被模型基本能力覆盖哪些反而限制了更强模型的判断。2. 它绝不等于“所有场景都应该删除80%的规则”80%是Anthropic针对特定模型、特定产品和特定内部评测得出的工程结果不是一个可以机械复制到所有企业Agent上的比例。金融交易、医疗流程、数据删除、权限变更、合规审批等高风险动作仍然需要强约束、显式权限和可审计的验证链路。更强判断力可以减少“如何写代码”这类细节规则却不能替代“哪些动作绝不能自动执行”这类安全边界。所以“少即是多”真正的专业表达应该是删除不能增加预期效用的上下文保留能够改变正确决策的高价值信号。上下文瘦身不是追求最短而是追求最小充分集。二、六条旧规则失效背后的共同机制给定材料把变化总结为六组“过去—现在”从规则转向判断、从示例转向接口、从全部前置转向渐进式披露、从重复指令转向简洁工具描述、从CLAUDE.md记忆转向自动记忆、从简单规格转向丰富引用。表面上它们属于不同技巧底层却可以归纳为同一个趋势把控制从静态文本堆叠迁移到结构化接口、动态检索、外部状态和可验证反馈之中。六项变化并非独立技巧而是共同指向“少静态文本、多结构化系统”的上下文架构。一从“给规则”到“让模型判断”控制粒度从动作级转向原则级1. 旧规则解决的是模型能力不足新原则解决的是任务差异早期系统提示常见的写法是“永远不要……”“必须总是……”“只能……”。这种写法能提高一致性但也把本来应该依赖上下文的判断提前固定下来。比如注释是否需要多行不应由一个全局规则决定而应取决于代码库风格、函数复杂度、团队规范和用户目的。更先进的模型可以在更高层原则下完成低层选择因此指令也应向“目标函数”靠近与周围风格一致、优先保持向后兼容、在不确定时选择保守方案、变更必须通过现有测试等。这类原则比动作级禁令具有更好的泛化性。2. 但“判断力”必须有边界不能把治理责任交给模型允许模型自行判断适合“如何实现”不适合“是否有权实现”。例如代码格式、命名方式、注释密度可以交给模型生产数据库删除、密钥导出、财务付款、隐私数据共享则应由权限系统、审批流程或工具本身强制限制。这是一个重要分界软约束可由上下文表达硬约束应由系统能力和工具权限实现。二从“给示例”到“设计接口”最好的提示词可能是一个好的Schema1. 示例会提供先验但也会缩小探索空间Few-shot示例一直是Prompt Engineering的重要方法。它的优势是直观模型可以模仿输出格式和工具用法缺点是示例会形成强先验使模型倾向于重复见过的路径。Anthropic在Claude 5代模型上的观察是当模型本身已经能够理解工具语义时大量示例可能限制其探索空间。[1]这并不意味着示例毫无价值而是说明示例应该用于真正复杂、容易歧义的参数关系而不是替代接口设计。Anthropic在后续“Advanced Tool Use”中也强调对于复杂嵌套结构和领域特殊约定工具示例仍然有价值对于单参数、语义明显的工具则不必为示例支付额外上下文成本。[6]2. 参数名、枚举、类型和错误信息本身都在“提示”模型如果一个Todo工具的状态字段定义为pending / in_progress / completed模型无需阅读长篇说明也能理解状态机。如果参数叫user_id而不是user可以减少对象类型歧义。Anthropic在工具设计文章中甚至提出要像给新同事写高质量docstring一样设计工具说明并通过清晰数据模型把正确用法“编码”进接口。[5]这意味着Agent工程师的工作重心会从“写更长的工具使用说明”转向“设计更不容易被误用的工具”。在传统软件工程里这叫poka-yoke也就是防错设计在Agent系统里它同样有效让不合法状态难以表达让高风险动作显式化让参数本身携带语义。三从“全部前置”到“渐进式披露”上下文开始像虚拟内存一样被调度1. 全量注入的问题不是只有Token贵更严重的是注意力被稀释如果一个Agent连接几十个MCP服务每个服务都有几十个工具把所有定义在请求开始前都塞进上下文会在模型读到用户任务之前就消耗大量Token。Anthropic在高级工具使用文章中披露工具定义和返回结果在某些场景可以消耗数万甚至十万级Token因此引入Tool Search、延迟加载和程序化工具调用等机制让Agent只在需要时加载完整定义。[6][7]这与操作系统中的虚拟内存思想非常相似并不是所有资源都必须一次性装入“工作集”只需要让Agent知道资源存在并在发生需求时加载对应页面。2. 渐进式披露的关键不是拆文件而是建立可发现性简单地把一个大文件拆成十个小文件如果Agent不知道何时应该找哪一个并不能真正改善效果。渐进式披露至少需要三个条件第一入口文件轻量且能指向下一级资源第二资源命名和目录结构具有明确语义第三Agent拥有可靠的搜索或检索手段。因此一个优秀的项目级上下文入口不应该变成“所有规范的合集”而应该更像索引和路由器说明仓库做什么、有哪些重要坑、遇到特定任务应该查看哪个Skill或哪类引用。给定材料对CLAUDE.md的建议正是如此保留轻量项目说明把Token重点花在代码库特有的gotchas上并通过Skill承载独特验证流程。四从“重复强调”到“单一事实源”上下文也需要配置治理早期模型可能更容易受上下文末尾影响因此工程师会在系统提示、工具说明和任务提示中重复同一规则。重复虽然提高被注意的概率却带来版本漂移某处改了另一处没改最终形成冲突。更成熟的做法是为每类信息确定唯一权威位置。例如工具使用规则放在工具描述里代码库特有约束放在项目级入口验证流程放在验证Skill用户临时目标只存在于任务上下文。这样做不仅节省Token更重要的是降低“同一规则多份副本”的维护成本。五从“把记忆写进CLAUDE.md”到“自动记忆”状态从文件转向长期服务自动记忆意味着Agent可以把与用户、工作偏好或长期项目相关的信息跨会话保存而不必把所有内容堆到一个仓库说明文件里。[1] 这是能力提升也是治理难题。因为记忆与规则不同规则是开发者希望模型遵循的显式控制记忆则是系统根据互动形成的长期状态。两者混在一起可能让“过去发生过什么”悄悄变成“未来必须怎么做”。因此企业采用自动记忆时应至少考虑来源、时效、可撤销性和作用域。个人偏好可以长期保留项目状态应该绑定项目组织政策应从权威系统动态获取高敏感信息则不应被随意固化为长期记忆。自动记忆降低了CLAUDE.md的负担但不意味着记忆可以无治理地增长。六从“简单规格”到“丰富引用”让模型直接看高保真事实文字描述是一种有损压缩。你用三段自然语言描述一个交互界面往往不如直接给模型一个HTML原型你解释一个算法应该怎么实现往往不如给它一个成熟代码库里的参考函数你描述“什么叫好API”往往不如给出一组可执行测试和Rubric。Anthropic把这类材料称为Rich References并强调代码、测试、HTML、Artifacts等高保真引用能够减少解释层的损失。[1][3] 这揭示了一个非常重要的上下文工程原则能引用事实就不要重复描述事实能提供可执行规范就不要只提供抽象要求。三、重新设计上下文架构四层、四类信息、三条边界如果把上述变化抽象成企业级架构可以把Agent上下文划分为四层。这个分层不是为了增加复杂度而是为了回答一个关键问题每条信息到底应该放在哪里。一四层上下文架构越靠上越稳定、越适合常驻越靠下越动态、越应该通过检索、工具与验证按需获取。1. 四层上下文分别承担不同职责1.1 系统层稳定身份、权限边界与产品级目标系统层描述Agent是谁、运行在哪个产品里、有哪些不可突破的安全规则、何时必须请求确认。它应该稳定、简短、高优先级。真正不可绕过的限制最好不仅写在文本里还由权限、沙箱、审批和工具访问控制共同实施。1.2 项目层组织特有知识、仓库gotchas与工作方式这一层对应CLAUDE.md、团队规范、项目级Skills等。它不应重复模型通过读文件就能推断出的显而易见内容而应记录模型难以自行发现、但会显著影响正确性的组织知识例如“所有类型只能集中在一个文件”“该接口必须兼容历史客户端”“发布前必须执行特定回归脚本”。1.3 任务层本次目标、引用材料与验收标准任务层是最具时效性的上下文包括用户目标、当前工单、设计稿、测试用例、Rubric、临时约束和要修改的文件。这一层应该尽可能高保真并随任务结束而退出工作集。1.4 运行时层工具结果、环境状态与验证反馈Agent真正可靠的依据往往来自运行时文件系统当前内容、Git差异、测试结果、数据库查询、API返回值、权限检查、监控指标等。Anthropic多篇Agent工程文章都反复强调“从环境获得ground truth”。静态上下文只能告诉模型“通常怎样”运行时上下文才能告诉模型“现在实际上怎样”。[4][8]2. 四层之间需要明确的覆盖关系如果四层信息发生冲突必须有可解释的优先级。例如系统层安全边界高于任务层用户要求任务层的明确目标通常高于项目层默认偏好运行时事实应覆盖陈旧的静态假设。没有这套优先级Agent只能凭语言强度猜测哪条更重要容易出现“谁写得更大声谁赢”的问题。一个实用原则是权限高低决定“能不能做”任务意图决定“要不要做”运行时事实决定“现在怎么做”。这三类判断不要混在同一段自然语言里。二四类信息应该放到不同载体1. 规则、知识、引用、状态不能混为一谈很多上下文膨胀来自载体错位把知识当规则写、把状态当知识写、把临时引用当长期记忆写。可以用下面的分配方式理解信息类型典型内容更合适的载体主要风险规则安全边界、权限、不可违反原则System Prompt、工具权限、审批流程过度约束或被文本绕过知识团队惯例、项目gotchas、领域流程Skills、项目文档、知识库过期、重复、难发现引用代码、测试、设计稿、规格、Rubric文件引用、Artifacts、代码库低保真转述、版本不一致状态当前任务进度、环境结果、用户长期偏好运行时工具、短期工作文件、Memory陈旧、越权、作用域污染这张表的价值在于它把“我要告诉模型什么”改成“我要把信息放到哪个系统组件中”。上下文工程因此从写作问题转化为架构问题。2. 一个判断载体的简单方法看信息是否能够被重新获得能通过文件系统、数据库、API、搜索、Git或测试重新获得的事实通常不需要永久塞进系统提示。越容易从权威源重新获取就越应该在需要时查询。相反那些模型无法通过环境发现的组织隐性知识才值得放入长期上下文。这种分工还能降低“陈旧事实”风险。比如“当前生产版本是v3.4”不应该写进长期Skill因为版本会变化更好的方式是让Agent查询发布系统。Skill只需要说明“需要判断生产版本时应调用哪个工具、结果以哪个字段为准”。三三条边界决定上下文工程是否可治理1. 能力边界模型会什么不要重复教什么通用编程知识、常见格式、标准库用法等如果模型已经掌握就没有必要在每个项目里重复。团队应该把上下文预算留给模型不知道的特有信息。2. 权限边界模型能决定什么系统必须决定什么“是否写两行注释”是判断问题“是否删除生产数据”是权限问题。高风险行为必须由工具和系统设计限制而不能仅靠一句“请谨慎”。3. 时效边界什么可以缓存什么必须重新取证越容易变化的信息越应在执行时获取。上下文里最危险的内容往往不是错误规则而是过去曾经正确、现在已经过时的事实。四、从“提示词工程师”到“智能体系统设计师”企业级方法论上下文工程的成熟意味着角色能力结构也会变化。过去擅长Prompt的人常关注措辞、顺序、角色设定和示例未来更重要的能力是信息架构、接口设计、检索、权限、评测和状态管理。可以把它概括成三个工程对象上下文预算、工具接口和验证闭环。一上下文预算把Token当作有限的决策带宽上下文预算的目标不是追求最少Token而是让常驻工作集保持高相关、低冲突、低陈旧度。1. 衡量上下文不应只看长度还要看“单位Token决策价值”一段上下文值不值得常驻可以问四个问题它是否经常被用到如果缺失会不会显著改变结果模型能否从环境中自己发现它多久会过期高频、高影响、难发现、稳定的信息最值得常驻低频、低影响、易检索、易过期的信息最不值得常驻。从这个角度看“删减上下文”的本质是做信息投资组合管理。每个Token都占用注意力预算因此应该优先放入能够降低错误率、减少歧义、提高任务完成率的高信号信息。2. 上下文预算需要关注冲突率而不只是重复率两个句子即使不完全相同也可能在行为上冲突。例如“尽量保持变更最小”和“主动重构相关模块以提升长期可维护性”在不同任务里可能拉向相反方向。团队在做上下文审计时不能只做文本去重还要做“决策冲突映射”如果模型同时遵守两条规则会不会产生无法兼容的动作二工具接口把自然语言控制转化为结构化约束1. 一个好的工具比十段解释更能约束行为如果一个高风险工具只有run(command)再长的提示词也很难确保Agent永远不误用如果工具被拆成read_logs、restart_service、deploy_version并要求显式环境、变更单号、确认状态等参数系统就能在接口层表达风险等级。工具设计应该让正确路径最顺畅让错误路径难以表达。对Agent来说参数schema、枚举、必填项、错误消息、返回字段都是上下文的一部分。换句话说接口即提示类型即规则。2. 工具返回值也应该进行“上下文压缩”很多Agent失败不是因为工具不会调用而是因为工具一次返回太多无关内容。Anthropic在工具工程与MCP文章中建议使用分页、过滤、范围选择、截断和程序化处理避免大规模中间结果直接污染上下文。[5][7]企业数据系统尤其应该重视这一点。例如“获取过去一年的所有订单”可能返回几十万行数据但Agent真正需要的可能只是异常订单数量和几个样例。最佳实践不是让模型在Token里手工聚合而是让工具先做数据库级过滤或代码级计算再返回足够支持判断的结果。三丰富引用与Rubric把“品味”变成可检查对象1. 参考物可以替代大量抽象描述当用户说“做得更高级一点”“API要优雅”“页面要像我们现有产品”这些要求很难通过规则穷举。最有效的方法往往是给出代表“好”的现有样本同一代码库中的高质量模块、已上线页面、设计系统组件、历史通过评审的PR、标准测试套件等。Claude Fable 5的Field Guide甚至把“References”作为发现未知和减少沟通损失的重要方法并指出源码通常是最丰富的参考之一因为它同时编码了结构、命名、行为和边界条件。[3]2. Rubric让主观标准进入验证环节Rubric不是简单的“要求列表”而是一组可以被验证Agent或评审流程使用的质量判断标准。比如API设计Rubric可以包含一致性、错误模型、幂等性、向后兼容、可观察性等维度UI Rubric可以包含信息层级、交互反馈、可访问性、视觉一致性等。它的价值在于把“我觉得不够好”转换为“哪些维度没有达到标准”。当Rubric与测试、静态分析和多Agent验证结合时上下文工程就从输入侧扩展到了输出评估侧。五、风险边界什么时候不能“松绑”“Unhobbling Claude”是给定材料的核心洞见之一但企业应用最容易误用的也是这句话。如果把“减少约束”理解成“减少控制”就会把模型能力提升误读成安全工程可以退场。事实上更合理的方向是减少低价值文本约束增强高价值系统约束和验证机制。一高风险动作仍然需要硬边界1. 破坏性和不可逆操作不能依赖模型自觉删除数据、覆盖备份、支付资金、修改访问控制、对外发布、发送敏感信息等操作应尽可能通过工具权限、最小授权、二次确认、审批和可撤销机制限制。文本里的“谨慎操作”只能作为补充不能作为主要安全控制。Anthropic关于Agent安全与自动模式的工程实践也体现了类似方向更自主并不等于无限权限而是通过更好的隔离、权限边界和风险识别让低风险任务减少摩擦、高风险任务仍保留强控制。2. 合规规则属于“不可协商约束”不是偏好企业上下文里往往同时存在风格偏好和法规要求。比如“尽量简洁”可以被任务需求覆盖“不得输出某类受监管数据”则不应该因为用户要求而取消。上下文重构时必须给规则分类避免把所有“必须”都当作历史技术债删掉。二模型判断力不能替代可验证性1. 让模型自由选择路径必须让环境负责验证结果Agent工程一个看似矛盾的趋势是输入端约束变少输出端验证反而要更强。因为越允许模型自行决定实现路径就越需要测试、静态分析、差异检查、模拟环境、Rubric和人工审批确认结果。这也是为什么编程Agent成为Agent系统的先行场景代码可以运行测试可以失败Git可以展示差异环境能够给出明确反馈。Anthropic在《Building effective agents》中强调Agent运行过程中应不断从环境获得ground truth并据此调整而不是只依赖内部推理。[4]2. 最可靠的上下文往往来自“刚刚发生的事实”对于长任务模型最容易被静态计划绑架。计划写得再好也可能在执行中遇到代码真实状态、依赖版本、接口限制或用户数据异常。高质量Agent必须允许自己根据新事实偏离旧计划并把偏离原因记录下来。这正是Fable 5 Field Guide推荐实施笔记implementation notes的价值当执行遇到未知问题时Agent记录偏差和决策使后续会话能够继承“为什么改变计划”这一关键上下文而不是只留下最终代码。[3]三自动记忆必须有生命周期治理1. 记忆应该区分“偏好”“事实”“策略”用户偏好如“喜欢简洁汇报”可以长期记事实如“本周项目负责人是A”可能很快过期策略如“上线前绕过某个测试”则不应因为一次临时对话变成永久习惯。不同类型记忆需要不同保留时间和确认机制。2. 记忆必须能够被检查、更新和遗忘长期Agent不可避免会积累状态。没有更新机制的记忆会变成隐形技术债。企业应考虑可见性、可删除性、作用域隔离、来源追踪和冲突解决特别是当同一Agent服务多个团队或多个项目时必须避免跨域污染。六、落地路径一套可执行的Context Refactoring Playbook对于已经运行一段时间的Agent系统最现实的问题不是“从零怎么设计”而是“现有Prompt、Skills、项目文档和工具说明已经很长如何安全瘦身”。下面给出一套可执行的重构流程。一第一步做上下文资产盘点而不是直接删Prompt1. 建立上下文来源清单列出模型在一次典型请求中可能收到的全部信息系统提示、开发者提示、项目入口文件、Skills、工具定义、长期记忆、检索片段、代码引用、会话历史、自动生成的计划、工具返回值等。很多团队只盯着System Prompt却忽略真正占用上下文的可能是几十个工具描述和大段检索结果。2. 给每条信息标记四个属性建议至少标记使用频率、决策影响、变化速度、可检索性。这样可以快速识别“高频高影响且稳定”的常驻核心也能识别“低频易变且可检索”的延迟加载候选。二第二步建立冲突地图和重复地图1. 找出语义重复而不是只做字符串去重例如“不要无请求创建文档”“除非用户要求否则不要写分析文件”“默认不生成规划文档”属于同一行为簇。可以合并成更高层原则或者交给任务上下文决定。2. 找出互相竞争的目标将“最小改动”“主动重构”“严格遵循既有结构”“优先现代化技术栈”等原则放在一起分析明确它们适用的条件。冲突不是一定要删除其中一条而是要增加条件和作用域。三第三步把信息迁移到正确载体1. 可以由接口表达的不再用自然语言反复表达枚举、参数类型、必填字段、权限检查、文件路径规范、状态机等优先进入工具或程序结构。自然语言只保留模型需要理解的目的和特殊语义。2. 可以按需检索的不再永久前置验证流程、复杂领域知识、很少使用的部署步骤可以迁移为独立Skill大型API文档可以通过检索访问不常用工具可以采用动态发现。入口文件只需要告诉Agent“资源在哪里、何时使用”。入口上下文负责导航Skill、引用和工具定义在任务触发时按需展开避免“中央仓库”式堆叠。四第四步建立“瘦身前—瘦身后”评测而不是凭感觉上线1. 评测集必须覆盖典型任务与高风险边界Anthropic能够删除大量系统提示仍保持性能一个前提是有编码评测作为依据。企业也应建立自己的任务集包括日常高频任务、历史失败案例、边界输入、高风险动作和长任务场景。2. 不只看成功率还要看成本、延迟和行为稳定性上下文重构的收益可能体现在多方面Token下降、响应速度提高、工具选择更准确、冲突减少、长任务完成率提高。同时也要监控是否出现新的幻觉、越权或风格漂移。最好的“简化”不是短而是总体效能更高。五第五步把上下文维护纳入模型升级流程每次模型大版本升级都应该触发一次Context Review。原因很简单模型能力变化后旧规则的边际价值也会变化。过去必要的示例可能已经多余过去无法交给模型判断的任务可能可以放权新的工具发现能力又可能允许更多内容延迟加载。这和传统软件升级后的依赖清理类似。Prompt与Skills不是一次性资产而是需要随模型能力迭代的工程代码。团队甚至可以把上下文文件纳入代码审查、版本控制和回归评测避免它们成为没人敢删的“神秘配置”。七、进一步推演上下文工程将走向“操作系统化”如果把Claude 5代所体现的趋势继续向前推演上下文工程很可能从“Prompt文件管理”演化成一种Agent Context OS系统不再预先拼接一个巨大字符串而是在Agent运行过程中动态管理信息的装入、淘汰、缓存、验证和持久化。一上下文将从静态文本资产变成运行时资源1. 上下文调度会越来越像缓存与虚拟内存管理未来的Agent Harness可能会对上下文条目维护元数据来源、可信度、最后更新时间、作用域、Token成本、访问频率、相关任务、是否可重新获取等。系统根据当前目标自动决定哪些内容进入工作集哪些只保留索引哪些需要刷新。这比“把所有资料塞给模型”更接近成熟的软件架构。Anthropic已经在Tool Search、动态Skills、程序化工具调用和长任务harness中展现了类似方向模型先发现资源再选择加载必要时让代码处理大数据只把压缩后的结果返回上下文。[6][7][8]2. 上下文淘汰会和上下文加载同样重要当前很多系统只会“加上下文”不会“忘上下文”。长期来看淘汰机制将成为核心能力某个任务结束后删除临时材料某条事实过期后自动失效某个Skill更新后旧版本不再被引用某段对话经过压缩后保留决策而丢弃低价值过程。这会让“上下文卫生”成为新的工程指标。一个能够正确忘记的Agent往往比一个什么都记得的Agent更可靠。二企业竞争力会从“谁有更长Prompt”转向“谁有更好的上下文资产”1. 可复用的高质量Skills会成为组织知识接口当通用模型能力越来越强企业差异化不再来自教模型“什么是Python”或“怎么写邮件”而来自组织独有的流程、标准、历史决策和高质量范例。Skills恰好提供了一种把这些隐性知识包装成可发现、可组合资源的方式。[9]未来优秀的企业Agent团队可能会像维护内部SDK一样维护Skills有负责人、有版本、有测试、有使用统计、有废弃策略。Skill不是提示词片段而是组织知识的可执行接口。2. 高保真引用会成为比自然语言规则更重要的数据资产代码库、测试、设计系统、Rubric、黄金样例、历史高质量PR、真实业务数据模式等能够比抽象规则更准确地表达“我们这里什么叫好”。企业如果把这些资产整理成Agent可访问、可检索、可引用的形式就能显著提高模型对组织语境的适配度。三Agent质量评估会从“回答像不像”转向“系统是否形成可靠闭环”1. 单次输出质量不再足以衡量Agent真正的Agent任务包含检索、决策、调用工具、修改环境、验证结果和跨会话持续推进。评价它不能只看最终文字是否漂亮而要看是否找到正确上下文、是否选择正确工具、是否在不确定时补充信息、是否根据反馈调整、是否保持权限边界、是否留下足够的可审计记录。2. 上下文工程与评测工程会逐渐合流每次上下文变更都可能改变Agent行为因此Context Engineering必须配套Evals。哪些Token应该保留不能靠经验争论而应通过评测判断。未来成熟团队会对系统提示、工具描述、Skills、检索策略甚至记忆策略做A/B评估把“提示词玄学”变成可测量的工程优化。发现信息、按需加载、执行动作、环境验证、记录状态、评测与重构形成闭环上下文工程由一次性写Prompt变成持续治理。八、结语少不是目的正确的信息在正确时机出现才是Claude 5代模型带来的上下文工程新规则最值得重视的不是“系统提示可以缩短80%”这个数字而是它揭示了Agent系统正在跨过一个工程拐点。过去我们用更多规则、更多示例、更多重复来弥补模型能力不足现在随着模型判断、工具使用、检索和长任务能力增强继续堆积静态上下文反而会制造新的瓶颈。新的范式可以浓缩为一句话把模型已经会的交还给模型把模型不知道的组织知识做成可发现资源把易变事实交给运行时工具把安全边界固化在系统与权限里把“好不好”交给测试和Rubric验证。因此专业的上下文工程并不是“尽可能少写”而是建立一种精确的信息供应链稳定信息常驻特殊知识按需加载复杂意图用高保真引用表达环境事实实时获取长期偏好受控记忆高风险动作由系统硬约束最终结果由可验证反馈闭环确认。当这种架构建立之后Prompt不再是Agent的全部“大脑”而只是一个入口。真正决定智能体上限的将是它身后的上下文操作系统能否在正确的时间把正确的信息以正确的形式交给足够强的模型做判断。参考文章The new rules of context engineering for Claude 5 generation models - Claude by AnthropicEffective context engineering for AI agents - AnthropicA field guide to Claude Fable 5: Finding your unknowns - Claude by AnthropicBuilding effective agents - AnthropicWriting effective tools for agents - with agents - AnthropicIntroducing advanced tool use on the Claude Developer Platform - AnthropicCode execution with MCP: Building more efficient agents - AnthropicEffective harnesses for long-running agents - AnthropicEquipping agents for the real world with Agent Skills - AnthropicUsing Claude Code: The unreasonable effectiveness of HTML - Claude by Anthropic