主流代码图谱只能回答"现在是什么"，涉及历史就得回Git手工比对，我们希望获得四项能力：任意版本的代码问答、结构演化追踪、跨仓版本兼容与影响分析、更经济地保存历史知识——把"代码快照"升级为可查询、可差异分析、可演化推理的基础。
复杂性不只是版本变多。14个仓库、每仓库10个版本，理论组合10¹⁴种，不可能都预构建完整代码图，更难的是三个难题：
根本约束是：版本一致性必须覆盖节点、边、修订与跨仓协议事实。
三层模型
同一逻辑实体和关系复用身份，不同提交选择有效关系和具体修订：共享拓扑层保存跨版本稳定的实体和关系，历史修订层记录变化属性及证据，版本层是指定提交下的视图
增量构图
更新一次接口变化要走五步：代码差异→影响范围扩展→重新解析绑定→身份对齐→语义图差异。关键在于，即使只有服务端文件变化，未修改的调用者也必须重验绑定。存储上不复制整张图，只保存检查点加增量
"客户端调用支付服务，这条链在指定版本组合下是否成立？"配旧版能找到有效调用链；配新版，原调用链已不成立。系统按四步处理：确定版本→找有效代码→沿有效边查找（每步检查版本与接口匹配）→返回证据。核心原则是不能把不同提交下曾经存在的关系，拼成一条并不存在的调用链。
反过来问"权限校验从哪个版本开始支持？"，系统沿历史给出四个节点：新增函数、接入流程、验证可用、正式发布。这里有个容易忽略的点："首次引入"不止一种含义——代码出现，不等于流程接通，不等于功能可用，更不等于发布。
我们发现三类典型低效行为：检索不收敛，围绕相似字段反复检索却没带来新证据；单步信息过载，某一步读取近4万字符；探索路径锁定，大量步骤集中在同一仓库。
关键观察是：问题不只是调用次数多，而是Agent缺少对"证据进展"和"何时改变策略"的判断，需要说明的是，上述案例来自具体观测，比例应按原始轨迹及判定规则核验，不等同全部任务发生率。
采集侧用双通道：OTel提供时间与调用状态，rollout提供模型消息与参数，自进化的架构分五层：采集→管理→语义分析（识别停滞及无效决策）→经验组织→反馈，本质是转化：原始轨迹→探索语义→可复用方法，形成闭环。
从失效决策生成可验证的替代策略，不是把失败轨迹直接总结成经验，而是四步：发现失效→产生方案→受控重执行→抽象并入库。一个示例是"检索停滞后的跨仓策略切换"：多轮同义检索无新增证据时，停止换词重搜，改切候选仓库。需要说明的是，该方案现阶段仍是技术路线表达，自动提炼与跨任务泛化仍需独立验证，离线比较也不能替代真实重执行。
进展有两块：
代码智能体正从代码生成走向自主软件工程，核心挑战从"生成代码"转向"理解系统、获取证据、完成任务"。
跨仓库代码知识是提升Agent能力的重要基础
运行轨迹驱动的经验学习是Agent自进化的重要方向
汇总来看，本次分享的核心判断：Agent能力上限，不只取决于基座模型本身，更取决于它能否获取结构化、可追溯、可演化的工程知识。从运维数据洞察，到代码知识理解，我们持续打通整条链路，欢迎交流探讨。
相关内容推荐阅读
擎创科技，Gartner连续推荐的AIOps领域标杆供应商。公司专注于通过提升企业客户对运维数据的洞见能力，为运维降本增效，充分体现科技运维对业务运营的影响力。
行业龙头客户的共同选择
