这是《AI 入门指南》拆分系列第 5 篇。前面我们已经把聊天框、工作台、coding agent、Prompt、Context、Tool Use、RAG、MCP、LLM Wiki 都拆开看过了。到了最后这一篇，真正的问题只剩一个：模型开始能做事之后，怎么让它可控、可测、可维护？

很多团队第一次做 Agent，最先遇到的障碍并不是“模型不够聪明”，而是系统根本不稳。

最常见的症状通常是这样的：

• 忘记目标
• 漏掉关键步骤
• 工具乱用
• 回答不稳定
• 看起来做了很多，实际上结果不可验证

于是问题就从“怎么把一句话说清楚”，转向了另一个更偏工程的问题：

怎么把模型装进一个可控、可验证、可维护的执行框架里？

这正是 Harness Engineering 在解决的事。

为什么 Prompt 已经不够了

很多人刚接触 AI 时，最先学到的通常是 Prompt。当然，这一步很重要。但只要你做过稍微复杂一点的任务，就会发现只靠 Prompt 很快会撞墙。

因为你面对的已经不是一次性问答，而是一个会持续执行的系统。它每一步都需要：

• 知道当前目标是什么
• 知道能看哪些材料
• 知道能调哪些工具
• 知道结果该如何校验
• 知道什么时候继续，什么时候停下来

这时候，Prompt 当然还是必要的，但它不再是全部。

Harness Engineering 在管什么

“Harness” 原本有“缰绳、控制装置”的意思。在 AI 语境里，它强调的不是“模型本身多强”，而是你如何设计一整套框架去约束、组织和放大模型能力。

如果把几个最容易混淆的词排在一起看，可以先这样理解：

• Prompt Engineering：你怎么把要求说清楚
• Context Engineering：系统在每一步到底能看到什么
• Agent Engineering：模型怎样调用工具、执行循环、推进任务
• Harness Engineering：怎样把 Prompt、Context、Tool、Memory、Eval、安全边界统筹起来

通常它会包括几类核心工作：

1. 上下文编排

模型不知道你的项目、目标、规则和历史。你必须决定：什么信息该给它，什么时候给，给多少，哪些信息是权威来源。这一步做不好，后面的一切都会跑偏。

2. 工具编排

模型能不能调用工具是一回事，会不会合理使用是另一回事。你要定义：

• 什么时候该用搜索
• 什么时候该读文件
• 什么时候该停下来问人
• 什么时候绝对不能直接写入

如果这一步不做约束，最典型的结果就是：Agent 会反复搜索同一件事，或者顺手调用本来就不该碰的高危工具。

3. 执行循环设计

Agent 不是一次输出，而是连续执行。你要定义：最多跑几步、失败怎么恢复、哪些步骤要确认、什么情况下必须中止。没有这些约束，一个 Agent 很容易在某个错误上无限打转，直到把 token 和调用额度一起烧完。

4. 状态与记忆管理

系统要记住：用户是谁、用户偏好是什么、项目进展到哪一步、哪些决策已经定了、哪些文件是可信来源。这些状态信息决定了 Agent 在不同任务之间的连贯性。

一个最小可用的 Harness 长什么样

如果把这层能力压成一个最小示意，可以先看这样一份骨架：

 1name: enterprise-knowledge-qa
 2
 3context_strategy:
 4  max_tokens: 8000
 5  document_retrieval:
 6    max_documents: 5
 7    rerank_enabled: true
 8
 9tools:
10  - name: document_search
11    scope: readonly
12  - name: web_search
13    require_approval: true
14
15execution_loop:
16  max_steps: 5
17  fallback_strategy: ask_human
18
19security:
20  input_sanitization: true
21  output_filtering: true

如果展开一点，企业级 Harness 还会进一步长出：

• 上下文优先级规则
• 工具权限白名单
• 失败恢复策略
• 状态检查点
• 评估指标与告警阈值

真正的重点不是 yaml 长什么样，而是你已经开始把一个“问答模型”变成一个“可治理系统”。

Eval：没有评估的系统，不知道自己哪里坏

模型生成结果之后，不能只看它“像不像对”，还要验证：

• 格式是否正确
• 路径是否存在
• 内容是否引用真实资料
• 代码是否能运行
• 结果是否符合约束
• 对长上下文任务，当关键证据出现在开头、中间、结尾时，结果是否同样稳定

没有评估的系统，是一个你不知道它在哪里失灵的系统。

如果要做一个最小可用的 Eval，可以先准备三类样本：

• 常规样本：正常任务是否稳定完成
• 边界样本：信息冲突、格式复杂、约束较多时是否还遵守要求
• 对抗样本：用户故意带偏、上下文很长、噪声很多时是否还能守住主任务

Guardrails：越能做事，越要先设边界

当 AI 还只是聊天工具的时候，最大的风险可能只是“回答不准”。但一旦它变成 Agent，开始读取文件、调用工具、接触私有信息、执行真实动作，风险级别就会迅速升级。

这时候，安全问题不再只是“模型会不会瞎说”，而是包括：

• 提示词注入
• 越狱
• 数据泄露
• 权限越界
• 工具滥用
• 幻觉导致错误执行

所以一个能真正落地的 Agent 系统，一定要把安全看成核心能力，而不是发布后再补的功能。

如果从更完整的工程视角看，安全往往会变成一套纵深防御体系：

• 输入层：清洗用户输入和工具回包
• 权限层：最小权限与作用域隔离
• 执行层：高风险动作强制人工确认
• 输出层：敏感信息脱敏、结果过滤、事实校验
• 运营层：红队测试、攻击样本库、持续回归演练

更细一层看，这套 Guardrails 会自然落成分层防御模型：

1. 输入层防护：输入验证、恶意内容检测、速率限制
2. 模型层防护：提示词注入防护、越狱检测、输出审查
3. 工具层防护：权限最小化、审批、敏感操作确认
4. 输出层防护：内容安全审查、隐私脱敏、事实校验
5. 审计层监控：完整操作日志、异常行为检测、合规性检查

如果你愿意，也可以把这一层统一叫成 Guardrails：不是简单的“加个禁止词列表”，而是整套保护系统不会越界的边界设计。

Versioning：提示词也要像代码一样管理

这里有一个特别容易被低估的点：Prompt 也要版本管理。就像代码不能随手改，Prompt 和 Workflow 其实也不能。

你改了哪一句、为什么改、改完之后效果有没有提升、出了问题能不能回滚，都应该有记录。否则当系统质量突然下滑时，你很可能根本不知道到底是哪一次提示词改动、哪一次工具编排调整、哪一次工作流分支变化引发了问题。

也就是说，Versioning 在 AI 系统里不是锦上添花，而是生产级可维护性的基本条件。

一个具体例子：企业知识库问答系统

让我们看一个很典型的 Harness Engineering 场景：企业知识库问答系统。

它的需求通常很现实：

• 公司有大量内部文档
• 员工需要快速找到相关信息
• 系统必须保证回答准确性，不能编造
• 需要控制成本，避免无谓的 token 消耗

一旦开始真的搭这种系统，你就会发现，问题根本不只是“RAG 能不能查到文档”，而是：

• 哪些资料能进上下文
• 哪些资料必须脱敏
• 检索到几段才合适
• 结果怎么做验证
• 工具结果该不该让模型直接信
• 某次回答异常时，怎么回放当时的输入、上下文、检索片段和模型输出

也就是说，这类系统几乎天然会把你推到 Harness、Eval、Guardrails 和 Observability 上。

Observability：为什么 AI 系统必须可观测

传统系统有日志、指标、链路追踪；AI 系统还要再多看几层：

• 上下文到底喂了什么
• 检索命中了什么
• 模型为什么走了这个工具路径
• 哪一步开始出现幻觉或格式跑偏

也就是说，AI 可观测性不只是“系统挂没挂”，而是“这次回答为什么是这样生成出来的”。

这一层会直接决定团队能不能：

• 找到性能瓶颈
• 回溯一次失败回答的原因
• 分析成本异常
• 做线上灰度
• 建立真正可持续的评估闭环

如果继续展开，可观测性通常会覆盖四类指标：

1. 性能指标：延迟、吞吐、错误率
2. 质量指标：准确性、相关性、完整性、幻觉率
3. 成本指标：token 消耗、模型调用费用、工具调用费用
4. 业务指标：用户满意度、任务完成率、用户留存

常见工具栈也会随之出现：

如果再往运维里走一步，告警规则也会变成现实问题。一个最简化的告警配置，大概会长这样：

 1alerts:
 2  - name: high_hallucination_rate
 3    condition: hallucination_rate > 0.1
 4    duration: 5m
 5    severity: critical
 6  - name: high_latency
 7    condition: p95_latency > 5000
 8    duration: 10m
 9    severity: warning
10  - name: cost_spike
11    condition: hourly_cost > 100
12    duration: 1h
13    severity: critical

而当团队开始认真控制成本时，还会进一步关心成本归因：

• 哪个模型最贵
• 哪类任务最烧 token
• 哪个用户或工作流在异常放大成本
• 哪个工具调用在吞掉预算

从 Harness Engineering 到 AI Operations / LLMOps

当你开始真的去搭 Agent，通常很快又会遇到下一个问题：系统搭出来了，然后呢？

Harness Engineering 更像是在解决“如何把系统组织起来”，而 AI Operations / LLMOps 关注的是：

• 数据怎么准备和清洗
• Prompt 和工作流怎么做版本管理
• 模型怎么评测，评测数据集怎么维护
• 服务怎么部署，伸缩策略怎么定
• 线上怎么监控，异常怎么报警
• 成本怎么控制，token 消耗怎么分析
• 回归测试怎么做，新版本怎么灰度
• 用户反馈如何闭环进入优化流程

如果继续往生产环境走，下面这些能力就会越来越重要：

1. 可观测性

不仅要看服务状态，还要看模型链路、检索路径、工具使用、上下文结构和结果质量。

2. 推理基础设施

一旦进入企业环境，部署问题就会立刻变成现实问题：

• 云端 API 和本地模型怎么混合
• 什么时候需要自托管推理服务
• GPU 怎么配、量化怎么做、吞吐怎么权衡
• 长上下文与推理成本怎么平衡

下面这张表可以先把部署模式拉平：

如果是自建推理服务，GPU 选型就会立刻变成预算问题：

对很多企业来说，真正可行的往往不是“全云”或“全本地”，而是混合部署：

• 敏感数据放本地或私有环境
• 通用能力放云端
• 低延迟场景放边缘侧

也就是把“数据主权”“成本”“模型能力”“运维复杂度”一起平衡，而不是只盯着单一指标。

分层治理架构

一个成熟的 AI 系统架构通常会自然走向分层治理：

如果是自建推理服务，GPU 选型就会立刻变成预算问题：

所以可以把两者的关系这样理解：

Prompt、RAG、Agent 解决的是“做出来”，AI Operations 解决的是“跑得住”。

这一篇真正想留下什么

如果把这一篇压成一句话，那就是：

当模型开始会做事，真正难的就不再是“能不能做”，而是“能不能可控、可测、可维护地持续做”。

这也是整个系列最后真正想落下来的判断。前面四篇从聊天框一路走到知识与工具系统，最后这一篇告诉我们的，是为什么成熟的 AI 系统一定会自然走到 Harness、Eval、Guardrails、Versioning、Observability 和 LLMOps。

换句话说，未来真正重要的，不是会不会用某一个 AI 工具，而是：

你能不能把 AI 组织进自己的工作系统。