手写一个 LLM Harness 框架：用工程化手段把大模型幻觉踩在脚下

大模型很强，但有两个痛点始终挥之不去：

• 幻觉
• 落地难
• 成本波动
• 可观测性不足
• 评估困难

Prompt Engineering 救不了这个问题——因为同一句 prompt 问三次LLM 可能给你三个质量天差地别的答案。

说到答案是，用工程化的手段来管住大模型的随机性。

一、什么是 Harness？怎么说呢，

┌──────────────────────────────────────────────────────┐
│ HARNESS 流水线 │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Generate │ ──► │ Evaluate │ ──► │ Select │ │
│ │ 并行生成N个│ │ LLM自动打分│ │ 择优输出 │ │
│ │ 候选答案 │ │ ~10分 │ │ 最高分 │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ │
│ 输入 Prompt ──────────────────────► 最佳答案 │
└──────────────────────────────────────────────────────┘

AWS Harness 原意是“马具”——用来驾驭烈马的工具。在这里它是一套将 LLM 的生成、评测、择优 三阶段串联成闭环流水线编排框架。像被缰绳驾驭的马一样，大模型在结构化流程中自动产出更高质量的结果。

This is also a microcosm of 感知→ 推理→ 行动，三个环节解耦、可替换、可观测。

二、主要引擎：askLLM — 一切对话的原子单位

import OpenAI from 'openai';import { config } from 'dotenv';config，const client = new OpenAI({
至于apiKey，process.env.OPENAI_API_KEY。baseURL: process.env.OPENAI_API_BASE_URL,});const askLLM = async => {
const res = await client.chat.completions.create({
从model来看。process.env.MODEL_NAME,messages:,});return res.choices.message.content;}，

• config: 加载 .env 文件中的所有环境变量，让 API Key、模型名等与代码完全解耦。
• new OpenAI: 支持任何兼容 OpenAI 协议的服务端，实现统一接口调用。
• askLLM: 原子能力。只负责把字符串送给 LLM 并返回文本，是全文件唯一 I/O 边界。
• res.choices.message.content: 获取模型完整文本输出。

因为 generateCandidates 与 judge 都要调用 LLM。把客户端创建和 API 细节封装在单一函数里后续加日志、加重试、切模型，只改这一个地方。

三、阶段一：Best‑of‑N Sampling — 并行生成多个候选

const generateCandidates = => {
const tasks = Array.from => askLLM);return Promise.all;}，

为什么不用其他写法？怎么说呢，

• ❌ 错误写法 —— Array 创建的是稀疏数组。map 会跳过空位，Array.map => askLLM) // 回调根本不会执行

• ✅ 等价写法 .map => askLLM)// ✅ 等价写法 .map => askLLM)// ✅ 当前写法—— 一次调用完成创建 + 填充Array.from => askLLM)

为什么需要“同一个问题问 N 次”？

• 大模型每一次生成本质上是一次概率采样 。无法提前知道哪一次运气好。最简单粗暴的方法就是让所有结果都产生，接下来挑出最好的那一个。多样性可以覆盖随机性的风险。

四、Array.from：你需要知道的一切

• 完整语法

  Array.from arrayLike 必须有 length 或者是可迭代对象 mapFn 可选映射函数。对每个元素执行一次 thisArg 可选，用作 mapFn 中 this 的指向

// 简单示例：并发发起 N 个请求
Array.from => askLLM);这行代码完成了两件事：
1️⃣ 在单线程事件循环里同步创建 N 个 Promise；2️⃣ 同步触发 N 次 HTTP 请求，实现“几乎同时”并发。这样做可以最大限度减少首字节时间，而不会像 `for` 循环那样逐个等待返回。从而避免因网络延迟导致整体吞吐下降。按理说，

为什么这里是最佳场景？


Harness 要求几乎同时发出 N 个 HTTP 请求，没有任何串行依赖；`Array.from` 的 map 回调在构造期间同步调用 `askLLM`，几乎在同一帧创建并开始飞行。这正是 JavaScript 单线程事件循环下能实现最高并发度的一种方式。



五、阶段二：LLM as Judge — 让大模型当评委



async function judge {
const prompt = 
你是一个严格的代码评审。请判断下面代码是否正确实现「数组去重函数」
要求的观点是，- 只返回一个数字评分
- 不要解释，不要附加文字
说到代码，${ code }
;const res = await askLLM;const score = parseFloat;return isNaN?-1 : score，}
``
judge` 将 “让 LLM 给 LLM 打分” 成为标准流程：
* 角色锚定 – “你是一个严格的代码评审”，控制评分严谨度；其实，* 输出约束 – “只返回数字”。剥离多余信息，使解析稳定；* 容错兜底 – 当解析失败时默认给最低分，避免因异常导致整个流程崩溃。


此方法直接解决了“缺乏可观测性 & 评估困难”的痛点。让非确定性的输出变成可量化指标，可用于后续监控和报警。


再看阶段一。**并行** – 因为无相互依赖，可最大化吞吐；阶段二：**串行** – 避免触发速率限制，同时保持对每个候选精确打分。

三个精巧设计的观点是，



六、阶段三：择优 — pickBest 的排序哲学
function pickBest {
return results.sort=>b.score-a.score);}
时间复杂度 O，但在实际中 candidates 数量很小，开销微乎其微。排序后取第一名直观易读，是工程师常见的小数据集调整策略。

七、总装：harness 流水线函数
async function harness {
console.log;// 阶段 ：生成—并行调用 LLM 输出 N 个候选
const candidates = await generateCandidates;console.log，console.log;// 阶段 ：评测—逐个给每个候选打分
const evaluated = await evaluateAll;console.log，// 阶段 ：择优—按分数排序取最高分
const best = pickBest;return best.code;}
const bestCode = await harness;console.log，此流水线完整演示了：
harness
|
▼ generateCandidates -> 并行请求 →
|
▼ evaluateAll -> 串行评分 →
|
▼ pickBest -> 返回最高得分代码片段

八、Harness 的工程哲学——单一职责 & 可

d `d t d>


想提高生成质量？更改 generateCandidates 调整采样数量。

想换评测模型？修改 judge 内使用 modelName 或添加新 prompt 模板。

想换择优策略？替换 pickBest 为多数投票或阈值过滤。说起来，

想加日志 & 可观测？在每一步加入 console.info / metrics.record。

九、写在最终

该框架仅用了不到 120 行代码 就实现了：


Best‑of‑N Sampling —— 用多样性覆盖随机性，将随机变优势；说起来，

LLM as Judge —— 自动化评判闭环替代人工测试。提高可靠性，

Pipeline Orchestration —— 解耦生产流程，让每个环节独立升级或替换。

掌握这些主要思路后你就能快速应用，并彻底驯服那些令人头疼的大模型幻觉。


函数 
职责 
关注点 

`askLLM`  vs API 通信 
与外部服务交互，仅提供接口包装器功能。
配置管理与请求发送细节统一处理。

`generateCandidates`  vs 并发控制 
异步批量产生答案，无业务逻辑干扰。
任务拆解与超时/错误策略集中管理。

`judge` vs 评价推理 
将业务规则转为 prompt 与结果解析。
评分尺度与错误兜底一致化维护。

`evaluateAll` vs 串行调度  Treat each candidate sequentially to respect rate limits.

d `)》d t d>