上个月组里评审 Agent 实施方案，我讲完接入和检索，负责架构的同事只问了一个问题：Agent 每次干完活都往库里写东西，写进去的内容谁来负责？他担心的情形很具体。一个 Agent 某次绕开了正常流程把事办成了，这条路径被记下来，下个月另一个 Agent 照着走，没人知道它是从哪来的。我当时没答好，只说"可以加人工审核"，但审核放在哪一步、审什么、审不过来怎么办，我自己也没想清楚。

所以这次云栖，我在"为 Agent 重塑数据服务"那个分论坛坐了一下午，主要是冲着王颜培讲 Context Growth Loop 那一段去的。听之前我对这类闭环图有成见：几只箭头首尾相连，好像系统只要跑起来就会自己变好。让人睡不着觉的，恰恰是箭头从"执行"指回"资产"的那一段。

现场的五个问题

讲者没有一上来就放那张环形图，先讲了企业里用 Agent 的几个能力缺口：数据变化之后怎么持续接进来，语义怎么重新组织，Agent 这次犯了错，下一次能不能用上这次的教训，不必重新教一遍；还有进了企业之后的权限、审计和监控。第三条我听得最认真，它说的正是"写回来"这件事的价值，也是风险的来源。

随后他把 Agent Context 的核心机制归成五个朴素的问题：数据怎么记录，怎么组织，Agent 召回时怎样把语义相关的内容组织好再返回，执行完成后怎么沉淀，沉淀之后又怎样让经验持续进化。对应到图上，就是记录、组织、召回与组合、执行沉淀、评估演进。

我把这五个环节按自己的顾虑重新排了一下。记录和组织关系到"进来的东西有没有来路"，召回与组合关系到"拿出去的是不是该拿的"，执行沉淀和评估演进关系到架构同事那个问题，"写回来的东西会不会直接变成规则"。

进来的东西有没有来路

记录环节覆盖的来源很杂：数据库、数仓、业务系统、协作平台、文档、图片和音视频，还有 Agent 自己的执行反馈。企业数据通过连接器进入 Agent Context，数据库类走授权访问，不需要搬数据；钉钉、飞书文档可以配一次性同步任务批量拉，也可以开增量同步，监听文件变化后持续更新。同步时保留来源、作者、时间、权限和版本。

这几个字段比"能接多少种数据源"更让我在意。一条内容以后能不能被用、出了争议找谁，全靠它们。我们之前自己做的知识库就是只存了正文，半年后没人说得清某条规则是谁写的、还算不算数。

记录还要分清存量初始化和持续变化。新增要进来，修改要产生能识别的新版本，删除不能再被召回，权限变化要反映到可见范围。只做一次导入的话，后面几个环节拿到的都是旧数据。

组织环节讲的是怎么把原始材料变成可判断的单元。内部有多条解析管线，覆盖 txt、Markdown、PDF、PPT、Excel，讲者特意补了一句，音频视频也支持，只是 PPT 上没写。解析之后和模型配合建知识图谱，每个知识库可以一键开启本体抽取，配置本体约束规则，得到他们称为"增强知识图谱"的结构。产出的知识单元包含两部分：按 chunk 切分的图谱内容，以及存在 OSS 里的原始文档。

入库时还有两个开关让我记了笔记。一个是"重写"，由模型把结构混乱的文档改写得更清楚；另一个是按逻辑性、噪音比、矛盾度的多维评分，由人决定入库还是驳回。解析解决结构问题，评审才解决可信问题。原文本身含糊，切得再细也只是更细的含糊。本体也一样，领域本体设计错了，关系建得越丰富，误导的范围可能越大。所以组织环节同样要有一道检查，查的是结构；后面评估演进查的是内容。

拿出去的是不是该拿的

召回与组合由 Context Engine 负责。底下组合了向量检索、全文检索和图关联查询，对 Agent 只暴露一个 search 入口。语义近似适合表达不同但含义相近的内容，全文检索适合名称、编号和明确的关键词，图关联用来沿实体和关系找上下游。

找出候选之后还要组合。任务意图、用户私有的 Memory、共享的 Knowledge、可用的 Skill 和 Token 预算一起决定最终的上下文包。我关心的是两件事：权限过滤要在模型看到内容之前做完；版本冲突不能交给模型随便挑一个。讲者提到后台任务会处理记忆冲突，知识层面的更新和取代走冲突审核，旧版本保留可追溯。展区材料里也有一句我抄下来的话：资产更新遵循治理规则，不代表冲突会自动覆盖。

讲多 Agent 共享那个场景时，PPT 备注里还有一句对我很有用：共享不等于加载全部历史或公开全部记忆，需要匹配项目、版本、环境与访问权限。我们组的数据变更规则只对少数几个人开放，测试环境和生产环境的操作约束也不一样。如果召回只看语义相关，一个在测试环境里总结出的"可以直接跑"的经验，很可能被注入到一个生产环境的任务里。共享范围按项目、版本、环境切开，比按"相关不相关"切开更接近我们的实际需要。

写回来的东西会不会直接变成规则

这是我去听的主要原因，也是被说服得最多的一段。

执行沉淀环节，讲者说得很克制。它接收的是外部 Agent 或控制台内置助手的执行过程与结果，任务本身不一定由引擎执行。常见的连接方式是在任务前后各挂一个钩子：任务开始前，在授权范围内检索相关记忆并注入；对话结束后，由服务端提炼并保存，同时带上对应的身份和权限范围。业务 Agent 负责流程编排、专业判断和执行，Agent Context 负责 Memory、Knowledge、Skill 的管理、检索、共享与演进。职责这样分开，上下文服务不必假装自己做了业务判断，执行系统也不用各自维护一套没法共享和治理的记忆。

评估演进环节有一道闸，这是关键。PPT 那一页的备注里有一句话，我回来翻材料时又确认了一遍：Context Growth Loop 把上下文供给、Agent 使用与经验写入、资产评估演进关联起来，并不表示执行结果未经评估自动成为正式资产。具体到机制上有这样几条：

• 执行产生的内容先进入 Memory 或候选区，记忆默认私有，只在单个 Agent 内召回；
• 系统会识别高价值记忆并推荐晋升，提炼成候选，由人判断是否纳入团队知识，通过之后才全局共享、跨 Agent 调用；
• 执行方法先生成 Skill 候选版本，评估后才投入使用，不会自动发布。

听到这里我想起架构同事举的例子。某次任务因为上游接口短暂异常，Agent 绕过常规步骤仍然完成了目标。如果系统只按"任务成功"打分，这条绕行路径很可能被固化成 Skill；接口恢复之后，它反而增加成本，甚至越过某个控制点。结果指标一样，过程质量完全不同。有了"先候选、再评估"这一层，这条路径最多停留在某个 Agent 的私有记忆里，或者作为一个待评估的候选摆在评审页面上，要成为团队规则，得有人看过、点过通过。

风险没有消失，但对我们的评审会来说，这已经能回答"谁负责"：点通过的那个人，有记录可查。

评估看什么，讲者没有给统一标准，我自己列了几项：内容是否新鲜，引用是否指向正确来源，权限是否匹配，执行方法是否可重复，新版本和已有资产是否冲突。后台还会根据实际使用情况判断过期、替代和适用性，会记录每个知识片段的召回次数、记忆的冷热，仍然有效的修订后继续用，失效或被替代的归档并保留追溯。

评估的结论还应该反过来作用于前面的环节。某类候选总被驳回，说明记录或提炼的规则有问题，应该回头调记忆规则，少记这一类；某些知识长期没被召回，要么是内容本身没用，要么是组织和召回方式让它很难被找到，两种情况的处理办法完全不同。哪些指标设硬门槛，取决于业务风险，不同场景不宜强行共用一套标准。

回去后在控制台上看到的

回公司第二天，我用组里的试用工作空间把自己常用的 Agent 接上，没急着灌数据，先把 Agent Context 控制台上和资产相关的几个页面挨个点了一遍，看看会上讲的那道闸在产品里长什么样。

记忆页面能看到当前工作空间里的记忆条目，有每晚自动整理的说明，也有一个"立即整理"按钮，整理会合并重复、更新属性。遗忘管理可以按自定义条件和召回频率设置。

记忆晋升页面对应的是"推荐晋升、人工决定"那一步。流程是创建晋升任务，AI 生成文档，人工评审时可以通过、驳回或编辑。AI 生成的文档里如果有它自己拿不准的地方，会列成疑点，需要先处理掉疑点再决定通过与否，命令行里对应 resolve-doubts、 approve、 reject。这个"疑点"设计比我预想的细，它至少让评审的人知道该重点看哪几句。命令行里整组子命令都挂在 memory promotion 下：

ctxdb memory promotion listctxdb memory promotion settings get

settings 里有一项是质量分达到阈值后自动入库。这个阈值设多少，帮助文档没有替我决定，我目前的想法是试点阶段先设得很高，让几乎所有候选都走人工，等看过一批真实候选之后再往下调。

知识评审页面能看到逻辑性、噪音比、矛盾度这几项评分，可以让它智能重写，入库或驳回由人决定。冲突不会自动覆盖，有单独的处理入口，命令行是 ctxdb kb review list 和 kb review resolve-conflicts。这里碰到一个限制：文档评审和晋升目前只支持 txt、md、pdf、doc、docx。我们组有不少规范写在 Excel 和 PPT 里，这部分要么先转成支持的格式，要么只能直接入库、跳过评审，后者恰好是我想避免的。

Skill 页面能看到"候选版本"的概念， ctxdb skill status 可以查当前状态。这和会上说的 Skill 先生成候选、评估后再用是对得上的。帮助文档里还列了 skill rollback 和 skill disable，回滚需要给出当前预期的版本，停用会保留历史。这两个命令我还没机会用，但它们的存在让我对"Skill 会持续更新"这件事放心了一些：更新错了能退回去，退回去的时候知道自己退的是哪一版。

什么场景用得上这一套

回来后我也问了自己一句：我们组里所有用 Agent 的地方，是不是都需要这么一整套？答案是否定的。低频、稳定、只读的问答场景，比如只回答内部工具使用说明的那个机器人，维护一条完整的增长链路太重了。把来源、版本和更新流程做好，比急着沉淀 Skill 更有效。

反过来，任务跨轮持续、多人共享、规则频繁变化、执行结果会被反复复用的场景，缺了评估演进就会很快攒下上下文债务。我们的发布和数据变更流程四条都占，这也是我想先在这里试点的原因。

还没想通的地方

我对这张闭环图的保留意见集中在评估演进这一环，而且回来看过控制台之后更具体了。

记录、组织、召回都有明确的工程对象，可以靠机器扩容。评估却依赖业务负责人持续投入审核时间。候选的产生速度跟着 Agent 的执行频率走，审核速度跟着人走。两边一旦失衡，候选区会先堆起来，接下来要么审核标准被悄悄放低，要么大量候选长期停在原地，失去时效。一个候选在评审页面上放了三周，它所依据的规则这期间可能已经改过一版，评审的人看到的是一份基于旧前提的总结，点了通过就等于引入了过期内容。整套流程实际能转多快，瓶颈很可能在这道人工闸门的容量上。

自动入库的阈值是缓解手段，但它把问题换成了另一个：阈值调低，闸门就变宽；调高，人就要多看。这个取舍没有通用答案，取决于业务风险。我们组里，涉及数据变更的规则我倾向于永远走人工，纯说明性的内容可以考虑放宽。

还有一个组织上的问题。会上讲的评审主体是"业务负责人或评审小组"，我们组目前没有这样的人，谁来看候选、多久看一次、看不过来时怎么办，需要在接入之前就定下来。否则闸门在产品里是存在的，在组织里却是空的。

下一步

我准备拿一个小团队做两周试点。试点前先把组里现有的内容按三类资产分一遍：个人工作习惯留在各自的 Memory 里，不晋升；已经评审过的发布规范和变更制度直接作为 Knowledge 入库；几套固定的排障步骤先手写成 Skill，再看 Agent 执行后会不会产生新的候选版本，候选和手写版本差在哪里。

试点期间自动入库的阈值保持高位，每周固定一个半小时看晋升候选和知识评审，由我和那位提问的架构同事一起看。我会记下每周新增多少候选、实际处理了多少、驳回的理由分几类，看人工闸门的容量和候选的产生速度大致是什么关系。Excel 和 PPT 里的规范先挑最常用的几份转成 docx 走评审，其余的暂时不进共享知识。

两周后，我想拿一张表去回答架构同事的那个问题：哪类内容可以自动入库，哪类必须人看，由谁看。现在这张表我还填不出来。