AI Agent 实战：从 Hermes 部署到测试团队智能化升级

AI Agent 实战：从 Hermes 部署到测试团队智能化升级

作者：浅木·先生

日期：2026-06-16

字数：约 4500 字

---

一、背景：当我们谈论 Agent 测试时，我们在谈论什么

2025 年下半年以来，AI Agent 从概念爆发进入了落地深水区。GitHub 上 Agent 类项目星数激增，各家云厂商争先推出 MCP Server 市场，大模型厂商一边卷模型能力一边卷 Agent 框架。但在我们财政行业的测试团队眼中，这些热闹背后有一个共同的问题：Agent 到底能不能真正帮我们把测试效率提上去？

我所在的团队负责一套省级财政预算管理一体化系统的质量保障。这套系统的特点可以概括为三个"极其"：

• 业务链路极其长：一笔专项资金从预算编制、指标下达、用款计划、支付申请、国库集中支付到最终对账，涉及 6 个核心子系统、30+ 个微服务
• 合规要求极其严：等保 2.0 三级、财政核心数据密评、国密算法改造------每一条都是"一票否决"
• 回归工作量极大：每月两次版本迭代，全量回归用例超过 6000 条，手工执行需要 3 个测试员全职投入两周

更让人头疼的是，财政系统的测试用例往往不是简单的"输入-预期输出"二元关系，而是涉及到跨会话状态流转、多系统时序协作、权限级联变化。传统的 UI 自动化脚本在财政系统面前显得特别脆弱------哪怕只是页面上一个字段标签的微调，都可能导致整条脚本断裂。

也是在这个时候，我开始认真研究 AI Agent。尤其是 Hermes Agent 这个项目，它不只是一个"AI 助手"，更是一套围绕跨会话记忆、自动沉淀 Skills、多 Agent 隔离构建的智能体框架。在我看来，这套思想恰好击中了财政系统测试的三大痛点：上下文断裂、经验难沉淀、多角色协作混乱。

这篇文章就围绕我在 Hermes 部署、Skills 构建、以及财政测试场景落地的全过程，讲讲我们踩过的坑和沉淀下来的经验。

---

二、核心概念：Hermes、Skill 与 MCP 的三层架构

在讲实战之前，需要先厘清几个关键概念。我不打算写教科书式的定义，而是结合我们在测试场景中遇到的具体问题来说。

2.1 Hermes Agent：跨会话记忆才是真正的"记忆"

先抛一个真实场景：我们有一个支付链路场景测试，需要依次执行"登录→预算编制→指标下达→用款申请→支付申请→发送国库→对账反馈"七个步骤。传统的自动化做不到------因为每一步都是独立的测试用例，上一个用例的返回值（比如指标文号）需要手工传递给下一个。

Hermes 解决这个问题的核心机制是跨会话记忆。

简单来说，Hermes 会记录你在每一次对话中产出的关键信息，并在后续会话中自动检索相关记忆来辅助决策。部署 Hermes 的配置文件（~/.hermes/config.yaml）中，记忆引擎的配置如下：

# ~/.hermes/config.yaml (关键部分)
memory:
  enabled: true
  provider: chromadb
  chromadb:
    path: ~/.hermes/memory
    collection: test_sessions
  retrieval:
    top_k: 10
    similarity_threshold: 0.75

这个配置的含义是：每次对话结束后，Hermes 会自动向量化对话内容并存入 ChromaDB 集合 test_sessions，后续对话启动时，系统会自动检索最相关的 10 条记忆片段。做支付链路测试时，第一步生成的"预算指标文号：2026-预-00812"会被自动索引，第二步启动时直接通过记忆检索获取，不需要人工传递。

我们针对这个功能做了一个实验：让 Hermes Agent 连续执行 7 步支付链路测试，中间不断开会话，记录它依赖记忆自动传递参数的准确率。跑了 50 轮后，结果如下：

指标	数值
参数自动传递成功率	92%
需要人工纠正次数（50轮中）	4 次
平均每轮执行时间（含等待）	3.2 分钟
传统手工执行时间	15 分钟

92% 的自动传递成功率，对于财政系统这种高精度要求的场景来说已经非常可用。那 4 次失败全部发生在预算指标文号的格式变化场景------当系统升级改变了编号规则时，Hermes 会匹配到旧规则的记忆片段，导致传递了过时的格式。这个问题的解决方案是给记忆加上"有效时间戳"标签，后面我会在"踩坑"部分展开。

2.2 Skills：测试经验的可执行封装

如果说记忆是 Agent 的"长期大脑"，那 Skills 就是 Agent 的"肌肉记忆"。

Hermes 的 Skills 系统跟我们之前熟悉的自动化脚本有个本质区别。一个 Skill 不是写死的代码，而是一套可执行的模板化流程，包含三个部分：

Skill = 触发条件 + 执行步骤 + 验证断言

Skills 的存储路径是 ~/.hermes/skills/，每个 Skill 是一个 Markdown 文件，上半部分是自然语言描述（什么场景下触发、输入输出是什么），下半部分是可执行的命令或 API 调用。

我在实践中为支付链路测试编写了第一个 Skill，名为 pay_chain_test.md，内容大致如下：

---
name: pay_chain_test
description: 执行财政支付全链路测试
trigger:
  pattern: "执行支付链路测试"
  context:
    app_version: "required"
    env: ["dev", "staging"]
steps:
  - id: step1_budget_prepare
    name: 预算编制
    command: test_budget_prepare.sh ${app_version}
    timeout: 120
    memory_keys: [budget_doc_id]
  - id: step2_quota_assign
    name: 指标下达
    command: test_quota_assign.sh ${budget_doc_id}
    timeout: 60
    memory_keys: [quota_no]
  - id: step3_pay_apply
    name: 支付申请
    command: test_pay_apply.sh ${quota_no}
    timeout: 60
    memory_keys: [pay_apply_id]
  - id: step4_national_treasury
    name: 发送国库
    command: test_treasury_send.sh ${pay_apply_id}
    timeout: 120
    memory_keys: [treasury_ret_code]
  - id: step5_reconciliation
    name: 对账验证
    command: test_reconciliation.sh ${treasury_ret_code}
    timeout: 60
assertions:
  - "所有步骤返回码均为 0"
  - "财政对账状态为 '一致'"

这个 Skill 的精髓在于：它同时是一个文档（给测试员看流程）和一个可执行脚本（给 Agent 执行）。新人来了不需要翻几十页的测试文档，只需要说一句"执行支付链路测试"，Agent 就会按 Skill 的步骤依次执行，自动传递上下文参数。

2.3 MCP：Agent 的工具箱，而不是 Agent 本身

在跟同行交流时，我发现一个普遍的混淆点：很多人把 MCP（Model Context Protocol）和 Agent 当成一回事。实际上两者是不同层级的抽象。

我用一个比喻来说明：Skills 是菜谱，MCP 是厨具。

• MCP 提供的是标准化的工具接口------文件读写、API 调用、数据库查询、浏览器操作
• Skills 是基于这些工具编排出的业务流程------先切菜（工具），再热油（工具），再下锅翻炒（工具）

在 Hermes 配置中，MCP Server 的配置通过 mcp_servers 字段声明：

# ~/.hermes/config.yaml
mcp_servers:
  - name: file_system
    transport: stdio
    command: npx
    args: ["@modelcontextprotocol/server-filesystem", "D:\\test_data"]
  - name: test_db
    transport: stdio
    command: python
    args: ["mcp_servers/test_db_server.py"]
  - name: browser_automation
    transport: stdio
    command: python
    args: ["mcp_servers/browser_server.py"]

每个 MCP Server 暴露一组资源（Resources）和工具（Tools）。Agent 在执行 Skills 时，会自动选择最合适的 MCP 工具来完成当前步骤。

比如上一步的支付测试中，step2_quota_assign 需要查询指标余额，Agent 就会调用 test_db MCP Server 的 query_execute 工具去数据库查余额。如果余额不足，Agent 不需要额外的逻辑代码------它直接基于自然语言理解判断"余额不足，跳过后续步骤并报告"，这就是 Skills + MCP 组合带来的灵活性。

2.4 三层架构总结

用一张简图来总结关系：

┌─────────────────────────────────┐
│          Agent 实例              │  ← 调度者，有记忆、能做决策
│  ┌───────────────────────┐      │
│  │    Skills 库           │      │  ← 流程模板，可复用、可进化
│  │  - 支付链路测试        │      │
│  │  - 等保合规扫描        │      │
│  │  - 回归报告生成        │      │
│  └──────────┬────────────┘      │
│             ▼                   │
│  ┌───────────────────────┐      │
│  │    MCP 工具层          │      │  ← 标准化工具接口
│  │  文件系统 | 数据库 | 浏览器 │      │
│  └───────────────────────┘      │
└─────────────────────────────────┘
         │
         ▼
┌─────────────────────────────────┐
│          大模型                  │  ← 推理引擎
│  (DeepSeek / GPT / Claude ...)  │
└─────────────────────────────────┘

这个架构最大的好处是解耦：换大模型不换 Skills，加新工具不换 Agent，改测试流程改 Skills 就行。对于财政系统这种合规要求严格、变更管控频繁的场景，这种解耦至关重要------因为任何一个组件的变更都需要走审批流程，拆得越开，变更影响面越小。

---

三、实战步骤：从零搭建测试 Agent 平台

3.1 环境准备与 Hermes 部署

我们的部署环境是 Windows Server 2022（财政系统测试服务器，等保合规要求不能上云），加上一台开发用 Windows 10 工作站。Python 版本 3.11+，推荐用 uv 管理包：

# 安装 uv（比 pip 快 10-20 倍）
powershell -c "iwr -useb https://astral.sh/uv/install.ps1 | iex"

# 验证安装
uv --version

# 安装 Hermes Agent
uv pip install hermes-agent
# 验证
hermes --version

首次运行会生成配置文件目录 ~/.hermes/，核心结构如下：

~/.hermes/
├── config.yaml         # 主配置
├── profiles/          # 多 Profile 隔离
│   ├── default/       # 默认 Profile
│   ├── tester_1/      # 测试员 A 的 Profile
│   └── tester_2/      # 测试员 B 的 Profile
├── skills/            # Skills 存储
├── memory/            # ChromaDB 向量存储
└── logs/              # 操作日志

踩坑提醒 1 ：Windows 上的 ~ 在 MSYS2/bash 下解析为 /c/Users/<username>/，在 PowerShell 下解析为 C:\Users\<username>\。建议在所有配置文件和脚本中统一使用 ${HOME} 而不是 ~。

3.2 多 Profile 隔离：测试团队不"打架"

财政系统的测试有一个特点：不同角色关注的视角完全不同。负责预算编制的测试员关心预算逻辑校验，负责支付链路的测试员关心跨系统接口，负责安全的测试员关心等保合规检查。如果所有人共享同一个 Agent Profile，记忆和 Skills 会混在一起，导致严重干扰。

Hermes 的 Profile 机制完美解决了这个问题。每个 Profile 有独立的 Skills、记忆和插件：

# ~/.hermes/config.yaml
profile: tester_budget  # 默认加载预算测试 Profile

我们为团队创建了三个专用 Profile：

# 创建预算测试 Profile
hermes profile create tester_budget
# 创建支付链路测试 Profile  
hermes profile create tester_payment
# 创建安全合规测试 Profile
hermes profile create tester_security

每个 Profile 下的 skills/ 目录相互独立。预算测试员只装跟预算校验相关的 Skills，支付测试员只装支付链路 Skills，互不干扰。

但有一个例外的共享 Skills------我们把"环境健康检查""测试数据准备""报告生成"这类通用 Skills 放到一个单独路径，通过软链接映射到每个 Profile：

# Windows 下创建目录链接
mklink /J "%HOME%\\.hermes\\profiles\\tester_budget\\skills\\_shared" "D:\\hermes_shared_skills"
mklink /J "%HOME%\\.hermes\\profiles\\tester_payment\\skills\\_shared" "D:\\hermes_shared_skills"
mklink /J "%HOME%\\.hermes\\profiles\\tester_security\\skills\\_shared" "D:\\hermes_shared_skills"

这样通用 Skills 一次编写、全局生效，专用 Skills 各自维护。

3.3 Skills-RAG：构建财政测试知识库

Skills 是流程，但测试员日常工作中更多的时候是在查知识------"这个报错码是什么意思""这笔业务的加密算法是什么""接口返回 -2201 怎么处理"。

我们做了两件事让知识变得可被 Agent 查询：

第一件事：把历史用例转化为 Skills 格式的文档

我们整理了过去两年的 200+ 个测试用例，按标准格式写成可查询的文档：

---
name: 预算指标超限额校验
domain: 预算编制
tags: [预算, 指标, 限额校验]
---
## 场景描述
当某单位的预算指标申请额超过该单位的年度预算限额时，系统应拦截并返回明确提示。

## 预期行为
1. 系统拒绝指标申请
2. 返回提示信息："单位年度预算限额不足，当前余额：X，申请金额：Y"
3. 在审批流中记录"预算超限"标签

## 常见报错码
| 报错码 | 含义 | 处理方式 |
|--------|------|----------|
| BGT-1001 | 预算限额不存在 | 检查是否已编制年度预算 |
| BGT-1002 | 预算余额不足 | 查看明细确认扣减逻辑 |
| BGT-1003 | 预算跨期不可用 | 确认是否跨年度操作 |

第二件事：配置 Skills-RAG 检索

在 Hermes 配置中启用 Skills-RAG：

# ~/.hermes/config.yaml
skills_rag:
  enabled: true
  provider: chromadb
  collection: test_knowledge
  embedding_model: BAAI/bge-small-zh-v1.5  # 中文效果好
  chunk_size: 512
  chunk_overlap: 64

配置完成后，Agent 遇到知识类问题时，会自动先查 RAG 再回答。

实战效果：我们引入了一个新同事，之前没有任何财政系统背景。他在 Hermes 里问"预算超限怎么处理"，Agent 直接返回了三条信息：

1. 超限审批流的操作步骤
2. 需要修改的限额字段在哪个菜单下
3. 常见报错码和处理方式

这个新人只用了一天就上手了基本的预算测试，而在过去这个过程至少需要两周。

3.4 MCP 服务器开发：给 Agent 接上系统

纯靠提示词是没法操作系统的。要让 Agent 真正执行测试，它需要能读写测试数据、操作浏览器、调用接口。这些都是 MCP Server 干的活。

我们为财政测试环境开发了三个 MCP Server：

测试数据库 MCP Server（简化版）：

# mcp_servers/test_db_server.py
from mcp.server import Server
import sqlite3

server = Server("test_db")

@server.tool("query_budget_balance")
async def query_budget_balance(unit_code: str, year: int) -> str:
    """查询单位年度预算余额"""
    conn = sqlite3.connect("D:\\test_data\\budget.db")
    cursor = conn.cursor()
    cursor.execute(
        "SELECT total, used, remaining FROM budget_summary WHERE unit_code=? AND year=?",
        (unit_code, year)
    )
    row = cursor.fetchone()
    if row:
        return f"单位 {unit_code} {year}年预算：总额 {row[0]}，已用 {row[1]}，余额 {row[2]}"
    return f"未找到单位 {unit_code} 的 {year}年预算数据"

@server.tool("query_treasury_status")
async def query_treasury_status(pay_apply_id: str) -> str:
    """查询支付申请的国库处理状态"""
    conn = sqlite3.connect("D:\\test_data\\treasury.db")
    cursor = conn.cursor()
    cursor.execute(
        "SELECT status, process_time, ret_code FROM treasury_log WHERE pay_apply_id=?",
        (pay_apply_id,)
    )
    row = cursor.fetchone()
    if row:
        return f"支付申请 {pay_apply_id} 国库状态：{row[0]}，处理时间：{row[1]}，返回码：{row[2]}"
    return f"未查询到支付申请 {pay_apply_id} 的国库记录"

浏览器自动化 MCP Server：基于 Playwright 封装，用于操作财政系统的前端页面。财政系统的前端用的是定制化的 Web 组件，不是标准的 select/input，所以需要特殊处理------这直接导致了我们后来踩的一个大坑。

文件系统 MCP Server ：直接用官方提供的 @modelcontextprotocol/server-filesystem，挂载测试报告目录和日志目录。

3.5 自进化 Skills：从 8 阶段循环到持续优化

Hermes 一个让我很受启发的特性是 自进化 Skills。它有 8 个阶段的 Loop 机制：

识别 → 执行 → 观察 → 评估 → 反思 → 修正 → 沉淀 → 上线
       ↑_____________________________|

简单说就是：Agent 执行 Skill → 观察执行结果 → 评估是否符合预期 → 反思失败原因 → 修正 Skill 模板 → 沉淀为新版本 → 上线替换旧版本。

我们在"等保合规扫描"这个 Skill 上验证了这个机制。最初我们写了一个很基础的扫描 Skill，只检查系统版本、端口开放等几个指标。跑了几轮后 Agent 发现：每次扫描到同一个 Web 服务器版本号偏低时，都会触发"版本不满足等保要求"的结果，但人工复核发现这个版本号只是因为补丁更新后配置文件没改导致的虚警。

Agent 自动在反思阶段做出了调整：在执行"检查版本"步骤后，增加一个"验证版本"步骤------先查配置文件版本，再查运行实例版本，对比不一致时取运行实例版本作为最终判断。

这个修正过程是 Agent 自动完成的，我们只是观察到了 Skill 文件的自动更新。

# skills/compliance_scan.md 的自动变更
  steps:
    - id: check_version
      name: 检查系统版本
      command: check_version.sh
+   - id: verify_version
+     name: 验证实际版本（防止配置文件延迟更新）
+     command: verify_runtime_version.sh
    - id: port_scan

看到这个自动修正时，我心里其实是有点复杂的------既兴奋于 Agent 懂得从错误中学习，又有点警惕：如果 Agent 学偏了怎么办？这就引出了下一个部分：踩坑。

---

四、踩坑经验：五件实实在在的教训

没有任何平台是开箱即用的。以下五个坑，是我们真金白银砸出来的。

坑一：Windows 路径的"三重转义"问题

Hermes 的配置文件和 Skills 中的路径表示在不同场景下存在三种不同的转义规则：

1. YAML 解析层 ：\ 需要写成 \\
2. Shell 执行层 ：MSYS2 bash 会把 C:\Users 解析成 C:Users（反斜杠被吞了）
3. Python 参数层：传给 subprocess 的路径需要是原生字符串

我们一条配置文件里的数据库路径，踩了三层坑才调对。最终方案：所有路径统一用 MSYS2 风格 /c/Users/.../ ，并在 MCP Server 的 Python 代码里用 pathlib.Path 做一次转换：

from pathlib import PureWindowsPath, PurePosixPath
import os

def normalize_path(p: str) -> str:
    """将 MSYS2 路径统一转为 Windows 原生路径"""
    if p.startswith("/"):
        return str(PurePosixPath(p))
    return p

坑二：浏览器自动化在财政系统上的"水土不服"

财政系统的前端大量使用了定制的 Web 组件，比如树形菜单、加密输入框、分页表格。标准的 Playwright page.fill() 在加密输入框上完全失效------因为这个输入框并不是真的 <input> 标签，而是一个监听键盘事件的自定义 DIV。

解决方案是绕过 UI 层，直接通过接口操作：

@server.tool("operate_encrypted_field")
async def operate_encrypted_field(page_id: str, field_name: str, value: str) -> str:
    """通过注入 JavaScript 操作加密输入框"""
    js = f"""
    (() => {{
        // 找到加密输入框的 Vue 组件实例
        const el = document.querySelector('[data-field="{field_name}"]');
        if (!el) return 'ERROR: field not found';
        const vueInstance = el.__vueParentComponent?.exposed;
        if (!vueInstance) return 'ERROR: vue instance not found';
        vueInstance.setValue('{value}');
        return 'OK';
    }})()
    """
    result = await page.evaluate(js)
    return result

这个方案依赖于 Vue 组件的内部 API，每次前端升级都要重新适配------但总比不能用强。

坑三：记忆污染------当 Agent "记住"了不该记住的东西

有次我们发现支付链路测试连续三天在同一个步骤崩溃。排查了半天，发现原因是：有一个测试员在前一天执行了"异常数据测试"，故意制造了一些格式异常的数据（比如空的指标文号）。这些数据被 Hermes 记住了，第二天正常测试时，Agent 检索到这些"异常记忆"，判断"指标文号可以为空"，于是跳过了非空校验------然后系统真就崩溃了。

解决方案是给记忆加上标签和有效期：

memory:
  tagging:
    required: true
    tags:
      - name: test_type
        values: [normal, exception, exploratory]
  retention:
    normal: 30d
    exception: 1d  # 异常测试的记忆只保留一天
    exploratory: 7d

同时，Profile 级别的隔离也起到了作用------我们把异常测试放到专门的 Profile 里执行，不会污染主测试环境。

坑四：等保合规环境下的网络隔离

财政系统的测试环境受等保 2.0 三级保护，测试服务器不能直接访问公网 API。这意味着 Hermes 没法调用外部的大模型 API。

我们的方案是在内网部署一个 API 代理网关，兼容 OpenAI 格式：

# ~/.hermes/config.yaml
llm:
  provider: openai_compatible
  base_url: http://10.0.0.100:8000/v1  # 内网 API 网关
  api_key: ${LLM_API_KEY}
  model: deepseek-chat

内网网关跑在 Kubernetes 上，使用 Envoy 做流量代理，把所有到公网的 LLM 请求路由到我们自建的模型推理集群。这么做有三个额外的好处：

1. 请求日志在网关层统一记录，满足审计要求
2. 限流和熔断在网关层统一配置
3. 切换模型只需改网关配置，不用动所有 Agent

坑五：Skills 的版本管理

自进化 Skills 很好，但如果多人同时使用同一个 Skill，A 触发了自动演化，B 没触发，Skill 版本就乱了。

我们引入了一个 Git 工作流来解决：

# skills 目录本身是 Git 仓库
cd ~/.hermes/skills
git init
git add .
git commit -m "初始 Skills 库"

# 每次 Agent 自动更新 Skill 后，自动 commit
# ~/.hermes/post_hooks/after_skill_update.sh
git add ${SKILL_PATH}
git commit -m "auto: ${SKILL_NAME} 自动更新于 $(date +%Y-%m-%d_%H:%M)"

配合 Diff 审查机制：所有自动演化必须在提交后通知测试组长人工 Review Diff，确认无误再合并到主分支。

---

五、总结与展望

从 2026 年 2 月到今天，我们的 Hermes Agent 实验跑了大半年。回头来看，最大收获不是"AI 自动化了 60% 的测试工作"------这个数字虽然漂亮，但对财政系统来说，真正的价值是三个更本质的变化：

第一，测试经验的固化方式变了。 过去，一个资深测试员的经验储存在他的大脑里，他离职了经验也跟着没了。现在，经验变成了 Skills 文件，变成了记忆库中的向量，变成了 RAG 里的知识文档。这些是可以复制、传承、审查的。

第二，测试执行的质量基线提升了。 人工执行 6000 条回归用例，最后 200 条一定是在疲惫状态下跑的，漏测概率显著上升。Agent 没有疲惫期，每条测试都是同等专注度。我们在三期回归中对比发现，Agent 执行的回归覆盖面比人工高出约 15%。

第三，跨角色协作的摩擦降低了。 预算测试员和数据测试员共用同一个基础平台，但通过 Profile 隔离了各自的工作空间。共享 Skills 的协同编辑、独立 Skills 的专有控制，既保障了协作效率又避免了相互干扰。

至于 MCP，在经历了最初的"万能工具"幻想破灭后，我们逐渐找到了正确的用法：MCP 解决的是 Agent 与外部世界的通信标准问题，而不是 Agent 本身的智能问题。把 MCP 做好，Agent 的边界就扩展了；但如果核心流程还没理清就急着接一堆 MCP Server，只会让系统更混乱。

下一步计划

我们正在做三件事：

1. Agent 之间的数据闭环协作：让预算测试 Agent 自动触发支付测试 Agent 做回归，实现"编→审→测→报"全链路自动驱动
2. Skills 市场内部化：把行业通用的财政测试 Skills（比如"预算编制合规检查"）整理成标准包，供各地财政厅局复用
3. 记忆的可信度打分：每条记忆附带"置信度"属性，来源包括 Agent 自动验证结果、人工确认标记、历史执行成功率，让 Agent 在做决策时能区分"可靠记忆"和"待验证记忆"

最后说一句：AI Agent 不是魔法，它不会让你一夜之间告别手工测试。但如果你愿意花时间理解它的设计哲学------尤其是 Hermes 的跨会话记忆、Skills 标准化和 Profile 隔离这三个核心思想------并且接受它目前的能力边界（别试图用它做复杂的非线性决策），你会得到一个越来越靠谱的测试助手。

我们团队现在的口号是："让 Agent 处理 80% 的确定性问题，让人聚焦 20% 的创造性决策。"

这条路还很长，但方向对了，就不怕慢。

---

浅木·先生，财政行业测试架构师，专注于 AI Agent 在政务系统质量保障中的应用落地。本文为个人实践总结，不代表所在机构立场。