Production AI | Home

Agent Evaluation 深度技术博客：从“LLM 能回答”到“Agent 真正可用”

Wed, 05 Aug 2026 00:00:00 +0000

Agent Evaluation 深度技术博客：从“LLM 能回答”到“Agent 真正可用”

一、引言：为什么 Agent 必须有 Evaluation？

传统软件系统通常通过：

Unit Test
Integration Test
End-to-End Test
Performance Test
Security Test

判断系统是否可靠。

例如：

Input
 ↓
Function
 ↓
Expected Output

只要：

Actual Output == Expected Output

测试就可以通过。

但是 Agent 完全不同。

一个 Agent 的执行过程可能是：

User
 ↓
Agent
 ↓
LLM
 ↓
RAG
 ↓
Tool A
 ↓
LLM
 ↓
Tool B
 ↓
Agent B
 ↓
LLM
 ↓
Final Answer

即使同一个问题：

Input = "帮我分析这家公司今年的财务情况"

Agent 每次可能：

使用不同的 Tool
检索不同的文档
调用不同的 Agent
产生不同的中间步骤
使用不同的模型
输出不同的答案

因此传统：

Input → Expected Output

开始失效。

Agent Evaluation 要解决的问题变成：

Agent 是否完成了任务？为什么完成？哪里失败？答案质量如何？成本是否合理？行为是否安全？

因此可以给出一个定义：

Agent Evaluation 是对 Agent 的输入理解、推理过程、工具选择、知识检索、协作行为、最终输出、成本、安全性和业务结果进行系统性度量与判断的工程体系。

二、Agent Evaluation 与传统 Testing 的区别

这是理解 Evaluation 的第一关键点。

传统 Software Testing	Agent Evaluation
Expected Output	Expected Outcome
Deterministic	Probabilistic
Function Correctness	Task Correctness
Unit Test	Component Evaluation
Integration Test	Workflow Evaluation
E2E Test	Agent Evaluation
Assertion	Scoring
Pass / Fail	Score / Grade
Bug	Behavioral Failure
Regression Test	Evaluation Regression
Performance	Quality + Latency + Cost

传统测试关注：

代码对不对？

Agent Evaluation 更关注：

Agent 行为是否合理？
最终任务是否成功？

三、Agent Evaluation 的核心模型

一个完整的 Agent Evaluation 可以抽象为：

 Agent Evaluation
 |
 +----------------+----------------+
 | | |
 Input Process Output
 | | |
 Task/Data Reasoning Answer
 Context Tool Call Result
 Retrieval Action
 Planning
 |
 v
 Quality
 |
 +----------------+----------------+
 | | |
 Correctness Relevance Safety
 | | |
 +----------------+----------------+
 |
 v
 Metrics
 |
 +----------------+----------------+
 | | |
 Quality Cost Latency

最终评价的不只是：

Answer

而是：

Input
 +
Context
 +
Execution
 +
Output
 +
Outcome

四、Agent Evaluation 的六个维度

一个成熟的 Agent Evaluation Framework，至少应该包含六个维度：

1. Correctness
2. Relevance
3. Faithfulness
4. Tool / Process Quality
5. Safety
6. Efficiency

下面逐一分析。

五、Correctness：答案正确吗？

这是最基本的 Evaluation。

例如：

Question:
What is 15 * 8?

Agent:
120

可以直接判断：

Correct = true

但是现实中的 Agent：

Question:
What caused the production incident?

答案可能不是简单的：

true / false

而是：

0.0 ~ 1.0

例如：

Correctness = 0.92

六、Exact Match

对于某些任务，可以使用：

Exact Match

例如：

Expected:
SUCCESS

Actual:
SUCCESS

结果：

适用于：

分类
标签
JSON
SQL
数学
固定格式输出

但是不适用于：

开放式问答
文章生成
复杂分析
Agent Task

七、Semantic Similarity

对于自然语言，可以比较：

Expected Answer
 |
 v
Embedding
 |
 v
Vector

以及：

Actual Answer
 |
 v
Embedding
 |
 v
Vector

计算：

Cosine Similarity

例如：

Expected:
Redis is an in-memory data store.

Actual:
Redis primarily stores data in memory.

语义高度接近：

Similarity = 0.94

但是：

Semantic Similarity ≠ Correctness。

两个错误答案可能也具有很高的语义相似度。

八、LLM-as-a-Judge

因此 Agent Evaluation 中非常重要的一种方式：

LLM-as-a-Judge

架构：

 Agent
 |
 v
 Agent Output
 |
 v
 Judge LLM
 |
 +----------+----------+
 | | |
 v v v
 Correctness Relevance Safety
 | | |
 +----------+----------+
 |
 v
 Score

例如：

{
 "correctness": 0.92,
 "relevance": 0.95,
 "completeness": 0.87,
 "safety": 1.0,
 "overall": 0.93
}

九、Judge Prompt 如何设计？

一个 Judge 不应该简单：

Is this answer correct?

而应该定义明确的 Rubric。

例如：

You are an expert evaluator.

Evaluate the agent response according to:

1. Correctness
 - Is the information factually correct?

2. Relevance
 - Does the answer directly address the question?

3. Completeness
 - Are important aspects missing?

4. Groundedness
 - Is the answer supported by the provided context?

Score each dimension from 0 to 1.

Return JSON only.

最终：

{
 "correctness": 0.9,
 "relevance": 0.95,
 "completeness": 0.8,
 "groundedness": 0.93
}

十、为什么 LLM Judge 不能盲目信任？

因为：

Judge 本身也是一个概率模型。

它可能出现：

Judge Bias
Position Bias
Verbosity Bias
Self-preference Bias
Prompt Sensitivity

例如：

Answer A:
非常详细，但核心错误。

Answer B:
简洁，但完全正确。

Judge 可能因为 Answer A 更详细而给更高分。

因此不能：

Agent LLM
 ↓
Judge LLM
 ↓
100% Trust

更合理：

LLM Judge
 +
Rules
 +
Reference
 +
Human Evaluation
 +
Statistical Analysis

十一、Reference-Based Evaluation

如果存在标准答案：

Question
 |
 +---- Reference Answer
 |
 +---- Agent Answer

可以进行比较。

例如：

Reference:
Redis uses an in-memory data structure
store and supports persistence.

Agent:
Redis is an in-memory data store
with persistence capabilities.

可以判断：

Correctness
Completeness
Semantic Similarity

十二、Reference-Free Evaluation

现实中很多 Agent 没有标准答案。

例如：

写一份技术方案
分析这个事故
设计一个系统架构
总结会议
制定旅行计划

这时候：

Expected Answer

很难预先定义。

所以采用：

Reference-Free Evaluation

评价：

Relevance
Quality
Coherence
Safety
Completeness

这也是 LLM Judge 最常见的应用场景之一。

十三、RAG Evaluation

Agent Platform 中经常会出现：

Agent
 ↓
Retriever
 ↓
Vector DB
 ↓
Documents
 ↓
LLM

那么答案错误，到底是谁的问题？

可能是：

Retriever 错了

也可能：

LLM 推理错了

所以 RAG Evaluation 至少需要拆成两个阶段。

十四、Retrieval Evaluation

核心指标：

Precision

检索结果中：

Relevant Documents
------------------
Retrieved Documents

Recall

Relevant Documents Retrieved
----------------------------
All Relevant Documents

例如：

100 个相关文档
检索出 80 个

那么：

Recall = 80%

十五、Top-K Evaluation

例如：

Top K = 5

Retriever 返回：

D1
D2
D3
D4
D5

其中：

D1 Relevant
D2 Relevant
D3 Irrelevant
D4 Relevant
D5 Irrelevant

可以计算：

Precision@5 = 3 / 5 = 60%

十六、MRR

如果我们关心：

第一个正确文档出现得有多快？

可以使用：

Mean Reciprocal Rank

例如：

Rank 1 → Relevant

则：

RR = 1

如果：

Rank 5 → Relevant

则：

RR = 1/5

MRR 非常适合：

Search
RAG
Knowledge Retrieval

十七、NDCG

如果搜索结果存在：

Highly Relevant
Relevant
Partially Relevant
Irrelevant

可以使用：

NDCG

它不仅考虑：

Relevant / Irrelevant

还考虑：

Ranking Position

因此适合：

Enterprise Search
RAG
Recommendation
Knowledge Retrieval

十八、Faithfulness：Agent 有没有胡说？

这是 RAG/Agent Evaluation 中非常关键的指标。

例如 Context：

Redis is an in-memory data store.

Agent：

Redis was created by Google.

虽然回答：

语言流畅

但：

Faithfulness = 0

Faithfulness 关注：

回答是否能够被提供的上下文支持。

因此：

Context
 ↓
Claims
 ↓
Evidence

需要判断：

Claim
 |
 +-- Supported → TRUE
 |
 +-- Unsupported → FALSE

十九、Hallucination Evaluation

可以进一步定义：

Hallucination Rate

例如：

100 个回答
12 个存在无法验证的事实

则：

Hallucination Rate = 12%

生产环境可以设置：

Hallucination Rate < 1%

对于：

金融
医疗
法律
企业知识库

尤其重要。

二十、Tool Evaluation

Agent 最大的特点之一：

会调用 Tool。

因此必须评估：

是否选择正确 Tool？
参数是否正确？
调用顺序是否正确？
是否需要调用 Tool？
是否调用太多次？

二十一、Tool Selection Accuracy

例如系统提供：

SearchTool
SQLTool
CalculatorTool
EmailTool

用户：

查询数据库中的订单

正确：

SQLTool

Agent：

SearchTool

则：

Tool Selection = FAIL

可以定义：

Tool Selection Accuracy
=
Correct Tool Calls
/
Total Tool Calls

二十二、Tool Argument Evaluation

假设：

{
 "tool": "get_order",
 "order_id": "12345"
}

Agent 生成：

{
 "tool": "get_order",
 "order_id": "12354"
}

Tool 本身正常。

但是 Agent 参数错误。

所以必须把：

Tool Selection

和：

Tool Argument

分开评估。

二十三、Tool Call Efficiency

Agent 可能：

Search
Search
Search
Search
Search

最终才找到答案。

虽然：

Task Success = TRUE

但：

Cost ↑
Latency ↑

因此需要：

Average Tool Calls
Tool Calls / Successful Task
Redundant Tool Calls
Retry Rate

例如：

Agent A
Success = 95%
Tool Calls = 3.2

Agent B
Success = 96%
Tool Calls = 15.7

从生产角度：

Agent A

可能明显更优秀。

二十四、Agent Planning Evaluation

复杂 Agent 通常：

Goal
 ↓
Plan
 ↓
Step 1
 ↓
Step 2
 ↓
Step 3
 ↓
Result

因此可以评价：

Plan Correctness
Plan Completeness
Step Efficiency
Plan Stability

例如目标：

完成一次数据分析

Agent：

1. 获取数据
2. 清洗数据
3. 分析数据
4. 生成报告

这是合理计划。

如果：

1. 生成报告
2. 获取数据
3. 删除数据

就是明显异常。

二十五、Agent Trajectory Evaluation

Agent Evaluation 不应该只看：

Final Answer

还应该看：

Trajectory

即：

Agent 是怎么走到最终结果的。

例如：

Task
 |
 +-- Plan
 |
 +-- Tool A
 |
 +-- Tool B
 |
 +-- Tool C
 |
 +-- Replan
 |
 +-- Tool D
 |
 +-- Final

可以定义：

Trajectory Score

评价：

Correctness
Efficiency
Tool Usage
Planning

二十六、Agent Outcome Evaluation

最终最重要的问题：

任务完成了吗？

例如：

用户：
帮我创建一个会议并邀请团队成员。

Agent：

调用 Calendar Tool
调用 Email Tool

最终：

Calendar Created = TRUE
Invitation Sent = TRUE

那么：

Task Success = TRUE

这比单纯：

LLM Output Quality = 0.95

更重要。

二十七、Business Outcome Evaluation

企业最终关心的不是：

LLM Accuracy = 93%

而是：

业务结果怎么样？

例如客服 Agent：

Answer Quality
 ↓
Customer Resolution
 ↓
Customer Satisfaction
 ↓
Cost Reduction

Coding Agent：

Code Quality
 ↓
Tests Passed
 ↓
PR Accepted
 ↓
Production Defects

所以：

Business Outcome 是 Agent Evaluation 的最高层。

二十八、Evaluation Pyramid

可以建立一个非常重要的 Evaluation Pyramid：

 Business Outcome
 ▲
 |
 Task Success
 |
 Agent Behavior
 |
 Tool / RAG / Planning
 |
 LLM Quality
 |
 Infrastructure Metrics

越往上：

越接近业务价值

越往下：

越接近系统实现

因此不能只做：

LLM Evaluation

而应该做：

End-to-End Agent Evaluation

二十九、Online Evaluation 与 Offline Evaluation

这是 Agent Evaluation 架构中的另一个核心概念。

Offline Evaluation

在上线前：

Dataset
 ↓
Agent
 ↓
Evaluation
 ↓
Score

例如：

1000 Test Cases

用于：

Regression
Model Selection
Prompt Optimization
Agent Version Comparison

三十、Online Evaluation

上线以后：

Real User
 ↓
Agent
 ↓
Production Trace
 ↓
Evaluation

例如：

Production Tasks
 ↓
Sampling
 ↓
Judge
 ↓
Quality Score

用于：

Drift Detection
Quality Monitoring
Production Regression

三十一、Offline + Online

完整体系：

 Evaluation
 |
 +-----------+-----------+
 | |
 Offline Online
 | |
 Dataset Production
 | |
 v v
 Regression Monitoring
 | |
 +-----------+-----------+
 |
 v
 Improvement

这就形成：

Evaluation Loop

三十二、Evaluation Dataset

没有 Dataset：

Evaluation

很难工程化。

一个 Dataset 可以：

{
 "id": "case-001",
 "input": "What is Redis?",
 "context": [
 "Redis is an in-memory data store."
 ],
 "expected": "Redis is an in-memory data store."
}

进一步：

{
 "id": "case-002",
 "input": "...",
 "tools": ["search", "sql"],
 "expected_tool": "sql"
}

三十三、Dataset 不应该只有 Happy Path

很多团队的 Evaluation Dataset：

90% Normal
10% Edge Case

这是不够的。

应该覆盖：

Normal Cases
Edge Cases
Ambiguous Cases
Adversarial Cases
Failure Cases
Security Cases
Long Context
Multi-turn
Tool Failure
Network Failure
LLM Failure

例如：

Tool Timeout
 ↓
Agent 是否 Retry？

Tool Returns Invalid JSON
 ↓
Agent 是否 Recovery？

Knowledge Not Found
 ↓
Agent 是否 Hallucinate？

这些才是真正有价值的 Evaluation Case。

三十四、Evaluation Dataset 分层

建议：

Dataset
 |
 +-- Smoke Set
 |
 +-- Regression Set
 |
 +-- Golden Set
 |
 +-- Adversarial Set
 |
 +-- Production Sample

Smoke Set

几十个核心 Case。

用于：

每次部署

Regression Set

几百/几千 Case。

用于：

版本升级

Golden Set

人工高质量标注。

用于：

核心质量评估

Adversarial Set

专门测试：

Prompt Injection
Tool Abuse
Hallucination
Boundary

Production Sample

真实生产数据采样。

用于：

线上质量

三十五、Evaluation Regression

Agent 系统最容易发生一个问题：

Prompt V1
 ↓
Quality = 92%

升级：

Prompt V2
 ↓
Quality = 95%

看起来更好了。

但是：

Tool Selection
92% → 85%

这就是：

Hidden Regression。

所以 Evaluation 必须支持：

Version Comparison

例如：

 V1 V2
Correctness 92% 95%
Relevance 90% 93%
Tool Accuracy 94% 85%
Cost $0.08 $0.12
Latency 5.2s 6.8s

最终：

Overall Improvement?

不能只看一个指标。

三十六、Multi-Dimensional Evaluation

建议建立 Scorecard：

Agent Scorecard

Correctness 0.94
Relevance 0.92
Faithfulness 0.96
Tool Accuracy 0.91
Safety 0.99
Efficiency 0.88
Cost 0.82

最终：

Overall Score

可以通过加权：

Score =
0.30 * Correctness
+ 0.20 * Relevance
+ 0.20 * Faithfulness
+ 0.10 * Tool Accuracy
+ 0.10 * Safety
+ 0.10 * Efficiency

但是：

不建议盲目使用一个 Overall Score。

因为：

Safety = 0.5

不能被：

Correctness = 1.0

平均掉。

对于某些指标应该使用：

Hard Constraint

例如：

Safety < 0.99
 ↓
FAIL

三十七、Evaluation Gateway

在企业 Agent Platform 中，可以建立：

 Agent
 |
 v
 Evaluation Gateway
 |
 +-----------+-----------+
 | | |
 Quality Safety Cost
 | | |
 +-----------+-----------+
 |
 Pass / Reject

例如：

Agent Version 2.3
 ↓
Regression Test
 ↓
Quality = 94%
Safety = 99.9%
Cost = $0.07
 ↓
PASS
 ↓
Production

如果：

Quality = 82%

则：

BLOCK RELEASE

这就是：

Evaluation-driven CI/CD。

三十八、Agent Evaluation CI/CD

可以设计成：

Git Push
 ↓
Build
 ↓
Unit Test
 ↓
Agent Evaluation
 ↓
Regression
 ↓
Security Evaluation
 ↓
Cost Evaluation
 ↓
Quality Gate
 ↓
Deploy

例如：

Quality >= 0.90
Safety >= 0.99
Task Success >= 0.95
Cost <= $0.10

全部满足：

Deploy

否则：

Reject

三十九、Evaluation 与 Observability 的关系

这是非常关键的一点。

Observability：

发生了什么？

Evaluation：

做得好不好？

例如：

Trace
 |
 +-- LLM
 +-- Tool
 +-- RAG
 +-- A2A

Observability 告诉你：

Agent 调用了 Tool A。

Evaluation 告诉你：

Agent 本来应该调用 Tool B。

因此：

Observability
 ↓
Execution Data
 ↓
Evaluation
 ↓
Quality

两者必须结合。

四十、Evaluation + Observability 架构

完整架构可以设计成：

 Agent Runtime
 |
 OpenTelemetry
 |
 +--------------------+-------------------+
 | | |
 Trace Metrics Logs
 | | |
 Tempo Prometheus Loki
 | | |
 +--------------------+-------------------+
 |
 v
 Evaluation Engine
 |
 +--------------------+-------------------+
 | | |
 Rule Evaluator LLM Judge Custom Evaluator
 | | |
 +--------------------+-------------------+
 |
 v
 Quality Metrics
 |
 +--------------------+-------------------+
 | | |
 Dashboard Regression Governance

这已经非常接近企业级：

Agent Quality Platform。

四十一、Evaluation Engine 的核心设计

可以抽象为：

Evaluation Engine
 |
 +-- Dataset Manager
 |
 +-- Runner
 |
 +-- Evaluator
 |
 +-- Scorer
 |
 +-- Reporter
 |
 +-- Regression Detector

四十二、Evaluation Runner

Runner 负责：

Load Dataset
 ↓
Invoke Agent
 ↓
Capture Trace
 ↓
Store Result
 ↓
Run Evaluators

例如：

for case in dataset:

 result = agent.execute(case.input)

 trace = observability.getTrace(result)

 scores = evaluator.evaluate(
 case,
 result,
 trace
 )

 store(scores)

四十三、Evaluator 接口设计

一个比较好的架构可以抽象成：

public interface Evaluator {

 EvaluationResult evaluate(
 EvaluationCase testCase,
 AgentResult result,
 AgentTrace trace
 );
}

不同 Evaluator：

CorrectnessEvaluator
RelevanceEvaluator
FaithfulnessEvaluator
ToolEvaluator
SafetyEvaluator
CostEvaluator
LatencyEvaluator

这样：

Evaluator

就成为：

可插拔的 Evaluation Plugin。

四十四、Evaluation Result

例如：

{
 "caseId": "case-001",
 "agentVersion": "2.1.0",
 "scores": {
 "correctness": 0.95,
 "relevance": 0.92,
 "faithfulness": 0.97,
 "tool_accuracy": 1.0,
 "safety": 1.0
 },
 "latency_ms": 4300,
 "tokens": 3250,
 "cost": 0.043,
 "passed": true
}

这样 Evaluation 数据本身就可以进入：

ClickHouse

进行分析。

四十五、Evaluation 的统计学问题

Agent Evaluation 不能只跑：

10 cases

然后宣布：

Accuracy = 90%

因为：

样本太小

可能导致：

统计偏差

例如：

10 Cases
9 Success

看起来：

90%

但生产：

10000 Cases

可能完全不同。

因此需要：

Large Dataset
Confidence Interval
Statistical Significance

尤其是：

A/B Testing
Model Comparison
Prompt Comparison

四十六、Agent A/B Evaluation

例如：

Prompt A
VS
Prompt B

随机：

50% → A
50% → B

然后比较：

Task Success
Quality
Cost
Latency
User Satisfaction

例如：

 A B

Success 92% 95%
Quality 89% 94%
Cost $0.10 $0.08
Latency 5.8s 4.9s

显然：

更有优势。

四十七、Human Evaluation

在高价值场景：

LLM Judge

不能完全替代：

Human

可以采用：

Human
 +
LLM Judge
 +
Rule

例如：

10000 Production Cases
 |
 v
 Sampling
 |
 v
 500 Cases
 |
 +----+----+
 | |
 v v
LLM Judge Human
 | |
 +----+----+
 |
 v
Calibration

通过 Human Evaluation 校准 Judge。

四十八、Judge Calibration

例如：

Human Score
 vs
LLM Judge Score

如果：

Correlation = 0.92

说明 Judge 比较可靠。

如果：

Correlation = 0.60

说明：

Judge Prompt

需要重新设计。

四十九、Evaluation 的数据闭环

成熟平台最终应该形成：

Production
 ↓
Trace
 ↓
Sample
 ↓
Evaluation
 ↓
Bad Cases
 ↓
Dataset
 ↓
Regression Test
 ↓
Prompt / Model / Agent Improvement
 ↓
Production

这是一条非常重要的：

Agent Quality Flywheel。

五十、Failure Case Mining

生产系统里最有价值的数据通常不是：

Successful Cases

而是：

Failed Cases

可以自动挖掘：

Low Score
Tool Failure
Hallucination
High Cost
Long Latency
User Negative Feedback

形成：

Failure Dataset

然后：

Failure Dataset
 ↓
Regression Test

最终让：

线上事故成为下一版本的测试用例。

五十一、Evaluation 与 Agent Runtime 的结合

Agent Runtime 不应该只负责：

Execute

还应该输出：

Execution Context

例如：

AgentRuntime
 |
 +-- Task
 +-- Step
 +-- LLM
 +-- Tool
 +-- Memory
 +-- A2A
 +-- Result
 +-- Trace

Evaluation Engine 读取：

Agent Execution Graph

然后分析：

Outcome
Trajectory
Tool
Reasoning
Cost

所以：

Agent Runtime 是 Evaluation 的数据源。

五十二、Evaluation 与 Agent Platform 的关系

企业级 Agent Platform 可以设计成：

 Agent Platform
 |
 +-----------------+-----------------+
 | | |
 Agent Runtime Evaluation Observability
 | | |
 | | |
 +-----------------+-----------------+
 |
 AgentOps
 |
 +-----------------+-----------------+
 | | |
 Release Governance Analytics

其中：

Observability

负责：

What happened?

Evaluation

负责：

How good?

AgentOps

负责：

What should we do?

五十三、Agent Evaluation 的成熟度模型

可以把企业 Evaluation 分成五级。

Level 0：No Evaluation

Agent
 ↓
Production

完全依赖用户反馈。

Level 1：Manual Evaluation

Agent
 ↓
Human Review

适合 PoC。

Level 2：Automated Evaluation

Agent
 ↓
Automated Dataset
 ↓
Score

开始工程化。

Level 3：Continuous Evaluation

Production
 ↓
Sampling
 ↓
Evaluation
 ↓
Regression

进入生产质量体系。

Level 4：Evaluation-Driven Agent Platform

Develop
 ↓
Evaluate
 ↓
Deploy
 ↓
Observe
 ↓
Evaluate
 ↓
Govern
 ↓
Improve

这是企业级 Agent Platform 的目标。

五十四、Evaluation 最终应该解决什么？

如果让我把整个 Agent Evaluation 总结成一张图：

 Agent
 |
 v
 Agent Execution
 |
 +----------------+----------------+
 | | |
 LLM Tool RAG
 | | |
 +----------------+----------------+
 |
 v
 Trace
 |
 v
 Evaluation Engine
 |
 +-------------------+-------------------+
 | | |
 Outcome Behavior Quality
 | | |
 Task Success Tool Accuracy Correctness
 Business Result Planning Relevance
 Efficiency Faithfulness
 Safety Groundedness
 |
 v
 Score
 |
 +------------+------------+
 | |
 Regression Governance
 | |
 v v
 Improve Agent Control Agent

五十五、结语：Evaluation 是 Agent Engineering 的“质量操作系统”

传统 AI Application 的核心问题是：

如何让 LLM 回答得更好？

Agent Engineering 的核心问题正在变成：

如何证明 Agent 做得足够好？

这是两个完全不同的问题。

一个成熟 Agent 系统最终需要建立：

 Agent Quality
 |
 +-----------+-----------+
 | | |
 Correctness Safety Outcome
 | | |
 +-----------+-----------+
 |
 +-------+-------+
 | | |
 Quality Cost Latency
 | | |
 +-------+-------+
 |
 Evaluation
 |
 +----------+----------+
 | |
 Offline Online
 | |
 Regression Monitoring
 | |
 +----------+----------+
 |
 AgentOps
 |
 Governance

因此，Evaluation 并不是 Agent Platform 中一个独立的测试模块，而应该成为贯穿 Agent 生命周期的质量基础设施。

从架构师视角来看，未来的 Agent Platform 至少应该形成这样一条完整技术链：

Agent Development
 ↓
Agent Runtime
 ↓
OpenTelemetry
 ↓
Trace / Event
 ↓
Evaluation Engine
 ↓
Quality Metrics
 ↓
Regression Testing
 ↓
CI/CD Quality Gate
 ↓
Production
 ↓
Online Evaluation
 ↓
Failure Mining
 ↓
Dataset
 ↓
Agent Improvement

最终形成：

Observe → Evaluate → Govern → Improve

这也是 Agent Engineering 从“Prompt Engineering”走向“Platform Engineering”的一个重要标志。

Agent Observability：构建可观测、可诊断、可治理的 Agent Platform

Wed, 05 Aug 2026 00:00:00 +0000

Agent Observability 深度技术博客：构建可观测、可诊断、可治理的 Agent Platform

一、引言：为什么传统 Observability 已经不够用了？

在传统微服务系统中，我们通常认为：

Observability
 |
 +-- Metrics
 +-- Logs
 +-- Traces

例如一个 HTTP 请求：

User
 |
 v
API Gateway
 |
 v
Order Service
 |
 v
Payment Service
 |
 v
Database

我们可以通过：

Metrics 看 QPS、Latency、Error Rate
Logs 看错误信息
Traces 看请求经过哪些服务

这套体系非常成熟。

但是进入 Agent 时代以后，一个请求可能变成：

User
 |
 v
Agent
 |
 +---- LLM Call
 |
 +---- Tool Call
 |
 +---- Memory Retrieval
 |
 +---- LLM Call
 |
 +---- Agent B
 |
 +---- Tool Call
 |
 +---- LLM Call
 |
 +---- Final Response

这时候传统的：

HTTP Trace

已经无法完整回答：

Agent 为什么做出了这个决定？

更重要的是，Agent 的失败可能不是传统意义上的：

HTTP 500

而可能是：

Agent 选择了错误的 Tool
Agent 使用了错误的参数
Agent 调用了过多 Tool
Agent 陷入循环
Agent 获取了错误的 Memory
LLM 输出格式错误
RAG 检索结果不相关
Agent 花费过高
Agent 推理步骤过长
Agent 调用了没有必要的 Agent

因此：

Agent Observability 不是简单地给 Agent 加上 Metrics、Logs、Traces，而是要对 Agent 的“决策、执行、协作和结果”进行完整观测。

二、Agent Observability 到底是什么？

可以给出一个比较工程化的定义：

Agent Observability 是通过 Trace、Metrics、Logs、Events、LLM Telemetry、Evaluation 等手段，对 Agent 的运行状态、决策过程、工具调用、模型调用、上下文、成本和最终效果进行可观测与诊断的技术体系。

可以抽象成：

 Agent Observability
 |
 +-------------------+-------------------+
 | | |
 Signals Context Quality
 | | |
 +-----+-----+ +-----+-----+ +-----+-----+
 | | | | | | | | |
Trace Metric Log Prompt Memory Tool Eval Score Cost

这与传统 Observability 最大的区别是：

Traditional Observability
 ↓
系统发生了什么？

Agent Observability
 ↓
系统发生了什么？
为什么发生？
Agent 为什么这样决策？
Agent 最终完成得怎么样？

三、Agent Observability 的核心目标

一个成熟的 Agent Observability 平台应该回答六个问题：

1. What？

发生了什么？

例如：

Agent 调用了 Search Tool

2. When？

什么时候发生？

3. Where？

发生在哪一个 Agent / Tool / Runtime？

4. Why？

为什么调用这个 Tool？
为什么选择这个 Agent？

5. How？

Agent 是怎么一步一步完成任务的？

6. How Good？

最终结果到底好不好？

传统 Observability 主要解决：

What
When
Where

Agent Observability 必须进一步解决：

Why
How
How Good

四、Agent Observability 总体架构

一个企业级 Agent Observability 可以设计为：

 Agent Application
 |
 v
 ┌───────────────┐
 │ Agent Runtime │
 └───────┬───────┘
 |
 OpenTelemetry SDK
 |
 +-----------------+-----------------+
 | | |
 v v v
 Trace Metrics Logs
 | | |
 +-----------------+-----------------+
 |
 v
 OpenTelemetry Collector
 |
 +---------------------+---------------------+
 | | |
 v v v
 Tempo Prometheus Loki
 | | |
 +---------------------+---------------------+
 |
 v
 Grafana
 |
 +---------------------+---------------------+
 | | |
 v v v
 Trace View Metrics Dashboard Log Search
 |
 v
 Agent Evaluation Platform

如果结合 Agent Platform：

 Agent Platform
 |
 +----------------+----------------+
 | |
 Control Plane Data Plane
 |
 Agent Runtime
 |
 +------------------+-------+-------+
 | | |
 LLM MCP A2A
 | | |
 +------------------+---------------+
 |
 v
 OpenTelemetry
 |
 v
 Observability Platform

五、传统 Observability 与 Agent Observability

传统微服务	Agent
Request	Task
Service	Agent
RPC	Agent-to-Agent
API	Tool
Database	Memory / Knowledge
Request Trace	Agent Trace
HTTP Error	Agent Failure
Latency	Execution Latency
CPU / Memory	Token / Cost / Context
Logs	Agent Events
SLA	Task Completion
Unit Test	Agent Evaluation

这张表非常重要。

因为：

Agent Observability 本质上是在传统 Observability 上增加了一层 AI-aware Telemetry。

六、Agent Trace：Observability 的核心

Agent 系统最重要的能力之一：

End-to-End Agent Trace

例如：

Trace: 8f7c...

User Task
│
├── Agent: ResearchAgent
│
├── LLM: Reasoning Model
│
├── Tool: WebSearch
│
├── Tool: WebSearch
│
├── Memory Retrieval
│
├── LLM: Reasoning Model
│
├── A2A: DataAgent
│ │
│ ├── LLM
│ ├── Tool: SQL
│ └── Tool: Database
│
├── LLM
│
└── Final Response

一个 Trace 不再只是：

HTTP Request

而应该是：

Agent Execution Graph

七、Agent Trace 的数据结构

一个 Agent Trace 可以包含：

{
 "traceId": "trace-10001",
 "taskId": "task-20001",
 "agentId": "research-agent",
 "agentVersion": "3.2.1",
 "startTime": "...",
 "endTime": "...",
 "status": "COMPLETED",
 "steps": [
 {
 "type": "LLM",
 "model": "reasoning-model",
 "latencyMs": 1800,
 "inputTokens": 3200,
 "outputTokens": 850
 },
 {
 "type": "TOOL",
 "tool": "web-search",
 "latencyMs": 600
 }
 ]
}

这样我们可以进一步计算：

Total Latency
LLM Latency
Tool Latency
Memory Latency
A2A Latency
Token Usage
Cost

八、Trace Span 应该怎么设计？

传统微服务：

Span
 |
 +-- HTTP
 +-- SQL
 +-- RPC

Agent：

Span
 |
 +-- AGENT
 +-- LLM
 +-- TOOL
 +-- MEMORY
 +-- RETRIEVAL
 +-- A2A
 +-- WORKFLOW
 +-- HUMAN

例如：

Agent Span
│
├── LLM Span
│
├── Tool Span
│
├── Retrieval Span
│
├── LLM Span
│
├── A2A Span
│
└── Finalization Span

九、Agent Span 的关键 Attributes

一个 LLM Span 至少可以记录：

agent.id
agent.version

llm.provider
llm.model

llm.input_tokens
llm.output_tokens
llm.total_tokens

llm.temperature

request.id
task.id
session.id

latency
status

Tool Span：

tool.name
tool.version
tool.type
tool.latency
tool.status
tool.retry_count

A2A Span：

source.agent
target.agent
task.id
communication.protocol
latency
status

十、为什么 OpenTelemetry 非常适合 Agent？

OpenTelemetry 的核心优势在于：

Vendor Neutral
Standardized
Distributed Tracing
Metrics
Logs
Context Propagation
Collector

传统微服务：

Service A
 |
 | trace context
 v
Service B
 |
 v
Service C

Agent：

Agent A
 |
 | trace context
 v
LLM
 |
 v
Tool
 |
 v
Agent B
 |
 v
Tool

因此：

OpenTelemetry 可以成为 Agent Observability 的底层 Telemetry Standard。

尤其适合你之前关注的：

OpenTelemetry
Collector
Tempo
Prometheus
Grafana

这些技术可以直接演进到 Agent Observability。

十一、Agent Context Propagation

这是一个非常容易被忽略的问题。

例如：

Agent A
 |
 | A2A
 v
Agent B
 |
 | MCP
 v
Tool

如果 Trace Context 丢失：

Trace A
 |
 X
Agent B
 |
 X
Tool

最终 Grafana 中看到：

三个孤立 Trace

而不是：

一个完整 Trace

所以必须传播：

traceId
spanId
trace flags
baggage

形成：

Agent A
 |
 +---- Trace Context
 |
 v
 Agent B
 |
 +---- Trace Context
 |
 v
 Tool

十二、Agent Metrics

Trace 解决：

单次请求发生了什么？

Metrics 解决：

系统整体怎么样？

Agent Metrics 可以分成六类。

1. Runtime Metrics

agent_task_total
agent_task_success_total
agent_task_failure_total

agent_task_duration
agent_task_queue_depth
agent_task_active

例如：

Task Throughput = 1000/min
Task Success Rate = 97.5%
P95 Latency = 8.2s

2. LLM Metrics

llm_request_total
llm_request_duration
llm_error_total

llm_input_tokens
llm_output_tokens
llm_total_tokens

3. Tool Metrics

tool_call_total
tool_call_failure_total
tool_call_duration
tool_retry_total

4. Memory Metrics

memory_read_total
memory_write_total
memory_retrieval_latency
memory_hit_rate

5. A2A Metrics

a2a_request_total
a2a_latency
a2a_failure_total
a2a_timeout_total

6. Cost Metrics

这是 Agent 特有的重要指标：

token_cost
tool_cost
execution_cost
agent_cost
tenant_cost

例如：

Daily Agent Cost

Research Agent $32
Coding Agent $85
Data Agent $17
Customer Agent $142

十三、不要只监控 Token

很多 Agent 系统会重点监控：

Token Usage

但：

Token 并不等于价值。

例如：

Agent A
1000 tokens
完成任务

Agent B
20000 tokens
没有完成任务

单纯看 Token：

Agent A < Agent B

但实际效果：

Agent A > Agent B

因此需要建立：

Cost
+
Quality
+
Latency
+
Success

四维指标体系。

十四、Agent Quality Metrics

这是 Agent Observability 与传统 Observability 最大的区别。

传统系统：

HTTP 200

并不代表：

业务正确

Agent 更明显。

例如：

HTTP 200
Agent Response = 完整废话

系统依然是：

200 OK

但用户体验：

FAIL

因此需要：

Quality Observability。

十五、Agent Evaluation

可以定义：

Task Success Rate

例如：

1000 tasks
 |
 +-- 950 success
 +-- 50 failure

Success Rate = 95%

还可以：

Tool Selection Accuracy
Response Accuracy
Groundedness
Faithfulness
Relevance
Safety

十六、LLM-as-a-Judge

一种常见方式：

Agent Output
 |
 v
Evaluator LLM
 |
 v
Score

例如：

Accuracy 0.92
Relevance 0.95
Completeness 0.88
Safety 0.99

最终：

Agent Quality Score = 0.93

但是需要注意：

Evaluator LLM 也可能产生偏差。

因此生产环境最好组合：

Rule-based
+
Deterministic Evaluation
+
LLM-as-a-Judge
+
Human Evaluation

十七、Agent Logs

传统 Log：

INFO request received
ERROR database timeout

Agent Log 应该更加结构化：

{
 "timestamp": "...",
 "traceId": "...",
 "taskId": "...",
 "agentId": "research-agent",
 "event": "tool_call",
 "tool": "web-search",
 "status": "SUCCESS",
 "latencyMs": 520
}

十八、Agent Event

Agent 的运行过程天然可以事件化：

AgentStarted
AgentStepStarted
LLMRequestStarted
LLMRequestCompleted
ToolCallStarted
ToolCallCompleted
MemoryRead
MemoryWrite
A2ARequest
A2AResponse
HumanApprovalRequested
AgentCompleted
AgentFailed

这些 Event 可以进入：

Kafka

然后被：

Audit
Analytics
Billing
Monitoring
Evaluation

消费。

十九、Trace + Event 的区别

两者不要混淆。

Trace

回答：

一次执行是怎样发生的？

Task
 ↓
LLM
 ↓
Tool
 ↓
LLM
 ↓
Result

Event

回答：

系统中发生了哪些事实？

ToolCalled
ToolCompleted
AgentFailed

因此：

Trace = Execution View

Event = System Event View

两者结合：

Agent Runtime
 |
 +----+----+
 | |
Trace Event
 | |
 v v
Tempo Kafka

是非常强的架构组合。

二十、Agent Observability 的三层模型

可以把整个体系分成：

┌──────────────────────────────┐
│ Business Layer │
│ │
│ Success Rate │
│ Quality │
│ User Satisfaction │
│ Business Outcome │
└──────────────┬───────────────┘
 │
┌──────────────▼───────────────┐
│ AI Layer │
│ │
│ LLM │
│ Prompt │
│ Token │
│ Tool │
│ Memory │
│ Retrieval │
│ Agent Decision │
└──────────────┬───────────────┘
 │
┌──────────────▼───────────────┐
│ Infrastructure Layer │
│ │
│ CPU │
│ Memory │
│ Network │
│ Kubernetes │
│ Database │
│ Kafka │
└──────────────────────────────┘

这就是：

Business + AI + Infrastructure 三层 Observability。

二十一、Agent Debugging

假设用户说：

“这个 Agent 为什么给出了错误答案？”

传统监控只能告诉你：

HTTP 200

但是 Agent Observability 应该能够打开 Trace：

Task
 |
 +-- Prompt
 |
 +-- Memory Retrieval
 | |
 | +-- Document A
 | +-- Document B
 |
 +-- LLM
 | |
 | +-- Decision
 |
 +-- Tool Call
 |
 +-- LLM
 |
 +-- Final Response

然后发现：

Memory Retrieval
 ↓
错误 Document
 ↓
LLM
 ↓
错误推理
 ↓
错误 Answer

这才是真正的：

Agent Root Cause Analysis。

二十二、Agent Debugging 的核心问题

可以把问题定位拆成：

Input Problem
 ↓
Context Problem
 ↓
Retrieval Problem
 ↓
Reasoning Problem
 ↓
Tool Problem
 ↓
Execution Problem
 ↓
Output Problem

例如：

Input Problem

用户需求理解错误。

Context Problem

上下文不完整。

Retrieval Problem

RAG 找到了错误文档。

Reasoning Problem

LLM 推理错误。

Tool Problem

选择了错误 Tool。

Execution Problem

Tool 参数错误。

Output Problem

最终回答格式错误。

这比传统：

HTTP 500

复杂很多。

二十三、Agent Loop Detection

Agent 可能出现：

LLM
 ↓
Tool A
 ↓
LLM
 ↓
Tool A
 ↓
LLM
 ↓
Tool A

形成：

Agent Loop。

如果没有监控，可能：

Token ↑
Cost ↑
Latency ↑

最终：

Timeout

因此 Runtime 应记录：

step_count
tool_sequence
repeated_action

例如检测：

A → B → A → B → A → B

发现异常后：

STOP

或者：

REPLAN

二十四、Agent Cost Observability

企业部署 Agent 后，一个非常现实的问题：

“为什么这个月 AI 成本突然增加了 300%？”

传统 Monitoring 很难回答。

Agent Observability 可以：

Tenant
 |
 +-- Agent
 |
 +-- Model
 |
 +-- Token
 |
 +-- Tool
 |
 +-- Execution

最终得到：

Tenant A
 $1000

Research Agent
 $300

Coding Agent
 $500

Customer Agent
 $200

继续往下：

Coding Agent
 |
 +-- Model Cost
 +-- Tool Cost
 +-- Retry Cost
 +-- Failed Task Cost

这就是：

AI FinOps。

二十五、Agent SLO

传统微服务：

Availability
Latency
Error Rate

Agent 可以进一步：

Task Success Rate
Task Completion Time
Tool Success Rate
Quality Score
Cost Per Task

例如：

Agent SLO

Task Success Rate >= 98%
P95 Latency < 10s
Tool Failure Rate < 1%
Quality Score >= 0.90
Cost Per Task < $0.10

这才是企业真正需要的：

Agent SLO。

二十六、Agent Error Budget

如果：

SLO = 99%

那么：

Error Budget = 1%

可以进一步定义：

Failed Tasks
Poor Quality Tasks
Timeout Tasks
Safety Violations

而不是只统计：

HTTP 500

例如：

10000 Tasks

Allowed Failure = 100

Actual Failure = 80

Remaining Budget = 20

二十七、Agent Observability 与 Security

Observability 和 Security 有一个非常重要的冲突：

越详细的 Trace，包含的信息越多；信息越多，敏感数据泄露风险越大。

例如 LLM Prompt 可能包含：

Customer Name
Account Number
Internal Documents
Credentials
Personal Information

所以不能简单：

log(prompt)

生产环境必须考虑：

PII Masking
Data Redaction
Encryption
Access Control
Retention
Audit

例如：

Original:
Customer SSN = 123-45-6789

Trace:
Customer SSN = ***-**-6789

二十八、Prompt Observability

Prompt 是 Agent 的核心输入。

因此需要记录：

Prompt Version
System Prompt
User Prompt
Retrieved Context
Tool Result

但这里必须解决：

Sensitive Data
Token Size
Storage Cost
Privacy

一个比较合理的设计：

Prompt Metadata
 +
Prompt Hash
 +
Encrypted Content

而不是所有环境都直接保存完整 Prompt。

二十九、Agent Observability Data Pipeline

完整数据流：

Agent Runtime
 |
 v
OpenTelemetry SDK
 |
 v
OTel Collector
 |
 +----+---------+---------+
 | | |
 v v v
Trace Metric Log
 | | |
Tempo Prometheus Loki
 | | |
 +--------------+---------+
 |
 v
 Grafana
 |
 +-------+-------+
 | |
 v v
 Operations Analytics
 |
 v
 Evaluation

如果 Event 也加入：

Agent Runtime
 |
 +---- Trace
 |
 +---- Metric
 |
 +---- Log
 |
 +---- Event
 |
 v
 Kafka
 |
 +------+------+
 | | |
 Audit Billing BI

三十、Agent Observability 存储架构

不同数据应该使用不同存储。

数据	推荐存储
Trace	Tempo / Jaeger
Metrics	Prometheus
Logs	Loki / Elasticsearch
Events	Kafka
Execution	PostgreSQL
Memory	Redis / Vector DB
Analytics	ClickHouse / Data Warehouse
Evaluation	PostgreSQL / Data Lake

不要：

Everything → PostgreSQL

也不要：

Everything → Elasticsearch

应该根据数据访问模式选择存储。

三十一、为什么 ClickHouse 很适合 Agent Analytics？

Agent 会产生大量：

Execution
LLM Call
Tool Call
Token
Cost
Evaluation

这些数据天然适合：

OLAP

例如查询：

SELECT
 agent_id,
 SUM(total_tokens),
 SUM(cost),
 AVG(latency)
FROM agent_execution
GROUP BY agent_id;

可以快速得到：

Agent
Token
Cost
Latency

因此：

Operational Observability
 ↓
Prometheus / Tempo / Loki

Analytical Observability
 ↓
ClickHouse / Data Warehouse

是一个很合理的架构。

三十二、Agent Dashboard 应该怎么看？

一个生产 Agent Dashboard 不应该只有：

CPU
Memory
QPS

而应该至少包括：

Overview

Task Throughput
Task Success Rate
P95 Latency
Quality Score
Total Cost

Agent

Top Agents
Failure Rate
Average Steps
Average Cost

LLM

Token Usage
Model Latency
Model Error
Model Cost

Tool

Top Tools
Failure
Latency
Retry

A2A

Agent Calls
Agent Latency
Agent Failure

Evaluation

Quality
Accuracy
Safety
Regression

三十三、Grafana 中的 Agent Trace

最终可以形成：

Dashboard
 |
 +-- Task Success = 97.8%
 |
 +-- P95 = 8.3s
 |
 +-- Cost = $1,235
 |
 +-- Quality = 0.93
 |
 +-- Failure = 2.2%

点击：

Failure = 2.2%

进入：

Agent Trace

继续点击：

Tool Failure

进入：

Tool Logs

再点击：

Execution ID

查看：

Prompt
Context
Model
Tool
Result

这才是真正的：

Observability → Investigation → Root Cause Analysis

三十四、Agent Observability 的四个层次

可以把成熟度划分为：

Level 1：Infrastructure Observability

CPU
Memory
Network
Kubernetes

Level 2：Service Observability

HTTP
RPC
Database
Kafka

Level 3：Agent Observability

Agent
LLM
Tool
Memory
A2A
Token
Cost

Level 4：AI Quality Observability

Reasoning
Quality
Accuracy
Safety
Task Success
Business Outcome

企业真正的目标应该是：

Level 1
 ↓
Level 2
 ↓
Level 3
 ↓
Level 4

三十五、Agent Observability 最难的地方

真正困难的并不是：

OpenTelemetry SDK
Prometheus
Grafana

这些技术相对成熟。

真正困难的是：

1. 如何定义 Agent Telemetry Schema？

Agent
Task
Step
LLM
Tool
Memory
A2A

如何标准化？

2. 如何观测“决策”？

传统 Trace：

Service A → Service B

Agent：

Agent → Why Tool A?

“Why”是非常困难的问题。

3. 如何定义 Agent Quality？

HTTP 200

不代表：

Task Success

4. 如何控制 Observability Cost？

如果每天：

10M Tasks

每个 Task：

20 Steps

可能产生：

200M Spans

全部保存成本非常高。

因此需要：

Sampling
Aggregation
Retention
Tiered Storage

三十六、Agent Trace Sampling

不能所有 Trace 都永久保存。

可以：

Normal Trace
 ↓
1% Sampling

Error Trace
 ↓
100%

High Cost Trace
 ↓
100%

Quality Regression
 ↓
100%

进一步：

Production
 |
 +-- Normal → 1%
 +-- Error → 100%
 +-- Slow → 100%
 +-- Expensive → 100%
 +-- Security → 100%

这就是：

Intelligent Sampling。

三十七、从 Observability 走向 Agent Governance

当 Observability 数据积累以后，就可以进一步做：

Observe
 ↓
Analyze
 ↓
Evaluate
 ↓
Govern

例如：

发现某 Agent
平均 20 次 Tool Call

进一步：

成本过高

然后：

Policy
 ↓
限制 Tool Calls <= 10

再进一步：

自动切换到更便宜的 Model

因此最终：

Observability 不只是“看”，而是 Agent Governance 的数据基础。

三十八、Agent Observability 与 AgentOps

可以形成完整闭环：

 AgentOps
 |
 +-------------+-------------+
 | | |
 Develop Deploy Run
 | | |
 +-------------+-------------+
 |
 Observability
 |
 +----------+----------+
 | |
 Monitor Evaluate
 | |
 +----------+----------+
 |
 Improve
 |
 v
 Release

所以：

Agent Observability 是 AgentOps 的核心基础设施。

三十九、一个生产级 Agent Observability Stack

如果基于 Cloud Native 技术构建，可以考虑：

 Agent Runtime
 |
 v
 OpenTelemetry SDK
 |
 v
 OpenTelemetry Collector
 |
 +-----------------+----------------+
 | | |
 v v v
 Tempo Prometheus Loki
 | | |
 +-----------------+----------------+
 |
 v
 Grafana
 |
 v
 Agent Observability

Event：

Agent Runtime
 |
 v
 Kafka
 |
 +----+----+------+
 | | |
Audit Billing Analytics

Analytics：

Kafka
 ↓
ClickHouse
 ↓
Agent Analytics

Evaluation：

Execution
 ↓
Evaluation Engine
 ↓
Quality Score
 ↓
ClickHouse

四十、Agent Observability 的最终架构

综合起来：

 User
 |
 v
 ┌───────────────┐
 │ Agent Gateway │
 └───────┬───────┘
 |
 v
 ┌───────────────┐
 │ Agent Runtime │
 └───────┬───────┘
 |
 +--------------+--------------+
 | | |
 v v v
 LLM MCP A2A
 | | |
 +--------------+--------------+
 |
 v
 OpenTelemetry SDK
 |
 +--------------+--------------+
 | | |
 v v v
 Trace Metric Log
 | | |
 Tempo Prometheus Loki
 | | |
 +--------------+--------------+
 |
 v
 Grafana
 |
 +--------------+--------------+
 | | |
 v v v
 Runtime AI Quality Cost
 Metrics Evaluation Analysis
 | | |
 +--------------+--------------+
 |
 v
 AgentOps
 |
 v
 Governance

四十一、总结：Agent Observability 的本质

如果把传统 Observability 总结成：

Metrics
+
Logs
+
Traces

那么 Agent Observability 应该升级为：

 Agent Observability
 |
 +-----------------+-----------------+
 | | |
 Telemetry Context Quality
 | | |
 +---+---+ +----+----+ +----+----+
 | | | | | | | | |
Trace Metric Log Prompt Memory Tool Eval Cost

进一步可以形成：

Observe
 ↓
Understand
 ↓
Evaluate
 ↓
Govern
 ↓
Optimize

这就是 Agent Observability 与传统 Monitoring 最大的区别。

四十二、从架构师视角理解 Agent Observability

对于企业级 Agent Platform，我认为最值得建立的一个完整认知模型是：

 Agent Platform
 |
 v
 Agent Runtime
 |
 +----------------+----------------+
 | | |
 LLM Tool A2A
 | | |
 +----------------+----------------+
 |
 v
 Agent Telemetry
 |
 +-----------------------+-----------------------+
 | | |
 Trace Metric Log
 | | |
 +-----------------------+-----------------------+
 |
 v
 Event / Analytics
 |
 +-----------------+----------------+
 | | |
 Runtime Quality Cost
 | | |
 +-----------------+----------------+
 |
 v
 AgentOps
 |
 v
 Governance

因此，Agent Observability 不是 Agent Platform 的附属功能，而应该被设计成 Agent Runtime 的一等公民。

尤其是你前面已经关注过的 OpenTelemetry + Prometheus + Grafana + Tempo + Kafka + Agent Runtime + A2A + MCP，实际上完全可以串成一套完整的企业级技术体系：

 Agent Platform
 |
 ┌──────┴──────┐
 | |
 Control Plane Data Plane
 |
 Agent Runtime
 |
 +--------------------+-------------------+
 | | |
 LLM MCP A2A
 | | |
 +--------------------+-------------------+
 |
 OpenTelemetry
 |
 +-----------------+-----------------+
 | | |
 Trace Metric Log
 | | |
 Tempo Prometheus Loki
 | | |
 +-----------------+-----------------+
 |
 Grafana
 |
 Agent Evaluation
 |
 Agent Governance

这套架构已经不再是单纯的 AI Application Development，而是在进入：

AI Platform Engineering / Agent Infrastructure Engineering。

Agent Reliability：如何构建高可靠的 Agent 系统

Wed, 05 Aug 2026 00:00:00 +0000

Agent Reliability 深度技术博客：如何构建高可靠的 Agent 系统

一、引言：Agent 最大的问题不是“聪明”，而是“可靠”

传统软件系统追求：

Deterministic Correctness

即：

Input
 ↓
Business Logic
 ↓
Expected Result

只要代码正确，系统通常能够稳定地产生相同结果。

Agent 则完全不同：

User
 ↓
Agent
 ↓
LLM
 ↓
Planning
 ↓
Tool
 ↓
RAG
 ↓
Another Agent
 ↓
LLM
 ↓
Action
 ↓
Result

其中任何一个环节都可能失败。

例如：

LLM 输出错误
Tool 调用失败
Tool 参数错误
RAG 检索错误
Context 丢失
Agent 无限循环
Agent 选择错误的 Tool
外部 API Timeout
网络抖动
模型服务限流
Token 超限
上下文污染
Prompt Injection

所以 Agent Engineering 中一个非常核心的问题是：

如何让一个具有概率性行为的系统，表现得像一个可靠的软件系统？

这就是：

Agent Reliability

二、什么是 Agent Reliability？

可以定义为：

Agent Reliability 是 Agent 在面对正常请求、异常输入、依赖故障、模型不确定性以及复杂执行路径时，持续完成目标并保持安全、可控和可恢复行为的能力。

它不仅仅是：

Availability

也不是：

LLM Accuracy

而是：

Reliability
=
Availability
+
Correctness
+
Resilience
+
Recoverability
+
Safety
+
Controllability

因此：

Agent Reliability
 |
 +-- Availability
 |
 +-- Correctness
 |
 +-- Resilience
 |
 +-- Recovery
 |
 +-- Safety
 |
 +-- Control

三、为什么 Agent Reliability 比传统微服务更难？

传统微服务：

Service A
 ↓
Service B
 ↓
Database

通常可以明确：

Timeout
Retry
Circuit Breaker
Fallback

Agent：

Agent
 ↓
LLM
 ↓
Tool
 ↓
LLM
 ↓
Search
 ↓
Agent B
 ↓
Tool

这里增加了一个非常特殊的问题：

Agent 自己决定下一步做什么。

例如：

if API failed:
 retry

传统程序由开发者决定。

Agent 则可能：

Tool failed
 ↓
LLM
 ↓
Should I retry?
 ↓
Maybe retry

甚至：

Retry
 ↓
Retry
 ↓
Retry
 ↓
Retry

因此 Agent Reliability 必须同时解决：

Infrastructure Reliability
+
LLM Reliability
+
Behavioral Reliability

四、Agent Reliability 的七层模型

一个成熟的 Agent Platform 可以把 Reliability 分成七层：

 Agent Reliability
 |
 +-------------------+-------------------+
 | | |
 Infrastructure Runtime Intelligence
 | | |
 Network Timeout LLM
 Storage Retry Planning
 Queue State Reasoning
 | | |
 +-------------------+-------------------+
 |
 Dependency
 |
 Tool / API / RAG
 |
 Recovery
 |
 Safety / Governance

进一步可以抽象成：

L1 Infrastructure
L2 Dependency
L3 Runtime
L4 State
L5 Agent Behavior
L6 Recovery
L7 Governance

五、Reliability 的第一原则：不要相信任何依赖

Agent 系统中的依赖包括：

LLM Provider
Vector DB
Database
Redis
Kafka
External API
MCP Server
Other Agent
Search Engine
Object Storage

任何一个依赖都可能：

Timeout
Unavailable
Rate Limited
Malformed Response
Slow Response
Partial Failure

所以应该遵循：

Every dependency is unreliable by default.

架构：

Agent
 |
 +---- LLM
 |
 +---- Tool
 |
 +---- RAG
 |
 +---- Agent B
 |
 +---- Database

每个依赖边界都应该存在：

Timeout
Retry
Circuit Breaker
Bulkhead
Fallback
Observability

六、Timeout：Reliability 的第一道防线

最危险的系统通常不是：

Fast Failure

而是：

Slow Failure

例如：

Agent
 ↓
Tool
 ↓
等待 30 秒
 ↓
等待 30 秒
 ↓
等待 30 秒

最终：

User Request = 90s

因此 Agent Runtime 必须设计：

Request Timeout
Step Timeout
Tool Timeout
LLM Timeout
Workflow Timeout

例如：

Global Timeout = 60s

Step Timeout = 20s

Tool Timeout = 5s

形成：

User Request
 |
 +---------------- 60s ----------------+
 |
 +-- Step 1 -- 10s
 |
 +-- Step 2 -- 15s
 |
 +-- Step 3 -- 20s
 |
 +-- Recovery -- 10s

七、Timeout 必须具有层级性

不能简单：

timeout = 60s;

应该：

Request Timeout
 |
 +-- Planning Timeout
 |
 +-- LLM Timeout
 |
 +-- Tool Timeout
 |
 +-- Recovery Timeout

例如：

Request = 60s

Planning = 5s
LLM = 15s
Tool = 10s
Recovery = 10s

这样 Agent 才不会出现：

Tool 调用了 60 秒

导致整个 Runtime 没有恢复空间。

八、Retry：不是所有失败都应该重试

Agent 系统中非常容易犯的错误：

Failure
 ↓
Retry
 ↓
Failure
 ↓
Retry

这是危险的。

应该区分：

Transient Failure
Permanent Failure
Business Failure

九、Transient Failure

例如：

HTTP 503
Connection Reset
Temporary Network Error
Rate Limit

可以：

Retry

例如：

Attempt 1
 ↓
503
 ↓
Wait
 ↓
Attempt 2
 ↓
Success

十、Exponential Backoff

不要：

Retry every 1 second

应该：

1s
2s
4s
8s
16s

公式：

delay = base × 2^attempt

同时增加：

Jitter

例如：

delay =
min(
 maxDelay,
 base * 2^attempt
)
+ random()

避免大量 Agent 同时重试造成：

Retry Storm

十一、Retry Budget

这是 Agent Reliability 中非常值得引入的概念。

不要只定义：

maxRetries = 3

还应该定义：

Retry Budget

例如：

每个 Request
最多允许 20% 时间用于 Retry

如果：

Request Budget = 60s

那么：

Retry Budget = 12s

这样可以避免：

Agent
 ↓
Retry
 ↓
Retry
 ↓
Retry
 ↓
Retry

耗尽整个请求生命周期。

十二、Idempotency：Agent Reliability 的核心

这是 Agent 系统中非常重要的问题。

假设 Agent：

CreatePayment

第一次：

Request sent
 ↓
Payment succeeded
 ↓
Network timeout

Agent 不知道结果。

于是：

Retry

如果没有 Idempotency：

Payment
Payment

可能执行两次。

因此所有有副作用的 Tool：

CreateOrder
CreatePayment
SendEmail
TransferMoney
DeleteResource
CreateTicket

应该支持：

Idempotency-Key

例如：

request_id = agent-task-123

第一次：

POST /payment
Idempotency-Key: agent-task-123

再次 Retry：

POST /payment
Idempotency-Key: agent-task-123

服务端：

if key exists:
 return previous result
else:
 execute

十三、Agent Runtime 应该区分 Read Tool 和 Write Tool

这是非常重要的架构原则。

Tools
 |
 +-- Read
 |
 +-- Write

Read：

Search
GetUser
GetOrder
QueryDatabase

通常：

Retry = relatively safe

Write：

CreateOrder
DeleteUser
SendEmail
TransferMoney

必须：

Idempotency
Authorization
Audit
Approval

因此：

Agent → Tool

不应该是一个统一调用模型。

十四、Circuit Breaker

如果 Tool 连续失败：

Agent
 ↓
Payment API
 ↓
Failure
 ↓
Failure
 ↓
Failure

继续调用只会：

浪费资源
增加延迟
扩大故障

所以：

Circuit Breaker

状态：

CLOSED
 |
 | failures > threshold
 v
OPEN
 |
 | wait
 v
HALF_OPEN
 |
 +---- success → CLOSED
 |
 +---- failure → OPEN

十五、Agent 场景中的 Circuit Breaker 更复杂

传统：

Service A → Service B

Agent：

Agent
 |
 +-- Search
 +-- CRM
 +-- Payment
 +-- Email
 +-- SQL

应该：

Tool-level Circuit Breaker

例如：

Search Tool CLOSED
CRM Tool CLOSED
Payment Tool OPEN
Email Tool CLOSED

不能因为：

Payment Tool

失败，就把整个 Agent 都关闭。

十六、Bulkhead：防止一个 Agent 拖垮整个系统

Agent 的执行具有：

Long-running
Variable concurrency
Unpredictable tool calls

因此非常容易出现：

Agent A
 ↓
Tool Slow
 ↓
Threads Occupied
 ↓
Thread Pool Exhausted
 ↓
Agent B
 ↓
Cannot Execute

这就是：

Cascading Failure

解决：

Bulkhead

例如：

Agent Runtime
 |
 +-- Customer Agent Pool
 |
 +-- Coding Agent Pool
 |
 +-- Data Agent Pool
 |
 +-- Background Agent Pool

每个拥有独立：

Concurrency Limit
Queue
Timeout
Resource Budget

十七、Concurrency Limit

Agent 不应该无限并发。

例如：

Max Concurrent Agents = 100

进一步：

Max Concurrent Tool Calls = 500

甚至：

Per Agent = 10
Per User = 5
Per Tool = 50

形成：

Global
 ↓
Tenant
 ↓
Agent
 ↓
Task
 ↓
Tool

多层限流。

十八、Agent Loop 是 Reliability 最大的敌人之一

Agent 很容易出现：

Think
 ↓
Tool
 ↓
Observe
 ↓
Think
 ↓
Tool
 ↓
Observe
 ↓
Think
 ↓
Tool

如果没有终止条件：

Infinite Loop

因此 Agent Runtime 必须设计：

Max Steps
Max Tool Calls
Max Tokens
Max Execution Time
Max Cost

例如：

maxSteps = 20
maxToolCalls = 30
maxTokens = 100000
maxExecutionTime = 60s
maxCost = $0.50

十九、Agent Budget

可以把这些统一成：

Agent Budget

Agent Budget
 |
 +-- Time Budget
 |
 +-- Token Budget
 |
 +-- Tool Budget
 |
 +-- Cost Budget
 |
 +-- Step Budget
 |
 +-- Retry Budget

这是 Agent Runtime 非常重要的设计。

例如：

{
 "maxExecutionTime": 60000,
 "maxSteps": 20,
 "maxToolCalls": 30,
 "maxTokens": 100000,
 "maxCost": 0.5
}

一旦超限：

STOP

而不是：

继续让 Agent 自己决定

二十、State Reliability

Agent 通常是 Stateful 的：

Task
 ↓
State
 ↓
Step
 ↓
State
 ↓
Step

因此不能只放在：

JVM Memory

否则：

Agent Runtime Crash

整个任务状态丢失。

应该：

Agent
 ↓
State Store

例如：

Redis
PostgreSQL
DynamoDB

保存：

Task ID
Current Step
Plan
Tool Results
Checkpoint
Retry Count
Budget
Status

二十一、Checkpoint

复杂 Agent 可以：

Step 1
 ↓
Checkpoint
 ↓
Step 2
 ↓
Checkpoint
 ↓
Step 3

如果：

Step 3 Failure

不需要：

Restart from Step 1

可以：

Resume from Step 3

架构：

Task
 |
 +-- Step 1 ── Checkpoint
 |
 +-- Step 2 ── Checkpoint
 |
 +-- Step 3 ── Failure
 |
 +-- Recovery
 |
 +-- Resume

二十二、Event-Driven Reliability

对于长时间 Agent：

User
 ↓
Agent
 ↓
Tool
 ↓
等待外部系统

不要一直占着 HTTP Connection。

应该：

API
 ↓
Task Created
 ↓
Kafka
 ↓
Agent Runtime
 ↓
Execute
 ↓
Event
 ↓
State Store

例如：

AgentTaskCreated
AgentStepStarted
ToolCalled
ToolCompleted
AgentStepFailed
AgentRetrying
AgentCompleted
AgentFailed

这样可以实现：

Durable Execution

二十三、Agent Failure Recovery

Agent Failure 可以分为：

Failure
 |
 +-- LLM Failure
 |
 +-- Tool Failure
 |
 +-- Network Failure
 |
 +-- State Failure
 |
 +-- Logic Failure
 |
 +-- Safety Failure
 |
 +-- Budget Exhaustion

不同 Failure：

不同 Recovery Strategy

二十四、Recovery Matrix

可以建立：

Failure	Retry	Fallback	Replan	Human
LLM Timeout	✓	✓
Tool Timeout	✓	✓	✓
Tool 500	✓	✓
Invalid Tool Args			✓
Knowledge Missing		✓	✓
Budget Exhausted				✓
Payment Failed	✓		✓	✓
Safety Violation				✓

这比：

catch(Exception e)

高级得多。

二十五、Fallback

Agent 不应该只有：

Success
Failure

可以：

Primary
 ↓
Failure
 ↓
Fallback

例如 LLM：

GPT Model
 ↓
Timeout
 ↓
Backup Model

Tool：

Primary Search
 ↓
Failure
 ↓
Backup Search

RAG：

Vector Search
 ↓
No Result
 ↓
Keyword Search

二十六、Graceful Degradation

可靠系统的一个重要原则：

失败时不要全部失败。

例如：

Recommendation Agent

推荐服务失败：

Recommendation unavailable

但：

Order Service
Payment Service
User Service

仍然正常。

即：

Partial Failure
 ↓
Partial Success

而不是：

One Tool Failure
 ↓
Entire Agent Failure

二十七、Multi-Agent Reliability

如果系统变成：

Supervisor
 |
 +-- Research Agent
 |
 +-- Coding Agent
 |
 +-- Data Agent
 |
 +-- Review Agent

Reliability 问题会进一步扩大。

因为：

Agent A
 ↓
Agent B
 ↓
Agent C
 ↓
Agent D

形成：

Distributed Agent System

二十八、Agent-to-Agent Failure

例如：

Agent A → Agent B

Agent B：

Timeout

Agent A 是否：

Retry?
Fallback?
Replan?
Stop?

因此 A2A 通信应该具备：

Request ID
Correlation ID
Timeout
Retry
Idempotency
Capability
Authentication
Authorization
Trace Context

二十九、Distributed Reliability

Multi-Agent 系统实际上类似：

Distributed System

所以需要：

Correlation ID
Distributed Trace
Timeout
Retry
Circuit Breaker
Event
State
Checkpoint
Saga

尤其是：

不要把 Multi-Agent 当成简单的函数调用。

它实际上是：

Distributed Workflow

三十、Saga Pattern

如果 Agent 执行：

Create Order
 ↓
Reserve Inventory
 ↓
Charge Payment
 ↓
Send Notification

中间：

Charge Payment

失败怎么办？

可以设计：

Create Order
 ↓
Reserve Inventory
 ↓
Charge Payment
 X
 |
 v
Compensation
 |
 +-- Release Inventory
 |
 +-- Cancel Order

这就是：

Saga / Compensation

特别适合 Agent 执行复杂业务流程。

三十一、Human-in-the-Loop

并不是所有事情都应该让 Agent 自动恢复。

例如：

Payment
Delete Production Database
Transfer Money
Deploy Production
Send Legal Document

应该：

Agent
 ↓
Risk Detection
 ↓
Human Approval
 ↓
Execute

架构：

 Agent
 |
 v
 Risk Engine
 |
 +----------+----------+
 | |
 Low Risk High Risk
 | |
 Auto Execute Human
 |
 Approve
 |
 Execute

这实际上是：

Reliability + Safety + Governance

的结合。

三十二、Reliability 与 Safety 的边界

Reliability：

系统是否按照预期工作？

Safety：

即使工作正常，会不会做危险的事情？

例如 Agent：

正确调用 DeleteDatabase Tool

从 Reliability 看：

SUCCESS

从 Safety 看：

DISASTER

所以：

Reliable ≠ Safe

必须同时考虑。

三十三、Observability 是 Reliability 的基础

没有 Observability：

Agent Failed

你不知道：

为什么？

所以必须记录：

Trace
Logs
Metrics
Events

例如：

Trace ID: abc123

Agent Start
 ↓
LLM Call
 ↓
Tool Search
 ↓
Tool Timeout
 ↓
Retry
 ↓
Tool Success
 ↓
LLM
 ↓
Final Answer

这样才能进行：

Root Cause Analysis

三十四、Agent Reliability Metrics

至少需要以下指标。

Availability

Availability =
Successful Requests
/
Total Requests

Task Success Rate

Task Success Rate =
Successful Tasks
/
Total Tasks

Failure Rate

Failure Rate =
Failed Tasks
/
Total Tasks

Recovery Rate

Recovery Rate =
Recovered Tasks
/
Failed Tasks

这个指标非常适合 Agent。

因为：

Failure

本身不一定意味着：

Task Failure

如果：

Tool Timeout
 ↓
Retry
 ↓
Success

Agent 仍然可靠。

三十五、MTTR

传统系统：

Mean Time To Recovery

Agent 也需要。

例如：

Tool Failure
 ↓
Detection
 ↓
Retry
 ↓
Fallback
 ↓
Success

测量：

Recovery Time

三十六、Agent Reliability SLO

企业 Agent 可以定义：

Task Success Rate >= 99%

p95 Latency <= 10s

Tool Failure Recovery >= 95%

Hallucination Rate <= 1%

Unsafe Action Rate <= 0.01%

Budget Violation = 0

注意：

Reliability 不应该只有 Availability SLO。

应该是：

Quality SLO
+
Reliability SLO
+
Safety SLO
+
Cost SLO

三十七、Reliability Dashboard

可以设计：

Agent Reliability Dashboard

Task Success Rate 98.7%
Availability 99.95%
Recovery Rate 96.2%
Tool Failure Rate 1.8%
LLM Failure Rate 0.4%
Timeout Rate 0.7%
Loop Detection 0.1%
p95 Latency 8.4s
p99 Latency 19.2s
Avg Tool Calls 4.3
Avg Cost $0.06

然后继续向下钻取：

Agent
 ↓
Task
 ↓
Trace
 ↓
Step
 ↓
Tool
 ↓
Failure

三十八、Reliability 与 Evaluation 的关系

前面我们讨论过：

Evaluation：Agent 做得好不好？

Reliability：

Agent 能不能稳定地把事情做好？

二者关系：

 Agent Quality
 |
 +----------+----------+
 | |
 Evaluation Reliability
 | |
 Is it good? Can it keep
 doing it?

例如：

Agent A
Accuracy = 95%
Availability = 90%

Agent B：

Accuracy = 93%
Availability = 99.9%

生产环境中：

Agent B

可能更加可靠。

三十九、Reliability + Evaluation + Observability

这三个体系应该统一起来：

 Agent Platform
 |
 +---------------+---------------+
 | | |
 Observability Evaluation Reliability
 | | |
 What happened? How good? Will it keep
 working?
 | | |
 +---------------+---------------+
 |
 AgentOps

最终形成：

Observe
 ↓
Evaluate
 ↓
Detect
 ↓
Recover
 ↓
Improve

四十、Agent Reliability Reference Architecture

一个企业级 Agent Platform 可以设计成：

 Client
 |
 v
 API Gateway
 |
 v
 Agent Gateway
 |
 +-------------+-------------+
 | |
 v v
 Agent Runtime Policy Engine
 | |
 +-------+-------+ |
 | | | |
 LLM Tools RAG |
 | | | |
 +-------+-------+-------------------+
 |
 v
 State Manager
 |
 +-----+------+
 | |
 Redis PostgreSQL
 |
 v
 Kafka
 |
 v
 Event / Workflow Engine
 |
 +------------------+
 | |
 v v
 Checkpoint Recovery
 | |
 +--------+---------+
 |
 v
 Observability
 |
 +-------+-------+
 | | |
 Trace Metrics Logs
 | | |
 +-------+-------+
 |
 v
 Evaluation
 |
 v
 AgentOps

四十一、Agent Runtime 中的 Reliability Middleware

一个非常实用的设计是：

Agent Runtime
 |
 v
Reliability Middleware
 |
 +----+----+----+----+----+
 | | | | | |
Timeout Retry Breaker Budget Checkpoint

例如：

public AgentResult execute(AgentTask task) {

 return timeout.execute(() ->
 retry.execute(() ->
 circuitBreaker.execute(() ->
 budget.execute(() ->
 agent.run(task)
 )
 )
 )
 );
}

实际生产环境还需要：

Idempotency
Tracing
Metrics
Audit
Policy

四十二、不要让 LLM 决定 Reliability Policy

这是一个非常重要的原则。

错误：

Tool Failure
 ↓
LLM decides:
"Maybe retry 5 times"

正确：

Tool Failure
 ↓
Runtime Policy
 |
 +-- Retry <= 3
 +-- Timeout <= 5s
 +-- Budget <= 10s
 +-- Circuit Breaker
 +-- Fallback

然后才：

LLM Replan

即：

LLM 决定业务行为，Runtime 决定系统边界。

这是 Agent Platform 非常重要的架构原则。

四十三、Policy 与 Intelligence 分离

可以进一步总结成：

 Agent
 |
 +-----------+-----------+
 | |
 Intelligence Runtime
 | |
 Planning Timeout
 Reasoning Retry
 Tool Selection Budget
 Replanning Security
 Circuit Breaker
 State

LLM：

What should I do?

Runtime：

What am I allowed to do?
How long can I run?
How many times can I retry?
How much can I spend?

这是一种：

Policy / Intelligence Separation

四十四、Agent Reliability 的五大原则

如果把全文浓缩成五条架构原则：

原则一：Everything Can Fail

LLM
Tool
Network
Database
Agent

都可能失败。

原则二：Bound Everything

任何 Agent 都必须有：

Time
Token
Step
Tool
Cost
Retry

Budget。

原则三：Make Side Effects Idempotent

所有：

Write Operation

必须考虑：

Idempotency

原则四：Failure Must Be Recoverable

不要：

Failure → Crash

而应该：

Failure
 ↓
Detect
 ↓
Classify
 ↓
Retry / Fallback / Replan
 ↓
Recover

原则五：Runtime Controls the Agent

最重要：

LLM = Intelligence
Runtime = Control

不要让：

LLM

突破：

Security
Budget
Timeout
Concurrency
Policy

四十五、Agent Reliability 的最终架构思想

传统系统：

Code
 ↓
Test
 ↓
Deploy
 ↓
Monitor

Agent 系统：

Agent
 ↓
Evaluate
 ↓
Deploy
 ↓
Observe
 ↓
Detect Failure
 ↓
Recover
 ↓
Learn
 ↓
Improve

因此 Agent Platform 最终应该形成：

 ┌───────────────────┐
 │ Agent Runtime │
 └─────────┬─────────┘
 │
 Execute Task
 │
 ┌───────────────┼───────────────┐
 │ │ │
 Timeout Budget Policy
 │ │ │
 └───────────────┼───────────────┘
 │
 Tool / LLM
 │
 Failure?
 │
 ┌─────┴─────┐
 │ │
 NO YES
 │ │
 │ Classify
 │ │
 │ ┌──────┼──────┐
 │ │ │ │
 │ Retry Fallback Replan
 │ │ │ │
 │ └──────┼──────┘
 │ │
 └─────┬─────┘
 │
 Recover
 │
 Complete
 │
 Observability
 │
 Evaluation
 │
 Improve

四十六、结语：Reliability 是 Agent 从 Demo 走向生产的分水岭

Agent 最容易做出来的是：

User
 ↓
LLM
 ↓
Tool
 ↓
Answer

真正困难的是：

User
 ↓
Agent
 ↓
LLM
 ↓
Tool
 ↓
Timeout
 ↓
Retry
 ↓
Tool
 ↓
Invalid Result
 ↓
Replan
 ↓
Fallback
 ↓
Checkpoint
 ↓
Resume
 ↓
Human Approval
 ↓
Execute
 ↓
Result

这才是真正的：

Production-Grade Agent

所以，从 Agent Platform 架构角度看，Reliability 不是一个附加功能，而是 Agent Runtime 的核心能力。

可以把整个 Agent Platform 的核心能力概括为：

 Agent Platform
 |
 +----------------+----------------+
 | | |
 Runtime Observability Evaluation
 | | |
 +----------------+----------------+
 |
 Reliability
 |
 +----------------+----------------+
 | | |
 Resilience Recovery Governance
 | | |
 +----------------+----------------+
 |
 Production

最终形成一套完整的 Agent Engineering 闭环：

Runtime 保证执行，Observability 负责看见，Evaluation 负责判断，Reliability 负责恢复，Governance 负责约束，AgentOps 负责持续改进。

这也是从普通 LLM Application 走向真正 Enterprise Agent Platform 的关键一步。

AI Cost Optimization：从 Token 控制到 Agent 成本工程的系统化实践

Wed, 05 Aug 2026 00:00:00 +0000

AI Cost Optimization：从 Token 控制到 Agent 成本工程的系统化实践

摘要当企业开始规模化使用 LLM、RAG 和 Agent 后，“模型效果”不再是唯一的工程指标。一个 Agent 请求可能经历多轮推理、工具调用、检索、上下文压缩以及多个模型协作，最终成本可能是一次普通 Chat 请求的数十倍甚至上百倍。

因此，AI 系统需要从传统的 Infrastructure Cost Optimization，进一步演进到 AI Cost Optimization：在保证质量、延迟和可靠性的前提下，对模型、Token、Context、RAG、Agent、缓存、并发以及基础设施进行系统化成本治理。

本文从 AI 系统架构师视角，建立一套完整的 AI 成本优化体系，并重点讨论 Token Economics、Model Routing、Context Engineering、Semantic Cache、RAG Optimization、Agent Cost Control、Observability 和 FinOps。

1. 为什么 AI 系统需要 Cost Optimization？

传统互联网系统的成本模型通常比较容易理解：

User
 ↓
API Gateway
 ↓
Application
 ↓
Database / Cache
 ↓
Infrastructure

成本主要来自：

CPU
Memory
Storage
Network
Database
Kubernetes
Cloud Infrastructure

而 LLM 应用的成本结构完全不同：

User
 ↓
Agent
 ↓
Prompt
 ↓
Context
 ↓
RAG
 ↓
LLM
 ↓
Tool Calling
 ↓
LLM
 ↓
LLM
 ↓
Final Answer

一次用户请求可能产生：

Input Tokens
 +
Retrieved Tokens
 +
Conversation History
 +
System Prompt
 +
Tool Result
 +
Output Tokens
 +
Embedding Calls
 +
Reranking Calls
 +
Multiple LLM Calls

因此，AI 系统的核心问题不再是：

“这个 API 调用了多少次？”

而是：

“一次业务任务到底消耗了多少 AI Compute？”

2. AI Cost 的基本数学模型

可以把一次 AI 请求的成本抽象为：

[ C_{request} = C_{LLM} + C_{Embedding} + C_{Reranking} + C_{Tool} + C_{Infrastructure} ]

其中：

[ C_{LLM}

\sum_{i=1}^{n} ( InputTokens_i \times P_{in} + OutputTokens_i \times P_{out} ) ]

如果一个 Agent 执行：

1. Planner
2. Search
3. RAG
4. Tool Call
5. Reflection
6. Final Answer

那么它实际上不是一次模型调用，而可能是：

LLM Call #1
LLM Call #2
LLM Call #3
LLM Call #4
LLM Call #5
LLM Call #6

假设每次调用平均消耗：

Input = 8K tokens
Output = 2K tokens

那么：

[ TotalTokens = 6 \times (8K + 2K) ]

也就是：

60K tokens / request

如果每天执行：

100,000 requests

那么每天就是：

6 billion tokens

这时，即使单次请求成本看起来很低，规模化之后也会形成非常大的费用。

3. Cost Optimization 的核心思想

AI Cost Optimization 不能简单理解为：

“换一个便宜的模型。”

真正成熟的优化体系应该是：

 AI Cost Optimization
 │
 ┌───────────────────┼───────────────────┐
 ↓ ↓ ↓
 Model Optimization Context Optimization Architecture
 │ │ │
 Model Routing Prompt Optimization Cache
 Model Cascade Context Window RAG
 Batch Inference Compression Agent
 Quantization Summarization Queue
 │ │ │
 └───────────────────┼───────────────────┘
 ↓
 Cost Observability
 │
 ↓
 FinOps / Governance

可以总结为六个方向：

少调用模型
少传 Token
使用更便宜的模型
减少 Agent 无效推理
提高缓存命中率
建立完整的成本可观测性

4. 第一原则：Don’t Call LLM If You Don’t Need It

这是最重要的成本优化原则。

很多 AI 系统存在一个典型问题：

所有请求
 ↓
LLM

实际上很多任务根本不需要 LLM。

例如：

"订单 12345 当前状态是什么？"

如果数据库已经存在：

order.status = SHIPPED

完全没有必要：

User
 ↓
LLM
 ↓
Tool
 ↓
Database
 ↓
LLM
 ↓
Answer

更合理的方式是：

User
 ↓
Intent Router
 ├── deterministic query
 │ ↓
 │ Database
 │
 └── complex reasoning
 ↓
 LLM

这就是：

LLM as a selective reasoning engine，而不是整个系统的默认执行引擎。

5. Model Routing：不要让所有请求使用最贵模型

这是 AI Cost Optimization 最重要的架构模式之一。

假设系统拥有：

Model A
高能力
高成本

Model B
中等能力
中等成本

Model C
基础能力
低成本

不要设计成：

所有请求
 ↓
Model A

而应该：

 Request
 │
 ↓
 Classifier
 │
 ┌──────────┼──────────┐
 ↓ ↓ ↓
 Easy Medium Hard
 │ │ │
 ↓ ↓ ↓
 Model C Model B Model A

例如：

请求类型	推荐模型
分类	Small Model
信息抽取	Small Model
FAQ	Small Model
简单代码生成	Medium Model
RAG QA	Medium Model
复杂推理	Large Model
高难度 Coding	Large Model

6. Model Cascade

更进一步，可以设计 Model Cascade。

例如：

Request
 ↓
Small Model
 ↓
Confidence Score
 │
 ├── High
 │ ↓
 │ Answer
 │
 └── Low
 ↓
 Large Model

假设：

80% 请求 → Small Model
20% 请求 → Large Model

那么相比：

100% → Large Model

成本可能显著降低。

这里最关键的问题是：

如何判断 Small Model 是否有能力解决？

可以使用：

Confidence
Intent
Complexity
Token Length
Retrieval Quality
Previous Failure Rate

构建一个：

Request Complexity Score

例如：

[ Score = w_1 \times Complexity + w_2 \times ContextSize + w_3 \times ReasoningRequired + w_4 \times HistoricalFailureRate ]

然后根据 Score 做模型路由。

7. Context Engineering：最大的隐藏成本

很多团队优化 Token 时，只关注 Prompt。

实际上真正的问题通常是：

Context 太大。

例如：

System Prompt 3K
Conversation 8K
RAG Documents 20K
Tool Results 10K
User Request 2K
-----------------------
Total 43K

如果每次 Agent Loop 都把这 43K Token 重新发送给模型：

Iteration 1 → 43K
Iteration 2 → 43K
Iteration 3 → 43K
Iteration 4 → 43K

那么：

172K input tokens

可能只是完成一个用户请求。

8. Context Compression

Context Optimization 的核心不是：

“把 Prompt 写得更短。”

而是：

让模型只看到当前任务真正需要的信息。

可以建立：

Raw Context
 ↓
Relevance Filter
 ↓
Deduplication
 ↓
Compression
 ↓
Summarization
 ↓
Relevant Context
 ↓
LLM

例如原始文档：

100K tokens

通过：

Retriever
+
Reranker
+
Compression

最终只保留：

8K tokens

那么：

[ CostReduction \approx 92% ]

当然，实际效果还需要结合模型价格和缓存机制计算。

9. Context Window 不等于 Context Budget

这是 Agent 系统中非常重要的一个概念。

模型支持：

1M Context

不代表你的 Agent 应该使用：

1M Context

应该定义：

Context Budget

例如：

context:
 system: 2000
 conversation: 4000
 retrieved_docs: 6000
 tool_results: 4000
 user_query: 1000

总预算：

17K tokens

而不是无限制地：

append(context)

10. Semantic Cache：AI 系统中的关键成本杠杆

传统 Cache：

GET /product/123

使用：

Key = product:123

但是 LLM 请求通常不是完全相同的：

"What is Kubernetes?"
"Can you explain Kubernetes?"
"Please explain Kubernetes to me."

语义不同，但答案高度相似。

因此可以使用：

Semantic Cache

架构：

User Query
 ↓
Embedding
 ↓
Vector Search
 ↓
Similarity
 │
 ├── similarity > threshold
 │ ↓
 │ Cache Hit
 │
 └── similarity < threshold
 ↓
 LLM
 ↓
 Cache

例如：

threshold = 0.92

如果：

similarity = 0.96

直接返回 Cache。

11. Semantic Cache 的成本模型

假设：

100,000 requests/day

其中：

Cache Hit = 40%
Cache Miss = 60%

那么真正调用 LLM 的请求：

60,000

而不是：

100,000

理论上：

[ LLMCallsReduced = 40% ]

如果 LLM 是整个系统最大的成本项，Semantic Cache 的收益可能非常明显。

但需要注意：

Cache 命中率越高不一定越好。

因为错误的 Semantic Cache 会产生：

Wrong Answer
Stale Answer
Context Mismatch
Authorization Leak

因此 Cache Key 必须考虑：

tenant
user
permission
model
prompt version
knowledge version
language
query embedding

12. RAG Cost Optimization

RAG 是另一个非常容易产生隐性成本的地方。

典型 RAG：

Query
 ↓
Embedding
 ↓
Vector Search
 ↓
Top-K
 ↓
Reranker
 ↓
LLM

问题在于：

Top-K = 20

意味着可能把 20 个 Document 全部送给 LLM。

更合理：

Vector Search
 ↓
Top 20
 ↓
Reranker
 ↓
Top 5
 ↓
Context Compression
 ↓
Top 3 relevant chunks
 ↓
LLM

这就是：

Retrieve More, Send Less

13. RAG 中不要把 Retrieval 和 Generation 混在一起优化

RAG Cost 可以拆成：

[ C_{RAG}

C_{Embedding} + C_{VectorSearch} + C_{Reranking} + C_{Generation} ]

通常：

Generation Cost
>
Reranking Cost
>
Embedding Cost
>
Vector Search Cost

因此不要为了省一点 Vector Search CPU，而把大量无关文档传给 LLM。

真正应该优化的是：

LLM Context Size

14. Agent Cost Optimization

Agent 是 AI Cost Optimization 最复杂的场景。

普通 Chat：

User
 ↓
LLM
 ↓
Answer

Agent：

User
 ↓
Planner
 ↓
Tool
 ↓
Observation
 ↓
Reasoning
 ↓
Tool
 ↓
Observation
 ↓
Reflection
 ↓
LLM
 ↓
Answer

如果 Agent 无限循环：

while (!done) {
 callLLM();
 executeTool();
}

成本非常危险。

15. Agent Budget

生产环境中的 Agent 必须具有：

Max Steps
Max Tokens
Max Tool Calls
Max Time
Max Cost

例如：

agent:
 maxSteps: 8
 maxTokens: 30000
 maxToolCalls: 10
 timeout: 60s
 maxCost: 0.10

这样 Agent 不会因为错误规划进入：

Tool
 ↓
LLM
 ↓
Tool
 ↓
LLM
 ↓
Tool
 ↓
LLM
...

无限循环。

16. Cost-aware Agent

进一步，可以让 Agent 自己感知成本。

例如：

Agent State

remaining_budget = $0.05

current_cost = $0.03

remaining_budget = $0.02

此时 Agent 可以动态改变策略：

High Budget
 ↓
Large Model
 ↓
Deep Reasoning
 ↓
Multiple Tools

Low Budget
 ↓
Small Model
 ↓
Short Context
 ↓
Limited Tools

这可以称为：

Cost-Aware Agent

Agent 的 Objective 不再只是：

[ Maximize\ Quality ]

而是：

[ Maximize\ Quality - \lambda Cost ]

进一步可以形成：

[ Utility = Quality

\lambda_1 Cost

\lambda_2 Latency

\lambda_3 Risk ]

这实际上是 AI Agent 从“能工作”走向“可生产化”的重要一步。

17. Multi-Agent 系统尤其需要 Cost Governance

Multi-Agent 架构通常类似：

 Supervisor
 │
 ┌─────────────┼─────────────┐
 ↓ ↓ ↓
 Researcher Coder Reviewer
 │ │ │
 ↓ ↓ ↓
 LLM LLM LLM

问题是：

1 User Request
 ↓
Supervisor
 ↓
Researcher × 3
 ↓
Coder × 2
 ↓
Reviewer × 2
 ↓
Supervisor

最终可能产生：

10+ LLM calls

因此 Multi-Agent 必须考虑：

Agent Budget
Agent Priority
Agent Timeout
Agent Max Calls
Agent Model Tier
Agent Context Budget

18. Model Selection Matrix

可以为 Agent 定义模型等级：

Tier 1
Cheap Model
 ↓
Classification
Extraction
Simple Tool Calling

Tier 2
Medium Model
 ↓
RAG
Planning
Coding

Tier 3
Premium Model
 ↓
Complex Reasoning
Architecture
Critical Decisions

Supervisor 根据任务动态分配：

Task
 ↓
Complexity
 ↓
Model Tier
 ↓
Budget

而不是：

所有 Agent
 ↓
Premium Model

19. Prompt Optimization

Prompt Optimization 不是单纯减少文字。

真正应该关注：

Prompt Length
Instruction Duplication
Few-shot Examples
Output Length
Context Duplication
Tool Description

例如：

System Prompt = 8K
Tool Definitions = 10K

每次调用都发送：

18K tokens

这其实是非常大的固定成本。

因此可以考虑：

Dynamic Tool Loading

不要给 Agent：

100 tools

而是：

User Request
 ↓
Tool Retrieval
 ↓
Relevant Tools
 ↓
LLM

例如：

100 tools
 ↓
Tool Router
 ↓
5 tools
 ↓
LLM

这同时降低：

Token Cost
Reasoning Cost
Tool Selection Complexity
Latency

20. Tool Description Optimization

很多 MCP / Agent 系统存在一个问题：

Tool Definition
 ↓
Name
Description
Parameters
Examples
Constraints

如果系统拥有：

200 tools

Tool schema 本身就可能消耗大量 Context。

因此可以采用：

Tool Registry
 ↓
Semantic Search
 ↓
Top-K Tools
 ↓
LLM

也就是说：

Tools should be retrieved just like documents.

这是 Agent 系统非常值得关注的优化方向。

21. Batch Processing

不是所有 AI 请求都要求实时。

例如：

Document Classification
Data Extraction
Embedding
Summarization
Report Generation

可以从：

Real-time

转为：

Batch

架构：

Application
 ↓
Kafka
 ↓
Batch Queue
 ↓
LLM Worker
 ↓
Result Storage

这样可以：

提高吞吐
降低峰值资源
减少 API overhead
提高资源利用率

22. AI Infrastructure Cost

如果企业开始自建模型，那么成本模型又发生变化：

GPU
CPU
Memory
Storage
Network
Kubernetes
Inference Server
Model Storage
Observability

此时核心指标变成：

[ CostPerToken = \frac{TotalInfrastructureCost} {GeneratedTokens} ]

或者：

[ CostPerRequest = \frac{GPUCost + InfraCost} {Requests} ]

23. GPU Utilization

GPU 成本优化不能简单理解为：

“让 GPU 使用率达到 100%。”

真正重要的是：

GPU Utilization
+
Tokens/sec
+
Latency
+
Batch Size
+
Memory Utilization

例如：

GPU A
Utilization = 35%

可能意味着：

Batch 太小
Request 太少
KV Cache 不合理
模型没有充分并发

可以通过：

Dynamic Batching
Continuous Batching
Request Queue
Model Quantization
KV Cache Optimization

提升单位 GPU 的 Token 产出。

24. Quantization

如果模型允许，可以使用：

FP16
↓
INT8
↓
INT4

降低：

GPU Memory
Bandwidth
Inference Cost

但 Quantization 的核心不是：

“精度越低越好。”

而是：

[ CostSaving

QualityLoss ]

因此应该通过 Evaluation Dataset 验证：

Accuracy
Reasoning
Hallucination
Latency
Cost

25. AI Cost Observability

没有 Observability，就无法进行 Cost Optimization。

传统监控：

CPU
Memory
QPS
Latency
Error Rate

AI 系统必须增加：

Input Tokens
Output Tokens
Cached Tokens
Model
Provider
Prompt Version
Agent Steps
Tool Calls
Embedding Calls
RAG Documents
Cost

26. AI Cost Dashboard

建议建立这样的 Dashboard：

 AI Cost Dashboard

Total Cost
$12,530

Cost / Request
$0.018

Total Tokens
2.3B

Cache Hit Rate
42%

Average Agent Steps
3.2

Model Distribution
Small 55%
Medium 35%
Large 10%

进一步按照：

Tenant
Application
API
Agent
User
Model
Provider
Environment

进行成本分析。

27. Cost Attribution

企业级 AI 平台最重要的能力之一是：

Who is spending the money?

例如：

Company
 ├── Business A
 │ ├── Chatbot
 │ └── RAG
 │
 ├── Business B
 │ └── Coding Agent
 │
 └── Business C
 └── Customer Service

最终应该能够看到：

Business A
$5,200

Business B
$12,800

Business C
$3,100

进一步：

Application
 ↓
Agent
 ↓
Model
 ↓
Token
 ↓
Cost

这就是：

AI FinOps

28. Cost Unit Economics

不要只关注：

Monthly AI Bill

更重要的是：

Cost per User
Cost per Request
Cost per Successful Task
Cost per Document
Cost per Conversation
Cost per Agent Task

尤其是：

[ CostPerSuccessfulTask

\frac{TotalCost} {SuccessfulTasks} ]

这个指标非常重要。

假设：

System A

Cost = $10,000
Success Rate = 50%

System B

Cost = $12,000
Success Rate = 95%

那么：

Cost / Successful Task

B 可能反而更便宜。

所以：

Cost Optimization 不能脱离 Quality Optimization。

29. Cost vs Quality Optimization

AI 系统实际上是在优化一个多目标函数：

[ Objective = \alpha Quality

\beta Cost

\gamma Latency

\delta Risk ]

不同业务的权重不同。

例如：

客服

Quality 50%
Cost 30%
Latency 20%

Coding Agent

Quality 70%
Cost 15%
Latency 15%

Enterprise Batch Processing

Quality 50%
Cost 40%
Latency 10%

因此不存在：

“最低成本就是最佳方案。”

真正目标是：

Minimum Cost under Quality Constraint

30. 一个完整的 AI Cost Optimization Architecture

最终可以形成如下架构：

 User
 │
 ↓
 API Gateway
 │
 ↓
 AI Cost Gateway
 │
 ┌──────────────────┼──────────────────┐
 ↓ ↓ ↓
 Cache Layer Model Router Budget Manager
 │ │ │
 ↓ ↓ ↓
 Semantic Cache Small Model Cost Policy
 │ Medium Model Rate Limit
 │ Large Model Token Budget
 │ │
 └──────────────────┼──────────────────┘
 ↓
 Agent
 │
 ┌─────────────┼─────────────┐
 ↓ ↓ ↓
 RAG Tools Memory
 │ │ │
 ↓ ↓ ↓
 Retrieval Tool Router Context Manager
 │ │ │
 └─────────────┼─────────────┘
 ↓
 LLM Provider
 │
 ↓
 Observability
 │
 ┌─────────────┼─────────────┐
 ↓ ↓ ↓
 Metrics Logs Traces
 │ │ │
 └─────────────┼─────────────┘
 ↓
 AI FinOps
 │
 ┌─────────────┼─────────────┐
 ↓ ↓ ↓
 Cost Report Cost Alert Optimization

31. AI Cost Gateway

在企业架构中，我非常推荐增加一个：

AI Cost Gateway

它类似：

API Gateway

但专门负责 AI 成本治理。

核心职责：

1. Model Routing
2. Token Budget
3. Rate Limiting
4. Semantic Cache
5. Cost Tracking
6. Provider Routing
7. Model Fallback
8. Tenant Quota
9. Cost Alert
10. Policy Enforcement

调用链：

Application
 ↓
AI Cost Gateway
 ↓
Policy Engine
 ↓
Model Router
 ↓
LLM Provider

32. Multi-Provider Cost Optimization

企业通常不会只使用一个模型供应商。

例如：

Provider A
Provider B
Provider C
Self-hosted Model

可以建立：

LLM Router

根据：

Cost
Latency
Availability
Quality
Region
Data Policy

动态选择 Provider。

例如：

 Request
 ↓
 LLM Router
 │
 ┌────────────┼────────────┐
 ↓ ↓ ↓
 Provider A Provider B Self-hosted
 Cheap Fast Secure

这实际上类似传统 Cloud FinOps 中的：

Cloud Workload Placement

33. Cost-aware Fallback

传统系统：

Primary Model
 ↓
Failure
 ↓
Backup Model

AI 系统可以进一步：

Primary Model
 ↓
Failure / Budget Exceeded
 ↓
Cheaper Model

例如：

Premium Model
 ↓
Quota exceeded
 ↓
Medium Model
 ↓
Quota exceeded
 ↓
Small Model

这可以保证：

系统可用性
+
成本可控

34. Token Budget 是 AI 系统的“资源配额”

传统系统：

CPU Quota
Memory Quota
API Rate Limit

AI 系统应该增加：

Token Quota
Cost Quota
Agent Step Quota
Tool Call Quota

例如：

tenant:
 enterprise-a:
 dailyTokenLimit: 100000000
 dailyCostLimit: 500
 maxAgentSteps: 10

 enterprise-b:
 dailyTokenLimit: 20000000
 dailyCostLimit: 100
 maxAgentSteps: 5

这让 AI 平台真正具备：

Resource Governance

35. AI Cost Optimization 的八层模型

可以把整个体系抽象成八层：

Layer 8 ─ Business Optimization
 ↑
Layer 7 ─ AI FinOps
 ↑
Layer 6 ─ Observability
 ↑
Layer 5 ─ Agent Optimization
 ↑
Layer 4 ─ RAG / Context Optimization
 ↑
Layer 3 ─ Model Routing
 ↑
Layer 2 ─ Token Optimization
 ↑
Layer 1 ─ Infrastructure Optimization

很多团队只做：

Layer 1

例如：

GPU Optimization
Kubernetes Optimization

但真正的 AI 成本往往更多来自：

Model
Token
Context
Agent

因此：

AI Cost Optimization 是 Application Architecture 问题，而不仅仅是 Infrastructure 问题。

36. 一套完整的优化优先级

实际项目中，可以按照下面的优先级进行。

Level 1：减少无意义调用

Don't Call LLM

优先使用：

Rule
Cache
Database
Deterministic Logic

Level 2：Model Routing

Easy → Small Model
Medium → Medium Model
Hard → Large Model

Level 3：Context Optimization

重点优化：

Prompt
History
RAG
Tool Description
Agent Memory

Level 4：Caching

建立：

Exact Cache
Semantic Cache
Embedding Cache
RAG Cache
Tool Result Cache

Level 5：Agent Optimization

控制：

Steps
Tokens
Tools
Iterations
Reflection
Planning

Level 6：Infrastructure Optimization

最后再优化：

GPU
CPU
Memory
Batching
Quantization
Kubernetes

37. 一个真实生产系统应该监控什么？

建议至少建立以下 Metrics：

ai_request_total

ai_request_cost

ai_input_tokens

ai_output_tokens

ai_cached_tokens

ai_model_usage

ai_cache_hit_rate

ai_agent_steps

ai_tool_calls

ai_rag_documents

ai_rag_context_tokens

ai_latency

ai_success_rate

ai_cost_per_successful_task

进一步可以建立：

cost_by_model
cost_by_tenant
cost_by_application
cost_by_agent
cost_by_api
cost_by_user

38. 最容易被忽略的 Cost Anti-Patterns

Anti-Pattern 1：所有请求都使用大模型

100%
 ↓
Premium Model

解决：

Model Routing

Anti-Pattern 2：整个 Conversation 全量发送

History = 100K
 ↓
Every Request

解决：

Summarization
Context Windowing
Memory
Compression

Anti-Pattern 3：RAG Top-K 太大

Top 50
 ↓
LLM

解决：

Retrieve → Rerank → Compress → Generate

Anti-Pattern 4：Agent 无限循环

while(true)

解决：

Max Steps
Max Cost
Max Tokens
Timeout

Anti-Pattern 5：所有 Tool 都暴露给 Agent

100+ Tools
 ↓
LLM

解决：

Tool Retrieval

Anti-Pattern 6：没有 Cost Observability

Monthly Bill
 ↓
"为什么这么贵？"

这是最危险的状态。

39. 从“成本控制”走向“成本智能”

成熟的 AI 平台最终应该能够做到：

Observe
 ↓
Analyze
 ↓
Predict
 ↓
Optimize
 ↓
Enforce

例如系统发现：

Agent X

Average Cost = $0.18
Success Rate = 82%

而：

Agent Y

Average Cost = $0.07
Success Rate = 89%

系统可以自动判断：

Agent X
 ↓
High Cost
 ↓
Investigate
 ↓
Context too large
 ↓
Optimize
 ↓
Cost = $0.09

这就是：

AI-driven AI Cost Optimization

也就是用 AI 本身优化 AI 系统的成本。

40. 未来：Cost Optimization 将成为 Agent Runtime 的核心能力

未来的 Agent Runtime 很可能不再只是：

Planner
Executor
Memory
Tools

而是：

 Agent Runtime
 │
 ┌──────────────────┼──────────────────┐
 ↓ ↓ ↓
 Planning Execution Memory
 │ │ │
 └──────────────────┼──────────────────┘
 ↓
 Cost Controller
 │
 ┌──────────────────┼──────────────────┐
 ↓ ↓ ↓
 Model Router Token Budget Tool Budget
 │ │ │
 ↓ ↓ ↓
 Model Tier Context Limit Call Limit

Agent 的每一次行动都可以考虑：

Expected Value
Expected Cost
Expected Latency
Risk

然后选择：

[ Action^*

argmax ( ExpectedUtility

ExpectedCost ) ]

这意味着未来 Agent 不只是：

Reasoning Agent

而会逐渐成为：

Resource-Aware Agent

41. 总结

AI Cost Optimization 绝不是简单的：

换便宜模型

真正完整的 AI 成本工程应该覆盖：

 AI Cost Optimization

 ↓

 ┌─────────────────────┐
 │ Don't Call LLM │
 └──────────┬──────────┘
 ↓
 ┌─────────────────────┐
 │ Model Routing │
 └──────────┬──────────┘
 ↓
 ┌─────────────────────┐
 │ Token Optimization │
 └──────────┬──────────┘
 ↓
 ┌─────────────────────┐
 │ Context Engineering │
 └──────────┬──────────┘
 ↓
 ┌─────────────────────┐
 │ RAG Optimization │
 └──────────┬──────────┘
 ↓
 ┌─────────────────────┐
 │ Agent Optimization │
 └──────────┬──────────┘
 ↓
 ┌─────────────────────┐
 │ Semantic Cache │
 └──────────┬──────────┘
 ↓
 ┌─────────────────────┐
 │ AI Observability │
 └──────────┬──────────┘
 ↓
 ┌─────────────────────┐
 │ AI FinOps │
 └─────────────────────┘

最终目标不是：

Make AI Cheap

而是：

Maximize AI Business Value per Dollar.

也就是说，真正应该优化的指标是：

[ \boxed{ AI\ ROI = \frac{Business\ Value} {AI\ Cost} } ]

对于企业级 AI 系统而言，最成熟的架构不是“最强模型 + 无限 Token + 无限 Agent Loop”，而是：

正确的问题使用正确的模型，在正确的 Context 下，以正确的 Agent 策略完成任务，并在整个生命周期内受到成本预算和质量指标约束。

这也是 AI Cost Optimization 从单点技术优化走向 AI Platform Engineering / AI FinOps 的核心演进方向。