Harness Engineering：跨系统协作的接口层工程化实践

1. 先别急着装工具——Harness Engineering 不是新软件，而是工程思维的“接口层重构”

最近刷技术社区、招聘JD、甚至内部立项会，总能看到“Harness Engineering”这个词高频出现。它不像 Docker 或 Kubernetes 那样有明确的二进制包可下载，也不像 VS Code 那样点开就能写代码；它没有官网首页、没有 GitHub star 数实时滚动，甚至搜不到一份权威定义文档。但奇怪的是，一线团队在聊 CI/CD 卡点时会说“缺 Harness Engineering 能力”，架构评审会上提到“这个模块的 harness 没对齐”，连外包交付验收单里都悄悄加了一条：“需提供 harness specification 文档”。

这词不是拼写错误，也不是某个小众工具的代称——Harness Engineering 的核心，是把“系统如何被安全、可控、可验证地接入与驱动”这件事，从隐性经验变成显性工程。它解决的从来不是“用什么工具”，而是“当 A 系统要调用 B 系统、B 要触发 C 的校验、C 又要回传状态给 A”这一整条链路上，谁来定义边界？谁来兜住异常？谁来保证每次触发都可追溯、可重放、可审计？

关键词里反复出现的System Prompt、Tools、Middleware、Verification Loop，其实已经勾勒出它的四根支柱：

• System Prompt是“指令入口”——不是自然语言提示词，而是结构化、带元信息的调用契约（比如一个 JSON Schema 描述“调用支付网关必须携带 merchant_id、order_id、timestamp、signature_v2”）；
• Tools不是泛指开发工具链，而是指被明确定义了输入/输出/副作用/超时/重试策略的原子能力单元（例如一个封装好的“发短信”工具，它不暴露 HTTP client，只暴露 send_sms(to: str, content: str, template_id: str) → Result[Success, RateLimitExceeded, InvalidTemplate]）；
• Middleware是“协议翻译器”——它不处理业务逻辑，只做三件事：校验输入是否符合 System Prompt、转换数据格式适配下游 Tools、注入 trace_id 和 context 供 Verification Loop 捕获；
• Verification Loop是“闭环校验器”——不是简单的日志打印，而是主动发起反向探查：调用完成 3 秒后，自动查数据库确认订单状态变更；5 秒后，抓取消息队列确认事件已投递；10 秒后，调用下游健康检查接口确认无积压。

所以，当有人说“我们要做 Harness Engineering”，他真正想表达的是：我们不能再靠人肉写脚本、靠口头约定参数、靠翻日志猜问题了。要把所有跨系统协作的“连接点”，当成需要设计、测试、版本化、监控的一等公民来对待。

它和你熟悉的“API 管理”有本质区别：API 管理聚焦于“暴露什么”，Harness Engineering 聚焦于“如何被安全可靠地使用”。它也不同于传统中间件开发：中间件工程师关心吞吐和延迟，Harness Engineer 关心“当支付回调失败时，重试逻辑是否跳过了风控拦截？补偿任务是否重复扣款？审计日志能否还原完整决策路径？”

提示：如果你正在评估一个新系统接入方案，先别急着看它支持多少种协议或并发量多高——直接问对接方三个问题：

1. 你们的 System Prompt 文档在哪里？是否包含字段级约束、枚举值范围、必填/选填标识、以及每个字段的业务含义说明？
2. 所有对外提供的 Tools 是否都附带独立的单元测试用例？这些用例是否覆盖了超时、网络中断、下游返回 503、上游重复请求等边界场景？
3. Verification Loop 的执行频率、校验维度、失败告警阈值、以及人工介入 SOP 是什么？有没有过去三个月的 Loop 执行成功率报表？
   如果对方答不上来，或者回答含糊其辞，那无论它叫什么名字，本质上都还没进入 Harness Engineering 阶段。

2. 为什么现在突然火了？——不是技术爆发，而是系统复杂度越过了“人肉协调”的临界点

Harness Engineering 并非横空出世的新技术。早在 2010 年代初，大型银行核心系统升级时，就有人用 Excel 表格定义“柜面交易调用清算系统的 17 个字段映射规则”，并手写 Perl 脚本做字段校验；2015 年微服务兴起后，“API 网关 + OpenAPI Spec”曾短暂承担过部分 harness 职能；2020 年前后，随着 Serverless 和低代码平台普及，“Connector”“Adapter”“Integration Flow”等概念也在不同层面尝试解决类似问题。

但它真正从边缘实践走向主流共识，关键触发点是系统交互复杂度突破了人类短期记忆与协作带宽的物理极限。我们可以用一个真实案例说明：

某电商平台在 2022 年上线“直播秒杀”功能。初期只有 3 个系统参与：前端 H5 页面、商品库存服务、订单中心。调用链路是线性的：H5 → 库存服务（扣减）→ 订单中心（创建）。运维同学靠一张脑图+几条 curl 命令就能定位问题。

但到 2024 年，同一秒杀活动涉及 12 个系统：

• 前端：H5、小程序、APP、PC 端（4 个入口）
• 中台：库存服务、价格中心、优惠券中心、风控引擎、实名认证服务、物流预估服务（6 个）
• 后端：订单中心、支付网关、短信平台、消息推送服务（4 个）
• 外部：银联支付、微信支付、三大运营商短信网关（3 个）

更致命的是，调用关系不再是线性，而是网状：

• 用户点击“抢购”后，前端同时向库存服务、价格中心、优惠券中心发起查询；
• 库存服务返回成功后，风控引擎才开始校验用户历史行为；
• 风控通过后，价格中心才触发“动态定价”计算；
• 任一环节失败，都要触发对应补偿：库存回滚、优惠券释放、风控记录归档……

这时，靠“张三负责库存、李四负责风控、王五写补偿脚本”的协作模式彻底崩溃。问题排查变成侦探游戏：

• 客服反馈“用户说抢到了但没下单”，日志显示订单中心没收到请求；
• 追踪发现风控引擎返回了{"code": "RISK_002", "msg": "疑似机器人"}，但前端没解析该 code，直接显示“网络错误”；
• 查风控日志，发现它依赖的实名认证服务超时，而实名认证服务又因上游公安接口限流失败；
• 公安接口限流是因为某省厅系统升级，但该信息只在政务云内部邮件组通知……

Harness Engineering 正是在这种混沌中给出的系统性解法：它强制把“谁在什么时候、以什么格式、向谁发起什么请求、期望什么响应、失败后怎么兜底”全部提前定义、版本化、自动化校验。

它火起来的另一个现实原因是工具链的成熟让落地成本大幅降低。过去要实现 Verification Loop，得自己写调度器、建结果比对服务、搭告警通道；现在用开源项目如 Temporal（工作流编排）、OpenTelemetry（可观测性）、JSON Schema Validator（契约校验），配合轻量级 DSL（如 YAML 定义 harness spec），一个中级工程师两天就能搭出可运行的最小闭环。

注意：Harness Engineering 的成熟度，和公司技术栈先进性无关，而和“跨系统协作的显性化程度”强相关。我们见过用纯 Shell 脚本 + Cron + MySQL 表实现 harness 的传统企业（把所有校验规则存进数据库，脚本定时扫描执行），也见过用 GraphQL Federation + Apollo Router 实现的现代方案。关键不在技术选型，而在是否承认“连接本身需要被工程化”。

3. 别被热词带偏——Harness Engineering 的四个核心实践层，和你每天写的代码直接相关

网上搜索 “harness engineering 如何落地”，结果充斥着“推荐 5 款 harness 工具”“harness engineering 最佳实践 PDF 下载”之类标题党内容。但真相是：Harness Engineering 没有标准工具箱，只有四个必须逐层夯实的实践层。每一层，都对应你日常开发中一个具体动作。

3.1 第一层：System Prompt —— 你写的每一个函数签名，都是微型 harness

很多人以为 System Prompt 是 API 文档或 Swagger UI。错。它是对“调用意图”的精确编码。当你写一个 Python 函数：

def calculate_discount(user_id: str, order_items: List[Dict], coupon_code: Optional[str] = None) -> Dict: ...

这个函数签名本身就是最原始的 System Prompt。它隐含了：

• user_id必须是非空字符串（否则风控无法识别身份）；
• order_items必须是列表，且每个 item 必须包含sku_id、quantity字段（否则价格计算无依据）；
• coupon_code若提供，则必须匹配正则^[A-Z]{3}-\d{4}$（否则优惠券中心直接拒绝）；
• 返回值必须包含final_amount、discount_detail字段（否则前端无法渲染）；

Harness Engineering 要求你把这种隐含契约显性化、可验证、可版本化。做法很简单：

1. 为每个核心函数/接口，单独维护一个prompt.yaml文件：

# prompt/calculate_discount.v1.yaml name: calculate_discount version: "1.0" description: "根据用户、商品清单和优惠券计算最终金额" input_schema: type: object required: [user_id, order_items] properties: user_id: type: string minLength: 8 pattern: "^[a-zA-Z0-9_]+$" description: "用户唯一标识，由认证中心颁发" order_items: type: array minItems: 1 items: type: object required: [sku_id, quantity] properties: sku_id: type: string description: "商品 SKU 编码" quantity: type: integer minimum: 1 maximum: 999 coupon_code: type: string pattern: "^[A-Z]{3}-\\d{4}$" description: "优惠券兑换码，格式如 ABC-1234" output_schema: type: object required: [final_amount, discount_detail] properties: final_amount: type: number multipleOf: 0.01 discount_detail: type: object properties: base_amount: {type: number} coupon_discount: {type: number} platform_subsidy: {type: number}

2. 在函数入口处，用jsonschema.validate()自动校验输入（Python）或ajv（JavaScript）；
3. 将prompt.yaml文件纳入 Git 版本管理，每次修改需 PR + 三方评审；
4. 生成 HTML 文档自动发布到内部 Wiki，链接嵌入代码注释。

实操心得：很多团队卡在第一步——觉得“写 YAML 太麻烦”。我的经验是：先从最痛的 3 个接口开始。比如支付回调、用户注册、订单创建。这 3 个接口占了线上 70% 的参数校验类报错。用半天时间写出它们的 prompt.yaml，再用pre-commithook 集成校验，第二天就能看到日志里InvalidParameterError错误下降 90%。这种即时正反馈，比任何 PPT 培训都管用。

3.2 第二层：Tools —— 你封装的每一个 SDK，都该是 harness-ready 的

“Tools” 在 Harness Engineering 语境下，特指被严格约束了行为边界的可复用能力单元。它和普通 SDK 的关键区别在于：

• 不暴露底层细节：不让你直接操作 HTTP client、数据库连接、文件句柄；
• 强制声明副作用：明确标注“此调用会修改数据库”“此调用会发送短信”“此调用会触发异步任务”；
• 内置防御性策略：默认开启重试（指数退避）、熔断（失败率 > 50% 自动降级）、超时（全局 3s，可局部覆盖）；
• 返回结构化结果：不是True/False或None，而是Result[Success, NetworkError, ValidationError, RateLimitExceeded]。

以封装短信平台为例：

# ❌ 普通 SDK（harness-unfriendly） class SmsClient: def __init__(self, api_key): self.session = requests.Session() def send(self, phone, content): # 参数无约束，返回无结构 return self.session.post("https://api.sms.com/send", json={ "phone": phone, "content": content }).json() # 可能抛异常，可能返回 {"code": 0}，也可能 {"error": "xxx"} # ✅ Harness-ready Tool（harness-friendly） from typing import Union, Literal from dataclasses import dataclass @dataclass class SmsResult: status: Literal["success", "failed"] error_code: Optional[str] = None error_msg: Optional[str] = None message_id: Optional[str] = None class SmsTool: def __init__(self, api_key: str, timeout: float = 3.0): self.api_key = api_key self.timeout = timeout def send(self, to_phone: str, template_id: str, params: Dict[str, str]) -> SmsResult: # 1. 输入校验（基于 prompt.yaml） if not re.match(r"^1[3-9]\d{9}$", to_phone): return SmsResult(status="failed", error_code="INVALID_PHONE") # 2. 内置重试与熔断（用 tenacity 库） try: response = self._send_with_retry(template_id, params) return SmsResult(status="success", message_id=response["msg_id"]) except requests.Timeout: return SmsResult(status="failed", error_code="TIMEOUT") except requests.ConnectionError: return SmsResult(status="failed", error_code="NETWORK_ERROR") except Exception as e: return SmsResult(status="failed", error_code="UNKNOWN", error_msg=str(e))

关键技巧：不要试图改造现有 SDK。而是用“适配器模式”包一层。新建sms_tool.py，里面只暴露send()方法，所有底层细节（HTTP 调用、序列化、重试逻辑）全在里面。这样既不影响老代码，又能快速让新模块具备 harness 能力。我们团队用此法，在两周内将 8 个外部依赖（支付、短信、物流、风控等）全部“harness 化”，后续新增接口平均只需 15 分钟。

3.3 第三层：Middleware —— 你写的每一个装饰器，都在构建 harness 的神经中枢

Middleware 是 Harness Engineering 的“翻译官”和“守门人”。它不处理业务，只做三件事：

1. 契约翻译：把上游 System Prompt 的抽象要求，翻译成下游 Tools 能理解的具体参数；
2. 上下文编织：注入 trace_id、user_id、request_id、环境标识（prod/staging），确保全链路可追溯；
3. 流量整形：根据下游 Tools 的 SLA，动态调整并发数、批量大小、重试间隔。

最常见的 Middleware 就是 Web 框架里的装饰器。比如 Flask 中：

from functools import wraps import time import logging def harness_middleware(prompt_name: str): def decorator(f): @wraps(f) def wrapper(*args, **kwargs): # 1. 加载并校验 System Prompt prompt = load_prompt(prompt_name) # 从 YAML 加载 try: validate_input(prompt.input_schema, kwargs) except ValidationError as e: return {"error": "INVALID_INPUT", "details": str(e)}, 400 # 2. 注入上下文 request_id = generate_request_id() trace_id = get_trace_id_from_header() or request_id context = { "request_id": request_id, "trace_id": trace_id, "start_time": time.time(), "caller_service": "frontend-h5" } # 3. 执行业务逻辑（此时 kwargs 已被校验） result = f(*args, **kwargs) # 4. 记录 harness 日志（供 Verification Loop 使用） logging.info(f"HARNESS_LOG|{prompt_name}|{request_id}|{trace_id}|{time.time()-context['start_time']:.3f}s|{result.get('status', 'unknown')}") return result return wrapper return decorator # 使用 @app.route("/api/v1/order", methods=["POST"]) @harness_middleware("create_order.v1") def create_order(): # 业务代码，只关注“做什么”，不关心“怎么做校验/埋点” return order_service.create(**request.json)

踩坑实录：我们最初把校验逻辑写在业务函数内部，导致同一个校验逻辑在 12 个接口里复制粘贴。后来统一抽成 middleware，但遇到新问题：某些接口需要特殊校验（如“仅限 VIP 用户”），而 middleware 是通用的。解决方案是：在 prompt.yaml 里增加custom_validators字段，指向一个 Python 函数名，middleware 动态加载执行。这样既保持通用性，又保留扩展性。

3.4 第四层：Verification Loop —— 你写的每一条监控告警，都该是闭环的一部分

Verification Loop 是 Harness Engineering 的“免疫系统”。它不满足于“调用成功”，而要主动验证“成功是否真实发生”。典型场景：

• 支付网关返回{"status": "success", "trade_no": "20240520..."}，但数据库里orders表没新增记录；
• 短信平台返回{"msg_id": "abc123"}，但运营商网关日志显示该 msg_id 被丢弃；
• 订单创建成功，但风控引擎的risk_score字段为空，说明风险评估未执行。

Loop 的实现分三步：

1. 定义校验点（Checkpoints）：在 prompt.yaml 中声明：

verification_loop: - name: "order_created_in_db" type: "sql" query: "SELECT COUNT(*) FROM orders WHERE trade_no = ?" expected: "1" timeout: 5000 # ms - name: "sms_delivered_to_carrier" type: "http" url: "https://carrier-api.com/status?msg_id={{.msg_id}}" expected_status: 200 expected_json_path: "$.status" expected_value: "DELIVERED"

2. 执行器（Executor）：用轻量级框架（如 Airflow DAG 或自研 Cron 服务）定时扫描 harness 日志，提取request_id和trace_id，按配置执行校验点；
3. 闭环动作（Action）：
   • 校验失败：自动创建工单（Jira）、发送告警（企业微信）、触发补偿任务（如重发短信、回滚库存）；
   • 校验成功：更新harness_status表，标记该次调用为“fully verified”。

经验之谈：Verification Loop 的价值，80% 在于“失败即报警”，20% 在于“成功即信任”。我们上线 Loop 后，第一次真实捕获到：支付网关返回 success，但因数据库主从延迟，从库读不到新订单，导致后续查询失败。Loop 在 3 秒后发现SELECT COUNT返回 0，立刻告警并触发重试。这个 bug 在旧模式下至少要等用户投诉才能发现。现在，它成了我们最信赖的“夜间守护者”。

4. 落地不是选工具，而是改流程——从需求评审到上线发布的 harness 化改造

Harness Engineering 的落地难点，从来不在技术，而在组织流程是否同步进化。我们服务过 7 家不同规模的公司，发现成功落地的共性是：把 harness 要求嵌入现有研发流程的每个环节，而不是另起炉灶搞一套“harness 团队”。以下是经过实战验证的四步改造法：

4.1 需求评审阶段：增加“harness 可行性”专项讨论

传统需求评审聚焦“功能是否做对”，Harness Engineering 要求增加一栏：“系统如何被安全接入？”

评审会必须回答以下问题，并记录在需求文档附件中：

• 该需求涉及哪些外部系统？它们的 System Prompt 文档链接是什么？（若无，谁负责本周内产出 v0.1）
• 新增或修改的接口，其 input/output schema 是否已用 JSON Schema/YAML 定义？是否已通过jsonschema校验？
• 该功能的 Verification Loop 校验点有哪些？（例如：用户注册成功后，是否校验邮箱验证码表有记录？是否校验风控引擎返回了 risk_score？）
• 若依赖的外部系统无 harness 能力（如老系统只提供裸 HTTP 接口），本项目是否承担“适配器开发”？工期如何预留？

实操案例：某金融客户做“跨境汇款”需求，原计划 2 周。评审时发现：合作银行只提供 SOAP 接口，无任何契约文档。我们当场决定：

• 第 1 天：用 SoapUI 抓包，逆向生成 WSDL 解析规则；
• 第 2 天：编写bank_adapter.py，封装为 harness-ready Tool，内置 XML 校验、重试、熔断；
• 第 3 天：定义verify_fund_transfer.v1.yaml，校验点包括“银行返回 ACK”“我方账务系统记账成功”“短信通知发送成功”。
  结果：需求延期 3 天，但上线后 0 跨境汇款失败，客服咨询量下降 95%。老板说：“这 3 天花得值。”

4.2 开发阶段：Git 提交规范强制 harness 约束

在pre-commit和 CI 流程中植入 harness 检查，让问题在提交前暴露：

• Commit Message 规范：必须包含harness:前缀，如harness: add sms_tool with retry logic；
• PR 检查项：
  1. 新增接口必须关联prompt/*.yaml文件；
  2. 修改接口必须更新对应 prompt.yaml 的 version 字段，并在 CHANGELOG.md 记录 breaking change；
  3. 所有调用外部系统的代码，必须使用 harness-ready Tool（禁止直连 HTTP/DB）；
  4. 新增的 Verification Loop 校验点，必须有对应测试用例（模拟失败场景）。

CI 脚本示例（.github/workflows/harness-check.yml）：

- name: Validate Prompt Schemas run: | for f in prompt/*.yaml; do yamllint "$f" python -c "import jsonschema, yaml; schema = yaml.safe_load(open('$f')); jsonschema.Draft7Validator.check_schema(schema)" done - name: Check Tool Usage run: | # 检查代码中是否出现 requests.post / pymysql.connect 等裸调用 grep -r "requests\.post\|pymysql\.connect\|urllib\.request" --include="*.py" . | grep -v "test_" || echo "✅ No raw HTTP/DB calls found"

注意事项：初期团队会抵触“多写 YAML、多跑检查”。我们的策略是：只对核心路径（支付、订单、用户）启用严格检查，非核心模块先灰度。用数据说话：上线 1 个月后，核心路径的参数类故障下降 82%，大家自然接受。

4.3 测试阶段：用 harness 替代 80% 的手工回归测试

Harness Engineering 让测试从“验证功能”升级为“验证契约”。我们取消了大部分手工回归测试，转而构建 harness 测试矩阵：

关键技巧：不要追求 100% 覆盖。聚焦“高频失败场景”。我们统计发现，80% 的线上故障源于 5 类输入：空值、超长字符串、非法枚举、时间戳格式错误、JSON 嵌套过深。针对这 5 类，用hypothesis库生成 fuzz 测试，效果远超手工用例。

4.4 上线发布阶段：harness 状态作为发布准入红线

发布前，必须满足以下 harness 状态指标，否则阻断发布：

• Prompt 合规率 ≥ 100%：所有上线接口的 prompt.yaml 已合并，且通过校验；
• Tool 使用率 ≥ 100%：代码扫描确认无裸调用；
• Verification Loop 健康度 ≥ 99.5%：过去 24 小时 Loop 执行成功率；
• harness 告警清零：当前无未关闭的 harness 相关告警（如“校验点超时”“重试次数超标”）。

发布后，自动执行：

• 将本次发布的 prompt.yaml、tool 版本、loop 配置打包为harness-bundle-v${VERSION}.tar.gz，存入制品库；
• 更新内部 Wiki 的 harness 文档，生成变更对比报告（diff）；
• 向 SRE 团队推送本次 harness 变更摘要，用于容量规划（如“新增短信校验点，预计每日增加 2000 次 HTTP 请求”）。

真实体会：当 harness 状态成为发布硬门槛后，开发同学会主动找 SRE 讨论：“这个新接口的 verification loop，要不要加数据库慢查询检测？我怕影响性能。”——这种跨职能的深度协同，正是 Harness Engineering 想达成的文化目标。

5. 别掉进“过度工程”陷阱——Harness Engineering 的三道实用边界线

Harness Engineering 的价值毋庸置疑，但实践中常见两种极端：一种是“完全不管，靠人肉救火”，另一种是“过度设计，写 1000 行 YAML 只为调用一个 Hello World 接口”。真正的高手，懂得在“足够好”和“刚刚好”之间划出清晰边界。我们用三条铁律守住底线：

5.1 边界一：只对“跨信任域”的交互做 harness，不碰内部模块

什么是“信任域”？简单说：同一团队、同一代码仓库、同一部署单元、同一监控体系下的组件，视为一个信任域。

• ✅ 必须 harness：调用支付网关（外部）、调用短信平台（SaaS）、调用合作方 API（第三方）；
• ✅ 建议 harness：调用公司内其他事业部的中台服务（如风控、实名认证），因其 SLA、演进节奏不可控；
• ❌ 不必 harness：调用本服务内的user_service.py、order_dao.py；调用同仓库的utils/date_helper.py。

理由很实在：内部模块的变更，你可以直接改代码、加日志、跑单元测试；而外部系统，你永远不知道它明天会不会把user_id字段改成uid，或者把200成功响应换成201。Harness 的核心价值，是应对“不可控的外部变化”，不是给内部代码加锁。

实操判断法：问自己一个问题：“如果这个调用失败，我能直接 SSH 登上去 debug 吗？” 如果答案是“不能”，那就需要 harness。

5.2 边界二：harness 的粒度，以“一次业务意图”为单位，而非“一个 HTTP 请求”

新手常犯错误：为每个 HTTP 接口单独写 prompt.yaml。结果一个“创建订单”业务，拆成 5 个 YAML 文件（库存扣减、价格计算、优惠券核销、风控校验、订单落库），维护成本爆炸。

正确做法：以用户视角的“一件事”为单位定义 harness。

• “创建订单”是一个 harness，它包含多个子步骤，但对外暴露单一入口和契约；
• “支付回调”是一个 harness，它接收微信/支付宝/银联三种格式，但统一转换为内部PaymentEvent对象；
• “用户注销”是一个 harness，它触发清理个人数据、解绑设备、关闭会话、发送通知等多个下游动作。

子步骤的细节（如“风控校验用哪个 API”）放在 harness 内部实现，不暴露给上游。上游只关心：“我传什么，得到什么，失败怎么办”。

经验之谈：我们曾为“直播秒杀”设计 harness，初期按 12 个系统拆成 12 个 prompt。上线后，每次风控策略调整，就要同步改 3 个 YAML、2 个 Tool、4 个 Loop 校验点。后来重构为单个live_seckill.v1.yaml，内部用状态机编排子步骤。现在风控改规则，只需更新harness_config/live_seckill/rules.json，5 分钟搞定。

5.3 边界三：Verification Loop 只校验“业务结果”，不校验“技术实现”

Loop 的目标是确认“用户要的效果达成了”，不是“代码按预期执行了”。

• ✅ 正确校验：

  • 支付成功后，orders表status = 'paid'；
  • 短信发送后，sms_log表delivered_at IS NOT NULL；
  • 用户注册后，users表is_active = true且email_verified = true。

• ❌ 错误校验：

  • 支付网关是否调用了https://pay-gateway.com/v2/charge（URL 可能变）；
  • 短信是否走了aliyun-sms而不是tencent-sms（供应商可切换）；
  • 用户注册是否调用了send_welcome_email()函数（内部实现可重构）。

关键原则：Loop 校验点必须基于业务数据库或第三方可信状态源，而不是日志、内存变量或临时文件。因为只有这些地方的数据，才是用户最终看到的结果。我们曾因校验“日志中是否出现 success 字样”导致误报——日志级别被调成 WARN，success 被过滤掉了，Loop 误判失败。改为查数据库后，再没出现过此类问题。

Harness Engineering 的本质，不是给系统加更多层，而是把原本散落在人脑、文档、脚本、日志里的隐性知识，沉淀为可执行、可验证、可演进的显性契约。它不承诺消灭所有故障，但能确保每次故障都成为一次可学习、可预防、可闭环的经验。当你下次听到“我们要做 Harness Engineering”，别再想它是什么新工具——想想你手头那个总在凌晨三点报警的接口，它的 System Prompt 写清楚了吗？它的 Tools 有重试吗？它的 Verification Loop 在默默守护吗？答案，就在你下一次 commit 里。