模型可以更换 公司知识应该留下

工作记录，要和执行者分开。

Anthropic 2026 年 4 月的 Managed Agents 工程文章，把会话记录、运行框架和执行环境分开，用稳定的接口，让各部分能各自演进。这是一条有用的架构经验，并不意味着企业必须使用它的托管服务。

对企业来说，对应的问题很直接：换了模型，或者重启了执行进程，团队还找得回输入、决定和认可的结果吗？重要的业务上下文，不能依赖某个聊天标签页或某个进程一直活着。

来源 [1]

上下文多，不等于上下文好。

Anthropic 的上下文工程指南，把模型工作时的上下文看作有限的资源，强调挑选相关信息、需要时再加载细节，而不是把所有能找到的文档塞进每次请求。

我们建议用一个实际的标准来检查：后来的执行者，能不能分清三件事。原始材料说了什么，某次分析得出了什么，公司后来确认了什么。把三者压成一段语气肯定的总结，其中一项变了，这段总结就很难维护。

来源 [2]

让知识有出处，也有适用范围。

可复用的知识，光有标题不够，还要保留来源、适用的任务或客户。时效性强的事实，还要有生效时间。为某位客户改过的交付规则，不能悄悄变成所有客户的默认规则。

权限也是这套结构的一部分。能总结一份文档，不等于有权把摘要发给更大范围的团队。访问决定要和存下来的内容绑在一起，并且从不同角色的角度检验检索结果。

用公司的实际工作，检验模型切换。

切换模型之前，先用固定的参考材料，把一组有代表性的任务重跑一遍。比较产物能不能用、漏了哪些依据、提了哪些权限请求、成本和审核负担。新模型可能更擅长一类任务，却不一定更守某项工具约定。

目的不是冻结技术栈，而是让变化可以承受：保留公司拥有的记录，写明工作接口，并且在让团队依赖新的执行层之前，先做完评估。