Harness Engineering 的语义底座：本体驱动的 Agent 可控执行

01

从 Agent 热潮到「管不住」

2024-2025 年，Agent 成为企业 AI 落地的主要形态。这类产品能够自主规划、调用工具、连续执行多步任务，在 Demo 里表现亮眼。但进入真实业务之后，问题高度相似：术语用不准、推理逻辑跑偏、执行结果跟企业规则对不上，在关键节点「自信地做错事」。

根本原因并不是模型不够强，而是 Agent 缺少一个「懂规矩的结构」——它知道怎么干活，但不知道这个行业的边界在哪、这家企业的决策规则是什么。一个能干活但对业务一知半解的执行者，很难让人放心交给他独立做决策。

这正是 2026 年 Q1「Harness Engineering」成为行业热词的背景。这个概念的核心并不新鲜：为 Agent 建立完整的约束、反馈与控制体系，让它既能自主行动，又不偏离业务边界。围绕这一目标，行业逐渐形成了三个关键技术支柱：用架构约束限定行为边界，用上下文工程管理信息输入，用反馈闭环验证输出质量。

但绝大多数实践仍停留在工程拼接层面——写 Prompt、列规则、搭流程、做权限控制。这些手段在简单场景下有效，但一旦进入复杂业务，就暴露出同一个深层问题：约束是「外加的」，语义是「隐式的」，合规依赖模型对规则的理解，而模型的理解本身不可靠。

本文要讨论的，是一条不同的路径——用本体（Ontology）为 Harness 体系提供语义基础设施，使约束不再来自工程配置，而是直接来自业务结构本身。本体的切入点是将业务语义显式建模，为三个技术支柱提供统一的结构化底座。

02

重新界定问题：「安全可控」是多维度工程命题

在进入具体方案之前，有必要先厘清「安全可控执行」这一命题的边界。它至少包含以下几个相互独立又彼此关联的维度：

本文聚焦的本体驱动方案，主要作用于「行为约束」和「结果校验」两个维度，并对「审计与溯源」有实质贡献。它是完整安全体系中的语义基础设施层，而非替代其他工程手段的完整解法。

03

架构约束：从「外加围栏」到「内建骨架」

工程化约束手段在简单场景下有效，但在复杂业务中面临三个结构性困难：规则数量随业务复杂度增长，维护成本持续膨胀；规则以自然语言表达，模型理解存在不确定性，有被绕过的风险；规则与业务对象之间的语义关系是隐式的，无法跨场景复用。

本体的不同之处在于：它不试图「拦住」Agent，而是从一开始就定义好它的行为空间。约束不是外加的围栏，而是内建于业务结构的骨架。

这套机制的关键在于，业务规则不再以自然语言形式存在于 Prompt 里，而是被显式建模为可查询、可校验的结构。工具也不是在 Agent 层临时定义的，而是由本体层统一管理——Agent 能用什么、如何触发、执行流程是什么，都由结构说了算，而不是模型自己决定。

约束的执行发生在 Agent 输出之后、操作落地之前：系统将 Agent 的执行意图拿回来与本体做比对，如果违反了既定规则，直接打回重推，不会静默放行。校验依据是结构中可追溯的具体节点和关系路径，结论是确定性的，不依赖模型理解。

04

上下文工程：从「补记忆」到「重构记忆方式」

Agent 在长任务中频繁「失忆」——不断重复询问基础信息，或在关键节点丢失上下文——根本原因是信息以线性文本堆叠，缺乏结构。无论是引入外部记忆、做上下文压缩，还是扩展窗口长度，本质上都是在缓解同一个问题，而非解决它。

本体的切入点不同：企业中的数据、流程和关系本来就不是线性的，而是一个复杂的关联网络。本体所做的，是把这种关系显式地表达出来，构建一个可查询、可演化的业务语义网络。

这个结构为上下文管理带来三项实质改善。精准检索替代全量注入：在 Agent 启动前，认知引擎从本体中抽取与当前任务相关的语义子图，将最相关的上下文动态注入推理语境，而不是把所有信息一股脑塞进去，上下文溢出和无关信息干扰从根源上得到控制。一致性保障：业务知识由统一的语义网络管理，过期信息、冲突内容、冗余记录可被系统性处理，Agent 始终基于最新一致的信息推理，而不是依赖可能过时的 Prompt 片段。跨任务复用：同一语义结构可服务于不同任务的 Agent，无需为每个场景重新组织上下文，本体是一张持续维护的「业务地图」，Agent 在这张地图上行动，而不是每次任务都从零开始。

此外，本体驱动的上下文工程还解决了符号推理与 LLM 推理长期以来的分裂问题。传统知识图谱推理可解释但覆盖范围有限，纯 LLM 推理灵活但结果不可控。本体提供了一个协同框架：结构覆盖到的地方，由本体给出确定性约束；结构未覆盖的地方，LLM 可以补位，但结论会被明确标注置信状态。两者各司其职，既保准确性，又保灵活性。

05

反馈闭环：从「主观评估」到「可追溯校验」

当前主流的反馈机制是引入一个「评估者」，用模型去判断模型的输出。这种方式有一定效果，但存在明显局限——模型很容易被表面合理的结果「说服」，对业务层面的正确性缺乏判断能力。

本体提供了一条更直接的路径：不依赖主观评估，而是基于结构进行客观校验。企业中大量的判断本质上是可以被规则化的——是否超出额度、是否满足前置条件、是否符合流程逻辑。这些判断不需要「理解」，可以直接验证。当这些规则被纳入本体之后，Agent 的每一个输出都可以自动与业务约束进行比对，结果要么成立，要么不成立。

当然，并非所有判断都能被形式化。「硬约束」适合本体校验，「软约束」则不然——某个决策是否符合业务惯例、操作背后是否存在异常动机、「重大变更」的界定本身存在主观性。对软约束，本体方案需要与 LLM 评估或人工审核节点结合，两者互补而非互斥。

反馈闭环的另一个价值，是让本体本身持续进化。本体与 Agent 之间不是单向的约束关系：本体定义 Agent 的能力边界，Agent 在真实执行中接触大量业务数据，这些数据可以反哺本体——识别尚未覆盖的概念和关系，标记推理路径中频繁出错的位置，指导本体的修正和迭代。这个持续进化的闭环，是区别于「建完就放在那」的传统知识图谱的核心差异。

可解释性是这套机制另一个不可忽视的价值。每一次校验结论都有明确的结构依据，每一个判断都可以追溯到具体的规则节点。监管审计需要的不是「模型认为合规」，而是「系统可以证明合规」。这两者之间的差距，在金融、工业、铁路等强合规行业的实际场景中是决定性的。

06

从技术可控到业务可控：Knora 的实现路径

1. 约束来自业务本身，而不是工程拼接

前述方法论如果只停留在原则层面，意义有限。关键在于它有没有被真正做出来，以及做出来之后，「可控」这件事发生了什么本质变化。

传统 Harness 方案能让 Agent「更稳定」，但稳定的边界是工程边界——规则是人写的，约束是配置出来的，合规是靠 Prompt 维持的。这套体系的天花板很清晰：一旦业务复杂度超过工程维护能力，约束就开始失效。

本体驱动的方案实现的是另一件事：让约束直接来自业务结构本身。企业的对象、关系、规则被统一建模为本体，Agent 在执行任务时不是拿到上下文就开始生成，而是必须先进入这层语义结构，在既定的业务关系中完成推理和决策。它不是在自由发挥，而是在一张已经定义好的「业务地图」里行动。

这个变化带来三个实质性的转变：Agent 不再只是执行工具，而是具备业务语义的参与者；系统不需要为每个场景重新构建约束，可以在统一语义底座上复用；在模型持续迭代的过程中，业务规则层保持稳定，不随模型版本漂移。这是从「技术可控」到「业务可控」的跨越。

2. Knora 的系统架构

悦点科技的 Knora 平台，将上述方法论落地为分层协作的系统架构。

本体层（知识底座） 底层以标签属性图（LPG）存储本体模型 Schema。在元模式层面定义了五个核心概念：实体（Entity），业务对象，如工单、设备、人员；关系（Relation），实体间的语义连接；事件（Event），业务中有意义的状态变化；Action，系统能执行的操作，包含触发条件和参数约束；Logic，用 DAG 编排引擎定义的执行流程。

这套设计的关键在于：传统本体主要解决「是什么」的分类问题，而 Action 和 Logic 把本体从静态知识描述变成了可执行的业务规范，可以直接驱动 Agent 的工具调用和流程编排。工具在本体层定义，而不是在 Agent 层——Agent 能用什么工具、如何触发、执行流程是什么，全部由本体决定。这一层是整个系统的知识底座，可持续演化。

认知引擎层（翻译与仲裁） 在本体和 Agent 之间做桥接，是连接两者的翻译和仲裁层。核心作用有两个：一是在 Agent 启动前，从本体中读取当前场景相关的领域知识——包括实体关系、业务规则、可用工具——注入到 Agent 的推理上下文，让Agent 既知道「这个领域是怎么运转的」，也知道「我在这个场景下能用哪些工具、怎么用」；二是在 Agent 生成结果后，将结论拿回来与本体做约束校验，如果违反了本体定义的规则，打回让 Agent 重新推理。

Agent 执行层（任务执行者） 自主智能体产品层。接收用户任务，调用工具，生成结果，完成执行。这一层是纯粹的执行者——工具从哪来、怎么用、边界在哪，不是它自己决定的，而是由本体层定义、由认知引擎传递的。

数据流向：用户任务进来 → 认知引擎从本体抽取相关知识注入上下文 → Agent 在此上下文中推理和执行 → 结果回到认知引擎做本体校验 → 通过后才最终输出。本体不直接与 Agent 交互，而是通过认知引擎这个中间层发挥作用。

以制造场景中「工单产量变更须经审批」为例，完整执行链路如下：

（1）用户意图：「将工单 WO-2026-0312 计划产量从 500 调整为 800」

（2）认知引擎查询本体（LPG 图遍历）：

• 节点：WO-2026-0312，类型 WorkOrder，状态「已下达/未开工」

• 属性：变更幅度 60%，超过本体中定义的 20% 审批阈值

• Action 规则：超阈值变更，触发条件 requiresApproval = true

• 关系链：WorkOrderChange → approvedBy → [BOMEngineer, ProductionManager]

（3）约束校验：当前操作缺少 approvedBy 关系，校验不通过

（4）系统响应：

• 阻断直接写入

• 生成结构化错误报告，携带违反的具体规则节点和关系路径

• 自动创建审批任务，路由至对应审批人

• 操作意图写入审计日志，状态「待审批」

（5）审批通过后：补充 approvedBy 关系，重新校验通过，执行写入

3. 自动建模：分层处理与人机协同

企业级本体的冷启动成本是一个绕不开的现实问题。手工构建覆盖度足够高的本体，传统方式往往需要数周甚至数月，且需要专业的知识工程师主导。

Knora 的策略不是追求「一步到位的全自动」，而是分层处理、置信度驱动、人机协同兜底。结构化强、规律明显的任务（如字段到本体属性的语义映射、从本体元数据自动生成数据治理 DAG 流程）交给自动化；涉及业务语义判断、概念边界划定的任务不强求自动。系统对每个自动生成的结果打置信度分，高置信直接执行，中等置信推荐人工确认，低置信进审核队列——人工介入的位置是精准的，只处理真正模糊的部分。每次人工确认或修正的结果反馈回系统，持续优化后续的自动建模能力，随着行业模板积累和领域样本适配，人工介入比例逐步降低。

4. 实际落地情况

目前 Knora 在能源运输、电子制造、金融、安防领域已有落地案例。

能源运输领域，铁路综合检测报告生成智能体能够自动构建指标体系、生成检测报告，将原本需要 30 人 / 7 天整理数据写报告的工作，变为 3 人投入一天核对数据、智能体 30 分钟自动完成，效率提升超 70 倍。在安全隐患识别、检修计划生成、应急预案生成、应急资源调度等数十个场景中，已作为「数字员工」承担实际业务职责。

电子制造领域，围绕质量追溯、缺陷分析等核心场景，将依赖个人经验的人工流程转变为由精准知识驱动的自动化数字业务流。

07

结语

AI 进入企业的方式，正在发生一次根本性的分叉。

一条路是继续堆工具、攒 Prompt、做集成——Agent 能跑起来，但跑到哪里、跑出什么结果，没有人真正说得清楚。另一条路是先把业务结构建起来，让 Agent 在一张定义清晰的语义地图上行动——它知道边界在哪，知道规则是什么，知道每一步决策的依据是什么。

两条路的短期成本差距不大，但一年后、三年后的差距，将体现在每一个需要向监管解释决策的时刻，体现在每一次多系统协作出现语义混乱的时刻，体现在每一个 Agent 在关键节点「自信地做错事」的时刻。

企业 AI 的竞争，最终不是模型之间的竞争，而是谁先把自己的业务知识结构化。先跑通这个闭环的企业，积累的不只是一套系统，而是一个持续自我进化的业务智能底座——它会随着每一次 Agent 执行而变得更准确，随着每一次业务迭代而变得更完整。

真正的护城河，从来不是买来的工具，而是沉淀下来的认知。Agent 会被替换，模型会被迭代，但沉淀在本体里的业务认知不会，这才是值得现在就动手的理由。

分享嘉宾

INTRODUCTION

周士雄

悦点科技

研发负责人

哈尔滨工业大学软件工程本硕，资深系统架构师。曾主导设计实现百亿级数据采集平台及千万级 DAU 级服务系统，在海量数据实时处理、复杂系统设计方面经验丰富。目前专注于 LLM Agent 和 AI 融合应用的开发与工程化落地。

点个在看你最好看

SPRING HAS ARRIVED