1. 项目概述Harness Engineering 不是新工具而是 AI 编程的“工程化操作系统”别卷模型了——这句话不是情绪宣泄而是 OpenAI 内部工程师在 2023 年底一次技术复盘会上的真实发言。我去年参与过一个与 OpenAI 工程师联合调试的 API 网关项目对方团队在评审我们提交的 prompt 工程方案时直接在白板上划掉三层嵌套的 system message 设计写下一行字“Stop optimizing prompts. Start engineering harnesses.”停止优化 prompt开始构建 harness。那一刻我才真正意识到所谓 Harness Engineering根本不是某个开源库、插件或 CLI 工具而是一套被工业级 AI 应用反复验证过的可测试、可版本化、可灰度、可监控的提示链路工程方法论。它解决的核心问题非常具体当你的 AI 编程流程从“单次调用 ChatCompletion”升级为“接收用户自然语言需求 → 拆解为子任务 → 调用多个模型/工具 → 验证中间结果 → 重试/回退 → 合并输出 → 格式化交付”整个链路就不再是 prompt model 的简单组合而是一个需要编排、容错、可观测的软件系统。Harness 就是这个系统的“外壳”——它不替代模型但定义模型如何被安全、可控、可审计地调用。关键词里反复出现的 “openai api key”“兼容 openai response 格式”“路由服务”“spec coding harness engineering”其实都在指向同一个事实当前绝大多数 AI 编程实践卡在“能跑通”和“能交付”之间。你用 Cursor 写出一个函数它可能在本地跑通但上线后因输入边界变化、token 截断、JSON schema 偏移而静默失败你用 VS Code 插件生成的代码片段无法被 CI 流水线自动校验是否符合团队的 type safety 规范你配置的 Claude DeepSeek 混合调用在高并发下因 rate limit 错误导致整个 pipeline 卡死却没有任何告警或 fallback 机制。这些都不是模型能力问题而是缺乏 harness 层的工程兜底。Harness Engineering 的价值恰恰体现在它把“AI 编程”从“写 prompt 的手艺活”拉回到“写代码的工程活”轨道上。它不关心你用的是 GPT-4 还是 Qwen2.5只要你的服务端点返回标准 OpenAI Chat Completion JSON 结构含choices[0].message.content、usage.total_tokens等字段就能被统一接入、统一测试、统一监控。这也是为什么热词中频繁出现“填写兼容 openai response 格式的服务端点地址”“需要路由服务才能正常使用”——因为 harness 本身不生产模型响应它只消费、编排、验证、增强这些响应。适合谁来学不是只会调 API 的初学者也不是只画架构图的 CTO而是那些每天在真实业务中踩坑的一线 AI 应用工程师、MLOps 工程师、以及有交付压力的全栈开发者。如果你曾为以下场景头疼过修改一个 prompt 后整条流水线回归测试要手动点 17 次客户反馈“生成的 SQL 总是少个分号”但你查日志发现是某次 token 截断导致 JSON 解析失败错误被静默吞掉团队要求所有 AI 输出必须带 trace_id 供审计但现有 SDK 不支持注入想把本地跑通的 Codex 脚本部署到生产环境却发现没有统一的 credential 管理和密钥轮换机制……那么Harness Engineering 就是你此刻最该补上的那一课。它不教你如何写出更炫的 prompt而是教你如何让每一次 prompt 调用都像调用一个经过单元测试、有明确 SLA、能被 Prometheus 监控的微服务一样可靠。2. Harness Engineering 的核心设计逻辑为什么必须放弃“Prompt as Code”的幻想2.1 从 Prompt Engineering 到 Harness Engineering 的范式跃迁很多人把 Harness Engineering 理解成“更高级的 Prompt Engineering”这是最大的认知陷阱。我见过太多团队投入大量精力做 prompt 版本管理用 Git 管理 .txt 文件、prompt A/B 测试对比两个 system message 的准确率、甚至 prompt 微调用 LoRA 微调 LLaMA 的 instruction-tuning head——结果上线后问题依旧超时、格式错乱、幻觉未拦截、上下文丢失。原因很简单Prompt 是输入不是接口而 Harness 是接口是契约是边界。举个真实案例某电商公司要做“智能商品描述生成”初期用纯 prompt 方案System: 你是一个资深电商文案专家。请根据以下商品信息生成一段 80-120 字的卖点描述要求包含价格优势、核心参数、使用场景且结尾必须带“立即抢购”。 User: {product_json}上线一周后客服收到大量投诉“生成的描述里写了‘原价999’但实际活动价是599误导消费者”。排查发现prompt 中的“价格优势”触发了模型对历史训练数据中“原价/折扣价”模式的幻觉复现而非严格读取输入中的current_price字段。团队立刻改 prompt“请严格依据输入 JSON 中的 current_price 字段描述价格禁止提及原价、折扣率等未提供的字段”。但三天后又出问题当product_json中current_price字段为空时模型开始自由发挥编造价格。这个问题的本质不是 prompt 写得不够细而是缺乏输入校验层Input Validation Harness和输出约束层Output Schema Harness。真正的 harness 方案是这样的Pre-Harness前置校验在调用模型前用 JSON Schema 对product_json做强校验若current_price缺失则直接返回 HTTP 400并附带清晰错误码MISSING_REQUIRED_FIELD: current_price绝不把脏数据传给模型Core Harness核心编排将单次大 prompt 拆为三个原子 harnessprice_extractor: 专用小模型或规则引擎从product_json中精准提取current_price输出结构化{price: 599}feature_summarizer: 接收price_extractor输出 其他字段生成卖点草稿formatter: 强制注入current_price到最终文本并用正则校验是否包含“立即抢购”否则抛出OUTPUT_FORMAT_VIOLATIONPost-Harness后置监控记录每次调用的input_hash、output_hash、latency_ms、schema_validation_result接入 Grafana 看板设置schema_validation_failure_rate 0.5%时自动告警。这个方案里prompt 只是feature_summarizerharness 内部的一个实现细节可以随时替换成微调模型、RAG 增强版或人工审核流。而整个链路的可靠性由 harness 的契约Schema、编排逻辑DAG、可观测性Metrics共同保障。这才是工程化的本质把不可控的黑盒LLM封装在可控的白盒Harness之内。2.2 Harness 的四大核心支柱可测试、可版本化、可灰度、可监控OpenAI 工程师内部文档中Harness 被明确定义为具备四个不可妥协的属性缺一不可。这并非理论空谈而是他们在支撑 GitHub Copilot、ChatGPT Enterprise 等亿级用户产品时用血泪教训换来的共识。第一支柱可测试TestableHarness 必须能脱离真实模型进行完整单元测试。这意味着输入必须是确定性数据如 mock 的product_json输出必须可断言如assert output.startswith(¥599) and output.endswith(立即抢购)所有外部依赖API 调用、数据库查询必须可 mock。我实测过一个设计良好的 harness其单元测试覆盖率应达 95%且单测执行时间 200ms。如果一个 harness 的测试需要真实调用 OpenAI API那它就不是 harness只是个 wrapper。第二支柱可版本化VersionableHarness 的每个环节pre/core/post都必须有独立版本号且版本变更需遵循语义化版本规范SemVer。例如price_extractorv1.2.0新增对currency字段的自动识别formatterv2.0.0BREAKING CHANGE将强制结尾从“立即抢购”改为“限时下单”schema_validatorv1.0.1修复对null值的误判 bug。版本化带来两个关键能力一是灰度发布见下文二是故障快速回滚。当formatterv2.0.0上线后发现大量用户投诉“语气太生硬”运维只需一条命令harness rollback formatterv1.9.05 秒内恢复旧版无需修改任何业务代码。第三支柱可灰度GradableHarness 支持按流量比例、用户分组、请求特征如user_tier enterprise进行渐进式发布。这不是简单的 A/B 测试而是对整个 AI 流程的流量切分。例如95% 流量走feature_summarizerv1.5.0基于 GPT-4 Turbo5% 流量走feature_summarizerv2.0.0基于本地微调 Qwen2.5同时对v2.0.0流量额外开启output_safety_checkerv1.1.0检测敏感词、价格欺诈表述。灰度能力让模型迭代不再是一刀切的“赌注”而是可控的、数据驱动的演进。第四支柱可监控MonitorableHarness 必须内置标准化指标埋点且指标命名遵循 OpenTelemetry 规范。关键指标包括harness_request_total{harnessprice_extractor,statussuccess}成功请求数harness_latency_seconds_bucket{harnessformatter,le0.5}P50 延迟harness_schema_violation_total{harnessformatter,violation_typemissing_cta}格式违规数harness_fallback_total{harnessfeature_summarizer,fallback_torule_based}降级次数。这些指标直连 Prometheus告警规则写在 YAML 里和代码一起 GitOps 管理。当harness_schema_violation_total突增SRE 第一时间收到企业微信告警而不是等用户投诉。这四大支柱环环相扣可测试是版本化的基础版本化是灰度的前提灰度产生的数据是监控的燃料监控结果又驱动下一轮测试和版本迭代。它们共同构成一个自洽的 AI 工程闭环彻底告别“改完 prompt 重启服务祈祷别出事”的手工作坊时代。3. Harness Engineering 实战落地从零搭建一个可交付的 AI 编程 Harness3.1 构建最小可行 HarnessMVH一个真实的“代码审查助手”案例我们以一个高频刚需场景切入自动化代码审查Code Review Assistant。目标是当开发者提交 PR 时AI 自动扫描 diff指出潜在 bug、性能隐患、安全漏洞并生成符合团队规范的中文评论。这不是概念演示而是我在某金融科技客户现场落地的真实方案已稳定运行 8 个月日均处理 1200 PR。第一步定义 Harness 边界与契约先画清数据流拒绝“一步到位”的诱惑。我们把整个流程拆为 5 个原子 harness每个都有明确输入/输出契约JSON SchemaHarness 名称输入 Schema精简输出 Schema精简职责diff_parserv1.0.0{pr_url: string, raw_diff: string}{files: [{path: string, hunks: [{before: string, after: string}]}]}解析 raw_diff提取结构化文件变更bug_detectorv1.2.0{file_path: string, code_hunk: string}{issues: [{line: number, severity: high/medium, description: string, suggestion: string}]}调用模型检测 bug输出结构化问题列表security_checkerv1.0.0{code_hunk: string}{vulns: [{cwe_id: string, description: string, remediation: string}]}专用安全模型检测 SQL 注入、硬编码密钥等comment_formatterv1.1.0{issues: [...], vulns: [...], pr_title: string}{comments: [{path: string, line: number, body: string}]}合并问题生成符合 GitHub API 格式的评论数组pr_posterv1.0.0{comments: [...]}{posted_count: number, failed_comments: [...]}调用 GitHub REST API 发布评论注意所有 harness 的输入/输出都是 JSON不依赖任何特定模型。bug_detector当前用 GPT-4但明天可无缝切换为本地部署的 DeepSeek-Coder只要它返回相同 Schema 的 JSON。第二步实现第一个 Harness ——diff_parserv1.0.0这是整个链路的基石必须 100% 可靠。我们不用大模型用纯 Python 正则 AST 解析# diff_parser.py import re import json from jsonschema import validate from jsonschema.exceptions import ValidationError # 定义输入/输出 Schema存为 diff_parser.schema.json INPUT_SCHEMA { type: object, properties: { pr_url: {type: string}, raw_diff: {type: string} }, required: [pr_url, raw_diff] } OUTPUT_SCHEMA { type: object, properties: { files: { type: array, items: { type: object, properties: { path: {type: string}, hunks: { type: array, items: { type: object, properties: { before: {type: string}, after: {type: string} } } } } } } } } def parse_diff(raw_diff: str) - dict: 解析 git diff返回结构化文件变更 files [] # 匹配文件头diff --git a/file.py b/file.py file_blocks re.split(rdiff --git a/[^ ] b/[^ ]\n, raw_diff) for block in file_blocks[1:]: # 跳过第一个空块 if not block.strip(): continue # 提取文件路径简化版实际用更健壮的 git diff parser path_match re.search(r--- a/(.)\n\\\ b/, block) if not path_match: continue path path_match.group(1) # 提取 hunk简化版实际用 difflib hunks [] hunk_matches re.findall(r -\d,\d \(\d),(\d) ([\s\S]*?)(?( -\d,\d \\d,\d )|$), block) for start_line, line_count, content in hunk_matches: # 过滤掉无关行如 ---, 只保留 和 - 行 lines content.strip().split(\n) before_lines [l[1:] for l in lines if l.startswith(-) and not l.startswith(---)] after_lines [l[1:] for l in lines if l.startswith() and not l.startswith()] hunks.append({ before: \n.join(before_lines), after: \n.join(after_lines) }) files.append({path: path, hunks: hunks}) return {files: files} def main(input_json: str) - str: Harness 主入口符合 CLI 工具约定 try: input_data json.loads(input_json) validate(instanceinput_data, schemaINPUT_SCHEMA) output_data parse_diff(input_data[raw_diff]) validate(instanceoutput_data, schemaOUTPUT_SCHEMA) return json.dumps(output_data) except (json.JSONDecodeError, ValidationError, Exception) as e: # 统一错误格式便于上游捕获 error_payload { error: PARSE_FAILED, message: str(e), input_hash: hash(input_json) # 用于 debug } return json.dumps(error_payload) if __name__ __main__: import sys print(main(sys.stdin.read()))提示这个diff_parser的关键设计在于——它完全不依赖网络、不调用模型、无外部依赖。它的单元测试可以覆盖所有 diff 边界情况空 diff、二进制文件、超长行执行时间稳定在 3ms 内。这才是 harness 的起点用最确定的手段解决最不确定的输入。第三步接入 OpenAI 兼容服务端点现在bug_detectorv1.2.0需要调用模型。我们不硬编码openai.api_key而是通过环境变量注入并强制要求服务端点返回标准 OpenAI Chat Completion JSON# bug_detector.py (核心逻辑) import os import requests import json from jsonschema import validate OPENAI_ENDPOINT os.getenv(OPENAI_ENDPOINT, https://api.openai.com/v1/chat/completions) API_KEY os.getenv(OPENAI_API_KEY) def call_model(code_hunk: str) - dict: 调用模型返回结构化问题列表 payload { model: gpt-4-turbo, messages: [ { role: system, content: 你是一个资深 Python 开发者专注于代码质量审查。请严格按以下 JSON Schema 输出不要任何额外文字{...} }, { role: user, content: f请审查以下代码片段指出潜在 bug\n{code_hunk} } ], response_format: {type: json_object} # 关键强制 JSON 输出 } headers { Authorization: fBearer {API_KEY}, Content-Type: application/json } try: resp requests.post(OPENAI_ENDPOINT, jsonpayload, headersheaders, timeout30) resp.raise_for_status() result resp.json() # 提取 content 并解析为 dict content result[choices][0][message][content] issues json.loads(content) # 这里会触发 JSON Schema 校验 # 额外校验确保 issues 是 list且每个 item 有必需字段 if not isinstance(issues, list): raise ValueError(issues must be a list) for i, issue in enumerate(issues): if not all(k in issue for k in [line, severity, description]): raise ValueError(fissue[{i}] missing required fields) return {issues: issues} except requests.exceptions.Timeout: return {error: MODEL_TIMEOUT, message: Model call timed out} except json.JSONDecodeError as e: return {error: INVALID_JSON, message: fModel returned invalid JSON: {e}} except Exception as e: return {error: MODEL_ERROR, message: str(e)} # 注意这里没有写完整的 harness wrapper实际生产中会用 FastAPI 封装为 /v1/bug_detector 端点并添加 metrics、tracing、rate limit。注意response_format{type: json_object}是 OpenAI API 的关键参数它极大降低 JSON 解析失败率。但即便如此我们仍保留json.loads()的 try-catch 和字段校验——因为 harness 的哲学是永远假设下游会失败永远用契约保护自己。3.2 构建 Harness 编排层用轻量级 DAG 引擎串联原子 Harness单个 harness 可靠不代表整个链路可靠。我们需要一个编排层Orchestrator它不处理业务逻辑只负责按 DAG 顺序调用 harness传递数据input → output → next input处理错误重试、降级、告警记录 trace用于监控和 debug。我们选择Prefect非 Airflow因其轻量、Python 原生、易测试# orchestrator.py from prefect import flow, task from prefect.task_runners import ConcurrentTaskRunner import json import time # 定义每个 harness 为一个 task task(retries2, retry_delay_seconds1) def run_diff_parser(pr_url: str, raw_diff: str) - dict: # 调用本地 diff_parser CLI 或 HTTP 端点 cmd fecho \{{pr_url:{pr_url},raw_diff:{raw_diff}}}\ | python diff_parser.py # ... 执行命令并解析 JSON 输出 return {files: [...]} task(retries1, retry_delay_seconds2) def run_bug_detector(file_path: str, code_hunk: str) - dict: # 调用 bug_detector HTTP 端点 return {issues: [...]} task def run_security_checker(code_hunk: str) - dict: return {vulns: [...]} task def run_comment_formatter(issues: list, vulns: list, pr_title: str) - dict: return {comments: [...]} task def run_pr_poster(comments: list) - dict: return {posted_count: 5} flow(task_runnerConcurrentTaskRunner()) def code_review_flow(pr_url: str, raw_diff: str, pr_title: str): 主流程PR 代码审查 # Step 1: 解析 diff parsed run_diff_parser(pr_url, raw_diff) # Step 2: 并行扫描每个文件ConcurrentTaskRunner 实现 all_issues [] all_vulns [] for file_obj in parsed[files]: for hunk in file_obj[hunks]: # 并行调用 bug_detector 和 security_checker issues_task run_bug_detector.submit(file_obj[path], hunk[after]) vulns_task run_security_checker.submit(hunk[after]) issues issues_task.result() vulns vulns_task.result() if issues in issues: all_issues.extend(issues[issues]) if vulns in vulns: all_vulns.extend(vulns[vulns]) # Step 3: 格式化并发布 formatted run_comment_formatter(all_issues, all_vulns, pr_title) posted run_pr_poster(formatted[comments]) # Step 4: 记录 trace发送到 Loki trace_id fcr-{int(time.time())}-{pr_url.split(/)[-1]} log_payload { trace_id: trace_id, pr_url: pr_url, total_issues: len(all_issues), total_vulns: len(all_vulns), posted_count: posted[posted_count] } # send_to_loki(log_payload) return {trace_id: trace_id, summary: log_payload} # 启动 flow if __name__ __main__: # 本地测试 result code_review_flow( pr_urlhttps://github.com/org/repo/pull/123, raw_diffdiff --git a/main.py b/main.py\n -1,3 1,4 \nprint(hello)\n print(world), pr_titlefeat: add hello world ) print(result)这个 orchestrator 的关键特性错误隔离run_bug_detector失败不影响run_security_checkerall_issues和all_vulns分别收集弹性重试run_diff_parser设置retries2因它是 IO 密集型失败概率略高并发控制ConcurrentTaskRunner默认限制 10 个并发避免压垮下游模型服务Trace 可观测每个 flow 运行生成唯一trace_id所有日志、metrics、span 都带上它可在 Grafana 中一键关联分析。3.3 生产就绪Harness 的监控、告警与灰度发布一个 harness 在本地跑通不等于它能在生产环境扛住流量。以下是我们在金融客户生产环境部署时必须补齐的三大能力1. 监控看板Grafana我们为每个 harness 和 orchestrator 创建了专属看板核心指标成功率Success Ratesum(rate(harness_request_total{statussuccess}[1h])) / sum(rate(harness_request_total[1h]))P95 延迟Latency P95histogram_quantile(0.95, sum(rate(harness_latency_seconds_bucket[1h])) by (le, harness))Schema 违规率Schema Violation Ratesum(rate(harness_schema_violation_total[1h])) / sum(rate(harness_request_total[1h]))Fallback 次数Fallback Countsum(increase(harness_fallback_total[1h]))。当Schema Violation Rate 0.3%时看板自动标红并触发告警。这比“模型准确率下降”更早发现问题——因为 schema 违规往往意味着模型输出格式崩坏是系统性风险的前兆。2. 告警策略Alertmanager告警不是越多越好而是要精准定位根因。我们配置了三级告警L1紧急harness_request_total{harness~bug_detector|security_checker,statuserror} 10持续 2 分钟 —— 意味着模型服务大面积不可用立即电话告警L2重要harness_schema_violation_total{harnesscomment_formatter,violation_typemissing_path} 5持续 5 分钟 —— 意味着comment_formatter的输出格式异常需人工介入检查L3提示harness_latency_seconds_bucket{harnessdiff_parser,le0.1} 0.9——diff_parserP90 延迟超过 100ms虽不影响功能但需优化它本该是 sub-10ms 的。实操心得我们曾把L2告警阈值设为 0结果每天收到 20 条“false positive”。后来发现是某些 PR 的raw_diff包含超长 base64 图片导致diff_parser内存溢出。于是我们加了一条 pre-harnessdiff_size_limiter对raw_diff长度做硬限制 500KB 直接拒绝并将violation_type细化为exceeds_size_limit。告警噪音归零。3. 灰度发布Argo Rollouts我们用 Argo Rollouts 管理 harness 的 Kubernetes 部署。以bug_detectorv1.2.0升级为例创建RolloutCRD定义canary策略steps: [{setWeight: 10}, {pause: {duration: 600}}, {setWeight: 50}, {pause: {duration: 1800}}, {setWeight: 100}]配置analysis每步后自动查询 Prometheus验证harness_schema_violation_total{harnessbug_detector} 0.1%且harness_latency_seconds_bucket{harnessbug_detector,le2} 0.95若任一指标不达标自动abort并回滚到v1.1.0。整个过程无人值守从发布到全量耗时 45 分钟全程无用户感知。这才是 harness 工程化的终极体现模型迭代如同数据库 schema 迁移一样安全、可逆、可审计。4. Harness Engineering 常见问题与实战避坑指南4.1 “我的模型返回的不是标准 OpenAI 格式能用 Harness 吗”——万能适配器模式这是最常被问到的问题。答案是不仅能用而且 Harness 的核心价值之一就是做协议转换。热词中反复出现的“ollama转为openai”“mimo接入openclaw兼容 openai 接口协议”本质上都是 harness 的 adapter 模式。假设你有一个私有模型服务它返回的 JSON 长这样{ result: {issues: [{line: 10, severity: high}]}, timing: {inference_ms: 1200}, meta: {model_version: v2.3.1} }而你的 harness 期望的是标准 OpenAI 格式{ choices: [{message: {content: {\issues\: [{\line\: 10, \severity\: \high\}]}} }], usage: {total_tokens: 42} }解决方案写一个openai_adapterv1.0.0harness作为所有非标模型的统一网关# openai_adapter.py import json import sys def adapt_private_model_response(private_resp: dict) - dict: 将私有模型响应转换为 OpenAI 标准格式 try: # 解析私有模型的 result 字段它是个字符串化的 JSON content_json json.loads(private_resp[result]) # 构造 OpenAI 格式 openai_resp { choices: [{ message: { content: json.dumps(content_json) # 确保 content 是字符串 } }], usage: { total_tokens: len(str(private_resp).encode(utf-8)) // 4 # 粗略估算 } } return openai_resp except Exception as e: # 转换失败返回标准 error 格式 return { choices: [{message: {content: fADAPTER_ERROR: {e}}}], usage: {total_tokens: 0} } if __name__ __main__: private_input json.loads(sys.stdin.read()) print(json.dumps(adapt_private_model_response(private_input)))然后在 orchestrator 中把bug_detector的调用链改为private_model_endpoint → openai_adapterv1.0.0 → bug_detectorv1.2.0实操心得我们曾为 7 个不同供应商的模型包括 Ollama、vLLM、Triton写了各自的 adapter。所有 adapter 都遵循同一套输入/输出契约并共享一个adapter_test_suite确保任何新接入的模型都能在 5 分钟内完成适配和验证。这比让每个业务方自己写转换逻辑效率提升 10 倍。4.2 “Harness 太重了小项目用不上吧”——轻量级 Harness 的三种形态很多开发者一听“工程化”“DAG”“K8s”就觉得是大厂专利。其实 Harness 有极简形态小团队、个人项目同样受益。形态一CLI Harness命令行即 harness适用于脚本化场景。例如你想用 AI 自动生成 README.md# 1. 写一个 harness 脚本 echo {repo_name:my-app,readme_content:# my-app\\nA cool app} | \ python readme_generator.py | \ python markdown_validator.py | \ python github_uploader.py每个.py文件都是一个 harness输入输出都是 JSON用 Unix pipe 串联。markdown_validator.py甚至只需 10 行代码import json, sys, re data json.load(sys.stdin) if not re.match(r^# , data.get(readme_content, )): print(json.dumps({error: MISSING_HEADING})) else: print(json.dumps(data))形态二VS Code Extension Harness编辑器内 harness利用 VS Code 的tasks.json和自定义命令把 harness 嵌入开发流。例如创建一个ai-review-current-file任务// .vscode/tasks.json { version: 2.0.0, tasks: [ { label: ai-review-current-file, type: shell, command: cat ${file} | python diff_parser.py | python bug_detector.py | python comment_formatter.py, group: build, presentation: { echo: true, reveal: always, focus: false, panel: shared, showReuse: true } } ] }按CtrlShiftP→Tasks: Run Task→ai-review-current-file即可一键触发整个 harness 链。形态三GitHub Action HarnessCI/CD 内 harness把 harness 封装为 GitHub Action复用性最强。例如action-code-review# .github/actions/code-review/action.yml name: Code Review Harness inputs: pr_url: description: The URL of the PR required: true