最近这半年，隔三差五就有做Java后端的朋友来问我同一个问题：现在转Agent Engineer还来得及吗？Java的底子转过去是不是等于从零开始？我一般先反问一句：你到底是想追一个热门岗位，还是想成为能把大模型真正落地进业务系统的人？如果答案是后者，那Java工程师做Agent Engineer非但不是从零开始，反而有别人没有的工程优势。

这篇不是讲概念，也不是打鸡血，是一份可以照着执行的24周学习计划。每一周学什么、做到什么程度算过关、为什么要这样安排，我会尽量讲清楚。适合已经有一到三年Java后端经验的工程师，也适合Java基础扎实但还在观望的毕业生。接下来我就按“先算账、再规划、后执行”的顺序，把整个计划拆给你看。

1. 转型前先把账算清楚：Agent Engineer到底需要什么样的能力结构

1.1 Agent Engineer的真实工作内容，和Java后端工程师有什么不一样

很多Java工程师对Agent Engineer的第一印象是“写提示词的人”，这个误解挺要命的。真实的Agent Engineer岗位，更像是在做一套“会自己决策和调用工具的小型系统”，只是这个系统的“大脑”换成了大模型，而且这个大脑的输出是概率性的，不是确定性的。

一个典型的Agent工程任务大概长这样：用户提了一个模糊需求，你需要把它拆解成可执行的步骤；要为模型配置合适的角色和上下文；要设计模型可以调用的工具，比如查订单、发消息、读数据库；还要管理对话记忆，不能聊着聊着把之前的上下文挤爆；最后还要在模型出错、返回格式不对、工具调用失败的时候做兜底。这一整套东西，跟Java后端里“接口—服务—数据”的常规套路很不一样。

最大的差异在于确定性。Java后端最舒服的场景是输入输出都可预期，单元测试一跑，结果是不是符合预期一目了然。而Agent系统的输出受模型影响，同一个Prompt连问十次，可能有九次一样，一次跑偏。所以Agent Engineer必须习惯一件事：质量不是靠“一次写对”保证的，而是靠“评测、兜底、重试、观测”这套机制保证的。习惯了单元测试和事务一致性的Java工程师，刚转过来会非常难受，但这种难受本身就是转型的起点。

1.2 Java工程师手里哪些技能能迁移，哪些必须主动丢掉

Java工程师的技能包在Agent领域并不是废纸，相反，工程化能力恰恰是这个赛道最稀缺的部分。先列一下我眼里能无损迁移的硬技能：系统设计能力、API设计规范、数据结构功底、异常处理机制、日志与链路追踪意识、代码Review习惯、以及把一个问题拆成多个模块的能力。这些在任何软件系统里都通用，Agent系统也一样。

真正需要丢掉的是几个“思维惯性”。第一个是过度追求确定性和完备性，AllAgent化之后还想着穷举所有分支，结果发现模型的行为本身就很难穷举，正确的做法是给足边界条件和失败策略，然后用评测集兜底。第二个是“一切都要持久化”的执念，Agent的短期记忆通常放在上下文窗口里，只有关键业务状态才需要落库，你不需要把模型的每句话都存进数据库。第三个是“接口就是一切”的习惯，传统后端把接口契约定得死死的，而Agent的接口契约除了结构约定，还依赖自然语言描述，模型理解错了照样白搭。

为了看得更清楚，我把Java后端工程师和Agent Engineer的日常行为做了一张对照表：

这不是说Java那套没用了，而是说Agent工程师要在Java工程师的工程素养之上，长出一套“概率系统的设计感”。你不需要忘记Java，你需要学会让Java为Agent服务。

2. 24周计划的总架构：三阶段推进，每周固定产出

2.1 为什么是24周，而不是3个月或一整年

我制定计划的时候先排除了“3个月速成”的选项。一个零基础、非科班的人要在12周内把大模型原理、提示工程、Agent框架、记忆机制、工具调用、评测方法全学完，还要做出项目，现实里基本做不到，最后容易变成调包侠，只懂表面不懂原理。

24周约等于6个月，是一个比较合理的时间跨度。前8周用来建立对模型和提示的基本认知，中间8周用来吃透工程化ABC，最后8周用来做一个完整项目并准备求职。这个节奏对在职工程师尤其友好，可以利用下班和周末时间推进，不逼你裸辞。

为什么不是一整年？因为Agent这个方向的迭代速度很快，如果你花12个月才从零开始，学到后面的知识可能已经出现新的主流做法。24周的设计思路是让你尽快跑完一个“认知—工程—项目”的闭环，先进入岗位，再在实战里持续更新知识。

2.2 三个阶段与里程碑产出

我把24周分成三段时间，每段都有明确的终点目标，不看学习的时长，只看有没有完成对应的产出。下面这张表是这个计划的总体骨架：

每个里程碑都不是摆设。第8周结束的时候，你应该能用自己的代码调用大模型，而不是只会在网页里聊天；第16周结束的时候，你应该能说清楚“记忆是怎么存、怎么取、怎么切的”；第24周结束的时候，你应该能对着面试官把项目从头到尾讲透，包括踩过的坑和优化过程。

2.3 在职与脱产两种时间预算的取舍

在职工程师的时间预算我建议这样排：工作日每晚8点到10点两小时，周末每天6小时，一周下来大约16小时。24周全投入是384小时左右，足够走完计划。关键是固定节奏，宁可每天只学一小时，也不要三天打鱼两天晒网。

脱产学习的话，时间可以压缩到18周左右。每天8小时，前两周先适应“主动学习”的节奏，因为大部分程序员在连续学习状态的维持上是需要刻意训练的。即使脱产，我也不建议把24周压到12周以内，项目期至少要留够6周，否则作品集的打磨深度会明显不够。

这里有一个很重要的认知：所有说“我三个月转行成功”的经验贴，大概率是已经有相关积累的人。纯粹的零基础小白，按计划稳定推进24周，做出能讲清楚的项目，远比花三个月赶工出来一个自己都说不明白的Demo更有竞争力。

3. 第1-8周：完成从Java思维到“Token思维”的切换

3.1 先聊清楚：为什么这个阶段要刻意换语言

这个阶段最容易被Java工程师忽略的点，是“思维切换”本身。你会忍不住用写Controller、写Service的思维去想问题，比如对手写Prompt觉得不严谨。但转换期的核心任务是先理解“大模型是怎么理解文本的”，不着急把一切工程化。

关于语言选择，我在这个阶段建议尝试Python。不是Java做不到，而是模型相关的教程、示例代码和社区讨论大量集中在Python生态，用Python能减少摩擦力。Java工程师学Python的成本很低，几天就能上手，你不需要把Python学成专家，只需要能跑通脚本、看懂示例。

真正要切换的是“Token思维”。Java工程师习惯把文本当成字符串处理，但在Agent系统里，文本是要被切分成Token的。Token是模型计费和上下文长度的基本单位，一个英文单词大约1.3到1.5个Token，一个中文字符往往要占更多。同样的功能，你用多少Token描述Prompt、带多少历史上下文、让模型输出多长，直接决定成本和效果。

3.2 第1-2周：把大模型当作一门新语言来“浸泡”

第一周的安排看起来轻松，但实际上很多人做不好：每天用你手边可用的模型产品，至少写10个不同场景的Prompt。不要只做日常问答，要故意让它“干活的”，比如让它帮你写SQL、总结会议纪要、提取一段话里的关键字段。每一天都要记录同一个Prompt在不同写法下的输出差别，形成自己的对比笔记。

到第二周，做完“模型输出稳定性实验”就算过关：拿同一个设计好的Prompt连问10次，记录哪些输出稳定、哪些波动。做过这个实验，你以后设计Agent时就不会再理所当然地认为“模型应该每次都返回一样的东西”，Java里那种断言式思维自然会被冲淡。

这一阶段还有一个容易被忽略的体验：直观感受上下文窗口。把一个很长的文档分次粘贴进对话，观察模型在哪个位置开始“忘记”前面的内容，这就是Token上限的物理边界。以后设计Agent时，你会下意识地考虑窗口占用，考虑要不要做摘要和裁剪，这个直觉就是这么来的。

3.3 第3-4周：提示工程，先学四个基础模式

提示工程不是玄学，核心就是四个基础模式，先把这四样吃透就够用了。

第一是角色设定，告诉模型“你是一个擅长数据分析的Java后端工程师”，输出风格会明显变化；第二是Few-Shot示例，给一个或两个你期望的输入输出示例，模型模仿能力会大幅提升；第三是思维链，让模型先列出推理步骤再给结论，复杂任务的准确率会更高；第四是格式约束，明确要求“只输出JSON”或“按下面的模板输出”，配合JSON Schema能做基本的结构化约束。

每周任务很明确：第一周练前两个模式，第二周练后两个模式。练完后做一个综合实验，拿同一个业务场景把四个模式叠加起来，比较输出质量。这个阶段不需要背模板，重点是理解不同模式在什么场景下起作用。

顺便提醒一个坑：提示词会被用户输入“劫持”。当你的Agent允许用户自由输入的时候，要测试类似“忽略以上所有指令”的输入，看看会不会绕开角色设定。这是Java工程师天然的盲区，因为你习惯了参数校验，却没习惯“文本输入也能攻击逻辑”。

3.4 第5-6周：用代码直接调用大模型API，跑通第一个程序

第5周开始，进入写代码阶段。直接用你最顺手的语言发HTTP请求，调用模型接口。建议不要急着上任何Agent框架，先用原始请求搞清楚三件事：API的请求格式长什么样；temperature、max_tokens、top_p这些参数分别影响什么；返回结果里的content字段和Token计数字段怎么读。

你可以用Java写或者用Python写，网上随手能搜到对应的调用示例。我建议你用Java写一次，因为这是你的主场，能帮你确认“我的老本行也能干这件事”，降低陌生感。然后第二遍用Python写，体验一下两种写法在生态上的差异。

这里有一个明确的标准：第6周结束前，你应该能写一个独立的类，输入是一段业务描述，输出是结构化的JSON，并且能处理模型偶尔返回空值或无法解析的情况。这一周解决的核心问题是“熟悉模型调用”，而不是“做得漂亮”。

3.5 第7-8周：不依赖框架，手写一个Mini版的ReAct循环

第7周和第8周是整个基础期最难也最关键的部分：不用框架，手写一个最简的ReAct循环。

ReAct的意思很简单，让模型在一个循环里走“思考—行动—观察—再思考”的路径。比如你的Agent接了一个需求：“查一下某地区的天气然后告诉我带什么衣服合适”，模型先思考要查什么，然后调用天气查询工具，观察到结果后继续思考，最后给出穿衣建议。这个循环就是Agent所有自主行为的地基。

你不需要写得很复杂，就写一个while循环，定一个合理的最大步数，比如5步；再用强约束Prompt让模型输出JSON格式，JSON里有thought和action两个字段；根据action调用对应的工具函数，把工具返回的内容拼进下一轮对话。第8周的交付标准是：它能连续完成至少两次工具调用，并且能把最终答案组织好返回给用户。

一定要自己手写一遍这个循环。你会在里面亲眼看到模型“选错工具”“输出格式不对”“陷入死循环”等各种问题，这些踩坑经验比任何框架文档都值钱。写出过这个Mini Agent之后，你对后面所有框架的理解都会快很多。

4. 第9-16周：核心工程化——编排、记忆、工具调用、评测

4.1 从手写循环到编排框架：框架解决什么、带来什么麻烦

当你亲身体会过手写ReAct的繁琐，你自然想找工具把重复劳动封装起来。这就是主流编排框架存在的意义，比如LangChain这类库，把模型调用、工具注册、对话历史管理、循环控制都做成了现成组件，让你不再重复造轮子。

但也要清醒看到框架的另一面。框架抽象了一层之后，你把控制权也交了出去，出了问题排查起来，需要先理解框架自身的调度逻辑。用Java举例子：你用Spring Boot的时候，如果Bean装配出了诡异问题，半天找不到原因，这时候最头疼的不是业务代码，而是框架。Agent编排框架也一样，模型输出不符合预期时，排查链路更长，你往往需要打开“详细日志模式”才能看清单个循环步骤里发生了什么。

第9周到第12周，我的建议是选择主流编排框架练手，但目标不是“把所有功能都用一遍”，而是看懂核心的AgentExecutor或者类似调度组件的执行过程。先把一个模型调用流程跑通，再往里加工具，一步一步来。

这个阶段你会接触到大量的抽象概念，比如Chain、Agent、Tool、Memory。每个概念学的时候都问自己一句：如果我自己手写，这部分代码会放在哪里？这样你再回到框架里看源码，才能看懂它帮你封装了什么。

4.2 记忆系统：会话记忆、向量检索与状态落库

Agent工程里，记忆是绕不开的工程难点。它不只是“把聊天记录存下来”那么简单，分为短时记忆和长时记忆，前者是当前对话的上下文，后者是跨会话可检索的知识。

短时记忆的处理核心是裁剪和摘要。当对话历史超过上下文窗口的限制，要么把旧消息丢弃，要么让模型生成一段摘要，把摘要保留在上下文里，旧内容移出。我第一次做这个功能的时候，第一版粗暴地按Token数截断，结果用户前五分钟说的偏好信息全丢了，后来改成“关键信息摘要+最新消息保留”的混合结构，效果才稳下来。

长时记忆通常需要向量检索。先把知识文档切成段落，对每个段落生成向量表示，也就是Embedding，用户提问时，把问题也转成向量，然后用余弦相似度在库里找出最相关的几个片段，再把片段放进上下文。这个过程就是后来大家都熟知的RAG，可在第13-14周，你只需要把链路跑通，暂时不需要做太多调优。

至于状态落库，Java工程师的优势就出来了。Agent执行到一半失败或者中断，你总得把流程状态存下来。用Redis存暂态，用MySQL存业务结果，这套你是熟悉的。区别是传统后端状态机跳转是严格定义好的，而Agent的选择由模型决定，你的状态表要为“意外路径”留好空间，别设计得太死。

4.3 工具调用设计：把Java API包装成Agent的“手”

Agent能干活，靠的是工具调用。工具的边界就是Agent能力的边界。Java工程师在这个环节的工程能力特别有价值。

现代模型基本都支持结构化函数调用，你给模型提供一段工具描述，模型根据用户需求决定要不要调用，并且按约定好的结构化格式返回函数名和参数。举一个最简单的天气工具定义，基本的JSON Schema长这样：

{ "name": "query_weather", "description": "查询指定城市的当前天气", "parameters": { "type": "object", "properties": { "city": { "type": "string", "description": "城市名称，如杭州" } }, "required": ["city"] } }

模型收到用户消息后，可能返回一个调用意图，比如“query_weather，参数{'city':'杭州'}”，你的程序再去真实的天气服务里查询，把结果塞回给模型。这个“模型决策、程序执行”的协作模式，就是Agent工具调用的本质。

工具调用方案的工程细节比Schema本身复杂得多。每个工具要有清晰的失败返回机制，比如查订单接口超时了，工具要返回“查询失败，原因：超时”，让模型决定是重试还是换一种方式；工具执行要有超时控制和并发限制，避免被外部接口拖垮；工具返回的内容别设计得太长，模型拿到一大堆无关字段，反而会干扰判断。

4.4 Agent评测：Java的单元测试在这里不够用

第15-16周，必须把评测方法提上日程。Java工程师习惯写单元测试，断言输入输出。但Agent的输出是概率性的，你不能简单断言“返回的JSON里必须有字段X”，因为格式可能对，语义却错了；也不能断言“模型推荐的产品一定是A”，因为它可能给出完全合理但不同的建议。

Agent评测的基本思路是建一套评测集。准备几十条典型的用户问题，记录每条问题对应的期望结果类别；然后让同一个Agent配置跑一遍，人工或者用更强的模型去判断输出是否达标；统计通过率，作为这个版本的核心指标。这样你在优化Prompt、调整工具描述、修改记忆策略时，就有了可以依赖的回归基准，而不是“感觉这次效果好一点”。

这个阶段的里程碑，是对着一个垂直场景跑通“工具调用+短时记忆+长时检索”的完整流程，并且用评测集记录基线数据。你在Java领域养成的测试习惯，到Agent领域不是白费的，换成评测集的思路，反而会成为你区别于纯Prompt选手的明显优势。

5. 第17-20周：做一个端到端Agent项目，把工程素养全部倒进去

5.1 选题：选“解决具体问题的工具”，不要选“聊天机器人”

项目期最忌讳的选题就是“做一个聊天机器人”。聊天机器人看起来好做，实际很难做出彩，而且很容易做得像个玩具。我更推荐做“一个解决具体业务问题的工具型Agent”，比如：企业内部知识库问答助手、技术方案写作助手、订单售后处理Agent、合同条款审查助手。

工具型Agent最大的好处是边界清楚：用户需求明确、工具调用固定、评价标准相对客观。比如订单售后处理Agent，它能查订单、能判断退款条件、能调用退款接口，好不好用，用户很快就能感受出来。面试官听完也会觉得“这个东西真的可以上线用”，而不是又一个Demo。

选题之前先想清楚三个问题：这个Agent给谁用？它解决什么问题？用户怎么判断它“干得好”？这三个问题说不清楚，项目大概率做到一半就迷茫。我在辅导的时候见过不少Java工程师，选题时追求高大上，最后卡在数据和工具不足上面，项目越做越虚。宁可选小场景，做深，也不要做大而全的壳子。

5.2 一条完整的Agent处理链路应该怎么拆

项目期最忌从头到尾一把梭。一开始就先把全链路拆成几个模块，再逐个实现。一个典型的工具型Agent至少有六个模块：输入层，负责接收用户请求；意图理解层，让模型判断用户想干什么；工具层，封装外部API；上下文管理层，组织历史消息和检索结果；决策循环层，控制Agent反复思考并调用工具；输出层，让模型给出最终结果。

这六个模块放在代码里，对应的就是项目里的几个包或者目录，Java工程师做这种东西非常顺手，因为你天生习惯模块化和分层。写完每个模块，最好都单独验证一遍：输入层能不能正确处理异常？工具层在外部接口挂掉的时候会不会把错误信息原样丢给模型？输出层能不能保证格式可解析？

我特别想强调链路日志的重要性。Agent系统里，每一条用户消息会触发一次多轮循环，中间包括模型调用、工具调用、结果回溯，任何一个环节出问题，没有日志排查起来会非常痛苦。一定要把每次模型输入和输出、每次工具调用参数和返回结果都记录下来，这样线上出了问题你才能复现和定位。

5.3 成本优化：从“全部塞进去”到“先检索后生成”

项目做到第18-19周，你会发现一个躲不开的问题：Token成本。把一大段文档或者一堆历史对话全塞给模型，效果好但账单吓人，而且响应慢，因为模型处理长输入也需要更多时间。

一个常见优化思路是“先检索后生成”，跟RAG的思路一致。用户提问后，先在知识库里检索出最相关的几段内容，只把这几段塞进上下文，让模型基于这些片段生成答案。我见过不少转型者做文档问答时，一开始把100页文档全塞进上下文，一次请求消耗上万个Token；改成检索Top5相关片段之后，一次请求可能只需要一两千Token，成本差距基本是一个数量级。

项目里还可以做几件基础的成本控制事：设置模型返回的最大Token上限，防止模型啰嗦；对超长历史做摘要压缩；把不常用的工具从工具清单里拿掉，减少模型“思考”时的选择负担。这些优化不会让你惊艳，但会让项目的工程完成度看起来高一个段位。

5.4 上线前的工程检查清单

Java工程师的工程自觉，在项目尾声该拿出来做一次完整的清单检查。下面这些项我每次带项目都列在文档里，逐项打勾：

• 有没有基本的错误兜底？模型调用超时、工具调用失败、输出解析失败，都有对应的重试或提示逻辑吗？
• 有没有可观测性？日志里能不能看到每一次用户请求的完整循环？异常有没有告警？
• 有没有输入校验？用户输入会不会绕过系统提示，有没有做指令注入的基础防御？
• 有没有配置外置？模型名称、API密钥、温度参数，是不是都放在配置里而不是硬编码？
• 有没有成本估算？每次请求的平均Token数大致是多少，有没有做过上限控制？
• 有没有一个可以演示的入口？别人拿到项目，能不能用最短时间跑起来？

这份清单越细，你面试的时候能讲出来的素材就越扎实。很多转型者项目做得炫，架构也画得漂亮，但一问到“线上如果模型返回空怎么办”就卡住，恰恰是因为工程细节没跟上。

6. 第21-24周：作品集打磨与面试准备的最后一公里

6.1 作品集四件套：每个部分都要能讲出“为什么”

很多Agent转型者的作品集只有一页项目说明加一个GitHub链接，这不够。作品集至少要包含四样东西：项目README、架构说明图、评测数据、可在线体验的Demo地址。

README一定要写得像个真实项目，安装步骤、环境变量、启动命令、示例调用，一个都不能少。面试官很可能没空深入看代码，但一定会看README是不是专业。架构说明图不用画得多精美，但要能讲清楚用户请求从输入到最终输出的完整流转，工具和记忆模块画在哪个位置，为什么这样设计。评测数据是很多转行者的加分项，把你自己建的测试集规模、测试类型、通过率和优化前后的对比都写出来，比写一百句“效果好”更有说服力。

Demo地址是用人单位最快建立信任的方式。如果条件允许，部署到免费服务上；部署不是一个技术难题，但对很多纯做算法或纯做提示工程的人来说是一道门槛，你有这个工程能力，就值得展示。

6.2 面试高频问题：概率输出怎么兜底

面试阶段，以下是高频问题，我建议每个都准备一遍完整的故事，不要背答案。

第一题：“模型返回的JSON结构不对，你怎么处理？”回答思路：解析前先做校验；解析失败重试一次；还是不行，把原始输出返回给用户看，至少不让流程直接崩溃。如果你的项目里有“让模型自我修正”的机制，讲出来会加分。

第二题：“工具调用失败，Agent陷入死循环怎么办？”回答思路：设置最大循环步数；超限后主动终止并告知用户；把工具失败的上下文回填给模型，让它换一种策略。你手写过ReAct循环，这个问题会答得很顺。

第三题：“你怎么压Token成本？”回答思路：检索而非全文塞入；长历史摘要化；限制输出长度；评测集上对比优化前后的成本数据。成本优化这块，面试官看重的是你有没有成本意识，以及有没有真实数据支撑。

第四题：“如何评估Agent做得好不好？”回答思路：建评测集、设定通过标准、记录版本迭代、人工抽样检查。你不需要假装建了很复杂的评测体系，只要思路对，并且有自己的测试集，就能压住这个问题。

第五题：“你的项目上线了吗？用户反馈是什么？”这题是分水岭。项目真的上线过的人，讲出来的语气跟只做Demo的人完全不一样。真实用户会提出各种出乎你意料的输入，逼你处理；这些故事恰好就是你工程能力的证据。

6.3 岗位选择：比起研究型Agent，更建议先进业务Agent团队

投递岗位的时候，要注意区分两类Agent工程师岗位。一类偏研究型，岗位描述里大量出现“最新论文复现”“多Agent理论框架”“模型微调”这类词，这类岗位往往要求扎实的算法背景，Java工程师硬投容易吃亏。另一类偏业务落地型，岗位描述里会出现“业务场景”“流程自动化”“系统稳定性”“智能客服”这类词，这一类对工程化能力要求很高，Java工程师的优势很明显。

我的建议是优先瞄准业务落地型Agent团队，尤其是需要把大模型接进现有业务系统的岗位。你在Java后端积累的系统设计、接口开发、链路追踪、线上排查经验，在这种岗位里会被直接复用。先进入业务场景，把垂直经验做深，再往研究型方向走，路径会更顺。

准备简历时，不要写“熟悉提示工程”这种人人都会写的套话，要写“独立完成一个订单售后Agent，支持工具调用与记忆管理，线上平均Token消耗较初版下降70%”这种有数据、有边界、有场景的描述。Java背景不要藏着，把它作为你的差异化标签，放在简历靠前的位置。

7. 转型路上最常见的五个坑，以及最后一个给Java工程师的补充建议

7.1 坑一：第一周就去啃框架源码

我看到太多人把Agent学习的第一步放在“啃LangChain源码”上，结果源码看了三遍，发现自己连模型API都还没亲自调过，越看越虚。框架是帮你把这些底层机制封装好的工具，前提是你得先理解底层机制。没有手写过ReAct的人直接上框架，遇到问题只能瞎改Prompt，根本不知道问题出在哪一层。前8周老老实实打基础，后面所有知识都会学得更快。

7.2 坑二：把Agent做成“什么都行，但什么都不精”的万金油

转型者第一个项目最喜欢做的是通用问答助手，什么问题都能聊，结果每个问题都聊不深。面试官问“你的Agent在什么场景下表现最好？”你答不上来。正确的做法是收窄场景，把一个业务问题做到一定深度，比如只做“合同关键条款提取”，而不是“合同助手”。边界清楚，用户才答得出来，评测指标也才立得住。

7.3 坑三：从不看Token账单，模型报价一翻就懵

有个朋友做Agent Demo，跑通之后非常兴奋，直到后端同学告诉他，一次完整流程要花好几块钱，他的第一反应是：这也太贵了。这个问题本质上是没有成本直觉。学习阶段就要养成看Token计数的习惯，每次请求之后记录Token用量，时间长了，你对“这个功能大概多少钱”就会有感觉。项目阶段的成本优化能力，不会凭空出现，就是这些日常习惯积累出来的。

7.4 坑四：靠感觉改Prompt，不建评测集

“我再加一句提示词，应该会好一点”这句话我听得太多了。没有评测集的时候，改Prompt全凭感觉，改完觉得好，第二天又觉得不好，完全依赖临场印象。有评测集之后，每次改动用同一组问题去跑一遍，通过率上升就是变好，通过了就是通过。这种回归思维对程序员来说很容易理解，但很多人就是忍不住偷懒。

7.5 坑五：项目只留在本地，没有真实用户反馈

最后一个坑，也是最常见的坑：Demo做完了，部署也部署了，但从来没让别人用过。没有真实用户输入，你的Agent就只接受过你自己设计的测试问题，覆盖度非常有限。哪怕只发给三五个同事试用，你也会收到类似“你能不能别每次回答都那么啰嗦”这种意料之外的反馈。把这些反馈消化掉，你的项目才真正从Demo变成作品。作品集这个环节，上线体验和真实反馈，是最难伪造的信任状。

最后再给Java工程师加一个补充建议：正式动手之前，把“Java工程师转Agent Engineer”这个目标改成“会Java工程化能力的Agent Engineer”。前者让你觉得自己是在补一块新知识，后者让你意识到你是带着一套成熟工程体系进入新领域的。你把JVM上的排查经验、数据库设计的严谨、异常处理的习惯，全部带进Agent系统的那一天，转型才算真正完成。24周计划只是路线图，决定你在终点能走多远的，永远是你在路上积累的工程细节。