同一次任务留下的三句话：我们怎样划分 Memory、Knowledge 与 Skill

一次任务结束后，Agent 的会话里可能同时留下这样三句话："用户在这次任务里选择了方案 B"；"方案 B 适用于某一类业务条件"；"选定方案 B 之后，按这几个步骤调用工具"。它们出自同一段对话，看上去都该存下来。我们在设计 Agent Context 的资产模型时，最先要回答的问题就是：这三句话能不能放在一起。

我们的答案是分开放。第一句是任务状态，只对这位用户、这个项目成立。第二句是一条判断，如果要给其他 Agent 使用，就需要有人对它负责。第三句是一种做法，一旦被调用，会直接驱动外部动作。三者的归属、可信程度和失效方式各不相同。放进同一个存储统一检索，前期最省事；等到需要分别设置权限、版本和发布流程时，就只能从头拆一遍。

在云栖大会的分论坛上，我们用过一个类比：做业务研发，最先定下来的是数据结构和表结构；做上下文也一样，资产分类相当于表结构设计。分类定得粗，后面的权限、检索和治理都会跟着含糊。下面按三类资产分别说明我们给出的定义、做过的取舍和目前的边界。

我们放弃过的另一种做法

在确定三类资产之前，我们评估过一种更简单的方案：只保留一个统一的上下文库，每条内容打上"私有""共享""可执行"之类的标签，检索时按标签过滤。这个方案的好处很明显，存储和检索只有一套，接口也少。

放弃它的原因在于，标签只能区分可见范围，解决不了生命周期的差异。私有记忆需要每晚整理、按召回频率衰减；共享知识需要入库评审、冲突审核和旧版追溯；Skill 需要候选版本、评估和回滚。如果三者共用一套写入和更新流程，要么记忆被套上知识的评审流程，写一条偏好都要等人审核；要么知识被套上记忆的自动整理逻辑，一条团队规则可能因为一段时间没被召回就被衰减掉。打标签的方案越往后走，标签之间的例外规则就越多，最终会在一个库里重新长出三套流程。我们宁可在模型层面一开始就把它们分开，让每类资产有自己的准入、治理和退出方式。

这个决定也有成本。三类资产之间需要明确的流转通道，记忆晋升、Skill 候选这些机制都是为此额外建设的；开发者也需要多理解一组概念。我们判断，这笔成本比日后在一个库里拆出三套流程要低。

Memory：私有的、带概率的任务连续性

Memory 产生于用户与 Agent 的对话，以及 Agent 执行任务的过程。它回答"之前发生了什么、现在走到哪一步、当时为什么这样选"，内容包括任务状态、关键决策和执行经验。

我们给 Memory 定了两个基本属性：私有，和概率性。它属于这个用户和这个 Agent，默认只在单个 Agent 内召回，必须具备隐私性。它又是经验，可能只在当时的条件下成立，不能直接当作稳定事实使用。

这两个属性决定了不少实现细节。写入时，服务端会从对话中提炼原子事实，再把事实组织到实体和结构化图谱上。

Memory 的不稳定性要靠后台治理来抵消。我们每晚对记忆做一次自动整理，合并重复内容、更新属性，控制台上也可以手动"立即整理"；去重、冲突处理和衰减是三种基本机制；遗忘管理可以按自定义条件和召回频率自动遗忘。这些机制背后的判断是，记忆的数量和它的价值并不成正比。把每一轮对话摘要都存成长期记忆，召回时更容易带进已经被推翻的前提。我们建议 Memory 优先保留会改变后续行为的状态，并且保证它能被审计、修改和删除，memory list、memory update、memory delete 就是为这件事准备的。需要调整"记什么、不记什么"时，可以用 memory rule set 设定记忆规则。

Knowledge：可以共享，所以需要有人负责

Knowledge 是事实、规则、领域知识以及经过验证的经验，回答"组织目前认可什么"。它可以私有，也可以共享；共享时可以分发给团队中的其他 Agent，跨 Agent 调用。

我们为 Knowledge 设计了两条进入路径。第一条来自企业的原始输入。企业里有大量已经验证过的文档，比如在钉钉或飞书上维护多年的资料，可以通过同步或上传直接进入知识库。第二条来自 Memory 的提炼，也就是记忆晋升：创建晋升任务，由 AI 生成文档，再由人评审，结果可以是通过、驳回或编辑后通过。

在第二条路径上，我们做了一个偏保守的选择：Memory 不会因为被反复提到就自动成为 Knowledge。系统会识别高价值记忆并推荐晋升，是否纳入团队知识，由人来判断。我们把这条原则概括为"记忆默认私有，知识审核共享"。晋升设置里有质量门槛，质量分达到阈值的内容可以自动入库，阈值由团队自己设定。我们的建议是，在团队对 AI 生成文档的质量有把握之前，先保持人工评审，等积累了一批评审记录、知道哪些内容几乎总被通过，再考虑放开自动入库。

内容进入 Knowledge 之后，需要来源和版本。两条规则冲突时，简单保留发布时间更晚的那一条并不可靠，业务范围、作者权限和适用对象都会影响该采用哪一条。所以入库评审里不做自动覆盖：AI 按逻辑性、噪音比、矛盾度给出多维评分，也可以对低质量文档做智能重写，入库还是驳回由人决定；冲突内容通过 kb review resolve-conflicts 处理。我们为知识设定的生命周期分为四段：多源发现后验证入库；高频引用后置信增强；衰减后降级保留、停止推送；被更新或取代时经过冲突审核，旧版可以追溯。

Skill：直接关系到行动，门槛应当更高

Skill 描述执行步骤、适用条件、工具配置和任务方法。它比说明文档更靠近行动：什么情况下触发，按什么顺序调用工具，遇到什么条件应当停下或转交给人。Agent 执行任务时，经验来自 Memory，对业务的理解来自 Knowledge，执行过程本身形成的做事方法就是 Skill，并且会随着执行次数增加而更新。

Skill 最容易被误做成"成功对话的复刻"。一次执行成功，可能依赖当时的数据、权限，或者某次偶然的工具返回。把执行轨迹直接发布成 Skill，等于把偶然条件固化下来。我们的做法是结合知识与成功路径生成 Skill 候选版本，候选经过评估后才成为正式版本。CLI 上对应的是一组命令：skill validate 检查结构，不执行其中的脚本；skill evaluate 读取一份证据文件做评估；skill status 查看当前状态；发现问题时用 skill rollback 回到旧版本，回滚需要给出当前预期版本，避免在并发修改时回错；skill disable 停用一个 Skill，同时保留它的历史。

我们对 Skill 的评审强度要求高于普通知识。知识文本有错，通常影响一次回答；执行方法有错，会在每一次调用时重复出现。

Skill 和 Knowledge 一样，是多个 Agent 可以共用的部分。同一个人在 Qoder、Claude Code、Codex 之间切换时，私有记忆默认留在各自的 Agent 里，团队的知识库和已经发布的 Skill 则可以共同使用。Agent 通过 skill list、skill search 找到可用的 Skill，再用 skill load 按需加载，不必在每个任务开始时把所有方法都塞进上下文。这也是我们没有把 Skill 写成长篇系统提示词的原因，方法越多，一次性全部注入的代价就越高。

三类资产怎样流转

三类资产之间会流动。任务中的 Memory 经过提炼和评审，可以成为 Knowledge；多次执行中稳定下来的方法，可以整理成 Skill 候选；Skill 的执行反馈又会形成新的 Memory，进入下一轮评估。我们用 Context Growth Loop 描述这条生命周期，它包含五个环节：记录、组织、召回与组合、执行沉淀、评估演进。其中有一条约束贯穿始终：执行结果先成为候选，评估之后才会更新资产或生成 Skill 候选版本，未经评估的结果不会直接变成正式资产。

流动的前提是先划分清楚。我们在设计时要求每类资产各自定义下面四项属性：

可见范围在产品里对应的是工作空间授权和知识库级权限：知识库可以按成员和用户组分别授予 Read、Write、Control 权限。私有 Memory 和共享 Knowledge 不共用一套权限设置，这是我们坚持把它们分成两类资产的主要原因之一。

三类资产如何进入同一次任务

分类之后，三类资产在一次任务里仍然要被组合使用。通过一键接入或 CLI 接入的 Agent 会安装 Hooks：每次用户提交 prompt 时，系统用这条 prompt 作为查询自动召回相关记忆，以 <recalled-memories> 的形式注入上下文，有时还会附上 <available-knowledge-bases>，告诉 Agent 当前可以查询哪些知识库。Agent 需要更多事实时，再调用 kb search 或带 --knowledge 的联合检索取回知识；需要执行方法时，按需加载对应的 Skill。本轮产生的新事实，再由 Hooks 写回记忆。

这里有两处细节和分类直接相关。包含知识库上传的那一轮对话会跳过记忆提炼，为的是防止文档原文被当作对话内容提炼进私有记忆，造成同一段内容在 Memory 和 Knowledge 里各存一份、来源却不一致。另一处在接入方式上：通过 MCP 接入的 Agent 只获得工具，没有 Hooks，召回和写入的时机要由 Agent 自己决定。对于希望记忆自动积累的场景，我们更推荐一键接入或 CLI；只想按需查询知识库的场景，MCP 已经够用。

两个难以归类的情况

一份操作手册算哪一类？ 操作手册里往往同时有产品事实、业务规则和操作步骤，把整份文件标成 Knowledge 或 Skill 都不准确。我们推荐的处理方式是保留原始文件，同时解析出可引用的知识单元，再把其中的可执行步骤整理为带适用条件的 Skill 候选。我们的知识单元本身就由两部分组成：按 chunk 组织的图谱内容，以及存放在对象存储里的原始文档，两者通过来源关联。Agent 先通过实体找到相关内容，需要核对时再下钻到原文，这样拆分之后也不会和原文各自漂移。

不过，如果手册很短、几乎不更新、也没有自动执行的需求，拆分只会增加维护负担。分类是为权限、检索和执行服务的，不必为了概念整齐制造额外工作。

用户纠正了一条共享知识，该记在哪里？ 这条修正既是这位用户的私有状态，又暴露了组织知识里的一处错误。我们的建议是两边都处理：Memory 里保留修正本身和发生的场景，知识侧通过晋升或评审流程形成一条待审核的修订。系统不会因为一条私有记忆就改动共享知识，这一点和"冲突不会自动覆盖"是同一个设计原则。由此带来的问题是同一件事有两处记录，修订被驳回、或者用户撤回了自己的修正时，两边需要一起处理。这件事由知识库的负责人来跟进比较合适，我们建议在规划权限模型时就把这个人定下来。

开始划分时的几条建议

如果团队准备把现有的 Agent 上下文整理进这三类资产，我们建议按下面的方式起步。

先盘点。把当前 Agent 用到的上下文逐项列出来：系统提示词里写死的规则、各个 Agent 自己维护的文档索引、对话中反复交代的偏好、团队约定的操作步骤。每一项都问一下：它属于谁，谁对它的正确性负责，用错了会造成什么影响。答案基本就决定了它属于哪一类。

Knowledge 从存量可信文档开始，已经被团队认可的制度和规范，可以直接上传或同步进知识库。Skill 则从执行路径固定、出错容易发现的任务开始，候选版本先过评估，再考虑扩大范围。

Memory 先用默认规则跑一段时间。观察 memory list 里实际记下了什么，再用记忆规则调整。召回阈值默认是 0.4，是否合适要用自己的任务去试。