Harness之后：智能体工程的下一站是什么？

一、先看演进逻辑：每一代工程手段，都在修复上一代的失灵

理解任何新范式的最好方式，是看清它解决了前一个范式的什么问题。AI工程化的三次演进，恰好对应问题复杂度的三级台阶。

Prompt工程：解决“如何让模型听懂一次指令”。 它的工程对象是措辞——角色设定、任务描述、思维链格式、输出结构。当交互只有一轮、任务只有一步时，一个精巧的提示词足以决定输出质量。但它的失灵点也很明确：任务一旦变长、状态一旦变多，再好的提示词也无法凭空承载跨越多轮的上下文。

Context工程：解决“模型在每一步该看见什么”。 它的工程对象是信息——检索增强、记忆管理、上下文压缩与裁剪。它承认了一个事实：模型的即时推理能力很强，但“知道什么”完全取决于喂给它什么。而它的失灵点在于：当Agent拥有工具和行动能力之后，问题从“看什么”变成了“做了之后怎么办”——行动会带来风险，输出必须被验证，错误必须可纠正。

Harness工程：解决“如何让一个会行动的模型变得可控、可验证、可生产”。 它不再优化模型本身，而是优化模型运行的环境。这是一次关键的视角转移：工程对象从“模型内部”彻底外移到“模型周围”。

把三者排成序列，规律非常清晰：措辞 → 信息 → 环境与控制系统。每一步，工程的边界都在向外扩张一圈。

agent-model-harness">二、Harness到底是什么：Agent = Model + Harness

一句话的核心公式：Agent = Model + Harness。

Harness就是大模型之外的一切——系统提示词、工具定义与调用规范、文件系统与沙箱、编排逻辑、钩子中间件、反馈回路、约束机制。大模型本身只是能力的引擎，只有通过Harness把状态、工具、反馈和约束串起来，它才真正变成一个Agent。

最贴切的类比是：大模型是CPU，Harness是操作系统。没有操作系统的CPU再强大，也无法安全地调度进程、隔离内存、管理权限；同理，没有Harness的模型再聪明，也只是“会说”，而不是“会做且做得稳”。

Harness一词来自马具——缰绳、马鞍、嚼子——这是一套引导强大但不可预测的动物的完整装备。这个比喻精准地传递了它的核心哲学，八个字：人类掌舵，智能体执行。驾驭工程不是去削弱AI的能力，而是为它打造一套“黄金缰绳”，让它跑得又快又稳：既不放任其失控，也不因过度约束而阉割其能力。

三、为什么瓶颈不在模型，而在Harness

这是Harness工程的第一性判断，值得从三个角度论证：

第一，模型质量已成为基本门槛。 头部模型之间的能力差距在持续收窄，同一个模型在不同团队手里表现天差地别——差异不在引擎，而在引擎外面的那套系统。对Agent基础设施而言，模型决定下限，Harness决定上限，后者才是真正的差异化因素。

第二，行动会放大误差。 生成一段错误的文字，损失有限；执行一次错误的操作——删除文件、发送消息、调用生产接口——损失可能不可逆。文本时代容错靠“人眼复核”，行动时代容错必须靠系统性的控制结构。Agent的可靠性瓶颈，天然落在控制层而非生成层。

第三，难投产的症结在验证而非能力。 业内常有大量Agent项目停留在演示阶段、难以走向生产的观察，其原因往往不是模型“不会做”，而是“做了无法验证、错了无法纠正、行为无法审计”。Harness通过引导把行为约束在正确轨道上，通过传感把输出纳入验证闭环，从而把原本不可靠的模型输出，转化为生产级别的行为。这是它最核心的工程价值。

四、Harness的分层架构：四层控制体系

业界流行的一种分类法，把Harness组件标准化为两类控制：引导（Guides）代表前馈控制，在行动发生之前施加约束；传感（Sensors）代表反馈控制，在行动发生之后收集信号并纠偏。这套分类法正迅速成为行业共识。在此基础上，一个完整的Harness可以进一步拆为四层：

1. 引导层（前馈控制）

• 系统提示词：定义角色、边界、输出协议；
• 仓库级智能体约定文件：类似为Agent编写的README，说明项目结构、编码规范与禁区（业界已有AGENTS.md这类通用约定）；
• 工具清单与调用规范：遵循最小权限原则，只暴露必要工具，工具描述力求精确无歧义；
• 任务约束：预算上限、步数上限、资源白名单。

2. 传感层（反馈控制）

• 评测集：以任务级正确率做回归，防止改动引入退化；
• 验证回路：单元测试、类型检查、构建结果是否通过；
• 运行时监控：轨迹审计、成本与延迟统计、异常熔断。

3. 数据上下文层：检索、记忆与状态存储，决定Agent“知道什么”。

4. 执行环境层：沙箱、容器隔离、文件系统，决定Agent“能在哪里动手”。

一个最小可用的验证回路，示意伪代码如下：

while not task.done:
    plan    = agent.plan(task, context)
    action  = harness.filter(plan)        # 引导层：前馈约束
    result  = sandbox.execute(action)     # 沙箱：隔离执行
    verdict = sensors.verify(result)      # 传感层：反馈验证
    if verdict.failed:
        context.add_feedback(verdict.errors)   # 回写上下文，驱动纠错
    else:
        task.commit(result)
    harness.audit(action, result, verdict)     # 审计留痕

这段循环揭示了Harness的本质：它不是一段静态配置，而是一个持续运转的控制系统。

五、从零搭建Harness的行动清单

1. 定义边界：先写下Agent“绝不能做”的事，负面清单比正面需求更能保命；
2. 收紧工具：最小权限，宁可逐步放开，也不要一开始全量暴露；
3. 建立沙箱：文件写入、网络访问、命令执行一律隔离；
4. 编写引导文件：把项目结构、规范和典型示例沉淀为Agent可读的约定；
5. 构建验证回路：把“做完了”升级为“验过了”，这是从Demo到生产的分水岭；
6. 沉淀评测集：从每一次失败中提取用例，让错误变成资产；
7. 接入观测：轨迹、成本、延迟、熔断缺一不可；
8. 持续迭代：Harness不是一次性交付物，而是随模型升级持续维护的资产。

在基础设施选型上，向量检索、对象存储、消息队列、容器平台、日志与监控告警等通用云产品可以分别承接记忆、状态、编排、执行与观测各层。例如在百度智能云等平台上，可以用模型服务承接推理层、向量数据库承接记忆层、容器平台与日志监控承接执行与观测层——关键在于各层职责清晰，而非堆砌组件。

六、下一站推演：Harness之后是什么？

沿用“复杂度升级驱动范式演进”的逻辑，可以推演下一个失灵点在哪里。当Harness解决了单个Agent的可控性之后，问题复杂度正在跨过新门槛：从单个智能体完成任务，到一群智能体协作完成长期项目。三个候选方向随之浮现：

其一，组织工程。 当多个Agent协作，失控点从个体行为转移到Agent之间：职责如何划分、通信协议如何定义、错误如何归因、成本如何分摊。人类管理者的工作从“为单兵配装备”变成“设计组织架构”——引导与传感的分类法依然适用，只是作用对象从个体扩展为协作拓扑。

其二，自适应工程。 Harness本身由谁来维护？下一步是让Agent根据评测反馈参与优化自己的缰绳——自动调整引导规则、扩充工具、收紧约束，人类从“设计者”退到“审批者”。

其三，治理工程。 当Agent能够长期自主行动，可审计性、责任链与合规边界将成为生产化的底线要求。

最可能的终局是三者融合：以组织工程为主体、以自适应为演化机制、以治理为护栏，或可称为“智能体组织工程”。届时核心哲学将从“人类掌舵、智能体执行”演进为“人类定目标与边界，智能体自我组织与演进”。人类角色进一步上移——从驾驭一匹马，到治理一个马场。

七、结语

Prompt工程优化的是话语，Context工程优化的是信息，Harness工程优化的是环境。值得注意的是，每一代工程手段都不是推翻上一代，而是把上一代收编为自己的一个子层——提示词成了引导层的一部分，上下文管理成了数据层的一部分。按同样的逻辑，Harness终将成为下一个范式的地基。

对开发者而言，真正的竞争力不在于追逐新名词，而在于理解演进背后不变的逻辑：能力越强的系统，越需要与之匹配的控制与验证体系。看懂了这一点，无论下一个工程范式叫什么名字，你都已经站在了它的门口。