软件工程 / 架构设计方法论知识图谱 / 分组目录 / 案例层 / AI Agent 架构 DAG 复盘
X · P2 · active

AI Agent 架构 DAG 复盘

Retrospective of an AI Agent DAG Analysis Project
P2进阶verified案例X · 跨域/其他质量属性团队与康威GC-CASE · 案例层

§1摘要与结论

TL;DR · 一句话结论

对四个工作日内独立完成三个异构对象 DAG 分析的方法论复盘，总结「采集→建模→生成→门控→交付」可复用管线与关键教训。

别名：DAG 方法论复盘、三项目复盘、采集建模生成门控　|　英文：Retrospective of an AI Agent DAG Analysis Project　|　类型：案例 / retrospective

§2局部关系图

AI Agent 架构 DAG 复盘 的 1-2 跳邻域关系图依据推导（derives_from）：测试金字塔依据测试的验证与成本本质依据推导（derives_from）：质量门控以测试作为验证反馈机制为依据依赖关联（dependency）：质量门控依据金字塔分层执行自动化测试细化（refines）：适应度函数是演进式架构的强制机制依据推导（derives_from）：属性冲突只能显式化与排序，无法消除依据推导（derives_from）：粒度决定偶然复杂度与理解成本依据推导（derives_from）：自动化方式按可信度与频率取舍依赖关联（dependency）：属性冲突治理需在粒度边界上落地前置依赖（prerequisite）：本质复杂度不可消除支撑权衡不可消除案例印证（case_instance）：印证：以可执行门控持续评估知识库架构完整性案例印证（case_instance）：印证：把架构约束转写为自动执行、可量化判定的校验案例印证（case_instance）：张力：双单体大文件反映边界粒度过粗，难独立变更案例印证（case_instance）：张力：受蓝本粒度约束，增量定位精度受限案例印证（case_instance）：印证：多层门控链与可再构建交付案例印证（case_instance）：印证：工具路由与自动化方式选择案例印证（case_instance）：印证：全链路自动化与子Agent 分片案例印证（case_instance）：印证：门控加无头渲染加视觉三重验证案例印证（case_instance）：印证：组级视图加下钻的粒度控制实现（implements）：质量门控把分析结果转化为变更准入判断依赖关联（dependency）：结构度量依赖静态分析平台采集耦合与复杂度数据组合（combination）：渐进收紧以级联适应度函数在流水线中先告警后报错实现（implements）：依赖结构度量与阈值收紧是架构适应度函数的代码层落地实现（implements）：持续集成服务落地质量门控与持续集成方法实现（implements）：以实例替换替代就地修改实现（implements）：多阶段制品晋级即部署流水线实现（implements）：构建一次逐环境晋级解耦发布部署组合（combination）：流水线产出不可变制品实现（implements）：适应度函数工具化实现架构适应度函数方法论实现（implements）：工具化持续校验支撑演进式架构的增量变更原则案例印证（case_instance）：印证：以自动化代码审查工具为载体沉淀质量实践案例印证（case_instance）：印证：多层门控链持续校验交付物完整性案例印证（case_instance）：印证：门控做无环断链覆盖一致校验，防漂移案例印证（case_instance）：印证：自动全量重生成加多级门控构成验证流水线案例印证（case_instance）：印证：采集建模生成门控交付的阶段化交付流水线案例印证（case_instance）：印证：以源数据全量重生成替代就地改页面防漂移AI Agent 架构 …AI Agent 架构 DAG 复盘（CAS-X-18）质量门控与持续集成质量门控与持续集成（MTH-I-06）粒度与边界设定粒度与边界设定（MTH-O-06）自动化方式选择自动化方式选择（MTH-O-07）部署流水线工具化部署流水线工具化（TEC-J-06）架构适应度函数工具化架构适应度函数工具化（TEC-L-01）本质复杂度与偶然复杂度本质复杂度与偶然复杂度（ESS-O-01）权衡的不可消除性权衡的不可消除性（ESS-O-03）SonarQube 静态…SonarQube 静态分析平台（TEC-H-01）测试作为验证与反馈机制本…测试作为验证与反馈机制本质（ESS-I-01）演进式架构演进式架构（MTH-L-04）架构适应度函数架构适应度函数（MTH-L-05）质量属性冲突治理质量属性冲突治理（MTH-O-05）插件 DAG RC5→R…插件 DAG RC5→RC7 升级（CAS-X-06）Open Code Re…Open Code Review 图谱（CAS-X-15）部署流水线部署流水线（MTH-J-01）不可变基础设施实现不可变基础设施实现（TEC-J-02）测试金字塔与反模式测试金字塔与反模式（MTH-I-04）依赖结构度量与渐进收紧治…依赖结构度量与渐进收紧治理（TEC-H-04）持续集成服务与流水线持续集成服务与流水线（TEC-I-01）dsh-manager …dsh-manager 插件深度分析（CAS-X-08）dsh 插件依赖增量定位dsh 插件依赖增量定位（CAS-X-10）技术知识中枢交付法技术知识中枢交付法（CAS-X-17）发布与部署解耦发布与部署解耦（MTH-J-06）
前置依赖实现依据推导案例印证对比冲突
以本节点为中心，静态内联 1–2 跳邻域：内环 5 个直接邻接、外环 18 个二跳节点，共 24 个节点；连线按边类型着色（六类配色见下）。构建期计算，无运行期脚本。

§3原理 · 为什么

三个对象（插件装配体系、单体仓库加配置双层、知识教程）表面异构，但都能抽象为「节点加边」，因此可以用同一条管线处理——差异只在采集阶段的实证依据，同构部分在于「实证、建模、生成、门控」四步。方法论可迁移性的证明，恰恰来自对象异构而管线同构。依赖还原的可信度锚定在三硬依据（编译依赖、运行时依赖、组合依赖）与源码行引用上，禁止凭空臆断边；每一条依赖都必须能指回具体源码位置，否则宁可不画。这套「先定证据、再定图」的顺序，是静态依赖分析不沦为示意图的关键，也让不同人对同一对象能复现出大致一致的图。换言之，方法论的边界由对象的依赖是否可静态枚举决定，其骨架由「证据先行、图后生成、门控收口」决定，前者决定适用性，后者决定可靠性。把它写成方法论而非三个项目的流水账，正是为了让经验能脱离具体对象被复用。边界清晰，才能避免把一个静态方法误用在不适合的对象上。

§4机制 · 如何运作

采集阶段用三硬依据加上并行探索子Agent 按领域分片，主Agent 只做分片设计与聚合裁决，语义分析全部下放以控制上下文。建模阶段把结果统一为含节点、边、组、层的 DAG 数据，用拓扑算法做分层（源头为第零层）、做无环校验、再做悬空边清洗。生成阶段产出多形态交付物：交互图带组级视图与点击下钻、每个节点一页、组目录、Markdown 镜像、drawio 静态图。门控阶段校验数据合法、无环、断链、覆盖、交互数据一致与统计一致，再叠加无头渲染与视觉验证。交付阶段推送托管平台并配置自动部署，形成「一次建模、多形态产出、自动发布」的完整链路。分片与聚合的分工是关键：子Agent 负责在各自领域内做深，主Agent 负责统一口径与裁决冲突，既避免单点上下文过载，也防止多人产出难以拼合。门控中的悬空边清洗与统计一致性校验，都是在真实事故后补上的，属于用代价换来的经验。分片与聚合的分工，本质是把上下文压力与口径统一分别交给不同角色承担。

§5工程 · 怎么落地

组级视图加点击下钻，解决数百节点一次性渲染的卡顿——第一层只渲染组节点，点击后下钻组内成员。双轨交付满足两类读者：人类看 HTML，AI 读 Markdown。悬空边清洗必须在渲染前完成，因为图库遇到引用不存在节点的边会整图抛错而非跳过，这是实战中付出代价后确立的铁律。三个子项目合计 312 节点、740 依赖边、360 个节点页、190 张静态图，均部署为可公开访问，证明同一管线可跨源码、配置、知识三类对象稳定复用。为了长期可维护，所有交付物均由数据源经脚本重建，修正一处即可全量刷新，避免多形态产物之间出现口径漂移。节点页按统一的 why-how 结构生成，使读者在不同项目间切换时不必重新适应版式。由脚本重建交付物，是保证多形态产物长期一致的最低成本手段。

§6权衡卡

代价 · 风险

其「可复用」验证也只覆盖了三个由同一人设计的项目，存在方法论自证的风险，普适性证据有限，故置信度标为中等。

原文要点
  • 该方法论适合结构相对静态、依赖可枚举的对象（源码、配置、知识），对运行时反射注入、动态加载等以动态依赖为主的对象无效，需要运行时跟踪而非静态解析，这是其明确边界。
  • 复盘本身也暴露局限：边主要覆盖直接依赖，间接与条件依赖未穷尽；边溯源率靠人工抽查、未全量自动化；节点热点分析（被依赖 Top N）尚未纳入。
  • 此外，这是一份求职导向的复盘，结论带个人叙事色彩，部分量化指标需按当时口径解读，不能当作行业基准。
  • 因此复盘的定位应是经验清单而非行业结论，读者应关注其可迁移的做法与踩过的坑，对其量化数字保持合理折扣与批判性使用。
  • 若要在正式项目中复用，建议先补齐边溯源自动化与间接依赖，再扩大适用范围。
  • 对复盘数字保持折扣，是对个人叙事类材料的合理审慎态度。

权衡原文仅按显式标记词归栏引用（收益 / 代价 / 反例），其余句子按原序列为「原文要点」；内容逐字引用未改写。

§7案例带

CAS-X-04 · 2 跳派生：当前节点 → MTH-O-07 → ESS-O-03

网申 v2 深度重构

一次由「改一处漏多处」症状触发的深度重构：定位到接口定义散落 12 个文件、存在 7 种接口形态的根因后，以单一契约源、dispatch 消息表与能力注册中心重建三层契约系统，恢复可审计与可校验性。

CAS-X-06 · 2 跳派生：当前节点 → TEC-L-01 → MTH-L-05

插件 DAG RC5→RC7 升级

一次知识库随上游源码版本升级的级联维护：以三层差异分析把 219 个包收敛为 26 个实质变更包，经编译、运行时、组合三类依赖判定更新 DAG 数据后全量重生成页面，并以静态门控加渲染验证收口。

CAS-X-07 · 2 跳派生：当前节点 → TEC-L-01 → MTH-L-05

插件 DAG 两次级联升级

在同一知识库上继续两轮上游级联升级：处理数百次提交与包的增删，暴露「依赖声明不等于运行时引用」、分层须按最长路径深度、纯外部依赖边不得入主图等差分陷阱，并以全量门控校验收口。

CAS-X-08 · 经 MTH-O-06

dsh-manager 插件深度分析

以「编译依赖、运行时注入、组合装配」三硬依据加源码行号，对第三方插件做依赖、功能、需求溯源与设计问题裁决，并复用上游 DAG 知识库节点标识，使分析结果可与主图互查。

CAS-X-10 · 经 MTH-O-06

dsh 插件依赖增量定位

以官方插件 DAG 为蓝本，对一个官方清单之外的全新社区插件做功能定位与依赖位置增量分析，产出可下钻交互依赖图与多形态文档的源码级架构逆向案例。

CAS-X-13 · 2 跳派生：当前节点 → MTH-O-06 → ESS-O-01

Claude Code 架构逆向

以社区逆向源码、系统提示词与官方文档三源交叉验证，还原一个商业 Agent 的查询引擎、子Agent、工具与权限体系的逆向分析案例。

CAS-X-14 · 2 跳派生：当前节点 → MTH-O-07 → MTH-O-02

OpenSpec 规约驱动解析

对比规约驱动开发工具链 OpenSpec 与 Superpower 的元模型、工件依赖 DAG 与安全门控，提炼「规约先于实现」工程形态的解析案例。

CAS-X-15 · 经 MTH-I-06

Open Code Review 图谱

对阿里开源 AI 代码审查 CLI 做源码级解析并构建「知识 + 实践资产 + AI 索引」三合一知识图谱的工程案例。

CAS-X-16 · 2 跳派生：当前节点 → MTH-O-06 → MTH-O-05

控制理论⊗Agent 设计

将控制理论五维（负反馈 / 状态估计 / PID / 鲁棒 / 分层）系统映射到 Agent 工程环节，并以真实产品案例验证的跨学科方法论案例。

CAS-X-17 · 经 MTH-O-07

技术知识中枢交付法

从模糊需求到上线，把 AI Agent 驱动的端到端交付固化为四阶段加双共识加迭代的可迁移方法论的实战提炼案例。

§8信源与核验

核验状态True（verified）
置信度medium
复核日期2026-09-10
生命周期active
规范信源LOC-037
勘误
常见误解：同一套 DAG 方法论可以分析任何复杂对象
核验结论：方法论只适用于结构相对静态、依赖可枚举的对象；运行时反射与动态加载需运行时跟踪。复盘案例的量化指标来自单一求职向项目，口径有限，置信度中等　[LOC-037]

§9原始关系清单

展开：本节点的全部原始关系边（5 条，含边 ID 与方向）
关系方向对端节点说明
案例印证→ MTH-I-06质量门控与持续集成
E-994		印证：门控加无头渲染加视觉三重验证
案例印证→ MTH-O-06粒度与边界设定
E-995		印证：组级视图加下钻的粒度控制
案例印证→ MTH-O-07自动化方式选择
E-993		印证：全链路自动化与子Agent 分片
案例印证→ TEC-J-06部署流水线工具化
E-26		印证：采集建模生成门控交付的阶段化交付流水线
案例印证→ TEC-L-01架构适应度函数工具化
E-22		印证：门控做无环断链覆盖一致校验，防漂移