ITPub博客

当 LLM 从聊天框走向业务系统，Agent 与数据库的关系正在被重新定义。它不再只是“写 SQL 的机器人”，而是把数据库当作感知、记忆、决策与执行的共同底座。依据现有素材判断，行业仍处在模式探索期，但几条关键路径已经清晰。 Agent 使用数据库的四种模式 1. 文本转 SQL：最直观，也最容易被高估 最容易被理解的模式，是让 Agent 把自然语言转成 SQL。用户问“上个月华东区退货率最高的品类是什么”，Agent 生成查询、执行、再把结果转成自然语言。 这条路的价值在于低门槛，但问题也很明显： Schema 理解成本高：真实库有几百张表、复杂外键、历史遗留字段，Agent 很容易“看起来查对了，其实口径错了”。 权限与安全边界模糊：让模型直接生成 SQL，等于把数据库暴露在自然语言攻击面之下。 结果不

从“人查数据”到“Agent 用数据”：数据库的交互范式正在换轨 过去四十年，数据库的核心服务对象是人——更准确地说，是写 SQL 的开发者、看报表的分析师、点按钮的业务人员。所有的查询语言、索引结构、事务模型、权限体系，都是围绕“人类提出明确问题、数据库返回确定结果”这一范式建立的。 但 LLM 驱动的 AI Agent 正在打破这个前提。当一个 Agent 自主规划任务、调用工具、读写记忆、在多轮推理中反复查询和更新状态时，它对数据库的需求和人类用户截然不同： 查询是高频、碎片化、语义化的，而不是低频、批量化、结构化的； 读写边界模糊，Agent 既在消费数据，也在生产数据（记忆、中间结果、工具调用记录）； Schema 可能动态演化，因为 Agent 面对的任务域本身就不固定； 延迟敏感度极高，Agent

过去几年，人工智能（Artificial Intelligence）几乎以一种不容置疑的方式，成为全球技术产业的主线。从生成式 AI 引爆公众想象，到大模型（LLM）进入搜索、办公、编程、客服、设计等场景，再到算力、数据、芯片、云服务被重新定价，AI 已经不只是实验室里的研究方向，而是一股正在重塑产业结构、工作方式与竞争格局的现实力量。 但当我们站在今天回看，会发现一个越来越清晰的趋势：人工智能的竞争重点，正在从“谁的模型更大”转向“谁的智能更有用”。这不是一句口号，而是技术、商业与产业逻辑共同推动的结果。依据现有素材判断，我们无法引用具体厂商的最新产品版本、参数规模或市场数据，但仍可以从行业公开讨论与技术演进方向出发，梳理 AI 正在经历的深层变化。 从参数竞赛到价值竞赛：AI 进入“落地深水区” 过去一段时

引言：当 AI 不再只是“一问一答” 过去几年，我们习惯了与 AI 的对话式交互：提问、回答、再提问、再回答。这种“回合制”的模式虽然高效，却暴露了一个根本性局限——AI 更像一个反应敏捷的“短跑选手”，而非能够持续奔跑的“马拉松运动员”。 然而，这一格局正在被打破。依据现有素材判断，AI 在长程任务（Long-Horizon Tasks）领域取得了非常大的突破。这意味着 AI 正从“秒回”式的单步响应，走向能够规划、执行、纠错并完成复杂多阶段任务的“长跑”模式。这不仅是技术指标的跃升，更可能重塑人机协作的底层逻辑。 什么是长程任务？为什么它如此困难？ 在讨论突破之前，有必要先厘清概念。长程任务通常指需要多个步骤、跨越较长时间跨度、且中间状态需要持续维护的复杂任务。例如： 自主完成一个软件项目的需求分析、编码、

Vibe Coding 让“凭感觉写代码”从玩笑变成方法论。但当 AI 从编辑器走向整个工作流，一个更大的命题浮出水面——我们是否正在进入“Vibe Working”时代？依据现有素材判断，这不是一次工具升级，而是一场关于工作方式的重新定义。 Vibe Coding：当“感觉”第一次被写进工程流程 Vibe Coding 这个词最初带着一点戏谑。它描述的是一种状态：开发者不再逐行推敲语法，而是用自然语言描述意图，让 LLM 生成代码，自己只负责判断“这样对不对、感觉顺不顺”。代码从“手工艺品”变成了“对话产物”。 但戏谑背后有真实的变化。传统编程要求人把意图翻译成机器能执行的精确指令，这个翻译过程本身就是门槛。Vibe Coding 把门槛从“会写”挪到了“会判断”——你不需要记住 API 的每个参数，但你需要

当大模型参数规模从百亿跃迁至万亿，当单卡算力从百T级迈向千T级，当云厂商的AI资本开支屡屡刷新纪录，一个无法回避的问题摆在所有人面前——AI模型、AI芯片与AI云这三条主线，究竟正在形成正向飞轮，还是正在酝酿一场结构性泡沫？依据现有素材判断，我们尝试从产业逻辑而非营销话术出发，给出一些冷静的观察。 三线共振的底层逻辑：模型需求倒逼芯片，芯片能力重塑云 1.1 模型侧：从“能跑通”到“跑得起” 过去两年，AI模型的发展主线非常清晰：参数规模持续膨胀，多模态能力不断叠加，推理成本成为比训练成本更棘手的长期问题。训练一次万亿参数模型动辄需要数千张加速卡连续运行数周，而推理侧面对的是每天数亿甚至数十亿次的调用请求。 这意味着，模型能力的竞争，本质上已经演变为单位算力产出效率的竞争。谁的模型能在同等芯片资源下提供更低延迟

过去两年，企业级 AI 的主旋律是大模型接入与 Copilot 式问答。但真正决定商业价值的，不是模型能不能回答问题，而是 Agent 能不能把一件事从头到尾办完。当 Agent 开始嵌入审批、工单、合同、报销、客服、运维等真实业务流程，企业和 SaaS 厂商面对的问题，已经从“要不要用 AI”变成“流程要不要为 Agent 重新设计”。 Agent 不是更聪明的聊天框，而是流程里的新执行单元 如果只把 Agent 理解为“会调用工具的聊天机器人”，企业很容易低估它的冲击力。依据现有素材判断，Agent 在企业场景中的核心变化，不是交互方式从输入框变成对话，而是它开始承担原本由人串联的跨系统动作：读取订单、核对库存、生成工单、发起审批、更新客户记录、触发通知。它不再只是信息入口，而是一个可以进入流程、改变流程状

过去三十年，协作软件的核心命题始终是“让人与人更好地一起工作”。邮件、IM、在线文档、项目管理工具，本质上都在解决同一个问题：把信息从一个人的脑子里，搬到另一个人的屏幕上，并确保它不被丢失、误解或遗忘。 但过去两年，这个命题悄悄换了主语。随着 LLM 能力的跃迁，Agent 不再只是“更聪明的输入框”，而是开始具备目标拆解、工具调用、状态记忆和多轮执行的能力。它第一次有资格被放进“协作网络”里，而不只是被当作一个功能按钮。 这意味着协作的边界正在从“人与人”扩展到“人与 Agent”，再进一步扩展到“Agent 与 Agent”。这不是一次界面升级，而是一次协作主体的扩容。依据现有素材判断，这一趋势已经在工程、运维、客服、内容生产等场景中露出雏形，但距离成熟仍有明显距离。 人与 Agent：协作不是“下指令”，

在大模型应用进入深水区之后，真正拉开成本差距的，往往不是模型单价，而是“有多少 Token 被浪费在了不该进入上下文的数据上”。本文讨论一个被低估的工程命题：如何用极低的 Token 成本完成数据的压缩与处理，让 LLM 只处理真正值得处理的部分。 Token 成本的核心矛盾：不是算不起，而是喂太多 过去两年，围绕 LLM 的成本讨论大多集中在两个方向：模型选型和推理优化。前者关心用哪个模型，后者关心怎么让推理更快更便宜。但在真实的生产系统里，一个更隐蔽的成本黑洞长期被忽视——进入上下文的数据本身没有被处理过。 一份 50 页的 PDF、一张包含复杂表格的截图、一段两小时的会议录音、一个上千行的日志文件，如果直接丢给模型，Token 消耗会迅速膨胀。更关键的是，这些 Token 中有相当比例是冗余的：重复的页眉

过去一年，围绕 Agent 的讨论大多集中在模型能力、提示词工程和工具调用协议上。但真正决定 Agent 能否从 Demo 走向生产系统的，往往不是模型本身，而是它脚下那层“被调用”的基础设施。依据现有素材判断，行业对 Agent 的注意力正在从“智能体有多聪明”转向“调用链有多可靠”。这不是一次简单的技术栈升级，而是软件架构重心的一次迁移。 Agent 调用的本质：一场被低估的“基础设施化” 传统 API 调用是确定性的：输入固定、路径清晰、超时可控。而 Agent 调用是概率性的、多跳的、带副作用的。一个用户请求可能触发规划、检索、工具调用、再规划、再调用，最终才落到某个真实系统上。这意味着，Agent 调用的基础设施必须同时解决四个问题：路由、隔离、可观测、成本。 第一，路由不再是简单的负载均衡。 Age

从“能聊”到“能干活”，中间隔着一条工程化的河 过去两年，大模型在企业侧的讨论焦点，已经从“要不要用”转向“怎么用得住”。Chatbot 式的问答助手证明了 LLM 的语言能力，却没能证明它能在真实业务流程里稳定交付结果。企业级 Agent 被寄予厚望，正是因为它试图补上这一段：不只是生成文本，而是调用工具、访问数据、执行多步任务，最终把一个业务动作闭环完成。 但依据现有素材判断，这个市场仍处在“概念清晰、产品分化、落地参差”的阶段。厂商发布会的演示往往流畅得令人心动，真实企业环境里的表现却常常受限于权限、数据、系统集成和责任边界。Agent 不是把模型接上几个 API 就结束了，它更像一次把 AI 能力嵌入企业 IT 治理体系的工程改造。 当前企业级 Agent 产品的几种典型形态 从产品形态看，市面上被称为

过去一年，Agent 几乎成了企业软件领域出现频率最高的词。从客服自动应答、销售线索跟进，到财务对账、供应链异常处理，几乎所有厂商都在讲同一个故事：让 Agent 接管流程，让人类只做决策。但真正进入企业核心业务流程的 Agent 项目，落地比例远没有演示视频里那么乐观。依据现有素材判断，制约 Agent 从“能演示”走向“能上岗”的最大瓶颈，不是模型能力，而是数据。 Agent 的能力上限，由它能看到的数据决定 1.1 模型决定“会不会”，数据决定“准不准” 大模型解决的是通用推理与语言理解问题，它让 Agent 具备了理解指令、拆解任务、调用工具的基础能力。但企业业务流程里的每一个动作，都依赖具体、实时、可追溯的业务数据：这张订单当前处于什么状态、这个客户的历史履约记录如何、这笔款项对应哪份合同、这个物料在

过去十年，治理平台的关键词是“规则”与“流程”；未来十年，关键词很可能是“Agent”。AgentCore 所代表的，不只是一次产品形态的升级，而是治理逻辑从“人找规则”向“智能体主动治理”的迁移。本文尝试在现有素材有限的前提下，梳理这一方向的技术逻辑、落地难点与产业影响。 为什么治理平台需要 AgentCore：从“规则引擎”到“智能体编排” 1.1 传统治理平台的天花板 企业治理平台（无论是数据治理、IT 治理、合规治理还是云资源治理）长期依赖一套相对固定的范式：采集元数据 → 定义规则 → 触发告警 → 人工处置。这套范式在规则明确、场景稳定的环境下非常有效，但一旦面对以下情况，就会迅速失效： 规则爆炸：业务线越多，规则数量呈指数级增长，维护成本高企； 上下文缺失：告警只告诉“哪里错了”，不告诉“为什么错

过去两年，Agent（智能体）几乎成了企业技术叙事中最热的关键词。从自动客服、代码生成，到合同审核、供应链调度，几乎每一个业务流程都被认为可以被 Agent 重构。但一个尴尬的现实是：大量 Agent 项目停留在 POC（概念验证）阶段，演示时惊艳，上线后沉默。 依据现有素材判断，我们无法引用具体的落地成功率数据，但从技术媒体的观察视角看，Agent 从“能演示”到“能交付”之间，横亘着几道必须跨越的门槛。这些门槛不是模型能力问题，而是工程、组织与信任问题。 门槛一：从“单点智能”到“流程嵌入” 很多 Agent 的演示场景是孤立的：给一个指令，它调用几个工具，输出一个结果。但真实业务流程是长链路、多角色、强状态的。一个采购审批 Agent，不仅要理解需求，还要对接 ERP、比对预算、触发合规检查、通知审批人、

过去两年，大模型赛道的关键词是“参数”“榜单”“跑分”。每隔几周，就有一家厂商发布新模型，宣称在某某基准上超越对手。但进入 2024 年之后，一个明显的转折正在发生：企业客户不再只问“你的模型有多强”，而是问“你能帮我省多少钱、多赚多少钱、少犯多少错”。大模型竞争，正在从能力比拼转向业务价值兑现。 能力比拼的边际收益正在递减 1.1 榜单越来越“卷”，但差距越来越小 回顾过去一年，头部模型在 MMLU、GSM8K、HumanEval 等基准上的得分不断刷新。但一个尴尬的事实是：当所有主流模型都能达到 80 分以上时，榜单上的几分之差，对实际业务几乎没有感知差异。企业用模型写客服话术、做文档摘要、生成代码片段，真正影响体验的往往不是那 2% 的跑分差距，而是响应延迟、调用成本、数据合规和系统集成难度。 依据现有素

当大模型从“会聊天”走向“会做事”，Agent（智能体）正在成为企业落地 AI 的主流形态。但一个现实问题摆在面前：Demo 阶段的 Agent 令人兴奋，规模化落地阶段却困难重重。围绕这一落差，业界开始讨论一个新概念——Agent Native Cloud。它究竟是云厂商的营销话术，还是 AI 基础设施演进的必然方向？本文尝试给出判断。 为什么 Agent 需要一朵“原生长出来”的云？ 从“调用模型”到“运行智能体”，基础设施诉求变了。 传统云原生（Cloud Native）解决的是应用如何弹性部署、如何高可用、如何被编排的问题。它的核心假设是：应用逻辑由人写死，运行过程相对确定。 Agent 打破了这一假设。一个典型的 Agent 应用，往往包含任务规划、工具调用、记忆管理、多轮反思、多 Agent 协作等

当大模型从对话助手走向自主智能体，强化学习的目标函数、数据范式和工程底座都在被重写。Agentic RL 不是把 RLHF 的规模再放大一倍，而是要把“行动—反馈—修正”的闭环真正装进训练框架里。本文尝试从工程视角拆解这一代训练框架的核心矛盾与演进方向。 为什么传统 RLHF 框架撑不起 Agentic RL 过去两年，主流对齐训练框架基本围绕一条流水线展开：收集偏好数据、训练奖励模型、用 PPO 或 DPO 优化策略。这套范式解决的是“让模型输出更符合人类偏好”，本质上是单轮、静态、无环境交互的优化问题。它的隐含假设是：模型只需要生成一段文本，好坏由人类或奖励模型打分即可。 Agentic RL 打破了这个假设。当一个 LLM 被放进真实或模拟环境中，它需要多轮决策、调用工具、观察结果、根据反馈调整下一步动作

当算力、网络与存储不再各自为政，而是被当作一个整体系统来调度、运营和优化，数字基础设施才真正有机会从“规模扩张”切换到“效率跃迁”。但“算网存协同”喊了多年，落地仍面临标准、利益与技术三重门槛。本文尝试从产业视角拆解：多方协同究竟难在哪，突破口又在哪。 为什么“算网存”必须协同：单点优化的天花板已经出现 过去十年，数字基础设施的主线是“各自做大”。算力侧追求 FLOPS 与卡数，网络侧追求带宽与时延，存储侧追求容量与 IOPS。这种分工在需求高速增长期是有效的，但当业务形态转向大模型训练、实时推理、海量数据湖与边缘智能，单点优化的边际收益正在快速衰减。 依据现有素材判断，行业已经形成一个基本共识：算力、网络、存储三者的性能并非简单相加，而是相互制约。一块高性能 GPU 如果被慢速存储或拥塞网络拖住，实际利用率会

当行业把注意力集中在参数规模、上下文长度和榜单分数时，真正决定大模型推理经济性的，往往是一个藏在显存里的数据结构——KVCache。它既是长上下文能力的支撑，也是推理成本、并发能力和响应延迟之间的核心矛盾点。本文尝试从工程视角拆解 KVCache 的管理难题，并给出媒体侧的判断。 KVCache 为什么成为推理系统的“隐形瓶颈” 要理解 KVCache 的价值，先要理解 Transformer 自回归生成的基本机制。模型在逐 token 生成时，每一层注意力都需要用到此前所有 token 的 Key 和 Value 向量。如果每次生成都重新计算历史 token 的 K、V，计算量会随序列长度呈平方级增长。KVCache 的思路很直接：把已经算过的 Key、Value 缓存下来，后续步骤直接复用，只计算新 tok

当大模型参数规模、上下文长度与多模态训练需求同时抬升，算力底座正在从“买得到卡”转向“跑得稳、用得起、扩得动”的系统工程。挑战 RSI（这里指以算力规模扩张为核心的惯性路径，即 Resource-Scale-Inertia）并不是否定规模，而是指出：单靠堆叠加速器，已难以线性兑换成有效训练吞吐与业务价值。真正的分水岭，在于算力底座能否完成系统级协同。 RSI 的惯性：为什么“更多卡”不再等于“更多有效算力” 过去几年，AI 基础设施的主旋律是扩张。集群从千卡走向万卡，单卡算力持续攀升，互联带宽不断刷新。但一个越来越明显的现实是：峰值算力与实际有效算力之间的鸿沟，正在被系统瓶颈放大。 依据现有素材判断，挑战 RSI 的核心矛盾集中在三个层面： 第一，通信墙。 大模型训练中的 All-Reduce、All-to-A