Construct AI：让智能体在工作区内直接生成内部应用

Construct 近日上线了「工作区应用」（workspace app）能力，用户可以用自然语言向 AI 智能体描述重复性的内部工作流程，智能体则在该工作区内直接生成一个 React + TypeScript 小型应用，而不是输出代码片段或链接到外部托管平台。这一思路的核心是把应用、数据和触发它的智能体放在同一个工作区里，让「写应用」和「用应用」共用同一份上下文。

从重复流程出发，而非预设架构

Construct 强调，最好的需求描述应该聚焦「工作内容」而不是「软件架构」。官方列举的典型请求包括：

• 「搭建一个研究请求跟踪器，包含负责人、优先级、状态以及成品的链接。」
• 「把这个周期性上线清单变成团队可以更新的应用。」
• 「为这个工作区里的 JSON 报告做一个仪表盘。」
• 「做一个客户审核请求的录入表单，把队列统一管理。」

智能体会根据这些描述判断是清单、表单还是仪表盘，生成应用包、撰写 React 与 TypeScript 源码、声明所需能力，并执行验证；构建成功后直接在 Construct 的桌面端打开，而不是跳转到一个独立的托管项目。

应用、数据与智能体同处一个工作区

工作区应用并非黑盒产物：源码放在 Files 目录下的 Apps/<app-id>/ 文件夹里，可被检视与编辑；持久化数据单独存放在 AppData/<app-id>/，与应用界面解耦，更新界面不会覆盖已有的应用数据，数据仍占用工作区的常规存储配额。这种设计让「工作区智能体」在应用上线后依然有用——如果界面需要新增字段或出现运行时错误，下一次任务可以直接基于真实源码继续修改，而不是凭截图和模糊的 bug 描述。

能力边界与权限声明

官方对当前运行时的能力做了明确限制：

• 支持 React 界面、TypeScript/TSX；
• 读写工作区文件需显式声明权限；
• 应用级 JSON 状态同样需要 Files 权限；
• 调用已连接的其它应用需走显式 allowlist；
• 网络请求只允许发往声明过的 HTTPS 来源；
• 不支持安装任意 npm 包、不支持从应用界面运行终端或智能体编排、不支持自动发布到公共应用市场。

应用界面获得一个精简的 Construct SDK，涵盖工作区文件、应用级存储、通知、窗口控制和被明确允许的调用——它并不会继承构建它的智能体所使用的全部工具。权限层面，平台会在应用发起网关调用时重新检查工作区成员身份与权限，文件操作受用户当前工作区访问限制，应用也不能借助自己的文件权限去改写其它应用的包，HTTPS 来源必须是精确匹配而非通配符域。官方将这种「按需最小权限」作为推荐的默认设定。

验证与可靠性：构建成功不等于运行正确

上线前，Construct 会检查包结构与 manifest、追踪相对导入、强制包边界、编译 TypeScript 与 JSX，并产出设计层面的诊断结果。一次成功的验证会生成带确定性 build ID 的不可变产物，并打开应用；但官方同时强调，这只证明包能在工作区运行时构建成功，并不保证每个按钮、数据形态、连接服务或边界条件都按预期工作，运行时验证依然必要，尤其在权限、存储行为或外部调用发生变化之后。智能体可以读取近期的控制台、网络、网关与运行时错误日志，修复源码后再次验证，请用户复核修改后的行为——这一闭环更接近「维护一个小型内部产品」，而不是「生成一段一次性代码」。在可靠性模型上，一次成功构建即成为当前运行产物；之后的源码编辑会把应用标记为「有草稿修改」，但打开应用时仍运行上次成功构建，直到新源码通过验证；若验证失败，正在运行的产物不会被替换，放弃编辑同样保留旧版本。

总体来看，Construct 这套能力把「AI 写应用」从一次性代码生成推进到了带权限边界、版本管理与运行时诊断的工作区内应用形态，但其影响仍局限于使用 Construct 工作区的团队，对更广泛的 AI 开发工具生态的拉动有限。