Agent 插件 / 技能开发工程师

💵 2026 年薪资区间与平均薪资

下表口径：一线城市 · 社招 · 税前月薪（现金部分）。数字综合 2026 年公开招聘信息与薪酬报告整理，不是精确统计 —— 校招与社招、均值与中位、是否含股票期权的口径差异很大，实际请以招聘平台实时岗位为准。

平均月薪参考：约 38K（一线城市社招口径）。溢价在「接口设计」：把内部系统包装成模型能稳定调用的工具，比会写提示词稀缺得多。

可以对照的公开锚点：2026 届校招里 AI 相关岗位月薪中位值约 2.53 万元；偏中高端的样本中 AI 岗位平均月薪约 6.07 万元；算法研究员 / 大模型算法岗位普遍在 7 万元 左右，AI 科学家 / 负责人可达 13 万元 以上。资深 AI 人才 2026 年的调薪幅度最高可达 20%–35%，高于市场平均。

地域差异明显：长三角与大湾区贡献了全国近七成的 AI 岗位需求，北京、上海、深圳、杭州、苏州的薪酬普遍高于其他城市。

🏦 岗位画像：这个岗位到底在招谁

这个岗位是给 Agent 造手和脚的人。模型会推理，但它要真正动到真实系统，必须有人把接口、数据库、文件、浏览器包装成模型能安全调用的工具。招的不是算法，而是懂协议、懂接口设计、更懂权限与安全边界的人。

日常工作有三块：设计工具（粒度、命名、描述、参数结构、返回结构）、实现协议（工具服务端、能力声明、资源与模板）、以及做安全收口（鉴权透传、最小权限、危险操作确认、审计）。做得好的标志是模型选得对、参数填得准、出错能兜住，而这三点里最难的是第三点。

三类用人单位面试侧重不同。做 Agent 平台的公司重生态，会追问多工具命名冲突、版本兼容、工具市场怎么治理；SaaS 厂商要把自己的产品变成 Agent 可调用能力，会追问接口抽象与租户权限；企业内部团队重落地，会追问内部系统的鉴权怎么接、写操作怎么防误伤。

一句话判断自己匹不匹配：你能把一个业务接口设计成模型「选得对、参得准、错了能兜」的工具，并且说清权限怎么收窄——你匹配。

📅 岗位职责

• 设计工具与技能：粒度、命名、描述文案、参数结构、返回结构与错误语义
• 实现工具服务端：协议实现、能力声明、资源与提示模板、连接管理
• 接入鉴权与授权：用户身份透传、令牌存储与刷新、最小权限与操作审计
• 做安全边界：输入校验、输出净化、防提示注入、危险操作二次确认
• 维护工具评测集：调用正确率、参数准确率、误用与漏用统计
• 管理版本兼容：工具变更对既有 Agent 的影响评估、灰度与回滚
• 写文档与示例，让模型与人两条读者都能看懂

🗝️ 岗位技能：技术基础

必备

• 工具协议：MCP 的角色划分（客户端与服务端）、工具与资源的区别、提示模板的用途、传输方式（本地标准输入输出、HTTP 类）与能力协商
• 接口设计：从接口描述到工具定义的映射、参数类型与枚举、必填与默认值、错误语义与可恢复性提示
• 结构校验：JSON Schema、严格模式、服务端二次校验，不信任模型传来的参数
• 鉴权与授权：OAuth2 授权码与令牌刷新、按用户身份透传、最小权限原则
• 安全：提示注入（工具返回内容被当成指令）、越权、服务端请求伪造、敏感数据泄露、危险操作确认
• 工程：TypeScript 或 Python 服务端开发、超时与重试、幂等、日志脱敏

加分

• 设计过多工具生态，处理过命名冲突、重复能力与版本兼容
• 做过沙箱隔离：在宿主环境里安全执行用户或模型给的代码
• 有前端经验，能做工具调用的可视化确认与结果展示
• 懂 Agent 侧：知道工具数量与描述措辞对选择准确率的影响，并有实测数据

🛡️ 技术面重点：会被问什么

• 「工具该做多细？」——考设计判断。太细会导致调用次数多、链路长、成本高且容易断；太粗会让参数复杂、模型填不对。经验法则是一个工具对应一个清晰的用户意图，并要能说出取舍理由。
• 「五十个工具怎么让模型选对？」——考工程手段。分层或分组暴露、按会话状态动态裁剪工具集、描述里写清适用与不适用场景、必要时先选类别再选具体工具。
• 「工具返回的内容里藏了指令怎么办？」——考提示注入。把工具输出当数据不当指令、返回结构化结果、对可执行动作做二次确认与权限校验。
• 「危险操作用户误触怎么办？」——考安全设计。写操作要幂等加确认加权限校验加审计，删除类操作默认需要人工确认，批量操作要限制影响范围。
• 「工具和资源在协议上有什么区别？」——考协议细节。工具是模型主动调用的动作，资源是可读取的上下文数据，提示模板是可复用的模板，三者用途与风险不同。
• 「鉴权是怎么做的？」——考授权模型。要用用户自己的身份与权限，而不是服务账号的权限；令牌安全存储与刷新，越权时返回明确错误让模型换策略。
• 「工具改版会不会把线上 Agent 弄崩？」——考兼容。新增参数要可选、返回字段只增不删、变更前跑评测集回归、发布用灰度并保留回滚。

⚖️ 业务场景：选型与权衡

🚧 故障排查

• 模型不选这个工具：描述含糊或命名太泛。描述里写清什么时候用、什么时候不用，补一到两个调用示例。
• 参数经常填错：结构太宽松或缺少枚举。收窄类型、补枚举与示例，服务端校验并返回可理解的错误信息。
• 工具超时把整轮对话拖死：没有超时设置。单工具超时加快速失败，返回可读错误让模型换策略。
• 同一工具被反复调用：返回信息不足以让模型判断已完成。返回结构化结果与明确的完成语义，并对重复调用做去重。
• 权限报错频繁：用了服务账号而不是用户身份。改为透传用户令牌，权限不足时返回明确提示而不是内部错误。
• 注入导致越权动作：工具输出被当成指令执行。对写操作加二次确认与权限复校，对输出做净化与标记。

💵 成本优化

• 工具描述也吃 token：精简描述、按需暴露工具子集，是降输入成本最直接的一招。
• 减少调用步数：合并高频组合动作，一次调用返回更多相关信息。
• 结果先截断再入上下文：大结果在工具侧裁剪或摘要，不要把整页内容塞进上下文。
• 缓存只读工具的结果：同一查询在短时间内复用，注意带上用户与租户维度。
• 确定性逻辑放进工具：能算的别让模型推理，既省钱又更准。
• 按工具做成本归因：找出最贵、最常被误用的几个工具先优化。

♾️ 项目经历怎么讲

用三段式：原有痛点 → 工具设计与安全设计 → 效果与安全记录。这个岗位最能加分的是「安全上没出过事」和「调用正确率提升了多少」这两类证据。

1. 原有痛点：模型只能聊不能做，或每个工具各写各的、风格与鉴权都不统一
2. 关键设计：粒度怎么定的、权限怎么收的、注入怎么防的、评测集怎么建的
3. 结果：调用正确率、端到端任务完成率、安全事故次数、新工具接入成本

正例：

我把内部工单系统做成八种能力的工具服务端，写操作全部要求确认并透传用户权限，建立了包含两百条样本的评测集做回归。上线后端到端任务成功率从六成多提到八成以上，没有发生越权写入；新增工具从半天缩到一小时，因为协议与鉴权是统一封装的。

反例：

我写了很多工具给 Agent 用。

反例讲不出粒度依据、权限模型与安全设计。面试官问「模型乱调用写接口怎么办」，就断了。