AI Coding Agent 如何配置后端

AI coding agent 可以先创建一个 Cohesivity 项目租户，读取每项所需服务的最新契约，再逐项配置资源并验证返回的端点，从而完成 Cohesivity 后端的配置。Agent 应复用现有的 .cohesivity 文件，并避免将任何 Cohesivity 凭据放入浏览器代码。

本文介绍配置顺序，不会把每种资源的请求体永久固化在文章中。Agent 执行任务时，应以 offering 页面为准。

从应用需求出发

列出应用所需的状态和外部影响：

关系型数据可能需要 postgres；
Google 登录可能需要 social-login；
文件上传可能需要 object-storage；
公网服务器可能需要 railway-hosting 或 cloudflare-workers；
异步邮件可能需要 inbox；
实时广播可能需要 realtime。

不要因为应用包含 AI 功能就配置向量数据库。Postgres 与向量数据库指南介绍了哪些语义检索场景需要独立存储。

创建或复用项目

首先检查是否存在有效的 .cohesivity 文件。如果存在，请复用该租户。创建新租户会拆散相关资源，也会增加清理难度。

如果项目不存在，先预览初始化过程：

npx @cohesivity/init --dry-run

然后创建临时项目：

npx @cohesivity/init

该命令会写入项目上下文，其中包含管理密钥、应用密钥、租户 ID、生命周期、运行时配置和过期时间。初始租户有效期为 72 小时，无需注册。之后认领租户属于单独的人工授权步骤。

读取每项服务的最新 offering 契约

配置资源前，先获取它当前的 offering 页面，例如最新的 Postgres offering 契约。通过 HTTP 直接请求 Cohesivity 时，需要使用非默认 User-Agent：

curl -sS -A "MyCodingAgent/1.0" \
  https://cohesivity.ai/offerings/postgres

阅读必需的请求体、固定区域、当前限制、身份验证方式、破坏性操作和验证字段，并对每项资源重复这一流程。Agent 可运维后端指南解释了为什么状态查询与清理也属于契约的一部分。

首先配置数据库

当前 Postgres 契约使用的管理面请求与下面类似：

curl -sS -A "MyCodingAgent/1.0" -X POST \
  https://cohesivity.ai/api/resources/postgres \
  -H "Authorization: Bearer <coh_management_key>" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: provision-postgres-v1" \
  -d '{}'

Postgres 只运行在一个区域（新加坡）；请求中的 region 字段会被接受但忽略。只有响应明确表示资源已就绪并返回文档约定的端点时，资源才算可用。不要因为请求返回 200 就自行推断资源已经就绪。

在服务端应用代码中，Postgres 接受一条 SQL 语句或一个原子批次。PostgreSQL 使用 $1 占位符：

curl -sS -A "MyAppServer/1.0" -X POST \
  "https://cohesivity.ai/edge/postgres?key=<coh_application_key>" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: create-signups-schema-v1" \
  -d '{"query":"CREATE TABLE IF NOT EXISTS signups (id BIGSERIAL PRIMARY KEY, email TEXT UNIQUE NOT NULL)"}'

查询字符串凭据是文档约定的备用方式。服务端可以用应用密钥换取短期 edge 会话 token，再改用 bearer 身份验证。这两种凭据都不应出现在客户端 JavaScript 中。

配置身份验证时包含所有回调 URL

配置社交登录会替换完整的回调 URL 列表，因此需要在同一请求中包含开发和生产 URL：

curl -sS -A "MyCodingAgent/1.0" -X POST \
  https://cohesivity.ai/api/resources/social-login \
  -H "Authorization: Bearer <coh_management_key>" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: provision-social-login-v1" \
  -d '{"callback_urls":["http://localhost:3000/auth/done","https://example.cohesivity.app/auth/done"]}'

请使用托管流程返回的实际部署主机名。如果之后只用一个 URL 替换列表，被省略的回调地址将会移除。

根据各自契约配置存储与托管

对象存储配置、上传行为、托管文件格式、环境变量、域名和就绪检查分别有各自的 offering 页面。使用前应立即获取最新内容。目前 Cohesivity 的主要托管路径通过 Railway 托管 API 上传文件，无需 Railway CLI、GitHub 连接或租户持有的 Railway 凭据。

每次配置一项服务并完成验证，再继续下一项。批量请求节省不了多少时间，还会增加定位契约失败项的难度。

验证完整生命周期

完成配置后：

通过管理面查询资源状态。
执行一次服务端应用调用。
使用同一个幂等键重复一次写入，并确认只产生一次影响。
确认浏览器资源、日志或版本控制中没有任何 coh_* 值。
记录租户过期时间和认领边界。
记录每项一次性资源的移除方式。

下方的提示词会让 coding agent 提出最小资源集合，并在创建任何资源前停止。

AI Coding Agent 如何配置数据库、身份验证、存储和托管