上下文不是聊天记录

一句话收获：上下文工程管理的是当前决策环境，不只是对话长度。

这个场景在解决什么问题

这个场景要讲清楚一件事：Agent 每次做决策前"脑子里装的东西"到底由哪些部分组成。原文的做法是逐层装载八类信息（目标、规则、资料、状态、工具、历史等），观察模型当前究竟能看见什么。它值得单独学，是因为很多人一听到"上下文"（Context，指模型当前能看到并参与决策的全部输入）就以为等于"把聊天记录拉长一点"，而实际上上下文是一个经过精心组织的"当前决策工作包"，对话长度只是其中最小的一环。

先理清这条判断链（文字版）

这个场景是"从稳定到动态、从当前到历史"逐层装上下文：先看稳定规则，再看这次任务的事实，接着看状态、知识和工具，最后才看历史和最近结果。验收标准是——模型当前"能看见什么"是否完整、是否权威、是否真的为下一步决策服务。

先确认稳定前缀：身份、任务边界、输出契约、长期规则是否装好。
再装载本次任务事实：目标、对象、业务材料、当前问题。
接着装载当前环境：权威状态、检索证据、可用工具。
最后只保留影响下一步的历史、错误和外部回执。

逐层详解

第 1 步：稳定规则

原文：身份、任务边界、输出契约和长期规则构成稳定前缀。

白话：每次开工前，先给模型放一份"基本不变的东西"——你是谁、这个任务能做什么不能做什么、输出要长什么样、有哪些长期规矩。这些内容相对固定，所以放在最前面。

类比：像公司新员工入职时发的那本《员工手册》——公司名、岗位职责、红线、报销流程，这些不会因为某一天的具体工作而变，所以装订在最前面，人人先读。

举例：你做一个售后客服 Agent，稳定前缀里就写"你是 XX 公司售后助手，只回答售后问题，回答必须带工单号，不得擅自承诺退款金额"。这部分不管今天处理 10 个还是 100 个工单都一样。

为什么重要：稳定内容应保持一致并便于缓存和审查——因为它不变，所以可以只装一次、缓存复用，也方便出了问题时倒查"当时规则到底是什么"。

怎么验证（证据点）：

角色明确
边界明确
版本可追踪

别踩的坑（边界）：放在 System 中仍然不是硬约束——写在 System Prompt（系统提示，位于消息最上层的高优先级提示）里只是"优先级更高、模型更倾向听"，不等于程序层面真的拦住它。

落地检查：消息位置提供优先级信号，不提供执行权限——落地时要把"规则写在 System 里"和"规则由代码强制"分成两件事，前者是提示，后者才是权限。

第 2 步：任务事实

原文：目标、对象、业务材料和当前问题进入动态任务区。

白话：每次任务不一样的内容单独放一块——这次要达成什么目标、针对哪个对象、有哪些业务材料、当前卡在什么问题。

类比：像每天的"今日工作单"——昨天是修 A 客户的机器，今天是给 B 客户出方案，材料、对象、目标天天换，所以是动态的。

举例：同一个客服 Agent，今天处理"订单 1001 退款申请"，任务事实区就装：目标=判断能否退款、对象=订单 1001、材料=该订单的支付记录和退款政策、问题=客户投诉金额错误。

为什么重要：每次任务事实不同，需要按需装载——不该把无关材料全塞进去，也不该漏掉本次必需的。

怎么验证（证据点）：

目标当前
对象明确
来源可回查

别踩的坑（边界）：材料进入窗口不证明模型会正确使用——放进来不等于用对，材料可能被忽略或误读。

落地检查：事实需要与推断分开——落地时明确区分"这是材料里的客观事实"和"这是模型根据材料推出来的结论"，别把两者混在一起。

第 3 步：状态、知识与工具

原文：权威状态、检索证据和可用工具共同形成当前环境。

白话：告诉模型三件事——现在实际是什么状态（权威状态）、判断的依据是什么（检索到的证据）、能动手做什么（可用工具）。

类比：像开车时的仪表盘 + 地图 + 方向盘——仪表盘告诉你当前车速和油量（状态），地图告诉你路况（知识/证据），方向盘、刹车、油门是你能操作的东西（工具）。

举例：客服 Agent 处理退款时，状态=订单当前"已付款未发货"、知识=检索到的退款政策原文、工具=可以调用的"查询物流""发起退款"两个接口。

为什么重要：Agent 要知道现在是什么、依据是什么、能够做什么——三者缺一，它既不知道处境，也不知道手里能出什么牌。

怎么验证（证据点）：

状态当前
知识有引用
工具按身份装载

别踩的坑（边界）：历史总结不能替代实时状态——模型从聊天里"总结出来"的状态可能已经过期，权威状态必须来自外部系统。

落地检查：状态、知识和工具各有权威来源——落地时分别指定：状态从数据库/接口来、知识从检索系统来、工具从身份白名单来，不能互相替代。

第 4 步：历史与最近结果

原文：只保留影响下一步的历史、错误和外部回执。

白话：历史不是全塞，只挑"会影响接下来动作"的部分——最近的结果、犯过的错、外部的回执。

类比：像接力赛交棒——你只需要知道"上一棒跑到哪、有没有犯规、成绩多少"，不需要回放整场比赛录像。

举例：客服 Agent 继续处理退款，历史区只留"上一轮已查询物流、客户已补充凭证、第三方支付已回执到账"，而不保留客户开头说的寒暄话。

为什么重要：上下文追求决策价值，不追求完整聊天存档——上下文是"为下一步决策服务"的，不是"聊天记录备份"。

怎么验证（证据点）：

最近回执
未决事项
剩余预算

别踩的坑（边界）：全部历史装入不等于信息更完整——塞满历史只会稀释关键信息，甚至让模型抓不住重点。

落地检查：历史应被筛选、摘要或外存——落地时对历史做筛选、摘要，或把完整历史存到外部数据库，只在需要时检索回来。

落地可行性小结

本场景涉及的技术栈是"上下文组装（Context Assembly）"：System Prompt 前缀、任务区模板、状态注入、工具描述注入、历史摘要与外部存储。真实落地做法：把稳定规则抽成可版本化的配置模板，每次请求按"稳定前缀 + 动态任务区 + 状态/知识/工具 + 精选历史"的顺序拼装。要检查的：状态是否来自权威源而非聊天摘要、工具是否按身份装载、历史是否被筛选。常见坑：把聊天记录直接当上下文、把状态写进 System 却不实时刷新、材料堆进去就以为模型会用。

回顾

上下文是"当前决策工作包"，不是聊天记录的简单延长。
八类信息分层：稳定前缀、动态任务、状态知识工具、精选历史。
稳定内容放前面便于缓存和审查，动态内容按需装载。
状态、知识、工具各有权威来源，不能互相替代。
历史只保留影响下一步的部分，其余筛选、摘要或外存。