AI Agent 工程师的核心能力：从模型调用到可靠系统

这两年，AI Agent 工程师开始成为一个越来越常见的岗位名称。

但很多学习路线仍然停留在技术名词的罗列：Python、LangChain、Prompt、RAG、MCP、多 Agent。学完一圈，Demo 能跑了，真正接到业务时却不知道该从哪里下手。

问题不在于这些技术不重要，而在于它们不是主线。

我对这个岗位的理解是：

AI Agent 工程师不是“会调用大模型 API 的工程师”，也不是“特别会写 Prompt 的人”。

更准确地说，他是一个能把不稳定的模型能力，变成可执行、可验证、可恢复、可交付系统的工程师。

模型有概率。

业务要结果。

Agent 工程师的工作，就是在这两者之间搭一座桥。

真正的主线是：

你能不能定义一个目标，让 Agent 调用真实工具持续推进；出错时保留秩序；最后用外部证据证明任务确实完成了。

这篇文章试着给出一张完整的能力地图，以及一条可以用真实项目验证的成长路线。

先认清这个岗位到底在做什么

一个最小 Agent，看起来可能只有几十行代码：

用户输入
  -> 调用模型
  -> 模型选择工具
  -> 执行工具
  -> 把结果交还模型
  -> 循环直到输出答案

这部分不难。

真正困难的是后面的几十个问题：

模型为什么该调工具时没有调？
工具参数错了，应该重试、修正还是退出？
同一个写操作执行两次，会不会产生重复数据？
RAG 搜到的内容到底是不是正确证据？
上下文越来越长，哪些该保留，哪些该压缩？
任务跑了两个小时，中断后能不能继续？
模型说“完成了”，谁来证明它真的完成？
高风险操作什么时候必须让人确认？
换一个模型以后，系统为什么突然退化？
效果提升了 5%，成本却涨了三倍，值不值得？

这些问题已经不是 Prompt Engineering 能单独解决的了。

它们涉及软件工程、分布式系统、数据工程、产品设计、安全治理和评估。

所以我对这个岗位还有一个更具体的定义：

AI Agent 工程师，本质上是一个理解模型不确定性的软件系统工程师。

第一层：扎实的软件工程基础

这是最容易被低估的一层。

很多学习路线一上来就教框架，但真实 Agent 项目最后拼的往往还是传统工程能力。

至少要掌握：

一门主力语言，Python 或 TypeScript 都可以；
HTTP、WebSocket、流式响应和异步编程；
数据库、缓存、队列和对象存储；
Git、测试、CI/CD、日志和部署；
API 设计、错误处理、重试和幂等；
基本的权限、安全和密钥管理；
阅读陌生代码和定位线上问题的能力。

为什么这些重要？

因为 Agent 一旦开始做事，就一定会碰真实系统。

它要读数据库、调接口、改文件、跑命令、等待异步任务、处理第三方限流。模型可以帮你写代码，但它不会替你承担系统设计的责任。

比如一个 sendEmail 工具，看起来只是调用一次 API。

真正上线以后，你要考虑：

重试会不会导致邮件发两次；
请求超时后，邮件到底发出去没有；
用户有没有权限给这个地址发信；
敏感信息能不能进入日志；
Agent 生成的是草稿，还是可以直接发送；
操作失败以后如何补偿。

这些都不是模型问题。

这是软件工程问题。

如果你已经是后端、全栈、基础设施或平台工程师，其实不用把自己清零重学。你原来的大部分能力都能迁移过来。

第二层：理解模型，而不是迷信模型

Agent 工程师不一定要会训练大模型，但必须理解模型的工作边界。

至少要知道这些东西：

token 和 context window 是什么；
system prompt、用户消息、工具结果如何进入上下文；
temperature、reasoning effort、structured output 会影响什么；
tool calling 是模型生成结构化决策，不是模型真的执行了函数；
embedding 适合解决什么，不适合解决什么；
prompt cache 为什么会命中或失效；
不同模型在推理、工具调用、长上下文、成本和速度上的差异；
幻觉不是一个可以彻底“修掉”的 bug，而是要被系统管理的风险。

真正有用的能力不是背参数。

而是遇到问题时，能判断它属于哪一层。

比如 Agent 漏掉了一次工具调用，可能是：

工具描述不清楚；
工具太多，选择空间过大；
当前上下文里没有触发工具所需的信息；
模型本身工具调用能力弱；
system prompt 和用户指令发生了冲突；
上游状态已经错了。

如果你把所有问题都归结为“Prompt 写得不好”，优化很快就会变成玄学。

第三层：Context 和 RAG

Agent 的能力，不只取决于模型知道什么，还取决于这一轮看见了什么。

这就是 Context Engineering。

你需要理解不同信息的性质：

Context：这一轮决策必须看到的信息
State：任务进行到哪里、已经发生了什么
Memory：跨任务、跨会话需要保留的经验和偏好
Knowledge：通过 RAG 动态检索的外部知识

这四个东西不能全部塞进聊天历史。

RAG 也不能只理解成“文档切块以后放进向量库”。

一套稍微可靠的 RAG，至少包括：

文档解析：网页、PDF、表格、代码不能统一按纯文本处理；
Chunk：保留标题、章节、代码块和语义边界；
Metadata：时间、来源、权限、业务线和文档层级；
Retrieval：关键词、向量和结构化过滤组合；
Rerank：召回负责找全，排序负责找准；
Context Assembly：控制顺序、长度、重复和冲突；
Citation：回答可以回到原始证据；
Evaluation：知道没搜到、搜错了，还是模型没用好证据。

学习这一层最好的方式，不是做一个“上传 PDF 然后聊天”的页面。

而是给自己设一组难题：跨文档引用、表格问答、时间冲突、权限过滤、没有答案。然后记录每一次错误发生在哪个阶段。

第四层：Tool Calling 和能力治理

Tool Calling 是 Agent 真正从“说”走向“做”的地方。

也是最容易翻车的地方。

一个好工具不只是有名字、描述和 JSON Schema。它还应该有：

清楚的输入和输出契约；
明确的副作用；
可区分的错误类型；
超时和重试策略；
幂等或补偿机制；
权限和审批规则；
输出截断和敏感信息处理；
可以进入 trace 的执行记录。

我一般会先按风险给工具分层：

类型	例子	默认策略
只读	搜索、查询、读取文件	自动执行
可逆写入	创建草稿、写临时文件	自动执行并记录
高风险写入	发邮件、提交代码、修改订单	执行前确认
不可逆操作	删除数据、扣款、生产部署	强审批或禁止

要记住一件事：

工具不是 Agent 的“插件列表”，而是系统交给模型的权力。

会定义工具，只能说明你做出了 Demo。

会治理工具，才开始接近生产系统。

第五层：Agent Loop、State 和 Memory

Agent 不只是模型调用一次工具。

它需要在多轮行动中持续接近目标。

我会把一个完整 Loop 拆成这些部分：

Goal         目标和成功标准
Planner      根据当前状态选择下一步
Actor        调模型、工具或子 Agent 执行动作
Observer     收集工具输出、日志、diff 和环境变化
Verifier     判断任务是否真的取得进展
State        保存已完成、失败、阻塞和下一步
Policy       权限、预算、模型路由和重试约束
Exit         成功、失败、风险、预算或人工接管

这里有两个常见误区。

第一个是把计划当成一次性产物。

真实任务会不断出现新信息，好的 Planner 应该根据 Observer 和 Verifier 的结果滚动调整，而不是死守最初生成的十步计划。

第二个是把聊天历史当成 State。

聊天历史记录了说过什么，但任务状态要回答：

当前目标是什么；
哪些已经完成；
哪些验证通过；
失败过什么；
为什么选择下一步；
哪些动作不能再重复；
中断以后从哪里恢复。

长任务能不能稳定运行，往往不取决于上下文窗口有多大，而取决于这些状态有没有被系统接住。

第六层：Harness Engineering

如果说模型是发动机，Harness 就是发动机周围整套让它可以上路的系统。

它把前面的能力组织起来：

Prompt 和上下文装配；
工具注册和权限；
Loop 和任务状态；
沙箱和资源隔离；
Hooks、Skills、MCP 和插件；
Trace、日志和可观测性；
Context compaction 和长任务恢复；
Verifier、评估和质量门禁；
人类确认、接管和回滚。

我自己做 Orca 时，对这一层感受很深。

有一次用户只反馈了三个字：

卡死了。

把 session 日志拉出来后，我看到接近 88 万 input tokens。真正的问题不是某个请求超时，而是很多小问题叠在一起：文件读取太长、搜索结果没有分页、旧 reasoning 被反复带回、压缩触发太晚、工具输出不断膨胀，系统压缩时用户还不知道发生了什么。

最后的修复涉及工具输出、上下文重放、soft compaction、TUI 状态和回归测试。

模型没有变。

变的是它在怎样的工程环境里工作。

这就是 Harness Engineering。

这次问题的完整排查过程，我单独写在了《用户说 Orca 卡死了，我最后修的是 Agent 的上下文债》里。

优秀的 Agent 工程师，不能只在模型表现好时把流程跑通。

还要在模型犯错、工具失败、上下文膨胀和任务中断时，让系统仍然保留秩序。

第七层：Evaluation 和可观测性

这是我认为 Agent 工程师最核心，也最稀缺的一项能力。

没有评估，Agent 开发就是玄学。

你改了 Prompt，感觉更好了。

换了模型，感觉更聪明了。

加了几个工具，感觉能力更强了。

但它可能只是换了一种错法。

Agent 评估不能只看最终回答像不像。至少要看五个维度：

维度	要回答的问题
任务	有没有真正完成目标
证据	结论有没有可靠依据
过程	工具和步骤是否合理
成本	token、时间和调用次数是否可接受
边界	失败和风险是否处理得当

不要让模型既当选手，又当唯一裁判。

能用确定性验证的，优先使用确定性验证：

代码任务跑测试和构建；
数据任务核对查询结果；
RAG 任务检查引用证据；
工作流任务检查下游状态；
高风险任务检查审批和审计记录。

LLM-as-Judge 可以辅助处理主观质量，但不能代替测试、规则和人工抽检。

同时要建立 trace。

一次任务为什么成功、为什么失败、在哪一步开始跑偏、花了多少成本，都应该能够被还原。没有 trace，你看到的只有最后一段话，根本谈不上优化。

第八层：安全、成本和生产工程

Demo 关心“能不能做”。

生产系统还要关心“出事怎么办”。

这一层包括：

Prompt injection 和不可信内容隔离；
工具权限、最小授权和敏感操作审批；
文件系统、Shell、浏览器和代码执行沙箱；
密钥、隐私数据和日志脱敏；
超时、限流、重试、熔断和降级；
模型路由、缓存和 token 预算；
checkpoint、恢复、回滚和人工接管；
灰度发布、监控、告警和事故复盘。

Agent 最大的风险不是偶尔答错。

而是它答错以后还有执行权。

所以安全不能等产品上线前再补。权限和风险边界，应该在定义工具时就进入设计。

成本也是一样。

“让模型再想一轮”很容易，“这一轮是否值得”才是工程问题。优秀的 Agent 工程师要能在任务成功率、延迟和成本之间做取舍，而不是默认把所有步骤都交给最贵的模型。

第九层：产品和领域判断

最后一层经常被技术学习路线漏掉。

不是所有流程都适合做 Agent。

Agent 比较适合这些任务：

输入和路径有一定不确定性；
需要动态选择工具；
可以通过环境反馈逐步推进；
有清楚的成功标准；
失败可以被发现、恢复或交还给人。

如果流程高度固定、规则明确，普通工作流和代码通常更便宜、更稳定。

如果任务没有可验证的结果，比如“帮公司做出正确战略”，那不是再加几个 Agent 就能解决的。

优秀的 Agent 工程师，不只是会问“怎么实现”。

他还要问：

为什么这里需要 Agent，而不是普通自动化？
用户愿意把多大的权力交给它？
用户什么时候需要看到过程？
哪些错误可以容忍，哪些错误一次都不能发生？
人类应该在什么位置介入？
这个系统创造的价值，能不能覆盖模型和工程成本？

技术决定能不能做。

产品判断决定该不该做。

一条更实际的学习路线

如果让我重新学一次，我不会从“把所有框架过一遍”开始。

我会用四个项目逐层建立能力。

第一个项目：有证据的 RAG

做一个你真正熟悉领域的知识助手。

要求不只是能问答，还要：

支持多种文档；
使用 metadata 和 hybrid search；
回答附带原文引用；
找不到时明确拒答；
准备至少 30 条评估样本；
记录召回、答案、延迟和成本。

做完这个项目，你会真正理解解析、检索、上下文和评估。

第二个项目：会做事的单 Agent

给它 3 到 5 个真实工具，比如搜索、读取数据、生成草稿和提交审批。

要求：

工具有明确 Schema；
错误有语义；
写操作具备幂等性；
高风险动作需要确认；
最终结果经过 Verifier；
整个过程可以在 trace 里重放。

不要急着做多 Agent。

一个单 Agent 的工具、状态、权限和验证都没有做好，多 Agent 只会放大混乱。

第三个项目：可以中断和恢复的长任务 Agent

让它完成一个持续几十分钟、跨多个步骤的任务。

比如分析一个仓库、修复问题、运行测试并生成报告。

要求：

有明确 Goal 和验收标准；
State 不依赖聊天历史；
支持 checkpoint 和 resume；
有最大轮数、token 和工具预算；
能检测重复动作和无进展；
中断后知道从哪里继续；
无法完成时能主动交还给人。

这一步会让你真正理解 Loop、State、Memory 和 Harness。

第四个项目：接入真实用户

最后，把前面的 Agent 给真实用户使用。

不一定要很多人，十个真实用户就能暴露大量 Demo 里看不到的问题。

你需要开始处理：

模糊输入；
权限差异；
失败恢复；
反馈和投诉；
成本和延迟；
版本退化；
监控和事故复盘。

Agent 工程能力不是看教程长出来的。

它是在真实任务失败以后，你能不能把这次失败沉淀成下一次的机制。

怎么判断自己有没有入门？

不是看你会多少框架。

我会用下面这些问题检查：

你能不能不用框架，写出一个最小 Agent Loop？
你能不能解释 Context、State、Memory 的区别？
你能不能给工具做权限和副作用分级？
你能不能区分 RAG 是召回错了，还是生成错了？
你能不能为一个 Agent 写 20 到 30 条固定 eval case？
你能不能从 trace 里找到任务开始跑偏的位置？
你能不能让长任务中断后继续，而不是重新开始？
你能不能证明一次改动提高了成功率，而不是只说“感觉更好了”？
你能不能说明什么时候不该用 Agent？

如果这些问题大多能回答，并且有实际项目作为证据，你已经不只是“会调用模型”了。

最后

成为 AI Agent 工程师并不需要先成为大模型研究员。

但成为一名优秀的 AI Agent 工程师，需要你同时尊重两件事：

第一，模型确实带来了过去软件没有的智能和泛化能力。

第二，这种能力天然不稳定，不能直接等同于可靠交付。

所以真正要学的，不只是 Prompt、RAG、Tool Calling 和框架。

而是怎么定义目标、组织上下文、治理工具、记录状态、构建 Loop、验证结果、控制风险，再把一次次失败沉淀成系统能力。

模型决定 Agent 的上限。

工程决定它有没有下限。

而优秀的 Agent 工程师，做的就是把这条下限一点点托起来。