很多企业做完 AI Agent Demo 后，才遇到真正难的问题：为什么它给出了一条错误报价？它看过哪些资料？调用了哪个工具？这次变更究竟该回归哪些场景？
这不是 Prompt 再加两句约束就能解决的事。也不是“把历史文档喂进 RAG”就能解决的事。
我越来越确信，接下来企业测试团队的分水岭，会出现在一个看似跨界的方向上：测试团队要不要长出一支“质量 FDE（Forward Deployed Engineering）”能力。
这里的 FDE 不是让测试工程师去做售前，也不是让每个人都变成驻场交付。它指的是一种面向真实业务现场的工程职责：把客户现场的流程、权限、数据、例外和事故，翻译成可以反复验证、持续更新、可被产品复用的质量资产。
DeepSeek Harness、知识图谱和企业测试智能化建设，刚好在这里汇合。
一、企业最缺的不是“会回答的 Agent”，而是“能交代清楚的 Agent”
先看一个脱敏合成的业务场景。
一家设备运维 SaaS 正在给制造集团部署“工单报价 Agent”。现场工程师输入：
A 厂夜班产线的高温故障，客户是年度框架客户，设备已过保，能否直接报价并派工？
这条问题背后至少藏着五层事实：
客户合同里有年度折扣上限；
高温故障属于 P1，夜间派工需要值班经理确认；
过保设备的备件价格走另一张价目表；
A 厂的进场许可必须由客户侧安全员放行；
本周刚更新过“紧急工单自动派单”规则。
如果 Agent 只做相似度检索，很容易从旧版操作手册里找到“高温故障可自动派工”，再从普通客户价目表里拿到一个看似合理的价格。最终文本可能很流畅，甚至工具调用也都成功了；但它会同时犯下价格、权限和安全流程三个错误。
传统测试团队通常在上线前补一批问答集、接口用例和人工验收。可一旦 FDE 或业务实施团队到了客户现场，合同条款、部门权限、例外流程和本地化规则每天都在变，测试用例很快从“覆盖”变成“过期”。
OpenAI 对 FDE 的岗位描述中，把工作范围定义为从发现问题、技术范围界定、系统设计、构建到生产上线；其衡量标准还包括由评测驱动的反馈能否改变产品与模型路线图。OpenAI FDE 职责说明
这件事对测试的启发很大：测试不该只接收交付结果，而应把现场事实转成可复用的“质量合同”。
二、DeepSeek Harness 真正可贵的地方：它让 Agent 的过程变成可查询的证据
DeepSeek Harness（DSH）不是一款“更会写代码”的模型。官方的定义很克制：Agent = Model + Harness；Harness 负责让 Agent 理解环境、使用工具并在真实环境中持续工作。模型、工具、Skill、会话、沙箱、存储、循环、调度和 UI 都可以按插件替换或组合。DeepSeek Harness 官方介绍
对企业测试团队更重要的一点是：DSH 会把系统提示、工具调用及结果、子 Agent 调度、上下文注入等记录到追加式会话日志里，并支持围绕同一事件流做查看、搜索、分叉与回放。官方运行轨迹说明
这意味着，过去散在截图、聊天记录和口头复盘里的问题，开始有机会被规范成一条条质量证据：
这次报价到底引用了哪一版合同条款？
调 create_dispatch 前，是否查过客户进场许可？
模型是根据当前规则拒绝派单，还是工具超时后“猜了一个成功”？
这次发布改变了哪个 Skill、哪个提示模板、哪个权限插件？
DSH 仓库自身的测试支持包也提供了 session-log 快照、Agent loop 测试基座、可编排的 LLM mock 服务，以及对已记录模型流的回放能力。DSH test-support 说明 这不是说企业可以直接把内部流水线照搬过去；它提醒我们：Agent 的最终答复不能是唯一断言，运行轨迹也应该进入回归资产。
但要先划一条红线：DeepSeek Harness 仍处于 developer preview，官方明确提示会有兼容性破坏性变更。项目 README 所以它适合先在隔离的评测/试点环境里验证“轨迹如何被治理”，不适合因为一波热度就成为企业生产发布的唯一控制平面。
三、别再建“文档知识图谱”了：企业真正需要的是质量部署图谱
RAG 与知识图谱常被用来帮助 Agent 理解业务、生成更细的测试用例。那解决的是知识输入的问题。
这篇要讨论的是另一层：上线时，谁和谁发生了依赖，哪条证据支持了哪次放行，某项变化会让哪些用例失效。
我把它叫作“质量部署图谱（Quality Deployment Graph）”。它不是把所有 Word、PRD、代码和会议纪要都塞进图数据库，而只保留会影响交付决策的少量对象和关系：
节点
需要记录什么
典型关系
业务能力
“高温故障报价”“夜间派工”
依赖、变更、覆盖
业务政策
合同折扣、派单阈值、审批规则
约束、适用、替代
工具与权限
get_contract
、create_dispatch、权限范围
调用、禁止、需要审批
评测用例
输入、硬约束、夹具、断言、版本
覆盖、证明、失效
Harness 运行
Prompt 版本、工具轨迹、上下文来源、结果
证据、观察到、复现
发布与事故
变更集、灰度范围、线上事件
改变、触发、回流
关键不是“节点多”，而是每条关系都要带三类元数据：来源、版本、生效范围。例如一条“夜间派单需审批”的边，必须能追到合同附件第几版，适用于哪些客户，何时开始生效。没有这三项，图谱只会把过期知识包装得更像真相。
LightRAG 的思路值得参考：它同时管理图结构和向量表示，以双层检索把局部实体事实与全局关系上下文结合；同时强调增量更新与选择性删除，以适应动态数据。LightRAG 项目说明 这和企业测试的真实诉求非常接近——我们既要能回答“合同 X 的折扣上限是什么”，也要能追到“这条规则变化会影响哪些报价、权限和评测”。
另一方面，Microsoft GraphRAG 的主仓库已经进入维护模式，更适合把它当作图增强检索的设计参考，而不是不加判断地当作唯一选型。Microsoft GraphRAG 仓库状态 2026 年的重点不在于押中某个 GraphRAG 名字，而在于你的图谱能否随着发布、事故和政策变更而持续校正。
四、把“变更影响分析”从经验判断，变成一条可执行的选测计划
设想报价 Agent 的一个改动：研发把“读取客户合同”的工具从同步 API 换成缓存读，并修改了夜间派单 Skill。
传统做法往往是群里问一句：“这次改动影响哪些用例？”然后 QA 凭经验拉一轮回归。问题不在于 QA 不够懂，而是证据没有被组织起来：谁能证明这个缓存没有读到旧合同？谁能证明修改派单 Skill 不会绕过经理审批？
质量部署图谱可以把“选测”分成两个动作：
从发布变更出发，找到受影响的能力、政策、权限和工具；
找到覆盖这些对象的评测用例，并检查其夹具和规则版本是否仍然新鲜。
下面的代码不是“画图式伪代码”。它展示了一个落地时很有价值的接口：让发布门禁从图中取回必须执行、但当前没有新鲜证据的评测项。图存储可以是 Neo4j，也可以是你们已有的配置库；重点是关系和版本，而不是数据库名字。
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 版本、工具版本和测试夹具版本。否则你会得到最危险的假象——一堆绿色历史用例，证明的却是上一版合同和上一版派单流程。
五、Harness 轨迹怎么进测试？别只断言“回答正确”
回到夜间派工场景。下面是一份从 Harness 追加式日志标准化出来的运行事件。字段并不绑定 DSH 的内部 API；企业落地时，应先把会话日志映射为自己的稳定事件契约，避免框架升级把评测资产一起拖垮。
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、工具包装、规则和模板。
三者的边界一旦清楚，才会形成正循环：客户现场不是一次性定制的黑洞，而是产品能力和测试资产的来源。
结语：下一代测试团队的护城河，是把现场经验固化成“可放行的证据”
DeepSeek Harness 提供了一个很重要的启示：真正的 Agent 工程不只关心模型最后说了什么，也关心它看见了什么、调用了什么、经历了什么，并且能否被重新检查。
知识图谱也不该只用来让回答“更聪明”。在企业测试团队里，它更应该回答：这项变化牵动了谁？哪些证据仍然有效？哪条风险必须阻断上线？
而 FDE 工程的价值，不在于把每个客户现场都做成一套独立项目，而在于把现场发现持续反哺为可复用能力。测试团队如果能接住这件事，就不再只是“AI 上线前的最后一道关”，而会成为企业 AI 交付能否规模化的质量中枢。
对正在做企业 Agent 私有化部署、内训或平台建设的团队来说，第一步不是选一个最热的框架，而是挑一条业务损失清晰的高风险流程，建立第一份可追溯、可回放、可放行的质量合同。
