先说个场景。上个月我接手一个维护了快九年的开源调度项目准备给它的 worker 做一次并发优化。代码我看明白了测试也补了但临门一脚时我发现一个非常尴尬的事实没人能说清楚当初为什么给队列加了一把全局锁。README 上只留了一句“防止重入”Git 历史里那次改动的 commit message 写得更为潦草——“加锁稳一手”。我翻了四个小时的 issue 和 PR才在一个 2017 年就沉底的评论里看到设计者本人的解释原来锁的背后还挂着一层更深的约束。这件事让我下定决心做一套东西用 AI 驱动的方式把散落在长期开源信息系统各处的证据抓取出来、融合起来最终把那些没人写在文档里的隐性知识自动挖出来。这就是本文要分享的项目一条由多个 AI Agent 协作完成的证据融合与隐性知识发现流水线。如果你维护过三年以上的开源项目或者在一块“祖传代码”里做过考古大概率能对上我接下来要讲的痛点和解法。这套方案不一定需要很贵的算力关键是先把“证据”这个概念在工程里立住再谈用大模型抽取和融合。1. 为什么“隐性知识”会烂在开源仓库里1.1 显性知识与隐性知识的边界做过知识管理的人都知道一个经典划分显性知识是能被文档、注释、规范明确记录下来的隐性知识则藏在人的脑子里表现为“直觉”“惯例”和“说不清道不明的约束”。放到软件项目里边界其实很清晰显性知识README、API 文档、代码注释、发布说明、架构图。隐性知识为什么当初用 A 方案而放弃 B 方案、哪些代码是历史包袱不能动、某个“魔法数字”背后对应的外部系统限制、某个看似冗余的校验实际是为了兼容老版本客户端。我见过不少团队代码写得整整齐齐文档也定期更新但隐性知识仍然会丢。原因很简单文档只能记录“当时达成共识的结果”很难记录“达成共识的整个过程”。而真正的坑几乎都在过程里。用开车来类比显性知识是导航地图上的路名和限速隐性知识是老司机脑子里的“这条道早上七点一定堵走辅路右转能省十分钟”。地图可以复制路感只能积累。1.2 长期系统的“知识断层”如何形成我拿 OpenScheduler 举例这是我参与维护的一个开源分布式任务调度器最早的一版代码可以追溯到 2015 年。它经历过三次大的架构调整核心贡献者换了四批。到了 2023 年新加入的维护者看代码时会反复产生同一个疑问这段逻辑为什么这么绕以队列锁为例。早期版本中调度器进程内部维护了一个全局锁用来保证一个任务不会被两个 worker 同时领取。后来系统改成了基于数据库行锁的分布式方案但全局锁并没有删除而是变成了一个仅在某些边缘路径生效的“兜底锁”。代码里留着它文档里只字没提。直到我们做证据考古时才发现2016 年的一次线上事故就是因为并发领取导致任务重复执行当年的维护者为了快速止损加了这把锁2018 年分布式锁上线时他们想删掉全局锁但审查者指出“数据库行锁在连接滞留场景下仍有缝隙”于是保留了下来并在 PR 评论里约定“至少留一个版本周期再评估”。这个约定后来被所有人遗忘了。2022 年有贡献者提 PR 要删除全局锁代码层面看完全合理但因为不了解历史事故改动在 review 阶段就引发了争执。问题不在于代码而在于隐性知识断层——当年决策的依据散落在 2016 年的 issue 讨论、2018 年的 PR 评论、一次电话会议记录里没有任何结构化载体。这就是长期开源信息系统的通病知识密度高但分布极度碎片化。文本存在于 commit、PR、issue、邮件列表、聊天记录、发布通告中彼此之间的关联依赖人的记忆。人一换记忆就断。AI 驱动的证据融合本质上就是把“记忆”从人脑搬到可计算、可检索、可交叉验证的系统中。2. 总体设计一条由多 Agent 协作的证据融合流水线2.1 “证据”在软件项目里到底指什么做这套系统之前我花最多时间想的就是“证据融合”这四个字该怎么落地。法律领域有证据链学术领域有引文索引软件领域其实也有类似物只是我们平时没这么叫。在 OpenScheduler 的场景里我把一条“证据”定义为一个可溯源的、关于软件系统某项事实的断言。它必须具备四个要素谁说的作者身份在项目中的角色什么时候说的时间戳对应代码版本基于什么上下文说的commit、PR、issue、邮件线程说了什么断言为什么这么做、警告什么、推荐什么、废弃什么。比如一条 2018 年的 PR 评论原文是“这个锁现在别删数据库连接滞留场景下仍然需要它”这就是一条典型的证据。它应该被结构化提取为actor维护者Btime2018-05-12sourcePR#486评论predWARNS_NOT_DELETEcontent“数据库连接滞留场景下需要此锁”。一旦证据被结构化我们才能进行下一步的融合。否则它只是又一条会被淹没的历史文本。2.2 流水线的四段式架构整个流水线我命名为 E-F-M-K四段式阶段 EEvidence从 Git 历史、Issue、PR、邮件列表中采集原始文本做清洗和切分。阶段 FFact用 LLM 将切分后的文本片段抽取为结构化的“证据元组”并提取谓词。阶段 MMerge将多条证据按“讨论主题”聚合检测相互冲突的断言进行时间线排序和可信度加权。阶段 KKnowledge将融合后的证据集交给知识合成 Agent生成决策记录、架构约束、避坑指南等隐性知识卡片。四段各自由不同的 Agent 承担彼此之间有明确的输入输出协议。采集 Agent 只负责清洗原始数据不允许做主观判断抽取 Agent 只负责把自然语言变成结构化元组不允许跳过证据直接生成结论融合 Agent 负责冲突消解和权重计算合成 Agent 负责最终的隐性知识产物。2.3 为什么不用单个大模型一把梭最早我做原型时偷懒把所有原始文本拼成一个超大上下文丢给一个大模型让它直接输出“这个项目里的隐性知识”。结果不难猜模型会漏掉很多细节不同来源的断言会被混在一起甚至拼凑出看起来合理但原始证据里根本没有的结论。问题出在“证据”和“知识”之间的距离。单模型一把梭的本质是让 LLM 同时干四件事读原始材料、判断材料间的关系、回忆隐含信息、形成结构化输出。模型注意力有限上下文一长就会“中间迷失”更何况一个长期开源项目动辄上万条 commit、数千个 issue。多 Agent 协作不是噱头它把四件事拆成四个子任务每个 Agent 只用专注于一个狭窄目标。采集 Agent 不需要理解语义抽取 Agent 不需要做全局决策合成 Agent 不需要看原始大海量文本只需看已经结构化的证据元组。这样既降低了单次任务的复杂度也让每一步的结果都可审计。这个思路和我后来用 AI 编程、AI 测试开发时的体会一致真正有效的多 AI 协作不是把一堆 Agent 扔在一起闲聊而是明确分工、明确交接物、明确复核点。每个 Agent 的输出都是下一个 Agent 的输入中间任何一步出错都可以定位。3. 证据采集与清洗先把散落的线索捞上来3.1 数据源画像建立证据融合系统的第一步不是引入大模型而是把数据源摸清楚。我列了一个表把 OpenScheduler 的数据源逐一画像数据源关键字段常见噪声采集难度Git 历史commit hash、作者、时间、message、diff无意义 message、合并提交、rebase 记录低GitHub Issue标题、正文、评论、标签、里程碑、状态机器人评论、格式引用的代码块中GitHub PR描述、审查评论、讨论线程、合并时间“1”评论、自动 bot 提示中邮件列表主题、发件人、时间、正文、引用链重复引用、base64 编码、签名高发布通告版本号、日期、变更列表版本回滚造成的记录错位低Git 历史的采集我用的是 GitPython按git log --all --prettyformat:%H|%an|%ad|%s --dateshort拉取索引再对每个 commit 做git show提取 diff stat。注意不要一次性把所有 commit 的完整 diff 都拉下来信息量太大且大部分没用先只拿结构信息后面按需补 diff。Issue 和 PR 我走 GitHub REST API分页拉取每页 100 条记录updated_at作为增量更新的游标。邮件列表我直接解析 mbox 文件噩梦主要在编码和引用链上后面细说。3.2 粒度划分与噪声过滤最关键的预处理是粒度控制。一整条 issue 常常包含背景陈述、复现步骤、讨论串、结论等多个主题如果把它作为一个整体喂给抽取 AgentAgent 很容易把“某用户猜测问题在 X”和“维护者确认问题在 Y”混为一体。我的做法是先用规则把文本切成“论断级片段”原则是按段落和对话轮次切分一个片段对应一个发言者的一次完整发言引用代码块单独切出来不参与语义抽取超过 500 字的发言再按句子边界拆成若干候选片段。噪声过滤相对机械但非常重要。我总结了几类必须去掉的内容机器人自动评论GitHub 上常见的 dependabot、stale bot 等只含“1”“me too”“赞”等无信息量回复CI 失败后自动生成的错误日志邮件签名、免责声明、历史引用内容通常超过正文长度的冗余引用。这些过滤逻辑我用正则和关键词模板搞定不需要机器学习。跑了真实数据后发现噪声占比往往超过 30%不清理干净后面融合的准确性会被严重拖累。3.3 增量同步与全量重建的取舍第一次跑全量同步是必须的但之后一定要做增量。commit 可以用 SHA 做断点遇到 force push 或 rebase 导致历史重写的情况需要做一次全量重建。Issue 和 PR 用updated_at做游标最稳妥因为评论发生会更新这个字段。存储选型上我一开始用 SQLite只存四个表sources、raw_docs、evidence_atoms、fusion_topics。后来为了做关系遍历比如“某个 Issue 被哪些 PR 引用这些 PR 的评论涉及哪些文件”引入了 Neo4j 做知识图谱层。说句实话数据量在百万级以下时 SQLite 完全够用Neo4j 更多是为了后续做复杂查询的舒适度不是必需品。增量同步还有一个容易踩的坑Issue 被编辑。原始内容变了之后旧证据可能失效。我的方案是给每个文本片段存两份哈希——原始哈希和当前哈希捕获到当前哈希变化时把该片段标记为“已修订”并保留修订前后两个版本的证据元组。这样既保留了历史也能观测到观点变化。4. 核心环节跨来源证据融合的建模与冲突消解4.1 证据元组模型采集清洗之后原始文本要交给抽取 Agent 转成结构化元组。我定义的数据结构长这样{ evidence_id: E-2018-0486-03, source: github_pr_comment, object_id: PR#486, time: 2018-05-12T14:32:00Z, actor: maintainer_B, actor_role: core_committer, predicate: WARNS_NOT_DELETE, content: 数据库连接滞留场景下仍然需要这个锁至少保留一个版本周期再评估, raw_location: https://github.com/example/OpenScheduler/pull/486#discussion_r12345 }其中predicate是我定义的一套受限谓词集合初期只保留这几类DECLARES_WHY解释某段代码或方案存在的原因RECOMMENDS推荐某种做法WARNS警告不要做某事OBSOLETES声明某事已废弃CONFIRMS确认某方案有效或问题已解决。限制谓词集合是为了让抽取 Agent 不那么自由。LLM 在开放输出时容易发明出千奇百怪的表述一旦受限融合阶段做聚合的难度会大幅下降。4.2 冲突检测同一决策为何会有多个说法把历史证据都结构化之后最常遇到的情况是“针对同一主题不同时间存在多条看似互相矛盾的断言”。这不是 LLM 的问题而是软件系统演化的自然产物。OpenScheduler 里最典型的一条2018 年 PR 评论说“全局锁不能删”2022 年 issue 里却有人说“全局锁是历史遗留应该彻底移除改用纯分布式锁”。两条断言在文本层面直接矛盾但实际并不冲突——2018 年的上下文是“数据库连接滞留场景未被修复”2022 年的上下文是“连接池已升级并增加了重试机制”。约束条件变了结论自然变。所以冲突消解的核心不是判断谁对谁错而是判断“断言的生效条件是否仍然成立”。我实现了一个简化版的可信度加权模型evidence_score ( 0.4 * role_weight 0.3 * recency_decay 0.2 * source_strength 0.1 * specificity )role_weight核心维护者 1.0普通贡献者 0.7用户 0.4recency_decay距离当前时间越近分越高半衰期按 180 天算source_strength代码变更记录 1.0PR 评论 0.9issue 讨论 0.8邮件列表 0.6specificity如果断言中提到了具体代码符号、版本号或环境条件就给更高分。这个公式从一开始我就没用它作为“删除证据”的依据只用于“排序展示”。证据融合系统最重要的职责是保留不同视角而不是替人拍板。在实际知识卡片里我会把高置信度的断言排在前面把低置信度的标记成“存疑”而不是直接丢掉。4.3 时间线聚合与知识演化融合的最后一步是生成“决策演化链”。对每个主题把相关证据按时间排序相邻证据之间用“延续”“修正”“废弃”“确认”四种关系连接。举一个具体的输出形态2016-04-11maintainer_A 提交 commita1b2c3d加入全局锁message“防止任务重复领取”。2016-04-12maintainer_A 在 issue #102 评论“线下排查发现行锁在事务超时后释放不及时临时用全局锁兜底”。2018-05-12maintainer_B 在 PR#486 评论“全局锁现在别删滞留场景仍有需要”。2022-03-01contributor_C 在 issue #887 提出“应该移除全局锁分布式锁已有重试机制”。2022-03-15maintainer_B 回复“连接池升级后可以移除但需要先跑一周压测”。这条演化链既包含了为什么存在也包含了为什么后来可以删还包含了删除前的验证要求。这种带时间线、带来源、带条件约束的知识才是隐性知识发现真正要产出的东西而不是一句干巴巴的“可以删锁”。5. 从融合结果到隐性知识提示词工程与知识输出5.1 隐性知识抽取的四种典型模式融合后的证据集就像一块块码放整齐的拼图合成 Agent 的任务是把它拼成可读的知识卡片。我在实践中定义了四种典型输出模式模式输入证据特征输出形态架构决策记录涉及关键模块设计、技术选型、重构的讨论ADR 形式背景、决策、理由、后续变化隐含约束反复出现“不要”“必须”“注意”等警告性断言约束清单约束内容、适用条件、引入证据避坑指南与线上事故、bug、失败尝试相关的证据问题、根因、解决方案、验证方法术语黑话项目内部缩写、外号、隐晦概念术语表含义、首次出现上下文、当前用法这四种模式在 OpenScheduler 里都有对应的真实需求新人培训最需要避坑指南架构评审最需要决策记录代码审查最需要隐含约束跨团队沟通最需要术语表。5.2 提示词模板中的“身份约束”与“证据引用”合成 Agent 的提示词设计是整套系统里最容易被低估的环节。我踩过最大的坑是模型生成的结论读起来很顺畅但结论背后的依据在原始证据里并不存在——也就是幻觉。我最终使用的提示词框架包含三条硬性约束你只能基于输入的证据元组进行推理不得补充任何证据之外的工程常识或经验每条结论的末尾必须列出支撑它的证据 ID格式为[citation:E-2018-0486-03]如果证据集合不足以支撑某个结论必须显式输出INSUFFICIENT_EVIDENCE而不是猜测。系统提示词的简化版本如下system: 你是一名软件历史考古专家。你的任务是基于用户提供的证据元组集回答关于软件项目演化的问题。 你需要遵守 1. 只允许引用输入证据中的内容 2. 每条结论后用 [citation:证据ID] 标注来源 3. 证据不足时直接回答 INSUFFICIENT_EVIDENCE不要推测。 user: 请解释 OpenScheduler 中全局锁的演化过程并补充当前是否可以删除。在调用模型时temperature0.1、top_p0.3尽可能抑制模型的创造欲。后处理阶段还会跑一个校验脚本检查输出里的[citation:...]是否都真实存在于输入证据集合中。凡是引用无效 ID 的结论一律打回重新生成。5.3 输出格式决策记录、架构约束、避坑指南为了让下游系统好消费知识卡片统一用 JSON 输出。一个架构决策记录的示例{ type: architectural_decision, topic: worker 队列锁的去留, status: pending_removal_after_stress_test, timeline: [ {time: 2016-04-11, event: 引入全局锁, evidence: [E-2016-0102-00]}, {time: 2018-05-12, event: 确认保留, evidence: [E-2018-0486-03]} ], decision: 在连接池升级后可移除全局锁, conditions: [需通过一周压测, 保留回滚预案], evidence_ids: [E-2018-0486-03, E-2022-0887-05] }避坑指南的卡片则略有不同我会额外加一个“复现步骤”和“验证方法”字段。有一次新同事读到一个避坑卡片后直接复现了 2019 年的那个连接滞留 bug效果比任何培训文档都立竿见影。从工程师视角看把知识结构化到 JSON 不是最终目的最终目的是让知识可以被程序调用、被其他 AI Agent 消费。到了这一步这套系统就已经从一个“搜索工具”进化成了“组织记忆基础设施”。6. 验证与踩坑我在这条流水线上交的学费6.1 评估指标召回率之外的“证据可追溯率”做这类系统最容易被问的问题是“效果怎么评估”。准确率和召回率当然要看但我觉得有两项指标更重要证据可追溯率所有生成的结论中包含有效证据引用的比例。要求 100%做不到就说明系统在幻觉。结论稳定性同一组证据输入多次产出结论的一致性。我用一个最简单的做法检验同一个问题跑五遍统计关键词层面的相似度。另外我建立了一份人工黄金测试集从真实项目历史中挑出 50 个有明确答案的问题比如“全局锁为什么存在”“数据库行锁的引入时间”“v3.0 移除 JVM 参数的具体原因”每个问题标注了标准答案和对应证据。每次调整提示词或融合逻辑后都拿这个测试集回归。6.2 幻觉治理强制引用与人工抽查幻觉治理是个长期拉锯战即使加了强制引用模型偶尔还是会在措辞上“润色”到偏离原意。我建议在融合与合成之间加一层“复核 Agent”专门对合成结果挑刺。具体做法是合成 Agent 产出知识卡片后复核 Agent 拿到卡片和对应证据集合逐条判断“是否忠实于证据”。只要发现以下任一情况就打回重写结论提及了证据集合中不存在的具体数字、文件路径或版本号把不同时间点的证据做了不当合并把条件性结论写成了绝对结论。这个“提出方案、交叉审查、打回重做”的模式是我在多 AI 协作实践中收益最大的一环。单个模型的自省能力很有限但两个模型互相审查能有效发现问题成本也没有翻倍因为复核 Agent 用的是小一号的模型。6.3 上下文窗口紧张时的时间分片策略还有一个躲不开的实际问题即使证据已经结构化单个主题的融合结果也可能很大。比如 OpenScheduler 的“任务调度引擎”主题关联了 300 多条证据全部塞进上下文接近十万 token经常出现“前面几轮讨论被模型遗忘”的情况。我最终采用时间分片策略把主题相关的证据按时间切成 2-3 个窗口比如 2015-2017、2018-2020、2021-至今每个窗口单独生成“中间摘要”保留关键断言和对应证据 ID知识合成 Agent 读三份中间摘要做跨窗口整合输出最终卡片。这个思路本质上是 Map-Reduce 的提示词变体。代价是中间摘要阶段可能丢失细节所以在提示词里我会特别强调“务必保留所有 WARNS 类断言”。实测下来时间分片后的结论稳定性比一次性硬塞高了不少丢失的细节也都能在溯源时通过证据 ID 找回。7. 落地效果与后续扩展从“代码考古”到“组织记忆”7.1 入职培训与架构评审系统跑通后我先在 OpenScheduler 社区里做了两个落地场景。第一个是新人问答机器人。新人进入项目后可以直接提问“为什么 worker 需要心跳机制”并在答案下方看到证据卡片每个断言后面都跟着历史 commit 和讨论链接。相比扔一个几百页的 wiki 链接这种“带证据的答案”更让人安心。第二个是架构评审辅助。每次有新 PR 要触及敏感模块时我先让系统自动生成一份“该模块历史决策简报”挂在 PR 描述里。评审者一眼就能看到过去的相关决策链、警告过的坑、以及当前约束条件是否仍然成立。有两次 PR 因为这份简报直接终止了原本会引入隐患的合并这就是系统价值的直接体现。7.2 与 AI 编程、AI 测试开发等场景衔接做了这套系统之后我对“AI Native 研发范式”有了更实际的体感。所谓 AI Native不只是让 AI 帮你写代码而是把研发过程中最有价值的经验沉淀成 AI 可以消费的结构化数据。举例来说给 AI 编程工具接上这套隐性知识库后它修改旧模块时会被强约束“不要移除 X 条件下的 Y 逻辑”而不是仅凭代码上下文自由发挥。AI 测试开发也一样生成用例之前先检索“该模块历史上出过什么问题”测试设计会更有针对性。这就是证据融合结果和 AI 编程、AI 测试开发之间的天然衔接——不是替代人而是让 AI 变得更懂系统。7.3 从单仓库工具到 AI Native 研发范式目前这套流水线已经能稳定处理单个中等规模的开源仓库。我给自己定的下一步方向是跨仓库和跨语言支持比如把依赖的上游库演进历史也拉进来形成一张更大的知识网络。再往后我希望把邮件列表、会议纪要、线上聊天记录也一起融合让“组织记忆”不再依赖任何单个人的回忆。最后再说一个建议如果你也想给自己的长期项目做类似的系统别一上来就追求大而全。先从 Git 历史和 Issue 两个数据源开始把融合后的证据卡片做出来放到团队里让所有人试用一个季度。你会发现很多你以为“没人知道”的设计秘密其实一直都在仓库里只是散得太远缺一个愿意把它们串起来的人。