| 字段 | 内容 |
|---|---|
| 岗位名称 | 智能体开发专家 |
| 公司 | 中电云计算技术有限公司（央企体系，中国电子系云计算公司） |
| 月薪 | 3.5–5.5 万/月 |
| 工作地点 | 北京市 |
| 经验要求 | 经验不限（对资深候选人有利） |
| 学历要求 | 未明示 |
| 企业性质 | 央企背景 / 信息传输、软件和信息技术服务业 |
| 招聘类型 | 社招 |
| 职位来源 | 猎聘 |
| 平台岗位 ID | 2075856300155224071 |
| JD 检索入口 | https://www.jobonline.cn/findPositions?keyword=%E6%99%BA%E8%83%BD%E4%BD%93%E5%BC%80%E5%8F%91%E4%B8%93%E5%AE%B6 |
| 综合评分 | 91.4 / 100（本日榜首） |
说明：平台详情页需登录后方可查看完整 JD 正文，本文的「岗位画像」依据岗位名称、公司背景、行业、薪资带与同赛道岗位共性推断得出，面试前请以实际 JD 与 HR 沟通为准。
岗位处于什么位置：这是典型的企业级 Agent 平台研发岗，落点在「央企云的 AI 中台 / 智能体平台」产品线，而不是做单个聊天机器人。公司卖的是能力平台，所以它要的人必须同时懂大模型应用工程和企业级系统架构。
核心职责（预期）
必备技能
加分项
| 维度 | 权重 | 得分 | 说明 |
|---|---|---|---|
| 方向匹配 | 25 | 25.0 | 智能体开发专家 = 候选人 AI 大模型应用主攻方向 |
| 简历匹配 | 20 | 18.4 | RAG 知识库 / Function Call / MCP / LangChain·Dify·Coze / Agent 开发 / vLLM·ollama 本地部署均已具备 |
| 北京人才引进资格 | 20 | 16.0 | 央企体系背景 + 属北京重点产业 + 岗位为中高级 |
| 薪资 | 15 | 15.0 | 3.5 万下限已高于期望区间中位 |
| 经验/学历 | 10 | 7.0 | 经验不限，16 年经验不吃亏 |
| 风险 | 10 | 10.0 | 未设年龄/应届限制 |
| 合计 | 100 | 91.4 | 当日综合分第一 |
强匹配点（面试要主动秀）
需要补强的点
差异化定调：不做「会调 API 的应用开发者」，做「能把大模型能力安全、稳定、低成本地接进央企现有系统的工程负责人」。
Q1：你们的 RAG 系统为什么要做混合检索？向量检索不够吗？ A：向量检索擅长语义相似，但对专有名词、型号、编号、缩写这类字面精确匹配弱。企业知识库里大量是产品型号、条款编号，纯向量会漏召。所以用 BM25 保字面 + 向量保语义，两路各取 TopK，用 RRF（倒数排名融合）合并，再用 Cross-Encoder 重排序取 Top5 送模型。实测在套餐条款检索场景上，命中率比单路向量高约 15–20 个百分点。
Q2：切分（Chunking）怎么做？ A：分三层：① 结构优先，先按标题层级/表格边界切，保住语义完整；② 再按长度兜底切，块大小 300–500 字、重叠 10–15%；③ 采用「父子块」——检索用小块（精度高），送给模型的是它所属的大块（上下文全）。表格单独处理，转成 Markdown 或结构化 JSON 再入库。
Q3：怎么解决大模型胡说（幻觉）？ A：分四层：① 检索层保证证据充分，召回不足时明确返回「未找到依据」而不是硬答；② 提示层强制「只依据给定上下文回答，并标注引用片段」；③ 校验层做答案与引用的一致性校验（可再用一次小模型判定忠实度）；④ 交互层保留引用来源，让用户可点开原文核对。关键是产品上允许 AI 说「不知道」。
Q4：Agent 陷入无限循环怎么办？ A：① 硬性步数上限 + 超时；② 工具调用结果做去重，相同参数重复调用直接短路；③ 引入反思节点，连续失败两次后切换到备用策略或转人工；④ 记录完整轨迹做离线复盘。工程上宁可让它优雅失败，也不能让它烧 Token。
Q5：Function Call 和 MCP 的区别？ A：Function Call 是模型厂商的协议能力——把函数签名给模型，模型决定调不调、传什么参；MCP 是工具接入的标准化协议——用统一的服务端规范把外部系统（数据库、文件、SaaS）暴露给任意兼容的客户端，好处是工具一次开发、多模型复用，且权限边界清晰。实践中 MCP 更适合企业内部工具多的场景，Function Call 适合少量高频、需要极低延迟的工具。
Q6：多智能体协作你会怎么设计？ A：优先用主从模式：一个 Orchestrator 负责意图识别与任务分解，若干 Worker 各自持有专用工具与知识域（如「订单查询 Agent」「政策问答 Agent」「工单创建 Agent」），最后由 Orchestrator 汇总。对等协作只在需要相互校验时用（如一个写、一个审）。理由是主从模式可观测、可限流、易于排障，企业场景下可维护性优先于「看起来高级」。
Q7：怎么评测一个 Agent 好不好？ A：三层指标：① 结果层——任务成功率、答案忠实度、人工采纳率；② 过程层——工具调用正确率、平均步数、平均耗时、Token 成本；③ 业务层——人工客服替代率、问题解决时长缩短比例。要有固定回归测试集（把线上真实问题脱敏后固化成用例），每次改 Prompt/换模型都跑一遍，防止越改越差。
Q8：RAG 和微调怎么选？ A：判断标准是「知识的性质」。频繁变化的事实性知识（政策、价格、库存、条款）→ RAG，因为改数据不用重训；稳定的表达风格、领域术语理解、结构化输出格式 → 微调，用 LoRA 小成本即可。两者不互斥，最优解通常是「微调一个懂领域、会按格式输出的小模型 + RAG 提供实时事实」。
Q9：企业内网不能访问外网，怎么部署？ A：三层方案：① 模型层——开源模型（Qwen/DeepSeek 系列）本地部署，用 vLLM 做推理服务，量化到合适精度以匹配现有 GPU；② 组件层——Embedding、重排序、向量库全部本地化，离线镜像包交付；③ 更新层——建内网模型仓库与知识库增量同步机制，允许在内网完成知识更新，不依赖外网。这才是政企私有化交付的完整形态。
Q10（架构题）：设计一个支撑 500 人使用的企业智能助手，画出关键链路。 A：入口（企微/Web）→ 网关（鉴权、限流、审计）→ 会话服务（上下文管理，Redis 存会话）→ 路由层（意图分类，决定走知识问答 / 工具调用 / 闲聊）→ 知识问答走 RAG 链路（检索 → 重排 → LLM）→ 工具调用走 Agent 链路（Function Call / MCP → 业务系统 API）→ 返回层（流式 SSE）→ 全链路 Trace 落库。旁路要有：模型网关（多模型路由与降级）、评测服务、Token 成本看板、内容安全过滤。部署上用 K8s，推理服务与业务服务分池，避免推理把业务拖垮。
Q11（场景题）：业务方说「AI 回答不准，不想用了」，你怎么处理？ A：先量化再谈方案：拉出近 7 天的低分会话，人工归类错误类型——是召回缺失（没检到）、检索噪音（检到了但不相关）、还是模型没遵循上下文（检到了却没用）。三类解法完全不同：召回缺失 → 补数据源与查询改写；噪音 → 加阈值与重排；不遵循 → 改 Prompt 与加忠实度校验。同时把「不确定就说不确定」的交互上限打开。用数据说话，避免陷入「感觉不准」的争论。
Q12：为什么从通信云 / 后端转到 AI 大模型方向？ A：我不是从零转的。通信云时期我就在主线业务里落了大模型能力——用 RAG 做企业知识库优化套餐检索，用推荐算法做用户套餐匹配，用企微机器人做微服务链路监控。做这些事的判断是：后端的瓶颈已经不在「并发和存储」，而在「系统能不能理解业务意图」。而我有 16 年后端底子，能把 AI 能力做成可运维、可审计、能上生产的东西，这恰好是纯算法背景的人最缺的一环。
Q13：你带过团队吗？做过架构决策吗？ A：2017–2018 年在控客科技带过 20 人技术团队（产品/前端/后端/移动/测试全职能），主导旅游分销平台的架构选型与研发流程；在现公司是通信云全栈产品负责人，主导 Spring Cloud 微服务重构，把单体拆成可弹性扩展的服务群，并引入 RAG 与推荐系统。架构决策上我习惯用「先降复杂度、再谈性能」的原则。
Q14：一个 AI 项目最大的风险是什么？ A：不是模型不够强，是预期没对齐。业务方想象的是一个全知全能的顾问，实际交付的是一个在特定知识域内可信、域外会说「不知道」的助手。所以项目一开始就要和业务方约定：覆盖范围、准确率目标、失败时的兜底流程。技术风险反而是可控的。
Q15（反问铺垫）：你希望这个人进来三个月做出什么？ （此题为向面试官提问，见第七节）
该单位属央企体系（中国电子系），在人才引进指标上属第一梯队，是本次 TOP10 中落户可能性最高的岗位之一。面试时建议确认：
问业务负责人
问技术负责人 4. 模型是自研还是采购？有没有国产化/信创约束？ 5. 现有的工具接入是用 Function Call 还是已经在推 MCP？ 6. 推理资源是自建 GPU 还是云上？成本和并发大概什么量级？
问 HR 7. 该岗位的汇报线与发展路径？ 8. 落户指标情况（见第六节）？ 9. 薪资结构（基薪/年终/项目奖）与调薪周期？
声明：本文中的岗位画像为基于公开招聘信息的推断，不代表用人单位正式 JD；岗位信息以平台实时内容为准。本文不含任何个人隐私与账号凭据。
还没有评论，登录后来说两句。