企业官网建设流程全解析

从 Demo 到生产：构建 Agent 持续调优闭环的第一步——高质量数据接入指南

把 Agent 从 Demo 推到生产，是我这几年见过最容易被低估的一关。Demo 跑通了、发布会演示完美、领导点头了，结果一接真实业务就崩：用户问法稍微换个说法就答非所问，工具调用偶尔成功偶尔失败，链路一长上下文就开始乱。最头疼的是出了问题根本不知道是哪一环的锅。我排查过不少团队的 Agent 项目，结论很一致：绝大多数据问题，根子不在模型、不在框架，而在数据接入。这里说的“数据”，不只是喂给模型的语料，而是 Agent 运行过程中产生和消费的所有结构化信息。高质量数据接入，就是从 Demo 走向生产的真正分水岭。这篇文章我会把我在多套 Agent 框架（含各类 agent 智能体项目、mcp 服务 demo、本地部署实践）上积累的数据接入经验完整拆开，讲清楚接入什么、怎么算高质量、怎么落地，以及踩过的那些坑。

1. 先认清：Demo 与生产之间的三道深坑

1.1 Demo 永远在“温室”，生产永远是“野外”

很多人没意识到，一个 Agent Demo 能跑通，不代表它有任何生产价值。Demo 的本质是“在可控条件下证明可行性”：输入是预设的、路径是单一的、数据几乎是干净的。你在演示 pi agent 或 hermes agent 这类项目时，可能只准备了三五个问题模板，模型输出稍有偏差也不影响大局。但生产环境是完全不同的动物：用户输入五花八门，情绪化表达、口语化缩写、错别字、夹杂术语，没人按你的脚本说话。工具返回的数据格式可能随时变动，第三方 API 超时，数据库字段为空，缓存命中失败——每一条都是真实世界塞给你的脏数据。

我见过一个团队把带记忆能力的 agent 项目从 demo 推到生产，发现用户聊了十轮之后，Agent 开始把之前对话的错误信息当成事实引用，因为记忆模块在 demo 阶段只测了三轮以内的会话。这不是个别问题，而是“温室环境”养成的错觉。Demo 阶段的 Agent 结构完整、框架选型正确、界面精美，但一旦脱离温室，第一个暴露问题的永远是数据层：数据缺失、数据冲突、数据不可用。这就像一台发动机在实验台上转速平稳，装上车跑颠簸路面就开始抖动——问题不在发动机设计图，而在它接收到的路况数据。

1.2 从 Demo 到生产的本质：输入域和反馈回路的剧变

这个变化是结构性的，不是量变。我习惯从两个维度去理解这层剧变：输入域的扩展和反馈回路的复杂化。

先看输入域。Demo 阶段，我们的 Agent 通常只有一条主输入通道：用户提问。生产阶段，Agent 的输入是多源、多类型、多时序的。用户指令只是一部分，还有工具返回的结构化数据、外部 API 推送的事件、数据库中查询到的历史记录、上游系统传递的上下文参数。举个例子，一个做智能客服的 Agent，demo 阶段你只管用户的文字问题，生产阶段你要同时处理用户画像数据、订单状态、商品库存、CRM 系统的事件推送，还要感知用户之前是否已经转接过人工。输入域的扩展，意味着 Agent 的数据接入层必须面对一个残酷事实：数据不是为你准备的，每套系统都有自己的数据方言。

再看反馈回路。Demo 阶段，我们的反馈回路是“模型输出 → 人工观察 → 手动调整 prompt 或参数”。这个回路可以很慢，因为 demo 场景下不追求效率。生产环境，反馈回路必须自动化、可度量、可追踪。你的 Agent 每天可能要处理数千次请求，你不可能逐条人工判断输出质量，你需要自动化的质量评估机制，需要把失败案例自动回传给调优流程，需要知道每一次工具调用成功还是失败、在哪一步超时、模型在哪一轮开始产生幻觉。这一整套反馈回路能运转的前提，就是有高质量的数据接入——没有数据，所有调优都是盲人摸象。

1.3 高质量数据接入是持续调优闭环的起点

我把 Agent 从 Demo 推向生产的过程总结为一个持续调优闭环：数据接入 → 运行观测 → 问题识别 → 针对性调优 → 回归验证 → 又回到数据接入。这个闭环的每一步都依赖数据，而数据接入是第一步，也是决定整个闭环上限的一步。你不可能在数据不可用、不完整、不准确的情况下讨论“持续调优”，那只是自我安慰。

我经常用这个类比来跟朋友解释：Agent 持续调优就像养一盆植物。Prompt 工程是修剪枝叶，模型微调是换土壤品种，而数据接入是根系——根系没扎好，上面怎么修剪都没用。很多团队的问题恰恰是根系发育不良：数据接了，但接的是污水，植物越长越歪。所谓高质量数据接入，就是要先保证根系吸收的是干净、均衡、富含营养的水。

2. 数据接入到底接什么：从输入到回补的完整视图

2.1 第一层：上游业务数据接入

这是最基础、也最容易被忽视的一层。上游业务数据，指 Agent 处理一个请求时需要依赖的所有外部信息——用户信息、业务订单、产品目录、权限体系、历史交互记录等。这些数据通常在 Agent 之外的其他系统中，通过 API、消息队列、数据库直连等方式获取。

做这层接入的时候，我最常提醒团队的一件事是：不要贪多，先明确 Agent 的“最小必要数据包”。什么意思？就是说，Agent 处理每一类任务到底需要哪些字段，把字段清单列出来，然后只接这些，其他一律不碰。为什么？因为每多接一个字段，就多一层出错的可能性，也会增加数据链路排查的复杂度。一个做订单查询的 Agent，核心数据包无非是订单号、用户 ID、订单状态、商品列表、金额——其他什么“用户星座”这种字段，接进来纯属添乱。

另一个要点是数据时效性。Agent 拿到的数据必须是当前时刻的真实状态，而不是某个时间点的快照。我在一个供应链 Agent 项目上踩过坑：当时数据接入层做的是每小时同步一次库存表，用户问“这个商品有货吗”，Agent 查到的还是两小时前的库存快照，结果用户下单之后才发现缺货，体验非常糟糕。后来改成实时查询库存服务接口，问题才解决。数据接入不是“把数据倒进来”就完了，你还要确认数据的有效期、刷新频率、是否存在缓存。

2.2 第二层：中间过程数据接入

中间过程数据，是 Agent 运行过程中产生的过程性信息，很多人叫它“轨迹数据”或“运行日志”。这一步是 Demo 阶段几乎不会考虑、生产阶段却无比关键的数据类型。它包含哪些东西呢？用户的原始输入、Agent 内部对用户意图的理解、选定的工具、传给工具的参数、工具的原始返回、模型每一步的中间输出、token 消耗、耗时、模型版本号、prompt 版本号……

为什么要接这层数据？我举一个真实发生过的例子。一个基于 codex agent 部署的项目，用户反馈“Agent 有时候会擅自修改不该改的文件”。团队查了很久，始终复现不出来。后来我们把 Agent 的每一步动作都记录下来——每一步调了哪个工具、传了什么参数、模型当时看到了什么上下文——最终发现，问题出在一个工具返回的 JSON 数据里某个字段出现了意想不到的值，导致模型误判了文件归属。没有中间过程数据，这个 bug 可能永远查不出来。

中间过程数据还有一个重要用途：作为调优的“训练样本”。当你的 Agent 在测试集上表现不佳时，你总不能把整个对话重新跑一遍来分析吧？但如果你记录了完整的中间过程，你就可以精确定位到哪一步出了问题，是用户意图识别错了，还是工具调用参数构造错了，还是模型最终输出组织错了。这种精细定位能力，是高质量调优的前提。我一直认为，Agent 的可观测性设计，应该和 Agent 的功能设计同时进行，而不是事后补。

2.3 第三层：反馈与评估数据接入

前两层接入的是“已经发生的事实”，第三层接入的是“主观/半主观的评价信号”。这些信号用来判定 Agent 的输出到底是好是坏，是持续调优闭环中最核心的燃料。反馈数据来源很多元：用户对回答的点赞/点踩、用户的显式评价、后续交互行为（用户是否重复提问、是否转人工、是否投诉）、业务结果（订单是否成交、工单是否解决、任务是否完成）、以及人工标注团队给的标签。

这层数据往往是接入难度最大的，因为它分散在各个地方，而且标准很难统一。比如，用户没有点踩，但也没有完成购买，那 Agent 的回答算好还是算坏？用户直接关闭了对话，是表示满意还是不满意？这些信号天然带有模糊性，不能简单用二元判断来处理。我的建议是：接入所有可获得的反馈信号，并给每个信号赋予明确含义，同时记录信号的获取时间、获取场景、对应哪一轮对话。宁可多接一点模糊信号，也不要只依赖单一片面信号。

特别要强调一点：不要只接“明示反馈”，要重视“隐式反馈”。明示反馈就是用户明确夸、骂、点赞、点踩，这种数据量往往很少，因为大多数用户并不会主动给反馈。隐式反馈才是数据的大头：用户问完之后是否立刻点了链接、是否继续追问、停留在页面的时长、是否复制了你的回答……这些行为信号虽然不如明示信号那么直接，但胜在量大、客观、持续产生。把隐式反馈接入进来，你就搭起了一个几乎实时的质量雷达。

3. 高质量数据接入的四个标准

3.1 完整性：字段缺一不可，上下文闭环

高质量数据的第一条标准是完整性。什么叫完整？就是从“用户发出请求”到“Agent 完成响应”这一整条链路上，每个关键步骤的数据都必须被记录，不能缺环。很多团队接数据的时候只接输入输出，中间过程一概不记，结果出了问题只能看到“用户问了什么”和“Agent 回了什么”，中间发生了什么完全不知道，调优自然无从谈起。

项目实践中，我建议你自己列一张“必接清单”，逐项核对。我自己的清单大概长这样：请求 ID、用户 ID、会话 ID、时间戳（精确到毫秒）、模型版本、prompt 版本、完整对话上下文、所选工具、工具参数、工具返回、每步耗时、token 消耗、最终输出、用户后续行为。列完之后，你还要检查：这些字段是否在每一次请求中都会被记录？如果没有，是代码分支漏了，还是某个中间环节根本没有埋点？

还有一个常见问题：上下文不闭环。比如你只记录了“用户输入了什么”，却没有记录“Agent 当时已经掌握的上下文”——它看到的前几轮对话、它从知识库检索到的资料、它从工具拿到的数据，这些都是它做出判断的依据。不记录这些，你无法复盘“为什么它会这样回答”，因为你根本不知道它“当时看到了什么”。上下文闭环，是“可解释调优”的最低要求。

3.2 可追溯性：从结果一路追到源头

可追溯性意味着：给定一个 Agent 输出结果，你能顺着数据链路一路往前查，查清这个结果是基于什么输入、什么逻辑、什么数据产生的。这听起来好像很简单，但实际做到非常困难，因为链路里会有多个系统交互：Agent 框架、模型服务、工具服务、知识库、缓存、数据库，每个系统都有自己的日志，要用一个统一的 trace 串起来。

我的习惯是，从上到下贯通一个 trace_id（追踪 ID）。在 Agent 接收请求的那一刻生成这个 ID，然后传给每一个下游环节——调用大模型时带上、调用工具时带上、写日志时带上、写入数据库时带上。整个链路的所有数据都挂在这个 ID 下面。这样出了问题，只要拿到用户的请求 ID，就能把整条链路的日志捞出来一条一条看。

这里有一个实践技巧：trace_id 最好在入口网关生成，而不是在 Agent 代码内部生成。因为生产环境前面往往还有负载均衡、API 网关，如果 Agent 自己生成 ID，网络层产生的日志就串不起来了。你在网关层生成 trace_id，然后通过 HTTP header 传入 Agent 服务，Agent 内部再传给所有下游，这才是完整的可追溯链路。我在 mcp 服务 demo 项目上遇到过一次类似问题，工具层报错，但工具日志里根本搜不到请求，因为 trace_id 没有传进去，查了一个下午。

3.3 可回放性：有了数据就能重现现场

可回放性指什么呢？就是你记录的数据，要能够支撑你在离线环境重新“演一遍”当时的现场。这是 Agent 持续调优的一个关键利器。理想状态下，你拿到一条线上记录，能在本地把当时 Agent 的输入、上下文、工具返回都还原出来，重新跑一遍模型，看看它这次输出什么——和线上输出对比，就知道模型版本变化、prompt 调整、上下文丢失等种种因素对结果的影响。

实现可回放有几个前提。第一，时间戳要足够精确，至少要精确到毫秒，因为同一秒内可能有多个请求。第二，数据不能做破坏性截断，比如某些日志系统默认只保留 4KB 日志，超出的部分直接被截掉——回放的时候这截掉的部分可能恰好就是关键信息。第三，关键字段要保留原始值，比如工具返回的原始 JSON，而不是经过你处理之后的解析结果；模型输出的原始文本，而不是去掉某些符号之后的“干净版本”。

还有一个很多人忽视的细节：随机性的处理。大模型本身是有随机性的——同样的输入，温度高于 0，输出就可能不同。所以“可回放”做不到 100% 还原，但你可以记录当时使用的模型参数（temperature、top_p 等），回放时使用相同的参数，至少能让结果分布大致对齐。如果是确定性优先的场景（比如有业务逻辑判断在模型输出之前），那记录 seed 会很有用。

3.4 结构化程度：别把日志当成垃圾桶

最后一个标准，也是最容易被忽视的：数据要认真设计 schema（数据结构），而不是把各色信息丢进一个日志文件里不管。我见过太多团队，自称“接了数据”，其实只是用 print 把信息打到标准输出，或者把所有变量统统塞进一个 JSON 对象里，字段名随意、类型混乱、嵌套层次深浅不一。这种数据，接了就等于没接——你根本无法对它做什么像样的分析、统计或自动化处理。

高质量的数据接入，要求你在设计阶段就想清楚 schema。每条记录的字段名要统一、类型要明确、层级要规范。我一般用 JSON Lines 格式做结构化日志——每行一个 JSON 对象，字段固定，方便用任意分析工具处理。schema 示例放后面的实操部分，这里先强调一个原则：宁可让 schema 设计花上一两天时间，也绝对不要在生产之后再来“补规范”。后期改 schema，等于把所有消费这条数据的分析任务、监控告警、回放脚本全部推翻重来，成本大得惊人。

4. 高质量数据接入的实操落地：一套可复用的接入方案

4.1 整体架构：三条数据管道

前面讲了一堆概念，这里给一个可落地的方案参考。我把数据接入做成三条并行的数据管道，用词可能比较工程化，但你一看就会明白。

第一条管道是请求-响应日志管道，负责记录 Agent 每个请求的外部行为，输入输出、耗时、状态码、token 消耗都在这条管道里。第二条管道是轨迹细节管道，负责记录 Agent 内部每一步的运转细节，意图识别结果、工具调用、中间决策点。第三条管道是反馈采集管道，负责收集用户反馈、业务结果、标注数据。三条管道各有侧重，但用同一个 trace_id 串起来，互相之间可以关联查询。

这个设计的好处是职责清晰、互不污染。丢掉一条细节管道里的日志，不影响外部行为数据的完整；反馈数据格式变了，也不需要改动轨迹日志的结构。我之前看到某些团队把这三类数据全部写在一个表里，结果字段爆炸、写入冲突、查询缓慢，教训很深刻。

4.2 数据结构 Schema 设计实例

这一步最关键，我直接给一套我常用的 schema 设计，你可以根据自己的场景裁剪。

请求-响应日志（request_log）：

{ "trace_id": "2b69c8f0-1a4b-4b7c-9e63-7a1f27d0d0a1", "session_id": "sess_20250117_001122", "user_id": "u_100234", "timestamp": "2025-01-17T15:04:12.382+08:00", "model_name": "gpt-4o-2024-11-20", "model_temperature": 0.7, "prompt_version": "v1.4.2", "input_text": "帮我看看这个订单为什么还没发货", "output_text": "您好，您的订单（#20250108001）目前处于待发货状态，预计将在今天下午 6 点前发出。", "input_tokens": 356, "output_tokens": 48, "latency_ms": 1821, "status": "success" }

注意prompt_version——不要小看这个字段，它记录的是当时用的 prompt 模板版本。没有它，将来你想复盘“v1.3 到 v1.4 的 prompt 变化到底有没有改善效果”，根本无从对比。

轨迹细节日志（trace_detail_log）：

{ "trace_id": "2b69c8f0-1a4b-4b7c-9e63-7a1f27d0d0a1", "sequence": 1, "event_type": "intent_detected", "event_time": "2025-01-17T15:04:12.410+08:00", "content": {"intent": "order_status_query", "confidence": 0.93, "entities": {"order_id": "20250108001"}} } { "trace_id": "2b69c8f0-1a4b-4b7c-9e63-7a1f27d0d0a1", "sequence": 2, "event_type": "tool_call", "event_time": "2025-01-17T15:04:12.450+08:00", "content": {"tool_name": "order_query_api", "args": {"order_id": "20250108001"}, "result_status": "success", "result_summary": "订单待发货，预计今日18点前发出"} }

关键的细节是sequence字段——记录事件在本次请求中的先后顺序。因为生产环境并发很高，如果不同时记录序列号，光靠时间戳可能无法确定事件先后顺序，时间戳精度不够时尤其危险。event_type建议用枚举值，不要随意自由发挥，方便下游做统计和分类。

反馈采集日志（feedback_log）：

{ "trace_id": "2b69c8f0-1a4b-4b7c-9e63-7a1f27d0d0a1", "feedback_type": "thumb_up", "feedback_value": 1, "feedback_time": "2025-01-17T15:04:18.920+08:00", "source": "user_explicit", "content": "", "attached_task_id": "order_query_20250117" }

反馈日志与请求日志共用同一个 trace_id。这样，当你想统计“某类问题的用户打压率是否下降”，只需要把三类日志关联起来，即可完成统计口径的校验。

4.3 埋点实现：在 Agent 管线中做结构化日志

收起 schema，聊聊具体埋点实现。现在主流的 agent 框架——不管是开源的 agent 框架，还是自己写的智能体编排引擎——几乎都有中间件或回调机制，这是埋点的最佳位置。你不需要在每个业务函数里手写日志，正确的做法是利用框架的拦截能力，在关键节点自动记录。下面是一个用 Python 风格表示的结构化日志埋点示例（框架无关，核心是思想）：

import json import uuid import time import logging logger = logging.getLogger("agent_dsl") def generate_trace_id(): return str(uuid.uuid4()) def emit_log(trace_id, sequence, event_type, content): record = { "trace_id": trace_id, "sequence": sequence, "event_type": event_type, "event_time": time.strftime("%Y-%m-%dT%H:%M:%S.%f%z"), "content": content, } logger.info(json.dumps(record, ensure_ascii=False)) def wrap_tool_call(trace_id, sequence, tool_name, args, func): emit_log(trace_id, sequence, "tool_call_start", { "tool_name": tool_name, "args": args, }) seq = sequence + 1 try: result = func(**args) emit_log(trace_id, seq, "tool_call_end", { "tool_name": tool_name, "result_status": "success", "result_summary": truncate(str(result), 500), }) return result except Exception as e: emit_log(trace_id, seq, "tool_call_end", { "tool_name": tool_name, "result_status": "error", "error": str(e), }) raise

几个要点说明一下。第一，result_summary字段我建议只存截断后的摘要，不要把完整的大数据结果都塞进日志，一是日志体积会爆炸，二是分析端真正常用的往往只是摘要；完整的结果可以放到独立的存储中，通过 trace_id 关联。第二，埋点必须在真实调用路径的主干上，不要在无关紧要的地方做过度埋点，否则字节成本持久累积会很可观。第三，埋点代码一定要做异常隔离——埋点自身的失败绝不能影响主业务流程，用 try/except 包住埋点逻辑，或者使用异步发送，是基本的工程安全意识。

4.4 上线前必须检查的三个配置项

埋点写完之后，别急着上线。我每次都会在正式环境部署前检查三个配置项，可以说是用真金白银换来的教训。

第一个是采样率。Demo 阶段你想全量就全量，生产环境你的 Agent 每天可能有几十万次请求，全量存日志，存储成本會让你肉疼。我的建议是：轨迹细节日志按 10%-20% 采样，请求-响应日志和反馈日志全量存。采样部分必须带上 trace_id，这样后续分析时能把采样数据和全量反馈对应上，才不会“采了样没法关联”。

第二个是日志保存周期。硬盘不是无限的，日志会越攒越多。我的默认策略是：轨迹日志保留 7 天，请求-响应日志保留 30 天，反馈数据与人工标注数据长期保存。超过保存周期的冷数据，定期转存到对象存储后删除，保持热数据区间的轻量。注意，这里要回避任何敏感的数据描述，正常的技术方案而已。

第三个是数据脱敏。Agent 处理业务数据时不可避免会碰到用户隐私信息——手机号、身份证、家庭住址。埋点时，你需要在写入日志之前就对敏感字段做脱敏处理（比如手机号只保留前三位后四位），而不是等数据到了分析工具再清洗。数据一旦进了日志系统，再想控制访问范围就很困难了。所以，脱敏动作一定要前置，在埋点函数内部完成。

5. 常见问题与排查技巧实录

5.1 我踩过的三个硬件场景坑

先聊几个我在不同项目里真实踩过的坑，这些场景各不一样，但底层逻辑相通。

第一个坑来自一个 3D 视觉相关的 demo 项目（3dgs 三维重建场景）。那时候我天真地想：“这不就是个 demo 吗，埋点简单一点就行。”于是只接了一个简易的日志文件，记录每次请求的结果，没有做结构化。等后面要拿这些数据做调优分析时，我面对的是几万行格式混乱的文本，字段缺失、顺序颠倒、编码混杂，根本没法用。最后我花了一整天写脚本清洗这些“数据垃圾”，刻骨铭心。从此以后，我无论再小规模的项目，也会先把 schema 定下来再动手。

第二个坑来自一个嵌入式场景（stm32h743vit6 rs485 相关的采集 Demo 项目）。嵌入式设备和服务器不同，资源极其紧张，日志写入量稍大一点就可能影响性能。我当时在 Agent 服务端做了完整的结构化埋点，却忽略了边缘端的性能限制，结果边缘端日志频繁丢失，链路数据断成一段一段，根本无法形成完整轨迹。后来我只能采用“轻量上传 + 关键词过滤”的方式，把边缘端的记录压缩到最小可接受的粒度，再在服务端补齐上下文信息。生产环境的数据接入，必须考虑每一条链路的物理条件，不能一刀切。

第三个坑来自一个移动端 demo 项目（android kotlin compose 相关）。Kotlin 侧写起来很爽，但埋点逻辑分散在各个 Composable 里，测试的时候经常忘了改采样参数，结果测试流量把生产日志池的预算直接打爆。后来我在接入层做了一个统一的“环境标签”字段，系统区分 dev/test/prod 环境，成本分析和告警全都按环境维度切分，才彻底治好这个问题。

5.2 常见问题速查表

把常见问题整理一下，方便你排查时直接对照。

5.3 什么时候才需要上正式的“数据平台”

很多团队一开始会纠结：我是不是得上一个复杂的日志系统/OLAP 平台/用户行为分析工具？我给的答案非常务实：先把手动日志模型跑通，不要一上来就追求重基础设施。

我推荐的演进路径是这样的。第一步，用 JSON Lines 文件落地日志就行，配合一个简单的日志检索工具，够用了；第二步，请求量上来之后，引入一个轻量的日志存储服务，解决文件可靠性低、不能多维度检索的问题；第三步，当需要做质量分评估、自动回归报告、数据可视化和监控告警，再考虑建设完整的数据平台。每一步推进的前提，都是你手头的数据分析需求真的到了这一步，而不是因为隔壁团队上了什么系统你也想跟风。

顺便提一句，现在很多 agent 框架其实自带了一些基础观测能力，你先用起来再说。包括本地部署 hermes agent 或某些自带观测面板的开源 agent 项目时，你优先使用的应该是它内置的日志模块和告警通道，而不是自己另起一套基础设施，这样既降低维护成本，又能快速跑通数据接入闭环。

6. 几条经过验证的避坑建议

最后分享几条我在实战中沉淀下来的经验。

第一，把“数据接入”当成一等需求来排期，而不是开发完 Agent 之后的后续项。我见过太多项目的排期是“Agent 功能开发 4 周，压测 1 周，数据接入 0 天”——这是必死排期。数据接入要在第一个可运行版本出来之前就同步启动。哪怕代码还没写完，先把 schema 定义好、把埋点框架铺好，后面只会越来越顺。

第二，尽量让 Agent 内部使用的上下文，最终都能通过 trace 关联到源头。模型产生了幻觉，很多情况是因为给它喂了不准确或过时的上下文。有了“上下文可溯源”这层设计，你排查“模型为什么会瞎说”的能力会提升一个数量级。做法很简单：每次向模型发送 prompt 前，把检索到的知识来源、工具返回结果、历史对话的截断策略都记一条 trace。

第三，抽一点时间做“数据体检”。我的节奏是每两周做一次，随机抽取 100 条带反馈的请求日志，人工过一遍：Agent 输出是否与当时上下文匹配，埋点数据是否完整，有没有明显异常的事件序列。这个动作花不了多少时间，但对整个数据链路的健康度帮助很大。数据接入是一个持续运营的工程，不是上线就完事。

把高质量数据接入做好了，Agent 的持续调优闭环才能转起来。之后你做的 prompt 优化、模型微调、工具策略调整，才能有清晰的评估标准和优化依据。可以说，数据接入的质量，决定了你的 Agent 在生产环境中能走多远。