AI原生范式：开发与运行共生一体

卡点一：通用智能体在系统外

• 通过 API 操作，只见函数名、参数、返回值
• 看不到业务对象、字段语义、关联约束、状态规则
• 无法准确执行，更无法基于业务全貌做判断

卡点二：通用智能体不针对任务

• 单一通用 Agent 承接所有业务任务
• 不专注、不深入，缺乏特定业务的专业判断口径
• 能力沉淀在个人桌面，无法统一治理与复用

智能体专用

• 按业务板块分建专项智能体
• 各板块专注自身职责与判断口径

智能体内生

• 智能体在系统内部，而非外挂
• 由运行时统一调度，遵从统一治理

业务孪生

• 系统一比一还原业务现实
• 业务对象、流程、规则在系统中有对应

AI 友好

• 系统能被 AI 感知、理解
• 可被 AI 调用、驱动

传统开发：高度定制 = 成本高、周期长、难维护

• 满足四项要求的系统，必须按企业自身业务现实专门构建，无法用通用软件替代
• 传统定制开发投入大、交付慢，业务变化后修改成本高

引入 AI 开发：AI Coding 仅带来约 15% 综合效率提升

• 根因：开发全链路信息断裂——需求、设计、编码、验证、发布、运行各环节不贯通
• AI 看不到所开发系统的全貌与上下文，错误种类无限、难以收敛
• 写完代码缺少自动反馈，错误只能靠人工测试发现

一、应用系统的 AI 原生

• 对应运行侧：让运行业务的 AI 看懂系统
• 系统的所有模块都是规范的、自描述的元素
• AI 能看到、看懂系统中的每一个模块
• 包括模型、服务、流程、权限、状态等结构与约束

二、应用开发技术的 AI 原生

• 对应开发侧：让开发系统的 AI 看懂开发对象
• AI 能看到所开发模块的全链路信息
• 定义、职责、代码、规范、验证结果、运行结果
• 需求到运行各环节贯通，错误可收敛

1. 设计抽象应用系统模型

• 定义系统分层、元素类型与职责边界
• 作为系统级知识，指导 AI 做架构拆分

2. 系统模块元素化

• 规范化、自描述
• 热插拔、热加载

3. 开发与运行统一

• 同一套系统模型、规范、运行时、架构、技术框架
• 开发侧也可驱动运行时

4. 双向贯通

• 开发能看到并驱动运行
• 运行能反馈、反哺开发

传统模式：外挂割裂

• 开发工具独立于系统架构之外
• 运行 Agent 外挂在业务系统之外
• 开发 AI 看不到开发对象全链路信息
• 运行 AI 只能调用 API，看不到业务全貌

JitAI：内生共生

• 开发技术是架构体系的内在组成部分
• AI 内生在系统之中，不是外部工具
• 开发 AI 可见系统全景与全部元素
• 运行 AI 也可见系统全貌，并以业务对象为调用面，感知完整

语义断裂

• 同一需求多种理解，AI 不主动澄清歧义，直接按最简解释实现
• 根因：无需求澄清机制

视野断裂

• 上下文窗口有限，看不到全部资料，载入后中间内容易被忽略
• 根因：无结构化上下文

环节断裂

• 只负责写代码，上游需求、下游部署、运行都不在其职责范围
• 根因：开发与运行分离

反馈断裂

• 写完代码后没有自动反馈，错误只能靠人工测试发现
• 根因：无运行回执闭环

记忆断裂

• 会话结束上下文丢失，需求澄清不持久，换会话重复一遍
• 根因：无持久化设计书

观测断裂

• 代码运行在哪、错在哪、谁在调用，AI 无从知晓
• 根因：无运行时可观测性

正确的系统设计全局观

以抽象应用系统模型承载系统级知识与元素类型职责知识，让 AI 具备正确的架构拆分能力，同时时刻正确的掌握着系统全局架构

精确的元素开发规范

以元素规范作为开发与运行的唯一契约，收敛 AI 自由发挥空间，把“系统模块”颗粒度降低和标准化，带来AI生成准确度极大提高，错误从无限变为可枚举

内生闭环：开发——运行——反馈/反哺

开发 AI 内生在系统中，可见运行时回执与异常，形成开发-验证-迭代的自动化闭环

抽象应用系统模型（系统级知识）

• 定义企业应用系统的通用分层结构
• 定义各层职责边界与协作关系
• 定义元素之间的引用与调用规则
• 模型中的每个节点即一种元素类型

元素类型（类型职责知识）

• 每种类型有明确系统定位
• 规定字段结构、公开能力、修改边界
• 规定验证方式与归属层级
• 模型 · 服务 · 页面 · 工作流 · 事件 · 智能体 · 角色……

Type 规范前置硬约束

• 规范固化在 Type 与工具校验中，不靠 AI 自觉
• 规范覆盖不到的场景必须停下报告缺口，不编造
• 规范与实现冲突时，以实现源码为准

元素即规范化源码模块

• 开发 AI 生成元素源代码，以元素形式交付
• 对话式开发，业务人员默认无需接触源码
• 源码始终可见、可编辑，支持人工兜底修改

上下文：从一次性注入到按需检索

• 传统：上下文为固定窗口，容量受限，依赖人工拆任务、选资料
• JitAI：上下文按需检索、可寻址
• 一个元素 = 可独立构建、验证的最小单元
• 只读当前 Type 规范与直接依赖
• 目标范围外的内容不会进入上下文
• 上下文从容量约束变为检索约束

设计书：强制澄清并持久化

• 应用设计书有状态：草稿 → 已确认
• 草稿仅记录已确认事实、公开来源、推断、假设与待确认项，不能作为实施依据
• 范围、角色权限、状态流转、异常与验收逐项确认
• 存在未解决歧义时，不得进入已确认状态
• 歧义显形 · 澄清被下游消费 · 事实与推断分离

校验即反馈

开发态校验的错误回执、运行态的异常与日志，均直接回传给开发 AI，不经人工转述；形成假设 → 校验 → 修改 → 复验的自动循环

修复阈值

同一对象修复不超过 5 次，超限自动转人工处理，避免 AI 在错误方向上反复迭代

01 AI 外置外挂

智能体运行在员工桌面或云端，通过 API 操作业务系统；不在系统架构内，看不到系统全景与元素结构

02 系统非 AI 原生

旧系统以数据库表和页面为中心，无 AI 可感知的对象模型、字段语义与约束；智能体只见接口契约，不见业务对象

03 判断与执行割裂

业务规则在系统侧与智能体侧各写一份，必然分叉；多次 API 调用串联，中间态不可见，失败难回滚

04 治理缺失

集成账号按接口级粗粒度授权；个人桌面沉淀的技能与提示词无法审计、升级；企业级落地不可控

AI 作为一等元素

智能体不是外挂组件，而是与业务元素同规范、同构建、同治理的专用元素，由运行时统一调度

智能和功能分离

• AI 负责非程序确定性的逻辑，如基于知识、经验性规则、思维框架/模式的理解判断决策；
• 金额、库存、状态流转等强一致逻辑由运行时服务确定性执行

统一治理

所有元素与智能体共享同一套 RBAC、数据范围、审计链路；AI 可见范围由权限裁剪决定

业务智能体（运行态 AI）

理解意图 → 选择已授权的服务能力 → 留痕

人员（人工操作）

表单 · 页面 · 门户 · 审批操作

大模型：负责非确定性环节

• 理解目标、分析研判、解释波动
• 找异常、给方案、处理模糊与例外

系统服务：负责确定性逻辑

• 金额计算、库存扣减、批次状态机
• 权限校验、审批事务、勾稽关系

这张单能发货吗？

• AI 汇总客户信用与历史
• 系统判定赊销规则与放行

这批货能放行？

• AI 检索检验依据与历史
• 系统判定批次状态与放行

往来款对得上吗？

• AI 比对差异、归因异常
• 系统计算金额与勾稽

业务智能体

操作真实业务对象与流程

长任务智能体

异步长周期，可无人值守

流程编排型

编排多步骤流程与跨环节协同

嵌入外部网站

对外提供受控的业务智能服务

统一 RBAC 与数据范围

• 组织、角色、数据范围对人和智能体同一套
• 智能体能做的，正是它被授权的业务能力

调用前权限校验

• 后端权限判定，不以页面可见性代替授权
• 精确到角色、流程节点、数据范围

全链路运行记录与审计

• 后端请求、元素执行、业务异常、构建诊断
• 每一步业务动作可追溯、可回退

数据安全裁剪

• 密钥不进日志 · 变量原值不进模型
• 敏感数据不落盘 —— 可见范围由权限裁剪决定

元素开发侧

• 读取抽象系统模型
• 按类型规范生成元素
• 六项自动化校验
• 交付合规元素包

元素规范（统一契约）

• 类型定义 · 公开能力
• 权限模型 · 命名空间

元素运行侧

• 按契约加载元素
• 执行业务逻辑与流转
• 运行态 AI 判断调度
• 输出状态、异常与日志

部署形态

• 私有化部署：企业自有环境，数据不出域
• 多租户 SaaS：平台侧统一托管
• 混合部署：核心数据私有，边缘能力上云

模型网关

• 统一适配多家大模型服务
• 不锁定单一模型供应商
• 按场景路由：判断走大模型，精确逻辑走服务

平台不承担的职责

• 不替代人做最终业务决策
• 不执行金额、库存等精确计算（交由服务）
• 不做通用办公与创意产出
• 不锁定单一模型供应商
• 元素化有建模成本，需以真实数据验收

技术演进路线

• 元素规范体系持续完善
• 行业模板与预置元素库
• 可复用技能与专项智能体市场
• 合作伙伴共建类型与行业方案