1. 项目概述：为什么我们需要“透明”的AI Agent？

最近在折腾AI Agent项目，从最初的Demo跑通，到真正部署上线处理实际业务，我踩过最大的一个坑就是：Agent一旦跑起来，你根本不知道它在“想”什么。它就像一个黑盒，你输入一个指令，比如“帮我分析一下上周的销售数据并给出建议”，然后你就只能干等着。它可能卡在调用某个API的权限验证上，也可能陷入了无限循环的自我对话，甚至可能因为一个未处理的异常直接“装死”了。你看到的只有最终那个可能出错、也可能延迟很久的结果，中间的过程完全不可知。

这就是“黑盒”的痛点。对于开发者而言，调试和排错成本极高；对于业务方而言，无法信任一个无法解释其决策过程的“智能体”。因此，将AI Agent从“黑盒”变为“透明”，构建一套完整的运行监控体系，就成了项目从玩具走向生产环境的必经之路。这不仅仅是加几行日志那么简单，它涉及到对Agent思维链的追踪、工具调用的审计、资源消耗的度量以及异常状态的实时告警。

简单来说，这个实战的目标是：给你的AI Agent装上“仪表盘”和“行车记录仪”。你能实时看到它的“思考步骤”（Chain of Thought）、它调用了哪些“工具”（Tools）、每次调用的输入输出、整个流程的耗时，以及资源使用情况。当它“抛锚”或“走错路”时，你能第一时间收到警报，并快速定位问题根源。

2. 监控体系的核心维度与设计思路

一个完整的AI Agent监控体系，不能只盯着最终输出。我们需要从多个维度去透视其内部运行状态，就像给一个复杂的分布式系统做APM（应用性能监控）一样。基于实战经验，我将其归纳为四个核心维度。

2.1 思维链（CoT）追踪：照亮推理过程

这是打破黑盒最核心的一环。AI Agent的“智能”很大程度上体现在其多步推理和规划能力上。监控必须能捕获并记录这个完整的“思维链”。

  • 捕获什么？ 不仅仅是LLM（大语言模型）的每一次输入和输出，更重要的是Agent在每一步的“决策上下文”。这包括：
    • 系统提示词（System Prompt） 的版本或哈希值，因为微小的提示词改动可能导致行为巨变。
    • 用户查询（User Query） 及历史对话上下文。
    • Agent的中间“想法” ：例如，在ReAct（Reasoning + Acting）框架中，Agent输出的“Thought: ”部分。这部分说明了它为什么决定下一步要做什么。
    • 工具调用的意图 ：在调用工具前，Agent对工具的选择和参数构造的逻辑。
  • 如何实现？ 通常通过在Agent的执行框架中注入“回调处理器”（Callback Handlers）来实现。无论是LangChain、LlamaIndex还是自定义框架，都提供了类似的钩子机制。我们需要编写自定义的Callback，在Agent产生“Thought”、决定调用“Tool”、收到“Tool”结果等关键节点，将结构化的数据发送到我们的监控存储中。
  • 存储与展示 ：这些数据是半结构化的日志，但为了更好的查询和分析，建议存储到Elasticsearch或专门的日志平台（如Loki）中。前端可以提供一个时间线视图，清晰地展示一次会话中Agent“思考-行动-观察”的完整循环。

注意：思维链数据可能包含敏感信息（如原始用户输入、工具返回的业务数据），在存储和传输时必须考虑脱敏和加密，并严格遵守数据隐私规定。

2.2 工具调用审计：掌控每一次外部交互

Agent的能力边界由其工具集决定。对工具调用的监控是保障稳定性、安全性和成本控制的关键。

  • 监控指标 ：
    1. 调用成功率与延迟 ：每个工具（如搜索引擎API、数据库查询、代码执行器）的调用成功率、平均响应时间、P95/P99延迟。这能快速发现第三方服务故障或网络问题。
    2. 输入/输出快照 ：记录每次调用的参数和返回结果。这对于调试工具参数错误和理解Agent行为至关重要。例如，Agent可能错误地将一个字符串ID传给了需要整数ID的API。
    3. 成本与配额 ：如果工具调用涉及计费（如调用某AI模型的API），需要累计消耗的Token数或调用次数，实时对比预算。
    4. 异常与重试 ：记录调用抛出的异常信息、自动重试的次数和结果。
  • 实现方式 ：通常有两种模式。一是在工具类的封装层进行统一埋点，所有工具调用都经过一个装饰器或基类，在那里完成监控数据的收集。二是在更底层的HTTP客户端或SDK处进行拦截。前者业务语义更清晰，后者更通用但上下文信息可能不足。
  • 安全审计 ：特别要注意那些具有“写”操作或高风险的工具（如发送邮件、执行Shell命令、操作数据库）。它们的每次调用都必须有完整的、不可篡改的审计日志，包括调用者（Session ID）、时间、参数和结果，便于事后追溯。

2.3 性能与资源度量：保障服务健康度

Agent本身作为一个服务，其运行时的健康指标必不可少。

  • 基础资源 ：CPU、内存占用率。尤其是当Agent集成了一些本地模型或重型计算库时，内存泄漏或CPU爆满可能导致服务崩溃。
  • 关键业务指标 ：
    • 会话耗时 ：从用户提问开始到最终答案返回的总时间。区分“总耗时”和“Agent纯思考耗时”（扣除用户网络延迟等）。
    • Token消耗与速率 ：记录每次LLM调用的Prompt Token和Completion Token数量，计算总体Token消耗速率和成本。这有助于优化提示词和设置流控。
    • 会话并发数 ：当前正在处理的活跃会话数，用于评估服务负载和扩容需求。
    • 错误率 ：会话级别的失败率（如最终未返回有效结果）。
  • 实现与集成 ：这些指标非常适合用Prometheus这样的监控系统来暴露。在Agent服务中集成Prometheus客户端库，定义并暴露上述自定义指标。然后由Prometheus抓取，并可在Grafana中绘制成直观的仪表盘。基础资源监控则通常由部署平台（如Kubernetes）或主机监控Agent（如Node Exporter）提供。

2.4 异常检测与告警：从被动到主动

监控的终极目的是为了快速发现问题。我们需要定义哪些情况属于“异常”，并建立告警通道。

  • 异常模式 ：
    1. 工具调用连续失败 ：例如，某个关键工具在5分钟内失败率超过80%。
    2. 会话超时 ：单个会话执行时间超过预设阈值（如5分钟），可能陷入了死循环。
    3. 资源异常 ：内存使用率持续超过90%，或Token消耗速率异常飙高。
    4. 逻辑异常 ：Agent在单次会话中循环调用同一工具超过N次，可能出现了规划错误。
    5. 输出质量异常（可选但高级） ：通过一个轻量级校验模型或规则，对Agent的最终输出进行内容安全或基本逻辑检查，失败则触发告警。
  • 告警渠道 ：根据团队习惯，集成到企业微信、钉钉、Slack或短信、电话。告警信息必须包含足够的上文，如Session ID、错误日志片段、相关的监控图表链接，以便接收者能快速判断严重性并开始排查。
  • 告警分级与降噪 ：避免“告警疲劳”。将告警分为“致命”、“严重”、“警告”等级别。对于短暂抖动可以设置“持续时间”条件，例如“连续2分钟失败率超限”才告警。同时，建立告警的聚合和抑制规则，防止同一根因问题引发告警风暴。

3. 技术栈选型与实战搭建

理论说完了，我们来点实在的。如何用一套可行的技术栈快速搭建起这个监控体系？下面是我在一个中型项目上验证过的方案。

3.1 后端监控数据管道

核心思路是：Agent服务产生日志和指标 -> 统一收集 -> 存储与索引 -> 可视化与分析。

  1. 日志收集（思维链 & 工具调用） ：

    • Agent框架 ：我们使用LangChain。它内置了完善的Callback机制。
    • 自定义Callback ：我们编写一个 MonitoringCallbackHandler ，继承自 BaseCallbackHandler 。在其 on_llm_start , on_llm_end , on_tool_start , on_tool_end , on_chain_start , on_chain_end 等方法中，将结构化的JSON日志打印到标准输出（stdout），或者更优的方案是直接发送到日志收集器。
    • 日志传输 ：服务部署在Kubernetes中。使用Fluentd或Fluent Bit作为DaemonSet收集每个Pod的stdout日志。这些日志被添加K8s元数据（Pod名、Namespace等）后，转发到下游。
    • 日志存储 ：选择 Grafana Loki 。相比Elasticsearch，Loki对日志的索引方式更经济，特别适合这种高吞吐量的应用日志。它使用标签（labels）进行索引（如 agent_name="sales_analyzer" , session_id="xyz" , level="info" ），日志内容本身不索引，查询时再解压扫描，在成本和性能间取得了很好平衡。Fluentd将日志推送到Loki的HTTP API。

  2. 指标收集（性能与资源） ：

    • 暴露指标 ：在Agent的FastAPI/Flask应用内，集成 prometheus_client 库。定义多个自定义的Counter、Gauge、Histogram指标，例如： 
      from prometheus_client import Counter, Histogram, Gauge
REQUEST_COUNT = Counter('agent_requests_total', 'Total requests')
REQUEST_DURATION = Histogram('agent_request_duration_seconds', 'Request duration')
ACTIVE_SESSIONS = Gauge('agent_sessions_active', 'Active sessions')
TOKENS_USED = Counter('agent_tokens_used_total', 'Total tokens used')
      在请求处理、LLM调用、工具调用等关键位置更新这些指标。
    • 抓取指标 ：在K8s中，通过Service的annotations声明Prometheus抓取。Prometheus Operator会自动发现并定期抓取这些/metrics端点。
    • 资源指标 ：由K8s的cAdvisor和Node Exporter提供，Prometheus同样会自动抓取。

  3. 存储与计算 ：

    • Prometheus ：作为时序数据库，存储所有指标数据。它强大的查询语言PromQL允许我们进行灵活的聚合和计算。
    • Loki ：存储所有日志数据。

3.2 前端可视化与告警配置

  1. 可视化 - Grafana ：

    • 连接数据源 ：在Grafana中配置Prometheus和Loki为数据源。
    • 创建仪表盘 ：
      • 概览页 ：放置核心健康指标：请求QPS、错误率、平均响应时间、活跃会话数、Token消耗速率。使用Stat、Graph等面板。
      • Agent思维详情页 ：使用Loki数据源。创建一个日志面板，查询特定时间段或特定Session ID的日志。利用Loki的“解析器”功能（如 json ）将日志中的字段（ thought , tool_name , duration ）提取为表格列，让日志更易读。甚至可以做一个类似“对话树”的可视化，直观展示Agent的推理路径。
      • 工具调用分析页 ：从Loki日志中，通过 tool_name 标签聚合，展示各工具的调用次数、平均耗时、失败率排行榜。从Prometheus中展示工具调用的延迟分布直方图。
      • 资源监控页 ：展示Pod的CPU、内存使用情况。

  2. 告警 - Grafana Alerting 或 Prometheus Alertmanager ：

    • 在Grafana中定义告警规则 ：例如，针对“工具调用失败率”创建一个查询： sum(rate(agent_tool_calls_failed_total{job="ai-agent-service"}[5m])) by (tool_name) / sum(rate(agent_tool_calls_total{job="ai-agent-service"}[5m])) by (tool_name) > 0.5 。意思是“按工具名分组，过去5分钟内失败率超过50%”。
    • 配置告警渠道 ：在Grafana的告警通道中，配置Webhook指向一个可以将消息转发到企业微信/钉钉的机器人服务，或者直接配置邮件。
    • 告警信息模板化 ：精心设计告警信息，包含：告警名称、触发值、相关标签（如 tool_name="google_search" ）、以及一个直接跳转到问题排查仪表盘的链接。

3.3 一个具体的代码示例：LangChain Callback

让我们看看 MonitoringCallbackHandler 的关键部分如何实现：

import json
import time
from typing import Any, Dict, List
from uuid import uuid4
from langchain.callbacks.base import BaseCallbackHandler
from langchain.schema import LLMResult, AgentAction, AgentFinish
import logging

# 配置一个结构化日志的logger
logger = logging.getLogger("agent_monitor")
logger.setLevel(logging.INFO)
# 假设使用JSONFormatter，方便Loki解析
formatter = logging.Formatter('{"time": "%(asctime)s", "level": "%(levelname)s", "message": %(message)s}')
handler = logging.StreamHandler()
handler.setFormatter(formatter)
logger.addHandler(handler)

class MonitoringCallbackHandler(BaseCallbackHandler):
    """自定义监控回调处理器，将关键事件以结构化日志形式输出"""
    
    def __init__(self, session_id: str = None):
        super().__init__()
        self.session_id = session_id or str(uuid4())
        self.chain_stack = []  # 用于追踪嵌套的chain调用
        
    def on_llm_start(self, serialized: Dict[str, Any], prompts: List[str], **kwargs: Any) -> None:
        """LLM开始调用时触发"""
        llm_event = {
            "event_type": "llm_start",
            "session_id": self.session_id,
            "llm_type": serialized.get("name", "unknown"),
            "prompts": prompts,
            "timestamp": time.time(),
        }
        # 安全考虑，可以对长prompt进行截断或哈希处理
        if len(prompts) > 0 and len(prompts[0]) > 500:
            llm_event["prompt_preview"] = prompts[0][:500] + "..."
        logger.info(json.dumps(llm_event))
    
    def on_llm_end(self, response: LLMResult, **kwargs: Any) -> None:
        """LLM调用结束时触发"""
        llm_event = {
            "event_type": "llm_end",
            "session_id": self.session_id,
            "generations": [[gen.text for gen in gen_list] for gen_list in response.generations],
            "token_usage": response.llm_output.get("token_usage", {}) if response.llm_output else {},
            "duration": kwargs.get("duration", None),
            "timestamp": time.time(),
        }
        logger.info(json.dumps(llm_event))
        # 更新Prometheus Token计数器
        if response.llm_output and 'token_usage' in response.llm_output:
            usage = response.llm_output['token_usage']
            TOKENS_USED.inc(usage.get('total_tokens', 0))
    
    def on_tool_start(self, serialized: Dict[str, Any], input_str: str, **kwargs: Any) -> None:
        """工具开始调用时触发"""
        tool_name = serialized.get("name", "unknown_tool")
        tool_event = {
            "event_type": "tool_start",
            "session_id": self.session_id,
            "tool_name": tool_name,
            "input": input_str, # 注意：可能需要脱敏
            "timestamp": time.time(),
        }
        logger.info(json.dumps(tool_event))
        # 开始计时，可以在on_tool_end中计算耗时
        self._current_tool_start = time.time()
        self._current_tool_name = tool_name
    
    def on_tool_end(self, output: str, **kwargs: Any) -> None:
        """工具调用结束时触发"""
        duration = time.time() - getattr(self, '_current_tool_start', time.time())
        tool_event = {
            "event_type": "tool_end",
            "session_id": self.session_id,
            "tool_name": getattr(self, '_current_tool_name', 'unknown'),
            "output": output, # 注意：可能需要截断或脱敏
            "duration": duration,
            "timestamp": time.time(),
        }
        logger.info(json.dumps(tool_event))
        # 更新Prometheus工具调用指标
        TOOL_CALL_DURATION.labels(tool_name=tool_event['tool_name']).observe(duration)
        TOOL_CALL_COUNT.labels(tool_name=tool_event['tool_name']).inc()
        
    def on_agent_action(self, action: AgentAction, **kwargs: Any) -> None:
        """Agent决定采取行动时触发（ReAct模式中的Thought后）"""
        agent_event = {
            "event_type": "agent_action",
            "session_id": self.session_id,
            "thought": action.log,  # 这是关键的“思考”内容
            "tool": action.tool,
            "tool_input": str(action.tool_input),
            "timestamp": time.time(),
        }
        logger.info(json.dumps(agent_event))
        
    def on_agent_finish(self, finish: AgentFinish, **kwargs: Any) -> None:
        """Agent完成所有行动，准备返回最终答案时触发"""
        agent_event = {
            "event_type": "agent_finish",
            "session_id": self.session_id,
            "output": finish.return_values.get('output', ''),
            "log": finish.log,
            "timestamp": time.time(),
        }
        logger.info(json.dumps(agent_event))
        # 标记会话结束，更新活跃会话数
        ACTIVE_SESSIONS.dec()

然后在初始化你的Agent时，将这个Callback传入：

from langchain.agents import initialize_agent, AgentType
from langchain.llms import OpenAI

llm = OpenAI(temperature=0)
tools = [...] # 你的工具列表

# 为每个会话创建一个独立的Callback实例
session_id = "user_query_123"
monitor_callback = MonitoringCallbackHandler(session_id=session_id)

agent = initialize_agent(
    tools,
    llm,
    agent=AgentType.ZERO_SHOT_REACT_DESCRIPTION,
    verbose=True, # verbose也会输出到控制台，但我们的Callback更结构化
    callbacks=[monitor_callback], # 关键：注入监控回调
    handle_parsing_errors=True
)

4. 部署与运维中的核心考量

监控系统搭建好后，要让它稳定、高效地运行，并在关键时刻真正发挥作用，还需要在部署和运维层面做好以下几件事。

4.1 数据量与性能的平衡

AI Agent的日志数据量可能非常庞大，尤其是思维链日志，每次LLM交互都可能产生数百甚至数千Token的文本。

  • 采样策略 ：全量记录所有会话的完整日志可能成本过高。可以考虑动态采样。例如，对于所有会话，只记录元数据（会话ID、起止时间、状态、基础指标）。对于出错的会话、耗时超长的会话，或者按一定比例（如10%）随机采样的正常会话，记录其完整的思维链和工具调用详情。这能在控制成本的同时，保留足够的调试信息。
  • 日志分级与保留策略 ：将日志分为不同级别。 INFO 级别记录关键事件（工具调用开始结束、Agent行动）； DEBUG 级别记录完整的LLM输入输出。为不同级别的日志设置不同的保留时间（如DEBUG保留1天，INFO保留7天）。在Loki中可以通过配置不同的存储卷来实现。
  • 异步与非阻塞写入 ：监控数据的收集和上报绝对不能阻塞Agent的主业务逻辑。Callback中的日志记录和指标更新操作必须是异步的或极其轻量的。例如，可以将日志事件放入一个内存队列，由后台线程批量发送到日志收集器。Prometheus客户端的指标操作是内存操作，开销极小。

4.2 监控系统的自监控与高可用

监控系统本身不能成为单点故障。

  • 监控组件的健康度 ：你需要监控Prometheus、Loki、Grafana这些组件本身的状态。可以利用它们自身暴露的/metrics端点，或者通过K8s的存活探针和就绪探针来保障。
  • 数据链路监控 ：确保Fluentd/Loki的日志摄入链路是通畅的。可以设置一个“心跳”日志源，定期向stdout打印一条特定格式的日志，然后在Grafana中监控这条日志是否持续出现，延迟是否正常。
  • 存储容量规划 ：预估每日的日志量和指标数据量，为Prometheus和Loki的持久化存储预留足够的空间，并设置自动清理旧数据的策略。

4.3 安全与隐私红线

这是重中之重，一旦出问题就是大问题。

  • 数据脱敏 ：在Callback中或日志发出前，必须对敏感信息进行脱敏。例如，用户查询中的手机号、邮箱、身份证号，工具调用返回的银行卡号、地址等。可以使用正则匹配或专门的脱敏库进行处理，替换为 <PHONE> 、 <EMAIL> 等标记。
  • 访问控制 ：Grafana仪表盘、Loki日志查询界面必须设置严格的权限控制。只有授权的运维和开发人员才能访问原始日志，尤其是包含用户数据的DEBUG级别日志。最好能区分角色：客服人员只能看到会话状态和最终结果，开发人员可以看到脱敏后的思维链，只有安全管理员才能查看原始数据。
  • 合规性 ：如果业务涉及欧盟用户，需考虑GDPR；涉及中国用户，需考虑个人信息保护法。监控数据的收集、存储、处理必须符合相关法律法规，明确告知用户并获得必要同意，并建立数据删除机制。

5. 典型问题排查与效能提升实战

有了监控，排查问题的思路就完全不同了。下面分享几个真实场景下的排查案例和基于监控数据的优化方向。

5.1 问题排查：Agent“装死”无响应

现象 ：用户反馈某个查询长时间无返回，前端超时。

传统排查 ：登录服务器，在一堆杂乱的日志文件里 grep Session ID，看错误信息，耗时耗力。

监控化排查 ：

  1. 定位会话 ：在Grafana的“活跃会话”面板，发现该 session_id 的会话持续时间异常长（例如超过300秒）。
  2. 查看思维链 ：在Loki日志查询界面，输入查询 {session_id="problem_session_123"} | json 。按时间排序查看日志流。
  3. 分析过程 ：发现日志在 on_tool_start 事件后停止了，下一个事件迟迟没有出现。该工具是“调用某内部数据API”。
  4. 检查工具监控 ：切换到“工具调用分析”仪表盘，发现该内部数据API的调用平均延迟从正常的200ms飙升到了30秒，且失败率增高。
  5. 根因定位 ：问题不在Agent逻辑，而在下游依赖的服务。立即联系该API的负责团队，同时为Agent配置该工具调用的超时时间和熔断机制，避免单个慢请求拖死整个Agent。

5.2 问题排查：Agent回答质量突然下降

现象 ：用户反馈Agent最近给出的建议变得笼统或不准确。

传统排查 ：对比代码版本，检查提示词是否被修改，很难定量分析。

监控化排查 ：

  1. 时间对比 ：在Grafana中，对比问题时间段和正常时间段的“平均会话Token消耗”图表。发现近期Token消耗显著下降。
  2. 假设验证 ：Token消耗下降可能意味着LLM生成的答案变短了。检查思维链日志，发现近期LLM的响应中 finish_reason 为 "length" （达到长度限制）的比例升高。
  3. 深入分析 ：查看具体会话的完整思维链。发现Agent在尝试进行多步推理时，经常在第一步或第二步就因为达到Token上限而被模型截断输出，导致推理链不完整，最终答案自然质量低下。
  4. 解决方案 ：调整模型的 max_tokens 参数，或者优化提示词，让Agent的“思考”更简洁，把“篇幅”留给最终答案。同时，监控“因长度限制截断”的比例作为一个关键质量指标。

5.3 效能提升：优化成本与响应速度

监控数据不仅是用来救火的，更是用来优化和创新的。

  • 成本优化 ：

    • 识别耗Token大户 ：通过Prometheus的 agent_tokens_used_total 指标，按会话类型或用户标签进行分组统计。你可能会发现，处理某类复杂分析任务的会话消耗了80%的Token成本。
    • 优化提示词 ：针对高消耗任务，分析其思维链日志。是否每次都需要长篇大论的背景介绍？能否设计更高效的提示词，用更少的Token引导模型产出相同质量的答案？A/B测试不同提示词版本下的Token消耗和结果质量。
    • 模型选型 ：对于简单的分类、提取任务，是否可以用更便宜、更快的模型（如gpt-3.5-turbo）替代昂贵的模型（如gpt-4）？监控不同模型在相同任务上的效果（需结合人工评估或简单自动化评估）和成本，做出数据驱动的决策。

  • 速度优化 ：

    • 定位性能瓶颈 ：利用Prometheus的Histogram指标 agent_request_duration_seconds ，可以绘制延迟的分布（50%, 95%, 99%分位数）。如果P99延迟很高，说明存在一些极端慢的请求。
    • 分解耗时 ：在思维链日志中，每个 on_tool_end 事件都记录了 duration 。在仪表盘中排序，立刻就能找出最慢的工具。优化这些工具的性能（如增加缓存、优化查询、升级下游服务），能显著提升整体体验。
    • 并行化优化 ：观察思维链，如果Agent总是顺序调用多个 独立 的工具（例如，同时查询天气和新闻），可以考虑修改Agent的规划逻辑，或者使用支持并行工具调用的框架特性，来减少总等待时间。

5.4 一个避坑指南：监控本身的“坑”

  1. 日志量爆炸 ：初期没有设置采样和日志级别，DEBUG日志全开，导致Loki存储一天就被塞满，且查询变得极其缓慢。 教训 ：上线前必须估算日志量，设计好采样和分级策略。
  2. Callback性能影响 ：最初的Callback同步调用一个远程HTTP接口发送日志，在网络抖动时严重拖慢了Agent响应速度。 教训 ：监控逻辑必须异步化、非阻塞，采用本地缓冲队列+批量发送的机制。
  3. 指标定义混乱 ：初期定义了太多细粒度的指标（如每个工具每个错误码的计数），导致Prometheus序列数暴涨，查询变慢。 教训 ：遵循USE（Utilization, Saturation, Errors）或RED（Rate, Errors, Duration）原则，先定义核心业务和资源指标，按需增加细分维度。
  4. 脱敏遗漏 ：曾有一次将包含测试用户真实手机号的日志暴露在了开发环境的Grafana中，虽然很快删除，但仍是安全隐患。 教训 ：将脱敏作为强制代码审查项，并定期进行安全审计，扫描日志中是否包含敏感信息模式。
Logo
亚马逊云科技技术品牌专区

更多推荐

cover

实践深度学习：构建一个简单的图像分类器

avatar 亚马逊云科技技术品牌专区
cover

大 硬 仗14小时：用2009年的上古亮机卡跑完深度学习，CPU满载但代码没崩

avatar 亚马逊云科技技术品牌专区
cover

害虫检测和识别3：基于深度学习YOLO26神经网络实现害虫检测和识别(含训练代码、数据集和GUI交互界面）

avatar 亚马逊云科技技术品牌专区