AI原生应用的自适应界面：UI Schema驱动动态渲染实战

如果你最近在关注 AI 应用开发，会发现一个现象：很多人把大模型接进 App 之后，界面还是老样子——固定的页面、固定的表单、固定的列表，聊天框像补丁一样粘在页面角落。这其实还算不上 AI 原生应用，最多算“AI 增强应用”。真正让我觉得有意思的，是把界面本身变成 AI 的输出结果：AI 理解用户意图之后，动态决定这一屏应该展示什么、用什么组件、信息怎么排布，这就是 AI 原生应用的自适应界面。

这篇文章会从概念讲起，然后完整走一遍从需求拆解、架构设计、关键代码到踩坑修复的实施流程。内容偏工程落地，适合已经能调用大模型 API、想做深度集成的团队或个人开发者。我会结合一个“AI 出行助手”的实际例子展开，也会讲清楚我理解的“AI 原生应用架构成熟度”分几个阶段，方便你对照自己项目到底处在哪个位置。

1. 项目定位与设计思路拆解

1.1 AI 原生应用与传统应用的本质区别

先说一个容易被忽略的判断标准。普通业务系统里，AI 只是某个功能模块：比如客服页面调用模型回答用户问题，或者运营后台用模型做内容分类。界面结构和业务流程还是人肉设计好的，AI 不参与“界面长什么样”的决策。

而 AI 原生应用正好反过来：模型不仅是业务逻辑的执行者，还在某种程度上是体验的编排者。用户进入产品之后，系统先通过多轮对话理解真实目标，再动态生成操作界面。比如用户说“下周去杭州出差，帮我订一个离客户近、能开发票的酒店”，传统 App 会给一个巨大的酒店筛选页，用户自己拖着十几个筛选项慢慢调；AI 原生应用则可能直接渲染出“三个候选酒店 + 一栏离客户公司的距离提示 + 发票信息确认卡片”。后者更贴近任务，也更省事。

所以，从产品设计的第一天起，“界面是变量而不是常量”这个理念，就必须成为团队的共识。它影响到数据建模、接口设计、测试策略，甚至 UI 组件的写法。

1.2 自适应界面到底“自适应”什么

绝大部分人听到自适应界面，第一反应是响应式布局——根据屏幕宽度调整卡片排列。那是 Web 1.0 就有的问题。AI 原生应用里的“自适应”，是指界面要适配下面三个维度：

• 用户意图：用户想要筛选航班，还是想要改签，界面逻辑完全不一样。
• 对话上下文：上一轮用户预付了款，这一轮再说“我要取消”，系统要能理解是取消刚才的订单。
• 数据状态：当查询结果为空、接口报错、或需要二次确认时，界面必须能随机应变，不能出现空白页或死路。

换个更通俗的说法：传统界面是“产品经理预设好所有路径”，自适应界面是“AI 根据用户当下的一句话临场铺路”。这就要求我们把“界面结构”和“界面内容”拆开，把每一种可能出现的界面形态抽象成可被描述、可被传输、可被校验的数据结构。

1.3 AI 原生应用架构成熟度：你的项目在第几层

“AI 原生应用架构成熟度”这个说法，我把它定义为：AI 在多大程度上接管了应用的状态流转和界面生成决策。按我的经验，可以粗略分五个阶段：

大部分宣称在做 AI 应用的产品，其实只到 L1。做到 L2 的已经不多。真正想去到 L3，就必须建设一套界面描述协议。这篇文章主要围绕 L3 如何落地，最后会聊到向 L4 演进时的一些思考。把这个成熟度框架放在团队里还有一个好处：不同岗位能很快对齐“我们现在做的是哪个阶段的事”，避免前端等后端定义死页面、后端等模型直接吐可执行代码这种两头乱的状态。

2. 核心机制设计：让界面跟上用户意图

2.1 为什么选择“UI Schema 中转”，而不是让 AI 直接写代码

一开始做这个项目时，我走过弯路。我的第一版思路是：让模型直接输出 JSX 或者 HTML，前端拿到之后 dangerouslySetInnerHTML 直接渲染。结果只跑了半天就放弃了。问题很明显：模型生成的代码质量不稳定，一旦引入了它自创的组件库、或者调用了不存在的事件方法，页面就白屏；更可怕的是安全不可控，模型可能在一句话的引导下输出包含外部资源链接的脚本，等于把 XSS 的大门打开。

后来我把方案调整为：模型不直接生成代码，而是生成一份高度结构化的 UI Schema（界面描述）。前端有一个“渲染器”，根据 Schema 里的 type 字段到组件注册表里找到对应组件，再填充数据渲染出来。

画个对比就清楚了：

• AI 直接输出代码 = 让一个外聘顾问直接进你的生产环境改代码，速度快但翻车了没兜底。
• AI 输出 Schema = 顾问只写一份“需求描述+建议方案”，经验丰富的工程团队去实现，安全且可控。

用 Schema 中转还有一个额外好处：可以校验。模型输出如果不符合 JSON Schema，我们可以在渲染前拦截并做修复或降级处理。而代码字符串无法结构化校验，除非你起一个沙箱环境去编译运行，成本很高。

2.2 设计一份“最小可用”的界面描述协议

界面描述协议是整套系统的地基。它要覆盖常见业务场景，又不能把组件库的每个属性都暴露给模型，否则模型会无所适从。我的做法是定义一套组件白名单，每个组件有固定的 schema，模型只能从白名单里做组合。

所谓“最小可用”，我理解包含这几类组件：

• 信息展示型：标题、段落、图片、卡片、列表、表格、统计指标
• 操作交互型：按钮（支持点击后触发预定义动作）、输入框（提交后回到对话）
• 容器布局型：垂直堆叠、横向排列、分组面板、弹窗
• 特殊场景型：表单生成器、时间轴、状态提示、错误页

实际项目里，我给每个组件分配一个唯一的 type 名称。模型产出的最高层是一个 page 容器，里面有序地放各个区块。整个输出的核心数据结构如下：

json复制{
  "schemaVersion": "1.2",
  "page": {
    "type": "stack",
    "children": [
      {
        "type": "title",
        "text": "上海 → 北京 · 4月12日"
      },
      {
        "type": "list",
        "items": [
          {
            "id": "f001",
            "title": "MU5101",
            "subtitle": "07:00 虹桥T2 → 09:00 首都T2",
            "badge": "750元"
          }
        ]
      },
      {
        "type": "actions",
        "buttons": [
          { "label": "只看早班机", "action": "filter:morning" },
          { "label": "按价格排序", "action": "sort:price" }
        ]
      }
    ]
  }
}

注意：我没有让模型输出“将整个页面替换成新页面”的指令，而是让它输出“当前界面某一区块应该是什么”。前者容易导致交互过程中界面剧烈跳动，后者才能支持局部更新。

当系统第一次接入新业务域时，我会把这套 schema 的核心定义发给模型，作为 few-shot 示例。不要一次性把所有组件的文档都发给模型，信息太多 = 信息噪声，模型反而不容易选对。把整个组件库按场景分组，每组对应不同的 System Prompt，是我验证下来最稳的方案。

2.3 前端渲染器与组件注册中心

前端是整个链路里承上启下的部分。它接收模型输出的 schema，把它变成真实可交互的 UI。最常见也最优雅的实现是“注册中心模式”，我用了不到两百行 TypeScript 就搭起了一个基础版本。

组件注册中心的核心逻辑是维护一张类型到组件的映射表，以及一个通用的渲染函数。每遇到一个节点，就根据 type 从映射表里取组件，取到就绑定 props 渲染，取不到就进入 breakpoints 降级逻辑。实现思路如下：

typescript复制type SchemaNode = {
  type: string;
  props?: Record<string, unknown>;
  children?: SchemaNode[];
};

class ComponentRegistry {
  private map = new Map<string, React.FC<any>>();

  register(type: string, component: React.FC<any>) {
    this.map.set(type, component);
  }

  render(node: SchemaNode, ctx: RenderContext): React.ReactNode {
    const Component = this.map.get(node.type);
    if (!Component) {
      return ctx.createFallback(node); // 回到 Markdown / 通用卡片
    }
    const children = node.children?.map((child) => this.render(child, ctx));
    return <Component {...node.props} children={children} />;
  }
}

const registry = new ComponentRegistry();
registry.register('title', TitleBlock);
registry.register('list', ListBlock);
registry.register('actions', ActionBar);

有几个细节很关键，也是容易踩坑的地方：

• 比如 props 中的 onClick 函数不能由模型直接传，而是传递动作字符串。实际点击时由统一的事件总线去派发。这样既隔离了风险，又使得后续做数据埋点非常容易。
• 通用组件如 TitleBlock、ListBlock 要支持 no-data、loading、error 三种状态，模型只负责传内容，渲染器负责处理状态展示，避免模型把异常显示也写在业务逻辑里。

渲染器还应该提供一个“只读预览模式”，当系统置信度不够高时，默认展示为聊天形态的文本卡片，只有置信度高、可操作性强时才启用完整动态渲染。这也是常见的安全兜底策略。

2.4 状态管理：多轮对话和界面状态如何联动

如果只是单轮对话生成页面，事情就简单了。但实际用户不会一次把话说完，他会说“帮我查下北京到上海的机票”，看到结果后又说“只要早上八点之前的”，再点一下就选了大清早的班次。这个完整链路里，上一轮的查询结果、用户已经做出的选择、当前高亮态都必须被保存。

大型语言模型有上下文窗口，但不代表它可以当数据库用。我最开始把全部对话历史塞给模型，让它自己整理状态，结果第二三轮还正常，到了第五轮之后经常出现幻觉，比如改一个筛选条件，结果把用户已经选好的出发地改了。

后来我调整策略：把整个系统拆成“用户状态”和“界面状态”，分别存储。

• 用户状态：用户身份、发起地点、出发地、目的地、时间、预算等业务参数，存在后端结构化会话中。
• 界面状态：当前渲染出的 schema、已展开哪一个区块、选中的列表项、弹窗开关，存前端本地或轻量缓存。

模型需要决策时，后端把结构化用户状态拼进 prompt，而不是把整段历史聊天丢进去。界面每次渲染只更新增量部分，模型只输出“这次变化了哪些区域”的 diff，前端把所有 diff 应用后重绘。这样既降低了模型输出的 token 数，也大幅减少了页面抖动。

实际交互中，任何按钮触发的新操作都会回到对话生成接口，由模型判断是局部更新还是跳转新流程。整条链路可以概括为：组件事件 -> 语义意图 -> 状态变更 -> 模型决策 -> 增量 schema -> 渲染器更新。

3. 实操：从零到一完成一个 AI 原生出行助手的自适应界面

3.1 项目场景与目标设定

理论讲多了容易飘，还是上项目。我选一个大家都熟悉的场景：AI 出行助手。用户可以对话查航班、选座位、值机、查看航变信息，界面完全由模型动态生成。为了控制工作量，第一版核心目标是：

• 支持查询航班列表，AI 根据用户需求动态渲染列表和筛选按钮。
• 支持点击筛选按钮后对列表做局部更新，而不是整个页面刷新。
• 支持多轮修改条件，比如换日期、换出发地，条件变更后能正确更新界面。
• 当出现无法识别的需求时，兜底走自然语言对话，而不是渲染错误页面。

我建议你也从这类高交互、多状态的任务入手，因为场景足够复杂，能逼出架构问题。如果只做天气查询这类一次性问答，是练不出自适应界面能力的。

3.2 项目整体目录结构

我采用前后端分离，后端 Python FastAPI 负责与模型交互和业务代理，前端 React TypeScript 负责动态渲染。项目结构如下：

text复制ai-native-travel/
├── backend/
│   ├── app/
│   │   ├── main.py              # FastAPI 入口
│   │   ├── models.py            # 业务数据模型
│   │   ├── agent.py             # 大模型 Agent 编排
│   │   ├── prompts.py           # 各场景 System Prompt
│   │   ├── ui_schema.py         # UI Schema 定义与校验
│   │   └── session_store.py     # 会话状态存储
├── frontend/
│   ├── src/
│   │   ├── registry/
│   │   │   └── index.ts         # 组件注册中心
│   │   ├── renderer/
│   │   │   └── Renderer.tsx     # 通用渲染器
│   │   ├── components/          # 白名单组件
│   │   └── App.tsx
│   └── package.json
└── README.md

这个结构的好处是 UI Schema 协议文件被前后端共享，后端定义协议和校验逻辑，前端只认协议渲染组件，两边不需要互相等人。

3.3 核心代码：构建可控的系统 Prompt 与输出约束

控制模型输出，最重要的不是把希望它的功能写得多复杂，而是要把输出边界说清楚。我把 prompt 分成三块：角色定义、输入状态、输出要求组合。不要把所有块一次性全部抛给模型，而是先让后端从会话中取到当前状态，再动态组装。

后端核心 agent 逻辑如下：

python复制from pydantic import BaseModel, Field

class UISchema(BaseModel):
    schemaVersion: str = "1.2"
    pageTitle: str | None = None
    blocks: list[dict] = Field(description="有序UI区块列表")

SYSTEM_PROMPT = """
你是一个AI原生应用界面生成引擎。用户会给出当前界面状态和最新指令。
请根据用户最新指令，输出一份渲染UI所需的JSON Schema。

规则：
1. 只能使用以下组件类型：
   - title: 标题，props: {text: string}
   - list: 列表，props: {items: [{id, title, subtitle?, badge?}]}
   - stats: 指标卡，props: {items: [{label, value}]}
   - actions: 按钮组，props: {buttons: [{label, action}]}
   - form: 动态表单，props: {fields: [{name, label, type}]}
2. 不得任意引入新组件类型。
3. 如果要表达"需要用户补充信息"，请使用 form 组件，不要用自然语言搪塞。
4. 保留用户操作所需的 stateId，所有按钮的 action 必须以"filter:"、 "sort:"、"buy:"、"next:"前缀开头。
5. 输出必须是合法的JSON，不要包含Markdown代码块标记。

当前用户状态：
{user_state}

最近对话摘要：
{session_summary}

最新用户指令：
{user_input}
"""

def generate_ui_schema(user_state, session_summary, user_input):
    prompt = SYSTEM_PROMPT.format(
        user_state=json.dumps(user_state, ensure_ascii=False),
        session_summary=session_summary,
        user_input=user_input
    )
    # 调用兼容 OpenAI 格式的接口，打开 JSON 模式
    resp = client.chat.completions.create(
        model="gpt-4o",
        messages=[
            {"role": "system", "content": prompt},
        ],
        response_format={"type": "json_object"}
    )
    raw_schema = json.loads(resp.choices[0].message.content)
    # 使用 pydantic 做二次校验
    validated = validate_schema(raw_schema)
    return validated

这里有两个点值得展开。

第一，为什么把“当前用户状态”和“最近对话摘要”分开传入？因为模型不需要完整对话记录，它只需要业务参数。业务参数一旦结构化了，前端渲染效率和多轮一致的稳定性都会明显提升。对话摘要由另一个轻量模型在后台先把长对话压缩，这一步属于可选项，实测下来对老用户的体验提升明显。

第二，我用 json_object 模式来约束模型直接输出 JSON。但即使这样，偶尔仍会出现字段缺失或类型不匹配的情况，所以外层还有一层 pydantic 校验，出错了会触发重试或降级策略。

3.4 前端渲染器与操作事件流

后端返回的 schema 是“一屏内容的结构化描述”。前端拿到之后，直接用渲染器渲染。核心逻辑我已经在前面展示过，这里补一个操作事件实际流动的例子。

假设模型返回了这样一个 actions：

json复制{
  "type": "actions",
  "buttons": [
    { "label": "只看 8 点前", "action": "filter:departure_before=8" },
    { "label": "按价格排序", "action": "sort:price_asc" }
  ]
}

前端渲染出按钮后，用户点击“只看 8 点前”。这不是一个真实的业务接口调用，而是一个需要返回给 AI Agent 语义指令的动作。所以我没有让按钮直接去 query 机票 API，而是把它送到一个全局事件处理函数：

typescript复制interface Payload {
  action: string;
  stateId: string;
}

const RuntimeBridge = {
  async dispatch(payload: Payload) {
    const res = await fetch('/api/agent/action', {
      method: 'POST',
      body: JSON.stringify({ ...payload, sessionId }),
    });
    const nextSchema = await res.json();
    renderer.merge(nextSchema); // 增量更新或重绘
  },
};

后端收到 filter:departure_before=8 之后，去上一轮的航班数据里做本地过滤，过滤完再把新的结果构造成 schema 返回给前端。这比让大模型重新去理解“只看八点前”再去调 API 要高效得多，也稳定得多。因此整个系统实际上是一个混合决策：大模型负责理解自然语言和决定界面形态，传统的确定性代码负责执行具体业务逻辑。

这是一个非常重要的架构判断。不要试图让大模型做所有的事。大模型适合做语义理解、任务规划、界面编排，而数据过滤、金额计算、权限校验这些，必须走确定性的代码路径。把两者分开，系统的可维护性和安全性都会有指数级提升。

3.5 流式结构与局部刷新技巧

自适应界面在真实场景下有另一个挑战：模型生成速度不稳定。用户上一句说完，等三秒才看到新界面已经算慢了，如果等六秒就完全不像话。我做了两个优化。

第一，模型解析并输出最终 schema 之前，先让底层模型开启流式输出。后端接流式 token 后，遇到一个完整的组件块就立即推进给前端，前端可以做到“先出现标题、再出现列表、最后出现按钮”的渐进式渲染，人脑对这种渐进感是很宽容的，但对着空白页等五秒则很难受。

第二，当模型只更新局部列表时，我会特别要求它输出区块的 update 指令，前端渲染器做 diff 级局部刷新。用代码表示就是后端可能返回这样的结构：

json复制{
  "update": {
    "selector": "block#flight_list",
    "action": "replace",
    "content": {
      "type": "list",
      "items": [...]
    }
  }
}

这个 update 结构不是让整页重绘，而是精确定位到列表区块，替换数据。实现时，前端渲染器维护一份区块级缓存，每个区块有唯一 id。schema 更新时按 id 匹配，能复用的 DOM 尽量不动，只更新内容。实测在 50 条候选航班列表内，局部刷新耗时稳定在 100ms 以下，视觉上不会出现闪烁。

3.6 评估本项目当前处于哪个成熟度层级

如果你按上面的方式做出来，你的应用已经处于 L3 的中上水平：模型生成结构化界面描述，前端有协议驱动渲染，业务中大量确定逻辑嵌入微服务。我常看到团队只把一个聊天框放到界面中，却说在做 AI 原生应用。用架构成熟度这个概念一对照，差距就很明显了。

我在自评时还会看四个维度：

• 界面生成是否由模型直接决定，而非固定模板套壳。
• 多轮交互里上下文状态是否结构化持久化，而不依赖模型背诵代码。
• 回流到传统代码的业务流程能不能以确定性实现，而不是让系统“随机应变”。
• 安全机制上，是否白名单限定模型可调用的能力。

一个成熟度高的应用，未必技术多复杂，而是每一层边界都清晰，每一类决策都有归属。

4. 常见问题与排查技巧实录

4.1 模型输出的 JSON 结构不合规

做动态渲染，最高频的坑就是模型给出了“看起来合理但前端完全渲染不了”的界面描述。我踩过最典型的几种：

• 字段类型错乱，text 写成了数组。
• 把自己发明的组件类型 type: "flight-card-list" 塞进来。
• 把可执行函数表达式写进字符串，期望前端 eval 执行。
• JSON 里混入了 markdown 代码块开头，导致 json.loads 直接失败。

我的排查策略分三层：模型层约束、后端校验层、前端降级层。模型层约束大家都懂；后端校验层可以用 pydantic 库定义响应模型，字段错误立即抓出来；前端降级层则是最后一个兜底，如果传输到前端还是出了问题，注册中心会返回通用 Markdown 渲染器，保证用户能看到内容，而不是白屏。

我强烈建议在开发环境把后端完整校验日志打出来，一旦出现 schema 错误，就把原始输出存入日志和样本库。这些样本以后是要做回归测试的，每次升级模型或调整 Prompt，都用这批样本集跑一遍 JSON 合法性检查。

4.2 界面闪烁不停、反复横跳

多轮状态联动中容易遇到界面抖动的现象。比如用户看到列表后点了一下排序，整个页面却又重新渲染了一遍，视觉上先是空白，再过几百毫秒才恢复。这会让用户觉得自己做错了什么。

根源往往是前端拿到整页 schema 后无脑全量 setState，没有做区块级 diff。我的解决方案是把渲染器从“整页重绘”改成“区块合并更新”。

还有一个细节值得分享：schema 里要增加一个 requestId 字段。后端每次处理用户事件时生成新的 requestId，前端渲染前对比本地当前 requestId，如果请求交错返回，比如上一个请求的结果晚于下一个请求返回，就丢弃旧数据。我早期没做这个防护，用户快速连点时经常出现旧结果覆盖新结果的情况，排查了很久才发现是请求竞态问题。

4.3 多轮对话里上下文状态丢失

用户说“查一下明天北京到上海”，再补充一句“还是改到后天吧”。有些版本用大模型硬撑，到了第三轮就分不清是查北京到上海还是上海到北京了。这其实是一个典型的状态漂移问题，解决手段就是“外部化状态”，不要让模型记忆状态。

具体说，任何业务参数发生变化，都要立即结构化更新 userState。模型每次生成 schema 时，userState 从会话存储读取，而不是让模型看自己刚才的输出。这就像你让一个实习生办事，不要指望他记得你三天前随口说的需求，最好在他开工前把最新的需求清单写到邮件里，他看邮件执行。

我还会给状态加版本号，每一轮变更都记录版本，以便回溯问题。如果用户后来反悔，说“我想改回刚进来的默认值”，系统能够准确找到最初状态并一键恢复。

4.4 安全边界：模型输出动作必须白名单化

动态界面最让人担心的就是安全问题。模型生成的按钮 action 可能会被恶意构造为 buy:ticket_without_payment 之类的内部动作，或者试图读取不该读的数据。我刚上线时也遇到过，有测试用户故意让 AI 渲染一个“导出全部用户”的按钮。幸好我在后端设计时强制要求所有 action 必须注册在可执行动作表中，未注册的一律拦截并返回提示。

凡是大模型能生成的动作，都应该是预定义能力集合的子集。后端在处理任何 action 之前，都要做一次服务端校验，而不是前端禁用按钮就了事。对需要高权限的操作，比如购买、删除、转账，还要强制加一道二次确认组件，由系统生成确认弹层，这一步必须走确定性代码，不能被模型跳过去。

4.5 组件越多性能越差怎么办

随着业务铺开，组件注册表里的组件会越来越庞大。如果组件库达到几十上百个，把全部组件文档和示例发给模型，不仅 token 消耗大，模型选择准确度还会明显下降。我建议按场景把组件分成多个命名空间。比如出行场景只加载出行组件集，办公场景只加载会议/文档组件集。渲染器本身全局可用同一个，只是“可用组件列表”按场景过滤。

前端渲染器也可以做按需加载。组件注册表改成异步注册，只有 schema 里真正出现某个组件类型时，才用动态 import 加载组件代码。这样首屏包体积能明显降下来，体验会好很多。

5. 产品效果评估和后续演进方向

5.1 评估指标不只是“模型答对率”

自适应界面这个形态下，评估要分多个维度。我长期关注的几个核心指标是：

• Schema 合法率：模型输出通过协议校验的比例，低于 95% 说明 Prompt 或模型还需要调。
• 意图直达率：用户从输入到搞定事务中间是否被不必要的页面打断，如果经常出现需要用户重复输入才能走到下一步，说明界面编排能力弱。
• 组件利用率分布：如果某些自定义组件永远不被模型触发，说明它对模型不可见，或提示词里没有给出合适触发条件。
• 人工兜底率：有多少请求最终走了对话兜底而不是动态卡片，这个比例长期高于 30% 时就要认真排查。

这些指标不是只开发阶段看一眼，而是要接到日志系统里持续监控。我通常会给每一次 schema 生成打点，记录用户输入、模型输出、渲染耗时、用户后续行为、是否紧接着求助人工客服。样本积累足够之后，每周做一次坏案例复盘，收益远比盲目调 Prompt 高。

5.2 灰度发布和反馈闭环

动态界面有个麻烦：同一个页面，模型更新或 Prompt 调整，可能给不同用户带来完全不同的体验。传统前端的 A/B 测试方法依然适用，只是需要把 schema 里上一个独特的 schemaVersion，前端上报时带上这个版本号，后端可以在用户维度控制某些用户走新 Prompt 逻辑。

我建议在灰度期间增加一键反馈入口。用户在动态卡片底部点“不满意”后，系统可以收起卡片，退回普通自然语言对话模式，同时记录当时完整的 schema 和用户操作日志。用这些负反馈样本去构造测试集，是优化 Prompt 最真实有效的手段。

5.3 从单 Agent 到多 Agent 编排的跃迁

当你把 L3 的单界面生成做得足够稳定后，自然会遇到更复杂的需求：用户提出一个任务，需要跨多个子应用完成。比如“帮我安排周五去苏州开完会以后顺便看一个美术馆”。系统先要订车票、订会议室，又要查美术馆开放时间，最后还是要把行程汇总成一个有条理的局面。

这个阶段，单个 Agent 做编排会比较吃力，因为它既要做语义规划，又要管理多组状态、输出多份界面。我会把单一 Agent 拆成“主编排 Agent”和多个“技能 Agent”。主 Agent 只负责把大任务拆成子任务、确定执行顺序。每个技能 Agent 负责自己的业务和局部 Schema。前端则引入“多页面容器”，比如可以并排渲染“行程总览”“订票表单”“场地信息”等多个卡片块，让用户看到 AI 正在分头干活的过程。

注意，多 Agent 不是拆得越多越好。每个子 Agent 都要有明确的领域边界，不然状态同步会变成一场灾难。我见过不少团队过早追求多 Agent，结果互相调用，上下文爆炸，调试时根本不知道错在哪一环。更好的路径是先基于单 Agent 把 L3 跑通，再逐步演化到 L4，切莫一步跨太大。

5.4 踩过这些坑之后，我现在的选择习惯

如果只让我分享一个最深的体会，就是不要用大模型去替代那些稳定、成熟、可测试的代码路径。AI 的价值在于处理模糊性和不确定性，而业务里大量操作是确定性流程：改个日期、重新算一遍价格、更新列表顺序。能用传统代码实现的，绝不让模型思考；能让结构化状态保存的，绝不让模型背诵；能白名单约束的，绝不给模型自由发挥的空间。

我自己后续在新项目里，会优先把“界面协议”设计得再小一点，再正交一点。与其追求组件覆盖所有场景，不如允许“通用文本卡片+动态表单+操作按钮”作为万能兜底。一个用户哪怕遇到不认识的新需求，看到的是排版不是很花哨但完全可用的界面，也比白屏或报错强得多。

最后再分享一个生产力小技巧：把 Schema 的协议文档直接作为系统提示词的一部分，同时放一个合法的完整 JSON 示例。每次调整组件库后，都要更新这个示例。前后端联调时如果出现协议不同步问题，多半是这个示例没有同步刷新。保持协议文档、示例代码、真实运行 schema 三者一致，能让整个团队少掉很多头发。