写在前面

最近做Agent工程化的工作比较多，在做Agent的时候也让我想到搜推工程，这篇文章我们就来探讨Agent工程和传统搜推工程之间的区别和联系，以及如何评估一个Agent工程化的质量和可用性。

⚠️ 注意：这里我们讨论的场景是C端在线高并发的场景。

搜推工程

传统搜推工程非常成熟，pipeline 似乎已经是固定搭配，基本如下图所示。

在搜推场景下，用户的输入其实很少，就是非常简短的query词 (推荐场景还没有query词)，通过这个query去做大量的数据召回，再根据用户特征去进行筛选合适的数据。

我们可以发现搜推的本质 是一个典型的 DAG（有向无环图）定向流，它的目标是 低延迟下(P99<100ms)处理海量数据，对海量数据进行筛选的过程，是做减法。

Agent 工程

Agent的架构是什么样的呢？我们先了解一下Agent的开发范式，一般来说会有ReAct、Plan&Executor、 Multi-Agent 等等。

我们就用常见的 ReAct 开发范式举例子，这是一个 Iterative Loop（迭代循环）。核心是 思考-行动-观察（Reasoning-Action-Observation）， 它不再是单向流，而是一个循环，自身不断在做加分。

上下文管理

在工程上，这意味着 Agent 需要处理不确定的执行步数，并且大模型的输出是很慢的，尽管有Streaming流式，但随着上下文的长度越长，输入的token越多，大模型做推理的时间也就越长，而在C端我们又希望大模型的输出尽可能的快。

此外大模型对于我们来说其实算一个黑盒，我们并不能百分百去控制这个大模型的输出，当出现 bad case 的时候也很难复现，只能在整体的 prompt 上进行调优。 我们的描述越多越准确，或者上下文越长，模型的推理也会越精准，当然耗时也就越长了。

如何用更少的上下文，做到相同或者更好的推理效果，这也是目前Agent工程化中很重要也很难的一点，也就是去年非常火的context engineering。 当然我们可以做上下文压缩，可以做工具的返回压缩，也可以将部分上下文进行抹除。

Tool & Skills

在Agent工程化里面，我们能听到很多词，从去年很火的MCP、A2A到今年的Skills。

无论是MCP Tool、SubAgent还是Skills，本质都是封装的颗粒度不同，MCP Tool是最原子的封装，是颗粒度最小的一环，而Skills更像是一个标准的SOP，是一些MCP Tool的集合，而SubAgent更像是一些Skills的集合。一层套着一层。

通信

在C端的分布式架构下，Agent 工程如何做通信？可能很多同学会想起去年四月谷歌发布的A2A协议，这个协议出来的时候我就关注了。

A2A协议很像我们的服务注册和发现，将Agent注册到一个中心，通过这个中心找到有哪些Agent，以及这个Agent有什么能力等基础信息，但是不是就只能用A2A去进行多Agent之间的通信呢？

我认为不是的，具体Agent需要具体分析，我们也可以通过MCP Tool的方式进行通信，比如微软的这篇博客：A2A by MCP Tool

可用性

对于搜推工程，我们有标准指标也就是CTR去评估搜推的质量。但AI Mode如何做评估呢？从上文我们可以知道核心难点在于不确定性。

最简单也是最直接的一点，就是用户对本次对话结果的反馈。

当然单靠这种简单的feedback进行评估是不可能的。对于大流量 C 端场景，我们需要构建一套 多维度的、自动化的、且具备工程闭环 的评估矩阵。

从宏观视角上来看，Agent的终端效果可以从以下两点进行评估：

• 再问率： 用户在回答后 30 秒内是否又问了类似问题？
• 点击/转化率： 如果 Agent 推荐了item，用户是否点击？

从细微的工程架构中，我们可以对工具召回和执行步骤进行评估：

• Tool Call 准确度： 在特定步骤下，是否选择了正确的 Tool。
• 参数准确度： 提取的参数是否准确（比如日期、金额、ID）。
• Step Redundancy (SR)： 评估是否存在冗余步骤。例如，本来两步能解决的问题，Agent 绕了五步。
• Hallucination Rate： 规划中是否出现了虚构的工具或不存在的参数。
• TPS/Latency： 尤其是 TTFT（首字延迟） 和任务总耗时。
• Tokens per Task： 完成一个任务平均消耗的 Token 数（直接关系到成本）。

当然，我这里也只是列举了一些常用的指标，具体业务的指标可以进行具体的拆分，针对大流量 C 端，这些指标直接决定了Agent系统的可用性。