Agent 产品战略与单位经济学：从 Token 消耗到 Verified Outcome

研究基线与 freshness audit：2026-08-03。本文讨论的是 Agent 产品的经济对象、成本结构、路由、产能、定价、增长与护城河，不是财务预测，也不把任何厂商的营销数据当作普遍规律。产品状态、套餐和价格均按该日可访问的官方页面核验；它们是时点事实，后续使用必须重新检查。2026 年引用的 arXiv 论文如未另述均为 v1 preprint、未经同行评审。所有自建公式都是决策模型，不是自然定律。

0. 先给出总判断

Agent 产品最根本的变化，不是一次请求消耗了更多 token，而是用户与系统之间的交易对象变了：

Chat：       用户购买一次认知响应
Copilot：    用户购买一次局部操作增益
Agent：      用户委派一个有边界、有验收、有风险的工作单元
Managed Agent：用户购买一组按 SLA 交付、可并行管理的工作产能

因此必须区分四种经常被混为一谈的单位：

核心结论：价值单位正在向 delegated task / verified outcome 迁移，不等于所有厂商都应立即按 outcome 收费。 资源计量仍可能按 token；套餐仍可能按 seat；负载仍可能按请求限流；但产品优化和 ROI 归因必须围绕“被验收的任务结果”。

OpenAI 2026 年对 Codex 使用的分析直接把 agentic work 描述为从单次交互转向 delegated、long-horizon task：到 2026-05，在抽样 individual users 中，80.6% 至少提交过一项被估算为超过 30 分钟人类工作的请求，70.2% 超过 1 小时，25.6% 超过 8 小时；到 6 月，OpenAI 内部日活用户的 P99 可产生超过 60 agent-turn hours/day，来自并行任务。这里的 individual 结论只基于随机 0.1% 用户样本，task horizon 由 LLM-as-judge 估算；internal P99 又是单一公司使用行为，既不是 elapsed human time，也不能外推为全行业生产率，但支持“工作单位变化”这一结构判断。How agents are transforming work

Anthropic 2025 年对 50 万次 coding interaction 的分析中，Claude Code 会话有 79% 被分类为 automation，而普通 Claude.ai coding interaction 为 49%；这同样是厂商自有流量的描述性证据，不是因果实验。AI’s impact on software development

0.1 证据标签

本文用三种标签约束论证：

• [事实]：公开产品、代码、研究或文档直接支持；
• [推断]：由多个事实推导出的战略判断，尚无公开内部数据证明；
• [示例]：用于解释公式的假设数字，不代表任何公司的实际指标。

证据强度还必须分层：当前官方定价/产品文档只证明“厂商此刻公开承诺什么”；原始论文或开放数据能支持其样本内结论；厂商自有流量分析与 engineering case study 只能作为描述性或机制证据；本文的战略推导仍是待证伪假设。不能用一类证据替代另一类。

0.2 北极星不是“完成任务数”

一个可用的北极星是 risk-adjusted verified outcome throughput：

RAVOT = Σ_task [Accepted(task) × BusinessWeight(task) × Confidence(task)
                × (1 - RiskPenalty(task))]
        / scarce_time

其中 scarce_time 应选择真实瓶颈：可能是用户注意力、reviewer 小时、交付周期，也可能是受限 GPU / sandbox 容量。它不能简单取模型运行时长。

为什么要四个因子：

• 只数“完成”会奖励错误自报完成；
• 只数接受率会诱导只接简单任务；
• 只数业务价值会掩盖证据强度差异；
• 不计风险会把不可逆事故当成普通失败。

1. 价值单位：Delegated Task 到底是什么

1.1 Task 不是一条长 prompt

一个可交易、可评测、可计费的 delegated task 至少是以下 contract：

DelegatedTask {
  intent:            用户真正要改变的状态
  scope:             repo / workspace / account / system 边界
  constraints:       技术、业务、安全、时间与风格约束
  starting_state:    可重放的环境、版本、依赖和权限
  allowed_effects:   允许读、写、执行、发布、发送到何处
  deliverables:      diff / PR / artifact / report / deployed state
  acceptance:        可执行 verifier + 人类 rubric + 业务结果
  budget:            money / tokens / wall-clock / attempts / concurrency
  deadline:          何时开始失去价值
  escalation:        哪些不确定性必须交还用户
  provenance:        输入、工具、变更、审批与证据链
}

如果没有 acceptance，系统只有“生成活动”而没有 outcome；如果没有 starting_state，失败不可归因；如果没有 allowed_effects，自动化价值与风险边界没有共同语言。

1.2 从 Message 到 Task 的经济变化

1.3 为什么 Token / Message 不再是价值单位

1. 同样 token，价值跨度极大。 一次关键 production bug 定位和一次样板代码生成可能消耗相近，却有完全不同的业务收益。
2. 优化 token 容易反向激励。 低成本模型多走 30 步、反复失败，可能比昂贵模型 5 步完成更贵。
3. Message 边界由 UI 决定，不由工作决定。 用户一次 prompt 可能触发数小时执行；也可能用十条 prompt 完成同一任务。
4. 真实稀缺资源常是验证。 Agent 生成越快，人类 review、integration 与 incident response 越可能成为瓶颈。
5. 风险不随 token 线性增长。 一条短命令可能删除生产数据；一百万 token 的只读分析可能没有外部 effect。

1.4 价值、支付意愿和客户剩余

任务 t 的期望净价值可写为：

EV_customer(t)
  = P(accepted_by_deadline) × Benefit_if_accepted
  + Reusable_learning_value
  - Human_attention_cost
  - Integration_cost
  - Expected_failure_loss
  - Switching_and_governance_cost
  - Price

用户愿意持续购买的必要条件不是“模型调用费低于人工工资”，而是：

EV_customer > best_available_alternative

替代方案可能是人工完成、推迟、放弃、使用另一个 Agent、购买 SaaS，或把需求从源头删除。因此“节省了多少工程师小时”只是一种 shadow value，并非所有任务的真实收益。

1.5 Outcome 的三层验收

只优化第一层会制造“可提交但不可采用”的产物；只优化测试通过会受到 verifier 缺口和 reward hacking 影响；只用人工最终判断又无法规模化。

METR 2025 年把 18 个真实开源任务用自动测试与 holistic review 对照，发现一些自动评分正确的实现仍在测试覆盖、格式、lint 或代码质量上不可直接使用。这是小样本，但很好地说明“测试通过 ≠ 经济上的可接受产物”。Algorithmic vs. Holistic Evaluation

1.6 反例：不是所有场景都该产品化为 Task

• 开放式学习、头脑风暴与品味探索，价值来自互动本身；强行定义 outcome 会过早收敛。
• 责任不能委派的医疗、法律、资本配置决策，Agent 更适合提供 evidence bundle，不适合售卖“决策已完成”。
• 验收成本高于任务价值的小请求，用 task contract 会产生流程税。
• 结果高度依赖组织政治或隐性偏好时，模型难以独立完成 business acceptance。

所以合理产品应同时支持 ask、assist、co-plan、delegate，不应把所有工作伪装成自治任务。

2. 总成本：最便宜的 Model 不一定产生最低成本

2.1 完整的 Task TCO

C_task = C_primary_execution
       + C_retry
       + C_machine_verify
       + C_human_attention
       + C_integration
       + C_latency_opportunity
       + E[C_failure]
       + C_support_governance

展开：

C_primary_execution
  = C_model[attempt_0]
  + C_tool[attempt_0]
  + C_runtime[attempt_0]
  + C_external[attempt_0]

C_model[attempt_a] = Σ_calls_in_attempt_a(
    uncached_input_tokens × price_uncached_input
  + cache_write_tokens × price_cache_write
  + cache_read_tokens × price_cache_read
  + output_tokens × price_output
  + model_specific_surcharge
)

C_runtime[attempt_a]
  = sandbox_compute + storage + image_startup
  + network_egress + queueing_overhead

C_retry
  = Σ_retry_attempt_a(
      C_model[a] + C_tool[a] + C_runtime[a] + C_external[a]
    )
  + cache_rebuild + state_recovery + retry_orchestration

C_human_attention = Σ_role(hours × fully_loaded_hourly_cost)

C_latency_opportunity = business_value_decay(wall_clock, deadline)

E[C_failure] = Σ_failure_class P(class) × Loss(class)

四类 token bucket 必须互斥。有些 provider 的 input_tokens 已包含 cached tokens；若再把 cached_input_tokens 整项相加会重复计费。先把原始 usage 归一成 uncached input、cache write、cache read、output，再应用对应 rate；若厂商直接返回最终 credits/charge，则同时保存原始 meter 与账单值用于 reconciliation。

Loss(class) 不能只计算重新运行费用，还包括错误 merge、回滚、数据损失、合规事件、信任流失和后续 review 加码。

2.2 成本所有权表

2.3 Cost per Verified Accepted Outcome

按 invocation 计算成本会奖励把 task 拆成更少或更多调用的实现细节。更稳定的单位是：

CPVAO(segment)
  = Σ_task TotalRealizedCost(task)
    / Σ_task AcceptedWithinSLA(task)

segment 至少按以下维度分层：

• task family 与难度；
• repo / organization maturity；
• effect risk；
• model / harness / route；
• verifier strength；
• new vs retained user；
• interactive vs background；
• deadline class。

全局平均 CPVAO 会被任务组合变化严重污染。例如产品吸引了更难任务，成功率下降、成本上升，不一定代表系统退化。

2.4 毛利不是 Token 毛利

ContributionMargin_task
  = AllocatedRevenue_task
  - C_model
  - C_tool/runtime/external
  - failure credits/refunds
  - variable support
  - risk reserve

GrossMargin_segment
  = Σ ContributionMargin_task / Σ AllocatedRevenue_task

若采用 seat subscription，AllocatedRevenue_task 只是管理会计分摊，不是用户逐任务支付。必须同时观察：

• seat utilization 与 spend concentration；
• heavy-user adverse selection；
• unused entitlement 对表面毛利的贡献；
• 额度触顶造成的 churn 与任务中断；
• included usage 和 overage 的交叉补贴。

2.5 Retry 的非线性

若每次尝试成功概率都是 p 且独立，最多 n 次时：

P_success_by_n = 1 - (1 - p)^n

但 Agent 失败通常相关：相同模型、相同上下文、相同错误假设、相同 verifier 会让后续尝试重复同类错误。真实提升低于独立假设。重试只有在至少改变一项信息时才有经济意义：

• 新证据；
• 新模型或 effort；
• 新计划/工具；
• 清理污染状态；
• 更强 verifier 的具体反馈；
• 人类纠正。

“同 prompt 再来一次”若没有失败分类和预算，只是把不确定性转成账单。

2.6 敏感性分析一：Review 时间通常比 Token 更敏感

[示例] 假设单次机器成本固定为 33 元，reviewer fully-loaded cost 为 300 元/小时，暂不计事故和延迟。每个 attempt 的直接成本：

C_attempt = 33 + 300 × review_hours
CPVAO_approx = C_attempt / P_accept

这个简化表不是财务预测，只说明两个产品判断：

1. 将 review 从 48 分钟降到 18 分钟，可能比把模型费砍半更有价值；
2. 提高可验收率同时会减少失败尝试和 review 浪费，具有乘数效应。

2.7 敏感性分析二：尾部风险可以压倒平均推理成本

[示例] 单次高影响事故损失为 10,000 元：

如果高能力 route 每任务贵 20 元但把事故概率从 1% 降到 0.1%，其期望经济价值是 90 元，净收益 70 元。这个推理只在损失和概率估计可信时成立；对极端不可接受事件，应使用硬约束而非期望值抵消。

2.8 能力升级阈值

高能力 route 相对便宜 route 的升级条件可近似写为：

Upgrade when:
ΔP_accept × Benefit
+ ΔHumanAttentionSaved
+ ΔExpectedLossAvoided
+ ΔDeadlineValue
> ΔMachineCost + ΔOperationalComplexity

[示例] 若 accepted outcome 的收益为 1,000 元，升级多花 20 元，其他项暂为零，只要验收概率提高超过 2 个百分点就值得升级。反过来，低价值、强 verifier、可无限重试的任务才更适合 cheap-first。

2.9 一个必要的反证

METR 在 2025 年对熟悉自己开源项目的开发者做随机对照实验，观察到允许使用当时 AI 工具的任务完成时间反而增加 19%；开发者主观上却认为自己更快。METR 2026 年更新又明确说明，后续实验受参与者选择偏差和并行 Agent 计时问题影响，无法可靠给出当前 uplift。正确结论不是“AI 没价值”，而是：benchmarks、主观节省时间和真实 task-level productivity 是不同测量对象，ROI 必须在目标任务分布上实测。 2025 RCT 原始论文；2026 methodology update

3. Latency–Quality–Cost Frontier

3.1 不是三选一，而是求 Pareto 前沿

把每一种 model × effort × harness × tool × verifier × parallelism 配置看成一点：

x = (ExpectedCost, P_accepted, P99_TimeToVerifiedOutcome, Risk)

如果配置 A 在成本、质量、延迟和风险上都不优于 B，A 被支配，应删除。产品应向用户暴露少数真正处于 Pareto 前沿的模式，而不是暴露所有底层旋钮。

3.2 Product Frontier 不等于 Economic Frontier

面试里必须把两条前沿分开：

• Product frontier：产品现在允许用户做什么，例如任务时长、并行分支、supervision/review surface、provider/model 可替换性、扩展面、状态恢复和权限控制；
• Economic frontier：在目标任务分布上，哪些配置真正实现更低 CPVAO、更短 TTV、更少 human attention 和更低风险，而且不被另一配置全面支配。

公开产品能力最多证明“可行域扩大”，不能自动证明“商业价值提高”：

来源：OpenAI — Introducing the Codex app、OpenAI — Work with Codex from anywhere、Claude Code — platforms、Claude Code — parallel agents、Claude Code — agent teams、Pi repository、Pi coding-agent README

这也给出一个关键判断：代码公开度、功能数量和商业价值是三条不同的轴。 MIT/public source 说明的是审阅、修改和分发权；它不证明线上部署与仓库同源，也不证明完成率、可靠性、安全治理、留存或毛利。反过来，Pi 的低复杂度也是一种刻意的 product-frontier 选择，而非“功能少所以落后”；是否进入 economic frontier，仍要在相同 task contract、budget、verifier 和风险边界下实测。

3.3 延迟必须拆分

T_verified = T_queue
           + T_prefill/cache
           + T_reasoning/decode
           + T_tool_wait
           + T_sandbox
           + T_retry
           + T_machine_verify
           + T_human_wait
           + T_integration

还应分别看：

• TTFE：time to first evidence，首次展示真实搜索/诊断证据；
• TTFA：time to first actionable artifact，首个可检查 diff/plan；
• TTV：time to verified outcome；
• deadline miss rate；
• P50/P95/P99，而非只看平均。

Kimi 官方模型文档给出了一个很好的 Amdahl’s Law 例子：高速版只加快模型输出；若工具或脚本占主要耗时，整体提速不明显。官方同时说明 K2.7 高速版约 6 倍输出速度、3 倍额度消耗。这说明“decode speed tier”不是“task speed tier”。Kimi Code 模型配置

3.4 用户价值随时间衰减

不同任务的时间价值函数不同：

Incident response:  value(t) steeply decays after minutes
Interactive edit:   value(t) decays after attention is interrupted
Background refactor:value(t) mostly flat before morning deadline
Compliance review:  value depends more on completeness than immediacy

因此统一优化“平均响应速度”会错误地把资源投向低价值即时请求。应为每个 task contract 建立 deadline class 和 late penalty。

3.5 并行的经济学

若运行 k 条异质 trajectory：

Cost_parallel ≈ Σ_i Cost_i + SelectionCost
Latency_parallel ≈ max_or_first_qualified(Time_i) + VerificationTime

独立假设下成功概率是 1 - Π_i(1-p_i)；但同模型、同证据和同 grader 会相关失败。并行最适合：

• deadline 价值高；
• 解空间有多个独立路径；
• selection verifier 强；
• trajectories 可以隔离环境；
• 失败相关性可通过不同模型、工具或方案降低。

不适合：

• merge/integration 成本高；
• reviewer 无法比较多个大 patch；
• 任务由单一事实缺失导致；
• 多 Agent 会竞争同一外部 rate limit；
• 选择器与生成器共享同一盲点。

3.6 四种用户模式的合理产品语义

模式应该映射稳定的服务语义，不应只是模糊的“low/high/max 智力”。

4. Routing：把能力分配给最值得的任务

4.1 路由目标函数

对 task features x 和候选 route r：

r* = argmax_r E[
       P_accept(r|x) × Benefit(x)
       - Cost(r|x)
       - HumanAttention(r|x)
       - DeadlinePenalty(r|x)
       - ExpectedRiskLoss(r|x)
     ]

subject to:
  data_region, provider_policy, tool_capability,
  max_effect, budget, deadline, availability

风险、数据边界、模型能力和用户预算首先是约束，不应全部折算成一个可以被收益抵消的分数。

4.2 路由特征

4.3 路由是多阶段决策，不是入口分类器

admit
  -> cheap diagnosis / evidence acquisition
  -> update task posterior
  -> select model + effort + tools
  -> inspect progress and verifier signals
  -> continue / escalate / hedge / ask / stop
  -> select assurance route

入口时缺少 repo 证据，静态路由必然误判。高质量 router 要把 Agent 执行当作 sequential decision problem：每一步用新证据更新后验。

4.4 Cheap-first Cascade 的必要条件

设便宜 route 正确率 p，verifier 在正确结果上通过率 α，在错误结果上误通过率 β：

P(pass) = pα + (1-p)β

Precision_of_pass
  = pα / [pα + (1-p)β]

P(escalate) = 1 - P(pass)

ExpectedMachineCost
  = C_cheap + P(escalate) × C_strong

cheap-first 只有在以下条件成立时才好：

• β 足够低，错误不会被廉价 verifier 放过；
• escalation 不丢失 cache / state 或重做成本可控；
• cheap route 不会污染 workspace；
• 任务不是高风险、不可逆；
• C_cheap + escalation overhead 显著低于直接 strong route。

否则，便宜起步会同时增加延迟、cache miss、错误锚定和人类 review。

4.5 一个可落地的路由决策表

4.6 Cache-aware 但不能 Cache-led

模型或 reasoning effort 切换可能使 prefix cache 失效。Kimi 官方明确提示切模型、切 effort 会导致已有 cache 失效并重新 prefill；K3 1M 与 256K 也有不同消耗语义。模型配置

Router 因此应计算：

NetUpgradeValue
  = capability_gain
  - cache_rebuild_cost
  - state_translation_risk
  - additional_latency

但不能为了保 cache 把明显不胜任的模型留在任务上。Cache affinity 是成本特征，不是 correctness constraint。

4.7 路由的可观测指标

• route decision 与 feature snapshot；
• predicted vs realized cost / acceptance / latency；
• escalation rate 与升级原因；
• cache miss caused by routing；
• cheap-route false pass；
• provider fallback 后的语义错误；
• route regret：事后最优 route 与实际 route 的价值差；
• task mix adjusted CPVAO；
• 用户手动改 model/effort 的 override rate；
• budget exhaustion before verification。

4.8 路由反例

• “简单任务都用小模型”：大 repo 中一行修改可能需要最难的定位。
• “长 context 都用 1M”：大窗口解决容量，不解决相关性；还可能提高 prefill 成本。
• “失败就升级模型”：首次错误可能在 tool、environment 或 verifier，换模型无效。
• “高价值用户永远走最贵模型”：高价值用户也需要 predictable spend 和低延迟。
• “fallback 到兼容 API 就等价”：thinking preservation、tool-call semantics、media 和 context limit 可能不兼容。

5. Capacity Planning：Agent 服务不是普通 Chat QPS

5.1 任务经过的是排队网络

admission
  -> model calls <-> tool/sandbox
  -> external services
  -> machine verification
  -> human review
  -> integration/deploy

一个 task 会反复访问同一阶段；多 Agent 又形成 fork–join。只用入口 QPS 做容量规划会看不见真正瓶颈。

5.2 每阶段的需求量

对阶段 j：

Demand_j_per_task
  = E[visits_j_per_task] × E[service_time_j_per_visit]

MaxTaskThroughput_j
  ≈ EffectiveCapacity_j / Demand_j_per_task

SystemSustainableThroughput
  ≤ min_j(MaxTaskThroughput_j)

EffectiveCapacity 要扣除维护、失败、突发、provider rate limit 和安全余量。生产系统不应在理论 100% utilization 上运行，因为排队尾延迟会急剧放大。

5.3 Little’s Law 管理 WIP

稳定系统中：

WIP = Throughput × CycleTime

[示例] 若每天进入 60 个任务，平均从创建到验收是 2 天，系统中平均会有 120 个在途任务。若 UI 只能让用户理解 10 个任务的状态，那么 runtime 吞吐提升已经超出产品的 task-portfolio 管理能力。

5.4 验证瓶颈示例

[示例] 每小时进入 120 个任务：

即使模型与 sandbox 可承载，review 仍把系统锁在 80 tasks/h。若风险路由后只有 30% 任务需要人工 review，则该阶段理论上可承载约 267 tasks/h；但前提是自动 verifier 能可靠挡住错误，而不是把风险转移到生产。

5.5 Agent 特有的容量维度

5.6 Fork–Join 的尾延迟

一个 task 分成 k 个 subtask 后，完成时间取决于最慢分支再加 merge：

T_task ≈ max(T_1 ... T_k) + T_merge + T_joint_verify

所以并发能缩短均值，却可能因为长尾分支、资源竞争和 merge 冲突恶化 P99。必须记录 critical path，不要只记录所有 agent time 的总和。

5.7 Admission 与 Overload Policy

过载时应按 contract 明确降级：

1. 保证已产生外部 effect 的任务完成 checkpoint / rollback；
2. 保证 deadline 高且已付 SLA 的任务；
3. 暂停 speculative/parallel 分支；
4. 降低非关键 verifier 频率，但不绕过必要安全 gate；
5. 对尚未开始的低价值任务排队或拒绝；
6. 清楚告知预计开始和完成时间。

不应静默做的事：降低模型导致语义变化、跳过测试、截断 context、无限重试、让任务“看似运行”但无进展。

5.8 Capacity 指标

• arrival / admitted / started / completed / accepted rate；
• per-stage demand 与 utilization；
• queue age、P95/P99 wait、deadline miss；
• active vs idle sandbox；
• tool/API quota headroom；
• verification queue depth；
• human review minutes / accepted task；
• task critical-path breakdown；
• retry amplification factor；
• cancellation wasted cost；
• work-in-progress by state；
• overload degradation branch。

6. Verification Capacity：真正的新稀缺资源

6.1 Generation Capacity 与 Verification Capacity

Generation capacity = 单位时间可产生多少候选 artifact
Verification capacity = 单位时间可对多少 artifact 给出足够可信的接受/拒绝证据
Integration capacity = 单位时间可安全进入真实系统的 accepted artifact

系统净吞吐受三者最小值约束。增加 Agent 并行数只扩大第一项，甚至会因更多候选和冲突压低后两项。

Google DORA 2025 年近 5,000 名技术人员调查发现，AI adoption 与 delivery throughput、product performance 呈正相关，但仍与 delivery stability 呈负相关；其解释是 AI 会放大已有团队与平台能力，强测试、版本控制和快速反馈是控制加速后不稳定性的关键。该研究是观察性调查，不能证明因果，但它支持“下游控制系统决定经济收益”。2025 DORA Report

6.2 Assurance Ladder

等级不是越高越好。目标是最小充分证据：assurance cost 应随不确定性、影响和不可逆性增长。

6.3 Verifier 的混淆矩阵

产品不能只报告 pass rate。至少需要：

• false-accept rate：最危险，会把错误送进系统；
• false-reject rate：产生无谓重试和成本；
• coverage：哪些要求根本没被 verifier 覆盖；
• independence：verifier 与 generator 是否共享数据、模型、prompt 和盲点；
• calibration：置信度与真实正确率是否一致；
• cost / latency per decisive finding。

6.4 Risk-based Review Routing

ReviewIntensity = f(
  blast_radius,
  reversibility,
  data_sensitivity,
  novelty,
  change_size,
  test_strength,
  provenance_quality,
  route_history,
  deadline
)

6.5 降低 Review 成本的正确方法

• 把大任务拆成独立、可验收的 change contract；
• 产出 evidence-first summary：意图、关键 diff、测试、未验证项、风险；
• 将 generated explanation 与可重放 evidence 分开；
• 为 reviewer 展示 first-error boundary，而不是完整冗长 transcript；
• 自动聚类已知 failure pattern；
• 对低风险重复模式抽检，对新模式提高 sampling；
• 让变更保持小而完整，不用大量无关格式化淹没语义；
• 保存 verifier version 与 execution receipt，支持复核。

6.6 不要用另一个 Agent 假装解决验证瓶颈

独立 reviewer agent 能增加带宽，但不自动增加独立性。至少应改变一部分条件：

• 不同模型族或训练来源；
• 不同证据路径；
• verifier 不读取 generator 的自我解释；
• deterministic oracle 优先；
• 对高风险结果保留人类与 staged rollout。

Anthropic 2026 年长任务 harness 实验也发现生成器自评容易过度正面；把 evaluator 分离后更容易调成怀疑式，但 evaluator 的价值只在任务超出 generator 稳定能力边界时值得其成本。这是一组工程实验，不是通用定理。Harness design for long-running application development

6.7 Verification Capacity 指标

• verified artifacts / reviewer-hour；
• review active time 与 queue time；
• defect escape / revert / incident rate；
• auto-pass 后人工抽检错误率；
• evidence completeness；
• false accept / false reject；
• verifier disagreement；
• review size、changed semantic units；
• unverified WIP age；
• post-acceptance regression；
• risk tier migration；
• reviewer override reason。

6.8 Benchmark 是系统测量，不是商业结果

2026 年几组原始研究进一步说明，coding-agent 分数不能脱离 harness、预算与 verifier 解释：

Kimi K3 自己的公开表也给出一个很好的面试反例：Kimi Code Bench 2.0 主表报告 K3 在 Kimi Code harness 下为 72.9，脚注同时披露在 Claude Code harness 下为 73.7；不同模型行还使用 Kimi Code、Claude Code 或 Codex，并披露部分 fallback/refusal。透明脚注值得肯定，但这仍是厂商自报、in-house benchmark，不能把主表分数解释为脱离 harness 的模型固有能力，也不能视为独立横评。Kimi K3 evaluation notes

因此 leaderboard 进入经营决策前至少要补齐：model × harness/version × task set × budget × tool/runtime × verifier version × cost × variance。对 pricing/ROI 更关键的是把同一配置放进客户真实任务分布，记录 accepted outcome、review、regression、incident 与 CPVAO；benchmark 只能充当能力证据的一层。

7. Pricing 与 Packaging：价值单位、计费单位不要硬绑

7.1 截至 2026-08-03，市场没有收敛到单一计费方式

公开产品正在同时实验多种抽象：

来源：GitHub current billing、GitHub 2026-06 migration、OpenAI Codex rate card、Kimi Code 会员权益、Claude Enterprise billing

这组事实支持一个反直觉判断：价值单位向 task 迁移，与资源计费回到 token 可以同时发生。 前者决定产品和 ROI，后者解决边际成本与预算归因。

7.1.1 可核验的当前价格快照

下表只记录官方页面在 2026-08-03 明确展示的数字；credit 不能跨厂商换算，厂商 credit 也不能在没有兑换规则时直接当美元：

价格来源：OpenAI API model pricing、OpenAI GPT-5.6 pricing semantics、Kimi 开放平台、Claude pricing。

两个容易在面试中讲错的历史状态：

• GitHub 2025-07 的“一次 coding-agent session = 一个 premium request，Actions minutes 另计”是有价值的 packaging 实验，但已被 2026-06-01 全计划 AI-credit usage billing 取代，不能当当前计费规则。历史变更
• OpenAI 2026-04-02 曾向 Business 与 Enterprise 推出 Codex-only pay-as-you-go seat；官方页面于 2026-06-24 更新为“不再向新的 Business plan 提供”，既有 Business pay-as-you-go seat 不受影响。它仍可作为 adoption 实验研究，但不能笼统表述为当前所有 team 都可新购。官方更新

7.2 七种计费模式的真实 tradeoff

7.3 Outcome Pricing 何时成立

必要条件：

• outcome 可客观定义，双方同意 verifier；
• starting state 和 counterfactual baseline 可记录；
• 交付周期短，结果不会半年后才显现；
• Agent 对结果具有足够控制，不由大量外部因素共同决定；
• 失败损失和责任上限可合同化；
• outcome 难以通过降低长期质量来投机；
• dispute resolution 成本低于价值增量。

适合例子：

• “把明确 dependency 升级到指定版本并通过约定测试”；
• “对这批结构化工单完成字段归类并达到抽检准确率”；
• “生成满足 schema、可重放且通过 validator 的迁移 artifact”。

不适合例子：

• “让代码库更好”；
• “提高团队生产率 30%”；
• “避免所有未来 incident”；
• “写出用户喜欢的创新产品”。

7.4 Outcome Pricing 的机制风险

1. Verifier gaming：只满足可测指标，牺牲不可测质量。
2. Adverse selection：客户只把最难、最混乱任务放到 outcome 套餐。
3. Moral hazard：客户不给上下文或频繁改需求，却把失败归给 Agent。
4. Joint causality：人、Agent、CI、外部依赖共同产生结果，责任不可分。
5. Delayed failure：当前通过，数周后维护/安全问题才出现。
6. Cherry-picking：厂商拒绝低成功率任务，表面 outcome rate 很高。
7. Liability concentration：一次高 blast-radius 事故吞掉大量毛利。

所以更现实的企业结构通常是：

Price = access/control-plane fee
      + metered variable usage
      + assurance/SLA premium
      + optional success-linked component

它把可预测访问、实际资源、保证等级和部分价值分享分离。

7.5 Packaging 是能力边界，不只是价格梯度

如果 enterprise 版本只是“额度更多”，它没有解决企业真正付费的 trust、governance、chargeback 和 operational continuity。

7.6 配额设计

配额同时承担三件事：保护服务、管理毛利、塑造行为。应明确区分：

• short-window rate limit：保护瞬时容量；
• concurrency limit：控制 fork/parallel amplification；
• monthly/weekly entitlement：套餐分层；
• hard spend cap：阻止账单失控；
• per-task budget：防止单任务 runaway；
• effect quota：限制高风险动作，不应按钱解锁；
• fair-use policy：处理自动化、转售和账号共享。

一个配额错误同时伤害可靠性和信任。例如“余额保证最后一次模型调用完成，但不保证整个 task 完成”是资源计费与任务语义之间的典型裂缝。产品应在开始任务前估算剩余 budget sufficiency，并在可恢复 checkpoint 停止，而不是消耗到中途突然失败。

GitHub 2026-07 的公开预览给出一个具体实现：Copilot CLI/SDK 可设置单 session 的 AI-credit 上限，覆盖 model calls、subagents 和 compaction；达到时先 wrap up，交互会话可加额后续跑，noninteractive run 则结束。但它明确是 soft cap——正在生成的 response 会完成，因此实际值可能略超预算。这说明“可恢复的 task budget”有产品价值，也说明任何事后计量的 cap 都不能被宣传成绝对 hard guarantee。GitHub session limits

7.7 价格弹性和敏感性

不要只做“每 token 贵了多少”的敏感性。至少模拟：

Margin sensitivity:
  model price ±x%
  cache hit rate ±x pp
  retries/task ±x
  task mix shift
  heavy-user concentration
  verification minutes/task
  support tickets/1k tasks
  incident loss tail

Demand sensitivity:
  seat price
  included verified-task capacity
  quota predictability
  time-to-first-trusted-outcome
  acceptance rate
  integration depth

7.8 定价不可被成本指标绑架

Anthropic 2025 Economic Index 对 2025-08 的 100 万条 first-party API transcript 样本分析发现，高成本 task category 反而使用更多；官方推测企业更看重能力与经济价值，而非单任务成本。样本来自约占其 first-party API usage 一半的一组客户，结论是 category-level correlation，不证明涨价不会抑制需求，也不是同一任务的价格实验；它只能反驳“企业永远优先选最便宜模型”的朴素假设。Economic Index: geography and enterprise adoption

7.9 定价指标

• revenue / active seat 与 revenue / accepted task；
• entitlement utilization distribution；
• overage attach rate、budget cap hit rate；
• compute gross margin 与 CPVAO；
• task abandonment caused by quota；
• spend surprise tickets/refunds；
• upgrade reason：capacity、model、context、speed 还是 governance；
• accepted outcome elasticity by price/plan；
• heavy-user contribution margin；
• unused seat、inactive seat、seat expansion/contraction；
• plan migration后 task mix 是否变化。

8. Wedge、Retention 与 Flywheel

8.1 Wedge 不是“功能最多”

Wedge 是一个狭窄但高频、痛点强、能快速证明信任的入口：

Wedge quality
  = PainIntensity
  × Frequency
  × TimeToFirstTrustedOutcome^-1
  × DistributionAdvantage
  × ExpansionPotential

Coding Agent 常见 wedge：

• terminal/IDE 原生、安装即用；
• 某类模型的明显 price/performance；
• 大 repo / 长 context / multimodal evidence；
• issue → PR 的 background workflow；
• enterprise policy / security / private runtime；
• 特定生态的 MCP、CI、Git hosting 或 data connector；
• 中国开发者可访问性、支付、速度与本地生态兼容。

Wedge 的验证不是下载量，而是首个成功任务后的重复委派：

• activation：在规定时间内产生首个 accepted artifact；
• second-task rate：第一次成功后是否自然产生第二次委派；
• time-to-trust：用户何时从逐步监控转为 exception-based supervision；
• adjacent expansion：从解释代码到修改、测试、review、background task。

8.2 Retention 的对象是 Workflow，不是聊天习惯

Retention = f(
  recurring_task_fit,
  verified_reliability,
  integration_depth,
  accumulated_context/policy,
  team coordination value,
  switching cost,
  price predictability,
  trust
)

必须区分健康 retention 和劣质 lock-in：

8.3 Retention Cohort 应按任务成熟度看

不要只看 D7/D30 active user。更有解释力的是：

• 首个 accepted task 后 7/30/90 天再次委派率；
• 同一 recurring workflow 的 cohort retention；
• 每周 accepted task / retained team；
• repo/team 扩展率；
• accepted task family breadth；
• automation maturity：ask → edit → delegate → background；
• trust regression 后的 churn；
• quota/incident/support cohort 的留存差异。

8.4 Agent 产品的网络效应并不天然强

把“有很多用户”直接称为网络效应是不严谨的；没有 feedback mechanism，只有规模。

8.5 Data Flywheel 的最小闭环

real delegated task
  -> structured trace + effect receipt
  -> deterministic and human verification
  -> failure attribution / cohort
  -> eval case + regression
  -> model / harness / router / tool change
  -> controlled experiment
  -> safer rollout
  -> better accepted outcomes
  -> more trusted delegation

三个关键门槛：

1. Label quality：用户不投诉不等于正确；accept click 也可能是 rubber stamp。
2. Attribution：要知道首次错误在 model、context、tool、runtime、verifier 还是 UX。
3. Rights and privacy：代码、secret、商业逻辑和个人数据不能因为“flywheel”被默认再训练。

8.6 Flywheel 可能反向旋转

• 只学习高活跃用户，router 对新用户失真；
• 从 agent 自评生成标签，把幻觉固化进训练数据；
• 优化 accept rate，使 Agent 迎合而不纠错；
• 把 benchmark task 过度代表真实任务；
• 生产失败没有进入数据闭环；
• 用户因隐私选择退出，剩余数据分布偏斜；
• 低价吸引高成本任务，毛利恶化导致限额收紧，再导致留存下降。

8.7 Retention 与 Flywheel 指标

• first accepted outcome time；
• first → second delegated task conversion；
• accepted outcomes / WAU、per repo、per team；
• recurring workflow retention；
• task-family expansion；
• verified label coverage；
• trace → eval conversion latency；
• regression escape rate；
• consented data coverage；
• model/harness improvement by cohort；
• trust downgrade / autonomy rollback frequency。

9. 护城河：九层，而不是“有一个好模型”

9.1 分层判断

9.2 各层的独立判断

Model moat

• 对垂直整合公司，模型与 harness 可以联合优化速度、context、tool protocol 和成本；
• 但 public benchmark leadership 的半衰期短；
• API 兼容会降低模型接入摩擦，也降低单模型锁定；
• 真正价值是 model–harness co-design iteration speed，不是参数量本身。

Harness moat

• 来自失败轨迹中积累的控制策略、tool semantics、recovery、compaction、routing；
• 随模型变强，旧 scaffold 可能从增益变成开销；
• 需要持续 ablation 删除不再 load-bearing 的复杂度。

Anthropic 2026 年公开实验明确展示：模型从 4.5 到 4.6 后，一些 context reset/sprint/evaluator scaffolding 的边际价值改变，团队通过逐项删除验证哪些组件仍必要。这正说明 harness moat 是活系统，而不是 prompt 秘方。Harness design

Context / Tool / Runtime moat

• 这些层与真实 repo、权限、CI、数据源、sandbox 和恢复深度相连；
• 看起来“工程化”，却决定大多数 deployment gap；
• 一旦企业把 policy、workflow、artifact 和 incident process 建在此处，retention 强于单模型偏好。

Eval / Data moat

• 原始 transcript 不是 moat；大量未验证数据只是噪声和责任；
• 能把一次失败转成稳定 cohort、可重放 eval 和归因实验，才形成复利；
• 数据必须覆盖真实难任务，而不只覆盖容易自动评分的 task。

Distribution / Trust moat

• 在开发者工具里，terminal、IDE、Git host、cloud account 是天然入口；
• 信任把“可试用”变成“可委派”；
• 开放源码可增加 inspectability 和生态，却不自动带来企业 trust，仍需 operational evidence。

9.3 护城河强度公式

一个战略能力 m 可用以下启发式审视：

MoatStrength(m)
  = CustomerValue
  × Uniqueness
  × LearningRate
  × Embeddedness
  × Trust
  / (ReplicationEase × ObsolescenceRate × MaintenanceBurden)

不是为了产出精确分数，而是迫使团队问：模型升级会不会把我们三年的复杂 harness 变成负资产？协议开放会降低锁定，但是否扩大分发和数据闭环？

9.4 伪护城河

• 很长的 feature list；
• 暂时便宜但没有成本曲线优势；
• 私有 prompt；
• 不能导出的用户历史；
• 未经独立复现的 leaderboard 第一；
• 大量插件但质量、权限和维护未知；
• 高 token 使用量；
• 低 churn，但来自年付锁定而非 recurring value；
• “我们有很多 trace”，但没有 verifier 和 consent。

10. Build vs Buy 与协议开放性

10.1 不要问“Agent 是否自研”，要逐层问

10.2 Build Score

BuildScore
  = Differentiation
  + StrategicData
  + TrustControl
  + ReliabilityOwnership
  + UnitCostAdvantageAtScale
  - EngineeringOpportunityCost
  - Maintenance/ComplianceBurden
  - CommodityMaturity
  - ObsolescenceRisk

任何“自研更可控”的提案都必须回答：谁长期 on-call、如何跟协议/模型演进、失败时有什么可观测证据、它替代了哪个真正差异化工作。

10.3 协议开放不是放弃护城河

开放 MCP/ACP/A2A/兼容 API 会增加 provider/tool 可替换性，但可能带来：

• 更低 integration CAC；
• 更大的工具/客户端生态；
• 用户对数据与 vendor lock-in 更放心；
• 更快成为默认 runtime / control plane；
• 更多真实任务和兼容性反馈。

应开放的是连接和可移植 contract，不应放弃的核心是：

• task state / durable execution；
• policy 与 delegated authority；
• context selection / memory integrity；
• trace / evaluation / routing；
• verified workflow 与组织协作；
• trust、SLO 和 incident ownership。

10.4 开放协议带来的新成本

• 最低公分母会抹掉 model-specific thinking/tool 能力；
• 版本迁移、capability discovery 和 schema drift；
• identity/authority 跨系统组合风险；
• external tool 的 supply-chain 和 billing 风险；
• 支持矩阵爆炸；
• 相同 API 名义兼容、实际错误语义不兼容。

因此内部应采用：

stable semantic core
  + capability-aware provider/tool adapters
  + explicit version/capability negotiation
  + per-boundary telemetry and policy

不能把所有 provider 强压成最弱的 message/tool schema。

10.5 一个开放性决策表

10.6 Buy 的退出计划

采购任何 provider、sandbox、tool 或 eval 平台前要定义：

• 数据可导出性与 retention；
• task state / artifact 的可迁移性；
• provider failure 与价格变化时的 fallback；
• capability mismatch 测试；
• contract termination 与删除证明；
• cost attribution 到 task 的字段；
• 供应商 SLO 与 incident evidence；
• 是否允许用客户数据训练；
• 替换成本和触发阈值。

Build vs buy 不是一次决策，而是带退出条件的 option management。

11. 产品优先级：从 Failure Cohort 到 Strategic Leverage

11.1 优先级对象不是 Feature Idea

每个候选项都应被写成：

Observed cohort:
  哪类用户、哪类任务、在哪个阶段发生什么失败

First-error boundary:
  model / context / tool / runtime / verifier / UX / packaging

User consequence:
  无法验收、review 增加、deadline miss、事故、churn、成本

Mechanism:
  为什么这个变化会改变该失败，而不是换一种 UI 描述

Measurement:
  primary metric + guardrail + attribution experiment

Complexity:
  新状态、新 contract、新支持面、长期维护和删除条件

没有 cohort 和 mechanism 的 feature request，只能进入 discovery，不能直接进入 roadmap。

11.2 Priority Score

AddressableValueLoss
  = Frequency × LossPerOccurrence × AddressableShare

Priority
  = AddressableValueLoss
  × ExpectedLift
  × Confidence
  × StrategicLeverage
  × LearningValue
  / (BuildCost + OngoingComplexity + RiskIntroduced + OpportunityCost)

其中：

• StrategicLeverage：是否同时改善多个 task family / 产品面；
• LearningValue：是否让未来失败更可观测、更可归因；
• OngoingComplexity：配置、状态、迁移、支持、文档、兼容矩阵；
• RiskIntroduced：新权限、外部 effect、账单或信任边界。

分数只用于暴露假设，不能替代判断。高不确定但可能重画架构边界的问题，可以先做最小证据实验，而不是因为 confidence 低永远排在后面。

11.3 Agent 产品的 Metric Tree

North star: risk-adjusted verified outcome throughput
  |
  +-- Demand quality
  |     task creation, repeat delegation, task value mix
  |
  +-- Acceptance
  |     accepted-within-SLA, first-pass accept, post-accept regressions
  |
  +-- Efficiency
  |     CPVAO, human minutes, calls/tools/retries, cache hit
  |
  +-- Speed
  |     TTFE, TTFA, TTV, queue, deadline miss
  |
  +-- Trust
  |     effect incidents, permission overrides, audit completeness
  |
  +-- Business
        retention, expansion, contribution margin, support burden

任何局部指标都必须能说明它如何传导到上层。例如“输出速度提高 6 倍”只有在 decode 位于 critical path 时才传导到 TTV；“context 1M”只有在减少检索失败/compaction loss 且不显著增加成本时才传导到 CPVAO。

11.4 先修哪类问题

推荐的默认次序不是绝对 roadmap，而是风险与复利原则：

1. 事实源错误：任务状态、effect、完成与 UI 不一致；
2. 不可恢复与不可审计：失败后丢状态、无法 replay、无稳定 ID；
3. 高频失败 cohort：tool/context/runtime 首次错误；
4. verification gap：自报完成、错误通过、review 爆炸；
5. 成本与容量失控：retry、cache miss、queue、quota 中断；
6. 核心 workflow friction：activation、handoff、approval、review；
7. 增长和新能力：更多插件、模型、入口、Agent 编排。

第 7 类建立在前六类之上，否则新增能力会放大失控面。

11.5 决策表：常见候选项

11.6 复杂度税

每个新增设置、模型、模式、工具和 agent role 都增加：

ComplexityTax
  = state combinations
  × failure interactions
  × docs/support burden
  × migration lifetime

产品应给每个 scaffold/feature 定义删除条件：

• 模型代际提升后还是否 load-bearing；
• cohort 是否仍存在；
• 用户是否真的采用；
• 是否被更深、更简单的模块替代；
• 是否造成比解决问题更多的支持和失败。

11.7 Experiment 设计

Agent 实验至少固定：

• task distribution 与 repo commit；
• starting environment；
• model version、effort、harness；
• token/turn/time/cost budget；
• verifier version；
• sample size、重复次数、置信区间；
• 人工 review rubric；
• first-error taxonomy；
• task-mix adjusted outcome。

不能用“新版本总 token 少了”推断更好，也不能用“更多用户开启”推断 productivity。对 workflow/长期留存，还需 cohort 或 stepped rollout，不应只看短 A/B。

11.8 Stop / Kill Criteria

上线前写清：

• accepted outcome uplift 低于多少停止；
• false accept / incident 超过多少回滚；
• CPVAO 恶化多少不接受；
• 哪些用户/任务不应 rollout；
• 何时认为问题在错误层、转向别的机制；
• 新复杂度何时删除。

如果实验只有 success criterion 没有 stop criterion，团队会不断追加 prompt、retry 和 special case 保护 sunk cost。

12. 经济与产品可观测性：建立 Outcome Ledger

12.1 一条 Stable Task ID 贯穿全链路

task_id
  -> user/org/plan (privacy-scoped)
  -> task contract/version
  -> route decisions
  -> model/tool/runtime spans
  -> effects and approvals
  -> verifier receipts
  -> acceptance / rejection / override
  -> realized cost allocation
  -> post-accept outcome / incident

没有稳定 task_id，finance 只能看 token，product 只能看 click，runtime 只能看 span，support 只能看报错；它们无法回答同一个任务是否产生价值。

12.2 Outcome Ledger 最小 schema

OutcomeRecord {
  task_id
  task_family
  contract_version
  risk_tier
  route_id / model / effort / harness_version
  created_at / started_at / first_evidence_at / artifact_at / accepted_at
  terminal_state
  acceptance_source
  verifier_versions[]
  evidence_receipts[]
  effects[]
  model_usage {input, cached_input, output, calls}
  tool_usage[]
  runtime_usage
  retries[]
  human_attention_estimate
  allocated_revenue
  realized_variable_cost
  incident_or_regression
  privacy_scope / retention_policy
}

严禁把 secret、完整私人代码或不必要 transcript 复制到经济分析表。Outcome Ledger 应保存指针、hash、类型和去内容化统计，敏感 artifact 留在其原边界。

12.3 Terminal State 必须诚实

建议最少区分：

accepted
completed_unverified
rejected
failed_recoverable
failed_terminal
cancelled_before_effect
cancelled_after_effect
blocked_user_input
blocked_external
budget_exhausted
deadline_missed

把 completed_unverified 算成 success 会系统性高估价值；把用户取消都算失败又会掩盖需求改变和错误创建。

12.4 成本归因

共享资源需用可解释规则分摊：

• provider invoice → request/span → task；
• warm sandbox idle 可按占用或容量池分摊，不能全塞给最后一个任务；
• shared CI/cache 需区分 marginal cost 和 fully-loaded cost；
• support / incident 可按 failure cohort 分摊；
• R&D 固定成本不要混进短期 route decision 的边际成本，但应进入长期单位经济学。

同时保留两套视图：

MarginalCost:  用于 routing、overage、短期容量
FullyLoadedCost: 用于产品线盈利、build-vs-buy、长期定价

12.5 Human Attention 的测量

session wall time 不是人工成本。更接近真实的事件：

• active spec/edit time；
• approval decision time；
• monitoring foreground time；
• post hoc review time；
• exception handling；
• context switch count；
• task reopen / correction time。

不能用键鼠监控侵犯隐私。可通过显式 UI state、review action 和短期研究抽样估算，并给区间而不是伪精确值。

12.6 仪表盘层级

12.7 Anti-Goodhart Guardrails

Anthropic 2026 Enterprise analytics 已公开把 cost per commit/PR/session、estimated lift、automation leverage 与 observed metrics 放到同一 value tab，并允许用户调整假设。[推断] 这表明市场正在从 usage analytics 走向 value analytics；但任何 estimated lift 仍需客户自己的 baseline 校准。Claude usage analytics

13. Kimi Code 的竞争位置：公开事实与战略推断分开

13.1 公开可确认的资产（截至 2026-08-03）

[事实] Model / price-performance surface

• Kimi Code 当前提供 K3、K3-256k、K2.7 Code 与高速版；K3 支持 low/high/max effort，最高 1M context 和图片/视频输入；
• K3-256k 官方定位是 256K 内保持能力、降低消耗；K2.7 高速版约 6 倍输出速度、3 倍额度消耗；
• 会员档位按模型、context、速度分层。

来源：Kimi Code 模型配置、Kimi K3 公开仓库

[事实] Distribution / compatibility

• 官方 CLI、VS Code；JetBrains/Zed 可经 ACP；
• Kimi Code API 兼容 OpenAI 与 Anthropic 接口，可接 Claude Code、OpenCode、Codex 等第三方工具；
• 官方产品概览称每 5 小时约 300–1200 次请求、最高并发 30，具体受套餐与用量影响；这是公开 entitlement range，不是实测吞吐或 SLA。

来源：Kimi Code 概览

[事实] Open runtime / extensibility

• kimi-code 公开仓库采用 MIT License；支持 MCP、plugins、skills、subagents、hooks 和 ACP；
• Kimi Agent SDK 公开提供 Go、Node.js、Python client，复用 CLI 的配置、工具、skills 与 MCP，并暴露 approval/tool call/session orchestration。

来源：Kimi Code repository、Kimi Agent SDK

这里的事实边界必须严格：MIT 与公开仓库证明的是特定代码资产的可审阅、修改和分发权；它们本身不证明公开仓库与线上版本完全同源，也不证明 Kimi 的 Agent 行为更先进、可靠性更高或商业价值更大。后者必须分别用 release provenance、目标任务 eval、SLO/incident、retention 和单位经济数据验证。

[事实] Packaging

• Kimi Code 是 Kimi 会员权益的一部分，与 Kimi 共享总额度；有每 7 天刷新和每 5 小时 rolling limit；
• Extra Usage 在订阅额度后按实际 input/output/cache 相关用量扣费，可设月消费上限；当前官方文档称不支持企业版；
• Kimi Code 会员面向交互式使用；产品集成、企业调用和团队用量管理被引导到开放平台。

来源：会员权益、社区倡议

13.2 战略位置

[推断] Kimi Code 当前最有辨识度的结构不是单一 CLI，而是：

自研前沿模型 K3 / coding model
  × 公开可审阅的 Agent runtime
  × OpenAI/Anthropic API compatibility
  × ACP/MCP/SDK/plugin extension surface
  × 中国用户订阅与产品分发

这让它可以同时竞争三个位置：

1. Model supplier：用户在 Claude Code/Codex/OpenCode 中用 Kimi 模型；
2. Agent runtime：用户选择 Kimi CLI/VS Code/SDK 作为执行控制面；
3. Agent platform/ecosystem：plugins、MCP、skills、subagents、ACP 与未来团队治理。

三个位置互相增强，也有冲突：API compatibility 扩大模型分发，却可能让用户不采用 Kimi runtime；公开 runtime 提高 inspectability、可定制性和生态参与的可能性，却降低代码本身的排他性，并且只有在 code-to-release provenance、安全响应和真实 outcome 可靠时才会转化为信任；会员低门槛促进个人采用，却与 production automation / enterprise governance 的 contract 不同。

13.3 Kimi 的潜在 Wedge

[推断，需内部数据验证]

• 高性能模型 + 订阅额度的 price/performance；
• 大 context、多模态，适合大 repo、视频/截图驱动开发；
• OpenAI/Anthropic 双协议兼容，迁移成本低；
• CLI/VS Code/ACP 覆盖现有开发习惯；
• 公开 runtime 与可扩展 surface 对高级开发者更可审阅、可组合；能否转化为信任取决于线上同源、release/security 治理和 outcome 证据；
• 中国支付、网络、语言、社区与本地数据工具生态。

验证这些 wedge 应看首次 accepted outcome 和第二次委派，不应看安装或 token 消耗。

13.4 Kimi 的战略张力

13.5 与主要竞争结构的对照（截至 2026-08-03）

这不是排名，也不是开源度或 feature count 比赛，而是不同的 product-frontier 选择；哪一个进入 economic frontier，只能由相同任务合同下的 outcome、attention、cost 和 risk 决定：

公开来源：Claude Code parallel agents、Claude Code agent teams、Claude Code platforms、Codex app、Codex remote supervision、Codex rate card、Pi repository、Pi coding-agent README、Pi custom models、GitHub Copilot billing

13.6 Kimi 真正可能形成的护城河

[推断] 最强组合不是“1M + 更便宜”，而是：

K3/K2.x model behavior
  -> Kimi runtime trace
  ->真实 failure cohort / eval
  -> model + context + tool + runtime 联合改进
  -> 更低 CPVAO / human attention / incident
  -> trusted delegation
  -> 更多高价值真实任务

这要求公开或内部系统能稳定回答：

• 同一模型在 Kimi harness 与外部 harness 为什么不同；
• 失败首次发生在哪层；
• 哪个改动降低了哪个 cohort；
• 1M、highspeed、subagent、plugin 各自改善哪些 task family；
• 用户是否真正验收，而不只是生成了更多代码；
• enterprise authority、audit、chargeback 与 incident response 如何闭环。

13.7 公开资料无法证明的事情

不能从现有公开资料断言：

• Kimi Code 的 retention、market share 或企业渗透率；
• K3 的真实推理成本和毛利；
• 用户 accepted outcome rate；
• 公开 repo 与线上生产版本完全一致；
• 1M context 在真实客户任务上的平均 ROI；
• 插件生态已形成强网络效应；
• 团队内部 product priority。

面试中把未知项明确标出，比用竞品叙事填空更有含金量。

14. 十五个反例：检验是否真的理解单位经济学

14.1 Token 降了，CPVAO 却升了

小模型少输出，但检索错误、重复工具调用、人工修复增加。结论：资源成本下降不等于结果成本下降。

14.2 Acceptance 上升，真实质量下降

UX 让用户更容易点接受，或默认隐藏未验证项。结论：acceptance 必须和 reopen/revert/incident、独立抽检一起看。

14.3 1M Context 让任务更差

相关文件被大量历史和工具定义淹没，prefill 变慢，cache miss 更贵。结论：容量不是 context quality。

14.4 高速模型没有缩短任务时间

critical path 在测试、sandbox、tool API 和 review。结论：测 TTV breakdown，不测 tokens/s 就结束。

14.5 Cheap-first 比直接 Strong 更贵

便宜 route 污染 workspace，升级后需重做 context 和修复错误。结论：cascade 依赖可靠 detector 和低 escalation overhead。

14.6 Multi-agent 提升 wall-clock，却降低组织吞吐

并行产生多个大 patch，merge 和 review 爆炸。结论：优化 verified throughput，不优化 agent-hours。

14.7 Outcome Pricing 奖励坏行为

按“测试通过的 PR”收费，Agent 添加脆弱或过拟合测试。结论：oracle 必须覆盖长期质量与不可投机约束。

14.8 Subscription 毛利看似很好，重度用户却被赶走

大量 inactive seat 补贴 heavy usage，限额触顶打断高价值 task。结论：看 utilization distribution、task interruption 与 expansion，不只看平均毛利。

14.9 开源带来 stars，没有带来生态

用户能读代码却没有稳定 extension contract、版本治理和 monetizable workflow。结论：open source 不是 network effect。

14.10 插件越多，成功率越低

tool discovery 占 context，schema drift、auth 和 supply-chain 故障增加。结论：生态要看 install→accepted outcome 与 trust，不看插件数量。

14.11 更强 Verifier 造成更多假失败

strict grader 拒绝可用 artifact，触发重试和 review。结论：验证器也要测 false reject、覆盖和成本。

14.12 用户说“省了 5 小时”，实际投入更多

主观估算忽略 prompt、monitor、review 和返工。结论：把 perceived value 与行为/对照证据分开。

14.13 Route 按用户付费等级选择能力

高价用户简单任务被过度计算；低价用户高风险任务被弱模型处理。结论：plan 是预算约束，不应代替 task/risk routing。

14.14 高 Retention 来自配置不可迁移

短期 revenue 稳定，长期 trust、采购和生态受损。结论：健康 embeddedness 建在 workflow value 和开放 contract 上。

14.15 Benchmark 领先，没有商业 ROI

评测任务可自动评分、环境干净；客户任务有隐性规范、review 和部署风险。结论：benchmark 是能力证据的一层，不是 outcome economics。

15. 二十组面试深追问与专家回答骨架

15.1 为什么说 Agent 的价值单位从 message 变成 delegated task？

主答： message 是界面交互边界，task 是工作与验收边界。Agent 会跨多轮模型调用、工具、环境和验证持续行动；用户购买的是一个被验收的状态变化，不是回复长度。应区分资源单位、计费单位、配额单位、价值单位；价值向 task 迁移不要求账单也立刻按 outcome。

追问：那 OpenAI 2026 为什么从 per-message 展示改成 token credit？

这是反而支持四单位分离：token 适合边际成本归因，task 适合产品价值归因。内部可按 token 控制成本，外部仍以“完成什么工作”证明 ROI。

追问：什么不是 task？

开放式学习、探索和品味协作，互动过程本身有价值，不应强行 outcome 化。

15.2 如何定义一个可经营的 Agent Task？

主答： 不是 prompt，而是 contract：intent、scope、constraints、starting state、allowed effects、deliverables、acceptance、budget、deadline、escalation、provenance。经济学上最关键的是 starting state 和 acceptance；前者让成本/失败可归因，后者让“完成”可被交易。

追问：用户需求天然模糊怎么办？

先运行 co-planning / discovery 子阶段，产出可批准的 contract；模糊不能被模型的自信补齐。不同风险下，允许的自主澄清范围不同。

15.3 你如何算 Coding Agent 的真实成本？

主答： model + tool + runtime + external API + retry + machine verify + human attention + integration + opportunity + expected failure + support/governance。我会同时维护 marginal cost 和 fully-loaded cost，并用 stable task ID 归因到 accepted outcome。

追问：最容易漏哪项？

人类 active review、cache rebuild、相关重试、verification queue、失败造成的信任与事故，以及 quota 中断后的上下文重建。

追问：为什么不用 cost/session？

session 边界不稳定，同一 task 可跨 session，一次 session 也可包含多个意图；它适合计费近似，不适合 outcome 归因。

15.4 什么时候更贵的模型反而更便宜？

主答： 当 ΔP_accept×Benefit + review saved + expected loss avoided + deadline value 大于增量 machine cost。强模型减少步骤、错误 tool call、重试和人工 review 时，CPVAO 会下降。

追问：如何证明不是事后故事？

按固定 task cohort、harness、budget、verifier 做 route A/B，报告 task-mix adjusted acceptance、TTV、human minutes、risk 和 CPVAO，不只看 token。

15.5 如何设计 latency–quality–cost 模式？

主答： 先找 Pareto frontier，删除同时更慢、更贵、更差的配置；再把剩余点包装为 stable service semantics，如 Instant、Balanced、Deep、Urgent/Hedged。每个模式绑定 deadline、budget、verifier 和 effect policy，而不是只映射一个 effort 参数。

追问：什么 latency 最重要？

至少分 TTFE、TTFA、TTV 和 deadline miss。交互式小改看 TTFA；background task 看 TTV；incident 看 deadline 内成功率。

追问：Codex/Claude Code 的长任务、多 Agent，或 Pi 的小内核，谁更先进？

先拆 product frontier 与 economic frontier。前者比较任务时长、监督面、并行协调、provider choice、扩展和治理能力；后者比较同一 task cohort 的 CPVAO、TTV、human minutes 和 risk。Codex/Claude Code 扩大 long-running supervision 与 multi-agent 可行域，Pi 用 minimal core 与多模型组合扩大选择权；三者都只是经济假设，不能从功能、公开代码或厂商 telemetry 直接推出 ROI。

15.6 你会如何做模型路由？

主答： 把它建模成 sequential decision：入口用 task/context/risk/deadline/plan 做初始 route；先获取便宜证据，再随 trace 更新后验；运行中可以 continue、escalate、hedge、ask 或 stop。risk/data/effect 是硬约束，价值与成本在可行 route 中优化。

追问：最重要的 route feature 是什么？

不是 prompt 长度，而是 task horizon、context uncertainty、verifier strength、effect risk、deadline、cache/state compatibility。

追问：如何评估 router？

predicted vs realized acceptance/cost/latency、escalation、false pass、cache loss、route regret，并按 task mix 校准。

15.7 Cheap-first cascade 为什么经常失败？

主答： 它依赖 detector，而不是便宜模型本身。Verifier 如果 false accept 高，错误直接流出；如果 false reject 高，会触发昂贵升级。再加 cache 失效、错误锚定、workspace 污染，期望总成本可能比直接 strong route 高。

追问：什么任务适合 cheap-first？

低风险、可逆、强 deterministic oracle、escalation 不需重做状态、便宜 route 不会产生外部副作用的任务。

15.8 如何做 Agent 服务容量规划？

主答： 把系统当作 model、tool/sandbox、external API、machine verify、human review、integration 的 queueing network。计算每 task 对各阶段的 visits×service time，系统吞吐受最小阶段容量限制；用 Little’s Law 管 WIP，用 P95/P99 而非均值管理 SLA。

追问：多 Agent 为什么难？

它是 fork–join：总完成时间由最慢分支加 merge/联合验证决定，还会放大外部 rate limit、状态和 review。应记录 critical path 和 retry amplification。

15.9 为什么 verification capacity 会成为瓶颈？

主答： generation 可以通过更多并发快速扩张，verification 和 integration 受可靠 oracle、reviewer 注意力、CI 和风险流程约束。若只扩生成，未验证 WIP、merge 冲突和 defect escape 会增长；组织得到的是自动化债务，不是产出。

追问：再加 reviewer agent 不就行了？

只有证据路径足够独立才增加 assurance。相同模型、context 和 grader 可能相关失败。deterministic oracle 优先，高风险结果保留人类与 staged rollout。

15.10 Human attention 如何量化？

主答： 不用 session wall-clock。我会拆 active spec、co-planning、approval、foreground monitoring、post-hoc review、exception handling、reopen/correction 和 context switching。通过显式 UI state、review action 与抽样研究估算区间，避免侵入式键鼠监控。

追问：怎么换算成钱？

用 fully-loaded role cost 是一种管理会计近似；对高价值专家还要考虑 opportunity cost。金额不是唯一指标，reviewer-hour 本身可能是硬 capacity constraint。

15.11 Agent 应按 token、seat、task 还是 outcome 定价？

主答： 没有单一答案。seat 适合 access 和低决策摩擦；token/usage 适合边际成本；task/session 适合 predictable delegation；outcome 适合 oracle 清楚、归因强、尾部风险可控的 workflow。成熟企业方案常是 access fee + usage + assurance/SLA + 可选 success component。

追问：用户不喜欢 token 账单怎么办？

产品层展示 task budget range、剩余完成概率和 CPVAO，财务层仍可用 token 结算。不要把内部资源单位直接丢给用户理解。

15.12 Outcome pricing 最大的问题是什么？

主答： verifier、归因和尾部责任。可测 outcome 会被投机；客户可能把最难任务逆向选择进来；结果常由人、Agent、CI 和业务环境共同产生；很多质量问题延迟出现。

追问：如何降低争议？

固定 starting state、contract/version/verifier，定义 exclusion 和责任上限，保留 evidence receipt，采用 staged acceptance，并让部分费用与 outcome 挂钩而非全押。

15.13 订阅模式的单位经济学最容易误判什么？

主答： 平均毛利会被大量 inactive seat 美化，而少数 heavy user 消耗和支持成本集中。还要看 entitlement utilization 分布、quota interruption、overage attach、heavy-user contribution margin、upgrade/churn cohort。

追问：限额越严毛利越好吗？

短期可能，但高价值 task 中断会伤害 trust、retention 和 expansion。应在任务开始前做 budget sufficiency，允许 checkpoint/overage，而不是中途突然停。

15.14 如何选 Agent 产品的 wedge？

主答： 选 pain 强、频率高、能快速产生 trusted outcome、分发有优势且可扩展的狭窄 workflow。指标是 first accepted outcome、second task conversion 和 adjacent expansion，不是下载/消息/token。

追问：Coding Agent 的 wedge 还存在吗？

存在，但从“能写代码”迁到更细的结构优势：特定 repo/生态、background workflow、enterprise control、长 context/multimodal、price-performance、地域/渠道。

15.15 Agent 产品有网络效应吗？

主答： 通常没有强同侧直接网络效应。更可能有 team collaboration、tool/skill 双侧生态、verified data learning、规模经济和 trust/brand。没有让新增用户改善其他用户价值的机制，就只是规模。

追问：开源社区算网络效应吗？

只有扩展供给和用户采用形成循环，且 extension contract、质量和信任可治理时才算；stars/forks 本身不是。

15.16 什么样的数据才是 Agent 护城河？

主答： 不是 transcript 量，而是有 starting state、trace、effect、verifier、acceptance、first-error attribution 和 consent 的真实任务数据。它能转成 eval/regression，并证明某个 model/harness/router 改动改善了某 cohort。

追问：用户 accept 能当 label 吗？

只能是弱信号，可能受 rubber stamp、低标准、结果延迟影响。要和测试、review、revert、incident、复用和长期 outcome 结合。

15.17 你如何判断 Agent 护城河？

主答： 分 model、harness、context、tools、runtime、eval/data、workflow、distribution、trust 九层，看 customer value、uniqueness、learning rate、embeddedness、replication ease、obsolescence 和 maintenance。单模型领先衰减快；eval/runtime/workflow/trust 更慢，但要求真实 operational evidence。

追问：开放源码会破坏 moat 吗？

会降低代码排他性，却可能增强 inspectability、可定制、生态、人才和分发；这是治理与分发属性，不是先进性证明。只有 code-to-release 可验证、扩展质量可治理、SLO/outcome 更好时，公开代码才可能转化为商业优势。真正 moat 应在运行数据闭环、SLO、workflow、trust 和迭代速度，不应靠隐藏实现。

15.18 Build vs Buy 怎么做？

主答： 逐层决策。通常 build 核心 loop、task state、policy、eval 和 route；对 base model、sandbox、search、IAM、billing 采用组合采购或标准。用 differentiation、strategic data、trust ownership、unit-cost advantage 减去 opportunity cost、maintenance、commodity maturity 和 obsolescence。

追问：什么必须有退出计划？

所有 provider/sandbox/tool/eval 采购：数据导出、state/artifact 迁移、价格/SLO 变化、contract termination、训练权利、cost attribution 和 fallback eval。

15.19 协议开放会不会把 Kimi 变成可替换 commodity？

主答： 会增加模型和工具可替换性，但也降低 integration CAC、扩大生态、增强用户信任。关键是开放 connection/portability contract，同时拥有 task state、policy、context、runtime、eval、verified workflow 和 SLO。稳定语义内核外加 capability-aware adapter，不能为兼容抹掉模型特化。

追问：兼容 OpenAI/Anthropic API 的风险？

名义 schema 相同，不代表 thinking preservation、tool ID、media、error、cache 和 context 语义相同。必须做 compatibility eval 和显式 capability negotiation。

15.20 你如何评价 Kimi Code 的竞争位置，并决定优先级？

主答： 公开证据显示 Kimi 同时拥有 K3/K2.x 模型、MIT 公开 runtime、OpenAI/Anthropic API compatibility、ACP/MCP/plugins/subagents/hooks/SDK，以及订阅分发。这使它能竞争 model supplier、agent runtime、platform/ecosystem 三个位置，但 MIT 和 feature surface 只说明资产/可行域，不证明产品领先或商业价值。

真正的战略问题不是再堆一个 feature，而是把这些层连成 outcome flywheel：公开 runtime trace 如何进入 failure cohort/eval，如何联合改善 model/context/tool/runtime，最终降低 CPVAO、review 和事故。

追问：你会先做什么？

没有内部数据不能假装给 roadmap。我会先检查四类证据：

1. 哪些高频 task cohort 无法验收，首次错误在哪；
2. 1M/256K/highspeed/subagent/plugin 对 TTV、CPVAO、review 的真实贡献；
3. quota/cache/retry 在长任务中造成多少中断与浪费；
4. 个人兼容分发如何转化为 Kimi runtime 的重复委派和团队 trust。

若 outcome/成本/trace 还不能按 task 联通，我会优先建立这条事实链，因为它同时提高产品判断、路由、定价和研发迭代质量。

16. 面试白板：一张图讲清 Agent Business System

User / Team
  |
  | DelegatedTask contract
  v
Admission -- plan/quota/risk/data policy
  |
  v
Adaptive Router ---------------------------+
  |                                        |
  | model/effort/harness                    | cost / capacity state
  v                                        |
Durable Runtime <-> Context/Memory          |
  |                                        |
  +-> Tools / Sandbox / External APIs       |
  |                                        |
  +-> Effect receipts / checkpoints         |
  |                                        |
  v                                        |
Verification Ladder                        |
  | machine -> independent -> human -> prod|
  v                                        |
Outcome Ledger ----------------------------+
  | acceptance / cost / latency / risk
  v
Product + Eval + Pricing + Capacity decisions
  |
  +-> failure cohort -> regression -> model/harness/tool/runtime change
  +-> packaging / routing / SLO / roadmap

白板时强调三个闭环：

1. 执行闭环：证据—行动—反馈—验证；
2. 经济闭环：任务—成本—验收—毛利/ROI；
3. 学习闭环：trace—failure cohort—eval—系统改进。

三个闭环必须共享 task identity，但数据权限和 retention 不必共享。

17. 一手资料与结论边界

17.1 Task / work unit / adoption

• OpenAI — How agents are transforming work, 2026-06-25：长任务和并行 agent turn 的自有产品数据；individual task-horizon 结论来自随机 0.1% 用户样本且由 LLM 估算，不能当独立 productivity 因果证据。
• Anthropic — AI’s impact on software development, 2025-04-28：Claude Code automation/augmentation 描述性分析；只代表其样本生态。
• Anthropic Economic Index — Geography and enterprise adoption, 2025-09-15：2025-08 的 100 万条 first-party API transcript 样本；企业 automation 与 task category cost/use 相关性，不是价格弹性实验。

17.2 Productivity / verification / downstream constraints

• METR — Early-2025 experienced open-source developer RCT, arXiv v2：16 位开发者、246 个任务、特定 repo 与 early-2025 工具中观察到 19% slowdown；未经同行评审，不能外推所有工具/人群。
• METR — 2026 experiment design update：明确披露后续样本选择与并行计时问题，当前 uplift 未能可靠估计。
• METR — Algorithmic vs. Holistic Evaluation：18 任务小样本，支持自动测试与真实可采用性有差距。
• DORA — 2025 State of AI-assisted Software Development：完整报告入口；近 5,000 人观察性调查，AI 与 throughput/product performance 正相关、与 stability 负相关，不能证明因果。
• Human oversight of agentic systems in practice, 2026：arXiv v1 preprint；17 位开发者访谈，提出 a priori control、co-planning、real-time monitoring、post hoc review；是未经同行评审的探索性定性研究。

17.3 Benchmark integrity / model–harness effect

• Harness-Bench, arXiv v1, 2026-05-27：106 个 sandbox task、5,194 条轨迹；支持按 model–harness configuration 报告结果，未经同行评审。
• Claw-SWE-Bench, arXiv v1, 2026-06-10：350 个任务；同模型下 adapter/harness 造成巨大分差，并公开成本轴，未经同行评审。
• DeepSWE, arXiv v1, 2026-07-08：113 个原创长任务、手写 verifier 和完整轨迹；judge disagreement 数字是作者样本内报告，未经第三方复现。
• OpenAI — Separating signal from noise in coding evaluations, 2026-07-08：厂商对 SWE-Bench Pro 的 task-level audit，估计约 30% task broken；不是独立同行评审研究。

17.4 Harness / runtime / evaluator economics

• Anthropic — Harness design for long-running application development, 2026-03-24：planner/generator/evaluator、模型代际与 scaffold 简化的厂商 engineering case study，不是受控普适实验。
• Anthropic — Scaling Managed Agents, 2026-04-08：session/harness/sandbox 解耦与 managed runtime 的厂商工程经验。
• Anthropic — Effective harnesses for long-running agents, 2025-11-26：跨 context 长任务的 initializer、incremental progress 和 artifact handoff；属于厂商工程案例。
• Anthropic — Claude Code platforms：web 离线继续长任务、Desktop 并行 review 与 remote steering 的当前产品文档；证明功能面，不证明生产率。
• Anthropic — Run agents in parallel 与 agent teams：subagent、agent view、worktree、team supervision 的当前官方语义；明确并行 token 放大，agent teams 为 experimental 且有协调/恢复限制。
• OpenAI — Introducing the Codex app, 2026-02-02 与 Work with Codex from anywhere, 2026-05-14：并行 thread/worktree、review、automation queue 与跨设备 long-task supervision；产品能力和厂商 adoption telemetry 均不构成客户 ROI 的因果证据。
• Pi Agent Harness repository、coding-agent README 与 custom models：MIT、小内核、默认四工具、多 provider/model 和 extension 事实；同一官方资料明确其默认无内建 filesystem/process/network/credential 权限边界，因此可组合性不能直接解释为更低总成本或更高 enterprise readiness。

17.5 Pricing / packaging 的真实市场实验（截至 2026-08-03）

• Kimi Code 产品概览：产品入口、双协议、频率/并发、会员与开放平台边界。
• Kimi Code 会员权益：周/5 小时额度、Extra Usage、cache-sensitive 计费、消费上限、企业边界。
• Kimi Code 模型配置：K3/K2.7、context、effort、速度/消耗与 cache 语义。
• Kimi 开放平台：K3、K2.7 Code、K2.6 的当前 cache-hit/input/output API 价格。
• GitHub — organization/enterprise billing：当前 seat price、included AI credits 与 $0.01/credit overage。
• GitHub — usage-based billing：model/token→AI credit、shared pool、促销期和预算控制。
• GitHub — all plans migrated to AI-credit billing, 2026-06-01：当前计费迁移时间点。
• GitHub — AI-credit session limits, public preview, 2026-07-01：覆盖 model/subagent/compaction 的单会话 soft cap，明确可能轻微超额。
• GitHub — one premium request per coding-agent session, 2025-07-10：已被 2026-06 规则取代的历史 task/session packaging 实验。
• OpenAI — Codex rate card：当前 token-based credit mapping、具体模型倍率与少量 legacy Enterprise 例外。
• OpenAI API — GPT-5.6 model comparison：Sol/Terra/Luna 的当前 API input/cache/output 美元价格。
• OpenAI API — GPT-5.6 model guidance：cache write 计价与模型迁移/effort 语义。
• OpenAI — Codex flexible pricing for teams, 2026-04-02；2026-06-24 更新：历史 rollout 与当前限制；新的 Business pay-as-you-go seat 已停止，既有 seat 不受影响。
• Anthropic — Enterprise billing：当前 single Enterprise seat access + separate API-rate usage + spend limit，并明确 legacy seat 边界。
• Claude pricing：当前 Enterprise seat 与 Fable/Opus/Sonnet API 价格；Sonnet 5 introductory price 有明确截止日。
• Anthropic — Team/Enterprise analytics：usage 与 cost per commit/PR/session、estimated lift/value metrics。

17.6 Kimi 的公开产品与代码

• MoonshotAI/Kimi-K3：模型架构、Kimi K3 License、评测设置及不同 harness/fallback/refusal 脚注；benchmark 数字属于厂商自报。
• MoonshotAI/kimi-code
• MoonshotAI/kimi-agent-sdk
• Kimi Code 社区倡议

17.7 哪些是本文推断

下列判断不是厂商公开结论，而是基于上述事实的战略推导：

• verified outcome / verification capacity 会成为 Agent 组织主要经营单位和瓶颈；
• Kimi 可同时竞争 model supplier、runtime 和 platform 三个位置；
• Kimi 最可持续的 moat 更可能是 model–runtime–eval 的联合学习率，而非单一 context/速度特征；
• seat + usage + assurance/SLA + 部分 success component 是比纯 outcome pricing 更现实的企业结构；
• 协议开放降低锁定，却可能通过分发、生态、trust 和 control-plane embeddedness 增强总体护城河；
• 个人会员共享额度与 production/enterprise contract 之间存在需要独立产品化的边界。

这些推断都应由真实 cohort、outcome ledger、成本、留存和企业采购证据继续证伪或修正。

18. 最终知识压缩

如果面试只剩三分钟，保留以下十句话：

1. Agent 的价值单位是有 contract、effect 和 acceptance 的 delegated task，不是 message；
2. 价值单位、计费单位、资源单位、配额单位必须分开；
3. 优化目标是 risk-adjusted verified outcome throughput；
4. 真实成本包含 model、tool、runtime、retry、verification、human attention、opportunity 与 risk；
5. 更贵模型只要显著提高验收、减少 review/事故，就可能降低 CPVAO；
6. routing 是基于新证据动态更新的 sequential decision，不是按 prompt 长度选模型；
7. Agent 扩张首先撞上的常是 verification / integration capacity，而非 generation capacity；
8. 定价可按 seat/token/session，但 ROI 必须回到 accepted outcome；纯 outcome pricing 受 oracle、归因和责任约束；
9. moat 分布在 model、harness、context、tool、runtime、eval、workflow、distribution、trust，最强的是跨层学习闭环；
10. 对 Kimi Code，最高含金量的问题是：如何把 K3、公开 runtime、协议生态和真实 trace 连接成更低 CPVAO、更强 trust 的 verified-outcome flywheel。