文章摘要
2026 年 6 月,AI Agent 可观测性已从「锦上添花」升级为「生产必需」。传统 APM 无法回答 Agent 特有的问题:哪个检索步骤返回了无关上下文?Agent 为何进入递归循环?输出质量是否在静默退化?本文系统讲解 Agent 可观测性的三大支柱(追踪、评估、监控)、六大平台选型(LangSmith/Langfuse/Arize Phoenix/Helicone/Datadog LLM Obs/Honeycomb)、OpenTelemetry 集成方案,以及从开发到生产的完整可观测性架构设计。
1为什么 Agent 需要专门的可观测性?
2026 年 6 月,Gartner 预测到年底 75% 的企业应用将内嵌 AI Agent。 但当 Agent 从实验室走进生产环境,一个残酷的现实浮出水面:传统可观测性工具对 Agent 几乎失效。
传统的 APM(Application Performance Monitoring)工具——Datadog、New Relic、Dynatrace——为确定性软件设计:给定输入 → 预期输出 → 固定路径。但 Agent 的行为是概率性的:
| 维度 | 传统软件 | AI Agent |
|---|---|---|
| 执行路径 | 固定的 if-else 分支 | LLM 动态决策 |
| 输出确定性 | 相同输入 = 相同输出 | 相同输入 ≠ 相同输出 |
| 失败模式 | 异常堆栈、超时 | 幻觉、逻辑错误、工具误用 |
| 性能指标 | 延迟、吞吐量、错误率 | + token 成本、输出质量、安全合规 |
| 调试方式 | 断点、日志 | 需要回放完整推理链 |
Agent 可观测性的核心挑战:
- 推理链不可见:Agent 的「思考过程」隐藏在 LLM 的内部状态中,传统日志只能看到输入和输出
- 工具调用级联:一个用户请求可能触发 10+ 次工具调用,每次调用都可能失败或返回异常
- 多 Agent 协作:当多个 Agent 协同工作时,错误可能在 Agent 之间传播和放大
- 质量漂移:模型更新、数据分布变化可能导致输出质量缓慢退化,且难以察觉
2026 年 1 月,Langfuse 被 ClickHouse 收购——这一事件标志着 Agent 可观测性从「小众需求」正式进入「主流基础设施」。
💡 一句话理解
Agent 可观测性的第一原则:不要等 Agent 出问题了才加监控。从第一行代码开始就内置追踪能力。
⚠️ 常见踩坑
传统 APM 的「错误率」指标对 Agent 毫无意义——Agent 可以「没有报错但输出完全错误」。
2Agent 可观测性的三大支柱
借鉴传统可观测性的「三大支柱」(日志、指标、追踪),Agent 可观测性有自己的三大支柱:追踪(Tracing)、评估(Evaluation)、监控(Monitoring)。
支柱一:追踪(Tracing)—— 看见 Agent 的每一步
追踪是 Agent 可观测性的基础。一条完整的 Agent 追踪记录包含:
- Trace:一次完整的用户请求到最终响应的全链路
- Span:Trace 中的每一个操作步骤(LLM 调用、工具调用、检索步骤等)
- Parent-Child 关系:Span 之间的嵌套关系(如 Agent 调用子 Agent)
Agent 追踪 vs 传统分布式追踪的关键区别:
| 特性 | OpenTelemetry Span | Agent Trace Span |
|---|---|---|
| 基本类型 | HTTP/RPC/DB | LLM/Tool/Retrieval/Agent |
| 属性 | URL、状态码、方法 | Token 数、模型名、工具名、提示词 |
| 嵌套深度 | 通常 2-3 层 | 可达 10+ 层(多 Agent) |
| 时间跨度 | 毫秒-秒 | 秒-分钟(Agent 可能长时间思考) |
| 成本属性 | 无 | 每个 Span 都有 token 成本 |
支柱二:评估(Evaluation)—— 判断输出好不好
追踪告诉你 Agent「做了什么」,评估告诉你 Agent「做得好不好」。
Agent 评估的三个层次:
- 输出质量评估:最终回答是否准确、完整、相关
- 过程质量评估:工具选择是否合理、推理链是否有效
- 安全合规评估:是否泄露敏感信息、是否执行了危险操作
支柱三:监控(Monitoring)—— 发现趋势和异常
监控是长期的、聚合的视角。关键监控维度:
💡 一句话理解
三大支柱的实施顺序:先追踪 → 再评估 → 最后监控。没有追踪数据,评估和监控都是空中楼阁。
⚠️ 常见踩坑
不要跳过评估直接做监控。没有质量评估的监控只能告诉你「Agent 慢了」,但不能告诉你「Agent 变蠢了」。
3六大可观测性平台深度对比
2026 年 6 月,Agent 可观测性平台形成了「三超 + 三强」格局。
三超(全功能平台):
- LangSmith:LangChain 生态原生,最深的框架集成
- Langfuse:开源领导者,可自托管,2026 年 1 月被 ClickHouse 收购
- Arize Phoenix:ML 级严谨度,OTel 原生,开源
三强(差异化玩家):
- Helicone:代理模式,最简单的接入方式
- Datadog LLM Observability:企业级,适合已有 Datadog 的团队
- Honeycomb LLM Observability:事件驱动,深度追踪
LangSmith:LangChain 生态的「亲儿子」
LangSmith 是 LangChain 团队开发的商业平台,对 LangChain/LangGraph 的集成深度无人能及:
- 自动追踪:一行代码启用,所有 LangChain 组件自动产生 Trace
- SmithDB:专为 Agent 追踪设计的数据库,支持 Graph View、Trace View、Message View
- 内置评估:支持 LLM-as-Judge、人工标注、自动化回归测试
- OpenTelemetry:2026 年新增 OTel 导入/导出,可与现有 APM 集成
局限:与 LangChain 生态绑定较深,非 LangChain 项目需要更多手动集成。
Langfuse:开源 + 自托管的首选
Langfuse 是 2026 年 Agent 可观测性领域最重要的开源项目:
- 完全开源:MIT 协议,可自由部署
- 自托管:Docker 一键部署,数据完全在自己的基础设施内
- 框架无关:不绑定任何特定 Agent 框架
- 被 ClickHouse 收购(2026 年 1 月):获得了商业支持,但开源版本功能不变
- 无按座位收费:对小团队极其友好
Arize Phoenix:ML 工程师的选择
Arize Phoenix 从 ML 可观测性起步,在 Agent 时代展现了独特优势:
- OTel 原生:完全基于 OpenTelemetry 构建
- 开源:Apache 2.0 协议
- ML 级评估:继承了 Arize 在模型漂移检测、数据质量监控方面的积累
- adb 数据存储:2026 年新推出的 Agent 数据存储,支持企业级监控和告警
| 平台 | 开源 | 自托管 | 框架绑定 | OTel 支持 | 评估能力 | 定价模式 | 最适合 |
|---|---|---|---|---|---|---|---|
LangSmith | ❌ | ❌ | LangChain 深度 | ✅ 导入/导出 | ⭐⭐⭐⭐⭐ | 按 Trace 量 | LangChain 团队 |
Langfuse | ✅ MIT | ✅ | 框架无关 | ✅ 原生 | ⭐⭐⭐⭐ | 免费/商业 | 注重数据主权 |
Arize Phoenix | ✅ Apache | ✅ | 框架无关 | ✅ 原生 | ⭐⭐⭐⭐⭐ | 按量/商业 | ML 工程团队 |
Helicone | ❌ | ❌ | 框架无关 | ✅ | ⭐⭐⭐ | 按请求量 | 快速接入 |
Datadog LLM Obs | ❌ | ❌ | 框架无关 | ✅ | ⭐⭐⭐⭐ | 企业定价 | 已有 Datadog |
Honeycomb LLM Obs | ❌ | ❌ | 框架无关 | ✅ 原生 | ⭐⭐⭐⭐ | 按事件量 | 事件驱动团队 |
💡 一句话理解
如果你刚起步,Langfuse 是最佳起点:开源、免费、自托管、框架无关。等规模上去后,再考虑是否需要 LangSmith 的深度评估或 Datadog 的企业集成。
⚠️ 常见踩坑
选择平台时考虑「退出成本」:如果平台绑定太深(如 LangSmith 对 LangChain 的依赖),迁移成本可能很高。优先选择 OTel 原生方案。
4OpenTelemetry:Agent 可观测性的统一标准
2026 年,OpenTelemetry(OTel)已成为 Agent 可观测性的事实标准。
OpenTelemetry 是 CNCF 的开源项目,提供厂商无关的可观测性数据采集和传输。在 Agent 领域,OTel 的价值在于:
- 避免厂商锁定:用 OTel 采集的数据可以发送到任何后端(LangSmith、Langfuse、Arize、Datadog...)
- 统一基础设施:Agent 追踪和传统 APM 使用相同的数据管道
- 生态丰富:OTel 已有 400+ 集成,覆盖几乎所有主流工具
OTel 在 Agent 场景的数据模型:
OTel 的核心抽象是 Trace → Span → Event。在 Agent 场景中,需要做语义映射:
- Trace = 一次完整的 Agent 执行(从用户输入到最终输出)
- Span = Agent 的一个操作步骤
- Event = Span 内的具体事件(如 token 生成、工具返回结果)
Agent Span 的自定义属性(Semantic Conventions):
虽然 OTel 的 Agent 语义约定仍在制定中(2026 年 6 月处于 Draft 状态),但社区已形成事实标准:
from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
import time
# 配置 OTel Tracer
provider = TracerProvider()
exporter = OTLPSpanExporter(endpoint="http://localhost:4317")
provider.add_span_processor(BatchSpanProcessor(exporter))
trace.set_tracer_provider(provider)
tracer = trace.get_tracer("agent-observability")
class ObservableAgent:
"""带 OTel 追踪的 Agent 包装器"""
def __init__(self, agent_name: str, model: str = "claude-sonnet-4-20250514"):
self.agent_name = agent_name
self.model = model
def run(self, user_input: str) -> str:
# 创建 Agent 级别的 Span
with tracer.start_as_current_span(
f"agent.{self.agent_name}.run",
attributes={
"agent.id": self.agent_name,
"llm.model": self.model,
"agent.input.preview": user_input[:200],
}
) as span:
# LLM 调用 Span
llm_response = self._call_llm(user_input, span)
# 工具调用 Span(如果有)
if self._needs_tool(llm_response):
tool_result = self._execute_tool(llm_response, span)
final = self._call_llm(tool_result, span)
else:
final = llm_response
span.set_attribute("agent.output.preview", final[:200])
span.set_attribute("agent.status", "success")
return final
def _call_llm(self, prompt: str, parent_span) -> str:
with tracer.start_as_current_span(
"llm.call",
attributes={
"llm.model": self.model,
"llm.token.input_tokens": len(prompt.split()),
}
) as llm_span:
# 实际调用 LLM API
response = f"[LLM response to: {prompt[:50]}...]"
llm_span.set_attribute("llm.token.output_tokens", len(response.split()))
llm_span.set_attribute("llm.cost", 0.003) # 美元
return response
def _needs_tool(self, response: str) -> bool:
return "[tool_call]" in response
def _execute_tool(self, response: str, parent_span) -> str:
with tracer.start_as_current_span(
"tool.execute",
attributes={"tool.name": "web_search"}
) as tool_span:
result = f"[Tool result: search completed]"
tool_span.set_attribute("tool.status", "success")
return result
# 使用示例
agent = ObservableAgent("research-agent")
result = agent.run("分析 2026 年 AI Agent 市场趋势")
print(result)import { Langfuse } from "langfuse";
// 初始化 Langfuse
const langfuse = new Langfuse({
publicKey: process.env.LANGFUSE_PUBLIC_KEY,
secretKey: process.env.LANGFUSE_SECRET_KEY,
baseUrl: process.env.LANGFUSE_BASE_URL, // 自托管地址
});
async function runAgentWithTracing(userInput: string) {
// 创建 Trace
const trace = langfuse.trace({
name: "agent-execution",
sessionId: crypto.randomUUID(),
userId: "user-123",
metadata: { framework: "custom-agent" },
});
try {
// LLM 调用 - Generation Span
const llmCall = trace.generation({
name: "initial-reasoning",
model: "claude-sonnet-4-20250514",
input: userInput,
modelParameters: {
temperature: 0.7,
maxTokens: 4096,
},
});
const llmResponse = await callAnthropicAPI(userInput);
llmCall.end({
output: llmResponse.content,
usage: {
input: llmResponse.usage.inputTokens,
output: llmResponse.usage.outputTokens,
unit: "TOKENS",
},
});
// 工具调用 - Span
if (llmResponse.hasToolCall) {
const toolSpan = trace.span({
name: "tool-execution",
input: { tool: llmResponse.toolName, args: llmResponse.toolArgs },
});
const toolResult = await executeTool(
llmResponse.toolName,
llmResponse.toolArgs
);
toolSpan.end({
output: toolResult,
metadata: { status: "success", duration: "1.2s" },
});
}
// 最终评分
trace.score({
name: "task-completion",
value: 1,
comment: "Agent completed successfully",
});
await langfuse.flushAsync();
return llmResponse;
} catch (error) {
trace.score({
name: "error",
value: 0,
comment: String(error),
});
await langfuse.flushAsync();
throw error;
}
}💡 一句话理解
OTel 的最大优势是「一次采集,多后端发送」。用 OTel 采集 Agent 追踪数据后,可以同时发送到 Langfuse(调试)和 Datadog(生产监控)。
⚠️ 常见踩坑
OTel 的 Agent 语义约定仍在 Draft 阶段(2026-06),属性名可能变化。建议使用 custom. 前缀保存自定义属性,等标准稳定后迁移。
5Agent 评估工程:从人工标注到 LLM-as-Judge
Agent 评估是可观测性中最具挑战性的部分。 追踪和监控相对成熟,但「如何判断 Agent 的输出质量」仍然是一个开放问题。
评估方法的演进路线:
2026 年的 Agent 评估形成了四层体系:
第一层:确定性评估(Deterministic Eval)
适用于有明确正确答案的场景:
- 工具调用是否正确(函数名、参数格式)
- 输出格式是否符合要求(JSON Schema 验证)
- 是否包含禁止内容(安全过滤)
第二层:LLM-as-Judge(模型评估模型)
2026 年最广泛使用的评估方法。核心思想:用一个 LLM 评估另一个 LLM 的输出质量。
典型评估维度:
- 相关性(Relevance):回答是否与问题相关
- 准确性(Faithfulness):回答是否基于检索到的上下文
- 完整性(Completeness):回答是否覆盖了问题的所有方面
- 安全性(Safety):回答是否包含有害内容
第三层:人工标注(Human-in-the-Loop)
最可靠但最昂贵的评估方式。2026 年的最佳实践是:
- 主动学习:只标注 LLM-as-Judge 不确定的样本
- 分层标注:先粗筛(LLM 自动),再精标(人工)
- 标注工具:LangSmith、Label Studio、Argilla
第四层:生产反馈闭环(Production Feedback Loop)
从生产环境自动收集反馈信号:
- 用户点赞/点踩
- 用户是否采纳了 Agent 的建议
- Agent 执行的操作是否被撤销
- 后续对话是否表明 Agent 理解正确
from pydantic import BaseModel
from anthropic import Anthropic
class EvalResult(BaseModel):
relevance: float # 0-1,回答与问题的相关度
faithfulness: float # 0-1,回答是否基于上下文
completeness: float # 0-1,回答的完整度
safety: float # 0-1,安全性评分
reasoning: str # 评分理由
JUDGE_PROMPT = """你是一个严格的 AI 输出质量评估员。
请根据以下维度评估 Agent 的回答:
1. 相关性(Relevance):回答是否直接回应了用户的问题?
2. 准确性(Faithfulness):回答中的事实是否有上下文支持?
3. 完整性(Completeness):回答是否覆盖了问题的所有方面?
4. 安全性(Safety):回答是否避免了有害内容?
每个维度打 0-1 分,并给出评分理由。
用户问题:{question}
Agent 回答:{answer}
参考上下文:{context}
请以 JSON 格式输出评估结果。"""
class LLMJudge:
def __init__(self):
self.client = Anthropic()
def evaluate(self, question: str, answer: str, context: str = "") -> EvalResult:
prompt = JUDGE_PROMPT.format(
question=question, answer=answer, context=context
)
response = self.client.messages.create(
model="claude-sonnet-4-20250514",
max_tokens=1024,
messages=[{"role": "user", "content": prompt}],
)
return EvalResult.model_validate_json(response.content[0].text)
def batch_evaluate(self, samples: list[dict]) -> list[EvalResult]:
"""批量评估并聚合分数"""
results = [self.evaluate(**s) for s in samples]
# 聚合统计
avg_relevance = sum(r.relevance for r in results) / len(results)
avg_faithfulness = sum(r.faithfulness for r in results) / len(results)
avg_completeness = sum(r.completeness for r in results) / len(results)
avg_safety = sum(r.safety for r in results) / len(results)
print(f"评估 {len(results)} 个样本:")
print(f" 相关性: {avg_relevance:.3f}")
print(f" 准确性: {avg_faithfulness:.3f}")
print(f" 完整性: {avg_completeness:.3f}")
print(f" 安全性: {avg_safety:.3f}")
return results⚠️ 常见踩坑
LLM-as-Judge 本身也可能有偏见。定期用人工标注校准 Judge 的评分,避免「评估漂移」。
6生产级 Agent 监控架构设计
从开发到生产,Agent 监控需要完整的架构设计。
架构分层:
一个生产级 Agent 监控架构包含四层:
- 采集层:在 Agent 代码中嵌入追踪点
- 传输层:将追踪数据从 Agent 运行时传输到后端
- 存储层:持久化追踪数据,支持查询和分析
- 展示层:Dashboard、告警、评估报告
采集层设计原则:
- 零侵入:使用装饰器或中间件,不修改 Agent 核心逻辑
- 异步采集:追踪数据的采集和发送不能阻塞 Agent 执行
- 降级容错:监控系统故障时,Agent 仍能正常运行
- 采样策略:生产环境不需要 100% 追踪,可以按比率采样
传输层选型:
| 传输方式 | 适用场景 | 延迟 | 可靠性 |
|---|---|---|---|
| OTLP/gRPC | 自托管,低延迟 | <100ms | ⭐⭐⭐⭐⭐ |
| OTLP/HTTP | 跨网络,防火墙友好 | <500ms | ⭐⭐⭐⭐ |
| 异步队列(Kafka) | 大规模,削峰 | 秒级 | ⭐⭐⭐⭐⭐ |
| 直接 API | 小规模,快速接入 | <1s | ⭐⭐⭐ |
存储层考虑:
- 热存储(7 天):最近 7 天的完整 Trace,支持实时查询
- 温存储(30 天):30 天内的聚合指标和采样 Trace
- 冷存储(1 年+):长期趋势分析和合规审计
告警规则设计:
Agent 监控的告警与传统软件不同:
💡 一句话理解
生产环境的采样率建议:开发期 100%,灰度期 50%,全量后 10-20%。关键是根据成本预算动态调整。
⚠️ 常见踩坑
不要忽略「冷存储」——很多合规要求(如 EU AI Act)需要保留 1 年以上的 AI 决策记录。
7多 Agent 系统的分布式追踪
当多个 Agent 协作完成一个任务时,可观测性的复杂度指数级增长。
多 Agent 追踪的核心挑战:
- 跨 Agent 上下文传播:Agent A 的 Trace 如何与 Agent B 的 Trace 关联?
- 并发执行:多个 Agent 可能同时工作,Trace 需要正确表示并发关系
- 错误传播:Agent A 的错误输出可能导致 Agent B 的错误行为,追踪需要能追溯根因
- 成本归因:一次用户请求涉及 3 个 Agent,成本如何分摊?
解决方案:W3C Trace Context + Agent 语义扩展
2026 年,社区采用 W3C Trace Context 标准作为多 Agent 追踪的基础:
- 每个 Agent 接收请求时,从
traceparentheader 获取 Trace ID - Agent 内部创建 Span 时,使用相同的 Trace ID
- Agent 调用下一个 Agent 时,将 Trace ID 传递给下游
这样,一次用户请求的所有 Agent 执行都在同一个 Trace 下。
Agent 间通信的追踪模式:
| 通信模式 | 追踪方式 | 示例 |
|---|---|---|
| 同步调用 | Parent-Child Span | Agent A 直接调用 Agent B |
| 异步消息 | Message Span + Link | Agent A 发消息到队列,Agent B 消费 |
| 事件驱动 | Event Span + Correlation ID | Agent A 发布事件,Agent B 响应 |
| 共享状态 | Shared State Span | 多个 Agent 读写同一个状态存储 |
成本归因的实现:
在多 Agent 系统中,成本归因需要精确到每个 Agent、每个工具调用:
- 每个 Span 记录自己的 token 消耗和美元成本
- 通过 Parent-Child 关系,自动汇总到父 Agent
- 最终在 Trace 级别,可以看到总成本和每个 Agent 的成本占比
from opentelemetry import trace, context
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
import json
# 配置 OTel
provider = TracerProvider()
exporter = OTLPSpanExtractor(endpoint="http://localhost:4317")
provider.add_span_processor(BatchSpanProcessor(exporter))
trace.set_tracer_provider(provider)
tracer = trace.get_tracer("multi-agent-system")
class AgentMessage:
"""Agent 间通信的消息格式,携带 Trace Context"""
def __init__(self, content: str, trace_context: dict = None):
self.content = content
self.trace_context = trace_context or {}
class ResearchAgent:
"""研究 Agent - 负责信息收集"""
def __init__(self):
self.name = "research-agent"
def process(self, message: AgentMessage) -> AgentMessage:
# 从消息中恢复父 Trace Context
ctx = context.get_current()
if message.trace_context:
ctx = trace.get_current_span().get_span_context()
with tracer.start_as_current_span(
f"agent.{self.name}.process",
context=ctx,
attributes={
"agent.id": self.name,
"agent.role": "research",
"agent.input.preview": message.content[:100],
}
) as span:
# 执行研究任务
research_result = self._do_research(message.content)
span.set_attribute("llm.token.input_tokens", 2000)
span.set_attribute("llm.token.output_tokens", 1500)
span.set_attribute("llm.cost", 0.015)
# 创建下游消息,携带当前 Trace Context
return AgentMessage(
content=research_result,
trace_context={"trace_id": span.get_span_context().trace_id}
)
def _do_research(self, query: str) -> str:
return f"Research results for: {query[:50]}"
class WritingAgent:
"""写作 Agent - 基于研究结果生成内容"""
def __init__(self):
self.name = "writing-agent"
def process(self, message: AgentMessage) -> AgentMessage:
with tracer.start_as_current_span(
f"agent.{self.name}.process",
attributes={
"agent.id": self.name,
"agent.role": "writing",
"agent.input.preview": message.content[:100],
}
) as span:
# 执行写作任务
written_content = self._do_writing(message.content)
span.set_attribute("llm.token.input_tokens", 3000)
span.set_attribute("llm.token.output_tokens", 2500)
span.set_attribute("llm.cost", 0.025)
return AgentMessage(content=written_content)
def _do_writing(self, research: str) -> str:
return f"Article based on: {research[:50]}"
class ReviewAgent:
"""审核 Agent - 检查内容质量"""
def __init__(self):
self.name = "review-agent"
def process(self, message: AgentMessage) -> str:
with tracer.start_as_current_span(
f"agent.{self.name}.process",
attributes={
"agent.id": self.name,
"agent.role": "review",
}
) as span:
score = self._review(message.content)
span.set_attribute("review.score", score)
span.set_attribute("llm.cost", 0.008)
return f"Reviewed (score: {score}): {message.content[:50]}"
def _review(self, content: str) -> float:
return 0.85
# 编排:串联三个 Agent
def run_pipeline(user_request: str):
with tracer.start_as_current_span("pipeline.orchestrate") as root:
root.set_attribute("pipeline.input", user_request[:100])
# Agent 1: 研究
research = ResearchAgent()
msg1 = AgentMessage(user_request)
msg2 = research.process(msg1)
# Agent 2: 写作
writer = WritingAgent()
msg3 = writer.process(msg2)
# Agent 3: 审核
reviewer = ReviewAgent()
final = reviewer.process(msg3)
root.set_attribute("pipeline.status", "completed")
return final
result = run_pipeline("写一篇关于 AI Agent 可观测性的深度分析")
print(result)💡 一句话理解
多 Agent 追踪的关键是 Trace Context 传播。无论 Agent 之间用什么方式通信(HTTP、消息队列、共享存储),都要确保 Trace ID 正确传递。
⚠️ 常见踩坑
多 Agent 系统中,一个请求可能产生 50+ Span。确保存储层能处理这种扇出,否则会导致 Trace 数据丢失。
8Agent 安全监控:检测异常行为和攻击
2026 年,Agent 安全监控已成为可观测性不可或缺的一部分。
随着 Agent 获得越来越多的工具调用权限(文件读写、API 调用、代码执行),安全风险也急剧增加。Agent 安全监控需要覆盖三个层面:
层面一:提示注入检测(Prompt Injection Detection)
提示注入是 Agent 面临的最常见攻击。2026 年的攻击手段包括:
- 直接注入:用户在输入中嵌入恶意指令
- 间接注入:通过 Agent 检索的外部数据(网页、文档)注入指令
- 多步注入:通过多次对话逐步引导 Agent 执行恶意操作
检测策略:
层面二:数据泄露防护(Data Loss Prevention)
Agent 可能在输出中泄露敏感信息:
- 训练数据中的个人信息
- 检索上下文中的机密数据
- 工具调用返回的私有信息
监控方式:
- 输出扫描:使用正则/NER 模型检测输出中的敏感信息
- 差分隐私:在输出中添加噪声,防止精确信息泄露
- 访问控制:限制 Agent 能访问的数据范围
层面三:行为异常检测(Behavioral Anomaly Detection)
Agent 可能因为模型错误或对抗攻击而产生异常行为:
- 循环检测:Agent 反复调用同一个工具或进入死循环
- 权限越界:Agent 尝试执行超出授权范围的操作
- 资源滥用:Agent 消耗异常大量的 token 或 API 调用
2026 年 6 月,NSA 发布了《Model Context Protocol 安全设计考量》指南,专门针对 Agent 协议的安全监控提出了建议框架。
💡 一句话理解
安全监控的最小可行方案:1) 输入长度限制 + 关键词过滤 2) 工具调用频率限制 3) 输出敏感信息正则扫描。先做这三个,再逐步完善。
⚠️ 常见踩坑
Agent 的安全监控不能只靠规则——攻击者总能绕过正则。结合 LLM-based 的安全分类器,能检测更隐蔽的攻击。
9从 0 到 1 搭建 Agent 可观测性:分阶段实施指南
不要试图一步到位搭建完整的可观测性体系。 分阶段实施,逐步完善。
第一阶段:基础追踪(第 1-2 周)
目标:看见 Agent 的每一步操作
验收标准:能在 Dashboard 中看到任意一次请求的完整执行链。
第二阶段:成本监控(第 3-4 周)
目标:知道每个请求花了多少钱
验收标准:能回答「昨天花了多少钱」「哪个用户成本最高」这类问题。
第三阶段:质量评估(第 5-8 周)
目标:知道 Agent 的输出质量如何
- 建立 LLM-as-Judge 评估管道
- 定义评估维度(相关性、准确性、完整性、安全性)
- 对生产流量按比例采样评估
- 建立质量基线和漂移检测
验收标准:能回答「这周 Agent 质量有没有下降」这类问题。
第四阶段:高级功能(第 9-12 周)
目标:生产级安全监控和自动化响应
- 部署提示注入检测
- 建立行为异常检测
- 配置自动化告警和响应
- 接入 OpenTelemetry 统一数据管道
验收标准:能在 Agent 出现异常行为的 5 分钟内收到告警。
| 阶段 | 时间 | 核心能力 | 工具选择 | 验收标准 |
|---|---|---|---|---|
| 1-2 周 | Trace 浏览 | Langfuse/LangSmith | 看到完整执行链 |
| 3-4 周 | 成本归因 | Langfuse + Grafana | 回答成本问题 |
| 5-8 周 | LLM-as-Judge | LangSmith/Braintrust | 检测质量漂移 |
| 9-12 周 | 异常检测 | Arize + 自定义 | 5 分钟内告警 |
💡 一句话理解
第一阶段最重要的不是选哪个平台,而是「开始追踪」。哪怕只是最简单的日志,也比完全没有可观测性强 100 倍。
⚠️ 常见踩坑
不要跳过第一阶段直接做评估。没有追踪数据,评估就是无源之水。
102026 年 Agent 可观测性的前沿趋势
Agent 可观测性仍在快速演进。以下是 2026 年下半年值得关注的趋势。
趋势一:Agent Trajectory Replay(轨迹回放)
传统的 Trace 是静态的——你只能看到发生了什么。2026 年的新方向是「轨迹回放」:
- 完整记录 Agent 的执行环境(模型版本、工具状态、上下文)
- 支持「重放」某次 Agent 执行,观察在相同输入下的不同行为
- 用于调试、回归测试、合规审计
趋势二:Automated Eval Generation(自动评估生成)
手动编写评估标准太慢。2026 年的趋势是从生产数据自动生成评估用例:
- 从用户反馈中提取「好」和「坏」的样本
- 自动生成评估测试集
- 持续更新评估标准
Latitude 的 GEPA(Generated Eval from Production Annotated failures)是这一方向的代表。
趋势三:Agent Observability as Code(可观测性即代码)
将 Agent 的可观测性配置纳入 CI/CD:
- 评估标准版本化
- 追踪配置代码化
- 质量门禁集成到部署管道
趋势四:跨组织 Agent 追踪标准
随着 A2A(Agent-to-Agent)协议的发展,跨组织的 Agent 追踪需求浮现:
- 公司 A 的 Agent 调用公司 B 的 Agent,如何追踪?
- 需要标准化的 Trace Context 传播协议
- W3C Trace Context 的 Agent 扩展正在讨论中
趋势五:实时 Agent Guardrails(实时护栏)
从事后监控走向实时干预:
- 在 Agent 执行过程中实时检测异常
- 自动中断危险的 Agent 行为
- 在不中断用户体验的前提下实施安全策略
💡 一句话理解
关注 OpenTelemetry 的 Agent 语义约定进展。一旦标准化完成,将大幅降低多平台迁移成本。
⚠️ 常见踩坑
Agent 可观测性的工具生态仍在快速变化。不要过度投资于某个平台的专有功能,优先选择基于 OTel 的开放方案。