导读:这份报告在回答什么
这不是一份会议纪要,而是一次横向比对。把 16 场演讲放进同一张坐标纸里,看它们在哪里指向同一个方向,在哪里彼此拆台,又在哪里同时沉默。
2026 年 10 月 24 日,首届 AI 架构师会议(AI NATIVE 2026活动的第一场峰会)在南京召开。上午全体会议 5 场,下午分 A、B 两个平行场次共 11 场。讲者构成罕见地混合:一所澳大利亚高校的教授、一家澳洲背景的研究者、南大教授、阿里云、中兴通讯、DaoCloud、优维、和度、傲拓、柯基数据、盛派、与星以舟,以及几位独立创业者和咨询师。
这种构成决定了讲稿的气质差异——学术派给证据,大厂派给规模,创业公司给案例,垂直行业给边界。但也正因为差异足够大,重合的部分才格外值得注意。
逐篇提炼:每场演讲一句话定位、核心命题、方法与关键数据。
横向归类:把 16 篇内容重新切成 8 条技术主线,标注每条主线的支持者与强度。
落地转化:从共识与空白中导出可执行的检查清单与 90 天路线。
不复述产品宣传页,不转述无法验证的数字而不加标注,不把讲者的自述成效当作第三方结论。
凡引用具体数字,均注明来自哪一场演讲;凡属本报告作者的推断,均单独标记。
只有 10 分钟:读第 01 章五条判断 + 第 05 章共识表。
要选型:读第 04 章第 1、2、4 条主线 + 第 06 章检查清单。
要交差:读第 07 章路线图,直接把三阶段搬到你的项目里。
这 16 场演讲表面上在讲 16 件不同的事——可复现性、Token 工厂、DDD、PLC、本体、企业上下文、零容错迁移——但它们其实在从不同方向回答同一个问题:当模型本身不再构成壁垒时,系统剩下的价值应该被放在哪里。答案高度一致:放在模型之外。分歧只在于「外面」具体指什么。
执行摘要:五条判断
如果只能带走五句话,应该是这五句。每句后面标注了它在样本中的支持强度。
判断一:系统的价值已经确定性地搬到了模型外面
这不是口号,而是被独立表述了至少六次的具体工程判断。周小四给出的数字最直接:约 70% 的功夫在模型之外。黄胜鲁把它画成一条演进线:Prompt 工程 → 上下文工程 → Harness 工程 → Loop 工程,每一步的工程化控制点都在往模型外面移。吴昊把公式写成 零容错 Agent 体系 = LLM + Harness + Sandbox + Tools,模型只是四个角色里的一个「大脑」。陆徐洲则把平台的管理单元从「一次模型调用」直接改成「一个可验证的组织任务」。
这个判断的实践含义是:如果团队的 AI 投入仍然集中在选模型、调 prompt,那么投入方向已经落后于这批一线实践者两到三个代际。
统计口径:本报告作者逐篇判读,强论述计入;仅顺带提及不计入。
判断二:「确定性」是这批人唯一没有分歧的信仰,但落地方式分成两条路
所有涉及生产环境的讲者——杨成彪、吴昊、姚文广、阿甘、苏震巍、陆徐洲——都在说同一句话的不同版本:不能把零容错的事交给概率系统。
分岔在于「把确定性放在哪里」:
- 类型与模型层(阿甘):把规则编进类型系统、值对象、聚合根。非法状态在代码里根本写不出来。他的比喻是三层防线——文档规则是路边牌子,类型约束是物理护栏,流程检查是收费站。
- 运行时与引擎层(杨成彪、吴昊、姚文广):把约束做成模型外部的规则引擎、DAG 校验器、沙箱与回滚链。杨成彪的表述最锋利——「先约束,后规划;顺序反了就是事后打补丁」。
两者不冲突,且在实践中应当叠加:一个管「写错了编译不过」,一个管「想错了执行不了」。
判断三:知识的结构化程度,正在成为比模型能力更硬的护城河
姚文广说得最直白:「AI Coding 与 Agentic 工程的护城河,是工业私域知识与工艺资产,不是单纯的大模型。」程杰用 45 万行、92 万行、150 万行源码的逆向工程案例佐证;杨成彪用 MTTR 从 4.5 小时降到 45 分钟佐证;张旭海用「两年前做同样的事,因维护成本过高而失败」的教训佐证。
但这里有一个被多数人忽略的转折:结构化的成本已经变了。张旭海原话是两年前失败于维护成本;现在 AI 维护 Agent 把持续维护的成本压到可行区间。这是「企业上下文」这类产品在 2026 年忽然重新变得可行的真实原因——不是概念更好了,是维护这件苦活有人(AI)干了。
判断四:可观测性不是运维附属品,而是整个体系的进化入口
黄胜鲁把它讲成五级链条:可观测 → 可度量 → 可评估 → 可决策 → 可进化。他的判断很硬:「没有可观测,选择等于瞎猜,进化等于盲人摸象。」杨成彪指出四类必须落盘的数据里,最被低估的是约束命中日志——命中率异常升高说明模型输出在漂移,异常下降可能是约束被绕过。陆徐洲则把验收拆成四件:轨迹能否复现、权威记录是否改变、结论能否回溯、代价是否在边界内。
而 Haifeng Shen 的实证研究给这条主线补上了最反直觉的一击:你以为在帮忙的干预,未必让系统更稳定。开启 thinking 反而显著降低输出一致性;加强型 prompt 防御对可复现性影响甚微,而重写 prompt 往往降低一致性;仓库上下文对 5 个 backbone 中的 4 个有帮助,但让其中一个在自包含任务上变差。
Haifeng Shen 的结论是:可复现性是「配置好的流水线」的属性,不是 backbone 的属性;而「可复现」与「正确」是两个独立的评估目标,任何一个都不能替代另一个。多数团队的评测仍在只看正确率——这等于只看了一半。
判断五:组织侧的真问题不是「用不用 AI」,而是「工作本身有没有被定义清楚」
程哲桥三次建设的复盘里,最有价值的一句是关于第一阶段的失败:「同样是一份报告,它有没有被采用?同样是完成一个任务,它解决了什么业务问题?」——他们发现,采集更多底层数据也无法补上这部分定义,因为组织原本就没有把目标、结果和评价标准说清楚。
陆徐洲的组织智能操作系统把这件事制度化了:业务负责人定目标与风险边界,领域专家定规则与验收案例,数据治理管口径,平台与安全管权限与回滚,一线人员负责确认与接管。黄胜鲁的双环理论则给了它一个更简洁的表述:内环解决「正确地做事」,外环解决「做正确的事」。
以上均为讲者自述成效,未经第三方复核;引用时请保留出处。
大会全景:谁在讲,讲给谁
16 位讲者,5 场全体会议 + 11 场平行场次。这个分布本身就说明了「AI 架构」这个词在 2026 年已经被拉扯成了多大的一片区域。
| 场次 | 讲者 | 机构 | 题目 | 本报告归类 |
|---|---|---|---|---|
| 全体 · 09:30 | Haifeng Shen | 南十字星大学 | Same Settings, Different Outcomes:LLM 代码生成与评估的可复现性 | 实证研究 |
| 全体 · 10:00 | 郭峰 | DaoCloud(CTO) | 迈入工业化 Token 时代 | 基础设施经济学 |
| 全体 · 10:30 | 周小四 | 与星以舟(CTO) | 从模型调用到知识执行 | 知识工程 |
| 全体 · 11:00 | 黄胜鲁 | 中兴通讯 有线院 | AI 端到端提效工程化落地新范式 | 工程体系 |
| 全体 · 11:30 | 崔张伟 | 优维科技 | AI 软件工厂 | 团队化 AI Coding |
| A 场 · 13:30 | 程哲桥 | 阿里云 海外事业部 | AI 原生组织的基础设施设计与实现 | 组织基建 |
| A 场 · 14:05 | 陆徐洲 | 上海杏和软件 | 从模型平台到组织智能操作系统 | 平台架构 |
| A 场 · 14:40 | 苏震巍 | 苏州盛派网络 | 使用 NeuCharBox 为 FDE 提供物理世界操作系统 | 物理世界 OS |
| A 场 · 15:15 | 杨成彪 | 南京柯基数据(CTO) | 面向生产环境的本体驱动智能体架构 | 本体架构 |
| A 场 · 15:50 | 张旭海 | Inspire & AI | 企业上下文:AI 时代的认知底座 | 知识工程 |
| B 场 · 13:30 | 阿甘(马林胜) | 云梦客栈「足下」 | 用 DDD 为 AI 软件开发建立架构护栏 | 架构护栏 |
| B 场 · 14:05 | 程杰 | 和度软件(总经理) | 存量系统 AI-FIRST 开发生产线 | 存量改造 |
| B 场 · 14:40 | 姚文广 | 傲拓科技(副总工) | 从可编程逻辑控制器到可编程智能体 | 工业控制 |
| B 场 · 15:15 | 吴昊 | 个人 / OpsWeave 开源 | 高并发与零容错场景下的 Agent Harness Engineering | 高责任系统 |
| B 场 · 15:50 | 郑立 | 上海惠艾 | 从不敢改到稳定交付:AI 加速遗留代码改造 | 成本与效能 |
| 主旨 | 杨鲲 | 南京大学 | 浅谈 AI 架构、AI 工程落地和人文情怀 | 学术视野 |
注:场次与机构依据现场议程表核对。程哲桥的原始文件中标注为「NJSD 演讲」,但讲稿内容与议程表 10.24 A 场「AI 原生组织的基础设施」完全对应,本报告以讲稿内容为准。
讲者构成:三分天下
Haifeng Shen(南十字星大学)、杨鲲(南京大学 NINE 实验室)、郑立(标准编制者,半学术)。
共同特征:给证据、给边界条件、给谨慎声明。三人都明确标注了结论的适用条件,这在其余演讲中并不常见。
阿里云、中兴通讯、DaoCloud、优维、惠艾。
共同特征:规模数据与体系化分层。讲「一条能力线怎么铺到几十个项目」,而不是「一个 demo 怎么跑通」。
柯基数据、盛派、和度、傲拓、杏和、与星以舟、云梦客栈、Inspire & AI。
共同特征:场景纵深。每个人都带着一个真实到有细节的失败案例——这是本次大会信息密度最高的部分。
本次大会最有价值的内容,几乎都不是「我们做到了什么」,而是「我们怎么搞砸的、后来怎么修」。阿甘的「李白称赞陆游」、程哲桥的「三次建设前两次没成」、张旭海的「两年前失败过」、杨成彪的「三个生产现场」、程杰的「AI 巧妇难为无米之炊」——这些失败样本的价值远超成功叙述。
内容完整度:一张必须说明的表
并非所有讲稿都以文本形式完整可读。以下说明本报告实际能分析到什么程度——这决定了第 03 章各篇摘要的详略差异。
| 讲者 | 页数 | 图片数 | 文本可读性 | 对本报告的影响 |
|---|---|---|---|---|
| 阿甘(马林胜) | 52 | 21 | 完整,含详细备注 | 可作为核心样本 |
| 苏震巍 | 48 | 47 | 较完整,部分页为图片 | 核心论证可还原 |
| 郭峰 | 32 | 125 | 完整,图表页有文字替代 | 数据可引用 |
| Haifeng Shen | 32 | 29 | 完整(英文) | 实证结论完整 |
| 程杰 | 26 | 74 | 较完整 | 方法论可还原 |
| 黄胜鲁 | 24 | 67 | 完整 | 框架可完整引用 |
| 杨成彪 | 23 | 0 | 完整 | 论证链最完整的一篇 |
| 吴昊 | 22 | — | 完整(PDF 文本层) | 架构可完整引用 |
| 姚文广 | 22 | 23 | 完整,含详细备注 | 核心样本 |
| 郑立 | 23 | 24 | 中等,关键页为图片 | 数据可引用,界面细节缺失 |
| 陆徐洲 | 21 | 22 | 完整,备注即讲稿 | 核心样本 |
| 周小四 | 21 | 25 | 完整 | 数据可引用 |
| 杨鲲 | 17 | 66 | 中等,图多 | 框架可引用 |
| 程哲桥 | 17 | 17 | 页面全是图片,但备注是完整讲稿 | 内容完整可还原 |
| 张旭海 | 15 | 21 | 较简 | 框架可还原,细节有限 |
| 崔张伟 | 28 | 28 | 28 页全部为整页图片,无文字层、无备注 | 无法做实质分析,仅能依据议程摘要定位 |
崔张伟《AI 软件工厂》这一篇的原始 PPT 是 28 张整页截图,没有任何可提取的文字和演讲者备注。本报告只能依据现场议程表给出一句话定位:「把超级个体的 AI Coding 经验落地为团队级工程化实践」。任何超出此范围的描述都将是编造,因此第 03 章对该篇只做定位、不做提炼。
十六篇速览:每场演讲的一句话
每篇给四个字段:定位、核心命题、方法或证据、最值得带走的一点。按会议出场顺序排列,方便对照原稿。
- 定位
- 全场唯一的受控实验研究。不卖方案,只给测量方法和反直觉结论。
- 核心命题
- 可复现性(固定输入与条件下重复运行的输出相似度)是「配置好的流水线」的属性,不是模型本身的属性;可复现与正确是两个独立目标。
- 方法
- 每个任务在固定条件下跑 n=10 次,产生 45 个无序输出对;用 CodeBLEU 的四个维度(n-gram、加权 n-gram、AST 语法、数据流)度量相似度,数据集级取宏平均。对 LLM-as-Judge 另设两套指标:ReproCorrect(判对的一致性)与 Repro(判同的一致性),并通过交换 A/B 顺序检验位置偏差。
四组反直觉发现:
- Few-shot 与 CoT 不是可靠的控制手段——同一策略能让某个 backbone 更稳定,同时让另一个更不稳定;CoT 甚至能反转示例带来的效果。
- 防御性 prompt 中,保持原文措辞、只加边界或强化指令的做法影响有限但偏正面;而改写、扰动任务表述往往降低一致性,其中 重新分词(retokenization)的负面效应最稳定。
- 开启 thinking 带来最大的可复现性损失;而在已开启的情况下继续加大推理预算,影响很小且大多不显著。真正起作用的是模型能力本身——同预算下更强的 Gemini 变体显著更可复现。
- 仓库上下文检索对 5 个 backbone 中的 4 个提升可复现性,且对依赖外部上下文的任务增益更大;但 Codex 在自包含任务上反而下降。
- 定位
- 把 AI 从「技术话题」翻译成「制造业话题」。全场唯一给出完整成本结构与商业模型的一场。
- 核心命题
- AI 基础设施的评价标准正从峰值算力(FLOPS)转向 Token 经济学:在规定延迟与服务质量下,每度电、每美元能稳定产出多少可售卖 Token。
- 方法
- 五层蛋糕框架(能源—芯片—基础设施—模型—应用);用 128 节点 H200 集群的真实运营数据拆成本;用两个公式分别对齐工厂侧与客户侧的价值语言。
关键结构(值得记住的两个公式):
- 工厂视角:
收入 = Tokens/W × 可用千兆瓦数(效率 × 规模) - 客户视角:
客户价值 = 单位 Token 成本 × Token 效能 × 业务适配度(VpT 三重杠杆:调度折价、缓存复用、引擎优化)
成本结构:GPU 折旧 60%、网络设备 10%、电费 8%、运营带宽与人力 10%、软件平台 10%、其他 2%。约 70% 固定、仅 8% 变动——这解释了为什么「利用率」是唯一的短期杠杆:利用率每提升 10 个百分点,毛利率提升 5–8 个百分点。
Agent 放大效应:Super-agent 类任务约为普通聊天 25 倍 Token;Agentic Coding 研究显示可达约 1000 倍;Tokenomics 论文指出多 Agent 软件工程中反复 Code Review 阶段占消耗大头(59.4%)。
本场对 OpenRouter 份额数据主动标注了口径偏差(平台开发者构成为美国约 47%、中国约 6%),并强调正确表述应为「该平台口径下」。这种自我限定在商业演讲中少见,值得记一笔。
- 定位
- 把 RAG、本体、Agent 三件事放进同一条演进线,并给出可量化的选型证据。
- 核心命题
- 企业知识要先成为「可核验的上下文」,才能支撑可核验的任务执行;模型越同质化,差异化越往模型外走。
- 方法
- 四类知识用途分类(参考/素材/依据/执行,各有不同的相关性、完整性、适用性、可控性要求);8 类 RAG 架构选型矩阵;用 MASSIVE zh-CN 基准实测小模型取代大模型做决策节点。
三类知识问题的对症下药——这是全场最实用的诊断表:
| 症状 | 典型情况 | 改进手段 |
|---|---|---|
| 召回遗漏 | 分块破坏语义、表格结构与图文关联丢失、查询表达与知识表述不匹配 | 改进知识组织与检索:语义结构保留、查询理解、混合检索 |
| 内容不适用 | 召回已失效版本、重复副本占用配额、以低质量文档为依据 | 落实知识治理:按版本、来源与质量筛选 |
| 证据不足 | 仅完成局部检索便终止、把检索无结果等同于内容不存在 | 引入 Agent 迭代检索,证据不足时不做确定性判断 |
实测数据:在 2,974 条中文意图分类任务上,9B 的 Clef-Flash 达到 91.69% 准确率、平均延迟 71.84ms;Qwen3-30B 为 83.69%、145.37ms。结论是准确率高 8 个百分点、延迟低 50.6%。
- 定位
- 全场体系化程度最高的一场:给了一条演进史、一个协作模型、一套平台分层和一串可复用的能力清单。
- 核心命题
- AI 工程能力分四阶段演进,每一阶段解决上一阶段的遗留问题;到 Loop 工程阶段,若人的判断力缺位,成本结构会从「前期设计成本」翻转为「后期返工与事故成本」。
四阶段演进表(本报告认为这是全场最好的一个框架):
| 阶段 | 解决的问题 | 工程化控制点 | 遗留问题 |
|---|---|---|---|
| Prompt 工程 | 如何「说清楚」任务 | 措辞、格式、示例 | 模型不了解业务、无记忆、人是触发与判断的瓶颈 |
| Context 工程 | 给模型足够的知识 | 进入上下文窗口的知识供给 | 概率性生成,看到正确信息仍可能错误行动,错误不自愈 |
| Harness 工程 | 让错误结构性不可重犯 | 模型之外的执行环境:规则、约束、工具、权限 | 从「知道失败」到「知道为什么失败」;长程任务可靠性 |
| Loop 工程 | 让系统自主执行与迭代 | 心跳、工作树隔离、技能编码、多 Agent 编排、状态存储 | 人的判断力缺失;成本转为后期返工与事故 |
双环模型:内环由 Agent 执行(计划—执行—评估—验证),解决「正确地做事」;外环是人机协同,解决「做正确的事」。两个方向:人类在环内(Human-in-the-Loop,经验回流、异常上报、决策日志)与人类在环上(Human-on-the-Loop,目标设定、权限控制、能力沉淀、规则制定)。
三层质量防护:硬约束(Hook 强制拦截,不满足即阻断)→ 软约束(自检 + 评审智能体)→ 人工决策(复杂场景兜底)。关键设计是「执行逻辑与执行引擎分离」:套件是院级/项目级、持续进化的,引擎(Claude Code / OpenClaw 等)是通用、独立演进的,同一引擎可服务 9–90 个项目,只切换套件。
原始文件 28 页全部是整页图片,没有文字层,也没有演讲者备注。本报告只能依据现场议程表给出一句定位:把超级个体的 AI Coding 经验,系统化落地为团队的 AI Coding 工程化实践。
讲者背景(议程表):优维科技研发总监、Elevo 产品合伙人,专注把已验证的 AI Coding 实践带到客户场景,帮助客户完成研发团队 AI 转型。若需该场内容,应回看录像或原始 PPT。
- 定位
- 全场唯一一场「以自我批评为主」的分享:三次建设,前两次都明确说了没成。
- 核心命题
- AI 原生的瓶颈不在工具,在于工作本身没有被定义清楚;基础设施 = 平台 + 业务对象 + 共同上下文 + 工作方法 + 验证反馈机制。
三次建设的递进关系(这场最大的价值):
- 第一次:可观测。收集谁在何时用了什么工具、多少 Token、做了什么、产生什么价值。结果:使用变得可见,但复盘时发现缺少关键定义——「同样是一份报告,它有没有被采用?」采集更多底层数据也补不上这层定义。
- 第二次:云端 Agent 平台 + Hub。让业务专家把方法做成 Skill/Agent 分享。结果:遇到新阻力——方法依赖的上下文、系统连接、使用体验搬不上云;企业内部系统开放程度不一;贡献者要花时间整理,使用者要理解怎么用,短期收益不明确就难持续。
- 第三次:从交付物出发重构流程。把业务对象、上下文、方法和工具一起设计,再把人的判断放到合适位置;明确哪些信息需确认、哪些动作可执行、结果怎样回系统。
商务链与研发链的对称结构:商务侧维护「客户背景」与「商机上下文」两套上下文;研发侧用大单库把前端、后端、CLI、需求、原型、技术设计、架构规范、研发 Skill 放在同一仓库,让一项需求的相关上下文可被一次性找到。两侧的共同点是——每次工作完成后,组织应该比开始时更了解这件事。
- 定位
- 本届在「平台架构」维度最完整的一篇,把一个抽象命题落到了可画的六层框架与可执行的责任表。
- 核心命题
- 平台的管理单元,要从「一次模型调用」扩展为「一个可验证的组织任务」。
切入点极好:实验室检验值「6.8」。同一个数字,样本类型、采样时点、检测方法、使用目的不同,后续任务就完全不同。由此推出 Task envelope——任务包必须同时交代四件事:对象/状态(处理谁的哪条、当前到哪一步)、规则/证据(凭什么判断)、行动/审批(允许做到哪一步)、终态/记录(以哪条权威记录验收)。
架构六层:Agent Runtime / Harness(上下文管理、规划与状态、工具调用、人机协同)+ 组织数据(事实、语义、版本、责任归属)+ 上下文工程(选择与契约)+ 治理控制(身份、策略、审批)+ 领域应用(工作流与验收终态)+ 可观测与评估(轨迹、业务终态、成本、失败归因)。
两个原创表达值得借用:
- Context Contract(上下文契约):重要上下文必须明确来源、用途、有效时点与责任归属。例如「当前质控状态」只能用于本次审核工作流,由实验室质量负责人负责。
- 三级扩权:只读建议 → 受限行动 → 跨系统闭环,每一级都需要新的验收证据(明确定义的任务终态、专家标注的真实样本、工具权限收敛到任务、关键动作人工批准、生产轨迹可重放、可回滚可审计、故障升级责任明确)。
- 定位
- 把「AI 落地物理世界」拆成一道工程题:不是模型不够强,是缺一层操作系统。
- 核心命题
- 当 FDE(前沿部署工程师)走进物理世界,他需要的不是更强的模型,而是一层能感知、编排、仿真并承担责任的运行底座。
对现状的三条批评:出厂固化的指令约束让任何软硬件故障都可能导致整体失效;边缘设备种类与协议被设计流程锁死,扩展性成为瓶颈;大量 AI 硬件落地受阻,一因过度依赖实时 AI 反馈(function-calling / MCP / A2A)导致响应慢成本高,二因幻觉导致结果不稳定。
解法:预编程 + 后编程——类比模型的预训练与后训练。把能力在部署前固化,运行时摆脱对 AI 算力的实时依赖,速度提升百倍,动态控制成功率接近 100%(讲者自述)。
三层编排与三层仿真(本场最可复用的部分):
| 编排层 | 内容 | 验收标准示例 |
|---|---|---|
| L1 能力编排 | 把意图落到已有能力上 | 调用序列里不能出现设备型号名——出现「3 号加热台」说明抽象层漏了 |
| L2 时序编排 | 依赖、并行、超时、最小间隔 | 关键路径时序正确 |
| L3 异常编排 | 降级、替代、中止、升级到人 | 失败路径全覆盖 |
仿真分三层且「一个都不能少」:L1 纯软件逻辑仿真(100 次运行无死锁无越界)→ L2 半实物/数字孪生(关键路径时延误差小于阈值)→ L3 真实试验台(覆盖足够多的失败用例)。跳过任一层,都有对应的、可预言的翻车方式——「单设备都对,一起跑就撞」「白天通过,夜班出事」。
本体数据管理三原则:Ontology-first(先定义对象、关系、约束再承载数据)、Lineage-aware(每次接入与转换可回溯来源与变换逻辑)、Security-by-design(访问控制与脱敏由统一策略执行,不靠调用方自觉)。
- 定位
- 本届论证链最完整的一篇。从失效模式到架构中枢再到工程指标,闭环无断点。
- 核心命题
- 生产环境要求确定性,而智能体架构的默认形态是概率的。因此必须把「不能错的部分」从概率域搬出去——这不是过渡方案,而是长期原则。
三个生产现场(这一组案例的选取本身就构成论证):石化压缩机跳机(判断错了是数百万级转子报废)、锂电极片涂布排产(系统给的不是建议,是会直接执行的动作)、供应链断供推演(答案散在 ERP/MES/PLM 三个系统)。共同特征:错误成本极高、状态跨时间跨系统——这些不是问答题,是操作题。
六项架构能力差:可复现性(Demo「这次答对了」vs 生产「同一输入同一输出」)、错误成本、状态持续性、审计要求、时延预算、可演进性。
三大失效模式 → 三个中枢:
| 失效模式 | 表现 | 中枢 |
|---|---|---|
| 状态无源 | 每次推理从零重建上下文,跨班组故障排查退化成间歇性失忆 | 状态图谱:带时间轴的唯一事实源,按目标实体增量拉取局部子图 |
| 约束缺位 | 控制流完全由模型生成,多步误差累积,走到第五步没人知道它在做什么 | 约束引擎:SOP 约束构成 DAG,输出前确定性校验,越界即拦截 |
| 寻址失效 | 自然语言与系统接口之间没有稳定映射,参数靠模型猜 | 语义寻址:API 实体化注册在业务对象上,参数一律从子图提取 |
四个必须遵守的工程细节:约束命中率要纳入可观测指标;重试设上限,N 次不收敛降级转人工;约束冲突时按预置优先级裁决;写回(Writeback)是闭环关键——没有回写,系统记忆永远不增长。
效果(讲者自述):跨班组故障 MTTR 4.5 小时 → 45 分钟;涂布排产批量报废率 0%,规划 2 小时 → 3 分钟;跨系统联动成功率 50% → 99.8%,排查半天 → 30 秒。
「约束命中日志的价值被低估了:命中率异常升高说明模型输出在漂移,异常下降可能是约束被绕过。」
- 定位
- 把「企业上下文」定义成一门可建设的工程学科,而不是一堆文档。
- 核心命题
- 数字员工要真正进入企业,必须先理解企业本身。企业上下文 = 企业建模 + 持续维护 + 提供依据。
三层建模范围:L1 外部环境、商业模式、战略目标与经营安排(客户与市场、收入与承诺、目标与文化、取舍原则);L2 组织、责任、资源、业务能力、产品与流程(谁负责、投什么资源、提供什么、怎样交付);L3 应用、数据、技术基础、运行状态与工作历史(系统与指标、代码与部署、实际观察、事件与处理结果)。
本场最诚实的一句话:「在两年前我们就已经做过类似的事情,最终因维护成本过高而失败。」紧接着给出的转折是:现在之所以可行,是因为 AI 维护 Agent 能持续完成「发现变化、核对、更新」这件苦活,人只处理冲突与 AI 无法判断的部分。
三 Agent 分工:编译 Agent(读懂资料、建立关联、提出建模建议)、维护 Agent(接入与解析、按状态处理、沿关系分析影响)、查询 Agent(规划查询、核验并组装任务上下文包)。评测也分开做:编译与查询独立评测,分别定位问题。
退款积压案例展示了「对象关系优先」与「关键词搜索」的效率差异:沿「退款流程—退款政策—退款服务—退款队列」的关系链查找,比关键词搜索再查状态更快更准。
- 定位
- 全场「失败案例」密度最高、也最具体的一篇。52 页里前 20 页全是真实 bug。
- 核心命题
- AI 只会执行你给它的约束;当系统里存在多个语义相近的对象,它就会取错。所以架构护栏不是给代码看的,是给 AI 看的。
五个真实故障(每一个都值得抄进团队复盘模板):
- 语义重叠:系统有两个「事件」数据源(统一时空事件表、人物履历表)。AI 实现「走过的路」取一张表,实现「来过的人」取另一张,结果李清照明明经过济南,查询却查不到。
- 读写不同步:管理员改了事件数据,物化视图不刷新。根因不是 bug,是「写入方不知道谁关心我改了这张表」——数据无属主、变化无通知、读写依赖藏在表里。
- 影子依赖:A 模块重构私有函数,B 模块崩溃,C 模块因为复制粘贴了一份版本悄悄过时。教训:公域私域无区分,依赖没有契约。
- 死后写诗:李白卒年 762,系统生成 765 年的写诗事件。根因是「人不能死后活动」这条领域不变量没有聚合来保证,而是散落在 20 多个 if-else 里各查各的。
- 方向搞反:「李白称赞陆游」实际是陆游称赞李白。根因是
person_a_id / person_b_id这类命名不携带业务语义,方向知识只存在于导入者的脑子里。
解法三层:统一语言(术语卡:一词一义、一义一词、语言进代码)→ 限界上下文(10 个 BC,分核心/支撑/差异化/通用四层,核心域投入 70% 建模精力)→ 领域模型(值对象、聚合、领域服务、领域事件)。并给出「错误类型 → 防护模式」对照表:字段超范围→枚举值对象;关键字段漏填→必填 + 不可变值对象;关联字段不同步→聚合方法;方向搞混→语义化命名 + 工厂方法;跨字段矛盾→聚合根 Validator;改到不该改的→上下文投影。
流程层:OpenSpec 四阶段(Explore / Propose / Apply / Archive)被改造成 propose-ddd、apply-ddd、archive-ddd,把「BC 归属判定」放在提案之前,把「domain-delta 存在且无未落实元素」设为归档的硬门禁。
三层隐喻:写在文档里的规则=路边立的牌子;写在类型系统里的约束=物理护栏;写在开发流程里的检查=收费站。
讲者在结尾主动降调:「不宜过度解读提升幅度,保持合理预期。」这种自我限定值得记录。
- 定位
- 唯一一个直面「80% 的开发预算花在存量系统上」这一现实的产品化方案。
- 核心命题
- 存量系统 AI 提效不稳定的根因是工程知识资产隐性化、离散化——「缺失工程知识,AI 巧妇难为无米之炊」。
方案结构:为每个存量系统构建专属生产线 = 4 个智能体(需求分析、设计建模、软件制造、逆向建模)+ 2 个知识资产库(需求知识资产库:组织/岗位/流程/业务对象/规则/功能模块/界面;设计知识资产库:子系统/程序模块/能力/框架/数据库/表/中间件/外联接口)。初始全量逆向,此后每次上线增量逆向。
逆向建模两阶段:先逆向设计资产(库表结构、程序架构、后端程序、前端程序、数据关系 → 设计基线 SPEC),再逆向需求资产(业务需求→软件需求→需求架构)。产出是可交互的多维度可视化 SPEC 模型,支持级联影响分析——选中一张库表,能展开「谁创建它的数据、谁更新它、哪些接口在写它」。
交付能力(讲者自述):银行核心系统存款模块 45 万行 3 周;央企工程管理系统 92 万行 2 周;证券 CRM 150 万行 2 周;「再大的系统 6 周内交付(足够算力保障)」。应用价值:端到端效率提升至传统模式的 1.5–3 倍。
一个容易被忽略的细节:其公司主编了两项团体标准——T/JSIA 0001—2026《基于大语言模型的软件开发指南》与 T/JSIA 0002—2026《面向 AI 编程的软件 SPEC 编制规范》。这说明「给 AI 写规格」正在从经验变成可引用规范。
- 定位
- 把「AI 进物理世界」讲到硬件与实时性的最底层,安全边界写得最硬。
- 核心命题
- AI 不替代 PLC,而是让 PLC 成为 AI 在物理工业世界最可靠的执行载体。AI 是增强,不是依赖。
架构:RK3576 核心板,6 TOPS NPU,八核异构 + RT 实时内核。核级分工:大核跑 AI,其余核跑 PLC runtime;算法结果通过封装库(libnaplc.so)读写 I/Q/M 测点,但是否执行仍由 PLC 既有确定性逻辑判定。
双路径隔离:AI 推理路径(可被调度、可抢占、可失效)与硬实时控制路径(毫秒级、不可被抢占)之间做资源隔离、时间隔离、故障域隔离。
两条不能破的红线:① AI 推理不得侵入 PLC 扫描周期,结果只以「建议值」写入测点;② 必须定义降级机制——推理超时/漂移/NPU 异常时自动退出增强层,系统退回纯确定性逻辑,关键联锁与安全回路绝不依赖 AI 输出。
AI Coding 五 Agent + 七步闭环:规划(解析自然语言需求,拆解控制任务)→ 编码(生成符合 IEC 61131-3 的 ST/SCL、LD、FBD)→ 验证(编译与仿真校验)→ 修复(基于仿真反馈迭代)→ 组态(标签库、HMI、报警、趋势、通信)。七步闭环是:需求解析 → 程序生成 → 自动编译 → 智能纠错 → 安全下载 → 在线调试 → 报告归档。多数人做到「生成代码」就停了,真正的难点在编译之后。
落地案例:视觉读表 + 声纹识别(结果写测点,PLC 决定降速/停机/告警);深圳河流域 LSTM 24 小时水位预测(单次推理 0.325 秒、内存 135.5 MB);预研中的自然语言控制(「天真热」→ 空调降温)。
- 定位
- 把「Agent 可靠性」拆成可数的工程机制,且开源了实现。
- 核心命题
- 零容错 Agent 体系 = LLM + Harness + Sandbox + Tools。可靠性来自严格的工程控制与状态管理,而非单一模型的偶然发挥。
两代范式的局限:1.0 Prompt 时代三大局限(无状态、无肌肉、依赖人工);2.0 Agent 时代四大致命伤(状态爆炸——95% 单次成功率跑 10 次降到 59.87%;首步盲目;侧效应不可逆;缺乏并发控制)。
三大工程铁律:不信任裸输出(不允许 Agent 自由拼装并执行原始 Shell)、状态必须落盘(长流程状态交外部持久化介质,而非 LLM 上下文)、必须支持逆向回滚(每个正向 Tool Action 都要有原子化的补偿动作)。
案例:1 个月无错迁移 5000 台虚拟机。起点是单机小工具、单次只能跑 4–5 台。策略是「不重写,只包裹」——用 Agent + Harness 把单机工具升维成分布式 Worker 集群。架构是四 Agent + 共享数据库(黑板模式):调度 Agent(只读扫描、8 种状态识别、标准化任务入库)→ 分发 Agent(乐观锁抢占、令牌桶限流、无状态下发以省 Token)→ 监督 Agent(实时监控、根因诊断、自愈重试)→ 验证 Agent(影子测试、业务校验、状态标记与逆向补偿)。
成效(讲者自述):并发吞吐 20×+、长尾报错自愈 97%+、0 安全事故与资损、异构模型路由使 Token 综合成本降低 70%+。
四大黄金法则:Harness 控制(确定性底座)、架构解耦(共享状态比 Agent 间直接通信更稳)、按需选型(高智力模型规划诊断、低成本模型分发校验)、回滚兜底(放弃对 LLM 完美输出的幻想)。
- 定位
- 唯一的「经济学视角」:不问能不能做,问做了划不划算、风险在哪里。
- 核心命题
- 同样的 AI 工具,新建项目像「生产力倍增器」,遗留项目更像「上下文助手 + 风险放大镜」。
两组采纳率对比:新建项目 AI 代码采纳率 60%–80%;遗留项目 37%–50%。前者低存量约束、架构可塑、测试资产可同步建设;后者隐性约束多、耦合度高、回归基线不完整。效率重心也从「降低生产成本」变成「降低理解成本 + 增加验证预算」。
三个外部证据(本场价值最高的部分,因为敢引反面数据):
- METR 2025 随机对照试验:16 名资深开发者、246 个真实任务、平均超过 100 万行的仓库——完成时间增加 19%。
- Stack Overflow 2025(3.1 万份回答):66% 认为 AI 输出「几乎正确,但并不完全正确」;45% 认为调试 AI 生成代码更耗时;46% 不信任 AI 输出的准确性。
- 讲者同时给出边界说明:METR 在 2026 年说明后续实验出现选择偏差,较新工具可能已提速但幅度无法可靠估计。
一行代码的六类风险(界面与交互、业务规则与流程、接口与协议、数据结构与存储、公共函数与组件、技术实现与架构),按影响扩散范围 × 恢复难度两个轴定位。这个二维坐标是整个 B 场最实用的决策工具:同样是「改一行」,界面文案和 SDK 升级的风险差了两个数量级。
方法:用「系统代码画像」当 AI 编码的缰绳——逆向工程识别方法画像、架构影响、调用链、数据实体;再跟踪增量代码覆盖率、为未覆盖代码生成用例、快速定位 AI 生成代码的异常。
- 定位
- 提供历史坐标与伦理维度。技术内容偏综述,但结尾的人文命题值得单拎出来。
- 核心命题
- AI 架构师站在技术与社会交界处,需要同时理解「能力如何实现」与「能力该不该这样实现」。
技术脉络:图灵(1936 图灵机 / 1950 图灵测试)→ 麦卡锡与达特茅斯(学科成立)→ 符号主义(专家系统、知识图谱,可解释但依赖人工构建)与连接主义(神经网络、深度学习,擅长模式识别但黑盒)两条路线 → AI 三要素(Hinton 的算法、CUDA 的算力、李飞飞的数据集)→ Transformer 与 LLM → 世界模型作为下一步方向。
工程视角:从云端智能到云边端协同智能再到端侧智能,驱动力是成本、时延、隐私三件事。端侧存在「不可能三角」——高性能、低资源、低时延,三者难以同时满足;对应三条优化路径:模型优化(剪枝、低秩分解、量化、蒸馏)、系统优化(模型切分、任务调度、资源协同)、硬件优化(近存计算 NMC、存内计算 IMC、NPU 与存储侧协同)。
落地案例:通信网络内生智能——传统系统各模块独立设计(源编码压缩 vs 信道编码加冗余),难以全局优化;端到端自编码器把发射机与接收机当成一个学习系统,可全局优化,但面临通用模型适配与数据质量问题。团队做了基于国产 NPU 的端到端实时收发(NAIRAN),并演示了机械臂遥操作。
——本场最值得抄下来的一句话。讲者给出的方向是:构造能施加社会压力的环境。
按「讲了什么」粗分:讲架构范式的 6 篇(杨成彪、吴昊、阿甘、陆徐洲、苏震巍、黄胜鲁),讲知识与上下文的 3 篇(周小四、张旭海、程杰),讲组织与效能的 3 篇(程哲桥、郑立、崔张伟),讲基础设施与经济的 2 篇(郭峰、姚文广),讲方法论与证据的 2 篇(Haifeng Shen、杨鲲)。架构范式占了近六成——这符合「架构师大会」的定位,但也意味着关于「如何衡量成效」的内容显著偏少,仅有 3 篇给出了可复用的度量方法(Haifeng Shen 的可复现性、黄胜鲁的五级链、郑立的成本模型)。
八条主线:横向合并同类项
把 16 篇按题目读,看到的是 16 件不同的事;按问题读,只有 8 条线。下面每条线给出:它要解决什么、谁在讲、他们之间是互相印证还是互相拆台、对你的项目意味着什么。
工程重心的四次迁移:从「说清楚」到「跑得住」
这条线要解决什么:AI 工程的注意力应该放在哪里。答案不是一个点,而是一条不断外移的线。
黄胜鲁给出的四阶段框架是本次大会的骨架。它的价值不在于分类,而在于每个阶段都标出了「这一阶段解决不了什么」:
| 阶段 | 核心动作 | 这一阶段之后的残余问题 | 谁在本届会上讲它 |
|---|---|---|---|
| Prompt 工程 | 措辞、格式、示例 | 模型不懂业务、无记忆、人是瓶颈 | —(已被视为基线) |
| Context 工程 | 知识供给、检索、上下文装配 | 看到正确信息仍可能错误行动,错误不自愈 | 周小四、张旭海、程哲桥 |
| Harness 工程 | 执行环境:规则、约束、工具、权限、状态 | 能防住单步错误,但长程任务仍不可靠 | 吴昊、黄胜鲁、陆徐洲、苏震巍 |
| Loop 工程 | 心跳、工作树隔离、多 Agent 编排、自动迭代 | 人的判断缺位,成本转为后期返工与事故 | 杨成彪(规则固化闭环)、黄胜鲁 |
一个可以自测的判断:如果你的团队 80% 的 AI 投入仍在 Prompt 和模型选型上,那么按这条线上讲者的口径,你大概落后两到三个阶段。这不是危言,而是 Argan 那 52 页 bug 案例的直接来源——他们的 MVP 阶段就是「只关注需求,架构放手交给 SDD + 大模型」。
但要注意这条线的一个隐性前提:四阶段是叠加而非替代。吴昊的系统里仍然需要 prompt(分发 Agent 要下指令),苏震巍的系统里仍然需要上下文(本体数据),只是这些东西不再被当作主要矛盾。
把团队的 AI 工程能力盘点表按这四个阶段做一遍,逐项标注「已覆盖 / 部分 / 缺失」。多数团队会发现自己在第 2 阶段有大量投入、第 3 阶段几乎空白——而第 3 阶段恰好是本届 16 场演讲里被讨论最多的。
确定性搬出模型:同一个主张的六种载体
这条线要解决什么:怎么保证「不能错的事」真的不错。这是全场共识度最高的一条,也是落地分歧最大的一条。
| 载体 | 主张者 | 机制 | 防住什么 |
|---|---|---|---|
| 类型系统 | 阿甘 | 枚举值对象、必填不可变对象、聚合根 Validator | 非法状态在代码里写不出来 |
| 规则引擎 | 杨成彪 | SOP 约束构成 DAG,输出前校验,越界拦截并返回违规原因 | 模型提出的方案越界 |
| 沙箱与回滚 | 吴昊 | 只读扫描、令牌桶限流、Saga 逆向补偿、人机割接锁 | 不可逆的破坏性动作 |
| 降级机制 | 姚文广 | AI 结果只作「建议值」写测点;异常时自动退出增强层 | 物理世界失控 |
| 预编程 | 苏震巍 | 部署前固化能力,运行时摆脱实时 AI 依赖 | 幻觉与实时推理抖动 |
| 策略与审批 | 陆徐洲 | 身份→策略判定→人工审批→审计留痕,高风险动作必经人 | 越权与不可追溯 |
这六种做法不是竞争关系,而是栈的不同层。把它们叠起来才是完整答案:类型系统管「写不出来」,规则引擎管「想不过去」,沙箱管「做不成灾」,降级管「坏了不塌」,审批管「谁批准」,预编程管「不依赖」。
本场最锋利的一句来自杨成彪,它解释了为什么这不是过渡方案:
概率域与确定域之间有一条边界。更强的模型不会让这条边界消失,只会让它往下移:概率域变大,确定域收缩,但永远不为零。所以它不是过渡方案,而是一条长期的架构原则。 杨成彪 · 面向生产环境的本体驱动智能体架构
一个需要警惕的反例来自 Haifeng Shen:他证明了「加强约束」不一定带来稳定——开启 thinking 反而显著降低输出一致性,加防御 prompt 的影响不稳定。这说明「加一层保护」本身也要被验证,而不是默认有益。两者的交集结论是:约束要加在确定性机制上(类型、规则、沙箱),而不是加在概率机制上(更长的 prompt、更强的推理)。
做一张「确定域清单」:列出你的业务里哪些判断如果错了会造成不可逆损失。对每一项标注它当前由什么机制保障(提示词?代码?流程?人?)。提示词保障的项,就是需要迁移的项。
状态与记忆外置:权威事实必须住在模型之外
这条线要解决什么:长任务跨步骤、跨会话、跨人时,谁知道「现在到哪一步了」。
吴昊把它写成铁律:「长流程状态必须交由外部持久化介质管控,而非 LLM 上下文。」他给了一个让人心惊的算术:单次成功率 95%,跑 10 次降到 59.87%。这不是模型变差,是状态在链路中衰减。
四种外置形态,各有适用场景:
| 形态 | 代表 | 存的是什么 | 适合的任务 |
|---|---|---|---|
| 数据库状态机 | 吴昊 | 任务队列、分布式锁、Checkpoint 偏移量、异常上下文 | 高并发批处理、可重放的运维动作 |
| 运行检查点 | 陆徐洲 | runId、tool result、approval、resume point | 含人工审批的长任务、需要断点恢复 |
| 时间轴状态图谱 | 杨成彪 | 以实体为锚点的事件序列,带时间戳与因果 | 跨班组、跨系统的因果追溯 |
| 业务上下文对象 | 程哲桥 / 张旭海 | 客户背景、商机进展、企业对象与关系 | 销售、服务、企业知识类工作 |
四者的共同点是「唯一事实源」;不同点在「事实的粒度」。吴昊存的是执行进度,陆徐洲存的是任务状态,杨成彪存的是物理世界发生了什么,程哲桥存的是业务对象的演变。它们可以共存于一个系统:执行层用状态机,业务层用上下文对象,追溯层用事件时间轴。
一个必须回答的工程问题(杨成彪提得最清楚):本体/上下文系统与业务系统的权威性关系。他的答案是:业务系统是事实的权威源,本体是状态的聚合视图;冲突时以业务系统为准,并记录差异。这个定调避免了「双写不一致」的经典陷阱。
检查你的 Agent 是否把关键状态存在对话历史里。如果是,那么任何一次上下文压缩、会话重置、模型切换都会造成状态丢失。判断标准很简单:能否在全新的进程里,仅凭外部存储恢复任务?不能,就还没做到外置。
知识的结构化:从「能查到」到「能判定」
这条线要解决什么:让系统不只是「知道」,而是能回答「能不能做、按什么顺序做、参数是多少」。
这是本届最有意思的一组对照。三篇讲者从不同起点出发,最后在同一个判断上会合:非结构化检索撑不住操作类任务。
杨成彪的路线最激进,直接给出技术路线对比表:
| 路线 | 能力边界 | 撑不住生产的地方 |
|---|---|---|
| 纯 Prompt | 单轮理解与生成 | 无状态、无约束、无审计,不能用于操作类任务 |
| RAG / Vector DB | 文档问答、相似度召回 | 无结构、无状态、无约束;参数靠猜,跨系统寻址失效 |
| GraphRAG | 多跳关系推理 | 多为静态图谱——无事件时间轴、无约束层,仍无法判定「能不能做这个动作」 |
| Ontology-driven | 语义+状态+约束+寻址四合一 | 代价:建模投入高、冷启动重、需领域专家——必须承认的取舍 |
他强调两个关键设计:事件与约束必须是「一等公民」。只建「实体+关系」的图谱,最多是个更好的搜索引擎——没有事件就无法追溯状态,没有约束就无法收敛动作。
周小四的路线更务实:RAG 与本体不是二选一。「RAG 提供证据,本体统一对象、口径和规则,共同支撑同一任务。」他的本体例子非常具体——「上季度华东区金额超过 50 万元、但未完成二级审批的采购合同有哪些?」,四个概念(华东区、合同金额、采购合同、超额审批)在没有语义定义时都有歧义,有了定义才可查。
张旭海的路线最上溯:不满足于「业务语义层」,而是把企业本身建模成三层(战略与经营 / 组织与流程 / 系统与运行),再向下提供任务上下文包。他的商业案例是退款积压——沿对象关系走比关键词搜索更快更准。
还有两位用「语言」而非「图谱」解决同一问题:阿甘的统一语言(术语卡:一词一义、一义一词、语言进代码),姚文广的私域语料(历史工程代码、FB 库、工艺手册、P&ID、联锁表、企业命名规范)。这说明结构化的形式不止一种——可以是本体图,也可以是一份被 AI 每次必读的术语表。
先判断你的任务属于哪一类。如果只是「问答与摘要」,RAG 足够;如果需要「判断动作是否允许、参数取自何处」,就绕不开对象、口径、约束三件套。杨成彪的冷启动建议值得照抄:不必先建全域本体——拿一个场景跑通「意图→约束→规划→执行→回写」的完整循环,再谈推广。
验证与可观测闭环:凭什么相信它做对了
这条线要解决什么:Agent 说「完成了」之后,你怎么知道它真的完成了。这是从 Demo 到生产的最后一道门,也是本届被讨论得最分散、最缺乏统一标准的一条。
四套验收语言,互相补充:
| 提出者 | 验收框架 | 关键判断 |
|---|---|---|
| 陆徐洲 | 业务验收门:轨迹 / 终态 / 证据 / 成本 | 行动能否复现、权威记录是否改变、结论能否回溯、代价是否在边界内 |
| 杨成彪 | 四类落盘数据 | 意图解析结果、子图快照、约束命中日志、动作执行与回写记录 |
| 黄胜鲁 | 五级递进链 | 可观测 → 可度量 → 可评估 → 可决策 → 可进化,缺一级就断 |
| Haifeng Shen | 重复运行度量 | 同条件跑 n 次,用四维相似度衡量稳定性;判官另算顺序敏感性 |
杨成彪的「约束命中日志」是本届最有洞察力的单一指标。他给出的读法是双向的:命中率异常升高,说明模型输出在漂移;异常下降,可能是约束被绕过。绝大多数团队的监控只看成功率,而成功率在约束被绕过时反而会「变好」——这是一个会伪装成进步的故障。
Haifeng Shen 补上了另一半:正确率与一致性是两个独立维度。他的判官实验提供了绝好的证据——交换 A/B 顺序后,四个判官的可复现正确率(ReproCorrect)都显著变化,而判断收敛度(Repro)变化很小。这意味着一个「每次都判得很稳定」的裁判,可能每次都稳定地判错。
程哲桥给了一个更朴素的版本:把验收条件写成「前提 / 动作 / 结果 / 证据」四件事,并分层验证——基础检查(代码与接口契约)、功能验收(完整用户故事)、页面冒烟(关键入口与操作链)、定期回归。开发环境与工具权限要跟上,让 Agent 能自己跑通验证,而不是每一步等人转述结果。
检查三件事是否都在:① 轨迹可重放(同样的输入能否复现同样的决策路径);② 终态可核验(是否以业务系统的权威记录为准,而不是 Agent 的自述);③ 异常可发现(有没有一个指标,在系统悄悄走偏时会变差)。第三项最常缺失。
Token 与成本经济学:当调用量成为主要成本项
这条线要解决什么:Agent 化之后,Token 消耗会以数量级上升,成本结构随之改变。
郭峰提供了宏观框架:Agent 是 Token 放大器——Super-agent 约 25 倍、Agentic Coding 可达 1000 倍;而在多 Agent 软件工程中,反复的 Code Review 阶段吃掉 59.4% 的消耗。他的成本结构拆解(GPU 折旧 60%、仅 8% 变动)解释了为什么「调度折价」是毛利率提升的最短路径。
吴昊提供了微观证据:四个 Agent 采用异构模型路由(高智力模型做规划诊断、低成本高吞吐模型做分发、强代码模型看日志、轻量模型做校验),Token 综合成本降低 70%+。同时还用「分发 Agent 无状态」这一设计省 Token——下发指令后不跟踪 Worker 状态。
周小四提供了另一种杠杆:用 9B 决策模型替代 30B 大模型做意图分类与片段筛选,准确率高 8 个百分点、延迟低 50.6%。逻辑是「把可独立评测的判断节点从大模型里拆出来」。
郑立提供了反面视角:AI 在遗留系统上的经济性并非天然为正。新建项目 AI 采纳率 60–80%,遗留项目只有 37–50%;METR 的实验甚至显示复杂度高 19%。他的结论是「效率重心从降低生产成本,转为降低理解成本、增加验证预算」。
AI 的成本优化有四个不同的杠杆,作用在不同层面:基础设施层(利用率、每瓦 Token)、路由层(按角色选模型)、架构层(无状态省 Token、缓存复用)、流程层(判断哪些工作根本不该用 AI)。多数团队只用了第二个。
组织与人机分工:人的位置从「操作者」变为「定义者 + 兜底者」
这条线要解决什么:人到底该在回路里的哪个位置。
四种表述,指向同一个结构:
- 黄胜鲁的双环:内环 Agent 执行(正确地做事),外环人做目标设定、复杂决策、质量兜底、经验沉淀(做正确的事)。人可以在环内(HITL),也可以在环上(HOTL)。
- 陆徐洲的责任表:业务负责人(目标、KPI、风险边界)、领域专家(规则、例外、验收案例)、数据治理(口径、来源、分类)、平台与安全(身份、权限、回滚)、一线人员(交接、确认、接管、反馈)。每个角色在「委托前 / 运行中 / 复盘时」三个时点各有分工。
- 姚文广的边界:AI 做标准化、重复性工作(代码草稿、标签库、画面骨架、编译纠错、回归验证),工程师 100% 把关安全逻辑、非标工艺、冗余降级、最终投运。
- 苏震巍的分化预测:FDE 将分化为「编排设计工程师」与「测试/验收工程师」两类角色。
最值得注意的一条实践原则来自陆徐洲——权限随证据逐级扩大:只读建议 → 受限行动 → 跨系统闭环,每一级都需要新的验收证据才允许升级。这比「先全自动再逐步收紧」更安全,也比「永远只读」更有价值。而且它给出了明确的升级门槛:明确定义的任务终态、专家标注的真实样本、工具权限收敛到任务、关键动作人工批准、生产轨迹可重放、可回滚可审计、故障升级责任明确。
吴昊提供了另一端的极端案例:默认全自动无人值守,仅在任务多次重试失败时挂起(Suspend),推送质检报告到 IM,由运维专家归因后再决定恢复或逆向清理。这是「默认自动化 + 异常按需干预」的反向设计——适合高责任但可回滚的运维场景。
陆徐洲的「逐级扩权」适合不可逆、跨系统、涉及资金或人身安全的场景;吴昊的「默认全自动 + 异常挂起」适合可回滚、可重试、有明确补偿动作的场景。判断依据是杨成彪那条原则的反面:如果错了能撤销,就可以放权;如果错了撤不回来,就必须留人。
物理世界的边界:当 AI 的动作会撞到真实物体
这条线要解决什么:软件里错了可以重跑,物理世界里错了会报废、会停机、会伤人。这是唯一一条把「延迟」和「故障域」当作一等公民的线。
三位讲者的分工恰好覆盖了三个层次:
| 讲者 | 层次 | 核心机制 |
|---|---|---|
| 姚文广 | 控制器层(毫秒) | 双路径隔离 + 两条红线:AI 不侵入扫描周期、必须有降级机制;AI 结果只作「建议值」 |
| 苏震巍 | 操作系统层(毫秒到分钟) | 预编程 + 后编程、三层编排、三层仿真;设备能力抽象到不出现型号名 |
| 杨鲲 | 端侧与网络层 | 云边端协同、端侧不可能三角、近存/存内计算;通信内生智能与遥操作 |
三者共同的技术判断是「把 AI 放到一个可以被切断的位置」:姚文广的降级机制、苏震巍的预编程、杨鲲的端侧推理,本质都是让 AI 成为可插拔的增强层,而不是不可或缺的控制环。姚文广那句话可以当作整条主线的一句话总结:「AI 是增强,不是依赖。任何 AI 路径失效,PLC 都能独立、安全地继续运行。」
苏震巍的三层仿真值得单独强调,因为它回答了一个软件架构师通常不熟悉的问题——物理世界的能力怎么验收。他的答案不是「测试通过率」,而是分层可验证的通过标准:L1 逻辑仿真跑 100 次无死锁无越界;L2 半实物关键路径时延误差小于阈值;L3 真实试验台覆盖足够多的失败用例。每一层跳过的后果都被明确写出来了(「单设备都对,一起跑就撞」「白天通过,夜班出事」)。
即使你不做硬件,这条线也有可迁移的部分:把「跳过某一层验证会发生什么」写成明文。这是把测试策略从「尽量多做」变成「知道不做会死在哪」的最有效方式。
八条线的相互关系
这八条不是并列的清单,它们之间有明确的依赖结构。本报告的读法是:
4.6 成本经济学 · 4.8 物理边界
前者决定「值不值得做」,后者决定「错了能不能承受」。这两条不解决的方案,其余六条做得再好也会被否决。
4.2 确定性 · 4.3 状态 · 4.4 知识
这三条共同构成「把模型包起来」的骨架:约束、记忆、语义。缺任意一条,系统都会在生产环境里露出破绽。
4.5 验证 · 4.7 组织 · 4.1 迁移
前两者让系统能自我修正、让组织能承接,最后一条给出演进路径。这是让前两层不腐化的机制。
共识、分歧与空白
一场会议的真正信息量,不在大家都说了什么,而在「大家都同意什么」「谁和谁对不上」「什么问题没人碰」。
5.1 七条共识
下表按「支持强度」排序。计数为本报告作者逐篇判读的结果,强论述计 1,顺带提及计 0.5,未涉及不计。
| 共识 | 最强的一句话表述 | 出处 |
|---|---|---|
| 模型之外才是主战场 | 「约 70% 的功夫在模型之外。模型越同质、越不值钱,差异化越往模型外走。」 | 周小四 |
| 关键约束必须外置 | 「把约束写在模型外面。Prompt 只能换来大概率的合规,规则引擎才能给出确定的合规。」 | 杨成彪 |
| 状态不能只存在上下文里 | 「长流程状态必须交由外部持久化介质管控,而非 LLM 上下文。」 | 吴昊 |
| 知识必须结构化才能支撑决策 | 「RAG 解决的是知道;生产要解决的是能不能做、按什么顺序做、参数是多少。」 | 杨成彪 |
| 可观测是进化的前提 | 「没有可观测,选择等于瞎猜,进化等于盲人摸象。」 | 黄胜鲁 |
| 人必须保留最终决定权 | 「关键决定与接管机制由人掌握。」 | 陆徐洲 |
| 护城河是私域知识而非模型 | 「AI Coding 的护城河,是工业私域知识与工艺资产,不是单纯的大模型。」 | 姚文广 |
5.2 三处真实分歧
以下分歧并非措辞差异,而是会导致不同架构选择的实质分歧。本报告不对谁对谁错下结论,只把两边的适用条件摆出来。
分歧一:多 Agent 协作,还是单体编排?
吴昊用四个 Agent(调度/分发/监督/验证)以黑板模式协作,明确说「基于共享数据库的异步协作是最稳固的通用范式」。
黄胜鲁用四类 Agent(总控/决策/管理/业务)分层解耦、分形同构。
姚文广用五个 Agent(规划/编码/验证/修复/组态)分工。
杨成彪的架构里只有一个 Planner + Constraint Checker + Reflexion 的编排层,其余能力由「本体中枢」以服务化方式提供,而不是拆成多个 Agent。
周小四把「单 Agent vs 多 Agent 之争」列为 2025 年的叙事,暗示这已不是 2026 年的主要矛盾。
本报告的读法:两者的区别不在「几个 Agent」,而在协调成本放在哪里。多 Agent 方案把协调成本放在通信协议上(需要 A2A、需要共享状态、需要防死锁);单体方案把协调成本放在模型内部推理上(需要更强的模型、需要约束引擎兜底)。任务可分解且子任务差异大 → 多 Agent;任务耦合紧且需要全局一致性 → 单体编排。
分歧二:本体 / RAG / 纯上下文,谁是正解?
| 立场 | 主张者 | 论据 | 代价 |
|---|---|---|---|
| 必须上本体 | 杨成彪 | RAG 无状态无约束无寻址,GraphRAG 也是静态图谱,判定不了「能不能做这个动作」 | 建模投入高、冷启动重、需领域专家 |
| RAG + 本体组合 | 周小四 | RAG 提供证据,本体统一对象口径规则,两者共同支撑同一任务 | 需要维护两套索引与语义定义 |
| 企业上下文系统 | 张旭海 | 不止业务语义,还包括战略、组织、运行现实三层建模 | 维护成本高——两年前正是因此失败 |
| 语料 + 术语表即可 | 姚文广 / 阿甘 | 私域历史工程与工艺手册 + 企业命名规范,就足以让 AI 生成可用代码 | 结构化程度低,依赖模型理解力 |
本报告的读法:四者其实是结构化程度的光谱,而不是互斥的技术路线。选择的依据是任务的错误成本:错了重来 → 语料 + RAG 够;错了要停机 → 需要对象与口径;错了会造成不可逆损失 → 需要约束层与状态时间轴。
杨成彪自己在对比表里写了「代价:建模投入高、冷启动重,需领域专家——这是必须承认的取舍」。张旭海的失败复盘也印证了同一点。任何声称「本体很轻」的说法,都与这两位的表述不符。
分歧三:上下文越多,系统越稳吗?
这是本届最有价值的一处分歧,因为它有实验数据,而不是观点。
周小四、张旭海、程哲桥的方案都建立在「给足上下文」上:按任务装配上下文、企业上下文系统、客户背景 + 商机上下文双轨维护。
杨成彪则加了限定:不做全图加载,以目标实体为锚点按关系与时序半径增量拉取局部子图——这是控制时延与 Token 成本的关键。
Haifeng Shen 的实验显示:仓库上下文检索对 5 个 backbone 中的 4 个提升可复现性,但 Codex 在自包含任务上反而下降。他的结论是「更多上下文并非天然稳定,其收益取决于任务依赖度与 backbone 对检索的响应」。
两者的交集:上下文的价值取决于「任务是否真的需要它」。杨成彪的「局部子图」与 Haifeng Shen 的「任务依赖度」说的是同一件事——上下文不是越多越好,而是越准越好;而准不准取决于任务,不取决于数据量。
5.3 五处空白
以下问题在 16 场演讲中都没有得到回答,而它们恰恰是落地时最先撞上的墙。
确定性的量化门槛
大家都在说「要确定性」,但只有 Haifeng Shen 给了可复现性的度量方法,只有杨成彪给了约束命中率这一个运行指标。剩下的是定性判断。
缺的是:不同风险等级的任务,可复现性应达到多少才算达标?没有行业基准,每个团队只能自己定阈值。
成本度量的统一货币
郭峰用 Token 计价(每瓦 Token、每百万 Token 成本),郑立用软件工程经济学(功能点、人天、成本区间),黄胜鲁谈流程节点与效率倍数。三套语言无法换算。
缺的是:当一个团队要论证「上本体系统值不值」时,用哪套账本算 ROI?
跨组织的知识迁移
杨成彪提了「行业本体共享 + 工厂本体私有」的双层结构,张旭海提了「数字员工模板集市」,但都没有说明:共享的部分如何标准化?谁维护?冲突如何裁决?
缺的是:行业级本体与 Skill 的互操作标准。目前每家公司都在重复造自己的一套。
责任的法律边界
陆徐洲说「人保留最终决定权」,姚文广说「工程师 100% 把关」,但这些是工程原则,不是责任划分。当 Agent 的建议被人批准后出了事,责任在谁?
缺的是:可审计的决策链如何转化为可追责的证据链。这一点在医疗、金融、工业三个高风险领域都是空白。
小团队的可负担性
本届高质量的方案——本体四中枢、四 Agent 黑板、三层仿真、六层平台——几乎都需要专门的平台团队。10 人以下的团队怎么办?
缺的是:这些能力的「最小可行版本」。哪些是第一周就该做的,哪些可以等到有规模再说。本报告第 07 章的路线图,是对这一空白的补充尝试。
安全与对抗性风险
16 场演讲中,只有 Haifeng Shen 提到了 prompt injection 防御(而且是从「对可复现性的影响」角度),以及澳大利亚的 Agent 越界事件(OpenAI agent 访问 Medicare 非公开数据)。没有任何一场系统性地讨论 Agent 自身的攻击面。
考虑到本届有大量 Agent 被赋予写权限、执行权限、跨系统调用权限,这是一个显著的空白。
实践指引:从共识到动作
这一章把前文的判断翻译成可以开会讨论、可以写进技术方案、可以逐条打勾的东西。
6.1 给架构决策者的七条
| # | 主张 | 理由与出处 |
|---|---|---|
| 1 | 先划概率域与确定域的边界,再选技术 | 杨成彪的边界原则:更强模型只会让边界下移,不会让它消失。边界画不出来,后面所有选型都是猜。 |
| 2 | 把「失误能不能撤销」作为放权依据 | 吴昊三大铁律的底层逻辑:每个正向动作都要有补偿动作。能撤销就放权,不能撤销就留人。 |
| 3 | 平台的管理单元从「调用」改为「任务」 | 陆徐洲:一次任务可能包含多次模型调用、工具调用与人工介入,平台要保存整条执行链的状态。 |
| 4 | 知识建设从「一个场景跑通全链路」开始 | 杨成彪:小场景全链路胜过全域半成品。一个场景从意图到回写完整跑通,比五个场景停在对话层更有价值。 |
| 5 | 把验收标准写在开发之前 | 程哲桥:把用户故事转成可操作、可观察的验收条件(前提/动作/结果/证据),Agent 才知道目标是什么。 |
| 6 | 先建立可观测,再谈进化 | 黄胜鲁的五级链:可观测→可度量→可评估→可决策→可进化。跳过任何一级,进化都是盲目的。 |
| 7 | 给「不确定性」留出预算,而不是留出幻想 | 郑立:遗留项目的 AI 收益被两头挤压——开发辅助变弱、回归风险上升,所以要增加验证预算,而不是假设提效自然到来。 |
6.2 工程检查清单(46 项)
按四条主线分组。每项都是可以明确回答「是/否」的判断题,答「否」的地方就是下一步该动的地方。
A · 确定域(12 项)
- 列出了一份「错了会造成不可逆损失」的判断清单
- 对每个关键判断标注了当前由什么机制保障(提示词/代码/流程/人)
- 关键业务规则有唯一的权威实现,不存在三份副本
- 核心域逻辑有独立测试与不变量保护
- 非法状态在类型层面写不出来(枚举、值对象、必填校验)
- 跨字段约束由聚合或验证器保证,而非调用方自觉
- 所有入口(HTTP/CLI/批处理/导入)经过同一套保护
- 跨模块依赖有显式契约,不存在跨层 import 私有函数
- 核心表对外只暴露所需字段的投影,不 SELECT *
- AI 的输出在写入前经过外部校验,而不是直接执行
- AI 失效时有明确的降级路径,且该路径不依赖 AI
- 约束被命中时,违规原因被记录而非被吞掉
B · 状态与记忆(12 项)
- 关键任务状态存在外部存储,而非对话历史
- 在全新进程中仅凭外部存储可恢复任务(已实测)
- 每个任务有唯一 ID,可跨步骤、跨会话追踪
- 任务状态流转有明确的状态机定义
- 有检查点机制,崩溃后可从最近确认点继续
- 恢复前会检查对象当前状态,避免重复执行写入
- 状态的权威源是业务系统,本体/上下文是聚合视图
- 权威源与视图不一致时有明确的处理规则(以谁为准、如何记录差异)
- 时间轴类数据明确了 Create/Update 的判定规则
- 上下文按任务增量加载,不做全量注入
- 重要上下文有使用条件(来源、用途、有效期、责任人)
- 不同场景使用不同的上下文投影,而非共享一张宽表
C · 知识与语义(11 项)
- 核心业务术语有唯一含义,且写进了 AI 每次必读的位置
- 同一概念不存在两个名字(如 appointment 与「任职」混用)
- 术语表在 context/spec 的头部,而非埋在长文档中段
- 验收条件中重复了关键的禁则
- 关键指标有明确的定义:起止时点、统计范围、计算规则、责任人、版本
- 对象与数据表、API 之间有显式映射
- 检索结果带来源与版本,可回溯
- 知识库有失效版本清理与质量分级机制
- 召回遗漏、内容不适用、证据不足三类问题分开度量
- 针对「证据不足」,系统明确选择追问而非强行作答
- 知识更新有评审与灰度流程,不是自动写入生产
D · 验证与观测(11 项)
- 每类任务都有明确的「完成」定义(业务终态)
- Agent 的自述「完成」不作为验收依据
- 决策轨迹可重放:记录输入、检索、决策、动作、结果
- 关键指标除了成功率,还有漂移与拦截类指标
- 有异常发现机制:系统走偏时会有一个指标变差
- 多步骤任务记录了每步证据的快照
- 对模型/提示词变更做了 A/B 或重复运行验证
- 评测覆盖一致性(可复现)而不只是正确率
- 评测集包含历史失败案例,并持续补充
- 失败归因区分「实现没做到 / 环境数据权限没就绪 / 产品预期需重确认」
- 有能力回滚版本与配置,且回滚经过演练
6.3 十一个反模式
全部来自本次大会讲者的真实踩坑记录。
- 把架构放手交给大模型。阿甘的 MVP 阶段原话:「对大模型能力了解不足,只关注需求,架构放手交给 SDD + 大模型。」结果是接近大泥球的架构,每个新功能都破坏旧功能。
- 只收集使用数据,不定义业务价值。程哲桥第一次建设的教训:采集更多底层数据也无法补上「这份报告有没有被采用」这层定义。
- 在不同入口上实现不同强度的保护。阿甘的 CLI 脚本直接写 SQL,绕过全部不变量保护。「人死了还在写诗」的 bug 就是这么来的。
- 用更长的提示词解决确定性问题。共识反例:Prompt 只能换来大概率的合规,规则引擎才能给出确定的合规。
- 让状态住在对话历史里。吴昊的算术:95% 单次成功率,跑 10 次只剩 59.87%。
- 在定义不清的工作上做 AI。程哲桥:组织原本就没有把目标、结果和评价标准说清楚,AI 只是把模糊放大。
- 追模型规模而不修私域知识。姚文广:通用大模型不懂工艺联锁、不懂 IEC 61131-3、不知道你项目里的泵阀叫什么。
- 在 Demo 上验收。杨成彪的六项对照:Demo 环境「这次答对了」即可,生产要求同一输入同一输出。
- 全图加载上下文。杨成彪:控制时延与 Token 成本的关键,是以目标实体为锚点做局部子图增量拉取。
- 只看成功率,不看约束命中率。杨成彪:约束被绕过时,成功率反而会变好——这是会伪装成进步的故障。
- 把可复现性当作 backbone 的属性。Haifeng Shen:可复现性是「配置好的流水线」的属性;换模型不解决问题,改配置才行。
6.4 给个人的能力地图
如果把本届内容按「一个 AI 架构师需要会什么」重新组织,会得到四层能力。这四层与第 4.1 节的四阶段工程演进是对应的。
把意图写清楚
术语定义、验收条件、禁则声明、示例。这一层已经沦为基线,单独掌握不再构成竞争力。
对应讲者:全体(默认能力)
把正确的信息送到正确的位置
检索、切分、语义层、上下文装配、来源与版本。这一层是当前的竞争焦点之一。
对应讲者:周小四、张旭海、程哲桥
让错误在结构上不可能发生
类型系统、规则引擎、沙箱、回滚、权限、审批。这一层是本届共识的中心,也是多数团队的空白。
对应讲者:杨成彪、吴昊、阿甘、陆徐洲、姚文广
让系统在使用中变强,且不失控
可观测、度量、评估、灰度、知识回流、规则固化。这一层决定三年后你还在不在牌桌上。
对应讲者:黄胜鲁、陆徐洲、杨成彪
如果你只能补一块能力,补 L3。理由很简单:L1 已经商品化,L2 有成熟产品可买,L4 需要组织支持,只有 L3 是「想清楚了就能在自己项目里立刻做」且「做了就有结构性收益」的。阿甘那 52 页的价值,正在于它证明了 L3 的缺失会带来什么。
90 天落地路线图
这是本报告对第 5.3 节「空白 05:小团队的可负担性」的回应。方案不是把大佬们的体系缩水,而是按依赖顺序挑出「先做就有效」的部分。
把「不能错的事」找出来,并给它一个位置
动作:
- 列出一张确定域清单:所有「错了不可逆」的判断(资金、权限、对外承诺、物理动作、合规)。
- 对每一项标注当前保障机制。若标注是「提示词」,它就是要迁移的对象。
- 画出系统的入口清单,检查是否所有入口经过同一套保护(阿甘的 CLI 后门检查)。
- 整理一份术语表:20–40 个核心业务词,每个词给「是什么 / 不是什么 / 归属哪个模块 / 代码里叫什么」。
验收标志:确定域清单 v1术语表进入 AI 必读位置入口审计报告
这一个月不写新代码。阿甘的教训是:没有边界时,AI 会走最短路径实现,写得越快,腐烂越快。
让第一个场景「意图→约束→执行→回写」跑通
动作:
- 选一个典型场景(不是最小的,杨成彪与阿甘都强调这一点),端到端跑通一次。
- 给这个场景建三层防护:类型层(枚举/值对象/必填)、外部校验层(规则或校验器)、流程层(评审或门禁)。
- 把状态外置:任务 ID、状态机、检查点、恢复逻辑,并用「新进程能否恢复」验证。
- 给这个场景建最小可观测:轨迹、证据快照、一个漂移/拦截类指标。
验收标志:端到端演示可重放新进程恢复实测通过至少一个异常指标
把「验证」和「扩权」变成制度,而不是一次性动作
动作:
- 建立评测集:把第一个场景的历史失败案例全部纳入,形成回归基线。
- 对模型或提示词变更做重复运行验证(至少 10 次),同时看正确率与一致性。
- 定义扩权门槛:从「只读建议」到「受限行动」需要哪些证据,写清楚。
- 建立失败归因分类:实现没做到 / 环境数据权限没就绪 / 产品预期需重确认。
- 复盘一次:这个季度有哪些「被绕过」和「悄悄退化」,进了知识或规则库没有。
验收标志:评测集 v1(含失败案例)扩权门槛文档季度复盘纪要
选型决策树
当团队争论「要不要上本体 / 要不要多 Agent / 要不要自建平台」时,按下面三个问题依次判断。
| 问题 | 如果答案是「是」 | 如果答案是「否」 |
|---|---|---|
| Q1:这个场景的错误会造成不可逆损失吗? | 必须建确定域:约束层 + 状态外置 + 人工审批。此时「轻量方案」不成立。 | 可以先做检索增强与流程自动化,把精力放在覆盖率而非确定性上。 |
| Q2:任务是否需要「判断能不能做、按什么顺序做、参数是多少」? | 需要对象、口径、约束三件套——本体或等效语义层绕不开。 | RAG + 好的切分与重排就够,不必背上建模成本。 |
| Q3:子任务差异大、可独立失败吗? | 多 Agent 分工(共享状态、各自可重试)更合适。 | 单体编排 + 强约束引擎更合适,协调成本低、结果一致性好。 |
阿甘:「选一个典型 change 走完全流程——要『典型』不要『小』。」
杨成彪:「小场景全链路,胜过全域半成品。」
程哲桥:「每一次工作完成以后,组织应该比开始时更了解这件事。」
三句话合起来,就是落地的方法论:选一个足够真实、痛感足够强的场景,把它从意图到验收完整走通一遍,然后把这一遍里学到的东西变成下一次的起点。
方法与附录
8.1 这份报告是怎么做出来的
为了让读者能判断哪些结论可信、哪些需要自行验证,这里完整交代方法与局限。
| 环节 | 做法 |
|---|---|
| 样本来源 | 桌面「PPT」目录下 16 个演示文件(15 个 .pptx + 1 个 .pdf),共 423 页。转换为 Markdown 后进行阅读。 |
| 转换方式 | 逐页提取文字,保留段落层级与版面顺序;表格转为 Markdown 表格;图片、图表、视频单独标注;演讲者备注完整保留。整页为截图的页面,将原图导出并在正文内嵌引用。 |
| 议程核对 | 讲者姓名、机构、职务、场次与现场议程表(桌面上的 xlsx)交叉核对。发现程哲桥的原始文件名为「NJSD 演讲」,但内容与 10.24 A 场议程一致,以内容为准。 |
| 分析方法 | 通读全部 16 篇 → 逐篇提炼主张与证据 → 横向归类为 8 条主线 → 统计支持强度 → 识别分歧与空白 → 导出实践指引。 |
| 引用原则 | 直接引语加引号并注明讲者;具体数字注明来源场次;标注「讲者自述」的数据未经第三方复核;本报告作者的推断单独标记为「本报告的读法」。 |
| 计数口径 | 第 05 章的共识支持强度由作者逐篇判读:明确论述计 1,顺带提及计 0.5。这是主观判断,不同读者可能给出不同数字,重要的是排序而非绝对值。 |
8.2 五项必须说明的局限
图片中的信息未提取
全部 16 篇共有数百张图片,多数是架构图、界面截图、数据图表。本报告的分析只基于文字层。这意味着:某些讲者的完整论证链可能比报告中呈现的更丰富;某些关键图示(如杨成彪的架构总览图、吴昊的系统架构图)本报告只能依据其文字说明来理解。
一篇讲稿无法分析
崔张伟《AI 软件工厂》的 28 页全部为整页图片,无文字层、无备注。本报告对该篇只给出一句基于议程表的定位,未做任何提炼。这是样本的实际缺口,不是分析取舍。
成效数据均为讲者自述
MTTR 4.5h→45min、报废率 0%、并发 20×、Token 成本降 70%、效率 1.5–3 倍等数字,均来自讲者自己的表述,未经独立审计。本报告在每一处都做了标注,但读者引用到自己的方案里时,应视之为「行业里有人做到了这个量级」,而非「这个量级可以被保证」。
主题归类是主观建构
「八条主线」不是大会官方分类,也不是讲者自认的归属。它是一次为了横向比对而做的强行切分。同一场演讲可以同时落进多条线(例如阿甘既在「确定性」里,也在「知识结构化」里),这正是真实方案的形态。
缺少会场问答与讨论
讲稿不含 Q&A 环节。而本次多场演讲(阿甘、杨成彪、苏震巍、杨鲲)都设置了讨论环节。这些现场互动往往是信息密度最高的部分,本报告无法覆盖。
所有结论都可回溯
本报告引用的每一句引语,都可以在桌面 md 目录下的对应 Markdown 文件中,通过搜索关键词定位到具体页码。如果你对某一处提炼有疑问,最可靠的验证方式是回到原文,而不是相信本报告。
8.3 术语表
本报告与原始讲稿中反复出现的术语。定义尽量贴近讲者的原意,而非教科书定义。
| 术语 | 英文 / 出处 | 本报告中的含义 |
|---|---|---|
| Harness | 吴昊、黄胜鲁、陆徐洲 | 包裹模型的外层执行环境:状态持久化、并发限流、工具调用、权限控制、回滚。区别于「框架」,它强调对不确定性的工程约束。 |
| 可复现性 | Reproducibility / Haifeng Shen | 固定输入与条件下,重复运行输出的相似程度。用 CodeBLEU 四维(词法、加权词法、语法、数据流)度量,与「正确性」是两个独立目标。 |
| 确定域 / 概率域 | 杨成彪 | 系统被划分为交给 LLM 的可容错部分,与交给本体与规则引擎的零容错部分。二者之间的边界会随模型变强而下移,但永不为零。 |
| 本体 | Ontology / 杨成彪、周小四、苏震巍 | 不止是知识图谱。杨成彪的定义包含四个中枢:模型(实体/关系/事件/约束)、状态图谱、约束引擎、语义寻址。 |
| 企业上下文 | 张旭海 | 对企业目标、规则、关系和运行现实的系统化建模 = 企业建模 + 持续维护 + 提供依据。 |
| Task Envelope | 陆徐洲 | 可执行任务包:对象与状态、规则与证据、行动与审批、终态与记录。四者齐备,Agent 才能接手。 |
| Context Contract | 陆徐洲 | 上下文契约:一份上下文给谁用、用于哪个步骤、有效到何时、由谁负责。 |
| Blackboard 模式 | 吴昊 | 多个 Agent 不直接通信,全部通过共享数据库读写状态,实现完全无状态解耦。 |
| VpT | 郭峰 | Value per Token。客户视角的价值公式:单位 Token 成本 × Token 效能 × 业务适配度。 |
| FDE | Forward Deployed Engineer / 苏震巍 | 前沿部署工程师:驻场把业务问题翻译成系统方案的角色。本届有两场演讲涉及这一岗位。 |
| 逆向建模 | 程杰 | 从存量源码反向生成设计与需求资产(SPEC),使 AI 获得理解老系统所需的工程知识。 |
| 约束命中日志 | 杨成彪 | 记录哪些候选动作被拦截、违规原因是什么。命中率异常升高说明模型漂移,异常下降可能是约束被绕过。 |
| HITL / HOTL | Human-in/on-the-Loop / 黄胜鲁 | 人嵌入决策环路(参与每一步判断)与人站在环路之上(设定目标与规则,不介入执行)。 |
8.4 结语
回到封面那句话:把不确定关进工程的笼子。这不是本报告发明的主张,而是 16 场演讲在不同语境下反复说出的同一件事——只是每个人手里的笼子不一样:有人用类型系统,有人用规则引擎,有人用沙箱,有人用三层仿真,有人用一份被 AI 每次必读的术语表。
这些笼子没有一个是完美的,也没有一个能覆盖全部场景。它们共同指向的是同一个方法论姿态:不要指望模型变得可靠,要设计一个即使模型不可靠、系统也不会崩的结构。
如果这份报告只能留下一个判断,那就是这句。
这句话在第一场峰会之外的场合还会被讨论一次——见文末「下一站」。
数据来源:桌面 PPT 目录下 16 个演示文件(423 页),经转换为 Markdown 后分析(转换结果见桌面 md 目录)。讲者机构与场次依据现场议程表 AI NATVE 2026 议程 v3.0.xlsx 核对。
报告性质:第三方独立分析,不代表大会主办方、演讲嘉宾或其所代表机构。文中所有观点提炼与归类均为本报告作者的解读。
使用建议:引用讲者原话时请回原文核对;引用本报告的判断时,请注明这是分析而非会议结论。
2026 AI 架构师大会 · 全景分析报告 | 生成于 2026-10-27