GPT-5.6进Kiro：82%成本降幅怎么测

“成本降低 82%”很容易变成一句营销数字。

真正决定这个数字是否对你的团队有意义，需要先把公式写出来：

Cost per Successful Task
=
全部Agent调用成本
/
最终成功完成的任务数

而不是只看：

单次请求Token价格

OpenAI 8 月 24 日公布 GPT-5.6 Sol、Terra、Luna 已进入 AWS Kiro，并给出一个很具体的数据：在 Terminal-Bench 2.1 上，GPT-5.6 Terra 在 Kiro 环境里完成成功任务的成本约下降 82%。

同一篇文章同时强调 Kiro 的 spec-driven development：先把高层需求转成结构化 Requirement、Technical Design 和 Executable Task，再让模型执行；关键节点继续人工 Review，并用 property-based testing 验证实现正确性。

如果你想判断这套结果能不能复制，不能只跑一个 Benchmark。

应该拆开看：

模型
Harness
Spec质量
迭代次数
成功率
验证成本

到底是谁把成本压下来的。

第一个指标不是Token，而是Task Success

假设模型 A：

单次任务成本：
$0.80

一次成功率：
50%

平均需要两次：

$1.60 / successful task

模型 B：

单次：
$1.10

一次成功率：
85%

如果大多数一次完成：

约 $1.29 / successful task

虽然单次更贵，真正完成工作的成本反而更低。

所以所有 Coding Agent 选型，至少同时记录：

Attempt Cost
Success Rate
Retry Count
Human Rework

一个最小成本模型

from dataclasses import dataclass

@dataclass
class Attempt:
    model_cost: float
    infra_cost: float
    review_cost: float
    success: bool

def cost_per_success(attempts):
    total = sum(
        a.model_cost
        + a.infra_cost
        + a.review_cost
        for a in attempts
    )

    successes = sum(
        1 for a in attempts
        if a.success
    )

    return (
        total / successes
        if successes
        else float("inf")
    )

这样失败尝试不会被漏掉。

Kiro这次最值得拆的是Spec-driven Harness

OpenAI 对 Kiro 的描述不是：

把Issue原样丢给模型

而是先形成：

Requirement
Technical Design
Executable Tasks

这会直接减少模型搜索空间。

例如用户说：

给订单系统增加批量取消功能

裸 Agent 可能自己猜：

API
权限
状态
数据库
事件

Spec-driven 先固定：

requirement:
  batch_size_max: 100
  allowed_status:
    - CREATED
    - PAID

authorization:
  permission: order.batch.cancel

behavior:
  atomic: false
  return_per_item_result: true

non_goals:
  - refund
  - shipment_recall

Agent 面对的是明确合同。

这通常会减少：

走错方向
重复改动
无效测试

所以要区分Model Gain和Harness Gain

A/B 测试至少做四组：

A:
旧模型 + 旧Harness

B:
GPT-5.6 Terra + 旧Harness

C:
旧模型 + Spec Harness

D:
GPT-5.6 Terra + Spec Harness

如果只比较 A 和 D，你不知道提升来自模型还是 Harness。

实验矩阵

组 模型 Spec Property Test
A Baseline 否 否
B Terra 否 否
C Baseline 是 是
D Terra 是 是

每组跑同一批真实任务。

Task Set不要只选容易成功的

我会分：

Bug Fix
Feature
Refactor
Dependency Upgrade
Test Migration
Cross-file Change

再按复杂度：

S
M
L

例如 60 个 Case：

6类 × 3难度 × 若干样本

不要拿 10 个特别适合 Agent 的 Task 做结论。

每个Case都要有Definition of Done

例如：

case_id: order-batch-cancel-17

required:
  - compile
  - unit_test
  - integration_test
  - api_contract

forbidden:
  - change_db_schema
  - modify_payment

max_files_changed: 12

模型自己说“完成了”不算成功。

Gate 通过才算。

Property-based Testing为什么值得关注

OpenAI 特别提到 Kiro 会用 property-based testing 检查正确性。

传统测试：

输入1
期望A

Property Test：

对一大批自动生成输入
检查不变量

例如批量取消：

任何时候：
取消成功数 + 失败数
必须等于输入订单数

@given(order_ids=order_id_lists())
def test_result_count(order_ids):
    result = cancel_orders(order_ids)

    assert (
        len(result.success)
        + len(result.failed)
        == len(order_ids)
    )

这类测试很适合 Agent，因为它能防止模型只修样例。

再加一个Invariant：不能重复取消

@given(order=cancelable_order())
def test_idempotency(order):
    first = cancel(order.id)
    second = cancel(order.id)

    assert first.status == "CANCELED"
    assert second.status == "ALREADY_CANCELED"

Agent 改代码后，不只跑人工写的几个固定 Case。

成本里必须算Review

很多 Coding Agent Benchmark 只算 Model Token。

企业真正成本包括：

模型
Sandbox
CI
Review
Rework
Incident

例如：

Agent生成成本：
$2

工程师Review：
18分钟

人工成本：
$1 / min

真正就是：

$20

模型成本只占 10%。

如果新模型让 Review 从：

18min → 7min

即使 Token 更贵，也可能非常划算。

我会记录Human Edit Distance

不只是 Review 时间。

例如 Agent 提交 120 行，最后人手改 5 行，和重写 70 行完全不同。

可以记录：

post_agent_diff_lines
human_modified_lines

计算：

Human Modification Ratio

还有一个指标：Iterations to Green

第一次生成
↓
CI失败
↓
第二次修
↓
Lint失败
↓
第三次修
↓
Green

记：

iterations_to_green = 3

如果 GPT-5.6 的真正优势是更少迭代，这个指标会比 Token 数更直接。

一个完整Case记录

{
  "case_id": "feature-018",
  "model": "gpt-5.6-terra",
  "harness": "spec-v4",
  "attempts": 2,
  "model_cost": 1.82,
  "sandbox_cost": 0.44,
  "ci_minutes": 11.8,
  "review_minutes": 8.5,
  "human_modified_lines": 7,
  "task_success": true
}

不要只比较平均值

Coding Task 成本经常长尾。

大多数：

$1—3

少数卡死：

$20+

所以看：

Median
P90
P95
Max

尤其 P95。

一个模型平均便宜，但偶尔进入长循环，会非常难控预算。

设置Task Budget

agent_budget:
  max_model_calls: 18
  max_cost_usd: 5
  max_wall_time: 30m
  max_replans: 3

达到就停：

ESCALATE_TO_HUMAN

不要为了 Benchmark 成功率允许 Agent 无限烧钱。

Spec本身也有成本

别忘了：

谁写Requirement？
谁写Technical Design？

如果每个任务都需要资深工程师花 40 分钟准备 Spec，82% 模型成本下降可能根本不重要。

所以记录：

spec_authoring_minutes

如果 Spec 可以从 Issue + Repo + Team Standards 自动生成，再由人 Review，成本才会下降。

一个更合理的ROI公式

Total Task Cost
=
Spec Preparation
+ Agent Execution
+ CI
+ Human Review
+ Rework

再除以 Successful Tasks。

不要只看 API 账单。

我会专门做无Spec压力测试

原因很简单，生产 Issue 不会永远写得很完美。

所以 Test Set 里至少 30%：

Ambiguous Requirement

看 Agent 是否主动提问、合理停下来，而不是擅自实现。

Spec-driven最大的风险是把错误需求固化得更彻底

Spec 写错：

batch cancel允许取消SHIPPED

Agent 非常认真地全部实现。

所以 Spec Gate 必须有：

Domain Review

模型执行得越稳定，错误 Spec 的伤害越大。

我会给Spec加来源

requirement:
  source:
    - ticket: PROD-1842
    - api_contract: order-v7
    - policy: refund-v12

关键规则要能追溯。

什么时候Terra更值得用

不要因为 Benchmark 就全部任务统一。

我会按层路由：

Luna:
小修改
分类
文档
简单测试

Terra:
多数Feature
Bug Fix
Cross-file Change

Sol:
高复杂架构
困难调试
最终Review

最后还是用自己的 Cost per Successful Task 确定边界。

GPT-5.6 Terra 在 Kiro 的 Terminal-Bench 2.1 里给出的约 82% 成本下降，是一个值得验证的信号。

但真正应该复制的不是数字，而是这套工程方向：

清晰Spec
减少搜索空间
Property Test
减少错误成功
关键节点Review
限制迭代
最后计算成功任务成本

模型价格只决定一部分账单。

真正昂贵的是模型走错方向以后，反复执行、反复修、最后还要人重写。

所以 Coding Agent 选型以后，我不会再问：

哪个模型每百万Token更便宜？

而会直接问：

同一批真实任务，哪个组合能用最低总成本稳定交付Green结果？

更多企业级 AI 应用、Agent、RAG 与模型工程化内容，我会继续整理在 智元界：

https://www.zyentor.com/