Agent 上线后如何持续优化？AgentLoop 提出数据飞轮七步法股票反弹，从接入、观测到经验库，将调优从零散修补升级为可复现、可验证的系统工程。本文拆解每一步的产品逻辑与 PM 落地要点，助你构建自进化 Agent。
Agent 的难点不是说“造出来”就好，主要在“上线后持续变好”。
开发期靠几十条样例和人工试聊能糊弄过去；一旦进生产环境，用户问法发散、工具会超时、模型会漂移、业务规则会改，原来那版 Prompt 会慢慢变质。这时候如果调优方式还是“看几条客诉 → 手动改几句 Prompt → 凭感觉发版”，就会出现原文说的三个毛病：
零散：只处理了刚好被看到的 case； 不可复现：下次换个人改，标准就变； 无法证伪：“这次改动到底变好还是变坏”答不上来。AgentLoop 给出的解法是把调优做成数据飞轮：
接入真实 trace → 观测 → 审计 → 沉淀 badcase 到数据集 → 建 Rubric 评估 → 开实验回测 → 经验库自动反哺。每转一圈，Agent 的起点都比上一圈高。
网上配资作为PM，你不用立刻会写探针代码，但你必须看懂这条链上每一环在产品里是什么对象、产出什么资产、下一环怎么消费它。
1. 从一个客服 Agent 与工作空间（AgentSpace）说起 1.1 为什么先讲“工作空间”而不是“接模型”很多PM容易一上来问“接哪个 LLM”，但企业级 Agent 平台的第一个边界概念是资源租户边界：
数据（trace、会话日志） 数据集（badcase 集、golden set） 评估器（Rubric、Judge Prompt） 实验（版本、回测结果） 经验库（Skill、经验规则）这些都挂在 AgentSpace 下。
为什么要强调这个？因为生产环境里“客服 Agent”和“报销 Agent”不能共用同一份 badcase 集，也不能互相污染评估分数。PM 做权限设计和资源隔离时，AgentSpace 就是一级边界。
1.2 为什么选 Claude Code 客服 Agent 做靶子对 PM 而言，选样板 Agent 有三个隐含标准：
有多步推理（不是单轮 QA）； 有工具调用（查订单、改工单）； 有真实业务 Rubric（金融/医疗/客服标准不同）。单轮聊天机器人用不着这么重的飞轮，直接 LLMOps 就行。只要 Agent 有“规划—调用—观察—再规划”的 loop，就需要 Agent 原生观测，而不是 LLM 调用级观测。
2. AgentLoop 核心定位：覆盖“开发→上线后”的调优全过程
“上线之后”才是飞轮主战场。开发期样本是假的（构造的），上线后样本是真的（带噪声、带长尾）。飞轮的地基是真实 trace，不是离线测试集。
3. 数据飞轮七步接入 → 观测 → 审计 → 数据集 → 评估 → 实验 → 经验库 →（反哺）Agent。
3.1 数据接入：OTel 探针 + Trace ID 串联地基环节。AgentLoop 基于 OpenTelemetry（OTel）标准协议 + 探针做无侵入采集，四种方式：
OTel 是事实标准：不锁平台，未来换后端也能消费； 探针形态四种：通用 Agent 一键对接 / SDK 集成 / 高代码注解埋点 / eBPF 无侵入； 关键产物是 Trace 不是日志：以 Trace ID 把“用户提问 → 模型调用 → 工具调用 → 沙箱 → 再模型”串成树； 统一字段：user / assistant / tool / token / model / latency，后面所有环节都吃这个 schema。PM 在这里要写清楚的需求：
采样策略（全量还是 10% 采样 + 全量错链路保留，参考 OTel 尾采样实践）； PII 过滤在探针侧还是服务端； Claude Code 的 claude_code.interaction / llm_request / tool span 映射成平台哪几个实体。 3.2 观测：还原“Agent 怎么想的”观测看“调了几次模型、用了哪几个工具、哪一步卡 9 秒”。看清每一次运行：调了哪些模型、用了哪些工具、走了什么路径”。
对客服 Agent，观测大盘至少五块（结合 OTel 实践）：
会话完成率（成功/失败/超时） P95 工具耗时（Bash / 查单 / 改工单分开） MCP/工具错误率 各模型 Token 消耗 工具重试分布（重试 ≥3 次 = 浪费钱前兆）PM 价值：把“慢/贵/错”定位到具体 span，而不是甩给算法“模型不好”。
3.3 审计：合规视角的不可篡改证据链Agent 多步执行，若出事（泄露 PII、越权改单），要能回放“哪一步调了什么、上下文是什么”。AgentLoop 产品侧是不可篡改轨迹 + 敏感数据检测 + 高危行为标记。
PM 做 ToB 方案时，这一环是过关项：金融/医保/政务没有轨迹留痕根本不让你上线。
3.4 数据集：飞轮的“弹药库”观测中发现 badcase（答非所问、流程跑偏、工具参数错），保存进数据集。数据集是后面实验回测的弹药库。
这里要区分三类集：
Golden Set（黄金集）：专家造的少量高标准题，用于回归门禁； Badcase Set：线上错例，用于定向修复； Online Sample：线上随机采样，用于跑分看大盘。数据集不是越多越好，是标注口径一致才值钱。一条 badcase 至少要带：原始 trace 引用、失败类型标签（结果错/过程错/合规错/成本高）、期望行为。
3.5 评估：结果 + 过程双视角，Rubric 是核心资产从结果和过程两个角度评估 Agent 的响应质量——不只看最终答案对不对，也看执行过程合不合理。
为什么要过程评估？
单看最终答案，会漏掉两种致命情况：
答案碰巧对，但调了 11 次工具、花了 3 万 token； 答案错，但过程里第 14 步工具选错，后面全歪。所以评估分两层：
结果 Rubric：最终答复是否正确、完整、合规； 过程 Rubric：是否先检索再回答、工具参数对不对、有无冗余调用、是否该转人工时硬撑。Rubric 是什么，PM 怎么写？
Rubric = 把“这个回答好不好”拆成可检查维度 + 判定标准 + 权重的评分表。这里给客服退款例：
PM 常犯的错：把 Rubric 写成“回答自然、有用”——不可判。必须下钻到二元或带证据的检查点（如“回答中是否出现订单号字段”）。
Rubric 的三种来源：
业务专家口述 → PM 结构化； 线上 badcase 反向归纳； LLM-as-a-Judge / Agent-as-a-Judge 用同一份 Rubric 批量打（AgentLoop 用评估器即 Agent 的范式）。关键认知：Rubric 一旦写出来，就是团队资产。它让“专家脑子里的好”变成可回测的显式标准，换人改 Prompt 也不会把标准弄丢。
3.6 实验：回测 + 实验计划 + 大盘评估产出分数，实验回答“我改完Prompt/Skill 后分数真的涨了吗”。
原文路径：评估挑badcase → 进数据集 → 建实验计划 → 一轮轮回测 → 看整体分 → 低了继续调。
PM 要理解的实验对象：
变体（Variant）：基线Prompt vs新Prompt vs新Skill注入； 固定集：同一份数据集回测，否则前后分不可比； 指标：整体准确率、过程合规率、P95 耗时、单位任务 Token、转人工率； 显著性：不能看单点浮动，要看集合层面稳定提升。“耗时降30~40%、成本降20~47%”这样的数据不是一次手工改出来的，是实验大盘里ablation + 多轮回测证出来的。
3.7 经验库：唯一不需专家介入的环节后台算法自动化地从运行轨迹中挖掘经验，反哺 Agent。
机制（结合AgentLoop官方说明）：
清Trace噪声 → 组装Trajectory（目标/动作/观察/错误/恢复/结果）； 跨多条轨迹比对，挖出“有效路径 / 反模式 / 参数规则 / 恢复策略”； 结构化经验存经验库，相似场景通过 Skill 召回注入上下文； 新运行产生新Trace → 下一轮再挖。经验库不碰模型权重，是在上下文层加“行动经验”，和微调、RAG、Memory 都不是一回事。
PM视角：经验库是“自动驾驶模式”，但必须配护栏
经验生效前后必须走实验验证； 业务强规则（如“金额 > 5000 必须人工）不能让经验覆盖； 经验要带版本和适用范围，能回滚。 4. 两种调优模式：人开车 vs 自动驾驶 模式一：人类专家驱动（手工闭环）适用：业务上线初期，标准未固化。
链路：专家给 Rubric → 在线评估抓 badcase → 进数据集 → 实验回测 → 针对性改 Prompt/Skill。
产出物：可复用 Rubric + 标注数据集 + 实验报告。这部分最值钱的是把隐性判断显性化。
模式二：经验库全自动化适用：标准已稳，需要持续增益。
链路：开经验库 → 自动挖轨迹 → Skill 召回 → 实验验证收益。
原文提醒：通用维度（延时、调用准确率、路径冗余）可自动挖；业务自定义需求仍要实验验证，不能信“经验自动生效”。
PM 落地建议别一上来全自动。正确顺序是原文演示顺序：
先用手工闭环把 Rub端 和 badcase 集建起来（兜住底线）； 再开经验库在标准之上做增益； 经验库每次发版前必须跑消融实验。 5. 五篇路线图对 PM 的意义
照这个顺序做内部推行，比直接买平台稳：先接数据，再定标准，再回测，最后才谈自动进化。
6. 最后 AI PM 读完需要带走第一，操作路径：AgentSpace → OTel 接入 → 观测大盘 → 抓 badcase → 写 Rubric → 建实验 → 开经验库。每一步在平台有对应入口，和需求文档能一一对上。
第二，设计逻辑：
采样不是偷懒，是成本可控； Rubric 不是评估脚本，是业务标准资产； 经验库不是魔法，是 Trajectory 比对 + 护栏 + 消融验证； 飞轮关键在“首尾相接”，评估产出是实验输入，实验结论指回下一轮评估。第三，验证方法论：任何“Agent 变好了”的宣称，必须回答——和谁比（基线变体）、在同集上测吗、多指标吗（质量/耗时/成本/风险）、显著吗、经验注入走消融了吗。答不出这五句，就是原文说的“看几条吐槽改改 Prompt”。
Agent产品需要把上线后的工程治理当成主问题：
没有 OTel 级接入，你连 Agent 跑了啥都不知道； 没有 Rubric，调优标准是飘的； 没有实验回测，“优化”是玄学； 没有经验库+消融，规模上去后人肉闭环会断。作为AI 产品经理，你早期可能不写 Rubric 细节、不配探针股票反弹，但你要能在一张架构图里指出来：数据从哪进、Rubric 谁维护、实验门禁卡哪、经验注入出事怎么回滚。能把这条链讲顺，你在 Agent 项目里就不是记笔记的，而是能和设计评估体系的人。
元股证券投资中心提示：本文来自互联网，不代表本网站观点。
