Hive 通过目录、分区和 Metastore 管理大规模数据，但当数据进入对象存储、单表扩展到数百万个文件，并由多个计算引擎并发读写时，目录 Listing、非原子 Rename、分区耦合和 Schema 演进等问题逐渐成为系统瓶颈。Iceberg 最初诞生于 Netflix，核心目标正是重新定义超大规模分析表的状态管理方式。
Iceberg 不再通过目录推断表中包含哪些文件，而是使用 Catalog、Snapshot、Manifest List 和 Manifest 构建不可变的元数据树，将一次表变更原子发布为新的快照。这套架构为数据湖补充了快照隔离、乐观并发控制、快速查询规划、时间旅行以及安全的 Schema 和 Partition Evolution。
上一篇文章介绍了机器人如何从传感器观测中估计自身与环境状态。但即使知道杯子和托盘的准确位姿，“把杯子放进托盘”仍不是一条可直接执行的指令：机器人还要确定动作顺序和抓取方式，规划无碰撞路径，并将路径转换为满足关节与速度约束的运动轨迹。
本文沿着“任务目标到可执行轨迹”的链路，介绍任务规划、抓取规划、运动规划、碰撞检测、轨迹优化与在线重规划的基本原理，理解机器人如何在身体约束和环境变化中，将抽象目标转化为能够被控制器执行并持续修正的动作。
上一篇文章介绍了机器人如何通过运动学、动力学与控制，将目标位姿转化为身体运动。但在行动之前，机器人首先要知道自己在哪里、周围有什么，以及环境正在怎样变化。相机、深度传感器、IMU 和编码器提供的只是带有噪声的原始观测，还不能直接成为规划与控制所需的世界状态。
本文沿着“传感器观测到世界状态”的链路，介绍相机模型与标定、RGB-D 与点云、物体位姿估计、滤波融合和 SLAM 的基本原理，理解机器人如何从离散的传感器信号中恢复空间关系，并形成连续、可信的状态估计。
上一篇文章解决了机器人如何描述身体与世界：通过自由度、坐标系、旋转和 SE(3)，视觉系统能够将“图像中的目标”转换为机械臂可以理解的抓取位姿。但位姿只说明夹爪应该到达哪里、保持什么朝向，并没有告诉机器人身体应当怎样运动。
要将几何目标变成真实动作，系统还需要求解关节配置，规划关节的速度与加速度，计算克服惯性、重力和接触所需的力矩，并根据执行误差持续纠偏。这条链路分别对应运动学、动力学与控制。
上一篇文章从 Observation、State 与 Action 出发，建立了具身智能的整体框架：机器人通过执行闭环完成当前任务，再通过学习闭环将交互经验转化为新的能力。但当这些抽象概念落到真实机器人上，首先要解决一个更基础的问题：如何把机器人的身体、周围物体以及二者之间的空间关系，表示成可以计算和执行的数据。
仍以“把桌上的杯子放进托盘”为例。视觉系统可以识别杯子，并估计它在相机坐标系中的位置；机械臂规划和执行动作时，却需要知道杯子相对机器人基座在哪里、末端执行器当前是什么姿态，以及各个关节应该如何运动。机器人必须结合关节状态、相机外参和坐标变换，才能将“图像中的杯子”转换为“身体能够到达的抓取位姿”。坐标方向、旋转顺序、时间同步或标定参数的任何偏差，都可能让语义正确的决策变成物理世界中的错误动作。
大语言模型已经能够处理文本、代码和数字工具，但当任务变成“把桌上的红色杯子放进左边托盘”时，智能面对的便不再只是信息。机器人还需要感知环境、估计状态、规划并执行动作，再根据物理反馈持续纠错。这正是具身智能的核心：让智能依托具体身体，在环境中形成观察、决策、行动和反馈的闭环。
作为具身智能系列第一篇文章，本文暂不深入运动学、控制算法和 VLA 的模型细节，而是先建立整体认知：具身智能是什么、技术路线如何演进、现代系统怎样连接 Observation、State 与 Action，以及执行闭环和学习闭环如何协同工作。最后，本文还将结合截至 2026 年的行业进展，讨论下一阶段的竞争重点与技术趋势。
Hive 通过 Schema、分区、Metastore 和 SQL，将 HDFS 上的文件组织成可管理、可查询的数仓表，奠定了大数据离线数仓的基础。但随着原始日志、事件流和机器学习数据快速增长，企业开始需要更低成本的共享存储，并让多个计算引擎访问同一份数据，数据湖架构由此逐渐形成。
早期数据湖解决了开放存储、弹性扩展和多引擎访问问题，却没有完整解决事务提交、更新删除、并发写入和版本管理。特别是面对数据库 CDC 和高频 Upsert，传统的分区覆盖与批量重写成本越来越高。Hudi 由此在文件之上补回增量存储内核：通过 Timeline 管理提交与可见性，通过 Index 和 File Group 定位记录，并利用 COW、MOR 与 Table Services 平衡读写成本。
过去十年，大模型沿着规模化路线快速演进：参数、数据与算力的扩展提升了语言能力，后训练与强化学习增强了指令遵循和复杂推理，多模态、RAG、Agent、工具调用与记忆系统，则进一步把 LLM 从对话模型扩展为能够获取知识、理解信息并执行任务的智能系统。
随着能力边界不断外扩，一个更根本的问题随之出现：继续扩大模型规模、增加训练数据和推理计算，是否就能自然通向 AGI？AGI 全称 Artificial General Intelligence，即通用人工智能。虽然业界尚未形成统一定义，但它通常指能够跨领域理解和解决问题、将已有知识迁移到新任务，并在复杂环境中持续学习和行动的智能系统。相比之下，LLM 擅长从数据中学习语言与知识规律，却不天然具备可靠的因果理解、长期记忆、环境适应和行动能力。
软件开发是大语言模型最早展现规模化价值的领域之一。代码不仅具有语言的表达能力，还具备严格语法、明确依赖和可执行反馈。模型生成的结果可以通过编译器、静态检查和自动化测试进行验证，使 AI 能够形成“生成、执行、观察、修正”的完整反馈闭环。
AI Coding 的形态也由此不断演进：早期产品主要在编辑器中预测下一行代码；随后开始结合当前文件、仓库结构和开发者指令完成跨文件修改；如今，Coding Agent 已经能够调用文件系统、终端、Git 和测试工具，围绕一个工程目标持续探索、实现和验证，最终交付可审查的代码变更。
大语言模型的单次推理本身近似无状态：模型只能看到当前请求、上下文以及参数中已有的知识，并不会自动保存跨会话的用户状态。一次对话结束后，用户偏好、项目背景和未完成任务如果没有被外部系统记录，下一次交互时仍需要重新提供。
长上下文可以让模型一次读入更多历史，却不等于真正的记忆。持续拼接聊天记录不仅会增加 Token 成本和推理延迟，还会引入大量无关信息；更重要的是，它缺少独立的写入、检索、更新、冲突处理和删除机制。能“放下历史”，不代表能准确找到并使用历史。
大模型上线并不意味着能力建设结束。真实用户的问题远比训练集复杂：业务规则持续变化，输入分布不断漂移，RAG、工具和 Prompt 也会频繁升级。模型在离线评测中表现良好，进入生产环境后仍可能出现幻觉、格式错误、工具误调用和安全误判。
这些线上失败既是问题，也是改进模型和系统的重要数据来源之一。通过采集反馈与执行轨迹、定位失败原因、挖掘高价值样本，再经过标注、训练、评测和灰度发布，系统可以把真实问题持续转化为经过验证的能力提升。
大模型应用长期以云端推理为主：用户将请求发送到服务器，由 GPU 集群完成计算并返回结果。云端能够承载更大的模型，也便于统一更新和管理，但它始终受到网络延迟、推理成本、数据隐私和离线可用性的约束。
随着大模型进入输入法、语音助手、本地文件检索、相册理解和手机 Agent 等场景，推理需求开始向用户设备延伸。这些任务通常高频、实时，并涉及大量本地敏感数据，完全依赖云端不仅成本较高，也难以保证稳定的响应速度与隐私边界。
大模型能力越来越强，但推理成本也越来越高：参数规模变大，显存占用上升，计算开销增加，长上下文带来更大的 KV Cache，线上服务还要面对延迟、吞吐和并发压力。对于真实业务系统来说，模型不只是“能不能答得好”，还要看它能不能在可接受的成本和延迟下稳定运行。
模型压缩要解决的正是这个问题：在尽量少损失模型能力的前提下，降低参数存储、显存占用、计算开销和生成延迟。它不是单一技术，而是一组面向推理降本提速的系统优化方法，包括量化、剪枝、蒸馏、低秩分解、KV Cache 优化和 Speculative Decoding。
这一篇我们重点看清楚：大模型推理成本到底来自哪里，不同压缩技术分别优化哪一部分，以及在生产环境里应该如何根据瓶颈选择合适的压缩与加速方案。
大模型擅长理解语言、生成内容和进行推理，但如果只停留在文本生成层面，它很难真正进入业务系统。真实应用中的很多任务，并不是生成一段回答就结束，而是需要查询订单、检索文档、执行 SQL、调用接口、读取文件、发送消息，甚至触发一段完整的工作流。
这就需要一种机制，把用户的自然语言意图转换成业务系统可以执行的结构化调用。Function Calling 要解决的正是这个问题：让模型在理解任务之后，能够选择合适的工具，生成符合 Schema 的调用参数，再由应用侧完成校验、执行和结果回传。
大模型擅长理解语言、生成内容和进行推理，但它并不天然连接外部世界。它不知道你电脑里的文件、数据库里的最新记录、浏览器当前页面状态，也不能直接访问企业内部系统。要让模型从“回答问题”走向“完成任务”，就必须让它能够安全、标准化地读取资料、调用 API、查询数据库、访问代码仓库、操作浏览器，并触发业务工作流。
在 MCP 出现之前，每个 AI 应用往往都要自己适配外部工具：代码助手要接文件系统、Git、数据库、终端和浏览器；企业助手要接飞书、Slack、Notion、工单、CRM 和数据平台；不同 Agent 框架又会重复实现类似能力。这会带来典型的 N × M 集成问题：N 个 AI 应用分别适配 M 个外部系统，连接方式、权限模型、工具描述和返回格式都不统一。
大模型能力很强，但并不意味着“随便问一句”就能稳定得到高质量结果。在真实业务系统里，模型输出会同时受到指令、上下文、历史对话、检索资料、工具结果、采样参数和安全策略影响。只要其中任何一环组织不好，模型就可能答非所问、格式不稳定、遗漏关键证据，甚至被恶意内容诱导执行错误指令。
提示词工程和上下文工程要解决的，就是如何把用户意图、任务约束、外部知识和输出要求，组织成模型更容易理解、更容易遵循的输入。Prompt 不是魔法咒语，而是大模型应用里的调用协议；Context Engineering 也不是简单把内容塞满，而是让模型在正确的位置看到正确的信息。
这一篇我们重点看清楚：Prompt、System Prompt、Few-shot、模板化 Prompt、结构化输出、上下文组织和 Prompt Injection 分别解决什么问题，以及如何更稳定、更可控地调用大模型能力。
在大模型落地到真实业务时，经常会遇到一个问题：基础模型能力很强，但并不一定适合当前场景。它可能不熟悉某个行业的表达习惯，不能稳定遵循业务输出格式，也可能在客服、代码审查、合同分析、工单分类这类垂直任务上表现不够一致。
要解决这类问题，常见有两条路线：一条是 RAG，把外部知识检索出来放进上下文，让模型基于资料回答；另一条是微调，用特定任务数据继续训练模型，让模型的行为、表达方式和任务能力更贴近目标场景。
微调本身也有不同层次：从更新全部参数的 Full Fine-tuning，到只训练少量增量参数的 LoRA、QLoRA。前者能力上限更高，但成本更大；后者更轻量、更易落地，也因此成为很多团队适配垂直场景时最常用的方法。这一篇，我们就从全量微调讲到 LoRA，看清楚大模型到底是如何被“定制”的。
大模型能力越来越强之后，一个新的问题会变得越来越重要：模型到底靠不靠谱？
在 Demo 场景里，模型回答得流畅、看起来聪明，往往就足够吸引人。但在真实业务系统里，“看起来对”远远不够。企业知识问答不能编造来源，代码助手不能给出错误的修复建议，RAG 不能越权召回文档，Agent 不能误调用高风险接口，多模态模型也不能把图表、截图或视频内容看错后还自信回答。
所以，大模型进入生产环境之后，核心问题会从“模型能不能回答”，进一步变成“回答是否正确、是否忠于证据、是否稳定安全、是否可追溯、是否能持续评估和改进”。这就是评测与安全要解决的问题：用评测判断能力边界，用安全策略约束风险行为，用监控和回归测试保证系统持续可靠。
过去的 LLM 主要围绕文本展开：用户输入一段文字，模型基于上下文生成回答。这个范式已经足够强大，可以支持问答、总结、写作、代码生成和复杂推理。
但真实世界的信息并不只以文本存在。技术文档里有表格、架构图和流程图；代码排障经常伴随截图、日志和监控曲线；会议内容包含语音、视频和演示材料；移动端 Agent 还需要理解界面布局、按钮位置和操作反馈。
如果模型只能处理文本，它看到的世界是不完整的。很多重要信息会在“转成文字”的过程中丢失，比如图像中的空间关系、图表中的趋势变化、视频中的动作过程，以及界面中的布局结构。这就是多模态要解决的问题。
大语言模型最初主要以对话式交互的形态被广泛使用：用户输入问题，模型基于上下文生成回答。在这一模式下，模型擅长完成信息解释、文本总结、代码生成、问题分析等任务，本质上仍然是一个以“生成答案”为核心的系统。
但在真实业务场景中，很多任务并不止于生成一段文本。它们往往需要模型围绕一个目标，连续完成资料检索、文档阅读、接口调用、代码修改、测试执行、结果分析和错误修正等多个步骤。也就是说，系统需要的不只是语言生成能力，还需要任务分解、外部工具使用、状态维护和基于反馈持续调整的能力。这就是 Agent 要解决的问题。