用户通过前端描述一个卧室要什么，agent通过数学模型进行碰撞检测发给llm并附上修复tools，然后在进行functional检测，持续react

回复 群友 8334： 明白了，你做的不是“生成一个卧室模型”，而是“根据自然语言需求，自动布置并验证卧室”。我觉得这个切入点比泛化的 3D 创作 Agent 更具体，核心是让布局真正能用。 比如用户说：“放双人床、衣柜和书桌，书桌靠窗，衣柜能正常打开。” 初始布局可能没有家具相交，但衣柜门打不开，或者床把去书桌的路挡住了。你的碰撞检测解决“有没有穿模”，functional 检测解决“能不能使用”，这两层分开是合理的。 不过，我会调整三个地方。 首先，functional 检测也应尽量落到可计算的约束，而不是只把截图发给 LLM 打分。衣柜需要开门空间，椅子需要拉出空间，房门到床边需要可达路径。可以把这些表示成操作区域、开合扫掠体积、通行区域；具体尺寸按家具参数和用户要求确定。 其次，检测结果要返回结构化问题，而不只是“布局不合理”。例如：“衣柜开门区域与床相交；相关对象 wardrobe_1、bed_1；床的位置已被用户锁定。”然后让 Agent 调用移动、旋转、替换家具等工具。精确位移和候选位置可以交给几何算法或求解器，LLM 负责判断该改哪个对象、是否需要放宽需求，不必让它反复猜坐标。 最后，不要无限 ReAct。修完功能问题后必须重新检查碰撞，否则容易来回打架。保留历史最优可行布局，设置迭代上限和无改进退出条件；如果房间确实放不下，就明确指出冲突，询问用户能否换小床或缩减家具，不能擅自牺牲硬约束。 类似的研究方向已经存在：OptiScene 就涉及碰撞规避、功能组织和布局约束，所以“LLM＋检测＋修复循环”本身不是独有创新。 https://arxiv.org/html/2506.07570v1 但你的方向依然值得做。真正能体现价值的是：functional 约束定义得是否准确，修复是否稳定，以及面对互相冲突的用户需求，能否给出可信的解释和替代方案。ReAct 是执行方式，这套可验证的布局能力才是核心。