2026 年每个人都在谈论 AI Agent，但大多数人不知道它们实际如何工作。
Rahul（@sairahul1）花了数周时间，整理了课程、书籍、真实构建和生产失败的教训，提炼出这份完整路线图。
第一部分：入门
1. 什么是 AI Agent？
普通 LLM 做一件事：你问，它答。一次完成。线性。无迭代。
AI Agent 工作方式不同。它像人类处理困难任务一样：先计划 → 研究 → 起草 → 审查自己的工作 → 修订 → 重复。
这被称为 ReAct 循环：Reason → Act → Observe → Repeat。
模型推理下一步做什么。行动（通常通过调用工具）。观察结果。然后要么给你答案，要么循环回去。
每一轮增加深度。更强的推理。更少的幻觉。更好的组织。一次性完成时失去的一切——Agent 都能找回。
2. Agent 真正擅长什么？
不是每个任务都需要 Agent。正确的思维模型是 2×2 矩阵：
- 低复杂度 + 高精确度 = 直接用代码
- 低复杂度 + 低精确度 = 单个 LLM prompt 即可
- 高复杂度 + 高精确度 = 带 heavy guardrails 的 Agent（税务表格、法律文档）
- 高复杂度 + 低精确度 = 最快早期胜利的甜蜜点
Agent 的完美任务示例：
- 研究并撰写报告
- 回复客户邮件（查询订单 → 起草回复）
- 处理发票
- 保存到数据库
- 通过实际检查库存回答"你们有 $80 以下的蓝色牛仔裤吗？"
Agent 在需要多步骤、外部信息、迭代和自我修正的任务中闪耀。如果能用一个 prompt 解决——不要构建 Agent。
3. 自主性光谱
构建 Agent 时的第一个重大决定：给它多少控制权？
脚本化（左端）：硬编码每一步。模型只做文本生成。可预测。易于调试。有限。
半自主（中间）：Agent 从你定义的工具中选择，在你设定的护栏内做决策。大多数真实生产系统所在的位置。
完全自主（右端）：LLM 决定一切。搜索什么、获取多少页面、是否反思、是否写新代码并运行。更强大。更难控制。
建议：从光谱中间开始。给它工具。设定护栏。只有在你获得信心后才增加自主性。
4. 上下文工程
让 Agent "智能" 的真正因素不是模型本身，是你围绕它构建的上下文。
上下文工程 = 决定 Agent 在每一时刻拥有什么信息。包括：
- 背景——任务是什么，用户是谁
- 角色——"你是专攻市场分析的研究 Agent"
- 记忆——之前步骤中发生了什么
- 可用工具——它可以调用哪些函数
- 知识——它可以参考的文档、数据库、PDF
工程化得好 → 模型行为一致。工程化得差 → 不可预测的垃圾。模型本身是一样的。上下文是区分优秀 Agent 和损坏 Agent 的关键。
5. 任务分解
构建 Agent 中最重要的技能。
从这个问题开始：人类会如何做这个任务？然后对每个步骤问：LLM 能做这个吗？一点代码？一个 API 调用？如果答案是否定的 → 拆分到更小直到可以。
示例——论文写作 Agent：
- 大纲 → LLM 生成结构
- 搜索词 → LLM 生成，然后调用搜索 API
- 获取页面 → 工具调用
- 写草稿 → LLM 使用获取的来源
- 自我批评 → LLM 列出差距和弱点
- 修订 → LLM 基于批评重写
每个步骤都是：小 → 可检查 → 有清晰的输入和输出。当最终输出不好时，你知道确切该修复哪个步骤。这就是分解的超能力。
第二部分：中级
6. 评估（区分专业者和爱好者的无聊事）
没人想谈论 evals。每个 ship 真实系统的人都做。
简单任务 → 统计正确答案。客服机器人是否正确回答了库存问题？是/否。
复杂任务 → 用 LLM 作为评判。让第二个模型用固定评分标准给输出打 1-5 分。论文有有力的论点吗？适当的引用吗？正确的语调吗？
两个评估层次：
- 组件级——每个单独步骤是否工作？（搜索查询是否足够具体？批评是否传递真实反馈？）
- 端到端——最终输出是否好？（论文实际上好吗？）
如果端到端失败但组件 evals 通过 → 交接问题。如果特定组件失败 → 该 Agent 需要工作。
从第一天开始评估。不要等待"完美"的 eval 系统。快速 ship 并迭代。
7. 记忆与知识
两个非常不同但人们混淆的东西。
记忆 = 动态。每次运行更新。
- 短期：Agent 工作时写笔记。其他 Agent 可以读这些笔记。
- 长期：任务后，Agent 反思。什么做得好？什么没做好？存储教训。下次运行 → 加载这些教训 → 应用它们。
这就是你如何"训练"Agent 而不 fine-tuning。给反馈 → Agent 每次运行都改进。
知识 = 静态。预先加载。
- PDF、CSV、内部文档、数据库访问
- Agent 的参考图书馆
- 给一次。需要时随时提取以提供准确答案
记忆 = 你从经验中学到的。知识 = 你可以参考的教科书。两者都重要。 neither 替代另一个。
8. 护栏
工作的 Agent 不是安全的 Agent。LLM 是非确定性的。它们可能格式错误、陈述虚假事实、偏离任务。
护栏是"Agent 说完成了"和"任务实际上最终确定"之间的质量门。
三种类型：
类型 1 — 代码检查（快速 + 便宜） 用于确定性事物。输出格式正确吗？长度对吗？必填字段存在吗？写一个简单的验证函数。即时运行。尽可能优先使用这个。
类型 2 — LLM 评判 用于细微的质量检查。"这个回复是否与源文档事实一致？""语调是否专业且积极？"如果评判说不 → 解释为什么 → Agent 修订 → 重试。
类型 3 — 人类在循环中 用于高风险决策。Agent 在最终确定前停止。发送输出供人类审查。人类批准、拒绝或请求更改。
大多数生产系统至少使用这三种中的两种。
9. 四个提升每个 Agent 的设计模式
模式 1：反思 不要在第一稿停止。模型产生输出 → 批评它 → 基于批评重写。对代码更强大——写它、运行它、捕获错误、反馈、模型修复。用于：结构化输出、长文写作、代码、程序步骤。
模式 2：工具使用 给 LLM 一个它可以调用的功能菜单。模型决定何时以及使用哪个工具。网络搜索、数据库查询、代码执行、日历、邮件、API 调用。LLM 单独不能做这些。工具是 Agent 与世界交互的方式。
模式 3：规划 不是固定管道，让 Agent 决定步骤。给它一个工具包。提示它制定计划。逐步执行。零售示例："$100 以下有圆形太阳镜吗？"Agent 计划：搜索描述 → 检查库存 → 按价格过滤 → 回答。
模式 4：多 Agent 协作 将复杂工作拆分到专业 Agent。研究员 → 设计师 → 写手。每个 Agent 擅长其特定工作。输出更好，因为没有一个 Agent 试图做所有事情。
10. 多 Agent 系统设计
四种协调模式，从最简单到最复杂：
顺序：每个 Agent 完成 → 传递输出给下一个 Agent。像流水线。研究员 → 设计师 → 写手 → 完成。易于调试。可预测。从这里开始。
并行：同时运行独立 Agent。研究员 + 设计师同时工作。写手合并他们的输出。更快。更多协调复杂性。
管理层次：一个管理 Agent 协调专家。管理计划、委派、审查。专家向管理报告，不互相报告。当今真实生产系统中最常见的模式。
全对全：任何 Agent 可以给任何其他 Agent 发消息。混乱。难以预测。仅用于创意/低风险工作，变化可以接受。不要在生产中使用。
经验法则：从顺序开始。仅在需要时增加复杂性。
第三部分：生产
11. 高级任务分解
复杂多 Agent 系统中，分解方式很重要。四种模式：
功能型——按技术域拆分。前端 Agent。后端 Agent。数据库 Agent。工程团队的经典模式。
空间型——按文件或目录结构拆分。Agent 1 处理 /services/users/。Agent 2 处理 /services/orders/。大型代码库的理想选择。最小化冲突。
时间型——按顺序阶段拆分。阶段 1：研究。阶段 2：计划。阶段 3：构建。阶段 4：发布。每个阶段在下个阶段开始前完成。
数据驱动型——按数据分区拆分。Agent 1 处理第 1 周日志。Agent 2 处理第 2 周。等等。大数据集的强大选择。并行化分析。
可以混合使用。主结构用功能型分解 + 每个 Agent 内部用时间型分解。使用匹配任务自然边界的方式。
12. 生产中提升质量
系统在工作但不够好。两种组件。两种不同修复策略。
非 LLM 组件（网络搜索、RAG、OCR、代码执行）：
- 调整旋钮：搜索日期范围、top-k 结果、chunk 大小、相似度阈值
- 更换提供商：尝试不同的搜索 API、视觉模型、解析器
LLM 组件（生成、推理、提取）：
- 更好的 prompt：添加约束、示例、输出模式
- 尝试不同模型：有些模型更擅长代码，其他更擅长遵循指令
- 将更难的任务分解为更小的部分
- Fine-tuning（最后手段——昂贵，留给最后几个百分点）
顺序很重要。先修复 prompts。尝试不同模型。进一步分解。Fine-tuning 最后。大多数团队在步骤 2 达到足够好的质量。
13. 延迟和成本
质量第一。然后速度和成本。
减少延迟：
- 测量每个步骤。找到真正的瓶颈。
- 并行化任何不依赖其他步骤的事情。
- 合适尺寸的模型——简单步骤用快速便宜 LLM，推理用大型模型。
- 尝试更快的提供商——token 流式传输速度差异很大。
- 修剪上下文——更短的 prompts 解码更快。
减少成本： 典型研究 Agent 运行的真实成本分解：
- LLM 生成调用：~$0.04
- 网络搜索 API 调用：~$0.02
- Embedding 调用：~$0.005
- 基础设施：~$0.015
- 每次运行总计：~$0.08
1,000 次运行/天 = 2,400/月。
如何削减：
- 先攻击最大的桶
- 分层模型——简单用便宜，困难用昂贵
- 积极缓存结果（搜索结果、embeddings、摘要）
- 约束输出（"返回 JSON。最多 5 个字段。"）
- 尽可能批量操作
14. 可观测性：规模化监控 Agent
传统软件：追踪执行路径。A 调用 B。B 调用 DB。返回结果。
AI Agent 不是这样工作的。它们是非确定性的。相同输入 → 不同输出。分布式执行。可能失败的外部依赖。
需要两种可见性：
Zoom-in 指标（单次运行调试）：
- 完整追踪：每个 prompt、每个工具调用、每个使用的 token
- Agent 为什么选择这个工具？
- 每个步骤返回了什么？
- 它确切在哪里失败了？
不仅记录发生了什么，还记录为什么："Agent 选择网络搜索而非 RAG，因为查询包含'最近'""反思识别出 3 个问题：缺少引用、模糊日期、错误语调"
Zoom-out 指标（跨多次运行的系统健康）：
- 随时间的质量分数
- 幻觉率
- 成功率
- 变化在帮助还是伤害？
你无法在规模上手动检查每个追踪。使用质量采样——评估所有运行的百分比。建立趋势线。这是在用户之前捕捉回归的方式。
15. 安全：没人谈论但应该谈论的部分
AI Agent 的安全不像传统应用安全。你不仅要保护免受外部攻击者。你还要保护自己的系统做出危险决策。
威胁：
- Prompt 注入——用户输入中的恶意内容劫持 Agent 的指令
- 不安全代码生成——Agent 编写访问敏感数据或做有害事情的代码
- 数据泄漏——PII 或专有信息通过输出或工具调用暴露
- 资源耗尽——Agent 旋转无限循环或燃烧昂贵的 API 调用
代码执行是最危险的功能。如果启用，安全做法：
- Docker 沙盒。每次运行后销毁容器。
- 设置硬资源限制：超时、内存上限、CPU 限制
- 仅白名单特定安全库
- 所有输入到达 Agent 前验证
- 扫描所有输出中的敏感数据（API 密钥、PII）
- 使用确定性 I/O——代码返回结构化 JSON，不是自由格式文本给用户
大多数团队以艰难的方式学到这些教训。Ship 之前读这个。
总结
入门：Agent 迭代工作——计划、行动、观察、重复。最适合复杂多步骤任务，可处理 ~90% 准确率。从半自主开始，不是完全自主。上下文工程是真正的智能。任务分解是最重要的技能。
中级：从第一天开始评估——复杂任务用 LLM-as-judge。记忆（动态）≠ 知识（静态）。三种护栏：代码 → LLM 评判 → 人类。四个总是有帮助的模式：反思、工具使用、规划、多 Agent。从顺序开始。仅在需要时增加协调复杂性。
生产：4 种分解模式：功能型、空间型、时间型、数据驱动型。Fine-tuning 之前先修复 prompts。按步骤测量延迟和成本，然后攻击最大的桶。两种可观测性模式：zoom-in 追踪 + zoom-out 健康指标。安全 = 保护自己系统，不只是攻击者。
大多数人开始构建 Agent。少数人 ship 在规模上可靠工作的 Agent。差距就是这篇文章中的 everything。