关于 Agent 岗与数据开发同源性的一些想法

笔者在秋招前由于有DB研发背景，试图找过数据开发岗的工作，最近心有所感，看现在的Agent开发岗越看越像数据开发岗，故写下这篇随想。

安慰大家，就算 oai 爆炸了，大家也不会被辞退的。
笔者一直很希望 oai 跟 nv 一起爆炸让笔者捡便宜显卡。
为什么不让加删除线，牛客怎么搞的

以下是两者在核心维度的映射对比：

维度	数据开发现状	Agent 开发现状
技术栈形态	以 SQL 为主。Java/Scala 因偏重而较少使用。	以 Prompt 为核心的自然语言，Python 和 Java/Go 也是有不少存在感的。
准入与门槛	技术门槛低于后端，学历门槛高于后端。	逻辑相近。代码门槛不算高。高并发高流量跟agent几乎毫无关系，大模型输出token的速度就限制死了。
核心壁垒	SQL 语法本身并不复杂，但理清混乱的业务指标和口径难度不小。	写Prompt调API 很简单，但将非标的业务 SOP 转化为模型可理解的逻辑、并控制幻觉问题，存在不小挑战。
薪资 ROI	略低于核心后端，但结合工作强度与技术迭代速度来看，性价比具备竞争力。	今年毕竟是agent校招第一年，各家开出的薪资并不低于正常后端（甚至略高些）。

几点推演：

1. 技术门槛与学历门槛

就像数据开发往往不需要精通 Java 多线程一样，Agent 开发也不需要吃透 Transformer 底层数学原理。两者的共性在于：都使用比Java/C++ 更加高层的语言，SQL与Prompt本身的掌握成本不高，技术门槛比后端低太多太多。

正因为代码层面的门槛相对温和（大部分时间在写逻辑判断和流程控制），使得人才筛选机制有所侧重 —— 企业更倾向于招聘高学历的校招新人，或经验丰富的后端老手转岗。

数据开发岗要起步双九的事不罕见，数据分析岗的学历要求更是要往上提一档，清北数分也不少。

也就是说，一份工作，他的技术门槛确实不高，但企业也确实需要做这部分工作，那么在抬高不了技术门槛的情况下，只有也必须抬高学历门槛来筛人。

今年的Agent其实已经有了这样的苗头，大家都在说实习很好找，秋招却找不到岗位，其实数开岗在某些年也这样，现在是冷却下来了，不像Java后端那么有梗，公开平台少有讨论这个岗位的。

2. 业务复杂度的真正来源

数据开发常自嘲是sql boy，但大家熟知的上万行sql史山，在数开岗的日常里也是会时不时碰到的，任何东西只要上了规模，但仍能产生经济价值，那么就值得雇一个人维护他。数开的工作就是维护这坨和那坨sql，以及堆几坨新的sql；数开还需要做一些系统运维工作，使得双11等高流量场景系统不至于挂掉，这个系统运维工作一般会涉及到10+种工具，这里就不一一列出了，反正懂得都懂，看着多，不难，虽然不难，但谁说没有复杂度呢？

Agent 开发同理，现在涌现了超级多的Agent应用，业界仍然在探索大模型的能力边界，试图搞清楚什么问题是大模型能解决的，什么问题是需要工程兜底的。

Prompt调优确实算不得太工程的想法，但当A社提出MCP和Context Engineering后，显然这两个概念是完全具备工程管理的要素，笔者认为可以肯定的是，工程侧的复杂度将会有很大一部分来自于管理几千上万的Prompt，要将它们适时的插入上下文，遵循一些节约token的准则，完成指定的需求，处理各种出错兜底逻辑。不可能让单个产品经理/程序员自己码上几千行Prompt然后直接上线测试，会需要各种各样的基建配套措施，会需要赛马决出更好的执行流程。

这一切，就是Agent开发复杂度的来源，写Prompt当然谁都会写啦，高中生都会。

3. 业务存在的必要性

大数据在刚提出来的时候非常火热，大家也会认为有了它，什么问题就都能解决了。但在理性看待大数据之后，大家就意识到了很多问题都是伪需求，非大厂几乎用不上真正的大数据，也就导致了数据开发岗岗位数量萎缩。但是再怎么萎缩，在大厂和小部分中小厂场景下，就是有这样的复杂系统，就是需要人来治理而无法交给数据库自动管理，并且出了事总是得有人负责的——这就是数据开发岗存在的必要性。

当前的Agent岗位大家心里也都清楚，这里面有一大半是要似掉的，但是笔者也相信，Agent在一些场景下是一定不可替代的，比如更加智能人性化的客服Bot，比如Code Agent，这是大浪淘沙之后一定会留存下来的Agent需求。