四期实验之后，我们总结出企业 Agent 进入深水区的公式

过去两周，我们做了一组实验。

用小龙虾（OpenClaw）接上 Aloudata CAN 的语义层，从最基础的「上月销售额是多少」问起，一路做到库存全盘诊断、四象限分类、渠道风险分级、补货促销行动方案——四期视频，每一期给 Agent 加一层能力，看它能走多远。

录第四期的时候，Claude Code 源码泄露了。512,000 行 TypeScript，一个顶级 Agent 产品的完整工程图纸摊在桌面上。全世界都在解读它的架构。

这两件事让我们对一个问题有了比之前更清晰的判断：企业 Agent 到底怎样才能进入深水区？

不是猜的。是测出来的。

一、大多数企业 Agent 还在浅水区

Agent 框架的爆发力有目共睹。但走进真实的企业，现阶段大多数跑起来的 Agent 在做什么——发邮件、填表单、整理会议纪要、生成周报摘要、从 CRM 里捞条记录。

写代码和写文章确实提效了。除此之外？都是浅活。

这些场景有个共同特征：不碰企业的数据分析和决策。不是不想碰，是碰不了。

碰不了的原因，四期实验给了非常清晰的答案。

二、深水区的闭环

先说深水区长什么样。

我们第四期视频用了一个库存场景。一个真正有用的库存 Agent 应该做到：先拉出全品类的售罄率和库销比，交叉分析定位问题商品；然后基于分析结论推导策略——这批该清仓、那批该补货、折扣给几折、补多少件；最后调用业务系统的接口把方案推出去。

Agentic Analysis（自主分析）→ Agentic Strategy（推导策略）→ Agentic Action（执行动作）。人只在关键节点校准方向和确认执行。

四期实验下来，我们发现这个闭环能不能跑通，取决于四个因子。

三、一个乘法公式

企业 Agentic 深水区的效果 = 语义层（数据） × Skill × Agent 框架 × LLM

是相乘，不是相加。任何一层拖后腿，整个链路效果就被系统性压低。模型用了最好的，Agent 效果还是不行——不是模型的问题，是别的因子在打折。

接下来我们逐个拆解。

四、语义层：远不止「查数准一点」

Agentic Analysis → Agentic Strategy → Agentic Action 这个闭环要跑起来，有一个硬前提：Agent 每一步用的数据必须是确定的、可审计的、每次一致的，并且要高性能灵活获取。一旦数据不确定，所有 Agentic 能力都会坍塌。

第二期实验的数据很触目：同一个模型、同一个数据集，Text-to-SQL vs 语义层，五个最基础的取数问题——坪效差了 253 倍，连带率差了 38%，复购率差了一倍。而且 Text-to-SQL 同一个问题问两次，答案不一样。用公式的框架翻译：Text-to-SQL 把「数据」这个因子变成了随机数。一个随机数乘进公式，整个闭环不可信赖。

但如果语义层的价值只是「查数准一点」，它在公式里的权重不会这么大。真正让语义层成为企业级 Agent 刚需基础设施的，是实验环境里看不到、但企业场景中无法回避的几个问题。

第一，认知预算的硬性约束。

Claude Code 泄露的架构里，让我印象最深刻的不是它多强大，而是它多「节省」——工具定义按需加载，初始上下文只放名字和一句话简介；对话历史反复压缩蒸馏；大结果写磁盘，只给模型一个文件路径。整个框架超过一半的工程量花在「怎么少往 context window 里塞东西」。为什么？因为 context window 就是 Agent 的工作台，空间是死的。每塞一段无关信息，就在挤压 Agent 用来思考和推理的空间。Claude Code 的工程师拿着 200K token 的窗口都如此精打细算。

有人会提出「把指标定义写进 Skill」这个方案——它本质上是要求 Agent 用最稀缺的资源（认知预算）承担一本字典的工作。5 个指标没问题，50 个开始吃力，500 个直接崩溃。

改成字典检索好一些，定义不常驻 prompt，按需检索。但 Agent 拿到了正确的定义之后，还要自己把它翻译成 SQL。翻译这一步，就可能错。我们的简单实验就证明了这是个高概率事件（见视频第二期，坪效问题）。

而且真实企业动辄几百上千个指标，口径还不是一成不变的。字典里要持续维护语义的频繁变更，还要期待没有错漏，AI 一定能找到，查对。

语义层的做法则是定义即执行。Agent 不需要理解定义、不需要翻译成 SQL，它只说「我要坪效」，语义层直接返回结果。中间没有翻译环节，就没有遗漏的机会。Agent 的认知预算 100% 花在分析和决策上，0% 花在理解数据口径和拼装查询上。这才是跟 Claude Code 架构思路一致的方向——把不该 Agent 操心的事，从 Agent 的认知空间里彻底移除。

第二，谁来维护，谁来负责。

实验环境里数据集是固定的，表结构不会变，也没有「定义谁说了算」的组织问题。在企业里这些全是现实。

口径写进 prompt——定义散落在各个 Skill 里，开发者写的，业务不知道。某天坪效的口径变了，prompt 没人更新，Agent 用错误定义跑了两周才被发现。谁的责任？说不清。维护口径字典——好一些，至少集中了。但一份文档没有审批流、没有版本号、没有变更通知。业务改了定义数据团队不知道，数据改了实现业务不知道。

语义层产品做的事本质上不同——它不是一本字典，而是一套组织契约。每个指标有明确的 owner，定义变更有审批流和版本记录，每次查询记录使用了哪个版本的定义。业务定义口径、数据实现逻辑、技术保障执行——三方的责任边界清晰。当 Agent 基于错误数据做了一个坏决策，「谁的责任」不再是一个政治问题，而是一条可追溯的审计链——定义是谁批准的、什么时候改的、Agent 用的是哪个版本，全部有据可查。

没有这套机制，没有哪个业务负责人敢把 Agent 的分析结果直接用于经营决策——不是不信模型，是出了问题没人兜底。

第三，企业数据的真实复杂度。

实验用的是 6 张表、标准星型模型。企业不是。企业的数据散在不同的系统里，每个系统有自己的数据模型和命名习惯。一个「客户综合价值」可能要关联 CRM 的画像、ERP 的交易、WMS 的退货、客服的投诉。让每个 Agent 自己理解这些跨多表的关联和 join 路径，等于要求每个 Agent 各自重建一遍语义层——不现实，而且会产生 N 个互相矛盾的「私有语义层」。

而且企业数据源不是静态的。ERP 升级换表名，业务系统迭代加字段，数仓重构改分层——大企业里这是月度事件。Agent 直写 SQL，每次 schema 变更都可能让所有相关 Agent 同时失效。语义层在这里是稳定契约：底层表怎么变，上层语义接口不变。没有这层抽象，Agent 的维护成本随数据源数量和变更频率指数级增长。

再加上权限和合规——不同角色看到的数据边界不同，监管审计要追溯每次数据访问的完整链路。语义层是在语义级别做权限和审计的唯一归口。

第四：查询成本的语义级优化

企业数据量级和个人实验完全不同。所有 Agents 各自对着数据湖写 naive SQL，不考虑分区裁剪、不复用物化视图、不做查询路由，计算成本会失控。语义层因为理解业务语义，可以做查询级的优化——知道「月度收入」已经有物化好的聚合表就不再回扫明细表，知道「华北」的范围就能在查询计划中提前裁剪。这在单个查询上差异不大，但当多 Agent 协作架构下海量 Agents 每天发起成百上千万次数据请求时，语义级优化和无优化之间可能是十倍、百倍的算力成本差。

综上，语义层解决的不只是「查数准」——它同时解决了认知效率、数据确定性、组织权责、变更吸收、合规审计和查询成本优化。 这就是为什么它是公式中放大效应最显著的因子——不是锦上添花，而是没有它，Agent 根本上不了企业深水区场景的生产环境。

五、Skill：后两期实验的角色跃迁

第一期实验里，Agent 接上语义层后可以查数、看趋势、按渠道拆解。很有用，但每一步它给的都是一个数字。

第三期，我们给它装了四个分析 Skill——异常检测、趋势预测、压力测试、报告编排。Agent 从「报数」升级为「诊断」。回答的深度变了。

第四期是更大的跳跃。我们装了一个库存策略 Skill，里面不是更深的统计方法，而是供应链运营的决策框架——四象限分类、生命周期判断、季节匹配、折扣规则、补货优先级。

一句「帮我看看库存有没有问题」，Agent 跑完全盘扫描后输出了这些：5 个品类的四象限分类（畅销、滞销、过季、断货）；连衣裙被标了 P0 紧急清仓；裤子和上衣紧急补货；最终输出 19 个行动项的完整方案——清什么、补什么、折扣多少、补多少件、什么时候复查。

Agent 从数据分析师变成了业务策略师。变的不是分析方法的深度，是角色本身。

这两期实验验证了 Skill 在公式中的作用——分为两层：

底层是通用的分析能力：查指标、做异常检测、做分析。这些跨行业复用，可以快速标准化。

上层是场景编排：一个好的库存诊断 Skill，背后是供应链专家的分析方法论——先看什么、再算什么、怎么分类、最后输出什么建议。

编排型 Skill 的壁垒在哪里？不在代码。它的主体就是一个 .md 文件，复制很简单。但复制了也用不了——同一个库存诊断 Skill，换一家企业，库销比警戒线不一样、季节周期不一样、渠道策略不一样、甚至「滞销」的定义都不一样。企业认知不只是领域知识，还有行业特定的私域数据、组织架构、流程规范、甚至潜规则。编排层会差异化、行业化，这才是各家企业真正的壁垒。

当然，从实验到生产，Skill 管理本身也是一层不小的工程——企业级场景需要分类分级和权限控制、版本管理、变更审计链，以及 Skill 之间的冲突检测与依赖解析。这些 Skill 治理基础设施是从 Demo 走向生产的必经之路，篇幅所限不展开。

六、框架和模型：重要但正在被拉齐

大模型只会越来越强，模型很重要，但不是差异化的来源。两周的测试里让我最意外的，不是「好模型效果好」而是同一个模型，换一种框架和 Skill 配置，效果天差地别。

框架解决的核心问题是什么？管理 Agent 的认知预算——上下文窗口就这么大，好的框架让模型在有限的台面上高效调度。前面语义层那一节已经拆解过 Claude Code 架构在认知预算管理上的工程量——那些精细到几千 token 都要省的设计，说明框架绝对不是一层「胶水代码」。

把 Agent 效果不好归因于「模型不够好」，是最常见的思维惰性。

但 3 月 31 日之后，框架层的设计思想和工程模式不再是黑箱。框架的技术门槛正在被快速拉低，趋同是大方向。 但值得一提的是，从开源骨架到企业级产品之间仍有大量工程——运维稳定性、边界 case 处理、工具链生态——这些不在源码里，需要时间积累。

七、回到公式

企业 Agentic 深水区的效果 = 语义层（数据） × Skill × Agent 框架 × LLM

模型在进化，框架正在趋同，Skill 可以累积和迭代——这三个因子起码大于 0。但没有语义层，「数据」这个因子就是负数：Agent 基于错误数据自主推导策略、自主执行动作，结果比不做还糟。

当四个因子到位，深水区的闭环就能跑通：自主分析 → 推导策略 → 执行动作。我们在实验中已经看到前两环运转的样子。第三环——Agent 通过接口直接调用下游系统完成调价、补货、调拨——需要业务系统的开放和治理体系的成熟，更长期，但方向确定。

行业趋势已经非常清晰，Agent 正在从「人触发、单次执行」走向「持续运行、主动感知」。当 Agent 能主动发现异常，主动启动归因，主动建议策略调整，语义层提供的数据确定性就不再是「重要」，而是生死线。

企业 Agent 的天花板不是模型的智能，是脚下的基础设施。语义层保障数据确定性和认知效率，Skill 体系将领域专家的认知编码为 Agent 可执行的方法论。两者叠加，Agent 才能从浅水区走进深水区。

最后预告下，我们的 Aloudata Agent 正在大幅迭代，跑同样的场景，效果比小龙虾 Demo 好很多，它不仅基于最好的 Agent 框架思想，更结合了关键的企业级特性。敬请期待。

四期视频使用的 Skill 全部开源，任何人都可以复现。