Agent上线不是终点_怎样让它在真实使用中越跑越稳_公众号直贴版_20260927

——从可观测轨迹、动态评测到受控回写，看 Agent 如何摆脱“上线即巅峰”

▼

一个 Agent 在测试阶段拿到不错的分数，并不意味着它已经具备了稳定工作的能力。

测试集通常边界清楚、输入规范、答案可预期；真实用户却会省略背景、临时改口、反复追问，把多个目标混在一句话里。业务规则会更新，知识会过期，模型、Prompt、Skill 和 Tool 也会持续变化。上线前跑通的路径，一旦进入真实环境，很快就可能偏离原来的质量基线。

这也是许多 Agent 面临的共同困境：演示时表现出色，上线后却“即巅峰，随后持续衰减”。问题不一定出在模型突然变差，而是系统从一个可控的测试分布，进入了不断变化的真实分布。失败可能来自用户输入、知识缺口、工具调用、流程编排、成本失控，也可能来自产品定位本身。没有足够证据，团队只能在模型、Prompt 和业务逻辑之间来回猜。

在 AiDD 成都站，中兴 AI 教练付光荣在《基于 Agent 可观测的 AI 应用与大语言模型双环自进化》中，把 Agent 上线后的改进问题放回真实运行轨迹：先看见每次任务怎样感知、思考和行动，再把高价值反馈转成评测、训练与系统优化的输入。

这条路径给出了一个重要判断：Agent 不会因为被更多人使用就自动变好。只有真实运行被观察、被评估、被验证并受控地回写，使用量才可能转化为进化能力。

图 1：付光荣《基于 Agent 可观测的 AI 应用与大语言模型双环自进化》：Agent 上线后面临真实分布变化、问题定位困难与成本失控（PPT 第 9 页）

▍一、上线后的第一道难题，是团队看不见 Agent 为什么失败

传统应用上线后，团队会重点观察延迟、错误率、吞吐量和资源消耗。接口返回 500，可以沿日志和调用链定位；机器负载异常，可以从指标和告警入手。这套 APM 体系擅长回答“系统是否健康”，却很难独立回答“Agent 为什么做出了这个决定”。

一次 Agent 任务可能跨越多轮规划、知识检索、模型调用和工具执行。最终答案错了，原因可能是最初理解错目标，也可能是召回了过期知识、选错工具、传错参数，或在中间步骤错误地认为任务已经完成。即使每个接口都返回 200，整个任务仍可能失败。

因此，Agent 可观测不能只记录输入和输出，还要保留任务状态、关键观察、规划结果、工具选择、参数、返回值、异常、人工接管和最终业务结果。付光荣将其概括为从 State、Observation、Thought、Action 到 Result 的全链路记录。这里的重点不是暴露模型所有内部推理，而是为每个可执行决策留下足够的工程证据。

当团队能把一次失败还原成轨迹，问题才会从“Agent 今天不太聪明”变成可以处理的故障类型：是知识缺失、工具契约错误、流程跳步、模型能力不足，还是用户目标本身没有被澄清。可观测性首先解决的，不是自动优化，而是让改进摆脱猜测。

图 2：付光荣《基于 Agent 可观测的 AI 应用与大语言模型双环自进化》：Agent 可观测从系统健康指标扩展到多步推理、完整状态和业务效果（PPT 第 12 页）

▍二、用户不一定会点“差评”，但真实行为一直在反馈

上线后的第二道难题，是显式评价往往太少。

用户很少耐心说明“第二步检索错了，所以第三步结论不可信”。更多时候，他们会直接中断执行、撤销生成结果、换一种说法重新提问、另开窗口重来，或切换模型后再次尝试。这些动作没有写下评价，却已经传递了对结果的态度。

付光荣把这类行为视为高价值隐式反馈。中断执行和撤销结果相对客观，通常意味着当前路径没有继续价值；重复询问、立即改述、新开窗口和切换模型，也可能提示回答没有解决问题。它们比只看点赞率更接近真实使用，但也不能被简单理解成“发生一次就记为负样本”。用户追问可能是任务自然延伸，采纳代码后继续修改也可能只是正常完善。

因此，反馈治理必须同时判断客观性、严重程度和上下文。埋点可以确认用户做了什么，语义相似度和任务状态可以判断前后动作是否相关，必要时再由模型或人工分析意图。只有经过分类和去噪，行为数据才能从海量日志中变成改进信号。

这一点非常关键。真实使用会不断产生数据，但数据量不等于数据质量。未经验证的反馈如果直接进入训练、记忆或规则库，Agent 可能把偶然行为当成稳定偏好，把错误修正当成正确经验，最终不是越跑越稳，而是越跑越偏。

图 3：付光荣《基于 Agent 可观测的 AI 应用与大语言模型双环自进化》：中断、撤销、重复询问和切换模型等行为可作为隐式反馈信号（PPT 第 19 页）

▍三、真实轨迹最重要的去处，不是日志仓库，而是动态评测集

很多团队已经保存 Agent 日志，但日志经常只在故障发生后被临时检索。问题修完，记录继续沉在系统里；下一次改 Prompt、换模型或更新 Skill 时，团队仍然不知道旧问题会不会重新出现。

要让一次失败真正产生复利，关键动作是把高价值 Trace 转成评测用例。一条完整用例不只包含用户问题和最终答案，还要保留输入状态、关键上下文、预期动作序列、工具约束、验证断言和完成标准。这样，过去发生过的真实问题才会变成以后每个版本都必须回答的一道题。

付光荣提出的转换路径包含四个环节：先定义高质量筛选标准，从真实轨迹中找到目标明确、链路完整、结果可确认的样本；再把它们转成标准评测用例；根据质量阈值和触发条件持续补充新样本；最后保持评测集与线上真实分布对齐。

这解决了人工评测集的一个结构性问题：上线前的用例天然来自团队已经想到的场景，线上轨迹则会暴露用户真正怎样使用、边界怎样出现、失败怎样组合。评测集如果不随着真实分布更新，分数可能很稳定，业务效果却会继续下降。

图 4：付光荣《基于 Agent 可观测的 AI 应用与大语言模型双环自进化》：优质 Trace 经过筛选、用例化和分布对齐进入动态评测集（PPT 第 27 页）

动态评测集的价值，不只是发现问题，还要阻止退化。模型升级、Prompt 修改、工具替换、知识库更新和工作流调整，都可能修好一个问题，同时破坏另一项原有能力。因此，每次变更都要与既有基线比较，并为核心指标设置容忍阈值和超限动作。

任务成功率、业务分析准确率、工具调用正确率、人工接管率等指标，回答的是不同层面的问题。某项指标下降超过阈值，系统可以自动拦截版本、触发根因分析或进入人工复核。具体基线和阈值应由业务风险与历史表现确定，不能照搬一套通用数字；真正重要的是建立“变更必须经过回归，退化不能直接进入生产”的机制。

图 5：付光荣《基于 Agent 可观测的 AI 应用与大语言模型双环自进化》：核心指标、容忍阈值与超限动作共同形成版本回归门（PPT 第 28 页）

▍四、越跑越稳，不等于让 Agent 直接修改自己

当轨迹、反馈和评测集准备好以后，系统才有资格讨论自动优化。

付光荣将自主进化拆成两个角色：Agent Debugger 负责回放轨迹、识别异常模式和定位根因；Evolve Agent 根据诊断结果生成候选修复方案，可能涉及 Prompt、优化工具描述、调整路由或更新编排。候选变更先进入隔离环境，经过回归测试、指标门控和必要的人工审核，才有机会进入生产版本。

这与“让 Agent 自己发现问题、直接改线上系统”有本质区别。前者是一条受控的软件变更流程，后者则把观察者、修改者和验收者放在同一个概率系统里，错误很容易被自我确认。

真正可靠的自进化，必须把生成与判定分开：可以让模型提出修改，但不能只由同一个模型证明修改有效；可以自动扩大候选方案，但发布权必须由独立评测、确定性检查和风险规则共同决定。自动化提高的是诊断和试验速度，质量责任不能因此消失。

图 6：付光荣《基于 Agent 可观测的 AI 应用与大语言模型双环自进化》：Agent Debugger、Evolve Agent、隔离验证与门控组成受控优化架构（PPT 第 31 页）

▍五、Agent 要有“经验”，更要有“考卷”和“上岗门”

顺丰科技研效运营唐亮在《Agent 驱动的 AI Native 软件生命周期端到端质量保障体系建设》中，把 Agent 工作所需资源归纳为需求与交付物、Tool、Skill、知识库、Memory 和 Eval 六类。他特别强调，最容易被忽略的是 Eval：没有考卷，就无法考核；无法考核，个人提效也很难稳定传导为团队能力。

这补上了持续进化中常被忽视的一环。知识库告诉 Agent 业务事实，Skill 告诉它怎样完成任务，Memory 保存经历；Eval 则负责判断这些经验到底有没有让结果变好。没有稳定评测，所谓“学习”只能凭主观感受；版本越多，团队反而越难回答哪一次修改真正有效。

图 7：唐亮《Agent 驱动的 AI Native 软件生命周期端到端质量保障体系建设》：需求、工具、Skill、知识库、Memory 与 Eval 共同构成 Agent 的岗位资源（PPT 第 23 页）

评测也不能只在发布前给出一个总分。唐亮提出通过、返回和降级三种裁决：客观证据满足要求，任务才进入下一节点；编译、测试或扫描未通过，就返回重做；部分风险可接受时可以降级放行，但必须标记风险并让下游加严。Checkpoint 保存稳定状态，Human in the Loop 保留关键判断，失败不必从头再跑，也不让 Agent 替人承担最终责任。

这让改进闭环有了可执行的出口。不是每个问题都要训练模型，也不是每个低分样本都值得修改系统。有些失败应补知识，有些应修工具契约，有些应调整流程，有些只需要收紧权限，还有些源于目标模糊，必须让人重新确认。先分类，再选择改进动作，才能避免把所有问题都粗暴地推给模型。

图 8：唐亮《Agent 驱动的 AI Native 软件生命周期端到端质量保障体系建设》：客观验证后按通过、返回或降级裁决，并以 Checkpoint 和人工节点保留责任边界（PPT 第 27 页）

绿盟科技“铁律蜂巢”AI 研发效能研发技术经理冀博则进一步强调，规则之内可以由机器判，规则之外必须由人决策。每次拦截都要留下主体、时间、规则和原因，形成可审计证据；经过复盘确认的事件，才有资格反哺规则进化。

这意味着，持续回写不是把所有线上数据倒回系统，而是一条有入口门槛、验证标准和责任人的资产生产线。数据可以推动改进，但不能绕过安全、合规和业务责任。

图 9：冀博《从 SDD 到确定性质量门禁：AI 驾驭技术跃迁》：规则定义、事前拦截、证据留存与人工卡点共同约束 Agent 的持续进化（PPT 第 20 页）

▍六、企业最终要运营的，不是一个模型，而是一套进化闭环

让 Agent 在真实使用中越跑越稳，最终会沉淀出四类长期资产。

第一类是运行轨迹。它让团队知道任务怎样被理解、工具怎样被调用、失败发生在哪一步。第二类是动态评测集。它把真实 Bad Case、边界场景和黄金路径变成版本必须反复回答的题库。第三类是改进与版本记录。每次 Prompt、模型、Tool、Skill、知识或编排变化，都要能解释为什么改、验证了什么、效果如何。第四类是门禁和责任规则。哪些指标下降必须拦截，哪些动作需要人工批准，哪些经验允许进入知识库或训练集，都要有清晰边界。

企业不必一开始就建设一套庞大的自进化平台。更现实的起点，是选择一个任务边界清楚、使用频率足够高、结果可以验证的 Agent，先打通一条最小闭环：记录完整轨迹，定义一组核心指标，把一个线上问题沉淀成回归用例，完成一次受控修复，再确认它没有破坏原有能力。

当这条闭环稳定运行，团队再逐步扩大数据来源、评测覆盖和自动化程度。可观测是起点，可评估是前提，可优化是结果；三者的顺序不能颠倒。

Agent 上线不是终点，因为真实世界从来不会停在上线那一天。真正决定它能否长期创造价值的，不是第一次演示有多惊艳，而是每次运行之后，组织能不能留下证据、识别问题、验证改进，并把正确经验带到下一个版本。

一个会执行的 Agent 只是产品功能；一套会从真实使用中稳步改进的闭环，才是企业能力。