AI智能体遇上房地产媒体：为Astra时代做准备

转变：从描述软件的模型，到操作软件的智能体

直到不久之前，AI模型与你的房产软件之间还只是建议关系。它能告诉你该在CRM里写什么，但打不开CRM。

这条界线在2026年9月移动了。OpenAI于9月3日发布的GPT-6 Astra围绕电脑操作构建——号称你在电脑上能做的任何事它都能替你做——并在OSWorld 2.0电脑操作基准上得分72.6%，每个任务平均约40分钟。同名却不相干的Google Project Astra，一个面向受信任测试者的DeepMind研究原型，则从另一个方向指向同一个目的地。整个行业的行进方向，是会行动的智能体。

具体到房产媒体，这改变的是谁来按按钮。一次房源拍摄一直都是一串软件操作：上传、挑选、软装、增强、转换、标注、发布。这些操作现在可以端到端自动化，于是引出一个多数地产科技团队还没回答的设计问题——要让智能体安全地驱动它，你的技术栈需要长成什么样？

智能体驱动的媒体管线长什么样

具体地说，智能体为一条房源跑的循环是这样的：

步骤	智能体做什么	它调用什么
1. 接入	读取新房源记录，拉取整组照片	你的CRM或DAM
2. 分拣	给照片归类：软装、增强、重拍、丢弃	视觉语言推理
3. 简报	为每张照片确定房型、风格和目标买家	它自己的推理，加上你的风格指南
4. 渲染	每张照片提交一个任务	一个图像API
5. 等待	接收Webhook回调，或轮询	同一个API
6. 校验	把输出与原图对比，查结构漂移	视觉语言推理
7. 发布	把结果写回，应用披露标签	你的CRM和门户数据流
8. 报告	记录成本、失败和已计费张数	你的财务

第2、3、6、8步是智能体模型真正赚回工钱的地方。第4步是它交棒的地方，因为智能体模型不渲染图像——这项重要限制在《GPT-6 Astra能做虚拟软装吗？》中有更详细的讨论。

架构上的要点是：智能体应当调用API，而不是在网页应用里点来点去。电脑操作是给没有API的软件用的兼容层。当API存在时，用API更快、更便宜、确定性更强，而且——凌晨三点最要紧的那部分——可调试。

实例：智能体通过图像API为一条房源做软装

这个例子用Roomagen API，因为我们能把它的精确形态写下来；这个模式可以推广到任何基于任务的图像API。

第1步——智能体为每张照片提交一个任务。 认证只是一个请求头。每个任务进一张图、出一张图，并立即计费。

curl -X POST https://api.roomagen.com/api/v1/jobs \
  -H "X-Api-Key: rmg_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: listing-8842-photo-03" \
  -d '{
    "tool": "virtual-staging",
    "image_url": "https://cdn.yourapp.com/listings/8842/photo-03.jpg",
    "options": { "style": "scandinavian", "roomType": "living-room" },
    "webhook_url": "https://yourapp.com/hooks/roomagen"
  }'

响应在生成结束之前就返回：

{
  "job_id": "3f1c9d4e-5b2a-4c8e-9f10-7d6a2b3c4e5f",
  "status": "processing",
  "images_charged": 1
}

有三个细节对智能体比对人类集成者更重要：

• Idempotency-Key是安全护栏。 一个丢失进度并重试的智能体，否则会付两次钱。有了一把从你自己的记录派生出来的稳定密钥——房源ID加照片ID——重放会重新返回原任务，而不是新建一个。
• images_charged在创建时就返回，所以智能体可以在花钱的同一个回合里把这笔花销记上，而不用事后对账。
• tool只是一个slug。 同样的调用形态可以跑日转夜转换、物品移除或图像增强；GET /api/v1/tools返回权威列表，含每个工具按张计的成本。智能体应当去取这份列表，而不是硬编码它可能凭空捏造的slug。

第2步——智能体通过Webhook接收结果。 任务完成时，API会把完成的任务POST到你的端点，并加上一个event字段：

{
  "job_id": "3f1c9d4e-5b2a-4c8e-9f10-7d6a2b3c4e5f",
  "tool": "virtual-staging",
  "status": "completed",
  "images_charged": 1,
  "result_urls": ["https://api.roomagen.com/api/uploads/9c2f7a10-render.jpg"],
  "error": null,
  "created_at": "2026-09-06T09:14:02.114Z",
  "completed_at": "2026-09-06T09:14:39.902Z",
  "processing_ms": 37788,
  "event": "job.completed"
}

在你相信它的任何一个字节之前，先验签。推送会携带X-Roomagen-Event、X-Roomagen-Timestamp和X-Roomagen-Signature: v1=<hex>，其中摘要是用你的whsec_密钥对{timestamp}.{raw body}做的HMAC-SHA256：

const crypto = require("crypto");

function verify(rawBody, headers, secret) {
  const ts = headers["x-roomagen-timestamp"];
  const expected =
    "v1=" + crypto.createHmac("sha256", secret).update(`${ts}.${rawBody}`).digest("hex");
  const got = headers["x-roomagen-signature"];
  if (got.length !== expected.length) return false;
  if (!crypto.timingSafeEqual(Buffer.from(got), Buffer.from(expected))) return false;
  return Math.abs(Date.now() / 1000 - Number(ts)) < 300;
}

摘要要对原始请求体字节计算，不要用重新序列化的JSON，并拒收超过约五分钟的时间戳。

第3步——轮询作为兜底。 Webhook会失败；只依赖它的智能体会无声地卡住。GET /api/v1/jobs/{id}返回同一个对象，因此一个监督循环可以把处理中状态过久的任务对上账：

async function waitForJob(jobId) {
  for (;;) {
    const res = await fetch(`https://api.roomagen.com/api/v1/jobs/${jobId}`, {
      headers: { "X-Api-Key": process.env.ROOMAGEN_API_KEY },
    });
    const job = await res.json();
    if (job.status !== "processing") return job;
    await new Promise((r) => setTimeout(r, 3000));
  }
}

典型完成时间是20–60秒，所以每2–5秒轮询一次，并把超过几分钟的当作卡住而不是慢。

第4步——智能体必须分支处理的错误。 每个非2xx响应都是{ "error": { "code", "message", "doc_url" } }。要按code分支，绝不要按message——面向人的文案会变，代码不会。自动化运行真正会遇到的有：invalid_tool（捏造的slug）、invalid_image和image_fetch_failed（你的CDN不肯提供的源URL）、webhook_url_rejected（私有或回环地址）、payload_too_large、积分不足和限流。没有为这些各自设置显式分支的智能体，会盲目重试并烧掉积分。

智能体为什么需要确定性的工具，而不是聊天界面

智能体驱动媒体里让人不舒服的真相是：瓶颈不是模型智力，而是工具的确定性。 智能体的可靠度不会超过它所操作的接口，而让一个接口对智能体友好的那些特性，都不光鲜：

• 幂等性，让重试是免费的而不是要计费的。
• 稳定的机器可读错误码，让失败处理是一次分支而不是一次猜测。
• 一个发现端点，列出有效的工具slug和成本，让智能体去核实而不是去假设。
• 带签名的推送通知，让"完成"不依赖智能体一直醒着。
• 在响应中报告成本，让花销按动作可观测。
• 一份公开的失败政策，让智能体知道一次失败的渲染要不要花钱。

聊天界面一条也不具备。这就是为什么"让智能体直接用我们的网页应用就行"是一个演示好看、运行糟糕的计划：每次UI变更都会打断运行，没有任何东西是幂等的，而一次失败呈现出来的是一张截图而不是一个错误码。

没人做进预算的失败模式

穿过你自己收件箱的提示词注入。 公开测试显示，Astra在Gray Swan的IPI Arena上的间接提示词注入成功率约为8.5%——相比其前代报告的27%是一次改进，但仍约等于每十二份敌意文档就有一份得手。一个房产智能体会阅读陌生人写的邮件、PDF和门户房源。就假设其中一些含有针对你的智能体的指令，永远不要把不可信输入和无人监督的发布或付款权限交给同一个智能体。

至少一次的Webhook投递。 Webhook投递在设计上是"至少一次"：一个在做完工作之后才超时的处理器会被重投，所以消费方必须按job_id去重，并保持处理器幂等。Roomagen的重试计划是在约36分钟内最多五次；智能体绝不能把第一次投递当成唯一一次。

没有顺序保证。 不要假设Webhook会在你自己的POST返回之后才到达，也不要假设任务A的回调先于任务B。要写出能容忍任意到达顺序的状态机。

成本失控。 一个陷入困惑的智能体会打转。一次针对60张照片的重试风暴就是一张真实账单。设死支出上限，在批量运行前查一次余额端点，并对异常的任务创建速率报警。

无声的结构漂移。 输出是一张有效图片，任务状态是completed，但窗户挪了位。管线里没有任何环节会报错。只有一个校验步骤能抓住它——要么是人，要么是一个把输出与原图对比并标出差异的智能体。

没人应用的披露。 人编辑照片时，人会记得披露规则。智能体凌晨四点做这件事时，只有代码记得。把标注和原图留存烤进管线本身——见MLS与AB 723披露指南。

地产科技团队的智能体就绪清单

给你自己的技术栈打分。每一项没打勾的，都是自动化运行会崩掉的地方。

1. 管线里的每个系统都有API吗？ 只有界面的东西，只能靠电脑操作来驱动——更慢、更贵、更脆。
2. 写操作是幂等的吗？ 同一个请求能否重放而不重复扣费或重复建记录？
3. 你的集成返回机器可读的错误码吗，还是返回一段话？
4. 有没有一个发现端点，让智能体去查询有效选项而不是靠猜？
5. Webhook有签名吗，你会验签吗，是对原始字节用常量时间比较吗？
6. 你的Webhook处理器会去重吗，能容忍乱序到达吗？
7. 每条推送通道都有轮询兜底吗？
8. 花销按动作可观测吗，并按周期设了上限吗？
9. 不可信输入与那些能发布、付款或签约的凭证隔离了吗？
10. 披露是由代码强制的，还是靠某个人的习惯？
11. 有没有审计链路，把每张已发布图片与产出它的任务、原始照片以及请求它的那次智能体运行连起来？
12. 有没有一份写明的停止条件——什么情况下运行会中止并叫醒一个人？

今天能勾上12项中10项的团队，已经具备把媒体管线交给智能体的条件。低于这个数的团队应当先修集成面：一个更聪明的模型，补不上一个无法被安全自动化的技术栈。

仍然属于人的部分

三件事，而且短期内不会移动。

呈现的判断。 一张软装照片是否公正地呈现了一处房产，是一个带有法律和伦理分量的判断。智能体可以标记；该由人来决定。

面向客户的例外。 当卖家对自家房子的渲染结果不满意时，答案是一次对话，不是一次重试。

支出权限。 自动化的是工作，不是预算。一个在智能体控制之外强制执行的硬上限，是整套架构里最便宜的保险。

结论

Astra时代不意味着模型会做你的房源照片。它意味着模型会操作那些做照片的工具，于是压力落在工具身上，而不是智力身上。

能从这次转变中拿到价值的房产团队，会是那些媒体技术栈以API为先、幂等、带签名、可观测且有上限的团队——正是那些让系统对人类工程师也用得舒服的特性，如今由一个永远不厌其烦重试的操作者来强制执行。如果你要把一个智能体接到图像管线上，Roomagen API文档有完整的请求与Webhook规范，API总览则涵盖定价和可用工具。

本文中的模型能力、基准分数和定价反映截至2026年9月的公开报道。API请求形态反映撰稿时的Roomagen API v1；当前规范请查阅文档。