小加号笔记

做 AI Agent 最怕的不是“它答错了”，而是“它为什么答错，没人知道”。普通服务出问题，你还能看日志、看链路、看指标；Agent 出问题，如果没有记录推理步骤、工具调用、上下文、失败原因和成本，就只能靠猜。

AI Agent 可观测性 的目标不是把所有对话原文都存下来，而是让每一次 Agent Run 都能被复盘：它看到了什么、决定了什么、调了什么工具、哪里失败、花了多少钱、最后为什么给出这个结果。

本文脉络：

• 一、为什么 Agent 比普通服务更需要可观测性
• 二、先区分三件事：日志、指标、Trace
• 三、一次 Agent Run 应该记录成一棵 Trace
• 四、推理过程到底要不要记录
• 五、工具调用怎么记录
• 六、失败要分类，不要只写 error
• 七、成本观测：Token、模型、工具和重试
• 八、质量观测：不要只看成功率
• 九、隐私与安全：可观测性不是全量留存
• 十、落地方案：从最小闭环开始
• 十一、常见问题

Context Engineering，上下文工程，可以理解为 Prompt Engineering 的下一层：Prompt 关注“怎么把任务说清楚”，Context Engineering 关注“这次模型调用前，到底该把哪些信息放进上下文窗口”。

这也是为什么 RAG、Memory、Tools、Agent 这些东西看起来不一样，底层却经常绕回同一个问题：模型下一步要做对，眼前需要看到什么？

本文脉络：

• 一、为什么会从 Prompt Engineering 走到 Context Engineering
• 二、上下文工程到底是什么
• 三、Prompt、Context、RAG、Agent 的关系
• 四、上下文不是一段文本，而是一组分层信息
• 五、四个核心动作：写入、选择、压缩、隔离
• 六、RAG：最典型的上下文工程
• 七、Agent：动态上下文工程
• 八、上下文工程的常见失败模式
• 九、怎么评估上下文工程做得好不好
• 十、落地建议：从简单系统开始
• 十一、常见问题

提示词工程 不是给模型念咒，也不是把一句话写得更客气。它真正解决的问题是：怎么把人的模糊意图，翻译成模型能稳定理解、稳定执行、稳定校验的任务说明。

如果说 LLM 是一个能力很强但容易“顺着话跑”的协作者，那么 Prompt 就是你给它的任务单。任务单写得含糊，结果就靠运气；任务单写得清楚，模型才有机会稳定地做对。

本文脉络：

• 一、提示词工程到底是什么
• 二、为什么同一个模型，换个提示词差别很大
• 三、一个好 Prompt 的 7 个零件
• 四、角色设定：不是扮演，而是限定视角
• 五、上下文管理：给足信息，但别把噪声全塞进去
• 六、输出约束：让结果可读、可用、可解析
• 七、Few-shot：用示例告诉模型“照这个风格来”
• 八、思考过程与分步任务：让复杂问题可控
• 九、面向 Agent 的 Prompt：还要考虑工具和状态
• 十、提示词评估与迭代
• 十一、常见问题

web-access 不是“再多一个搜索工具”。它解决的是另一类问题：当 Agent 必须使用你的真实浏览器环境，带着登录态打开动态页面、点击按钮、截屏取证、读取浏览器历史或处理反爬页面时，普通网页抓取就不够了。

换句话说，web-access 是把 Agent 接到 Chrome / Edge 的真实页面上。它让 Agent 不只“读网页”，还可以像一个谨慎的助手那样“看页面、点页面、验证页面”。

本文脉络：

• 一、web-access 到底解决什么问题
• 二、什么时候该用，什么时候不要用
• 三、它的工作原理：Codex、CDP Proxy 与真实浏览器
• 四、使用前的预检：先确认浏览器和代理可用
• 五、一次最小可用流程：打开页面、读取、截图、关闭
• 六、常用能力：点击、滚动、上传、提取媒体
• 七、读取浏览器历史和书签
• 八、登录态与账号安全
• 九、站点经验沉淀：site patterns
• 十、常见问题

RAG 系统最容易出现一种错觉：Demo 里问几个问题都答得不错，就觉得可以上线了。真正上线后才发现，用户问法一变、文档一更新、召回一抖，答案就开始漏、偏、编。

评估 RAG 不能只问“答案看起来对不对”。要拆开看：检索有没有找到关键证据，生成有没有忠于证据，答案有没有回应问题，评审本身是否稳定。

本文脉络：

• 一、为什么 RAG 必须单独评估
• 二、先把 RAG 拆成两段：检索与生成
• 三、Recall：关键证据有没有找回来
• 四、Precision：检索结果是不是混进太多噪声
• 五、Faithfulness：回答有没有基于证据
• 六、Response Relevancy：回答有没有答到点上
• 七、RAGAS：把 RAG 评估流程自动化
• 八、LLM-as-Judge：用模型做裁判，但别迷信裁判
• 九、如何构建一套 RAG 评估集
• 十、怎么把评估接入研发流程
• 十一、常见误区与调优方向
• 十二、参考资料
• 十三、常见问题

一个真正好用的 AI Agent，不是“一个更会聊天的大模型”。它更像一个小型协作系统：有人负责想清楚怎么做，有人负责一步步执行，有地方保存上下文，还有一组工具连接外部世界。

如果把 Agent 只理解成“LLM + Prompt”，很快就会遇到三个问题：任务复杂一点就乱、做到一半忘了前面、需要查资料或改文件时无从下手。Planner、Executor、Memory、Tools 这四个模块，就是为了解决这些问题而出现的。

本文脉络：

• 一、先用一句话理解 Agent 架构
• 二、为什么一个模型还不够
• 三、四个核心模块分别管什么
• 四、一次 Agent 任务是怎么跑起来的
• 五、Planner：负责把目标拆成计划
• 六、Executor：负责把计划变成行动
• 七、Memory：负责带上该带的上下文
• 八、Tools：负责连接外部世界
• 九、四个模块如何协作
• 十、开发者落地时要注意什么
• 十一、普通用户怎么看懂 Agent 的表现
• 十二、常见问题

AI 客服系统 不是“套一个大模型聊天框”。真正难的地方在于：它要能理解用户问题，查到可靠知识，调用业务系统，知道什么时候不能回答，还要能把复杂问题顺滑地交给人工客服。

对 AI Agent 开发者来说，AI 客服是一个很典型的落地场景：它同时考验 RAG、工具调用、权限控制、状态管理、人工协同和线上评估。做得好，它是服务自动化；做不好，它就是一个会一本正经胡说的聊天窗口。

本文脉络：

• 一、先明确边界：AI 客服不是普通聊天机器人
• 二、核心需求与非功能指标
• 三、容量估算：客服系统的压力在哪里
• 四、整体架构：入口分流、AI 编排、人机协同
• 五、会话主流程：从用户提问到回复或转人工
• 六、知识库与 RAG：客服回答必须有来源
• 七、工具调用：让 AI 能查订单、退款和物流
• 八、人机协同：什么时候必须转人工
• 九、数据模型与存储设计
• 十、评估、观测与持续优化
• 十一、安全、成本与降级策略
• 十二、常见问题

会思考，是 Agent 区别于「一次性聊天机器人」的根本标志。问它一个问题，它不是直接吐答案，而是先想一下、查查资料、必要时做几步——这套「思考方式」背后，是一套被工程化的推理模式。

本文梳理 LLM 推理模式的演进脉络：从最朴素的直接生成，到 CoT 思维链，再到 ReAct（推理+行动交替）、Plan-and-Execute（先规划后执行）、Reflexion（失败后反思再试）。

本文脉络：

1. 为什么需要「思考模式」：直接生成的局限
2. CoT：让模型「想一想」再答
3. ToT：思维树，分叉探索
4. ReAct：推理与行动交替
5. Plan-and-Execute：先规划，再执行
6. Reflexion：反思循环，失败中学习
7. 五种模式对比与选型
8. 它们怎么组合成现代 Agent
9. 常见误区与陷阱
10. 常见问题

外卖订单分发系统 的核心不是“写一个最优匹配算法”——题目里已经说明分配算法是现成的，只需要调用。真正要设计的是：在订单和骑手数据都很大的情况下，如何持续构造合适的候选集，如何每 30 秒刷新未分配订单，如何把调用算法这件事做成一个稳定、可扩展、可观测的分布式调度系统。

本文按照系统设计面试的方式展开：先算清楚量级，再拆核心链路，最后讨论分区、数据模型、一致性和高可用。

题目输入：

本文脉络：

• 一、题目理解：系统重点不是算法，而是候选集与调度
• 二、容量估算：订单流和位置流到底有多大
• 三、整体架构：订单池、骑手位置索引、分区调度
• 四、地理分区：如何把经纬度范围变成可计算的批次
• 五、30 秒分发主流程：从未分配订单到推送骑手
• 六、数据模型与存储设计
• 七、一致性、幂等与并发控制
• 八、高可用、降级与可观测性
• 九、面试追问与总结

RAG（Retrieval-Augmented Generation，检索增强生成） 是让 LLM 用好私有数据的主流方案：在生成回答前，先从你的知识库里检索出相关片段，塞进 prompt 让模型「看着资料答题」。它解决了 LLM 的三个硬伤——知识截止、幻觉、无法访问私有数据。

本文脉络：

1. 为什么需要 RAG：LLM 的三个硬伤
2. 为什么不直接微调：RAG vs Fine-tuning
3. RAG 的完整架构：检索 → 增强 → 生成
4. 文档处理：chunking 是 RAG 成败的关键
5. Embedding：把文本变成向量
6. 向量检索：相似度 + Top-K
7. Reranking：把最相关的排到前面
8. Prompt 拼装与生成
9. 评估 RAG 系统
10. 生产实践与常见陷阱
11. 常见问题