强Agent时代，Agent开发岗位到底在招什么人？

1. 当招聘启事开始要求"会写Prompt"，Agent开发这个岗位到底在招什么人

"强Agent时代，还招Agent开发？"这个问题我第一次在技术群里看到的时候，底下跟了一串"同问"。有人觉得Agent都能自己写代码、自己调工具、自己规划任务了，那还要人干嘛；也有人反驳说，恰恰因为Agent变强了，才更需要懂Agent的人。这两种说法其实都没说到点子上。

我先把结论摆出来：Agent越强，Agent开发这个岗位越不会消失，但它招的人变了。以前招的是"会调API、会拼Prompt、会接LangChain"的人，现在招的是"知道Agent什么时候会崩、崩了怎么兜、成本怎么压、边界怎么划"的人。前者是操作工，后者是工程师。标题里那个问号，本质上问的不是"还要不要人"，而是"还要什么样的人"。

这篇内容我打算聊清楚几件事：Agent开发这个岗位的真实工作内容到底是什么，它和Prompt Engineer、AI Engineer的边界在哪，强Agent时代哪些活被Agent自己吃掉了、哪些活反而变得更值钱，以及如果你现在想入行或者想转型，学习路线应该怎么排。适合正在观望这个方向的人、已经在一线但感觉活变少了的人，以及团队里要搭Agent项目、需要判断该招什么人的技术负责人。

先破一个最常见的误解。很多人以为Agent开发就是"写Prompt + 接工具"，所以看到Claude、GPT这类模型能力越来越强，就觉得这活要被替代了。这个判断的问题在于，它把Agent开发等同于"让Agent跑起来"，而实际岗位里，"让它跑起来"可能只占20%的时间，剩下80%全花在"让它稳定地、可控地、便宜地跑下去"上。模型越强，后面这80%的复杂度反而越高，因为你能做的事情变多了，出问题的面也变大了。

2. Agent开发、Prompt Engineer、AI Engineer：三个岗位到底谁在干什么

2.1 从一条真实的分工线说起

我拿一个具体项目来拆。假设要做"让Agent自动把一篇网页整理成Markdown并归档"这个功能。听起来简单，但三个人在这件事上的分工完全不同。

Prompt Engineer关心的是：给模型的指令怎么写才能让它稳定输出结构化的Markdown，要不要给few-shot示例，标题层级怎么约束，遇到表格和代码块怎么处理。他的产出是一段经过反复测试的Prompt模板，以及一套评估这个模板好不好的测试用例。

AI Engineer关心的是：整个链路怎么搭。网页怎么抓、正文怎么抽取、超长内容怎么切分、模型调用怎么并发、失败了怎么重试、结果存到哪、怎么和现有的知识库打通。他的产出是一个能跑的服务，以及它的监控和告警。

Agent开发关心的是：这个Agent该有哪些工具（抓取工具、转换工具、归档工具），工具之间怎么编排，Agent自己决定调用顺序还是走固定流程，它有没有记忆、记忆存什么，跑偏了怎么拉回来，一次任务大概烧多少token，成本能不能接受。他的产出是一个"会自己干活但不会乱来"的Agent。

你会发现，这三者有重叠，但重心完全不同。Prompt Engineer偏"语言层"，AI Engineer偏"系统层"，Agent开发偏"决策层"。强Agent时代，模型自己把"语言层"的很多活干了——你随便说句话它就能理解，不需要你精雕细琢Prompt了。所以纯Prompt Engineer的空间确实在被压缩。但"决策层"的活不但没少，反而变多了，因为Agent能做的决策越多，你需要设计的约束、兜底、评估就越多。

2.2 一张表看清三者的能力要求差异

这张表不是要分高低，而是想说清楚：如果你现在做的是纯Prompt调优，确实该焦虑；如果你做的是Agent编排和稳定性，反而该庆幸。标题里那个问号，对前者是警报，对后者是机会。

2.3 为什么"会调框架"不再值钱

前两年招Agent开发，简历上写"熟悉LangChain、Dify、CrewAI"基本就能过初筛。现在不行了。原因很直接：这些框架把"跑起来"的门槛降到了极低，一个下午就能搭出一个能对话、能调工具的Demo。当一件事的门槛降到人人都能做，它就不再是岗位的核心竞争力。

我面过不少人，问"你用LangChain做过什么"，对方能说出一堆功能，但一问"你的Agent有没有出现过无限循环调用工具的情况，怎么发现的、怎么解决的"，就卡住了。这就是分水岭。框架会用是入场券，框架搞不定的时候你能搞定，才是岗位价值。强Agent时代，模型和框架把"能用"这件事包办了，剩下的"可靠、可控、可负担"才是要招的人来解决的。

3. 强Agent时代，哪些活被Agent自己吃了，哪些活反而更值钱

3.1 被吃掉的：样板代码、基础Prompt、简单工具封装

先说被替代的部分，认清这个才能不白费力气。现在一个强模型加上Agent能力，能自己完成的事情包括：根据自然语言描述生成工具调用的参数、自己决定先调哪个工具、把多个简单工具串起来完成一个任务、根据报错信息自己调整重试。这意味着以前需要人写的很多"胶水代码"和"流程编排"，现在模型自己就能搞定。

举个具体的。以前做一个"查天气然后建议穿什么"的Agent，你得写清楚：先调天气API，拿到结果后把温度传给建议模块，建议模块再调模型生成文案。现在你只要给Agent一个天气工具和一个"根据天气给建议"的能力描述，它自己就知道先查再建议。这种"固定流程编排"的活，确实在快速贬值。

基础Prompt也是同理。以前要花大力气研究"怎么措辞让模型听话"，现在模型的理解能力上来了，你正常说话它就能懂。那些靠"咒语"吃饭的Prompt技巧，价值在肉眼可见地下降。

3.2 更值钱的：边界设计、失败兜底、成本控制、安全约束

反过来看，哪些活变值钱了。我列四个，都是我在实际项目里反复踩过的。

第一，边界设计。Agent能自主决策，但自主决策意味着它可能做出你不想要的决定。比如一个能操作数据库的Agent，你得设计清楚：它能不能执行删除？能不能改数据？改之前要不要人工确认？这些边界不是模型能自己定的，是你要根据业务风险定的。模型越强，能碰的东西越多，边界设计越关键。

第二，失败兜底。Agent跑任务，失败是常态。工具超时、模型返回格式不对、任务中途卡死、陷入循环——这些都得有人设计兜底逻辑。我见过一个Agent因为工具返回了空结果，自己反复重试了四十多次，token烧了一大截才发现。这种问题模型自己解决不了，得靠你在架构层面加限制：最大重试次数、超时熔断、循环检测。

第三，成本控制。强Agent意味着更多的模型调用、更长的上下文、更复杂的推理链，token消耗是实打实的钱。一个设计不好的Agent，单次任务成本可能是设计良好的十倍。怎么压缩上下文、怎么缓存中间结果、怎么用小模型处理简单子任务，这些都是要人算的账。

第四，安全约束。这个在热词里被反复提到（agent安全、agent沙箱），不是没道理的。Agent能调工具、能执行代码、能访问外部资源，一旦被诱导或者自己判断失误，后果可能很严重。沙箱隔离、权限最小化、敏感操作二次确认，这些都得在架构里做死。

3.3 一个判断标准：这件事模型能不能自己学会

我总结了一个简单的判断方法，用来判断某个Agent开发技能会不会贬值：如果这件事模型通过更强的能力就能自己搞定，那它就会贬值；如果这件事需要结合你的业务、你的风险偏好、你的成本约束来做判断，那它就保值。

按这个标准，"写Prompt"会贬值，因为模型理解力上来了；"设计Agent的权限边界"会保值，因为这是业务判断，模型不知道你的业务能承受多大风险。"封装工具"会贬值，因为模型能自己生成调用逻辑；"设计失败兜底策略"会保值，因为这是工程判断，取决于你对稳定性的要求。

4. 从零到能上手：一条不绕弯的Agent开发学习路线

4.1 先搞清楚Agent到底是什么，别急着上框架

热词里"agent是什么""agent架构""ai agent主流架构"出现频率很高，说明很多人卡在第一步。我的建议是：先别碰框架，先用最原始的方式手搓一个Agent。什么叫最原始？就是你自己写一个循环：把用户输入发给模型，模型返回要调用的工具，你执行工具，把结果再发给模型，直到模型说任务完成。就这么个循环，二三十行代码。

为什么强调手搓？因为框架会把这个循环藏起来，你用了半天也不知道Agent内部到底在干嘛。一旦出问题（比如循环停不下来），你连从哪查都不知道。手搓一遍，你就理解了Agent的本质：它就是一个"模型决策 + 工具执行"的循环，加上记忆和状态管理。理解了本质，再用框架就是如虎添翼；不理解本质，用框架就是盲人摸象。

4.2 工具调用是核心，先把这块吃透

Agent和普通聊天机器人的最大区别就是它能调工具。所以工具调用（tool use / function calling）这块必须吃透。要搞清楚的问题包括：工具的描述怎么写模型才容易正确调用、参数怎么定义、模型返回的调用请求怎么解析、工具执行失败怎么把错误信息反馈给模型让它重试。

这里有个实操心得：工具的描述要写得像给新同事的交接文档。你不能只写"查询用户信息"，要写清楚"根据用户ID查询用户的基本信息，包括姓名、注册时间、会员等级；如果用户不存在返回空"。描述越清楚，模型调用越准。我见过太多人工具描述写得含糊，然后抱怨模型老是调错工具，其实问题出在描述上。

4.3 记忆和状态：Agent能不能干长活的关键

热词里"agent记忆"是个高频词。简单说，Agent的记忆分两种：短期记忆（当前任务的上下文）和长期记忆（跨任务的知识）。短期记忆好办，就是对话历史；长期记忆复杂，涉及存什么、怎么存、怎么检索。

我的经验是：别一上来就搞复杂的长期记忆。先把短期记忆做好，也就是管理好当前任务的上下文。因为上下文长度是有限的，任务一长就会超，你得设计压缩策略：哪些历史可以丢、哪些必须留、怎么摘要。这块做不好，Agent干到一半就"失忆"了。长期记忆等有明确需求了再上，比如需要Agent记住用户的偏好、记住之前处理过的类似案例。

4.4 编排：什么时候让Agent自己决定，什么时候你替它决定

"agent框架与编排"是另一个高频词。编排的核心问题是：任务的执行顺序，是Agent自己决定，还是你写死？我的建议是分场景。

如果任务步骤固定、顺序明确，比如"先查订单再退款"，那就写死流程，别让Agent自己决定，这样稳定、便宜、可预测。如果任务步骤不固定、需要根据中间结果动态调整，比如"帮我把这份资料整理成报告"，那就让Agent自己编排，但加上边界约束。

新手最容易犯的错是什么都让Agent自己决定。觉得这样才叫"智能"。实际上，能写死的就写死，把Agent的自主性用在真正需要判断的地方，这才是工程思维。一个全自主的Agent看起来很酷，但成本和稳定性往往一塌糊涂。

4.5 框架选型：LangChain、Dify、CrewAI到底怎么选

热词里直接问了"agent框架如langchain、dify、crewai等，哪个好"。这个问题没有标准答案，得看你的场景。我按自己的使用体验给个参考。

我的实际建议：如果你是要快速验证一个想法，用Dify；如果你要做深度定制、要控制每个细节，用LangChain或者干脆自己写；如果你明确要做多Agent协作，再看CrewAI。别为了用框架而用框架，很多时候自己写一个轻量循环比套框架更省心。

5. 面试和实战里真正会卡住人的几个问题

5.1 Agent陷入无限循环，你怎么发现和解决

这是Agent面试题里的经典题，也是实战里最常见的坑。Agent为什么会循环？通常是它调了工具，拿到结果后觉得没达到目标，又调一次，还是没达到，再调……或者两个工具互相调用形成死循环。

发现的手段：给Agent的执行步数设上限（比如最多20步），超了就强制停止并报警；监控单次任务的token消耗，异常高就介入；记录每一步的工具调用，事后能复盘。

解决的手段：在Prompt里明确告诉Agent"如果同一个工具连续调用两次结果相同，就停止并报告失败"；在架构层加循环检测，识别重复的工具调用模式；给工具加幂等性，避免重复调用产生副作用。我踩过的坑是：光在Prompt里约束不够，模型有时候就是不听，必须在代码层加硬限制。

5.2 工具调用失败，Agent该怎么反应

工具失败太常见了：网络超时、接口报错、返回格式不对。关键是Agent怎么处理。我的做法是分错误类型：可重试的错误（超时）让Agent重试，但限制次数；不可重试的错误（参数错误）直接把错误信息返回给模型，让它自己修正参数或者换方案；致命错误（权限不足）直接终止任务并报告。

这里有个细节：返回给模型的错误信息要"可读"。别把一堆堆栈信息丢给模型，它看不懂。要转成自然语言，比如"查询失败，原因是用户ID格式不正确，请检查后重试"。模型看到这种信息才知道怎么调整。

5.3 成本失控：一个任务烧掉几十万token是怎么回事

这个坑我踩过。一个看起来简单的任务，因为Agent反复调用工具、上下文不断累积，最后单次任务烧了几十万token。原因通常是：上下文没有及时压缩、工具返回了大量无用信息、Agent在某个子任务上反复纠结。

控制成本的手段：给上下文设上限，超了就摘要压缩；工具返回结果做裁剪，只返回模型需要的关键字段；给单次任务的token消耗设预算，超了就停。还有一个反直觉的经验：有时候用更小的模型处理简单子任务，比用大模型硬扛更划算。比如工具调用的参数生成，小模型往往就够了。

5.4 Agent安全：沙箱和权限最小化不是可选项

热词里"agent沙箱""agent安全"反复出现，说明大家开始重视了。Agent能执行代码、能访问外部资源，如果不做隔离，风险很大。基本做法：Agent执行代码必须在沙箱里，限制它能访问的文件和网络；Agent调用的工具按最小权限原则授权，能只读就别给写权限；敏感操作（删除、转账、发消息）必须二次确认。

我特别想强调一点：别相信Prompt层面的安全约束。你在Prompt里写"不要执行危险操作"，模型大部分时候会听，但总有例外。真正的安全必须在架构层做，也就是不管模型说什么，危险操作在代码层就被拦住了。这是"纵深防御"的思路。

6. 如果你现在想入行，我的几条实在建议

6.1 别把时间花在背框架API上

框架的API会变，今天学的明天可能就废弃了。把时间花在理解Agent的本质机制上：决策循环、工具调用、记忆管理、失败处理。这些是底层能力，换什么框架都用得上。我见过有人把LangChain的API背得滚瓜烂熟，但换个框架就懵了，因为他学的是"怎么用这个工具"，不是"这件事的本质是什么"。

6.2 一定要自己完整做一个项目

看一百篇教程不如自己做一个。而且要做那种"会出问题"的项目，别做Demo。什么叫会出问题？就是任务足够复杂、工具足够多、会真的遇到循环、超时、成本失控这些坑。你把这些坑踩一遍，比看任何教程都值。热词里"agent项目""用ai agent开发django"这类需求，说明大家都在找实战项目，我的建议是找一个你自己真的会用到的场景，比如自动整理资料、自动处理邮件，做出来自己用。

6.3 关注"agent harness"这个概念

热词里"agent harness""harness和agent区别"值得单独说。Harness这个词最近很火，它指的是"驾驭Agent的那套框架和约束"。Agent是那匹能跑的马，Harness是缰绳和马鞍。强Agent时代，马越来越能跑，缰绳的重要性反而更高了。所以如果你在找方向，"怎么驾驭强Agent"比"怎么让Agent更强"更有前景，因为前者是工程问题，后者是模型厂商在解决的问题。

6.4 面试准备：多准备"出问题怎么办"的答案

如果你在准备Agent开发的面试，我的建议是：少讲你做过什么功能，多讲你解决过什么问题。面试官现在不太关心你能不能搭出一个Agent，因为这是基本要求；他们关心的是Agent出问题时你能不能搞定。所以准备几个"踩坑故事"：循环怎么解决的、成本怎么压下来的、安全怎么保证的。这些故事比任何技术名词都有说服力。

回到标题那个问题。"强Agent时代，还招Agent开发？"——招，而且招的人更贵了。因为Agent越强，能做的事越多，需要有人来划定它能做什么、不能做什么、做错了怎么办、做贵了怎么省。这些活模型自己干不了，框架也包不了，只能靠懂业务、懂工程、懂风险的人来做。这个岗位的名字可能还会变，从"Agent开发"变成"Agent Engineer"或者别的什么，但它的内核——驾驭Agent而不是被Agent驾驭——会一直值钱。

我自己在这个方向做了几年，最大的体会是：别追着模型能力跑，追着"模型能力变强之后新出现的问题"跑。模型每强一分，就多出一分新的工程问题，那里才是你的机会。