目前AI行业最值得去的30家公司。

沉默王二约 2971 字大约 10 分钟

AI行业看起来热闹，但真正值得长期关注的公司，其实就那么几家。

我综合考虑了技术含金量、岗位数量、业务落地、成长空间和履历价值，整理了目前最值得去冲的 30 家公司。

ps：不过需要叠甲一下，这不是绝对排名，没有先后顺序。也欢迎大家补充，我们开整！

大模型与 AIGC 赛道目前最卷，核心技术岗的薪资也是第一梯队。

DeepSeek、字节、阿里、腾讯、百度、华为、智谱、MiniMax、月之暗面、阶跃星辰，是佼佼者。方向包括模型算法、AI Infra、数据工程、Agent 研发和产品经理，技术岗门槛比较高。

AI 企业服务和 SaaS 赛道离商业化最近。

第四范式、Moka、影刀 RPA、智齿科技这 4 家是代表，重点包括 AI 应用研发、解决方案工程师、售前和售后支持。这个赛道需要理解企业流程，B 端的产品思维比纯算法能力更重要。

智能驾驶赛道研发周期长，算法和工程壁垒很高。地平线、Momenta、小马智行、文远知行、禾赛科技 5 家公司，主要招聘感知、规划控制、端到端智驾、世界模型和芯片人才。

能进入核心技术岗，薪资完全不输大模型。

机器人赛道是具身智能热度最高的方向。宇树科技、智元机器人、优必选、普渡科技 4 家公司，重点招聘运动控制、强化学习、VLA（Vision-Language-Action，视觉语言动作模型）、感知导航和嵌入式人才。

外语能力对海外交付岗位比较加分。

AI 医疗健康赛道行业门槛高，竞争相对少一些。百川智能、联影智能、晶泰科技 3 家公司，主要招聘医疗大模型、医学影像、AI 制药和数据工程人才。

有医学、药学、生物信息和计算机交叉背景的同学会更有竞争力。

互联网 AI 与场景落地赛道岗位最多，业务覆盖也最全。美团重点做 LongCat 和 Agent，小米重点做 MiMo、AI Agent 和智驾，京东重点做 JoyAI 和物流，蚂蚁重点做金融和生活服务 Agent。

这个赛道适合算法、研发、产品、运营等不同背景的同学，岗位类型最丰富。

大家可以放开思路，结合自己的兴趣和特长选择合适的赛道和公司。

如果你是一位愿意相信努力、相信过程、相信一步一个脚印、相信自己能在 AI 时代分一杯羹的人，那接下来这份硬核的面经，希望你能认真读一读。

（全文比较肝，保证大家能学到很多很多，系好安全带，我们粗粗粗粗发～）

content

PS：PaiCLI 是一个类 Claude Code 的终端 Agent，已开源。如果你想拥有一个 Agent 的项目经验，可以参考。

GitHub: https://github.com/itwanger/PaiCLI-Python

01、系统如何区分正常重试和无效循环？「有没有取得进展」用什么指标判断？

「我在 PaiCLI 里做了一套工具签名的滑动窗口机制来检测循环。」

每一轮 Agent 调用完工具之后，系统会把这一轮的工具调用生成一个签名，签名由工具名加上参数拼接而成。

然后用一个固定大小的滑动窗口，把每轮的新签名放进来。如果窗口里的 3 个签名完全一样，就判定为无效循环。

举个例子，Agent 连续三次调用 grep_code，但每次搜的关键词都不一样，说明它在尝试不同的检索策略。只有工具名和参数都完全一样的时候，才说明 Agent 卡住了。

为什么用工具签名而不是对比 LLM 输出文本来判断循环？

LLM 每次生成的文本都有随机性，即使在做完全重复的事情，输出也会有差异。

工具调用是结构化的，工具名和参数是精确的字符串，要么完全一样，要么不一样。判断起来简单可靠。

02、Agent 达到最大执行轮数但只完成部分工作，是直接退出还是返回部分结果？

在交互场景下，我会默认不限制固定轮数，让 Agent 根据任务是否完成自然结束，同时通过上下文压缩、重复调用检测和用户取消来保证安全。对于后台任务这类无人值守场景，可以显式设置最大轮数。

如果真的达到上限，Agent 会立即停止调用工具，再进行一次无工具的收尾，让模型根据已有工具结果返回部分成果，明确说明哪些已经完成、哪些还没完成、阻塞原因和下一步建议。

这样既不会因为达到上限就丢掉前面的工作，也不会让 Agent 为了收尾继续无限调用工具。

03、项目中哪些是自己开发的？哪些复用现成的框架？

「PaiCLI 没有用任何 AI 框架，全部由 Codex + Claude Code 完成。」

ReAct、工具调度、Prompt 组装、上下文压缩、记忆系统、多 Agent 编排、Skill 体系，都是从零写的。MCP 客户端也是自己实现的，包括 JSON-RPC 协议层和传输层，stdio 和 Streamable HTTP 都支持。

第三方类库用的都是工具级别的，OkHttp、Jackson、SQLite、JavaParser、JGit、Lanterna、Jieba，各管各的事。

04、多 Agent 协同执行时可能遇到哪些性能瓶颈？如何解决？

「LLM 的 API 调用延迟。」

多 Agent 编排里每个 Worker 每一轮都要调一次 LLM，多个 Worker 并行跑下来调用次数会很多。PaiCLI 把执行计划解析成 DAG，按拓扑排序分批调度，没有依赖关系的任务放在同一批并行执行，尽量把等待时间压下来。

共享资源也会有竞争。对话历史是隔离的，每个 Worker 有自己的消息列表，但工具注册表和记忆管理是共享的。PaiCLI 的处理方式是规划器和审查器只做判断，工具执行权集中在 Worker 手里，竞争入口就收窄了。

05、如何控制 Agent 并发数量？有哪些限流或调度策略？

「多 Agent 编排模式用 BlockingQueue 做 Worker 池化。」

系统默认创建 2 个 Worker，线程池大小也是 2。Worker 执行完一个步骤后自动归还到队列里，下一个步骤可以立即领走。

后台任务队列走 FIFO 轮询，每个 Worker 以 300 毫秒为间隔轮询 SQLite 数据库取任务。PaiCLI 是本地工具，并发上限受 LLM API 的配额约束，线程池设到 2 到 4 就够了。

06、直播场景大量用户同时点赞，如何优化？

客户端先做聚合，用户点了多少次先在本地存着，攒一批再发给服务端。

服务端收到请求后用 Redis 的 INCRBY 做原子累加，不走数据库。然后定时任务把 Redis 里的计数批量刷回数据库。前端展示不需要精确实时，动画补间过渡就行。

07、目前 RAG 最大的瓶颈是什么？

「检索质量。」

检索阶段召回的文档如果和用户问题不相关，大模型拿着一堆无关内容去生成回答，质量就会很差。

分块粒度最影响召回质量。分块太大噪音多，太小容易语义断裂。拿派聪明的经验来说，512 字符加 100 字符重叠是一个比较稳妥的经验值。

Embedding 模型的选择也很关键，不同模型编码出来的向量质量差别很大。还有查询改写，用户问题经常很口语化，不做改写直接检索召回率会打折扣。

08、给电商平台搭建百万级商品知识库问答系统，怎么设计？

商品信息里标题、描述、参数表、用户评价的切分策略不一样。标题和参数表按字段切，描述和评价按语义切。

Embedding 用阿里的 text-embedding-v4。检索层用混合检索，ES 先做 KNN 向量召回，再在候选集上做 BM25 关键词重排序。

「电商场景里用户经常搜具体型号和参数，关键词匹配比语义相似度更准，所以 BM25 权重要比向量高。」

生成层用 DeepSeek V4，temperature 偏低，检索结果注入 Prompt 强制模型基于检索内容回答。

能复现就直接看日志，定位到请求对应的日志行，看有没有异常堆栈。有堆栈就顺着找到出问题的代码位置，分析入参为什么会在那个位置触发异常。

日志里没有异常的话，说明代码没报错但返回了不对的数据。这种情况从接口入口开始跟数据流，看每一步数据经过了哪些处理，哪一步变成了不符合预期的样子。

复现不了就先排除环境差异，有些 bug 只在特定数据组合下触发。修完补一个回归测试用例，把这次的入参和预期结果固化下来。

ending

AI时代， Agent 的工程能力正在成为新的考点。

对我们这群喜欢学习、还在准备的人来说，是好事。

原因很简单，如果技术不变更，不迭代，一直保存学习热情的人就永远没有翻身之日。

反而，AI 时代的到来，让公司有了新的机遇，也让我们有了新的机遇。

冲就完了，我们下期见。