70%智能体项目折戟，根子不在模型！

1 多数智能体系统折戟的真实原因

2025 年的一项行业调研显示，超过 70% 的企业级智能体试点项目在六个月内被搁置或缩减规模。原因高度集中在三个方向：模型在受限场景下产生不可预期的输出、多个智能体之间的状态同步失效、以及工具调用的权限边界模糊。

这些问题的共同根源，是团队把精力放在模型选型和 Prompt 优化上，忽略了承载智能体运行的底层系统。Agent = Model + Harness。模型相当于 CPU，Harness 相当于操作系统，负责资源调度、边界隔离与接口封装。没有操作系统，再强的 CPU 也没用。

Agent = Model + Harness 核心概念

2 从 Prompt 到 Harness 的工程焦点转移

SWE-bench Verified 榜单上，排名前六的基座模型首尾分差只有 1.3 分。但同样使用 Claude Opus 4.5，嵌入不同智能体框架时得分差能到 10 分。模型本身的差距在缩小，框架工程的价值在放大。

工程焦点经历了四个阶段：

• Prompt Engineering 优化问题模板，提升单次输出质量
• Agent Engineering 思维链与 ReAct，多轮交互迭代
• Context Engineering 上下文压缩、摘要与长窗口管理
• Harness Engineering 构建长期、稳定、可靠的系统工程

前三个阶段解决的是『如何让模型回答正确』，第四个阶段回答的是『如何让系统稳定运行』。

从 Prompt 到 Harness 的四阶段演进

3 工业界正在验证的三种模式

在智能体系统的工程化落地中，三个方向正在被不同团队验证：

三种工业验证模式

安全隔离模式。一家金融科技公司为其交易分析智能体设置了多层沙箱：智能体只能访问经过脱敏的只读数据库副本，所有写操作必须通过审批队列。上线六个月，零事故。这套方案的核心不是模型能力，而是 Harness 层的权限闸门。

失败轨迹优先模式。一个开源智能体框架团队在迭代中发现，刻意保留失败执行轨迹比只记录成功路径更有价值。掩盖错误会激发虚假信念偏见——模型以为自己的策略是对的，实际上已经偏离了目标。通过分析失败路径，他们改进了指令回溯机制，任务成功率从 62% 提升到 89%。

渐进式开放模式。某云计算厂商的运维智能体采用最小权限起步策略：智能体上线时只有读取权限，运行稳定后逐步开放写操作，每个权限提升阶段伴随 48 小时观察期。这种设计让运维团队敢用、愿意用，而非将智能体视为需要时时盯着的问题源。

4 Harness 的自动化演进方向

业界对 Harness 的探索已经超越了『手动配置规则』的阶段。几个值得关注的方向：

• Meta Harness 由一个 Proposer Agent 读取执行日志，自动生成改进策略，并跨模型迁移
• 可观测性驱动自演化 通过可证伪的指标触发自动回滚，消除人工介入延迟
• 结构化自然语言描述 Harness 将控制逻辑与语义说明分离，降低 Harness 的管理门槛
• 元-元演化 直接优化系统演化的蓝图本身，而非每次迭代调整具体规则

这些方向指向同一个结论：Harness 本身正在从静态配置演化为一个可自我优化的系统层。

5 知识工程在 Harness 中的角色

纯向量检索的 RAG 在多跳推理场景中不够用。当智能体需要跨多个数据源、经过多步推理才能得出答案时，语义相似度检索的准确率急剧下降。

知识图谱作为约束层

知识图谱和本体（Ontology）在这类场景中充当了约束层：它们拦截违规操作，触发自纠错，并为智能体提供结构化的领域知识。一家零售企业让多个职能智能体共享统一零售知识图谱，实现了跨部门的协同工作——订单智能体与库存智能体共用同一套商品分类体系，避免了命名冲突和逻辑断层。

6 落地的起点

Harness 不是等到系统跑起来之后再加固的外壳，而是从第一个智能体上线时就该搭建的骨架。选一个端到端任务，用最简 Harness 跑通，再逐步引入计算型 Sensor、部署前馈引导集、切入结构化知识层。

评估指标也要换——从 Token 消耗转到任务采纳率、人工返工率、故障恢复时间。这些数字反映的是 Harness 的真实效能，不是模型的推理速度。