H8 · 如何管理 Agent System 的资源、成本与预算？ - Resource Management

所属知识库：Agent 全栈技术地图
所属领域：03 · Agent System
所属章节：03 · 如何让 Agent System 稳定、安全、可控地运行？ - Engineering & Governance
文档类型：资源治理、成本工程与预算控制专题研究
版本：v1.1
更新日期：2026 年 10 月 29 日
核心问题：当 Agent System 的任务具有不确定执行步数、动态模型选择、多 Agent 并发、外部工具调用和长时间运行等特征时，如何在满足质量、安全与时效要求的前提下，对计算、容量、Token、费用、时间及人工资源实施可度量、可分配、可约束、可追溯的治理？

专题导读

本篇属 Engineering & Governance。传统 API 的资源需求通常可以通过单次请求规模与请求量估算；Agent System 则可能在执行中继续规划、调用工具、触发子 Agent、返工或等待人工审批。一次任务提交不是一次模型调用，一次模型调用也不代表任务成本已经确定。 因此，资源治理必须覆盖任务生命周期，而不能只统计供应商账单。

本文以“技术研究报告 Studio”为贯穿案例：用户提交研究主题，选题、调研、分析、审核和发布 Agent 协作完成报告。系统需要决定任务能否启动、为每个阶段分配预算、处理并发与限流、在成本上涨时选择降级或等待，并在最终交付时解释费用来自何处。研究同时覆盖模型 Token、计算、存储、检索、网络、工具 API、人工审核与运营成本。

章节边界： L1 研究运行资源的基础设施；L2 提供队列、缓存、存储等基础服务；L3 执行模型路由、限流与计量；L4 管理单 Agent 执行循环；L5 管理跨 Agent 任务调度。H8 负责跨层资源政策、预算约束、成本归因与优化决策。H1 提供观测数据，H3 判断优化是否损害质量，H5 管理价格和策略版本，H7 约束可靠性风险，H12 规定组织级治理政策。

阅读目标： 能建立资源分类与计量模型，设计任务级预算协议、并发与配额体系、成本账本、优化实验及验收标准，并识别“省钱但损害质量或安全”的错误优化。

一、资源管理的定义、目标与边界

1.1 定义

Agent System 的 Resource Management 是一组跨技术层的资源可见性、容量分配、使用约束、成本核算与优化控制机制。它同时管理两类问题：第一，系统是否有足够的资源在规定时限内执行任务；第二，系统是否应当为某个任务继续投入资源。

资源管理并不等于成本削减。合格的系统应在质量、可靠性、安全、延迟与费用之间建立明确的服务约束：有些任务应提高模型能力，有些任务可以排队，有些任务必须因预算不足而停止，有些高风险操作即使预算充足也必须等待审批。

1.2 六类主要资源

资源类别	典型计量单位	常见约束
模型推理	输入/输出 Token、请求数	TPM、RPM、价格、上下文
计算资源	CPU/GPU 时间、内存	配额、实例容量、利用率
外部工具	API 次数、查询量、执行时间	供应商限额、单价、许可
数据资源	GB·月、读写量、传输量	容量、吞吐、保留期限
调度资源	并发槽位、队列等待时间	公平性、优先级、超时
人工资源	审核分钟、审批队列	人力容量、响应时限

这些资源不能简单折算为 Token。比如，模型生成代码只消耗少量 Token，但随后启动的沙箱可能占用大量 CPU；一份报告生成费用较低，却可能要求人工审核数小时。应同时维护资源使用量与货币化成本两个视图。

1.3 五个治理目标

1. 可预测性： 提供任务启动前的成本区间、容量需求与预计时长，而不是承诺无法保证的精确值。
2. 可控性： 支持任务、用户、租户、项目、Agent、工具等多个层级的硬限制与软限制。
3. 公平性： 防止长任务、循环 Agent 或单一租户长期占据公共资源。
4. 可追溯性： 费用能归因到具体 Run、Step、模型调用、工具动作与配置版本。
5. 有效性： 以质量与完成率为前提进行优化，而不是单纯降低账面成本。

1.4 与相邻概念的区别

• Quota（配额）： 某主体在一段时间或总生命周期内允许使用的资源总量。
• Rate Limit（速率限制）： 单位时间内允许发生的请求或资源消耗。
• Concurrency Limit（并发限制）： 同一时刻允许进行的工作数量。
• Budget（预算）： 对可计价资源的支出上限或目标，通常需要预留、结算与超额处理。
• Capacity Planning（容量规划）： 预测资源需求与供给缺口，决定扩容或排队策略。
• Cost Attribution（成本归因）： 把已发生的使用与费用分配到责任对象。

配额、速率限制和并发限制解决不同问题。限制每分钟请求数不能保证不超支；限制费用也不能防止瞬间并发打满数据库连接池。

二、资源治理对象与责任模型

2.1 多层级资源主体

建议建立如下逻辑层级：Organization → Tenant/Workspace → Project → Task → Run → Step → Operation。一个 Step 可包含多次模型尝试或工具尝试；一次尝试必须具有独立的 attempt_id，否则无法辨认重试费用。

成本可以按多维度归因，例如 tenant_id、project_id、run_id、agent_id、provider、model、tool_name、environment 和 config_revision。多维标签用于分析，不代表同一笔费用可以重复计入总账；聚合时必须选择明确的账务口径。

2.2 控制面与执行面的职责

资源控制面负责预算策略、配额定义、价格目录、优先级、分配与结算；执行面负责每次操作前的准入检查、资源占用、调用执行、结果报告及资源释放。重要原则是：执行器不能仅凭模型自报的剩余预算决定是否继续。

建议将以下决策放在可信服务端：预算余额检查、资源预留、租户限额、供应商凭据、工具执行权限、费用结算和强制停止。模型可以提出“换用低成本模型”或“继续调研”，但是否允许执行由控制面决定。

2.3 预算继承与隔离

上层预算对下层预算形成约束。例如项目剩余 100 元、任务被分配 30 元，则任务不得因为自身尚有额度而越过项目总预算。并行子 Agent 需要在启动前明确预算分配，否则每个子 Agent 都可能误认为可以使用全部剩余额度。

可采用两种策略：静态子预算适合可预测的流水线；共享预算池 + 原子预留适合动态分支，但必须处理竞争、超时回收与公平性。对于动态多 Agent 系统，通常需要二者组合。

三、计量模型：从原始使用量到成本账本

3.1 计量事件的最小契约

每次可计费操作产生一条不可随意覆盖的计量记录，至少包含：

{
  "usage_event_id": "ue_01",
  "tenant_id": "tenant_a",
  "task_id": "task_42",
  "run_id": "run_07",
  "step_id": "step_12",
  "operation_id": "op_98",
  "attempt_id": "attempt_02",
  "resource_type": "model_inference",
  "provider": "provider_a",
  "model": "model_x",
  "input_tokens": 2200,
  "output_tokens": 640,
  "cached_input_tokens": 500,
  "usage_source": "provider_reported",
  "pricing_revision": "price_2026_10",
  "occurred_at": "2026-10-29T00:00:00Z"
}

字段仅为示例契约，不是任何供应商的标准响应格式。供应商可能对缓存、推理 Token、批处理、工具调用、音视频或其他用量采用不同计费方式。实际系统应保留供应商原始账单字段，并由适配器映射到内部规范，不能假设所有模型都只有输入与输出两种 Token。

3.2 三种使用量口径

估算量（estimated）： 调用前根据提示词、历史统计和上限推断，用于预算预留。估算量可能与实际计费不同。

供应商报告量（reported）： API 返回的用量字段，通常适合单次调用归因，但未必覆盖所有账务调整。

最终结算量（billed）： 账单、折扣、退款、阶梯价或最低消费等调整后的费用。它可能滞后于调用发生时间。

因此建议同时维护 estimated_cost、reported_cost 与 settled_cost，并记录 price_revision、币种、税费和汇率口径。供应商未返回 usage 时，不应把用量记为零；应标记为 unknown 或 estimated，等待补偿对账。

3.3 成本核算公式与适用边界

对于仅按普通输入/输出 Token 计费的简化模型：

$$C_{model}=\frac{T_{in}}{{10}^6}{P}_{in}+\frac{T_{out}}{{10}^6}{P}_{out}$$

其中 P 是每百万 Token 的对应价格。实际计费还可能包括缓存命中/写入、推理 Token、批处理折扣、多模态计量、托管推理资源或固定费用。上述公式只是简化示例，不能直接替代真实供应商计费规则。

任务总成本可写成：

$$C_{task}=C_{model}+C_{tool}+C_{compute}+C_{storage}+C_{network}+C_{human}+C_{allocatedoverhead}$$

注意区分直接成本和分摊成本；人工审核及公共基础设施分摊往往是管理核算，不一定对应即时支付。对外计价与内部成本核算也应分离。

3.4 重试、失败与取消的计费

失败调用不一定免费；超时可能发生在供应商已经开始生成之后；用户取消本地请求也不保证远端停止处理。所有尝试都需要独立记录，并区分“未发出”“已发送但未知”“已收到用量”“最终账单确认”。对于未知状态，采用对账流程而非假定零费用。

3.5 成本账本与对账

建议采用追加式 Ledger：reservation_created、usage_reported、reservation_released、cost_adjusted、invoice_reconciled。不必强制所有业务使用完整复式记账，但必须保证事件唯一、可审计、可修正且不可静默删除。

常见对账维度包括：供应商账单与调用日志、预留金额与实际使用、任务汇总与操作明细、缓存节省估算与真实账单。对账差异需有状态（待查、已解释、已修正），不能通过直接改写原始用量来消除。

四、任务预算：预估、预留、执行与结算

4.1 预算类型

类型	作用	超限行为
硬预算	不允许继续产生新增支出	拒绝或暂停新操作
软预算	提醒、降级或请求批准	可按策略继续
阶段预算	限制选题、调研等阶段	阶段结束再分配
时间预算	限制执行总时长	超时停止或等待
资源预算	限制 Token、调用次数等	拒绝对应资源操作

“硬预算”也不等于绝对不会超支：预估误差、账单滞后和已发出请求会产生尾部风险。应设置安全缓冲、单次调用最大上限与对账补偿，并明确系统提供的是准入层硬约束还是最终账单绝对上限。后者在外部异步计费条件下通常无法无条件保证。

4.2 预算生命周期

Task Submitted
    ↓
Estimate：估算总量、峰值和不确定性
    ↓
Admission：验证租户/项目配额与预算
    ↓
Reserve：为即将执行的操作原子预留额度
    ↓
Execute：模型、工具或计算操作
    ↓
Meter：接收用量与费用信息
    ↓
Settle：实际费用入账，释放剩余预留
    ↓
Reconcile：与供应商账单核对并调整

每次操作的预算预留应采用事务或等价的原子条件更新。并发情况下，不能先读余额再分别写入，否则两个 Worker 可能同时通过检查。预算不足时，应返回明确的机器可读原因，例如 BUDGET_EXHAUSTED，并区分可申请扩额与不可重试的限制。

4.3 预算预留的示例

假设项目余额 20 元，两个并行任务各申请预留 15 元。如果检查与预留不是原子操作，两个任务可能都看到 20 元余额并启动。正确做法是通过数据库事务、条件更新或串行化的预算服务，使只有一个请求成功；失败者等待、缩小任务或申请额外预算。

预留不是永久扣费。完成后需按实际用量结算；失败或未执行应释放未使用部分；超时预留要通过租约和对账机制处理。若已发出外部调用但结果未知，不可简单释放全部预留，应先标记待核验。

4.4 不确定任务的动态预算

Agent 任务可能在研究过程中发现需要额外资料或多轮返工。建议在每个阶段设置决策点：检查剩余预算、边际收益、已有证据覆盖度、质量门槛和剩余截止时间。系统可选择继续、换模型、缩小范围、提交部分结果、等待审批或安全停止。

避免无限“自我优化”循环： 为每个 Run 设置最大步骤数、最大工具次数、最大重试次数、最大子任务深度及总截止时间。预算是最后防线之一，不应替代终止条件。

五、容量管理：限流、并发、排队与公平性

5.1 四种不同的容量约束

1. 请求速率： 如每分钟请求数（RPM），控制调用频率。
2. Token 速率： 如每分钟 Token 数（TPM），控制推理吞吐。
3. 并发槽位： 同时在途的模型请求、沙箱任务或工具操作数量。
4. 资源容量： CPU、GPU、内存、数据库连接、队列深度和带宽。

同一请求可能同时受到多个约束。不能用单一“并发数”代表所有容量；也不能把供应商限额误认为系统实际可用容量，因为租户隔离、模型能力、延迟与故障率还会影响有效吞吐。

5.2 限流算法的选择

Token Bucket 允许有限突发，适合请求或 Token 准入；Leaky Bucket 强调平滑输出；固定/滑动窗口 易于理解，但需考虑边界效应和实现成本；Semaphore 适合并发槽位。生产环境通常组合多种机制。

Token 预算存在调用前估算与调用后实际消耗的差异。可先按预计输入、最大输出与安全系数占用 TPM，再按供应商报告用量进行校正；不能仅用输入 Token 计算准入。

5.3 队列与优先级

研究报告 Studio 可将交互式审批响应、普通研究任务和批量后台任务分开调度。建议定义优先级但防止低优先级任务永久饥饿，采用加权公平排队、年龄提升或租户保底容量。

队列至少应提供：排队时长、预计等待区间、取消、截止时间、租户公平性、最大队列深度和拒绝策略。任务入队成功不代表能够在截止时间前完成；应在准入阶段考虑剩余容量与任务时限。

5.4 背压与负载削峰

当模型供应商限流、工具服务退化或数据库连接耗尽时，不能无限积压子 Agent。应在上游减少新任务、降低并行度、暂停低优先级工作或返回明确的过载状态。对于持续扩展的任务图，必须设置子任务创建配额和最大 Fan-out。

5.5 资源泄漏与长尾任务

常见泄漏包括：Worker 崩溃后未释放的并发槽位、已取消任务仍在运行的沙箱、超时后持续占用的浏览器会话、无人处理的审批队列。资源租约必须具有过期与核验机制；对于可能产生外部副作用的操作，回收资源与判定操作结果是两个独立步骤。

六、Agent 专属成本驱动因素

6.1 上下文膨胀

Agent 每次循环都把全部历史消息重新发送，会使输入 Token 随步数持续增长。优化方向包括：保留必要指令与最新状态、把长期证据存入外部存储、使用摘要或检索恢复相关内容、对大型工具结果进行结构化压缩。

但压缩会丢失信息，不能把未验证摘要作为事实来源。对于需要引用的研究报告，应保留原始证据和可回溯引用，评估压缩前后事实正确率。

6.2 多 Agent 扇出

一个 Supervisor 同时派发五个研究 Agent，可能缩短墙钟时间，却增加重复检索、上下文复制、协调消息与审核费用。成本模型应包含协作开销：总成本 = 有效工作 + 重复工作 + 协调开销 + 失败返工。

采用多 Agent 的前提是可度量收益，例如覆盖率提升、错误率下降或时效显著改善。若单 Agent 已能稳定完成任务，多 Agent 可能只是增加费用与复杂性。

6.3 重试与返工

同样的输出质量可能来自一次成功，也可能来自五次失败后的第六次成功。必须记录尝试次数、失败原因、重试费用、审核返工费用和最终有效产出。对无法恢复的错误持续重试，会同时损害成本与可靠性。

6.4 工具与外部服务

网页搜索、商业数据库、代码沙箱、OCR、浏览器自动化、语音识别、图像生成等工具的计费口径可能完全不同。统一模型网关不代表统一工具成本；工具应有独立的计量适配器和执行预算。

6.5 人工审核与等待

人工审核的成本不仅是工时，也包括等待时间和任务恢复开销。审批等待期间应释放不必要的计算资源；但不能因为预算压力绕过 H6 规定的审批门槛。应单独统计人工处理时长、排队时长与系统等待时长。

七、模型选择与成本 - 质量 - 延迟权衡

7.1 分层模型策略

将任务拆为检索规划、信息抽取、证据比对、复杂推理、审稿等不同工作类型。对能力要求较低且可验证的步骤，可评估成本更低的模型；对高风险推理或关键审核，应优先满足质量与安全门槛。

模型路由必须考虑：能力兼容性、结构化输出、工具调用、上下文容量、多模态支持、数据驻留、延迟、可用性、价格与历史评估结果。不能只按每百万 Token 价格排序。

7.2 缓存的适用性与风险

缓存可能减少重复推理与检索，但需要定义缓存键、权限作用域、模型/Prompt 版本、数据时效和失效策略。跨租户复用未经授权的响应会形成数据泄漏；对时效性强的研究结论使用陈旧缓存会损害质量。供应商侧 Prompt Caching 的实际节省也应按其计费规则核算。

7.3 批处理与异步执行

对无需实时响应的独立任务，可考虑供应商支持的批处理能力或内部异步队列。应评估折扣、完成时限、失败重试、结果顺序、数据安全与用户体验；不能假定所有模型、地区和工具都支持批处理。

7.4 优化实验必须保留质量门槛

建议采用配对任务集，对照相同输入与验收标准，比较质量通过率、任务成功率、总成本、P50/P95 延迟、重试次数与人工返工时间。优先使用每个合格任务的成本（cost per accepted task），而不是只看单次模型调用费用。

例如：方案 A 每次任务平均 2 元、通过率 50%；方案 B 每次任务平均 3 元、通过率 90%。在忽略返工差异的简化条件下，A 的每个合格任务成本约 4 元，B 约 3.33 元。单次调用更便宜的方案未必更经济。

八、资源管理系统的参考架构

8.1 核心组件

用户 / API / Studio UI
        │
        ▼
Task Admission Controller ──────── Policy & Quota Registry
        │                              │
        ├── Budget Service ─────────── Price Catalog
        │        │
        │        └── Reservation Ledger
        ▼
Scheduler / Queue / Fairness Controller
        │
        ├── L4 Agent Engine
        ├── L5 Multi-Agent Orchestrator
        └── L3 Model Gateway / Tool Gateway
                    │
                    ▼
             Usage Metering Events
                    │
                    ▼
       Cost Ledger / Reconciliation
                    │
                    ▼
       Dashboard / Alerts / Reports

其中模型网关负责单次模型调用的能力匹配和供应商交互；预算服务负责跨调用、跨任务的总量约束。两者通过统一的操作 ID 与用量事件关联。L5 调度器应在派发子任务前完成资源准入，而不是在任务执行后才发现预算不足。

8.2 最小数据实体

实体	关键字段	作用
ResourcePolicy	scope、limit、period、version	配额与规则
BudgetAccount	owner、currency、balance	预算归属
Reservation	operation、amount、expires_at	额度预留
UsageEvent	attempt、units、source、time	原始计量
PriceCatalog	provider、SKU、effective_at	价格版本
CostEntry	usage、amount、revision	费用核算
CapacityLease	worker、resource、expiry	容量占用

预算账户中的 balance 是逻辑字段，实际实现应明确它表示“已结算余额”“可用余额”还是“总额度减已结算与预留”。这些口径不可混用。建议统一为：available = limit - settled - active_reserved，并为已发生但未确定费用的操作保留风险缓冲。

8.3 事件与一致性要求

用量事件至少一次送达时，消费者必须通过 usage_event_id 或操作与尝试的组合键去重。预算预留与任务启动之间需要明确事务边界；如果跨服务不能使用同一事务，应使用 Outbox、补偿或状态机处理“已预留但未启动”等中间状态。

在分布式系统中，无法仅依赖进程内计数器保证租户总预算。需要共享的原子状态源。对于高吞吐场景，可采用分片配额或预分配额度，但应明确超发上限与回收机制。

8.4 API 契约示例

POST /v1/tasks
Idempotency-Key: task-create-123
Content-Type: application/json

{
  "project_id": "research_studio",
  "objective": "研究某产业发展趋势",
  "budget": {"currency": "CNY", "hard_limit": 30},
  "deadline_seconds": 3600,
  "priority": "normal"
}

示例是应用层与预算控制面的参考设计，不是现有标准 API。服务端应校验用户是否有权使用该项目及额度，检查租户和项目上限，并返回明确的预算批准或拒绝原因。调用方提供的 hard_limit 不能扩大上级配额。

九、研究报告 Studio：端到端资源治理案例

9.1 场景假设

用户要求生成一份具有可核查引用的技术研究报告。系统设定：单任务预算 30 元、最大执行 60 分钟、最多三轮审核返工。以下数字仅用于说明预算结构，不是实测或供应商报价。

阶段	预算示例	主要成本驱动
选题与规划	3 元	推理与初步检索
深度调研	12 元	搜索、网页处理、模型抽取
分析与写作	8 元	长上下文与生成
审核与返工	5 元	质量评估、重试
预留缓冲	2 元	用量误差与尾部风险

阶段预算可以重新分配，但必须遵守任务总上限和审批策略。若调研阶段只用 7 元，剩余额度是否可转给审核阶段，应由明确的预算规则决定，而非 Agent 自行修改。

9.2 一次任务的执行过程

提交： Admission Controller 检查租户配额、项目预算和当前容量，创建 Task 与预算账户关联。若系统预计无法在截止时间内完成，应拒绝或提示用户调整约束。

调研： 调研 Agent 请求启动三个并行检索子任务。L5 在派发前为每个子任务分配并发槽位与预算预留，防止全部子任务重复查询相同来源。

分析： 任务需要长上下文模型。L3 根据能力、数据权限和价格策略选择模型；H8 检查该次调用的预计最大费用。模型选择的最终结果与计量事件一同记录。

审核： 审核 Agent 发现引用不充分，需要返工。系统检查剩余预算和返工次数；若无法满足质量门槛，应返回“需要追加预算或缩小范围”，而不是在预算耗尽后输出看似完整但缺乏证据的报告。

发布： 人工批准后发布报告。发布动作属于 H6/H2/H7 管理的受控副作用，不能因预算紧张而绕过审批。最终展示直接成本、预估/实际差异、模型与工具分项费用及质量验收结果。

9.3 关键异常处理

异常	正确控制动作
供应商返回限流	排队或回退，遵守重试预算
子 Agent 无限扩展	阻止超过 Fan-out 与预算上限
用量字段缺失	标记待核验，不按零费用处理
Worker 崩溃	回收租约，核查在途操作
费用达到阈值	暂停新增支出，申请批准
质量未达标	拒绝以“低成本完成”冒充成功

十、资源指标、告警与管理看板

10.1 运行指标

建议监控：任务预算使用率、预留占比、预算拒绝率、单任务费用分布、每个合格任务成本、各模型/工具费用占比、每分钟 Token 消耗、模型 RPM/TPM 利用率、队列等待时间、并发槽位占用、缓存命中率、重试费用占比和账单对账差异。

指标需要有明确分母与口径。 例如“平均任务成本”是否包含失败任务、取消任务与人工审核费用？“缓存节省金额”是按理论价格估算还是经账单核实？若定义不统一，不同版本之间的比较没有意义。

10.2 建议告警规则

• 任务预算使用率达到 70%：提示并评估剩余阶段可行性；达到 90%：触发更严格的准入或人工确认；达到硬上限：拒绝新增支出。
• 某租户短时间内 Token 消耗突增：检查异常循环、滥用或错误配置。
• 单次调用估算费用显著高于历史分布：检查上下文膨胀与模型选择。
• 供应商账单与内部 Ledger 差异持续扩大：启动对账调查。
• 队列等待时间持续超出 SLO：调整容量或降低准入速度。

以上阈值是设计示例，必须通过真实负载、费用容忍度和业务目标校准。告警本身不能自动证明异常来自恶意行为。

10.3 高基数与数据隐私

不要把 run_id、task_id 等高基数字段直接作为所有时序指标的标签，可能显著提高监控系统成本。可在指标中使用低基数聚合维度，把具体 ID 放入 Trace、日志和成本账本。成本记录也可能包含客户、项目和供应商敏感信息，需要与 H2、H9 的访问控制和保留策略协同。

十一、资源优化方法与决策框架

11.1 优化优先级

第一步消除明显浪费：无限循环、重复检索、无效重试、未释放的计算资源和不必要的长上下文。第二步优化执行路径：缓存、批处理、并行度和任务分解。第三步优化模型组合：基于真实评估结果调整模型路由。最后再考虑自托管模型、预留实例或复杂的多级调度架构。

原因是：先解决逻辑浪费，通常比过早引入复杂基础设施更可控，也更容易通过实验归因。

11.2 自托管与 API 的成本边界

自托管模型不仅有 GPU 成本，还包括空闲容量、工程维护、模型更新、推理优化、安全隔离、故障恢复和质量评估。API 模式则受外部价格、速率、数据政策和供应商可用性约束。应比较给定质量与服务水平下的总拥有成本，不能仅以每 Token 理论推理价格下结论。

11.3 成本优化决策表

场景	候选措施	必须验证
重复输入多	缓存或复用检索	时效、权限、正确率
长上下文昂贵	摘要、检索、裁剪	证据完整性
高峰排队严重	扩容、限流、错峰	SLO 与公平性
子 Agent 过多	减少 Fan-out	质量与覆盖率
审核返工频繁	改进前序质量门槛	总成本与通过率
模型成本过高	能力分级路由	安全、质量、延迟

11.4 何时停止优化

当进一步降本需要牺牲合规性、审计能力、必要人工审批或最低质量要求时，应停止。成本治理必须服从系统级约束。对于研究报告 Studio，减少一次必要的事实核查不应被视为成功优化。

十二、工程实施路径

12.1 MVP：先做到可计量、可停止

第一阶段建议实现：统一操作 ID；记录模型与工具调用；任务级费用估算；单任务硬预算；最大步骤/重试次数；基础并发限制；按任务展示费用。即使暂时无法精确对账，也应保留原始事件与估算来源。

12.2 第二阶段：多租户与跨 Agent 控制

引入租户/项目预算层级、原子预留、共享容量池、队列公平性、子 Agent 预算分配、价格版本和用量对账。此阶段重点解决并发超支与成本归因。

12.3 第三阶段：数据驱动优化

建立质量 - 成本 - 延迟联合评估，实施模型路由实验、成本异常检测、容量预测和自动化预算建议。优化策略的发布应由 H5 管理版本，并通过 H3 的回归评估验证。

12.4 最小验收清单

• 同一操作重复上报用量不会重复入账。
• 两个并发请求无法同时花掉同一笔剩余额度。
• 子 Agent 预算总额不会绕过父任务和项目预算。
• 模型超时但计费未知时，账本保留待核验状态。
• 取消任务后，新的可计费操作受到阻止，既有在途费用仍可补录。
• 不同价格版本的历史费用能够复算与解释。
• 资源不足时返回明确错误，并支持排队、降级或申请扩额。
• 低成本策略必须通过质量、安全与可靠性门槛。
• 成本报表可以追溯到 Run、Step、Attempt 和供应商原始记录。
• 数据与账单访问符合租户隔离、审计和保留策略。

十三、最小可复现实验：并发预算预留

以下代码仅用于验证单进程、多线程条件下的原子预留；不适用于多实例生产部署。实际系统需采用数据库事务、唯一约束及可靠事件处理。配套文件 H8-Agent-System-Resource-Management-v1.1-demo.py，Python 3 标准库（含 3.9）。运行：python3 H8-Agent-System-Resource-Management-v1.1-demo.py。

from __future__ import annotations

from decimal import Decimal
from threading import Lock, Thread

class Budget:
    def __init__(self, limit):
        self.limit = Decimal(limit)
        self.reserved = Decimal("0")
        self.lock = Lock()

    def reserve(self, amount):
        amount = Decimal(amount)
        if amount <= 0:
            raise ValueError("amount must be positive")
        with self.lock:
            if self.reserved + amount > self.limit:
                return False
            self.reserved += amount
            return True

budget = Budget("20")
results = []
threads = [Thread(target=lambda: results.append(budget.reserve("15")))
           for _ in range(2)]
for thread in threads:
    thread.start()
for thread in threads:
    thread.join()
assert sorted(results) == [False, True]
assert budget.reserved == Decimal("15")
print("single-process reservation test passed")

本地执行通过：输出 single-process reservation test passed。

此实验只证明 Lock 可以保护同一 Python 进程内的共享余额；没有覆盖跨进程竞争、进程崩溃、结算、幂等请求、价格修订、数据库事务和账单对账。不能据此声称系统具备生产级预算一致性。

13.1 必须补充的集成测试

数据库竞争测试： 两个独立进程同时为同一预算账户预留额度，验证原子条件更新和唯一操作键。

故障注入测试： 在“预留成功 - 任务入队 - 操作执行 - 用量上报 - 结算”各节点强制崩溃，验证无重复扣费、无永久悬挂额度。

账单延迟测试： 模拟供应商数小时后补充费用，验证待核验余额与调整账本。

质量对照测试： 在固定研究任务集上比较不同模型策略的合格任务成本，确保降本没有牺牲事实与引用质量。

多租户压力测试： 模拟单租户突发负载，检查其他租户的最低服务能力和公平性。

十四、常见误区与反模式

反模式一：只统计 Token，不统计工具和人工成本。 结果会低估真实交付成本，尤其是浏览器自动化、外部检索和人工审核密集型任务。

反模式二：把预算判断交给模型提示词。 模型可以理解预算，但不能代替可信控制面的原子扣减与授权判断。

反模式三：按平均调用费用直接估算长任务。 Agent 的步骤数、返工次数和失败重试具有长尾分布，应使用区间估算与风险缓冲。

反模式四：将限流等同于预算。 低速持续调用仍可能长期超支；低费用操作也可能瞬间打满并发资源。

反模式五：把超时或取消视为零费用。 外部操作可能已发生或继续计费，必须保留未知状态与对账机制。

反模式六：以单次调用单价衡量模型性价比。 更便宜的模型可能带来更多重试、返工和人工修正。

反模式七：为降本跳过审核或事实核查。 违反质量与安全门槛的方案不是有效优化。

反模式八：没有价格版本。 供应商调整价格后，历史成本无法复算，跨期比较失真。

反模式九：用全局 FIFO 处理所有任务。 长任务或大租户可能挤占交互式请求与其他租户资源。

反模式十：把预算预留当作最终结算。 预留用于控制风险，实际费用需通过用量报告与账单核验确定。

研究结论

1. H8 是跨层资源治理能力。 它将 L1 - L2 - L3 - L4 - L5 - L6 的计算、模型、工具、存储、调度与人工资源统一纳入可计量、可约束、可归因的管理体系，而不替代各层具体执行机制。
2. 任务级预算是 Agent System 的基本控制单元。 单次 API 限流无法约束动态循环、多 Agent 扇出与多轮返工；需要任务、项目和租户的分层预算。
3. 预算控制必须区分估算、预留、报告和结算。 在异步计费和网络故障下，未知费用不能视为零；预算服务需要原子预留、幂等事件和对账流程。
4. 容量与费用是两个独立维度。 RPM、TPM、并发、计算资源、队列时延与货币预算必须分别控制，并通过调度器协调。
5. 多 Agent 的资源开销包含协作与返工。 评价架构效率应比较合格任务的总成本、质量和时效，而不是只比较模型调用次数。
6. 成本优化服从质量、安全和可靠性约束。 缓存、压缩、低价模型、批处理与自托管都需要通过可复现评估验证。
7. 最小可行体系应先实现可追踪与可停止。 随后逐步增加多租户公平性、对账、容量预测和质量感知的动态调度。

附录 A：参考文献与原始资料

以下以官方文档和标准为主。链接用于查阅原始技术定义与实现细节；本文未对全部页面在 2026 年 10 月 29 日的最新版本逐条联网核验，实际部署前应检查当前版本、适用地域和供应商合同。

• [R1] OpenAI, API Pricing. openai.com/api/pricing/ - 模型计费与价格结构；价格随时间变化，本文不引用固定单价。
• [R2] OpenAI, Rate Limits. platform.openai.com/docs/guides/rate-limits - API 速率限制、限流处理与额度约束。
• [R3] Anthropic, Rate Limits. docs.anthropic.com/en/api/rate-limits - 请求和 Token 等维度的速率约束；具体版本以官方文档为准。
• [R4] Google Cloud, Quotas and Limits. cloud.google.com/docs/quotas/view-manage - 配额概念与管理。
• [R5] Kubernetes, Resource Management for Pods and Containers. kubernetes.io/docs/concepts/configuration/manage-resources-containers/ - CPU、内存请求与限制。
• [R6] Kubernetes, Resource Quotas. kubernetes.io/docs/concepts/policy/resource-quotas/ - 命名空间资源配额。
• [R7] Kubernetes, Horizontal Pod Autoscaling. kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/ - 自动扩缩容原理及适用条件。
• [R8] OpenTelemetry, Metrics. opentelemetry.io/docs/concepts/signals/metrics/ - 指标信号与观测基础。
• [R9] OpenTelemetry, Semantic Conventions for Generative AI. opentelemetry.io/docs/specs/semconv/gen-ai/ - 生成式 AI 操作的观测字段与语义约定。
• [R10] AWS, Well-Architected Framework: Cost Optimization Pillar. docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/welcome.html - 云资源成本优化原则。
• [R11] Google, Site Reliability Engineering - Handling Overload. sre.google/sre-book/handling-overload/ - 过载、容量与负载保护。
• [R12] PostgreSQL, Explicit Locking. www.postgresql.org/docs/current/explicit-locking.html - 并发控制与锁机制。
• [R13] PostgreSQL, Transaction Isolation. www.postgresql.org/docs/current/transaction-iso.html - 事务隔离与并发异常。
• [R14] FinOps Foundation, FinOps Framework. www.finops.org/framework/ - 云成本可见性、分配与优化的管理框架。
• [R15] Temporal, Documentation. docs.temporal.io/ - 长时间运行工作流、重试和恢复的工程参考。

来源使用说明： R1 - R3 用于说明模型调用成本与速率限制；R4 - R7 用于基础设施容量与配额；R8 - R9 用于计量观测；R10 - R11、R14 用于成本与容量治理原则；R12 - R13 用于预算原子预留的数据库机制；R15 用于持久化工作流背景。文中的 Budget Service、Ledger、示例 API 与 Studio 配额数字属于综合工程设计，并非这些来源直接规定的标准架构。

附录 B：研究证据、验证声明与适用边界

B.1 研究材料类型

本文由四类内容组成：官方技术资料支持的机制说明（例如 Kubernetes 配额、数据库事务、供应商限流）；通用工程原理（例如原子预留、幂等与背压）；本文提出的参考架构（预算服务、计量事件与成本账本）；说明性示例（30 元任务预算、示例接口和 Python 代码）。四类内容的证据强度不同，不应混同。

B.2 已验证与未验证

文中不包含真实供应商账单、生产环境用量统计或可代表市场现价的报价。Python 片段是单进程并发示例，其通过与否以实际执行结果为准；即使通过，也不能证明分布式预算服务的正确性。文中的容量策略、预算阈值、架构拓扑与优化建议尚需在具体系统中实测。

B.3 实施前必须核验的外部条件

应核验当前模型价格、币种和税费、供应商缓存/批处理计费、RPM/TPM/并发限额、工具 API 商业条款、数据存储地区、模型上下文与输出上限、取消调用后的计费语义，以及所选框架版本的接口行为。

B.4 适用范围

本文适用于具备模型调用、工具执行、动态任务分解或多 Agent 协作能力的 Agent System，尤其适用于 SaaS、多租户研究平台、企业内部 Agent 平台和长任务自动化系统。对于单用户、低频、无外部副作用的原型，可从最小计量和任务预算起步，无须立即引入完整的分布式成本账本。

B.5 后续专题衔接

H9 Data Governance 将进一步处理用量记录、运行数据和产物的分类、保留、删除与生命周期；H10 Testing & Validation 将验证预算、容量与质量策略的工程行为；H11 Deployment & Operations 将落实扩容、发布和运维；H12 Policy & Governance 将把预算、配额和审批纳入组织级政策。