2014 年的微服务和 2019 年的云原生，奠定了过去十年互联网架构的核心跃迁，AI 经过 3 年多的高速发展，逐步从 PE 到 Context Engineering，再到 Agent Engineering。Agent 的核心产品设计和架构会是什么样的？同时在架构跃迁的核心问题是什么？存量系统如何做升级？AI Coding 为核心的开发升级能够给 Agent 工程体系带来什么启示？同时运行态 Workload 在互联网时代和 AI 时代的区别我们需要在运行态架构做前置布局。

演讲提纲

1. AI 时代架构范式的跃迁分析

• 微服务和云原生再到 Agent Engineering，PE->CE->AE->ME 四层核心架构定义
• 从 Workload 视角定义 Agent 在长周期和不确定性的应对策略分析
• Agent 产品形态的演进，『稳定态+敏捷态』，双态架构的推演

2. 四个案例细节分析架构升级以及需要面临的问题

• AI SRE，从人类经验到线上 Agent 自动诊断和预防
• 助理型 Agent 到员工型 Agent 的演进中遇到的技术问题
• AI 销售，从 Leeds 到 Cash 的关键设计
• AI 质控，长周期 long-horizon Agent 的关键探索

3. 关键问题延伸

• 存量系统如何升级？传统数字化和 AI 化的跃迁逻辑
• 从 Claude Code 中我们学习到的三大 Agent 设计范式
• Agent 产品架构基于 Context 和 Agenty 二维矩阵定义

您认为，这样的技术在实践过程中有哪些痛点？

• 新的 Agent 形态的定义，超越了之前微服务分布式的形态，边摸索边前进
• Skills 以及 Teams 等模式逐步涌现，给架构带来新的契机
• 存量系统如何升级，如何从古典的架构升级到 Agent 架构

演讲亮点

• PE->CE->AE->ME，四层 Agent 工程架构体系，核心的架构定义和实践案例
• 稳健态和敏捷态，超越传统六层架构到『双态架构』，给存量系统升级带来思路
• Workload 的定义，面向长周期以及不确定性，来设计新的 Agent 架构

听众收益

• 核心架构定义和演进，能够从更全的视角，提前布局未来 Agent 工程架构
• 核心案例辅助理解和认知，Agent 架构需要解决的关键问题和技术细节

当前 AI Coding 工具在复杂系统中面临“结构不可控、上下文幻觉、资产难维护”的落地困境，代码采用率往往不足 10%。本演讲我将分享 Toco AI 探索的 “建模驱动开发 (MDD) + LLM” 新范式，深入剖析如何构建 “AI 架构师 (Agent) + 确定性引擎 (Engine)” 的双核架构：通过 DSL 定义领域模型与读写方案，利用 LLM 进行意图理解与胶水代码生成，再由引擎自动渲染 80% 的 DDD/CQRS 结构化代码，内容涵盖解决 “模型与代码一致性”、“非侵入式 DSL 设计” 及 “存量系统渐进式重构” 的技术细节与踩坑经验。

演讲提纲

1. 痛点：为什么 Chat-to-Code 在复杂系统中失效？

• 现象： “Vibe Coding” 的繁荣与企业级落地的“ 10% 采用率”悖论
• 根因分析：
  • 熵增效应： 概率性生成导致代码同义异表（Same Intent, Different Code），维护成本指数级上升
  • 信任危机： 上下文窗口限制导致的“结构性幻觉”（引用不存在的类/循环依赖）
• 结论： 在 AGI 到来前，必须引入“中间层”（DSL）来锁定确定性

2. 新范式：构建“神经符号”双核架构

• 核心设计： Agent (右脑/概率) + Engine (左脑/确定性)
• Agent 职责： 意图理解、模糊匹配、非结构化胶水代码生成
• Engine 职责： 拓扑计算、架构约束、DDD/CQRS 骨架渲染
• 工作流解密：Input: 自然语言需求 -> Output: 中间态 DSL -> Action: 静态语法校验 -> Result: 渲染标准 Spring 代码

3. 关键技术实践与 DSL 边界

• 技术点 1：DSL 的“克制”哲学
  • 挑战： 如何避免重蹈 UML 覆辙（变得极其复杂且难用）
  • 方案： 坚决不侵入 if/else。DSL 仅描述实体 (Entity)、聚合 (Aggregate) 和读写契约 (Contract)
• 技术点 2：解决“N+1”与复杂查询的读写建模
  • 方案： 引入 CQRS（读写分离） 策略
  • Write Model： 基于聚合根的事务一致性保障
  • Read Model： 基于 Toco-DTO 的自动组装器（Auto-Assembler）实现，解决跨表 JOIN 与脱敏
• 技术点 3：从模型到代码的渲染机制 (M2C Engine)
  • 如何通过 AST 操作生成人类可读、可 Debug 的原生 Java 代码，而非二进制黑盒

4. 踩坑经验与反直觉教训 

• 坑 1：Brownfield（存量系统）的阻抗失配
  • 问题： 在“屎山”代码上强行叠加 MDD 模式遭遇失败
  •  认知迭代： 承认技术的适用边界。该模式最适合 Greenfield（新模块/重构）。对于老系统，采用“双模开发” + “防腐层（ACL）”策略
• 坑 2：AI 并非全自动驾驶
  • 问题： 试图让 AI 全自动设计架构，结果出现不合理的聚合边界
  • 认知迭代： 强调 Human-in-the-loop。人必须作为“架构审核员”介入 DSL 的确认环节
• 坑 3：All-in Prompt 的失败
  • 教训： 无论 Prompt 多精妙，无法解决长链路依赖。必须用 Engine 兜底结构正确性

5. 实施效果与总结

• 数据支撑： 某电商场景重构，Code Review 耗时下降 70%，架构类 Bug 归零
• 终局思考： AI 时代，Code 是过程，Model 才是资产

您认为，这样的技术在实践过程中有哪些痛点？

• 该方案对新建系统，新建模块，重构项目(Greenfield Projects)适合，对于在老系统(Brownfield Projects)上直接叠加逻辑并不适合建模驱动的开发模式. 需要一定的试用土壤，但长远来说，如果能成为行业标准，那么更容易成为大量系统重构的构建技术
• 在当前大模型基础上，无法让AI在所有场景都是按最佳实践去试用引擎，还是需要人进行积极干预

演讲亮点

• 把“架构规范”固化在工具里，彻底解决架构、代码随意发挥的问题。现有 AI 工具生成的代码风格完全取决于 Prompt 写得好坏和AI发挥，导致架构、代码风格严重发散，难以治理。我们通过内置引擎，统一了架构和结构性代码。避免了AI的发散导致的不易控制、不易维护的问题
• 解决 AI 代码“只管生、不管养”的维护难题 现有方案生成的代码往往是“一次性”的，后续需求变更时，AI 很难在庞大的旧代码堆里精准修改。我们采用模型驱动，改需求本质上是在改模型，引擎会自动重新计算并同步更新所有相关代码。这让系统具备了长期演进的能力，而不是随着时间推移变成一堆不敢动的“黑盒代码”

听众收益

• 了解一种解决 AI 编程“不可控”问题的架构实战模式（Agent + 引擎） 听众将看到我们是如何通过“中间层建模”和“双核驱动”的设计，让 LLM 负责理解意图，让规则引擎负责生成结构，从而解决 AI 写复杂系统时容易出现的“幻觉”和“逻辑不自洽”难题。这是一套可复用的架构设计参考
• 获得一套在 AI 代码爆发下，保障系统可维护性的工程治理策略 当 AI 能瞬间生成几千行代码时，传统的 Code Review 模式已经失效。听众将收获如何通过“模型管理”替代“代码管理”，确保团队无论产出多少代码，架构标准始终统一，避免系统沦为难以维护的“各种风格的大杂烩”

在 App 的性能治理实践中，火焰图已成为核心分析工具，但其高度依赖专家经验、分析效率低且难以规模化复用。我们构建了 AI 驱动的大前端统一火焰图分析平台 FlameEye，将专家诊断思路沉淀为“Trace 解析 → 结构化数据预处理 → Prompt 驱动推理”的三步工程流水线，实现从原始 Trace 到结构化诊断报告的自动化生成。

平台支持 iOS、Android、Web、RN 多平台，累计处理近 5000 次分析，部分页面启动耗时降低 30%+，发热率下降 40%-50%。本次分享将重点讲解如何将专家经验工程化、如何设计可扩展的 SQL+Prompt 体系、以及如何构建可量化的 AI 评测机制。

演讲提纲

1. 火焰图分析为何难以规模化？

• 高度依赖专家经验，门槛高且难以传承
• 百兆级 Trace 人工分析效率低、易遗漏关键问题
• 多平台、多维度分析割裂，难以形成统一能力
• 专家资源有限，无法支撑规模化需求
• 核心问题：如何把“专家能力”转化为“工程能力”？

2. AI 分析体系建设：如何把专家经验工程化？

• 不直接接入大模型，而是构建完整的分层分析体系
• 三步流架构：Trace 解析 → 结构化特征提取 → AI推理归因
• 将专家直觉沉淀为可计算规则与垂直 Prompt 体系
• 引入源码语义，让分析从“函数耗时”升级为“实现级解释”
• 统一输出结构与反馈闭环，确保能力可复用、可进化

3. AI 评测体系建设：如何让能力稳定、可演进？

• 构建覆盖核心性能场景的标准化样本集
• 建立规则校验 + LLM Judge 的双模评估机制
• 围绕内容质量、成本、端到端耗时三大指标量化能力
• 支持回归对比与持续优化，避免模型漂移

4. 规模化落地：是否真正解决了最初的问题？

• 实现 Android / iOS / Web / RN 多平台统一分析
• 覆盖启动、卡顿、加载、发热等核心性能维度
• 累计 5000+ 次分析，近百用户持续使用
• 分析采纳率接近 80%，部分页面性能提升 30%–50%
• 火焰图能力从“专家瓶颈”走向“工程化基础设施”

5. 未来方向：迈向 AI Native 性能闭环

• 打通监控、抓取、分析、优化的自动化链路
• 探索自动生成修复 MR 与效果验证
• 构建性能领域垂直模型，降低成本、提升精度
• 目标：从“分析助手”进化为“自主优化系统”

您认为，这样的技术在实践过程中有哪些痛点？

• 规则依赖 vs 泛化能力：为保证稳定性必须依赖结构化预处理；规则越强越可控，但对未知场景的适应性可能下降
• 精度 vs 成本与时延：更多调用栈与源码上下文能提升准确率，但会增加 Token 消耗与整体延迟
• 跨平台统一 vs 复杂度：iOS / Android / Web / RN 机制差异大；统一范式会损失细节，平台专属逻辑则提升维护成本

演讲亮点

• 将性能专家“诊断直觉”转化为参数化 SQL + Prompt 双层沉淀模型，实现经验工程化
• 引入“数据 + 源码语义”双输入分析范式，实现从函数耗时到实现级解释的升级
• 构建可量化 AI 评测基线，避免凭感觉优化模型，推动能力工程化演进

听众收益

• 学会如何将领域专家知识工程化为 AI 可执行流水线
• 理解“规则 + LLM”混合架构在垂直场景落地的方法论
• 获得构建 AI 评测体系与成本控制机制的实践经验