本文反思了“知识库+Prompt工程+工具调用”这一轻量级Agent构建模式的局限性，指出其难以应对真实业务场景中的知识质量、语义理解与规模化维护挑战。（本文内容基于作者个人技术实践与独立思考，旨在分享经验，仅代表个人观点。）
回顾过去2–3年，AI演进速度堪比代码提交频率——快的甚至让人来不及写“注释”。在这波浪潮中，“AI Agent”迅速从学术圈的热词，变为企业转型的标配。无论是开源社区的 Demo，还是行业战略蓝图、企业产品更迭，“如何快速构建XX Agent以实现业务提质提效”成为行业共识命题。在此背景下，我们早期也自研数据Agent，试图用轻量级方式验证“智能体”的构建路径。彼时朴素认知是：“知识库 + Prompt Engineering（PE）+ Function Calling + Few-shot 示例这四件套拼在一起，就能召唤出一个能答会算的 AI 小助手。”
这套组合拳确实见效快，一度让我们产生了“人人皆可成为 Prompt Engineer”的幻觉。- 你发现取数工具还没cover到xx指标，“焕新补贴季”是个啥语义没ready……此刻，像极了产品经理在周五下班前发来的“小改动”需求，表面温和，实则致命。
我们意识到：Agent 不是乐高，它更像一辆自动驾驶汽车，光有方向盘（Prompt）远远不够，还得有高精地图（上下文）、传感器融合（工具链）和实时决策系统（推理闭环）
2.1 知识质量不可控：RAG 不是万能胶，乱贴会掉渣
早期普遍采用“原始文档切片 → 向量索引 → 重排序检索”的知识注入方式，虽能快速跑通端到端流程，但存在缺陷：
幻觉：模型基于不完整或错误上下文生成看似合理但事实不符的回答；
语义断裂：“优惠券叠加规则”被切成三片，每片单独看都合理，合起来逻辑崩坏，像极了if-else 嵌套超过三层的代码。切片粒度过细导致上下文逻辑割裂，影响推理连贯性；
召回缺失：关键信息因切分策略或嵌入偏差未能有效召回，造成答案遗漏。
2.2 元数据语义鸿沟：数据表看得见，但 AI 读不懂“黑话”
沉淀于ODPS、Hologres、数据湖等引擎中的元数据（如表字段、血缘关系、业务口径、指标定义），本质上是面向机器而非人类语言的符号系统。若直接用于RAG或工具调用，常导致模型“看得见数据，读不懂含义”。
要将其转化为AI可理解的语义资产，需进行深度语义对齐、本体建模与上下文增强，而这一过程高度依赖人工梳理与领域知识注入，初期人工成本较高。我们不是缺数据，是缺“能让 AI 看懂的数据说明书”。
2.3 Prompt Engineering 的规模化瓶颈
尽管PE被视为Agent开发的“第一生产力”，其效能却严重依赖工程师经验，实践中呈现两极分化：
2.4 Agent 链路过简：防御式设计 vs 开放性悖论
为了防幻觉、保稳定，一些Agent加了“安全带”：前置意图识别、输入过滤、结果校验、CoT 强引导……甚至限制用户提问自由度。效果是稳了，但 Agent 也变得“死板”了——像极了客服机器人：“亲，您的问题已记录，请稍后联系人工.....”
简化链路虽能短期控险，却牺牲了 Agent 最宝贵的泛化能力与探索精神。真正的智能，应该在可控与开放之间走钢丝。——By AI
三、范式跃迁：从Prompt-Centric走向Context-Aware
上述问题共同指向一个核心认知转变：以Agent应用为中心的开发范式正在经历双向演进。
3.1 向左延伸：从“Prompt驱动”到“上下文工程”
不再仅依赖提示词，而是构建高质量、结构化、可追溯的上下文语料体系，涵盖：
合规约束规则：明确哪些事能做、哪些红线不能碰，让 Agent 真正“懂边界”。
3.2 向右深化：从“搭积木组装”到“全链路闭环”
需建立覆盖以下环节的系统化能力：
Agent 的终极目标，不是“会说话的工具”，而是“懂业务、守规则、能扛事的数字员工”。
四、MktAI知识体系建设：让 AI “读懂”数字
基于上述认知，我们将重心转向以 Context-Aware 知识库体系建设。目标是：为大模型注入高信噪比、结构化、可推理的领域知识，使其在复杂中具备精准理解、可靠推理与高效生成的能力，降低系统性“幻觉”，提升AI决策的可解释性。
4.1.1 构建元数据知识体系：从“What”到“How & When”
不再满足于“这个字段叫什么”，而是回答：
- 怎么算？（例如：“商家公域到手价 = 基础价 - 可叠加优惠 + 排他规则校验”）
- 在哪用？（适用于活动全周期分析，不适用于单品粒度）
- 别乱用！（警示：此字段不含退款剔除，慎用于最终结算）
字段级语义富化成为标配，每个字段附带：
更进一步，引入正反例对比学习：
正例：SELECT brand, score FROM brand_tone_score WHERE activity='...' AND score=6 ORDER BY score DESC, brand ASC LIMIT 5反例：...WHERE score='6分'（枚举值匹配失败）
让模型在“对与错”的边界上学会判断。
4.1.2 血缘关系的语义化扩展
显式建模字段间的业务因果链，比如：
并支持跨表语义推理：当用户问“尖货商品的支付金额”，系统能自动关联商品表、活动表、订单表，避免因表隔离导致逻辑断裂。
4.1.3 元数据治理：开发即治理，AI 辅助评审
- 元数据AI代理评审：当新增或修改元数据（如定义一个新的“价格口径”字段）时，让7*24小时的AI助手帮你审核
4.1.4 数据保鲜：变更感知 + AI 自动填充
构建变更感知流程，监听 MaxCompute / Hologres 的 DDL/DML 变更，让AI帮你：
终于不用每次改个字段都要手动更新了——程序员的幸福感，有时候就这么简单。
4.1.5 模块化分析框架：把专家经验沉淀为“可加载插件”
将数科、运营专家分析经验进行知识下沉，形成可复用的分析模块，供不同Agent按需加载。
4.1.6 效果论证：准确率从 86% → 95%
我们以营销活动场景生成350+评测集。通过DataAgent引入元数据与黑话后，泛化取数（兜底）准确率从86%提升至95%。提升的不仅是数字，更是同学对 AI 的信任度
典型评测示例（含黑话，350+） | 准确率 |
统计2025年焕新补贴季活动中品牌调性分为6分的品牌名称及对应分值，按分值降序、品牌名顺序取Top5品牌 | 86%->95% |
统计2024年双旦活动期间各品牌的累计支付金额和支付订单数，按支付金额排序 |
统计2024年女王节抢先购现货活动期间尖货且为活动商品的支付金额总和、订单数，按金额排序，取Top5 |
统计2025年双十一期间每个商家分层的累计支付GMV和支付订单数，按GMV降序排列，取Top5分层 |
4.2 RAG 升级：从 Vector-Based 到 Reason-Based
面对 70% 的非结构化知识（文档、流程图、截图），继续探索RAG提升方案（Reason-Based RAG 架构）。
阶段1：层次化索引构建 —— 把文档变成 LLM 能“翻”的书
- 多模态理解：调用多模态模型自动解析图表、截图，生成结构化描述并回填原文；
- 结构化解析：基于Md等符号构建 ToC Tree，智能跳过代码块中的伪标题；
- 智能摘要：长文本由 LLM 生成摘要，强制高亮关键词（活动名、Toolcode、角色职责），输出两份视图：
阶段2：LLM 驱动的推理式召回 —— 让模型自己“翻目录找答案”
抛弃向量相似度，改由 LLM 扮演“文档专家”：
- 在search_tree中推理出最相关的N个节点；
- 若信息不足，可生成“扩展计划”（向上/向下/横向导航），构建完整推理链；
- 多文档并发检索，仅 Top-K 进入生成阶段，控制成本。
这不是检索，这是“AI 主动阅读 + 推理”。
方案优势与效果验证
在相同营销知识语料场景下进行对比评测：Reason-Based RAG在58条涵盖前N、预售、官方立减等子域评测集中表现相对更优。维度 | 表现 |
人工好评率 | 98%（vs 传统Vector-Based RAG ≈30%） |
精准性 | 提升准确回答定义类、规则类问题，避免无关干扰 |
完整性 | 提升跨文档、跨段落复杂查询，构建完整推理链 |
鲁棒性 | 对长尾问题、表达差异大的Query具备更好召回能力 |
如果说前文所述的结构化语义增强（4.1）和推理式RAG（4.2）是为AI Agent配备了高精度的“望远镜”和“显微镜”，那么本体，就像是为它绘制一张完整的、可导航的“世界地图”。这张地图的目的，不是让AI去“猜”业务规则，而是让它能像一个受过专业训练的新人一样，系统性地“学习”和“理解”这个数字世界的运行法则。为什么前两种方案仍是“治标不治本”？
想象一下，一个新入职的运营同学，如果只给他看无数个Excel报表（数据实例）和几百份活动SOP（非结构化文档），他可能会成为一个熟练的“操作工”，但很难成为一个能独立思考、举一反三的“分析师”。因为他缺少一个贯穿始终的概念框架——即，什么是“品牌”？什么是“活动”？“补贴”和“优惠券”是什么关系？“尖货”是如何被定义和圈选的？这些核心概念之间的逻辑关系构成了业务世界的“骨架”。没有这个骨架，AI面对“焕新补贴季活动中品牌表现如何？”这样的问题时，依然需要在海量的、孤立的知识碎片中进行拼凑和猜测。它知道“焕新补贴”是个活动，“品牌”是个实体，但它无法真正理解“活动”这个概念是如何作用于“品牌”这个实体的，也无法推导出“表现”背后可能涉及的指标体系（如GMV、订单数、调性分等）。这就是“数字世界已经是结果，但对于回答‘为什么’是不足的”这句话的深刻含义。本体论：为AI构建业务世界的“公理系统”
源自哲学，意指“关于存在的学问”。在计算机科学和AI领域，它被引申为对特定领域内概念、实体、属性、关系及其约束的正式、明确的描述。我们可以将其理解为一个领域的“公理系统”或“概念共识”。在MktAI知识库实践中，本体建设并非凭空创造，而是将散落在各个业务系统、数据表、文档中的隐性知识，进行结构化、标准化、形式化的沉淀。我们和架构师一起将本体要素进行抽象：1.对象类型：这是业务世界中的“名词”，代表具有唯一标识的实体。例如 Item（商品）、Brand（品牌）、Activity（活动）、ComparisonPool（比价池）....。每个对象类型都有其主键（Primary Key）和一组属性（Properties），如 Item 的 base_item_id、item_title、brand_id 等。这超越了传统元数据仅描述“字段名”，而是定义了“实体”本身。2.关系类型：这是连接不同对象的“动词”或“介词”，描述实体间的结构化关联。例如 ItemComparesWithItem（商品A与商品B进行比价）、ItemUsesDiscountTool（商品使用了某个优惠工具）。关系不仅有方向和基数，还可以携带自己的属性（如比价状态、使用时期），从而形成一张富含语义的知识图谱。3.动作类型：这是业务世界中的“操作”或“函数”，代表可执行的计算或流程。例如 QueryComparisonStatus（查询比价状态）这个动作，其输入参数是 ComparisonPool 这个对象。这确保了所有操作都根植于本体之上，而非游离在外的黑盒。Action的定义包含了详细的计算逻辑、SQL模板和重要规则，使得AI不仅能“理解”要做什么，还能“知道”怎么做。通过这三者的有机结合，我们构建了一个自洽、可推理、可执行的数字业务模型。当用户提问时，Agent的任务不再是模糊的“找答案”，而是精确的“在本体图谱上进行查询、分析和执行”。本体驱动的AI Agent：从“问答机”到“数字员工”
有了本体这张地图，AI Agent的能力实现了质的飞跃：- 精准理解：面对“焕新补贴季”这个短语，Agent能立刻识别出这是一个 Activity 类型的实例，并能关联到其包含的 Item、使用的 DiscountTool 等。
- 可靠推理：当被问及“尖货商品的支付金额”时，Agent能通过 Item -> is_featured_item (属性) 或 Item -> BelongsTo -> FeaturedPool (关系) 找到尖货，再通过 Item -> HasOrder -> Order (关系) 找到支付金额，整个过程基于预定义的逻辑链路，杜绝了臆测。
- 高效执行：当需要生成复杂查询时，Agent可以直接调用 QueryComparisonStatus 这样的Action，传入正确的 ComparisonPool 对象，即可获得格式化、合规的结果，无需再进行脆弱的Prompt工程。
效果验证与持续演进
我们在300+的评测集上对本体驱动的Agent进行了验证，结果如下：
评测场景 | 指标 | 当前最佳值（%） |
购后价格场景评测集 | 归因合理性 | 89% |
本体召回率 | 82% |
推理完整性 | 89% |
大促价格管控场景评测集 | 归因合理性 | 94% |
本体召回率 | 90% |
推理完整性 | 92% |
实践证明，本体化方法提升了在复杂业务场景下快速冷启的推理能力，同时通过白盒化本体路径推理和约束，也有效抑制了模型“幻觉”和修正。这条路，我们仍需坚定地探索验证下去。回望这段从“Prompt-Centric”到“Context-Aware”，再到“Ontology-Driven”的探索历程：AI应用的繁荣，尤其数据同学要深刻重视知识工程的深厚土壤。现实告诉我们，没有高质量、结构化、可推理的领域知识作为基石，再强大的大模型也如同在流沙上建塔，终将陷入幻觉与不可靠的泥潭。如今，我们正将对数据模型的理解、对业务方法论的抽象——重新注入到AI应用的底层。不再仅仅是Prompt的调优者，更是数字&现实世界的建筑师。我们构建的不仅是知识库，更是一个能让AI自主学习、可靠推理、高效执行的数字孪生业务环境。
展望未来：与后训练、评测等技术的协调融合
这些经过验证的、高信噪比的结构化知识语料，天然具备更高的准确性与合规性，能进一步加速模型训练数据/评测数据的自动化合成，从而减少对复杂推理链路的依赖。
这，便是我们在AI浪潮中所追寻的“返璞归真”——回归到数据与知识的本源，以工程化的严谨，探索值得信赖的智能。
粤ICP备14082021号
免费POC，
零成本试错
