SCOPE本章边界
本章只讲 Trace、Eval、failure taxonomy、release gate 和观测数据治理。其他章节只列该层专属指标,不重复通用评测方法。
30 SEC面试开口版
我会用 Trace 解释单次失败,用 Eval 证明长期改进。Trace 要记录 goal、model input、tool intent、permission、execution、observation、artifact、context decision、verification 和 cost/latency;Eval 要覆盖任务完成率、工具正确率、恢复成功率、安全绕过率、用户接管率和回归。不能只用 LLM judge 看最终回答,要把确定性检查、人工标注、轨迹指标和红队样本组合起来。
理解与记忆 · 术语、解析、关联知识点
| 专业术语 | Trace:单次运行轨迹。 Eval:固定样本上的质量评测。 Span:一次可观测操作。 Failure Taxonomy:失败分类。 Regression:回归退化。 |
| 为什么这样回答 | 先把 trace 和 eval 分工讲清楚,避免回答成“加日志”和“跑几个例子”。 |
| 小白解析 | Trace 像行车记录仪,Eval 像驾照考试和定期路考;一个查事故,一个看整体水平。 |
| 关联知识点 | OpenAI Agents SDK tracing 默认记录 agent、LLM generation、function tool、guardrail、handoff 等 span;OpenTelemetry 有 GenAI semantic conventions。 |
1 MIN一分钟口语版
我会把可观测性分四层。第一是事件账本,保存事实源;第二是 trace,把一次 run 组织成 goal -> context -> decision -> tool -> observation -> verification 的因果链;第三是 metrics,看任务完成率、tool error、permission denial、context missing fact、token cost、p95 latency、user rescue;第四是 eval,把真实失败样本、合成红队样本和 golden tasks 固定下来,每次 prompt、tool、model、context policy 变更都跑回归。LLM judge 只用于主观质量和摘要可读性,安全、schema、exit code、引用、文件 diff 这些尽量用确定性检查。
理解与记忆 · 术语、解析、关联知识点
| 专业术语 | Event Ledger:事实账本。 Metrics:聚合指标。 Golden Task:固定评测任务。 LLM Judge:模型评审器。 p95 Latency:95 分位延迟。 |
| 为什么这样回答 | 一分钟版要把单次诊断、聚合指标和离线评测连成工程闭环。 |
| 小白解析 | 你既要能回看某次为什么失败,也要知道这个月整体有没有变好,还要防止改了新功能把老任务弄坏。 |
| 关联知识点 | learn-agent trace analysis 强调从 event log 投影出责任链;Guga strategy 把真实任务完成率、可恢复率、工具审计覆盖率作为关键指标。 |
FLOW从事件到评测闭环
Trace/Eval 数据闭环
COMPARE主流方案怎么讲
OpenAI Agents SDK Tracing
OpenAI Agents SDK 内置 tracing,覆盖 agent run、LLM generation、function tools、guardrails、handoffs 和 custom spans。
OpenAI Agent Evals
OpenAI 平台提供 agent eval 工具,用于检查 agents 在固定任务上的一致性和准确性。
OpenTelemetry GenAI
OpenTelemetry 的 GenAI semantic conventions 正在把模型调用、token、响应、工具等观测字段朝统一语义收敛,但它仍处于演进期。生产系统要保留 schema version、adapter 和 upcaster,避免把当前字段当成永久稳定标准。
Guga / learn-agent
本地口径强调 event log 是事实源,trace 是诊断视图,eval 是策略变更的回归门。
DESIGN我会怎么设计
- Trace Schema记录 workflow、turn、model span、tool span、permission span、context span、verification span、artifact refs 和 usage。
- Failure Taxonomy把失败分到 intent、planning、context、tool、observation、permission、memory、verification、product。
- Eval Dataset来自真实失败、golden tasks、红队样本、边界样本;每条带 expected behavior 和 risk tags。
- Judging Strategy确定性规则优先,LLM judge 用于主观质量;关键任务用人工 spot check 校准。
- Release Gateprompt、tool、model、context policy 变更前后比较成功率、成本、延迟、安全和回归。
TRADEOFF常见问题和优化
问题:trace 含敏感数据
trace 默认保存引用、hash 和摘要,敏感 payload 进受控 artifact;导出前做脱敏和访问控制。
问题:LLM judge 不稳定
judge 结果只作为软信号;schema、exit code、diff、引用、权限等用确定性检查。
问题:eval 样本会过拟合
固定回归集之外保留新鲜 holdout、真实线上抽样和红队更新,不让 prompt 只背题。
问题:指标太多看不懂
面向负责人看任务成功率、人工救援率、成本和安全;面向工程师看失败分类和 span 细节。
REVISION一次失败如何归因
| 现象 | 归因 | 修什么 |
|---|---|---|
| event 里有用户约束,但本轮模型输入没有 | context_projection_missing_fact | Context policy、source ranking、compact boundary。 |
| 工具 exitCode=1,却被 observation 摘成成功 | observation_normalization_failure | ResultPolicy、结构化错误、artifact preview。 |
| 模型看到了测试失败,仍 final done | model_or_verification_failure | VerificationGate、stop criteria、release eval。 |
Eval 报告不要只给总分,要输出 failure diff:本次比 baseline 多了哪些 permission denial、schema repair、context_missing_fact,才能判断是工具/schema/context 改动导致,还是模型退化。
REVISIONOnline Eval / Canary / Rollback
| 阶段 | 做什么 | 看什么指标 |
|---|---|---|
| Offline gate | golden tasks、真实失败集、red-team set、holdout;比较 baseline failure diff。 | task success、regression、unsafe miss、cost、latency。 |
| Shadow mode | 新 context/tool/routing policy 只旁路运行,不影响用户结果。 | tool choice diff、context inclusion diff、cost delta、risk diff。 |
| Canary | 先给内部用户或 1% 低风险租户,按 run/session 固定策略版本。 | user rescue、permission denial、tool failure、p95 latency。 |
| A/B | 按 user/session/run 固定分组,长任务中途不切策略。 | cost per successful task、rollback rate、user abort、answer correction。 |
| Guarded rollout | 超过阈值自动 freeze 或 rollback;事故 trace 脱敏进入 eval。 | SLO breach、ACL leak、unsafe action missed、context_missing_fact。 |
离线 eval 通过只说明候选策略可以进入发布流程,不说明线上一定更好。线上判断要有样本量、分段指标和事故 replay,不能凭一次 judge 分数宣布胜利。
INTERVIEW高强度追问
面试官:Agent eval 和普通 LLM eval 有什么不同?第二层追问:最终答案对了不就行了吗?
我:Agent eval 要评轨迹。最终答案对了但用了危险工具、泄露 secret、没验证、成本爆炸,也不能算好。要评 goal completion、tool choice、permission、context use、observation、verification、recovery、安全和用户接管。最终答案只是一个输出面。
理解与记忆 · 背后工程点
背后工程点:Agent 的质量在行动轨迹里,不只在最终文本。
专业术语:
Trajectory:轨迹。
Goal Completion:目标完成。
Verification:验证。
Safety Regression:安全回归。
为什么这样回答:先区分评测对象,后面指标才成立。
小白解析:考试答案对了,但如果是作弊、闯红灯送来的,也不能算合格。
关联知识点:OpenAI tracing 收集 LLM generation、tool calls、handoffs、guardrails;learn-agent trace analysis 从多边界归因。
面试官:Trace 里必须记录哪些 span?第二层追问:只记模型输入输出够吗?
我:不够。至少要有 workflow/run、turn、context projection、model request/response、tool intent、permission decision、tool execution、artifact write、observation projection、verification、handoff、error、usage/cost spans。否则失败时无法判断问题在模型、工具、权限还是 context。
理解与记忆 · 背后工程点
背后工程点:Trace 要覆盖决策链和副作用链。
专业术语:
Span:可观测操作片段。
Context Projection:上下文投影。
Usage:用量。
Handoff:移交。
为什么这样回答:具体 span 列表体现实践经验。
小白解析:只看司机最后说“到了”,不知道中间有没有绕路、超速、撞车。
关联知识点:OpenAI Agents SDK 默认 tracing 包含 agent_span、generation_span、function_span、guardrail_span、handoff_span。
面试官:失败分类怎么设计?第二层追问:分类太主观怎么办?
我:分类要服务修复路线。我会先粗分 intent、planning、context、tool、observation、permission、memory、verification、product,再给每类定义证据规则。例如关键事实在 event 里但没进 model input,是 context;exit code 非零却被标成功,是 observation/verification。主观部分再用人工或 LLM judge。
理解与记忆 · 背后工程点
背后工程点:失败分类必须可操作、可证据化。
专业术语:
Failure Taxonomy:失败分类。
Evidence Rule:证据规则。
Context Missing Fact:上下文缺失事实。
Verification Failure:验证失败。
为什么这样回答:避免分类变成贴标签。
小白解析:维修单要写是电路坏、水管坏还是使用方式错,这样才知道找谁修。
关联知识点:learn-agent trace analysis 明确用 trace 把失败归因到具体责任边界。
面试官:LLM judge 什么时候能用,什么时候不能用?
我:主观质量、可读性、解释完整性、是否答非所问可以用 LLM judge,但要有 rubrics 和校准样本。安全、权限、schema、测试通过、引用存在、文件 diff、是否调用危险工具尽量用确定性规则。关键发布不能只靠一个 judge 分数。
理解与记忆 · 背后工程点
背后工程点:Judge 是软评审,不是万能裁判。
专业术语:
Rubric:评分标准。
Calibration:校准。
Deterministic Check:确定性检查。
Soft Signal:软信号。
为什么这样回答:这回答了 eval 可信度。
小白解析:作文可以请老师评分,算术题最好直接验算。
关联知识点:OpenAI agent evals 可用于一致性检查,但工程系统通常要混合规则、人工和模型评审。
面试官:评测数据从哪里来?第二层追问:线上失败能直接进 eval 吗?
我:来源包括 golden tasks、线上失败、用户接管案例、安全红队、边界合成样本和回归 bug。线上失败不能直接丢进去,要脱敏、去租户数据、标注 expected behavior、risk tags 和版本。还要保留 holdout,避免 prompt 过拟合。
理解与记忆 · 背后工程点
背后工程点:Eval 数据要治理,不是日志搬运。
专业术语:
Golden Task:黄金任务。
Holdout:保留集。
Risk Tag:风险标签。
Data Sanitization:数据脱敏。
为什么这样回答:数据治理是评测可信度核心。
小白解析:错题能进题库,但要去掉学生隐私,写清标准答案,不能让大家提前背完全部题。
关联知识点:learn-agent LLM 数据工程也强调 eval set 独立、追踪和版本固定。
面试官:如何评估 context policy?第二层追问:summary 质量怎么量化?
我:看压缩后任务继续成功率、关键约束保留率、context_missing_fact、工具重读率、摘要矛盾率、token 节省、成本延迟。Summary 主观质量可以 judge,但更重要是它有没有保留目标、下一步、未完成事项、关键证据和用户限制。
理解与记忆 · 背后工程点
背后工程点:Context eval 要看任务连续性,不只看摘要好不好读。
专业术语:
Constraint Retention:约束保留。
Tool Re-read Rate:工具重读率。
Compression Gain:压缩收益。
Contradiction Rate:矛盾率。
为什么这样回答:和 Context 章节形成闭环。
小白解析:会议纪要好不好,不是文笔美,而是下次开会能不能接着干。
关联知识点:Guga default context policy 有 compact boundary 和 projection decision;learn-agent context 章节强调事实留账本。
面试官:怎么评估工具层?第二层追问:工具描述改了以后怎么证明变好?
我:跑 tool-selection eval:给任务和可见工具,看选择是否正确、参数是否有效、是否少调或误调;再跑 execution eval:schema error、permission denial、timeout、large output、artifact reference、observation 正确率。比较改动前后失败分类和成本。
理解与记忆 · 背后工程点
背后工程点:工具说明和 schema 都要进入回归评测。
专业术语:
Tool-selection Eval:工具选择评测。
Schema Error:参数错误。
Observation Correctness:观察正确性。
Artifact Reference:产物引用。
为什么这样回答:工具是 Agent 成败核心,不能只测模型。
小白解析:改了工具说明书,要看新人拿错工具的次数有没有下降。
关联知识点:Anthropic 工具设计文章建议用 eval 检查 agent 是否理解工具用途。
面试官:安全 eval 怎么做?第二层追问:prompt injection 测多少才够?
我:要覆盖直接注入、间接注入、工具结果注入、MCP tool poisoning、memory poisoning、secret exfiltration、excessive agency、multi-agent privilege escalation。数量不是唯一,关键是风险面覆盖和线上事故回流。每个安全用例要有 expected refusal、permission escalation 或 safe completion。
理解与记忆 · 背后工程点
背后工程点:安全 eval 要按攻击面覆盖。
专业术语:
Indirect Injection:间接注入。
Tool Poisoning:工具投毒。
Exfiltration:数据外传。
Safe Completion:安全完成。
为什么这样回答:安全不是一个 prompt injection 样例就够。
小白解析:防盗测试不能只试一把锁,还要试窗户、后门、快递入口和监控盲区。
关联知识点:OWASP LLM/MCP Top 10 提供风险分类;Guga security 章节把这些转成 runtime 测试。
面试官:可观测性指标怎么分层?第二层追问:老板和工程师看同一套指标吗?
我:老板看业务指标:任务成功率、节省时间、用户接管率、成本、SLA、安全事故。工程师看诊断指标:tool error、context missing fact、verification fail、permission denial、p95 latency、token usage、failure taxonomy。底层同一套 trace,上层投影不同。
理解与记忆 · 背后工程点
背后工程点:观测要按受众投影。
专业术语:
Business Metric:业务指标。
Diagnostic Metric:诊断指标。
SLA:服务等级。
Projection:投影。
为什么这样回答:这能体现产品化意识。
小白解析:驾驶员看仪表盘,维修师傅看故障码,管理者看准点率和油耗。
关联知识点:Guga strategy 同时定义任务完成率、可恢复率、工具审计覆盖率和交付时间。
面试官:Trace 会不会太贵?第二层追问:所有 payload 都存吗?
我:不存所有原文。默认存 span metadata、ids、hash、token、latency、status、artifact refs 和 bounded preview;敏感或大 payload 存受控 artifact 或不存。采样策略按环境和风险:开发全量、生产按任务类型采样,高风险和失败全量保留。
理解与记忆 · 背后工程点
背后工程点:Trace 成本通过引用、采样和脱敏控制。
专业术语:
Sampling:采样。
Payload:负载内容。
Hash:哈希。
Retention:保留策略。
为什么这样回答:回应成本和隐私质疑。
小白解析:监控不一定录下所有高清视频,关键路口和事故片段要保留。
关联知识点:OpenAI tracing 有 sensitive data 控制;Guga artifact/event 分离减少 prompt 和 trace 膨胀。
面试官:怎么把 eval 接到发布流程?第二层追问:每次改 prompt 都跑全量吗?
我:建立分层 release gate。小 prompt 改动跑 smoke eval 和相关风险集;tool/context/model 变更跑更大回归;安全和权限变更必须跑红队集。报告比较 baseline:成功率、失败分类、成本、延迟、安全。超过阈值阻断发布,必要时人工审查。
理解与记忆 · 背后工程点
背后工程点:Eval 要成为发布门禁,而不是事后报告。
专业术语:
Release Gate:发布门禁。
Baseline:基线。
Smoke Eval:冒烟评测。
Threshold:阈值。
为什么这样回答:这让评测变成工程流程。
小白解析:改车灯跑短测,换刹车跑全套安全测试。
关联知识点:Guga runtime 边界回归率适合作为 CI/发布指标。
面试官:离线 eval 和线上观测怎么分工?第二层追问:离线分数涨了,线上用户还是不满意怎么办?
我:离线 eval 证明候选变更没有明显回归,线上观测证明真实流量下有没有价值。离线看固定样本的可重复比较;线上看真实任务成功率、用户接管、重试、取消、成本和延迟。离线涨但线上差,通常说明 eval 集不覆盖真实任务分布,要把线上失败脱敏回流,同时用 shadow/canary 降低发布风险。
理解与记忆 · 背后工程点
背后工程点:离线评测控制回归,线上观测验证真实价值。
专业术语:
Offline Eval:离线固定样本评测。
Online Metrics:线上真实使用指标。
Shadow:影子运行,不影响用户结果。
Canary:小流量灰度。
为什么这样回答:面试官常追问 eval 是否脱离生产,这里把发布前和发布后闭环讲清楚。
小白解析:模拟考成绩变好,不代表真实工作一定顺利;要看上班后的实际表现,再把真实错题补进题库。
关联知识点:OpenAI practical guide 强调 agent 要在真实工作流里迭代;Guga strategy 也把真实任务完成率和接管率作为关键指标。
面试官:Trace schema 怎么设计版本?第二层追问:跨模型服务、工具服务、前端会话怎么串起来?
我:Trace schema 要版本化,核心字段保持稳定:trace_id、run_id、span_id、parent_span_id、span_type、status、start/end、actor、resource refs、usage、error、policy_version。跨服务靠 trace_id 和 correlation id 传递,工具服务也要回写 span。字段升级用 adapter 或 upcaster,避免老 trace 读不了。
理解与记忆 · 背后工程点
背后工程点:Trace 是跨边界诊断协议,必须版本化和可关联。
专业术语:
Trace ID:一次任务的全局轨迹标识。
Span ID:单个操作片段标识。
Correlation ID:跨服务关联请求的标识。
Upcaster:把旧版本事件升级成新读取模型的适配层。
为什么这样回答:这能证明你不是只会打印日志,而是在设计长期可演进的观测数据模型。
小白解析:包裹经过仓库、运输和派送,每一站都要扫同一个运单号,否则丢了以后查不到卡在哪。
关联知识点:OpenTelemetry 用 trace/span 组织跨系统观测,GenAI semantic conventions 正在收敛模型调用相关字段;生产落地仍要保留 schema version 和 upcaster。
面试官:Agent eval 里 replay 是重新执行工具,还是只回放历史 observation?第二层追问:工具有副作用怎么办?
我:两种都要有。诊断 replay 默认回放历史 observation,不重新执行副作用,这样可重复、便宜、安全;live eval 或 sandbox eval 才重新执行工具,用来测当前系统和外部依赖。带副作用工具必须有 dry-run、sandbox、idempotency key 或 mock,否则 eval 会污染真实环境。
理解与记忆 · 背后工程点
背后工程点:回放历史和重新执行是两种不同评测模式。
专业术语:
Diagnostic Replay:诊断回放,只复现决策上下文。
Live Eval:真实执行评测。
Side Effect:工具调用造成的外部状态改变。
Idempotency Key:幂等键,避免重复执行产生重复副作用。
为什么这样回答:Agent 有工具副作用,评测不能像纯文本模型一样随便重跑。
小白解析:复盘转账错误时,可以看历史流水;不能为了复盘再真的转一次钱。
关联知识点:LangGraph durable execution 和 Guga event log 都强调从事件恢复状态,但副作用必须被边界化处理。
面试官:怎么评估恢复能力?第二层追问:正常路径全过,为什么还要故障注入?
我:Agent 生产质量很大一部分在异常路径。我会在 eval 里注入 tool timeout、rate limit、schema mismatch、权限拒绝、context compaction、worker crash、artifact missing、模型输出不合规,看它能不能重试、降级、请求用户、恢复上下文、避免重复副作用。正常路径全过只能说明天气好时能开,不能证明系统可靠。
理解与记忆 · 背后工程点
背后工程点:恢复 eval 要主动制造故障,测试 runtime 的韧性。
专业术语:
Fault Injection:故障注入。
Rate Limit:限流。
Graceful Degradation:优雅降级。
Duplicate Side Effect:重复副作用。
为什么这样回答:资深面试官会看你是否只测 happy path,这里主动覆盖可靠性压力。
小白解析:车不仅要在晴天直路能开,还要在堵车、爆胎、导航失灵时不会把人带进更糟的状态。
关联知识点:LangGraph time travel/persistence 和 Guga recovery 章节都把中断恢复、回放和幂等作为生产能力。
面试官:成本和延迟怎么进 eval?第二层追问:便宜模型分数低一点,怎么判断值不值得?
我:不要只看质量分,要看 cost per successful task、p95/p99 latency、平均轮次、tool calls、token usage、retry rate。便宜模型如果让失败率、重试和人工接管上升,真实成本可能更高。路由策略要按任务风险分层:低风险用便宜模型,高风险或失败恢复升级强模型,用总成功成本比较。
理解与记忆 · 背后工程点
背后工程点:成本评测要按成功任务计价,而不是只按单次 token 便宜。
专业术语:
Cost per Successful Task:每个成功任务成本。
p99 Latency:99 分位延迟。
Retry Rate:重试率。
Escalation:升级到更强模型或人工。
为什么这样回答:把模型路由、质量、成本和产品体验连起来,比单独报 token 成本更成熟。
小白解析:便宜工人如果经常返工,最后可能比贵但一次做对的人更贵。
关联知识点:OpenAI practical guide 提到 agent 要在能力、延迟和成本之间权衡;Guga strategy 也把交付时间和成本纳入指标。
面试官:Eval 集会不会被 prompt 调参“背题”?第二层追问:怎么发现过拟合?
我:会,所以要分训练式调试集、固定回归集、隐藏 holdout 和线上抽样集。发现方式是固定集涨很多、holdout 和线上不涨,或者失败模式只是从一类转移到另一类。治理上要限制直接把答案写进 prompt,保留样本版本,定期轮换红队和真实失败样本。
理解与记忆 · 背后工程点
背后工程点:Agent eval 也会过拟合,需要数据集分层和样本治理。
专业术语:
Overfitting:过拟合,只适应已知题目。
Holdout Set:隐藏保留集。
Dataset Versioning:数据集版本管理。
Failure Migration:失败从一类迁移到另一类。
为什么这样回答:回应评测可信度,避免把 eval 当成静态排行榜。
小白解析:学生把模拟题答案背熟了,不代表真会;要换题型、留暗题、看真实表现。
关联知识点:learn-agent 数据工程口径强调 eval set 独立和版本固定;线上失败回流能持续更新覆盖面。
面试官:人评怎么接入?第二层追问:两个标注员意见不一致怎么办?
我:人评适合主观质量、任务是否真正解决、用户体验和高风险样本抽查。要先写 rubric,再做校准样本,让标注员对齐什么算成功、部分成功、失败和安全问题。不一致时记录 disagreement,升级给资深 reviewer,反过来修 rubric;不要把人评分数当成没有误差的真理。
理解与记忆 · 背后工程点
背后工程点:人评要制度化,用 rubric 和校准降低主观漂移。
专业术语:
Human Evaluation:人工评测。
Rubric:评分规则。
Inter-annotator Agreement:标注员一致性。
Adjudication:分歧裁决。
为什么这样回答:LLM judge 和确定性规则都有盲区,资深回答要说明人工评审如何可信地参与。
小白解析:作文比赛要有评分细则,评委意见不一致时要复议,也要更新评分标准。
关联知识点:OpenAI agent evals 支持围绕任务结果做评测,工程上通常还会结合人工 spot check 校准模型评审。
面试官:可观测性里有用户数据,隐私和权限怎么处理?第二层追问:工程师排障需要看原文怎么办?
我:默认最小化采集:存 metadata、hash、摘要和 artifact ref,敏感原文放受控存储。访问要按租户、角色、工单和时间授权,所有查看都审计。排障确实需要原文时走 break-glass 流程,限时、留痕、脱敏导出。Retention 和删除请求要能传播到 trace、artifact 和 eval 样本。
理解与记忆 · 背后工程点
背后工程点:观测系统本身也是数据系统,要有隐私、权限和删除链路。
专业术语:
Data Minimization:数据最小化采集。
Break-glass:紧急临时访问机制。
Audit Log:访问审计日志。
Retention Policy:数据保留策略。
为什么这样回答:Trace 很容易变成敏感数据集中地,必须把安全治理讲进设计。
小白解析:医院病历能帮助诊断,但不是所有员工都能随便看;看了也要有记录,到期还要清理。
关联知识点:OpenAI tracing 提供敏感数据控制思路;Guga artifact/event 分离也能减少 trace 中直接暴露原始 payload。
面试官:Eval MVP 先做什么?第二层追问:没有线上数据怎么办?
我:先做 30-50 个 golden tasks、10 个安全红队、10 个恢复/工具失败用例,配 trace schema 和报告。没有线上数据就从本地任务、历史 bug、手工构造和参考项目失败模式开始;上线后把真实失败脱敏回流。先追求稳定回归,不追求大而全 benchmark。
理解与记忆 · 背后工程点
背后工程点:Eval MVP 先小而固定,能防回归。
专业术语:
Golden Set:黄金集。
Red-team Set:红队集。
Failure Case:失败案例。
Report:报告。
为什么这样回答:给出落地第一步。
小白解析:新老师先准备一套核心题,每次改教材都考一遍。
关联知识点:learn-agent trace 章节和 Guga strategy 都强调用失败样本推动 runtime 迭代。
PRINCIPLE我总结的核心范式
Agent 评测与可观测性的核心原则是“没有 trace,就没有归因;没有 eval,就没有改进证明”。Trace 面向单次事故,Eval 面向长期质量,二者都必须落到模型、工具、权限、上下文、恢复和产品体验的责任边界。