开场：Agent 不是更聪明的 LLM
很多人以为 Agent 就是"更聪明的大模型"。错。
LLM 是会说话的模型，Agent 是会干活的助手。同一句话，LLM 回答完就结束；Agent 会拆任务、调工具、看结果、错了再来，直到把事办成。
本文把 Agent 从"是什么"讲到"怎么造"，一条主线贯穿：模型负责聪明，工程负责稳定。全文覆盖六大模块——工具调用机制、上下文与记忆、ReAct 循环、Skill、生产脚手架、多 Agent 协作与可观测性。
一、Agent 到底比 LLM 多了什么？
一条 LLM 的工作链路是：输入 → 输出。一条 Agent 的工作链路是：
任务 → 规划 → 调工具 → 观察 → 纠错 → 完成
相比裸 LLM，Agent 多了四样东西：
| 能力 | 英文 | 干什么用 |
|---|---|---|
| 规划 | plan | 把大任务拆成可执行的小步骤 |
| 工具 | tool use | 调用外部 API / 代码 / 数据库，真正"动手" |
| 记忆 | memory | 记住本对话、记住历史偏好 |
| 反思 | act / reflect | 观察执行结果，发现不对就自我纠错 |
这四样，就是 LLM 与 Agent 之间那道"从说到做"的鸿沟。
二、模型调动工具的秘密
先破除一个误解：模型不会真的执行代码。
模型做的只有一件事——输出一段结构化文字（tool_calls）。真正解析并执行这段文字的，是你的框架代码。所谓"Agent 调了天气 API"，实际流程是这样的：
messages[0]· system（220 Token）：role: "system"，content: "你是一个智能助手，可以使用以下工具帮助用户…"，tools: [get_weather, send_email, web_search]messages[1]· user（30 Token）："北京明天天气怎么样？"- ← 第 1 次模型调用完成（耗时 1.8s）
messages[2]· assistant（60 Token）：content: null，tool_calls: [{name: "get_weather", id: "call_abc123", arguments: {city: "北京", date: "2026-04-23"}}]- ⚙️ 你的代码登场：解析 tool_calls → 校验参数（city 合法 ✓、date 格式正确 ✓）→ 调用天气 API（耗时 0.8s）
messages[3]· tool（50 Token）：role: "tool"，tool_call_id: "call_abc123"，content: {weather: "小雨转多云", temp: "12°C ~ 20°C", wind: "北风 3 级"}—— 注意：这条消息由你的代码注入，不是模型生成的- → 你的代码发第 2 次请求（携带完整 4 条消息 + 工具结果）
- ← 模型返回最终回答（耗时 1.5s）
messages[4]· assistant（120 Token）："明天北京小雨转多云，气温 12-20°C，北风 3 级，出门建议带把伞。"
整个过程：2 次模型调用 + 1 次天气 API。工具调用不是魔法，是"模型出试卷、框架改卷子"的协议循环——assistant.tool_calls 是模型的"意图"，tool 消息是框架的"回执"，二者一闭环，Agent 就"动"起来了。
三、工具描述的学问
工具描述 = 给模型的使用说明书。说明书写得越清楚，模型用得越准确。
同样是天气工具，差评描述是"查询天气"，好评描述是"输入城市名（中文，如'北京'）和日期（YYYY-MM-DD），返回当天天气、温度与风力"。
这不只是工程问题——产品经理应该像写 PRD 一样写工具描述。参数边界、返回格式、失败行为写清楚，模型才不会把参数传错、把结果读歪。
四、多工具编排：串行、并发、智能分批
同一轮模型可能返回多个工具调用，框架必须决定执行顺序：
| 策略 | 特点 | 适用 |
|---|---|---|
| 全部串行 | 最安全，一个失败就停 | 有依赖关系的步骤 |
| 全部并发 | 最快，但互相干扰就出事 | 相互独立的查询 |
| 智能分批 | 按安全性分组，低危并发、高危串行 | 混合场景（Alice 的做法） |
这个决定直接影响用户等待时间——选错了，体验就从"秒回"变成"转圈"。
五、MCP：AI 工具的 USB 标准
没有 MCP 之前，每个 Agent 都要为每个工具写专属对接代码——就像每台设备都要专属数据线。
MCP（Model Context Protocol）就是 AI 工具的 USB 标准：工具开发者只写一次适配，就能接入所有 Agent。一端是工具服务器暴露能力，一端是 Agent 客户端统一消费，协议替你解决了握手、鉴权与数据格式。
六、上下文窗口：模型的唯一工作记忆
上下文窗口是模型唯一的工作记忆。128K Token 看似很大，但有个残酷事实：每轮对话都要重发全部历史消息。10 轮深度对话 + 一份长文档，就可能把窗口撑满。管理上下文，就是管理产品的记忆寿命。
四层压缩策略（超限前逐级触发）
| 层 | 名称 | 触发水位 | 压缩动作 | 信息损失 |
|---|---|---|---|---|
| L1 | 裁剪 Snip | 120K（60%） | 删掉早期工具返回的超长原始数据，只留摘要（如 1200 Token 的 7 天逐小时预报 → 80 Token 摘要） | 用户完全无感 |
| L2 | 微压缩 MicroCompact | 150K（75%） | 把早期长对话生成简短摘要替换（如 3 轮改稿对话 → "用户要求 Word 格式、改标题、调配色"） | 轻微，关键信息保留 |
| L3 | 折叠 Collapse | 170K（85%） | 多轮早期对话折叠成一条摘要消息（第 1-8 轮 12 条 4200 Token → 350 Token 会话摘要） | 细节丢失，主线保留 |
| L4 | 紧急压缩 AutoCompact | 190K（95%） | 只保留 system + 全局摘要 + 最近 3 轮（18000 Token → 2500 Token） | 明显损失，避免崩溃 |
四层全用尽还继续涨，超过模型上限（如 256K）时，API 直接返回 context_length_exceeded 错误。这就是为什么还需要"上下文急救"作为最终兜底——在崩溃前主动切换策略，而不是让请求失败。
七、记忆体系：短期 + 长期
- 短期记忆 = 上下文窗口：让 Agent 记住当前对话，随压缩策略滚动淘汰。
- 长期记忆 = 向量检索：让 Agent 记住上个月的事，用 Embedding 把历史沉淀进向量库，需要时按语义召回。
两者配合，Agent 才像真正的助手：既了解你现在在做什么，也记得你过去的偏好。
落地长期记忆，常选 Milvus。把它翻译成数据库心智模型，上手极快：
| Milvus | 可类比为 | 职责 |
|---|---|---|
| Collection | 表 | 一组具有同一 Schema 的 Entity |
| Schema / Field | 表结构 / 列 | 约束主键、向量维数与标量类型 |
| Entity | 行 | 一条业务对象；主键必须能稳定定位 |
| Index | 索引 | 加速向量近邻搜索 |
一条知识库 Entity 长这样：
{
"id": 42, # 主键：用于更新、删除、追踪
"vector": [0.12, ...], # 向量字段：用于 Search
"text": "退款通常 3 天到账",
"category": "refund", # 标量字段：用于 Filter / Query
"active": true
}
八、RAG 检索质量工具箱
| 方法 | 解决什么 | 注意 |
|---|---|---|
| 标量 Filter | 租户、权限、时间、语言约束 | 权限必须在检索阶段执行，不能只靠 Prompt |
| 向量 + 关键词混合检索 | 兼顾语义、产品型号、错误码等精确词 | 两种分数尺度不同，不宜直接相加 |
| RRF 融合 | 按排名融合多路结果 | 简单稳健；再用 reranker 精排候选 |
| Partition / TTL | 隔离热点或清理过期数据 | 扩展能力；先用清晰的 collection 与 filter 设计 |
九、ReAct：Agent 的灵魂循环
Agent 的工作方式是一个 「思考 → 行动 → 观察 → 再思考」的循环。一个复杂任务可能循环十几轮。
这正是 Agent 和普通聊天机器人的本质区别：它会根据执行结果调整策略。方案 A 不work，它看观察结果换方案 B，而不是一条路走到黑。
十、Agent 会卡死：5 种典型模式
Agent 不是万能的，它有 5 种典型的卡死模式。好的产品设计正视这些问题，为每种故障预设应对方案：
| 卡死模式 | 现象 | 应对 |
|---|---|---|
| 参数错误 | 工具参数格式不对、字段缺失 | 参数校验 + 自动修正重试 |
| 工具失效 | API 挂了、权限不足 | 工具验证 + 降级提示 |
| 死循环 | 同一个动作反复执行 | 循环检测 + 最大步数限制 |
| 目标模糊 | 用户意图不清，瞎猜乱做 | 主动提问机制，先问清再动手 |
| 任务超时 | 拖太久，占资源 | 超时兜底，中断并给部分结果 |
十一、Agent 权限设计：安全与效率的平衡
Agent 权限有三种模式：
| 模式 | 行为 | 取舍 |
|---|---|---|
| 确认模式 | 每个动作都要用户点头 | 最安全但最慢 |
| 自动模式 | 全部放行 | 最快但最危险 |
| 智能模式 | AI 判断风险等级，低危自动、高危拦截确认 | 平衡（Alice 的做法） |
本质是在安全和效率之间找平衡：全部确认最稳但最慢，全部放行最快但最险。生产系统几乎都在往智能模式走——把风险分级交给模型判断，把"签字权"留给用户。
十二、Skill：把「摸索」变成「执行」
同一个发版任务，没有 Skill 时 Agent 试错 12 轮花 1.5 万 Token 还出 3 个错；有 Skill 时 5 轮搞定、只花 4000 Token、零错误。
Skill 是 Agent 的经验传承机制：一个 Skill 就是一份给 Agent 的 SOP——什么时候触发、按什么步骤执行、能用哪些工具、有什么安全约束。写 Skill 的本质，是把人类专家的经验编码成 Agent 能执行的流程。
十三、生产级脚手架：Agent 工程 = 80% 脚手架 + 20% 模型
大多数 Agent 项目失败，败在错误处理不够健壮，模型够不够聪明反倒是次要的。核心能力来自 LLM，但稳定性来自工程护栏。
5 大能力缺一不可
| # | 能力 | 说明 |
|---|---|---|
| 1 | 超时与重试 | 工具调用设 timeout + 指数退避重试 |
| 2 | 最大步数限制 | max_iterations 防止死循环 |
| 3 | 输入输出校验 | JSON Schema 拦截非法参数 |
| 4 | 状态机 + 回滚 | 检查点恢复，失败不从头来 |
| 5 | 观测与日志 | 全链路记录，生产问题靠日志 |
这 5 道防线决定了你的 Agent 是「能用」还是「好用」：迭代上限防死循环、输出截断防撑爆、超时控制防卡死、中断恢复防损坏、上下文急救防崩溃。
十四、多 Agent 协作：Agent 世界的团队
复杂任务不靠一个 Agent 硬撑，而是拆成多个专职子 Agent：
- 调研员负责读代码、开发者负责改代码、测试员负责验证。
- 只读任务并行加速（同时读互不干扰），写入任务串行保安全（同一份文件不能两个人同时改）。
这就是 Agent 世界的团队协作——把"一个人干所有事"变成"一个团队各司其职"。
十五、可观测性：让 Agent 不是黑箱
Agent 不是黑箱：通过事件流，你可以实时看到它在想什么、做什么、花了多少钱。
每次工具调用（输入/输出）、每次模型返回都记录完整日志，包含时间戳、Token 消耗、延迟。生产环境 90% 的问题靠日志排查——没有日志的 Agent 是黑盒，问题无从定位。推荐集成 LangSmith 或 Arize AI。
可观测性是产品运营的基础设施：没有它，你无法优化成本、排查故障、改善体验。
结语：Agent 入门路线图
把全文串成一张图：
LLM 是大脑，工具调用是手脚，上下文与记忆是工作台，ReAct 是工作方式，Skill 是经验，脚手架是安全带，多 Agent 是团队，可观测性是仪表盘。
入门 Agent，就按这条线走：先搞懂 tool_calls 协议循环（模型出题、框架执行），再学会管好上下文窗口（四层压缩 + 急救），接着把长期记忆接进向量库（Milvus + RAG 工具箱），然后用 ReAct 循环把任务串起来，最后套上生产脚手架、用 Skill 沉淀经验、靠事件流让它可见。
记住那句话：Agent 的核心能力来自 LLM，但稳定性来自工程护栏。 别只追模型，把脚手架打好，你的 Agent 才真正"能用"。