- 博客(39)
- 收藏
- 关注
RSS订阅
原创 Agent 是什么——LLM 只是“嘴”，Agent 才有“手”
从0到1学习agent， Agent是AI领域的新范式，本质是"会动手的AI"。与仅能回答问题的普通LLM和RAG不同，Agent=LLM（大脑）+工具（手脚）+自主决策循环（灵魂）。它通过"思考→行动→观察"循环完成任务（如自动订机票），实现从"知道"到"做到"的跨越。Agent的自主性分6级（L0-L5），核心架构是ReAct循环。生产级Agent需解决幻觉防护、记忆管理等问题。常见误区包括混淆Agent与API调用、过度依赖框架等。下篇将用50行代码实现最小ReAct Agent。
2026-08-01 21:37:49
829
原创 MySQL 索引详解：B+ 树、聚簇索引与最左前缀
结构叶子是否存数据范围查询树高结论哈希❌ 只能等值（没有顺序）只适合等值，如 RedisB 树非叶子也存数据❌ 中序遍历麻烦更高（非叶子大，扇出小）淘汰B+ 树只有叶子存数据，叶子间链表相连✅ 顺着链表扫更矮（非叶子只存 key）InnoDB 用它非叶子节点不存数据，只存 key→ 一个磁盘页（16KB）能塞的索引项远多于 B 树 → 树更矮 → IO 更少叶子节点用链表串联且有序→ 范围查询（）找到起点后顺着链表扫，不用回上层反复遍历。
2026-09-04 19:39:45
646
原创 线程池详解：从 7 大参数到生产避坑
线程池 = 复用线程省创建开销 + 队列缓冲抗洪峰。一条主线：核心跑→队列排→扩线程→拒绝；三个必守：有界队列防 OOM、自定义工厂防裸奔、拒绝计数当容量警报。核心线程数先按类型估（CPU 密集核数+1 / IO 密集核数×2）再用压测校准，参数可热更新。这篇是"Agent 生产底座"的知识铺垫——Agent 系统的并发网关、批量任务处理都依赖线程池，下一篇开始讲 Agent 系统背后的 JVM：你的 Agent 服务跑在什么样的内存模型上，GC 又在什么时候卡你一刀。
2026-09-04 19:39:07
194
原创 真题拆解 07：RAG 召回不准，从哪几方面排查
RAG 召回不准 = 链路某环出问题，先建 badcase 闭环、逐环看 trace，别直接怪模型。五环（改写/检索/重排/截断/生成）各查各的：query 先做无损改写，检索查分块并上混合检索（向量+BM25），重排查排序，截断查最终上下文，四环都净才轮到生成背锅。修没修好用 Hit Rate / MRR 说话，修复必过评测集回归。
2026-09-03 22:29:48
197
原创 真题拆解 06：模型自以为成功提前结案怎么办
假成功 = 模型"正常结束"但结果错误，预算和超时都管不到。兜住它靠：结案必须带证据链（结论引用真实工具返回）、高风险操作二次校验（确定性规则 + 找茬复核）、错误结案进 badcase 闭环（每次被骗长一次记性），并用"错误结案率"持续监控。
2026-09-03 22:29:04
289
原创 MCP 03：MCP 安全与生产落地——开放生态怎么防住恶意工具
MCP 的安全本质是信任链——工具从哪来、可不可信；落地靠五层纵深（传输加密 → 双重鉴权 → 数据脱敏 → 写操作四步法 → 全量审计），外加一个关键架构决策：用统一网关收口所有 Server，把分散的信任收敛成一个可控的信任点。三篇 MCP 专题到这里收尾：入门讲"它是什么"，比对讲"它和谁什么关系"，这篇讲"怎么安全地用"。对 Agent 工程化系列来说，MCP 补上了"工具接入标准"这一块——正片第 3 篇讲了 Function Calling 原理，这三篇把接入层的全景讲完了。
2026-09-02 22:13:20
277
原创 MCP 02：MCP 的各类比对——和 Function Calling、A2A、Skill 到底什么关系
MCP 管"怎么连工具"（标准化接入）、FC 管"模型怎么发起调用"（模型能力，MCP 最终还得走 FC）、A2A 管"Agent 怎么互连"（横向协作）、Skill 管"怎么干活的剧本"（编排）——四个概念各管一段，互补不重复。下一篇是专题的收尾，也是生产里最要命的部分：MCP 是开放生态，工具能随便发布——恶意工具、鉴权裸奔、数据泄露，怎么防？下一篇：《MCP 03：MCP 安全与生产落地——开放生态怎么防住恶意工具》
2026-09-02 22:12:26
370
原创 MCP 01：MCP 到底是什么——Agent 的万能插座
MCP 就是给 Agent 的工具接入定义了"万能插座"——工具方做一次 Server、模型方做一次 Client，把 M×N 的集成问题降成 M+N；协议核心是 JSON-RPC 上的三步流程：握手 → 发现 → 调用。下一篇把 MCP 放进对比桌：它和 Function Calling 是什么关系？和 A2A、Skill 怎么分？为什么有人说 MCP 会"终结"各家私有协议？下一篇：《MCP 02：MCP 的各类比对——和 Function Calling、A2A、Skill 到底什么关系》
2026-09-01 22:28:12
529
原创 真题拆解 05：ReAct 还是 Plan-and-Execute——规划范式怎么选
路径能枚举用 Plan（省、稳），路径未知强依赖反馈用 ReAct（活、贵）；而生产主流是"粗规划 + 局部 ReAct"——计划给方向，ReAct 处理细节，两边的软肋互相补掉。
2026-09-01 22:26:58
249
原创 真题拆解 04：模型一次调了三个工具——并行调用怎么管
并行不是"一把梭"——先判依赖（能并才并）、再限并发（打不爆外部）、独立超时（卡不住整体）、聚合返回（配对不乱）；而写操作工具不幂等，并行就是灾难。
2026-08-27 20:53:20
739
原创 真题拆解 03：多 Agent 互相推诿任务怎么办
多 Agent 不推诿的前提是三个设计同时到位：职责边界靠工具集隔离锁死，任务所有权靠接收协议锁定，踢皮球靠计数熔断加人工兜底——缺一个，任务就会在 Agent 之间踢到天荒地老。
2026-08-26 22:24:51
177
原创 真题拆解 02：ReAct 消息格式——工具结果到底以什么身份返回
工具结果必须以独立的 tool 身份、带 tool_call_id 精确配对返回——因为模型只认消息角色来判断"这是谁说的"，身份错了，理解就错了。
2026-08-26 22:23:38
281
原创 底座 02：Agent 系统要不要上消息队列——Kafka 在异步任务里的角色
消息队列 = 把"等不起的操作"交给后台慢慢做——用户先拿到"已受理"，worker 慢慢做完再通知；而 Kafka 用分区换吞吐、用 ISR 换不丢、用 key 路由换顺序。Redis 解决"重复算的账"，Kafka 解决"等不起的活"——Agent 系统的两块成本地基都铺好了。十万 QPS 的 Agent 网关，并发和线程池怎么设计。下一篇：《底座 03：十万 QPS 的 Agent 网关怎么做——并发与线程池》
2026-08-25 23:36:53
274
原创 底座 01：Agent 的 token 成本怎么砍——Redis 缓存实战
缓存方案很多（本地 Map、数据库、文件），但 Agent 系统里 Redis 几乎是标准答案。为什么？Redis = 内存 KV 存储，数据结构上天生匹配"问题 → 答案"这种映射。key 放归一化后的 query，value 放模型答案，TTL 设过期时间——三个能力正好覆盖需求，不用自己造轮子。@Service// 1. 先查缓存if (cached!= null) {// 命中：零成本// 2. 没命中才调模型就这么几行，重复问题直接短路。
2026-08-25 23:36:13
260
原创 真题拆解 01：Agent 死循环了，异常处理写在哪
工具层把异常转成结构化错误让模型看懂（治"盲目重试"），推理层用最大轮数 + 重复动作/无进展检测 + 熔断器切断失控（治"绕圈子"），系统层用 token/超时/调用次数预算兜住成本（治"烧钱"）。只设最大轮数是不够的——那是最后一道闸，不是第一道防线。终止必须收尾四步：停循环、报进度、记日志、给人/重新规划。
2026-08-24 12:03:47
524
原创 深度 7：LangGraph 的点和边——图式编排到底在编排什么
图式编排的四件套是 State、Node、Edge、条件边。点是执行动作的单元，边是节点间的流转关系——普通边固定、条件边由路由函数根据 State 动态决定下一跳，决策活在边上不活在节点里。生产图的点边设计：点=各意图路由节点（内部是受限 ReAct 循环，工具集和循环上限各不同），边=入口条件边、护栏边（证据不足降级）、兜底边（预算耗尽优雅收尾），出口边共享、节点内部各异。加路径 = 加节点加边，不动原有逻辑，这就是图相比 while 循环的核心价值。
2026-08-24 12:03:04
300
原创 深度 5：Tools、Workflow、Agent——零件、流水线、能换线的机器人
有人问你：最常见的回答是列一张对比表，好像三者是互斥的选项。但真实系统里，一个 Agent 内部同时有 Tools 和 Workflow——所以"区别"这个词本身就问错了方向。正确的理解是：它们不是同一维度的东西，而是从小到大嵌套的三层结构。 判别三者只看一件事：Tools 就是一个封装好的函数：有明确的输入参数、明确的输出结果，仅此而已。它和普通函数唯一的区别是：要额外写一份"说明书"（name、description、parameters），让模型知道有这个能力、什么时候该调它、参数怎么填。关键设计：
2026-08-20 20:57:34
334
原创 深度 4：Skill 与 Tool——剧本和演员，还有 Skill 到底存哪
本文深入探讨Agent工程化中Skill与Tool的关系以及Skill存储方案。核心观点如下： Skill与Tool的关系： Tool是原子执行单元（如查日志），Skill是编排层知识（如故障诊断流程） 类比为"剧本与演员"：Skill指导Agent如何调用Tool，自身不直接执行 Skill是数据（流程描述），Tool是代码（可调用函数） Skill存储的三层架构： L1元数据（名称/描述）常驻内存 L2具体内容按需加载 L3成功案例定期沉淀 采用渐进式加载策略避免上下文膨胀 SQLite存储的四大优势：
2026-08-20 20:52:57
343
原创 深度 3：意图路由——「模糊的 query」到底怎么判断
本文探讨了AI Agent意图路由中的模糊查询判断问题。文章指出，在生产环境中，准确识别用户模糊查询意图是提升交互质量的关键。作者提出了意图路由的完整流程框架，分析了模糊判断的三大难点，并对比了三种解决方案：基于规则打分的基础方案、规则+LLM兜底的过渡方案，以及采用3B小意图模型的进阶方案。文章建议采用渐进式演进路线，强调规则系统应覆盖80%明确查询，剩余模糊查询由LLM或小模型处理。最后总结了三个常见实施误区，包括全量使用LLM、随意设置阈值和不测试边界案例。文章为构建高效的意图路由系统提供了实用指导。
2026-08-11 22:32:38
501
原创 深度 2：记忆压缩——上下文装不下时，怎么保住关键信息
不丢内容，把多条记忆合并成更紧凑的表述。滚动摘要：对话达到一定长度时，让 LLM 把早期对话总结成一段摘要，替换掉原始长消息。经典模式是[系统提示] + [历史摘要] + [最近 N 轮完整对话]结构化摘要：摘要时按固定字段抽取（用户诉求、已确认的事实、待办事项、决策结论），比自由摘要更可控、更可检索双层摘要：高层摘要（如"本周对话主题"）+ 低层事件列表（带时间戳的关键事件），兼顾概括和细节代价：摘要会丢细节，而且越滚越长——摘要本身也在增长，需要周期性地"摘要的摘要"。
2026-08-11 22:30:36
190
原创 深度 1：Reflection 反思机制——Agent 做错了能自己改吗
本文探讨了AI代理(Agent)中的反思机制(Reflection)及其工程实现。反思机制是Agent区别于一次性生成器的关键能力，其本质是一个包含生成、评估、改进三环节的闭环系统。核心观点包括： 反思机制不同于简单重试，是基于评估结论的定向修改，评估环节是关键，需提供具体检查维度和PASS出口。 三种主流实现范式： Self-Refine：模型自评自改，适合文案润色 Reflexion：依赖环境反馈（如工具报错），适合代码执行 ReAct+Reflection：结合观察和反思，适合多步推理 实践建议： 优
2026-08-10 22:58:24
246
原创 番外 3：框架选型决策——真实生产团队到底怎么选
本文探讨了AI Agent框架选型的核心决策逻辑。通过分析Klarna、Uber等大厂案例与自研场景的对比，指出选型关键在于评估需求与框架能力的匹配度。60%的生产事故源于状态管理失败，这是框架的主要价值所在，但框架也存在学习成本、性能陷阱等隐性代价。提出决策四问法（差异化、模型匹配、团队规模、迁移路径）和面试三句话术（评估过、规模匹配、留路径），强调合理选型不是简单站队，而是基于场景的理性权衡。最后提醒三个常见误区：不要为省钱自研、重视状态管理风险、避免无评估的自研决策。
2026-08-10 22:54:47
288
原创 番外 2：LangGraph 深挖——框架到底帮你做了什么
文章摘要： LangGraph框架本质是对手写ReAct循环的工程化封装，核心解决了三个问题：状态管理（State结构化存储）、流程控制（Node-Edge图结构）和可观测性（内置LangSmith）。它将循环步骤抽象为节点，转移逻辑定义为边，通过状态图（StateGraph）实现确定性流程。框架提供断点恢复、人工审批等生产级能力，但需权衡学习成本与抽象复杂度。LangGraph并非万能，适合复杂场景的工程化需求，简单任务仍可手写实现。结论：框架选择应基于实际场景需求而非技术热度。
2026-08-08 23:34:52
741
原创 番外 1：Agent 框架横评——LangGraph、OpenAI SDK、CrewAI、Dify 怎么选
本文是Agent工程化系列的番外篇，对主流Agent框架进行横向对比。首先提出2026年框架生态已经分化为四层架构：Runtime运行时引擎（如LangGraph）、SDK开发套件（如OpenAI Agents SDK）、多Agent编排层（如CrewAI）和AI应用平台（如Dify）。每层各有特点：越底层越可控但难度高，越上层越便捷但黑盒化。 文章详细分析了四种代表性框架：LangGraph作为生产级状态机引擎，适合需要精细控制的团队；OpenAI SDK提供极简API，适合快速原型开发；CrewAI以角
2026-08-08 23:32:40
783
原创 Agent 评测与回归——怎么证明它「变好了」
文章摘要 本文探讨了Agent评测与回归的核心问题：如何量化证明Agent的改进效果。文章指出，仅凭"感觉更聪明了"不可靠，必须通过固定评测集进行量化评估。评测应从正确性、性能、安全、成本四个维度综合考量，采用离线评测和LLM-as-judge方法进行验证。关键建议包括：建立固定评测集作为迭代基础，设置质量发布门槛，通过坏案例驱动持续优化，并避免评测中的常见陷阱。作为"Agent工程化"系列终篇，文章将前10篇内容串联起来，强调Agent工程需要能力、约束、可见性和验证四者的系统化整合。最终指出，可靠的Ag
2026-08-07 19:22:27
220
原创 生产级 Agent 部署与可观测——给 Agent 装「行车记录仪」
Agent上线后必须构建完善的可观测体系，包括全链路trace记录（步骤、思考、工具调用、参数、结果、成本等关键信息），采用批量写入、异步处理等技术方案避免性能瓶颈；同时需建立降级策略保证服务可用性，设置核心指标告警机制，并满足审计合规要求。要特别注意日志量的合理控制，避免过度记录导致存储压力。可观测性是定位Agent运行问题的关键，也是后续评测优化的基础。（149字）
2026-08-05 23:23:42
171
原创 给 Agent 装上护栏——harness 层设计
本文是「Agent 工程化」系列第九篇，重点讨论如何通过"护栏（harness）"机制确保智能代理（Agent）的可控性。文章从实际场景出发，指出Agent可能陷入死循环、超额消耗资源等问题，并提出解决方案： 三层预算控制：设置单次调用、单轮循环和整个会话的资源上限，超限后优雅终止而非硬中断 工具白名单机制：按任务场景动态分配工具权限，对写操作强制人工确认 智能重试策略：区分网络故障（自动退避重试）和业务错误（反馈修正） 断点恢复能力：持久化会话状态（包括上下文、预算和进度）确保服务中断后可续接 异常检测机
2026-08-05 22:39:21
596
原创 编排模式与多 Agent——复杂任务怎么拆
本文探讨了Agent工程化中复杂任务的拆解与编排模式。文章以三亚5日游规划为例，分析了单循环ReAct模式的局限性，提出三种编排方案：灵活的ReAct、先规划后执行的Plan-Execute模式（可并行处理无依赖任务）和严格受控的状态机模式。作者建议根据任务复杂度、并行性和流程可控性选择合适模式，强调"够用就好"原则。对于多Agent协作，指出应谨慎评估必要性，避免过度设计。最后对比了自研实现与框架方案的优劣，建议先掌握核心原理再考虑框架使用，以确保系统可控性和可调试性。
2026-08-04 22:55:00
240
原创 Skill 系统——让 Agent 从成功经验里学习
这篇文章介绍了如何通过Skill系统让AI智能体(Agent)从成功经验中学习，避免重复处理同类问题。主要内容包括： 痛点分析：当前Agent对相同问题每次都要从头推理，浪费资源且结果不稳定。 Skill定义：将成功解决方案沉淀为可复用的"技能"，包含问题特征、处理步骤和工具调用序列。 两级加载设计： L1元数据(关键词和描述)常驻内存，占用极少token L2完整指令仅在命中关键词时注入 自学习机制：成功处理的问题经过通用性检查和去重后，自动提炼为新的Skill。 质量控制：通过去重策略、三层质量检查和健
2026-08-04 22:50:58
306
原创 RAG 与向量知识库——让 Agent 有「知识」
本文介绍了RAG（检索增强生成）技术在AI助手中的应用，主要解决LLM因缺乏特定业务知识而"编造答案"的问题。文章通过机票改签的案例，对比了传统LLM的"闭卷"模式和RAG"开卷"模式的区别，详细阐述了RAG的四步实现流程：文档切分、向量化、检索和带资料生成。重点指出生产环境中需要优化的四个关键点：多路召回融合、元数据过滤、动态TopK和检索质量评估。文章强调RAG的核心价值是让AI在回答前先查阅业务资料，并特别提醒当检索不到相关信息时应明确回答"不知道"，避免编造内容破坏用户信任。最后预告下篇将探讨如何通
2026-08-03 16:59:46
202
原创 Memory 记忆系统——让 Agent 记住用户
本文介绍了AI Agent的Memory记忆系统，旨在解决跨会话信息丢失问题。文章将记忆系统分解为三个核心机制：存储、写入和检索，并区分了四种记忆层级（短期、工作、长期、语义）。作者强调写入门槛的重要性，建议仅存储具有长期价值的信息，而非所有对话内容。文章还讨论了生产环境中记忆维护的关键问题，包括记忆过期清理、用户遗忘权和动态调整记忆权重。最后，作者警告避免"全记全忘"陷阱，指出记忆系统应是精选过滤器而非简单仓库。该记忆系统使Agent能够真正记住用户偏好和重要事实，实现跨会话的连贯体验。
2026-08-03 16:57:39
328
原创 上下文管理——Agent 的「工作记忆」
上下文管理：Agent的"工作记忆"解决方案 在Agent工程化中，上下文管理是核心挑战。由于模型上下文窗口有限（如8K/32K token），长对话会导致关键信息被挤出视野，表现为"失忆"。本文提出三种应对策略： 滑动窗口：仅保留最近N轮对话，简单但易丢失早期重要信息 摘要压缩：用LLM将旧历史浓缩为要点，平衡信息保留与token消耗 截断优化：结构化处理工具返回的大数据，保留关键字段 生产级解决方案采用分层结构： 锁住区：永久保存用户偏好、任务目标和关键操作 摘要区：压缩旧历史 滑动区：保留最近对话细节
2026-08-02 18:39:28
183
原创 Function Calling 原理与 Tool 设计——教 LLM 学会「点菜」
本文介绍了 Function Calling 的工作原理及其在 LLM 工具调用中的优势。通过类比餐厅点菜场景，说明 Function Calling 让 LLM 能够输出结构化的调用意图（工具名+参数），而非自由文本，从而提高可靠性。文章详细解析了 Function Calling 的完整流程，包括工具定义、模型响应和执行过程，并对比了与之前文本协议方式的差异，强调 Function Calling 作为业界标准在生产环境中的优势，如结构化输出、参数校验和多工具并行支持等。
2026-08-02 13:33:57
202
原创 手写一个最小 ReAct Agent（50 行代码）
这篇文章介绍了一个50行Python代码实现的简单ReAct Agent，用于处理天气查询任务。要点包括： ReAct原理：通过"推理-行动-观察"循环，让模型逐步完成任务 核心实现： 两个工具函数：获取城市代码和天气信息 主循环逻辑：模型输出指令→执行工具→观察结果→循环 关键设计： 模型只输出指令，代码负责实际工具调用 完整记录对话历史，形成闭环 设置双重终止条件（模型主动结束/最大步数限制） 文章通过一个"查询北京明天天气是否需要带伞"的示例，展示了Agent如何分步完成任务。代码简洁但完整实现了Re
2026-08-01 23:18:58
364
原创 黑马点评中使用测试工具添加秒杀卷
本文介绍了使用ApiPost工具测试黑马点评秒杀券功能的完整流程。首先下载安装ApiPost，然后分三步进行测试：1)发送验证码请求获取验证码；2)使用验证码登录获取token；3)携带token添加秒杀券。文中详细说明了每个请求的URL、参数设置和注意事项，包括手机号一致性、验证码获取、token提取等关键步骤。通过这种方式，开发者可以在不依赖前端的情况下，独立完成后端逻辑的测试验证，解决初学时前后端联调困难的问题。最后提供了秒杀券的JSON模板供参考修改。
2026-03-26 22:55:09
624
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人