夜雨聆风一、这份"整体架构"是怎么来的
上一篇我们说：AI 原生系统本质上就是记忆与关系理解系统——它把全部工作流、决策、业务流程流经智能层，靠记忆理解业务、靠关系理解上下文。那么问题来了：这样一套系统，在架构上到底长什么样？
回答这个问题，我们做了大量的研究：研究了国外 AI 原生产品的三种定位（以客户为核心的记忆系统、以智能体协作为内核的系统、以人机协同为核心的系统），拆解过它们的架构设计（数据怎么接入、记忆怎么组织、代理怎么执行），也对比过各自在六个架构层面上的"有/无/强/弱"。
把这些研究和总结收敛到一起，我们发现：形形色色的产品，底层其实共享同一个骨架。无论哪家、哪种定位，拆到最后都是五块剖面——业务与用户入口、AI 智能体团队、记忆系统、统一数据与知识底座、模型与工具供给——再加上一条贯穿始终的效果回接。这就是 AI 原生系统的整体架构。
先看这张图，再听我们一步步讲清楚它为什么长这样、每个部件是干什么的、以及 10 个能力是怎么从这张图里推导出来的。
而我们之所以今天能谈这套架构，是因为一条成本曲线刚刚翻转——AI 原生的转移，是成本曲线翻转，不是理念偏好。 传统企业软件的第一性成本是"翻译成本"：Beyond PLM 的原话，传统 PLM 实施 "was mostly a translation process"（主要是一个翻译过程）；Lightfield 对应的那一头，是"先定义对象、字段、阶段，再让员工填"。AI 原生把它换成"捕获成本"——先把真实发生的业务连续捕获下来，结构后补。为什么是现在才成立？因为没有 LLM 时，非结构化记忆是死数据，只能靠 schema 强约束把信息压成字段；有了 LLM，记忆第一次成为可计算资产，"先捕获后建模"才比"先建模后填报"更便宜。这条曲线不翻转，AI 原生只是昂贵的理念；翻转了，它才是更省的解法。
二、整体架构图
- 谁在台前。
业务与用户入口在最前——人用自然语言下单、查进度，红线决策留给人（人机协同闸门）；AI 智能体团队在台前干活——领域智能体各管一块，调度中枢统一派活。这就是 S07 说的"智能体、人的所有工作都围绕平台发生"。 - 谁在身后。
记忆系统在身后积累——短期记住本次上下文、长期沉淀知识、把经验复用起来。记忆系统是关键差异：没有它，AI 每次从零开始；有了它，系统越用越懂你。 - 谁在支撑。
数据与知识底座在底层支撑——业务对象统一建模、关系可追溯；模型与工具横切供给——大模型按需路由、标准动作即取即用、治理闸门兜住可控可信可观测。右侧纵向的 ⇄ 效果回接则贯穿五块剖面，把业务结果沉淀回记忆、校准能力，让闭环不断。
把"记忆系统"这个被用滥的词讲精确：记忆 = 事实 + 关系 + 理由 + 时序，四缺一不成立。 传统系统有事实（What，比如"这个零件编号 X"）、有硬关系（外键，比如"X 属于产品 Y"），结构性缺失的是理由（Why）和演化时序（When）——也就是 Beyond PLM 说得最狠的那句："including the context, decisions, and exceptions that requirements documents never capture"（包括需求文档永远抓不住的上下文、决策和例外）——谁反对过、权衡了什么、哪个替代方案被否了。没有这两样，系统记得住"是什么"，记不住"为什么变成这样"。
由此得到一条可以直接用于自检的成熟度判据：一个系统能回答 What（"当前状态是什么"），它是数据库；能回答 Why（"怎么走到这个状态、当时怎么想的"），它才是记忆系统。拿到产品域，检验题就是两句话——"这个零件为什么用 A 供应商不用 B""这个需求为什么被砍掉"。答得上 Why，记忆才真立住。
把这条判据落到可操作的记忆完备度自检表，任何记忆系统上线前都可以照着自测：
五格全答得上 Why，才是真记忆系统；哪一格还停在 What，哪一格就是缺口——它直接告诉你该先补哪块记忆。
把这条判据再往前推一步，就得到 AI 原生架构的同一条护栏：记忆层必须稳定，体验层才可生成。 架构图里哪些该"稳定"、哪些可以"生成"，一条明确切分线（以产品研发为例）——稳定侧：产品结构、版本史、生命周期上下文、权限、可信关系、变更追溯（它们本就是记忆系统的硬骨头，必须扎牢）；可生成侧：UX、看板、校验器、助手、流程边缘、导入导出（它们从稳定的记忆里长出来，随用随生成）。这条线也是前面那张对比图右半边的注脚：右边之所以能"生成代替翻译、复利代替损耗"，前提正是左边那块记忆是稳的。
反过来，错误的做法是：没有共享记忆、没有治理，每个部门用 AI 各自生成一堆应用，最后应用各自为政、数据彼此割裂，记忆反而更碎。造成的后果可能是：接入不全则记忆不全（生成的体验缺根）、AI 判断需人工验证（生成物不能直接信任）、企业级治理待验证（生成规模上来后护栏够不够）。
一句话：稳定的记忆层是体验层能放心生成的前提，没有这条护栏，生成越多、散得越乱。
把整套架构放回公司层面看，它就是 AI 原生公司的运转方式：AI 原生公司致力于让工作可观察、可查询、并持续改进——它不止于把任务自动化，更致力于创建循环。循环长这样：
工作产生数据 → 数据构建上下文 → 上下文帮助 AI 推理 → AI 提出行动方案 → 人类审核与修正 → 系统从结果中学习。
对应到这张架构图，它正是右侧那条反馈回路在每一轮里同时完成的事：智能体团队执行工作、产生数据；记忆系统把数据沉淀成上下文；再次推理、提出动作方案；人机协同闸门让人类审核修正；反馈闭环把结果学回记忆。可观察、可查询、持续改进不是三个口号，而是这条回接主线一遍遍转出来的结果——转得越久，系统越懂这家企业。 下一节的对比图，画的也正是这条循环在"传统"与"AI 原生"两种做法下的不同命运。
三、新老架构的对比（以 PLM 为例）
光看"AI 原生架构长什么样"还不够直观——把它和传统架构摆在一起，差别才震得动认知。下面这张图，左边是传统信息系统实施过程，右边是 AI 原生架构：
图：左边是"翻译式"实施的样子——一步步丢上下文、循环回到变更请求；右边是 AI 原生方式——产品记忆在中央，工作流、界面、智能体、校验都从记忆里生成，临时缺口由注册器补位，最终"自适应契合、持续优化"。
这张图把新旧两种架构的本质差异画成了两列，读三遍就通：
- 左边（传统信息系统实施）
需求收集 → 数据建模 → 配置 → 定制 → 部署 → 变更请求……每一步都是"翻译"——把公司现实翻译成系统配置。翻译一次丢一层上下文，走完全程 2–36 个月，最后得到一个"通用结果，与企业契合度差"的系统。它没有记忆，一切从头开始，改一次再丢一次。 - 右边（AI 原生架构构建）
一切围绕产品记忆这个中心。CAD、ERP、遗留系统、门户对话、外部源持续喂给它；它长出工作流、界面规则、智能体、校验；每次产出经"人工审核 + 治理（HITL 闸门）"再把审核结果记回记忆——形成"记忆持续增强"的闭环。周期从天到周，上下文保留并复利累积。
三个关键词点透这张图：
- 记忆是中心，不是边缘。
左图没有记忆，右图一切围着记忆转。有没有记忆系统，就是新旧架构最本质的分野——这也是为什么把"记忆系统"放在整体架构图的正中。 - 生成代替翻译。
左边靠人一遍遍翻译需求；右边靠记忆喂养、系统自动生成工作流/界面/规则/智能体，人只做审核与治理。 - 复利代替损耗。
左边每步丢上下文（损耗）；右边每次使用都沉淀新记忆（复利）。时间越长，右图越贴企业，左图越偏离企业。
四、从架构图推导出 10 个能力
图看明白后，能力不是拍脑袋数的——图上的每一块剖面，都对应一组必须有的能力。我们逐块拆：
| 能力 8：自然语言交互（对话式作业） | ||
| 能力 9：人机协同与信任边界 | ||
| 能力 5：端到端自主执行 | ||
| 能力 6：多智能体协同编排 | ||
| 能力 7：事件驱动自我进化 | ||
| 能力 3：上下文分层注入 | ||
| 能力 4：记忆生命周期治理 | ||
| 能力 10：反馈闭环（效果回接） | ||
| 能力 1：粒子级数据建模 | ||
| 能力 2：知识自动构建 |
所以，10 个能力 = ①入口长出 2 个 + ②智能体团队长出 3 个 + 🧠记忆系统长出 3 个 + ③数据底座长出 2 个。它不是十个并列的功能清单，而是从架构图里一块块"长"出来的——这就是先画图、再数能力的意义。
（注：这 10 个能力按"架构部位"编号 1–10，便于从图里数出来；而 S10–S19 十篇深度文章按"记忆优先调用序"展开——#1 写库即构建 → #2 记忆治理 → #3 粒子 → #4 上下文 → #5 Action → #6 编排 → #7 门户页面 → #8 进化 → #9 反馈 → #10 能力落地审计。调用序是阅读与构建的先后，架构编号是能力在图里的位置，二者指向同一套能力、只是排序视角不同。）
那第 ④ 块"模型与工具供给"呢？它是横切供给底座（大模型、标准动作库、治理闸门），不单独构成一个能力——它决定系统"做得多好"，而不是"会做什么"；其中"标准动作库"正是能力 5"动作即能力"的载体。和第 ④ 块一样贯穿五块的，还有右侧那条纵向的 效果回接主线——它不属于任何一块，而是把业务结果源源不断地送回记忆与能力。
五、10 个能力的整体介绍
把上面推导出的一项项摊开，就是 AI 原生系统的完整能力清单：
这十项不是并列的"功能列表"，而是一个有机体：
- 底座与认知（1~4）
让系统"看得懂、记得住"——对应 S07 里"让智能体更好理解任务"； - 执行与协同（5~7）
让系统"干得动、一起干、自己变强"——对应 S07 里"以智能体协作为内核、打破流程桎梏"； - 入口与闸门（8~9）
让系统"低成本用、敢用"——对应 S07 里"区分人机边界、建立信任边界"； - 第 10 项反馈闭环
把业务结果回接到记忆与能力，让前 9 项持续变好。没有它，系统是"建好能用"的静态工具；有了它，系统才是"越用越聪明"的生命体。
六、能力围绕回接怎么转
一条典型的数据流是：人在入口下指令（①/8/9）→ 智能体团队执行与协同（②/5/6/7）→ 结果回写并沉淀进记忆与知识底座（🧠/③）→ 经验复用把结果回接到下一次决策（10） → 下一轮更准。回接不断，系统就一直在"用中发现、发现中改进"。
下一篇，我们从记忆优先调用序的第一块讲起——写库即构建（调用序 #1）：知识在写入那一刻自动成型，本体从记忆里浮现。它恰好是这 10 个能力共同的地基：先有"写入即构建"的记忆，后面粒子、治理、注入、生成才立得住。
顺着"记忆系统"往下想一层：域的本质，是由记忆的主体定义的——销售的主体是客户，研发的主体是产品；由此推论，财务是"资金流与合约记忆"，供应链是"供需与履约记忆"。这条"记忆主体"的推论，才是这套东西真正可复用的价值：它不绑定某一家产品或某个行业，而是给你一把尺子——去看任何一条业务线，先问"它的记忆主体是谁"。后面 S10–S19 十篇（记忆优先调用序 #1–#10），我们都会点明这一层、这一域对应的记忆主体，让抽象的"记忆系统"落到具体业务上。调用序是阅读与构建的先后，架构能力编号是能力在图里的位置，二者指向同一套能力。
两个真实域的长相：销售 = 客户记忆，研发 = 产品记忆
把"记忆主体"落到实处，遵循同一条结构骨架：捕获 → 实体关系识别 → 记忆层 → 理解层 → 执行层，只是记忆主体不同。
- 销售管理 = 客户记忆与关系理解系统。
传统 CRM 先逼销售设计完整 schema（客户、商机、阶段、字段），再要求持续手工录入——两大病灶：录入即失真（成交关口最忙时被迫填表，信息被压缩、滞后、选择性遗漏）、模型先于数据（业务还没发生结构就定死，真实关系演化无处安放）。正确做法是：不要求一开始设计完整数据库表，先捕获、再让业务模型逐步形成；强调"零手工录入"，靠摄入销售管道自动维护；Agent 工作流按需生成，而非先建好一套固定 CRM。其记忆主体是客户，理解层抽取的是"需求、意向、风险、异议、承诺、下一步"六维——关系的全貌，而非字段的拼图。 - 研发管理 = 产品记忆与关系理解系统。
传统 PLM 实施 = 需求 → 配置 → 定制，本质是顾问把业务"翻译"进系统，每一步丢上下文（需求文档里的 Why 在配置阶段被简化，临时妥协上线后无人记得）。AI 原生 PLM 把产品记忆作在中心：结构化产品数据、对象间关系、生命周期上下文、版本、变更历史、权限、集成服务，作为连续性的唯一真相来源；围绕它，AI 生成工作流、UX、校验器、助手、仪表盘。关键差异：研发的决策发生在评审桌上，不在客户往来里——所以产品记忆的"理由与叙事"主要沉淀在 DCP/TR 评审、变更评审、需求访谈，而非邮件。
把两个域摆在一起对照，就能看清"域的本质由记忆主体定义"到底意味着什么：
三个经验说明
- 经验 1 · schema-first → capture-first（建模时机）。
先捕获，后建模。模型从数据里长出来，而非事先规定好让数据削足适履。 - 经验 2 · 人维护系统 → 系统维护自己（维护责任）。
传统系统靠人持续填表养活；AI 原生靠摄入管道自动维护记忆，人只做验证与治理。 - 经验3 · 项目制 → 实践制（交付形态）。
旧模型是"上线即冻结的项目"；新模型是"持续适应"——系统 7×24 被动摄入、围绕记忆持续生成与自我修正。
这套解法之上，永远悬着那条护栏，且有一条顺序推论：先把记忆层加深做厚，再扩捕获宽度与生成花样——顺序错了，就是生产更多没人读的原文。 捕获面铺得再宽、生成得再花哨，记忆层没深度（抽不出 Why、不可检索），生成出来的东西就是无根之木。
下一篇预告：整体架构图看清了，10 个能力也从图里推导出来了。但骨架要立得住，得从地基打起——下一篇（S10），从记忆优先调用序的第一块讲起：写库即构建（调用序 #1），知识在写入那一刻自动成型。
—— 本篇为《企业AI转型方法与实践》AI 原生系统方法论总论之一。