低代码平台接入 Agent 后 我们踩到的组件 上下文和追问坑

本文复盘一次内部低代码平台智能助手的阶段性验证。

目标很直接：用户在聊天入口里发送设计图、切图链接，或者一段文字描述，Agent 理解需求后调用低代码平台能力，生成页面或配置页链接。

早期简单场景可以跑通：

• 一张图的规则页可以生成页面结果；
• 单组件需求可以匹配组件并生成可编辑配置；
• 熟悉平台的人可以通过补充组件描述，让 Agent 生成页面骨架。

但真实需求一复杂，问题也很快暴露出来：

• 组件一多，生成结果开始不稳定；
• 对话轮次一多，Agent 可能丢掉前面已经修改过的组件；
• 遇到需要追问的场景时，系统可能把“追问内容”当成最终结果保存，反而丢掉前面已经生成出的有效结果；
• 每次改 Prompt、组件描述或工具调用逻辑之后，缺少稳定的回归验证方式。

这次实践给我们的结论是：

低代码页面生成不是一次性的文本生成任务，而是一个带状态、带工具调用、带平台约束的工程流程。

所以它真正难的不是“让模型生成一次页面”，而是让生成结果能被平台理解、能继续编辑、能多轮修改、能追问补齐信息，并且每次调整后都能验证是否真的变好了。

1. 生成链路：它不是让 AI 自由画页面

低代码平台的核心资产不是一张空白画布，而是一批已经沉淀好的组件、参数、规则和配置能力。

所以这个 Agent 的定位不是“让 AI 随便画一个看起来差不多的页面”，而是给低代码平台增加一个自然语言入口。

整体链路可以简化成这样：

这个定位决定了后面所有工程取舍。

如果只是做 Demo，生成一个视觉上接近的页面就够了。但进入低代码平台之后，生成结果必须满足几个条件：

• 只能使用平台真实存在的组件；
• 组件参数要符合平台约束；
• 生成出的页面配置要能被编辑器继续打开和修改；
• 复杂场景里缺少信息时，要能正确追问；
• 多轮修改时，不能把上一轮已经确认的组件改丢；
• 后续要有测试样例验证生成质量。

换句话说，AI 的价值不是绕过低代码平台，而是更低成本地调用平台已有能力。

2. 第一阶段能跑通什么，边界在哪里

第一阶段验证里，比较稳定的场景集中在三类。

2.1 一张图的规则页

用户给出图片和描述后，Agent 根据输入生成对应页面。

这类页面结构相对固定，组件数量少，平台侧可选组件也比较明确，所以更容易生成可预览结果。

2.2 单组件页面

比如只需要一个弹窗组件、头图组件或者某个业务组件时，Agent 根据用户补充的少量参数，可以匹配组件并生成初始配置。

这个场景的关键是：任务边界足够窄。

它不需要同时判断很多组件之间的顺序、参数依赖和页面结构，所以更适合作为早期验证场景。

2.3 熟悉平台的人辅助生成骨架

如果使用者本身熟悉低代码平台，能明确告诉 Agent 页面里有哪些组件、每个组件承担什么功能，它就更容易先生成页面骨架，再由人工继续核改。

这个场景很适合内部提效，但它也提醒我们：当前能力还不是“无门槛自动生成复杂页面”，而是“在边界清楚的前提下，帮助人更快生成初版”。

可以把当前适用边界先收敛成一张表：

场景	当前适配度	原因
单图规则页	较高	结构固定，组件少
单组件页面	较高	任务边界清晰，参数较少
熟悉平台的人生成骨架	中等偏高	人能补充组件和参数上下文
多组件复杂页面	不稳定	组件选择、顺序、参数约束同时变复杂
长对话持续修改	不稳定	容易丢失已确认组件或误判任务边界

这一步判断很重要。很多 AI 项目早期最容易犯的错误，就是把 Demo 场景里的顺畅，误判成真实场景里的稳定。

3. 复杂需求上来后，问题从“生成”变成“状态管理”

真正的问题出现在复杂页面里。

真实页面通常不是单组件。一个活动页可能同时包含头图、规则、按钮、跳转、状态展示、弹窗、列表、业务卡片和各种配置参数。

组件一多，Agent 需要处理的就不只是“选一个组件填几个参数”，而是：

• 哪些组件可以满足需求；
• 多个组件之间是什么顺序；
• 哪些参数必填，哪些可以默认；
• 缺少信息时应该追问什么；
• 用户补充信息后，应该更新哪个组件；
• 新一轮输入是在改当前页面，还是开始一个新页面。

这时问题就从“能不能生成”变成了“状态能不能管住”。

3.1 坑一：追问时丢掉了已有中间结果

一次复杂需求里，用户希望生成一个包含头图、轮播视频图，以及两行两个主播的页面。

Agent 能理解大致方向，但落到实际配置时，还需要继续追问视频链接、封面图、主播数据、跳转信息等内容。

追问本身是合理的。

真正的问题在于，早期追问流程没有处理好：系统会把追问内容直接保存，反而没有保留前面已经搜索或生成出的有效结果，导致页面里的组件不正确。

从聊天视角看，这只是“问用户补充一个信息”。但从工程视角看，追问背后对应的是一个未完成任务、一部分页面结构，以及已经拿到的中间结果。

如果系统没有把这些状态保存住，追问就会变成覆盖。

后续修复后，追问时可以继续保留上下文，至少不会因为一次补充信息就把前面的有效结果丢掉。

3.2 坑二：多轮修改时丢弃已确认组件

页面生成不是一次性对话。

用户很可能会连续说：

• 把头图换成另一张；
• 第二个组件参数调一下；
• 增加一个按钮；
• 按钮跳转到另一个页面；
• 再补一个弹窗。

如果前一轮刚确认的组件，下一轮因为一句新指令被覆盖掉，用户很快就会失去信任。

这个问题不能简单归因于“模型没理解”。更准确地说，是系统没有把当前页面结构、已确认组件、待补参数和本轮修改目标建模清楚。

3.3 坑三：任务结束判断不稳定

还有一个容易被低估的问题：一个页面需求什么时候算结束？

用户下一句话到底是在补充同一个页面，还是开始了一个新页面？

如果完全交给模型自动判断，实际效果会不稳定。当前更稳妥的方式，是通过手动结束会话来显式标记任务边界，避免系统误把不同页面认成同一个任务，或者把同一个任务拆成多个页面。

这类设计看起来不够“智能”，但在工程早期更可靠。

4. 四个必须收紧的工程边界

踩坑之后，我们发现问题不只是模型能力。

模型当然会影响理解和生成效果，但内部 Agent 要进入业务工具，必须先把工程边界收紧。

4.1 组件边界：不能让模型想象不存在的组件

低代码平台不是自由画布。

Agent 不能为了满足用户描述，想象一个平台里不存在的组件，也不能随意创造平台不支持的参数。

所以组件描述不能只写“这个组件是做什么的”，还需要补充：

• 适用场景；
• 不适用场景；
• 必填参数；
• 参数约束；
• 示例输入；
• 示例输出；
• 缺信息时的追问方式；
• 不支持时的返回策略。

组件说明对 Agent 来说不是普通文档，而是它选择工具、生成配置和处理异常时的重要依据。

4.2 上下文边界：页面生成需要任务状态

普通聊天可以模糊一点，但页面配置不行。

一个页面生成任务里，至少要记录：

• 当前页面包含哪些组件；
• 每个组件是否已确认；
• 哪些参数还缺失；
• 本轮用户输入作用于哪个组件；
• 当前任务是否已经结束；
• 下一轮是继续编辑还是新建页面。

如果没有任务状态，Agent 很容易在多轮对话里“看起来很努力”，但实际上把页面越改越乱。

4.3 工具调用边界：中间结果、追问和最终保存要分开

Agent 调用平台能力时，工具返回结果、用户追问、异常信息和最终保存结果应该有清晰流转。

尤其是追问场景，系统需要保留已经拿到的有效结果，而不是因为缺少某个参数，就把追问内容覆盖成最终结果。

一个更稳的流程应该接近这样：

识别需求
  -> 匹配组件
  -> 生成部分配置
  -> 判断缺失参数
  -> 保存中间状态
  -> 向用户追问
  -> 合并补充信息
  -> 再次生成 / 更新配置
  -> 最终保存

这里的关键不是流程图多漂亮，而是“中间状态”和“最终结果”不能混在一起。

4.4 验证边界：不能靠感觉判断这次变好了

页面生成不能只靠肉眼看一眼，也不能每次出问题都靠人工读日志、贴上下文、让代码 Agent 猜哪里错。

一旦日志变长、上下文变复杂，这种排查方式会非常低效。

更需要补上的是可回归验证机制。至少要覆盖几类样例：

• 简单单图生成；
• 单组件参数生成；
• 多组件页面骨架生成；
• 多轮修改不丢组件；
• 追问后继续保留原有效结果；
• 手动结束会话后不再误关联上一页；
• 不支持组件时能正确拒绝或继续追问。

这样每次调整组件描述、工具调用逻辑或模型策略时，团队才知道它到底变好了，还是只是这一次碰巧跑通。

5. 一套更适合落地的迭代路径

这次验证之后，我们没有继续盲目扩大需求范围，而是先把问题收窄。

5.1 先做高频组件，不追求全组件覆盖

低代码平台里的组件很多，但真实高频使用的往往只是其中一部分。

早期与其追求全量覆盖，不如先把高频组件的描述、参数、示例和限制条件写清楚。

这一步的目标不是“看起来支持很多”，而是让最常见的场景先稳定下来。

5.2 把组件经验翻译成 Agent 能执行的规则

很多平台经验原本存在于研发、运营或熟练使用者脑子里。

比如：

• 哪个组件适合规则页；
• 哪个组件适合活动入口；
• 哪些参数不能同时出现；
• 缺少跳转信息时应该先问什么；
• 哪些复杂需求只能先生成骨架，不能承诺全自动完成。

这些经验如果不显式写出来，Agent 只能靠模型推理去猜。

真正要做的是把这些经验翻译成结构化的组件能力说明和测试样例。

5.3 业务侧和平台侧分工要清楚

业务 Agent 接入平台时，业务侧和平台侧的边界要先分清。

低代码平台侧更应该关注：

• 高频组件；
• 组件能力说明；
• 页面生成样例；
• 失败样例；
• 人工核改边界。

通用 Agent 平台更适合承接：

• 会话状态；
• 工具注册；
• 日志分析；
• 执行环境；
• 权限审计；
• 失败恢复；
• 回归验证。

这样业务侧不用每次都从零搭一套 Agent 服务，而是把精力放回自己的业务能力描述、组件边界和验证样例上。

6. 可复用 Checklist

如果你也在做“Agent + 内部业务工具”或“AI + 低代码平台”，可以先用这份检查清单过一遍。

6.1 组件和能力描述

• 组件是否有明确适用场景？
• 是否写清了不适用场景？
• 必填参数和可选参数是否区分清楚？
• 参数之间是否有约束说明？
• 是否提供了标准示例和反例？
• 不支持的需求应该拒绝，还是继续追问？

6.2 多轮对话和状态管理

• 当前任务是否有唯一上下文？
• 页面里已确认的组件是否被保存？
• 本轮修改作用在哪个组件上？
• 缺失参数是否有单独状态？
• 用户什么时候结束当前页面任务？
• 新任务和旧任务如何隔离？

6.3 工具调用和结果保存

• 工具返回结果是否和用户追问分开？
• 中间结果是否会被追问内容覆盖？
• 异常信息是否可追踪？
• 最终保存前是否有必要校验？
• 失败后是否能恢复到上一个有效状态？

6.4 质量验证

• 是否有固定测试样例？
• 是否能对比生成配置差异？
• 是否记录失败原因分类？
• 是否能复现多轮修改问题？
• 是否能验证一次改动对多个场景的影响？

7. 总结：从能跑到可用，差的是工程闭环

如果只看第一次生成页面，AI 低代码页面生成很容易让人兴奋：图片丢进去，页面出来；一句话过去，配置页链接回来。

但工程团队真正要关心的是：

• 复杂一点还能不能生成；
• 多轮修改会不会破坏已有结果；
• 缺信息时能不能正确追问；
• 工具调用异常能不能恢复；
• 生成结果能不能回到平台继续编辑；
• 每次调整后有没有回归验证。

所以这次探索给我们的结论不是“AI 已经可以完全替代页面搭建”，而是更接近工程落地的一句话：

内部 Agent 想要真正可用，不能只追求模型更强，还要让业务规则、状态管理、工具调用和验证闭环一起成熟。

低代码平台里，组件和配置本身就是工程资产。AI 的价值不是绕开这些资产，而是更低成本地理解、调用，并把结果重新放回平台流程里。

先从高频组件开始，把简单页面做稳；再用测试和日志把问题收集回来，逐步扩大能力边界。这条路没有一次 Demo 那么漂亮，但它更接近真实工程落地。

---

花椒技术交流群

还在孤军研究 AI 工程化、AI 编程、Agent 落地，没人同行交流、没人拆解实战？

这里汇聚一线技术从业者，专注代码评审、企业内部 AI 助手真实实战落地。

想紧跟 AI 前沿动态、交流工程落地经验、少走踩坑弯路，欢迎直接加入「花椒技术交流群」。

群内专属福利拉满：每日精选研发向 AI 行业日报、文章独家延伸资料、文中未展开的技术细节，全部同步共享。

如果群过期关注公众号 花椒技术，私信回复「交流群」获取最新入群二维码。