四维定位

• 技术栈：应用层（Agent/RAG/业务系统集成）
• 业务线：跨业务线（投资顾问、交易、合规、研究）
• 组织归属：信息技术部（IT）或金融科技部
• AI成熟度：L2-L3（从"AI应用"到"AI系统"）
• 组织位置：L2阶段可嵌入业务部门（贴近场景），L3阶段可集中至信息技术部（统一平台）；通常向技术负责人汇报；业务侧是"内部客户"，提需求、验效果

AI Agent/应用开发工程师，是大模型能力到业务价值的"最后一公里"执行者。他的核心任务不是训练模型，而是把大模型"包"成一个能用的业务功能——让投资顾问能用、让交易员能用、让合规员能用。

回到开头的核心问题：券商的大模型为什么"demo 跑得通，生产上不去"？答案正是缺 AI Agent/应用开发工程师——demo 只需要跑通模型调用，但生产需要工程化封装、RAG 管道对接、业务系统集成、应用层测试，这些都是这个岗位的核心职责。

具体来说，他的日常工作包括：

与 AI 算法工程师的边界：算法工程师关心"模型效果"，Agent/应用开发工程师关心"业务能不能用"。前者输出模型文件，后者输出可调用的业务接口。明确地说，Agent/应用开发工程师不负责模型训练——那是算法工程师的职责。

与 MLOps/LLMOps 工程师的边界（详见分篇5）：MLOps 工程师关心"模型训好了能不能稳定上线、监控、再训练"，聚焦模型全生命周期的工程化（Pipeline 调度、部署、版本管理、线上监控）；Agent/应用开发工程师关心"应用能不能跑起来、好不好用"，聚焦应用层集成（Agent 流程编排、RAG 管道对接、业务系统集成）。前者是模型上线保障（不负责模型效果，只负责工程化落地），后者是业务价值交付。在一个成熟的 AI 团队里，MLOps 工程师是"模型生命周期管家"，Agent/应用开发工程师是"业务系统集成者"——两者协作，但职责分工明确。

二、能力模型

软技能：

• 跨部门沟通（能同时理解业务语言和技术语言，在需求评审中把AI能力边界讲清楚，避免业务预期过高或过低）- 快速试错（大模型应用迭代快，不能等"完美方案"）

不是必须的（但加分）：

• 了解模型原理（不需要会训练，但要知道模型能做什么、不能做什么、什么时候该换模型）
• 丰富的金融知识（业务理解比证书更重要）

三、与互联网同岗的本质差异

一句话差异：互联网的 AI 应用开发是"增长工具"，券商的 AI 应用开发是"生产系统"——可靠性、合规性、可审计性的优先级远高于"酷炫效果"。

四、为什么这个岗位最稀缺？

4.1 供需缺口：市场上根本没有"对的人"

AI 应用开发需要"大模型+工程+业务"三角能力，但市面上三类人都不完整：

结果：三类人都"不对口"，招来的人要么做不出，要么做出来的东西业务用不了。

4.2 为什么外部招聘难？

券商在人才市场上的竞争力有限，尤其是 AI 应用开发这种热门方向。

4.3 为什么内部培养也难？

即使券商愿意培养，路径也很难走通：

1. 现有工程师转型难：传统券商 IT 工程师熟悉交易系统、柜台系统，但大模型应用开发是全新技能栈，学习曲线陡峭。
2. 业务人员学不会工程：让投资顾问或研究员学 Python 和 Agent 框架，可行性低。
3. 培养周期长：即使招到合格的 AI 工程师，也需要 6-12 个月熟悉证券业务，中小券商等不起。

结论：这个岗位"内外都难"——外部招不到，内部培养慢。但也有券商通过"干中学"跑通了路径，关键是老板是否愿意给工程师试错空间。

五、小结

AI Agent/应用开发工程师，是券商 AI 落地链条里最关键的执行层——把大模型的能力封装成业务侧能用的工具。

他不需要懂怎么训练模型（那是算法工程师的活），但必须懂：

• 怎么用模型（Prompt、RAG、Agent）
• 怎么把模型包成应用（工程化、系统集成）
• 券商的业务场景是什么（投资顾问、交易、合规……）

目前这个岗位的稀缺程度被低估了。很多券商的 AI 战略停留在"我们有大模型 API 了"，但没人能把 API 变成业务价值——在 AI 落地链条中，缺的就是这群人。

给券商的建议：

• 短期：从互联网大厂"挖"有 AI 应用开发经验的人，代价高但速度快
• 中期：内部培养，让工程师在真实项目里干中学——这是成本最低、效果最好的方式
• 长期：建立"AI 应用开发"的岗位序列和晋升通道，让人愿意来、留得住

免责声明：本文所引用信息均来自公开渠道，仅供行业分析参考，不构成任何招聘建议或投资建议。文中涉及的各券商岗位信息以各公司官方发布为准，实际情况可能因券商具体情况而异。