Agent 应用开发会员账号
知识目录选择核心方向与细分内容
知识单元 45进阶实现约 12 分钟

理解 → 实现 → 排错 → 取舍

任务因果链与资源归因

把业务任务、模型请求与工具调用串成可查询的链路,并用质量回归补足运行指标。

OpenTelemetryTracing评测成本控制

知识内容核对 2026-10-03 · 原题来源核对 2026-10-02

这个知识点,你想学到哪一步?

按当前基础选择起点,也可以依次深入。遇到不熟悉的概念,先回到核心原理;完成后用知识练习检查理解。

先理解

刚接触这个知识点

补齐先备概念,读原理与反例,再用自己的话解释为什么。

从核心原理开始 →

再实现

准备把原理写进代码

理解实现步骤与边界,完成小任务,对照验收要求检查结果。

查看代码示例 →

会排错

需要处理故障与条件变化

沿连续追问定位失效前提,再比较迁移案例,说明方案应如何调整。

沿问题继续深入 →

能取舍

需要设计或评审方案

结合工程推演与资深自评标准,解释方案的适用条件、代价和替代选择。

分析工程场景 →
知识单元目录

LEARN · PRACTICE · REFLECT

知识学习与个人记录

我的笔记与复习 ↗

先沿着原理、问答和迁移案例阅读。需要检查理解时,再切换巩固练习或展开个人记录。

作答与个人记录

每次修改后的提交会保留为独立历史。掌握程度由你对照标准自评。

核心知识 · 任务因果链与资源归因

先理解核心原理

先备概念:分布式追踪、异步队列、业务终态

可观测性要把一次用户任务连到真实模型、工具和业务效果。时间线用于解释等待,资源账用于解释费用,两者不能靠模型自述或简单累加替代。

从接口耗时到任务耗时

一次报告任务包含检索、多个模型轮次、工具重试和审批等待。HTTP span 结束后任务可能仍运行,因此用稳定 run_id 连接业务记录,trace 表达调用关系。记录每次尝试的阶段、版本、错误类别及真实用量,才能区分模型慢、排队慢和审批慢。

并行时间与费用不同

两个查询各耗两秒且完全重叠,用户等待约两秒加编排开销,不是四秒;而两次计费查询仍各自产生成本。沿依赖图计算关键路径,费用按去重后的计费事实加总。不要把父 span 与子 span 重复累计,也不要用平均耗时解释少量极慢任务。

调试证据不是无限正文日志

优先保存事件标识、数据版本、工具参数结构及经脱敏的错误。敏感正文可在有权限和期限的专门存储中保留最小复现样本。关闭正文采集会限制语义复现,要诚实说明;不能靠摘要哈希还原输入。以下归因流程是设计示例,未对真实流量做性能结论。

用一个问题检查理解

Agent 上线后回答变慢、成本变高,如何定位到具体一步?

我会先给任务统一 run_id 和 trace_id,把模型、检索、工具与审批等待拆成子 span。每次尝试记录耗时、状态、token、版本与重试原因,区分业务成功和请求成功。先查慢链路和重复调用,再看质量回归,最后按租户和模型版本比较成本。正文默认脱敏,审计记录独立保存,不能因为采样而丢掉关键写操作。

实现与取舍

从业务任务建立链路

用户的一次请求产生稳定的 run_id;重试沿用任务标识,但建立新的 attempt_id。任务 span 下面放检索、模型和工具 span,队列投递携带 trace 上下文,worker 消费后建立父子关系。每一步记录开始结束时间、操作名、错误类型、模型与提示模板版本。OpenTelemetry 的 GenAI agent span 约定提供 agent、workflow 与工具等操作的语义;该约定仍处于 Development 状态,应集中管理字段映射并固定采用的版本。

区分延迟、费用和任务成功

用户感知延迟包含排队、执行与审批等待,不能把所有子 span 耗时相加当作总耗时,并发工具会重叠。费用统计优先读取供应商 usage,再按当时价格表计算估算额,缓存命中和失败重试分别标记。HTTP 成功只代表请求传输成功;“找到正确账户并给出有依据的余额”才是业务成功。工具错误率按工具、错误类型和租户聚合,任务质量用固定样本及业务规则检查,避免用同一个模型的赞同代替验收。

用链路提出可以验证的修复

排查先找最慢任务,再看关键路径:是检索慢、模型输出长,还是工具超时触发多次重试。修复假设要对应实验,例如减少无关工具描述后,在同一题集检查正确工具选择是否下降;压缩上下文后检查引用遗漏。OpenAI Agents SDK 的 Tracing覆盖模型生成、工具调用、handoff 等事件;框架 tracing 是起点,还需接上数据库、队列与自定义业务节点。

保留证据并控制数据暴露

普通日志记录资源标识、摘要和脱敏错误,不默认写入完整文档或密钥。确需保存输入输出时,采用独立访问权限、保留期限与删除机制。聚合指标使用低基数字段,不把 run_id 作为时序指标标签。常规成功链路可采样,失败和慢请求可加强保留;审批、权限判定和对外写入进入独立持久化审计。验证时注入一次工具超时和一次权限拒绝,检查链路能定位到具体步骤,拒绝不会被错误计为业务成功。 同时把提示模板发布纳入变更事件,让一次质量退化能关联到具体版本,而非仅看到平均响应时间变化。

代码示例

离线汇总一个任务的工具尝试

Python 3 标准库即可运行。仅演示逻辑调用与重试统计,未接入 OpenTelemetry;tool_work_ms 是工作量之和,存在并发时不能视作任务墙钟耗时。

import json

# 假设采集得到的三个 span;同一 tool_call_id 的不同 attempt 是重试。
spans = [
    {"run_id": "r1", "tool_call_id": "t1", "attempt": 1, "status": "timeout", "duration_ms": 800},
    {"run_id": "r1", "tool_call_id": "t1", "attempt": 2, "status": "ok", "duration_ms": 120},
    {"run_id": "r1", "tool_call_id": "t2", "attempt": 1, "status": "ok", "duration_ms": 60},
]
result = {
    "tool_attempts": len(spans),
    "logical_tool_calls": len({s["tool_call_id"] for s in spans}),
    "failed_attempts": sum(s["status"] != "ok" for s in spans),
    "tool_work_ms": sum(s["duration_ms"] for s in spans),
}
print(json.dumps(result, ensure_ascii=False, sort_keys=True))

预期输出

{"failed_attempts": 1, "logical_tool_calls": 2, "tool_attempts": 3, "tool_work_ms": 980}

工程推演

场景
假设工程场景:企业知识助手出现响应变慢,同时 token 用量上升。
设计决策
将模型尝试、检索耗时与工具重试拆开记录,对同一版本固定样本比较。
验证目标
验收目标是定位最慢阶段并解释新增费用,本文未声称已执行真实线上实验。
适用边界
离线例子只演示统计口径;生产部署仍需真实埋点、采样与权限配置。

连续追问与解答

沿着问题的前提和约束继续向下读。先理解参考解答,再尝试收起答案,用自己的话解释因果和取舍。

举一反三:条件变了,怎样推导?

先找出改变的条件,再判断原方案中哪些前提仍成立。下面的案例是教学推演,便于将原理迁移到新问题。

加入人工审批

改变的条件:机器执行之外新增长时间的人类等待。

延伸问题:审批等待应算模型延迟吗?

推导与参考解答

不应。将任务端到端时长、主动计算时长和审批等待分开,保留暂停与恢复事件;用户等待指标仍包括审批。优化模型速度不能解决审批队列积压,需要按阶段定位。

保持不变的原理:同一任务由真实因果事件连接,等待和工作量有独立口径。

供应商只提供账单汇总

改变的条件:请求级费用证据不足。

延伸问题:能准确归因每个租户费用吗?

推导与参考解答

先根据可得用量和公开计价做估算,标明分摊规则与差异,再与账单对账。共享缓存、折扣和重试使估算不等于实付;不能把不明账单强行写成精确每任务成本。

保持不变的原理:费用结论不得超过采集与计价证据的支持范围。

易错点

  • 把最终 HTTP 200 当成任务正确完成。
  • 把重试产生的多次尝试统计为独立业务任务。
  • 将完整客户文档或高基数任务标识无控制地写入日志和指标。

参考资料

依据公开技术资料设计;参考资料支持技术机制,场景与评分标准为本站设计,不代表某公司面试原题。 新增问答与迁移案例用于原理讲解,来源核查与案例运行验证分别记录。

检查自己理解到哪一步

读完后可以对照这些标准解释原理、边界和取舍。掌握程度由你自评;需要进一步验证时,再完成下方小任务。

基础达标
能记录运行、步骤、工具耗时和用量。
中高级信号
以关联 ID 定位排队、模型、工具和重试成本。
资深信号
兼顾脱敏、指标基数、采样及单位成功成本。

查看独立示例的校验记录

动手验证 按需完成 · 建议 15 分钟

为多工具任务设计最小 Trace 字段,定位 P95 延迟来源。

展开验收要求与检查点
  • 运行与步骤可关联
  • 成本包含重试
  • 秘密与个人信息不默认入日志

重点检查

  • 能够区分任务、步骤、尝试三个层次,串联异步队列中的上下文。
  • 能说明运行指标与答案质量指标分别怎样采集。
  • 能设计脱敏、采样和审计保留策略,而不是默认记录所有原文。