实战复盘：我是怎样用代码实现 Harness 的

上篇回顾：上一篇我们聊了 DIFY 的边界，结论是它适合做“接客”的轻量级编排，但核心逻辑还得靠代码。这一篇，我想把“代码”这件事聊透。

面试中最虚的就是被问到“你具体怎么做的？”。如果我说“我用 DIFY 做了个流程”，那太浅了。但如果我说“我手写了一套 Harness 机制来管控 AI 的行为”，这就有了技术深度。

今天，我就以一个虚构但极其常见的 “订单核查机器人” 为例，复盘一下我是如何用 Python 实现 Harness Engineering​ 的。

1. 场景设定：AI 的“幻觉”是致命的

假设业务场景是这样的：用户问客服机器人——“订单号 ORD12345 的物流卡住了，发票金额是不是多算了？”

如果直接用 DIFY 或者简单的 LangChain Agent，很容易出问题：

1. 参数提取错误：模型可能把 ORD12345 看成 0RD12345。
2. API 调用失控：模型可能试图调用删除订单的接口，或者查询其他用户的隐私数据。
3. 结果解析错误：模型可能把返回的 JSON 数据看错行，导致告诉用户“金额正确”，实际上差了 1000 块。

在金融或电商场景，这种错误是不可接受的。这时候，Harness（缰绳） ​ 就必须上场了。

2. 架构设计：LLM 只做“大脑”，代码做“手脚”

我的核心原则是：LLM 负责理解和规划，代码负责执行和校验。

我设计了一个 OrderCheckSkill（订单核查技能）。当大模型决定需要核查订单时，它不是直接飞快地调用各种 API，而是调用我的这个 Skill，并传入它认为的参数。

架构图如下：

 复制代码用户提问
   ↓
[LLM 节点]：理解意图，提取参数（订单号）
   ↓
[OrderCheckSkill] (Harness 发生在这里)
   ↓
[执行结果]：结构化数据
   ↓
[LLM 节点]：根据结构化数据生成自然语言回复

3. 代码实现：三层 Harness 防护

下面是这个 Skill 的核心逻辑（Python 伪代码），重点看注释部分，那就是 Harness 的具体落地：

 复制代码from pydantic import BaseModel, ValidationError
import requests
import logging# ---------- 第一层 Harness：严格的参数校验 ----------
class OrderCheckParams(BaseModel):
    """
    使用 Pydantic 定义参数模型。
    这是 Harness 的第一道防线：确保进来的数据是合法的。
    """
    order_id: str
    check_type: str # 'logistics' or 'invoice'def OrderCheckSkill(params: dict):
    try:
        # 强制校验：如果 params 不符合定义，直接抛异常，阻断执行
        validated_params = OrderCheckParams(**params)
    except ValidationError as e:
        # 绝不把错误抛给 LLM 去理解，而是直接返回错误信息
        return {"error": "参数格式错误，无法执行"}    order_id = validated_params.order_id
    check_type = validated_params.check_type    # ---------- 第二层 Harness：权限与范围控制 ----------
    # 白名单机制：只允许查询特定的业务系统
    ALLOWED_APIS = {
        "logistics": "https://internal-api/logistics/",
        "invoice": "https://internal-api/finance/"
    }
    
    if check_type not in ALLOWED_APIS:
        # 防止模型试图调用未授权的接口（如 delete_order）
        logging.warning(f"Attempted unauthorized access: {check_type}")
        return {"error": "无权访问该资源"}    api_url = ALLOWED_APIS[check_type] + order_id    # ---------- 第三层 Harness：执行控制与容错 ----------
    try:
        # 设置超时和重试机制
        response = requests.get(api_url, timeout=5)
        response.raise_for_status() # 如果状态码不是 200，抛异常
        data = response.json()
    except requests.Timeout:
        # 网络超时处理：不崩溃，返回可控结果
        return {"error": "查询超时，请稍后再试"}
    except Exception as e:
        # 兜底异常处理
        logging.error(f"API call failed: {e}")
        return {"error": "系统繁忙，请稍后重试"}    # ---------- 第四层 Harness：结果校验与清洗 ----------
    # 确保返回的数据包含必要的字段
    if "status" not in data or "amount" not in data:
        return {"error": "数据格式异常"}    # 数据脱敏（如果必要）
    if "user_name" in data:
        data["user_name"] = "***"    # 返回干净、结构化、安全的数据给 LLM
    return data

4. 复盘：这就是 Harness Engineering

回头看这段代码，你会发现几乎没有一行代码是在教模型怎么思考，所有的代码都在做一件事：限制、保护、验证。

1. 参数校验（Pydantic） ：防止模型瞎填参数（如 SQL 注入、错误的 ID 格式）。
2. 权限白名单：防止模型越权（这是 DIFY 很难精细做到的）。
3. 执行控制（超时/重试） ：防止模型因为网络波动导致整个流程崩溃。
4. 结果清洗：防止模型看到不该看的数据（脱敏），并确保它拿到的数据结构是稳定的。

这就是 Harness。它把模型从“野生”状态，变成了“受控”状态。

5. 与 DIFY 的结合

在实际项目中，我并不会抛弃 DIFY。相反，我会把上面的 OrderCheckSkill 封装成一个 Docker 容器​ 或者 FastAPI 服务，然后在 DIFY 的工作流里，用一个简单的 HTTP 节点​ 去调用它。

这样，DIFY 负责前端交互和简单的逻辑编排（比如：先问好，再查单），而复杂的安全管控和业务逻辑则由我的代码（Harness）负责。

6. 总结

Harness Engineering 的核心代码量不大，但它体现的是一种“防御性编程”的思维。 ​ 在 AI 时代，我们不能假设模型永远正确，我们必须假设它会犯错，然后用代码去兜底。

下篇预告：

刚才的代码里，我提到了 response.json()。这些数据从哪里来？如果知识库里的文档是乱的，模型再聪明也查不出正确的物流信息。这就引出了 JD 中要求的 ETL 与数据调度。下一篇，我们来聊聊 AI 系统的地基——《数据基石》。