AI Agent开发记录
本文记录了AI Agent开发过程中的探索和实践，本文作者是鹅厂架构师 hardyqliu 什么是 AI Agent第一步是去了解什么是 AI Agent。 AI Agent 的定义在这篇文章中总结的很好：lilianweng.github.io… 下面这个图也比较经典： 简单讲，目前的 AI Agent 是使用 LLM 作为大脑（决策器）的智能体。基于 LLM 的逻辑推理能力理解并规划任务执行，结合工具调用和记忆系统完成任务。 设计一个 Agent要实现一个 AI Agent，就是将上面讲的 LLM、工具、检索以某种形式组合在一起。 关于如何构建 Agent，Anthropic 的几篇文章写的很好： Building Effective AI Agents \ Anthropic Writing effective tools for AI agents—using AI agents \ Anthropic How we built our multi-agent research system \ Anthropic OpenAI的Agent白皮书也可以参考...
Agent篇(15)：编排治理层 (Layer 7) —— 上帝视角：全链路追踪、成本监控与自动化评估体系
导语：CFO 的愤怒 月末，财务总监（CFO）拿着一张 $50,000 的 OpenAI 账单冲进了 CTO 的办公室。 “谁能解释一下，为什么上个月 Token 费用翻了十倍？是哪个业务线跑出来的？是那个写诗的 Bot，还是那个查报表的 Bot？” 没人能回答。大家面面相觑。后端工程师只能看到日志里满屏的 200 OK。我们知道系统在跑，但我们不知道它在裸奔。 盲区一： 你不知道一个简单的“帮我查下这周数据”，背后 Agent 到底循环了多少次，调用了多少次 GPT-4。 盲区二： 你不知道昨天上线的那个 Prompt 优化，到底是让 AI 变聪明了，还是变傻了。没有单元测试，只有“体感”。 盲区三： 某个用户恶意刷量，你的系统还在傻乎乎地陪聊，直到把预算烧光。 这就是缺乏治理的代价。在 L7 编排治理层 (Orchestration & Governance Layer)，我们要为这个黑盒装上 CT 扫描仪。我们要把每一次思考、每一个 Token、每一分钱，都映射到可视化的大屏上。 第一部分：第一性原理——从日志到链路 (From Logs to Trac...
Agent篇(14)：交互协同层 (Layer 5) —— 人机共舞：异步通信、主动反问与 HITL 最佳实践
导语：沉默的杀手你是否遇到过这样的“智能”客服？ 你：“帮我退款。”AI：“好的，正在为您办理。”（五分钟过去了，屏幕一片死寂…）你：“喂？还在吗？”AI：“系统处理中，请稍候。” 或者更糟的场景： AI：“请提供订单号。”你：“是昨天下午买的那个红色的杯子。”AI：“抱歉，我不理解。请提供订单号。”你：“…” 这两个场景暴露了 Agent 系统的两大交互顽疾： 黑盒焦虑 (Black Box Anxiety)： 用户不知道 AI 在干嘛，是在思考？在查库？还是死机了？ 沟通僵局 (Communication Deadlock)： 当信息不足时，AI 像个死板的填表机器，不懂得像人一样通过“追问”来获取上下文。 在 L5 交互协同层，我们的目标是打破这种沉默与僵局。我们要让 Agent 学会显式地展示思考过程，学会聪明地感知信息缺失并优雅地请求人类帮助。让它从一个冷冰冰的执行者，变成一个有温度的协作者。这就是 Human-in-the-Loop (HITL) 的真谛。 第一部分：第一性原理——同步 vs 异步的鸿沟 为什么传统的 Request-Response ...
百万架构师成长之路(24)：【终极实战篇·特别篇】简历的“升维打击”：从秒杀项目看不同级别工程师的自我包装艺术
导语：你的简历，是你价值的“作战报告”在我们的职业生涯中，简历，可能是我们写过的最重要、也最被低估的“项目文档”。 我们常常花费数月甚至数年的时间，去构建一个复杂的系统，却只愿意用几个小时，去草草地罗列自己做过的事情。我们写的简历，就像一份流水账式的“工作日志”，充满了技术名词的堆砌，却缺乏一个引人入胜的“故事”，更没有一个清晰的“价值主张”。 一个残酷的真相是：你的能力再强，如果无法在简历这短短的“30秒电梯演讲”中清晰地传达出来，那么在面试官眼中，你的能力就约等于零。 “雷神之锤”秒杀项目，对于参与其中的每一个人，都是一次宝贵的职业镀金。但是，如何将这份“金”提炼出来，并打造成一枚符合自己身价的“勋章”，却是一门需要精心设计的艺术。 本篇，我们将以一个前所未有的视角，剖析同一个顶级项目，在四位不同级别的工程师简历中，会呈现出怎样截然不同的面貌。我们将学习如何： 从“我做了什么”（What I did）升级到**“我实现了什么价值”**（What I achieved）。 从“技术点的罗列”升级到**“技术深度的展现”**。 从“被动的执行者”升级到**“主动的思考者和影响者...
百万架构师成长之路(23)：【终极实战篇·复盘】架构的“胜利之道”:秒杀系统全景复盘与思想沉淀
导语：从“一张草图”到“一座堡垒”，我们的战争与和平在双十一的凌晨，当最后一波流量洪峰平稳地退去，Grafana作·战大盘上的QPS曲线从陡峭的山峰回归宁静的平原时，“雷神之锤”秒杀项目的指挥室里，响起了一阵克制的欢呼。我们成功了。但对于架构师而言，一场战役的结束，仅仅是另一场更重要战役的开始——复盘。如果说“打胜仗”证明了我们架构的有效性，那么“复盘”则是为了提炼出那些可以被复制、被传承的“胜利之道”，并将它们沉淀为团队乃至整个组织的技术资产。一个不懂得复盘的团队，每一次胜利都只是侥幸；而一个精于复盘的团队，才能将偶然的成功，转化为必然的能力。在过去的几个月里，我们从CEO的一纸“军令状”开始，经历了一场从无到有、从理论到实践的完整架构之旅。我们绘制了蓝图，构建了防线，重塑了流程，优化了内核，并最终用残酷的压测和混沌实验，为这套系统注入了“反脆弱”的基因。本篇，将不再是关于某个具体技术的“术”，而是关于整个架构设计过程的“道”。我们将以一次完整的项目复盘为线索，重新走过这段旅程，系统地梳理我们在每一个关键节点所做的决策、所面临的权衡、所采纳的策略，以及它们背后更深层次的架构思...
百万架构师成长之路(22)：【终极实战篇·终章】终极试炼：全链路压测与混沌工程——为系统注入“反脆弱”的基因
导语：从“祈祷它能工作”到“确信它不会失败”经过数月的精心设计与极限优化，我们的“雷神之锤”秒杀系统，已经从一张蓝图，变成了一套部署在云端的、由数十个微服务组成的复杂生命体。它拥有了坚固的外部防御、流畅的核心流程、经过深度优化的数据存储和高效的并发模型。在上线前的最后一次架构评审会上，你向CTO和所有相关方，自信地展示了这套堪称艺术品的架构。“…我们的系统，理论上可以承受百万QPS的入口流量，核心下单链路的P99延迟在50ms以内，并且通过多级缓存和异步解耦，保证了数据库的绝对安全…”在你汇报结束时，CTO点了点头，然后提出了那个所有架构师都必须回答的终极问题：“理论上？你怎么证明？你怎么让我相信，在双十一那天凌晨，当真实的、混乱的、不可预测的流量洪峰涌来时，你这套完美的‘理论’不会像纸糊的城堡一样，一触即溃？”这个问题，直击灵魂。它标志着架构师工作的下半场——验证——的开始。上半场，我们追求的是“构建正确（Build it Right）”；下半场，我们必须证明我们“构建的是正确的系统（Build the Right System）”。从“祈祷它能工作（Hope it work...
百万架构师成长之路(21)：【终极实战篇·七】极限压榨：Redis内存优化与JUC并发编程的艺术
导语：当性能的战场，从磁盘转移到纳秒级的内存世界在过去的几个篇章里，我们构建了从外到内的层层防御，重塑了核心的下单流程，并对最终的“真相之源”MySQL进行了深度优化。我们的“雷神之锤”系统，在宏观架构层面，已经趋于完善。但真正的卓越，源于对微观世界的极限压榨。现代高性能系统的战争，早已从毫秒级的磁盘I/O，升级到了微秒级甚至纳秒级的内存访问。在这场战争中，我们手中最锋利的两把剑，便是Redis和Java自身的内存与并发模型（JUC）。Redis，作为我们架构的“首席内存官”，承载了库存预扣减、用户资格校验、分布式锁等最核心、最频繁的读写操作。它的性能和容量，直接决定了我们系统能支撑的并发上限。Java应用（Seckill-Core服务），作为执行命令的“作战单元”，其内部的线程管理、内存使用效率，则决定了它能否将硬件的性能百分之百地转化为业务处理能力。然而，我们常常满足于对它们“开箱即用”式的应用：redisTemplate.opsForValue().set()、Executors.newFixedThreadPool()。这种“黑盒”式的使用，在常规业务中或许无...
百万架构师成长之路(20)：【终极实战篇·六】深渊之战：MySQL的极限优化与InnoDB灵魂拷问
导语：当秒杀的洪流抵达“世界尽头”在前五章的史诗旅程中，我们构建了一套宏伟的分布式防御工事。流量从用户的浏览器出发，历经客户端的智能阻截、CDN的全球幽灵网络、Nginx的铁壁、Sentinel的精细手术、Redis的内存闪电战，以及RocketMQ的异步洪峰转移。最终，那些承载着用户真金白银的、珍贵的订单数据，抵达了它们旅程的终点，也是我们整个系统“真相的源头”（Source of Truth）——MySQL数据库。很多架构师在这里会长舒一口气，认为最艰难的时刻已经过去。这是一个致命的错觉。数据库，是我们整个架构的“地基”。如果地基不稳，上层建筑无论多么华丽，都终将倾覆。在秒杀场景下，即使经过了消息队列的“削峰填谷”，在订单创建的几分钟内，数据库依然要承受远超平时的、密集的写入压力（INSERT）和少量但关键的读取压力（SELECT）。如果我们的MySQL服务器依然停留在“开箱即用”的状态，如果我们的表结构设计依然遵循着教科书式的“三范式”，如果我们的索引策略依然是“随手一加”，那么等待我们的，将是：**慢查询（Slow Query）**拖垮整个应用。**死锁（Deadloc...
百万架构师成长之路(19)：【终极实战篇·五】风暴之后：构建系统的“上帝之眼”——全链路可观测性体系
导语：从“黑盒”到“白盒”，当系统拥有了“灵魂”我们的“雷神之锤”秒杀系统，在经历了蓝图绘制、前哨防御、壁垒构筑和核心流程重塑之后，已经具备了应对流量风暴的强大能力。它就像一头肌肉发达的巨兽，充满了力量。但是，这头巨兽是沉默的。当用户抱怨“抢购失败”时，请求究竟死在了漫长调用链路的哪一环？是CDN？是Nginx？是网关的限流？是Redis库存不足？还是订单服务的数据库写入超时？当系统整体响应变慢时，瓶颈究竟是CPU、内存、网络，还是某个下游服务的抖动？当秒杀活动结束后，我们该如何精确地复盘整个过程的流量曲线、资源消耗和潜在风险？一个没有被充分观测的系统，就是一个“黑盒”。无论其内部设计多么精妙，对我们而言，它都是一个运行在“薛定谔的猫”状态下的、充满不确定性的存在。运维和排障，将变成一场依赖猜测、经验和运气的“玄学”。本篇，我们的任务，就是打破这个“黑盒”，为这头巨兽注入“灵魂”，让它学会“言说”。我们将深入探索现代分布式系统的基石——可观测性（Observability）。我们将不再把Logging（日志）、Metrics（指标）、Tracing（追踪）视为三个孤立的技术，而...
百万架构师成长之路(18)：【终极实战篇·四】核心之战：乾坤挪移——用缓存和消息队列重塑下单流程
导语：风暴之眼，直面架构的“灵魂拷问”在前三章的铺垫中，我们构建了一个堪称铜墙铁壁的防御体系。从客户端到CDN，再到Nginx和Sentinel，我们像剥洋葱一样，层层削减了99.9%的无效流量。现在，那些通过了重重考验的、最高质量的请求，终于抵达了风暴的中心——秒杀核心服务 (Seckill-Core Service)。在这里，我们必须回答整个秒杀架构中最核心、最致命的“灵魂拷问”：当成千上万的线程在同一毫秒，企图对同一个商品的库存（一个共享变量）进行减一操作时，我们如何保证：原子性（Atomicity）： “读取库存、判断是否足够、减库存”这三个动作必须捆绑执行，不可分割，否则就会出现“超卖”。高性能（High Performance）： 处理过程必须在内存中以微秒级完成，任何对数据库的同步操作，都将引发灾难性的性能雪崩。一致性（Consistency）： 如何确保缓存中的库存与数据库中的最终库存保持一致？这个问题，是分布式系统领域“数据一致性”与“高性能”这对永恒矛盾的经典缩影。任何试图用传统方式——例如，在Java代码中使用synchronized关键字，或者在数据库层...