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关键字,或者在数据库层...

