Agent 接下来三年会怎么走？一个数仓老兵 + 两年Agent工程师的判断

Python_金钱豹

254人浏览 · 2026-06-13 20:37:33

Python_金钱豹 · 2026-06-13 20:37:33 发布

阅读提示

这一篇帮你搞清：Agent 不是单线演化，技术人看到的演进路径和产品人看到的分化逻辑是两件事

这一篇能让你直接动手：选你要扎下去的那条路，别在三条路之间反复摇摆

这一篇能让你带走一个判断：prompt 工程是消耗品，数据资产 + 学习闭环才是 agent 时代真正的复利

我做了十年数仓，干过的活包括 Hive 调优、实时链路上线、跨数据源指标对齐、给业务方的 BI 报表 review SQL。最近一年开始写 LLM 应用，正在用 LangChain + LangGraph 构建一个 data agent。

这两段经历叠在一起看 agent 这个赛道，视角和纯 LLM 工程师不太一样。下面是三个我比较确定的判断。

Agent 内核会被反向重构 4 次

先看图，再说为什么。

图 1｜Agent 内核架构演进 · 4 代路径

这张图我画的时候有点纠结要不要画第 4 代 —— 因为它现在还在论文阶段。但我决定画，因为前 3 代已经是事实，第 4 代是在地基上画好的逻辑路径。

第一代 Prompt + Tool（2023）就是早期 LangChain 那套：拼一个长 prompt，挂几个 tool，agent 在工具调用循环里一轮一轮跑。问题是控制流太弱 —— 工具失败了不知道怎么办，多步任务靠 prompt 工程顶。

第二代 Workflow 编排（2024，现在的主流）解决的就是控制流。LangGraph 的 StateGraph、条件边、反思循环 —— 把"agent 该干嘛"从 prompt 里搬到代码里，用工程师能 debug 的方式表达。我现在做的 Datus 就在这一代。优点是可控，缺点是工作流是人工固化的，agent 自己不会改。

第三代记忆 + 学习闭环（2025-2026，正在上来）是 Hermes 这种。它的 claim 是"会成长" —— 但成长的物理形式不是模型变聪明，而是 agent 把每次会话沉淀成可检索资产。Skills 自动生成、session FTS5 搜索、Honcho 用户建模，三件套加起来本质是给 agent 装了个数据库（参考前一篇拆解）。

第四代自我修改（2026-2028，论文阶段）是真正麻烦的一代。Agent 会改自己的 prompt、改自己的工作流、甚至训练下一代自己。技术上的难点不是实现，是怎么保证它不改坏。

但这里有个反直觉的事：这四代不是替代关系，是嵌套关系。

我做数仓时见过太多次"新一代技术全面替代旧一代"的预言最后都没兑现 —— Hadoop 没替代 Hive，Spark 没替代 Hive，最后是几代东西在不同场景共存。Agent 也一样。第 4 代真上线后，简单 ChatBot 还是会用第 1 代的路子，因为成本结构对。

作为技术人，要做的不是赌哪一代赢，是赌你的内核架构能不能向后兼容。我现在写 Datus 的反思循环节点，已经在留接口让未来能加 memory 层和 trajectory 导出 —— 不是因为现在用得上，是因为不留这个口未来要重写。

至于多 agent 协作（subagent / A2A / MCP）—— 这其实是上面四代演进的横切面，不是单独一代。OpenClaw 的"多 agent 路由"和 Hermes 的"subagent 委派"是同一种东西的两种产品形态：把任务隔离到独立上下文里。这个能力从第 2 代就该有，区别只是用 ToolNode 实现还是用独立 Gateway 进程实现。

数据飞轮回归我们的主场

图 2｜Agent 数据飞轮 · 数仓老兵视角下的护城河

这张图是我读 Hermes 自学习闭环时画的草稿改出来的。Hermes 的 4 个组件（skills 生成 / memory / FTS5 / Honcho）我看到的不是"AI 创新"，而是一个朴素的数据闭环：

用户使用 → 结构化沉淀 → 检索反思 → trajectory 回炉 → 能力增强 → 用户使用

这个闭环在数仓圈我们干了十年。换个名字就是 ODS → DWD → DWS → ADS 那一套。原始日志变明细、明细变汇总、汇总变可消费数据资产、数据资产再反哺业务决策。**Agent 时代只是把"业务决策"换成了"模型能力"**。

这意味着什么？意味着飞轮跑得起来不靠模型多大，靠三件传统数仓的护城河：

数据建模分层：raw trajectory（一次会话的原始日志）≠ 可训练 trajectory，中间需要清洗、对齐、去重，这是 DWD 层的活
指标口径治理：Hermes 的 skills 文件我看下来本质就是"指标定义" —— 一段操作 + 一组参数 + 一个口径。同一个业务问题不同人写出不同 SQL 的痛点，在 agent 时代会变成"同一个用户意图不同 session 学出不同 skill"。这是指标语义层要解决的事
数据资产沉淀机制：什么算"成功 case"值得入库？什么算"失败 case"应该淘汰？怎么避免脏数据污染下一轮训练？这些问题在数仓圈叫数据质量治理

我现在的 Datus 已经有 6 类向量知识库（schema / metric / SQL / template / 业务规则 / 平台文档），覆盖前两件。第三件（trajectory 沉淀）是我下一阶段要补的。

这个判断对纯 LLM 工程师可能反直觉，但对数仓圈的人是常识 —— 数据资产的复利是单调递增的，模型参数的红利是会衰减的。三年后回头看，真正难复制的不是谁家 prompt 写得好、工作流编排得花，而是谁家飞轮跑了多久、沉淀了多少结构化资产。

至于训练数据飞轮（trajectory → 微调 → 反哺基模）—— 这是飞轮的最后一环。Hermes 已经在做（batch trajectory generation + ShareGPT 格式导出），但企业场景目前还跑不通，因为：

行业 agent 的 trajectory 量级不够支撑微调（除非聚合多个客户的数据，但又涉及合规）
反哺哪个基模也没明确路径 —— 各家闭源模型都不接受外部 fine-tune

但这一环跑通只是时间问题。Modal、Daytona 这种 serverless GPU + 开源基模（Qwen / DeepSeek）双轮成熟之后，**企业自己微调一个领域 agent 基模会从"科研项目"变成"季度迭代"**。

Agent 不会赢家通吃，三条路会持续分化

图 3｜Agent 不会赢家通吃 · 三条分化路线

很多人以为 agent 赛道未来会有一个"超级 agent"统一所有场景。我不这么看。

我读完 OpenClaw 和 Hermes 之后越来越确信：agent 会按"用户 + 安全模型 + 商业逻辑"这三个维度分化成至少三条互不相通的路线。

第一条·个人 Agent（OpenClaw 这一类）：单用户、跑在自己设备上、跨 IM 通道。商业模式是订阅或开源。卖点是"随时在线 + 数据在你手里"。这条路上的对手是 Apple Intelligence 和系统级助理 —— 谁能更好地集成进 OS 生态谁赢。

第二条·通用云 Agent（Cursor / Claude Code 这一类）：B2C 或多租户 SaaS、按 token 计费、生态绑定 IDE 或 API。卖点是"开箱即用"。这条路上的最大风险是模型方反向集成 —— OpenAI 自己出了 Codex CLI 之后，单纯做"OpenAI 套壳 IDE"的产品就开始被压缩生存空间。

第三条·企业私有 Agent（Datus 这一类，我自己在做的）：行业部门用、私有化部署、深度集成数据底座。商业模式是 License + 实施 + 数据分润。卖点是"行业 know-how + 数据资产"。这条路最重，但护城河也最深 —— 因为模型方做不了你的数据底座，云厂商做不了你的行业 SOP。

这三条路的内核架构、安全模型、商业逻辑根本不一样：

个人 Agent 的安全模型是 “main session 全权 + 非 main 沙箱”，因为是你自己用
通用云 Agent 的安全模型是 “租户隔离 + 凭证池 + 审计日志”，因为是 SaaS
企业私有 Agent 的安全模型是 “RBAC + 数据脱敏 + 操作审计 + 合规留痕”，因为对的是数仓里的真实业务数据

人和 agent 的协作边界也完全不同：个人助理可以默认 auto-execute（你自己用），通用云需要每一步 confirm（怕花你 token），企业 agent 必须 HITL（人工审核）+ 影子模式（重要操作先 dry-run）。我做 Datus 时设计的三级权限（ALLOW/ASK/DENY + glob 匹配 SQL 操作类型）就是这条路的标配 —— DROP / DELETE 默认 DENY，SELECT 默认 ALLOW，UPDATE 走 ASK。

作为产品人最大的诱惑是想三条都做。我亲眼见过创业团队从"做开发者工具"摇摆到"做企业 Copilot"再摇摆到"做个人 ChatBot"，每次摇摆都意味着推翻 60% 的代码。三条路的护城河完全不同，试图三条都做的产品最后都不上不下。选一条扎下去，把其他两条当友商而不是机会。

我的选择和我对你的建议

写到这里，我自己的选择是清楚的：扎在第三条路——企业私有 Agent + 数据底座深度耦合。原因不是这条路最好走，而是这条路上我那十年数仓经验是稀缺资产。

纯 LLM 工程师做不了：因为 SQL 质量判断、指标口径治理、数据建模分层这些事是 know-how，不是 prompt 能堆出来的
模型方做不了：因为这事重交付、重客户关系、重行业积累，不符合 SaaS 的边际成本逻辑
传统 BI 厂商做不了：因为他们没有 agent 工程能力，反思循环 / 多 agent 协作 / MCP 协议这些事对他们是新东西

这是我自己的"比较优势矩阵"。你的不一定一样。

我对你的建议是：

如果你是前端 / IDE 工程师，扎第二条路（通用云 Agent）—— 你对开发者体验的判断力是稀缺的
如果你是做 OS / 终端的，扎第一条路（个人 Agent）—— 你对设备协议、跨端一致性的经验是稀缺的
如果你是做数仓 / 数据库 / SaaS 的，扎第三条路（企业私有 Agent）—— 行业纵深和数据治理经验是稀缺的

别看到 Hermes 飞轮酷就去做飞轮，别看到 OpenClaw 通道多就去接通道。问自己一个问题：三年后这件事如果做成了，护城河长在我身上的哪一块？

护城河长不出来的事，做了也是给别人打工。护城河长在你身上的事，慢一点没关系，但每天都在变厚。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

在这里插入图片描述

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～