今天，阿里发布Qoder 1.0，从AI IDE升级为智能体自主开发工作台，用户只需专注需求定义，Agent团队即可“自动驾驶”，自主完成执行、验证和交付全流程任务。目前，Windows、macOS和Linux系统用户均可下载使用。

01

Quest独立视窗，

Agent-first开发台

Qoder 1.0将并行范围扩展至跨项目、跨代码库维度，开发者可在多个Workspace中同时运行不同项目的Agent任务，通过统一面板，实时追踪所有任务的动态。

每个Quest任务拥有独立的状态标签（运行中/等待确认/已完成），进度一目了然。开发者无需逐一切换窗口，一屏即可掌握全局进展。任务完成后，系统自动生成Summary交付清单，涵盖任务进展、产物文档和代码变更，供快速审查。

基于代码仓库，每位成员都可以贡献知识、修正知识，由智能体对知识进行持续优化。知识在云端统一存储，企业可以统一维护，并实现过程审计。个人的经验变成了组织的持续成长能力。

Experts专家团模式上线以来用户反馈积极。但此前仅支持在Chat侧边栏中使用，1.0版本将其正式引入Quest视窗。开发者可在Quest内自由选择单Agent模式或Experts专家团模式。专家团由规划、调研、编码、审查、测试五类专家组成，以流水线方式协同交付。

同时，1.0版本新增自定义专家能力。开发者可创建专属Agent团队，为其配置领域知识、任务技能和外部工具接口，打造贴合自身业务场景的Agent团队。

上述产品升级的背后，是底层Agent Harness的系统性重构。模型提供智能，Harness决定这份智能能否转化为可用交付。Qoder 1.0在此层沿两条路径完成升级：将传统聊天对话升级为结构化的任务运行时（Task Runtime），将分散的上下文供给收敛为贯穿运行时的知识工程（Knowledge Engineering）。

Qoder是面向全球开发者的智能体编程平台，旗下产品包括Qoder IDE、Qoder CLI、Qoder JetBrains 插件、Qoder移动端、QoderWork、QoderWake。自2025年8月上线以来，Qoder已服务全球超过500 万用户。

背景

随着 AI，尤其是 Generative AI（后文简称 GenAI）的快速发展，AI Agent 系统中涌现出大量新的核心概念，例如 Model、Prompt、Token、Tool Calling、Agent、Memory、Session 等。这些概念已成为算法工程师、运维人员和可观测平台用户最关心的观测对象。它们需要像传统系统中的 HTTP 请求、数据库调用一样，被标准化地采集、展示和消费，以便系统维护者清晰了解调用过程、高效排查问题。

基于此，OpenTelemetry（后文简称 OTel）早在 2024 年初就开始推动 Gen AI 语义规范建设，希望为这些新对象建立统一的数据采集规范——Semantic Conventions（后文简称 SemConv），以解决相关领域可观测数据采集标准缺失、口径不统一等问题。

Java、Go 和 Python 等各语言的自动插桩（Auto Instrumentation）或 SDK 等可观测采集工具，在许多对 OTel 刚接触的人眼里，可能会认为它们是 OTel 社区的核心价值所在。

然而，深入了解社区后会发现，相比于 SemConv，这些采集能力更多扮演的是“术”的角色，服务于 OTel 真正的“道”——通过 SemConv 建立统一的可观测数据语言。OTel SemConv 是一套汇聚全球几十家头部可观测厂商、数百名领域专家共同设计并持续演进的可观测数据采集标准。过去几年，在多次 KubeCon 会议上与社区核心 Maintainer 和 Co-founder 交流后，我们了解到，在他们眼中，SemConv 是 OTel 的灵魂，推动其逐步完善并走向 Stable 是社区最重要的工作。

一个统一的可观测 SemConv 可以实现如下效果：

统一数据语言，解决口径不一致

以 GenAI 语义为例，其应用场景天然跨模型、跨框架、跨平台。没有统一语义规范时，不同团队往往会各自记录“模型名”、“输入长度”、“Token 数”、“响应内容”等信息，字段命名和统计口径无法对齐。OTel GenAI SemConv 的核心价值在于为这些通用概念提供标准化字段，例如 gen_ai.system、gen_ai.request.model、gen_ai.usage.input_tokens等。

一旦这些关键字段被标准化，不同业务、不同基础设施、不同观测后端就能共享同一套分析方法，真正做到“同一类问题用同一套数据解释”。这也是语义规范最基础、最重要的价值。

支撑性能、成本、质量与安全的统一治理

可观测建设的目标不仅仅是排障，还包括性能、效率、安全与输出行为的持续治理。比如在 GenAI SemConv 场景中，统一的 SemConv 在把模型参数、响应元数据、Token 用量等关键信息标准化后，团队才能更容易追踪性能、成本和安全相关问题。

对大型企业来说，这意味着可以在统一标准上解决如下几个实际诉求：

• 技术排查：通过 Trace ID 查看跨 Agent 完整链路，分钟级定位各类问题，如：某业务模型调用时延异常。

• 经营分析：效果数据跨业务可比，直接用于产品决策，极大提升 BI、产品、数科等角色做跨业务分析时的效率。

• 评测：真实用户轨迹持续积累，自动构建评测数据集，特别是多 Agent 协同场景的端到端评测。

• 合规：统一的审计链路，满足安全备案刚性要求。

如果没有统一语义，这些问题就只能停留在单系统内局部分析，无法形成集团级治理能力。

降低接入成本，推动基础设施复用

OTel 的设计目标之一，是通过标准协议、语义规范、SDK、自动插桩和 Collector 等组件，让遥测数据可以复用同一条采集与治理链路。在 GenAI 场景中，统一语义规范的价值也在这里体现得尤其明显：一旦字段、Span 结构、事件模型和上下文传递方式定义清楚，无侵入埋点、SDK 封装、平台分析、看板和告警策略都能复用。

这意味着业务不需要每次都从“我要采什么字段”开始思考，而可以直接站在已有规范之上接入能力，降低整体建设成本。

作为当前可观测业界的事实标准，OTel 虽早在 2024 年初就开始了 GenAI 语义规范的讨论和设计，但由于早期的人力投入有限，再加上社区标准更强调广泛适用与长期稳定，更新节奏整体较慢。相比之下，阿里巴巴集团内部有大量的大模型应用落地场景，遇到了大量真实场景中的案例问题，因此有将相关问题抽象成为统一标准的诉求。

2025 年：阿里云、阿里控股与蚂蚁集团的可观测团队联合启动，在 OTel GenAI 语义基础上对内部场景中 OTel 尚未覆盖的内容进行语义建模，并基于此推进内部可观测采集工具的实现与落地。

2026 年：与 OTel 社区 GenAI 主要 Maintainer 沟通后，考虑到相关内容较多且迭代较快，在社区 Maintainer 的建议下，先将成果开源至阿里巴巴 LoongSuite 可观测品牌下，作为 OTel GenAI SemConv 的厂商增强标准，后续择机逐步贡献至 OTel 上游。

目前，该规范已在集团内多个核心场景完成落地，形成了从 Agent 层到基建层的全栈可观测能力。例如以下是部分相关 Loongsuite GenAI SemConv^[1]相比于 OTel GenAI SemConv^[2]的增强内容：

新增 Entry/Step Span

问题背景

我们在 AI Agent 的实践过程中发现，当 Agent 执行长程任务时，其执行逻辑会变得越来越复杂。它会包含多轮工具调用和模型调用，导致单个 Trace 中包含成百上千个 Span。这些 Span 在同一链路中展示时显得非常冗长，导致调用链轨迹难以清晰观测。为了解决这个问题，我们引入了以下两个关键设计：

1. Entry Span：在 Agent 调用的入口处创建 Span，用于还原模型和用户的原始输入、输出，形成对话历史。这样可以确保在执行下游任务时，处理的数据不受 System Prompt 或框架 Prompt 的干扰，能够获取最原始的客户请求。

2. Step Span：Step 代表 Agent 在每次 ReAct 过程中的层次化表达。在每次 ReAct 过程中，Agent 都需要完成“反思 → 工具调用 → 模型调用”的循环。在排查问题时，通常采用 Top-down 的方式来定位 Agent 的执行情况。具体流程是：首先观察整体情况，例如当 Agent 执行包含 10 轮 ReAct 过程时，先定位是哪一轮出现问题，然后再深入分析该轮中具体是哪一步出错。通过这种逐轮的 Span 结构，可以清晰展示 Agent 的多轮行动、反思以及对应的执行结果，使每轮循环的轨迹一目了然。

语义建模

新增的 Entry 和 Step Span 类型定义如下：

实现效果

目前该语义规范已经在多个 Agent 场景中落地，包括 OpenClaw，QwenPaw，Hermes Agent，以下是在 OpenClaw 场景下实现语义规范，接入后的效果：

新增 Skill 语义

问题背景

在电商购物助手等 Agent 场景中，用户的每条指令由 AI Agent 理解意图后，路由到对应的 Skill（技能）完成执行。Skill 是业务功能的最小可复用单元，内部编排了一组 LLM 调用和工具调用，用于完成特定任务，例如搜索商品、加购物车、申请退款等。

现有 OTel GenAI 语义约定已覆盖 Agent、LLM、Tool 等 Span 类型，但缺少对 Skill 这一业务功能聚合层的抽象。Skill 既不是单一的 Tool 调用，也不是完整的 Agent，而是介于两者之间的编排单元。缺少 Skill 维度的可观测性，意味着当性能抖动时，我们只能看到一堆 execute_tool 和 inferenceSpan，缺少 Skill 可观测性导致三个核心痛点：

• 无法归因到功能域：性能抖动时只能看到一堆 execute_tool 和 inference Span，无法快速判断是哪个功能域出了问题。

• 无法统计 Skill 健康指标：缺少 Skill 粒度的 P99 延迟、成功率、调用频率等度量。

• 多 Skill 并发时链路混淆：不同 Skill 的 LLM/Tool Span 在 Trace 树中无法区分归属。

语义建模

为了实现对 Skill 信息的采集，我们在 LoongSuite GenAI SemConv 中新增了一组 gen_ai.skill.* 属性，用于标识 Skill 的身份与版本信息：

当前阶段，这些属性附着在已有的 execute_toolSpan 上，无需引入新 Span 类型即可快速落地。

同时，基于集团业务，我们落地了独立invoke_skillSpan 的方案，并向 OTel 社区提交了提案（https://github.com/open-telemetry/semantic-conventions-genai/issues/86），以覆盖 Skill 从加载到执行完成的完整生命周期，支撑按功能域的端到端分析。

实现效果

通过 Skill 语义属性，可观测平台可以按功能域聚合分析：快速定位“哪个 Skill 错误率最高”、对比“新版本 Skill 上线后延迟是否劣化”、度量“LLM 调用占 Skill 总耗时的比例”等。

此外，同一套 gen_ai.skill 语义约定也可覆盖各类框架，如 OpenClaw、Langchain、Spring AI 等，以下是 OpenClaw 场景下的埋点效果：

新增 Token 级推理观测

问题背景

2025 年上半年，蚂蚁可观测团队围绕蚂蚁推理云服务建设了全链路可观测体系，覆盖推理云服务核心组件，构建了从客户端到引擎端的多语言、多协议分布式追踪 Trace 能力。其中，蚂蚁与阿里云团队协作，向社区三大推理引擎 vLLM、SGLang、TensorRT-LLM 贡献了基础的引擎可观测 Trace，形成了蚂蚁和阿里集团层面事实上的可观测 Trace 标准。整个可观测体系是蚂蚁推理云服务重要的稳定性底盘。

然而，随着业务蓬勃发展，推理云服务承压加剧，推理引擎相关的疑难问题大量涌现，请求级别的引擎 Trace 已无法有效定位更深层次的问题。我们深入研究推理引擎底层原理，结合生产实际案例，整理了如下问题：

1. 性能异常：单个请求响应慢往往是因为某些 Token 生成慢，而 Token 生成慢大概率是其他请求并发干扰导致的。

2. 精度异常：出现复读、答非所问、乱码等精度问题，往往从某个 Token 开始异常，后续 Token 受此影响持续出错。

因此，问题本质出在 Token 生成过程中。由此自然推演出，推理请求问题定位定界必须以 Token 级别可观测数据作为支撑。

因此，2025 年下半年，蚂蚁可观测团队率先构建了业界首个覆盖多推理引擎、支持 Token 级深度 Trace 的可观测产品，把可观测性从宏观请求下沉到了微观 Token 维度。它不仅关注单个请求是否成功，更深入观察：

1. 每个 Token 的生成耗时及子阶段过程；

2. 慢 Token 生成时，同一推理实例内多请求并发的相互影响；

3. 每个 Token 生成背后的 Top-K 候选分布，帮助精度问题定位。

这一工作的核心价值在于：首次将推理引擎内部许多原本“黑盒”的过程拆解到 Token 粒度，打造了一个可透视、可解释、可归因的白盒系统。

语义建模

推理引擎工作原理简介：推理引擎本质上是一个无限循环执行迭代（Iteration）的系统。每个迭代根据资源情况和调度策略选取一批请求组成 Batch，作为当前迭代的执行目标进行批量处理。迭代完成后，被选中的每个请求通常会生成一个 Token。接着进入下一个迭代，同样经历选取请求组成批->批量执行的过程。如此循环下去。

Token 性能数据采集：在每个请求的每个 Token 粒度，我们采集进入迭代和退出迭代的时间戳。通过这两个时间戳可以推演出每个 Token 的调度时间、实际执行时间以及用户感知的总耗时。此外，每个 Token 对应的请求都在一个 Batch 中，Batch 的总请求数（特别是总 Token 数）刻画了批处理的负载，该负载进一步决定了 Token 生成的耗时。因此，我们定义了以下刻画 Token 粒度性能数据的相关属性：

Token 精度数据采集：在每个请求的每个 Token 粒度，我们采集每个 Token 对应的候选 Top-K Token 的概率分布。通过该分布可以判断模型输出质量：质量差的模型其 Top 候选 Token 越不符合预期。如果模型输出符合预期，但选中的 Token 不在 Top-K 中，则问题指向用户指定的采样参数（如温度等）。所以我们定义了下面候选 Token 概率相关的属性：

实现效果

基于上述设计的 GenAI 规范，我们在三大引擎上进行采集并输出标准数据；依托这份标准数据，向用户展现出一致的功能界面。最终我们打造了引擎显微镜产品，提供引擎并发与 Token 级别的推理引擎深度观测能力。

• 引擎 Token 分析：切换到高倍镜，对准单个请求，观察其内部 Token 生成的每一个步骤耗时，以及 top 候选 Token 概率分布，精准定位延迟根源与精度异常问题。

• 引擎并发剖析：使用广角镜头，清晰呈现引擎所有请求的并发、竞争和协作关系，快速识别资源冲突与瓶颈。

引擎 Token 分析的 Token 粒度性能数据可以揭示有哪些慢 Token？引擎并发分析进一步解答这些 Token 为什么慢？另外 Token 粒度的概率分布数据可以揭示异常 Token 的大模型输出是否有正常还是采样参数设置不合理。产品上线后，历经年底大促，在稳定性战场成功帮助引擎/SRE/业务同学定位多起稳定性问题，10 倍提速问题定界效率，真正做到了又快又准，并且进一步给出了优化建议。下面选择了一些比较典型的案例来阐述产品功能与业务价值。

案例 1：慢 Token 定位，快速识别跨请求的资源干扰

线上经常会碰到某个特定请求破线了，比如指征 Token 输出速度的 TPOT（Token 平均输出时间）破线，对用户来说会感受到输出的卡顿。下面这个案例讲述了这个场景下，Token 分析与引擎并发剖析如何帮助定界定位。

当我们拿到异常请求 TraceId 之后，我们打开如下图所示的 Token 分析页面，可以看到第 125 个 Token 花了 6.8 秒，远超预期，最终导致 TPOT 高达 54.77ms。

点击 Token 分析右上角的“引擎并发分析”，我们跳转到对应引擎实例并发剖析页面。根据时间或者 TraceId 搜索定位到异常请求。这个请求就是下图中的请求 2。我们看到请求 1 生成首 Token（prefill 阶段）-亮绿色块花了 6s+，中断了请求 2 去 decode 生成第 125 个 Token 黄色块，跟 Token 分析吻合。总结下根因是其他租户的请求 prefill 中断了当前请求的 decode 过程，那么可能的一个解决方案是去做 PD 分离，避免不同请求的 prefill 和 decode 相互影响。

案例 2：Token 级观测，精准定位答非所问的根因

下面这个案例属于典型的“答非所问”案例，比如用户问的是医疗问题，但大模型回复了 LeetCode 解题答案。

打开如下图异常 Trace 的 Token 分析页面，我们一眼能看到首 Token 是“begin_of_sentence”。这个 Token 是一个特殊的 Token，简称 BOS，它被用来分割毫无关联的两个语料。也就是说，一旦出现了 BOS，那么接下来的回答就跟之前的 prompt 毫无关联，自然而然就答非所问了。所以很明显，在任何情况下，回答里面都不应该出现 BOS，那么问题定界到为何会出现这个 BOS。对于这个案例，无论在用户的回复里面，或者是引擎日志/网关日志里面，都不会显示 “begin_of_sentence”，而只会显示成空串，所以没有 Token 分析，定位过程会变得复杂。后续我们进一步挖掘发现产出 BOS 属于大模型的 badcase，解决方案是调整模型或者等后续模型版本优化更新。

在前文中，我们详细介绍了 LoongSuite GenAI SemConv 在 Agent、Skill、Token Level Inference 等多个维度的语义建模。然而，对于实现 LoongSuite GenAI SemConv 的各类插桩库（Instrumentation）开发者而言，他们面临一个共同的工程挑战：

每个 GenAI 框架插桩库都需要实现一套完整的遥测采集逻辑——创建 Span、挂载语义属性、记录 Metrics、发送 Events、管理 Context 传递——而这些逻辑在不同框架插桩间高度重复。更关键的是，当语义规范迭代升级时（例如新增字段、调整 Span 结构），若每个插桩库各自维护一套实现，升级成本将成倍增长。

以一个 Agent 框架插桩为例，如果不使用公共工具层，开发者需要手动完成：创建 invoke_agent Span 并设置 SpanKind、逐一挂载 gen_ai.agent.name、gen_ai.agent.id、gen_ai.usage.input_tokens 等数十个属性、根据配置决定是否采集消息内容、处理异常并设置 Error 状态、记录 Duration 和 Token Usage Metrics——这些样板代码在每个插桩库中都大同小异。

为了解决这一问题，我们在探针中实现了 GenAI Utils，它作为 LoongSuite GenAI SemConv 的工程化能力层，将语义规范的复杂性封装成简洁的 API，让插桩库开发者只需关注“从框架中提取什么数据”，无需关心“如何按规范输出遥测数据”。以下是一些我们支持的 GenAI Utils 实现：

1. LoongSuite Python 对应实现 LoongSuite-utils-genai^[3]。

2. LoongSuite JS 对应实现 LoongSuite-utils-genai^[4]。

GenAI Utils 的整体架构遵循“分层解耦、统一收口”的设计原则：

核心设计理念：

插桩层只做数据提取：各框架插桩库通过 Hook/Monkey-Patch 拦截框架调用，将数据填充到对应的 Invocation 数据对象中，不直接操作 OTel API。

GenAI Utils 统一收口遥测输出：所有 Span 创建、属性挂载、Metrics 记录、Event 发送、Context 管理均由 ExtendedTelemetryHandler 内部完成。

规范升级只改一处：当 LoongSuite GenAI SemConv 新增字段或调整结构时，只需修改 GenAI Utils 中的 Span Utils 和 Metrics 模块，所有下游插桩库自动生效。

GenAI Utils 为 LoongSuite GenAI SemConv 覆盖的每种 GenAI 操作都提供了对应的 Invocation 数据类和 Context Manager 方法，形成了统一的“填数据 + 交给 Handler”编程模型。接下来，以 Python 语言 GenAI Utils 工具库为例，介绍如何使用：

第一步：获取 Handler 单例

from opentelemetry.util.genai.extended_handler import get_extended_telemetry_handler
handler = get_extended_telemetry_handler(
    tracer_provider=tracer_provider,
    logger_provider=logger_provider,
)

ExtendedTelemetryHandler 继承自 OTel 上游的 TelemetryHandler（负责基础 LLM 操作），并在此基础上扩展了 Agent、Tool、Embedding、Retrieve、Rerank、Memory 等 LoongSuite 新增的操作类型，同时还集成了多模态异步处理能力。这种继承设计确保了与上游社区代码同步时不产生冲突。

第二步：选择对应的 Invocation 数据类，填充业务数据

GenAI Utils 为每种操作定义了对应的 Invocation 数据类，插桩库开发者只需将从框架中提取的数据填充其中：

第三步：使用 Context Manager 完成遥测输出

以典型的 Agent 框架插桩为例，展示如何使用 GenAI Utils 快速实现完整的可观测采集：

from opentelemetry.util.genai.extended_handler import get_extended_telemetry_handler
from opentelemetry.util.genai.extended_types import (
    InvokeAgentInvocation, ExecuteToolInvocation
)
from opentelemetry.util.genai.types import InputMessage, OutputMessage, Text
handler = get_extended_telemetry_handler()
# ========== Agent 调用 ==========
with handler.invoke_agent() as invocation:
    invocation.provider = "dashscope"
    invocation.request_model = "qwen-max"
    invocation.agent_name = "ShoppingAssistant"
    invocation.agent_id = "agent-001"
    invocation.input_messages = [
        InputMessage(role="user", parts=[Text(content="帮我推荐一款笔记本电脑")])
    ]
    # ... 实际调用 Agent 框架 ...
    invocation.output_messages = [
        OutputMessage(
            role="assistant",
            parts=[Text(content="我来帮您搜索，请稍等...")],
            finish_reason="tool_calls"
        )
    ]
    invocation.input_tokens = 42
    invocation.output_tokens = 18
# ========== 工具执行 ==========
with handler.execute_tool() as invocation:
    invocation.tool_name = "search_products"
    invocation.tool_call_arguments = {"query": "笔记本电脑", "category": "electronics"}
    # ... 实际执行工具 ...
    invocation.tool_call_result = {"products": [{"name": "MacBook Pro", "price": 12999}]}

在上面这段代码中，开发者没有直接操作任何 OTel API——不需要手动创建 Span、设置 SpanKind、挂载 gen_ai.agent.name 属性、记录 Duration Metrics——这些全部由 ExtendedTelemetryHandler 在 Context Manager 的 __enter__ 和 __exit__ 中自动完成。若在调用过程中抛出异常，Handler 会自动捕获并在 Span 上设置 error.type 属性和错误状态。详细使用过程可以参考文档^[5]。

当前已支持的插桩

基于 GenAI Utils，LoongSuite Python Agent 已实现以下 GenAI 框架和模型服务的插桩，覆盖国内外主流 GenAI 生态：

这些插桩库的核心遥测逻辑全部复用 GenAI Utils 实现，当 LoongSuite GenAI SemConv 新增语义或调整规范时，只需要升级 opentelemetry-util-genai 包，所有下游插桩库即可统一生效。

GenAI 时代的可观测建设，已经从“为模型调用加日志埋点”演进到“为 Prompt、推理、检索、工具和 Agent 全链路建立统一语义”。OTel 已经为此提供了标准化方向，并通过语义规范与插桩库推动 GenAI 观测能力的形成。

阿里巴巴与蚂蚁集团共建 GenAI 可观测语义规范的意义，正在于把这种标准化方向进一步工程化、平台化、规模化：一方面用统一语义降低业务接入成本，另一方面用统一数据驱动观测平台、分析服务和治理能力的复用。最终目标并不是“产出一份规范文档”，而是让所有使用该套规范的厂商和用户能够为快速增长的 GenAI 应用真正做到可看见、可分析、可治理、可演进。

相关链接：

这是2026年的第14篇文章

（ 本文阅读时间：25分钟 ）

前言/我们正在看到的事情

我们最近做了一份内部访谈，问几位深度使用 AI 的工程师"你日常时间分配的变化"。结果有点出乎意料——

写代码的占比，从过去的 30% 降到 5%；和 Agent 对话的占比，从 5% 升到 60%；查问题的时间下降一半以上；纯编码效率提升 10 倍，但端到端需求交付效率只提升 2 到 3 倍。

更值得停下的不是数字，是节奏：一个工程师上午 10 点上线一个新功能、中午做 A/B 测试、下午 3 点根据数据下线、5 点上线更好的版本。同一天。这是过去 6 周才能完成的迭代。

为了理解这件事到底意味着什么，我想先回到一个更基本的问题：组织到底是为什么存在的？

01

两千年的协调问题史

把这个问题拉远一点看，会发现组织的演化已经持续了两千年。本质都在解决同一件事：信息怎么路由。

罗马军团把军队拆成 8 → 80 → 480 → 5000 人的嵌套结构，就是把信息路由协议化：每一层都有人聚合下层、传递上层。1806 年，普鲁士被拿破仑打败之后，军队改革重建了"总参谋部"，这是中层管理的雏形：一群专门做信息整合和决策预演的人。

1840 年代，美国铁路从军队里借来这个结构，画出了世界上第一张组织架构图——为了避免火车相撞。Taylor 的科学管理把这个金字塔做到极致；战后矩阵组织、Spotify 的 Squad、Holacracy、Valve 的扁平化，都是各种修补。

这两千年里有一件事没变：组织演化的核心约束是人的"管理跨度"：一个人能直接管的下属在 3 到 8 之间。这个数字不是文化决定的，是人这个生物的硬限制。所以所有组织的形状本质上都是在这个限制上做的妥协。

Block 在最近一篇文章里说得很直接："问题从来不是要不要分层，而是：人是不是这些层唯一的承担者？现在，他们不再是了。"[1]

02

组织的形态来自哪里：人的镜像

如果组织的形状是为了适配"人"，那么组织里的所有具体设计，也都是人的镜像。

康威定律说"组织结构 = 系统结构"[2]——为什么？因为团队内部的沟通成本远低于跨团队，所以模块边界不可避免地与团队边界重合。Brooks 在《人月神话》里说"加人无法加速一个延期的项目"[3]——为什么？因为沟通成本随人数指数增长。Frederick Taylor 把工作拆分成专业岗位——为什么？因为人的注意力是稀缺资源。我们今天还在用的 manager 评价制和强制分布——为什么？因为员工产出不可观测，所以让"信息上最近的人"代理评估。

这些定律和制度都不是抽象工程哲学，它们是人这个生物的协作物理学。组织设计的所有特点本质上都是这个物理学的具体实现。

03

AI 不是新工具，是新协作主体

接着这条线，AI 进来之后会发生什么？

AI 不是过去意义上的"工具"：工具是延伸人的能力，AI 是新的协作主体。它的特点正好和人形成镜像反面：人有沟通衰减，AI 没有；人需要激励，AI 不需要；人会疲劳和有情绪，AI 没有；人有 context switching 成本，AI 极小；人的记忆和注意力有限，AI 几乎无限。

也就是说，上一节里所有"以人形约束为前提的设计"，其前提开始失效。

那 AI 实际是怎么进入组织的？是替换人吗？还是和人共存，怎么共存？

观察几个真正在做 AI Native 的团队——Anthropic、CREAO、我们内部的一些先锋小组，会发现一个共同形态：它们的工作分两层，两层的运作逻辑甚至是相反的。

底层是极度结构化的 Harness 层：代码、测试、流水线、文档、世界模型，所有信息都被做成 AI 友好的形态，这一层越结构化越好，AI 主导；上层是极度松散的 Hive Mind 层：对话、试错、idea 涌现、Yes-and，这一层越松散越好，人主导。

Anthropic 几乎肯定有比任何公司都精密的 Harness（Claude 就是它造的），但它在 Harness 之上选择运行混乱的文化——这两件事不是替代，是叠加。结构化是为了释放无结构的协作，不是用结构控制一切。

如果 AI 是新协作主体，AI 的特点正好和人形成镜像反面，那么过去围绕"人"被设计出来的整个组织和研发体系，应该怎么重设计？新瓶颈又会落在哪里？

这是接下来要回答的问题。但要真的回答它，得先承认一件事：组织本身这个对象，需要被重新思考。

Ken Huang 在一篇文章里有一句话，我认为很关键。"Once AI becomes agentic, the organization stops being accurately described by an org chart. It becomes an execution graph."[4]

它的意思是：当 AI 真的能行动、能调用工具、能修改系统、能执行 workflow，你的公司就不再能被一张 org chart 准确描述。它变成了一张 execution graph，一个把人、agents、数据、权限、工具、审批关系当作同等节点的活的网络；节点之间不是"汇报关系"，是"意图到行动的转化链路"。

这个范式转换里最关键的一点是核心问题变了：旧问题是 ownership——"谁拥有这件事？"新问题是 routing 加 governance——"意图从哪里进入系统？怎么被翻译成行动？什么约束让这个行动是安全的？"

为什么这件事真的重要？让我从一个管理者的体感角度补一个：每个做过组织调整的人都经历过 reorg 的真实代价：计划几个月、执行几个月、恢复信任又几个月，一次完整的 reorg 周期常常是 6 到 12 个月。

这是因为旧组织的最小单元是"人 + 长期关系网"。这个单元粘性极高，每次 reorg 实际上是在重新建立信任、重新拆解依赖、重新切割身份归属。

Execution Graph 把组织的最小单元从"人 + 关系网"换成"任务 + 上下文 + 权限 + 工具"，这个单元里大部分依赖是机器可读的 artifact，不是人脑里的隐性关系。

所以重组的成本可以从季度级压到 week 级，这是数量级的跃迁。从公司层面看，这可能是 AI Native 转型最被低估的红利：不是"组织能更高效"的小提升，是适应性速度本身的升级。

05

人既是瓶颈，也是兜底

前不久看团队的 AI Native 访谈调研，做记录时我在文档里随手写了一句批注：「之前的模式一个工作需要拉入很多人来做模块划分，功能上需要相互协议和对齐目标，消除理解的不一致性。但如果是一个人或者少数人来自定向下的处理，就不需要协商和对齐，自己理解清楚，就能开始干了。」

事后越想越觉得这句话隐含了一个更深的判断——协作的本质是消除理解不一致性的成本，而这个成本，过去一直是人在扛。

人为什么扛得起？不是因为人多牛，是因为没别的选择。我们这个生物有一些硬约束：通信带宽很窄、记忆有限、注意力是稀缺资源、切换情境成本极高，再加上情绪、疲劳、动机这些非线性变量。这些约束放在一起，定义了人作为协作主体的物理形状。前面说的康威定律、人月神话、manager 评价制，都是围绕这些约束的妥协。

但这次访谈让我看清了之前没认真想过的另一面：

人既是协作的瓶颈，也是协作的兜底。

什么意思？过去几十年我们抱怨的所有"组织效率问题"——会议太多、对齐成本高、信息上下传递失真、流程慢，矛头都指向人。

但同时还有一件事却很少有人正面说：一份不完整的需求、一段没注释的代码、一个不一致的 API 约定、一段口头传达的"潜规则"......这些缺陷之所以系统能正常运转，是因为人在用自己的灵活性、推理能力、社会沟通能力悄悄把缺口补上。开个会问一下、走过去问老王、凭经验猜一下、跑去预发环境试一下——这些动作发生得太自然，自然到我们不再把它看作"工作"。

但它们是工作。它们是人扛在肩上的、维持系统运转的隐性成本。

整个研发系统其实长期容忍着大量的不规范、不结构化、不完整的信息，只要人足够聪明、勤奋、熟悉，这些缺陷就不会上升为瓶颈。

而当 AI 接管执行之后，这一面就翻过来了。AI 没有"猜"和"问老王"的能力：它需要的是结构化、可查询、可执行、确定性的信息。但传统系统根本没有这些，因为它从来就不是为 AI 设计的。

这就是新瓶颈的真相：它不是 AI 能力不够，是系统的信息形态不够。过去被人吸收的所有"信息隐性化、信息非结构化、信息缺失"的成本，第一次以瓶颈的形式暴露出来。

06

新瓶颈：信息形态的人形偏置

我先给一个数据。这是公司内部最近做的一份大规模 AI 化调研，对象是已经在大量使用办公和编程 AI 工具的员工——不是 AI 化的反对派，是已经在用、并且想用得更深的那批人。

在所有维度的期待里，提及最多的是什么？不是模型能力更强，不是响应更快。是"系统打通与数据整合"——数百条原声，所有岗位、所有层级提及频次最高，断崖式领先第二名。

具体痛点是：员工已经认可 AI 的处理能力，但苦于 AI 无法触及他们日常工作的数据和系统：钉钉、数据系统、研发系统、邮件、审批流。

结果是一种很反讽的人机协作：员工自己当信息搬运工，从各系统手动导出数据、复制粘贴进 AI、再把 AI 输出搬回业务系统。

把这个画面看清楚：员工正在做"人肉中间件"。

AI 已经能处理（大模型很强），但系统没给 AI 留接口（系统是为人设计的）。所以人成了系统和 AI 之间的中间件，这是当前 AI 化最大的隐性税。

OpenAI 在 2026 年初提出过一个相关概念叫 Harness Engineering[5]——工程团队的首要职责不再是写代码，而是让 Agent 能干活。当 Agent 出错时，不是问"它怎么这么笨"，而是问"我们少了什么能力？怎么让这个能力对 Agent 来说是 legible 和 enforceable 的？"

我们内部访谈里，一位工程师同事给"AI 友好"做了一个 5 维度归纳：测试完备性、环境完备性、架构合理性（无循环依赖、无跨服务隐式调用）、端到端测试可执行性、文档充分性。

这五个维度有一个共同本质——它们要求的不是"能用"，是"AI 友好"。而我们今天大量的研发系统，能用是因为人聪明，不是因为它们 AI 友好。

新瓶颈一旦看清，给到的判断就很硬：这个瓶颈不会自己消失，需要人主动去拆。而拆它的工作有一个不显眼但至关重要的特性——复利。

一旦 Harness 跑起来，AI 接管的工作越多，失败信号越丰富，Harness 优化得越快，这是一个开始之后只会加速的飞轮。早建好 Harness 的公司会在某个临界点之后突然加速；晚建的公司不只是慢一点，是会被远远甩开。

6.1 管理塌缩

如果新瓶颈的拆除工作如此关键，它会落到谁头上？

CREAO 的 CTO Peter Pang 直接说：他自己两个月前还有 60% 时间在管人，现在不到 10%[5]。Block 把判断说得更激进——"永久的中层管理层不再必要"。

但这个结论太粗糙。

把传统管理者的工作拆开看至少有 10 件事——战略传导、信息聚合、资源协调、日常决策、重大决策、冲突调解、激励、辅导、招聘退出、文化建设。

这十件事在 AI Native 之下命运分化得很厉害——前四项（战略传导、信息聚合、资源协调、日常决策）可被系统替代（World Model 承载 alignment、自动化报告替代汇报）；重大决策和冲突调解形态在变——重大决策从 manager 拍板下沉到离客户最近的 DRI；冲突调解的总量随团队变小自然减少；激励、辅导、招聘退出、文化建设这四项不可被系统替代（伦理上必须由人完成）；还有一类是新出现的——意图教练、身份重建、虚无对抗——以前不需要做、现在需要做、目前几乎没人在做。

所以判断是：管理塌缩，不是管理消失。是管理在重新选择它的位置。

新出现的角色里最关键的是 Architect：设计教 AI 怎么工作的人。这个角色不是写代码、不是堆功能，而是为整个 Execution Graph 设计架构：定义系统能力的边界、设计 SOP、建立测试基础设施、搭建集成与 triage 系统、定义"什么叫好"。

换句话说，Architect 是把组织的隐性 know-how 翻译成 AI 可消化形态的人——他做的每一份 SOP、每一个判据、每一段架构决策，都直接进入 Harness 层、直接决定 AI 接管的深度。

这个角色的特殊性在于——它要求最懂这个领域的人来做。写好的测试需要懂业务的人；写好的 SOP 需要做过这件事的人；定义好的判据需要有品味的人；设计好的架构需要见过失败模式的人。这些都是资深工程师才有的特质。

→ 所以 Architect 是新组织的最高杠杆点——一个 Architect 的产出会被 N 个 agent 复用、被多个 domain team 依赖、被多个项目继承。组织里能找到、留住、并主动转身投入这个角色的资深工程师，就是新组织最稀缺的资本。

还有一类新员工被忽略了——Agent。Ken Huang 直接说"Agentic AI introduces a new employee class."不是比喻——Agents 需要 onboarding、scoping、supervision、offboarding，但它们和人有四个最危险的不对称：可被无限复制、同小时既 brilliant 又 brittle、compliance-blind by default、fast enough to fail at scale。管 agent 不是管软件、也不是管人，需要第三套治理框架。

6.2 Platform 三柱架构

管理者塌缩之后剩下的、扩张出来的、加上数字员工，这些怎么安顿？

Ken Huang 给了我目前看到的最具体的回答：Platform 三柱架构。

柱 1 · Agent Platform Group——中央团队，runtime 标准、权限、日志、可观测、评估 harness、安全部署。Huang 说："This is not 'AI research' in the romantic sense; it's production engineering plus governance."这就是 Architect 角色的组织化形态。

柱 2 · Domain Teams——业务团队。"Own outcomes rather than models."对结果负责，不对模型负责。3-5 人的垂直功能小组就是它的实现。

柱 3 · Risk and Oversight——治理层。Huang 给了一个很硬的定位："An immune system rather than a bureaucratic brake"——免疫系统，不是官僚刹车。"When governance is done well, it does not slow the Hive Mind down; it keeps it alive."

这一柱最被低估——前面所有 AI Native 讨论都在讲创造性、效率、文化，但没人正面回答"出事了怎么办？"Huang 说："Assuming nothing will go wrong is not optimism; it's negligence in a world where mistakes can propagate quickly."

把双层结构（Harness 层 + Hive Mind 层）和三柱架构叠在一起：柱 1 在底层建造、柱 3 在底层守护、柱 2 在上层探索和交付。

横看是两层、竖看是三柱：柱 1 建造底层、柱 3 守护底层、柱 2 在上层探索和交付。

Huang 给了 6 项基本功：枚举 agents、权限纪律、梯度自治、日志、评估 harness、事故响应。它们都不"性感"，但基础设施工作有复利。

6.3 三类工作 / 三种治理：Death of ego 是有边界的

我想在这一节做一个反转——给前面的判断加一个边界条件。

前几节引用的素材里有一个共同倾向——大家都在朝最大化透明度 + 最大化死 ego 的方向推。Yegge 用了一个词："death of the ego"[6]。

听起来很美。但我越想越不踏实——它会扼杀创新。

我先做一个区分。我们日常说的 ego 把两种东西混在一起了：防御性 ego（保护我的地盘、隐藏失败、邀功避责）是旧组织协调机制的副产品——Yegge 想杀的是这种，他对的；生产性 ego（"这是我要弄明白的"、"我不接受这个答案"、"这件事没想透我睡不着"）是创新的发动机——它被杀掉的时候，没人会立刻看到。

为什么生产性 ego 是发动机？困难问题需要数月级的持续注意力——靠"我的"作锚点；创新要求愿意在公开场合显得愚蠢——靠 skin in the game；死胡同期需要顽固——靠"我不接受这是无解问题"；创新常常是反共识的——Hive Mind 越成熟反共识声音越难维持；凌晨 2 点的执着——只发生在你真心觉得"这是我的事"的问题上。

这五件事 AI 当前架构上做不到。AI 没有自我连续性——transformer 是 stateless 的，本质上排斥"在一个问题上保持几个月在乎"这件事。所以创新工作就是人在 AI Native 组织里的真正不可替代领域。

回到 Death of ego——它在哪些工作上对、哪些工作上错？我把工作分成三类：执行类——杀掉防御性 ego 是对的，越透明越好；优化类——抑制 ego，结构化但留批判空间；创新类——保护半成形的想法，主动维护生产性 ego，半私密、不强制广播。

如果一个组织把这三类工作用同一种治理方式管——Death of ego 一刀切——结果就是：执行的高效率 + 创新的死亡。

07

我们看到的：三个案例

前面五节判断都是逻辑推理。下面用三个案例来检验。

1 · 先锋：内部访谈的 4 位深度使用 AI 的工程师——写代码 30%→5%、和 Agent 对话 5%→60%、3-5 人小团队按垂直功能划分（不再有产品/前端/后端边界）、沟通从需求评审驱动转向成果评审驱动、决策权与开发权分离（"决策权还在领域专家手上，但开发权可以交出来"——访谈原话）。这是 AI Native 跑通后的样子。

2 · 全员：上一节那份数百条系统打通调研——它告诉我们，普通员工已经在大量用 AI，但还卡在"人肉中间件"阶段。这是 AI 化中段的真实状态。

3 · 反例：一个内部 3 人小组的两阶段对照——同一批人、同样能力。阶段 1 在做一个有挑战、有自主权的项目，团队自评行业前沿、士气很高；阶段 2 因为战略调整被调到他人主导的项目里，贡献关键但汇报里只字未提——士气崩塌、想退出。变量唯一是 ego 投入条件。

这里有一个尖锐的观察："可见性 ≠ 被看见"。他们的代码 commit 都在那里所有人都能看到（可见性），但管理者没在汇报里念他们名字（没有被看见）。这是两件事，而新系统里很容易把前者当成解决了后者。

08

转型的真实代价

讲到这里要停一下，问一个不能回避的问题：人怎么办？

行业里因为推行 AI 引发的人员结构调整压力不小，公司内部有一种自嘲："把自己蒸馏完，就在组织里没位置了"。

蒸馏（distillation）这个词太准了。员工每写一份 SOP、每教 AI 一个流程，确实是在把知识"导出"到组织资产里。它感觉是合作行为，但结构上接近一种替代关系。

这件事不能回避，至少有三个原因。

第一，培养断裂。旧路径很清楚：day 1 写简单代码 → 几年写复杂代码 → 设计系统 → 定战略，每一步都是上一步的连续延伸。新路径里这条线断了，day 1 AI 已经在写代码，那 day 1 的人到底应该做什么？最让人不安的可能是：入门级岗位本身可能消失。每家公司不招 day 1 是局部最优，但整个行业不招 day 1，三五年后 senior 池开始枯竭——这是产业级灾难。

第二，蒸馏焦虑会直接破坏 AI Native 转型。当员工意识到"我说的越多被替代得越快"，关键知识开始藏匿，而 Harness 工作恰恰需要员工说出"哪些隐性约定需要被结构化"。员工不说，Harness 工作就不可能完成。最优秀的人先走（他们外部选择最多），剩下的是 risk-averse 的 followers，然后转型基本失败。

第三，行业级的负反馈环：当一些公司开始用 AI 替代而不是放大人时，竞争压力会让其他公司跟着收缩；senior 池被慢慢消耗、Architect 储备越来越薄；大家不知不觉在 "death of expertise" 的方向上互相加速。几年后，整个行业的判断力会被同步抽空。

我不假装有完美方案，但有几个方向能避免最坏情况。明确 AI 红利的分享方式：是用它来扩展组织边界、做以前做不了的事，还是用它来收缩团队？这两条路给员工的信号完全相反；转型必须有真实的"接住"机制，Architect 通道、跨领域 DRI、新业务负责人、真实的过渡支持......不能只是 PPT 上写；诚实分类哪些岗位形态正在变化，因为模糊的承诺比明确的告知更伤人；评价系统必须跟着变，口头说"判断比执行值钱"但 KPI 还是产出量，员工不会信。

AI Native 转型最难的部分不是技术，是处理"被转型"的人。组织里的人不是 capability units，他们是有 ego、有焦虑、有家庭、有身份的存在。AI Native 不是把人当 capability 调度——是给 capability 之外的部分留出位置。

09

还没解决的

把前面的判断推到这里，仍然有几件事我没有答案。

第一，AI 的信任度。CR 和缺陷分析这种高风险环节，AI 产出仍需打问号，人工审核又跟不上，形成"不敢全信、人工又扛不住"的两难。

第二，绩效失效。评价的旧依据（老板目击）失效，新的依据（artifact 可见 + recognition 主动）还没建立。

第三，3-5 人小团队是临时最优还是终态——目前的"魔法"可能来自三个临时条件：探索者效应、过渡期人形需求、审稿层价值。

第四，AI 知识资产继承。员工花几个月调教好的 agent，人走时怎么办？目前没有任何公司有完整方案。

这些都是开放性问题。承认它们没答案，比假装有答案更诚实。

10

几条关键判断

写到最后，留几条值得记住的判断。

第一，Harness 工作不显眼，但它是组织未来速度的复利本金。早投入和晚投入的差距，不是线性的，是指数的。今天每小时投在 Harness 上的工程精力，就是明天 AI Native 速度的来源。

第二，不要把 AI Native 转型当作"又一次 reorg"——这是错配。AI Native 的真正价值不是再做一次组织调整，而是让组织未来不再需要痛苦的 reorg。今天投入到 Execution Graph 上的工程，是把"组织响应变化"这件事从季度级压到 week 级，这是组织级别的复利。Harness 复利让组织变快，Execution Graph 复利让组织能持续应对变化——两个复利合在一起，是 AI Native 转型的真正礼物。

第三，解决 Architect 的激励问题。把"被威胁的资深工程师"转化为"被赋能的 Architect"：给身份、给权力、给资源。

第四，分辨节点类型，执行节点全透明 + 死防御性 ego；创新节点保护性环境 + 维护生产性 ego。两者搞混 = 执行高效 + 创新死亡。

第五，开始做 agent 名册，你不可能治理你叫不出名字的东西。

最后回到 Block 那个问题——你的公司理解什么是真正难以理解的？这个理解每天都在变深吗？

如果答案是没有，AI 只是降本故事，砍掉人头、几个季度提升毛利、最终被更聪明的对手吞并。如果答案足够深，AI 不是增强你的公司，是揭示你的公司到底是什么。

References

[1] Jack Dorsey & Roelof Botha, From Hierarchy to Intelligence, Block Inside, March 2026. 

https://block.xyz/inside/from-hierarchy-to-intelligence

[2] Melvin E. Conway, How Do Committees Invent?, Datamation, April 1968. 

https://www.melconway.com/Home/pdf/committees.pdf

[3] Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering, Addison-Wesley, 1975（1995 年纪念版）.

[4] Ken Huang, What is an Agentic AI Native Organization?, Substack, February 2026. 

https://kenhuangus.substack.com/p/what-is-an-agentic-ai-native-organization

[5] Peter Pang, Why Your "AI-First" Strategy Is Probably Wrong, X (Twitter), April 2026. 

https://x.com/intuitiveml/article/2043545596699750791

[6] Steve Yegge, The Anthropic Hive Mind, Medium, February 2026. 

https://steve-yegge.medium.com/the-anthropic-hive-mind-d01f768f3d7b

*封面头图来自Human Verification，侵删。

网盘客户端支持以下上传特性：

*了解更多:higress.ai | GitHub

我们总以为拍下即留存，却常被“看得见、用不了”的内容困住：

• 此前在图书馆里拍摄的重要书籍页面却因为当时光线不佳，现在转文字时无法识别；

• 导师发来一份多年前的扫描版学术论文PDF，关键公式识别乱码，只能手动重新敲打；

• 开发者截图一段 GitHub 代码，识别后格式全无，需要手动调整缩进才能理解；

• 书本中纵横交错的思维导图，拍得下全貌却抓不住逻辑，想引用时只能对着照片重新构图；

• 谱架上那页珍贵的手写乐谱，承载着旋律却无法数字化，难以编辑或分享给伙伴。

格式本应是思想的容器，而非牢笼。

Logics-Parsing V2解析能力全新升级， 不止于文本，读懂更多数据的结构和逻辑。现在，无论是一篇紧凑的学术论文复印件、一页复杂的财务报表扫描件，还是一张跳动的乐谱图片、一个包含思维导图或伪代码的网页截图——Logics-Parsing V2 都能穿透像素的屏障，将其转化可编辑、可搜索的结构化数字资产。让信息不再只是被“看见”，而是被真正“唤醒”。

轻松实现端到端处理

• 单模型端到端实现各类文档的识别和解析

• 处理报纸、杂志等复杂版面文档更加游刃有余

先进的内容元素识别能力

• 无惧复杂排版，密集文字、复杂表格、科学公式、化学符号都能精确识别

• 拓展 Parsing 2.0 识别能力，乐谱、思维导图、代码伪代码也能精准还原

丰富的结构化输出

• 模型生成简洁的QwenVL HTML来表示文档，并标记元素类别、位置，保留其逻辑结构

业界领先的性能表现（SOTA）

• Logics-Parsing-V2不仅在自建评测集LogicsDocBench上取得了业界最佳（SOTA）的效果，同时在权威的公开评测集OmnidocBench-v1.5上也取得了端到端模型SOTA效果（总分93.23）

github: https://github.com/alibaba/Logics-Parsing

demo: https://www.modelscope.cn/studios/Alibaba-DT/Logics-Parsing/summary

模型地址：https://huggingface.co/Logics-MLLM/Logics-Parsing-v2https://www.modelscope.cn/models/Alibaba-DT/Logics-Parsing-v2

Logics-Parsing-V2是去年9月开源的Logics-Parsing的升级版本。它继承了Logics-Parsing模型的所有核心功能，同时在处理复杂文档方面展现出更为强大的性能，并且进一步扩展了对 Parsing-2.0 场景的支持，实现了对乐谱、流程图、思维导图以及代码/伪代码块的结构化解析。模型大小也从8B下降到了4B，推理更快。

Logics-Parsing-V2是基于多模态大模型的端到端文档解析模型，在Qwen3-VL-4B的基础上，采用SFT+GRPO两阶段方式训练而成。我们同时针对真实解析场景的复杂任务，构建了以复杂版面和STEM学科为特色的高质量解析数据集，其不仅涵盖多栏报纸、学术海报等极具挑战的版面，更延伸至 Parsing-2.0 场景，覆盖化学分子式、五线谱、代码/伪代码块、流程图与思维导图。另外在复杂版面文档的解析过程中，创新性地引入基于布局的强化学习机制，设计识别、检测、阅读顺序的多维度奖励机制，显著提升模型在复杂文档布局下的结构理解与内容排序能力。

权威开源评测OmniDocBench_v1.5评测：端到端模型SOTA

自建 LogicsDocBench 深度测评：展现复杂文档解析的全维度领先实力

LogicsDocBench介绍

LogicsDocBench为自建综合评估基准，由 900 页精心挑选的 PDF 页面组成，涵盖了传统的 Parsing-1.0 任务以及新引入的 Parsing-2.0 场景。该基准旨在更全面地评估模型在解析复杂且多样化的真实世界文档时的能力，LogicsDocBench近期将会开源。该数据集分为三个核心子集：

STEM 文档

侧重于高难度的学术和教育内容，涵盖物理、数学、工程和交叉学科等十多个领域。该子集旨在评估模型对数学公式、技术术语和结构化知识表示的深层理解。

复杂布局

包含具有挑战性的真实世界布局，如多栏文本、跨页表格、竖排书写以及图文混排。该子集用于全面评估模型的布局分析能力。

Parsing-2.0 场景

针对对传统 OCR 系统构成了重大挑战的现代数字化和半结构化内容，包括：

• 化学分子式

• 乐谱

• 代码和伪代码块

• 流程图和思维导图

各模型在LogicsDocBench的表现

代码 Bug 就像蟑螂：当你发现一只时，阴暗处可能早已潜伏着成百上千只，你不去寻找，隐患依然存在。

{
  "role": "assistant",
  "content": "需要详细了解新添加方法的上下文环境以更好地评估其功能和潜在问题。",
  "reasoning_content": "我将根据提供的评审检查项来审查当前文件的代码改动。首先分析新增的方法 `getCodeReviewAiRuleResult`",
  "tool_calls": [
    {
      "type": "function",
      "function": {
        "name": "file.read",
        "arguments": "{\"file_path\":\"force-base/src/main/java/com/alibaba/force/base/project/service/impl/ProjectsImpl.java\",\"start_line\":2715,\"end_line\":2755}"
      }
    }
  ]
}

{
  "role": "assistant",
  "content": "需要确认AiReviewSettingsOutputDTO对象是否可能为空以及如何处理这种情况",
  "reasoning_content": "我已经阅读了相关的代码，我发现一个潜在的问题，在 `getCodeReviewAiRuleResult` 方法中，如果没有对 `aiReviewSettings` 进行空值检查，当 `projectCodeReviewSettingsService.getAiReviewSettings(projectId)` 返回null时会导致NPE。\n  让我进一步确认一下这个方法的上下文和其他相关信息。",
  "tool_calls": [
    {
      "type": "function",
      "function": {
        "name": "code.search",
        "arguments": "{\"search_text\":\"getAiReviewSettings\",\"case_sensitive\":false}"
      }
    }
  ]
}

{
  "role": "assistant",
  "content": "发现了一个可能导致空指针异常的问题，需要提供具体的修复建议",
  "reasoning_content": "通过搜索结果可以看到，`getAiReviewSettings` 方法在多个地方被调用，并且在测试中有返回null的情况（例如 ClientLlmCodeReviewEventListenerTest.java 中的第151行）。这表明该方法确实可能返回null。\n\n  因此，在新的 `getCodeReviewAiRuleResult` 方法中直接调用 `aiReviewSettings.getAiReviewSetting()` 存在空指针异常的风险。我们需要添加空值检查或者确保上层已经处理了这种情况。\n\n\n  此外，我还注意到一个问题：在 `getIntelligentReviewExcludePaths` 方法中，如果配置不存在，默认值是从 `MergeRequestLlmConstants.INTELLIGENT_REVIEW_EXCLUDE_PATHS` 获取的。但是我没有看到这个常量的定义，需要确认它是否存在以及内容是否合适。\n\n\n  不过基于现有信息，最主要的问题是NPE风险。我现在准备提交这个问题的反馈。",
  "tool_calls": [
    {
      "type": "function",
      "function": {
        "name": "code_comment",
        "arguments": "{\"comments\":[{\"comment\":\"可能存在空指针异常风险。projectCodeReviewSettingsService.getAiReviewSettings(projectId) 的返回值可能为 null，这种情况下调用 aiReviewSettings.getAiReviewSetting() 将抛出 NullPointerException。建议增加空值检查。\"}]}"
      }
    }
  ]
}

- path: "**/enums/**.java"
  rule: "枚举类新增枚举值时，检查所有使用该枚举的 switch 语句是否处理了新值，避免遗漏分支"

- path: "**/{model,dto,do,entity}/**.java"
  rule: "避免字段隐藏的风险，例如在子类增加父类中已有的字段，或者在父类中增加子类已有的字段。"

- path: "***.java"
  rule: "记录日志时必须使用代码库内部的FormatLogUtil工具类"

- path: "**/mapper/**.xml"
  rule: "禁止多表关联查询时超过 5 张表，防止复杂多表关联导致的性能问题。"

- path: "***.java"
  rule: "金额计算应使用BigDecimal而不是double。"

• 课题一：大小模型协同机制的研究

• 课题二：生成式推荐技术在全球化电商的探索和应用

• 课题三：多模态场景下的AI Coding Agent探索与评测

• 课题四：面向大规模异构算力集群的Profiling-based Auto-FDO联合优化

• 课题五：AIGC高性能推理加速技术研究

• 课题六：基于ECS故障预测专有领域知识的模型研究

• 课题七：面向 Agent 进化的自适应语义数据引擎研究

• 课题八：面向世界模型的高效推理基础设施研究

• 课题九：大模型推理中的新型存储部件软硬件结合设计研究

• 课题十：故障应急处置 AIOps 研究

• 课题十一：面向LLM全生命周期的系统能效评测基准与自适应优化技术

• 课题十二：AI智算中心综合能源系统优化

申请人须为全球高校/科研机构的全职学者或研究人员。

• 2月28日24:00前：开放征集环节

• 3月31日前：申报评审环节

官方邮箱：university_collaboration@service.alibaba.com

课题介绍及申报书模版，请咨询官方邮箱。

请注意：您从官方邮箱处获得的相关材料，未经我们的同意不得向社会公开展示或提供给全球高校/科研机构以外的第三方。

据有关推测，到2026年，全球数据总量中非结构化数据占比将超过80%，而结构化数据比例将逐渐下降。AI正成为数据第一消费者，日益快速增长多模态数据价值释放与当前非结构化数据处理能力存在结构性矛盾：

• 存储层面：缺失高效多模态数据储存格式或统一存储系统满足多模态数据高效存储、数据处理、高吞吐IO、批查点查训练及推理需要，存在GPU等数情况；

• 引擎层面：多引擎适配统一存储需求同样存在于多模态数据场景中，如实时特征处理、数据检索、OLAP分析等；相较于现有传统大数据处理框架局限性，AI类引擎如Ray专为AI设计，涵盖训练、计算、数据处理模块，支持CPU、GPU混合计算，需考虑扩展AI类计算引擎引入；

• 平台层面：无统一多模态数据处理平台，处理流程割裂；传统数据研发期待数据处理SQL化，算法同学数据处理倾向脚本化；处理链路涉及多平台导致预算多处管理，数据及模型血缘存在缺失；

• 数据治理：无统一元数据管理、数据检索及权限管理体系，存在找数难、烟囱处理挤压基础计算资源；缺失类似传统结构化数据分层、质量管理等数据建设方法论体系和标准化处理手段。

多模态数据存储需要支持包括文本、图像、音频、视频、嵌入向量等在内的多模态文件。需满足多模态数据入湖的需求，并实现多模态数据和结构化数据的统一存储和高效管理。

大多数多模态文件实际上并不大，大约1MB左右，甚至不到1MB，但也有相对较大的多模态文件，比如10GB以上的文件。

三种解法：

• 多模态数据以二进制方式直接存储在列式文件中，如Parquet或Lance文件。这种解决方案的最大问题是它给文件格式带来了挑战，例如解决内存溢出（OOM）的读写问题，这需要对文件格式使用流式API，以避免加载整个多模态数据。此外，多模态数据的额外字段可能会频繁更改、增加甚至删除。如果这些更改要求多模态文件一起参与读写，则成本非常高。

• 多模态数据存储在对象存储中，而Parquet通过指针引用这些文件（记录真实文件地址）。这样做的不利之处在于，它无法直接管理多模态数据，并可能导致产生大量小文件，这些小文件在使用过程中会产生大量的文件IO操作，从而导致性能下降和成本增加。

• 在解法2的基础上，小文件打包成一个文件。虽然一定程度上解决了小文件问题，但文件管理上的难度却增加了。

可见，我们应该考虑新的方式来满足这一需求。创建一个专为海量小型和大型多模态文件混合场景设计的高性能架构，实现高吞吐量写入和低延迟读取，满足AI、大数据和其他业务的严格性能要求。

为解决如上问题，ALake提供统一多模态数据存储方案和元数据体系，并引入与结构化数据一致的用户鉴权及数据安全体系，做到数据统一集中管理。同时，与AI类引擎进行统一对接。

图3-1：ALake非结构化（多模态）数据存储处理方案

Paimon提供了多模态数据存储全新方案：采用独立的多模态存储和结构化存储，对多模态存储进行单独管理，引入blob文件机制来存储多种多模态数据：.parquet保存所有结构化字段，而blob字段列则单独保存在一个.blob文件中。

图4-1：blob文件机制

4.1.1 高效列式存储

• 按需加载：读取非blob列时，不会加载blob数据，节省I/O资源

• 减少内存占用：只加载需要的数据列，提高查询效率

• 网络传输优化：减少不必要的数据传输

4.1.3 更好的数据压缩

• 列式压缩：针对列式数据提供更高效的压缩算法

4.2.2 小结

• Spark：blob字段为BINARY，Flink：blob字段为BYTES。

• 需要指定blob-field。

• target-file-size（建议设置为4GB）为预期内单个.blob文件大小，写入时会合并多模态数据为这个大小：解文件数问题。

• 必须在建表时row-tracking.enabled、data-evolution.enabled设置为true：blob使用强依赖Paimon的行版本控制、加列这两个能力。

• blob-as-descriptor需要设置为true，从实际应用视角，此配置必备，后面会展开。

• 多个blob数据存储到一个.blob文件中。

• 可根据索引快速查询blob的偏移量和长度。

图4-2：blob file

4.3.1 blob format

图4-3：blob format

• CRC32校验和：每个blob条目都有一个CRC32检验和，用于数据完整性验证

• 索引访问：末尾的索引允许对文件中的任何blob进行高效的随机访问

• 增量变量压缩：该索引使用增量变量压缩来提高空间效率

4.3.2 小结

.blob是一种专门存储二进制对象（如图片、视频）的文件格式，采用magic number、文件二进制、文件长度信息和CRC32校验和的结构，通过文件末尾的Delta-Varint压缩索引实现快速随机访问，支持顺序扫描和高效查询，确保数据完整性的同时优化存储空间和访问性能。

设置blob-as-descriptor = true后，可以对非常大的blob进行内存高效读写：

• 写时通过一个指向外部数据的BlobDescriptor，Paimon将数据从外部源流式传输到Paimon的.blob文件中，而无需将整个blob加载到内存中。

• 读时查询blob字段返回的是BlobDescriptor而不是实际文件，可以通过BlobDescriptor拿到文件的inputstream，流式读避免内存溢出。

写入：序列化的BlobDescriptor（包含外部数据源URI、偏移量、长度）作为blob字段值

Paimon复制数据：Paimon从BlobDescriptor的URI读取小块（例如，一次1024个字节），并流式写入Paimon的.blob文件

主要优势：内存效率：对于非常大的blob文件（例如，千兆字节大小的视频），不需要将整个文件加载到内存中。Paimon以增量方式流式传输数据。

实战：BlobDescriptor的使用案例，请详见章节5.2（写入）和5.4.1（消费）

• blob-as-descriptor = true时，一行只支持存在一个blob字段

• blob字段仅支持append表，不支持主键表

• blob列不支持谓词下推

• blob列不支持统计信息收集

• row-tracking.enabled和data-evolution.enabled必须设置为true

4.6.1 写入多模态数据时，blob-as-descriptor=true/false的实现、存储了什么

表4-2：blob_as_descriptor配置

long size = this.inputFileIO.getFileSize(new Path(ossUri));
BlobDescriptor blobDescriptor = new BlobDescriptor(ossUri, 0L, size);
return blobDescriptor.serialize();

return  inputFileIO.readFileUtf8(new Path(ossUri)).getBytes();

4.6.2 BlobDescriptor作用

缓冲层、懒加载

• 写入时通过URIReader拿到BlobDescriptor（这一部分根据业务逻辑自己实现）后把对应的文件流写入.blob文件，避免内存溢出（这一部分由Spark Writer调用Paimon底层实现）

• 读取时可以由BlobDescriptor拿到实际文件的inputstream，流式读避免内存溢出

4.6.3 blob底层存的是什么，.parquet放了什么，.blob放了什么

无论写入时descriptor=true还是false，底层都是一份 .parquet + 一份.blob

4.6.5 写入时，BlobDescriptor的二进制是否落到了Pangu上持久化

没有。blob-as-descriptor配置和BlobDescriptor对象，都是运行时参数。

4.6.7 查询时底层是如何拿到的BlobDescriptor

Paimon会在运行时解析.blob文件，拿到BlobDescroptor的二进制。

4.6.8 运行时解析BlobDescriptor不会全量扫描.blob文件吗

如4.3章节所述：

• .blob支持索引访问：末尾的索引允许对文件中的任何blob进行高效的随机访问，能够快速拿到offset和length。

• uri为.blob文件的路径地址。

因此，可以快速拿到BlobDescroptor的二进制，不需要全量扫描。

4.6.9 小结

综上所述，实际使用blob功能时，为了起到缓冲层和懒加载的效果，建议开启blob-as-descriptor=true，利用BlobDescriptor根据业务逻辑获取并使用实际文件。

业务方使用数据湖多模态存储方案从OSS入湖日增 PB级。迁移前后的数据CRC完全对齐。生产上音频推理链路已在Paimon Blob方案上完全走通，E2E耗时相比OSS方案总体减少约10%。

5.2.1 背景

多模态数据面临存储效率低、引擎适配难、平台分散割裂、治理体系缺失四大挑战。使用数据湖多模态数据存储方案一站式解决这些问题是大势所趋。

5.2.2 写入实现

CREATE TABLE IF NOT EXISTS alake.unstructured_alake_mlm.zpx_blob_test (
    id STRING,
    oss_path STRING COMMENT '原始oss路径',
    content BINARY
)
PARTITIONED BY (ds STRING)
TBLPROPERTIES (
'comment' = 'blob格式表',
'partition.expiration-time' = '365 d',
'row-tracking.enabled' = 'true',
'data-evolution.enabled' = 'true',
'blob-field' = 'content',
'blob-as-descriptor' = 'true'
);

INSERT OVERWRITE TABLE alake.unstructured_alake_mlm.zpx_blob_test
SELECT
  id,
  oss_path,
  rest.alake_dt_test.gen_paimon_blob(oss_path) AS content,
  ds
FROM (
  SELECT /*+ repartition(10000) */  
  id,
  oss_key as oss_path,
  ds
 FROM vedio_meta.s_raw_meta_mlm_sink_lake_vedio
 WHERE ds = '20251201'
) t;

5.2.2.1 写入UDF

public byte[] evaluate(String ossUri) throws IOException {
    init(ossUri);
    long size = this.inputFileIO.getFileSize(new Path(ossUri));
    BlobDescriptor blobDescriptor = new BlobDescriptor(ossUri, 0L, size);
return blobDescriptor.serialize();
}
private void init(String uri) throws IOException {
if (this.sparkConf == null) {
        synchronized (OssMigrate.class) {
            Map<String, String> allConfs = (Map<String, String>) JavaConverters.mapAsJavaMapConverter(SQLConf.get().getAllConfs()).asJava();
            this.sparkConf = ConfigFactory.makeSparkConf(allConfs);
            this.inputFileIO = FileIO.get(new Path(uri), makeCatalogContext(this.sparkConf, new HashMap<>()));
        }
    }
}
private CatalogContext makeCatalogContext(SparkConf sparkConf, java.util.Map<String, String> extraConf) {
    Configuration hadoopConf = new Configuration();
for (Tuple2<String, String> entry : sparkConf.getAllWithPrefix(this.hadoopConfPrefix)) {
        hadoopConf.set(entry._1(), entry._2());
    }
    extraConf.forEach(hadoopConf::set);
return CatalogContext.create(Options.fromMap(new HashMap<>()), hadoopConf);
}

这个方法实际上并没有将文件内容读取到内存中，而是创建了一个 BlobDescriptor 对象，其中包含：

• 文件 URI (ossUri)

• 偏移量 (0L)

• 文件大小 (size)

然后调用 blobDescriptor.serialize将这些元数据序列化为字节数组。

5.2.2.2 BlobDescriptor 的序列化格式

BlobDescriptor.serialize方法将元数据序列化为二进制格式：

• 版本号 (1字节)

• URI 长度 (4字节)

• URI 字符串

• 偏移量 (8字节)

• 长度 (8字节)

5.2.2.4 实际文件落地过程

当数据写入 Paimon 表时，实际的文件落地过程如下：

1. 写入阶段：

• 结构化数据（id, oss_path, ds）写入 .parquet 文件

• 写入时URIReader拿到BlobDescriptor->Spark Writer调用Paimon SDK把对应的文件流写入.blob文件，避免内存溢出

2. 读取阶段：

• 当查询需要访问 blob 数据时，Paimon 会解析.blob文件信息为 BlobDescriptor

• 根据 BlobDescriptor 中的 URI 等信息从原始位置读取实际的文件内容

5.3.1 背景

AI引擎平台是面向集团内广告搜索推荐的一站式深度建模工程平台，覆盖从特征引入、样本构建、到模型训练及交付上线整个算法迭代环节。

以往，AI引擎平台推理集通常由ODPS元数据表 + OSS文件组成。而现在，只需要一张包含blob字段的Paimon表即可。

5.3.2 推理实现

def elastic_infer_tts(args, batch_size, process_fn, output_col_num=1, **kwargs):
#解析输入表
    input_table = args.tables
    output_table = args.output_table
print(input_table)
print(output_table)
    dataset = DistributeDataset(input_table, shuffle=False)
    dataset_ld = torch.utils.data.DataLoader(dataset, num_workers=1, batch_size=batch_size, collate_fn=lambda x: x)
# Paimon输出配置
    output_config = {
'paimon_table_name': output_table, //alake_video_zhaopengxiang_output
'lake_schema': [
            ['aid', 'audio_path', 'meta', 'processing_history', 'result', 'ds', 'source', 'shard'],
            ['string', 'string', 'string', 'string', 'string', 'string', 'string', 'string']
        ],
'partition_keys': ['ds', 'source', 'shard'],
'buffer_size': 1000,
    }
print("输出paimon表配置")
print(output_config)
    with ElasticInferProcess(dataset_ld, output_config) as EIP:
for batch in tqdm(EIP, desc="AUDIO PROCESS ->  ", total=len(dataset_ld), unit="batch"):
            new_batch = []
if"single_thread"in kwargs and kwargs["single_thread"] == True:
print("single-threading is enabled.")
for row in batch:
                    process_res = process_fn(args, row, bucket)
if isinstance(process_res, list):
print("paimon输出为list")
                        new_batch.extend(process_res)
else:
                        new_batch.append(process_res)
print("paimon输出为元组")
else:
print("multi-threading is enabled.")
                futures = []
                with ThreadPoolExecutor() as executor:
for row in batch:
                        future = executor.submit(process_fn, args, row, bucket)
                        futures.append(future)
for future in futures:
                        process_res = future.result()
if isinstance(process_res, list):
                            new_batch.extend(process_res)
else:
                            new_batch.append(process_res)
print("开始sink到paimon表")
            EIP.trace(new_batch)

{
"vad_results": {
"segments": [
            {
"segment_wav_id": "a0331317e90f2ebf5064d3cc35e57fff_0.000",
"start_time": "0.000",
"end_time": "25.220",
"segment_duration": 25.22,
"temp_local_path": "/tmp/audio_segment_a0331317e90f2ebf5064d3cc35e57fff_1764644423_65220111_1b5b7bd6-71f2-413b-bf5b-6ed607213e73/bef020ca9fc4303e7b1c6eb50043e163.wav",
"language": "ja",
"predict_whisper_large_v3_text": "日 本 语 が 好 き で す か 日 本 语 が 好 き で す か",
"predict_sensevoice_text": "日本人の方へメッセージがあります本日の動画英語でやらせただきます外国人に話したいことい々あるので字幕を入れとくのでそのままぜ非ご覧ください最後までと言いまチャンネル登録をよろしくお願いします",
"sensevoice_tags": "<|ja|><|NEUTRAL|><|Speech|><|woitn|>",
"predict_firered_asr_aed_text": "DO YOU LIKE JAPAN ARE YOU INTERESTED IN JAPAN THEY DO ME A FAVOR AND STICK AROUND YOU'RE GONNA WANNA HEAR WHAT I'M GONNA TALK ABOUT NIHONG JINO KATAI MESSAGE YADDAI MAS KHONG JITSUNO DOGA EGO DE YADDAI YADDA YADDA YADDA LIKE MAS GEIKO KUJIN NI HANNA STEI KOTO ILORADNO DE JIMAKU IDA TOKUNO DE TONO MAMA ZEHI KORAN KURAZAI SAIGAMA DE STI BUTE CHANDOS TIBITOY MAS CHANDERUTORO KU OYOYOS KUO HANNIKA SHIMAS GUYAZ MY NAME IS STEVE NAME IS CHANNO STEVE'S P O V",
"punc_firered_asr_aed_text": "DO YOU LIKE JAPAN ARE YOU INTERESTED IN JAPAN THEY DO ME A FAVOR AND STICK AROUND YOU'RE GONNA WANNA HEAR WHAT I'M GONNA TALK ABOUT NIHONG JINO KATAI MESSAGE YADDAI MAS KHONG JITSUNO DOGA EGO DE YADDAI YADDA YADDA YADDA LIKE MAS GEIKO KUJIN NI HANNA STEI KOTO ILORADNO DE JIMAKU IDA TOKUNO DE TONO MAMA ZEHI KORAN KURAZAI SAIGAMA DE STI BUTE CHANDOS TIBITOY MAS CHANDERUTORO KU OYOYOS KUO HANNIKA SHIMAS GUYAZ MY NAME IS STEVE NAME IS CHANNO STEVE'S P O V。",
"punc_whisper_large_v3_text": "日本语が好きですか日本语が好きですか。",
"punc_sensevoice_text": "日本人の方へメッセージがあります本日の動画英語でやらせただきます外国人に話したいことい々あるので字幕を入れとくのでそのままぜ非ご覧ください最後までと言いまチャンネル登録をよろしくお願いします。",
"asr_score": {
"whisper_sensevoice_wer": "4.83",
"predict_whisper_large_v3_text_lens": 8,
"predict_sensevoice_text_lens": 25,
"whisper_firered_wer": "5.06",
"predict_firered_asr_aed_text_lens": 88,
"sensevoice_firered_wer": "1.00",
"audio_lens": 25220
                }
            }
        ]
    }
}

弹内生产上AI引擎平台已经接入Paimon Blob的相关能力，用户可以直接使用。

5.3.3 Paimon Blob 处理 VS OSS + ODPS 处理

处理流程包含以下步骤： 

音频下载 && FFmpeg 处理 && 加载到内存 → base_info 提取 → VAD 有效音频检测 → SNR 信噪比检测 → DIA 人声分离

可见，对于同一批音频数据推理：

下载 + FFmpeg 处理 + 加载到内存，此阶段 Paimon Blob明显更快。后续推理步骤的耗时几乎一致。此任务下，Paimon Blob方案相比OSS方案总耗时有10%左右提升。

Ray提供了一个分布式流式Python计算框架，类比Spark、Flink，Ray提供了Python脚本大规模并发的能力。

5.4.1 计算CRC校验完整性、一致性

当多模态数据以blob形式存储在Paimon里，我们可以计算CRC64校验和来验证数据完整性和一致性。

Ray通过pypaimon打通弹内Paimon Blob（支持DLF2.5鉴权）：

from pypaimon import CatalogFactory
from pypaimon.table.row.blob import BlobDescriptor, Blob
from pypaimon.common.uri_reader import UriReaderFactory
import crcmod
import ray
import logging
@ray.remote
def paimon_read():
    options = {
'metastore': 'alake',
'warehouse': 'alake',
'uri': 'metastore-inner.aliyuncs.com',
'dlf.region': 'cn-hangzhou',
'token.provider': 'bear',
'dlf.access-key-id': "LTAI5tEVmvU28awuDU5GiYUN",
'dlf.access-key-secret': "xx",
    }
    catalog = CatalogFactory.create(options)
    table_name = 'unstructured_alake_mlm.zpx_blob_test_v14'
    table = catalog.get_table(table_name)
    table_options = table.options
    table_options['blob-as-descriptor'] = 'true'
    read_builder = table.new_read_builder()
    table_scan = read_builder.new_scan()
    table_read = read_builder.new_read()
    result = table_read.to_arrow(table_scan.plan().splits())
    result_bytes = result.column('content').to_pylist()[0]
    crc64_func = crcmod.mkCrcFun(0x142F0E1EBA9EA3693, initCrc=0, xorOut=0xFFFFFFFFFFFFFFFF)
    try:
print(table_name + "read success")
        new_blob_descriptor = BlobDescriptor.deserialize(result_bytes)
        uri_reader_factory = UriReaderFactory(table_options)
        uri_reader = uri_reader_factory.create(new_blob_descriptor.uri)
print(f"URI: {new_blob_descriptor.uri}")
        blob = Blob.from_descriptor(uri_reader, new_blob_descriptor)
        blob_data = blob.to_data()
        crc64_value = crc64_func(blob_data)
print(f"CRC64: {crc64_value}")
return f"CRC64: {crc64_value}"
    except Exception as e:
print(f"Error get table: {str(e)}")
return f"Error: {str(e)}"
if __name__ == "__main__":
    ray.init(logging_level=logging.INFO, log_to_driver=True)
    result = paimon_read.remote()
    result_value = ray.get(result)
print(f"Function result: {result_value}")