01核心判断CORE JUDGMENT
很多在校生和转方向的工程师把"没有实验室、没有算力"当成入门 Agent 方向的硬障碍。这个前提放在模型训练上成立，放在 Agent 工程上不成立：Agent 项目的模型能力来自公开 API，重点从来不是训练模型，而是把模型能力接进一个真实系统，并让它稳定、可控、可复现地完成任务。
所以真正的门槛是另外两样东西：闭环和证据。闭环指系统从输入到产出的完整路径都被做出来，而不是停在"能对话"；证据指这条路径留下了可以被别人追问的材料——README、运行轨迹、产物、测试和边界声明。
这两样东西恰好都不需要钱，只需要纪律。这也是学生项目最公平的地方：算力买不起，纪律人人买得起。
02四层能力栈FOUR LAYERS
Agent 工程的能力可以拆成四层。第一层是基础工程：Python、Git、Linux 命令行、HTTP 与 JSON、一个能写接口的后端框架、数据库基础。第二层是模型调用：Prompt、结构化输出、工具调用（Function / Tool Calling）、异常重试、流式输出、成本与日志。第三层是 Agent 能力：任务拆解、工具编排、状态管理、失败重试、文件与代码执行。第四层是工程化：任务队列、异步执行、评测、产物保存、权限边界、可观测性、部署。
这个栈的正确用法不是横着铺——把每一层学"完"再进下一层——而是竖着串：选一个小任务，让它从第一层贯穿到第四层。一条跑通的竖线，胜过四层各自的一堆概念。
层与层之间也有诚实的依赖关系：第三层的"工具调用失败要重试"，靠的是第一层"看得懂报错、查得了日志"的基本功。跳过基础直接堆 Agent 框架，问题不会消失，只会在更难调试的位置爆发。
03不要只做聊天框BEYOND THE CHATBOX
只做一个聊天框，证明的是"会调 API"；做出一个闭环，证明的是"会做系统"。两者在演示里看起来可能差不多，在追问下立刻分开：聊天框答不出"失败了怎么办、日志在哪、结果存在哪里"。
一个值得做的最小闭环长这样：用户提交任务 → 系统拆解任务 → 调用工具执行 → 记录过程日志 → 失败时重试或升级 → 保存产物 → 展示结果。每一个箭头都是一小块真实的工程，也都是面试里可以被单独追问的点。
这个结构和成熟的长任务生成系统是同构的——任务状态、失败处理、产物保存，在任何规模的系统里都是同一套问题（见 N-009）。学生项目做小没有关系，做残才有关系：规模可以缩，环节不能省。
04项目驱动，JD 倒推PROJECT-DRIVEN
这个方向最常见的失败方式不是学不会，而是一直在"准备学"：RAG、MCP、多 Agent、各种框架的概念看了一遍又一遍，却始终没有一个能跑起来、能展示、能解释设计取舍的项目。概念焦虑的解药只有一个：让一个真实任务先跑通。
学习的优先级可以从目标岗位倒推。找几份想投的 JD，看它们反复出现什么——如果是 RAG、工具调用、后端工程，那就先补这些；JD 里没有的，再热也可以先放。这比任何通用路线图都更贴近你要通过的那场考试。
渠道上，官方文档和优秀开源项目的代码，长期回报高于视频课：前者训练"自己查、自己验证"的能力，这个能力本身就是岗位要考的内容之一。视频用来建立概念可以，用来替代动手不行。
05适合的项目形态PROJECT SHAPES
适合在没有实验室的条件下做的项目，共同点是：有真实输入、有可验证的输出、有失败的可能。比如邮件分类与草稿生成、文档知识库问答、代码任务评测、表格数据处理、浏览器自动化、客服对话质检。它们都不需要训练模型，都需要认真的工程。
反过来，两类项目要警惕。一类是纯展示型：界面很好看，但没有失败处理，没有日志，换一个输入就露馅。另一类是纯概念型：接了五个框架、三个模型，却说不清楚这个系统到底替谁解决了什么问题。
选题时可以用一个简单测试：向自己提问"这个系统失败的时候会发生什么"。如果这个问题有具体答案——重试、报警、留痕、人工接管——这个选题就有工程含量；如果答不出，说明它还只是一个演示的想法。
06学生项目的证据链EVIDENCE FOR STUDENTS
学生项目和商业项目在证据链上的要求是一样的，只是规模更小：README 说清声称和启动方式，trace 留下最近一次真实运行，artifact 能独立打开，测试覆盖核心路径，边界声明写明没做什么。面试官的逐层追问，本质上就是一次证据链体检（见 N-005）。
其中性价比最高的一件事是保留失败样例。多数候选人只展示成功案例，能拿出"这里失败过、日志是这样、后来这样修"的人极少——而这恰恰是面试官判断你是否真的做过系统的依据。失败样例是学生项目最便宜的差异点。
简历上的写法也随之改变：不写"熟悉大模型、了解 Agent"，写你做了什么系统、解决了什么问题、留下了什么可验证的结果。前者是形容词，后者是证据；筛简历的人只会为证据停留。
07背景不是劣势，定位才是POSITIONING
非科班背景转 AI 方向，最大的错误是伪装成算法候选人，用自己最弱的一面去比别人最强的一面。正确的做法是重新定位：一个 Agent 系统里，模型只占一小部分，其余是 API 网关、任务队列、权限控制、容器隔离、日志监控、服务部署——这些都是基础设施工程。
以网络工程背景为例：网络、Linux、部署、服务治理的底子，接到 Agent 工程上就是现成的优势。"构建支持任务调度、工具调用、失败重试和日志追踪的 Agent 服务"，比"学习过大模型"有竞争力得多——前者是你已有能力的自然延伸，后者是所有人都会写的一句话。
这条判断可以推广：转方向不是清空重来，而是找到新领域里恰好需要你旧能力的那个位置。Agent 工程需要的位置足够多，多到几乎每一种工程背景都有对应的接口。
08无实验室 Agent 项目检查清单CHECKLIST
- 是否用公开 API 获得模型能力，把精力留给系统本身？
- 是否有从输入到产物的完整闭环，而不是一个聊天框？
- 失败路径是否被设计过：重试、报警、留痕、人工接管？
- 是否有一条竖线贯穿四层能力栈，而不是横着铺概念？
- 选题是否有真实输入、可验证输出和失败的可能？
- README、trace、artifact、测试、边界声明是否齐了？
- 失败样例和修复过程是否被保留下来？
- 简历上写的是系统和结果，还是"熟悉"和"了解"？