业务Agent架构：把Coding Agent接入商业软件实践

在构建具备生成能力的商业软件时，我们常常面临一类典型的跨域需求。例如，商家可能会发出这样的指令：“筛选出当前库存充足的商品，补充英文介绍，准备促销活动，并先让我审阅。”

动态需求与沙箱执行

这个请求同时横跨了商品规格、库存管理、多语言内容和促销交易等多个底层服务。如果仅依靠预先枚举的接口或封装好的离散工具进行组合，系统很难覆盖所有动态需求的排列组合。为此，平台允许模型在具备文件系统和执行环境的沙箱内工作。Agent 可以阅读平台提供的授权 Schema 和业务数据视图，通过编写脚本来处理复杂的中间数据并生成修改建议。在这套机制中，明确的原子化任务依然适合直接的工具调用（Tool Calling），代码执行与工具调用相互组合，通过多次执行循环共同完成任务。

我们为什么让业务 Agent 像 Coding Agent 一样工作

状态隔离与并行演进

在上述机制中，Agent 生成修改建议仅仅是第一步。为了支撑持续运行的真实产品，平台需要明确界定不同类型状态的归属，并为高频并发的变更提供稳定的执行路径。

当一个站点生成后，通常会面临几种并发的演进：商家在可视化画布上调整文字和样式，Agent 在沙箱中持续接收指令修改源码，而真实的交易环境里商品价格和后台数据也在独立变动。为了接住这些变化，宿主平台对状态进行了清晰的职责划分：

一方面是项目状态，这包含源码、页面引用以及受支持的实例覆盖。另一方面是业务状态，诸如商品价格、库存与促销规则，它们严格属于原有的业务服务。平台在准备执行环境时，复用的是只读源码快照与授权业务数据快照。这种分离确保了项目修改和业务变更能够使用各自独立的版本控制、校验逻辑与撤销机制。

当执行进入到真实写入阶段时，操作必须继续走原有的业务服务。执行成功、用户确认和业务写入属于不同的阶段，最终写入必须重新核对当前的用户权限、实体版本与强约束条件。

源码派生与可视化编辑

在前端页面的持续维护上，系统需要在代码库与可视化界面之间建立映射。我们选择复用内部现有的源码、SDK、文档和编译环境，而非重写另一套完整的页面生成语言。系统主要依靠编译器分析普通的 React 代码，结合运行时观测，来派生出编辑索引。在这个架构下，编译索引和预览视图仅仅是派生产物，平台依靠源码本身来维持真实状态，而不另立一份脱离源码的可编辑页面树。普通的 React 代码能够在沙箱中运行，并不代表其中所有的动态表达式都支持从画布进行反向的可视化编辑。

如何让 AI 生成的前端代码支持可视化编辑