Oracle 的行业 Agent Studio 还要等十二个月：在等之前该先问清的事

2026 年 10 月 21 日，Oracle 的公告表面上很直接：Oracle AI Agent Studio for Industry Applications，一个低代码/无代码环境，用来为行业专属业务流程创建、测试、编排、部署和管理 AI Agent 与工作流，构建在面向 Fusion 应用的 AI Agent Studio 之上。它包含预置 Agent、工作流、模板与可复用工具，并在 Oracle 行业应用、Fusion 应用与 OCI 之间协调 Agent 与多 Agent 工作流，同时让它们运行在已配置的访问控制与策略之内。真正决定你路线图的细节在脚注里：产品计划在未来 12 个月内上线，先在美国，之后逐步扩展到受支持的 OCI Enterprise AI 区域。那是对方向的承诺，不是一个这季度就能试点的产品。

Oracle 的行业 Agent Studio 还要等十二个

一、公告里到底有什么

把形容词去掉，剩下的是一个构建面，含四块：围绕行业流程设计的预置 Agent、工作流与模板；能围绕你自己的数据、决策、角色与策略去配置它们；部署前可测试与调试，并在采用扩大时监控执行、性能与 AI unit 消耗；以及跨应用协调，让你不必为每个用例单独做点对点集成。被点名的行业是工程与建筑、零售、金融、餐饮、政府、公用事业、通信与酒店。Oracle 自己给的例子很具体：一家工程建筑公司用这个平台识别里程碑风险、定位相关现场问题，并给出供项目团队执行的缓解措施。注意这个例子不是什么——它不是聊天机器人。

# Cost model you want filled in BEFORE a vendor pilot, not after.
# Units, steps and outcomes are variables -- put your measured values in.
python3 - <<'PY'
from dataclasses import dataclass

@dataclass
class Workflow:
    name: str
    runs_per_day: int
    llm_calls: int          # measured, not guessed
    tool_calls: int
    retries: float          # average retries per run
    units_per_llm_call: float
    units_per_tool_call: float
    price_per_unit: float   # whatever the contract says one unit costs

    def units_per_run(self):
        return (self.llm_calls * self.units_per_llm_call +
                self.tool_calls * self.units_per_tool_call) * (1 + self.retries)

    def cost_per_run(self):
        return self.units_per_run() * self.price_per_unit

flows = [
    Workflow("invoice exception", 400, 6, 9, 0.15, 1.0, 0.25, 0.002),
    Workflow("milestone risk review", 40, 11, 14, 0.35, 1.0, 0.25, 0.002),
]

for f in flows:
    print(f"{f.name:<24} units/run={f.units_per_run():7.2f} "
          f"cost/run=${f.cost_per_run():6.3f} "
          f"monthly=${f.cost_per_run()*f.runs_per_day*30:8.0f}")

# If price_per_unit is unknown, print the break-even: at what unit price does
# this workflow stop being cheaper than the manual process it replaces?
PY

二、卖点是「行业上下文」，就把它当断言来测

两段引述定了调。Oracle 行业应用执行副总裁 Simon de Montfort Walker 说，Agent 只有能在一个行业运作所依赖的流程、数据和控制之内工作，才会产生价值。IDC 的 Eric Newmark 说，难点在于 Agent 的有用程度取决于它能触达的数据、工具和审批，而把这三者可靠地连起来正是多数项目卡住的地方。这两句话都对，而且都不是 Oracle 独有的——所以正该把它们当作评估标准而不是差异点。对任何厂商的 Agent 平台都可以问：它能不能不靠定制连接器项目就触达我们真正的记录系统；它是否把审批建模为一等步骤；它能不能说清某个决策的数据来自哪里。如果演示答不出第三个问题，那这个平台就是「挂了个模型的工作流搭建器」。

# Tool contract: define the capability, not the vendor's UI.
# Versioned, schema-validated, and stored in YOUR repository.
{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://example.com/contracts/purchase-order.read/1.0.0",
  "title": "purchase_order.read",
  "version": "1.0.0",
  "description": "Read a purchase order by id. Read-only by construction.",
  "input": {
    "type": "object",
    "required": ["po_id"],
    "additionalProperties": false,
    "properties": {
      "po_id": { "type": "string", "pattern": "^PO-[0-9]{8}$" },
      "fields": { "type": "array", "items": { "type": "string" } }
    }
  },
  "output": {
    "type": "object",
    "required": ["po_id", "status", "total", "currency"],
    "properties": {
      "po_id": { "type": "string" },
      "status": { "enum": ["draft", "approved", "received", "closed"] },
      "total": { "type": "number", "minimum": 0 },
      "currency": { "type": "string", "minLength": 3, "maxLength": 3 }
    }
  },
  "side_effects": "none",
  "rate_limit": { "per_minute": 60 }
}

// A contract with side_effects: "none" can be granted broadly.
// Everything else needs a named approver in the policy file.

三、AI unit 是那个没人先问的定价问题

公告提到会在采用扩大时监控 AI unit 消耗，这很坦诚，也是对任何要签合同的人来说这份发布里最重要的一句。Agent 没有可用的「按人头」成本模型，因为同一个功能可能只花不到一分钱，也可能花几美元，取决于推理步数、重试、工具调用和上下文长度。在接受任何 unit 定义之前，自己先把「unit → 业务结果」的桥搭出来：处理一次发票异常、做一次里程碑风险复核、分诊一次客服工单，各消耗多少 unit。如果厂商说不出这个汇率、你也测不出来，那你签的是一份没有上限的可变成本承诺。下面这段脚本，就是要在试点之前用真实数字填满的那个模型，而不是试点之后。

# Access policy as a diffable file. Intersection, never union.
agents:
  invoice-triage:
    owner: [email protected]
    review_by: 2027-01-31
    tools:
      allow:
        - purchase_order.read
        - invoice.read
        - invoice.flag_for_review   # side effect: creates a task
      deny:
        - payment.release
        - vendor.master_data.write
    constraints:
      business_units: [EU-OP]
      hours: "07:00-19:00 Europe/Berlin"
      max_amount_without_approval: 5000
      approver_for_exceptions: [email protected]

  milestone-risk:
    owner: [email protected]
    tools:
      allow: [project.read, schedule.read, risk.propose_mitigation]
      deny: [schedule.write, contract.amend]
    constraints:
      business_units: [NA-CON]
      require_human_confirm: true

# Rule for multi-agent workflows: effective permissions = INTERSECTION of
# member allows, minus UNION of member denies. Write the test that asserts it.

四、访问控制是功能本体，不是勾选项

Oracle 说 Agent 在已配置的访问控制与策略内运行，而这句话正是「企业平台」与「演示品」的分界线。考验在于粒度。策略能不能表达：这个 Agent 在这个业务单元、在这些时间段内可以读采购订单但不能修改，例外需要指定审批人？能不能表达：一个多 Agent 工作流继承各成员权限的「交集」而不是「并集」？默认取并集，正是 Agent 团队悄悄积累出超过任何单个人类权限的方式，也是你今年会读到的多数 Agent 安全事故背后的失效模式。要他们把策略语言拿出来读一遍——一份不能在 PR 里 diff 的策略，就是一份你无法审计的策略。

# Eval set lives in your repo, built from your own near-misses.
# If the platform cannot run this, the pilot has no success criterion.
python3 - <<'PY'
import json, statistics

CASES = json.load(open("evals/invoice_triage.json"))
# Each case: input payload + expected decision + the reason a human gave.

def score(run_fn, cases=CASES):
    results = []
    for c in cases:
        out = run_fn(c["input"])
        results.append({
            "id": c["id"],
            "decision_ok": out["decision"] == c["expected"]["decision"],
            "reason_ok": c["expected"]["reason_key"].lower()
                         in (out.get("reason") or "").lower(),
            "cited_source": bool(out.get("sources")),
        })
    n = len(results)
    return {
        "cases": n,
        "decision_accuracy": sum(r["decision_ok"] for r in results) / n,
        "reason_accuracy": sum(r["reason_ok"] for r in results) / n,
        "citation_rate": sum(r["cited_source"] for r in results) / n,
    }

# Publish these three numbers per release. Anything else is a demo.
# A vendor that will not run your eval set is a vendor with a fixed script.
PY

五、可迁移性是你唯一留下的杠杆

对这类平台诚实的架构，是在你自己拥有的东西之上，放一层薄且可替换的编排：你定义的工具契约、你写的评测集、你保留的日志。这样一份十二个月的产品路线图就困不住你，因为换编排是一个项目，而不是一次重写。具体做法：把每个业务能力定义成带 JSON Schema 的版本化工具契约；把评测集放在你的仓库里，而不是厂商控制台里；把每条 trace 连同工具参数导出，这样合同结束后你仍能重放某个决策。这些都不稀奇——和你对待任何托管队列、托管数据库该有的纪律一样，也正是多数团队因为演示太好看而跳过的那一部分。

# Portability inventory: where does your orchestration actually live?
# Run monthly. Growing counts inside a vendor console = growing switching cost.
python3 - <<'PY'
import json, pathlib, collections

ROOT = pathlib.Path("automation")
counts = collections.Counter()
contracts = []

for p in ROOT.rglob("*.y*ml"):
    text = p.read_text(encoding="utf-8", errors="ignore")
    if "vendor_platform" in text or "studio_id" in text:
        counts["in_vendor_console"] += 1
    if "tools:" in text and "allow:" in text:
        counts["policy_files"] += 1

for p in ROOT.rglob("contracts/*.json"):
    try:
        c = json.loads(p.read_text())
    except json.JSONDecodeError:
        counts["malformed_contracts"] += 1
        continue
    contracts.append((c.get("title"), c.get("version"),
                      c.get("side_effects", "unknown")))

write_tools = [c for c in contracts if c[2] != "none"]
print("files:", dict(counts))
print("contracts:", len(contracts), "with_side_effects:", len(write_tools))
for c in write_tools[:10]:
    print("  write-capable:", c)

# Target state: orchestration in code you own, contracts versioned in git,
# vendor console holding only credentials and deployment settings.
PY

六、接下来十二个月该做什么

三步，全都不需要 Oracle。第一，把「Agent 被允许做什么」写成机器可读的策略，放在你自己的仓库里，这样无论哪家平台胜出都能消费它。第二，用你自己的事故和未遂事件建一个评测集，因为那才是唯一与你业务相关的基准。第三，现在就开始按业务结果度量成本——用你今天手上跑的任何东西——这样当厂商报价 AI unit 时，你能一步换算成钱。如果 Oracle 的 studio 十二个月后落地，并且在你 Fusion 与行业应用里已有的数据之上把这些都做得好，那对生活在这套栈里的组织确实是一笔好交易。做准备的目的不是回避它，而是在演示那天有能力判断它说的话是不是真的。