Agent工程师不是调Prompt的：本质是AI应用交付工程师

开头

最近这两年，AI行业冒出来一个特别火的岗位——Agent工程师。打开招聘软件一看，薪资开得比传统后端高出一截，职位描述里写满了LangChain、RAG、MCP、Function Calling这些词。但真坐下来跟同行聊一圈，你会发现一个有意思的现象：很多人对这个岗位的理解是模糊的，有人觉得它是搞算法的，有人觉得它是写Prompt的，还有人觉得它就是个加强版爬虫开发。

我做了几年软件交付，这两年带队落地了不少Agent项目，想给这个岗位做一个更接地气的定义：Agent工程师本质上不是研究员，也不是算法工程师，而是一位软件的交付工程师。

为什么这么说？因为Agent工程的核心问题从来不是“模型能不能做到”，而是“这套系统能不能在真实业务里稳定跑起来、出了问题怎么兜底、换了个场景还能不能复用”。这跟传统软件交付工程师的思维模型是一模一样的，只是交付的载体从“确定性的业务逻辑”变成了“充满不确定性的大模型应用”。

这篇文章把自己的踩坑经历和实操心得整理出来，给想入行的人、正在做Agent落地的人、以及招人用人方的管理者一些参考。全文不涉及复杂的数学推导，重点讲清楚Agent工程师到底在交付什么、怎么交付、交付过程中最容易栽在哪。

1. Agent工程师与交付工程师的角色对应关系

1.1 为什么说Agent工程师是“交付”而不是“研发”

先讲一个我前阵子遇到的真实案例。有个客户要做合同审查Agent，需求描述得很简单：“把合同里的风险条款自动标出来。”听起来是不是特别像一个成熟的AI功能？但真正做起来，从需求到上线，中间差了十万八千里。

首先，合同文件是什么格式？PDF有扫描版、有文字版、有表格嵌套、有页眉页脚，这些都得先处理干净。其次，“风险条款”这个定义在不同行业完全不一样，租赁合同的违约金条款和软件开发合同的IP归属条款，风险判断逻辑天差地别。再往后，模型输出结果怎么展示？是直接标红？还是给出修改建议？置信度不够的时候要不要人工复核？复核流怎么设计？

这些问题，没有一个是靠“调大模型”能解决的。它们全是典型的交付问题——需要梳理业务、拆解需求、设计流程、做异常兜底、安排测试验收。传统软件交付工程师干的活，Agent工程师一样都逃不掉。

所以我的判断是：Agent工程师的角色定位，应该是用大模型能力解决实际业务问题的交付者，而不是模型能力的探索者。

1.2 从招聘JD反推岗位真实技能模型

看了一圈市面上Agent工程师的招聘JD，出现频率最高的要求有这么几个：

• 熟悉LangChain、LlamaIndex等Agent框架
• 有RAG系统落地经验
• 熟悉Prompt Engineering
• 了解常见的模型API调用和微调方案
• 有Python开发能力
• 了解向量数据库

这些技能看起来五花八门，但把它们放到“交付工程师”的框架里就好理解了：

画像就很清晰了：这是一位懂业务、会开发、能搞定模型能力与实际场景之间落差的工程师。说白了，跟“交付工程师”的技能模型高度重合，只是多了一层跟大模型打交道的经验。

1.3 Agent交付与传统软件交付的异同点

做Agent交付和做传统软件交付相比，共性的东西很多：都要做需求分析、技术选型、方案设计、开发测试、上线运维。但差异点非常值得留意，我用一个表格把核心差异列出来：

这个差异直接影响Agent工程师的日常：你70%的时间花在与模型不确定性搏斗上，但方法论仍然来自软件工程那套东西。把确定的部分用工程手段焊死，把不确定的部分用机制约束到可控范围。

2. Agent交付的整套工作流拆解

2.1 从业务洞察到Agent方案的转化过程

Agent项目从哪里开始？我见过很多团队栽在第一步：客户说“我们要上一个智能客服”，开发团队就开干，干了一个月发现对方想要的其实是“能自动处理退换货的售后机器人”。需求理解的偏差，到后期再纠偏成本极高。

正确的起点是先把业务洞察转化成技术方案。这里分享一个简单有效的模板，我在每个Agent项目启动前都会用它过一遍：

1. 业务目标是什么（降本、增效、还是提升体验）
2. 使用对象是谁（C端用户、内部员工、还是管理人员）
3. 决策链路是什么（全自动决策、建议后人工拍板、还是人机协同）
4. 可用的数据有哪些（文档、数据库、API、还是完全没有历史数据）
5. 失败成本有多高（出错无所谓、出错了能人工兜底、还是出错就是重大事故）

这五个问题过完，方案边界基本就清楚了。比如“全自动决策+失败成本高”这种组合，第一版就不要做全自动，优先做辅助模式，把Agent的输出作为建议呈现给人工审核。

2.2 任务拆解：从目标到子任务再到工具编排

业务洞察完成后，紧接着就是任务拆解。这一步是整个Agent交付中最考验功力的环节。

举一个例子，客户要做一个“竞品分析周报Agent”。如果直接给模型一个Prompt：“帮我生成一份竞品分析周报”，结果一定非常飘——没有数据来源、没有格式要求、没有分析维度，模型只能编。

正确的拆解方式是这样：

• 主任务：生成竞品分析周报
• 子任务1：采集指定竞品的最新动态（新闻、官网、公众号）
• 子任务2：对采集内容做分类（产品更新、市场活动、人事变动、融资信息）
• 子任务3：结合我方产品现状生成影响分析
• 子任务4：按固定模板输出周报文档

每个子任务对应一个或一组工具：

• 子任务1对应：搜索引擎接口、网站爬虫、RSS订阅器
• 子任务2对应：LLM分类器
• 子任务3对应：LLM分析器 + 我方产品知识库RAG
• 子任务4对应：文档生成API（如导出到飞书云文档/钉钉文档）

这个拆解过程就是把一个模糊的“AI功能”变成一张可执行的流程图。如果团队习惯用流程图软件辅助设计，强烈建议这个阶段画一版清晰的任务流转图，后面开发会顺畅很多。画图工具用draw.io、ProcessOn或者excalidraw都行，关键是让团队对流程达成一致。

2.3 模型选型与成本测算的落地思路

Agent系统复杂在它通常“多模型协同”，不同环节用不同模型，效果和成本之间存在明显权衡。

先讲模型选型的基本原则。复杂推理（如代码生成、数学计算、多步规划）需要顶级模型，能力硬指标摆在那里。分类、抽取、格式化输出这类可控性强的任务，中小模型完全够用，成本低且响应快。摘要总结任务则要按文档长度来选，长文档优先选择支持长上下文的中端模型，性价比更高，而不是盲目上最强模型。

我前阵子做了一个合同审查Agent，整个流程里跑了四次模型调用：文档分类用小型模型、条款抽取用中型模型、风险判断用旗舰模型、风险建议生成用中型模型。如果全链路都用旗舰模型，单份合同的Token成本差不多翻了三倍，而实际效果提升不到1%。这个测试结果出来后，团队果断采取了混合模型方案。

成本测算方面说一个数据感受。中文场景下，旗舰模型处理一份10页合同大约需要5到6万Token，成本折合约几块钱人民币。量大的时候要按“每万次调用成本”来报价，给客户做需求评审时把Token消耗估算表直接亮出来，比说“保证效果优秀”有说服力得多。建议每个Agent项目里面加一层Token消耗日志埋点，按用户维度做成本分析，防止出现“效果好但客户跑单”的尴尬局面。

3. Agent系统核心模块的实现要点

3.1 提示词工程：不只是“写Prompt”而是“写逻辑”

很多人觉得提示词工程就是把人话组织得更有条理，这是对这个技术方向最大的误解。在Agent系统里，提示词承担的是“业务逻辑预编译”的角色，它是系统的规则层、兜底层，也是模型行为的边界。

我自己写提示词有几个基本要求：

第一，角色边界清晰。告诉模型它是谁、它不是谁，什么情况下必须拒绝回答，什么情况下必须主动求助。这个看似简单，但在复杂Agent里特别重要，不然模型会“越权”。

第二，输出格式强制约束。所有结构化输出必须要求模型按JSON格式返回，并且提供JSON Schema或者少样本示例。这一步能大幅减少解析异常。

第三，思考链路引导。对复杂的子任务，在提示词里写清楚分析步骤。以“风险判断”为例，先角色设定“你是资深法务顾问”，然后要模型先列出合同中存在的风险类型，再逐条分析，最后按模板输出，这样的结构化指令能显著降低模型“跳步”概率。

第四，边界口径统一。所有兜底话术必须硬编码在提示词里，不能放飞让模型即兴发挥。比如“无法从知识库中找到答案时，必须回答：‘抱歉，我无法回答该问题，请联系人工客服’”，要强制模型照做。

3.2 工具调用层：MCP与Function Calling的选型实战

Agent系统里最见工程师功力的部分是工具调用层。模型本身不产生外部数据，它的能力上限由它能调用什么工具决定。

现在主流的工具调用方案有两个：一个是OpenAI推出的Function Calling，模型在对话过程中自动判断需要调用哪个函数并生成函数参数；另一个是Anthropic推出的MCP协议，把工具调用标准化——模型通过MCP服务器发现可用工具、按统一格式调用、获取标准化结果。

遇到具体项目，选哪种要视情况而定。如果只对接两三个工具，且都在同一个代码仓库里，Function Calling更轻量，自己维护一套工具注册表就够了。如果工具数量多、跨团队协作，或者希望Agent能力可以横向扩展，MCP更合适，因为它把工具提供方和Agent解耦了，相当于给Agent“接口化能力”。我见过一个Agent项目对接了公司十几个内部系统，没有用MCP之前，每个系统都得定制开发一套适配逻辑，迁移成本极高，切换MCP后，新增一个系统只需要提供MCP Server配置，省下来的工作量非常可观。

工具调用层还有一个做法值得推荐：工具结果反馈回路。每次工具调用返回结果后，额外做一个校验，比如确认SQL查询结果是否为空、API返回是否超时，再把返回结果和校验信息一起重新喂给模型，让它判断是继续调用、纠错还是直接结束。这层增加了一个决策节点，但有效防止了模型在错误结果上继续“一本正经地胡说八道”。

3.3 RAG与知识库链路：企业知识落地的核心关卡

Agent真正产生业务价值的场景，大多数都得靠企业私有知识做支撑。RAG（检索增强生成）就是给Agent装上一个“企业知识外挂”，否则模型凭通用训练数据回答企业专属问题，准确率完全不可控。

我在多个项目里验证下来，RAG链路的核心优化点分别是：文档解析、分块策略、召回重排、上下文注入。

文档解析是第一个坑。很多PDF看起来正常，转出来却是图片，直接取文本拿不到东西。投一个“带OCR的解析层”在前面是必须动作，否则后续步骤都白搭。另外，表格结构很复杂的文档，如果解析后变成一堆乱序文本，召回效果会非常差。光这一步，处理不好就能让系统效果折损一半以上。

分块策略要靠实验说话，没有通吃方案。固定长度切块、按标题语义切块、按固定句子数量切块，在不同场景下效果差异很大。一个基本的经验是：检索定位型问题用小分块，生成摘要型问题用大分块并做重叠拼接。比如合同的“违约责任”条款，如果被切到两个块里，检索时就容易顾此失彼。

最后是重排序（Rerank）。向量检索TopK召回后，结果直接丢给模型往往不够精准。加一个Cross-Encoder重排序模型，对召回结果按相关性再次打分，把最相关的TopN送进上下文，通常能带来5到10个百分点的回答准确率提升。这块我建议直接作为RAG链路标配，不要省。

3.4 Agent可观测性：没有追踪就等于没有底牌

Agent系统上线和传统系统上线最大的不同在于：传统系统可以通过日志快速定位问题，Agent系统里，同一条用户问题可能因为模型随机性走出一条完全不同的调用路径，有的路径成功，有的路径失败，没有可观测性你根本不知道哪一步出了问题。

所以我带Agent项目时第一个要求就是：可观测性必须从第一天做起，不能等上线后再补。

可观测性至少包括三块：调用链追踪、Token成本分析、效果评估看板。调用链追踪这块，LangSmith、Langfuse、Helicone都有成熟方案，开源的用Langfuse自托管也完全可以。重点关注的是，每个节点要记录模型名称、Prompt版本、输入输出、Token数，以及工具调用的请求参数和响应结果。

调试阶段还有一个很容易被忽视的细节：模型在复杂工具链路里的某个环节连续重试三次以上，大概率是提示词引导有歧义或者工具返回格式不匹配。这个要专门设置“重试异常告警”，否则用户那边只会感受到“Agent转圈圈转很久”，异常原因完全无法感知。

另外，网络层的排查也经常遇到。比如Agent服务调用外部API超时，公网链路不稳定的时候反复重试拖垮整个请求，我通常会在调试阶段用终端调试工具验证接口连通性，CRT这类软件虽然老牌但胜在稳定，排查网络代理、端口连通、抓包都顺手。真到分布式环境，还是得靠可观测平台收口。

4. 常见问题与排查技巧实录

4.1 模型输出格式不稳定的根本解法

Agent开发展里最高频的坑，就是模型输出格式不稳定。说好返回JSON，它会在JSON前后加说明文字；要求日期格式YYYY-MM-DD，它会给你来一个“今天是2025年1月1日星期二”。

这个问题的根本解法在于：不要在输出解析层硬刚，要在前置约束层下功夫。具体做法包括：

第一，系统提示词里给JSON Schema和Few-shot示例。模型对“示例”的理解力远强于“描述”，给一个期望输出的完整示例，效果立竿见影。第二，使用JSON Mode。OpenAI等厂商提供了这种模式，模型在JSON Mode下“只顾着输出JSON”，可靠性大幅提升。第三，加一层防御性解析。解析失败时不要直接报错，而是用正则提取代码块中的JSON片段再解析，或者把错误信息回传给模型让它自己修正。第四，面对模型返回结构化数据特别不听话的情况下，可以考虑用小模型做“格式化修复”，成本低、效果好。

4.2 Agent死循环与超时失控的干预策略

Agent在规划多步任务时，偶尔会“钻牛角尖”——反复调用同一个工具、在同一轮里循环往复，把调用次数耗尽，体验非常糟糕。

干预方案分两层。第一层是硬限流，给调用次数设上限，比如单轮对话最多调用15次工具，超过即停止规划，把已收集到的结果直接返回给用户。第二层是软兜底，设计“退化路径”：当Agent感知到任务推进困难时，允许它主动切换成简化模式，跳过非核心子任务，先把主要答案给出来。这个设计要写进系统提示词里，让模型遇到“路走不通”时有一套备用方案，而不是死磕到超时。

另外，超时控制也要单独设置。工具调用耗时不可控时，需要给每个工具调用单独设超时时间，超时后中断该次调用，然后让模型决定是重试还是换方案。不要等在Agent主流程外层做一个大超时兜底，那只能保住接口不报错，救不了用户的体验。

4.3 效果评估：如何让“AI效果”变得可度量可回归

传统软件开发最舒服的地方在于，功能对不对有明确标准。Agent开发则没有这种“确定性对错”，效果好坏经常是“感觉还行”。一旦效果无法度量，团队就会陷入“反复调Prompt但都不知道有没有变好”的泥潭。

我对效果度量的建议是分三步走：

第一步，建评估集。至少准备100条覆盖典型场景的问题，每一条标注期望的标准回答或判定标准。这个数据集就是Agent的回归测试集。

第二步，定指标。维基级的用准确率、召回率，生成类的用人工评分或LLM-as-a-Judge。注意，LLM作为裁判的应用，要具体到打分维度里，包括相关性、完整性、准确性、格式正确性，并且每个维度要给详细评分细则，不然裁判不稳定。

第三步，每次改动后跑回归。改动Prompt、换模型、调参数后，跑一遍评估集进行比对，分析差在哪些Case上。效果下降就回滚，效果提升再上线。

评估集不用一次建完善，但要持续积累。每收到一个客户抱怨“回答质量问题”的反馈，就把它转成一条评估数据。系统上线三个月后，手里积累起几千条经过验证的评估数据，评估体系才算初步成型。有了这个底座，任何Agent版本迭代都变得踏实可控。

5. 交付与运维：Agent工程师的长期主义

5.1 Agent上线不是终点而是起点

传统软件上线后，只要需求不变代码不动，系统基本稳定运行。Agent不一样，模型API会升级、知识库要更新、业务场景会变化，甚至同一个模型在相同的输入下，答复也可能跟昨天略有偏差。

我把Agent运维理解为“养宠物”不是“开机器”。长期稳定需要一套完整机制：

一是模型版本管理。每次更换模型版本前必须跑回归集，准确率不降才可以切。同时记录线上使用的模型版本号，方便出问题快速回滚。二是知识库更新。企业知识文档更新频率不同，RAG检索库要设置周期性重建或增量更新任务，否则Agent会反复用旧知识答新问题。三是提示词版本管理。提示词对模型行为的影响是“致命性”的，所以提示词修改必须走评审，每次修改要记录变更原因和回归测试结果。

5.2 权限控制与数据安全：Agent交付中最容易忽略的硬伤

Agent系统能调用工具，就意味着它能访问数据、操作资源。权限控制如果设计不好，Agent就会成为企业数据安全的“后门”。

我在几个项目里都踩到过类似问题：Agent调用内部API查询用户信息，API接口没有按照最小权限开放，Agent能查到什么取决于它“说服了”模型输出什么参数。这是非常危险的一件事。

正确做法是三管齐下：

第一，Agent所用API Key的权限必须最小化。只分配给当前流程必需的范围，不要图省事用一把“超级Key”跑所有场景。第二，用户态概念。企业内部Agent要区分“谁在问”，涉及个人信息的查询，需要在工具层校验当前用户的权限范围，不能只要模型判断“可以答”就给查。第三，敏感操作二次确认。涉及删除、修改、发送消息等非逆向操作，必须走人工审批流，Agent只负责生成建议，不能直接执行。

5.3 从单点Agent到Agent平台化交付

做过的Agent项目多了之后，我有一个非常明显的感受：如果每个项目都从零搭建Agent，效率低、重复造轮子，而且每个项目的“坑”还都不互通。

Agent交付跑成熟以后的路径是平台化。底层统一模型管理平台，打通不同模型的API接入和能力路由，不要每个项目单独接一遍。工具注册中心把常用工具做成标准插件，后续新项目直接注册复用，大幅减少重复开发。评估中心沉淀评估集和回归测试流程，新项目一键批量跑效果验证。可观测平台统一收集所有Agent的调用链、成本、质量数据，做横向对比分析。

我最近在帮一个团队搭这套平台，做完之后，一个新Agent项目的平均交付周期直接缩短了一半。这就是“交付工程”的复利效应：把单点交付的经验提炼成平台能力，后面每个项目都在吃前期积累的红利。

5.4 架构设计先行：从一张软件架构图开始

最后强调一下架构设计的重要性。见过不少Agent项目，一开始代码全堆在一个Python文件里，Prompt、工具调用、业务逻辑全混在一起。上线后加功能都费劲，想排查问题更不知道该从哪下手。

Agent系统的标准架构分层应该是：应用层（对话界面、管理后台）、编排层（Agent规划器、工作流引擎）、工具层（MCP服务器、API适配器、数据检索）、模型层（多模型接入、模型路由、降级策略）、数据层（向量数据库、业务数据库、缓存）。每一层之间用清晰的接口解耦，这样上层迭代不会拖累下层，模型升级也不会影响应用界面。

画架构图这件事，我推荐团队用draw.io之类的软件先画清楚再动手写代码。画图的过程就是思考过程，节点之间的关系理清楚了，开发就是填肉的工作。这跟传统软件工程里的设计先行是一个道理，不要让“AI项目很新”成为不按工程规范干活的借口。

我自己在多个项目里验证下来，凡是一开始就画清架构图、分层设计、接口定义的Agent项目，后期维护成本都远低于“先跑起来再说”的项目。越是底层逻辑不确定的系统，越需要工程化的套路去兜底。

结尾

做Agent交付这两年，我最大的体感是：这个岗位看起来要懂的东西很多，模型、提示词、RAG、工具调用、前端、后端、运维样样都要沾边，听起来很唬人。但真正拉开交付水平差距的，往往不是谁的提示词写得花哨，而是谁更有“交付思维”——谁更早把评估集建起来、谁更早把可观测性打通、谁更早把权限边界划清楚、谁更早把知识库更新机制跑起来。

一个Agent项目的成功，靠的不是模型跑通那一刻的惊喜，而是后续几百天里每一次小修改都有依据、每一次线上异常都能快速定位、每一个新需求都能低成本接入。这些能力全部来自软件工程的基本功，只是穿了一层AI的外衣。

所以如果你正在准备入行Agent工程师，或者已经在做Agent交付但觉得心里没底，我的建议很简单：把传统软件工程那套好习惯捡起来，再加上对模型行为的敬畏心，你会走得更稳。Agent技术迭代很快，今天的热门框架明天可能就被替代，但好的交付习惯，永远都不会过时。

最后再分享一个小技巧：做Agent项目时，从第一天起就坚持记录“每次改动带来的效果变化”。这个习惯会让你在一个季度后拥有别人没有的“直觉”，因为你清楚什么样的改动在什么场景下真的有效，而不是凭感觉调参、靠运气上线。