测试视角做AI Agent可观测：权限、日志、证据全补齐

关注

原创最新推荐文章于 2026-11-11 23:38:25 发布 455 阅读 AI 写同款· GEO 优化 ›

AI安全与Agent治理：从超级智能监管到工程落地随着AI系统自主性不断提升，从大模型到AI Agent，安全风险从内容生成失控延伸到工具调用越权、数据泄露与自动化决策连环错误。理解能力分级是构建防护的前提：自主性越高，越需要权限边界与人工熔断机制。工程化团队应建立覆盖安全评估、红队测试、日志审计和事故复现的全链路体系，将监管要求转化为可执行的技术动作。尤其在模型本地部署与RAG应用场景中，输出过滤、访问控制和最小化权限成为必要护栏。从工程视角拆解AI安全测试方法与Agent治理最佳实践，帮助开发者从容应对合规挑战。阅读详情

聊《做过测试的人学大模型，哪些经验可以直接迁移？》之前，先说一句实在的：别急着背概念，先看它在真实项目里到底解决什么问题。

摘要

真实案例：我带的一个AI测试项目

文章插图 1

去年我接手了一个电商Agent的项目，做的是智能客服问答。系统用RAG架构，接入公司内部的订单数据库和产品知识库。产品侧要求的是"用户问什么答什么"，但作为测试，我拿到需求后第一时间不是想怎么测通过率，而是先问了一句话："它的权限边界在哪里？"

这个项目当时踩过的坑，我觉得很有代表性，也直接对应了我后来写进简历里的几个核心模块。

先说整体背景：这是一个基于LangChain的Agent，底层用的是OpenAI的API，知识库是通过Milvus向量数据库管理的。测试目标包括：功能正确性、权限合规性、可观测性、稳定性。其中前两个，传统测试同学容易上手；后两个，才是这次转型真正拉开差距的地方。

我做的第一件事，是搭了一个简化的本地测试环境——用一个开源模型加一个小型向量库，模拟真实RAG Agent的核心链路：用户输入 → 意图路由 → 工具调用 → 结果生成。这个环境的好处是，可以在权限配置上灵活调整，便于做各种边界测试。

权限：被很多人忽略的"第一道墙"

文章插图 2

面试过程中我发现一个问题：很多候选人做的项目，能跑通Demo就算完事，但真到企业级应用，权限往往是最先暴露问题的地方。

我的项目中，有一个很典型的case：知识库的某些数据是有访问权限控制的——比如订单金额、用户联系方式这类敏感字段，只有特定角色才能查询。但Agent在做检索时，没有做权限过滤，直接把所有数据都返回给了用户。

这属于典型的"数据平权"问题。解决思路是把权限检查放在检索层之前，而不是靠后期的人工审核。具体来说，就是让Agent在执行查询前，先获取当前用户的角色权限信息，然后根据权限白名单过滤知识库的返回结果。

代码层面，我是在ChatOpenAI之前加了一个中间件，专门做权限校验：

from typing import List, Dict

class PermissionFilter:
    def __init__(self, user_role: str):
        self.user_role = user_role
        self.access_levels = self._load_access_config()

    def _load_access_config(self) -> Dict:
        # 从配置文件加载角色权限表
        return {
            "customer_service": ["public_info"],
            "order_manager": ["order_info", "public_info"],
            "admin": ["all"]
        }

    def filter_documents(
        self,
        docs: List[Dict],
        user_role: str
    ) -> List[Dict]:
        allowed = self.access_levels.get(user_role, ["public_info"])
        if "all" in allowed:
            return docs

        filtered = []
        for doc in docs:
            if doc.get("access_level") in allowed:
                filtered.append(doc)
        return filtered

# 使用示例
filter = PermissionFilter(user_role="customer_service")
filtered_docs = filter.filter_documents(raw_docs, "customer_service")

这个代码的核心逻辑是先过滤再给模型，而不是让模型自行判断。输出是所有文档中符合当前角色权限的部分，异常处理方面，如果用户角色不在配置表里，默认只返回public_info级别的数据。

我在这个模块上花的时间不少，主要是调试不同角色的权限交叉访问问题。有一次发现某个manager角色的权限配置少了一个level，导致订单查询返回了空结果，排查了很久才发现是配置表的key拼错了。

日志与可观测：Agent决策链追踪

这是测试转AI最核心需要补的一个能力。传统测试只需要看接口返回对不对，但Agent的决策过程是多步的，每一步都可能出问题。

我做了一个工具调用链的日志追踪方案，核心思路是：每次工具调用都要记录输入参数、输出结果、耗时，并关联到同一个request_id。这样排查问题时，可以从最终回答反推整个决策过程。

排查过程是这样的：有一次发现Agent对同一个问题，有时候回答准确，有时候回答错误。通过日志追踪发现，问题出在tool选择上——模型在某些情况下选择了错误的工具，而且错误选择后没有重试机制。这个case让我深刻体会到，Agent的"随机性"在测试阶段就必须被充分覆盖。

具体实现上，我用了一个自定义的Callback类，继承LangChain的BaseCallbackHandler：

import time
import logging
from langchain.callbacks.base import BaseCallbackHandler
from typing import Any, Dict, List

logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)

class TraceCallback(BaseCallbackHandler):
    def __init__(self, request_id: str):
        self.request_id = request_id
        self.tool_calls = []

    def on_tool_start(
        self,
        serialized: Dict,
        input_str: str,
        **kwargs
    ) -> Any:
        tool_name = serialized.get("name", "unknown")
        self.tool_calls.append({
            "tool": tool_name,
            "input": input_str,
            "start_time": time.time(),
            "request_id": self.request_id
        })
        logger.info(
            f"[{self.request_id}] Tool start: {tool_name}, "
            f"input: {input_str[:100]}"
        )

    def on_tool_end(self, output: str, **kwargs) -> None:
        last_call = self.tool_calls[-1]
        last_call["output"] = output
        last_call["end_time"] = time.time()
        last_call["duration"] = (
            last_call["end_time"] - last_call["start_time"]
        )
        logger.info(
            f"[{self.request_id}] Tool end: {last_call['tool']}, "
            f"duration: {last_call['duration']:.2f}s"
        )

    def on_llm_end(self, response: Any, **kwargs) -> None:
        logger.info(
            f"[{self.request_id}] LLM response received"
        )

代码解释：输入是requestid，用于关联同一次请求的所有日志；核心逻辑是在工具调用开始和结束时记录时间戳和参数；输出是结构化的日志信息，方便后续查询和回溯；异常处理方面，如果工具调用失败，会在ontool_end里记录错误信息。

优快云资料领取方式

失败原因：三类错误的区分方式

在做这个项目期间，我遇到很多看似奇怪的问题，后来总结成三类：业务错误、配置错误、环境错误。

业务错误是最难定位的。比如模型返回了错误的工具名，这不是代码bug，而是prompt设计的问题。有一次我在prompt里写"根据用户问题选择合适的工具"，结果模型在某些边界case下会误判。排查思路是：先把模型输出的raw response打印出来，看它到底看到了什么、想了什么，再针对性地调整prompt。

配置错误相对好排查。有一次向量库的embedding模型和检索用的模型不一致，导致检索效果很差。排查动作是对比两边的配置项，发现embedding模型版本号不一致，统一后问题解决。这类错误的特征是：配置项之间有不一致，通过diff配置表可以快速定位。

环境错误一般出现在部署阶段。比如某个依赖包的版本在本地能跑但在服务器上不行。这类问题的排查思路是：先在开发环境复现，再看线上环境的docker镜像和依赖配置，找出差异点。

区分这三类错误的方法很简单：业务错误改prompt，配置错误改配置，环境错误改部署。但真正难的是在问题发生时，快速判断它属于哪一类。我后来的习惯是，遇到问题先问自己：是模型"想错了"，还是配置"设错了"，还是环境"装错了"。