企业智能体的下半场，如何让智能体越用越聪明？

当我们在讨论AI Agent的进化能力时，实际上需要区分两类截然不同的场景。一类是员工办公场景下的通用Agent，通过持续学习用户的偏好、协作风格和操作习惯，让助手越来越懂主人；另一类则是企业业务场景中的垂直Agent，如面向客户的智能客服、内部数据分析助手等。前者在C端市场已展现出显著效果——据研究显示，使用Claude超过6个月的老用户，对话成功率比新用户高出3至5个百分点。然而，后者——企业级业务Agent的进化之路，依然充满挑战。大多数企业仍处于“手搓”观测、手工评估的阶段，缺乏系统化的工程方法论。

从模型进化到Agent进化：复杂度跃升

本文聚焦企业业务场景，深入剖析Agent进化飞轮构建过程中的核心难题与应对思路。

进化飞轮的四重挑战

传统的模型进化范式相对清晰：采集（prompt, completion）二元组，构建数据集，通过LLM-as-Judge进行评估，最后沉淀为SFT数据、DP O对或LoRA权重。这套方法论已有成熟的工具链支撑。然而，Agent任务的复杂度远高于此。Agent的一条执行轨迹（Trajectory）不再是简单的二元组，而是一张带有拓扑结构的网络图：它包含任务规划与子目标分解、检索过程中的关键词搜索与文件定位、工具调用的入参出参与执行耗时、浏览器访问与DOM解析、中间状态的实时更新、反思与决策分支、甚至多条并行子任务。每一个环节都可能影响最终效果，这种多因素耦合的特性，使得传统进化范式难以直接套用。

分层评估与资产沉淀的困境

构建Agent进化飞轮通常需要四个步骤：数据采集、数据集构建、效果评估、资产沉淀。看似清晰的流水线，在Agent场景下却处处是坑。 第一重挑战是数据采集的复杂性。Agent行为评估需要采集完整的Trajectory执行轨迹，而每一步的输入输出形态各异：检索返回chunk列表，工具调用返回结构化JSON，浏览器返回DOM片段，模型返回token流。要将这些异构事件按时序和因果关系串联起来，加上token消耗、延迟、错误码等元数据，存储成本是传统二元组采集的数十倍。更棘手的是，目前行业尚无统一标准，OpenTelemetry的GenAI语义规范仍在草案阶段，企业大多只能自建方案。 第二重挑战在于数据集构建。一条轨迹是否是好样本，定义远比模型时代困难。考虑这样一个场景：最终结果正确，但中途走了三个错误工具；或者最终结果错误，但前五步推理逻辑完全正确。这条轨迹是好样本吗？前五步能否单独抽取作为训练信号？更复杂的是，Trajectory中往往包含真实业务数据（订单信息、客户名称、内部接口响应），脱敏工作不是简单的字符串替换，而是需要结构化的数据治理能力。

构建自进化飞轮的工程实践

第三重挑战是效果评估。传统LLM-as-Judge只需对单一输出打分，而Agent时代需要三层评估体系：Step-level评估每一步的工具调用是否正确；Trajectory-level评估整条执行路径是否合理，有无绕路、回退或死循环；Outcome-level评估最终交付是否满足业务要求。三个层级的结论可能完全不一致，这要求评估体系必须具备多维度、多视角的结构化能力。 第四重挑战是进化资产的沉淀。模型的资产形态已有行业共识——SFT数据、DPO对、LoRA权重，工具链成熟。但Agent时代的资产形态仍在分化：可以回流成prompt优化策略，可以构造成few-shot经验库，可以沉淀为episodic memory，还可以抽成可复用的skill或子流程。每种形态消化Trajectory的方式各异，缺少像模型权重那样的统一容器。这导致许多企业陷入一个尴尬境地：Agent上线了，用户量增长了，但可进化的资产却没有相应积累。

如有侵权，请联系删除。