本体与记忆让 Coding Agent 越用越懂项目

From Coding to Ontology: 本体, Memory 与 Loop RSI的研发实践

一个 Agent 怎样才能逐渐熟悉一个项目? 通用模型提供了代码和推理能力, 但具体项目里的概念, 约定和历史, 还需要从团队的材料与实际工作中获得。 拿到这些信息之后, Agent 还要判断它们在什么条件下成立, 应该怎样影响当前任务。

这涉及两个不同的问题。 一个是如何表达项目知识, 让模型理解我们在讨论什么。 另一个是如何利用执行反馈, 让后续任务受益。 本体和 RSI 分别从这两个方向提供了思路, Memory 则承担知识保存与复用的工作。

我们先从这些基本概念讲起, 再看相关研究如何把它们联系起来, 最后展开我们在内部研发 、Loop 中的实践。 我们关心的落点很具体: 能不能让 Agent 少花一些重新理解项目的时间, 少犯一些团队已经弄明白的错误。

1. AI 时代的本体, 到底是什么

1.1 从词的含义, 到一个领域的共同模型

这里说的本体, 即 Ontology, 是知识工程中的概念, 不展开哲学里关于「存在」的讨论。 可以先这样理解: 本体把一个领域中有哪些概念, 概念之间是什么关系, 有哪些成立条件, 明确表达成一套可以共享的模型。

「共享」很重要。 一个人心里知道什么叫订单完成, 不代表仓储系统, 财务系统和客服使用同一种含义。 同样, 模型知道中文里的「完成」是什么意思, 不等于知道某家公司以支付, 出库还是签收作为完成标准。 本体要把这种领域内的约定表达出来。

用一个简化的订单系统来说明。 「订单」和「发货单」是概念或类型; 某一笔订单是具体对象; 「订单对应发货单」是一种关系; 金额, 币种和创建时间是属性。 如果业务允许拆单, 一个订单就可能对应多张发货单。 如果业务规定所有有效发货单签收后订单才完成, 这个条件也需要明确。

这样一来, 「一张发货单已经签收」和「整个订单已经完成」就不能随意互换。 区别来自对象和关系, 不来自两句话看起来有多相似。 拆单规则若随业务版本变化, 条件还要带上适用范围。

更严格地说, 本体要让概念和关系具有明确的语义。 哪些对象属于同一类, 哪种关系可以连接哪些对象, 什么条件下能够推出某个结论, 都应有一致解释。 W3C 的 OWL 2 提供了类, 属性, 个体及逻辑公理的表达方式。 这说明本体并不是大模型出现后才发明的东西。

工程实践未必一开始就使用完整的形式化语言。 有版本的概念定义, 关系类型, 数据映射和规则文件, 也可以逐步承担这些职责。 关键在于含义能被核对, 模型不必每次从散落的材料里临时猜测。

这里还要分开两件事: 表达规则, 与确认实际数据满足规则。 本体可以表达订单和发货单的关系, 但当前订单是否满足完成条件, 还需要查询数据并检查。 SHACL 处理图数据的约束验证, 业务系统也可以通过普通程序和测试完成检查。 本体不会因为写下了一条规则, 就保证现实已经遵守它。

1.2 它与 Schema, 知识图谱和 RAG 有什么不同

这些概念经常一起出现, 但关注点不同。 数据库 Schema 主要描述数据怎样组织, 知识图谱描述实体和关联, RAG(检索增强生成) 把检索内容提供给模型, 本体则强调对象与关系的共同含义。 它们可以组合, 也可能在具体系统中有重叠。

仍以订单为例, 一张表可以有 status 字段, 但字段存在不代表我们已经知道它属于订单还是发货单, 哪些状态是中间态, 什么时候能据此认定业务完成。 如果这些知识只存在于某位工程师的记忆里, Agent 看到表结构之后仍然要继续寻找。

这张表并不意味着 RAG 只能搜索文本, 或 Schema 不能表达语义。 一个好的 RAG 系统也可以利用图谱, 规则和结构化过滤。 区别在于, 增加检索能力与补齐领域含义是两项不同的工作。 检索找到了一份政策, 还需要判断它是否适用于当前车型, 年款, 地区和时间。

本体与知识图谱也不是互斥的两种技术。 图谱可以按照本体组织事实, 本体本身也可以用图表示。 但如果一张图所有边都叫「相关」, 模型仍然不知道两端究竟是实现关系, 依赖关系, 还是一方违反了另一方的约束。 连接更多节点与表达更准确的关系, 不是同一个目标。

我们真正需要补的是: 找到一段知识之后, 还能判断它在说哪个对象, 在什么条件下成立, 能支持哪一步推断。 存储在图数据库, 关系表还是文件里, 是之后的实现选择。

1.3 为什么 Palantir 和 FDE 会反复遇到这个问题

Palantir 的 Ontology 系统 把 data, logic, action 和 security 联系起来。 它不只组织可查询的数据, 还将业务对象与逻辑, 操作和权限结合。 模型或应用通过业务对象理解系统, 也通过受控的操作影响系统。

例如, 「迁移一个实例」涉及实例与节点的关系, 目标区域限制, 迁移状态, 可执行的动作和操作权限。 仅知道实例对应哪张表, 还不足以完成迁移。 对象模型需要与实际流程连接, 执行后还要核对结果。 动作和权限属于这类产品系统的扩展, 不应直接当成所有经典本体的定义。

Palantir 的建模建议 强调从现实领域出发, 再映射源数据。 这一点对研发很有启发。 业务上的同一个对象可能分布在多个系统, 一个数据表也可能混合多个业务概念。 直接把表搬成图上的节点, 并不会自动补出这些含义。

由此也就容易理解 FDE, 即 Forward Deployed Engineer, 为什么会关注本体。 这类工程师深入具体业务现场, 需要把用户的目标, 既有系统和交付标准连接起来。 用户说「这个流程成功了」, 工程师得继续确认: 哪个对象成功, 哪个阶段成功, 是受理成功还是业务结果已经生效?

我们的理解是, Agent 越接近实际操作, 这类工作就越难省略。 含义不一致, 会继续传到工具参数, 代码实现和验收断言里。 本体提供了一种把业务澄清沉淀为共享模型的方法, 不必每个功能都在自己的 Prompt 里重新解释一遍。

所以, 「AI 时代的本体」并没有改变本体的基本含义。 变化在于它开始更直接地参与 Agent 的检索, 判断和行动, 并需要随业务与执行反馈持续维护。 这也引出了下一个问题: 这些理解能否在任务之间积累, 甚至让系统改善自己获得理解的方法?

2. 从 Loop 和 Memory, 理解 RSI

2.1 任务反复执行, 不等于系统已经学会了

先解释这里的 Agent 和 Loop。 Agent 可以利用模型作判断, 调用工具执行动作, 再根据环境反馈继续推进。 Loop 就是这段「行动, 观察, 调整」的循环。 对 coding 任务而言, 写代码, 执行测试, 读取失败, 修改后重测, 已经构成一个执行 Loop。

这个循环能把当前任务做得更好, 但任务结束后, 下一轮未必有所不同。 如果新会话再次从相同信息出发, 它可能重新搜索同一条链路, 再误解一次相同的业务约定。 当前任务的完成与跨任务学习, 需要分别设计。

Memory 的作用是保存可以跨轮次使用的信息。 保存的内容可以是发生过的事件, 已确认的知识, 也可以是处理任务的方法。 模型权重保持不变, Agent 系统仍然可能因为获得了更合适的知识与工具而表现更好。

Reflexion 给出了利用语言反馈的一个例子。 Agent 根据任务反馈形成反思, 将其保存在情节记忆中, 指导后续尝试。 Agent Workflow Memory 进一步关注可复用工作流, 从历史经历中归纳操作方法, 再选择性提供给后续任务。 前者说明反馈可以成为记忆, 后者说明记忆也可以是「怎样做」。

但保存不等于学会, 复用也不保证改进。 一条错误经验被更稳定地召回, 反而可能让错误重复得更稳定。 因此我们把 Memory 称为自改进的方法和燃料时, 还要补上后半句: 经验需要改变后续行为, 并通过后续结果检验它是否有用。

反馈也不能只留下「成功」或「失败」。 相同的失败可能来自代码缺陷, 环境异常, 观察器错误或业务概念混淆。 对这些情况使用同一种反思模板, 很容易形成宽泛但不能指导行动的建议。 有价值的反馈应保留发生条件, 判断依据和被排除的解释。

2.2 RSI 中的「递归」, 究竟体现在哪里

RSI 是 Recursive Self-Improvement, 即递归自我改进。 自改进意味着系统改变自身的某些部分, 改善后续表现; 递归性进一步指向, 产生改进的过程也能够成为改进对象。 讨论时最好直接问: 改了什么, 谁根据什么反馈来改, 改完怎样验证?

我们可以按改动对象区分三个层次。 这是帮助分析工程系统的视角, 不代表所有论文采用统一分级。

Darwin Gödel Machine 研究了迭代修改 Agent 自身代码的路线。 系统维护候选 Agent, 通过编码评测筛选改动。 它改变的是解题系统的工具和工作机制, 而不只是某道题的代码。 这与普通的「测试失败就改补丁」有明显区别。

预印本 Skill∞ 则把递归关系表达得更直接。 它用 task skill 保存解决任务的方法, 用 meta-skill 描述如何优化这些 skill。 meta agent 根据执行轨迹诊断问题, 提出候选, 请求独立审查并分配搜索预算。 随后, 同一种优化过程还可以作用于 meta-skill 自身。

因此, 一个版本可能改进「如何定位 Bug」, 另一个版本则改进「如何分析定位失败, 并生成更好的定位方法」。 后者是否有效, 要看它能否在给定预算下产出更好的 task skill。 Skill∞ 将评分放在自改进范围之外, 候选还需要经过独立审查。 允许改进方法, 与允许改低评分标准, 是两件事。

这些研究让 RSI 有了可以实验的具体对象, 但都在限定任务, 预算和验证条件下工作。 我们在企业研发中可以从外部记忆, 工具和流程开始探索, 无需先改基础模型权重; 同时, 一次正向实验也不足以说明系统能够持续, 无限地变强。

到这里, 本体和 RSI 的分工已经比较清楚: 本体帮助系统表达与使用领域知识, RSI 关注系统怎样根据反馈改进自己。 两者不是互相成立的前提, 但当主要卡点来自概念理解时, 本体就成为一个值得改进的对象。

3. 本体与 RSI 可以怎样结合

3.1 EvoOntology: 让本体根据 Agent 的使用反馈演进

一个直接相关的研究是预印本 EvoOntology: A Self-Evolving Ontology Layer for Data Agents。 它讨论的场景是数据分析和 text-to-SQL, 即将自然语言问题转成 SQL 查询。 Agent 面对数据库或文件时, 经常反复确认字段含义, 表间关系和过滤条件。 即使某次已经查明白, 后续任务仍可能重新发现一遍。

论文将可演进的本体系统拆成 Content, Schema 和 Tool 三部分。 Content 保存领域概念, 到数据字段的映射, 使用约束和支撑证据; Schema 规定这些对象及关系怎样表达; Tool 决定 Agent 怎样找到和展开这些信息。 这里的三部分与后文我们的三层项目图谱划分不同, 不能按名字直接对应。

它提供了两类访问: browse 找到语义上相关的对象, resolve 取得所需对象及关联记录。 会话开始时只提供简要说明, 具体知识由 Agent 按需查询。 本体因此既是可维护的知识, 也是 Agent 实际会使用的接口。

论文附录中的一个卡牌查询案例很直观。 任务要找到在某种游戏赛制下被禁用的卡牌。 初始本体已经知道卡牌与合法性记录的关联, 也知道状态存放在 legalities。status, 但没有明确状态相对于赛制成立。 Agent 能找到字段, 却还要自己重新确认如何使用。

演进过程把问题定位为语义内容缺失, 增加状态值的含义, 对应字段, 观测证据及约束。 要找目标赛制的禁用卡牌, 需要同时满足 legalities。status = 'Banned' 与 legalities。format = target_format。 只检查「禁用」会丢掉适用范围。 这次改动补充的是内容, 不需要修改查询工具或整个 Schema。

更重要的是, 论文没有把每次失败都处理成「再加一段提示词」。 它先分析执行轨迹, 判断限制来自内容缺失, 工具暴露不合适, 还是当前 Schema 无法表达所需知识。 每个候选针对其中一个层面作局部修改, 然后让候选与原版本在相同模型, 验证集和交互预算下比较。 改善达到设定幅度才保留, 未通过的修改记录下来, 不直接部署。

这项设计同时区分用于构建和选择候选的材料, 与最终测试任务。 本体在最终测试前冻结, 不能一边看到测试答案, 一边补充语义后再报告同一批成绩。 完整查询仍由工具执行并验证, 本体只提供有依据的解释与使用条件。

这个方法提供的关键思路是: 本体既可以帮助 Agent 理解任务, 也可以因 Agent 的实际使用结果而被修订。 但修订本体与递归改进修订机制仍有区别。 EvoOntology 直接研究了前者, Skill∞ 则提供了理解后者的参照。 数据任务中的结果也需要重新经过实验, 才能迁移为研发 Loop 的结论。

3.2 我们的想法: 让经验有归属, 让反馈找到具体改进对象

把前面的研究放在一起, 可以看到一条逐渐具体的路线。 Reflexion 关注如何从反馈留下经验, Agent Workflow Memory 关注如何形成可复用方法, EvoOntology 关注语义知识及其访问方式怎样演进, Skill 进一步把优化过程本身变成可修改对象。

对于我们, 这里最值得借鉴的地方是, 不要把所有失败统一归为「模型还不够聪明」或「Memory 还不够多」。 同样表现为定位失败, 背后可能有完全不同的原因: 代码关系没找到, 业务含义理解错, 旧经验的条件不匹配, 或者已经知道约束却没有执行相应检查。

本体可以让这些反馈有更明确的归属。 一次失败不只关联一个会话, 还可以关联到某个业务概念, 某条跨仓映射, 某个状态条件, 或者某项错误推断。 下一次优化就有了具体对象, 不必把整份记忆重写一遍。

比如, 把「请求受理」和「业务完成」混为一谈, 需要补充或拆分概念; 概念已经准确, 但搜索只返回相似旧案例, 需要调整索引或适用性过滤; 检索和解释都没有问题, 却仍省略数据面检查, 则要检查工作流程和验证工具。 这几种问题不能只靠增加同一句提醒来解决。

我们希望形成的关系是: Loop 提供行动与真实结果, Memory 保存经验及来源, 本体组织概念和经验的适用条件, 后续任务检验这些知识是否改变了行为。 如果还能据此改进抽取, 检索和使用策略, 就进一步进入学习机制的改进。

这里有一个容易忽略的代价。 语义组织会增加抽取和维护成本, 图关系也可能放大错误经验的影响。 所以, 本体与 RSI 的结合需要同时具备「能关联」和「能纠正」的能力。 系统应该能够收紧一条经验的适用范围, 拆开被误合并的概念, 或撤回不成立的结论, 而不是只能继续增加内容。

3.3 一个老工程师看到代码时, 脑中会出现什么

如果要确定值得提取哪些知识, 我们觉得可以从一个朴素的问题出发: 熟悉项目的工程师在看代码时, 除了知道函数调用谁, 还知道什么?

他可能不知道某个函数的精确行号, 但知道这段逻辑处在什么业务流程, 谁负责推进状态, 哪个消费者还依赖旧协议。 看见一个特殊分支, 会想起保留它的原因。 看见一个异常, 会知道先查哪项观察, 才能区分环境问题和真实缺陷。 他也知道哪些条件在流程变化时仍然必须成立, 这些条件就是我们后面说的业务不变量。

其中, 「知道自己还不知道什么」也很重要。 老工程师会区分当前实现, 已确认需求和个人猜测。 发现冲突时, 他会回到设计或找业务负责人确认。 我们希望提取的项目经验同样保留这种区别, 不把每句自信的解释都当作事实。

这个目标并不要求复制人的完整思维过程。 可以先外化那些反复影响定位方向, 改动范围和验证方式的知识线索。 本体提供共同概念, 历史案例提供经历, Skill 提供方法, 测试与运行结果负责验证。 接下来就是把这些角色放进我们的实际流程。

4. 我们的实践: 在研发 Loop 中组织三层项目知识

4.1 从设计完成, 到上线前测试的一轮 Loop

我们目前在做的实践是, 需求与设计完成之后, 从代码实现到上线前的测试, 由 Agent 承担这一段工作。 人确定目标, 设计和必要的业务取舍; Agent 理解需求, 实现改动, 执行验证, 遇到失败就定位和修复, 直到得到约定范围内的验收结果。

设计完成不代表所有细节都无歧义。 一轮开始时, Agent 需要把设计转成可以观察的验收条件, 说明对象, 范围, 输入, 预期状态和排除项。 发现业务冲突时仍需澄清, 不能靠猜测补齐。 当前范围也不自动包括生产发布或其他未授权动作。

图 1：研发 Loop 从已完成的设计推进到上线前验收, 异常按原因返回相关阶段, 结构依据当前内部研发流程整理。

在我们当前的云数据库研发路径中, 本地主要做编译和静态检查。 原生单测, 功能测试和受影响回归在集成环境运行, 必要时还要验证真实数据面的访问行为。 接口返回成功, 异步任务结束, 进程就绪和客户端可用, 分别需要与其含义匹配的证据。 当前路径主要覆盖后端与数据面, 不能外推为全部前端和所有产品类型均已自动验收。

图 1 的回路也不要求每次失败都从头重跑。 只修报告且输入未变, 未必需要重新部署; 测试观察器发生变化, 则需要重新验证受影响的判断。 如果写请求结果未知, 先恢复对原任务的观察, 避免重复执行已经发生的操作。

还有一项重要分工: Agent 负责语义理解, 规划, 实现和异常判断, 确定性工具负责推进已经确定的常规步骤。 构建, 部署, 等待和回执归集, 不必每一步都重新交给模型决定。 工具成功也不能替代业务验收。 Loop 要交付的是对应实际版本的验收证据, 而不只是模型的一句「完成了」。

这一执行过程同时产生了大量可学习的材料: 哪个概念曾经理解错, 哪项测试暴露了兼容问题, 哪次澄清改变了实现方向。 团队 Memory 负责让这些信息能进入下一轮, 而不是随当前会话结束而消失。

我们分析实际卡点时发现, 不少纠结和返工涉及业务概念: 模型能够读懂局部代码, 却没有把对象, 状态或字段的项目含义理解准确。 这是一项实践观察, 还没有量化为全部失败中的占比。 但它足以促使我们在已有 Memory 上进一步补充语义关系, 而不仅是保存更多原始对话。

4.2 四类记忆资产, 加上三层互索引图谱

我们已有的团队 Memory 包括四类资产。 Chat Memory 保存对话中的背景, 澄清与决定; Wiki 组织业务与架构知识; CodeGraph 提供代码结构和依赖; Skill 保存可复用的处理方法。 四类资产分别有自己的用途, 原始来源也应保留。

在这些资产之外, 我们已经构建了可以用于单仓和跨仓的三层关联图谱。 四类资产与三个层次描述的是两个维度: 前者侧重材料的形态与用途, 后者侧重不同知识之间怎样关联和访问。 它们不是七类平行资产, 也没有严格的一一对应关系。

第一层是工程事实。 它主要依靠工程手段建立函数, 类型, 字段, 接口及其使用者之间的关系, 类似 CodeGraph, 但还包含跨仓关联, 整体偏静态。 这一层帮助 Agent 知道定义在哪里, 谁使用它, 一个功能可能跨越哪些仓库。

从建设方法看, 跨仓关联需要通过 API, 消息或 Schema 等契约核对生产者与消费者, 不能仅凭同名符号连边。 对反射, 配置路由等动态行为, 静态图也可能无法确定实际路径, 需要用运行信息补充。 「代码中可能连接」与「这次实际执行经过」仍有区别。

第二层是项目语义。 它结合工程分析与 LLM, 提取功能职责, 业务概念, 定义之间的关系, 字段含义, 跨仓映射及相关约束, 同样支持仓内和跨仓。 相比第一层, 这一层更偏动态, 会随着新材料和理解修正而更新。

第一层可以告诉 Agent 一个字段从仓库 A 传到仓库 B, 第二层进一步解释两端分别是什么意思, 是否发生单位转换, 默认值是否相同, 哪些版本需要兼容。 因此, 语义层需要围绕工程位置提出可核对的解释。 LLM 生成的候选关系, 不能仅凭语言流畅就升级为项目事实。

第三层是错误与经验, 我们称为 bug_fixed。 它将历史 Bug 整理成经验, 挂到前两层的相关节点和关系上, 以渐进式披露的方式供 Agent 使用。 代码能够找到相关经验, 经验也能够反查涉及的代码和业务约定。

这里我们特别希望区分「发生过的一次事件」与「可以复用的经验」。 事件记录版本, 现象, 条件, 原因判断和修复; 经验提炼其揭示的风险及适用范围。 一次事件可能支持多条经验, 多个事件也可能共同支持一项约束。 故障表现位置, 根因位置和补丁位置也可能不同, 不宜压成一条没有说明的「关联代码」。

图 2：三层项目知识图谱以工程关系连接仓库, 以语义解释业务含义, 再挂接历史经验和证据, 结构依据团队的三层设计整理。

图 2 的双向箭头表示可以互相查询。 「代码实现某项约定」可以反查为「约定由哪些代码实现」, 但不代表语义关系本身对称。 同样, 图上关联到一个历史问题, 只说明值得核对, 不自动证明当前问题具有相同根因。

本体不需要再成为第四层。 它首先体现在第二层的概念与约束表达中, 也体现在跨层关系对实现, 经验和证据角色的区分中。 第一层提供工程锚点, 第三层提供历史反例, 两者都能帮助修订项目语义。 我们接下来的本体优化, 就是在已有结构上让这些含义和边界更加可靠。

4.3 让 Agent 自己沿关系找到需要的知识

三层互索引意味着, 模型可以从任何一层进入。 有明确符号时从工程层开始, 只有业务需求时先找概念, 面对故障现象时先检索经验。 进入之后, 再依据当前问题选择下一条关系, 不必固定执行「先读代码, 再读语义, 最后读历史」。

用一个简化的跨仓场景说明。 假设一项配置约定: 未传策略字段时使用默认配置, 显式传空列表时清空限制。 现在请求失败并重试后, 用户选择丢失了。 这个例子用于演示使用方法, 不对应后文定位试验中的具体题目。

从字段出发, 工程层可以引导 Agent 查看仓库 A 的请求解析, 跨仓消息契约, 仓库 B 的持久化与重试读取路径。 语义层进一步说明, 「未传」与「显式空」表达两种意图, 传递与重试都要保留这个区别。 历史经验若记录过适用条件相同的默认值覆盖问题, 就能提供一个优先检查的候选解释。

随后需要做的仍然是验证。 第一次请求保存的值是什么? 重试读到的值是什么? 如果保存时已经丢失区别, 应检查解析或持久化; 如果保存正确, 只有重试后改变, 才进一步检查默认值应用位置。 经验帮助缩小搜索, 当前代码和实际观察决定结论。

测试也可以沿着约束展开: 未传, 显式空和非空值分别如何处理, 重试前后是否保留意图, 两端协议版本不同时是否仍然兼容。 若当前故障与旧案例不同, 排除过程同样有价值。 我们需要留下什么条件不匹配, 哪项观察推翻了旧解释, 而不只是保存最后的补丁。

渐进式披露用来控制这段过程的信息量。 已有能力是按需展开经验; 我们希望进一步细化为, 首先提供关联理由, 风险摘要和适用范围, 然后展开触发条件与检查方法, 最后读取完整差异, 对话和运行证据。 披露深度与图谱层次是两个维度, 工程层和语义层也可以逐步展开。

关键前提必须跟摘要一起出现。 一条经验只适用于旧协议, 就不能把版本条件藏到最后一层。 权限和项目范围也应在检索入口受到约束, 跨仓可导航不意味着可以读取所有仓库。 图遍历还需要预算和停止条件, 找到足以支持或排除当前假设的材料后, 就应回到任务。

这让图谱有了多种具体用途。 规划时从功能定位影响面, 实现时核对跨仓契约, 测试时由约束与历史反例补充边界用例, 定位时沿症状寻找候选机制。 对熟悉项目这件事而言, 有用的导航不是替模型规定全部思考顺序, 而是让下一步查询有依据, 查询结果又能回到当前判断。

4.4 从代码, Bug 和对话中, 提取可以被纠正的经验

三层结构已经存在, 接下来更需要完善的是语义的提取与维护。 我们不想让同一个抽取 Prompt 把所有材料都压成几条类似的总结。 源码描述现在怎样运行, 设计表达期望行为, Bug 单记录异常及调查过程, 对话里则常有最终澄清和被否定的方案。

一个实际可推进的方法是, 先用工程分析定位符号与契约, 再让 LLM 围绕高频误判生成语义候选。 每条候选都带来源, 对象, 版本和适用条件, 再用设计, 实现, 测试或领域确认相互核对。 两个仓库都叫 Task, 不代表它们是同一个概念; 同一业务对象名称不同, 也不应自动拆成无关节点。

我们希望一张概念卡除了定义, 还包含易混淆对象, 状态作用域, 工程映射, 关键约束和验证入口。 一条经验则至少保留现象, 触发条件, 原因依据, 处理方式和不适用条件。 这里是进一步细化的数据设计方向, 不代表所有字段已经自动填齐。

内部复盘中有一个真实例子。 一个父实例已经完成删除, 逻辑拓扑表中仍保留记录, 早期判断将其视为脏数据。 后续核对发现, 父实例与子拓扑状态属于不同作用域, 逻辑记录也不能等同于物理进程, 因此撤回了原先「已证实删除缺陷」的定性。[^internal]

这个例子与前面卡牌案例有共同点: 字段和数据都找到了, 但对象或适用范围没有完整表达。 在删除场景里, 清理 helper 的安全检查即使通过, 也不能证明业务上应该清理。 反过来, 当前实现保留记录, 同样不足以证明所有版本都应该保留。 需要先核对删除契约, 再分别观察业务状态, 逻辑数据和物理资源。

对这样的经验, 下一步值得做的是沿关联追踪更正影响。 旧结论被替代后, 引用它的摘要, Skill 和测试假设应进入待复核状态。 原事件不必删除, 但不能继续以已确认规则指导新任务。 这需要版本化的陈述和依赖关系, 目前属于我们希望加强的能力。

另一次复盘还记录了「读过但没有落实」的问题。 共享管理端口的经验已经被读取, 后续观察器仍然按错误的一一对应关系作判断。 这提醒我们, 仅靠召回日志不能确定经验是否生效。 一条稳定约束最好能对应本轮的对象映射, 测试断言或动作前检查。

经验的使用, 应能追踪到它改变了哪项判断, 哪段实现或哪项验证。 比如共享端口经验应进入资源观察模型及相应用例, 请求受理与业务完成的区别应进入终态检查。 自然语言经验要变成强制检查时, 还需要确认契约来源, 审查断言, 不能让同一套错误假设同时生成实现和唯一的验收标准。

这项工作适合从小范围开始。 优先整理状态, 默认值, 资源身份和跨仓兼容等反复影响判断的概念。 对局部, 契约明确的修改, 普通代码搜索已经足够时, 就不必强制加载整个图谱。 本体维护的投入, 应由减少的误判和返工来证明。

5. 初步结果, 以及怎样检验后续改进

5.1 Bug 定位成功率从 58% 到 65%

在一项内部代码 Bug 定位试验中, 加入上述图谱能力后, Agent 的问题定位成功率从 58% 提升到 65%, 增加了 7 个百分点。这是我们目前得到的一个初步正向结果, 说明三层关联知识在这批定位任务上值得继续验证。

定位是完整 Loop 中的一项子任务。 找到问题之后, 补丁是否正确, 回归是否充分, 环境是否稳定, 都会继续影响最终交付。 因此这个结果尚不能换算成完整研发效率的提升, 也不能单独证明本体语义层贡献了全部增益。

我们需要进一步分开几种能力。 工程图是否让跨仓代码更容易找到? 语义解释是否减少了对象和条件误判? 历史经验是否提供了更好的诊断起点? 三层配合是否比任何单层都更有效? 这些问题需要在相同模型, 信息来源和预算下做分层对照。

比较图谱与普通 Memory 时, 信息来源尤其重要。 如果图谱组额外获得了历史工单, 而普通检索组只能读取代码, 结果可能反映的是信息增多, 不能完全归因于组织方式。 更合适的比较是给两组同样的材料, 观察关系与适用性表达是否带来额外收益。

bug_fixed 还对应两种不同的业务价值。 已知故障再次出现时找回旧解法, 可以减少重复劳动; 目标 Bug 从未进入图谱时, 用其他事件的经验完成定位, 则更能体现迁移能力。 两种结果应该分别报告。

评估未见问题时, 需要排除目标补丁, 后续回归测试, 重复工单和从这些材料抽出的间接关系。 只删除目标 Bug 标题不够, 语义层也可能保留答案线索。 时间切分和来源追踪既是实验要求, 也能帮助我们发现生产图谱中的过期知识。

5.2 从一次定位增益, 走向可验证的持续改进

接下来我们希望同时观察结果和过程。 结果包括定位成功率, 上线前验收完成率, 缺陷遗漏和人工介入; 过程则包括知识何时被找到, 条件是否匹配, 是否改变实现或测试, 以及哪里仍然重复返工。 过程证据帮助诊断, 后续任务的对照结果决定改进是否成立。

对于持续学习, 一个可行实验是按时间推进任务。 一组使用冻结版本的图谱, 另一组只吸收已经结束任务中形成并通过检查的经验。 两组在下一批未见任务上比较, 同时保留旧任务的回归检查。 如果新知识提高了一部分任务表现, 却让原先能完成的任务退化, 这同样必须计入结果。

更接近 RSI 的尝试, 则是把知识更新过程也纳入比较。 例如, 固定抽取策略与新抽取策略处理同一批历史材料, 分别生成候选图谱, 再在独立任务上检验。 改进对象可以是概念拆分规则, 跨仓映射核对方法, 经验适用性筛选或 Skill 生成流程。 不能只因为新策略生成了更多关系, 就认定它更好。

借鉴 EvoOntology, 我们倾向于让每次候选修改针对可解释的问题: 是语义缺失, 映射错误, 访问困难还是执行遗漏? 明确预计改变的行为, 再比较修改前后。 借鉴 Skill∞, 若修改的是学习策略, 就要检验它能否在多个任务中产生更有用的知识或方法, 而不仅是修好某一条经验。

沿用前面的空值场景, 这项尝试可以具体到三次变化。 第一次修好重试代码, 完成当前任务; 随后把空值与默认值的区别整理为有条件的经验, 改善以后相似任务的输入; 如果发现多类经验都遗漏适用条件, 再提出修改经验抽取策略, 要求新候选提供条件和反例依据。 最后一项是否有效, 要看它生成的经验能否帮助后续不同任务, 同时减少误用。 修改结果还可以反馈给下一次策略优化, 而不是只增加一条永远重复的提醒。

企业场景还需要外部边界。 知识可以修订, 业务目标与权限不能由学习过程自行放宽。 Agent 可以指出测试工具不可靠, 提议修正, 但不能通过删除失败用例获得更好的成绩。 高影响约束的发布, 版本切换和回退也应保留审查机制。

成本同样要计入。 语义抽取, 图谱维护和额外检查会消耗时间, 检索噪声还可能引入新的错误。 我们最终要比较用户等待的端到端时间, 模型与工具开销及维护投入, 而不能只看累计执行耗时或知识条目数。 当前三层图谱的定位收益, 与系统持续改善学习方法, 是两项需要分别取得证据的目标。

6. 结论: 让项目理解成为下一轮的起点

本体帮助我们明确业务对象, 关系和约束, 让经验有可核对的含义与适用范围。 Memory 保存这些知识以及它们的来源, Loop 提供行动与反馈, 自改进机制则利用后续结果判断什么应该保留, 修正或放弃。 当改进过程本身也能被检验和优化时, 才进一步体现出递归性。

我们当前的实践, 是在设计完成到上线前测试的研发 Loop 中引入团队 Memory, 并用工程事实, 项目语义和 bug_fixed 三层图谱关联仓内与跨仓知识。 这让 Agent 可以从代码找到经验, 从经验反查实现, 再通过概念和约束判断是否适用。 58% 到 65% 的定位结果给出了初步信号, 完整 Loop 的收益和持续学习效果还需要继续验证。

我们希望模拟的, 是老工程师对项目的那些有效联想: 知道一段代码负责什么, 为什么这样设计, 哪里曾经出错, 怎样检查自己的判断。 这些理解不必一次提取完整, 但应该能够逐步积累, 也能够在新证据出现时更正。

一个 Loop 结束后, 除了交付需求和测试结果, 我们还希望留下这轮新弄明白的项目知识。 下一轮能够可靠地从这里开始, 就少一次重复理解, 少一次相同误判。 本体与 RSI 在内部研发中的结合, 可以先从这件具体的事情做起。

TencentDB Agent Memory 已在 GitHub 开源，我们诚挚邀请开发者在社区一同探讨记忆系统设计中的工程取舍，也期待你通过 Issue 提出反馈与建议，共建下一代 Agent 记忆基础设施，项目Github链接：

https://github.com/Tencent/TencentDB-Agent-Memory

跳转微信打开