大量 Agent 项目死于同一个病因：不是模型不够聪明，而是治理维度的单一化。行业正在分化为两条路线—— 一条管行为，一条管认知。理解它们的分野，是理解中国企业 Agent 建设路线的起点。
一、问题的重新定义：Agent 失败的两个独立变量
过去两年，Agent 框架经历了爆炸式增长。但复盘那些在实际业务场景中失败的 Agent 项目，失败模式高度集中在两类：
第一类：执行失控。 Agent 在工具调用、API 链、状态流转上出现错误——调错了接口、漏掉了步骤、产生了不可恢复的中间状态。这类失败的特征是：模型"想对了"，但"做错了"。
第二类：认知错位。 Agent 在知识层面产生偏差——把"华东区"理解错了范围、把"经销商"和"代理商"混为一谈、把"业绩"按不同口径计算。这类失败的特征是：模型"做对了"，但"想错了"。
这两类失败高度互不重叠——一个流程可以执行得完美无缺但结论完全错误，也可以在认知正确的框架内因执行步骤缺失而功亏一篑。这意味着 Agent 治理不是一个单维问题，而是两个独立变量构成的二维空间。当前行业的主流叙事倾向于把这两个维度压缩成一个——"Agent 需要更好的治理"。但"更安全的状态管理"和"业务口径的正确理解"需要的技术手段完全不同。把压缩的维度展开，是理解两种治理路线的起点。
二、两条路线：Execution Harness 与 Knowledge Ontology
围绕这两个独立变量，行业分化出两条截然不同的路线。
路线 A：Execution Harness——管行为
Harness 路线的核心主张是：Agent 不可靠的原因是执行过程没有被充分约束。解决方案是构建一套运行时框架，对 Agent 的行为进行轨道化管理。技术特征包括：任务分解（task decomposition）、工具编排（tool orchestration）、状态机管理（state management）、权限边界（permission gating）。典型的 Harness 产品形态是 Workflow 引擎 + Agent 调度器。这类框架的隐含假设是：Agent 已经在认知层面"知道怎么做"，问题只出在执行的可靠性上。
路线 B：Knowledge Ontology——管认知
Ontology 路线的核心主张截然不同：Agent 不可靠的根本原因不是执行问题，而是它"不知道自己在什么世界里运作"。企业有独特的实体、关系、规则，Agent 如果不理解这些，执行再精确也必然出错。技术特征包括：实体建模（entity modeling）、关系网络（relationship network）、规则定义（rule definition）、语义映射（semantic mapping）。Ontology 类产品的隐含假设是：如果 Agent 对业务世界有正确的理解，执行问题可以通过工程手段解决。
三、关键分歧：两者在解决不同层次的问题
用计算机科学的经典分层来类比，两者的差异一目了然。
这个类比揭示了一个关键洞察：在软件工程中，类型系统和领域模型的设计先于部署流水线的构建。你不会在没有定义数据模型之前就设计 CI/CD 流程。但在 Agent 工程中，这个顺序被普遍颠倒了——大多数团队先搭建 Harness 框架，发现 Agent 不可控后，再试图通过提示词来约束认知。这是 Agent 项目失败率高企的结构性原因：用执行层的工具去补认知层的缺口。
四、为什么 Harness 不能替代 Ontology
一个具体例子可以说明两种路线的边界。业务指令："对上个月业绩最差的华东区经销商发送风险提醒邮件。"
Harness 路线能保证什么？查询 CRM 的 API 被正确调用；邮件发送服务的认证令牌有效；批量发送的并发控制在合理范围；失败的发送被记录并重试。
Harness 保证不了什么？"华东区"是按行政划分还是销售大区？"经销商"包含代理商吗？"业绩最差"是按签约额还是回款额？"风险提醒"的触发阈值是什么？这些问题不是执行问题，是语义问题。Harness 框架在设计上就不负责回答这些问题。更重要的是：这些语义问题如果出错，Harness 的执行越完美，造成的损失就越大。完美执行一个错误的判断，比执行失败更危险。
五、建设顺序：为什么必须先 Ontology 后 Harness
基于上述分析，一个规范的 Agent 系统建设顺序应该是：
第一步：领域建模（Ontology 先行），定义业务域内的实体、关系、约束
第二步：认知验证，在 Ontology 框架内测试 Agent 对业务问题的理解是否准确
第三步：执行框架（Harness 后置），在认知验证通过后，构建 Workflow 和工具编排。
这个顺序的合理性在于：Ontology 是 Harness 中每个决策节点的判断依据。Workflow 中的条件分支——这些判断如果不来自 Ontology 定义的知识体系，就只能来自模型的"自由推理"。而自由推理在企业场景中的可靠性，已经被无数失败案例充分证明。
六、对中国的启示：我们走在了哪条路上？
回顾过去两年中国 Agent 建设的主流方向，绝大多数走的是 Harness 先行甚至 Harness 独占的路线——低代码 Workflow 引擎是主打卖点，"接入主流大模型"是标配口号，"零代码 5 分钟搭建"是增长叙事。很少见到有框架在产品定义层面强调"本体建模"或"语义层"。
这不是偶然的。 Harness 框架有天然的商业化优势：它的价值是即时可见的，而 Ontology 的价值是延迟显现的。但用 Harness 替代 Ontology，本质上是"用一个在运行时捕捉 bug 的工具，去替代一个在设计时防止 bug 的工具"——不仅治标不治本，还会制造一种"流程在跑，就是安全"的虚假信心。
中国企业 Agent 建设的真正破局点，不在于找到"更好的 Harness"，而在于正视 Ontology 这个更难但更根本的维度。