D6 · Agent 架构、评测与成本
本日安排：8 小时净学习。休息另计，算法可独立安排。
- 2.5 小时：AG24–AG28，评测、观测与性能。
- 2.5 小时：案例 B，售后 Agent 设计。
- 1 小时：编写 12 条结果断言。
- 1 小时：模型配额和容量手算。
- 1 小时：模拟与纠错。
Agent 的成功条件与评测集
Section titled “Agent 的成功条件与评测集”Agent 给出“处理完成”只是一次文本输出。若目标是退款，成功条件应该落在可信的业务状态：退款操作属于当前租户和订单，金额、币种与获批提案一致，操作处于支付系统确认成功的终态，额度预留与账本记录也相符。若用户不符合退款条件，Agent 正确拒绝、说明依据或转交人工，同样可以算任务成功。把正确拒绝当失败，会驱使系统为了提升通过率而过度执行。
评测题至少包含输入、初始状态、工具/政策版本、故障条件、期望结果和断言。退款成功看业务记录；不能跨租户访问看授权边界；答复是否清楚、引用是否支持结论，可以由经过校准的模型评分器或人工评价。一个任务可以由多个评分器分别检查结果、动作和语言。若测试夹具损坏、运行器超时或断言程序报错，应记为 invalid，单独报出，不混成系统成功或失败。2
评测样本可按正常办理、正确拒绝、信息不足、越权请求、提示注入、政策版本冲突、工具错误、取消、事实变化和未知支付结果分层。分层数字比一个总分更能说明问题：总体 98% 可能掩盖“超时后重复退款”。测试集要记录版本，修复一个失败案例后可放入回归集；另留不参与调参的测试集，减少对同一批题反复调试造成的过拟合。不要用模型生成的答案替代权威预期，也不要让被测 Agent 自行改写评分条件。OpenAI 建议按任务定义指标、持续扩展数据，并用人工判断校准自动评分器。1
模型评分器、pass@k 与 pass^k
Section titled “模型评分器、pass@k 与 pass^k”LLM-as-judge 适合给自由文本按清楚的量表打分，例如解释是否引用了正确政策、是否准确说明仍待审批。它不适合单独证明钱是否已到账、操作是否属于正确租户。对后者，用程序读取账本、退款服务或授权记录。模型评分器会受答案先后顺序、长度和措辞影响；写 rubric 时给出正反例，盲化候选顺序并交换顺序复评，在人工标注集上检查一致性，再持续抽查分歧。1
若一次任务独立试验的成功概率为 p，pass@k 的简化概率是至少一次成功，即 1-(1-p)^k；pass^k 则是 k 次全都成功，即 p^k。例如 p=0.8、k=3 时，前者是 0.992，后者是 0.512。两种指标回答的问题不同：多次采样里能不能找出一次可用方案，与连续使用是否稳定。公式依赖同分布、独立、成功概率固定的假设。真实 agent 重试可能受相同外部故障、缓存或上下文影响，试验也可能不是独立样本；应报告实际观测和定义，不能把公式当成真实线上概率。生产一次请求若只允许一次执行，pass@10 不能替代 pass@1。
评测时还要问“单位是什么”：按任务平均还是按每次 trial 平均？是否重试？哪些拒绝算成功？是否先在多次结果中挑最好的？这些选择都改变分数含义。应保留每次 trial 的结果和轨迹，报告样本量及失败类型，不只展示挑出来的成功案例。
Trace 与审计记录
Section titled “Trace 与审计记录”给一次业务 run 一个关联标识，把它与步骤、模型调用、检索、工具调用、审批事件和业务操作关联起来。每个事件至少能回答：何时发生、哪个版本、用了多少时间、以什么结果结束、是否重试以及错误类别。退款类写操作还要记录稳定的业务操作 ID。模型调用、工具访问和人工等待应拆开计时，否则一条总耗时无法指出瓶颈。
排查从最早偏离预期的事件开始。例如用户要求查询政策并建议处理，trace 显示检索器漏掉现行政策，后面模型再会解释也无法补回证据；如果工具返回“已受理”而非“退款成功”，问题可能出在最终状态转换或回答措辞。记录可以包含受控保存的请求片段或摘要、证据文档版本、工具参数和返回码，但要分级脱敏、设定访问和留存期限。不要默认把个人信息、支付数据或密钥写进所有日志。
工程 trace 记录可观察动作、输入输出、证据、耗时和版本即可，不要求隐藏思维链，也不要把模型自述的理由当业务审计证据。审计记录回答谁批准了什么、系统执行了什么、业务系统确认了什么；调试 trace 则可以采样、限期保存，二者用途不同。OpenTelemetry 的 GenAI span 规范也提示输入输出内容可能大且敏感，应谨慎配置采集。4
延迟、成本、缓存与容量
Section titled “延迟、成本、缓存与容量”先拆关键路径：排队、模型 prefill、模型 decode、串行工具等待、审批等待和重试。TTFT（首个 token 时间）衡量首次输出延迟。测量时应写明起点，以及首 token 指模型流首次输出还是用户首次可见文本；二者可能因工具调用或缓冲而不同。它不代表任务已经完成。用户看到“退款正在处理”很快，也不等于支付操作很快。报告端到端完成时延和业务完成时延，并给 p50/p95 等分位数。不能把各阶段的 p95 简单相加当作端到端 p95，因为分位数的发生样本不一定相同，阶段之间还可能相关；总时延应在同一批请求上直接测量。
按成功任务核算费用：该批总成本 ÷ 经后置状态验证成功的任务数。失败尝试、重试和被人工接管任务的费用仍在分子里。若100个请求花费30个记账单位、80个完成，则是 30/80=0.375 单位/成功任务；若一个成功都没有，报告“无成功样本/无法计算”，不能说每成功成本为零。成本还应分开标注模型调用、工具、存储以及人工处理，不把只算 token 的数字描述成总成本。
KV cache 是活跃生成请求中的注意力状态；prefix/prompt cache 在符合条件时复用相同前缀已处理的状态；response cache 保存已完成的答案。它们不是同一种东西。前缀缓存只减少重复处理的共同输入部分，新输入仍要处理，模型也仍需生成新的输出；它不会绕过工具、审批或对订单状态的验证。3 业务响应缓存还必须把租户、权限、数据版本和时效纳入键与失效策略，不能用昨天的退款状态回答今天的查询。
容量例子是教学假设，不是实测：2 run/s，每个 run 3 次模型调用，每次输入 3000、输出 300 token。模型调用为 2×3=6次/秒=360次/分钟；输入为 6×3000×60=1,080,000 token/分钟；输出为 6×300×60=108,000 token/分钟。若活动 run 平均停留 30 秒，按 Little 定律估算平均在途数 2×30=60。这不是 60 个 worker 或数据库连接的采购结论，也不推导 p95；真实容量要测峰值、重试、调用并行度、外部服务限额及人工等待。API 免去部分推理基础设施运维，但受配额、数据处理边界和供应商变更影响；自部署增加版本、GPU、批处理、KV 内存、可用性和容量管理责任。选择依据应是相同任务集上的质量、成功成本、时延和数据要求，而非抽象地说大模型更好或自部署一定便宜。
售后 Agent 的系统设计
Section titled “售后 Agent 的系统设计”题目：为商家设计一个 Agent，查看最近七天待处理售后，给出政策建议；退款必须由员工确认。先说明假设：登录身份和店铺权限由服务端提供；模型可以读订单和政策、生成提案，但不拥有最终退款权限；审批可晚于 HTTP 请求结束。然后画 API、持久任务/worker、模型、受限工具网关、业务订单/退款服务、审批服务、数据库与 trace/eval 的边界。首版可以单体服务加队列，不必把每个盒子拆成微服务。
任务状态、模型上下文、工具调用记录和退款业务状态分别管理。run_id 是工作流任务，tool_call_id 是模型协议中的调用关联，operation_id 是一次退款业务意图。它们不能互相代替。模型可调用只读查询、政策搜索和创建提案；执行退款由后端在验证审批记录、提案版本、金额、币种、租户和时效后调用。批准应绑定确切提案内容或摘要；审批后若金额、订单状态或政策版本变化，应重新验证，必要时重新审批。
一个正常路径是：认证确认店铺范围→分页查售后→按权限检索政策→检查订单事实→生成带证据的提案→保存待审批→员工确认具体动作→业务服务执行→查询权威退款状态→检查后置条件→更新任务并答复。若资格不足，Agent 解释拒绝或补问；没有证据时不得编造政策。若模型误称“已退款”，实际状态检查应将 run 标为未完成或核查中，而不是让文本成为事实来源。
退款任务的成功判定，最可靠的依据是什么？
- A. 最终回答含有“已退款”
- B. 模型评分器给出高分
- C. 退款业务记录和目标状态符合订单、金额及租户约束
- D. 工具调用返回 HTTP 200
答案与解析
正确答案：C。要验证权威业务后置状态。A 只检查文本；B 可评价解释但不能证明副作用发生；D 可能只说明请求被受理，且未必表示最终退款成功。
哪项是 LLM-as-judge 的合理用途？
- A. 证明支付服务已完成退款
- B. 根据明确 rubric 评价答复解释是否清楚，并用人工样本校准
- C. 代替租户授权检查
- D. 直接批准模型生成的退款提案
答案与解析
正确答案：B。语言和语义质量可用模型辅助判断，但要校准。A 需要业务状态；C、D 都把安全权限交给评分器或模型，越过了服务端授权。
在每次成功概率 p 固定且 trial 相互独立的简化假设下，pass^k 表示什么？
- A. k 次中至少成功一次，概率为 1-(1-p)^k
- B. k 次都成功，概率为 p^k
- C. k 次都失败，概率为 p^k
- D. 首次成功概率，无论 k 取何值
答案与解析
正确答案：B。A 是 pass@k。C 的全失败概率应为 (1-p)^k。D 与 k 无关，是 pass@1。公式须注明独立同分布假设。
关于 prefix cache，哪项最准确？
- A. 命中后不必生成新的输出 token
- B. 命中就可直接重用上一次退款答案
- C. 匹配前缀可复用部分输入处理状态，但新输入和输出生成仍需处理
- D. 等同于活跃请求的 KV cache
答案与解析
正确答案：C。缓存能减少重复前缀计算，不替代新输入处理与生成。A 错在将输入计算误当输出生成；B 混淆计算缓存与业务响应缓存；D 混淆跨请求的前缀复用和活跃请求状态。
哪项 trace 做法更合适？
- A. 无期限保存所有 prompt、支付字段和凭据
- B. 只存最终聊天文本
- C. 关联模型、检索、工具、审批和业务操作事件，按敏感级别限制内容与留存
- D. 依赖模型生成的完整思维链作为审计日志
答案与解析
正确答案：C。它支持沿事件定位问题并控制敏感信息。A 有隐私和安全风险；B 缺少诊断信息；D 不是可靠的可观察事实，也不需要私有思维链。
100 个任务的总成本为 30 个单位，其中 80 个后置状态验证成功。每成功任务成本是多少？
- A. 0.30
- B. 0.375
- C. 2.67
- D. 3.75
答案与解析
正确答案：B，30/80=0.375。A 用全部任务数作分母；C、D 把分子分母方向或小数位置算错。失败任务成本仍应留在总成本里。
设计一个退款 Agent 的最小评测集，并说明怎样分别判定正常完成与正确拒绝。
参考答案与评分点
**参考答案：**固定初始订单、政策版本、租户和工具状态，覆盖可退款成功、不可退款、信息不足、越权、工具超时/未知结果、恶意检索内容、取消和审批后事实改变。每例保存输入、预置状态、故障计划、版本、期望后置状态及禁止动作。正常完成由退款记录、金额/币种、订单归属、批准版本和最终状态断言；正确拒绝要求不产生退款副作用，并且拒绝原因有证据或进入人工。报告各层指标、无效样本和样本数。模型 judge 只评价解释等开放文本，不决定钱是否已退。
评分（每项 1 分）：
- 写明输入、环境/版本与预置状态。
- 覆盖正常和故障/安全类别，而非仅 happy path。
- 以业务状态验证成功，区分正确拒绝且检查无副作用。
- 分离确定性断言、模型评分及
invalid测试结果。
Agent 回答“退款已完成”，但客服反馈顾客未收到退款。说明你要查看什么 trace，并如何区分执行失败与虚报成功。
参考答案与评分点
**参考答案：**以 run_id 找到关联订单、提案、审批和 operation_id，沿时间顺序检查模型版本、政策证据、工具参数/返回、支付查询状态、重试和最终答复。先核对支付服务的权威状态；accepted/pending 不等于退款完成。若没有合法的既有退款，也没有写调用，却声称退款完成，属于虚报；有调用但结果未知，则标 UNKNOWN 并按原业务身份查询，不重复创建退款；明确失败按契约处理；支付已成功而本地未更新，则补做对账/状态推进。日志中敏感原文应受控访问，不能以模型自述替代交易记录。
评分（每项 1 分）：
- 正确关联 run、tool call 与 operation/business ID。
- 检查业务端最终状态，区分受理、成功、失败、未知。
- 对未知状态用原身份查询，不盲目重发副作用。
- 能从最早异常步骤定位，并说明日志隐私边界。
解释 pass@k 与 pass^k 的区别，并指出用它们评估线上售后系统时的限制。
参考答案与评分点
**参考答案：**pass@k 衡量 k 次试验至少一次成功；pass^k 要求 k 次都成功。若 trial 独立同分布且成功率为 p，对应概率分别为 1-(1-p)^k 和 p^k。它们描述能力与一致性的不同问题。真实重复尝试可能相关，也可能包含外部状态变化；生产通常不是多次采样后挑最好，因此必须声明重试/选样规则，报告 pass@1、实际 trial 分布和分层结果，不能把 pass@10 当作用户一次请求的可靠性。
评分（每项 1 分）：
- 正确定义“至少一次”与“全部成功”。
- 给出正确公式并声明独立同分布条件。
- 说明线上样本可能相关或环境变化。
- 指出采样挑选不能代表单次生产结果。
按教学假设计算模型调用量、输入输出 token 量和平均在途 run，并说明不能从结果推出什么。假设 2 run/s，每个 run 调 3 次模型，每次输入 3000 token、输出 300 token，活动停留平均 30 秒。
参考答案与评分点
**参考答案：**调用率 2×3=6次/秒=360次/分钟。输入 6×3000×60=1,080,000 token/分钟；输出 6×300×60=108,000 token/分钟。平均在途活动 run 2×30=60。这是稳定平均假设下的教学估算，不包含重试或人工审批等待；不能推断需 60 个 worker/连接，也不能推出 p95、实际峰值或某供应商配额。
评分（每项 1 分）：
- 算出 6 次/秒或 360 次/分钟。
- 输入量 1,080,000 token/分钟正确。
- 输出量 108,000 token/分钟与平均在途 60 正确。
- 标记教学假设，并指出平均在途数不等于 worker/连接数或 p95。
- 2：任务、trial、评分器、环境结果和多次试验。
- 1：任务型数据、人工校准模型评分及持续评测。
- 3：前缀匹配、缓存指标与限制。
- 4：模型/检索/工具跨度与内容采集注意事项。
- Stripe：Idempotent requests：特定支付 API 对幂等键的语义示例；实际系统要查自身供应商契约。
Sources
Section titled “Sources”1 https://developers.openai.com/api/docs/guides/evaluation-best-practices — Evaluation best practices | OpenAI API 2 https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents — Demystifying evals for AI agents | Anthropic 3 https://developers.openai.com/api/docs/guides/prompt-caching — Prompt caching | OpenAI API 4 https://github.com/open-telemetry/semantic-conventions-genai/blob/main/docs/gen-ai/gen-ai-spans.md — GenAI spans semantic conventions | OpenTelemetry
下面保留原报告的题目和口述参考答案。先自行作答，再展开查看。
AG24｜怎么评估 Agent，而不是只看几个成功 Demo？〔P0〕
口述答案
先定义环境中的成功条件，再建立覆盖常见、困难和对抗场景的固定任务集。退款成功必须由最终账本和支付状态判定；不该退款时正确拒绝也是成功。把业务结果、违规副作用、人工介入、时延和成本分开报告。
测试分三层：工具契约与权限单测；用模拟工具结果覆盖控制流和故障的集成测试；在可重置环境中做真实模型端到端测试。评测固定输入、初始数据、工具/schema/提示版本，保存失败轨迹。测试夹具和评分规则由程序或可信标注控制，不能让被测 Agent 改答案。
追问怎么接
“工具路径必须和标准答案一致吗？”不一定，合法路径可以不同。对必须先审批、不得访问别的租户等安全约束检查轨迹，对目标完成看最终状态。“怎么上线？”先离线回归，再只读/影子验证，最后小范围放开；影子模式不能实际执行写工具。
不要这样答：“模型说退款成功，所以测试通过”，或只展示挑选后的成功案例。
依据与延伸：Agent-Evals、Eval-Practice。
AG25｜LLM-as-judge、pass@k、pass^k 有哪些坑？〔P1〕
口述答案
LLM judge 适合语言质量、复杂语义支持等难以写规则的维度，但可能受位置、长度、表达风格影响。先写具体 rubric，用人工标注小集校准，做盲评/顺序交换，并与确定性结果检查结合；不得让 judge 单独判定是否发生了真实退款。
pass@k 关注多次尝试中至少一次成功；pass^k 关注多次尝试都成功。前者反映“有机会解出”，后者更接近重复可靠性。生产通常只有一次机会，不能用允许多次挑最佳结果的指标冒充单次成功率。
追问怎么接
“可以直接用 p^k 吗？”只有将每次试验当作同分布、独立且成功概率为 p 的简化模型时，连续 k 次成功才是 p^k；真实重试可能相关，应实测并说明聚合方式。“评了几十题没越权，安全了吗？”只能说该测试集未发现，不能推出低概率风险为零。
不要这样答：“同一个强模型当 judge 就客观”“pass@10 很高说明线上很可靠”。
依据与延伸：Agent-Evals、Eval-Practice。
AG26｜Agent 需要记录什么？如何排查一次失败？〔P0〕
口述答案
以 run_id 关联模型调用、检索、工具、审批和业务操作，每一步记录开始/结束、版本、输入输出摘要或受控存储引用、token、错误分类、重试次数和 operation_id。指标区分模型耗时、工具耗时、排队、人工等待；业务审计记录批准和执行凭据，不与可采样的调试 trace 混为一谈。
排障按“最早出现偏差的步骤”定位：意图识别错误、未检索到证据、证据解释错误、错误工具/参数、权限拒绝、执行失败、最终答复歪曲结果。不要只看最后一条聊天消息。
追问怎么接
“全部原始提示和结果都记录吗？”不默认，可能包含个人信息、密钥和商家数据；分级脱敏、访问控制、保留期限，必要内容放受控存储。“能完全复现吗？”工具与数据快照可以重放，真实模型输出未必逐 token 一致；固定版本并记录可获得的上下文，不依赖私有思维链。
不要这样答：“有日志就是可观测性”，或“为了 debug 把所有 token 和用户资料无限期留存”。
AG27｜Agent 慢、贵，按什么顺序优化？〔P0〕
口述答案
先拆解端到端关键路径：排队、模型 prefill/decode、串行轮次、工具等待、重试和审批。优先去掉不必要模型轮次、缩小冗长工具结果、并行独立只读操作，再考虑模型路由和缓存。每个优化要在相同任务集上同时检查质量、违规率、费用与尾延迟。
Prompt/Prefix cache 复用相同前缀的推理计算，不等于复用最终答案；在典型自回归服务中它主要减少重复 prefill，不能直接消掉后续生成每个 token 的 decode。业务结果缓存还需处理租户、权限、版本、时效性与失效，写操作不能靠“命中过去成功响应”决定现在再执行。
追问怎么接
“流式输出会更快吗？”通常改善首个可见结果的体验，不等于最终任务更早完成。“成本看每请求平均值够吗？”还看每个成功任务成本、失败重试开销和人工成本。“工具越并行越快？”关键路径可能缩短，但会增加限流、争用和尾延迟。
不要这样答：“加 Redis 缓存模型回答就解决了”“prefix cache 会大幅减少所有 decode 时间”。
依据与延伸：Prompt-Cache、vLLM-APC、AWS-Retry。
AG28｜模型怎么选？API 与自部署怎么权衡？〔P1〕
口述答案
按自己的任务集选，不按通用榜单直接决定。比较工具选择、参数准确性、多语言、长任务稳定性、结构化输出、延迟和成功任务成本。先选能稳定完成任务的基线，再测试更小模型、分层路由或复杂任务升级；路由器本身也有成本和误判。
API 减少推理运维，但要处理配额、供应商失败、数据边界和版本变化；自部署换来更多控制，也引入 GPU 容量、批处理、KV 内存、模型升级和监控成本。面试重点是说明什么时候值得，不需要背某张卡的吞吐。
追问怎么接
“大模型超时就切小模型？”不一定，小模型未必具备同样工具/上下文能力；明确哪些步骤允许降级，输出再走同一验证链。退款结果未知时不能切模型重新发起退款。“temperature=0 能复现吗？”不能作为跨硬件、版本和服务更新的确定性保证。
不要这样答：“越大越好”“换模型只是改个字符串，没有语义兼容问题”。