AI Harness 架构科普：从演进到落地

AI Harness 是怎么演进来的：从“写 Prompt”到“可运营系统”的必然结果

AI Harness 并不是某个突然出现的新概念，而是生成式 AI 应用在真实业务里“撞墙”之后，自然长出来的一套工程化架构。它大致经历了几个阶段：

1）Prompt 时代：把大模型当“超级文本函数”

最早大家做 LLM 应用，常见形态是：

• 一个输入框（用户提问）
• 一段 Prompt（告诉模型怎么回答）
• 一个输出框（模型回答） 这阶段的核心目标是“能回答”，优点是快、demo 效果惊艳；缺点也很明显：不稳定。同一个问题可能每次回答不同，偶尔还会胡编或跑题，但因为只是“内容生成”，业务风险相对可控。

2）RAG 时代：发现“只会说不行”，需要“基于证据说”

当 LLM 被用于客服、知识库问答、内部制度查询时，幻觉问题会直接变成事故：答错政策、编造不存在的流程、引用不存在的文档。

于是开始引入 RAG（检索增强生成）：

• 先检索知识库/文档（找证据）
• 再让模型基于证据组织答案（尽量可追溯） 但新的问题随之出现：检索结果质量参差不齐、上下文拼接成本高、权限与脱敏复杂、不同来源的证据冲突怎么办。你会发现：要把“检索 + 生成”用好，需要一套专门的上下文管理与治理机制——这已经在逼近 Harness 的雏形。

3）Tool-Use 时代：从“回答问题”升级为“替你办事”

当大家开始让模型“做动作”，例如：

• 查数据库、写工单、生成报表

• 发邮件、排日程、调用内部 API

• 进行多步骤流程（先确认 → 再执行 → 最后汇报） LLM 的角色从“内容生成器”变成“任务执行者”。此时风险和复杂度陡增：

• 工具该不该调用？何时调用？

• 参数填错、重复调用、超时重试会不会造成重复下单/重复扣费？

• 一次任务需要多步，怎么确保中间状态不丢？

• 出了问题如何追踪：是模型决策错、工具返回错、还是上下文错？ 这时候仅靠 Prompt 已经不够了，必须有一层 “工具调用协议 + 参数校验 + 幂等 + 人在回路 + 日志追踪” 的工程系统来兜底。

4）多智能体与编排时代：任务变长、变复杂，需要“调度与分工”

当任务变成“研究 → 归纳 → 写作 → 审校 → 输出结构化结果 → 执行动作”，单次推理很难一把梭：

• 需要规划（plan）
• 需要分工（researcher / writer / reviewer）
• 需要状态机或工作流（关键步骤必须确认/审批）
• 需要错误恢复（某一步失败要能回滚/重试/降级） 于是“编排层（Orchestration）”成为必需品。到这一步，系统已经越来越像一个“AI 运行时”，而不是一个“聊天机器人”。

5）可观测与治理时代：从“能用”走向“可长期运营”

当 AI 真正在业务里跑起来后，最后一道门槛是运营与治理：

• 成本：token、模型路由、峰值限流
• 质量：离线评测、回归测试、A/B
• 安全：权限控制、敏感信息、提示注入防护
• 可追溯：全链路 trace，能复盘每一步为何这么做 这一阶段的结论是：你需要一个统一的“系统层”把模型、上下文、工具、编排、评测、监控、安全全都管起来。这套系统层，就是今天大家所说的 AI Harness。

一、什么是 AI Harness：把“模型能力”变成“可用系统”的那层架构

很多人第一次做 AI 应用时会以为：

“接个大模型 API + 写个 Prompt，就能上线一个智能助手。”

但很快会遇到现实问题：输出不稳定、成本失控、上下文丢失、工具调用乱套、无法回溯、无法评估、难以迭代……

AI Harness 可以理解为：连接用户/业务与模型/工具的“安全带 + 变速箱 + 仪表盘”。它负责把一次次不可控的生成式推理，变成 可观测、可评估、可治理、可扩展 的工程系统。

如果用软件工程类比：

• 模型（LLM）像“CPU”
• 工具（搜索、数据库、下单、发邮件）像“外设”
• AI Harness 像“操作系统/运行时 + 调度器 + 日志与监控 + 安全策略 + 测试框架”

二、为什么需要 AI Harness：从“能用”到“可运营”的分水岭

只靠 Prompt 拼凑的系统，常见痛点包括：

1. 不可控的输出与行为：有时胡编、有时跑题、有时遗漏关键步骤
2. 上下文管理混乱：对话长了就“失忆”；拼接上下文又贵又慢
3. 工具调用不可靠：不知道何时该查数据库、何时该问用户、何时该停止
4. 成本与延迟不可预测：高峰期请求排队；token 消耗暴涨
5. 无法定位问题：出错不知道是 prompt、模型版本、工具结果、还是上下文导致
6. 无法科学迭代：缺离线评测、A/B、回归测试，越改越玄学 AI Harness 的价值就是把这些不确定性“收敛”到工程可控的边界里。

三、AI Harness 的典型分层：一张“可落地”的架构图（文字版）

一个常见的 AI Harness 可以分成 6 层（从上到下）：

1）体验层（Experience Layer）

面向用户的入口与交互形态：

• Chat/对话式 UI
• 表单式任务（写周报、生成方案）
• 工作流式界面（多步骤确认、审批）
• 插件/侧边栏/IDE 助手 这一层决定了：用户如何表达意图，以及如何确认与纠错。

2）意图与任务层（Intent & Task Orchestration）

把“用户一句话”转换为“可执行计划”，并明确每一步的输入、输出、边界与风险：

• 意图识别：问答、写作、分析、信息抽取、执行操作、混合任务

• 任务分解（Plan）：把目标拆成可验证的小步骤，并为每步定义完成标准

• 步骤编排（Orchestrate）：串并行、依赖关系、超时策略、重试与降级

• 中断与澄清（Ask）：缺少关键信息时先问再做，避免“自作主张”

• 终止条件：何时停止调用工具，何时返回结果，何时 fail-fast 一个可落地的“任务协议”（建议 Harness 固化为结构化对象）：

• goal：用户目标

• constraints：时间、成本、权限、必须引用证据、输出格式

• plan[]：步骤列表（每步包含 tool?、inputs、expected_output、verify）

• risk_level：低/中/高（决定是否需要二次确认） 常见两种编排范式：

• ReAct / Tool-Use：边推理边调用工具，适合开放性任务与探索性工作

• 工作流 / 状态机：步骤固定且可审计，适合关键业务（财务、工单、审批） 推荐的混合实践：

• 外层用工作流卡住关键节点（比如“提交工单”“付款”“发外部邮件”）

• 内层允许 LLM 弹性推理（比如“检索并归纳”“生成草稿”“对齐格式”） 示例（把一句话变成可执行计划）：

• 用户：“帮我生成一份本周研发周报并发给相关人”

• 计划：

  • 先确认：周报范围、收件人、敏感信息、截止时间
  • 拉取数据：Git 提交、工单、里程碑、会议纪要
  • 归纳：进展、风险、下周计划
  • 生成：按固定模板输出
  • 发送：发邮件前二次确认（高风险动作）

3）上下文层（Context & Memory）

决定模型“看到了什么”，以及“看这些是否值得、是否合规、是否可追溯”：

• 对话历史（短期记忆）：窗口化、关键轮次保留
• 用户画像/偏好（长期记忆）：口吻、格式偏好、常用对象，但需可编辑与可撤销
• 业务数据：订单、库存、CRM、知识库等结构化数据优先
• 检索增强（RAG）：向量检索、关键词检索、混合检索、重排（rerank）
• 上下文预算管理：token budgeting、摘要压缩、证据去重 上下文治理的 3 个落地原则：

1. 证据优先：能引用文档片段或结构化字段，就不要只依赖“模型记忆”
2. 最小必要：只放与当前任务强相关的片段，减少噪声与成本
3. 权限先行：先过滤权限与脱敏，再把内容交给模型（避免越权泄露） 常见能力清单（Harness 可提供为组件）：

• 片段选择：top-k 动态、去重、冲突提示（多来源说法不一致时）
• 压缩策略：摘要、要点抽取、事实表格化
• 可追溯：每条关键结论绑定证据来源（文档、字段、时间）

4）执行层（Tools, Actions, Agents）

让模型“能做事”，并把不确定的推理转换为可靠的软件行为：

• 工具适配器：Search、DB、ERP、邮件、日历、工单系统、内部 API

• 工具调用协议：schema、参数校验、默认值、枚举约束、错误码规范

• 事务与幂等：幂等 key、去重、补偿动作（必要时回滚）

• 人在回路：高风险操作必须二次确认（或者审批流）

• 多智能体协作（可选）：研究员、写作员、审校员等角色 工具可靠性四件套：

• 输入校验：类型、范围、必填字段

• 输出校验：结构化返回、异常分类（可重试 vs 不可重试）

• 超时与重试：指数退避、熔断、降级路径

• 审计与权限：谁发起、用什么权限、做了什么改动

5）模型层（Model Gateway）

把“用哪个模型、怎么用”从代码角落提升为可配置、可回放的工程能力：

• 多模型路由：便宜模型做分类/草稿，强模型做最终答案

• 动态选择：按任务类型、时延、成本、上下文长度自动路由

• 推理配置：温度、采样策略、system prompt 管控

• Prompt 版本管理：灰度发布、回滚、差异对比

• 输出约束：JSON schema、结构化输出、guardrails 建议增加的关键能力：

• 回放（replay）：同一请求在不同模型/不同 prompt 下重放对比

• 变更影响分析：模型升级或 prompt 改动前后的质量与成本对齐

6）治理与可观测层（Evaluation, Observability, Governance）

决定系统能否长期运营，而不是“上线即玄学”：

• 全链路日志：输入、上下文、工具结果、模型输出（含版本号）

• Trace/Span：一次请求内每一步耗时、成本、重试次数

• 质量评测：离线基准集、在线满意度、人工抽检

• 回归测试：防止“修 A 坏 B”，覆盖关键意图与关键工具链

• 安全与合规：敏感信息脱敏、提示注入防护、权限审计

• 成本监控：token、调用次数、峰值限流、预算告警 最小可行的指标面板（MVP）：

• 成功率：任务完成率、工具调用成功率

• 质量：引用命中率、用户反馈、人工抽检通过率

• 成本：单次请求 token、工具调用次数、模型占比

• 时延：P50/P95 总耗时、关键步骤耗时

• 安全：越权拦截次数、敏感信息命中次数

四、AI Harness 的关键机制：让大模型“更靠谱”的 4 个方法

这一部分可以用一句话概括：先把事实和规则管住，再让模型去表达和执行。

1）先找证据，再回答

在回答问题前，先去查资料或业务系统（例如知识库、订单、工单）。

然后让模型只基于这些证据来组织语言。

这样能明显减少“瞎编”，并且答案可以追溯到来源。

2）让输出“按格式交卷”，并自动检查

不要让模型随便写一大段，而是让它按固定格式输出，例如：JSON、表格、固定字段。

Harness 再做一次“自动验收”：

• 少了必填信息，就让模型补齐
• 类型不对或格式不合规，就让模型重写
• 数值越界或不确定，就先向用户确认，或者降级处理

3）工具调用更谨慎：能防错，也能止损

当模型需要“动手做事”（查库、下单、发邮件）时，必须加防护：

• 参数白名单与 schema 校验，避免填错
• 高风险操作二次确认，避免误发或误操作
• 幂等 key，避免重复执行造成重复扣费或重复创建
• 超时、重试、熔断、降级，遇到异常时能稳住系统（例如检索失败就用已有信息并说明限制）

4）成本与速度要可控：给模型一套“预算规则”

让系统知道这次请求可以花多少钱，用多快的方式完成：

• 先用更便宜的模型做分类和路由，需要时再切换更强的模型
• 长文先摘要再深入，减少无效 token
• 检索条数（top-k）动态调整，避免把一堆无关材料塞进上下文
• 对话历史窗口化，只保留关键事实和关键轮次

五、落地建议：从 0 到 1 的最小可行路线

如果资源有限，建议按“先打地基，再堆能力”的顺序：

1. 先做 Model Gateway：把模型调用统一入口、参数配置、路由与日志先管起来
2. 再做 Tool Layer：接入最重要的 3–5 个工具，并做好参数校验与幂等
3. 引入 Context/RAG：从最简单的检索增强开始，再逐步优化召回与压缩
4. 加 Orchestration：先用轻量的边想边做（ReAct），在高风险流程上再加工作流或状态机
5. 最后补齐评测与治理：基准集、回归测试、监控面板、成本预算、安全策略

六、常见误区（踩坑清单）

• 把 Prompt 当架构：Prompt 只是其中一环，系统边界和兜底机制更重要。
• 把 RAG 当万能药：检索到不等于答对，还需要引用、去噪、权限过滤，以及冲突处理。
• 只做离线评测，不做线上观测：线上才是“真实世界”，必须能持续看到质量与成本变化。
• 不做幂等和审计就开放执行工具：很容易造成真实业务事故。
• 模型升级不做回归测试：输出格式、语气和工具选择策略都可能悄悄变。

七、总结：一句话解释 AI Harness

AI Harness 就是用“编排 + 上下文 + 工具执行 + 模型网关 + 评测治理”，把大模型从“会说”变成“能稳定交付”的可运营系统。