


很多企业做完 AI Agent Demo 后，才遇到真正难的问题：**为什么它给出了一条错误报价？它看过哪些资料？调用了哪个工具？这次变更究竟该回归哪些场景？**

这不是 Prompt 再加两句约束就能解决的事。也不是“把历史文档喂进 RAG”就能解决的事。

我越来越确信，接下来企业测试团队的分水岭，会出现在一个看似跨界的方向上：**测试团队要不要长出一支“质量 FDE（Forward Deployed Engineering）”能力。**

这里的 FDE 不是让测试工程师去做售前，也不是让每个人都变成驻场交付。它指的是一种面向真实业务现场的工程职责：把客户现场的流程、权限、数据、例外和事故，翻译成可以反复验证、持续更新、可被产品复用的质量资产。

DeepSeek Harness、知识图谱和企业测试智能化建设，刚好在这里汇合。

## 一、企业最缺的不是“会回答的 Agent”，而是“能交代清楚的 Agent”

先看一个脱敏合成的业务场景。

一家设备运维 SaaS 正在给制造集团部署“工单报价 Agent”。现场工程师输入：

> A 厂夜班产线的高温故障，客户是年度框架客户，设备已过保，能否直接报价并派工？

这条问题背后至少藏着五层事实：

1. 客户合同里有年度折扣上限；
2. 高温故障属于 P1，夜间派工需要值班经理确认；
3. 过保设备的备件价格走另一张价目表；
4. A 厂的进场许可必须由客户侧安全员放行；
5. 本周刚更新过“紧急工单自动派单”规则。

如果 Agent 只做相似度检索，很容易从旧版操作手册里找到“高温故障可自动派工”，再从普通客户价目表里拿到一个看似合理的价格。最终文本可能很流畅，甚至工具调用也都成功了；但它会同时犯下**价格、权限和安全流程**三个错误。

传统测试团队通常在上线前补一批问答集、接口用例和人工验收。可一旦 FDE 或业务实施团队到了客户现场，合同条款、部门权限、例外流程和本地化规则每天都在变，测试用例很快从“覆盖”变成“过期”。

OpenAI 对 FDE 的岗位描述中，把工作范围定义为从发现问题、技术范围界定、系统设计、构建到生产上线；其衡量标准还包括由评测驱动的反馈能否改变产品与模型路线图。[OpenAI FDE 职责说明](https://openai.com/careers/forward-deployed-engineer-(fde)-sf-san-francisco/)

这件事对测试的启发很大：**测试不该只接收交付结果，而应把现场事实转成可复用的“质量合同”。**

![image.png](https://developer.qcloudimg.com/http-save/yehe-9678105/53c4b8f3ce87ab52449e247d1f5446ff.png)


## 二、DeepSeek Harness 真正可贵的地方：它让 Agent 的过程变成可查询的证据

DeepSeek Harness（DSH）不是一款“更会写代码”的模型。官方的定义很克制：Agent = Model + Harness；Harness 负责让 Agent 理解环境、使用工具并在真实环境中持续工作。模型、工具、Skill、会话、沙箱、存储、循环、调度和 UI 都可以按插件替换或组合。[DeepSeek Harness 官方介绍](https://www.deepseek.com/harness/en/)

对企业测试团队更重要的一点是：DSH 会把系统提示、工具调用及结果、子 Agent 调度、上下文注入等记录到追加式会话日志里，并支持围绕同一事件流做查看、搜索、分叉与回放。[官方运行轨迹说明](https://www.deepseek.com/harness/en/)

这意味着，过去散在截图、聊天记录和口头复盘里的问题，开始有机会被规范成一条条质量证据：

- 这次报价到底引用了哪一版合同条款？
- 调 `create_dispatch` 前，是否查过客户进场许可？
- 模型是根据当前规则拒绝派单，还是工具超时后“猜了一个成功”？
- 这次发布改变了哪个 Skill、哪个提示模板、哪个权限插件？

DSH 仓库自身的测试支持包也提供了 session-log 快照、Agent loop 测试基座、可编排的 LLM mock 服务，以及对已记录模型流的回放能力。[DSH `test-support` 说明](https://github.com/deepseek-ai/deepseek-harness/blob/master/packages/test-support/README.zh.md) 这不是说企业可以直接把内部流水线照搬过去；它提醒我们：**Agent 的最终答复不能是唯一断言，运行轨迹也应该进入回归资产。**

但要先划一条红线：DeepSeek Harness 仍处于 developer preview，官方明确提示会有兼容性破坏性变更。[项目 README](https://github.com/deepseek-ai/deepseek-harness) 所以它适合先在隔离的评测/试点环境里验证“轨迹如何被治理”，不适合因为一波热度就成为企业生产发布的唯一控制平面。

## 三、别再建“文档知识图谱”了：企业真正需要的是质量部署图谱

RAG 与知识图谱常被用来帮助 Agent 理解业务、生成更细的测试用例。那解决的是**知识输入**的问题。

这篇要讨论的是另一层：上线时，谁和谁发生了依赖，哪条证据支持了哪次放行，某项变化会让哪些用例失效。

我把它叫作“质量部署图谱（Quality Deployment Graph）”。它不是把所有 Word、PRD、代码和会议纪要都塞进图数据库，而只保留**会影响交付决策的少量对象和关系**：

| 节点 | 需要记录什么 | 典型关系 |
| --- | --- | --- |
| 业务能力 | “高温故障报价”“夜间派工” | 依赖、变更、覆盖 |
| 业务政策 | 合同折扣、派单阈值、审批规则 | 约束、适用、替代 |
| 工具与权限 | `get_contract`、`create_dispatch`、权限范围 | 调用、禁止、需要审批 |
| 评测用例 | 输入、硬约束、夹具、断言、版本 | 覆盖、证明、失效 |
| Harness 运行 | Prompt 版本、工具轨迹、上下文来源、结果 | 证据、观察到、复现 |
| 发布与事故 | 变更集、灰度范围、线上事件 | 改变、触发、回流 |

关键不是“节点多”，而是每条关系都要带三类元数据：**来源、版本、生效范围**。例如一条“夜间派单需审批”的边，必须能追到合同附件第几版，适用于哪些客户，何时开始生效。没有这三项，图谱只会把过期知识包装得更像真相。

LightRAG 的思路值得参考：它同时管理图结构和向量表示，以双层检索把局部实体事实与全局关系上下文结合；同时强调增量更新与选择性删除，以适应动态数据。[LightRAG 项目说明](https://github.com/HKUDS/LightRAG) 这和企业测试的真实诉求非常接近——我们既要能回答“合同 X 的折扣上限是什么”，也要能追到“这条规则变化会影响哪些报价、权限和评测”。

另一方面，Microsoft GraphRAG 的主仓库已经进入维护模式，更适合把它当作图增强检索的设计参考，而不是不加判断地当作唯一选型。[Microsoft GraphRAG 仓库状态](https://github.com/microsoft/graphrag) 2026 年的重点不在于押中某个 GraphRAG 名字，而在于你的图谱能否随着发布、事故和政策变更而持续校正。

![image.png](https://developer.qcloudimg.com/http-save/yehe-9678105/ebce73370b0c44f82921d292373d7103.png)


## 四、把“变更影响分析”从经验判断，变成一条可执行的选测计划

设想报价 Agent 的一个改动：研发把“读取客户合同”的工具从同步 API 换成缓存读，并修改了夜间派单 Skill。

传统做法往往是群里问一句：“这次改动影响哪些用例？”然后 QA 凭经验拉一轮回归。问题不在于 QA 不够懂，而是**证据没有被组织起来**：谁能证明这个缓存没有读到旧合同？谁能证明修改派单 Skill 不会绕过经理审批？

质量部署图谱可以把“选测”分成两个动作：

1. 从发布变更出发，找到受影响的能力、政策、权限和工具；
2. 找到覆盖这些对象的评测用例，并检查其夹具和规则版本是否仍然新鲜。

下面的代码不是“画图式伪代码”。它展示了一个落地时很有价值的接口：让发布门禁从图中取回**必须执行、但当前没有新鲜证据**的评测项。图存储可以是 Neo4j，也可以是你们已有的配置库；重点是关系和版本，而不是数据库名字。

```python
from dataclasses import dataclass
from neo4j import Driver


@dataclass(frozen=True)
class RequiredEval:
    capability: str
    protected_asset: str
    risk: str
    eval_ids: tuple[str, ...]


IMPACT_QUERY = """
MATCH (release:Release {id: $release_id})-[:CHANGES]->(cap:Capability)
MATCH path = (cap)-[*1..4]->(asset)
WHERE ALL(rel IN relationships(path) WHERE type(rel) IN
    ['CALLS', 'READS', 'DECIDES_ON', 'ENFORCED_BY', 'REQUIRES_APPROVAL'])
  AND (asset:Policy OR asset:Tool OR asset:Permission)
OPTIONAL MATCH (eval:EvalCase)-[:COVERS]->(asset)
OPTIONAL MATCH (eval)-[:PASSED_IN]->(build:Build {id: $baseline_build})
WITH cap, asset,
     collect(DISTINCT CASE WHEN build IS NOT NULL THEN eval.id END) AS fresh_evals
RETURN cap.id AS capability,
       asset.id AS protected_asset,
       coalesce(asset.risk, 'P2') AS risk,
       [item IN fresh_evals WHERE item IS NOT NULL] AS eval_ids
ORDER BY CASE coalesce(asset.risk, 'P2')
           WHEN 'P0' THEN 0 WHEN 'P1' THEN 1 ELSE 2 END
"""


def required_evals(driver: Driver, release_id: str, baseline_build: str) -> list[RequiredEval]:
    with driver.session() as session:
        rows = session.run(
            IMPACT_QUERY,
            release_id=release_id,
            baseline_build=baseline_build,
        )
        return [
            RequiredEval(
                capability=row["capability"],
                protected_asset=row["protected_asset"],
                risk=row["risk"],
                eval_ids=tuple(row["eval_ids"]),
            )
            for row in rows
        ]


def assert_release_has_evidence(plan: list[RequiredEval]) -> None:
    missing = [
        f"{item.capability} → {item.protected_asset} ({item.risk})"
        for item in plan
        if item.risk in {"P0", "P1"} and not item.eval_ids
    ]
    if missing:
        raise AssertionError(
            "高风险变更缺少当前基线的回归证据：\n- " + "\n- ".join(missing)
        )
```

它解决的是一个很具体的问题：**不再因为“全量跑不动”就靠感觉删用例，也不再因为怕漏而把所有用例都跑一遍。**

这里有个容易被忽略的细节：`PASSED_IN` 不能只表示“历史上跑过”。它必须绑定本次的 Policy 版本、工具版本和测试夹具版本。否则你会得到最危险的假象——一堆绿色历史用例，证明的却是上一版合同和上一版派单流程。

![image.png](https://developer.qcloudimg.com/http-save/yehe-9678105/bb1420cefacc814e20333408235302a4.png)


## 五、Harness 轨迹怎么进测试？别只断言“回答正确”

回到夜间派工场景。下面是一份从 Harness 追加式日志标准化出来的运行事件。字段并不绑定 DSH 的内部 API；企业落地时，应先把会话日志映射为自己的稳定事件契约，避免框架升级把评测资产一起拖垮。

```python
from collections.abc import Iterable


def tool_calls(events: Iterable[dict], name: str) -> list[dict]:
    return [
        event for event in events
        if event["type"] == "tool.result" and event["tool"] == name
    ]


def event_index(events: list[dict], predicate) -> int:
    return next(i for i, event in enumerate(events) if predicate(event))


def assert_night_dispatch_run(run: dict) -> None:
    """保护年度框架客户的夜间派工：业务事实、调用顺序和副作用都要验证。"""
    events = run["events"]

    contract = tool_calls(events, "get_contract")
    assert contract and contract[-1]["output"]["customer_tier"] == "FRAMEWORK"
    assert contract[-1]["output"]["policy_version"] == "contract-2026-09-01"

    price = tool_calls(events, "get_spare_price")
    assert price and price[-1]["input"]["pricebook"] == "OUT_OF_WARRANTY"

    approval_idx = event_index(
        events,
        lambda event: event["type"] == "tool.result"
        and event["tool"] == "request_manager_approval"
        and event["output"]["status"] == "PENDING",
    )
    dispatches = tool_calls(events, "create_dispatch")

    # 有待审批时，Agent 可以生成报价草案，但不能产生不可逆的派工副作用。
    assert not dispatches, "P1 夜间工单在审批前不得自动派工"
    assert run["final"]["status"] == "NEEDS_APPROVAL"
    assert approval_idx < event_index(
        events,
        lambda event: event["type"] == "final.answer",
    )
```

这段断言比“最终答案里有没有出现‘请审批’”多了三层保护：

- **事实层**：读到的是当前合同和正确价目表；
- **轨迹层**：先拿到审批状态，再给用户答复；
- **副作用层**：在审批通过前，没有实际创建派工单。

这才是企业 Agent 评测和普通聊天问答评测的差别。文本可以有多种等价表达；但合同版本、审批顺序、工具副作用和权限边界，不能模糊处理。

## 六、测试团队怎样成为“质量 FDE”，而不是又多背一套平台

很多团队一听到知识图谱、可观测、评测和 FDE，就会马上启动一个半年期大项目：建统一知识库、接所有文档、做万能助手、让所有测试数据都进图。

我更建议反过来，按照“一个高风险流程、三个月、四类资产”推进。

| 阶段 | 做什么 | 交付物 | 不做什么 |
| --- | --- | --- | --- |
| 0—30 天 | 选一条有真实损失的流程，如报价、审批、售后派工 | 质量合同、10—20 条 P0/P1 评测、人工维护的小图谱 | 不做全公司知识图谱 |
| 31—60 天 | 在隔离环境接入 Harness，统一事件信封与回放夹具 | 可重放轨迹、工具 mock、变更影响选测 | 不让 Agent 直连生产写操作 |
| 61—90 天 | 把评测接到灰度和发布评审，收集一次真实异常 | 发布门禁、事故复盘模板、可复用组件 | 不把 LLM Judge 当唯一放行人 |

这个过程里，FDE/实施团队提供现场语义：真正的例外、角色、风险和业务结果；测试团队负责把这些东西变成**质量合同、图谱关系、可回放轨迹和上线证据**；平台团队把稳定的模式沉淀成 Skill、工具包装、规则和模板。

三者的边界一旦清楚，才会形成正循环：客户现场不是一次性定制的黑洞，而是产品能力和测试资产的来源。

![image.png](https://developer.qcloudimg.com/http-save/yehe-9678105/e3dc98d4e6d8415e791a2f57c9d37d92.png)


## 结语：下一代测试团队的护城河，是把现场经验固化成“可放行的证据”

DeepSeek Harness 提供了一个很重要的启示：真正的 Agent 工程不只关心模型最后说了什么，也关心它看见了什么、调用了什么、经历了什么，并且能否被重新检查。

知识图谱也不该只用来让回答“更聪明”。在企业测试团队里，它更应该回答：**这项变化牵动了谁？哪些证据仍然有效？哪条风险必须阻断上线？**

而 FDE 工程的价值，不在于把每个客户现场都做成一套独立项目，而在于把现场发现持续反哺为可复用能力。测试团队如果能接住这件事，就不再只是“AI 上线前的最后一道关”，而会成为企业 AI 交付能否规模化的质量中枢。

对正在做企业 Agent 私有化部署、内训或平台建设的团队来说，第一步不是选一个最热的框架，而是挑一条业务损失清晰的高风险流程，建立第一份可追溯、可回放、可放行的质量合同。

很多企业做完 AI Agent Demo 后，才遇到真正难的问题：为什么它给出了一条错误报价？它看过哪些资料？调用了哪个工具？这次变更究竟该回归哪些场景？

DeepSeek Harness + 知识图谱：企业测试团队，正在长出一支“质量 FDE”

测试

人工智能

架构设计

企业AI Agent落地的关键不在模型更聪明，而在过程可追溯、变更可评估。测试团队应建立"质量FDE"能力，将现场业务规则沉淀为质量合同，用Harness轨迹作为证据，以质量部署图谱驱动选测，实现从结果断言到过程治理的升级，构建可放行的质量中枢。

知识图谱

代码解释

数据库

Agent

SaaS

2026上云采购 | AI焕新·智启新局

lexiang

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

DeepSeek Harness + 知识图谱：企业测试团队，正在长出一支“质量 FDE”-腾讯云开发者社区-腾讯云

DeepSeek Harness + 知识图谱：企业测试团队，正在长出一支“质量 FDE”

DeepSeek Harness + 知识图谱：企业测试团队，正在长出一支“质量 FDE”

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐