Agent 工程师学习路线：从 LLM 基础到后端工程与实战项目

Posted on Edited on In Word count in article: 6.7k Reading time ≈ 24 mins.
整理 Chasen《「万字总结」- 我偷来了一份成为 Agent 工程师的学习线路》：按 LLM 基础、Prompt Engineering、RAG、Agent 应用、后端工程和实战项目六个阶段，梳理知识点、项目要求、验收标准与学习文档。

想做 AI 应用开发，常见的困惑不是“资料太少”，而是不知道该按什么顺序学、学到什么程度才算会。这篇长文给出的答案是：每个阶段配一个能交付的项目，再用明确的验收标准检验自己。

Chasen（@chasen_liao）在 X 长文《「万字总结」- 我偷来了一份成为 Agent 工程师的学习线路》中，整理了一份面试后由面试官提供的《Agent 工程师入门指南》，并补充了自己的学习心得。本文按原文脉络做结构化总结，保留每个阶段的项目要求和验收标准，并把原文给出的学习文档附在对应知识点下。

主线：LLM 基础（API Playground）→ Prompt Engineering（贯穿所有项目）→ RAG（RAG + Tool Calling Agent）→ Agent 应用（简化 Coding Agent）→ 后端工程（AI 服务后端系统）→ 开源项目实战。

原文发布于 2026 年 10 月 11 日。知识点和项目要求来自那份入门指南；入门取舍、开源项目推荐和起步建议是作者本人的补充。本文的表格和归纳是对原文的整理，没有逐项验证每个外链的当前内容。

0. 这条路线讨论的是什么

作者的背景是：面试一家 AI + web3 公司未通过，反馈是“AI 方面问题不大，工程能力和计算机基础还不够”，之后又去补了 MySQL、计算机网络等基础。所以这份路线不只讲 Agent，也用很大篇幅讲后端。

路线限定在 AI 应用开发：不训练模型，而是围绕已有模型，把检索、工具、上下文和业务系统连起来，让 Agent 完成具体任务。

作者建议带着一个问题读每一部分：学完之后我能做出什么，又怎样证明自己确实学会了？ 这也是整份材料最有价值的地方——知识点、学习文档、项目要求和验收标准放在一起。

1. LLM 基础：先看懂一次模型调用

这是后面所有内容的底座。目标不是研究训练，而是弄清楚一次调用里哪些因素会影响系统行为。

1.1 模型如何生成内容

需要建立的基本认识：Transformer、预训练、指令微调、RLHF / RLAIF；自回归生成（Next Token Prediction，根据已有内容预测下一个 Token）；上下文学习（In-Context Learning，模型如何利用当前给出的指令、资料和示例）。

  • 学习文档：图解 Transformer

1.2 Token 与上下文窗口

  • 理解 Tokenization，分清输入 Token、输出 Token、Context Window、最大输入 / 输出长度；Token 和汉字、单词之间没有固定换算。
  • System Prompt、历史消息、工具说明、检索资料都占输入空间，还要给输出留余量。
  • 请求超限时要有明确策略：裁剪历史、压缩资料还是调整输入。
  • 上下文长不等于每条信息都被同等利用，原文特别点名 Lost in the Middle：关键信息放在长上下文中间时容易被忽略。后面学裁剪、摘要、压缩时，要知道自己在解决这个问题。
  • 学习文档：Token 与计数

1.3 采样参数

原文列出 Temperature、Top-p、Top-k、Frequency Penalty、Presence Penalty、Seed、Stop Sequences。学习重点是它们如何影响采样范围、重复倾向和输出终止，以及确定性与创造性之间的取舍。

两个边界：这份清单不是所有 API 都支持的统一接口；低 Temperature 也不保证答案正确，Seed 不等于“结果完全一致”的承诺。

  • 学习文档：vLLM SamplingParams（v0.6.4），实际使用时以所用模型的接口说明为准

1.4 模型类型与 API 协议

模型类型要分开看：Chat Model、Reasoning Model、多模态模型、Embedding Model（把内容表示成向量）、Rerank Model（给候选内容重新排序）、语音与实时模型，各自在应用里处于不同位置。

接口层面要理解 Chat Completions、Responses、Messages 三种抽象：

  • 看懂 message / role / content，以及 system、user、assistant、tool 各自承载什么；
  • 认得 model、messages / input、instructions / system prompt、tools、tool_choice、response_format、stream、usage、finish_reason 等字段，换一种协议也能找到对应信息。

学习文档：

  • Chat Completions、Responses、Responses Create
  • Claude Messages、Claude Stop Reasons

1.5 流式输出

打字机效果只是表面。完整链路包括 SSE、event stream、delta 增量文本，以及工具参数分段到达、连接中断、用户取消、响应未完成等情况。

  • 学习文档：OpenAI 流式响应、Claude Streaming、Responses Streaming 事件参考

1.6 结构化输出

JSON Mode 解决“是不是合法 JSON”；按 Schema 约束的 Structured Outputs 进一步限定字段、类型和结构。但结构对了不代表内容对，应用仍要处理拒绝、截断、校验失败，以及修复或重试。

  • 学习文档：JSON Schema 基础、Structured Outputs、Structured Outputs 介绍文章

1.7 工具调用

核心是区分“模型请求调用工具”和“系统真正执行工具”：

开发者提供工具描述 + 参数 Schema
    ↓
模型生成调用请求
    ↓
业务系统校验参数并执行
    ↓
结果返回给模型 → 模型继续回答，或请求下一次调用

tool_call_id、参数、tool result 和错误返回必须一一对应，否则模型拿不到结果或把结果关联错；并行工具调用也要分别返回结果。

  • 学习文档：OpenAI Function Calling、Claude Tool Use

1.8 多轮会话

独立的生成请求通常不会自动继承应用里的聊天记录。会话连续性由系统负责：自己维护历史，或使用供应商的状态管理接口，无论哪种都要清楚实际传入了什么。涉及历史消息、摘要、短期 / 长期记忆、上下文压缩和会话状态。

  • 学习文档：会话状态、Claude 对话中途的系统消息与工具变更

1.9 Embedding

文本向量、语义相似度、向量维度、归一化、Cosine / Dot Product / L2、模型选型、批量生成与向量缓存。这是后面 RAG 的基础。

  • 学习文档：Embedding

阶段项目：大模型 API Playground

项目要求 验收标准
一个小应用，支持普通对话、流式响应、结构化输出、工具调用、Embedding 生成与相似度计算 能讲清一次请求到响应的完整过程
每次调用记录模型、输入、输出、Token 用量和耗时 能解释 message、role、tool call、tool result、stream、usage 的含义
对比至少两个模型或两个供应商的 API 差异 能演示一次完整工具调用，以及结构化输出失败后的处理
仓库包含 README、运行说明、示例请求和测试用例 别人能照着文档跑起来

作者的评价是：这一步做扎实，后面会少很多“框架能跑，但不知道里面发生了什么”的困惑。

2. Prompt Engineering：把任务、材料和验收要求说清楚

这一阶段没有独立项目，而是贯穿后面所有项目——Prompt 的效果只能放在具体任务里验证。

2.1 基本组成

Role / System Prompt、Instruction、Context、Input、Output Format、Constraints。以知识库助手为例，要写清：回答依据哪些资料、资料不足怎么办、引用如何呈现、哪些请求超出职责。

  • 学习文档：OpenAI Prompt Engineering、Claude 提示词指南

2.2 示例与任务组织方式

方法 关注点 学习文档
Zero-shot / Few-shot 用少量贴近真实任务的示例表达分类标准、格式或风格；模型反复误解某个边界时，补例子比堆形容词更好验证 Few-shot
CoT 拆解问题、逐步推理、先分析后回答，用于复杂推理与规划，需用测试确认是否有帮助 CoT
ReAct Reasoning + Acting：决定是否调用工具、观察结果、根据反馈推进，后面可与 Agent Loop 对照 ReAct
Self-Critique / Reflexion 对已有结果检查、反思和修正，可用于代码生成、报告复核 Reflexion

两条使用边界：

  • 对推理模型强行加“请一步一步思考”未必有收益，见 推理模型提示建议。更稳妥的做法是给清楚的目标、必要材料和验收条件，再用测试决定要不要加示例或拆解流程。
  • 模型自查之后仍需外部依据：测试结果、引用证据、字段校验或人工复核，不能因为它说“检查完成”就认定正确。

实践要求（适用于每个项目）

  • 每个项目至少记录 3 组 Prompt 修改前后的效果对比，尽量用同一组输入，记录改善了什么、是否引入新的失败，再决定是否保留。
  • README 说明：用了哪些结构、System Prompt 和约束为什么这样设、是否用 Few-shot、怎样控制格式，以及如何处理不确定回答、越界回答和格式错误。

3. RAG：把资料变成可检索、可引用的证据

需要私有文档、持续更新资料或领域知识时就会用到 RAG：把外部资料检索出来放进本轮上下文，为回答提供依据。建议按完整链路学：

文档加载与解析 → 分块 → Embedding → 索引 → 召回 → 重排
    → 上下文组织 → 回答生成 → 引用溯源 → 效果评估

3.1 解析与分块

  • 解析范围：PDF、Word、HTML、Markdown、代码、表格、图片 OCR、多模态文档，不能一律同样处理。表格行列错位、章节标题丢失、代码被切断，都会让后面检索到也用不上。
  • 分块方式：固定长度、递归、语义、按 Markdown / Code 结构、父子分块、滑动窗口与 overlap。用自己的资料实测：块太小丢上下文，块太大混入噪声，重叠部分带来额外成本。
  • 学习文档：LlamaIndex 文档加载、Pinecone 分块策略、LlamaIndex 节点解析

3.2 检索：语义、关键词与元数据

  • 向量检索：结合 Embedding 选型、维度、归一化和距离度量，掌握 Top-K、相似度阈值和向量缓存。
  • 向量库：原文列出 FAISS、Milvus、Qdrant、Weaviate、Chroma、Pinecone、pgvector、Redis Stack，以及 FLAT、IVF、HNSW、PQ 等索引。入门先选一种，跑通写入、更新、检索、删除，再按数据量、延迟和召回效果学取舍。
  • 混合检索：产品型号、报错码、专有名词等问题需要 BM25 等关键词检索，再学 RRF 融合和多查询改写。
  • 元数据与权限：标题、章节、来源、时间戳、版本、用户权限都要抽取管理。权限过滤必须由系统执行，并权衡“先过滤后检索”和“先检索后过滤”，保证未授权资料不会进入上下文或返回给用户。
  • Rerank：召回后再判断哪些片段更贴近问题，理解 Bi-Encoder 与 Cross-Encoder、粗排 + 精排的二阶段检索；可对比 bge-reranker、Cohere Rerank、Jina Rerank。

学习文档：Embedding、向量数据库、Hybrid Search、LlamaIndex Metadata Extraction、Cohere Reranking

3.3 生成：让引用和拒答都有依据

  • 决定放哪些片段、如何排序、是否压缩，并把引用对应回原始位置；留意 Lost in the Middle。
  • 明确要求回答依据检索内容；资料没覆盖时说明证据不足。检索结果也可能过时、冲突或不相关。
  • RAG 仍可能答错，要分别检查检索效果和生成效果。
  • 学习文档：RAG 完整流程

3.4 评估与进阶

  • 指标：检索准确率、召回率、答案忠实度、上下文相关性、幻觉率，并用测试集持续验证。学习文档：Ragas
  • 进阶：Query Rewrite、HyDE、Self-Query、Agentic RAG、GraphRAG，对应复杂查询、跨文档推理、多轮检索。原则是先在基础版本里找到具体失败，再决定是否引入。GraphRAG 可读 官方项目。

阶段项目：RAG + Tool Calling Agent

项目要求 验收标准
支持上传或导入 Markdown / PDF，完成切分、Embedding 和向量检索 能讲清 RAG 完整链路
回答能引用来源，资料不足时拒答 提供检索结果、回答质量和失败案例分析
至少 2 个工具（如网页搜索、计算器、文件查询、时间查询），由 Agent 决定是否检索、是否调用工具 能说明模型工具调用与普通函数调用的区别
记录每一步的 reasoning 摘要、工具请求、实际返回和最终结果 过程可复盘（摘要用于解释进展，不等于模型内部推理的完整记录）
不少于 20 条测试问题 作者建议覆盖：直接可查、跨文档、需要工具计算、资料里没有答案、工具失败

4. Agent 应用：先理解循环，再补状态、上下文与边界

到这里可以把前面串起来：Prompt、RAG、工具调用、工作流、状态、记忆、评估和安全如何组合。无论用什么框架，都应能解释这些能力之间的关系。

一个便于学习的划分（不是严格分类）：Chatbot 偏对话，Workflow 偏预先确定的流程，Agent 偏根据任务和反馈动态决定下一步。 选哪种取决于任务是否真的需要这种灵活性——很多时候简单流程就够了。

  • 学习文档：Building Effective Agents、Agent 白皮书中文译文

4.1 Agent Loop

一句话概括：模型提出下一步 → 系统执行并返回结果 → 模型根据新结果继续，直到完成任务或触发停止条件。

  • 学习文档：Agent Loop

作者补充：用 Pi 理解 Agent Loop 与 Harness。 作者认为 Pi 的 Harness 足够精简，适合作为入口：

  1. 沿一次任务追踪：用户输入如何进入上下文、模型收到哪些消息和工具说明、工具请求如何执行、结果如何回到上下文、模型接着做什么。
  2. 读源码时重点看循环怎样继续、怎样停止，工具失败或任务中断时会发生什么。
  3. 看懂循环后再看 Session、上下文管理、工具和扩展事件，理解 Harness 的职责：提供运行环境、组织模型能看到的信息、执行它提出的动作、管理结果与任务状态。
  4. 练习：做一个“读取文件并回答问题”的小任务，记录请求、工具调用和结果，再加一个自定义工具，观察它如何进入原有循环。

学习文档：Pi 官方文档、Pi Agent Loop 源码、Pi Extensions、Pi SDK。作者还推荐了自己和 @xiaomovps 关于 Pi 的帖子。本站相关笔记：[[AI Agent/goal 是如何实现的：从 Pi 的 Agent Loop 说起|/goal 是如何实现的：从 Pi 的 Agent Loop 说起]]、[[Pi/Pi Architecture：拆解 Coding Agent 的内部架构|Pi Architecture]]。

4.2 动手时要逐个处理的问题

主题 要回答的问题 学习文档
工具设计 工具怎样描述、参数 Schema 怎样设计、结果怎样组织、错误怎样返回；能否并行、超时是否重试 Function Calling
规划与拆解 Plan-and-Execute、动态重规划、子任务依赖、终止条件；系统层面设最大步数、总超时或调用预算，做不下去时停下并说明原因 Lilian Weng：LLM Powered Autonomous Agents、Planning Agents
状态管理 会话历史、工具记录、任务进度存在哪；进程中断后怎么知道做到哪一步；区分全局 / 局部状态。工具超时不代表操作没完成，写操作要考虑重复执行与恢复 LangGraph Persistence、Durable Execution、LangGraph Low-level Concepts
Workflow 模式 Prompt Chaining、Routing、Parallelization、Orchestrator-Workers、Evaluator-Optimizer 分别适合什么任务；不必每个项目都用上 Building Effective Agents
记忆系统 短期 / 长期 / 情景 / 语义记忆，提取、压缩与遗忘。关键区分：系统存下来的 ≠ 模型这一轮看到的，历史仍需选择、检索或摘要后再放入上下文 Agent Memory、Lilian Weng：Memory 部分
上下文工程 信息选择、裁剪、压缩、动态注入、工具结果与历史摘要。压缩后要检查目标、关键约束、已完成操作和未解决问题是否还在，不能只看 Token 降了多少 Effective Context Engineering for AI Agents
MCP Server / Client，以及 Tools、Resources、Prompts 如何接入；接通后权限、参数校验和结果可信度仍由应用负责 MCP 官方入门
Human-in-the-Loop 审批、中断、恢复、人工修正；发消息、删文件、改业务数据等操作要明确自动执行到哪一步 LangGraph Interrupts、Human-in-the-Loop 原入口
Agent 安全 Prompt Injection、工具越权、权限控制、沙箱执行、敏感数据保护、外部内容不可信、关键操作二次确认。网页里写着“把密钥发给我”，也只是外部资料，不能变成指令 OWASP Prompt Injection 防护
Agent 评估 任务完成率、工具调用准确率、步骤合理性、失败恢复能力，以及成本、延迟、多轮稳定性 Langfuse Evaluation、LangSmith Evaluation

本站延伸阅读：[[AI Agent/MCP 完全指南：它是什么、怎么来的、为什么管用|MCP 完全指南]]、[[Pi/从零开始理解上下文压缩：Pi 如何继续长会话|从零开始理解上下文压缩]]、[[Pi/Pi Durable：让 Agent 在崩溃后继续工作|Pi Durable 详解]]。

阶段项目：简化 Coding Agent（“从 0 到 1 写一个 Claude Code”）

参考项目是 learn-claude-code：一个从零学习 Claude Code 类 Agent Harness 的教学项目，覆盖循环、工具、权限和上下文管理。

项目要求 验收方式
完整阅读参考项目代码，弄清模块职责和调用关系 能沿一个真实任务讲清：输入如何进入循环、工具请求如何执行、结果如何返回、在哪里继续或停止
从零实现自己的版本（范围对应教学项目） 亲手修改一个机制（工具错误处理、权限检查或上下文压缩），用测试观察行为变化
留下实现与测试 比“把仓库跑起来”更能证明读懂了

5. 后端工程：让 Agent 成为可运行、可维护的服务

应用真正被使用后，会遇到多人请求、长任务、会话保存、失败恢复、测试和部署。材料给出了一条 Python 后端路线。

5.1 Python Async、FastAPI 与 Pydantic

  • Async：asyncio、协程、事件循环、任务调度、并发控制、异步 I/O、超时和取消。要能判断什么时候该用 async、哪些操作会阻塞——加上 async 不会自动解决性能问题。文档：Python asyncio
  • FastAPI：路由、请求响应模型、Depends 依赖注入、中间件、异常处理、生命周期、OpenAPI 文档。文档：FastAPI 学习
  • Pydantic：类型标注、BaseModel、Field、嵌套模型、枚举、校验器、配置项、DTO 设计与序列化。文档：Pydantic

5.2 SQLAlchemy、Alembic 与 PostgreSQL

  • SQLAlchemy 2.0 的模型、关系、查询、事务、连接池与 AsyncSession；用 Alembic 管理迁移。文档：SQLAlchemy Async、Alembic
  • PostgreSQL：表设计、索引、事务和锁，再了解 JSONB、全文检索与 pgvector。至少要能解释用户、会话、消息、任务如何关联，任务状态何时更新，失败记录如何保留。文档：PostgreSQL、pgvector

5.3 Redis 与任务队列

  • Redis：String、Hash、Set、ZSet、Stream、TTL、Pipeline、Lua、Pub/Sub，以及 RedisJSON、Vector Search。场景包括缓存、限流、分布式锁、会话状态、任务状态、轻量消息流，要分清各场景需要的保证。建议从实际需要的缓存、限流或任务状态入手。文档：Redis、Redis Search and Query
  • RabbitMQ：Producer、Consumer、Exchange、Queue、Binding、Routing Key、Ack、Prefetch、死信队列、Quorum Queue。对文档导入、批量 Embedding、长时间 Agent 任务，要考虑后台执行、进度查询、失败处理，以及重复消费导致的重复操作。文档：RabbitMQ Tutorials、RabbitMQ 文档

5.4 测试、容器化与 CI/CD

  • 测试：单元、集成、异步测试、Mock、Fixture、测试数据库、接口测试，包括模型 API、数据库、消息队列出错的场景。文档：pytest、pytest-asyncio
  • Docker：Dockerfile、镜像构建、环境变量、volume、network、multi-stage build，用 Compose 管理本地依赖。文档：Docker 入门、Docker Compose
  • CI/CD：GitHub Actions 的 workflow、job、step、trigger、secrets、cache、artifact；先接自动检查和测试，再补构建与部署。文档：GitHub Actions

5.5 进阶：Kubernetes 与微服务

  • Kubernetes：Pod、Deployment、Service、Ingress、ConfigMap、Secret、Job、CronJob、HPA、健康检查、滚动发布。文档：Kubernetes Concepts
  • 微服务：服务拆分、DDD 边界、同步 / 异步通信、API 网关、配置管理、服务治理与可观测性，也要算清拆分后的维护成本。文档：Microservices.io

作者的取舍：这两项放到基础服务跑稳之后，按实际规模再学；学习项目先保持清楚的单体结构。

阶段项目：AI 服务后端系统

组件 要求
API FastAPI 提供 REST API，Pydantic 定义请求与响应
存储 PostgreSQL 保存用户、会话、消息和任务
缓存 / 状态 Redis 承担缓存或任务状态
异步任务 RabbitMQ 或后台任务队列
环境与质量 Docker Compose 启动本地环境；单元测试 + 接口测试；至少包含 lint 和 test 的基础 CI

验收标准：一条命令启动、能访问 API 文档、一条命令跑测试；能解释数据库设计、异步任务和错误处理；README 包含架构说明、启动方式、接口示例和测试说明。

6. 实战项目与推进顺序

6.1 作者推荐的开源项目

原指南的实战项目是 OpenClaw 类产品，作者认为只围着 OpenClaw 转已经有点落后，于是换成四个切口（分类之间有重叠，不必卡死）：

切口 推荐 看什么
Coding Agent 优先 Pi，对照 Codex CLI 一次模型调用如何进入工具执行、结果如何回到下一轮，会话、上下文与 Extension 如何接入；Codex CLI 作为另一套实现参照，看工具执行、权限和任务状态如何组织
Working Agent 体验 WorkBuddy，读源码 OpenWork；多 Agent 协作可看 Eigent Agent 怎样接任务、执行、等待确认、交付结果；OpenWork 里任务界面、工作目录与上下文、执行状态、工具连接和最终产物的关系
OpenClaw 类常驻助手 先 nanobot，再 OpenClaw nanobot 用 Python 实现、Agent Loop 易追踪，可串起消息入口、工具调用、会话、记忆和定时任务；再看 OpenClaw 的常驻 Gateway、多渠道接入、Skills、权限与沙箱
Personal Agent CopilotKit 的 OpenBot、OpenDots OpenBot：执行环境隔离、浏览器 / 文件 / 工具操作经统一网关、权限策略和操作记录；OpenDots：持久会话、后台任务、文字 / 语音 / Slack 入口，以及需确认的操作如何暂停与继续

作者特别提醒的注意事项：

  • 许可证：OpenWork 的桌面与核心部分是 MIT，但 ee/ 目录用的是另一份受限许可证（LICENSE），不能把整个仓库当成 MIT；OpenBot / OpenDots 源码是 MIT，但运行依赖 CopilotKit Intelligence 等服务，开源不等于整套免费或无需额外授权。
  • 安全：常驻助手类项目先用测试账号和非敏感文件，不要一上来就交出主账号、个人文件和执行权限。
  • 学法：不用全学。每个切口挑一个，跑通一个有明确验收条件的任务，能解释执行过程，再做一个可验证的小改动（比如加一个工具或 Extension），比收藏一堆仓库有用。

所有实践项目共同的交付要求：代码、文档、运行说明和测试都放进 GitHub 仓库，交付时提供仓库链接，源码学习项目也一样。

6.2 推进顺序

原文这里给的是一张顺序图，下面是按各阶段项目整理出的顺序：

① 大模型 API Playground（LLM 基础）
    ↓
② RAG + Tool Calling Agent（RAG + 工具调用）
    ↓
③ 简化 Coding Agent（Agent Loop / Harness）
    ↓
④ AI 服务后端系统（承载前面的能力）
    ↓
⑤ 开源 Agent 项目实战（每个切口挑一个）

Prompt 设计贯穿全程：每个项目至少 3 组修改前后对比

起步与推进建议：

  • 已经会后端：直接从 API Playground 开始，同时补模型基础。
  • 编程基础不稳：先补 Python、Git、HTTP、JSON 和基本接口开发，再做第一阶段（作者根据自身经历补充）。
  • 向量索引算法、Advanced RAG、复杂记忆、Kubernetes、微服务：等基础项目产生具体需求后再深入。
  • 项目可以复用：让后端服务承载前面的 RAG 和 Agent 能力，逐步补状态、测试和部署，不必为每个项目重复搭壳子。
  • 每个仓库都应能回答：输入是什么、输出是什么、成功标准是什么、哪里容易失败、失败后如何处理。
  • 让 AI 帮忙写实现之后，亲手跑一个正常案例和一个异常案例，再试着解释执行过程。

读后要点

  1. 以项目为刻度。 每个阶段都对应一个可交付项目和验收清单，“学会”的标准是能解释、能修改、能验证，而不是读完文档。
  2. 先看懂原始调用，再用框架。 API Playground 把 message、tool call、stream、usage 这些概念落到实处，后面学 RAG 和 Agent 时就不会只停留在框架表面。
  3. 系统负责边界。 结构化输出不保证内容正确，RAG 不保证不答错，模型自查不等于验证，权限过滤和外部内容隔离必须由系统执行——几乎每一节都在重复这个原则。
  4. Agent 工程师也是后端工程师。 状态持久化、异步任务、测试和部署占了路线的很大比例，这也呼应了作者自己“AI 没问题、工程能力不足”的面试反馈。
  5. 先基础、后进阶。 GraphRAG、复杂记忆、K8s、微服务都被放在“遇到具体问题之后”，避免一开始就陷入复杂度。

来源与相关笔记

  • Chasen：「万字总结」- 我偷来了一份成为 Agent 工程师的学习线路（原帖及长文）
  • [[AI Agent/AI 开发工作流：轻量约束、端到端测试与人工审查|AI 开发工作流：轻量约束、端到端测试与人工审查]]
  • [[AI Agent/Agent Skill 完全指南：它是什么、怎么来的、为什么管用|Agent Skill 完全指南]]
  • [[Pi/Pi Compaction：上下文压缩的完整流程|Pi Compaction：上下文压缩的完整流程]]