【AI面试临阵磨枪】为什么生产级 Agent 必须上 Harness，而不能只靠 Prompt？

一、 面试题目

在开发 Agent 时，很多人认为只要 Prompt 写得足够好，模型就能处理一切。但为什么在生产级应用中，我们必须构建Harness 治理框架？Prompt 的局限性在哪里？Harness 解决了哪些 Prompt 无法触及的核心痛点？

二、 知识储备

1. 核心背景：概率性 vs 确定性

• Prompt (概率系统)：无论你如何强调“请输出 JSON”，模型在面临长上下文或复杂逻辑时，仍有 1% ~ 5% 的概率输出非法格式或幻觉内容。
• Harness (确定性系统)：通过代码层面的拦截、校验和重试，将这 5% 的不确定性收敛到 0%。

2. Prompt 的三大“致命伤”

① 闭环失效（The Loophole）：

Prompt 无法感知外部世界的真实反馈。例如，当工具（Skill）调用返回 500 错误时，仅靠 Prompt 很难实现精准的状态回滚，模型往往会开始编造结果。

② 状态膨胀（Context Bloat）：

为了让模型守规矩，我们会在 Prompt 中加入大量的限制条件（Guardrails）。这会导致 Token 消耗激增，且模型会因为指令过载而产生“注意力稀释”，反而更容易出错。

③ 安全脆弱（Jailbreak）：

Prompt 极易受到提示词注入（Prompt Injection）的攻击。黑客可以通过巧妙的台词绕过 Prompt 层的约束。

3. Harness 的核心价值

三、 破局之道

在回答完技术差异后，通过这段话展现你对AI 工程化思维的深度思考：

“回答这个问题，核心要理解“AI 治理”与“AI 生成”的本质区别。

你可以告诉面试官：

Prompt 就像是给员工发的“员工手册”，而 Harness 则是公司里的‘打卡机、权限系统和财务审计。手册写得再好，也不能代替规章制度的物理执行。

在生产场景下，我宁愿要一个 60 分智力的模型配合 100 分的 Harness，也不要一个 100 分智力却裸奔运行的模型。因为Agent 的商业价值在于‘交付结果的确定性’。Harness 存在的意义，就是为了让不稳定的概率模型，在确定的工程框架内，产出可被业务部门信赖的、具备 SLA 保障的服务。一个优秀的开发者不应迷信模型的“悟性”，而应致力于构建一套“防御性架构”，让 AI 在规则的范围内“冲”，在框架的监控下“稳”。

四、 代码实现

我们用两种语言展示：当 Prompt 失效（输出格式错误）时，Harness 是如何“硬核”介入的。

1. Python 实现：Harness 层的强制重试逻辑

def production_inference(task): # 1. 尝试执行，Prompt 可能失效 raw_response = llm.generate(f"请按JSON格式处理任务: {task}") # 2. Harness 介入：格式校验 try: data = json.loads(raw_response) return data except json.JSONDecodeError: # 3. 发现 Prompt 失效，Harness 执行“回滚并修正”策略 print("发现格式幻觉，触发 Harness 修正流...") # 此时不再只是重试，而是通过 Harness 注入更强的格式补丁 return harness.retry_with_strict_schema(task)

2. JavaScript (Node.js) 实现：Harness 的“观察-修正”闭环

async function executeAgentTask(task) { const agent = new OpenClawAgent(); // 建立执行快照 const checkpoint = await agent.saveState(); const output = await agent.think(task); // Harness 层：输出护栏校验 if (!output.contains_required_fields(['id', 'status'])) { console.error("模型输出不合规，强制回滚状态..."); // 物理回滚：抹去模型刚才的错误记忆，重新执行 await agent.rollback(checkpoint); return await agent.retryWithCoT("注意：必须包含id和status字段。"); } return output;