我是一名有较好学历的（上交本硕），硕士毕业后在国内互联网大厂数据中台数据治理团队工作了三年的数据/后端工程师。我在团队内的算法小组，我的mentor（职级P7）的title是算法工程师，但他不是通常意义上的训练深度神经网络的算法工程师，而是通过数据、图算法等确定性算法设计数据治理解决方案的算法工程师，他对工程不在行。我前一年半主要在做数据治理解决方案相关工作，主要目标是帮助大厂内各数据业务团队降本，技术栈涉及数据、后端工程、算法。后一年半开始做数据相关的Agent，去年做了数据治理Agent和Text2SQL Agent，都主要由我一个人负责，让我实践掌握了Agent的全栈能力（包括设计、产品开发、Agent效果优化），但因为各种原因做的不深，用户量也较少。但我仍然凭借这些工作顺利从P5晋升到P6，也拿到了较高涨薪。今年我们小组开始做数据领域的知识库，原因是去年的Agent经验告诉我Context才是数据相关Agent（尤其是Text2SQL）的瓶颈，一旦提供了准确的表、字段和需求，LLM写SQL是比较准确的，核心瓶颈是如何提供准确的Context给LLM。这是我的idea，我先和我的mentor聊了这个idea，然后我的mentor觉得有道理就和我们的+2 P9大老板聊，也说服了P9大老板。正巧我的+1 P8老板接了公司高管的Agent问数分析项目，所以我们就以这个高管项目为切入点开始了Data Agent知识库的探索。这个知识库项目由我的P7 mentor负责，我作为其中的得力干将，帮助完成了LLM-Wiki的调研和Demo的开发，后续LLM-Wiki也成为这个项目的技术选型。由于一个去年做了一年BI Agent的团队今年并入了我+2 P9大老板的大团队，他们在BI Agent、取数分析Agent上做的更深，因此我的Text2SQL Agent被搁置，我的+1 P8老板要求我全力all in Data Agent知识库。虽然+2 P9大老板希望大团队内所有知识库的场景都接入我们的知识库，但这个BI Agent团队老板不想这么做，而是他们自己也自建了一套知识库，把我们作为第三方知识库，和其它第三方知识库竞品一起作为第三方接入选项。我猜测因为P9大老板的团队内缺少对Agent的团队级别的积累（去年的工作主要都是像我一样的单兵探索作战），因此今年也依赖新并入的BI Agent团队开发的Data Agent新产品作为核心产品入口，因此也无法完全拒绝BI Agent团队的自建需求。因为整个团队在做高管项目，P9大团队分到了很多hc，后端工程hc分给了BI Agent团队（他们老板和干活的主要都是工程title），算法hc分给了我mentor。我mentor虚线lead的人从4人扩张到了8人，我猜测P9大老板希望力推他明年晋升P8。但新入职的算法工程师的画像和我mentor一样，不懂工程也不是科班出身的熟练掌握深度学习的算法工程师。新来的4人中有2人是数学系的校招，有1个之前做供应链算法的内转（也和llm、agent关系不大），只有1人是真实对口社招，之前在另外一家大公司的数据中台做RAG，但这个人学历又不太行，差点过不了学历背景审查。这些人的共同特点是都不懂工程，因此过去半年虽然我仍然是小组里最懂Agent的人，但不得不负责知识库的产品工程工作，积累的都是全栈开发能力和工程组长能力。但在这个维度上我认为我很难竞争过真正做工程出身的小组和人（比如BI Agent团队中任意一个P7），加上coding agent能力目前越来越强，这一职业发展道路我个人长期不看好。虽然我和mentor沟通过，他也同意我下半年多做些算法工作、少做些工程，但我认为这个矛盾是结构性的，因为小组里懂工程的就我一个，我继续stay改变不了这个结构性矛盾。因此决定出来看看机会，虽然我是mentor的嫡系，也与我的+1 P8老板、+2 P9老板完成了信任的建立。 看机会前我的规划是：1. 我认为真正有技术壁垒的是基础模型，要么加入基模团队做Agent Harness（类似Claude Code团队），做适配基模的Harness；要么加入基模团队做后训练数据工程，看看能不能接触到基模后训练的insight，但我过去一年半的经历和基模数据工程完全无关，因此没有什么适配度。2. 找到真正深入的业务（如法律、医疗、金融、广告等）做Agent落地，如继续做知识库等，类似FDE的逻辑，积累业务壁垒，因为技术实现未来壁垒会越来越低。3. 在大厂中跳到更合适做Work Agent Context的团队，如钉钉、飞书的知识库团队，可见的Context层会是Agent落地的一大瓶颈。

“只我懂工程”之所以消耗你，是因为经验锁在你一个人身上：新人来了从零开始，你不在就没人能判断。可交接的做法是把踩过的坑沉淀成规则、把验证过的做法变成模板、把发现的盲区放进团队共用的检查清单，让系统越跑越强而不是每次重新摸索⁠1。这背后需要设计 context 怎么组织：什么信息放哪里、谁负责更新、AI 通过什么路径读取⁠1。落到你的知识库项目，可以先挑一个反复出现的判断——比如某类表字段该不该进知识库——写成规则和验收清单，让 mentor 或新同事照着做一次，看他们能否独立完成。

基模数据岗能不能积累训练效果 insights，不取决于岗位名称，而取决于团队是否把数据交付和模型效果对账。如果团队只对数据量和 ETL 正确性负责，需求又多到没时间优化 pipeline，那接触反馈的空间就有限⁠2。一个可试的做法：入职前或入职后主动问，这批数据交付后，下游会作出什么不同的决定，效果不好时责任能不能回到数据判断⁠2。如果答案只是“按时交付”，那这份工作更接近代理信号；如果能把数据改动和训练结果连起来看，才可能积累你要的 insights。

判断一个业务能不能长久，不是看它现在热不热，而是看它是否解决真实用户反复出现的问题、结果是否被采用。演示让人相信有潜力，但跨到另一层管理关系，对方还要判断值不值得继续给资源；展示能力做得到，和证明许多人确实需要、反复从中受益，之间隔着距离⁠3。可以试着把业务需求做成一个可追问的记录：需求来自多少个组、原本卡住什么、节省了什么、结果是否被采用⁠3。如果这些都能落到具体的人和事，业务壁垒就更实；如果只是演示惊艳、现实中没多少人需要，风险就高。

判断一份工作有没有壁垒，可以问：客户或用户买的是哪个结果，你在这条链上负责哪一环。如果只负责把数据搬对、把功能做出来，别人和 AI 都能替代，议价能力会先下降⁠1。真正难替代的是数据、workflow、反馈闭环和长期迭代这些不容易被复制的东西⁠2。放到你的两个选项上：基模数据工程如果只接需求、交付数据量和 ETL 正确性，你负责的是过程不是结果，很难积累“什么样的数据让训练变好”的判断；Context 层如果能让 Agent 效果变好、并看到用户是否真的在用，你负责的是结果，壁垒才可能长出来。

把记忆和上下文作为独立工程层解耦出来，让模型按需调用，数据留在模型之外，换模型也不丢历史——这本身就是可以积累的价值，用户持续使用留下的上下文会影响下一次交付⁠3。你现在的 wiki 检索速度、效果优化和知识更新，正落在这个方向上。但要成立有个条件：你得能观察到 Agent 对业务是否真有价值，而不只是把检索指标做上去。如果中台项目始终拿不到真实用户反馈，它和“业务自建、Codex+skills”的区别就答不上来，壁垒也就停在通用工程能力上。

在今晚回复主管之前，可以先想清楚一个可检验的问题：你接下来做的检索和知识更新优化，能不能对应到一个具体的、反复出现的用户问题，并且你能看到它有没有被解决。如果能，留下就是往 Context 层壁垒走；如果拿不到这个反馈，那这份工作和你担心的纯 ETL 差别不大，只是换了个技术名词。这个判断不需要你现在就决定去留，但能帮你分清“留下”到底留下的是什么。

出处 2 3