AI Agent 站内学习手册
这份手册负责解释“为什么”和“怎么运转”，完整学习契约负责告诉你“做到什么才算掌握”。两者配合使用，整个学习过程都在本站完成。
推荐顺序：先读一节站内讲解，再完成对应实践，最后用自测问题检查自己能否脱离原文说明原理。
快速入口：
- 01 · Agent 最小闭环
- 02 · 上下文工程
- 03 · Memory 与 RAG
- 04 · Tool、MCP 与 Skills
- 05 · Agent Runtime
- 06 · Coding Agent 与交互
- 07 · 评估与可观测性
- 08 · 训练与行为优化
- 09 · 持续进化
- 10 · 多 Agent 与生产项目
01 · Agent 最小闭环
核心结论
大模型本身只负责根据输入生成下一段内容。Agent 在模型外增加了一个控制循环：把目标交给模型，解析模型决定，执行工具，把执行结果重新放回上下文，再判断是否继续。
最小闭环可以写成下面的伪代码：
messages = [system, user_goal]
repeat until stopped:
decision = model(messages, tools)
if decision is final_answer:
return decision
result = execute(decision.tool, decision.arguments)
messages.append(decision)
messages.append(result)必须理解的边界
- 聊天：控制权主要在人，用户决定下一轮问什么。
- Workflow：控制权主要在预先写好的程序，步骤通常是确定的。
- Agent：程序提供边界，模型在边界内动态选择下一步动作。
- 工具结果不是最终答案：它是 Observation，需要回到模型或确定性逻辑继续判断。
- 停止条件必须外置：最大轮数、超时、预算、成功判定和人工接管不能只靠模型自觉。
自测
- 为什么“模型会 Tool Calling”仍不等于系统已经是可靠 Agent？
- 工具报错后，应该把什么信息放回上下文？
- 最终成功应由模型声明，还是由程序验证？
02 · 上下文工程
核心结论
上下文不是聊天记录的简单拼接，而是一次推理前的“信息装配结果”。装得太少会遗漏约束，装得太多会引入噪声、提高成本并稀释重点。
一个实用的装配顺序是：
系统规则 → 当前目标 → 必要状态 → 相关记忆或检索证据 → 最近轨迹 → 本轮输入四种常见策略
- 裁剪：删除确认无关的信息，适合工具输出过长的场景。
- 摘要：压缩历史语义，但必须保留不可丢失的约束、决定和待办。
- 按需加载：先放索引，需要时再取正文，适合大型代码库和知识库。
- 缓存：复用稳定前缀，减少重复计算；缓存命中不代表内容仍然正确。
上下文、运行状态和长期记忆要分开：运行状态服务于任务恢复，长期记忆服务于跨会话偏好，上下文只是本轮真正交给模型的内容。
自测
- 为什么更长的上下文不一定得到更好的回答？
- 哪些信息绝不能只保留在摘要里？
- 工具返回十万行日志时，你会怎样决定给模型看什么？
03 · Memory 与 RAG
核心结论
Memory 解决“系统应该记住什么”，RAG 解决“回答当前问题需要查到什么”。它们都向上下文提供信息，但生命周期和可靠性要求不同。
RAG 的基本链路
- 文档切分并保留来源位置。
- 将问题转换成检索查询。
- 召回候选片段。
- 通过过滤或重排找到真正相关的证据。
- 让模型只基于证据回答，并给出引用。
- 当证据不足时拒答或请求补充信息。
错误需要分层判断：没找到正确内容是召回问题，找到了却排在后面是重排问题，证据正确但答案错误是生成问题。只看最终答案，很难知道应该修哪一层。
Memory 的三种常见类型
- 会话轨迹：当前任务发生过什么。
- 用户记忆：相对稳定的偏好、身份和约束。
- 知识记忆：可引用、可更新的外部事实。
三者不应混成同一张“万能表”，否则很难处理过期、权限和删除要求。
自测
- 用户说“以后都用中文回答”应进入哪种记忆？
- 检索正确但回答错误时，为什么不该先调整向量模型？
- 引用能证明哪些事情，又不能证明哪些事情？
04 · Tool、MCP 与 Skills
核心结论
Tool 是系统可以执行的动作，MCP 是连接工具与数据源的一种标准协议，Skill 是可复用的任务方法和约束。三者解决的问题不同，不能互相替代。
一个可靠工具至少需要：
- 明确的名称与用途，避免模型误选。
- 可校验的参数 Schema，非法输入在执行前被拒绝。
- 超时、取消和资源限制。
- 可区分的错误类型，例如参数错误、权限拒绝、业务失败和系统故障。
- 对写入操作提供预览、确认、审计和幂等保护。
风险分级
- 只读动作：通常可以自动执行，但仍要限制读取范围。
- 可恢复写入：先展示变更，再让用户确认。
- 难恢复动作：删除、付款、发布等需要更严格的身份与权限检查。
模型给出的工具参数只能视为候选输入，不能直接当作可信命令。真正的安全边界必须由确定性程序实现。
自测
- 为什么 Schema 既是提示信息，也是运行时边界？
- MCP 解决了互操作后，哪些安全问题仍然存在？
- 怎样避免任务重试时重复创建同一资源？
05 · Agent Runtime
核心结论
Runtime 管理的是一个任务从开始到结束的生命周期：状态、检查点、并发、重试、取消、恢复和资源边界。它是 Agent 从演示程序走向可用系统的关键层。
需要分开的三种数据
- Transcript：完整发生记录，用于审计和回放。
- Runtime State：程序恢复任务所需的结构化状态。
- Model Context：本轮精选后真正发给模型的信息。
每个工具动作最好经历“计划 → 执行中 → 已完成或失败”的状态变化。检查点要记录动作是否已经产生副作用，恢复时才能决定继续、跳过还是补偿。
可靠恢复原则
- 写入操作使用幂等键或唯一业务标识。
- 重试只针对可重试错误，并设置退避和上限。
- 取消信号要能传到正在运行的工具。
- 恢复前先读取真实外部状态，不能只相信旧日志。
自测
- 为什么把所有聊天消息保存下来仍不等于支持恢复？
- 工具刚成功、系统却在写检查点前崩溃，恢复时怎么办？
- 什么错误适合重试，什么错误必须立即停止？
06 · Coding Agent 与交互
核心结论
Coding Agent 不只是生成代码。它需要观察文件、搜索调用关系、提出补丁、运行验证，并在可能造成损失的动作前让人做决定。
一次安全修改的流程
- 读取仓库规则和目标文件。
- 搜索相关调用链，确认影响范围。
- 生成最小补丁，不覆盖无关改动。
- 展示 Diff 或变更摘要。
- 在权限允许时应用补丁。
- 执行测试、构建或静态检查。
- 报告已验证内容和仍然未知的风险。
Computer Use 和浏览器 Agent 也遵循相同原则：先观察，再定位，再行动，行动后重新读取界面确认真实结果。屏幕看起来“像成功”不等于后台状态已经成功。
自测
- 为什么整文件重写比最小补丁风险更高？
- 人工确认应该放在哪些动作前？
- Agent 自己说“测试通过”为什么不算验证证据？
07 · 评估与可观测性
核心结论
Trace 解释一次任务发生了什么，Eval 判断系统在一组任务上表现如何。没有 Trace 很难定位失败，没有 Eval 很难证明改动整体变好。
建议记录的运行数据
- 输入、期望结果与评分规则。
- 模型、提示、工具和代码版本。
- 每一步决策、参数、Observation 和耗时。
- Token、成本、重试次数与最终状态。
- 确定性检查、人工评分或规则评分。
评估集应同时包含正常任务、边界条件和已知失败。报告不能只给平均分，还要展示改善样例、退化样例和没有变化的样例。
指标的三层结构
- 结果层：任务是否完成，输出是否正确。
- 过程层：工具选择、参数、步骤数和恢复行为是否合理。
- 系统层：延迟、成本、可用性和安全事件。
自测
- 为什么只使用“模型评分模型”风险很高？
- 平均分上涨时，系统仍可能出现什么退化？
- 一条 Trace 至少要能追溯到哪些版本信息？
08 · 训练与行为优化
核心结论
看到失败时，先定位失败来自上下文、工具、编排、数据还是模型能力。只有稳定复现且无法通过系统设计解决的问题，才值得考虑训练。
三类方案
- 系统改进：修改提示、上下文、工具或流程，成本最低且容易回滚。
- SFT：让模型更稳定地模仿目标回答或操作格式，依赖高质量示例。
- 偏好优化或 RL：根据比较或奖励信号调整行为，要求可靠评价信号和更高工程成本。
训练前必须先有独立评估集、数据来源记录和停止条件。否则训练后只会看到“感觉变好”，无法知道是否损害了其他能力。
自测
- 工具参数经常缺字段，应该先训练还是先加强 Schema 与重试提示？
- SFT 数据为什么不能直接来自未经清洗的线上日志？
- 训练指标改善后，为什么仍要检查真实任务成功率？
09 · 持续进化
核心结论
持续进化不是让 Agent 随意修改自己，而是把真实失败转化成受控候选改进，再经过离线验证、人工审核和灰度发布。
安全改进闭环
失败收集 → 去敏与分类 → 原因定位 → 生成候选方案
→ 离线评估 → 人工审核 → 灰度发布 → 监控 → 保留或回滚知识、提示、程序和模型参数是四种不同更新面。知识更新通常最容易回滚，程序和权限边界的更新风险更高，模型参数更新影响最广。不同更新面需要不同审批和验证强度。
必须设置的门禁
- 候选改进不能绕过已有测试和权限检查。
- 线上轨迹进入数据集前要去除敏感信息。
- 同时监控质量指标和安全回归指标。
- 每次发布都保留版本、证据和回滚方法。
自测
- 为什么线上失败不能直接自动进入训练集？
- 更新知识库和更新模型参数的风险有什么不同？
- 自动生成补丁后，发布前至少要经过哪些门禁？
10 · 多 Agent 与生产项目
核心结论
多 Agent 的价值来自并行、权限隔离、上下文隔离或专业角色，而不是角色数量。能用一个 Agent 加确定性函数完成的任务，不必为了形式拆成多个 Agent。
拆分前先问四个问题
- 子任务之间是否真的可以并行？
- 不同角色是否需要不同权限或工具？
- 单个上下文是否已经过长或相互干扰？
- 协调成本是否低于拆分带来的收益？
协作协议需要明确
- 每个角色接收什么输入、产出什么结果。
- 共享哪些事实，隔离哪些私有上下文。
- 冲突由谁裁决，失败由谁恢复。
- 总预算、最大并发和停止条件是什么。
生产项目应先建立单 Agent 基线，再引入多 Agent，并比较质量、延迟、成本和维护复杂度。没有对照数据，就无法证明拆分值得。
自测
- “规划 Agent + 执行 Agent”一定比单 Agent 好吗？
- 多个 Agent 共享全部上下文会带来什么问题？
- 怎样证明多 Agent 架构的收益超过协调成本？
附录 A · 框架与 SDK 选型
框架不能代替架构判断。选型时先回答六个问题：状态是否显式、流程是否需要图结构、工具是否很多、是否要恢复、是否需要多 Agent、最终运行在哪个宿主。
| 类型 | 代表方案 | 适合场景 | 主要代价 |
|---|---|---|---|
| 原厂 SDK | OpenAI Agents SDK、Google genai、Anthropic SDK | 希望紧跟模型原生能力 | 跨厂商迁移需要适配 |
| 图编排 | LangGraph | 分支、并行、循环和状态恢复较复杂 | 状态设计与调试成本更高 |
| 通用应用框架 | LangChain、Semantic Kernel、Mastra | 需要现成组件与生态集成 | 抽象层可能掩盖真实调用链 |
| 多 Agent 框架 | AgentScope、AutoGen、AgentUniverse | 角色协作、分布式或企业治理 | 协调、成本和错误传播更复杂 |
| 研究型工作流 | DeerFlow | Deep Research、多阶段报告生成 | 对特定工作流依赖较强 |
| 全栈 UI 框架 | Vercel AI SDK | Web 流式交互、React/Next.js 应用 | 不负责完整后端 Runtime |
| Go 生态 | Eino | Go 服务、流式处理和高并发 | 社区资源少于 Python/TS |
| 最小 Harness | 自写 Loop、GitAgent 模式 | 学习原理或需要完全掌控边界 | 可靠性能力都要自己实现 |
LangGraph 的统一理解
LangGraph 的核心不是“画图”，而是把状态、节点和边变成一等公民：
- State 保存节点之间共享的数据，更新时尽量返回增量。
- Node 承担一个可验证步骤，输入状态并返回状态变化。
- Edge 表示确定顺序，Conditional Edge 表示动态路由。
- Fan-out / Fan-in 用于并行分析与结果聚合。
- Checkpoint 让长流程支持暂停、恢复和人工介入。
如果流程只是一次模型调用或三个固定步骤，用普通函数会更清楚。只有当状态转移本身成为主要复杂度时，图框架才真正有价值。
三大 SDK 的共同协议
虽然接口名称不同，三者最终都在做同一件事：描述工具 → 发送消息 → 接收工具请求 → 本地执行 → 回传结果 → 继续生成。选型时比较自动循环、流式事件、模型覆盖、多模态、Handoff、Tracing 和部署环境，而不是只比较示例代码行数。
附录 B · Coding Agent 与 Harness 对比
五类系统可以放到同一张能力地图中理解：
| 系统 | 最值得学习的部分 | 适合借鉴的设计 |
|---|---|---|
| Claude Code 渐进课程 | 从 Loop 逐步加入 Tools、Todo、Subagent、Skill、Compact、Teams | 用小步演进理解复杂系统 |
| Codex CLI | 配置层级、审批策略、平台沙箱、MCP 与线程式 SDK | 把权限和隔离放在模型之外 |
| Pi | Provider 适配、Extension、Package、树形 Session 与恢复 | Runtime、Transcript、Context 分层 |
| DeepSeek Harness | 插件内核、LLM 接缝、Session Log、Inbox、Runtime Surface | 将大部分能力设计成可替换接缝 |
| OpenClaw | 从最小 Loop 推导 RAG、工具、记忆、多 Agent 和部署 | 先理解机制，再引入框架 |
渐进构建顺序
- Loop：完成 Model–Tool–Observation 闭环。
- Tool Registry：用注册表替代硬编码分支。
- Todo / Plan State：让计划成为可观察状态。
- Session Log：记录不可变事件，作为事实源。
- Context Builder：从事实源挑选本轮上下文。
- Compaction：压缩历史但保留任务状态和关键决定。
- Subagent：用独立上下文处理明确子任务。
- Background Task：非阻塞运行长工具，并支持状态查询和取消。
- Team Protocol：定义消息、责任、冲突和完成条件。
- Workspace Isolation：并行修改时隔离文件和 Git 状态。
Harness 的五条工程判断
- Loop 是控制平面，不应同时承担所有业务实现。
- 工具“存在”不代表模型“有权限执行”。
- Session Log 记录事实，Context 是从事实中构造的工作集。
- 用户插话、取消和审批都是独立事件，不能伪装成普通聊天消息。
- 插件可以扩展能力，但安全边界必须由不可绕过的宿主机制保证。
附录 C · 七个应用实战
1. 用 Agent 发布个人主页
从需求澄清、信息架构、视觉实现、构建检查到 GitHub Pages 部署。重点不是“一句话生成网页”，而是如何保存设计决定、检查移动端、处理资源路径并验证线上状态。
2. AI Coding 面试
把题目拆成输入输出、约束、例子、算法选择、边界测试和复杂度说明。Agent 可以辅助搜索和验证，但候选人必须能解释关键决定，并区分“代码能跑”和“答案可交付”。
3. 日常开发工作流
为仓库准备规则、常用命令和验证入口；先搜索再修改，先最小补丁再扩展，使用测试和 Diff 作为证据。长任务通过计划、检查点和阶段摘要控制上下文。
4. Auto Harness
从失败轨迹中识别重复工具调用、状态丢失、错误分类不清和提前结束，再修改运行骨架。每个改动都必须有失败样例和回归验证，不能只优化成功 Demo。
5. Eval-Driven Practice
先建立 15–30 条小型评估集，再改提示、工具或模型。记录版本、Trace、耗时、成本和评分，报告同时展示改善与退化。
6. RSI 求解优化
把一次求解失败转化成策略候选，通过离线问题集比较新旧策略。真正的 RSI 需要受控候选、外部验证和回滚，而不是让模型未经审核修改自身生产逻辑。
7. 云端 Bot Agent
关注渠道接入、身份、会话、异步事件、限流、重试、长任务状态与用户通知。不同聊天渠道只是入口，核心 Runtime 应保持一致。
每个实战统一留下五类证据：需求说明、可运行代码、一次失败轨迹、评估结果和部署说明。
附录 D · 十七类面试复习
面试内容使用“定义 → 原理 → 取舍 → 实践证据”四层回答，不背孤立结论。
| 维度 | 必须能回答的核心问题 |
|---|---|
| 架构选型 | ReAct、Plan-and-Execute、图编排与 Workflow 如何选择？ |
| 工具管理 | 百级工具如何发现、路由、校验、授权和审计？ |
| 容错鲁棒性 | 超时、重试、幂等、降级、补偿和幻觉如何分层治理？ |
| 记忆上下文 | Context、State、Transcript、用户记忆和知识库如何区分？ |
| 评估与全局观 | 怎样设计任务、验证器、指标和失败归因？ |
| 多 Agent | 何时拆分、怎样通信、如何隔离与仲裁冲突？ |
| 工程踩坑 | 死循环、状态丢失、上下文污染、成本失控如何处理？ |
| Prompt 与 Skills | 系统提示、Few-shot、动态提示和渐进披露如何协作？ |
| RAG | Chunk、召回、重排、引用、拒答和知识更新如何设计？ |
| 训练数据 | SFT、DPO、PPO、GRPO、数据清洗与 Loss Mask 如何选择？ |
| AI 代码测试 | 如何测试非确定性输出、工具轨迹和生成代码？ |
| 业务 AI | 如何从业务问题推导指标、数据、流程和风险边界？ |
| 项目深挖 | 你的架构、难点、失败、验证和个人贡献证据是什么？ |
| 公司偏好 | 如何根据岗位和业务调整准备重点，而不是背统一答案？ |
| Agent 概念 | Harness、Context Engineering、MCP、Skills 的边界是什么？ |
| Agent Infra | Runtime、Sandbox、Session、调度和可观测性如何落地？ |
| AI Infra | 训练、推理、GPU 调度、Serving 和平台工程如何协作？ |
一次有效的复习
- 隐藏答案，用两分钟口述。
- 给出一个真实或可运行的例子。
- 说明一个备选方案和为什么没选。
- 补充失败条件、监控指标和兜底。
- 把无法回答的点回填到手册对应章节。
题库原项目包含单独的 CC BY-NC-SA 4.0 许可。本站把考察维度融合进学习路线，问题与答案使用独立表达，不把整套题库混入其他许可内容。
附录 E · 十二步生产项目
以“面试诊断 Agent”为示例，可以用下面十二步把知识串成一个完整作品：
- PRD：明确用户、输入、输出、成功标准、隐私和非目标。
- 系统架构：划分 Web、API、Query Engine、Tools、Knowledge、Runtime 和 Storage。
- Query Engine：统一多 Provider，处理流式响应、超时、重试、缓存和路由。
- Tools & Skills：原子工具负责动作，Skill 负责可复用任务方法。
- 知识库：支持关键词与向量双路检索，答案必须带来源证据。
- Context & Memory：分离当前任务状态、短期历史、长期偏好和知识证据。
- Permission & Session：权限分级、确认、检查点、恢复和审计日志。
- Hook & Command：用确定性钩子治理输入、工具前后、输出和错误流程。
- Sub-agent：将检索、评分或总结包装为边界清晰的子任务。
- STT 与语音：转写、说话人分离、时间戳和口语表现分析。
- 部署与演示：环境配置、可复现启动、正常用例和可恢复失败用例。
- Web UI：上传、进度、流式结果、证据查看、失败恢复与移动端体验。
推荐架构
Web / CLI
↓
API + Session
↓
Runtime / Query Engine
├── Model Provider
├── Tools & Skills
├── Knowledge Retrieval
├── Memory & Context
└── Eval / Trace / Audit项目展示时至少演示一次正常分析、一次工具失败后的恢复，以及一份可以追溯到版本的评估结果。
学完之后
不要只记录“看完了”。回到完整学习契约，为每个阶段留下代码提交、实验表格、Trace、测试结果或项目演示。需要核对资料出处和许可时，再查看来源说明。