我做了一个交互站，把企业 Agent 建站从需求到发布完整拆开

我最近完成了一个叫 Agent Site X-Ray 的交互站：

https://agent-site-xray-lab.wangzq.chatgpt.site

它想解决一个很具体的问题：当我们说“Agent 会建站”时，Agent 到底完成了哪些工程工作？

第一版项目其实已经能用了，但方向不太对。当时的重点是队列、缓存、数据库等后端组件。每个技术点都可以解释得很细，可读者走完整个站点以后，仍然缺少产品与工程的整体认识：需求是谁确认的，Spec 从哪里来，代码归谁，后端资源怎样申请，企业账号怎样接入，生产版本怎样发布，出现问题怎样回滚。

所以我重做了一遍。新的站点不再从某个技术组件开始，而是让同一个 demo-shop 贯穿五个实验。

一、从一句需求开始，观察 Agent 留下哪些产物

示例需求并不复杂：做一个企业礼品订购站，员工使用公司账号登录，商品可搜索，重复点击不能产生两张订单，管理员只能查看本部门订单。

站点把接下来的工作拆成六步。

1. 理解需求

Agent 先提取角色、业务流程、数据边界、验收条件和仍待确认的问题。

例如，员工只能查看自己的订单，部门管理员不能跨部门读取；取消规则、库存扣减时机、数据保留周期还没有答案。这些问题不能悄悄变成代码里的默认行为，要么追问，要么明确记录假设。

2. 生成 Spec

需求得到确认后，Agent 才生成页面、API、数据表、权限、运行时 Binding 和发布策略。

我把 Spec 放在这个步骤下面，而不是放在用户需求旁边。原因很简单：Spec 是 Agent 推导出来的应用合同，不是用户原话。它需要单独审查，也需要进入版本管理。

3. 生成代码

Agent 根据已批准的 Spec 生成 TypeScript、React、Node、SQL、迁移和测试。预览环境只连接开发资源，不能接触生产数据库和生产密钥。

4. 提交 Git

临时工作区不应该成为事实源。生成代码要形成清晰的 diff，记录 prompt、Spec hash、模型运行和 commit SHA 的对应关系，再提交给工程师审查。

5. 质量门禁

“页面能打开”不等于可以发布。站点展示了类型检查、单元测试、E2E、依赖与密钥扫描、迁移 dry-run、租户越权用例和人工预览审批。

6. 发布版本

生产发布使用已经通过审查的同一份 Git SHA 和构建产物，登记为不可变版本。active 指针从旧版移到新版，旧制品继续保留。代码回滚可以切换版本，数据库恢复则需要独立方案。

这六步想表达的是：Agent 建站平台首先是一个工程控制面。生成代码只是其中一个阶段，前后还需要需求、资源、身份、审查和发布证据。

二、点击一次“下单”，追踪完整请求路径

第二个实验从浏览器按钮开始，把一次订单请求分成八个节点：

React 页面、企业 API Gateway、身份上下文、V8/FaaS 函数、BaaS Adapter、Redis、MySQL、审计与 OpenTelemetry Trace。

第一次点击时，前端发起请求。网关完成路由、TLS、限流和请求 ID；身份层验证 OIDC/JWT 中的用户与组织信息；订单函数在受限运行时中执行；Adapter 把逻辑 Binding 翻译为具体后端能力。

接下来 Redis 尝试写入幂等键。首次请求成功占位，MySQL 在事务里写入订单、订单项和关联审计字段。第二次提交相同请求时，Redis 返回已有结果，函数不会再次创建订单。

这个实验帮助区分几个常见误区：

浏览器负责交互，不是业务安全边界；
认证回答“你是谁”，授权回答“你能做什么”；
Redis 适合短期幂等和热数据，MySQL 才是订单事实来源；
BaaS Adapter 让生成代码不必直接绑定某个产品的 SDK 和错误模型；
日志、指标、Trace 和审计有关联，但用途不同。

三、把 BaaS/FaaS 部署展开成十个动作

第三个实验提供企业自建 BaaS + V8、Supabase、Firebase 和 Appwrite 四个落点。

平台不同，部署步骤不能简单复制，但可以用同一组问题检查：

是否锁定了经过审批的 Git SHA、Spec、Schema 和依赖锁文件？
租户、环境、区域、配额和数据等级是否明确？
数据库、缓存、存储、队列与域名如何创建或复用？
OIDC/SAML 回调和组织角色如何映射？
Migration、索引和数据权限是否经过 dry-run 与越权测试？
函数拿到的是不是最小权限、短期凭证？
构建是否可复现，是否生成 SBOM 并经过扫描？
新版本能否先进入隔离预览，完成冒烟、E2E 与人工审批？
生产流量是否分阶段切换，并按版本观察指标？
激活新版本以后，审计记录和回滚目标是否完整？

这也是站点对“热部署”的解释。开发环境的 HMR 适合快速反馈；生产环境更适合生成一个新的不可变版本，先让它 Ready，再逐步转移流量。原地替换正在运行的代码虽然听起来直接，却会让回滚、请求一致性和审计变得困难。

数据库迁移还要更加谨慎。代码可以切回旧版，已经写入或改变结构的数据不会自动恢复。因此 Schema 需要兼容窗口、恢复点和单独的恢复预案。

四、企业账号打通后，权限工作才刚开始

第四个实验展示企业 IdP、OIDC/SAML、JWT Claims、网关验证、RBAC/ABAC、函数身份、数据层行权限和审计。

用户可以模拟一次登录，也可以触发 SCIM 撤权。离职或调岗事件到来后，系统需要停止新登录、终止现有会话、撤销角色和短期凭证，并记录完成时间。

只在前端隐藏按钮并不能形成权限边界。网关、函数和数据层都要验证自己的那一段条件。尤其是多租户系统，查询必须带上 tenant 或组织范围，不能依赖调用者“自觉”传对参数。

五、平台选型先看缺的是哪一层

最后一个实验比较 Supabase、Firebase、Appwrite 和 Cloudflare Workers for Platforms。

Supabase 擅长关系数据、SQL、RLS、迁移和 pgvector，更像 Agent 建站的数据与后端平面。Appwrite 同时提供 Sites、Functions、Auth、DB 和 Storage，接近一体化应用交付底座，也保留 Docker 自托管路径。Firebase 的托管体验和 Google Cloud 结合紧密。Workers for Platforms 适合大量租户动态上传并运行代码，但企业身份、数据治理和完整 BaaS 仍要另外组合。

这些判断不能只看产品首页。站内内容明确标记了三种证据等级：可以从官方文档核对的事实、跨产品能力得到的架构综合判断、必须进入真实企业环境做 PoC 的部分。

六、如何验证这个站点

打开首页以后，可以按下面顺序体验：

在“Agent 如何建站”里依次点击 01 到 06，观察详情和产物是否真的变化。
回放完整建站过程，查看版本是否进入可发布状态。
进入“点击下单发生什么”，连续提交两次，观察第二次是否命中已有订单。
在部署实验里切换四个平台，并走完十个步骤。
在权限实验中完成 SSO 登录，再模拟 SCIM 撤权。
到平台地图中查看选型判断和官方研究链接。

七、目前没有解决的事情

Agent Site X-Ray 是学习站，不是可以直接接入生产的 BaaS/FaaS 或 Agent 建站平台。demo-shop 的订单、版本、日志和部署过程都是模拟数据。

自建 V8 的隔离强度、公共服务 Binding、企业内网身份、资源配额、成本、压测和故障恢复，需要放到真实环境中验证。平台能力也会持续变化，正式选型前仍要回到官方文档。

如果你正在做 Agent 应用、低代码平台、内部工具或 AI 应用交付，可以直接走一遍：