ai-agent教程-12-生产部署本章包括:1.服务化与 API 契约设计;2.可观测三支柱与看板建设;3.可靠性与降

本章目标:把 Agent 从「demo」送进「生产」——服务架构、可观测性、可靠性、扩展与并发、成本控制、人机协作、以及 CI/CD 与上线流程。

1. 生产环境的 Agent 有什么不同

Demo 里的 Agent 是「同步跑一次循环,返回结果」。生产的 Agent 要面对:

并发:几十、几百、上千用户同时用;
长耗时:一个 Agent 任务可能跑几十秒甚至几分钟(多轮工具调用);
不稳定:模型可能超时、报错、输出异常;
成本:每次运行都在烧 token;
可观测:出问题要能定位「哪一步错了」;
安全:第 11 章的全部问题;
合规:数据、审计、用户控制。

一个生产 Agent 系统,本质是一个分布式异步工作系统—— Agent 循环是「业务逻辑」,周围是标准后端工程。

2. 服务架构

2.1 同步 vs 异步

维度	同步(请求-响应)	异步(任务队列)
延迟	低(适合快速任务)	中(轮询/回调/WebSocket)
长任务	不适合(连接超时)	适合(几十秒~几分钟)
资源利用	每个请求占住连接	队列削峰
复杂度	低	高(队列+状态+回调)

工程经验:

快速任务(秒级):同步 REST / 流式 SSE,简单直接;
慢速任务(分钟级):异步——请求进来 → 入队 → Agent 在 worker 里跑 → 结果存库 → 客户端轮询/回调/WebSocket 取结果;
流式:SSE / WebSocket 推送中间进度,改善长任务体验。

2.2 推荐架构

                    ┌───────────────────────────────────┐
客户端 ──► 网关 ──► │ API 层(鉴权 / 限流 / 路由 / 护栏)   │
                    └──────────────┬────────────────────┘
                                   │ 任务入队
                    ┌──────────────▼────────────────────┐
                    │ 任务队列(RabbitMQ / Redis / 自建)   │
                    └──────────────┬────────────────────┘
                                   │ worker 消费
                    ┌──────────────▼────────────────────┐
                    │ Worker 池(跑 Agent 循环)           │
                    │   ├─ Agent(工具 / 记忆 / 上下文)    │
                    │   └─ 状态存储(任务进度 / 结果)      │
                    └──────────────┬────────────────────┘
                                   │ 每次模型调用都走这里
                    ┌──────────────▼────────────────────┐
                    │ 统一模型出口(LLM 网关 / Router)     │
                    │   provider 路由 / 限流 / 缓存 /    │
                    │   密钥托管 / 故障切换 / 用量审计     │
                    └──────────────┬────────────────────┘
                                   ▼
                    ┌───────────────────────────────────┐
                    │ 存储(任务表 / 结果 / trace / 审计)  │
                    └───────────────────────────────────┘

统一模型出口(LLM 网关 / Router)是生产架构里常被漏掉、却极重要的一层: 所有 Worker 的模型调用都经过它,集中做——provider 路由(按任务/成本/延迟选 OpenAI/Anthropic/自托管)、统一限流与预算、Prompt Caching、密钥托管(模型密钥不进 Worker 环境)、provider 故障切换(一家 5xx 时自动 failover 到另一家或降级模型)、用量与成本审计。没有它,「模型全挂→兜底」「多 provider 混用」都会散落在每个 Worker 里,无法统一治理。

2.3 状态与持久化

Agent 是有状态的(多轮、记忆)。生产必须:

任务状态表:task_id → status(pending/running/success/failed/interrupted)、进度、结果、错误;
断点续跑:进程重启后,未完成任务能从上次中断点继续(第 06 章 LangGraph 的 checkpoint 是这一需求的框架实现);
记忆持久化:长期记忆进数据库,不随进程消失。

2.4 Agent 的 API 设计:把「一次运行」契约化

Agent 服务的 API 与传统 REST 服务有个本质区别:一次请求不是「查询」, 而是「启动一次可能有副作用的自主运行」。契约设计要围绕这个本质:

// 请求(异步模式)
{
  "task_id": "task_9f3a",
  "user_id": "u_8847",
  "input": "查一下我上个月的订单物流",
  "config": { "model": "claude-sonnet-4-5", "maxIterations": 8 },
  "guardrails": { "requireApproval": ["apply_refund"] }
}

// 响应:立即返回「已受理」
{ "task_id": "task_9f3a", "status": "accepted", "poll_url": "/tasks/task_9f3a" }

// 查询任务状态
{ "task_id": "task_9f3a", "status": "running", "progress": 0.6,
  "current_step": "正在查询订单物流…", "messages": [...] }

// 最终结果
{ "task_id": "task_9f3a", "status": "completed",
  "output": "您的订单已发货…", "stats": { "llmCalls": 3, "toolCalls": 2,
  "totalTokens": 8421, "costUsd": 0.021, "stopReason": "end_turn" } }

契约设计的五个要点:

任务 ID 是唯一入口:所有轮询、取消、审计都挂在 task_id 上;
状态是显式的:pending → running → completed / failed / interrupted / requires_approval,中间态清晰,客户端好渲染;
流式进度是可选增强:SSE / WebSocket 推送中间消息(第 03 章流式);
结果带回成本:stats 里带 token 与成本,客户端与账单可对照;
「requires_approval」是一个合法状态:Agent 撞到审批流时暂停,等待人工放行(§7 人机协作)——不要把「需要人」当成「出错」。

3. 可观测性:三根支柱

3.1 Logging(日志)

每次运行记录:任务 ID、用户、模型、token 用量、耗时、结果、停止原因;
脱敏:不记录敏感内容(第 11 章);
结构化(JSON),便于检索。

3.2 Tracing(链路追踪)

一次 Agent 运行 = 一个 trace,每次模型调用/工具调用 = 一个 span;
第 07 章 mini-agent 的 Tracer 是它的教学原型;生产用 OpenTelemetry / LangSmith / 自建,聚合展示「每步花了多久、烧了多少 token」;
价值:定位瓶颈(哪次工具调用慢)、复现问题(回放轨迹)、评测数据源(第 10 章)。

3.3 Metrics(指标)

业务指标:任务成功率、完成率、平均轮数;
成本指标:每任务 token 消耗、每任务成本、按用户/按工具聚合;
性能指标:端到端延迟 P50/P95/P99、首 token 延迟、工具调用延迟;
可靠性指标:失败率、重试率、超时率、错误类型分布;
模型指标:各模型调用量、失败率、用量。

3.4 一个生产看板长什么样

指标不是拿来「存」的,是拿来「看」的。一个 Agent 生产看板按「能回答什么问题」来组织,比按「指标类别」组织更实用:

┌─ 业务健康 ───────────────────────────────────────────┐
│ 任务成功率 94.2% │ 转人工率 3.1% │ 平均轮数 2.4 │ 完成率 98% │
├─ 成本 ───────────────────────────────────────────────┤
│ 今日成本 $214 │ 每任务平均 $0.031 │ 成本 Top 工具: query_order 41% │
│ 单任务成本超限数: 12(触发降级 8)                       │
├─ 性能 ───────────────────────────────────────────────┤
│ 端到端延迟 P50 4.2s │ P95 11.8s │ 首 token 0.9s │ 工具调用 P95 1.3s │
├─ 可靠性 ─────────────────────────────────────────────┤
│ 模型 429 重试率 2.4% │ 工具失败率 1.1% │ 超时任务 0.2% │
├─ 安全 ───────────────────────────────────────────────┤
│ 输入护栏拦截 37 │ 审批通过/驳回 42/5 │ 注入类回归 100% 通过 │
└──────────────────────────────────────────────────────┘

看板的三个原则:

每个指标都要能回答一个问题(「今天贵不贵?」「哪里变慢了?」), 否则就是噪音;
按时间看趋势,不只按点看数值——「成功率从 95% 掉到 90%」比「成功率 90%」重要得多;
业务、成本、性能、可靠性、安全五个维度同时看——只盯成功率会漏掉「成本翻倍」「注入攻击」这类致命问题。

4. 可靠性工程

4.1 失败模型

Agent 系统的失败点远多于传统服务:

失败点	处理
模型 API 限流(429)	重试 + 退避 + 队列削峰
模型 API 超时	重试 + 超时分级(连接/请求/整体)
模型输出异常	结构化输出解析兜底
工具失败	回喂模型自愈(第 03 章)
工具超时/挂死	每工具超时 + 强杀
循环失控	迭代上限 + token 上限 + 耗时上限
进程崩溃	任务状态 + 断点续跑
队列积压	弹性扩容 + 告警

4.2 超时与重试

模型调用:配置连接超时 + 请求超时 + 整体超时;瞬时错误(429/5xx/网络) 重试 2–3 次,指数退避 + 抖动;
工具调用:每个工具单独超时,避免一个慢工具拖死整个循环;
整任务:给任务设「最长运行时间」,超时强制终止并返回「超时,已部分完成」。对用户诚实,比无限等待好。

4.3 降级与兜底

模型全挂 → 返回友好错误 + 告知「稍后再试」;
多 Agent 失败 → 降级到单 Agent(第 08 章);
工具不可用 → 告诉用户「该功能暂不可用」;
始终要有「无模型可用」的兜底路径(缓存常见答案 / 转人工)。

4.4 限流算法:从「简单计数」到「公平配额」

Agent 服务要防「单用户打爆预算」与「突发流量压垮上游」,限流是必须的。常见算法与取舍:

算法	原理	优点	缺点	适用
固定窗口	每窗口(如 1min)计数,超限拒绝	简单	窗口边界突发(59s 与 61s 各打满)	粗粒度
滑动窗口	按请求时间滑动统计	平滑,边界无毛刺	需存请求时间戳,略复杂	通用默认
令牌桶	匀速补令牌,突发可消费存量	允许短期突发 + 长期限速	参数(桶深/补速)需调	API 网关标配
漏桶	固定速率出水,多余排队/丢弃	输出速率绝对平滑	无法应对突发	下游脆弱时

Agent 场景的两个特殊点:

限流单位不只看「请求数」,还要看「token」。一个 Agent 任务的 token 消耗是请求数的几十倍。按「每用户每窗口 token 预算」限流,比按请求数更贴合成本治理(§6);
Agent 任务的「审批流」不能限流误伤。requires_approval 状态的任务等待人工审批,可能挂很久——限流器要区分「活跃请求」与「挂起审批」, 否则会把正在等人审批的任务当成「卡住」误杀。

工程建议:入口用「令牌桶(按请求)+ 每用户 token 配额(按成本)」双层限流;配额超限返回 429 + 明确提示「额度用尽,请明日再试」,而不是静默降级。

5. 扩展与并发

5.1 横向扩展

Worker 是无状态的(状态在存储层),因此可以横向扩展:

多个 worker 副本消费同一队列;
按模型 API 配额合理分配;
峰值时弹性扩容(云上 auto-scaling)。

5.2 并发与限流

入口限流:每用户/每 API Key 的请求速率限制;
成本护栏:每用户每日/每任务预算上限(第 11 章「过度代理」缓解);
模型配额:监控每家模型 API 的用量与限额,避免打爆;
背压:队列积压时,拒绝新请求或提示「高峰期请稍候」。

5.3 状态隔离

多用户共享 Agent 时,必须隔离(第 11 章):

记忆、上下文、会话按用户隔离;
工具凭证按用户/租户隔离;
数据访问按角色授权。

5.4 容量规划与压测:规模不是「够用」,是可算的

「能跑」与「能扛」之间,隔着一个容量模型。估算口径:

单任务模型调用次数 m(来自评测集统计,第 10 章)
每任务平均 token t(来自线上/评测统计)
每 worker 吞吐 ≈ 并发 worker 数 × (60s / 单任务平均时长)
队列积压率 = 到达率 λ - 处理率 μ;λ > μ 则队列无限增长(背压失控)

步骤:

算清单任务成本画像:m、t、平均时长、工具调用数——从评测与线上 trace 统计 (第 10 章、第 12 章 §3 可观测性);
按目标 QPS 反推 worker 数:worker 数 ≥ QPS × 单任务时长。例:QPS=5、单任务平均 8s → worker ≥ 40;
留峰值余量:峰值通常是均值 3–10 倍,用 auto-scaling 弹性应对;
压测:用负载工具(Grafana k6、Locust)灌流量,观察——队列积压、 worker CPU/内存、模型 API 限流、P95/P99 延迟。目标不是「不崩」, 而是「明确知道在什么负载下崩、以什么方式崩(拒绝新任务 vs 任务超时)」;
积压可视化:看板必须有「队列深度 + 积压时长」两个指标(§3.4), 否则负载上来你只能等用户投诉。

5.5 多区域、高可用与灾难恢复

Agent 服务一样要回答「机房挂了怎么办」:

手段	说明
多区域部署	主备或多活;DNS/负载均衡层切流量(§5.1)
任务级幂等	队列消费要幂等:同一 task 被两个 worker 同时消费不产生副作用(§2.4 的 task_id 是幂等键)
状态可恢复	任务状态表 + 断点续跑(§2.3),worker 崩溃后任务能从 checkpoint 继续
备份与恢复	记忆库 / 任务表定期备份,演练恢复流程,别等事故当天才第一次试
可用性目标	明确写 SLO(如 99.9%),并让看板能对账——「目标」不写下来就不是承诺

合规附加题:数据驻留(region 选择)、数据跨境、审计留存周期——这些是「部署合规」而非「功能问题」,往往由安全/法务部门(第 11 章 §4)在架构评审时提出,越早对齐越便宜。

6. 成本工程

Agent 的成本 = token 成本 + 基础设施成本。token 是大头,控制 token 是核心:

6.1 控制 token 的技巧

这一节是「上下文工程」(第 05 章)在生产成本侧的落地。预算分配、 Prompt Caching、动态工具子集的完整方法论见第 05 章;这里只列清单。

上下文裁剪(第 04 章):不相关的历史别进 prompt;
工具描述精简:每个工具在 tools 清单里都占 token,工具越多越贵; 只给本轮可能用到的工具(动态工具子集,第 05 章 §5);
避免重复上下文:记忆里的信息别重复注入;
模型分级:简单步骤用小模型,复杂决策用大模型 (第 06 章 OpenAI SDK 的「模型路由」就是干这个);
Prompt Caching(第 05 章 §4):稳定前缀放前、动态内容放后, 多轮 Agent 的输入成本可降数倍——这是比换模型更划算的成本杠杆;
反思按需(第 02 章):高价值任务才反思,别一律双轮。

6.2 成本可观测

每个任务记录 token 与成本;
按用户/按工具/按模型聚合成本报表;
设置成本告警(某工具成本异常飙升);
成本/成功率预算:上线前定好「单任务成本上限」,超出自动降级。

6.3 成本的公式化:先把账算清,再谈优化

Agent 成本不是「感觉贵」,而是可以公式化的。把变量列出来,优化点自然浮现:

单任务成本 C = Σ(每轮输入 tokens × 输入单价 + 每轮输出 tokens × 输出单价)
             + Σ(工具执行次数 × 工具平均成本)

令:
  n      = 模型调用轮数
  P_in   = 每轮输入 tokens(系统提示 + 工具定义 + 历史 + 记忆)
  P_out  = 每轮输出 tokens(思考 + 工具调用 + 最终答案)
  r_in   = 输入单价(缓存命中可低至 0.1×–0.5×,具体看厂商计价,见第 05 章 §4.2)
  r_out  = 输出单价(随模型而异,前沿模型常为输入的 5–10 倍;请以官方计价表取值)

则:  C ≈ n × (P_in × r_in + P_out × r_out) + 工具成本

从这个公式能直接读出优化杠杆(按性价比排序):

杠杆	作用公式的哪个变量	手段	量级
Prompt Caching	把 P_in 的重复部分单价降到 0.1×–0.5×(以计价为准)	稳定前缀在前(第 05 章 §4)	最大单一杠杆
减少轮数 n	直接乘性降低	更好的工具/提示词,别让模型反复试错	大
动态工具子集	缩小 P_in(工具定义)	只发本轮需要的工具(第 05 章 §5)	大
模型分级	r_in / r_out 降数倍	简单步骤用小模型,复杂决策用大模型	大
上下文裁剪	缩小 P_in(历史)	不相关的历史别进 prompt	中
输出截断	缩小 P_out	maxTokens 收紧;工具参数精简	中

两个容易算错的点:

输出 token 的单价远高于输入——很多团队只优化 P_in,却忽略了「模型反复输出冗长思考」占的成本;maxTokens 和提示词「回答要简洁」同样重要;
成本方差要按 P95 看,不只按均值。自主 Agent 的 token 消耗方差大, 均值正常但 P95 超预算,照样亏钱。预算上限要用 P95 设计。

公式化的价值:把「怎么省成本」从「感觉」变成「改哪个变量」。每次优化前先更新公式,估算省多少,再用第 10 章的评测验证质量没掉。

6.4 一个完整的工作示例:把公式用起来

空谈公式没有感觉,来算一笔真实的账。假设一个客服 Agent,窗口 32k, 输入单价 r_in = $0.5/M、输出单价 r_out = $1.5/M(约 3 倍),缓存命中单价 r_cache = $0.1/M(取 5 倍折扣作示例,真实倍率以厂商计价为准,见第 05 章 §4.2)。优化前的单任务成本:

参数:
  n = 4 轮(首轮 + 3 次工具回环)
  P_in  = 18k tokens/轮(系统提示 2k + 工具定义 8k + 历史 5k + 记忆 3k)
  P_out = 400 tokens/轮

优化前(无缓存、全量工具):
  C = 4 × (18k × $0.5/M + 400 × $1.5/M)
    = 4 × ($0.009 + $0.0006)
    = 4 × $0.0096
    ≈ $0.0384 / 任务

现在按「性价比排序」逐个优化,每一步都看它对公式里哪个变量做了什么:

步骤	手段	对公式的影响	新成本
①	Prompt Caching:稳定前缀(system + 工具定义)命中缓存	10k/轮从 `r_in` 变 `r_cache`	每轮 = 10k× $0.1 + 8k×$ 0.5 + 0.4k× $1.5 ≈$ 0.0056;单任务 ≈ $0.022
②	动态工具子集:只发 3 个相关工具	P_in 从 18k → 10k	每轮 ≈ 10k× $0.5 + 0.4k×$ 1.5 ≈ $0.0056;单任务 ≈$ 0.022
③	减少轮数 n:更好的工具描述让 3 次工具回环变 2 次	n 从 4 → 3	单任务 ≈ 3 × $0.0056 ≈$ 0.017
④	模型分级:简单的「查单/查物流」用小模型(`r_in=$0.15/M, r_out=$0.6/M`)	r_in / r_out 降 3 倍	每轮 ≈ 10k× $0.15 + 0.4k×$ 0.6 ≈ $0.0017;单任务 ≈$ 0.005
⑤	上下文裁剪:去掉不相关历史	P_in 从 10k → 6k	单任务 ≈ 3 × (6k× $0.15 + 0.4k×$ 0.6) ≈ $0.0035

结果:单任务成本从 $0.0384 →$ 0.0035,下降约 11 倍,而正确率(用第 10 章评测集跟踪)没有下降——这就是「公式化 + 评测」双轮驱动的收益。

关于上表「累计 vs 独立」的语义:每一步优化是独立评估,不是简单累加。最典型的例子是步骤①(缓存)与步骤②(动态工具子集):②改变了工具清单, 也就改变了稳定前缀,①的缓存收益会随之失效——所以②按全价 $0.5 计算而不是沿用①的 $0.1。真实系统里「缓存收益只在稳定前缀不变时成立」, 任何改变前缀的优化(换模型、改工具集、动 system 提示)都会让缓存命中率重新爬坡。顺序地逐个验证(而非叠加),才是对成本的诚实估算。

两个从例子里能直接读出的经验:

优化顺序很重要:缓存(①)是「最大单一杠杆」,但④(模型分级)的乘性效果更惊人——因为它同时压低输入与输出单价,还常伴随更小的上下文需求;
算完之后必须用评测验证:每一步优化都在改变上下文布局与模型选择, 「省了 11 倍成本」的前提是「质量没掉」——这个假设只有评测能证明 (第 10 章)。成本公式负责「算账」,评测负责「验货」,两者缺一不可。

7. 人机协作(Human-in-the-Loop)

生产 Agent 不是全自动的——「关键动作要人确认」是安全与信任的基石 (第 11 章 OWASP LLM06 过度代理 / LLM09 错误信息)。

7.1 介入点

介入点	场景	实现
工具确认	转账、删除、外发	调用前暂停,等审批
任务确认	高风险/高成本任务	执行前展示计划,人确认
中途接管	Agent 卡住/方向偏	中断,人工修正后继续
结果审核	对外输出内容	发布前人工审阅

7.2 实现模式

审批队列:Agent 请求审批 → 人工在后台审批 → 通过则继续;
暂停/恢复:Agent 执行到 checkpoint 暂停,等待输入(第 06 章 LangGraph 的 interrupt);
人工可编辑状态:人可以直接修改 Agent 的状态(计划、消息), 然后恢复执行。

产品设计要点:人机协作的界面要「看得懂 Agent 在干什么」—— 把计划、轨迹、工具调用渲染成可读的进度,而不是黑盒。这是信任的工程化。

8. CI/CD 与上线流程

8.1 质量门禁(Quality Gates)

Agent 上线的门槛必须比传统软件更严(因为不确定性):

CI 门禁:
  1. 代码测试(单测/集成)        通过
  2. 类型检查 + lint              通过
  3. 最小回归集评测(第 10 章)     通过
  4. 安全扫描(依赖 / 提示注入用例) 通过
  5. 成本预算检查(改动是否显著增本)通过

8.2 发布策略

金丝雀发布:新版本只放给 5% 流量,在线评测对比(第 10 章);
A/B 实验:改 system prompt / 工具 / 模型,用在线指标决定去留;
回滚:配置化(提示词、模型、工具集)而非硬编码,支持一键回滚;
灰度监控:发布期间盯住成功率 / 延迟 / 成本 / 用户反馈。

8.3 配置管理

把「会变的东西」从代码里抽出来:

agent:
  model: claude-sonnet-4-5
  temperature: 0.2
  maxIterations: 8
  systemPrompt: "…"          # 提示词也要版本化
  tools: [calculator, query_order, send_email]
  guardrails:
    toolApproval: [send_email]
    budgetPerTask: 0.05

提示词、模型、工具集、护栏配置全部版本化 + 可回滚 + 可 A/B。

9. 上线检查清单

10. 对照 mini-agent

mini-agent 是「单进程教学版」,但它为生产留好了所有「升级点」:

生产需求	mini-agent 现状	生产升级
并发	单实例串行	无状态 worker + 队列
状态持久化	内存 MemoryManager	数据库 + 向量库
超时重试	`signal` 支持中断	RetryProvider + 工具超时包装
可观测	`Tracer`(console)	OpenTelemetry / LangSmith
评测	tests(54 用例)	领域评测集 + LLM Judge + CI
护栏	`ToolRegistry` 参数校验	三层护栏 + 审批流
配置	构造参数	配置化 + 版本化

核心洞察:mini-agent 的分层(接口 + 门面 + 依赖注入)让「从教学到生产」的升级都发生在边界,核心循环不变。这正是工程化的复利。

11. 生产反馈闭环:让线上数据回流成评测集

第 10 章的评测集是「静态的」:上线那一刻它是最新知识,可线上 Agent 每天都会遇到评测集没覆盖的新情况——新话术、新边界、新失败模式。静态评测集会过期: 本周通过率 98%,不代表它覆盖了上周线上新增的 5 种失败。

闭环流程

线上 trace / 用户反馈 / 转人工日志
        │
        ▼
采样标注(失败全采 / 成功抽样)
        │
        ▼
新评测用例(入库,带来源标记)
        │
        ▼
合并进回归集(版本化)
        │
        ▼
CI 门禁(发布必须过)
        │
        ▼
下一个版本(回到线上,产生新 trace)

线上信号源

哪些「线上痕迹」值得回流成用例?

信号	含义	采集难度
用户点赞 / 点踩	直接的用户态度	低
转人工率	Agent 兜不住才转人,是强信号	低
用户修正(重发消息)	用户对结果不满意,重发一次	中
task 失败率	任务级失败(第 12 章 §8.2 的回滚触发项)	低
tool 错误率	工具调用持续报错(第 03 章工具层)	中
trace 里的异常轨迹	卡循环、超轮数、空输出	高(需分析)

要点:信号越「直接」越优先——点踩比 task 失败率更接近真相,但量少; 失败率量足、噪声多。两者都进闭环,一个管「准」,一个管「全」。

采样与标注策略

失败样本全采:失败(点踩 / 转人工 / 任务失败)是「金子」,一条都不该丢;
成功样本按比例采样:避免评测集被同质化成功样本淹没,建议 ≤5% 或按类分层;
先粗筛再精标:先用规则或 LLM 粗筛出「明显误答」(第 10 章 §5 LLM-as-Judge 同思路),人工只精标边界样本——标注成本大幅下降。

与第 10 章在线评测打通

这不仅是「离线补数据」。第 10 章 §3 的在线评测(灰度期 A/B 的指标对比) 本身就是反馈闭环的一环:灰度期间把「新版本 vs 旧版本」的失败样本对挑出来, 差异样本直接进下一轮回归集。在线评测负责「发现问题」,反馈闭环负责「把问题变成用例」,两者循环迭代。

落地点:发布门禁

一个可执行的门禁定义:

每次发布 = 先跑全量回归集 + 附带上周新增的线上回流用例。 新增用例全部通过(或明确豁免),才算过门禁。

配合第 12 章 §8.3 的配置化发布:回流用例进了回归集,下周的发布就会被「逼着」回应上周的线上教训——评测集从「快照」变成「活的记忆」。

12. 本节要点

生产 Agent = 分布式异步工作系统,Agent 循环只是业务逻辑;
同步/异步分流:快速任务同步,慢速任务队列 + worker + 状态存储;
可观测三支柱:日志 / trace / metrics,缺一不可;
失败点很多,每个都要有超时 + 重试 + 降级;
横向扩展的前提是状态在存储层,worker 无状态;
成本控制:上下文裁剪、动态工具子集、模型分级、缓存;
Agent API 契约化:task_id 是唯一入口,状态显式化, requires_approval 是合法状态而非错误;
监控看板按「能回答什么问题」组织:业务/成本/性能/可靠性/安全五维, 重趋势不重单点;
人机协作是信任的基石,审批队列 + 暂停/恢复 + 可读进度;
CI/CD 要加评测门禁,发布要金丝雀 + 一键回滚;
提示词/模型/工具集/护栏全部配置化 + 版本化;
上线清单把第 09/10 章的能力接进流程;
限流要「请求数 + token 配额」双层,且不能误伤挂起的审批任务; 令牌桶是网关标配;
成本公式化 C ≈ n×(P_in·r_in + P_out·r_out) + 工具成本—— 每个优化杠杆对应一个公式变量;输出 token 单价更高,成本方差看 P95。

下一章,把镜头拉到最远——现状与未来方向。