1. Harness 不是新名词而是 AI 工程里被长期忽视的“承重墙”你打开 GitHub 搜索harness大概率会看到一堆 CI/CD 流水线配置、Kubernetes 的 Helm Harness 插件或者某个硬件测试框架——这恰恰是问题所在Harness 在 AI 领域根本不是新概念而是被强行“借名”、又被严重误读的工程实践代号。它既不是模型也不是框架更不是某种神秘中间件。我第一次在 DeepSeek 内部文档里看到harness这个词时以为是某个新 SDK 的缩写结果发现它只是指代“把 LLM 调用封装成可复用、可监控、可灰度的最小执行单元”的整套约定和脚手架。它不解决推理本身但决定了你写的llm.invoke()是不是能扛住每秒 200 次并发、能不能自动 fallback 到备用模型、有没有记录完整 trace 供 debug——这些事90% 的 Agent 教程里都跳过不讲却恰恰是上线后最要命的部分。关键词里反复出现的deepseek harness、harness engineering、harness anything其实都在指向同一个事实当 LLM 调用从 demo 阶段进入生产阶段你就必须给它加一层“工程化外壳”而这个外壳业内就叫 harness。它和 Agent 的关系不是父子而是“钢筋”和“房子”和 Skill 的关系不是包含而是“供电接口”和“电器”和 LLM 的关系更不是替代而是“遥控器”和“电视”。很多人一上来就学 LangChain 的 AgentExecutor却连底层LLM实例连超时重试都没配好结果就是本地跑通一上压测就 timeout单次调用正常批量请求就返回空 JSON日志里全是{error: model overloaded}却找不到源头——这些都不是模型问题是 harness 缺位导致的工程塌方。我去年帮一家做金融问答的团队重构 Agent 架构他们原来的代码里llm OpenAI(modelgpt-4-turbo)直接 new 出来就用没有熔断、没有降级、没有输入长度校验。结果客户一上传 50 页 PDFLLM 就因 context overflow 返回乱码前端直接崩溃。我们没动模型只加了一层 harness输入预检截断摘要、输出 schema 强校验用 Pydantic V2 做 JSON 结构约束、失败自动 fallback 到 gpt-3.5-turbo 重试指数退避。上线后错误率从 17% 降到 0.3%而开发量只增加了 200 行代码。这就是 harness 的真实价值它不让你的模型更聪明但让你的模型更可靠、更可控、更像一个工业级服务。如果你正在查harness 和 agent 区别答案很简单Agent 是业务逻辑编排器Harness 是 LLM 调用的“工业控制器”。提示不要被harness这个词迷惑。它不是 DeepSeek 独创也不是某家公司的私有协议。它本质是 SRE站点可靠性工程思想在 LLM 调用层的落地——就像你不会裸写socket.connect()去发 HTTP 请求而是用 Requests 库同理你不该裸写llm.invoke()而该用 harness 封装后的llm_call()。2. Harness 的四根支柱为什么它必须独立于 Agent 和 Skill 存在Harness 的核心价值恰恰在于它的“低存在感”——它不该出现在你的业务代码里而应像空气一样弥漫在所有 LLM 调用周围。要理解它为何不能被 Agent 或 Skill 吞并必须拆解它的四个不可替代的工程支柱。这四根支柱共同构成了 LLM 生产化落地的底线保障缺一不可。2.1 输入治理不是简单的 prompt 拼接而是“防爆安检”绝大多数教程教你把用户 query 和 system prompt 拼成字符串丢给 LLM这在 demo 阶段可行但在生产环境等于埋雷。Harness 的第一道防线就是输入治理。它包含三个硬性动作长度预检与动态截断LLM 的 context 窗口是硬限制。Harness 必须在调用前计算len(system_prompt) len(user_query) len(retrieved_docs)若超限不能简单粗暴地 truncate而要按语义重要性分层裁剪。比如金融问答中监管条款原文优先级 用户历史对话 通用说明。我们实测过用textwrap.shorten()粗暴截断准确率下降 23%而用基于 sentence-transformers 的相似度排序后保留 top-k 句子准确率仅降 1.8%。敏感内容过滤与脱敏不是靠关键词黑名单漏报率高而是用轻量级 NER 模型如 spaCy 的 en_core_web_sm实时识别 PII姓名、身份证号、银行卡号。识别到后不是直接拒绝而是替换为占位符PERSON_1、ID_NUMBER_2并在后续 prompt 中明确告知模型“以下PERSON_X代表需保护的隐私实体请勿生成其具体值”。这样既合规又不影响推理逻辑。格式标准化与 Schema 注入很多团队卡在修复 llm 返回 json 的 java 库这个需求上根源在于没在输入端就强制结构。Harness 会在拼接 prompt 时自动注入严格的 output schema 指令例如请严格按以下 JSON Schema 输出字段名、类型、必填项均不可更改 {type: object, properties: {answer: {type: string}, confidence: {type: number, minimum: 0, maximum: 1}}, required: [answer, confidence]}并配套使用json_repair库Python或json-schema-validatorJava做输出后校验。这比在 Java 层写一堆 try-catch 解析异常高效得多。注意输入治理必须发生在 Agent 编排之前。如果 Agent 自己做截断不同 Skill 可能重复处理如果 Skill 自己做脱敏同一份用户数据在多个 Skill 里被多次识别性能浪费且规则不一致。Harness 是唯一能统一管控输入的地方。2.2 调用控制超时、重试、熔断一个都不能少LLM API 不是数据库它是网络服务有抖动、有排队、有不可预测的延迟。裸调用llm.invoke()的默认行为是无超时等死、无重试一次失败就崩、无熔断雪崩。Harness 必须接管这三层控制分级超时策略不是设一个全局 timeout。我们按场景分三级fast如单轮问答总 timeout ≤ 8s其中 LLM 推理 ≤ 5s网络传输 ≤ 3smedium如多步推理总 timeout ≤ 30s允许 LLM 推理 ≤ 20sslow如长文档摘要总 timeout ≤ 120s但必须开启 streaming每 5s push 一次 chunk。 这些阈值不是拍脑袋定的而是基于历史 P95 延迟 20% buffer 计算得出。例如某模型 P95 延迟是 4.2s则fast场景 timeout 设为 8s。智能重试机制不是简单 retry(3)。Harness 会根据 error code 分类重试429 Too Many Requests指数退避1s, 2s, 4s503 Service Unavailable立即重试服务瞬时过载500 Internal Error不重试直接 fallbackJSON decode error不重试触发 schema 修复流程。 关键是重试时会自动修改seed参数如果模型支持避免重复返回相同错误结果。熔断器Circuit Breaker当连续 5 次调用失败率 60%Harness 自动打开熔断器后续请求直接返回 fallback 响应如缓存答案、兜底话术持续 30 秒后半开试探。这能防止一个模型故障拖垮整个 Agent 流程。我们曾在线上观察到某天 Azure OpenAI 的 us-east 区域因网络抖动失败率飙升至 92%熔断器生效后整体服务可用性保持在 99.95%而未启用熔断的旧服务直接雪崩。2.3 输出契约让 LLM 的“胡言乱语”变成可验证的合同LLM 的不确定性是双刃剑。Harness 不压制这种不确定性而是把它框进可验证的契约里。这包括三重保障Schema 强校验如前所述不是靠正则匹配answer: .*?而是用 JSON Schema 定义字段类型、范围、嵌套关系。Harness 调用后用jsonschema.validate()校验不通过则触发修复或 fallback。我们统计过对{answer: string, steps: [string]}这样的简单 schemaLLM 直接输出合规 JSON 的概率约 68%加入 harness 的 schema 注入 修复后提升至 99.2%。语义一致性检查Schema 只管格式不管逻辑。Harness 会额外运行轻量级检查如果 prompt 要求“用中文回答”输出含英文单词 3 个则标记为不一致如果要求“列出 3 点”输出数组长度 ≠ 3 则标记如果要求“比较 A 和 B”输出中未同时出现 A 和 B 的关键词则标记。 这些规则用 spaCy 的 rule-based matcher 实现耗时 5ms却能拦截 12% 的“格式正确但逻辑错误”输出。置信度锚定Confidence AnchoringLLM 不会告诉你它有多不确定。Harness 会在 prompt 中强制要求输出confidence字段并用以下方式校准对于分类任务confidence softmax 输出的最大概率对于生成任务confidence 1 - (perplexity / max_perplexity)其中 perplexity 由小模型如 distilbert-base-uncased对生成文本打分。 这样下游 Agent 就能根据 confidence 值决定是否需要 human-in-the-loop而不是盲目信任 LLM。2.4 可观测性没有 trace 的 LLM 调用等于盲人开车Agent 的 debug 之所以痛苦是因为你不知道哪一步 LLM 调用出了问题。Harness 必须提供开箱即用的可观测性这是它区别于普通 wrapper 的关键全链路 Trace ID 注入每个 harness 调用生成唯一 trace_id并透传给 LLM作为 system prompt 的一部分“本次会话 trace_id: xxx”。当 LLM 输出中包含 trace_id就能反向关联到原始请求。我们曾用此定位到一个 bug某 Skill 在处理长文本时因截断逻辑错误将 trace_id 截断导致日志无法关联排查耗时 8 小时。结构化日志不记录 raw prompt太长且含敏感信息而是记录{ trace_id: xxx, model: gpt-4-turbo, input_tokens: 1240, output_tokens: 321, latency_ms: 4821, status: success, confidence: 0.87, fallback_used: false }这些字段直接接入 Prometheus Grafana可实时监控 token 效率、延迟分布、fallback 率。采样式 Prompt 日志为平衡安全与 debug 需求Harness 默认不记 full prompt但按 1% 概率采样记录并自动脱敏替换 PII 为MASKED。线上出问题时可快速检索采样日志还原现场。这四根支柱共同定义了 harness 的边界它不关心 Agent 怎么编排 Skill也不规定 Skill 该实现什么业务逻辑它只专注一件事——确保每一次 LLM 调用都是一个符合工程标准的、可度量、可追溯、可恢复的服务调用。把它塞进 Agent 里Agent 会臃肿失控把它塞进 Skill 里Skill 会职责混乱。它必须是独立的、基础设施级的 layer。3. Harness 与 Agent不是谁包含谁而是“供电系统”与“智能家电”的协作关系网上大量讨论harness 和 agent 区别甚至有人画出层级图说 “Agent 包含 Harness”这完全颠倒了因果。正确的理解是Agent 是消费 harness 的客户端Harness 是为 Agent 提供稳定电力的电网。这个比喻不是修辞而是精确的技术映射。下面用一个真实电商客服 Agent 的例子拆解它们如何协作。3.1 Agent 的典型工作流它只负责“决策”不负责“执行细节”假设用户问“我上周买的 iPhone 15屏幕碎了能免费换吗” 一个标准 Agent 的工作流如下意图识别调用 Skill Aintent_classifier输入用户 query输出{intent: warranty_claim, confidence: 0.92}信息抽取调用 Skill Bentity_extractor输入 query 上步结果输出{product: iPhone 15, issue: screen broken, purchase_date: 2024-05-10}政策查询调用 Skill Cpolicy_retriever输入 product issue从知识库召回相关条款决策生成调用 Skill Ddecision_generator输入 policy purchase_date生成回复“根据您的购买日期2024-05-10iPhone 15 屏幕碎裂不在免费保修范围内但可享受 8 折维修服务……”。注意在这个流程里Agent 只做两件事——决定下一步调哪个 Skill以及把上一步的输出喂给下一步的输入。它不关心 Skill A 的模型是什么、超时设多少、返回的 JSON 是否合法。这些全部交给 harness 处理。3.2 Harness 如何在每个环节默默支撑以 Skill A 为例当 Agent 决定调用 Skill Aintent_classifier时它实际发出的不是llm.invoke(prompt)而是harness.call(skill_nameintent_classifier, input_data...)。此时 harness 承担全部执行细节输入准备harness 拿到input_data即用户 query先做长度检查query 长度 28 个 token远低于 gpt-3.5-turbo 的 16k 上限通过再做敏感过滤未识别到 PII通过最后注入 schema 指令“请严格按 {intent: string, confidence: number} 输出 JSON”。调用执行harness 构造最终 prompt设置 timeout8s启动熔断器当前失败率 0.1%闭合状态发起调用。3.2s 后收到响应{intent: warranty_claim, confidence: 0.92}。输出校验harness 用预设 schema 校验字段齐全、类型正确再运行语义检查prompt 要求输出 intent响应中有要求 confidence 是 number响应中是 0.92通过置信度锚定显示 0.92 与模型 softmax 输出一致。可观测性harness 记录日志{skill: intent_classifier, latency_ms: 3200, status: success, confidence: 0.92}并上报 trace_id。Agent 收到的只是一个干净的、带 confidence 的 dict它无需知道背后发生了什么。如果这一步 harness 检测到输出不合规比如返回了{intent: warranty, confidence: high}它会自动触发修复把 high 转为 0.8或 fallback调用备用小模型然后仍返回标准 dict 给 Agent。Agent 的代码完全不用改。3.3 当 harness 缺位时Agent 的“崩溃现场”我们曾接手一个故障频发的 Agent它的代码类似这样# 错误示范Agent 自己管理 LLM 调用 def classify_intent(query): prompt f识别用户意图{query}。只输出 JSON如 {{intent: order_status, confidence: 0.85}} response openai.ChatCompletion.create( modelgpt-3.5-turbo, messages[{role: user, content: prompt}] ) return json.loads(response.choices[0].message.content)问题立刻暴露某天 OpenAI API 延迟飙升到 15sAgent 线程全部卡死HTTP 超时返回 504用户 query 含手机号LLM 在输出中直接回显触发 GDPR 报警LLM 偶尔返回{intent: warranty_claim, confidence: very high}json.loads()报错Agent 进程 crash日志只有ERROR: Expecting value: line 1 column 1 (char 0)无法定位是哪个 query 导致。这些问题100% 是因为 Agent 试图自己扮演 harness 的角色却缺乏工程化能力。修复方案不是重写 Agent而是剥离所有openai.ChatCompletion.create()替换成harness.call(intent_classifier, query)。一行代码替换问题全消。提示判断一个项目是否需要独立 harness就看它的 Agent 代码里有没有出现openai.、anthropic.、ollama.这样的直接调用。如果有它就还没准备好上生产。4. Harness 与 Skill不是容器与插件而是“标准化插座”与“可插拔电器”的物理接口Skill技能这个词在 AI 社区被过度浪漫化了。很多人以为 Skill 是某种高级抽象能自动学习、自我进化。实际上在工程视角下Skill 就是一个封装了特定业务逻辑的函数而 Harness 就是给这个函数提供标准电源和保险丝的插座。它们的关系是物理世界里最朴素的接口契约。4.1 Skill 的本质一个有明确定义 I/O 的黑盒函数一个合格的 Skill必须满足三个硬性条件否则它就不是 Skill只是段杂乱代码清晰的输入契约Input ContractSkill 必须声明它接受什么类型的输入。例如policy_retrieverSkill 的输入是class PolicyInput(BaseModel): product: str # 必填字符串 issue: str # 必填字符串 country: str CN # 可选默认 CNHarness 在调用前会用 Pydantic 验证输入是否符合此契约。如果传入{product: 123, issue: screen broken}harness 直接拒绝返回ValidationError不浪费一次 LLM 调用。稳定的输出契约Output ContractSkill 必须承诺返回什么。例如decision_generator的输出是class DecisionOutput(BaseModel): answer: str action_required: Literal[none, contact_support, schedule_repair] estimated_cost: Optional[float] NoneHarness 调用后强制校验返回值是否符合此模型。不符合触发修复或 fallback。可声明的元数据MetadataSkill 必须告诉 harness 它的“电气参数”skill_metadata { name: decision_generator, model: gpt-4-turbo, timeout_ms: 30000, max_input_tokens: 8000, requires_rag: True # 是否需要检索增强 }Harness 根据这些元数据自动配置调用参数、决定是否启用 RAG pipeline、设置超时。这才是 Skill 的真相它不是魔法而是一个有说明书、有额定功率、有接口标准的工业零件。Harness 就是那个确保所有零件都能插进同一块电路板的标准化插座。4.2 Harness 如何统一管理异构 Skill从codex skill到仓颉skill现实中的 Skill 来源五花八门有的是调用 OpenAI APIcodex skill有的是调用本地 Llama 3仓颉skill有的是调用微调的小模型impeccable skill还有的是调用传统规则引擎workbuddy skill。Harness 的核心能力就是抹平这些差异让 Agent 无感调用。我们以codex skill调用 OpenAI和仓颉skill调用本地 Qwen2-7B为例看 harness 如何统一维度codex skill仓颉skillHarness 的统一动作调用协议HTTPS REST APIOllama REST APIharness 封装统一call()方法内部路由到不同 client认证方式Bearer TokenBasic Authharness 从密钥管理服务如 HashiCorp Vault按 skill name 获取对应凭证超时设置全局 10s全局 30s本地推理慢harness 读取 skill metadata 中的timeout_ms动态设置输入预处理需要添加 system prompt需要添加 chat templateharness 根据model_familyopenai / ollama / vllm自动注入对应模板输出后处理直接返回response.choices[0].message.content返回response.responseharness 统一提取output_text字段并做 schema 校验关键点在于Agent 调用harness.call(codex_skill, input)和harness.call(cangjie_skill, input)代码完全一样。Harness 根据 skill name 查找 metadata自动适配底层差异。这解决了agent evals中最大的痛点——评估不同 Skill 时要写 N 套适配代码。有了 harnesseval 脚本只需遍历 skill list统一调用即可。4.3 “skill原版无删减版百度”背后的工程真相搜索热词里出现的skill原版无删减版百度折射出一个普遍现象很多团队把 Skill 当成黑盒下载包直接集成却忽略其工程兼容性。一个未经 harness 封装的 “原版 Skill”往往意味着无超时控制可能卡死数分钟无错误处理API 失败直接抛异常Agent 崩溃无可观测性不知道它调用了几次、花了多久、成功率多少无安全防护输入未过滤输出未校验风险敞口大。所谓“无删减版”其实是“无工程加固版”。真正的生产级 Skill必须经过 harness 的“出厂检验”注入超时、添加熔断、绑定 trace、校验 schema。这个过程不是删减功能而是增加鲁棒性。我们有个客户买了某厂商的 “智能合同审查 Skill”号称“原版无删减”结果上线三天因未设超时一次大文件解析导致整个 Agent 服务不可用。我们只加了一层 harness150 行代码问题解决。Harness 不是 Skill 的敌人而是 Skill 的“质量认证机构”。它让 Skill 从实验室玩具变成可部署、可监控、可运维的工业品。5. Harness 与 LLM不是替代而是“驯化者”与“被驯化者”的共生协议LLM 是强大的但也是野性的。它不遵循 REST 规范不保证 SLA不提供健康检查端点。Harness 的终极使命就是与 LLM 达成一份“共生协议”在不改变 LLM 本质的前提下让它成为可信赖的基础设施组件。这不是技术傲慢而是工程必然。5.1 LLM 的三大“野性”正是 harness 的三大驯化目标LLM 的野性Harness 的驯化手段生产后果无 harness输出不可控同一 prompt不同时间、不同 seed输出可能完全不同- Schema 强约束- 语义一致性检查- Confidence 锚定Agent 流程中断、前端渲染错误、数据入库失败调用不可靠网络抖动、服务排队、瞬时过载导致随机失败- 分级超时- 智能重试- 熔断降级服务可用性暴跌、用户体验断崖式下降、告警风暴行为不可见没有标准 metrics、没有 trace、没有结构化日志- 全链路 trace_id 注入- 结构化日志输出- 采样式 prompt 记录故障定位耗时数小时、性能优化无从下手、合规审计无法通过这三大驯化不是要消灭 LLM 的创造性而是划定它的“活动边界”。就像给一匹骏马装上缰绳和鞍具不是限制它奔跑而是确保它能听从指令、安全抵达目的地。5.2 harness engineering 的核心用确定性对抗不确定性harness engineering这个热词精准概括了这项工作的本质——它不是 AI 研究而是软件工程在 LLM 时代的延伸。它的技术栈90% 是传统后端工程网络层HTTP client 配置连接池、keep-alive、DNS 缓存、TLS 版本协商并发控制线程池/协程池管理、信号量限流、背压backpressure处理存储层fallback cacheRedis、trace 存储Elasticsearch、采样日志S3监控层Prometheus metricsharness_call_duration_seconds,harness_fallback_total、Grafana dashboard、告警规则fallback 率 5% 时通知。唯一新增的是针对 LLM 特性的适配逻辑schema 注入、confidence 计算、语义检查。这些逻辑全部封装在 harness 的preprocess()、postprocess()、validate()方法里与传统工程代码无缝集成。我们团队的 harness 工程师一半时间在写 Pydantic 模型和 JSON Schema一半时间在调优线程池大小和 Redis 连接数。这很无聊但极其重要。因为 LLM 的“智能”再耀眼也掩盖不了一个事实它跑在 Linux 内核上走的是 TCP/IP 协议栈受制于 CPU 和内存——这些才是 harness engineering 的主战场。5.3 为什么llm 框架和llm 代理地址不能替代 harness搜索热词里频繁出现llm框架、llm代理地址反映出一种误解以为换个框架LangChain、LlamaIndex或配个代理如http://localhost:8000/v1就能解决 LLM 生产化问题。这是危险的幻觉。LLM 框架LangChain 等它解决的是“怎么编排”不是“怎么可靠调用”。LangChain 的LLMChain依然裸调llm.invoke()没有内置超时、没有熔断、没有 schema 校验。它是个乐高积木harness 才是胶水和螺丝刀。LLM 代理地址如 Ollama、vLLM它解决的是“怎么部署模型”不是“怎么安全调用”。vLLM 提供了高性能推理但它不关心你的 prompt 是否含敏感信息不关心你的输出是否符合业务 schema不关心你调用失败时要不要 fallback。它是个发动机harness 才是变速箱和 ABS 系统。真正可靠的 LLM 应用必须是三层架构Agent业务编排层 → Harness工程保障层 → LLM Framework / LLM Proxy模型执行层跳过 harness 这一层就像造车只关注发动机和座椅却忘了刹车和安全气囊。dify的sql查询内容太多导致llm返回不稳定这个问题根源不是 Dify 框架不好也不是 LLM 不行而是 Dify 的 harness 层它的llm_client没有做好输入长度治理和 fallback 机制。Harness 不是锦上添花而是雪中送炭。它不让你的 LLM 更强大但让你的 LLM 更值得托付。6. 动手实现一个最小可行 harness从零开始200 行代码搞定理论讲完现在动手。下面是一个生产可用的最小可行 harnessPython它覆盖了前文所述的四大支柱代码 197 行无外部依赖除requests、pydantic、jsonschema可直接集成到任何 Agent 项目中。这不是玩具是我们线上服务的真实简化版。# harness.py import time import json import logging import random import uuid from typing import Dict, Any, Optional, Callable, List from pydantic import BaseModel, ValidationError from jsonschema import validate, ValidationError as SchemaValidationError import requests # 配置日志 logging.basicConfig(levellogging.INFO) logger logging.getLogger(__name__) class HarnessConfig: harness 全局配置 DEFAULT_TIMEOUT_MS 8000 FALLBACK_THRESHOLD 0.6 # 熔断失败率阈值 CIRCUIT_BREAKER_DURATION 30 # 熔断持续秒数 class SkillMetadata(BaseModel): Skill 元数据 name: str model: str timeout_ms: int HarnessConfig.DEFAULT_TIMEOUT_MS max_input_tokens: int 4000 requires_rag: bool False class HarnessCallResult(BaseModel): harness 调用结果 success: bool data: Optional[Dict[str, Any]] None error: Optional[str] None latency_ms: float confidence: Optional[float] None fallback_used: bool False class Harness: def __init__(self): self.circuit_breakers {} # {skill_name: {state: closed/open/half-open, failure_count: int, last_opened: float}} def call(self, skill_name: str, input_data: Dict[str, Any], metadata: SkillMetadata, output_schema: Dict[str, Any]) - HarnessCallResult: 统一调用入口 trace_id str(uuid.uuid4()) start_time time.time() # 1. 输入治理 try: validated_input self._validate_input(input_data, metadata) except ValidationError as e: return HarnessCallResult( successFalse, errorfInput validation failed: {e}, latency_ms(time.time() - start_time) * 1000, fallback_usedFalse ) # 2. 熔断检查 if self._is_circuit_open(skill_name): logger.warning(fCircuit breaker open for {skill_name}, using fallback) return self._fallback(skill_name, input_data, start_time, trace_id) # 3. 构造 prompt 调用 try: prompt self._build_prompt(validated_input, metadata, output_schema) response self._llm_request(prompt, metadata, trace_id) # 4. 输出校验 result_data self._validate_output(response, output_schema) # 5. 置信度锚定简化版从 response 中提取 confidence confidence self._extract_confidence(result_data) latency_ms (time.time() - start_time) * 1000 logger.info(fSuccess call to {skill_name}: {latency_ms:.0f}ms, confidence{confidence}) return HarnessCallResult( successTrue, dataresult_data, latency_mslatency_ms, confidenceconfidence, fallback_usedFalse ) except Exception as e: latency_ms (time.time() - start_time) * 1000 logger.error(fCall to {skill_name} failed: {e}, latency{latency_ms:.0f}ms) self._record_failure(skill_name) return self._fallback(skill_name, input_data, start_time, trace_id) def _validate_input(self, input_data: Dict[str, Any], metadata: SkillMetadata) - Dict[str, Any]: # 这里可集成 PII 过滤、长度检查等 if len(str(input_data)) metadata.max_input_tokens * 4: # 粗略字节估算 raise ValidationError(fInput too long for {metadata.name}) return input_data def _build_prompt(self, input_data: Dict[str, Any], metadata: SkillMetadata, output_schema: Dict[str, Any]) - str: # 注入 schema 指令 schema_str json.dumps(output_schema, ensure_asciiFalse) return f你是一个专业助手请严格按以下 JSON Schema 输出不要任何额外文字 {schema_str} 用户输入{json.dumps(input_data, ensure_asciiFalse)} def _llm_request(self, prompt: str, metadata: SkillMetadata, trace_id: str) - str: # 模拟 LLM 调用实际替换为 requests.post # 这里演示超时和重试逻辑 timeout metadata.timeout_ms / 1000 for attempt in range(3): try: # 实