4 月 22 日，蚂蚁百灵正式推出 Ling-2.6-flash —— 一款总参数量 104B、激活参数 7.4B 的 Instruct 模型。该模型主打“Token 效率（Token Efficiency）”，在保持竞争力智能水平的同时，更快、更省以及更适合大规模真实应用。

据权威三方评测 Artificial Analysis 数据，Ling-2.6-flash 展现了突出的 Token Efficiency 优势，以 15M output tokens 实现了 26 分的 Intelligence Index，在保持较强智能水平的同时，将输出消耗控制在相对更低的位置。相比部分依赖更长输出换取更高分数的模型，Ling-2.6-flash 在“智能表现”与“输出成本”之间取得了更优平衡。

对于开发者和企业场景而言，这种效率优势意味着更低的推理开销、更快的首字响应、更短的整体生成时延，以及更流畅的交互体验，满足在真实部署环境下对速度、成本与体验的综合要求。

Ling-2.6-flash 沿用了 Ling 2.5 的混合线性架构设计，这种高度稀疏化的 MoE 架构在硬件表现上优势明显。

• 在 4 卡 H20 条件下推理速度最快可达到 340 tokens/s

• Prefill 吞吐达到 Nemotron-3-Super 的 2.2 倍

• 在 Output Speed 测评中，Ling-2.6-flash 以 215 tokens/s 的稳定输出速度位列同参数级别模型的第一梯队

从 Token 消耗来看，Ling-2.6-flash 的智效比显著提升。

• 在 Artificial Analysis 完整测评中，Ling-2.6-flash 总消耗为 15M tokens

• Nemotron-3-Super 等模型达到或超过 110M tokens

• 这意味着 Ling-2.6-flash 仅用约 1/10 的 token 消耗完成了同类评测任务

Ling-2.6-flash 面向 Agent 场景进行了定向增强，在控制 Token 消耗的前提下，依然保持了极强的任务执行力。

• 模型在 BFCL-V4、TAU2-bench、SWE-bench Verified、Claw-Eval、PinchBench 等 Agent 相关基准上达到同尺寸 SOTA 水平

• 与此同时，Ling-2.6-flash 在通用知识、数学推理、指令遵循及长文本解析等维度保持优秀水准

API 定价方面，Ling-2.6-flash 输入每百万 tokens 定价 0.1 美元，输出 0.3 美元。

目前，Ling-2.6-flash 的 API 已正式向用户开放，并提供为期一周的限时免费试用。

• 用户可以通过 OpenRouter、百灵大模型 tbox 获取对应服务

• 据了解，该模型后续将通过蚂蚁数科发布商业版本 LingDT，服务全球开发者及中小企业

一周前，Ling-2.6-flash 的匿名测试版本“Elephant Alpha”上线 OpenRouter，上线以来，其调用量持续增长，连续多日位列 Trending 榜首，日均 tokens 调用量达 100B 级别，周增长超 5000%。

4 月 20 日深夜，Kimi K2.6 发布并开源。它最值得被探讨的，并非又赢了几个 Benchmark，跑分逼平乃至反超海外三巨头。这些数字反映的更多是理论上限，而非你我实际上手时的真实水平。

图注：K2.6 基准测试成绩。在 DeepSearchQA、SWE-Bench Pro 等核心 Agent 与代码评测项目中位居第一，在 Humanity's Last Exam 等博士级难度测试中持平或优于三巨头（GPT-5.4、Claude Opus 4.6 和 Gemini 3.1 Pro），整体成绩处于同级别模型的第一梯队。

K2.6 更现实的意义，还在于它抛出了一个关键命题：

当模型步入 Agent 时代，竞争内核已从“单次作答的灵光乍现”，跃迁为“多步执行的善始善终”。Agent 的价值不再停留于输出答案，而在于多步执行、对象管理、结构维护与增量更新中的系统承载能力。

这才是新一代模型真正的分水岭。

循此判断，笔者摒弃了常规的单点用例测试，转而借 Andrej Karpathy 的 AI Wiki 思路，设计了一组高承压任务。这套思路自 AK 大神在本月初提出，迅速出圈狂揽两千万曝光，被视为“检索增强的下一代范式”。

测试目的直指 Agent 底层能力：它能否超越单纯的“内容生成”，展现出将内容组织为结构、将结构推进为系统的建构能力。

比写代码难得多的任务

如果只是验证代码能力，最简单的做法是复现网页、写个应用。直接，出活快。但这测的只是局部优势，而非 Agent 的工作流承接力。

所以，Andrej Karpathy 的 AI Wiki 成了更优选。它表面是搭网站，内核却是一套知识编译系统。 这也正是它比普通 RAG（检索增强生成） 更难的地方。

图注：基于 K2.6 Agent 搭建的一套 Harness Engineering Wiki，已形成可检索、可路由、可写回的知识闭环系统，具备持续演化的工程知识库形态。效果可参见：https://f24e2z3zeghre.beta-ok.kimi.link/

很多人一听“AI 知识库”，认为还是老一套：切片、建索引、检索、生成。每次问答都从零开始，毫无沉淀。

而 AK 大神的破局点，正在于把“查资料”变成了“整理知识”，将无状态检索（即没有记忆，不留痕迹）推进为有状态编译。这体现在 Wiki 极清晰的三层架构上：

架构之外，更有精髓。AI Wiki 的真正价值，在于把知识系统的重心从“文档展示”转向了“对象构建”。原始资料喂进去，不直接吐长文，而是先拆解为主题、概念和来源，再织成一张可检索、可连接、可扩展的网络。

页面 UI 只是表皮，底层真正拷问的是：对象稳不稳？关系立不立得住？新信息进来，旧结构会不会崩？

但原版的 Wiki 思路不是没有短板：偏本地。它回避了线上系统的致命问题：对象如何持久化？增量如何接入？旧结构如何防覆盖？前后台如何同步？

所以，这一次我们不做简单复刻，而是将其从一套离线编译流程，改造为可在线运行、持续更新、前台可访问的知识网络。从离线走向在线，从生成走向系统。

这也天然地覆盖了当前 Agent 最该被检验的五大能力：

• 长链执行：持续推进，而非单轮结束

• 结构组织：拆为对象，而非停留于段落

• 系统维护：新信息入网，旧结构不崩

• 前台落地：组织成可用的界面，而非仅存于后台

• 任务拆解：规模扩大时，能否并行处理

为什么要用 K2.6 来测？

Kimi K2.6 值得测，恰恰在于它这次强化的几条主线，与这类任务高度重合。

从官方披露的信息看，K2.6 的提升并不只停留在参数和榜单，而是明确落在了三种更接近系统任务的能

力上：长链执行、Vibe Coding 与 Agent 集群。

先看长链执行。官方给出的案例里，K2.6 能在复杂任务中连续运行 12 小时以上、调用上千次工具、完成 4000 余行代码修改；在主动式 Agent 框架中，甚至给出了最长 5 天持续自主运行的能力描述。

这类指标的意义，不只是“它更耐跑了”，而是它开始具备承接持续任务的基本条件。

而 AI Wiki 恰恰不是一次性生成任务，它要求模型能够在对象抽取、关系组织、页面生成和后续维护之间不断往返。没有足够强的长链稳定性，这类任务很容易在中途塌掉。

再看 Vibe Coding。K2.6 这次另一条被明显强化的能力，是将代码、视觉理解与前端表达结合起来，直接交付专业级 Web 应用。对于 AI Wiki 来说，这一点并不只是“页面更好看”——它意味着模型不只要会整理知识，还要能把知识网络做成一个可浏览、可使用、可继续扩展的前台系统。

换句话说，AI Wiki 不是纯知识抽取任务，必须落地成可浏览、可交互的前台界面。这正是 K2.6 突出的强项。

最后是 Agent 集群。 官方披露，K2.6 的集群架构最高支持 300 个子 Agent 协同，并且明确强调了它在搜索、深度研究、文档分析和长文创作等任务中的协同能力。

这对于 AI Wiki 也非常关键。因为一旦输入资料一多，任务就很容易从“一个 Agent 持续推进”转向“多个 Agent 分工处理”。也就是说，AI Wiki 不只是一条长链任务，它天然也具备被 Swarm 化的潜力。

具体来看，这次任务至少包括四个关键环节：

1. 消化与编译（Raw Source → 结构化对象） 原始文本不能直接当正文展示，必须先被拆解、提纯，编译成主题、概念、对比关系与来源，形成结构化对象层。难点在于：多步骤信息处理中，模型的准确性和连贯性在这里最先暴露。

2. 联网与落地（对象层 → 可用前台系统） 基于编译结果生成 Topic 页、Concept 页、对比页、关系图谱，并保证页面之间形成跳转闭环。这考察的是 Vibe Coding 能力：结构能不能真正变成可用的产品。

3. 调用与反哺（知识问答 → 持续沉淀） 页面之间不只有链接，还要能表达相似关系、对比关系和来源回溯，把"页面集合"推进成"知识网络"。跨页面操作中的一致性，是这一步的核心考验。

4. 维护与演化（增量接入 → 系统自愈） 新资料进入后，系统要能继续触发编译，支持断链检查和重复概念识别。这测的不是一次性生成的惊艳，而是长程运行中的自我修复与持续生长能力。

此外，为更完整地观察 K2.6 在不同任务组织方式下的能力边界，这次测试并不只在一个执行环境中完成，而是分别考察了它在 单 Agent 、 Agent 网站 和 Agent Swarm （集群） 三种模式下的表现：

其中，单 Agent 作为基线，网页端 Agent 重点考察连续施工能力，Swarm Agent 则进一步测试复杂任务的拆解与协作组织能力。

单 Agent 基准：系统骨架成型，知识闭环待补

如果只给 K2.6 一个基础单 Agent 执行环境作为基准水平，它的表现可以概括为一句话：前台成型很快，系统感很强，但知识闭环最初并没有自然成立。

它最先兑现的，是两项能力。

这轮测试里，K2.6 最先体现出来的，不是单点页面生成能力，而是把复杂任务持续推进成一个完整原型的能力。围绕我们给出的要求，它先后完成了信息架构设计、对象层拆解、页面路由搭建和主要交互补全，逐步做出了 账号登录、工作台、知识索引、主题页 / 概念页、问答 / 洞察面板以及知识图谱 等核心模块。

从结果上看，这已经不是一个零散页面集合，而是一套具备明确结构和产品感的知识网络雏形。

这里最值得强调的，首先是它的 长链条任务能力。

AI Wiki 不是一次性生成任务，而是一个需要在资料输入、知识编译、页面生成、关系组织和后续维护之间反复往返的长链工作流。K2.6 在单 Agent 模式下，已经表现出了承接这类任务的基本稳定性：它不是完成一个页面就停，而是能沿着既有上下文持续往前推进，把任务一步步从“做页面”推向“搭系统”。

这一点很重要，因为如果没有足够强的长链稳定性，这类任务通常会很快退化成局部补丁，而无法积累成完整结构。

第二个更突出的优点，是它的 自我修复能力。

单 Agent 模式下，K2.6 并不是一开始就把所有链路都做对了，但它有很强的“沿着当前系统继续修”的能力：页面缺入口，就补路由；对象层不完整，就补实体；跳转不闭环，就补详情页；图谱数据不够，就继续补关系读取。

这种能力的价值在于，它不只是生成一次结果，而是能在连续上下文中维持系统状态，对已有结构做增量修正。这比“第一版就完美”更接近真实工程任务，也更能体现 Agent 的实际承接能力。

同时，K2.6 的 Vibe Coding 能力在这一轮里也相当突出。它不仅能把知识对象落成前台，还能迅速做出风格统一、结构清晰、适合展示的产品界面。换句话说，单 Agent 模式下，它已经证明自己不只是会写页面，而是能把抽象任务迅速组织成一个“像样的系统原型”。

当然，单 Agent 的边界也在这一轮里显露出来。最核心的问题不是页面是否成型，而是 知识链路不会随着页面一起自动成立。也就是说，前台可以很快搭出来，但知识编译、问答调用和沉淀闭环，初始状态下往往还需要继续补强。

更进一步：从单点执行到系统组织

单 Agent 已经给出了基线：它能把复杂任务压成系统原型。接下来的问题是，当执行环境增强，K2.6 能把任务推进多深？

从结果看，网页端 Agent 和 Swarm 模式都带来了明显提升，但方向截然不同：网页端 Agent 强化了对同一系统的连续施工与修正能力；Swarm 模式强化了对复杂任务的拆解、分工与编排能力。

4.1 Agent 网站模式：更强的连续施工能力

“Agent 网站”最突出的特质，不是多做了几个页面，而是能在 同一套系统上连续迭代。

图注：Agent 网站模式的体验入口

在测试中，它围绕既有知识网络持续补全：从编译管线、状态处理到知识图谱，始终保持了极强的上下文延续性。对于 AI Wiki 这类任务，最难的从来不是初版原型，而是多轮修改后系统不散架：对象层有没有被保留？逻辑有没有被延续？网页端 Agent 在这一点上表现出了真正的工程连贯性。

更进一步，它的核心优势在于 能不断重新识别系统的真实约束。

最典型的例子是登录与数据库的实现：它先按标准全栈思路做了认证和持久化，但部署后迅速察觉静态环境无法承载后端服务，于是果断切回本地持久化方案，把产品重新拉回可运行状态。

当然，它的边界也依然存在。Agent 网站模式的典型问题，不是不会推进，而是容易先把前台和交互做成立，再逐步追补底层链路。

4.2 Agent Swarm 模式：不再硬扛，开始组织系统开发

如果说网页端 Agent 是更强的执行器，那么 Swarm 模式带来的则是质的跃迁：它让 K2.6 尝试把任务本身组织成一个可拆分、可协作、可调度 的系统工程。

在测试中，Swarm 不再满足于修补现有网络，而是把开发过程抽象成了一套集群工作流：定义 Research、Architect、Compiler 等角色，制定流程模板、命令系统、状态机与消息协议，甚至做出了任务流可视化。

这种变化极其关键。AI Wiki 天然是多线程任务，研究、编译、生成、维护如果全压在一个 Agent 身上，长链路很容易出现崩溃。Swarm 给出的是系统工程的解法：不把所有事硬扛，而是先拆成角色，再组织成流程。

它的深层价值，在于极强的 抽象表达能力。它能把零散的开发过程，重写成结构化的方法体系——谁先做、谁负责、怎么流转、交付什么。这意味着它不仅在执行项目，更在生成一份可复用的“开发语法”。

能力形态开始从“完成一次任务”跃升为“为同类任务生成可复制框架”。

然而，Swarm 的边界也很清楚：方法论和协作框架做得漂亮，但具体执行细节未必同等扎实。不过这恰好印证了它的核心定位：它不是更强的执行模式，而是让复杂任务进入“可分工、可编排、可复用”状态的能力放大器。

4.3 三种模式，三层系统能力

将三种模式放在同一坐标系，比较三者各自最有代表性的 能力形态 与 能力本质 更为清晰。

从“单轮聪明”到“长链存活”

这轮评测下来，我越来越清晰地感受到：模型竞争的重心正在改变。

真正重要的，已经不只是回答得像不像、写得好不好，而是它能不能在真实任务里持续推进、持续修补，并最终把结果落成一个可用的系统。

单 Agent 搭骨架、Agent 网页通经络、 Agent Swarm 做编排，这不仅是对 K2.6 的能力测绘，更是行业下一阶段的预演。

Agent 时代，竞争深水区，已从“谁生成质量更高”转为了“谁的系统存活率更高”。

市场早已厌倦了单轮聪明的玩具。当下真正需要的，是三种硬核特质的系统融合：抗衰减的长链可靠性、遇阻即改的路径校准力、面向系统的结构编排力。

2026 年，智能体将在企业级应用中取得哪些实质性突破？点击下载《2026 年 AI 与数据发展预测》白皮书，获悉专家一手前瞻，抢先拥抱新的工作方式！

在企业数据版图内，生成式人工智能的演进已超越简单的聊天界面，迈入自主编排的领域。对金融机构而言，这项技术的前景在于弥合一个历史性鸿沟：一端是高度结构化的交易数据（如总账分录），另一端是非结构化文档的庞大存储库（如监管手册和 ERP 系统指南）。Snowflake Cortex 智能体代表了这一范式的根本转变，它提供了一个托管框架，用于构建不仅能检索数据、还能规划复杂任务、执行专用工具，并以高精度和可验证的引用综合生成洞察的智能助手。

Cortex 智能体框架：规划、工具调用与反思机制

从核心架构来看，Cortex 智能体本质上是一个编排引擎，其设计目标是在数据仓库的安全边界内，通过协同调用多个异构数据源，生成深度洞察结果。与标准大语言模型在面对复杂数据库模式时容易产生幻觉输出不同，Cortex 智能体遵循一套严谨的四阶段生命周期：规划、工具调用、反思与监控。

在规划阶段，智能体将自然语言查询拆解为若干逻辑子任务。它能够精准判断：当用户询问“净利润率”时，是否需要针对分类账执行 SQL 查询；而当问题涉及“会计科目计划表的配置前提”时，是否应转而检索 Microsoft Dynamics 365 Business Central 中的技术文档。

在工具调用阶段，智能体会激活特定的专业服务。针对结构化数据，智能体调用 Cortex Analyst 服务。该服务通过语义模型的理解，能够以超过 90% 的准确率将自然语言转化为 SQL 语句。针对非结构化数据，智能体则启用 Cortex Search，其采用混合检索机制，融合了基于向量的语义搜索与基于关键词的词法搜索。这一混合策略在金融领域尤为重要：一方面，对于“总账科目”这类精确术语，必须实现字符级精准匹配；另一方面，对于“收入确认政策”等宽泛概念，又需通过语义理解捕捉上下文关联。

在反思阶段，智能体对其所调用工具返回的结果进行评估。若发现数据不充分，或 SQL 执行过程中抛出异常，智能体将进行迭代调整——修正执行计划、切换备选工具，或向用户发起澄清性追问。这一闭环迭代流程确保了最终输出内容严格锚定于 Snowflake 中存储的真实数据，而非大模型自身的参数化记忆。

基础环境搭建与基于角色的访问控制

实施金融智能体需要严格的安全基础，以确保编排层遵循与金融数据其他部分相同的治理标准。Snowflake 通过特定的数据库角色和权限来管理对 Cortex 功能的访问。SNOWFLAKE.CORTEX_USER 角色提供对更广泛 AI 功能套件的访问权限，而 SNOWFLAKE.CORTEX_AGENT_USER 则是专门用于智能体特定操作的专用角色。

在专业的金融环境中，最小权限原则要求为智能体应用程序创建一个专门的、自定义的角色。必须授予该角色对其将要使用的特定数据库、模式（Schema）和虚拟仓库的 USAGE 权限，以及对智能体对象本身的 OWNERSHIP 或 USAGE 权限。以下实现展示了数据库基础设施的创建以及必要权限的分配。

-- 初始基础设施创建USE ROLE ACCOUNTADMIN;-- 为金融分析和智能体编排创建专用虚拟仓库CREATE WAREHOUSE IF NOT EXISTS FINANCIAL_AGENT_WH     WITH WAREHOUSE_SIZE = 'X-SMALL'     AUTO_SUSPEND = 60     AUTO_RESUME = TRUE;-- 用于金融智能的主数据库和模式CREATE DATABASE IF NOT EXISTS FIN_INTEL_DB;CREATE SCHEMA IF NOT EXISTS FIN_INTEL_DB.CORE;-- 为金融智能体创建自定义角色CREATE ROLE FIN_AGENT_ROLE;-- 将强制性的 Snowflake AI 数据库角色授予自定义角色GRANT DATABASE ROLE SNOWFLAKE.CORTEX_USER TO ROLE FIN_AGENT_ROLE;GRANT DATABASE ROLE SNOWFLAKE.CORTEX_AGENT_USER TO ROLE FIN_AGENT_ROLE;-- 授予标准资源使用权限GRANT USAGE ON DATABASE FIN_INTEL_DB TO ROLE FIN_AGENT_ROLE;GRANT USAGE ON SCHEMA FIN_INTEL_DB.CORE TO ROLE FIN_AGENT_ROLE;GRANT USAGE ON WAREHOUSE FINANCIAL_AGENT_WH TO ROLE FIN_AGENT_ROLE;-- 授予模式级别的创建权限，用于创建智能体相关对象GRANT CREATE TABLE, CREATE STAGE, CREATE VIEW, CREATE CORTEX SEARCH SERVICE, CREATE AGENT     ON SCHEMA FIN_INTEL_DB.CORE TO ROLE FIN_AGENT_ROLE;-- 将该角色分配给技术用户GRANT ROLE FIN_AGENT_ROLE TO USER <your user>;GRANT CREATE SEMANTIC VIEW ON SCHEMA FIN_INTEL_DB.CORE TO ROLE FIN_AGENT_ROLE;

这些权限的隔离是一项关键的安全控制措施。 通过确保智能体在 FIN_AGENT_ROLE 角色范围内运行，组织可以防止编排模型访问未经授权的数据或执行破坏性操作。此外，任何应用于基础表的行访问策略或数据脱敏规则都将被智能体的查询自动继承，从而维持一致的安全防护态势。

结构化数据架构：总账建模

要使 Cortex 智能体能够回答核心财务问题，底层数据库的结构必须反映财务报告的逻辑流程。《Microsoft Dynamics 365 Business Central 指南》强调，财务报告本质上是行定义（公式）与列定义（数据源）的“外积”。在 Snowflake 环境中，这体现为一种规范化模式，即中央总账分录事实表与科目、部门、区域等维度表建立关联。

一个高性能的财务模式通常包含：

• 事实表：存储交易流水记录（例如：总账、销售账）；

• 维度表：提供描述性属性（例如：会计科目表、成本中心）；

• 分类映射：将过账科目映射到更广泛的类别（例如：资产、负债、收入），以简化报表定义的复杂度。

USE ROLE FIN_AGENT_ROLE;USE DATABASE FIN_INTEL_DB;USE SCHEMA CORE;-- 维度：会计科目表CREATE OR REPLACE TABLE DIM_GL_ACCOUNT (    ACCOUNT_KEY INT PRIMARY KEY,    ACCOUNT_NO VARCHAR(20),    ACCOUNT_NAME VARCHAR(100),    ACCOUNT_CATEGORY VARCHAR(50), --资产、负债、收入、费用    ACCOUNT_SUB_CATEGORY VARCHAR(50),    ACCOUNT_TYPE VARCHAR(20) --  过账 或 页眉);-- 维度：组织结构CREATE OR REPLACE TABLE DIM_DEPARTMENT (    DEPT_KEY INT PRIMARY KEY,    DEPT_NAME VARCHAR(50),    REGION_NAME VARCHAR(50));-- 事实：总账分录CREATE OR REPLACE TABLE FCT_GL_ENTRY (    ENTRY_ID INT PRIMARY KEY,    POSTING_DATE DATE,    ACCOUNT_KEY INT REFERENCES DIM_GL_ACCOUNT(ACCOUNT_KEY),    DEPT_KEY INT REFERENCES DIM_DEPARTMENT(DEPT_KEY),    AMOUNT FLOAT,    DESCRIPTION VARCHAR(255));-- 插入示例财务数据以作演示INSERT INTO DIM_GL_ACCOUNT VALUES (1, '40100', 'Product Sales', 'Income', 'Sales', 'Posting'),(2, '60200', 'Travel Expense', 'Expense', 'Administration', 'Posting'),(3, '10100', 'Operating Cash', 'Asset', 'Cash', 'Posting');INSERT INTO DIM_DEPARTMENT VALUES (1, 'North American Sales', 'Americas'),(2, 'European Marketing', 'EMEA');INSERT INTO FCT_GL_ENTRY VALUES (1, '2025-01-15', 1, 1, 75000.00, 'Q1 Enterprise License Sale'),(2, '2025-01-20', 2, 2, 1200.50, 'Flight to London Conference'),(3, '2025-02-05', 1, 1, 45000.00, 'Mid-quarter software renewal');-- 确保美洲区域存在相应部门INSERT INTO DIM_DEPARTMENT (DEPT_KEY, DEPT_NAME, REGION_NAME) VALUES (3, 'US Enterprise Sales', 'Americas');-- 插入 2025年1月 特定产品销售收入-- ACCOUNT_KEY 1 对应上述配置中的 '产品销售收入'INSERT INTO FCT_GL_ENTRY (ENTRY_ID, POSTING_DATE, ACCOUNT_KEY, DEPT_KEY, AMOUNT, DESCRIPTION)VALUES (4, '2025-01-14', 1, 3, 125000.00, 'January Software License - Americas');--  再插入一条以验证后续的数据聚合效果INSERT INTO FCT_GL_ENTRY (ENTRY_ID, POSTING_DATE, ACCOUNT_KEY, DEPT_KEY, AMOUNT, DESCRIPTION)VALUES (5, '2025-01-28', 1, 3, 50000.00, 'January Consulting Services - Americas');

这种结构化的规范化处理是实现 Text-to-SQL 的第一步。通过显式定义主键和外键，数据架构师提供了 Cortex Analyst 所需的元数据，使其能够正确理解如何关联表以及如何准确聚合金额数据。

非结构化数据处理：摄取 Microsoft Business Central 指南

财务智能体的第二大支柱是其对非结构化文档的访问能力。Microsoft 关于 Business Central 财务报告的指南提供了有关会计科目表工作原理、总账预算重要性以及维度使用的关键上下文。为了让智能体能够“搜索”该文档，必须先对其进行摄取、解析和索引。

Snowflake 的非结构化数据管道涉及将文档上传至内部暂存区，使用 AI_PARSE_DOCUMENT 函数进行内容提取，然后对文本进行分块以便在 Cortex Search 中建立索引。AI_PARSE_DOCUMENT 中的 LAYOUT 模式对于财务手册尤为重要，因为它能保留表格和标题的结构完整性，而这些元素在软件指南中十分常见。

文档解析与语义分块

财务文档内容密集且高度依赖上下文。仅仅按字符数进行简单拆分往往会导致信息碎片化。因此，采用递归字符拆分——并优先考虑 Markdown 标题或换行符——可确保概念单元的完整性。

-- 为 Microsoft 手册创建安全的内部暂存区CREATE OR REPLACE STAGE MANUALS_STAGE     DIRECTORY = (ENABLE = TRUE)    ENCRYPTION = (TYPE = 'SNOWFLAKE_SSE');-- 用于存储已处理和分块文档内容的表CREATE OR REPLACE TABLE PROCESSED_MANUAL_CHUNKS (    FILE_ID TEXT,    FILE_NAME TEXT,    CHUNK_ID NUMBER,    CHUNK_TEXT TEXT,    METADATA VARIANT);-- 摄取管道逻辑（概念流程）-- 1.  将财务指南上传至 @MANUALS_STAGE-- 你可以从以下 URL 复制内容并导出为 PDF：-- https://learn.microsoft.com/en-us/dynamics365/business-central/bi-how-work-account-schedule

可以使用 Snowflake CLI 上传，或在 Snowflake UI 中导航至刚创建的暂存区，点击“+文件”上传 PDF。

-- 2. 执行提取与分块 SQL：INSERT INTO PROCESSED_MANUAL_CHUNKS (FILE_ID, FILE_NAME, CHUNK_ID, CHUNK_TEXT, METADATA)SELECT     MD5(relative_path) as FILE_ID,    relative_path as FILE_NAME,    c.index as CHUNK_ID,    c.value as CHUNK_TEXT,    PARSE_JSON(SNOWFLAKE.CORTEX.AI_PARSE_DOCUMENT(TO_FILE('@MANUALS_STAGE', relative_path), {'mode': 'LAYOUT'})):metadata as METADATAFROM     DIRECTORY(@MANUALS_STAGE),    LATERAL FLATTEN(input => SNOWFLAKE.CORTEX.SPLIT_TEXT_RECURSIVE_CHARACTER(        TO_VARCHAR(SNOWFLAKE.CORTEX.AI_PARSE_DOCUMENT(TO_FILE('@MANUALS_STAGE', relative_path), {'mode': 'LAYOUT'}):content),         'markdown', 1500, 200)) c;

使用 LAYOUT 模式可确保输出的 Markdown 格式能正确反映 Microsoft 指南的层级结构。通过保留“总账科目类别”与“总账预算”之间的区别，后续的搜索服务在智能体被问及报表设置问题时，能够提供更精准的上下文信息。

配置专用智能工具

Cortex 智能体不直接与原始数据表交互，而是通过工具进行交互。对于这个财务智能体，我们必须配置一个 Cortex 搜索服务用于手册查询，并配置一个语义视图用于账本数据。

文档的 Cortex 搜索服务

搜索服务为智能体提供"模糊"检索能力。它会创建一个混合索引，使智能体既能查找特定的技术术语（如"账户计划表"），又能理解语义相关的查询（如"如何计算账户组的小计？"）。

CREATE OR REPLACE CORTEX SEARCH SERVICE MANUAL_SEARCH_SERVICE    ON CHUNK_TEXT    ATTRIBUTES FILE_NAME    WAREHOUSE = FINANCIAL_AGENT_WH    TARGET_LAG = '1 day'    EMBEDDING_MODEL = 'snowflake-arctic-embed-l-v2.0'AS (    SELECT CHUNK_TEXT, FILE_NAME FROM PROCESSED_MANUAL_CHUNKS);

TARGET_LAG 参数在财务系统中是一项关键配置。虽然对于静态手册而言，设置为 '1 day' 通常已足够，但对于文档更新更频繁的组织（例如每日市场研究报告），可以选择更短的间隔，以确保智能体的知识库保持时效性。

财务分析的语义视图

Cortex Analyst 在自然语言与 SQL 之间架起了桥梁。语义视图是一个模式级别的对象，用于定义数据的业务逻辑。它将物理列映射到业务术语，定义"净收入"等指标，并建立账本与维度表之间的关联关系。

CREATE OR REPLACE SEMANTIC VIEW FINANCIAL_INTELLIGENCE_VIEWTABLES (    ledger AS FCT_GL_ENTRY PRIMARY KEY (ENTRY_ID),    accounts AS DIM_GL_ACCOUNT PRIMARY KEY (ACCOUNT_KEY),    departments AS DIM_DEPARTMENT PRIMARY KEY (DEPT_KEY))RELATIONSHIPS (    ledger (ACCOUNT_KEY) REFERENCES accounts,    ledger (DEPT_KEY) REFERENCES departments  )DIMENSIONS (    accounts.ACCOUNT_NAME AS account_name        WITH SYNONYMS = ('Product Sales', 'Travel Expense', 'Revenue Type')        COMMENT = 'The formal name of the GL account',        accounts.ACCOUNT_CATEGORY AS account_category        WITH SYNONYMS = ('Category', 'Classification'),    departments.DEPT_NAME AS dept_name        WITH SYNONYMS = ('Department', 'Cost Center'),    departments.region AS REGION_NAME        WITH SYNONYMS = ('Region', 'Geography', 'Location')        COMMENT = 'The geographic area like Americas or EMEA',    ledger.POSTING_DATE AS posting_date        WITH SYNONYMS = ('Transaction Date', 'Date'))METRICS (    ledger.total_amount AS SUM(ledger.AMOUNT)        COMMENT = 'The absolute sum of the ledger entries',        ledger.net_sales AS SUM(CASE WHEN accounts.ACCOUNT_CATEGORY = 'Income'       THEN ledger.AMOUNT ELSE 0 END)        WITH SYNONYMS = ('Total Sales', 'Revenue', 'Gross Income')        COMMENT = 'Total revenue from income-categorized accounts',        ledger.total_opex AS SUM(CASE WHEN accounts.ACCOUNT_CATEGORY = 'Expense'       THEN ledger.AMOUNT ELSE 0 END)        WITH SYNONYMS = ('Expenses', 'Opex', 'Spending')        COMMENT = 'Total operating expenses');

在语义视图中加入诸如 net_sales 和 total_opex 这类具体指标，可以防止大语言模型尝试从零开始计算这些数值——这正是许多 AI 产生幻觉的环节。通过在语义视图内用 SQL 定义业务逻辑，组织能够确保智能体提供一致且可审计的结果。

构建金融智能体对象

最后一步是编排层。CREATE AGENT 命令定义了智能体的思考方式、应使用的工具集以及必须遵循的规则约束。该过程通过基于 YAML 的规范文件实现，其中详细描述了编排模型、工具配置及系统指令集。

一个成熟的金融智能体必须具备处理模糊查询的明确指引。例如，当用户询问“我们在差旅上花了多少钱？”时，智能体应调用 Analyst 工具；而当用户询问“差旅费用的报销政策是什么？”时，则应切换至 Search 工具。

本次我们将通过 UI 界面创建智能体。

1.确保你已被分配至 FIN_AGENT_ROLE 角色；

2.导航至 AI/ML => Agents，点击 ‘Create agent’ 按钮；

3.在描述字段中可填写类似内容：“精通总账分析与 Microsoft Dynamics 365 BI 指引的专家智能体”。

示例问题建议：

• 2025 年 1 月美洲区域的产品销售总额是多少？

• 根据 Business Central 指南，新建科目附表的前提条件有哪些？

• 欧洲市场部差旅费用为 $1,200.50 美元，此入账是否符合文档中“行政管理”子类目的准则？

4. 接着切换至 ‘Tools’ 标签页，添加该智能体可调用的两个工具：

添加 Cortex Analyst 工具：

添加 Cortex Search 工具：

现在两个工具已就绪，你可选择在新标签页中分别打开它们：

你还可以添加经过验证的查询语句：

完成后，请务必保存智能体配置：

点击 ‘Preview in Snowflake Intelligence’：

你将看到刚创建的智能体聊天界面，并附带已添加的三个示例问题：

点击任意问题即可获取回答：

你还可以继续追问后续问题：

现在，让我们测试对文档库的搜索功能是否生效：

尽管这只是基础演示，但其底层技术架构可扩展至更复杂的业务场景。

附注：该智能体同样支持通过代码方式创建：

ALTER AGENT FIN_INTEL_DB.CORE.FIN_AGENT  MODIFY LIVE VERSION SET SPECIFICATION = $$    models:      orchestration: auto    tools:      - tool_spec:          type: cortex_analyst_text_to_sql          name: FinanceAnalyst          description: "Provides access to the general ledger, account totals, and sales metrics."      - tool_spec:          type: cortex_search          name: GuideSearch          description: "Searches the Microsoft Dynamics 365 Business Central BI documentation."    tool_resources:      FinanceAnalyst:        semantic_view: "FIN_INTEL_DB.CORE.FINANCIAL_INTELLIGENCE_VIEW"        execution_environment:          type: warehouse          warehouse: FINANCIAL_AGENT_WH      GuideSearch:        name: "FIN_INTEL_DB.CORE.MANUAL_SEARCH_SERVICE"        max_results: 5  $$;

策略指令与工具选择

智能体的效能高度依赖于编排指令。这些指令在大语言模型（LLM）的规划阶段起到指引作用。通过定义“何时使用”与“何时禁止使用”的规则，数据工程师可以防止智能体调用搜索服务来回答数学问题，从而避免性能低下及潜在的答案错误。

生命周期管理：交互、线程与 API 集成

部署完成后，Cortex 智能体可通过 REST API 集成至自定义应用程序中，或是在 Snowsight 智能体演练场进行测试。智能体 API 的一项关键特性是利用“线程”来持久化对话上下文。在财务分析场景中，用户很少只问一个问题；他们会进行多轮的数据探索（例如：“总营收是多少？”紧接着问“按部门拆分一下”）。

REST API 工作流程

为了维持对话连续性，客户端应用程序必须跟踪 thread_id 和 message_id。工作流程遵循以下可预测的顺序：

• 初始化：发送带有 parent_message_id: 0 的请求以开启一个新线程；

• 追踪：API 会流式返回元数据，其中包括每轮对话唯一的 message_id；

• 继续：若想继续对话，下一次请求必须将上一次成功的助手消息 ID 作为其 parent_message_id。

这种机制使得智能体能够记住先前计算出的数值（例如第一季度的营收总额），并应用后续的筛选条件（例如“仅显示该总额中 EMEA 地区的部分”），而无需重新执行整个思考过程。

性能优化与高级配置

对于企业级的财务智能体而言，仅靠简单的配置往往是不够的。大容量环境需要对检索和生成阶段进行优化，以确保回答的准确性与成本效益。

多索引检索与权重提升

如果金融知识库的规模增长至包含数千份文档（例如，历史 10-K 财报文件、内部审计报告及 ERP 手册），单一搜索服务的性能可能会出现下降。Snowflake 支持多索引检索，使智能体能够借助“特定索引权重提升”功能，同时对不同数据源进行检索。

例如，数据架构师可能希望优先检索“官方政策”文档，而非“会议记录”数据。为此，可为政策索引赋予更高权重，从而确保当智能体被问及差旅指南时，会优先查阅官方手册，而不是先去查看某条随机的客服工单。

已验证查询知识库 (VQR)

Cortex Analyst 内置了“已验证查询知识库”（Verified Query Repository, VQR），管理员可将特定的自然语言问题映射至人工编写且经过验证的 SQL 查询。在金融领域，出于监管要求，某些指标必须绝对精确地计算，此时 VQR 充当“黄金路径”。例如，当用户询问“我们当前的资产负债率是多少？”时，VQR 会确保智能体执行由财务团队核准的精确 SQL 查询，从而完全绕过大语言模型的查询生成逻辑。

金融 AI 编排中的安全性与隐私保护

金融行业属于监管最严格的领域之一，AI 的应用引发了数据泄露与隐私方面的担忧。Snowflake Cortex 智能体采用“安全优先”的架构设计，确保数据始终不离开 Snowflake 的治理边界。

• 仓内推理：与需要将数据发送至第三方 API 的外部 AI 服务不同，Cortex 智能体直接在 Snowflake 虚拟仓库内部执行模型（例如来自 Mistral、Meta 及 Snowflake 自身的模型）；

• 基于角色的访问控制与策略传播：若用户因行访问策略限制而无法查看“人力资源”相关支出，智能体自然也无法检索或计算这些数据。智能体生成 SQL 的能力受限于执行角色的权限；

• 数据脱敏：尽管智能体可利用元数据生成 SQL，但会严格遵守对包含敏感信息（如员工薪资或特定客户姓名）的列的脱敏规则。智能体的最终回复仅展示脱敏后的数据，从而防止未经授权的信息泄露。

金融工程智能体实施最佳实践

为确保金融智能体的长期成功，实施团队应遵循以下若干最佳实践：

• 描述性命名规范：工具名称应采用“领域”（如“Ledger/总账”）加“功能”（如“Analyst/分析师”）的组合方式。避免使用“Tool1”或“Search”等含义模糊的名称，以降低编排过程中的错误概率；

• 详尽全面的描述：每个工具的描述应明确说明其覆盖的数据范围，更重要的是，应指出其无法处理的内容。明确“禁止使用场景”有助于清晰划定能力边界；

• 语义模型定期迭代：金融术语会随时间演变。语义模型应持续更新同义词与样本值，以帮助大语言模型识别新的会计科目或产品线；

• 引用来源校验：开发人员应监控智能体的推理过程事件，确保引用标注正确生成。引用是建立专业用户信任感的核心机制。

智能体在金融领域的未来展望

Cortex 智能体的部署，标志着金融智能新时代的开启。通过从静态仪表盘向对话式编排的转变，企业能够赋能团队，以思考的速度获取答案。将 Microsoft Business Central 智能指南与总账进行集成，仅是迈出的第一步。未来，这些智能体的迭代版本将能够通过外部 API 接入实时市场数据，借助自定义工具（如用户定义函数 / 存储过程）自动生成审计日志，并利用“数据转图表”功能生成复杂的财务可视化内容。

随着技术的不断成熟，“人在回路”模式仍将发挥关键作用，但财务分析师的职责将从数据收集转向更高层次的战略决策。Cortex 智能体作为效能倍增器，承担繁重的数据检索与解读工作，使专业人员能够专注于数据背后的深层影响。在精准度要求极高的金融领域，构建一个受管控、透明且根植于组织特有数据的智能体，不仅是一种技术优势，更是一种战略必需。

如需获取更多与 Snowflake 相关的文章更新，欢迎在 Medium 上关注我：Eylon's Snowflake Articles。

我是 Eylon Steiner，Infostrux Solutions 工程经理兼 Snowflake 数据超级英雄。您也可以在 LinkedIn 上关注我。

请通过 https://blog.infostrux.com 订阅 Infostrux Medium 博客，获取最新前沿的数据工程与 Snowflake 资讯。欢迎通过 GitHub关注 Infostrux 的开源项目动态。

原文地址：https://medium.com/snowflake/architectural-orchestration-of-financial-intelligence-implementing-snowflake-cortex-agents-for-4349df4057b2

点击链接立即报名注册：Ascent - Snowflake Platform Training - China，更多 Snowflake 精彩活动请关注专区。

2050 大会倒计时 2 天！

⏰活动时间 | 2026 年 4 月 24 日-26 日

🏠活动地点 | 杭州市云栖小镇国际会展中心

今年的 2050 有点狠：两天一夜，130+场论坛、500+分享者，从早 8 点一路讲到深夜。

全球最有趣的年轻开发者、创客、AI 爱好者将齐聚杭州。

截至 4.22 18:00

这里刻意去掉了大会常见的那套：没有主办方架子、没有 Logo 墙铺满、没有 VIP 标签。所有人统称“自愿者”，人人买票入场。这里有对科技的热爱，以及更纯粹的快乐。

2050 大会，王坚院士在 2018 年发起的一场年面向年轻人的“科技乌托邦式聚会”，极客邦科技创始人兼 CEO 霍太稳（Kevin）也是最早的共创者之一。

今年，极客邦科技依然深度参与，旗下模力工场和 TGO 的鲲鹏会的伙伴们，为了能在 2050 大会上以更丰富有趣、更意思的方式与大家见面，我们几乎拼尽了全力、绞尽了脑汁。

参与我们的本次系列活动，你可以得到：

• 实用好玩的 AI 工具+保姆级指南

• 加入高手云集的 AI 社区，随便聊聊都可能打开新思路那种

• AI 现场为你特调的小酒或饮品

• 我们认真打磨、经过多轮头脑风暴设计出的精美周边

• 不只是技术，还有踢足球、看演出、晨读等活动，顺便认识一群有意思的人

• ......更多彩蛋，欢迎来线下解锁哦～

如果你还不清楚如何报名，或者对交通食宿不够明白，请往下看！

参与方式 &大会议程

1. 首先，进入 2050 活动现场，每人需要一张 2050 的唯一通行证：2050PASS。

关于价格，看起来有点奇怪：

• 三日 2050PASS：330 元

• 单日 2050 PASS：660 元

(以上费用不包含餐饮和住宿)

为什么待三天反而更便宜？因为发起者鼓励你三天两夜都留在 2050，留出足够的时间，和更多有趣的“年青人”认真见面交流。

获取 2050PASS：

了解更多活动信息，抽取 2050 门票，回复“2050 抽取门票”：

1. 今年的 2050 大会有多个“活动容器”：新生论坛、探索空间、热点雨林、思想约会、青春舞台、热力运动、百城味道、星空露营……每个容器里，都装着多个由自愿者（模力工场和 TGO 鲲鹏会也是是自愿者之一）发起的活动。

总览日程如下：

大会地图：

如何在 2050 大会找到我们？

今年，模力工场和TGO鲲鹏会，准备了更丰富有趣、更意思的活动和超多礼品，欢迎全网科技爱好者来玩！

4 月 24 日（周五）

• 14:00–16:00｜足球争霸赛

• 地点｜云栖小镇国际会展中心 足球场

来一场不太严肃、但可能很上头的 5 人制足球局：不管你是技术流还是气氛组，都可以上场跑两脚、顺便认识一群同样好动的人。

2018 年首届 2050 大会足球争霸赛

• 18:00–21:00｜TGO 鲲鹏会学员欢迎晚宴

• 地点｜老桐庐 1977 餐厅（转塘店） 包厢 1-3

这一顿不只是欢迎，更是一次轻松认识彼此的机会：边吃边聊，说不定就聊出下一次合作或灵感。

4 月 25 日（周六）

• 6:30-8:00 | 带上喜欢的文字，一起晨读吧

• 地点｜云栖之眼附近草坪

放下手机，放下短视频，放下 AI，只带来你心爱的篇章。迎着朝阳，一起放开嗓子，用声音，和彼此的默契，感受文字的美好。

形式：

1. 我们根据大家的喜好，提前准备好要晨读的篇章，打印少许

2. 现场三五个人一份，有喜欢相应篇章的同学带头晨读，依次循环

• 9:00-18:00｜ “你得了 AI 病 · AI 职场心声站”展台

• 地点｜云栖小镇国际会展中心二期 探索空间

不只是看展，这是我们精心准备的超好玩 AI 应用体验区，当然，还有一些好东西可以免费带走！

你可以从抽一张 AI 工具卡开始：30 秒带走一个真能用的 AI 应用，说不定正好解决你最近的小问题。

（共 14 款，看你能抽到哪款～）。

接着再玩点不一样的：AI 可以给你做一枚专属徽章；还可以根据你的心情和描述，来一杯 AI 现场特调酒（或其他饮品）。

也可以停下来写点你对 AI 职场的想法：在“打工人实录”和“早日退休”两棵树上尽情吐槽（要夸也行）👉 说不定你的内容，还会被做成开源 Skill。

还可以获得我们原创设计的模力工场周边手提袋哦～

• 14:00-16:00｜ 亲子时光微电影专场

• 地点｜云栖小镇国际会展中心 A 区 2-3 夹层楼 地球基地

你可以和孩子把一段回忆、一个小故事，现场变成一支属于你们的微电影。

从“看懂 AI 视频”到“亲手创作”，没有门槛，一步步完成一支 2 分钟亲子短片。作品会在现场大屏幕放映，把那些平时说不出口的瞬间，认真记录下来。

• 19:00 起｜ 合唱表演

• 地点 ｜ 云栖小镇国际会展中心 A 区 二楼 云栖厅

一群爸爸妈妈和孩子组成的合唱团～带来一首原创歌曲《一群无知少年的梦想》。“无知少年”是王坚院士提出的一个概念，非贬义，主要用于描述年轻人在面对未知世界时所具备的纯粹、开放与创造力。

这里的“少年”不仅指年龄上的青年，更指一种精神状态——充满好奇、不惧失败、愿意为理想投入。

2018 年 2050 创始届的青春舞台

4 月 26 日（周日）

• 6:30-8:00 | 带上喜欢的文字，一起晨读吧

• 地点｜云栖之眼附近草坪

（活动信息同上）

• 9:00-17:00｜ “你得了 AI 病 · AI 职场心声站”展台

• 地点｜云栖小镇国际会展中心二期 探索空间

（活动信息同上）

• 9:00-12:00 ｜ AI 社区怎么干？

• 地点｜云栖小镇国际会展中心 A 区 二楼 团聚基地

这次，我们想聊的，是一个更大的问题：AI 社区，到底该怎么做？

如果你对 AI 时代的社区怎么玩儿，有想法、在做相关事情，或者只是好奇未来的科技会怎么发展，都欢迎来聊一聊。

当然，还有一些精心准备的小礼物等你来拿～

到场攻略

交通指南

1. 公共交通指南

温馨提示：乘坐地铁的各位朋友，请在科海路站下车，B2 口出站

杭州萧山机场 - 云栖小镇国际会展中心

驾车：杭州萧山机场 - 云栖小镇国际会展中心；全程 42 公里，用时约 60 分钟；

地铁路线：萧山国际机场站乘坐【7 号线（吴山广场方向）】，奥体中心站下车站内换乘--【6 号线（双浦方向）】科海路 B2 口下车出站，下车步行 549m；

公交线路：萧山国际机场站乘坐【机场大巴武林门线】， 浙医二院公交站下车同站换乘--【39 路（里桐坞方向）】，九溪公交站下车同站换乘--【500 路（富阳客运南站方向）】，地铁科海路站（A 口）下车（机场大巴武林门线运营时间：24h）。

杭州东站 - 云栖小镇国际会展中心

驾车：杭州东站 - 云栖小镇国际会展中心；全程 30 公里，用时约 50 分钟；

地铁路线：火车东站（东广场）地铁站乘坐【地铁 6 号线（双浦方向）】，科海路地铁站 B2 口下车出站，下车步行 549m；

公交线路：火车东站西公交站乘坐【20 路（杭州陶瓷品市场方向）】--民安苑公交站下车同站换乘--【500 路（富阳客运南站方向）】--地铁科海路站（A 口）下车。

杭州西站 - 云栖小镇国际会展中心

驾车：杭州西站 - 云栖小镇国际会展中心；全程 30 公里，用时约 40 分钟；

地铁路线：火车西站地铁站乘坐【地铁 19 号线（永盛路方向）】，火车东站（东广场）地铁站下车站内换乘--【6 号线（双浦方向）】，科海路 B2 口下车出站，下车步行 549m。

1. 自驾指南

温馨提示：会场周边停车场资源非常紧张，建议选择公共交通或网约车出行。

🅿️停车场地址：云栖小镇国际会展中心地下停车场（导航至云栖小镇国际会展中心西门）

入场方式：凭 2050 金属 PASS 或 2050PASS 动态二维码入场，先到先得。出场前可到会场 2050PASS 领取处（服务台）领取停车券，免费停车。

住宿指南

目前，星空露营区已满员！请大家尽快就近安排酒店，我们为大家整理了一版信息供参考～

餐饮攻略

1. 会场内餐饮

百城味道：这里有全国（甚至是世界）各地的美食，还有不少免费试吃活动哦！

1. 会场外周边餐饮，详情见下方导览图

温馨提醒：会场周边外卖可送达地址 —— 杭州云栖小镇国际会展中心（南门）/（北门）。