DeepSeek Agent Harness 2026终极指南 - 第7章第34节 一句提示词做分析日志数据挖掘实战报表能看数字了但输出长度和耗时有线性关系吗“哪个时段调用最慢”“token 数有随时间增长的趋势吗”——这些藏在数字背后的规律靠肉眼扫报表看不出来。这节把 CallTracker 里的结构化数据喂给 DeepSeek用一句自然语言提问题让模型帮你挖规律。以后分析日志就是跟 Agent 聊天。本文导航从看报表到问模型LogAnalyzer把数据变成对话相关性分析代码实战五类典型问题的分析结果跟上届调用总结的数据闭环完整实录小结从看报表到问模型第 33 节的退出报表跑出来是这样的指标 最小 最大 平均 合计 输入 token 6 18 12.0 36 输出 token 4 234 82.3 247 总 token 10 252 94.3 283 耗时(秒) 0.92 5.37 2.83看这个表你能回答几个问题Q: “输出越长的调用越慢吗” → 三个数据点不好判断Q: “有没有某次调用特别异常” → 只能看 max5.37s但不知道是不是偶然Q: “token 利用率高吗”输出/输入 token 比→ 得手算但如果你的数据是 100 次调用呢1000 次呢肉眼看报表就废了。我们的 CallTracker 里每条记录都是结构化的——prompt_tokens、completion_tokens、elapsed_seconds……这些数据天然适合喂给 LLM 做分析。模型不需要做数学计算它只需要理解这些数字之间的关系、找出异常、生成人类可读的结论。CallTracker_records 列表提取为结构化 JSON拼装 System Prompt 数据 用户问题调 DeepSeek让模型分析人类可读的分析结论LogAnalyzer把数据变成对话在deep_pilot下新建log_analyzer.py# deep_pilot/log_analyzer.py —— 日志数据挖掘模块 v0.2from__future__importannotationsimportjsonfromtypingimportAnyfromdeep_pilot.call_trackerimportCallRecord,CallTrackerfromdeep_pilot.clientimportclientfromdeep_pilot.loggerimportget_logger loggerget_logger(__name__)classLogAnalyzer:用一句自然语言分析调用数据——背后是 DeepSeek 在做推理SYSTEM_PROMPT你是一个 API 调用数据分析助手。你会收到一份 DeepPilot Agent 的调用记录数据。 每条记录包含输入 token、输出 token、总 token、耗时秒、终止原因。 你需要根据用户的问题对这份数据进行分析并给出结论。 分析要求 1. 如果用户问平均值等统计问题给出准确数值。 2. 如果用户问关系如长度与速度的关系做相关性推理给出定性结论。 3. 如果发现异常值如某次耗时远超平均指出具体的异常记录。 4. 回答简洁、有据——每个结论后面附上具体数字作为证据。 5. 使用中文回答。 def__init__(self)-None:self._trackerCallTracker()defask(self,question:str)-str:一句提示词做分析recordsself._tracker.recordsifnotrecords:return暂无调用记录可供分析。# 把 CallRecord 列表转为模型友好格式data[{idx:i1,prompt_tokens:r.prompt_tokens,completion_tokens:r.completion_tokens,total_tokens:r.total_tokens,elapsed_seconds:round(r.elapsed_seconds,3),finish_reason:r.finish_reason,model:r.model,}fori,rinenumerate(records)]# 拼装 user messageuser_content\n\n.join([f以下是{len(data)}条 DeepPilot API 调用记录JSON 格式,json.dumps(data,ensure_asciiFalse),f\n用户问题{question},])# 调模型分析respclient.chat([{role:system,content:self.SYSTEM_PROMPT},{role:user,content:user_content},])returnresp.contentor模型未返回分析结果。defauto_analysis(self)-str:自动问一组预设问题生成综合分析报告questions[请给出本次运行的输入输出 token 和耗时的 min/max/avg/合计,输出 token 数和耗时之间是否存在正相关请给出判断依据,有没有明显异常的调用如果某次耗时明显超过平均值的 2 倍请指出,从 token 使用趋势来看输入输出比是否合理,]lines:list[str][]forqinquestions:answerself.ask(q)lines.append(fQ:{q}\nA:{answer}\n)return\n.join(lines)相关性分析代码实战如果你的数据量比较大50 条以上在喂给模型之前先做一个轻量级的相关性预分析可以帮助模型更准确地推理。用纯 Python 算 Pearson 相关系数defpearson_r(x:list[float],y:list[float])-float:计算皮尔逊相关系数——衡量两个变量线性相关的程度。返回值在 [-1, 1] 之间。nlen(x)ifn3:return0.0sum_x,sum_ysum(x),sum(y)sum_xxsum(v*vforvinx)sum_yysum(v*vforviny)sum_xysum(x[i]*y[i]foriinrange(n))numeratorn*sum_xy-sum_x*sum_y denominator((n*sum_xx-sum_x**2)*(n*sum_yy-sum_y**2))**0.5returnnumerator/denominatorifdenominator!0else0.0defpre_analyze(records:list[CallRecord])-dict[str,Any]:预分析计算耗时与输出 token 的相关系数、异常值等out_tokens[float(r.completion_tokens)forrinrecords]elapsed[r.elapsed_secondsforrinrecords]r_valuepearson_r(out_tokens,elapsed)avg_elapsedsum(elapsed)/len(elapsed)ifelapsedelse0anomalies[{idx:i1,elapsed:elapsed[i],out_tokens:out_tokens[i]}foriinrange(len(elapsed))ifelapsed[i]avg_elapsed*2]return{record_count:len(records),correlation_output_vs_elapsed:round(r_value,4),correlation_desc:(强正相关ifr_value0.7else中等正相关ifr_value0.3else弱相关或无相关ifr_value-0.3else负相关),avg_elapsed:round(avg_elapsed,3),anomalies_count:len(anomalies),anomalies:anomalies,}这个预分析可以附加到LogAnalyzer.ask()的 user message 里模型有了预分析的参考数字结论会更准确、更快。五类典型问题的分析结果假设你的 CallTracker 里攒了 30 条记录体验一下一句提示词的效果Q1: 性能趋势——“分析调用平均速度、最大最小”A: 本次 30 次调用分析 - 输入 token: min6, max142, avg35.2, 合计1056 - 输出 token: min4, max1523, avg218.7, 合计6561 - 总 token: min10, max1612, avg253.9, 合计7617 - 耗时: min0.89s, max12.34s, avg3.21sQ2: 相关性——“长度与速度的关系”A: 输出 token 数与耗时呈中等正相关 (r0.52)。 大部分调用随输出增长耗时增加但有几例例外 记录 #7: 输出 88 token 但耗时 8.2s明显异常可能网络抖动。 记录 #23: 输出 1423 token 但仅耗时 4.1s可能是缓存命中。 建议排查 #7 的网络状态并检查高频调用是否命中 Prefix Caching。Q3: 异常检测——“有没有明显异常的调用”A: 发现 2 次异常调用 记录 #7: 耗时 8.2s平均的 2.6 倍输出仅 88 token。建议检查网络延迟。 记录 #19: 耗时 11.5s平均的 3.6 倍输出 1523 token最长。高耗时主要由输出长度驱动属于正常但值得关注。Q4: Token 效率——“token 利用率怎么样”A: 输入输出比输出 token / 输入 token 平均 ratio 6.2中位数 ratio 4.8。 大部分调用的输出远大于输入token 利用效率较高。 但有 3 条记录的 ratio 1输出比输入少属于短回答场景正常。Q5: 综合报告——auto_analysis()这个方法自动问四组问题一口气给出综合报告。你可以在 atexit 退出总结后面接一行analyzer.auto_analysis()程序退出时不仅看分布数字还能看到模型对数据的解读。对于长期运行的 Agent这个自动分析的价值远大于干巴巴的 min/max/avg。跟上届调用总结的数据闭环这里补充一个重要的工程实践——第 31-34 节的调用留痕体系不是为做而做它确实构成了 Agent 开发的数据闭环Agent 运行产生调用CallTracker自动记录每条退出时print_exit_report()LogAnalyzer一句提示词分析发现慢调用发现异常模式调整参数优化提示词这个闭环的意义在于你不需要额外配监控系统、不需要学 SQL 做报表——Agent 自己产生数据、Agent 自己通过 DeepSeek分析数据、Agent 的分析结果指导你自己人类做优化。这是可观测性的最高境界。完整实录cddeep-pilot# 第一步攒一些真实调用数据uv run python-c from deep_pilot.client import client import random questions [你好, Python 列表推导式是什么, 写一个快速排序, 解释机器学习中的过拟合, 什么是哈希表, Python 装饰器原理, 写一个斐波那契, RESTful API 设计原则, Docker 和虚拟机的区别, SQL 中 JOIN 的类型] for q in questions: client.chat([{role: user, content: q}]) 10 次调用后跑分析uv run python-c from deep_pilot.log_analyzer import LogAnalyzer analyzer LogAnalyzer() # 一句提示词 print(analyzer.ask(分析调用平均速度、最大最小、长度与速度的关系)) # 输出# A: 本次 10 次调用分析# - 输入 token: min6, max32, avg16.8, 合计168# - 输出 token: min25, max892, avg286.5, 合计2865# - 耗时: min0.92s, max7.52s, avg3.34s## 输出 token 与耗时整体呈正相关——输出越长的调用耗时越长。# 具体看输出 25 token 的调用耗时 0.92s输出 892 token 的调用耗时 7.52s。# 但也存在波动记录 #5 输出 234 token 但耗时 4.12s# 而记录 #8 输出 245 token 仅耗时 2.15s可能是模型负载或网络延迟影响。# 建议对耗时异常的几次调用检查 trace 文件确认具体原因。小结结构化数据 LLM 自然语言数据分析。把 CallRecord 喂给模型用一句提示词挖规律。LogAnalyzer 把数据变成对话analyzer.ask(问题)返回人类可读的分析结论。相关性分析皮尔逊 r做预分析模型有了上下文数字结论更准确。auto_analysis()全自动出综合报告预设四组问题一口气出完整分析。数据闭环Agent 产生数据 → LogAnalyzer 分析数据 → 人类优化参数 → 更好的 Agent循环迭代。DeepPilot v0.2 日志留痕体系完整收尾——第 7 章第 30-34 节共 5 篇从日志双输出到退出总结到一句提示词分析全链路打通。下节预告日志留痕体系完整了该给 Agent 注入灵魂了——进入第 8 章Agent Loop 从零实现。下一节手写 Agent 最核心的引擎50 行代码实现完整 Agent Loop——组装消息 → 调模型 → 解析 tool_calls → 执行工具 → 回填结果 → 再调模型直到模型说完工。一个读天气玩具工具跑通全链路你会亲眼看到 Agent 的第一次呼吸。如果觉得本文对你有帮助欢迎点赞、收藏、关注三连本系列持续更新中关注不迷路~
DeepSeek-Agent-Harness-2026终极指南-第7章第34节-生产级日志与调用留痕-一句提示词做分析：日志数据挖掘实战
DeepSeek Agent Harness 2026终极指南 - 第7章第34节 一句提示词做分析日志数据挖掘实战报表能看数字了但输出长度和耗时有线性关系吗“哪个时段调用最慢”“token 数有随时间增长的趋势吗”——这些藏在数字背后的规律靠肉眼扫报表看不出来。这节把 CallTracker 里的结构化数据喂给 DeepSeek用一句自然语言提问题让模型帮你挖规律。以后分析日志就是跟 Agent 聊天。本文导航从看报表到问模型LogAnalyzer把数据变成对话相关性分析代码实战五类典型问题的分析结果跟上届调用总结的数据闭环完整实录小结从看报表到问模型第 33 节的退出报表跑出来是这样的指标 最小 最大 平均 合计 输入 token 6 18 12.0 36 输出 token 4 234 82.3 247 总 token 10 252 94.3 283 耗时(秒) 0.92 5.37 2.83看这个表你能回答几个问题Q: “输出越长的调用越慢吗” → 三个数据点不好判断Q: “有没有某次调用特别异常” → 只能看 max5.37s但不知道是不是偶然Q: “token 利用率高吗”输出/输入 token 比→ 得手算但如果你的数据是 100 次调用呢1000 次呢肉眼看报表就废了。我们的 CallTracker 里每条记录都是结构化的——prompt_tokens、completion_tokens、elapsed_seconds……这些数据天然适合喂给 LLM 做分析。模型不需要做数学计算它只需要理解这些数字之间的关系、找出异常、生成人类可读的结论。CallTracker_records 列表提取为结构化 JSON拼装 System Prompt 数据 用户问题调 DeepSeek让模型分析人类可读的分析结论LogAnalyzer把数据变成对话在deep_pilot下新建log_analyzer.py# deep_pilot/log_analyzer.py —— 日志数据挖掘模块 v0.2from__future__importannotationsimportjsonfromtypingimportAnyfromdeep_pilot.call_trackerimportCallRecord,CallTrackerfromdeep_pilot.clientimportclientfromdeep_pilot.loggerimportget_logger loggerget_logger(__name__)classLogAnalyzer:用一句自然语言分析调用数据——背后是 DeepSeek 在做推理SYSTEM_PROMPT你是一个 API 调用数据分析助手。你会收到一份 DeepPilot Agent 的调用记录数据。 每条记录包含输入 token、输出 token、总 token、耗时秒、终止原因。 你需要根据用户的问题对这份数据进行分析并给出结论。 分析要求 1. 如果用户问平均值等统计问题给出准确数值。 2. 如果用户问关系如长度与速度的关系做相关性推理给出定性结论。 3. 如果发现异常值如某次耗时远超平均指出具体的异常记录。 4. 回答简洁、有据——每个结论后面附上具体数字作为证据。 5. 使用中文回答。 def__init__(self)-None:self._trackerCallTracker()defask(self,question:str)-str:一句提示词做分析recordsself._tracker.recordsifnotrecords:return暂无调用记录可供分析。# 把 CallRecord 列表转为模型友好格式data[{idx:i1,prompt_tokens:r.prompt_tokens,completion_tokens:r.completion_tokens,total_tokens:r.total_tokens,elapsed_seconds:round(r.elapsed_seconds,3),finish_reason:r.finish_reason,model:r.model,}fori,rinenumerate(records)]# 拼装 user messageuser_content\n\n.join([f以下是{len(data)}条 DeepPilot API 调用记录JSON 格式,json.dumps(data,ensure_asciiFalse),f\n用户问题{question},])# 调模型分析respclient.chat([{role:system,content:self.SYSTEM_PROMPT},{role:user,content:user_content},])returnresp.contentor模型未返回分析结果。defauto_analysis(self)-str:自动问一组预设问题生成综合分析报告questions[请给出本次运行的输入输出 token 和耗时的 min/max/avg/合计,输出 token 数和耗时之间是否存在正相关请给出判断依据,有没有明显异常的调用如果某次耗时明显超过平均值的 2 倍请指出,从 token 使用趋势来看输入输出比是否合理,]lines:list[str][]forqinquestions:answerself.ask(q)lines.append(fQ:{q}\nA:{answer}\n)return\n.join(lines)相关性分析代码实战如果你的数据量比较大50 条以上在喂给模型之前先做一个轻量级的相关性预分析可以帮助模型更准确地推理。用纯 Python 算 Pearson 相关系数defpearson_r(x:list[float],y:list[float])-float:计算皮尔逊相关系数——衡量两个变量线性相关的程度。返回值在 [-1, 1] 之间。nlen(x)ifn3:return0.0sum_x,sum_ysum(x),sum(y)sum_xxsum(v*vforvinx)sum_yysum(v*vforviny)sum_xysum(x[i]*y[i]foriinrange(n))numeratorn*sum_xy-sum_x*sum_y denominator((n*sum_xx-sum_x**2)*(n*sum_yy-sum_y**2))**0.5returnnumerator/denominatorifdenominator!0else0.0defpre_analyze(records:list[CallRecord])-dict[str,Any]:预分析计算耗时与输出 token 的相关系数、异常值等out_tokens[float(r.completion_tokens)forrinrecords]elapsed[r.elapsed_secondsforrinrecords]r_valuepearson_r(out_tokens,elapsed)avg_elapsedsum(elapsed)/len(elapsed)ifelapsedelse0anomalies[{idx:i1,elapsed:elapsed[i],out_tokens:out_tokens[i]}foriinrange(len(elapsed))ifelapsed[i]avg_elapsed*2]return{record_count:len(records),correlation_output_vs_elapsed:round(r_value,4),correlation_desc:(强正相关ifr_value0.7else中等正相关ifr_value0.3else弱相关或无相关ifr_value-0.3else负相关),avg_elapsed:round(avg_elapsed,3),anomalies_count:len(anomalies),anomalies:anomalies,}这个预分析可以附加到LogAnalyzer.ask()的 user message 里模型有了预分析的参考数字结论会更准确、更快。五类典型问题的分析结果假设你的 CallTracker 里攒了 30 条记录体验一下一句提示词的效果Q1: 性能趋势——“分析调用平均速度、最大最小”A: 本次 30 次调用分析 - 输入 token: min6, max142, avg35.2, 合计1056 - 输出 token: min4, max1523, avg218.7, 合计6561 - 总 token: min10, max1612, avg253.9, 合计7617 - 耗时: min0.89s, max12.34s, avg3.21sQ2: 相关性——“长度与速度的关系”A: 输出 token 数与耗时呈中等正相关 (r0.52)。 大部分调用随输出增长耗时增加但有几例例外 记录 #7: 输出 88 token 但耗时 8.2s明显异常可能网络抖动。 记录 #23: 输出 1423 token 但仅耗时 4.1s可能是缓存命中。 建议排查 #7 的网络状态并检查高频调用是否命中 Prefix Caching。Q3: 异常检测——“有没有明显异常的调用”A: 发现 2 次异常调用 记录 #7: 耗时 8.2s平均的 2.6 倍输出仅 88 token。建议检查网络延迟。 记录 #19: 耗时 11.5s平均的 3.6 倍输出 1523 token最长。高耗时主要由输出长度驱动属于正常但值得关注。Q4: Token 效率——“token 利用率怎么样”A: 输入输出比输出 token / 输入 token 平均 ratio 6.2中位数 ratio 4.8。 大部分调用的输出远大于输入token 利用效率较高。 但有 3 条记录的 ratio 1输出比输入少属于短回答场景正常。Q5: 综合报告——auto_analysis()这个方法自动问四组问题一口气给出综合报告。你可以在 atexit 退出总结后面接一行analyzer.auto_analysis()程序退出时不仅看分布数字还能看到模型对数据的解读。对于长期运行的 Agent这个自动分析的价值远大于干巴巴的 min/max/avg。跟上届调用总结的数据闭环这里补充一个重要的工程实践——第 31-34 节的调用留痕体系不是为做而做它确实构成了 Agent 开发的数据闭环Agent 运行产生调用CallTracker自动记录每条退出时print_exit_report()LogAnalyzer一句提示词分析发现慢调用发现异常模式调整参数优化提示词这个闭环的意义在于你不需要额外配监控系统、不需要学 SQL 做报表——Agent 自己产生数据、Agent 自己通过 DeepSeek分析数据、Agent 的分析结果指导你自己人类做优化。这是可观测性的最高境界。完整实录cddeep-pilot# 第一步攒一些真实调用数据uv run python-c from deep_pilot.client import client import random questions [你好, Python 列表推导式是什么, 写一个快速排序, 解释机器学习中的过拟合, 什么是哈希表, Python 装饰器原理, 写一个斐波那契, RESTful API 设计原则, Docker 和虚拟机的区别, SQL 中 JOIN 的类型] for q in questions: client.chat([{role: user, content: q}]) 10 次调用后跑分析uv run python-c from deep_pilot.log_analyzer import LogAnalyzer analyzer LogAnalyzer() # 一句提示词 print(analyzer.ask(分析调用平均速度、最大最小、长度与速度的关系)) # 输出# A: 本次 10 次调用分析# - 输入 token: min6, max32, avg16.8, 合计168# - 输出 token: min25, max892, avg286.5, 合计2865# - 耗时: min0.92s, max7.52s, avg3.34s## 输出 token 与耗时整体呈正相关——输出越长的调用耗时越长。# 具体看输出 25 token 的调用耗时 0.92s输出 892 token 的调用耗时 7.52s。# 但也存在波动记录 #5 输出 234 token 但耗时 4.12s# 而记录 #8 输出 245 token 仅耗时 2.15s可能是模型负载或网络延迟影响。# 建议对耗时异常的几次调用检查 trace 文件确认具体原因。小结结构化数据 LLM 自然语言数据分析。把 CallRecord 喂给模型用一句提示词挖规律。LogAnalyzer 把数据变成对话analyzer.ask(问题)返回人类可读的分析结论。相关性分析皮尔逊 r做预分析模型有了上下文数字结论更准确。auto_analysis()全自动出综合报告预设四组问题一口气出完整分析。数据闭环Agent 产生数据 → LogAnalyzer 分析数据 → 人类优化参数 → 更好的 Agent循环迭代。DeepPilot v0.2 日志留痕体系完整收尾——第 7 章第 30-34 节共 5 篇从日志双输出到退出总结到一句提示词分析全链路打通。下节预告日志留痕体系完整了该给 Agent 注入灵魂了——进入第 8 章Agent Loop 从零实现。下一节手写 Agent 最核心的引擎50 行代码实现完整 Agent Loop——组装消息 → 调模型 → 解析 tool_calls → 执行工具 → 回填结果 → 再调模型直到模型说完工。一个读天气玩具工具跑通全链路你会亲眼看到 Agent 的第一次呼吸。如果觉得本文对你有帮助欢迎点赞、收藏、关注三连本系列持续更新中关注不迷路~
