# AI Agent 工程师: 工作内容、技能要求与入门路线

```{contents}
```

"AI Agent 工程师"这个词最近两年被用得很泛:招聘网站上,它可能指"会调 LangChain 的后端",也可能指"负责把大模型接进业务流程的产品工程师",甚至等于"Prompt 工程师"。

这篇文章回答三个问题:这个岗位**每天在做什么**、需要哪些**可验证的技能**、以及一个普通开发者**从零到能上手**的具体路线是什么。文中的每个概念都尽量落到本仓库已有的实践文章上——原理说明 + 可跑代码,而不是概念堆砌。

## 一句话定义

> AI Agent 工程师 = 把"会说话的模型"改造成"能自己动手把任务做完的系统"的人。

关键词是**系统**,不是模型。

| 岗位 | 主要产出 | 是否训练模型 |
|------|---------|-------------|
| 算法/大模型工程师 | 模型权重、微调与对齐方案、推理加速 | 是 |
| **AI Agent 工程师** | 能完成任务的 Agent 系统(循环 + 工具 + 上下文 + 评估 + 运维) | 基本不训练,以调用与工程集成为主 |
| Prompt 工程师 | 提示词模板与效果调优 | 否,但只是 Agent 工程的一个子集 |
| 后端工程师 | 稳定的业务 API 与数据流 | 否 |

一句话概括这个岗位要解决的问题:**概率性的组件,怎么接进要求确定性的业务里**。模型输出天然不确定,而业务要求"要么成功、要么可解释地失败",这两者之间的全部工程缝隙,就是这个岗位的工作内容。

## 一、日常工作内容

按一个 Agent 从想法到上线的生命周期展开,六个阶段的日常大致是:

```{mermaid}
flowchart LR
    A[定义任务边界<br/>成功标准] --> B[上下文与提示设计<br/>context engineering]
    B --> C[工具与协议<br/>function calling / MCP]
    C --> D[编排实现<br/>循环 / DAG / 多 Agent]
    D --> E[评估与观测<br/>eval + trace]
    E --> F[上线与运维<br/>成本 / 权限 / 回滚]
    F -.失败样本回流.-> B
    E -.不达标.-> D
```

### 1. 把模糊需求翻译成"可判定的任务"

业务方说"做个能自动处理客服工单的 Agent",这句话没法直接开工。要拆成:

1. **输入是什么**:邮件正文?工单系统里的字段?附件?
2. **输出是什么**:一句回复、一次数据库写入、一个工单状态变更?
3. **什么算成功**:这里是最关键的一步——**必须存在一个自动可判定的成功信号**。比如"工单被正确分类到 12 个类目之一"可以自动判定;"回复让客户满意"不可判定,得换成"包含退款金额且金额与订单表一致"。

能不能自动判定成功,直接决定这个任务适不适合做成 Agent。不可判定的任务先别急着上模型。

### 2. 上下文工程 (context engineering)

确定任务后,决定"模型每轮该看到什么"。这是当下这个岗位**最耗时间**的部分,也是效果差异最大的地方:

- **系统提示词**:角色、边界、输出格式约定。工程化的写法是把角色/工具规范/安全边界/任务管理分成独立模块,而不是写成一大段散文;
- **检索**:从文档库、代码库、数据库里取出该给模型的事实。这块的技术栈见 [RAG: 给模型接上外部知识](./rag.md);
- **历史与记忆**:多轮对话怎么压缩,跨会话经验怎么持久化(常见做法是落成 `AGENTS.md` 之类的项目记忆文件);
- **预算控制**:上下文窗口是有限的,超了就要摘要、截断、按优先级打分裁剪。

日常动作是:跑一个失败用例 → 打印出真正发给模型的完整上下文 → 发现"该给的信息没给"或"无关信息挤爆了窗口" → 改组装逻辑。

### 3. 工具与协议设计

工具是 Agent 的手,而模型只能看到工具的 JSON 描述,看不到实现。所以工具体验就是产品体验:

| 设计点 | 反例 | 正例 |
|--------|------|------|
| 描述 | `query`——查询数据 | "按订单号查订单状态与金额, 返回 JSON" |
| 粒度 | 一个 `do_everything` 巨工具 | 每个工具只做一件原子的事 |
| 返回 | 甩回 800 行原始日志 | 内部先过滤, 只回结构化结论 + 明确的成功/失败标记 |
| 权限 | 给 Agent 一个 unrestricted shell | 命令白名单 + 超时 + 高危操作人审 |

再往上就是协议层:把工具用统一协议(如 [MCP: AI 应用的 "USB-C" 接口](./mcp.md))暴露,做到"一处实现,多个 Agent 复用"。当工具数量上到几十个,协议化就从"锦上添花"变成"必需品"。

### 4. 编排:循环、DAG 还是多 Agent

三种形态各有适用面,选错会白烧很多 token:

| 形态 | 适合 | 代价 |
|------|------|------|
| 单次调用 / Prompt 链 | 步骤固定、一次问答能解决的 | 复杂任务会崩 |
| Agent 循环 (ReAct) | 流程未知的开放式探索 | 可能死循环、不可复现 |
| DAG | 流程已知、步骤固定的生产流程 | 需要事先把流程摸清楚 |
| 多 Agent (主管 + 专家) | 子任务彼此独立、可并行 | 通信开销大、调试成本高 |

成熟做法是**分层**:用 Agent 循环在探索阶段把流程摸清,固化下来后改写成 DAG 进生产。原理与最小实现见 [从0开始搭建一个 Agent](./agent.md) 和 [AI 工作流里的 DAG](./dag.md)。

### 5. 评估 (eval):这个岗位的分水岭

这是"玩具"和"产品"之间那道线。一个 Agent 上线前必须能回答:**改了这句提示词,效果是变好了还是变坏了?**

日常动作:

- 维护一个**测试集**:从真实失败样本里攒出来的(输入, 期望行为)列表,几十条起步;
- 定义**指标**:任务成功率、工具调用正确率、平均轮数、幻觉率、拒绝率、单任务成本与延迟;
- **回归**:每次改提示词/换模型/加工具后跑一遍全量测试集,对比通过率曲线;
- **判分方式**:能用代码判定的就用代码判(断言输出 JSON 字段、断言数据库状态);不能的用模型判分(LLM-as-judge),但要有抽样人工复核。

没有这一步,后面所有优化都是凭感觉。

### 6. 安全加固、上线与运维

- **提示词注入**:外部数据(网页、邮件、文件名)里夹带的指令,模型分不清"用户说的"和"数据里写的"。防护靠权限收口而不是靠提示词;
- **权限模型**:最小权限、沙箱执行、危险操作二次确认;
- **可观测**:每次运行保留完整 trace——发给模型的完整上下文、每轮的工具调用与返回、最终输出、耗时与 token 数。线上出问题第一件事是回放 trace;
- **成本与延迟优化**:缓存稳定前缀(见 [KV Cache: 大模型推理加速的关键机制](./kv-cache.md))、把简单请求路由到小模型、并行化无依赖的工具调用;
- **灰度与回滚**:新提示词、新模型先在 5% 流量上跑,指标不达标一键回退(整体部署方法见 [从学习到生产](./production-deployment.md))。

### 团队协作

- 和**业务方**:对齐"什么算成功",管理对准确率的预期(90% 不是"差不多了",20 次里错 2 次对某些场景不可接受);
- 和**后端/SRE**:工具接口、限流、鉴权、成本归属;
- 和**风控/法务**:数据不能出域、模型输出不能涉及合规承诺;
- 和**算法团队**:要不要微调、换哪个模型、上下文窗口多大。

一个容易被忽略的现实:**这个岗位的技术栈每几个月就会变一次**(模型换代、框架换代、协议换代)。能活下来的是那些理解"循环 + 工具 + 上下文 + 评估"这套不变量的人,而不是记住某个框架 API 的人。

## 二、需要的技能

按"基础 → 核心 → 加分"三层组织。判断某项技能是否真会,标准只有一个:**能不能在项目里用出来**。

### 第一层:基础(缺了寸步难行)

| 技能 | 具体到能做什么 | 为什么必需 |
|------|--------------|-----------|
| Python | 熟练写异步代码、类型标注、pydantic 数据校验 | Agent 生态的主语言, 几乎所有框架和示例都是 Python |
| HTTP / API 集成 | 调 REST、处理超时重试与限流、读 SDK 文档 | 每个工具都是一次 API 调用 |
| JSON / JSON Schema | 手写工具定义, 解析模型输出的结构化数据 | function calling 的接口语言 |
| Git 与命令行 | 分支、diff、grep 检索代码库 | Agent 常常要操作代码和文件 |
| 后端基本功 | 数据库读写、消息队列、容器化部署 | Agent 最终是一个要上线的服务 |
| 英文文档阅读 | 直接读官方 docs 和论文 | 中文资料滞后, 生态更新以英文为主 |

### 第二层:核心(决定能不能独立交付)

| 技能 | 具体到能做什么 |
|------|--------------|
| **LLM 基础直觉** | 知道 token、上下文窗口、温度、幻觉的成因;知道模型不会"执行"任何东西,只会输出 token,一切行动都是外层代码干的 |
| **Function Calling 协议** | 能手写 `tools` 定义、处理 `tool_calls`、把结果以正确 id 回传、处理参数解析失败 |
| **Agent 循环** | 能写出带最大轮数、超时、错误处理的 ReAct 循环;知道循环的记忆就是那串 messages |
| **上下文工程** | 能设计系统提示词的结构;能做检索、压缩、按优先级裁剪 |
| **RAG** | 会切分文档、算 embedding、向量检索 + 关键词检索混合、重排序;知道什么时候根本不需要向量库 |
| **评估与观测** | 能自己搭测试集与判分脚本;能接 trace 与日志, 用数据说话 |
| **工具设计** | 能写出一份模型不会用错的工具描述;知道返回值要短小结构化 |
| **安全与权限** | 理解提示词注入的攻击面;能设计沙箱、白名单、人审三道闸 |

### 第三层:加分(决定走多高)

| 技能 | 什么时候用得上 |
|------|--------------|
| 工作流编排(DAG、队列、重试、幂等) | 流程固化的生产系统, 见 [AI 工作流里的 DAG](./dag.md) |
| 多 Agent 协作 | 子任务可并行、需要角色分工时 |
| MCP / A2A 协议 | 工具与 Agent 需要跨系统复用时 |
| 微调与蒸馏 | 提示词优化到瓶颈、需要稳定输出格式或降本时 |
| 推理服务运维 | 自建推理(llama.cpp / vLLM)、GPU 显存与吞吐调优, 见 [从0开始搭建本地 AI 服务](./local-ai-service.md) |
| 产品思维 | 判断"这个需求该不该用 Agent 做", 往往是最高杠杆的技能 |

### 软技能

- **把不确定说清楚**:向非技术同事解释"为什么这次答错了""为什么准确率只能到 95%";
- **结果导向**:Agent 项目 80% 的时间花在让最后 10% 的失败率降下来,要有耐心做脏活;
- **持续学习但不追新**:新框架先看它解决了什么问题,再决定要不要引入。

## 三、如何入门

核心原则:**先跑通最小闭环,再逐层加复杂度**。不要一上来学框架——框架是对原理的封装,不理解原理,遇到问题只会卡死。

### 第一步:跑通"模型 + 一次函数调用"(1~2 天)

1. 在本地跑起一个模型服务(见 [从0开始搭建本地 AI 服务](./local-ai-service.md)),或者直接用任意 OpenAI 兼容 API;
2. 用 `curl` 或 Python 发一次带 `tools` 定义的请求,观察模型返回的 `tool_calls`;
3. 自己执行那个工具,把结果以 `role: "tool"` 回传,拿到最终答案。

**这一步的验收标准**:不看别人的代码,能自己写出这段请求-执行-回传的三步流程,并解释 `arguments` 为什么是字符串、`tool_call_id` 为什么必须原样带回。

### 第二步:写出你的第一个 Agent 循环(3~5 天)

按 [从0开始搭建一个 Agent](./agent.md) 里的 30 行示例跑通,然后**故意把它改坏**,观察每种故障的现象:

- 把 `max_rounds` 去掉,看它怎么不收敛;
- 把工具描述改得含糊,看模型是不是就不用这个工具了;
- 让工具返回 1 万行原始输出,看多轮之后回答质量怎么掉。

**这一步的验收标准**:能背出 Agent 的三要素(LLM + 工具 + 循环),并能独立诊断上面三种故障。

### 第三步:加上检索与结构化输出(1~2 周)

做一个**有真实数据的小项目**,例如"基于你自己的笔记/代码库回答问题的助手":

1. 文档切分 + embedding + 向量检索(参考 [RAG: 给模型接上外部知识](./rag.md));
2. 强制结构化输出(JSON),并用校验库在解析失败时触发重试;
3. 把检索也做成一门工具,让模型自己决定"要不要查、查什么"。

**这一步的验收标准**:能说出"什么时候该用检索、什么时候该把内容直接塞进提示词",以及混合检索为什么常常比纯向量检索好。

### 第四步:补上评估与安全(1~2 周)

这是区分"做过 demo"和"能做产品"的分水岭:

1. 攒 30 条真实测试用例(输入 + 期望行为),写个脚本自动跑分;
2. 记录每次运行的工具调用序列、token 数、耗时;
3. 给工具加白名单、超时、危险操作确认;写一个"注入攻击"用例(让 Agent 读一段含恶意指令的文件),验证它不会照做。

**这一步的验收标准**:你能拿着一条通过率曲线说"这次改动把成功率从 62% 提到 85%",而不是"感觉变好了"。

### 第五步:做真实项目,建立作品集(3~8 周)

入门最快的路径是**解决你自己真实存在的问题**。选题建议按"有明确成功信号"来挑:

| 项目 | 成功信号 | 会练到的技能 |
|------|---------|------------|
| 日志/告警分诊助手 | 错误分类与人工判断一致 | 结构化输出、评估集、规则兜底 |
| 个人知识库问答 | 答案引用到正确原文段落 | RAG、引用、幻觉抑制 |
| 代码库问答/改码助手 | 生成的补丁能通过测试 | 代码检索、工具设计、沙箱 |
| 工作流自动化(如日报汇总) | 定时产出且人工只做审核 | DAG、调度、幂等 |
| 客服工单处理 | 分类准确率 + 平均处理时长 | 工具权限、人机协作、上线运维 |

交付时**一定要写清三件事**:成功率多少(怎么量出来的)、失败模式有哪些、成本和延迟是多少。面试时这三条比"我用了哪个框架"有说服力得多。

### 一个 12 周路线图

```{mermaid}
flowchart LR
    W12["第 1~2 周<br/>Python + API<br/>+ JSON Schema"] --> W34["第 3~4 周<br/>本地模型<br/>+ 一次工具调用"]
    W34 --> W56["第 5~6 周<br/>Agent 循环<br/>+ 故障诊断"]
    W56 --> W78["第 7~9 周<br/>RAG<br/>+ 结构化输出"]
    W78 --> W910["第 10~11 周<br/>评估与安全"]
    W910 --> W1112["第 12 周<br/>真实项目<br/>+ 作品集"]
```

按每周 8~10 小时投入估算。有后端经验的人可以跳过基础段,直接用真实项目倒逼学习。

### 学习资源(按权威性排序)

1. **官方文档优先**:OpenAI / Anthropic 的 function calling 与上下文工程文档、模型上下文协议(MCP)规范、你所用推理引擎的文档。文档永远比二手教程新;
2. **论文**:ReAct(推理与行动交替)、Reflexion(反思)、以及各类 Agent 综述——读摘要 + 方法图即可,不必逐行推导;
3. **开源项目源码**:挑一个成熟 Agent 框架,只读它的主循环那一百来行,比读完整仓库有价值;
4. **本仓库的实践系列**:[从0开始搭建本地 AI 服务](./local-ai-service.md) → [从0开始搭建一个 Agent](./agent.md) → [RAG](./rag.md) → [MCP](./mcp.md) → [DAG](./dag.md) → [从学习到生产](./production-deployment.md),这是一条从原理到生产的完整线。

## 四、常见误区

| 误区 | 现实 |
|------|------|
| "Agent 效果不好是模型不行" | 大多数线上故障来自工具实现、上下文组装和错误处理, 不是模型本身。先打印出真正发给模型的上下文再下结论 |
| "先把框架学完再动手" | 框架换代很快, 主循环原理却十年不变。直接手写 30 行循环比看完 10 小时教程有用 |
| "提示词工程就是全部" | 提示词只是上下文工程的一部分; 工具设计、检索质量、评估闭环的杠杆往往更大 |
| "demo 惊艳 = 能上线" | demo 跑一次成功很容易, 上线要求第 100 次也成功, 还要能解释失败的那几次 |
| "Agent 越自主越好" | 生产系统里, 自主度要和可验证性匹配; 拿不准的环节就该插人工确认 |
| "多 Agent 一定更强" | 多 Agent 引入通信开销与不可复现性; 单 Agent + 更好的工具常常更划算 |
| "准确率 90% 就够用了" | 取决于场景: 内部草稿也许够, 涉及资金与用户外发则远远不够 |

## 五、面试与求职准备

**简历/作品**:一个能演示的项目 + 一份写清指标的报告(成功率、失败模式、成本、延迟)。带上你如何量化改进的那次迭代。

**高频问题**:

1. 一个 Agent 调用工具失败后应该怎么处理?(答:错误信息回传模型让它换路 + 重试上限 + 兜底逻辑,而不是抛异常结束)
2. 上下文塞满了怎么办?(答:按优先级裁剪 / 摘要压缩 / 检索代替全量塞入 / 分阶段交付)
3. 怎么防止提示词注入?(答:最小权限 + 沙箱 + 白名单 + 人工确认,提示词层面只能降低概率)
4. 怎么判断 Agent 改得好不好?(答:测试集 + 指标 + 回归对比,给出具体数字)
5. 什么时候该用 DAG、什么时候该用 Agent 循环?(答:流程是否已知/是否固定)
6. 幻觉怎么抑制?(答:检索给事实 + 强制引用 + 输出校验 + 明确的"不知道"出口)

**岗位方向**:AI 应用/Agent 开发工程师、AI 平台工程师、AI 产品工程师、解决方案架构师。要求从"会调 API"到"能设计评估体系"不等,看 JD 关键词就能分辨:出现"eval / 可观测 / 成本优化 / 权限"的,是认真的 Agent 岗;只写"熟悉 LangChain"的,多半是 prompt 集成岗。

## 小结

把全文压缩成三句话:

1. **工作内容**:定义可判定的任务 → 设计上下文与工具 → 编排循环或 DAG → 建立评估 → 收权限、上线上量 → 用失败样本回流持续迭代;
2. **技能要求**:Python 与 API 集成的底子 + function calling / 循环 / 上下文工程 / 工具设计 / RAG 的核心 + 评估与安全的分水岭能力;
3. **入门路径**:手写一次工具调用 → 手写 30 行循环 → 加检索与结构化输出 → 补评估与安全 → 用真实项目做作品集。

这个岗位真正的门槛从来不是"会不会用某个框架",而是能不能把一个概率性的系统,做成别人敢用的产品。