当理解和使用业务知识的主体变成 Agent，企业本体应该如何构建、如何持续演化？这篇从构建方式和业务实践展开。
企业本体要做的，正是把业务中的对象、关系与约束统一表达，让人和 Agent 都能在一致的业务语义下使用它们。
Agent 时代的企业本体，需要是一套可以持续运转的业务表达系统：能被业务理解、能组织 Agent 的行动、能随业务不断演化、也能被治理和校验。
要支撑这套系统运转，企业本体的建设需要同时在三个层面做出重构：产品形态、迭代机制、工程基建。
火山引擎知识引擎VeKnow是「面向企业级智能Agent场景打造的知识统一管理和智能检索平台」，依托先进的大模型与大数据技术，对结构化与非结构化数据知识提供从数据接入、清洗加工、知识建模、智能挖掘到应用服务的全链路数据资产管理能力。
一、产品形态重构：从固定流程到能力组合
第一个层面，是产品形态的重构。传统做法通常是围绕功能动线来设计产品：先预设用户会怎么操作，再把每一步做成固定流程，用户按页面引导逐步完成任务，系统在每个节点提供对应功能。
但企业本体的构建恰恰相反，面对同一批业务资料，检索问答需要索引，关系推理需要图谱，按条目查阅则需要知识百科（Wiki），不同场景需要不同形态的知识资产。如果每一种需求都对应一套固定流程，场景越多，入口和路径就越复杂，维护成本会被推得越来越高。
知识引擎 VeKnow 提供了更贴合这类任务的“Agent Harness + 能力供给”范式：把读取、抽取、检索、关联、评测这些底层能力，封装成一组可以被 Agent 调用的算子和 CLI，人负责定义目标、在关键节点确认判断；Agent 根据目标、当前状态和反馈，自行决定调用哪些能力、以什么顺序组合。
这套范式的好处在于，同一组能力可以组合出完全不同的业务解法，需求变化时，不必重做整条流程，而是让 Agent 重新编排能力组合；同时，这种组合必须可控，人的修改要进入上下文，关键节点要保留确认，中断任务能够续做，失败步骤可以局部重试。灵活性和可控性同时具备，Agent 才能从“能演示”走向“能交付”。
二、迭代机制重构：既看修复，也查退化
第二个层面，是迭代机制的重构。产物更新了，并不意味着质量一定提升，一个新迭代版本可能修正了实体命名，却遗漏了原本抽取正确的关系，只看这次改好了什么，无法判断有没有把别处改坏，更麻烦的是，依靠人工逐条复核，根本撑不住持续、大规模的本体构建。
难点集中在三件事上。一是规模问题：实体与关系会不断增加，逐条核对会持续消耗人力；二是口径问题：如果没有明确标准，同一条关系在不同场景下可能得到不同判断；三是隐性错误：产物看起来格式正确、节点完整，并不代表业务事实真的准确。
要解决这些问题，迭代机制就必须变成一套可复验的闭环，知识引擎 VeKnow 提供了「可协作的本体构建」和「可持续优化的评测闭环」两大能力。
前者让系统自动读取权限范围内的企业知识，识别对象、属性、关系与约束，生成 Schema 提案并进一步完成实例抽取与本体构建；业务专家在 Schema、关键关系与冲突项等节点审核，Agent 根据修改意见更新上下文继续执行，每一项结果都保留与源材料的对应关系，方便复核和追溯。
后者把评测嵌入闭环，围绕业务目标确定评测集、标准答案和评价维度，产物与标准对照定位差距，修订后回到同一基准复测，既看修复也查退化，让企业本体可以在这样的迭代里持续演化。
三、工程基建重构：拆得开、调得动、收得住
第三个层面，是工程基建的重构。从一张订单里理清几件商品的归属，和从千万条订单里构建一张完整、一致的“商品—店铺—用户—交易”关系网，是两种难度完全不同的工作，文档一多，实体去重、跨文档关系对齐、长文处理、失败恢复，这些问题会同时冒出来。
比如，Excel 能做数据分析，但面对真正的海量数据，需要的是 Spark、Flink 这样的并行计算体系。知识编译面对的是同样的量级，想让它在企业海量资料上稳定、持续地跑起来，知识引擎 VeKnow 的工程底座必须做好三件事：
- 拆得开：面对海量资料，先按业务模块和文档类型，把工作切成大小合适的处理单元，让每一块都能被 Agent 稳稳消化，而不会因为一次吞得太多而出错。
- 调得动：成千上万个任务同时跑，系统能自己排队、分配资源、化解相互等待，让算力和大模型额度稳定地用在业务最紧要的那部分上。
- 收得住：跑完的结果要能合并、能对齐、能追溯到原文的具体位置；一旦出错，坏的那段可以单独补跑，前面做完的成果不会白费。
这些事做到位了，效果肉眼可见。在真实场景测试中，底层使用相同模型来处理同一批资料，VeKnow 知识编译相比通用 Agent 框架不仅耗时更低、Token 消耗更少，对关键信息的识别准确率也更稳定。底层能力扎实，本体建设才能更快、更稳地落到业务上。
四、落到业务：让本体构建更快、更贴近业务
当知识编译从方法论落成一套产品能力，成效最终会体现在两个层面。一个是效率，减少重复梳理和手工录入，缩短本体构建周期；另一个是效果，让 Agent 在更完整的企业知识上下文中做全局推理，主动识别风险、内容缺失与隐性关系，提升 Schema 提案的完整性和一致性。
先看效率方面。以某头部制造厂商的售后服务本体建设为例，涉及设备型号、零部件、维修工单、历史故障、工程师技能等多类对象和关系。传统做法下，这样一张本体通常需要两类角色协同：业务专家解释售后与保修的语义规则，本体建模工程师负责结构设计、人工填充和反复校验，工作在不同角色之间串行流转，既增加了协同成本，也拖长了交付周期。
引入知识编译后，系统直接读取服务手册、维修工单、BOM 清单与保修政策等资料，自动生成 Schema 提案、抽取实例、构建本体并基于评测集持续校验。业务专家不再逐项生产内容，只需审核关键结构和例外项，在资料较完整、业务边界清晰且审核及时的条件下，这张本体的交付角色由两类缩减为一类，周期由四周压缩至最快一周。
再看效果方面。以某零售集团为例，企业本体建模涉及商品主数据、促销规则、库存流转、门店与渠道等多个来源。人工建模往往受限于个人能够阅读和记忆的信息范围，面对分散在制度规范、业务文档、数据定义、历史案例与运行记录中的知识，需要逐份理解并建立关联，很容易受到局部视角影响，遗漏跨域约束、潜在风险和未显式表达的业务关系，比如某个促销规则与特定渠道的库存口径之间的隐性冲突。
Agent Native 的建模方式不一样，它可以通读权限范围内的相关企业知识，在统一上下文中理解对象、属性、关系与规则。有了全局视野，AI 不仅能生成结构，还能主动预判跨域冲突和潜在风险，识别应补充的对象、属性与约束，并挖掘散落在不同材料中的隐性关系，在源材料质量和人工审核机制有保障的前提下，Schema 提案更完整、更一致，也更便于评审与持续迭代。
从产品形态、迭代机制到工程基建，三层重构最终落在同一个目标上：让本体构建更快、更贴近业务。
本文由 AI图鉴自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。
How should the business itself be structured and continuously evolving when the subject of understanding and using business knowledge becomes Agent? This article is based on building approaches and business practices.
What the enterprise itself does is to give a uniform expression to the objects, relationships and constraints of its business, so that it can be used in consistent business terms.
The business essence of the Age of Agent requires a business expression system that is sustainable: it can be understood by business, it can organize Agent ' s actions, it can evolve as business evolves, it can be governance and validation.
To support the operation of the system, the construction of the enterprise ' s physical infrastructure needs to be re-engineered simultaneously at three levels: product form, iterative mechanism, and engineering infrastructure.
The Volcengine knowledge engine, VeKnow, is the "Knowledge Management and Smart Retrieval Platform for Enterprise-level SmartAgent Sites", which relies on advanced LLM and big data technologies to provide a full-chain data asset management capability for structured and non-structured data knowledge, from data access, cleansing processing, knowledge modelling, intelligence excavation to application services.
I. Product morphological reconstruction: from fixed processes to capacity combinations
The first dimension is the reprogramming of product patterns. Traditional practices usually focus on the design of products around functional action lines: pre-set the user ' s operation, then make each step a fixed process, the user is guided by page and gradually accomplishes the task, and the system provides a corresponding function at each node.
However, the construction of the enterprise itself is quite the opposite: in the face of the same business information, access to questions and answers requires indexing, relationship reasoning requires mapping, access by entry requires knowledge encyclopaedia (Wiki), and different scenarios require different forms of knowledge assets. If each demand corresponds to a fixed set of processes, the more scenes, the more complex the access and path, the higher the maintenance costs.
The knowledge engine VeKnow provides a more appropriate “Agent Harness + Capability Supply” paradigm for such tasks: reading, extracting, retrieving, connecting, assessing these bottom capabilities, encapsulating them into a set of algorithms and CLIs that can be used by Agent, who are responsible for defining objectives and confirming judgement at key nodes; Agent determines which capabilities are to be mobilized and in which order, depending on objectives, current status and feedback.
The advantage of this paradigm is that the same set of capabilities can be combined into completely different operational solutions, and when needs change, it is not necessary to re-engineer the whole process, but instead to re-engineer the Agent; at the same time, the combination must be manageable, with changes going into context, key nodes retained to confirm that the interruption of the mission can be continued, and the failure step can be partial retry. Flexibility and control are available, so that Agent can move from being able to demonstrate to being able to deliver.
II. Reconstruction of the iterative mechanism: both restoration and degradation
The second level is the reshaping of the iterative mechanism. The product has been updated, which does not mean that the quality has improved, and a new, iterative version may have modified the entity’s name, leaving out the correct relationship. It is only because of what has been changed this time, it is impossible to judge whether it has been done otherwise.
The hard part is on three things. The first is the size: the number of entities and relationships will increase and the number of people will continue to be consumed by article-by-article checks; the second is the calibre: without clear criteria, the same relationship may be judged differently in different contexts; and the third is the implicit error: the product appears to be in the correct format and complete, and does not represent a true accuracy of business facts.
To solve these problems, the iterative mechanism must become a repertoire of repertoire, with the knowledge engine VeKnow providing the two main capabilities of "coherent architecture" and " sustainable optimization of closed loops".
The former allowed the system to automatically read enterprise knowledge within the scope of permission, identify objects, attributes, relationships and constraints, generate Schema proposals and further complete the extraction and build-up of examples; business experts reviewed the Schema, Key Relationships and Conflicts nodes, and Agent continued to update context on the basis of modifications, each of which retained its correspondence with source material to facilitate review and traceability.
The latter embeds the assessment in a closed ring, sets the assessment set, standard answers and evaluation dimensions around the operational objectives, and the difference between product and standard control positioning, revises and reverts to the same benchmark, both for restoration and degradation, so that the enterprise's own body can evolve over time in such an iterative manner.
III. Architectural reconstruction: Dismantling, leveraging and capturing
The third level is the reconstruction of engineering infrastructure. The sorting of several items from an order, and the construction of a complete and consistent “commodity-store-user-trading” network from a million orders, are two very different kinds of work, with more than one file, physical heavyness, cross-document alignment, long text processing, and failure to recover.
For example, Excel can do data analysis, but in the face of real big data, what is needed is parallel computing systems like Spark and Flink. In order for it to run in a steady and continuous manner on the enterprise's big volume, the project base of the knowledge engine VeKnow must do three things:
- Dismantling: In the face of big information, cut the work into appropriate processing units by operation module and type of document, so that each piece can be digested by Agent, without making a mistake by swallowing too much at a time.
- Motivated: Thousands of missions run at the same time, and the system is able to line itself up, allocate resources, defusing each other ' s waiting lists, allowing computing power and LLMZ81Z to be used steadily in the most vital part of the business.
- Collected: the results of the run-off should be consolidated, aligned and traced back to the exact location of the original text; if there is a mistake, the bad part can be replaced by a single run, and the results of the previous run will not be wasted.
These things are in place. The effects are visible. In real scene testing, the same model is used at the bottom to process the same information, and VeKnow knowledge compilation is not only less time-consuming, less consumption of Token, but also more stable identification accuracy of key information than the generic Agent framework. At the bottom, robust capabilities will allow for faster and more stable physical development.
Getting down to business: making the home built faster and closer to business
When knowledge is translated from a methodological perspective into a set of product capabilities, the results will ultimately be at two levels. One is efficiency, reducing duplicate combo and manual entry, and shortening the built-in cycle; the other is the effect of having Agent do global reasoning in a more complete enterprise knowledge of context, proactively identifying risks, missing content and hidden relationships, and enhancing the integrity and consistency of Schema ' s proposal.
First, the efficiency aspect. In the case of post-sale service construction by a head manufacturer, for example, there are various categories of objects and relationships such as equipment models, spare parts, maintenance worksheets, historical failures, engineers ' skills, etc. Under traditional practice, such a body usually requires two types of role synergy: business specialists explain semantic rules for post-sale and warranty, home modeling engineers are responsible for structural design, manual filling and double-checking, and work flows between different players, increasing the cost of synergy and prolonging delivery cycles.
When knowledge is introduced, the system directly accesss information such as service manuals, maintenance manifests, BOM lists and warranty policies, automatically generating Schema proposals, extracting examples, constructing the body and continuously verifying it on the basis of assessments. Operational experts no longer produce content-by-sections, but only review key structures and exceptions, and the delivery role of this body has been reduced from two categories to one, from four weeks to the nearest week, provided that the information is complete, operational boundaries are clear and timely.
Look again at the effects. In the case of a retailing group, business-based modelling involves multiple sources, such as commodity master data, promotion rules, stock flow, door stores and channels. Artificial modelling is often limited to the range of information that individuals can read and remember, and in the face of knowledge dispersed in institutional norms, business files, data definitions, historical cases and operating records, needs to be understood and linked on a case-by-case basis. It is easily influenced by local perspectives, leaving out cross-domain constraints, potential risks and unexpressed business relationships, such as hidden conflicts between a promotion rule and inventory calibres from a given channel.
Agent Native is modelled in a different way by reading the relevant business knowledge within permission and understanding objects, attributes, relationships and rules in a unified context. With a global vision, AI not only generates structures, but also proactively predicts cross-domain conflicts and potential risks, identifies objects, attributes and constraints that should be supplemented, and explores hidden relationships scattered over different materials. The Schema proposal is more complete, consistent and easier to evaluate and sustain, subject to the assurance of the quality of source materials and manual auditing mechanisms.
From product formation, iterative mechanisms to engineering infrastructure, the three-tiered restructuring ultimately falls on the same objective: to make the building of the home faster and closer to business.
Auto-fetched and translated by AI Atlas. All rights belong to the original author.